From srivatsan.raghavan@aricent.com Thu Jul 1 04:27:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310613A6826 for ; Thu, 1 Jul 2010 04:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68+NNOyouiwv for ; Thu, 1 Jul 2010 04:27:28 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id C407B3A6405 for ; Thu, 1 Jul 2010 04:27:27 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id ECEC636B7A for ; Thu, 1 Jul 2010 16:57:12 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id D79DD36B75 for ; Thu, 1 Jul 2010 16:57:12 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 1 Jul 2010 16:57:33 +0530 From: Srivatsan Raghavan To: "ccamp@ietf.org" Date: Thu, 1 Jul 2010 16:57:31 +0530 Thread-Topic: Co-routed bidirectional XC entries Thread-Index: AQHLGRAXYNRcXWmtnkOK2rmkpcL/0Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] Co-routed bidirectional XC entries X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 11:27:29 -0000 Hi all RFC 4802/03 introduces the gmplsTunnelDirection object which has an additio= nal enumeration to specify a bidirectional tunnel. This I assume, is used for co-routed bidirectional tunnels , independent of= whether the tunnel is static or signalled. So there is one tunnel row instance, and there is no reference as such to a= remote tunnel number. Is this understanding right ? Secondly, As per RFC 4803, for such a [ co-routed ] bidirectional tunnel, there are t= wo XC entries, [for each of the directions] Both these XC entries share the same XC index and that is how these two XC = entries are co-related. In that sense the example in RFC 4803 needs to be c= orrected [ it shows two different XC indices example below : In mplsXCTable: { mplsXCIndex =3D 0x01, mplsXCInSegmentIndex =3D 0x00000015, mplsXCOutSegmentIndex =3D 0x00000012, ... < snip> } In mplsXCTable: { mplsXCIndex =3D 0x02, =3D=3D=3D> should also read 0x01 mplsXCInSegmentIndex =3D 0x00000016, mplsXCOutSegmentIndex =3D 0x00000013, .. < snip > } Is this understanding right that the example needs to be corrected or is there some other interpretation to this ? Thanks Srivatsan "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From pierre.peloso@alcatel-lucent.com Thu Jul 1 07:54:25 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59DB3A6833 for ; Thu, 1 Jul 2010 07:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrYBvFO5umje for ; Thu, 1 Jul 2010 07:54:24 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7ACC93A67F2 for ; Thu, 1 Jul 2010 07:54:24 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o61EsMBo007323 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Jul 2010 16:54:31 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 1 Jul 2010 16:54:30 +0200 From: "PELOSO, PIERRE (PIERRE)" To: "ccamp@ietf.org" Date: Thu, 1 Jul 2010 16:54:28 +0200 Thread-Topic: Proposed contribution to draft-bernstein-ccamp-wson-signaling-06 Thread-Index: AcsZLU5paSjtiZtjQGKSJ+uf7gUbGQ== Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [CCAMP] Proposed contribution to draft-bernstein-ccamp-wson-signaling-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:54:25 -0000 Hi ccampers and Greg, =20 During the latest meeting in Anaheim, I was asked to propose on the list fo= r discussion some text dealing with the re-introduction of wavelength metri= c inside the signalling draft by Greg. The wavelength metric object is to b= e used inside the path message when performing LSP request. The interest of the metric is to enrich the information collected on the wa= velength availability, which could be used to perform wavelength differenti= ations according varying criteria. So here is the text that I find fitting properly the needs, it actually is = a slight adaptation of the text that was contained inside the first version= of this draft: Distributed wavelength assignment makes extensive use of the label set object/TLV of [RFC3471]. Some wavelength assignment algorithms=20 require supplemental information concerning the potential lambdas to be used. An ordered set of TLVs in correspondence with the group of one or more label set TLVs can be used to convey this information in the form of a general wavelength "acceptability" metric. Note that the label set syntax of [RFC3471] allows group of wavelengths into ranges. For the purpose of supplementing this information with wavelength count only those wavelengths with the same counts could be grouped. The general format for supplemental wavelength selection information could be as follows: The information carried in a Wavelength Set Metric TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Info Type | Metric Size | Num Metrics | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Metric Info | | From lowest to highest frequency if more that one value | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Info Type: 8 bits 0 - Single Value The enclosed single value for the wavelength metric is given to all wavelengths in the corresponding wavelength set. 1 - List The enclosed list gets applied in a one-to-one fashion to each wavelength in the corresponding wavelength set. An error occurs if the number of metrics in this list and the number of wavelengths in the wavelength set is not equal. Metric Size: Indicates the size of the wavelength metric information as follows 0 - 8 bits 1 - 16 bits 2 - 32 bits Number 0f Metrics: 24 bits Wavelength Metric: (1, 2, or 4 octets) The wavelength metric represents in some fashion the desirability or lack thereof to use this wavelength over another available wavelength. Different wavelength assignment algorithms may use this information differently. Regards, Pierre _____________________________________________________ Pierre Peloso Engineer =20 +33 1 3077 2662 Network & Networking rte de Villejust 91620 Nozay (France) Alcatel-Lucent From lberger@labn.net Fri Jul 2 07:07:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909C83A68E7 for ; Fri, 2 Jul 2010 07:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7J1hRtcoHbd for ; Fri, 2 Jul 2010 07:07:30 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 77E8D3A68E6 for ; Fri, 2 Jul 2010 07:07:30 -0700 (PDT) Received: (qmail 2731 invoked by uid 0); 2 Jul 2010 14:07:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 2 Jul 2010 14:07:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=hng6DAccn8AQfoPGoGxc9xFQjOvwG2txbyhMrxfPfRXIG4w01Z1BLLI1xfH7VZYV+eR+VnhWMiOwjSuGo2rYg1v8Ct0tsl+m5aMlFWjrBJSy0QG51wLz4UiBCUsft7yN; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OUgu6-0007Gg-6K; Fri, 02 Jul 2010 08:07:42 -0600 Message-ID: <4C2DF2C6.10103@labn.net> Date: Fri, 02 Jul 2010 10:08:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201006300702.o5U72GWq003232@harbor.orleans.occnc.com> In-Reply-To: <201006300702.o5U72GWq003232@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, MPLS WG Chairs , Deborah Brungard Subject: Re: [CCAMP] please consider draft-villamizar-mpls-tp-multipath as WG item X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 14:07:31 -0000 Curtis, This is certainly and interesting document. As it covers TP data plane functions, it really belongs in the MPLS WG and not the CCAMP WG. I suggest you ask for a slot in the mpls WG as part of the MPLS-TP session. Lou On 6/30/2010 3:02 AM, Curtis Villamizar wrote: > CCAMP WG, > > Please consider adopting draft-villamizar-mpls-tp-multipath-00 as a WG > item. > > Lou, Deb, > > Even though this is just beyond 24 hours after you asked that time > slots be requested, please try to fit in a short time slot at IETF78. > > Curtis > > > ------- Forwarded Message [multiple blank lines removed] > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, June 29, 2010 9:51 PM > To: Curtis Villamizar > Subject: New Version Notification for draft-villamizar-mpls-tp-multipath-00 > > A new version of I-D, draft-villamizar-mpls-tp-multipath-00.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. > > Filename: draft-villamizar-mpls-tp-multipath > Revision: 00 > Title: Use of Multipath with MPLS-TP and MPLS > Creation_date: 2010-06-29 > WG ID: Independent Submission > Number_of_pages: 35 > > Abstract: > Many MPLS implementations have supported multipath techniques and > many MPLS deployments have used multipath techniques, particularly in > very high bandwidth applications, such as provider IP/MPLS core > networks. MPLS-TP has discouraged the use of multipath techniques. > Some degradation of MPLS-TP OAM performance cannot be avoided when > operating over current high bandwidth multipath implementations. > > The tradeoffs involved in using multipath techniques with MPLS and > MPLS-TP are described. Requirements are discussed which enable full > MPLS-TP compliant LSP including full OAM capability to be carried > over MPLS LSP which are traversing multipath links. Other means of > supporting MPLS-TP coexisting with MPLS and multipath are discussed. > > The IETF Secretariat. > > ------- End of Forwarded Message > > > > From zhangfatai@huawei.com Mon Jul 5 02:45:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0703A67B6 for ; Mon, 5 Jul 2010 02:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv8KOhvASItF for ; Mon, 5 Jul 2010 02:45:02 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3871A3A6861 for ; Mon, 5 Jul 2010 02:45:02 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5200CH4WAT8X@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 05 Jul 2010 17:42:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5200L2VWAT05@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 05 Jul 2010 17:42:29 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5200B8TWAS8P@szxml06-in.huawei.com> for ccamp@ietf.org; Mon, 05 Jul 2010 17:42:29 +0800 (CST) Date: Mon, 05 Jul 2010 17:42:28 +0800 From: Fatai Zhang To: ccamp@ietf.org Message-id: <0bc901cb1c26$61dba270$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_iLGlieHIhiLwZrCbPWGNaw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [CCAMP] New drafts uploaded X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 09:45:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iLGlieHIhiLwZrCbPWGNaw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi ccampers, We just submited three new drafts, which are: draft-zhang-ccamp-gmpls-h-lsp-mln-00.txt draft-zhang-ccamp-srlg-fa-configuration-00.txt draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt Hope you can review these drafts and any comments are appreciated. Best Regards Fatai --Boundary_(ID_iLGlieHIhiLwZrCbPWGNaw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi ccampers,
 
We just submited three new drafts, which are:
 
draft-zhang-ccamp-gmpls-h-lsp-mln-00.txt
draft-zhang-ccamp-srlg-fa-configuration-00.txt
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt
 
 
Hope you can review these drafts and any comments are appreciated.
 
 

Best Regards
 
Fatai
 
 
 
 
--Boundary_(ID_iLGlieHIhiLwZrCbPWGNaw)-- From ashok.technologist@gmail.com Tue Jul 6 04:15:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC223A6834 for ; Tue, 6 Jul 2010 04:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6BH6Wyu5mnK for ; Tue, 6 Jul 2010 04:15:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F03F03A6888 for ; Tue, 6 Jul 2010 04:15:01 -0700 (PDT) Received: by gyh3 with SMTP id 3so3197273gyh.31 for ; Tue, 06 Jul 2010 04:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=BR/LTATiXYgOstvv409jaYSKLcLKA4We9UdGyYP0iTE=; b=aYTl6z4YOr2qhqolkiQ/cbHjOy3GMa5JrepUid+LEDHoHfiRQChDK6YJ7ELNbUUpIY MrYU9LO+yWlappIQLt1uRahVkL/1O86PVZdtD+eeb+Ligw+IB+s0El7zDPitdP7hTiKb w4QE8kt+2+bpyqQcmWINGChTKGmXfoMj0JtTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NjwE3TGdfqQK13KZzuyM4LyVwK+bXAvkpDoswhzc+egYFXvVk5TIfOwnglD09JtypI yKlbWWvL+7nGNICl9vxl5csN33nw+ZZyWNLxEfdEOQrBWeXjhT4m/4Bo6FEAj+qjabhR BD1iGkrRXHkBVfZDl5RO0/F3qo9+ZuDk4Sf3c= MIME-Version: 1.0 Received: by 10.213.33.195 with SMTP id i3mr3947164ebd.46.1278414900368; Tue, 06 Jul 2010 04:15:00 -0700 (PDT) Received: by 10.220.202.3 with HTTP; Tue, 6 Jul 2010 04:14:59 -0700 (PDT) Date: Tue, 6 Jul 2010 16:44:59 +0530 Message-ID: From: Ashok K To: ccamp@ietf.org Content-Type: multipart/alternative; boundary=0015174c0f4603174d048ab62a89 Subject: [CCAMP] Query on RFC-4202 (Routing Extensions in support of GMPLS) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 11:30:26 -0000 --0015174c0f4603174d048ab62a89 Content-Type: text/plain; charset=ISO-8859-1 Hi CCAMPers, I have a question regarding the intrepretation of an illustration (pertaining to SDH ISCD) in RFC-4202 (Routing Extensions in support of GMPLS). Refer to the following ISCD encoding example specified in the section 3.2 of RFC-4202 (Page-15): 3.4. STM-64 SDH Interface on a Digital Cross Connect with Two Types of SDH Multiplexing Hierarchy Supported Interface Switching Capability Descriptor 1: Interface Switching Capability = TDM [Standard SDH] Encoding = SDH Min LSP Bandwidth = VC-3 Max LSP Bandwidth[p] = STM-64, for all p Interface Switching Capability Descriptor 2: Interface Switching Capability = TDM [Arbitrary SDH] Encoding = SDH Min LSP Bandwidth = VC-4 Max LSP Bandwidth[p] = STM-64, for all p If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used. Does the above mean that the ISCDs pertaining to both VC-3 and VC-4 should be encoded if both are supported on a given interface? Here "Switching Capability" and "Encoding type" of both the ISCDs are exactly the same. The only distinguishing attribute here is the Min-LSP-Bandwidth which is encoded as a part of "Switch Capability Specific Information". I somehow got the impression that "Switch Capability" and "Encoding type" combination should be unique for an ISCD (within Link TLV). If the answer is Yes, Can we generalize this as follows? TE-LSA Link-TLV can contain multilple ISCD Sub-TLVs with same "Switching Capability" and "Encoding type" - but distinguished solely through one or more attribute(s) encoded in their "Switch Capability Specific Information". It would be of great help if the authors/someone in the mailing-list clarifies this. Thanks, Ashok --0015174c0f4603174d048ab62a89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi CCAMPers,

I have a question regarding the intrepretation of an illustration (per= taining to SDH ISCD) in RFC-4202 (Routing Extensions in support of GMPLS). =

Refer to the following ISCD encoding example specified in the sect= ion 3.2 of RFC-4202 (Page-15):

<SNIP>

3.4.=A0 STM-64 SDH Interface on a Digital Cross Connect with Two Types o= f
=A0=A0=A0=A0=A0 SDH Multiplexing Hierarchy Supported

=A0=A0=A0=A0=A0 Interface Switching Capability Descriptor 1:
=A0=A0= =A0=A0=A0=A0=A0=A0 Interface Switching Capability =3D TDM [Standard SDH]=A0=A0=A0=A0=A0=A0=A0=A0 Encoding =3D SDH
=A0=A0=A0=A0=A0=A0=A0=A0 Min = LSP Bandwidth =3D VC-3
=A0=A0=A0=A0=A0=A0=A0=A0 Max LSP Bandwidth[p] =3D= STM-64, for all p

=A0=A0=A0=A0=A0 Interface Switching Capability Descriptor 2:
=A0=A0= =A0=A0=A0=A0=A0=A0 Interface Switching Capability =3D TDM [Arbitrary SDH]=A0=A0=A0=A0=A0=A0=A0=A0 Encoding =3D SDH
=A0=A0=A0=A0=A0=A0=A0=A0 Min= LSP Bandwidth =3D VC-4
=A0=A0=A0=A0=A0=A0=A0=A0 Max LSP Bandwidth[p] = =3D STM-64, for all p

=A0=A0 If multiple links with such interfaces at both ends were to be=A0=A0 advertised as one TE link, link bundling techniques should be used.=

</SNIP>


Does the above mean that the ISCDs pertaining to both VC-3 and VC-4 = should be encoded if both are supported on a given interface?

Here "Switching Capability" and "Encoding type" of b= oth the ISCDs are exactly the same. The only distinguishing attribute here = is the Min-LSP-Bandwidth which is encoded as a part of "Switch Capabil= ity Specific Information". I somehow got the impression that "Swi= tch Capability" and "Encoding type" combination should be un= ique for an ISCD (within Link TLV).

If the answer is Yes, Can we generalize this as follows?

TE-LSA=A0 Link-TLV can=A0contain multilple ISCD Sub-TLVs with same &qu= ot;Switching Capability" and "Encoding type" - but distingui= shed solely through one or more attribute(s) encoded in their "Switch = Capability Specific Information".

It would be of great help if the authors/someone=A0in the mailing-= list clarifies this.

Thanks,
Ashok
--0015174c0f4603174d048ab62a89-- From SBardalai@infinera.com Tue Jul 6 12:59:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DED3A68E7 for ; Tue, 6 Jul 2010 12:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZXd+LtSX6QO for ; Tue, 6 Jul 2010 12:59:50 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 9001C3A6807 for ; Tue, 6 Jul 2010 12:59:50 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Tue, 6 Jul 2010 12:59:28 -0700 From: Snigdho Bardalai To: "ccamp@ietf.org" Date: Tue, 6 Jul 2010 12:59:51 -0700 Thread-Topic: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsdRcu5LuShJsU+TaeoEeTMTAJjig== Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8SVEXDB1infine_" MIME-Version: 1.0 Subject: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 19:59:53 -0000 --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8SVEXDB1infine_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a comment and a question on Section 3.1.2.1. This section describes = the link-parameters that are required for OTN service routing purposes. My comment is how are we going to advertise the low-order ODUj availability= within a higher-order container. For example, consider an OTU3 link which = has 16 time-slots of 2.5G granularity and then we establish an ODU2 service= over the link. At this point in time the OTU3 link has 12 time-slots avail= able for ODU2 services and up to 12+4 time-slots available for ODU1 service= s (4 ODU1s are contained over the ODU2). So it is obvious from this example= that the number of time-slots available is different based on the signal-t= ype (i.e. ODU1 and ODU2). How do we address this issue based on the approac= h specified in the draft? My other question is why not simply advertize the available number of ODU0,= ODU1, ODU2, ..., ODU4 container instances or the equivalent bandwidth in b= ytes/sec within a link? This approach seems to be more in-line with the gen= eral approach outlined in RFC-4202. Refer to section 3.4 in RFC 4202 for an= example that shows multiple ISCDs being advertised per VC rate for an SDH = link. The additional benefit is that the advertisement is TS size independe= nt and hence will simplify the implementation. Regards Snigdho --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8SVEXDB1infine_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have a comment and a question on Section 3.1.2.1. Th= is section describes the link-parameters that are required for OTN service rou= ting purposes.

 

My comment is how are we going to advertise the low-or= der ODUj availability within a higher-order container. For example, consider an= OTU3 link which has 16 time-slots of 2.5G granularity and then we establish an O= DU2 service over the link. At this point in time the OTU3 link has 12 time-slot= s available for ODU2 services and up to 12+4 time-slots available for ODU1 se= rvices (4 ODU1s are contained over the ODU2). So it is obvious from this example t= hat the number of time-slots available is different based on the signal-type (i.e. = ODU1 and ODU2). How do we address this issue based on the approach specified in = the draft?

 

My other question is why not simply advertize the avai= lable number of ODU0, ODU1, ODU2, …, ODU4 container instances or the equivalent ba= ndwidth in bytes/sec within a link? This approach seems to be more in-line with the general approach outlined in RFC-4202. Refer to section 3.4 in RFC 4202 for= an example that shows multiple ISCDs being advertised per VC rate for an SDH l= ink. The additional benefit is that the advertisement is TS size independent and hence will simplify the implementation.

 

Regards

Snigdho

 

 

--_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8SVEXDB1infine_-- From zhangfatai@huawei.com Wed Jul 7 03:29:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3983A67CC for ; Wed, 7 Jul 2010 03:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.086 X-Spam-Level: * X-Spam-Status: No, score=1.086 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr7gUDd+Egwe for ; Wed, 7 Jul 2010 03:29:28 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7C4613A6784 for ; Wed, 7 Jul 2010 03:29:28 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L56007BNNSXO4@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 07 Jul 2010 18:29:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L56004EWNSWJC@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 07 Jul 2010 18:29:20 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5600C0CNSVGI@szxml06-in.huawei.com> for ccamp@ietf.org; Wed, 07 Jul 2010 18:29:20 +0800 (CST) Date: Wed, 07 Jul 2010 18:29:19 +0800 From: Fatai Zhang To: ccamp@ietf.org Message-id: <06a701cb1dbf$42533720$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_wCt5E+gOM6vXiIauiExYbQ)" X-Priority: 3 X-MSMail-priority: Normal Cc: sergio.belotti@alcatel-lucent.it Subject: [CCAMP] comments requested on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 10:29:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wCt5E+gOM6vXiIauiExYbQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi CCAMPers, The requirements of multi-stage muxing for OTN networks (i.e., Data Plane) were discussed in the last SG15 plenary meeting. The editors of this draft are planing to update [OTN-FWK] to reflect something about multi-stage muxing. If you are interested in this topic, hope you can send the comments or suggestions to the editors or mailing list. Best Regards Fatai --Boundary_(ID_wCt5E+gOM6vXiIauiExYbQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi CCAMPers,
 
The requirements of multi-stage muxing for OTN networks (i.e., Data Plane) were discussed in the last SG15 plenary meeting.
 
The editors of this draft are planing to update [OTN-FWK] to reflect something about multi-stage muxing.
 
If you are interested in this topic, hope you can send the comments or suggestions to the editors or mailing list.
 
 
Best Regards
 
Fatai
 
--Boundary_(ID_wCt5E+gOM6vXiIauiExYbQ)-- From db3546@att.com Wed Jul 7 07:57:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678603A67D3; Wed, 7 Jul 2010 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUwwwPSj0laM; Wed, 7 Jul 2010 07:57:06 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 876CC3A67C3; Wed, 7 Jul 2010 07:57:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-5.tower-129.messagelabs.com!1278514627!33491293!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 1761 invoked from network); 7 Jul 2010 14:57:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2010 14:57:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o67EugbU004225; Wed, 7 Jul 2010 10:56:43 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o67EueTR004216; Wed, 7 Jul 2010 10:56:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 10:57:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt Thread-Index: Acsd5KjavXnp1fQlSf+BwrHsqstq4w== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" , Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 14:57:07 -0000 This begins a joint ccamp and pwe3 last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt: http://www.ietf.org/id/draft-ietf-ccamp-mpls-tp-cp-framework-02.txt The last call ends on July 21, 2010 at 24:00 UTC. Please send comments to the ccamp and pwe3 lists. Deborah and Andy and Matthew From lberger@labn.net Wed Jul 7 08:37:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8443A684D for ; Wed, 7 Jul 2010 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WidZF4Ru4HOe for ; Wed, 7 Jul 2010 08:37:04 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 228AB3A687A for ; Wed, 7 Jul 2010 08:37:04 -0700 (PDT) Received: (qmail 6386 invoked by uid 0); 7 Jul 2010 15:37:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 7 Jul 2010 15:37:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=KgF7v69h7tKCxqn2ly0DyQ+FVcg5Va4c2wHLJVS6BdRoBT4syvKXYLYaJkQXuKYTZbuv6Np+CDtHHSToa1IOT1QJ622QWXgYVVZL9lcaZTuAsRr4KgMxLhmsH7Kf03LK; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWWgN-0003Nd-2M; Wed, 07 Jul 2010 09:37:07 -0600 Message-ID: <4C349F23.5040301@labn.net> Date: Wed, 07 Jul 2010 11:37:07 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: Snigdho Bardalai References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 15:37:05 -0000 Snigdho, I believe there has been some off-line discussion on how to better align the work with 4202. Use of common approaches is of course one of the main objectives of *C*CAMP. I look forward to hearing from the draft and discussion contributors on there progress on this point. Lou On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > Hello, > > I have a comment and a question on Section 3.1.2.1. This section > describes the link-parameters that are required for OTN service routing > purposes. > > My comment is how are we going to advertise the low-order ODUj > availability within a higher-order container. For example, consider an > OTU3 link which has 16 time-slots of 2.5G granularity and then we > establish an ODU2 service over the link. At this point in time the OTU3 > link has 12 time-slots available for ODU2 services and up to 12+4 > time-slots available for ODU1 services (4 ODU1s are contained over the > ODU2). So it is obvious from this example that the number of time-slots > available is different based on the signal-type (i.e. ODU1 and ODU2). > How do we address this issue based on the approach specified in the draft? > > My other question is why not simply advertize the available number of > ODU0, ODU1, ODU2, …, ODU4 container instances or the equivalent > bandwidth in bytes/sec within a link? This approach seems to be more > in-line with the general approach outlined in RFC-4202. Refer to section > 3.4 in RFC 4202 for an example that shows multiple ISCDs being > advertised per VC rate for an SDH link. The additional benefit is that > the advertisement is TS size independent and hence will simplify the > implementation. > > Regards > > Snigdho > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Wed Jul 7 08:43:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93B33A6783 for ; Wed, 7 Jul 2010 08:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j7k5NPt-nzz for ; Wed, 7 Jul 2010 08:43:41 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id DC1EE3A672E for ; Wed, 7 Jul 2010 08:43:41 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Wed, 7 Jul 2010 08:43:45 -0700 From: Snigdho Bardalai To: Lou Berger Date: Wed, 7 Jul 2010 08:43:46 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsd6kLMp6BzRlDhTK60Dc5LnIIOigAAL+gQ Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> In-Reply-To: <4C349F23.5040301@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 15:43:43 -0000 Hi Lou Thanks, I also would like to hear about the same. Snigdho -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, July 07, 2010 8:37 AM To: Snigdho Bardalai Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snigdho, I believe there has been some off-line discussion on how to better=20 align the work with 4202. Use of common approaches is of course one of=20 the main objectives of *C*CAMP. I look forward to hearing from the=20 draft and discussion contributors on there progress on this point. Lou On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > Hello, > > I have a comment and a question on Section 3.1.2.1. This section > describes the link-parameters that are required for OTN service routing > purposes. > > My comment is how are we going to advertise the low-order ODUj > availability within a higher-order container. For example, consider an > OTU3 link which has 16 time-slots of 2.5G granularity and then we > establish an ODU2 service over the link. At this point in time the OTU3 > link has 12 time-slots available for ODU2 services and up to 12+4 > time-slots available for ODU1 services (4 ODU1s are contained over the > ODU2). So it is obvious from this example that the number of time-slots > available is different based on the signal-type (i.e. ODU1 and ODU2). > How do we address this issue based on the approach specified in the draft= ? > > My other question is why not simply advertize the available number of > ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > bandwidth in bytes/sec within a link? This approach seems to be more > in-line with the general approach outlined in RFC-4202. Refer to section > 3.4 in RFC 4202 for an example that shows multiple ISCDs being > advertised per VC rate for an SDH link. The additional benefit is that > the advertisement is TS size independent and hence will simplify the > implementation. > > Regards > > Snigdho > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Wed Jul 7 18:32:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB813A69E7 for ; Wed, 7 Jul 2010 18:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t60NFUtJH75w for ; Wed, 7 Jul 2010 18:32:47 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BE39B3A69EE for ; Wed, 7 Jul 2010 18:32:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L57000RUTMBEM@szxga04-in.huawei.com> for ccamp@ietf.org; Thu, 08 Jul 2010 09:32:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5700JH4TMB45@szxga04-in.huawei.com> for ccamp@ietf.org; Thu, 08 Jul 2010 09:32:35 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5700EBJTMB9T@szxml06-in.huawei.com> for ccamp@ietf.org; Thu, 08 Jul 2010 09:32:35 +0800 (CST) Date: Thu, 08 Jul 2010 09:32:35 +0800 From: Fatai Zhang To: Snigdho Bardalai , Lou Berger Message-id: <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_Yp/wrGhVpZmTGv0EDTfpiQ)" X-Priority: 3 X-MSMail-priority: Normal References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 01:32:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Yp/wrGhVpZmTGv0EDTfpiQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other interested experts, and we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plane, no matter how you encode the routing information. For TDM networks, you know the resource is allocated based on TS, so the available TS should be get or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think you need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find that one of your suggestions is adopted (i.e., simply advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" To: "Lou Berger" Cc: ; Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draft? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --Boundary_(ID_Yp/wrGhVpZmTGv0EDTfpiQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Snigdho and Lou,
 
Yes, we have lots of off-line discussions among authors and other interested experts, and we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.
 
The framework draft just tells you what information needed for control plane, no matter how you encode the routing information. For TDM networks, you know the resource is allocated based on TS, so the available TS should be get or induced before creating cross-connect.
 
If you are trying to find how to encode the routing information, I think you need go to the routing drafts (info model and encoding).
 
If you look at the routing drafts (info model and encoding), you will find that one of your suggestions is adopted (i.e., simply advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container instances).
 
One more thing for your first comment:
If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing TE link (like RFC4206bis).
 
 

Best Regards
 
Fatai
 
----- Original Message -----
From: "Snigdho Bardalai" <SBardalai@infinera.com>
To: "Lou Berger" <lberger@labn.net>
Sent: Wednesday, July 07, 2010 11:43 PM
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

> Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> Snigdho,
> I believe there has been some off-line discussion on how to better
> align the work with 4202.  Use of common approaches is of course one of
> the main objectives of *C*CAMP.  I look forward to hearing from the
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section
>> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, consider an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we
>> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4
>> time-slots available for ODU1 services (4 ODU1s are contained over the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU2).
>> How do we address this issue based on the approach specified in the draft?
>>
>> My other question is why not simply advertize the available number of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent
>> bandwidth in bytes/sec within a link? This approach seems to be more
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is that
>> the advertisement is TS size independent and hence will simplify the
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> --Boundary_(ID_Yp/wrGhVpZmTGv0EDTfpiQ)-- From daniele.ceccarelli@ericsson.com Thu Jul 8 05:27:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BA83A6AAD for ; Thu, 8 Jul 2010 05:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAWkLXPu0Ni4 for ; Thu, 8 Jul 2010 05:27:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 931443A6AA6 for ; Thu, 8 Jul 2010 05:27:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-15-4c35c4257743 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.73.10125.524C53C4; Thu, 8 Jul 2010 14:27:17 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jul 2010 14:27:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1E98.E69F5F4E" Date: Thu, 8 Jul 2010 14:27:16 +0200 Message-ID: In-Reply-To: <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePYF5AVvd9I5vS56yr/GKrgVZkQAWxKiA References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com><4C349F23.5040301@labn.net><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> From: "Daniele Ceccarelli" To: "Fatai Zhang" , "Snigdho Bardalai" , "Lou Berger" X-OriginalArrivalTime: 08 Jul 2010 12:27:17.0197 (UTC) FILETIME=[E7244FD0:01CB1E98] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:27:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1E98.E69F5F4E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to add that the the new version of the info model draft is already = available =20 http://tools.ietf.org/id/draft-bccg-ccamp-otn-g709-info-model-01.txt =20 while the -02 version of the encoding draft will be available in a = couple of days. =20 Best regards =20 Daniele ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Fatai Zhang Sent: gioved=EC 8 luglio 2010 3.33 To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Hi Snigdho and Lou, =20 Yes, we have lots of off-line discussions among authors and other = interested experts, and we think the proposal described in = "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more = feasible for OTN networks. =20 The framework draft just tells you what information needed for control = plane, no matter how you encode the routing information. For TDM = networks, you know the resource is allocated based on TS, so the = available TS should be get or induced before creating cross-connect. =20 If you are trying to find how to encode the routing information, I think = you need go to the routing drafts (info model and encoding). =20 If you look at the routing drafts (info model and encoding), you will = find that one of your suggestions is adopted (i.e., simply advertize the = available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). =20 One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for = ODU1, you have to advertise a new TE link or put this FA as a component = link of an existing TE link (like RFC4206bis). =20 =20 Best Regards =20 Fatai =20 ----- Original Message -----=20 From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; = > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt > Hi Lou >=20 > Thanks, I also would like to hear about the same. >=20 > Snigdho >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org ; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org = =20 > Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Snigdho, > I believe there has been some off-line discussion on how to better=20 > align the work with 4202. Use of common approaches is of course one = of=20 > the main objectives of *C*CAMP. I look forward to hearing from the=20 > draft and discussion contributors on there progress on this point. >=20 > Lou >=20 > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service = routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider = an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the = OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over = the >> ODU2). So it is obvious from this example that the number of = time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the = draft? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to = section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is = that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/ccamp = =20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org =20 > https://www.ietf.org/mailman/listinfo/ccamp = =20 >=20 ------_=_NextPart_001_01CB1E98.E69F5F4E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Just=20 to add that the the new version of the info model draft is already=20 available
 
http://tools.ietf.org/id/draft-bccg-ccamp-otn-g709-info-model-01.txt=
 
while=20 the -02 version of the encoding draft will be available in a couple of=20 days.
 
Best=20 regards
 
Daniele

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai = Zhang
Sent:=20 gioved=EC 8 luglio 2010 3.33
To: Snigdho Bardalai; Lou=20 Berger
Cc: ccamp@ietf.org;=20 draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org
Subject: = Re:=20 [CCAMP] Comment on=20 draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Snigdho and Lou,
 
Yes, we have lots of off-line discussions among = authors=20 and other interested experts, and we think the proposal described in=20 "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more = feasible=20 for OTN networks.
 
The framework draft just tells you what = information needed=20 for control plane, no matter how you encode the routing information. For = TDM=20 networks, you know the resource is allocated based on TS, so the = available TS=20 should be get or induced before creating = cross-connect.
 
If you are trying to find how to encode the = routing=20 information, I think you need go to the routing drafts (info model and=20 encoding).
 
If you look at the routing drafts (info model = and=20 encoding), you will find that one of your suggestions is adopted (i.e., = simply=20 advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container=20 instances).
 
One more thing for your first = comment:
If you create an ODU2 LSP (usually over multi = OTU3 links)=20 as FA for ODU1, you have to advertise a new TE link or put this FA as a=20 component link of an existing TE link (like RFC4206bis).
 
 

Best=20 Regards
 
Fatai
 
----- Original Message -----
From: "Snigdho Bardalai" <SBardalai@infinera.com>
To: "Lou Berger" <lberger@labn.net>
Cc: <ccamp@ietf.org>; = <draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org<= /A>>
Sent: Wednesday, July 07, 2010 11:43 = PM
Subject: Re: [CCAMP] Comment on=20 draft-ietf-ccamp-gmpls-g709-framework-01.txt

> Hi = Lou
>=20
> Thanks, I also would like to hear about the same.
> =
>=20 Snigdho
>
> -----Original Message-----
> From: Lou = Berger=20 [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37=20 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org<= /A>
> Subject: Re: [CCAMP] Comment on=20 draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> = Snigdho,
> I=20 believe there has been some off-line discussion on how to better =
> align=20 the work with 4202.  Use of common approaches is of course one of =
>=20 the main objectives of *C*CAMP.  I look forward to hearing from the =
> draft and discussion contributors on there progress on this=20 point.
>
> Lou
>
> On 7/6/2010 3:59 PM, = Snigdho=20 Bardalai wrote:
>> Hello,
>>
>> I have a = comment and=20 a question on Section 3.1.2.1. This section
>> describes the=20 link-parameters that are required for OTN service routing
>>=20 purposes.
>>
>> My comment is how are we going to = advertise=20 the low-order ODUj
>> availability within a higher-order = container. For=20 example, consider an
>> OTU3 link which has 16 time-slots of = 2.5G=20 granularity and then we
>> establish an ODU2 service over the = link. At=20 this point in time the OTU3
>> link has 12 time-slots available = for=20 ODU2 services and up to 12+4
>> time-slots available for ODU1 = services=20 (4 ODU1s are contained over the
>> ODU2). So it is obvious from = this=20 example that the number of time-slots
>> available is different = based=20 on the signal-type (i.e. ODU1 and ODU2).
>> How do we address = this=20 issue based on the approach specified in the = draft?
>>
>> My=20 other question is why not simply advertize the available number = of
>>=20 ODU0, ODU1, ODU2, ..., ODU4 container instances or the = equivalent
>>=20 bandwidth in bytes/sec within a link? This approach seems to be = more
>>=20 in-line with the general approach outlined in RFC-4202. Refer to=20 section
>> 3.4 in RFC 4202 for an example that shows multiple = ISCDs=20 being
>> advertised per VC rate for an SDH link. The additional = benefit=20 is that
>> the advertisement is TS size independent and hence = will=20 simplify the
>> implementation.
>>
>>=20 Regards
>>
>>=20 Snigdho
>>
>>
>>
>>=20 _______________________________________________
>> CCAMP = mailing=20 list
>> CCAMP@ietf.org
>> = https://www.ietf.org/mailman/listinfo/ccamp
> = _______________________________________________
> CCAMP=20 mailing list
> CCAMP@ietf.org
> = https://www.ietf.org/mailman/listinfo/ccamp
> ------_=_NextPart_001_01CB1E98.E69F5F4E-- From SBardalai@infinera.com Thu Jul 8 08:10:43 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376A63A6A02 for ; Thu, 8 Jul 2010 08:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o99A48dpo8YF for ; Thu, 8 Jul 2010 08:10:41 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id DDD153A6B0A for ; Thu, 8 Jul 2010 08:10:40 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Thu, 8 Jul 2010 08:10:44 -0700 From: Snigdho Bardalai To: Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 08:10:17 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzA Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> In-Reply-To: <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947SVEXDB1infine_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 15:10:43 -0000 --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947SVEXDB1infine_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai I think we need to sort out the issues with the framework document before w= e can embark on any proposals to the problem. I am still not clear why do w= e have to deviate from the general approach that has been established in RF= C 4202. Additionally, I do not see any reason to advertise a new TE-link to represe= nt the low-order ODUj bandwidth within the high-order containers. This is s= imply blowing up the solution to a very simple problem. Regards Snigdho From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 07, 2010 6:33 PM To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other intereste= d experts, and we think the proposal described in "draft-ceccarelli-ccamp-g= mpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plan= e, no matter how you encode the routing information. For TDM networks, you = know the resource is allocated based on TS, so the available TS should be g= et or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think yo= u need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find = that one of your suggestions is adopted (i.e., simply advertize the availab= le number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, y= ou have to advertise a new TE link or put this FA as a component link of an= existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fr= amework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draf= t? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947SVEXDB1infine_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fatai

 

I think we need to sort out the issues with the framework do= cument before we can embark on any proposals to the problem. I am still not clear = why do we have to deviate from the general approach that has been established in R= FC 4202.

 

Additionally, I do not see any reason to advertise a new TE-= link to represent the low-order ODUj bandwidth within the high-order containers.= This is simply blowing up the solution to a very simple problem.

 

Regards

Snigdho

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, July 07, 2010 6:33 PM
To: Snigdho Bardalai; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Sn= igdho and Lou,

 

Yes, = we have lots of off-line discussions among authors and other interested experts, an= d we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.

 

The f= ramework draft just tells you what information needed for control plane, no matter h= ow you encode the routing information. For TDM networks, you know the resource= is allocated based on TS, so the available TS should be get or induced before creating cross-connect.

 

If yo= u are trying to find how to encode the routing information, I think you need go t= o the routing drafts (info model and encoding).

 

If yo= u look at the routing drafts (info model and encoding), you will find that one of = your suggestions is adopted (i.e., simply advertize the available number of ODU0= , ODU1, ODU2, ..., ODU4 container instances).

 

One m= ore thing for your first comment:

If yo= u create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing T= E link (like RFC4206bis).

 

 


Best Regards
 
Fatai
 

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

From: "Snigdho Bardalai" <SBardalai@infinera.com>

Sent:= Wednesday, July 07, 2010 11:43 PM

Subje= ct: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt=

 

> = Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fram= ework@tools.ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> Snigdho,
> I believe there has been some off-line discussion on how to better > align the work with 4202.  Use of common approaches is of course = one of
> the main objectives of *C*CAMP.  I look forward to hearing from t= he
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, conside= r an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we<= br> >> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4<= br> >> time-slots available for ODU1 services (4 ODU1s are contained over= the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU= 2).
>> How do we address this issue based on the approach specified in th= e draft?
>>
>> My other question is why not simply advertize the available number= of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent<= br> >> bandwidth in bytes/sec within a link? This approach seems to be mo= re
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is = that
>> the advertisement is TS size independent and hence will simplify t= he
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

--_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947SVEXDB1infine_-- From sergio.belotti@alcatel-lucent.com Thu Jul 8 09:03:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3AB3A6B37 for ; Thu, 8 Jul 2010 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSn28ZkAuVL4 for ; Thu, 8 Jul 2010 09:03:04 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 3AD493A6B30 for ; Thu, 8 Jul 2010 09:03:04 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o68G2eng027970 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Jul 2010 18:02:40 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 8 Jul 2010 18:02:40 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Snigdho Bardalai Date: Thu, 8 Jul 2010 18:02:38 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAAH2hIA= Message-ID: References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F050945A8D8E9A44A71039532BA344D80B61DF24FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:03:15 -0000 --_000_F050945A8D8E9A44A71039532BA344D80B61DF24FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Snigdho, Framework draft is dealing with information needed form control plane presp= ective iin the OTN context , and list also requirements to be considered.(b= oth form sugnaling and routing point of view) Then we a draft with the aim to explain , starting from requirements descri= bed in the framework, how the present tools can accomplish or not these req= uirements. And finally we have an encoding draft proposing a solution format. It seems to me you're making question about encoding starting from requirem= ents . As suggested by Fatai we probably discuss about the various points t= aking into consideration all the bunch of OTN CP work. Best Regards sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 ________________________________ Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Sni= gdho Bardalai Inviato: gioved=EC 8 luglio 2010 17.10 A: Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Fatai I think we need to sort out the issues with the framework document before w= e can embark on any proposals to the problem. I am still not clear why do w= e have to deviate from the general approach that has been established in RF= C 4202. Additionally, I do not see any reason to advertise a new TE-link to represe= nt the low-order ODUj bandwidth within the high-order containers. This is s= imply blowing up the solution to a very simple problem. Regards Snigdho From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 07, 2010 6:33 PM To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other intereste= d experts, and we think the proposal described in "draft-ceccarelli-ccamp-g= mpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plan= e, no matter how you encode the routing information. For TDM networks, you = know the resource is allocated based on TS, so the available TS should be g= et or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think yo= u need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find = that one of your suggestions is adopted (i.e., simply advertize the availab= le number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, y= ou have to advertise a new TE link or put this FA as a component link of an= existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fr= amework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draf= t? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --_000_F050945A8D8E9A44A71039532BA344D80B61DF24FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Snigdho,

 

Framework draft is dealing with information needed form control plane prespective iin the OTN context , and list also requirements to be considered.(both form sugnaling = and routing point of view)

Then we a draft wit= h the aim to explain , starting from requirements described in the framework, how= the present tools can accomplish or not these requirements.

And finally we have= an encoding draft proposing a solution format.

 

It seems to me you&= #8217;re making question about encoding starting from requirements . As suggested by Fatai we probably discuss about the various points taking into consideratio= n all the bunch of OTN CP work.

 

Best Regards

 

sergio

 

Sergio Belotti

System Architecture=
Optics Division-Terrestrial Optics Unit=
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Snigdho Bardalai
Inviato: gioved=EC 8 luglio = 2010 17.10
A: Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org
Oggetto: Re: [CCAMP] Comment= on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Fatai<= /o:p>

 

I think we nee= d to sort out the issues with the framework document before we can embark on any proposals to the problem. I am still not clear why do we have to deviate fr= om the general approach that has been established in RFC 4202.

 

Additionally, = I do not see any reason to advertise a new TE-link to represent the low-order OD= Uj bandwidth within the high-order containers. This is simply blowing up the s= olution to a very simple problem.

 

Regards

Snigdho

 

From:= Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, July 07, 20= 10 6:33 PM
To: Snigdho Bardalai; Lou Be= rger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org
Subject: Re: [CCAMP] Comment= on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Snigdho and Lou,

 

Yes, we have lots of off-line discussions among authors and other interested experts, and we think the proposal described i= n "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.=

 

The framework draft just tells you what informati= on needed for control plane, no matter how you encode the routing information.= For TDM networks, you know the resource is allocated based on TS, so the availa= ble TS should be get or induced before creating cross-connect.

 

If you are trying to find how to encode the routi= ng information, I think you need go to the routing drafts (info model and encoding).

 

If you look at the routing drafts (info model and encoding), you will find that one of your suggestions is adopted (i.e., sim= ply advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container instances).

 

One more thing for your first comment:

If you create an ODU2 LSP (usually over multi OTU= 3 links) as FA for ODU1, you have to advertise a new TE link or put this FA a= s a component link of an existing TE link (like RFC4206bis).

 

 


Best Regards
 
Fatai
 

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

To: "Lou Berger" <lberger@labn.net>

Sent: Wednesday, July 07, 2010 11:43 PM

Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

> Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org= ; draft-ietf-ccamp-gmpls-g709-= framework@tools.ietf.org
&g= t; Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t
>
> Snigdho,
> I believe there has been some off-line discussion on how to better > align the work with 4202.  Use of common approaches is of course = one of
> the main objectives of *C*CAMP.  I look forward to hearing from t= he
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, conside= r an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we<= br> >> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4<= br> >> time-slots available for ODU1 services (4 ODU1s are contained over= the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU= 2).
>> How do we address this issue based on the approach specified in th= e draft?
>>
>> My other question is why not simply advertize the available number= of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent<= br> >> bandwidth in bytes/sec within a link? This approach seems to be mo= re
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is = that
>> the advertisement is TS size independent and hence will simplify t= he
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org=
&g= t;> https://www.ietf.org/mailman= /listinfo/ccamp
&g= t; _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org=
&g= t; https://www.ietf.org/mailman= /listinfo/ccamp
&g= t;

--_000_F050945A8D8E9A44A71039532BA344D80B61DF24FRMRSSXCHMBSB1d_-- From SBardalai@infinera.com Thu Jul 8 09:12:33 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEF53A6B19 for ; Thu, 8 Jul 2010 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHcBdK+1JDgj for ; Thu, 8 Jul 2010 09:12:24 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 2EE0A3A6AED for ; Thu, 8 Jul 2010 09:12:24 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Thu, 8 Jul 2010 09:12:01 -0700 From: Snigdho Bardalai To: "BELOTTI, SERGIO (SERGIO)" Date: Thu, 8 Jul 2010 09:12:28 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAAH2hIAAAIue0A== Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC8697C@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC8697CSVEXDB1infine_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:12:33 -0000 --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC8697CSVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio Yes, I agree with the process you described and you are right I am question= ing the routing requirements that are being laid out in the framework draft= . Regards Snigdho From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Thursday, July 08, 2010 9:03 AM To: Snigdho Bardalai Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org; F= atai Zhang; Lou Berger Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Hi Snigdho, Framework draft is dealing with information needed form control plane presp= ective iin the OTN context , and list also requirements to be considered.(b= oth form sugnaling and routing point of view) Then we a draft with the aim to explain , starting from requirements descri= bed in the framework, how the present tools can accomplish or not these req= uirements. And finally we have an encoding draft proposing a solution format. It seems to me you're making question about encoding starting from requirem= ents . As suggested by Fatai we probably discuss about the various points t= aking into consideration all the bunch of OTN CP work. Best Regards sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 ________________________________ Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Sni= gdho Bardalai Inviato: gioved=EC 8 luglio 2010 17.10 A: Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Fatai I think we need to sort out the issues with the framework document before w= e can embark on any proposals to the problem. I am still not clear why do w= e have to deviate from the general approach that has been established in RF= C 4202. Additionally, I do not see any reason to advertise a new TE-link to represe= nt the low-order ODUj bandwidth within the high-order containers. This is s= imply blowing up the solution to a very simple problem. Regards Snigdho From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 07, 2010 6:33 PM To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other intereste= d experts, and we think the proposal described in "draft-ceccarelli-ccamp-g= mpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plan= e, no matter how you encode the routing information. For TDM networks, you = know the resource is allocated based on TS, so the available TS should be g= et or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think yo= u need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find = that one of your suggestions is adopted (i.e., simply advertize the availab= le number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, y= ou have to advertise a new TE link or put this FA as a component link of an= existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fr= amework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draf= t? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC8697CSVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sergio

 

Yes, I agree with the process you described and you are righ= t I am questioning the routing requirements that are being laid out in the framework draft.

 

Regards

Snigdho

 

From: BELOTTI, SERG= IO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]
Sent: Thursday, July 08, 2010 9:03 AM
To: Snigdho Bardalai
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org; Fatai Zhang; Lou Berg= er
Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Snigdho,

 

Framework draft is dealing with information needed form control plane prespective iin the OTN context , and list also requirements to be considered.(both form sugnaling and routing point of view)

Then we a draft with the aim to explain , starting from requirements described in the framework, how the present tools can accompli= sh or not these requirements.

And finally we have an encoding draft proposing a solution form= at.

 

It seems to me you’re making question about encoding star= ting from requirements . As suggested by Fatai we probably discuss about the various points taking into consideration all the bunch of OTN CP work.

 

Best Regards

 

sergio

 

Sergio Belotti

System Architecture
Optics Division-Terrestrial Optics Unit
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

Da: cca= mp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Snigdho Bardalai
Inviato: gioved=EC 8 luglio 2010 17.10
A: Fatai Zhang; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewor= k-01.txt

 

Hi Fatai

 

I think we need to sort out the issues with the framework document before we can embark on any proposals to the problem. I am still n= ot clear why do we have to deviate from the general approach that has been established in RFC 4202.

 

Additionally, I do not see any reason to advertise a new TE-= link to represent the low-order ODUj bandwidth within the high-order containers. This is simply blowing up the solution to a very simple problem.=

 

Regards

Snigdho

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, July 07, 2010 6:33 PM
To: Snigdho Bardalai; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewor= k-01.txt

 

Hi Sn= igdho and Lou,

 

Yes, = we have lots of off-line discussions among authors and other interested experts, an= d we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.

 

The f= ramework draft just tells you what information needed for control plane, no matter h= ow you encode the routing information. For TDM networks, you know the resource= is allocated based on TS, so the available TS should be get or induced before creating cross-connect.

 

If yo= u are trying to find how to encode the routing information, I think you need go t= o the routing drafts (info model and encoding).

 

If yo= u look at the routing drafts (info model and encoding), you will find that one of = your suggestions is adopted (i.e., simply advertize the available number of ODU0= , ODU1, ODU2, ..., ODU4 container instances).

 

One m= ore thing for your first comment:

If yo= u create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing T= E link (like RFC4206bis).

 

 


Best Regards
 
Fatai
 

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

From: "Snigdho Bardalai" <SBardalai@infinera.com>

Sent: Wednesday, July 07, 2010 11:43 PM

Subje= ct: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt=

 

> = Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fram= ework@tools.ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> Snigdho,
> I believe there has been some off-line discussion on how to better > align the work with 4202.  Use of common approaches is of course = one of
> the main objectives of *C*CAMP.  I look forward to hearing from t= he
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, conside= r an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we<= br> >> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4<= br> >> time-slots available for ODU1 services (4 ODU1s are contained over= the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU= 2).
>> How do we address this issue based on the approach specified in th= e draft?
>>
>> My other question is why not simply advertize the available number= of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent<= br> >> bandwidth in bytes/sec within a link? This approach seems to be mo= re
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is = that
>> the advertisement is TS size independent and hence will simplify t= he
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

--_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC8697CSVEXDB1infine_-- From db3546@att.com Thu Jul 8 09:40:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEBA3A6AF3; Thu, 8 Jul 2010 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM87gLG6+e5F; Thu, 8 Jul 2010 09:40:20 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 7255F3A6B30; Thu, 8 Jul 2010 09:40:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-11.tower-167.messagelabs.com!1278607223!27370463!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 19154 invoked from network); 8 Jul 2010 16:40:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2010 16:40:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o68GduVi005594; Thu, 8 Jul 2010 12:39:56 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o68Gdqjh005558; Thu, 8 Jul 2010 12:39:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 12:40:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt Thread-Index: Acsd5KjavXnp1fQlSf+BwrHsqstq4wA1mEKg From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" , , Cc: mpls-tp@ietf.org Subject: [CCAMP] FW: Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:40:21 -0000 This WG Last Call will be extended to be a joint last call of the ccamp, pwe3, and mpls wgs and the end date extended to July 26th. Thanks, CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Wednesday, July 07, 2010 10:57 AM To: CCAMP; pwe3@ietf.org Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt This begins a joint ccamp and pwe3 last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt: http://www.ietf.org/id/draft-ietf-ccamp-mpls-tp-cp-framework-02.txt The last call ends on July 21, 2010 at 24:00 UTC. Please send comments to the ccamp and pwe3 lists. Deborah and Andy and Matthew _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 10:54:16 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029273A6863 for ; Thu, 8 Jul 2010 10:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGwSR+6WR3dV for ; Thu, 8 Jul 2010 10:54:13 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 2A5F43A6888 for ; Thu, 8 Jul 2010 10:54:12 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68Hs3jb002508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 19:54:03 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 19:54:03 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.694.0; Thu, 8 Jul 2010 19:54:02 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 13:54:00 -0400 From: Igor Bryskin To: Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 13:53:20 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7atlsrvexgenat_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:54:16 -0000 --_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7atlsrvexgenat_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Snigdho, =D8 I think we need to sort out the issues with the framework document bef= ore we can embark on any proposals to the problem. I am still not clear why= do we have to deviate from the general approach that has been established = in RFC 4202. IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and i= t is highly desirable to adhere to the layer independent paradigm of advert= ising of TE links, and there is no reason to invent an OTN specific ISCD. T= he combination of Switching Capability and Encoding type of RFC4202 ISCD al= lows for specifying both multiplexing capabilities and OTN layer (LO, HO, S= HO) of an OTN link, and, if this not sufficient, you have another reserved = 16 bits. >Additionally, I do not see any reason to advertise a new TE-link to repres= ent >the low-order ODUj bandwidth within the high-order containers. This is= simply >blowing up the solution to a very simple problem. IB>> Here I disagree. In order to give a user possibility to create OTN hie= rarchies and constrain LO connections to HO containers, one needs to advert= ise OTN links with different switchcaps. Cheers, Igor Regards Snigdho From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 07, 2010 6:33 PM To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other intereste= d experts, and we think the proposal described in "draft-ceccarelli-ccamp-g= mpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plan= e, no matter how you encode the routing information. For TDM networks, you = know the resource is allocated based on TS, so the available TS should be g= et or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think yo= u need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find = that one of your suggestions is adopted (i.e., simply advertize the availab= le number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, y= ou have to advertise a new TE link or put this FA as a component link of an= existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fr= amework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draf= t? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7atlsrvexgenat_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Snigdho,

 

 

=D8&= nbsp; I think we need to sort out the issues with the framework document before we = can embark on any proposals to the problem. I am still not clear why do we have= to deviate from the general approach that has been established in RFC 4202.

 

IB>> Agree absolutely. GMPLS is inherently multi-layer= control plane, and it is highly desirable to adhere to the layer independent paradi= gm of advertising of TE links, and there is no reason to invent an OTN specific I= SCD. The combination of Switching Capability and Encoding type of RFC4202 ISCD allows for specifying both multiplexing capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have another reserved= 16 bits.

 

>Additionally, I do not see any reason to advertise a new TE-= link to represent >the low-order ODUj bandwidth within the high-order container= s. This is simply >blowing up the solution to a very simple problem.

 

IB>> Here I disagree. In order to give a user possibil= ity to create OTN hierarchies and constrain LO connections to HO containers, on= e needs to advertise OTN links with different switchcaps.

 

Cheers,

Igor

 

Regards

Snigdho

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, July 07, 2010 6:33 PM
To: Snigdho Bardalai; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Sn= igdho and Lou,

 

Yes, = we have lots of off-line discussions among authors and other interested experts, an= d we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.

 

The f= ramework draft just tells you what information needed for control plane, no matter h= ow you encode the routing information. For TDM networks, you know the resource= is allocated based on TS, so the available TS should be get or induced before creating cross-connect.

 

If yo= u are trying to find how to encode the routing information, I think you need go t= o the routing drafts (info model and encoding).

 

If yo= u look at the routing drafts (info model and encoding), you will find that one of = your suggestions is adopted (i.e., simply advertize the available number of ODU0= , ODU1, ODU2, ..., ODU4 container instances).

 

One m= ore thing for your first comment:

If yo= u create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing T= E link (like RFC4206bis).

 

 


Best Regards
 
Fatai
 

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

Sent: Wednesday, July 07, 2010 11:43 PM

Subje= ct: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt=

 

> = Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fram= ework@tools.ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> Snigdho,
> I believe there has been some off-line discussion on how to better > align the work with 4202.  Use of common approaches is of course = one of
> the main objectives of *C*CAMP.  I look forward to hearing from t= he
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, conside= r an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we<= br> >> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4<= br> >> time-slots available for ODU1 services (4 ODU1s are contained over= the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU= 2).
>> How do we address this issue based on the approach specified in th= e draft?
>>
>> My other question is why not simply advertize the available number= of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent<= br> >> bandwidth in bytes/sec within a link? This approach seems to be mo= re
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is = that
>> the advertisement is TS size independent and hence will simplify t= he
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

--_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7atlsrvexgenat_-- From jdrake@juniper.net Thu Jul 8 11:01:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D5D3A6B39 for ; Thu, 8 Jul 2010 11:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9qHh5sO2-TE for ; Thu, 8 Jul 2010 11:01:52 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 6796A3A6857 for ; Thu, 8 Jul 2010 11:01:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTDYScQFe/X8hDdfEZ6Nak25lJkMOLvr2@postini.com; Thu, 08 Jul 2010 11:01:57 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 8 Jul 2010 10:59:25 -0700 From: John E Drake To: Igor Bryskin , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 10:59:24 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEA== Message-ID: <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:01:55 -0000 What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > From SBardalai@infinera.com Thu Jul 8 11:16:46 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9983A68DE for ; Thu, 8 Jul 2010 11:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhMtcAkYgZAD for ; Thu, 8 Jul 2010 11:16:39 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id 2BC293A6888 for ; Thu, 8 Jul 2010 11:16:39 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Thu, 8 Jul 2010 11:16:43 -0700 From: Snigdho Bardalai To: Igor Bryskin , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 11:16:43 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAA1JQUA== Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0F@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0FSVEXDB1infine_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:16:47 -0000 --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0FSVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, Please see below. Thanks, Snigdho From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 10:53 AM To: Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snigdho, =D8 I think we need to sort out the issues with the framework document bef= ore we can embark on any proposals to the problem. I am still not clear why= do we have to deviate from the general approach that has been established = in RFC 4202. IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and i= t is highly desirable to adhere to the layer independent paradigm of advert= ising of TE links, and there is no reason to invent an OTN specific ISCD. T= he combination of Switching Capability and Encoding type of RFC4202 ISCD al= lows for specifying both multiplexing capabilities and OTN layer (LO, HO, S= HO) of an OTN link, and, if this not sufficient, you have another reserved = 16 bits. [SCB] I support your suggestion here. >Additionally, I do not see any reason to advertise a new TE-link to repres= ent >the low-order ODUj bandwidth within the high-order containers. This is= simply >blowing up the solution to a very simple problem. IB>> Here I disagree. In order to give a user possibility to create OTN hie= rarchies and constrain LO connections to HO containers, one needs to advert= ise OTN links with different switchcaps. [SCB] No disagreement with advertising the OTN link with different "switchc= aps" but why do we need an FA? Cheers, Igor Regards Snigdho From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 07, 2010 6:33 PM To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other intereste= d experts, and we think the proposal described in "draft-ceccarelli-ccamp-g= mpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plan= e, no matter how you encode the routing information. For TDM networks, you = know the resource is allocated based on TS, so the available TS should be g= et or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think yo= u need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find = that one of your suggestions is adopted (i.e., simply advertize the availab= le number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, y= ou have to advertise a new TE link or put this FA as a component link of an= existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fr= amework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draf= t? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0FSVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

Please see below.

 

Thanks,

Snigdho

 

From: Igor Bryskin = [mailto:IBryskin@advaoptical.com]
Sent: Thursday, July 08, 2010 10:53 AM
To: Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewor= k-01.txt

 

Snigdho,

 

 

=D8&= nbsp; I think we need to sort out the issues with the framework document before we = can embark on any proposals to the problem. I am still not clear why do we have= to deviate from the general approach that has been established in RFC 4202.

 

IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and it is highly desirable to adhere to the layer independen= t paradigm of advertising of TE links, and there is no reason to invent an OT= N specific ISCD. The combination of Switching Capability and Encoding type of RFC4202 ISCD allows for specifying both multiplexing capabilities and OTN l= ayer (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have another reserved 16 bits.

[SCB] =A0I support your suggestion here.

 

>Additionally, I do not see any reason to advertise a new TE-link to represent >the low-order ODUj bandwidth within the high-order containers. This is simply >blowing up the solution to a very simple problem.

 

IB>> Here I disagree. In order to give a user possibil= ity to create OTN hierarchies and constrain LO connections to HO containers, on= e needs to advertise OTN links with different switchcaps.

[SCB] No disagreement with advertising the OTN link with different ”switchcaps” but why do we need an FA?

 

Cheers,

Igor

 

Regards

Snigdho

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, July 07, 2010 6:33 PM
To: Snigdho Bardalai; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Sn= igdho and Lou,

 

Yes, = we have lots of off-line discussions among authors and other interested experts, an= d we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.

 

The f= ramework draft just tells you what information needed for control plane, no matter h= ow you encode the routing information. For TDM networks, you know the resource= is allocated based on TS, so the available TS should be get or induced before creating cross-connect.

 

If yo= u are trying to find how to encode the routing information, I think you need go t= o the routing drafts (info model and encoding).

 

If yo= u look at the routing drafts (info model and encoding), you will find that one of = your suggestions is adopted (i.e., simply advertize the available number of ODU0= , ODU1, ODU2, ..., ODU4 container instances).

 

One m= ore thing for your first comment:

If yo= u create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing T= E link (like RFC4206bis).

 

 


Best Regards
 
Fatai
 

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

Sent: Wednesday, July 07, 2010 11:43 PM

Subje= ct: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt=

 

> = Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fram= ework@tools.ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> Snigdho,
> I believe there has been some off-line discussion on how to better > align the work with 4202.  Use of common approaches is of course = one of
> the main objectives of *C*CAMP.  I look forward to hearing from t= he
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, conside= r an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we<= br> >> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4<= br> >> time-slots available for ODU1 services (4 ODU1s are contained over= the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU= 2).
>> How do we address this issue based on the approach specified in th= e draft?
>>
>> My other question is why not simply advertize the available number= of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent<= br> >> bandwidth in bytes/sec within a link? This approach seems to be mo= re
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is = that
>> the advertisement is TS size independent and hence will simplify t= he
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

--_000_0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0FSVEXDB1infine_-- From IBryskin@advaoptical.com Thu Jul 8 11:31:22 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960673A6B14 for ; Thu, 8 Jul 2010 11:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYYtIS03SOuj for ; Thu, 8 Jul 2010 11:31:21 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id A76633A6B58 for ; Thu, 8 Jul 2010 11:31:13 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68IV6ZM022438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 20:31:06 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 20:31:06 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 14:31:04 -0400 From: Igor Bryskin To: John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:31:02 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0w Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:31:22 -0000 I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > From IBryskin@advaoptical.com Thu Jul 8 11:34:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759D73A6B2C for ; Thu, 8 Jul 2010 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2-J3JrY7iiA for ; Thu, 8 Jul 2010 11:34:46 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 929F73A6B44 for ; Thu, 8 Jul 2010 11:34:44 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68IYhPT025828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 20:34:43 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 20:34:43 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 14:34:40 -0400 From: Igor Bryskin To: Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:34:37 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAA1JQUAAA1Srw Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E202@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0F@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A0F@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E202atlsrvexgenat_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:34:54 -0000 --_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E202atlsrvexgenat_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [SCB] No disagreement with advertising the OTN link with different "switch= caps" but why do we need an FA? We need FA because it is possible in GMPLS (and quite beneficial) to share = the same routing instance between OTN layers From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: Thursday, July 08, 2010 2:17 PM To: Igor Bryskin; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, Please see below. Thanks, Snigdho From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 10:53 AM To: Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snigdho, =D8 I think we need to sort out the issues with the framework document bef= ore we can embark on any proposals to the problem. I am still not clear why= do we have to deviate from the general approach that has been established = in RFC 4202. IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and i= t is highly desirable to adhere to the layer independent paradigm of advert= ising of TE links, and there is no reason to invent an OTN specific ISCD. T= he combination of Switching Capability and Encoding type of RFC4202 ISCD al= lows for specifying both multiplexing capabilities and OTN layer (LO, HO, S= HO) of an OTN link, and, if this not sufficient, you have another reserved = 16 bits. [SCB] I support your suggestion here. >Additionally, I do not see any reason to advertise a new TE-link to repres= ent >the low-order ODUj bandwidth within the high-order containers. This is= simply >blowing up the solution to a very simple problem. IB>> Here I disagree. In order to give a user possibility to create OTN hie= rarchies and constrain LO connections to HO containers, one needs to advert= ise OTN links with different switchcaps. [SCB] No disagreement with advertising the OTN link with different "switchc= aps" but why do we need an FA? Cheers, Igor Regards Snigdho From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 07, 2010 6:33 PM To: Snigdho Bardalai; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Snigdho and Lou, Yes, we have lots of off-line discussions among authors and other intereste= d experts, and we think the proposal described in "draft-ceccarelli-ccamp-g= mpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks. The framework draft just tells you what information needed for control plan= e, no matter how you encode the routing information. For TDM networks, you = know the resource is allocated based on TS, so the available TS should be g= et or induced before creating cross-connect. If you are trying to find how to encode the routing information, I think yo= u need go to the routing drafts (info model and encoding). If you look at the routing drafts (info model and encoding), you will find = that one of your suggestions is adopted (i.e., simply advertize the availab= le number of ODU0, ODU1, ODU2, ..., ODU4 container instances). One more thing for your first comment: If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, y= ou have to advertise a new TE link or put this FA as a component link of an= existing TE link (like RFC4206bis). Best Regards Fatai ----- Original Message ----- From: "Snigdho Bardalai" > To: "Lou Berger" > Cc: >; > Sent: Wednesday, July 07, 2010 11:43 PM Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > Hi Lou > > Thanks, I also would like to hear about the same. > > Snigdho > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, July 07, 2010 8:37 AM > To: Snigdho Bardalai > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fr= amework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Snigdho, > I believe there has been some off-line discussion on how to better > align the work with 4202. Use of common approaches is of course one of > the main objectives of *C*CAMP. I look forward to hearing from the > draft and discussion contributors on there progress on this point. > > Lou > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> Hello, >> >> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing >> purposes. >> >> My comment is how are we going to advertise the low-order ODUj >> availability within a higher-order container. For example, consider an >> OTU3 link which has 16 time-slots of 2.5G granularity and then we >> establish an ODU2 service over the link. At this point in time the OTU3 >> link has 12 time-slots available for ODU2 services and up to 12+4 >> time-slots available for ODU1 services (4 ODU1s are contained over the >> ODU2). So it is obvious from this example that the number of time-slots >> available is different based on the signal-type (i.e. ODU1 and ODU2). >> How do we address this issue based on the approach specified in the draf= t? >> >> My other question is why not simply advertize the available number of >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent >> bandwidth in bytes/sec within a link? This approach seems to be more >> in-line with the general approach outlined in RFC-4202. Refer to section >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being >> advertised per VC rate for an SDH link. The additional benefit is that >> the advertisement is TS size independent and hence will simplify the >> implementation. >> >> Regards >> >> Snigdho >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E202atlsrvexgenat_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=A0[SCB] No disagreement with advertising the OTN link with different ”switchcaps” but why do we need an FA?

 

We need FA because it is possible in GMPLS (and quite beneficial) to share the same routing instance between OTN layers

 

From: Snigdho Barda= lai [mailto:SBardalai@infinera.com]
Sent: Thursday, July 08, 2010 2:17 PM
To: Igor Bryskin; Fatai Zhang; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewor= k-01.txt

 

Igor,

 

Please see below.

 

Thanks,

Snigdho

 

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, July 08, 2010 10:53 AM
To: Snigdho Bardalai; Fatai Zhang; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Snigdho,

 

 

=D8&= nbsp; I think we need to sort out the issues with the framework document before we = can embark on any proposals to the problem. I am still not clear why do we have= to deviate from the general approach that has been established in RFC 4202.

 

IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and it is highly desirable to adhere to the layer independen= t paradigm of advertising of TE links, and there is no reason to invent an OT= N specific ISCD. The combination of Switching Capability and Encoding type of RFC4202 ISCD allows for specifying both multiplexing capabilities and OTN l= ayer (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have another reserved 16 bits.

[SCB]  I support your suggestion here.

 

>Additionally, I do not see any reason to advertise a new TE-link to represent >the low-order ODUj bandwidth within the high-order containers. This is simply >blowing up the solution to a very simple problem.

 

IB>> Here I disagree. In order to give a user possibil= ity to create OTN hierarchies and constrain LO connections to HO containers, on= e needs to advertise OTN links with different switchcaps.

[SCB] No disagreement with advertising the OTN link with different ”switchcaps” but why do we need an FA?

 

Cheers,

Igor

 

Regards

Snigdho

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Wednesday, July 07, 2010 6:33 PM
To: Snigdho Bardalai; Lou Berger
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf= .org
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

 

Hi Sn= igdho and Lou,

 

Yes, = we have lots of off-line discussions among authors and other interested experts, an= d we think the proposal described in "draft-ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible for OTN networks.

 

The f= ramework draft just tells you what information needed for control plane, no matter h= ow you encode the routing information. For TDM networks, you know the resource= is allocated based on TS, so the available TS should be get or induced before creating cross-connect.

 

If yo= u are trying to find how to encode the routing information, I think you need go t= o the routing drafts (info model and encoding).

 

If yo= u look at the routing drafts (info model and encoding), you will find that one of = your suggestions is adopted (i.e., simply advertize the available number of ODU0= , ODU1, ODU2, ..., ODU4 container instances).

 

One m= ore thing for your first comment:

If yo= u create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, you have to advertise a new TE link or put this FA as a component link of an existing T= E link (like RFC4206bis).

 

 


Best Regards
 
Fatai
 

-----= Original Message -----

Sent: Wednesday, July 07, 2010 11:43 PM

Subje= ct: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt=

 

> = Hi Lou
>
> Thanks, I also would like to hear about the same.
>
> Snigdho
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 07, 2010 8:37 AM
> To: Snigdho Bardalai
> Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-fram= ework@tools.ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt
>
> Snigdho,
> I believe there has been some off-line discussion on how to better > align the work with 4202.  Use of common approaches is of course = one of
> the main objectives of *C*CAMP.  I look forward to hearing from t= he
> draft and discussion contributors on there progress on this point.
>
> Lou
>
> On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
>> Hello,
>>
>> I have a comment and a question on Section 3.1.2.1. This section >> describes the link-parameters that are required for OTN service routing
>> purposes.
>>
>> My comment is how are we going to advertise the low-order ODUj
>> availability within a higher-order container. For example, conside= r an
>> OTU3 link which has 16 time-slots of 2.5G granularity and then we<= br> >> establish an ODU2 service over the link. At this point in time the OTU3
>> link has 12 time-slots available for ODU2 services and up to 12+4<= br> >> time-slots available for ODU1 services (4 ODU1s are contained over= the
>> ODU2). So it is obvious from this example that the number of time-slots
>> available is different based on the signal-type (i.e. ODU1 and ODU= 2).
>> How do we address this issue based on the approach specified in th= e draft?
>>
>> My other question is why not simply advertize the available number= of
>> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent<= br> >> bandwidth in bytes/sec within a link? This approach seems to be mo= re
>> in-line with the general approach outlined in RFC-4202. Refer to section
>> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
>> advertised per VC rate for an SDH link. The additional benefit is = that
>> the advertisement is TS size independent and hence will simplify t= he
>> implementation.
>>
>> Regards
>>
>> Snigdho
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

--_000_052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E202atlsrvexgenat_-- From Jonathan.Sadler@tellabs.com Thu Jul 8 11:35:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB063A6A95 for ; Thu, 8 Jul 2010 11:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9HA8MkPqHH1 for ; Thu, 8 Jul 2010 11:35:38 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 4CEB53A68DE for ; Thu, 8 Jul 2010 11:35:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,559,1272844800"; d="scan'208";a="1324582915" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 18:35:42 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Thu, 8 Jul 2010 13:35:42 -0500 From: "Sadler, Jonathan B." To: Igor Bryskin , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 13:35:40 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSA= Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:35:39 -0000 For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 11:40:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F813A6833 for ; Thu, 8 Jul 2010 11:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9kduIenUrGb for ; Thu, 8 Jul 2010 11:40:24 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 759F73A68B6 for ; Thu, 8 Jul 2010 11:40:23 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68IeN9D001953 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 20:40:23 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 20:40:23 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 14:40:21 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:40:19 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:40:27 -0000 There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Thu Jul 8 11:43:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BA73A67F4 for ; Thu, 8 Jul 2010 11:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFLPDWMjbppi for ; Thu, 8 Jul 2010 11:43:26 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 19C553A635F for ; Thu, 8 Jul 2010 11:43:26 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Thu, 8 Jul 2010 11:43:02 -0700 From: Snigdho Bardalai To: Igor Bryskin , "Sadler, Jonathan B." , John E Drake , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 11:43:30 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeA Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:43:27 -0000 Why not simply create switching capability descriptors per hierarchy (i.e. = ODU0, ODU1,...)? > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 11:40 AM > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > There is a lot of swcaps available :=3D) > Separate swcaps provide an easy way to constrain connection to a > desired level of hierarchy. >=20 > -----Original Message----- > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > Sent: Thursday, July 08, 2010 2:36 PM > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > ODU3 in ODU4) - while this may be the worst case, it is the possible > case too. >=20 > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > 400G?) the depth of the hierarchy will grow. >=20 > This makes me wonder: wouldn't a generalized method be a better > approach than just creating new SwitchingTypes -- especially since the > signals supported within each of these is the same (e.g. an ODU1 over > an ODU2 is the same as an ODU1 over an ODU3...) >=20 > Jonathan Sadler >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: Thursday, July 08, 2010 1:31 PM > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > I think OTN links require more than one switchcaps: as many as the > depth of the deepest possible OTN DP hierarchy, for example: >=20 > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ >=20 > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > What do you mean by "different switchcaps"? >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not > clear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > and > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN > specific > > ISCD. The combination of Switching Capability and Encoding type of > RFC4202 > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order > containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > OTN > > hierarchies and constrain LO connections to HO containers, one needs > to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for > control > > plane, no matter how you encode the routing information. For TDM > networks, > > you know the resource is allocated based on TS, so the available TS > should > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I > think > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will > find > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > ODU1, > > you have to advertise a new TE link or put this FA as a component > link of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course > one of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service > routing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, > consider an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the > OTU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over > the > > >> ODU2). So it is obvious from this example that the number of time- > slots > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > >> How do we address this issue based on the approach specified in > the > > draft? > > >> > > >> My other question is why not simply advertize the available number > of > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be > more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is > that > > >> the advertisement is TS size independent and hence will simplify > the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Thu Jul 8 11:45:33 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5734E3A679C for ; Thu, 8 Jul 2010 11:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve2WG18ixcLf for ; Thu, 8 Jul 2010 11:45:32 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id A43EF3A68A0 for ; Thu, 8 Jul 2010 11:45:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,559,1272844800"; d="scan'208";a="1324584244" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 18:45:35 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Thu, 8 Jul 2010 13:45:35 -0500 From: "Sadler, Jonathan B." To: Igor Bryskin , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 13:45:33 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79A Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:45:33 -0000 How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 11:45:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AD03A6B36 for ; Thu, 8 Jul 2010 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiG5Ffpwb6Dv for ; Thu, 8 Jul 2010 11:45:48 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id DDA043A6B2C for ; Thu, 8 Jul 2010 11:45:46 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68Ijkwe009718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 20:45:47 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 20:45:46 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.694.0; Thu, 8 Jul 2010 20:45:46 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 14:45:44 -0400 From: Igor Bryskin To: Snigdho Bardalai , "Sadler, Jonathan B." , John E Drake , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:45:41 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeAAAAcENA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:45:50 -0000 Because the same signal (and connection) could be on a different hierarchy = level.=20 -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com]=20 Sent: Thursday, July 08, 2010 2:44 PM To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berge= r Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Why not simply create switching capability descriptors per hierarchy (i.e. = ODU0, ODU1,...)? > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 11:40 AM > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > There is a lot of swcaps available :=3D) > Separate swcaps provide an easy way to constrain connection to a > desired level of hierarchy. >=20 > -----Original Message----- > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > Sent: Thursday, July 08, 2010 2:36 PM > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > ODU3 in ODU4) - while this may be the worst case, it is the possible > case too. >=20 > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > 400G?) the depth of the hierarchy will grow. >=20 > This makes me wonder: wouldn't a generalized method be a better > approach than just creating new SwitchingTypes -- especially since the > signals supported within each of these is the same (e.g. an ODU1 over > an ODU2 is the same as an ODU1 over an ODU3...) >=20 > Jonathan Sadler >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: Thursday, July 08, 2010 1:31 PM > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > I think OTN links require more than one switchcaps: as many as the > depth of the deepest possible OTN DP hierarchy, for example: >=20 > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ >=20 > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > What do you mean by "different switchcaps"? >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not > clear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > and > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN > specific > > ISCD. The combination of Switching Capability and Encoding type of > RFC4202 > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order > containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > OTN > > hierarchies and constrain LO connections to HO containers, one needs > to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for > control > > plane, no matter how you encode the routing information. For TDM > networks, > > you know the resource is allocated based on TS, so the available TS > should > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I > think > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will > find > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > ODU1, > > you have to advertise a new TE link or put this FA as a component > link of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course > one of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service > routing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, > consider an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the > OTU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over > the > > >> ODU2). So it is obvious from this example that the number of time- > slots > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > >> How do we address this issue based on the approach specified in > the > > draft? > > >> > > >> My other question is why not simply advertize the available number > of > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be > more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is > that > > >> the advertisement is TS size independent and hence will simplify > the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 11:50:06 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882AB3A6833 for ; Thu, 8 Jul 2010 11:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RK-b-BRnanE for ; Thu, 8 Jul 2010 11:50:05 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 956F93A684A for ; Thu, 8 Jul 2010 11:50:04 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68Io4xQ014578 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 20:50:04 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 20:50:04 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 14:50:01 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:49:59 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:50:06 -0000 In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Thu Jul 8 11:51:22 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4033A67F4 for ; Thu, 8 Jul 2010 11:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7Ivgb2+G+sG for ; Thu, 8 Jul 2010 11:51:21 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id DFE773A635F for ; Thu, 8 Jul 2010 11:51:20 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Thu, 8 Jul 2010 11:51:24 -0700 From: Snigdho Bardalai To: Igor Bryskin , "Sadler, Jonathan B." , John E Drake , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 11:51:24 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeAAAAcENAAABxFkA== Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:51:22 -0000 That means that the signal can be at different hierarchies over different O= TN links along the route. If that is the case how can you constraint a connection to a specific hiera= rchy end-to-end? I think all you can do is find an OTN link that can suppor= t the required signal-type. > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 11:46 AM > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Because the same signal (and connection) could be on a different > hierarchy level. >=20 > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 2:44 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Why not simply create switching capability descriptors per hierarchy > (i.e. ODU0, ODU1,...)? >=20 > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 11:40 AM > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > There is a lot of swcaps available :=3D) > > Separate swcaps provide an easy way to constrain connection to a > > desired level of hierarchy. > > > > -----Original Message----- > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > Sent: Thursday, July 08, 2010 2:36 PM > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 in ODU4) - while this may be the worst case, it is the possible > > case too. > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" > -- > > 400G?) the depth of the hierarchy will grow. > > > > This makes me wonder: wouldn't a generalized method be a better > > approach than just creating new SwitchingTypes -- especially since > the > > signals supported within each of these is the same (e.g. an ODU1 over > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > Jonathan Sadler > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: Thursday, July 08, 2010 1:31 PM > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > before we can embark on any proposals to the problem. I am still > not > > clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > and > > > it is highly desirable to adhere to the layer independent paradigm > of > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > ISCD. The combination of Switching Capability and Encoding type of > > RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > hierarchies and constrain LO connections to HO containers, one > needs > > to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for > > control > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > you know the resource is allocated based on TS, so the available TS > > should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, > > > you have to advertise a new TE link or put this FA as a component > > link of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; > gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to > better > > > > align the work with 4202. Use of common approaches is of course > > one of > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > draft and discussion contributors on there progress on this > point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, > > consider an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > >> establish an ODU2 service over the link. At this point in time > the > > OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to > 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > the > > > >> ODU2). So it is obvious from this example that the number of > time- > > slots > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > >> How do we address this issue based on the approach specified in > > the > > > draft? > > > >> > > > >> My other question is why not simply advertize the available > number > > of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit > is > > that > > > >> the advertisement is TS size independent and hence will simplify > > the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Jul 8 11:55:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3F23A686A for ; Thu, 8 Jul 2010 11:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuLCRX21aGyR for ; Thu, 8 Jul 2010 11:55:38 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 3747F3A679C for ; Thu, 8 Jul 2010 11:55:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTDYfFst1dWnSoEhpbK/0dIGSoIFP5TJ/@postini.com; Thu, 08 Jul 2010 11:55:42 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Jul 2010 11:51:24 -0700 From: John E Drake To: "Sadler, Jonathan B." , Igor Bryskin , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 11:51:22 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4A== Message-ID: <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:55:39 -0000 Igor, I suppose you could do that but it doesn't seem necessary. I think the exi= sting TDM ISC could be re-used: Switching capability =3D TDM Encoding =3D OTN Max LSP BW (0-7) =3D max ODU rate at that priority Min LSP BW =3D min ODU rate (where rates are expressed in bytes per second) There would be one or more of these advertised, such that every ODU rate cu= rrently supported by the advertising node is advertised either explicitly o= r implicitly, by being within the range covered by a Min/Max LSP BW pair. Thanks, John > -----Original Message----- > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > Sent: Thursday, July 08, 2010 11:36 AM > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 > in ODU4) - while this may be the worst case, it is the possible case too. >=20 > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > 400G?) the depth of the hierarchy will grow. >=20 > This makes me wonder: wouldn't a generalized method be a better approach > than just creating new SwitchingTypes -- especially since the signals > supported within each of these is the same (e.g. an ODU1 over an ODU2 is > the same as an ODU1 over an ODU3...) >=20 > Jonathan Sadler >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 1:31 PM > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > I think OTN links require more than one switchcaps: as many as the depth > of the deepest possible OTN DP hierarchy, for example: >=20 > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ >=20 > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > What do you mean by "different switchcaps"? >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not > clear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > and > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN > specific > > ISCD. The combination of Switching Capability and Encoding type of > RFC4202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order > containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM > networks, > > you know the resource is allocated based on TS, so the available TS > should > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will > find > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > ODU1, > > you have to advertise a new TE link or put this FA as a component link > of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one > of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service > routing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider > an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the > OTU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over > the > > >> ODU2). So it is obvious from this example that the number of time- > slots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is > that > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 11:58:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8753A67F7 for ; Thu, 8 Jul 2010 11:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWsJVSPJxp6Y for ; Thu, 8 Jul 2010 11:58:01 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 204343A68A3 for ; Thu, 8 Jul 2010 11:58:00 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68Iw1gJ025788 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 20:58:01 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 20:58:01 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 14:57:58 -0400 From: Igor Bryskin To: Snigdho Bardalai , "Sadler, Jonathan B." , John E Drake , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:57:57 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeAAAAcENAAABxFkAAAJ3WA Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:58:03 -0000 >If that is the case how can you constraint a connection to a >specific hie= rarchy end-to-end?=20 You don't have to. You MAY constrain a connection to take, for example, onl= y LO links. But you can also allow the connection to take either HO or LO l= inks. Also, keep in mind that GMPLS allows to advertise OTN link to belong = to more than one OTN layer. -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com]=20 Sent: Thursday, July 08, 2010 2:51 PM To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berge= r Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t That means that the signal can be at different hierarchies over different O= TN links along the route. If that is the case how can you constraint a connection to a specific hiera= rchy end-to-end? I think all you can do is find an OTN link that can suppor= t the required signal-type. > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 11:46 AM > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Because the same signal (and connection) could be on a different > hierarchy level. >=20 > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 2:44 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Why not simply create switching capability descriptors per hierarchy > (i.e. ODU0, ODU1,...)? >=20 > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 11:40 AM > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > There is a lot of swcaps available :=3D) > > Separate swcaps provide an easy way to constrain connection to a > > desired level of hierarchy. > > > > -----Original Message----- > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > Sent: Thursday, July 08, 2010 2:36 PM > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 in ODU4) - while this may be the worst case, it is the possible > > case too. > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" > -- > > 400G?) the depth of the hierarchy will grow. > > > > This makes me wonder: wouldn't a generalized method be a better > > approach than just creating new SwitchingTypes -- especially since > the > > signals supported within each of these is the same (e.g. an ODU1 over > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > Jonathan Sadler > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: Thursday, July 08, 2010 1:31 PM > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > before we can embark on any proposals to the problem. I am still > not > > clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > and > > > it is highly desirable to adhere to the layer independent paradigm > of > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > ISCD. The combination of Switching Capability and Encoding type of > > RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > hierarchies and constrain LO connections to HO containers, one > needs > > to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for > > control > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > you know the resource is allocated based on TS, so the available TS > > should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, > > > you have to advertise a new TE link or put this FA as a component > > link of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; > gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to > better > > > > align the work with 4202. Use of common approaches is of course > > one of > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > draft and discussion contributors on there progress on this > point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, > > consider an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > >> establish an ODU2 service over the link. At this point in time > the > > OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to > 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > the > > > >> ODU2). So it is obvious from this example that the number of > time- > > slots > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > >> How do we address this issue based on the approach specified in > > the > > > draft? > > > >> > > > >> My other question is why not simply advertize the available > number > > of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit > is > > that > > > >> the advertisement is TS size independent and hence will simplify > > the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Thu Jul 8 12:02:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947093A6B36 for ; Thu, 8 Jul 2010 12:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CLntWLYampZ for ; Thu, 8 Jul 2010 12:02:08 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 308143A68A9 for ; Thu, 8 Jul 2010 12:01:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="1324586524" Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 19:00:59 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Thu, 8 Jul 2010 13:58:46 -0500 From: "Sadler, Jonathan B." To: Igor Bryskin , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 13:57:20 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UAAADhsIA== Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:02:09 -0000 The only way I can see that working is if the entity doing path computation= knows about the equivalence of Switching Cap/Encapsulation Type/Signal Typ= e tuples. That sounds like the path computation function has to know specif= ic details about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:50 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 12:02:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81A23A6A95 for ; Thu, 8 Jul 2010 12:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAZcAG505WOT for ; Thu, 8 Jul 2010 12:02:10 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 646E13A687F for ; Thu, 8 Jul 2010 12:02:03 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68J21Bi032475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 21:02:01 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 21:02:01 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 15:01:59 -0400 From: Igor Bryskin To: John E Drake , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 15:01:58 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxg Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:02:11 -0000 This won't allow an easy way to constrain a connection to a desired level o= f hierarchy. As Jonathan correctly wrote, ODU1 could be supported by differ= ent levels, and what if an operator wants to constrain the connection to a = particular one? -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 2:51 PM To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, I suppose you could do that but it doesn't seem necessary. I think the exi= sting TDM ISC could be re-used: Switching capability =3D TDM Encoding =3D OTN Max LSP BW (0-7) =3D max ODU rate at that priority Min LSP BW =3D min ODU rate (where rates are expressed in bytes per second) There would be one or more of these advertised, such that every ODU rate cu= rrently supported by the advertising node is advertised either explicitly o= r implicitly, by being within the range covered by a Min/Max LSP BW pair. Thanks, John > -----Original Message----- > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > Sent: Thursday, July 08, 2010 11:36 AM > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 > in ODU4) - while this may be the worst case, it is the possible case too. >=20 > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > 400G?) the depth of the hierarchy will grow. >=20 > This makes me wonder: wouldn't a generalized method be a better approach > than just creating new SwitchingTypes -- especially since the signals > supported within each of these is the same (e.g. an ODU1 over an ODU2 is > the same as an ODU1 over an ODU3...) >=20 > Jonathan Sadler >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 1:31 PM > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > I think OTN links require more than one switchcaps: as many as the depth > of the deepest possible OTN DP hierarchy, for example: >=20 > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ >=20 > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > What do you mean by "different switchcaps"? >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not > clear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > and > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN > specific > > ISCD. The combination of Switching Capability and Encoding type of > RFC4202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order > containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM > networks, > > you know the resource is allocated based on TS, so the available TS > should > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will > find > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > ODU1, > > you have to advertise a new TE link or put this FA as a component link > of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one > of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service > routing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider > an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the > OTU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over > the > > >> ODU2). So it is obvious from this example that the number of time- > slots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is > that > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 12:05:43 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C8C3A6B3A for ; Thu, 8 Jul 2010 12:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnfVSn3W3fgb for ; Thu, 8 Jul 2010 12:05:42 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id D46693A6B30 for ; Thu, 8 Jul 2010 12:05:41 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68J5fYi004474 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 21:05:41 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 21:05:41 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 15:05:39 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 15:05:37 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UAAADhsIAAAYG5Q Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E227@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_01:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:05:44 -0000 All path computation needs to know is switchcap/encoding type combination t= he connection is allowed to take. This is the GMPLS universal multi-layer a= pproach (not specific to OTN). -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:57 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t The only way I can see that working is if the entity doing path computation= knows about the equivalence of Switching Cap/Encapsulation Type/Signal Typ= e tuples. That sounds like the path computation function has to know specif= ic details about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:50 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Thu Jul 8 12:14:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EABC3A6867 for ; Thu, 8 Jul 2010 12:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnQx7zyCguZA for ; Thu, 8 Jul 2010 12:14:36 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id E92F33A6834 for ; Thu, 8 Jul 2010 12:14:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="1324588525" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 19:14:39 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Thu, 8 Jul 2010 14:14:39 -0500 From: "Sadler, Jonathan B." To: Igor Bryskin , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:14:38 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UAAADhsIAAAYG5QAABYszA= Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E1D@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E227@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E227@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:14:41 -0000 I'm not certain I agree this is "universal". Consider an LSP with a loose = ERO hop -- how does the intermediate GMPLS NE know what Switching Cap/Encod= ing Type to allow? The LSP signaling only contains one Switching Cap/Encod= ing Type... Again, it looks like that intermediate node has to understand specific deta= ils about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 2:06 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t All path computation needs to know is switchcap/encoding type combination t= he connection is allowed to take. This is the GMPLS universal multi-layer a= pproach (not specific to OTN). -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:57 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t The only way I can see that working is if the entity doing path computation= knows about the equivalence of Switching Cap/Encapsulation Type/Signal Typ= e tuples. That sounds like the path computation function has to know specif= ic details about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:50 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Thu Jul 8 12:20:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FE93A68B6 for ; Thu, 8 Jul 2010 12:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjGlz07gbwT5 for ; Thu, 8 Jul 2010 12:20:06 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 207A03A6834 for ; Thu, 8 Jul 2010 12:20:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="1324589345" Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 19:20:10 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Thu, 8 Jul 2010 14:18:28 -0500 From: "Sadler, Jonathan B." To: John E Drake , Igor Bryskin , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:18:27 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AABJhkg Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E2B@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:20:07 -0000 John, I agree that a single Switching Cap/Encoding Type should be possible. What= needs to be considered is how the potential LSP hierarchy is announced -- = especially when G.709 (2009) specific signals are being setup over G.709 (2= 003) intermediate nodes... Jonathan Sadler -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:51 PM To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, I suppose you could do that but it doesn't seem necessary. I think the exi= sting TDM ISC could be re-used: Switching capability =3D TDM Encoding =3D OTN Max LSP BW (0-7) =3D max ODU rate at that priority Min LSP BW =3D min ODU rate (where rates are expressed in bytes per second) There would be one or more of these advertised, such that every ODU rate cu= rrently supported by the advertising node is advertised either explicitly o= r implicitly, by being within the range covered by a Min/Max LSP BW pair. Thanks, John > -----Original Message----- > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > Sent: Thursday, July 08, 2010 11:36 AM > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 > in ODU4) - while this may be the worst case, it is the possible case too. >=20 > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > 400G?) the depth of the hierarchy will grow. >=20 > This makes me wonder: wouldn't a generalized method be a better approach > than just creating new SwitchingTypes -- especially since the signals > supported within each of these is the same (e.g. an ODU1 over an ODU2 is > the same as an ODU1 over an ODU3...) >=20 > Jonathan Sadler >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 1:31 PM > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > I think OTN links require more than one switchcaps: as many as the depth > of the deepest possible OTN DP hierarchy, for example: >=20 > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ >=20 > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > What do you mean by "different switchcaps"? >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not > clear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > and > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN > specific > > ISCD. The combination of Switching Capability and Encoding type of > RFC4202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order > containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM > networks, > > you know the resource is allocated based on TS, so the available TS > should > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will > find > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > ODU1, > > you have to advertise a new TE link or put this FA as a component link > of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one > of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service > routing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider > an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the > OTU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over > the > > >> ODU2). So it is obvious from this example that the number of time- > slots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is > that > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 12:26:58 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6643A6452 for ; Thu, 8 Jul 2010 12:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le5eBJh-JynY for ; Thu, 8 Jul 2010 12:26:52 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 1C5183A68B6 for ; Thu, 8 Jul 2010 12:26:51 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68JQpoB032700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 21:26:51 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 21:26:51 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 15:26:49 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 15:26:43 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UAAADhsIAAAYG5QAABYszAAAEZIUA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E23D@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E227@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E1D@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E1D@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:26:58 -0000 Agree, but we all know that ingress NE has more information than transit NE= s. For instance, how a transit NE knows whether optical impairments need or= need not to be considered in WDM layer path computation? This is a service= specific policy and unless it is signaled is known only on the ingress NE, -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 3:15 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I'm not certain I agree this is "universal". Consider an LSP with a loose = ERO hop -- how does the intermediate GMPLS NE know what Switching Cap/Encod= ing Type to allow? The LSP signaling only contains one Switching Cap/Encod= ing Type... Again, it looks like that intermediate node has to understand specific deta= ils about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 2:06 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t All path computation needs to know is switchcap/encoding type combination t= he connection is allowed to take. This is the GMPLS universal multi-layer a= pproach (not specific to OTN). -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:57 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t The only way I can see that working is if the entity doing path computation= knows about the equivalence of Switching Cap/Encapsulation Type/Signal Typ= e tuples. That sounds like the path computation function has to know specif= ic details about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:50 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Thu Jul 8 12:34:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421FD3A6B57 for ; Thu, 8 Jul 2010 12:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hnWonDdtyl0 for ; Thu, 8 Jul 2010 12:34:26 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 344883A6B60 for ; Thu, 8 Jul 2010 12:33:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="1324591611" Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 19:33:23 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Thu, 8 Jul 2010 14:32:02 -0500 From: "Sadler, Jonathan B." To: Igor Bryskin , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:32:00 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UAAADhsIAAAYG5QAABYszAAAEZIUAAAQ8+A Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E5C@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E227@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E1D@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E23D@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E23D@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:34:28 -0000 I agree that for existing standards there are some constraints (e.g. impair= ments, latency) that cannot be handled by the intermediate node. However, in this case, the introduction of multiple switching capabilities = is creating this problem. If a method exists that solves the need to show = hierarchy supported but doesn't create this problem, I would expect it to b= e more desirable. Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 2:27 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Agree, but we all know that ingress NE has more information than transit NE= s. For instance, how a transit NE knows whether optical impairments need or= need not to be considered in WDM layer path computation? This is a service= specific policy and unless it is signaled is known only on the ingress NE, -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 3:15 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I'm not certain I agree this is "universal". Consider an LSP with a loose = ERO hop -- how does the intermediate GMPLS NE know what Switching Cap/Encod= ing Type to allow? The LSP signaling only contains one Switching Cap/Encod= ing Type... Again, it looks like that intermediate node has to understand specific deta= ils about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 2:06 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t All path computation needs to know is switchcap/encoding type combination t= he connection is allowed to take. This is the GMPLS universal multi-layer a= pproach (not specific to OTN). -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 2:57 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t The only way I can see that working is if the entity doing path computation= knows about the equivalence of Switching Cap/Encapsulation Type/Signal Typ= e tuples. That sounds like the path computation function has to know specif= ic details about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 1:50 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy. -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Snigdho, > > > > > > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. > > > > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. > > > > Cheers, > > Igor > > > > Regards > > Snigdho > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Hi Snigdho and Lou, > > > > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. > > > > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. > > > > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). > > > > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > One more thing for your first comment: > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). > > > > > > > Best Regards > > Fatai > > > ----- Original Message ----- > > From: "Snigdho Bardalai" > > > To: "Lou Berger" > > > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > > > Sent: Wednesday, July 07, 2010 11:43 PM > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Jul 8 12:38:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60E93A689F for ; Thu, 8 Jul 2010 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPZSPSS4VpHK for ; Thu, 8 Jul 2010 12:38:17 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 599F63A68A3 for ; Thu, 8 Jul 2010 12:38:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTDYpFxIzq5KENQkjmSMe8Z8RwZKTBhY8@postini.com; Thu, 08 Jul 2010 12:38:21 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Jul 2010 12:09:35 -0700 From: John E Drake To: Igor Bryskin , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 12:09:34 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXA= Message-ID: <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:38:19 -0000 Igor, You are arguing backwards from a capability that might or might not be need= ed. I don't recall seeing this requirement in any of the CCAMP OTN documen= ts to date. I actually have the impression that the requirement is actually the opposit= e; viz, establish an LSP by whatever means. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:02 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > This won't allow an easy way to constrain a connection to a desired level > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > different levels, and what if an operator wants to constrain the > connection to a particular one? >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 2:51 PM > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Igor, >=20 > I suppose you could do that but it doesn't seem necessary. I think the > existing TDM ISC could be re-used: >=20 > Switching capability =3D TDM > Encoding =3D OTN > Max LSP BW (0-7) =3D max ODU rate at that priority > Min LSP BW =3D min ODU rate >=20 > (where rates are expressed in bytes per second) >=20 > There would be one or more of these advertised, such that every ODU rate > currently supported by the advertising node is advertised either > explicitly or implicitly, by being within the range covered by a Min/Max > LSP BW pair. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > Sent: Thursday, July 08, 2010 11:36 AM > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > ODU3 > > in ODU4) - while this may be the worst case, it is the possible case > too. > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > > 400G?) the depth of the hierarchy will grow. > > > > This makes me wonder: wouldn't a generalized method be a better approac= h > > than just creating new SwitchingTypes -- especially since the signals > > supported within each of these is the same (e.g. an ODU1 over an ODU2 i= s > > the same as an ODU1 over an ODU3...) > > > > Jonathan Sadler > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 1:31 PM > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > I think OTN links require more than one switchcaps: as many as the dept= h > > of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework docume= nt > > > before we can embark on any proposals to the problem. I am still not > > clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > > and > > > it is highly desirable to adhere to the layer independent paradigm of > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > ISCD. The combination of Switching Capability and Encoding type of > > RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > OTN > > > hierarchies and constrain LO connections to HO containers, one needs > to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for contro= l > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > you know the resource is allocated based on TS, so the available TS > > should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will > > find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, > > > you have to advertise a new TE link or put this FA as a component lin= k > > of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to better > > > > align the work with 4202. Use of common approaches is of course on= e > > of > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > draft and discussion contributors on there progress on this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, conside= r > > an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > >> establish an ODU2 service over the link. At this point in time the > > OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained over > > the > > > >> ODU2). So it is obvious from this example that the number of time- > > slots > > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > > >> How do we address this issue based on the approach specified in th= e > > > draft? > > > >> > > > >> My other question is why not simply advertize the available number > of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be > more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit is > > that > > > >> the advertisement is TS size independent and hence will simplify > the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 12:42:52 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE25F3A68AC for ; Thu, 8 Jul 2010 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKUTkzbVmpdc for ; Thu, 8 Jul 2010 12:42:51 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id AE1313A68A3 for ; Thu, 8 Jul 2010 12:42:50 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68JgiGd021405 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 21:42:44 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 21:42:44 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 15:42:41 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 15:42:35 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAAK79AAAAq1UAAADhsIAAAYG5QAABYszAAAEZIUAAAQ8+AAAAyBQA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E251@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DA0@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E20D@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5DDC@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E227@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E1D@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E23D@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E5C@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E5C@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:42:53 -0000 > However, in this case, the introduction of multiple switching capabiliti= es is creating this problem. If a method exists that solves the need to sh= ow hierarchy supported but doesn't create this problem, I would expect it t= o be more desirable. IB>> I almost always compute entire explicit end-to-end paths in one place = (ingress NE or remote PCE) even when explicit loose paths are specified. Bu= t in rear cases when I have to do distributed path computation, in OTN case= I would simply assume that all OTN layers are allowed -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 3:32 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I agree that for existing standards there are some constraints (e.g. impair= ments, latency) that cannot be handled by the intermediate node. However, in this case, the introduction of multiple switching capabilities = is creating this problem. If a method exists that solves the need to show = hierarchy supported but doesn't create this problem, I would expect it to b= e more desirable. Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 2:27 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Agree, but we all know that ingress NE has more information than transit NE= s. For instance, how a transit NE knows whether optical impairments need or= need not to be considered in WDM layer path computation? This is a service= specific policy and unless it is signaled is known only on the ingress NE, -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 3:15 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I'm not certain I agree this is "universal". Consider an LSP with a loose = ERO hop -- how does the intermediate GMPLS NE know what Switching Cap/Encod= ing Type to allow? The LSP signaling only contains one Switching Cap/Encod= ing Type... Again, it looks like that intermediate node has to understand specific deta= ils about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 2:06 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t All path computation needs to know is switchcap/encoding type combination t= he connection is allowed to take. This is the GMPLS universal multi-layer a= pproach (not specific to OTN). -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 2:57 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t The only way I can see that working is if the entity doing path computation= knows about the equivalence of Switching Cap/Encapsulation Type/Signal Typ= e tuples. That sounds like the path computation function has to know specif= ic details about the technology... Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 1:50 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In the situation you describe the connection goes through more than one OTN= layer. It is possible to route such connection by constraining path comput= ation to more than layer (e.g. in case of restoration you may allow the con= nection to take any OTN link with sufficient bandwidth) -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 2:46 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t How do you see the LO/HO/SHO switch-caps being allocated to the ODU signals= ? Since the switch-cap is end-to-end significant, there is no opportunity for= changing it in the middle, but the specific relationship between the LSP a= nd what it is being carried by can change. For example, an ODU1 could star= t out on an OTU1, but at the next node (operated by the customer) be muxed = into an ODU2 that goes into a carrier's edge-to-edge connection. That carr= ier could in turn use a carriers-carrier service which muxes it into an ODU= 3. At each point in this chain, the ODU1 has a different relationship to what = is carrying it. At the ODU1 over OTU1, it was an HO signal. At the ODU1 o= ver ODU2, it was a LO signal. What is it at the ODU1 over ODU2 over ODU3? Jonathan Sadler -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 1:40 PM To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy. -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Snigdho, > > > > > > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. > > > > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. > > > > Cheers, > > Igor > > > > Regards > > Snigdho > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Hi Snigdho and Lou, > > > > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. > > > > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. > > > > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). > > > > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > One more thing for your first comment: > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). > > > > > > > Best Regards > > Fatai > > > ----- Original Message ----- > > From: "Snigdho Bardalai" > > > To: "Lou Berger" > > > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > > > Sent: Wednesday, July 07, 2010 11:43 PM > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 12:49:25 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68C53A688F for ; Thu, 8 Jul 2010 12:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvMEPRkHbit7 for ; Thu, 8 Jul 2010 12:49:24 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 2F89C3A685A for ; Thu, 8 Jul 2010 12:49:22 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68JnMc4030723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 21:49:22 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 21:49:22 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.694.0; Thu, 8 Jul 2010 21:49:21 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 15:49:18 -0400 From: Igor Bryskin To: John E Drake , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 15:49:14 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:49:25 -0000 John, HO connections may make up a topology for LO connections. They may require = different planning and created in different time frame. Ergo it is likely t= hat an operator may want to route a service LO connection over topology he = prepared rather than over any OTN capable links. -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 3:10 PM To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, You are arguing backwards from a capability that might or might not be need= ed. I don't recall seeing this requirement in any of the CCAMP OTN documen= ts to date. I actually have the impression that the requirement is actually the opposit= e; viz, establish an LSP by whatever means. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:02 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > This won't allow an easy way to constrain a connection to a desired level > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > different levels, and what if an operator wants to constrain the > connection to a particular one? >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 2:51 PM > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Igor, >=20 > I suppose you could do that but it doesn't seem necessary. I think the > existing TDM ISC could be re-used: >=20 > Switching capability =3D TDM > Encoding =3D OTN > Max LSP BW (0-7) =3D max ODU rate at that priority > Min LSP BW =3D min ODU rate >=20 > (where rates are expressed in bytes per second) >=20 > There would be one or more of these advertised, such that every ODU rate > currently supported by the advertising node is advertised either > explicitly or implicitly, by being within the range covered by a Min/Max > LSP BW pair. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > Sent: Thursday, July 08, 2010 11:36 AM > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > ODU3 > > in ODU4) - while this may be the worst case, it is the possible case > too. > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > > 400G?) the depth of the hierarchy will grow. > > > > This makes me wonder: wouldn't a generalized method be a better approac= h > > than just creating new SwitchingTypes -- especially since the signals > > supported within each of these is the same (e.g. an ODU1 over an ODU2 i= s > > the same as an ODU1 over an ODU3...) > > > > Jonathan Sadler > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 1:31 PM > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > I think OTN links require more than one switchcaps: as many as the dept= h > > of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework docume= nt > > > before we can embark on any proposals to the problem. I am still not > > clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > > and > > > it is highly desirable to adhere to the layer independent paradigm of > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > ISCD. The combination of Switching Capability and Encoding type of > > RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > OTN > > > hierarchies and constrain LO connections to HO containers, one needs > to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for contro= l > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > you know the resource is allocated based on TS, so the available TS > > should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will > > find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, > > > you have to advertise a new TE link or put this FA as a component lin= k > > of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to better > > > > align the work with 4202. Use of common approaches is of course on= e > > of > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > draft and discussion contributors on there progress on this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, conside= r > > an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > >> establish an ODU2 service over the link. At this point in time the > > OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained over > > the > > > >> ODU2). So it is obvious from this example that the number of time- > > slots > > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > > >> How do we address this issue based on the approach specified in th= e > > > draft? > > > >> > > > >> My other question is why not simply advertize the available number > of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be > more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit is > > that > > > >> the advertisement is TS size independent and hence will simplify > the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Jul 8 12:55:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28DF3A688F for ; Thu, 8 Jul 2010 12:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qytXnJEi33zR for ; Thu, 8 Jul 2010 12:55:45 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 01A6A3A685A for ; Thu, 8 Jul 2010 12:55:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTDYtMwoeucWVxgAWc3mzSFhl1TNbDoeP@postini.com; Thu, 08 Jul 2010 12:55:50 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Jul 2010 12:24:46 -0700 From: John E Drake To: "Sadler, Jonathan B." , Igor Bryskin , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 12:24:44 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AABJhkgAAA7miA= Message-ID: <5E893DB832F57341992548CDBB3331639843878453@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E2B@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5E2B@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:55:48 -0000 Jonathan, I would have to see some examples. What I proposed was simply a reduced ve= rsion of what is in the OTN routing I-D. It tried to advertise available b= andwidth by ODUj, which I don't think is necessary. Thanks, John > -----Original Message----- > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > Sent: Thursday, July 08, 2010 12:18 PM > To: John E Drake; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > John, >=20 > I agree that a single Switching Cap/Encoding Type should be possible. > What needs to be considered is how the potential LSP hierarchy is > announced -- especially when G.709 (2009) specific signals are being setu= p > over G.709 (2003) intermediate nodes... >=20 > Jonathan Sadler >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:51 PM > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Igor, >=20 > I suppose you could do that but it doesn't seem necessary. I think the > existing TDM ISC could be re-used: >=20 > Switching capability =3D TDM > Encoding =3D OTN > Max LSP BW (0-7) =3D max ODU rate at that priority > Min LSP BW =3D min ODU rate >=20 > (where rates are expressed in bytes per second) >=20 > There would be one or more of these advertised, such that every ODU rate > currently supported by the advertising node is advertised either > explicitly or implicitly, by being within the range covered by a Min/Max > LSP BW pair. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > Sent: Thursday, July 08, 2010 11:36 AM > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > ODU3 > > in ODU4) - while this may be the worst case, it is the possible case > too. > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > > 400G?) the depth of the hierarchy will grow. > > > > This makes me wonder: wouldn't a generalized method be a better approac= h > > than just creating new SwitchingTypes -- especially since the signals > > supported within each of these is the same (e.g. an ODU1 over an ODU2 i= s > > the same as an ODU1 over an ODU3...) > > > > Jonathan Sadler > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 1:31 PM > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > I think OTN links require more than one switchcaps: as many as the dept= h > > of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework docume= nt > > > before we can embark on any proposals to the problem. I am still not > > clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > > and > > > it is highly desirable to adhere to the layer independent paradigm of > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > ISCD. The combination of Switching Capability and Encoding type of > > RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > OTN > > > hierarchies and constrain LO connections to HO containers, one needs > to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for contro= l > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > you know the resource is allocated based on TS, so the available TS > > should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will > > find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, > > > you have to advertise a new TE link or put this FA as a component lin= k > > of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to better > > > > align the work with 4202. Use of common approaches is of course on= e > > of > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > draft and discussion contributors on there progress on this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, conside= r > > an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > >> establish an ODU2 service over the link. At this point in time the > > OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained over > > the > > > >> ODU2). So it is obvious from this example that the number of time- > > slots > > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > > >> How do we address this issue based on the approach specified in th= e > > > draft? > > > >> > > > >> My other question is why not simply advertize the available number > of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be > more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit is > > that > > > >> the advertisement is TS size independent and hence will simplify > the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Jul 8 13:08:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F0B3A687F for ; Thu, 8 Jul 2010 13:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyQyuq095DXB for ; Thu, 8 Jul 2010 13:08:06 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id C8DD83A682B for ; Thu, 8 Jul 2010 13:08:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTDYwCWS3Rd6CgCORuGPkvqP4Ah/9O8je@postini.com; Thu, 08 Jul 2010 13:08:10 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 8 Jul 2010 13:07:21 -0700 From: John E Drake To: Igor Bryskin , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 13:07:19 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQ Message-ID: <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:08:18 -0000 Igor, >From the I-D under discussion: "While [G872-2001] considered the ODU as a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-Am2] includes an agreement to model the ODU as a single layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO-ODU (which has a one-to-one relationship with the OTU)." "Therefore, this document only considers ODU layer for LO ODU connection re= quest." "GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor = of TDM which can be used for ODU." "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:49 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > HO connections may make up a topology for LO connections. They may requir= e > different planning and created in different time frame. Ergo it is likely > that an operator may want to route a service LO connection over topology > he prepared rather than over any OTN capable links. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 3:10 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > You are arguing backwards from a capability that might or might not be > needed. I don't recall seeing this requirement in any of the CCAMP OTN > documents to date. > > I actually have the impression that the requirement is actually the > opposite; viz, establish an LSP by whatever means. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:02 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > This won't allow an easy way to constrain a connection to a desired > level > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > different levels, and what if an operator wants to constrain the > > connection to a particular one? > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > I suppose you could do that but it doesn't seem necessary. I think the > > existing TDM ISC could be re-used: > > > > Switching capability =3D TDM > > Encoding =3D OTN > > Max LSP BW (0-7) =3D max ODU rate at that priority > > Min LSP BW =3D min ODU rate > > > > (where rates are expressed in bytes per second) > > > > There would be one or more of these advertised, such that every ODU rat= e > > currently supported by the advertising node is advertised either > > explicitly or implicitly, by being within the range covered by a Min/Ma= x > > LSP BW pair. > > > > Thanks, > > > > John > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 11:36 AM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 > > > in ODU4) - while this may be the worst case, it is the possible case > > too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" = - > - > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > approach > > > than just creating new SwitchingTypes -- especially since the signals > > > supported within each of these is the same (e.g. an ODU1 over an ODU2 > is > > > the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > depth > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still no= t > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > > and > > > > it is highly desirable to adhere to the layer independent paradigm > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link t= o > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > > hierarchies and constrain LO connections to HO containers, one need= s > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link > > > of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to bette= r > > > > > align the work with 4202. Use of common approaches is of course > one > > > of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this point= . > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider > > > an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then w= e > > > > >> establish an ODU2 service over the link. At this point in time > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+= 4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > > >> How do we address this issue based on the approach specified in > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalen= t > > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit i= s > > > that > > > > >> the advertisement is TS size independent and hence will simplify > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 13:29:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19283A688F for ; Thu, 8 Jul 2010 13:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moFGuq+X4VXD for ; Thu, 8 Jul 2010 13:29:52 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 806283A6914 for ; Thu, 8 Jul 2010 13:29:51 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68KTmdh020148 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 22:29:48 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 22:29:48 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 16:29:44 -0400 From: Igor Bryskin To: John E Drake , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 16:29:41 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:29:53 -0000 Jonathan, According to ITU-T each layer must have a separate routing instance, hence = ITU-T folks assume that it would be very awkward to model an OTN network as= a multi-layer network. IN GMPLS, however, we do not have such a limitation. it is OK to share a ro= uting instance between several layers and we can take advantage of this. Wi= th the multi-layer approach I suggest one can do everything what is possibl= e to do in a single-layer approach by constraining the routing to all OTN l= ayers. However. It gives certain flexibility in building OTN hierarchies an= d constraining connections to desired levels of hierarchy, which is not obv= ious how can be done within a single layer. Ypu wrote: "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." What if in the described scenario the operator wants to constrain or prefer= for a given ODU2 connections usage of only OTU2 links rather than other po= ssible combinations perhaps provisioned for different purposes? Cheers, Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 08, 2010 4:07 PM To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, >From the I-D under discussion: "While [G872-2001] considered the ODU as a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-Am2] includes an agreement to model the ODU as a single layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO-ODU (which has a one-to-one relationship with the OTU)." "Therefore, this document only considers ODU layer for LO ODU connection re= quest." "GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor = of TDM which can be used for ODU." "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:49 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > HO connections may make up a topology for LO connections. They may requir= e > different planning and created in different time frame. Ergo it is likely > that an operator may want to route a service LO connection over topology > he prepared rather than over any OTN capable links. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 3:10 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > You are arguing backwards from a capability that might or might not be > needed. I don't recall seeing this requirement in any of the CCAMP OTN > documents to date. > > I actually have the impression that the requirement is actually the > opposite; viz, establish an LSP by whatever means. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:02 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > This won't allow an easy way to constrain a connection to a desired > level > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > different levels, and what if an operator wants to constrain the > > connection to a particular one? > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > I suppose you could do that but it doesn't seem necessary. I think the > > existing TDM ISC could be re-used: > > > > Switching capability =3D TDM > > Encoding =3D OTN > > Max LSP BW (0-7) =3D max ODU rate at that priority > > Min LSP BW =3D min ODU rate > > > > (where rates are expressed in bytes per second) > > > > There would be one or more of these advertised, such that every ODU rat= e > > currently supported by the advertising node is advertised either > > explicitly or implicitly, by being within the range covered by a Min/Ma= x > > LSP BW pair. > > > > Thanks, > > > > John > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 11:36 AM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 > > > in ODU4) - while this may be the worst case, it is the possible case > > too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" = - > - > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > approach > > > than just creating new SwitchingTypes -- especially since the signals > > > supported within each of these is the same (e.g. an ODU1 over an ODU2 > is > > > the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > depth > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still no= t > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > > and > > > > it is highly desirable to adhere to the layer independent paradigm > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link t= o > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > > hierarchies and constrain LO connections to HO containers, one need= s > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link > > > of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to bette= r > > > > > align the work with 4202. Use of common approaches is of course > one > > > of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this point= . > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider > > > an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then w= e > > > > >> establish an ODU2 service over the link. At this point in time > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+= 4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > > >> How do we address this issue based on the approach specified in > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalen= t > > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit i= s > > > that > > > > >> the advertisement is TS size independent and hence will simplify > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Jul 8 13:48:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B353E3A67D0 for ; Thu, 8 Jul 2010 13:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIhZhbp5SfIu for ; Thu, 8 Jul 2010 13:48:32 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id B6B1F3A67B8 for ; Thu, 8 Jul 2010 13:48:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTDY5k4e5blQQOZe7n/spYytbEp1UYl5W@postini.com; Thu, 08 Jul 2010 13:48:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Jul 2010 13:43:41 -0700 From: John E Drake To: Igor Bryskin , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 13:43:39 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAAAAOw9wA== Message-ID: <5E893DB832F57341992548CDBB33316398438784AB@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:48:34 -0000 Igor, Even though I think you are making up requirements as you go, on behalf of = service providers to whom you have never spoken, I think that the scheme I = proposed would support what you are stipulating as a requirement without an= y trouble. By controlling the values of min/max LSP bandwidth that are advertised, one= can clearly see which links are ODU2, ODU3, etc., and route an LSP request= along only those links with the required granularity. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 1:30 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Jonathan, > > According to ITU-T each layer must have a separate routing instance, henc= e > ITU-T folks assume that it would be very awkward to model an OTN network > as a multi-layer network. > > IN GMPLS, however, we do not have such a limitation. it is OK to share a > routing instance between several layers and we can take advantage of this= . > With the multi-layer approach I suggest one can do everything what is > possible to do in a single-layer approach by constraining the routing to > all OTN layers. However. It gives certain flexibility in building OTN > hierarchies and constraining connections to desired levels of hierarchy, > which is not obvious how can be done within a single layer. > > Ypu wrote: > "Thus, for example, an ODU2 connection service request could be supported > by: OTU2 links (here the connection service rate is the same as the link > rate), a combination of OTU2 and OTU3 links, OTU3 links, etc." > > What if in the described scenario the operator wants to constrain or > prefer for a given ODU2 connections usage of only OTU2 links rather than > other possible combinations perhaps provisioned for different purposes? > > Cheers, > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 4:07 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > From the I-D under discussion: > > "While [G872-2001] considered the ODU as a set of layers in the same > way as SDH has been modeled, recent ITU-T OTN architecture progress > [G872-Am2] includes an agreement to model the ODU as a single layer > network with the bit rate as a parameter of links and connections. > This allows the links and nodes to be viewed in a single topology as > a common set of resources that are available to provide ODUj > connections independent of the value of j. Note that when the bit > rate of ODUj is less than the server bit rate, ODUj connections are > supported by HO-ODU (which has a one-to-one relationship with the > OTU)." > > "Therefore, this document only considers ODU layer for LO ODU connection > request." > > "GMPLS Routing [RFC4202] defines Interface Switching Capability Descripto= r > of TDM which can be used for ODU." > > "Thus, for example, an ODU2 connection service request could be supported > by: OTU2 links (here the connection service rate is the same as the link > rate), a combination of OTU2 and OTU3 links, OTU3 links, etc." > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:49 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > John, > > > > HO connections may make up a topology for LO connections. They may > require > > different planning and created in different time frame. Ergo it is > likely > > that an operator may want to route a service LO connection over topolog= y > > he prepared rather than over any OTN capable links. > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 3:10 PM > > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > You are arguing backwards from a capability that might or might not be > > needed. I don't recall seeing this requirement in any of the CCAMP OTN > > documents to date. > > > > I actually have the impression that the requirement is actually the > > opposite; viz, establish an LSP by whatever means. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 12:02 PM > > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > > Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > This won't allow an easy way to constrain a connection to a desired > > level > > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > > different levels, and what if an operator wants to constrain the > > > connection to a particular one? > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 2:51 PM > > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Igor, > > > > > > I suppose you could do that but it doesn't seem necessary. I think > the > > > existing TDM ISC could be re-used: > > > > > > Switching capability =3D TDM > > > Encoding =3D OTN > > > Max LSP BW (0-7) =3D max ODU rate at that priority > > > Min LSP BW =3D min ODU rate > > > > > > (where rates are expressed in bytes per second) > > > > > > There would be one or more of these advertised, such that every ODU > rate > > > currently supported by the advertising node is advertised either > > > explicitly or implicitly, by being within the range covered by a > Min/Max > > > LSP BW pair. > > > > > > Thanks, > > > > > > John > > > > -----Original Message----- > > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > > Sent: Thursday, July 08, 2010 11:36 AM > > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 i= n > > > ODU3 > > > > in ODU4) - while this may be the worst case, it is the possible cas= e > > > too. > > > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed= " > - > > - > > > > 400G?) the depth of the hierarchy will grow. > > > > > > > > This makes me wonder: wouldn't a generalized method be a better > > approach > > > > than just creating new SwitchingTypes -- especially since the > signals > > > > supported within each of these is the same (e.g. an ODU1 over an > ODU2 > > is > > > > the same as an ODU1 over an ODU3...) > > > > > > > > Jonathan Sadler > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 1:31 PM > > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth > > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > document > > > > > before we can embark on any proposals to the problem. I am still > not > > > > clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > plane, > > > > and > > > > > it is highly desirable to adhere to the layer independent paradig= m > > of > > > > > advertising of TE links, and there is no reason to invent an OTN > > > > specific > > > > > ISCD. The combination of Switching Capability and Encoding type o= f > > > > RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > OTN > > > > > hierarchies and constrain LO connections to HO containers, one > needs > > > to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in "draft= - > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > control > > > > > plane, no matter how you encode the routing information. For TDM > > > > networks, > > > > > you know the resource is allocated based on TS, so the available > TS > > > > should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, = I > > > think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will > > > > find > > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, > > > > > you have to advertise a new TE link or put this FA as a component > > link > > > > of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > gmpls- > > > > > g709-framework@tools.ietf.org > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > gmpls- > > > > > g709-framework@tools.ietf.org > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > better > > > > > > align the work with 4202. Use of common approaches is of cours= e > > one > > > > of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > the > > > > > > draft and discussion contributors on there progress on this > point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > > >> describes the link-parameters that are required for OTN servic= e > > > > routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, > > consider > > > > an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > > > >> establish an ODU2 service over the link. At this point in time > > the > > > > OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to > 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > over > > > > the > > > > > >> ODU2). So it is obvious from this example that the number of > > time- > > > > slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > ODU2). > > > > > >> How do we address this issue based on the approach specified i= n > > the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > number > > > of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to b= e > > > more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit > is > > > > that > > > > > >> the advertisement is TS size independent and hence will > simplify > > > the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Thu Jul 8 14:15:04 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490563A67B8 for ; Thu, 8 Jul 2010 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86avv1TDPFS0 for ; Thu, 8 Jul 2010 14:15:01 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 4398D3A6903 for ; Thu, 8 Jul 2010 14:15:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="1324604689" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 08 Jul 2010 21:15:03 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Thu, 8 Jul 2010 16:15:03 -0500 From: "Sadler, Jonathan B." To: Igor Bryskin , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 16:14:06 -0500 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAAAAZiD8A== Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5F9D@EX-NAP.tellabs-west.tellabsinc.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 21:15:04 -0000 Hi Igor, I beg to differ with your characterization about the ITU-T's standards. G.7715 (2002) and G.7715.1 (2003) recognize the benefit of having a single = routing instance carrying information about multiple layers (see G.7715 Sec= tion 5.2). What is required is link attribute information is defined per l= ayer (see G.7715.1 section 9.5). This allows variable adaptation (such as = found in SONET/SDH) to have a single advertisement, but provide different a= ttribute information for each layer (e.g. separate information for VT1.5/VC= 11, STS1/VC3, STS3c/VC4, STS12c/VC4-4c). It also enables separate routing = instances to be used per layer if the service provider/vendor chooses to do= so. The ITU-T has recently consented an amendment to G.8080 that defines a new = construct - the transitional link. A liaison about this has been sent by I= TU-T to IETF (see https://datatracker.ietf.org/liaison/910/). Transitional links enable the routing information being carried from differ= ent layers in a single instance to show the relationships where termination= /adaptation points exist. And it only works when a single routing instance= is used to carry information about multiple layers. If you're not familiar with the ITU-T's transitional link - think of it as = information similar to the IACD defined in the MLN/MRN solution RFCs. (The= re are some differences, but the intent is the same.) This transitional link construct is certainly applicable to G.709 (2009) ne= tworks, and can show the relationship for how an ODU1 would be routed over = various server layers (e.g. ODU1 over OTU1, ODU1 over ODU2 over OTU2, ODU1 = over ODU2 over ODU3 over OTU3, ...). Jonathan Sadler P.S. I didn't write the quote you included in your email... but the situati= on you describe isn't specific to OTN -- it would exist for any multi-layer= interaction. (e.g. lighting a lambda to satisfy a 2.5G demand). Again, a = technology agnostic solution would make more sense to me than one that is t= echnology specific. -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 3:30 PM To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Jonathan, According to ITU-T each layer must have a separate routing instance, hence = ITU-T folks assume that it would be very awkward to model an OTN network as= a multi-layer network. IN GMPLS, however, we do not have such a limitation. it is OK to share a ro= uting instance between several layers and we can take advantage of this. Wi= th the multi-layer approach I suggest one can do everything what is possibl= e to do in a single-layer approach by constraining the routing to all OTN l= ayers. However. It gives certain flexibility in building OTN hierarchies an= d constraining connections to desired levels of hierarchy, which is not obv= ious how can be done within a single layer. Ypu wrote: "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." What if in the described scenario the operator wants to constrain or prefer= for a given ODU2 connections usage of only OTU2 links rather than other po= ssible combinations perhaps provisioned for different purposes? Cheers, Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 08, 2010 4:07 PM To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, >From the I-D under discussion: "While [G872-2001] considered the ODU as a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-Am2] includes an agreement to model the ODU as a single layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO-ODU (which has a one-to-one relationship with the OTU)." "Therefore, this document only considers ODU layer for LO ODU connection re= quest." "GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor = of TDM which can be used for ODU." "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:49 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > HO connections may make up a topology for LO connections. They may requir= e > different planning and created in different time frame. Ergo it is likely > that an operator may want to route a service LO connection over topology > he prepared rather than over any OTN capable links. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 3:10 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > You are arguing backwards from a capability that might or might not be > needed. I don't recall seeing this requirement in any of the CCAMP OTN > documents to date. > > I actually have the impression that the requirement is actually the > opposite; viz, establish an LSP by whatever means. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:02 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > This won't allow an easy way to constrain a connection to a desired > level > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > different levels, and what if an operator wants to constrain the > > connection to a particular one? > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > I suppose you could do that but it doesn't seem necessary. I think the > > existing TDM ISC could be re-used: > > > > Switching capability =3D TDM > > Encoding =3D OTN > > Max LSP BW (0-7) =3D max ODU rate at that priority > > Min LSP BW =3D min ODU rate > > > > (where rates are expressed in bytes per second) > > > > There would be one or more of these advertised, such that every ODU rat= e > > currently supported by the advertising node is advertised either > > explicitly or implicitly, by being within the range covered by a Min/Ma= x > > LSP BW pair. > > > > Thanks, > > > > John > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 11:36 AM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 > > > in ODU4) - while this may be the worst case, it is the possible case > > too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" = - > - > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > approach > > > than just creating new SwitchingTypes -- especially since the signals > > > supported within each of these is the same (e.g. an ODU1 over an ODU2 > is > > > the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > depth > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still no= t > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > > and > > > > it is highly desirable to adhere to the layer independent paradigm > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link t= o > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > > hierarchies and constrain LO connections to HO containers, one need= s > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link > > > of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to bette= r > > > > > align the work with 4202. Use of common approaches is of course > one > > > of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this point= . > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider > > > an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then w= e > > > > >> establish an ODU2 service over the link. At this point in time > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+= 4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > > >> How do we address this issue based on the approach specified in > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalen= t > > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit i= s > > > that > > > > >> the advertisement is TS size independent and hence will simplify > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 14:19:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC7D3A6843 for ; Thu, 8 Jul 2010 14:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLU0BHxX7pSZ for ; Thu, 8 Jul 2010 14:19:51 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 230C93A67D0 for ; Thu, 8 Jul 2010 14:19:50 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68LJlKU022506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 23:19:48 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 23:19:48 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 17:19:45 -0400 From: Igor Bryskin To: John E Drake , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 17:19:38 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAAAAOw9wAAA0M3g Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E28F@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438784AB@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316398438784AB@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 21:19:53 -0000 John, You wrote:: " Even though I think you are making up requirements as you go, on behalf o= f service providers to whom you have never spoken" IB>> And how would you know that? By controlling the values of min/max LSP bandwidth that are advertised, one= can clearly see which links are ODU2, ODU3, etc., and route an LSP request= along only those links with the required granularity. IB>> No, you can not do this. In the example you described "OTU2 links, , a combination of OTU2 and OTU3 links, OTU3 links, etc." may advertise the= same value of min/max LSP bandwidth currently available on the links after= some resources are allocated. Besides, in a multi-layer GMPLS path computa= tion I'd like to constrain a computation to particular layer(s) in a univer= sal way (which is usually done by evaluating advertised switchcaps/encoding= type) without making any layer or technology specific considerations. Igor Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 1:30 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Jonathan, > > According to ITU-T each layer must have a separate routing instance, henc= e > ITU-T folks assume that it would be very awkward to model an OTN network > as a multi-layer network. > > IN GMPLS, however, we do not have such a limitation. it is OK to share a > routing instance between several layers and we can take advantage of this= . > With the multi-layer approach I suggest one can do everything what is > possible to do in a single-layer approach by constraining the routing to > all OTN layers. However. It gives certain flexibility in building OTN > hierarchies and constraining connections to desired levels of hierarchy, > which is not obvious how can be done within a single layer. > > Ypu wrote: > "Thus, for example, an ODU2 connection service request could be supported > by: OTU2 links (here the connection service rate is the same as the link > rate), a combination of OTU2 and OTU3 links, OTU3 links, etc." > > What if in the described scenario the operator wants to constrain or > prefer for a given ODU2 connections usage of only OTU2 links rather than > other possible combinations perhaps provisioned for different purposes? > > Cheers, > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 4:07 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > From the I-D under discussion: > > "While [G872-2001] considered the ODU as a set of layers in the same > way as SDH has been modeled, recent ITU-T OTN architecture progress > [G872-Am2] includes an agreement to model the ODU as a single layer > network with the bit rate as a parameter of links and connections. > This allows the links and nodes to be viewed in a single topology as > a common set of resources that are available to provide ODUj > connections independent of the value of j. Note that when the bit > rate of ODUj is less than the server bit rate, ODUj connections are > supported by HO-ODU (which has a one-to-one relationship with the > OTU)." > > "Therefore, this document only considers ODU layer for LO ODU connection > request." > > "GMPLS Routing [RFC4202] defines Interface Switching Capability Descripto= r > of TDM which can be used for ODU." > > "Thus, for example, an ODU2 connection service request could be supported > by: OTU2 links (here the connection service rate is the same as the link > rate), a combination of OTU2 and OTU3 links, OTU3 links, etc." > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:49 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > John, > > > > HO connections may make up a topology for LO connections. They may > require > > different planning and created in different time frame. Ergo it is > likely > > that an operator may want to route a service LO connection over topolog= y > > he prepared rather than over any OTN capable links. > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 3:10 PM > > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > You are arguing backwards from a capability that might or might not be > > needed. I don't recall seeing this requirement in any of the CCAMP OTN > > documents to date. > > > > I actually have the impression that the requirement is actually the > > opposite; viz, establish an LSP by whatever means. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 12:02 PM > > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > > Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > This won't allow an easy way to constrain a connection to a desired > > level > > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > > different levels, and what if an operator wants to constrain the > > > connection to a particular one? > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 2:51 PM > > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Igor, > > > > > > I suppose you could do that but it doesn't seem necessary. I think > the > > > existing TDM ISC could be re-used: > > > > > > Switching capability =3D TDM > > > Encoding =3D OTN > > > Max LSP BW (0-7) =3D max ODU rate at that priority > > > Min LSP BW =3D min ODU rate > > > > > > (where rates are expressed in bytes per second) > > > > > > There would be one or more of these advertised, such that every ODU > rate > > > currently supported by the advertising node is advertised either > > > explicitly or implicitly, by being within the range covered by a > Min/Max > > > LSP BW pair. > > > > > > Thanks, > > > > > > John > > > > -----Original Message----- > > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > > Sent: Thursday, July 08, 2010 11:36 AM > > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 i= n > > > ODU3 > > > > in ODU4) - while this may be the worst case, it is the possible cas= e > > > too. > > > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed= " > - > > - > > > > 400G?) the depth of the hierarchy will grow. > > > > > > > > This makes me wonder: wouldn't a generalized method be a better > > approach > > > > than just creating new SwitchingTypes -- especially since the > signals > > > > supported within each of these is the same (e.g. an ODU1 over an > ODU2 > > is > > > > the same as an ODU1 over an ODU3...) > > > > > > > > Jonathan Sadler > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 1:31 PM > > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth > > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > document > > > > > before we can embark on any proposals to the problem. I am still > not > > > > clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > plane, > > > > and > > > > > it is highly desirable to adhere to the layer independent paradig= m > > of > > > > > advertising of TE links, and there is no reason to invent an OTN > > > > specific > > > > > ISCD. The combination of Switching Capability and Encoding type o= f > > > > RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > OTN > > > > > hierarchies and constrain LO connections to HO containers, one > needs > > > to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in "draft= - > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > control > > > > > plane, no matter how you encode the routing information. For TDM > > > > networks, > > > > > you know the resource is allocated based on TS, so the available > TS > > > > should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, = I > > > think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will > > > > find > > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, > > > > > you have to advertise a new TE link or put this FA as a component > > link > > > > of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > gmpls- > > > > > g709-framework@tools.ietf.org > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > gmpls- > > > > > g709-framework@tools.ietf.org > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > better > > > > > > align the work with 4202. Use of common approaches is of cours= e > > one > > > > of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > the > > > > > > draft and discussion contributors on there progress on this > point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > > >> describes the link-parameters that are required for OTN servic= e > > > > routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, > > consider > > > > an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > > > >> establish an ODU2 service over the link. At this point in time > > the > > > > OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to > 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > over > > > > the > > > > > >> ODU2). So it is obvious from this example that the number of > > time- > > > > slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > ODU2). > > > > > >> How do we address this issue based on the approach specified i= n > > the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > number > > > of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to b= e > > > more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit > is > > > > that > > > > > >> the advertisement is TS size independent and hence will > simplify > > > the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 14:37:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9100F3A6978 for ; Thu, 8 Jul 2010 14:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEr5XJBOuwxh for ; Thu, 8 Jul 2010 14:37:15 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id AC3C73A696B for ; Thu, 8 Jul 2010 14:35:34 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68LYx59010218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Jul 2010 23:34:59 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Jul 2010 23:34:59 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 17:34:56 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 17:34:53 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAAAAZiD8AAA5ofQ Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E298@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5F9D@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5F9D@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 21:37:39 -0000 Hi Jonathan, Thanks for this information. My understanding of ITU-T standards is clearly= outdated. You wrote: "Again, a technology agnostic solution would make more sense to me than one= that is technology specific" But this is exactly the point of my suggestion: constraining the routing to= particular layer(s) just by looking at the the advertised switchcaps/encod= ing type pairs. How is that not a technology agnostic solution? In our mult= i-layer implementation we are using this approach to separate WDM, generic = sub-lambda, OTN and Ethernet layers already. Thanks, Igor -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 5:14 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor, I beg to differ with your characterization about the ITU-T's standards. G.7715 (2002) and G.7715.1 (2003) recognize the benefit of having a single = routing instance carrying information about multiple layers (see G.7715 Sec= tion 5.2). What is required is link attribute information is defined per l= ayer (see G.7715.1 section 9.5). This allows variable adaptation (such as = found in SONET/SDH) to have a single advertisement, but provide different a= ttribute information for each layer (e.g. separate information for VT1.5/VC= 11, STS1/VC3, STS3c/VC4, STS12c/VC4-4c). It also enables separate routing = instances to be used per layer if the service provider/vendor chooses to do= so. The ITU-T has recently consented an amendment to G.8080 that defines a new = construct - the transitional link. A liaison about this has been sent by I= TU-T to IETF (see https://datatracker.ietf.org/liaison/910/). Transitional links enable the routing information being carried from differ= ent layers in a single instance to show the relationships where termination= /adaptation points exist. And it only works when a single routing instance= is used to carry information about multiple layers. If you're not familiar with the ITU-T's transitional link - think of it as = information similar to the IACD defined in the MLN/MRN solution RFCs. (The= re are some differences, but the intent is the same.) This transitional link construct is certainly applicable to G.709 (2009) ne= tworks, and can show the relationship for how an ODU1 would be routed over = various server layers (e.g. ODU1 over OTU1, ODU1 over ODU2 over OTU2, ODU1 = over ODU2 over ODU3 over OTU3, ...). Jonathan Sadler P.S. I didn't write the quote you included in your email... but the situati= on you describe isn't specific to OTN -- it would exist for any multi-layer= interaction. (e.g. lighting a lambda to satisfy a 2.5G demand). Again, a = technology agnostic solution would make more sense to me than one that is t= echnology specific. -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 3:30 PM To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Jonathan, According to ITU-T each layer must have a separate routing instance, hence = ITU-T folks assume that it would be very awkward to model an OTN network as= a multi-layer network. IN GMPLS, however, we do not have such a limitation. it is OK to share a ro= uting instance between several layers and we can take advantage of this. Wi= th the multi-layer approach I suggest one can do everything what is possibl= e to do in a single-layer approach by constraining the routing to all OTN l= ayers. However. It gives certain flexibility in building OTN hierarchies an= d constraining connections to desired levels of hierarchy, which is not obv= ious how can be done within a single layer. Ypu wrote: "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." What if in the described scenario the operator wants to constrain or prefer= for a given ODU2 connections usage of only OTU2 links rather than other po= ssible combinations perhaps provisioned for different purposes? Cheers, Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 08, 2010 4:07 PM To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, >From the I-D under discussion: "While [G872-2001] considered the ODU as a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-Am2] includes an agreement to model the ODU as a single layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO-ODU (which has a one-to-one relationship with the OTU)." "Therefore, this document only considers ODU layer for LO ODU connection re= quest." "GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor = of TDM which can be used for ODU." "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:49 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > HO connections may make up a topology for LO connections. They may requir= e > different planning and created in different time frame. Ergo it is likely > that an operator may want to route a service LO connection over topology > he prepared rather than over any OTN capable links. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 3:10 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > You are arguing backwards from a capability that might or might not be > needed. I don't recall seeing this requirement in any of the CCAMP OTN > documents to date. > > I actually have the impression that the requirement is actually the > opposite; viz, establish an LSP by whatever means. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:02 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > This won't allow an easy way to constrain a connection to a desired > level > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > different levels, and what if an operator wants to constrain the > > connection to a particular one? > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > I suppose you could do that but it doesn't seem necessary. I think the > > existing TDM ISC could be re-used: > > > > Switching capability =3D TDM > > Encoding =3D OTN > > Max LSP BW (0-7) =3D max ODU rate at that priority > > Min LSP BW =3D min ODU rate > > > > (where rates are expressed in bytes per second) > > > > There would be one or more of these advertised, such that every ODU rat= e > > currently supported by the advertising node is advertised either > > explicitly or implicitly, by being within the range covered by a Min/Ma= x > > LSP BW pair. > > > > Thanks, > > > > John > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 11:36 AM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 > > > in ODU4) - while this may be the worst case, it is the possible case > > too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" = - > - > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > approach > > > than just creating new SwitchingTypes -- especially since the signals > > > supported within each of these is the same (e.g. an ODU1 over an ODU2 > is > > > the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > depth > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still no= t > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > > and > > > > it is highly desirable to adhere to the layer independent paradigm > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link t= o > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > > hierarchies and constrain LO connections to HO containers, one need= s > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link > > > of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to bette= r > > > > > align the work with 4202. Use of common approaches is of course > one > > > of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this point= . > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider > > > an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then w= e > > > > >> establish an ODU2 service over the link. At this point in time > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+= 4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > > >> How do we address this issue based on the approach specified in > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalen= t > > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit i= s > > > that > > > > >> the advertisement is TS size independent and hence will simplify > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Jul 8 14:41:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6982E3A681F for ; Thu, 8 Jul 2010 14:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhCE6OXlhZLp for ; Thu, 8 Jul 2010 14:41:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4EBCD3A6807 for ; Thu, 8 Jul 2010 14:41:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTDZF/dZQsPfQwu7Y0w5i6gGlpryWo0JH@postini.com; Thu, 08 Jul 2010 14:41:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 8 Jul 2010 14:40:50 -0700 From: John E Drake To: Igor Bryskin , "Sadler, Jonathan B." , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 14:40:47 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAAAAOw9wAAA0M3gAAEsa3A= Message-ID: <5E893DB832F57341992548CDBB333163984387850D@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438784AB@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E28F@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E28F@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 21:41:56 -0000 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 2:20 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > You wrote:: > > " Even though I think you are making up requirements as you go, on behalf > of service providers to whom you have never spoken" > > IB>> And how would you know that? [JD] Everything you have been mentioning as a requirement runs counter to what t= he existing OTN I-Ds, Jonathan's explanation of ITU modeling, etc. are sayi= ng, and I haven't seen anyone express any agreement with you. > > By controlling the values of min/max LSP bandwidth that are advertised, > one can clearly see which links are ODU2, ODU3, etc., and route an LSP > request along only those links with the required granularity. > > IB>> No, you can not do this. In the example you described "OTU2 links, > , a combination of OTU2 and OTU3 links, OTU3 links, etc." may advertise > the same value of min/max LSP bandwidth currently available on the links > after some resources are allocated. Besides, in a multi-layer GMPLS path > computation I'd like to constrain a computation to particular layer(s) in > a universal way (which is usually done by evaluating advertised > switchcaps/encoding type) without making any layer or technology specific > considerations. [JD] We will see. I know this won't mean anything to you, but switching capabil= ity has a very specific meaning and it isn't network layer indicator. > > Igor > > > Thanks, > > John > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 1:30 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Jonathan, > > > > According to ITU-T each layer must have a separate routing instance, > hence > > ITU-T folks assume that it would be very awkward to model an OTN networ= k > > as a multi-layer network. > > > > IN GMPLS, however, we do not have such a limitation. it is OK to share = a > > routing instance between several layers and we can take advantage of > this. > > With the multi-layer approach I suggest one can do everything what is > > possible to do in a single-layer approach by constraining the routing t= o > > all OTN layers. However. It gives certain flexibility in building OTN > > hierarchies and constraining connections to desired levels of hierarchy= , > > which is not obvious how can be done within a single layer. > > > > Ypu wrote: > > "Thus, for example, an ODU2 connection service request could be > supported > > by: OTU2 links (here the connection service rate is the same as the lin= k > > rate), a combination of OTU2 and OTU3 links, OTU3 links, etc." > > > > What if in the described scenario the operator wants to constrain or > > prefer for a given ODU2 connections usage of only OTU2 links rather tha= n > > other possible combinations perhaps provisioned for different purposes? > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 4:07 PM > > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > From the I-D under discussion: > > > > "While [G872-2001] considered the ODU as a set of layers in the same > > way as SDH has been modeled, recent ITU-T OTN architecture progress > > [G872-Am2] includes an agreement to model the ODU as a single layer > > network with the bit rate as a parameter of links and connections. > > This allows the links and nodes to be viewed in a single topology as > > a common set of resources that are available to provide ODUj > > connections independent of the value of j. Note that when the bit > > rate of ODUj is less than the server bit rate, ODUj connections are > > supported by HO-ODU (which has a one-to-one relationship with the > > OTU)." > > > > "Therefore, this document only considers ODU layer for LO ODU connectio= n > > request." > > > > "GMPLS Routing [RFC4202] defines Interface Switching Capability > Descriptor > > of TDM which can be used for ODU." > > > > "Thus, for example, an ODU2 connection service request could be > supported > > by: OTU2 links (here the connection service rate is the same as the lin= k > > rate), a combination of OTU2 and OTU3 links, OTU3 links, etc." > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 12:49 PM > > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > > Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > John, > > > > > > HO connections may make up a topology for LO connections. They may > > require > > > different planning and created in different time frame. Ergo it is > > likely > > > that an operator may want to route a service LO connection over > topology > > > he prepared rather than over any OTN capable links. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 3:10 PM > > > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > > Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Igor, > > > > > > You are arguing backwards from a capability that might or might not b= e > > > needed. I don't recall seeing this requirement in any of the CCAMP > OTN > > > documents to date. > > > > > > I actually have the impression that the requirement is actually the > > > opposite; viz, establish an LSP by whatever means. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Thursday, July 08, 2010 12:02 PM > > > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai > Zhang; > > > Lou > > > > Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > This won't allow an easy way to constrain a connection to a desired > > > level > > > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported > by > > > > different levels, and what if an operator wants to constrain the > > > > connection to a particular one? > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 2:51 PM > > > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai > Zhang; > > > Lou > > > > Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > I suppose you could do that but it doesn't seem necessary. I think > > the > > > > existing TDM ISC could be re-used: > > > > > > > > Switching capability =3D TDM > > > > Encoding =3D OTN > > > > Max LSP BW (0-7) =3D max ODU rate at that priority > > > > Min LSP BW =3D min ODU rate > > > > > > > > (where rates are expressed in bytes per second) > > > > > > > > There would be one or more of these advertised, such that every ODU > > rate > > > > currently supported by the advertising node is advertised either > > > > explicitly or implicitly, by being within the range covered by a > > Min/Max > > > > LSP BW pair. > > > > > > > > Thanks, > > > > > > > > John > > > > > -----Original Message----- > > > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > > > Sent: Thursday, July 08, 2010 11:36 AM > > > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lo= u > > > > Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > in > > > > ODU3 > > > > > in ODU4) - while this may be the worst case, it is the possible > case > > > > too. > > > > > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > speed" > > - > > > - > > > > > 400G?) the depth of the hierarchy will grow. > > > > > > > > > > This makes me wonder: wouldn't a generalized method be a better > > > approach > > > > > than just creating new SwitchingTypes -- especially since the > > signals > > > > > supported within each of these is the same (e.g. an ODU1 over an > > ODU2 > > > is > > > > > the same as an ODU1 over an ODU3...) > > > > > > > > > > Jonathan Sadler > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 1:31 PM > > > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > I think OTN links require more than one switchcaps: as many as th= e > > > depth > > > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > > /*****/ > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > > Of > > > > > > Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document > > > > > > before we can embark on any proposals to the problem. I am stil= l > > not > > > > > clear > > > > > > why do we have to deviate from the general approach that has > been > > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > plane, > > > > > and > > > > > > it is highly desirable to adhere to the layer independent > paradigm > > > of > > > > > > advertising of TE links, and there is no reason to invent an OT= N > > > > > specific > > > > > > ISCD. The combination of Switching Capability and Encoding type > of > > > > > RFC4202 > > > > > > ISCD allows for specifying both multiplexing capabilities and > OTN > > > > layer > > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > > have > > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE- > link > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > OTN > > > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to > > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > other > > > > > > interested experts, and we think the proposal described in > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible > > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > control > > > > > > plane, no matter how you encode the routing information. For TD= M > > > > > networks, > > > > > > you know the resource is allocated based on TS, so the availabl= e > > TS > > > > > should > > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information= , > I > > > > think > > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), yo= u > > > will > > > > > find > > > > > > that one of your suggestions is adopted (i.e., simply advertize > > the > > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > > ODU1, > > > > > > you have to advertise a new TE link or put this FA as a > component > > > link > > > > > of > > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: >; ccamp- > > > > gmpls- > > > > > > g709-framework@tools.ietf.org g709- > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp= - > > > gmpls- > > > > > > g709-framework@tools.ietf.org g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > better > > > > > > > align the work with 4202. Use of common approaches is of > course > > > one > > > > > of > > > > > > > the main objectives of *C*CAMP. I look forward to hearing > from > > > the > > > > > > > draft and discussion contributors on there progress on this > > point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > > >> describes the link-parameters that are required for OTN > service > > > > > routing > > > > > > >> purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > ODUj > > > > > > >> availability within a higher-order container. For example, > > > consider > > > > > an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > then > > we > > > > > > >> establish an ODU2 service over the link. At this point in > time > > > the > > > > > OTU3 > > > > > > >> link has 12 time-slots available for ODU2 services and up to > > 12+4 > > > > > > >> time-slots available for ODU1 services (4 ODU1s are containe= d > > > over > > > > > the > > > > > > >> ODU2). So it is obvious from this example that the number of > > > time- > > > > > slots > > > > > > >> available is different based on the signal-type (i.e. ODU1 > and > > > > ODU2). > > > > > > >> How do we address this issue based on the approach specified > in > > > the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the available > > > number > > > > of > > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > equivalent > > > > > > >> bandwidth in bytes/sec within a link? This approach seems to > be > > > > more > > > > > > >> in-line with the general approach outlined in RFC-4202. Refe= r > > to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > being > > > > > > >> advertised per VC rate for an SDH link. The additional > benefit > > is > > > > > that > > > > > > >> the advertisement is TS size independent and hence will > > simplify > > > > the > > > > > > >> implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> CCAMP mailing list > > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > > CCAMP mailing list > > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Thu Jul 8 15:07:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01B93A68B8 for ; Thu, 8 Jul 2010 15:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2S9qnnMhHfY for ; Thu, 8 Jul 2010 15:07:34 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 4FCD83A681F for ; Thu, 8 Jul 2010 15:07:34 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Thu, 8 Jul 2010 15:07:11 -0700 From: Snigdho Bardalai To: Igor Bryskin , "Sadler, Jonathan B." , John E Drake , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 15:07:47 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeAAAAcENAAABxFkAAAJ3WAAAbK1sA= Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:07:36 -0000 Igor, It is not clear why are you requiring the constraint for a connection to ta= ke a specific level in the hierarchy end-to-end? Is it a hardware specific = issue you are trying to address? Snigdho > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: Thursday, July 08, 2010 11:58 AM > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > >If that is the case how can you constraint a connection to a >specific > hierarchy end-to-end? > > You don't have to. You MAY constrain a connection to take, for example, > only LO links. But you can also allow the connection to take either HO > or LO links. Also, keep in mind that GMPLS allows to advertise OTN link > to belong to more than one OTN layer. > > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 2:51 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > That means that the signal can be at different hierarchies over > different OTN links along the route. > > If that is the case how can you constraint a connection to a specific > hierarchy end-to-end? I think all you can do is find an OTN link that > can support the required signal-type. > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 11:46 AM > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Because the same signal (and connection) could be on a different > > hierarchy level. > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Thursday, July 08, 2010 2:44 PM > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Why not simply create switching capability descriptors per hierarchy > > (i.e. ODU0, ODU1,...)? > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 11:40 AM > > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai > Zhang; > > > Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > There is a lot of swcaps available :=3D) > > > Separate swcaps provide an easy way to constrain connection to a > > > desired level of hierarchy. > > > > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 2:36 PM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > in > > > ODU3 in ODU4) - while this may be the worst case, it is the > possible > > > case too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > speed" > > -- > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > > > approach than just creating new SwitchingTypes -- especially since > > the > > > signals supported within each of these is the same (e.g. an ODU1 > over > > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > document > > > > before we can embark on any proposals to the problem. I am still > > not > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > plane, > > > and > > > > it is highly desirable to adhere to the layer independent > paradigm > > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type > of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available > TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > > > link of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > one of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > the > > > > > draft and discussion contributors on there progress on this > > point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > > > consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > we > > > > >> establish an ODU2 service over the link. At this point in time > > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to > > 12+4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > number > > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > equivalent > > > > >> bandwidth in bytes/sec within a link? This approach seems to > be > > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit > > is > > > that > > > > >> the advertisement is TS size independent and hence will > simplify > > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jul 8 15:16:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9620B3A698B for ; Thu, 8 Jul 2010 15:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+cdm5gGwy7c for ; Thu, 8 Jul 2010 15:16:01 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 3370A3A6948 for ; Thu, 8 Jul 2010 15:16:01 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o68MFx2I001687 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 9 Jul 2010 00:15:59 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Jul 2010 00:15:59 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 8 Jul 2010 18:15:56 -0400 From: Igor Bryskin To: Snigdho Bardalai , "Sadler, Jonathan B." , John E Drake , Fatai Zhang , Lou Berger Date: Thu, 8 Jul 2010 18:15:54 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeAAAAcENAAABxFkAAAJ3WAAAbK1sAAAEmEUA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:16:03 -0000 No, just network policies and planning. Cheers, Igor -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: Thursday, July 08, 2010 6:08 PM To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou Berge= r Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, It is not clear why are you requiring the constraint for a connection to ta= ke a specific level in the hierarchy end-to-end? Is it a hardware specific = issue you are trying to address? Snigdho > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: Thursday, July 08, 2010 11:58 AM > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > >If that is the case how can you constraint a connection to a >specific > hierarchy end-to-end? > > You don't have to. You MAY constrain a connection to take, for example, > only LO links. But you can also allow the connection to take either HO > or LO links. Also, keep in mind that GMPLS allows to advertise OTN link > to belong to more than one OTN layer. > > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 2:51 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > That means that the signal can be at different hierarchies over > different OTN links along the route. > > If that is the case how can you constraint a connection to a specific > hierarchy end-to-end? I think all you can do is find an OTN link that > can support the required signal-type. > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 11:46 AM > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Because the same signal (and connection) could be on a different > > hierarchy level. > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Thursday, July 08, 2010 2:44 PM > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Why not simply create switching capability descriptors per hierarchy > > (i.e. ODU0, ODU1,...)? > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 11:40 AM > > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai > Zhang; > > > Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > There is a lot of swcaps available :=3D) > > > Separate swcaps provide an easy way to constrain connection to a > > > desired level of hierarchy. > > > > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 2:36 PM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > in > > > ODU3 in ODU4) - while this may be the worst case, it is the > possible > > > case too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > speed" > > -- > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > > > approach than just creating new SwitchingTypes -- especially since > > the > > > signals supported within each of these is the same (e.g. an ODU1 > over > > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > document > > > > before we can embark on any proposals to the problem. I am still > > not > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > plane, > > > and > > > > it is highly desirable to adhere to the layer independent > paradigm > > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type > of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available > TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > > > link of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > one of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > the > > > > > draft and discussion contributors on there progress on this > > point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > > > consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > we > > > > >> establish an ODU2 service over the link. At this point in time > > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to > > 12+4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > number > > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > equivalent > > > > >> bandwidth in bytes/sec within a link? This approach seems to > be > > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit > > is > > > that > > > > >> the advertisement is TS size independent and hence will > simplify > > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Fri Jul 9 01:25:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F06C3A67D3 for ; Fri, 9 Jul 2010 01:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSh6ArlqoOhF for ; Fri, 9 Jul 2010 01:25:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 01CCB3A67A3 for ; Fri, 9 Jul 2010 01:25:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-dd-4c36dd124dfe Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.7E.10125.21DD63C4; Fri, 9 Jul 2010 10:25:55 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jul 2010 10:25:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 10:25:30 +0200 Message-ID: In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAALFeAAAAcENAAABxFkAAAJ3WAAAbK1sAAAEmEUAAVD1+g References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com><4C349F23.5040301@labn.net><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com><07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86 B09@SV-E XDB1.infiner a.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> From: "Daniele Ceccarelli" To: "Igor Bryskin" , "Snigdho Bardalai" , "Sadler, Jonathan B." , "John E Drake" , "Fatai Zhang" , "Lou Berger" X-OriginalArrivalTime: 09 Jul 2010 08:25:32.0844 (UTC) FILETIME=[4C496EC0:01CB1F40] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 08:25:55 -0000 All, We tried analize if the the ISCD was enough to meet ITU requirements, if = it needed to be modified, replaced or whatever. The result of our = analysis has been translated into an info-model draft: http://tools.ietf.org/id/draft-bccg-ccamp-otn-g709-info-model-01.txt. Each requirement has been considered and a reason why it can be = addressed via RFC4202 or not has been given. Could you please send your = comments about it?=20 Many thanks and BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Igor Bryskin Sent: venerd=EC 9 luglio 2010 0.16 To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; = Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt No, just network policies and planning. Cheers, Igor -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: Thursday, July 08, 2010 6:08 PM To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou = Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, It is not clear why are you requiring the constraint for a connection to = take a specific level in the hierarchy end-to-end? Is it a hardware = specific issue you are trying to address? Snigdho > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = > Of Igor Bryskin > Sent: Thursday, July 08, 2010 11:58 AM > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang;=20 > Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > >If that is the case how can you constraint a connection to a=20 > >>specific > hierarchy end-to-end? > > You don't have to. You MAY constrain a connection to take, for=20 > example, only LO links. But you can also allow the connection to take=20 > either HO or LO links. Also, keep in mind that GMPLS allows to=20 > advertise OTN link to belong to more than one OTN layer. > > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 2:51 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou=20 > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > That means that the signal can be at different hierarchies over=20 > different OTN links along the route. > > If that is the case how can you constraint a connection to a specific=20 > hierarchy end-to-end? I think all you can do is find an OTN link that=20 > can support the required signal-type. > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 11:46 AM > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai=20 > > Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Because the same signal (and connection) could be on a different=20 > > hierarchy level. > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Thursday, July 08, 2010 2:44 PM > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang;=20 > > Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Why not simply create switching capability descriptors per hierarchy = > > (i.e. ODU0, ODU1,...)? > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 11:40 AM > > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai > Zhang; > > > Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > There is a lot of swcaps available :=3D) Separate swcaps provide = an=20 > > > easy way to constrain connection to a desired level of hierarchy. > > > > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 2:36 PM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou = > > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > in > > > ODU3 in ODU4) - while this may be the worst case, it is the > possible > > > case too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > speed" > > -- > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better=20 > > > approach than just creating new SwitchingTypes -- especially since > > the > > > signals supported within each of these is the same (e.g. an ODU1 > over > > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-=20 > > > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the = > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ = /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > document > > > > before we can embark on any proposals to the problem. I am still > > not > > > clear > > > > why do we have to deviate from the general approach that has = been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > plane, > > > and > > > > it is highly desirable to adhere to the layer independent > paradigm > > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type > of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and = OTN > > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new = TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple = problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and = other > > > > interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available > TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a = component > > > link of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; = > > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > one of > > > > > the main objectives of *C*CAMP. I look forward to hearing = from > > the > > > > > draft and discussion contributors on there progress on this > > point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order = ODUj > > > > >> availability within a higher-order container. For example, > > > consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and = then > > we > > > > >> establish an ODU2 service over the link. At this point in = time > > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to > > 12+4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 = and > > > ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > number > > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > equivalent > > > > >> bandwidth in bytes/sec within a link? This approach seems to > be > > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs = being > > > > >> advertised per VC rate for an SDH link. The additional = benefit > > is > > > that > > > > >> the advertisement is TS size independent and hence will > simplify > > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Fri Jul 9 01:45:20 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4B63A693A for ; Fri, 9 Jul 2010 01:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN9E4HGKdiDe for ; Fri, 9 Jul 2010 01:45:19 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id A9E503A67EC for ; Fri, 9 Jul 2010 01:45:17 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o698Lu4o025120 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jul 2010 10:45:12 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 9 Jul 2010 10:45:06 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin Date: Fri, 9 Jul 2010 10:45:04 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAbL9Yw Message-ID: References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 08:45:20 -0000 Hi Igor, We are on the same page here, this is the reason in CH. 5.3 of the framewor= k of the requirement=20 - Support for differentiating between link multiplexing capacity and link r= ate capacity Best Regards sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: gioved=EC 8 luglio 2010 21.49 A: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou Be= rger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t John, HO connections may make up a topology for LO connections. They may require = different planning and created in different time frame. Ergo it is likely t= hat an operator may want to route a service LO connection over topology he = prepared rather than over any OTN capable links. -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 3:10 PM To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, You are arguing backwards from a capability that might or might not be need= ed. I don't recall seeing this requirement in any of the CCAMP OTN documen= ts to date. I actually have the impression that the requirement is actually the opposit= e; viz, establish an LSP by whatever means. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:02 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > This won't allow an easy way to constrain a connection to a desired level > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > different levels, and what if an operator wants to constrain the > connection to a particular one? >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 2:51 PM > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Igor, >=20 > I suppose you could do that but it doesn't seem necessary. I think the > existing TDM ISC could be re-used: >=20 > Switching capability =3D TDM > Encoding =3D OTN > Max LSP BW (0-7) =3D max ODU rate at that priority > Min LSP BW =3D min ODU rate >=20 > (where rates are expressed in bytes per second) >=20 > There would be one or more of these advertised, such that every ODU rate > currently supported by the advertising node is advertised either > explicitly or implicitly, by being within the range covered by a Min/Max > LSP BW pair. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > Sent: Thursday, July 08, 2010 11:36 AM > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > ODU3 > > in ODU4) - while this may be the worst case, it is the possible case > too. > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" -- > > 400G?) the depth of the hierarchy will grow. > > > > This makes me wonder: wouldn't a generalized method be a better approac= h > > than just creating new SwitchingTypes -- especially since the signals > > supported within each of these is the same (e.g. an ODU1 over an ODU2 i= s > > the same as an ODU1 over an ODU3...) > > > > Jonathan Sadler > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 1:31 PM > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > I think OTN links require more than one switchcaps: as many as the dept= h > > of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework docume= nt > > > before we can embark on any proposals to the problem. I am still not > > clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, > > and > > > it is highly desirable to adhere to the layer independent paradigm of > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > ISCD. The combination of Switching Capability and Encoding type of > > RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > OTN > > > hierarchies and constrain LO connections to HO containers, one needs > to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for contro= l > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > you know the resource is allocated based on TS, so the available TS > > should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will > > find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, > > > you have to advertise a new TE link or put this FA as a component lin= k > > of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to better > > > > align the work with 4202. Use of common approaches is of course on= e > > of > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > draft and discussion contributors on there progress on this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, conside= r > > an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > >> establish an ODU2 service over the link. At this point in time the > > OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained over > > the > > > >> ODU2). So it is obvious from this example that the number of time- > > slots > > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > > >> How do we address this issue based on the approach specified in th= e > > > draft? > > > >> > > > >> My other question is why not simply advertize the available number > of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be > more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit is > > that > > > >> the advertisement is TS size independent and hence will simplify > the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Fri Jul 9 02:08:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB113A6B9A for ; Fri, 9 Jul 2010 02:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW5jwnRnnfqa for ; Fri, 9 Jul 2010 02:08:28 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 784093A6B96 for ; Fri, 9 Jul 2010 02:08:27 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6996PUF023161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jul 2010 11:08:25 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 9 Jul 2010 11:08:08 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin , "Sadler, Jonathan B." Date: Fri, 9 Jul 2010 11:08:06 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdA Message-ID: References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 09:08:30 -0000 Hi Igor, Jonathan, I tent to agree with Jonathan. The nature of signals in the different possible chains in the OTN hierarchi= es is the same . My understanding of Switching Cap is that different Switch= ing Cap would be linked to different technologies imply different switching= capabilities : we have not created different Switching Cap for VC4 or VC1= 2 in SDH.=20 Best Regards sergio Best Regards Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: gioved=EC 8 luglio 2010 20.40 A: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Be= rger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Fri Jul 9 02:45:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B103A68AF for ; Fri, 9 Jul 2010 02:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.315 X-Spam-Level: * X-Spam-Status: No, score=1.315 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj5tQtCZxkgq for ; Fri, 9 Jul 2010 02:45:09 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9A0B63A6870 for ; Fri, 9 Jul 2010 02:45:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5A002W4AZLB8@szxga05-in.huawei.com> for ccamp@ietf.org; Fri, 09 Jul 2010 17:42:57 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5A00LJ9AZJUM@szxga05-in.huawei.com> for ccamp@ietf.org; Fri, 09 Jul 2010 17:42:56 +0800 (CST) Received: from Z41162C ([10.70.76.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5A007EBAZJWJ@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 09 Jul 2010 17:42:55 +0800 (CST) Date: Fri, 09 Jul 2010 17:42:55 +0800 From: Fatai Zhang To: Igor Bryskin , Snigdho Bardalai , "Sadler, Jonathan B." , John E Drake , Lou Berger Message-id: <0fdd01cb1f4b$1b913320$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_iHgPpmT1wkTQ/2vsDApcQg)" X-Priority: 3 X-MSMail-priority: Normal References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> Cc: ccamp@ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 09:45:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iHgPpmT1wkTQ/2vsDApcQg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgSWdvciBhbmQgYWxsLA0KDQpJIHRoaW5rIHdlIGFyZSBhdCB0aGUgc2FtZSBsaW5lIGFib3V0 IHRoZSByZXF1cmVtZW50IG9mIG5ldHdvcmsgcG9saWN5IGFuZCBwbGFubmluZy4gRm9yIHRyYW5z cG9ydCBuZXR3b3JrcywgdGhlIHR1bm5lbHMgZm9yIHRyYW5zcG9ydGluZyBzZXJ2aWNlIHVzdWFs bHkgc2hvdWxkIGJlIHBsYW5lZCB1bmRlciBzb21lIHBvbGljeS4gVGhlcmVmb3JlLCB3ZSBtYXkg bmVlZCB0byBkaWZmZXJlbnRpYXRlIGZ1bGwgbGFtYmRhIExTUCBvciBzdWIgbGFtYmRhIExTUCB3 aGVuIGNyZWF0aW5nIGEgY29ubmVjdGlvbi4gV2Ugd291bGQgbGlrZSB0byByZWZsZWN0IHRoZSBy ZXF1aXJlbWVudCBtdWNoIGNsZWFyZXIgaW4gdGhlIEZXSyBkb2N1bWVudC4NCg0KSG93ZXZlciwg dG8gbWVldCB0aGUgcmVxdWlybWVudCwgSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgbWF5YmUgd2Ug ZG9uJ3QgbmVlZCB0byBleHRlbmQgSVNDIHR5cGUuIEZvciBleGFtcGxlLCBMbyBPRFUsIEhvIE9E VSwgU0hPIE9EVSwgdGhleSBhcmUgcmVsYXRpdmUgdG8gZWFjaCBvdGhlci4gRm9yIGV4YW1wbGUs IE9EVTEtPk9EVTItPk9EVTMtPk9EVTQsIGhvdyB0byByZWdhcmQgT0RVMiBvciBPRFUzIGFzIEhv IE9UTiBMZXZlbCBvciBMbyBPVE4gTGV2ZWw/IEFub3RoZXIgZXhhbXBsZSBpcywgaWYgdGhlcmUg aXMgYSBPVFUzIGxpbmsgc3VwcG9ydGluZyBPRFUyIHN3aXRjaGluZywgd2hpY2ggY2FuIGJlIHVz ZWQgYXMgTG8gT0RVMiAoc2VydmljZSBvdmVyIE9EVTIgZGlyZWN0bHkpIGFuZCBIbyBPRFUyIChP RFUxIGlzIG92ZXIgdGhpcyBPRFUyKSwgaW4gdGhpcyBjYXNlLCBob3cgdG8gZGlmZmVyZW50aWF0 ZSBpZiB0aGlzIE9EVTIgaXMgTG8gT1ROIExldmVsIG9yIEhvIE9UTiBMZXZlbD8NCg0KQW5vdGhl ciBwb2ludCBpcyBhYm91dCB3aHkgdGhlIGV4aXN0aW5nIElTQ0QgaXMgbm90IGNvbXBldGVudC4g DQoNCldlIGFsbCBrbm93IHRoZSBoaXN0b3J5IG9mIHRoZSBHTVBMUywgd2hpY2ggaXMgaW5oZXJp dGVkIGZyb20gTVBMUy4gIEluIE1QTFMgbmV0d29ya3MsIHdlIGNhbiBvbmx5IHVzZSBmbG9hdGlu ZyBwb2ludCBudW1iZXIgdG8gaWRlbnRpZnkgdGhlIGJhbmR3aWR0aC4gSG93ZXZlciwgZm9yIHRo ZSBURE0gbmV0d29yaywgdGhlIHJlc291cmNlIGlzIGFsbG9hY3RlZCBiYXNlZCBvbiB0aGUgVFMs IHNvIGl0IGlzIHZlcnkgbmF0dXJhbGx5IHRvIHVzZSBUUyAob3IgcGVyIHNpZ25hbCB0eXBlKSB0 byBlbmNvZGUgdGhlIGJhbmR3aWR0aC4gSWYgd2UgdXNlIHRoZSBmbG9hdGluZyBwb2ludCBudW1i ZXIsIHRoZSByb3V0aW5nIHN0aWxsIG5lZWQgdG8gY29udmVydCB0aGUgZmxvYXRpbmcgcG9pbnQg dG8gc2VlIGhvdyBtYW55IFRTIG9yIHNpZ25hbCAoT0RVaykgY2FuIGJlIHN1cHBvcnRlZCB0byBj cmVhdGUgdGhlIGNvbm5lY3Rpb25zLiBTZWNvbmRseSwgaWYgd2UgdXNlIHRoZSBleGlzdGluZyBJ U0NEICh3ZSBqdXN0IGFkdmVydGlzZSBNYXggTFNQIGJhbmR3aWR0aCAoZS5nLiwgT0RVNCkgYW5k IE1pbiBMU1AgYmFuZHdpZHRoIChPRFUxKSwgaG93IHRvIGtub3cgd2hldGhlciBpdCBjYW4gc3Vw cG9ydCBPRFVmbGV4OyBIb3cgdG8ga25vdyBpZiBpdCBjYW4gc3VwcG9ydCBPRFUyIGFuZCBPRFUz IGlmIHRoZSBlcXVpcG1lbnRzIG1heSBoYXZlIHNvbWUgY29uc3RyYWl0cy4gVGhpcmRseSwgaW4g VERNIG5ldHdvcmtzLCBpdCBpcyBub3QgZWZmaWNpZW50IGZvciBzY2FsYWJpbGl0eSBpc3N1ZSBp ZiB3ZSB1c2UgdGhlIGV4aXN0aW5nIElTQ0QsIGJlY2F1c2UgaXQgbmVlZHMgMzIgYml0cyB0byBp bmRpY2F0ZSB0aGUgYmFuZHdpZHRoIChBY3R1YWxseSwgd2Ugb25seSBuZWVkIG11Y2ggZmV3ZXIg Yml0cyB0byBpZGVudGlmeSB0aGUgc2lnbmFsIHR5cGUgKGUuZy4sIE9EVWspKS4NCg0KSG9wZSB0 aGlzIGNhbiBjbGFyaWZ5IHlvdXIgY29uY2Vybi4NCg0KDQoNCg0KQmVzdCBSZWdhcmRzDQogDQpG YXRhaQ0KIA0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJJZ29yIEJyeXNr aW4iIDxJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20+DQpUbzogIlNuaWdkaG8gQmFyZGFsYWkiIDxT QmFyZGFsYWlAaW5maW5lcmEuY29tPjsgIlNhZGxlciwgSm9uYXRoYW4gQi4iIDxKb25hdGhhbi5T YWRsZXJAdGVsbGFicy5jb20+OyAiSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIubmV0Pjsg IkZhdGFpIFpoYW5nIiA8emhhbmdmYXRhaUBodWF3ZWkuY29tPjsgIkxvdSBCZXJnZXIiIDxsYmVy Z2VyQGxhYm4ubmV0Pg0KQ2M6IDxjY2FtcEBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLWc3MDktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPg0KU2VudDogRnJpZGF5LCBKdWx5IDA5 LCAyMDEwIDY6MTUgQU0NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0KDQpObywganVzdCBuZXR3b3Jr IHBvbGljaWVzIGFuZCBwbGFubmluZy4NCg0KQ2hlZXJzLA0KSWdvcg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogU25pZ2RobyBCYXJkYWxhaSBbbWFpbHRvOlNCYXJkYWxhaUBp bmZpbmVyYS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCA2OjA4IFBNDQpUbzog SWdvciBCcnlza2luOyBTYWRsZXIsIEpvbmF0aGFuIEIuOyBKb2huIEUgRHJha2U7IEZhdGFpIFpo YW5nOyBMb3UgQmVyZ2VyDQpDYzogY2NhbXBAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbQ0NBTVBdIENv bW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0K SWdvciwNCg0KSXQgaXMgbm90IGNsZWFyIHdoeSBhcmUgeW91IHJlcXVpcmluZyB0aGUgY29uc3Ry YWludCBmb3IgYSBjb25uZWN0aW9uIHRvIHRha2UgYSBzcGVjaWZpYyBsZXZlbCBpbiB0aGUgaGll cmFyY2h5IGVuZC10by1lbmQ/IElzIGl0IGEgaGFyZHdhcmUgc3BlY2lmaWMgaXNzdWUgeW91IGFy ZSB0cnlpbmcgdG8gYWRkcmVzcz8NCg0KU25pZ2Robw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgSWdvciBCcnlza2luDQo+IFNlbnQ6IFRodXJz ZGF5LCBKdWx5IDA4LCAyMDEwIDExOjU4IEFNDQo+IFRvOiBTbmlnZGhvIEJhcmRhbGFpOyBTYWRs ZXIsIEpvbmF0aGFuIEIuOyBKb2huIEUgRHJha2U7IEZhdGFpIFpoYW5nOw0KPiBMb3UgQmVyZ2Vy DQo+IENjOiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiBm cmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBv biBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLQ0KPiAwMS50eHQNCj4NCj4g PklmIHRoYXQgaXMgdGhlIGNhc2UgaG93IGNhbiB5b3UgY29uc3RyYWludCBhIGNvbm5lY3Rpb24g dG8gYSA+c3BlY2lmaWMNCj4gaGllcmFyY2h5IGVuZC10by1lbmQ/DQo+DQo+IFlvdSBkb24ndCBo YXZlIHRvLiBZb3UgTUFZIGNvbnN0cmFpbiBhIGNvbm5lY3Rpb24gdG8gdGFrZSwgZm9yIGV4YW1w bGUsDQo+IG9ubHkgTE8gbGlua3MuIEJ1dCB5b3UgY2FuIGFsc28gYWxsb3cgdGhlIGNvbm5lY3Rp b24gdG8gdGFrZSBlaXRoZXIgSE8NCj4gb3IgTE8gbGlua3MuIEFsc28sIGtlZXAgaW4gbWluZCB0 aGF0IEdNUExTIGFsbG93cyB0byBhZHZlcnRpc2UgT1ROIGxpbmsNCj4gdG8gYmVsb25nIHRvIG1v cmUgdGhhbiBvbmUgT1ROIGxheWVyLg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBTbmlnZGhvIEJhcmRhbGFpIFttYWlsdG86U0JhcmRhbGFpQGluZmluZXJhLmNv bV0NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMjo1MSBQTQ0KPiBUbzogSWdvciBC cnlza2luOyBTYWRsZXIsIEpvbmF0aGFuIEIuOyBKb2huIEUgRHJha2U7IEZhdGFpIFpoYW5nOyBM b3UNCj4gQmVyZ2VyDQo+IENjOiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nNzA5LQ0KPiBmcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtDQ0FN UF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLQ0KPiAw MS50eHQNCj4NCj4gVGhhdCBtZWFucyB0aGF0IHRoZSBzaWduYWwgY2FuIGJlIGF0IGRpZmZlcmVu dCBoaWVyYXJjaGllcyBvdmVyDQo+IGRpZmZlcmVudCBPVE4gbGlua3MgYWxvbmcgdGhlIHJvdXRl Lg0KPg0KPiBJZiB0aGF0IGlzIHRoZSBjYXNlIGhvdyBjYW4geW91IGNvbnN0cmFpbnQgYSBjb25u ZWN0aW9uIHRvIGEgc3BlY2lmaWMNCj4gaGllcmFyY2h5IGVuZC10by1lbmQ/IEkgdGhpbmsgYWxs IHlvdSBjYW4gZG8gaXMgZmluZCBhbiBPVE4gbGluayB0aGF0DQo+IGNhbiBzdXBwb3J0IHRoZSBy ZXF1aXJlZCBzaWduYWwtdHlwZS4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0N Cj4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAxMTo0NiBBTQ0KPiA+IFRvOiBTbmln ZGhvIEJhcmRhbGFpOyBTYWRsZXIsIEpvbmF0aGFuIEIuOyBKb2huIEUgRHJha2U7IEZhdGFpIFpo YW5nOw0KPiA+IExvdSBCZXJnZXINCj4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtZzcwOS0NCj4gPiBmcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0N Cj4gZnJhbWV3b3JrLQ0KPiA+IDAxLnR4dA0KPiA+DQo+ID4gQmVjYXVzZSB0aGUgc2FtZSBzaWdu YWwgKGFuZCBjb25uZWN0aW9uKSBjb3VsZCBiZSBvbiBhIGRpZmZlcmVudA0KPiA+IGhpZXJhcmNo eSBsZXZlbC4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog U25pZ2RobyBCYXJkYWxhaSBbbWFpbHRvOlNCYXJkYWxhaUBpbmZpbmVyYS5jb21dDQo+ID4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMjo0NCBQTQ0KPiA+IFRvOiBJZ29yIEJyeXNraW47 IFNhZGxlciwgSm9uYXRoYW4gQi47IEpvaG4gRSBEcmFrZTsgRmF0YWkgWmhhbmc7IExvdQ0KPiA+ IEJlcmdlcg0KPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1n NzA5LQ0KPiA+IGZyYW1ld29ya0B0b29scy5pZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbQ0NB TVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiBmcmFtZXdvcmst DQo+ID4gMDEudHh0DQo+ID4NCj4gPiBXaHkgbm90IHNpbXBseSBjcmVhdGUgc3dpdGNoaW5nIGNh cGFiaWxpdHkgZGVzY3JpcHRvcnMgcGVyIGhpZXJhcmNoeQ0KPiA+IChpLmUuIE9EVTAsIE9EVTEs Li4uKT8NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206 IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NCj4gPiA+IFNl bnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDExOjQwIEFNDQo+ID4gPiBUbzogU2FkbGVyLCBK b25hdGhhbiBCLjsgSm9obiBFIERyYWtlOyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaQ0KPiBaaGFu ZzsNCj4gPiA+IExvdSBCZXJnZXINCj4gPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4gZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnDQo+ID4g PiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt ZzcwOS0NCj4gPiBmcmFtZXdvcmstDQo+ID4gPiAwMS50eHQNCj4gPiA+DQo+ID4gPiBUaGVyZSBp cyBhIGxvdCBvZiBzd2NhcHMgYXZhaWxhYmxlIDo9KQ0KPiA+ID4gU2VwYXJhdGUgc3djYXBzIHBy b3ZpZGUgYW4gZWFzeSB3YXkgdG8gY29uc3RyYWluIGNvbm5lY3Rpb24gdG8gYQ0KPiA+ID4gZGVz aXJlZCBsZXZlbCBvZiBoaWVyYXJjaHkuDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+IEZyb206IFNhZGxlciwgSm9uYXRoYW4gQi4gW21haWx0bzpKb25hdGhh bi5TYWRsZXJAdGVsbGFicy5jb21dDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAx MCAyOjM2IFBNDQo+ID4gPiBUbzogSWdvciBCcnlza2luOyBKb2huIEUgRHJha2U7IFNuaWdkaG8g QmFyZGFsYWk7IEZhdGFpIFpoYW5nOyBMb3UNCj4gPiA+IEJlcmdlcg0KPiA+ID4gQ2M6IGNjYW1w QGlldGYub3JnOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiBmcmFtZXdvcmtA dG9vbHMuaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+IGZyYW1ld29yay0NCj4gPiA+IDAxLnR4dA0K PiA+ID4NCj4gPiA+IEZvciB0aGUgZXhpc3RpbmcgaGllcmFyY2h5LCB0aGF0IHdvdWxkIGJlIDUg KE9EVTAgaW4gT0RVMSBpbiBPRFUyDQo+IGluDQo+ID4gPiBPRFUzIGluIE9EVTQpIC0gd2hpbGUg dGhpcyBtYXkgYmUgdGhlIHdvcnN0IGNhc2UsIGl0IGlzIHRoZQ0KPiBwb3NzaWJsZQ0KPiA+ID4g Y2FzZSB0b28uDQo+ID4gPg0KPiA+ID4gQXMgbmV3IHNpZ25hbHMvcmF0ZXMgYXJlIGFkZGVkIChl LmcuIE9EVTUgZm9yICJ0aGUgbmV4dCBncmVhdA0KPiBzcGVlZCINCj4gPiAtLQ0KPiA+ID4gNDAw Rz8pIHRoZSBkZXB0aCBvZiB0aGUgaGllcmFyY2h5IHdpbGwgZ3Jvdy4NCj4gPiA+DQo+ID4gPiBU aGlzIG1ha2VzIG1lIHdvbmRlcjogd291bGRuJ3QgYSBnZW5lcmFsaXplZCBtZXRob2QgYmUgYSBi ZXR0ZXINCj4gPiA+IGFwcHJvYWNoIHRoYW4ganVzdCBjcmVhdGluZyBuZXcgU3dpdGNoaW5nVHlw ZXMgLS0gZXNwZWNpYWxseSBzaW5jZQ0KPiA+IHRoZQ0KPiA+ID4gc2lnbmFscyBzdXBwb3J0ZWQg d2l0aGluIGVhY2ggb2YgdGhlc2UgaXMgdGhlIHNhbWUgKGUuZy4gYW4gT0RVMQ0KPiBvdmVyDQo+ ID4gPiBhbiBPRFUyIGlzIHRoZSBzYW1lIGFzIGFuIE9EVTEgb3ZlciBhbiBPRFUzLi4uKQ0KPiA+ ID4NCj4gPiA+IEpvbmF0aGFuIFNhZGxlcg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYNCj4gPiA+IE9mIElnb3IgQnJ5c2tp bg0KPiA+ID4gU2VudDogVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMTozMSBQTQ0KPiA+ID4gVG86 IEpvaG4gRSBEcmFrZTsgU25pZ2RobyBCYXJkYWxhaTsgRmF0YWkgWmhhbmc7IExvdSBCZXJnZXIN Cj4gPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0K PiA+ID4gZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW0NDQU1Q XSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiBmcmFtZXdvcmst DQo+ID4gPiAwMS50eHQNCj4gPiA+DQo+ID4gPiBJIHRoaW5rIE9UTiBsaW5rcyByZXF1aXJlIG1v cmUgdGhhbiBvbmUgc3dpdGNoY2FwczogYXMgbWFueSBhcyB0aGUNCj4gPiA+IGRlcHRoIG9mIHRo ZSBkZWVwZXN0IHBvc3NpYmxlIE9UTiBEUCBoaWVyYXJjaHksIGZvciBleGFtcGxlOg0KPiA+ID4N Cj4gPiA+IHR5cGVkZWYgZW51bQ0KPiA+ID4gew0KPiA+ID4gICAgTFNQU3dpdGNoVHlwZV9Vbmtu b3duID0wICAgICAgICAgICAgLyogVW5rbm93biAqLw0KPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBl X1BTQ18xID0xICAgICAgICAgICAgLyogUFNDLTEgKi8NCj4gPiA+ICAgICwgTFNQU3dpdGNoVHlw ZV9QU0NfMiA9MiAgICAgICAgICAgIC8qIFBTQy0yICovDQo+ID4gPiAgICAsIExTUFN3aXRjaFR5 cGVfUFNDXzMgPTMgICAgICAgICAgICAvKiBQU0MtMyAqLw0KPiA+ID4gICAgLCBMU1BTd2l0Y2hU eXBlX1BTQ180ID00ICAgICAgICAgICAgLyogUFNDLTQgKi8NCj4gPiA+ICAgICwgTFNQU3dpdGNo VHlwZV9MMlNDICA9NTAgICAgICAgICAgIC8qIEwyU0MgKi8NCj4gPiA+ICAgICwgTFNQU3dpdGNo VHlwZV9URE0gICA9MTAwICAgICAgICAgIC8qIFRETSAqLw0KPiA+ID4NCj4gPiA+IC8qKioqKi8N Cj4gPiA+ICAgICwgTFNQU3dpdGNoVHlwZV9PVE5fTE89MTI0ICAgLyogT1ROIGxvdyBvcmRlciAq Lw0KPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX09UTl9ITz0xMjUgICAvKiBPVE4gaGlnaCBvcmRl ciAqLw0KPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX09UTl9TSE89MTI2ICAvKiBPVE4gc3VwZXIg aGlnaCBvcmRlciAqLw0KPiA+ID4gLyoqKioqLw0KPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX0xT QyAgID0xNTAgICAgICAgICAgLyogTFNDICovDQo+ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfRlND ICAgPTIwMCAgICAgICAgICAvKiBGU0MgKi8NCj4gPiA+IH1lX0xTUFN3aXRjaFR5cGU7DQo+ID4g Pg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBK b2huIEUgRHJha2UgW21haWx0bzpqZHJha2VAanVuaXBlci5uZXRdDQo+ID4gPiBTZW50OiBUaHVy c2RheSwgSnVseSAwOCwgMjAxMCAxOjU5IFBNDQo+ID4gPiBUbzogSWdvciBCcnlza2luOyBTbmln ZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91IEJlcmdlcg0KPiA+ID4gQ2M6IGNjYW1wQGll dGYub3JnOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiBmcmFtZXdvcmtAdG9v bHMuaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+IGZyYW1ld29yay0NCj4gPiA+IDAxLnR4dA0KPiA+ ID4NCj4gPiA+IFdoYXQgZG8geW91IG1lYW4gYnkgImRpZmZlcmVudCBzd2l0Y2hjYXBzIj8NCj4g PiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0K PiA+ID4gQmVoYWxmIE9mDQo+ID4gPiA+IElnb3IgQnJ5c2tpbg0KPiA+ID4gPiBTZW50OiBUaHVy c2RheSwgSnVseSAwOCwgMjAxMCAxMDo1MyBBTQ0KPiA+ID4gPiBUbzogU25pZ2RobyBCYXJkYWxh aTsgRmF0YWkgWmhhbmc7IExvdSBCZXJnZXINCj4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnOyBk cmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiBmcmFtZXdvcmtAdG9vbHMuaWV0Zi5v cmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLWc3MDktDQo+ID4gPiBmcmFtZXdvcmstDQo+ID4gPiA+IDAxLnR4dA0KPiA+ID4g Pg0KPiA+ID4gPiBTbmlnZGhvLA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiDYICBJIHRoaW5rIHdlIG5lZWQgdG8gc29ydCBvdXQgdGhlIGlzc3Vl cyB3aXRoIHRoZSBmcmFtZXdvcmsNCj4gPiBkb2N1bWVudA0KPiA+ID4gPiBiZWZvcmUgd2UgY2Fu IGVtYmFyayBvbiBhbnkgcHJvcG9zYWxzIHRvIHRoZSBwcm9ibGVtLiBJIGFtIHN0aWxsDQo+ID4g bm90DQo+ID4gPiBjbGVhcg0KPiA+ID4gPiB3aHkgZG8gd2UgaGF2ZSB0byBkZXZpYXRlIGZyb20g dGhlIGdlbmVyYWwgYXBwcm9hY2ggdGhhdCBoYXMgYmVlbg0KPiA+ID4gPiBlc3RhYmxpc2hlZCBp biBSRkMgNDIwMi4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gSUI+PiBBZ3Jl ZSBhYnNvbHV0ZWx5LiBHTVBMUyBpcyBpbmhlcmVudGx5IG11bHRpLWxheWVyIGNvbnRyb2wNCj4g PiBwbGFuZSwNCj4gPiA+IGFuZA0KPiA+ID4gPiBpdCBpcyBoaWdobHkgZGVzaXJhYmxlIHRvIGFk aGVyZSB0byB0aGUgbGF5ZXIgaW5kZXBlbmRlbnQNCj4gcGFyYWRpZ20NCj4gPiBvZg0KPiA+ID4g PiBhZHZlcnRpc2luZyBvZiBURSBsaW5rcywgYW5kIHRoZXJlIGlzIG5vIHJlYXNvbiB0byBpbnZl bnQgYW4gT1RODQo+ID4gPiBzcGVjaWZpYw0KPiA+ID4gPiBJU0NELiBUaGUgY29tYmluYXRpb24g b2YgU3dpdGNoaW5nIENhcGFiaWxpdHkgYW5kIEVuY29kaW5nIHR5cGUNCj4gb2YNCj4gPiA+IFJG QzQyMDINCj4gPiA+ID4gSVNDRCBhbGxvd3MgZm9yIHNwZWNpZnlpbmcgYm90aCBtdWx0aXBsZXhp bmcgY2FwYWJpbGl0aWVzIGFuZCBPVE4NCj4gPiA+IGxheWVyDQo+ID4gPiA+IChMTywgSE8sIFNI Tykgb2YgYW4gT1ROIGxpbmssIGFuZCwgaWYgdGhpcyBub3Qgc3VmZmljaWVudCwgeW91DQo+IGhh dmUNCj4gPiA+ID4gYW5vdGhlciByZXNlcnZlZCAxNiBiaXRzLg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiA+QWRkaXRpb25hbGx5LCBJIGRvIG5vdCBzZWUgYW55IHJlYXNvbiB0 byBhZHZlcnRpc2UgYSBuZXcgVEUtbGluaw0KPiA+IHRvDQo+ID4gPiA+IHJlcHJlc2VudCA+dGhl IGxvdy1vcmRlciBPRFVqIGJhbmR3aWR0aCB3aXRoaW4gdGhlIGhpZ2gtb3JkZXINCj4gPiA+IGNv bnRhaW5lcnMuDQo+ID4gPiA+IFRoaXMgaXMgc2ltcGx5ID5ibG93aW5nIHVwIHRoZSBzb2x1dGlv biB0byBhIHZlcnkgc2ltcGxlIHByb2JsZW0uDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+IElCPj4gSGVyZSBJIGRpc2FncmVlLiBJbiBvcmRlciB0byBnaXZlIGEgdXNlciBwb3Nz aWJpbGl0eSB0bw0KPiBjcmVhdGUNCj4gPiA+IE9UTg0KPiA+ID4gPiBoaWVyYXJjaGllcyBhbmQg Y29uc3RyYWluIExPIGNvbm5lY3Rpb25zIHRvIEhPIGNvbnRhaW5lcnMsIG9uZQ0KPiA+IG5lZWRz DQo+ID4gPiB0bw0KPiA+ID4gPiBhZHZlcnRpc2UgT1ROIGxpbmtzIHdpdGggZGlmZmVyZW50IHN3 aXRjaGNhcHMuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IENoZWVycywNCj4g PiA+ID4NCj4gPiA+ID4gSWdvcg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBS ZWdhcmRzDQo+ID4gPiA+DQo+ID4gPiA+IFNuaWdkaG8NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+ID4gRnJvbTogRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5j b21dDQo+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCA2OjMzIFBNDQo+ID4g PiA+IFRvOiBTbmlnZGhvIEJhcmRhbGFpOyBMb3UgQmVyZ2VyDQo+ID4gPiA+IENjOiBjY2FtcEBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4gZnJhbWV3b3JrQHRv b2xzLmlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4gZnJhbWV3b3JrLQ0KPiA+ID4gPiAwMS50 eHQNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gSGkgU25pZ2RobyBhbmQgTG91 LA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBZZXMsIHdlIGhhdmUgbG90cyBv ZiBvZmYtbGluZSBkaXNjdXNzaW9ucyBhbW9uZyBhdXRob3JzIGFuZCBvdGhlcg0KPiA+ID4gPiBp bnRlcmVzdGVkIGV4cGVydHMsIGFuZCB3ZSB0aGluayB0aGUgcHJvcG9zYWwgZGVzY3JpYmVkIGlu DQo+ICJkcmFmdC0NCj4gPiA+ID4gY2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDkiIFtP U1BGLUVuY29kaW5nXSBkcmFmdCBpcyBtb3JlDQo+ID4gPiBmZWFzaWJsZQ0KPiA+ID4gPiBmb3Ig T1ROIG5ldHdvcmtzLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgZnJh bWV3b3JrIGRyYWZ0IGp1c3QgdGVsbHMgeW91IHdoYXQgaW5mb3JtYXRpb24gbmVlZGVkIGZvcg0K PiA+ID4gY29udHJvbA0KPiA+ID4gPiBwbGFuZSwgbm8gbWF0dGVyIGhvdyB5b3UgZW5jb2RlIHRo ZSByb3V0aW5nIGluZm9ybWF0aW9uLiBGb3IgVERNDQo+ID4gPiBuZXR3b3JrcywNCj4gPiA+ID4g eW91IGtub3cgdGhlIHJlc291cmNlIGlzIGFsbG9jYXRlZCBiYXNlZCBvbiBUUywgc28gdGhlIGF2 YWlsYWJsZQ0KPiBUUw0KPiA+ID4gc2hvdWxkDQo+ID4gPiA+IGJlIGdldCBvciBpbmR1Y2VkIGJl Zm9yZSBjcmVhdGluZyBjcm9zcy1jb25uZWN0Lg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiBJZiB5b3UgYXJlIHRyeWluZyB0byBmaW5kIGhvdyB0byBlbmNvZGUgdGhlIHJvdXRp bmcgaW5mb3JtYXRpb24sDQo+IEkNCj4gPiA+IHRoaW5rDQo+ID4gPiA+IHlvdSBuZWVkIGdvIHRv IHRoZSByb3V0aW5nIGRyYWZ0cyAoaW5mbyBtb2RlbCBhbmQgZW5jb2RpbmcpLg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBJZiB5b3UgbG9vayBhdCB0aGUgcm91dGluZyBkcmFm dHMgKGluZm8gbW9kZWwgYW5kIGVuY29kaW5nKSwgeW91DQo+ID4gd2lsbA0KPiA+ID4gZmluZA0K PiA+ID4gPiB0aGF0IG9uZSBvZiB5b3VyIHN1Z2dlc3Rpb25zIGlzIGFkb3B0ZWQgKGkuZS4sIHNp bXBseSBhZHZlcnRpemUNCj4gdGhlDQo+ID4gPiA+IGF2YWlsYWJsZSBudW1iZXIgb2YgT0RVMCwg T0RVMSwgT0RVMiwgLi4uLCBPRFU0IGNvbnRhaW5lcg0KPiA+IGluc3RhbmNlcykuDQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IE9uZSBtb3JlIHRoaW5nIGZvciB5b3VyIGZpcnN0 IGNvbW1lbnQ6DQo+ID4gPiA+DQo+ID4gPiA+IElmIHlvdSBjcmVhdGUgYW4gT0RVMiBMU1AgKHVz dWFsbHkgb3ZlciBtdWx0aSBPVFUzIGxpbmtzKSBhcyBGQQ0KPiBmb3INCj4gPiA+IE9EVTEsDQo+ ID4gPiA+IHlvdSBoYXZlIHRvIGFkdmVydGlzZSBhIG5ldyBURSBsaW5rIG9yIHB1dCB0aGlzIEZB IGFzIGEgY29tcG9uZW50DQo+ID4gPiBsaW5rIG9mDQo+ID4gPiA+IGFuIGV4aXN0aW5nIFRFIGxp bmsgKGxpa2UgUkZDNDIwNmJpcykuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEJlc3QgUmVnYXJkcw0KPiA+ID4gPg0KPiA+ID4g PiBGYXRhaQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQo+ID4gPiA+DQo+ID4gPiA+IEZyb206ICJTbmlnZGhvIEJhcmRhbGFpIiA8U0JhcmRh bGFpQGluZmluZXJhLmNvbQ0KPiA+ID4gPiA8bWFpbHRvOlNCYXJkYWxhaUBpbmZpbmVyYS5jb20+ ID4NCj4gPiA+ID4NCj4gPiA+ID4gVG86ICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldCA8 bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+ID4NCj4gPiA+ID4NCj4gPiA+ID4gQ2M6IDxjY2FtcEBp ZXRmLm9yZyA8bWFpbHRvOmNjYW1wQGlldGYub3JnPiA+OyA8ZHJhZnQtaWV0Zi1jY2FtcC0NCj4g PiA+IGdtcGxzLQ0KPiA+ID4gPiBnNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZyA8bWFpbHRv OmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtDQo+IGc3MDktDQo+ID4gPiA+IGZyYW1ld29ya0B0b29s cy5pZXRmLm9yZz4gPg0KPiA+ID4gPg0KPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDcs IDIwMTAgMTE6NDMgUE0NCj4gPiA+ID4NCj4gPiA+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29t bWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiBmcmFtZXdvcmstDQo+ ID4gPiA+IDAxLnR4dA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IEhpIExv dQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzLCBJIGFsc28gd291bGQgbGlrZSB0byBoZWFy IGFib3V0IHRoZSBzYW1lLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU25pZ2Robw0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBM b3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4gPiA+ID4gPiBTZW50OiBXZWRu ZXNkYXksIEp1bHkgMDcsIDIwMTAgODozNyBBTQ0KPiA+ID4gPiA+IFRvOiBTbmlnZGhvIEJhcmRh bGFpDQo+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ IDsgZHJhZnQtaWV0Zi1jY2FtcC0NCj4gPiA+IGdtcGxzLQ0KPiA+ID4gPiBnNzA5LWZyYW1ld29y a0B0b29scy5pZXRmLm9yZyA8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtDQo+IGc3MDkt DQo+ID4gPiA+IGZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4NCj4gPiA+ID4gPiBTdWJqZWN0OiBS ZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ IGZyYW1ld29yay0NCj4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTbmlnZGhv LA0KPiA+ID4gPiA+IEkgYmVsaWV2ZSB0aGVyZSBoYXMgYmVlbiBzb21lIG9mZi1saW5lIGRpc2N1 c3Npb24gb24gaG93IHRvDQo+ID4gYmV0dGVyDQo+ID4gPiA+ID4gYWxpZ24gdGhlIHdvcmsgd2l0 aCA0MjAyLiAgVXNlIG9mIGNvbW1vbiBhcHByb2FjaGVzIGlzIG9mDQo+IGNvdXJzZQ0KPiA+ID4g b25lIG9mDQo+ID4gPiA+ID4gdGhlIG1haW4gb2JqZWN0aXZlcyBvZiAqQypDQU1QLiAgSSBsb29r IGZvcndhcmQgdG8gaGVhcmluZyBmcm9tDQo+ID4gdGhlDQo+ID4gPiA+ID4gZHJhZnQgYW5kIGRp c2N1c3Npb24gY29udHJpYnV0b3JzIG9uIHRoZXJlIHByb2dyZXNzIG9uIHRoaXMNCj4gPiBwb2lu dC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IExvdQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gNy82 LzIwMTAgMzo1OSBQTSwgU25pZ2RobyBCYXJkYWxhaSB3cm90ZToNCj4gPiA+ID4gPj4gSGVsbG8s DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEkgaGF2ZSBhIGNvbW1lbnQgYW5kIGEgcXVlc3Rpb24g b24gU2VjdGlvbiAzLjEuMi4xLiBUaGlzDQo+IHNlY3Rpb24NCj4gPiA+ID4gPj4gZGVzY3JpYmVz IHRoZSBsaW5rLXBhcmFtZXRlcnMgdGhhdCBhcmUgcmVxdWlyZWQgZm9yIE9UTg0KPiBzZXJ2aWNl DQo+ID4gPiByb3V0aW5nDQo+ID4gPiA+ID4+IHB1cnBvc2VzLg0KPiA+ID4gPiA+Pg0KPiA+ID4g PiA+PiBNeSBjb21tZW50IGlzIGhvdyBhcmUgd2UgZ29pbmcgdG8gYWR2ZXJ0aXNlIHRoZSBsb3ct b3JkZXIgT0RVag0KPiA+ID4gPiA+PiBhdmFpbGFiaWxpdHkgd2l0aGluIGEgaGlnaGVyLW9yZGVy IGNvbnRhaW5lci4gRm9yIGV4YW1wbGUsDQo+ID4gPiBjb25zaWRlciBhbg0KPiA+ID4gPiA+PiBP VFUzIGxpbmsgd2hpY2ggaGFzIDE2IHRpbWUtc2xvdHMgb2YgMi41RyBncmFudWxhcml0eSBhbmQg dGhlbg0KPiA+IHdlDQo+ID4gPiA+ID4+IGVzdGFibGlzaCBhbiBPRFUyIHNlcnZpY2Ugb3ZlciB0 aGUgbGluay4gQXQgdGhpcyBwb2ludCBpbiB0aW1lDQo+ID4gdGhlDQo+ID4gPiBPVFUzDQo+ID4g PiA+ID4+IGxpbmsgaGFzIDEyIHRpbWUtc2xvdHMgYXZhaWxhYmxlIGZvciBPRFUyIHNlcnZpY2Vz IGFuZCB1cCB0bw0KPiA+IDEyKzQNCj4gPiA+ID4gPj4gdGltZS1zbG90cyBhdmFpbGFibGUgZm9y IE9EVTEgc2VydmljZXMgKDQgT0RVMXMgYXJlIGNvbnRhaW5lZA0KPiA+IG92ZXINCj4gPiA+IHRo ZQ0KPiA+ID4gPiA+PiBPRFUyKS4gU28gaXQgaXMgb2J2aW91cyBmcm9tIHRoaXMgZXhhbXBsZSB0 aGF0IHRoZSBudW1iZXIgb2YNCj4gPiB0aW1lLQ0KPiA+ID4gc2xvdHMNCj4gPiA+ID4gPj4gYXZh aWxhYmxlIGlzIGRpZmZlcmVudCBiYXNlZCBvbiB0aGUgc2lnbmFsLXR5cGUgKGkuZS4gT0RVMSBh bmQNCj4gPiA+IE9EVTIpLg0KPiA+ID4gPiA+PiBIb3cgZG8gd2UgYWRkcmVzcyB0aGlzIGlzc3Vl IGJhc2VkIG9uIHRoZSBhcHByb2FjaCBzcGVjaWZpZWQNCj4gaW4NCj4gPiA+IHRoZQ0KPiA+ID4g PiBkcmFmdD8NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gTXkgb3RoZXIgcXVlc3Rpb24gaXMgd2h5 IG5vdCBzaW1wbHkgYWR2ZXJ0aXplIHRoZSBhdmFpbGFibGUNCj4gPiBudW1iZXINCj4gPiA+IG9m DQo+ID4gPiA+ID4+IE9EVTAsIE9EVTEsIE9EVTIsIC4uLiwgT0RVNCBjb250YWluZXIgaW5zdGFu Y2VzIG9yIHRoZQ0KPiA+IGVxdWl2YWxlbnQNCj4gPiA+ID4gPj4gYmFuZHdpZHRoIGluIGJ5dGVz L3NlYyB3aXRoaW4gYSBsaW5rPyBUaGlzIGFwcHJvYWNoIHNlZW1zIHRvDQo+IGJlDQo+ID4gPiBt b3JlDQo+ID4gPiA+ID4+IGluLWxpbmUgd2l0aCB0aGUgZ2VuZXJhbCBhcHByb2FjaCBvdXRsaW5l ZCBpbiBSRkMtNDIwMi4gUmVmZXINCj4gdG8NCj4gPiA+ID4gc2VjdGlvbg0KPiA+ID4gPiA+PiAz LjQgaW4gUkZDIDQyMDIgZm9yIGFuIGV4YW1wbGUgdGhhdCBzaG93cyBtdWx0aXBsZSBJU0NEcyBi ZWluZw0KPiA+ID4gPiA+PiBhZHZlcnRpc2VkIHBlciBWQyByYXRlIGZvciBhbiBTREggbGluay4g VGhlIGFkZGl0aW9uYWwgYmVuZWZpdA0KPiA+IGlzDQo+ID4gPiB0aGF0DQo+ID4gPiA+ID4+IHRo ZSBhZHZlcnRpc2VtZW50IGlzIFRTIHNpemUgaW5kZXBlbmRlbnQgYW5kIGhlbmNlIHdpbGwNCj4g c2ltcGxpZnkNCj4gPiA+IHRoZQ0KPiA+ID4gPiA+PiBpbXBsZW1lbnRhdGlvbi4NCj4gPiA+ID4g Pj4NCj4gPiA+ID4gPj4gUmVnYXJkcw0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBTbmlnZGhvDQo+ ID4gPiA+ID4+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4+IENDQU1QIG1h aWxpbmcgbGlzdA0KPiA+ID4gPiA+PiBDQ0FNUEBpZXRmLm9yZyA8bWFpbHRvOkNDQU1QQGlldGYu b3JnPg0KPiA+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wDQo+ID4gPiA+IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w Pg0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiA+ID4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gQ0NBTVBAaWV0Zi5v cmcgPG1haWx0bzpDQ0FNUEBpZXRmLm9yZz4NCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ID4gPiA+IDxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wPg0KPiA+ID4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IENDQU1QIG1haWxp bmcgbGlzdA0KPiA+ID4gQ0NBTVBAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== --Boundary_(ID_iHgPpmT1wkTQ/2vsDApcQg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4yOTEyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFk+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGkgSWdvciBhbmQgYWxsLDxCUj48QlI+ SSB0aGluayB3ZSBhcmUgYXQgdGhlIHNhbWUgbGluZSANCmFib3V0IHRoZSByZXF1cmVtZW50IG9m IG5ldHdvcmsgcG9saWN5IGFuZCBwbGFubmluZy4gRm9yIHRyYW5zcG9ydCBuZXR3b3JrcywgdGhl IA0KdHVubmVscyBmb3IgdHJhbnNwb3J0aW5nIHNlcnZpY2UgdXN1YWxseSBzaG91bGQgYmUgcGxh bmVkIHVuZGVyIHNvbWUgcG9saWN5LiANClRoZXJlZm9yZSwgd2UgbWF5IG5lZWQgdG8gZGlmZmVy ZW50aWF0ZSBmdWxsIGxhbWJkYSBMU1Agb3Igc3ViIGxhbWJkYSBMU1Agd2hlbiANCmNyZWF0aW5n IGEgY29ubmVjdGlvbi4gV2Ugd291bGQgbGlrZSB0byByZWZsZWN0IHRoZSByZXF1aXJlbWVudCBt dWNoIGNsZWFyZXIgaW4gDQp0aGUgRldLIGRvY3VtZW50LjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ SG93ZXZlciwgdG8gbWVldCB0aGUgcmVxdWlybWVudCwgSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQg DQptYXliZSB3ZSBkb24ndCBuZWVkIHRvIGV4dGVuZCBJU0MgdHlwZS4gRm9yIGV4YW1wbGUsIExv IE9EVSwgSG8gT0RVLCBTSE8gT0RVLCANCnRoZXkgYXJlIHJlbGF0aXZlIHRvIGVhY2ggb3RoZXIu IEZvciBleGFtcGxlLCANCk9EVTEtJmd0O09EVTItJmd0O09EVTMtJmd0O09EVTQsJm5ic3A7aG93 IHRvIHJlZ2FyZCBPRFUyIG9yIE9EVTMgYXMmbmJzcDtIbyBPVE4gDQpMZXZlbCBvciBMbyZuYnNw O09UTiBMZXZlbD8gQW5vdGhlciBleGFtcGxlIGlzLCBpZiB0aGVyZSBpcyBhIE9UVTMgDQpsaW5r Jm5ic3A7c3VwcG9ydGluZyBPRFUyIHN3aXRjaGluZywgd2hpY2ggY2FuIGJlIHVzZWQgYXMgTG8g T0RVMiAoc2VydmljZSBvdmVyIA0KT0RVMiBkaXJlY3RseSkgYW5kIEhvIE9EVTIgKE9EVTEgaXMg b3ZlciB0aGlzIE9EVTIpLCBpbiB0aGlzIGNhc2UsIGhvdyB0byANCmRpZmZlcmVudGlhdGUgaWYg dGhpcyBPRFUyIGlzIExvIE9UTiBMZXZlbCBvciBIbyBPVE4gTGV2ZWw/PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD5Bbm90aGVyIHBvaW50IGlzIGFib3V0IHdoeSB0aGUgZXhpc3RpbmcgSVNDRCBpcyBu b3QgDQpjb21wZXRlbnQuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+V2UgYWxsIGtub3cgdGhlIGhp c3Rvcnkgb2YgdGhlIEdNUExTLCB3aGljaCBpcyBpbmhlcml0ZWQgDQpmcm9tIE1QTFMuJm5ic3A7 IEluIE1QTFMgbmV0d29ya3MsIHdlIGNhbiBvbmx5IHVzZSBmbG9hdGluZyBwb2ludCBudW1iZXIg dG8gDQppZGVudGlmeSB0aGUgYmFuZHdpZHRoLiBIb3dldmVyLCBmb3IgdGhlIFRETSBuZXR3b3Jr LCB0aGUgcmVzb3VyY2UgaXMgYWxsb2FjdGVkIA0KYmFzZWQgb24gdGhlIFRTLCBzbyBpdCBpcyB2 ZXJ5IG5hdHVyYWxseSB0byB1c2UgVFMgKG9yIHBlciBzaWduYWwgdHlwZSkgdG8gDQplbmNvZGUg dGhlIGJhbmR3aWR0aC4gSWYgd2UgdXNlIHRoZSBmbG9hdGluZyBwb2ludCBudW1iZXIsIHRoZSBy b3V0aW5nIHN0aWxsIA0KbmVlZCB0byBjb252ZXJ0IHRoZSBmbG9hdGluZyBwb2ludCB0byBzZWUg aG93IG1hbnkgVFMgb3Igc2lnbmFsIChPRFVrKSBjYW4gYmUgDQpzdXBwb3J0ZWQgdG8gY3JlYXRl IHRoZSBjb25uZWN0aW9ucy4gU2Vjb25kbHksIGlmIHdlIHVzZSB0aGUgZXhpc3RpbmcgSVNDRCAo d2UgDQpqdXN0IGFkdmVydGlzZSBNYXggTFNQIGJhbmR3aWR0aCAoZS5nLiwgT0RVNCkgYW5kIE1p biBMU1AgYmFuZHdpZHRoIChPRFUxKSwgDQpob3cmbmJzcDt0byBrbm93IHdoZXRoZXIgaXQgY2Fu IHN1cHBvcnQgT0RVZmxleDsgSG93Jm5ic3A7dG8ga25vdyZuYnNwO2lmIGl0IGNhbiANCnN1cHBv cnQgT0RVMiBhbmQgT0RVMyBpZiB0aGUgZXF1aXBtZW50cyBtYXkgaGF2ZSBzb21lIGNvbnN0cmFp dHMuIFRoaXJkbHksIGluIA0KVERNIG5ldHdvcmtzLCBpdCBpcyBub3QgZWZmaWNpZW50IGZvciBz Y2FsYWJpbGl0eSBpc3N1ZSBpZiB3ZSB1c2UgdGhlIGV4aXN0aW5nIA0KSVNDRCwgYmVjYXVzZSBp dCBuZWVkcyAzMiBiaXRzIHRvIGluZGljYXRlIHRoZSBiYW5kd2lkdGggKEFjdHVhbGx5LCB3ZSBv bmx5IA0KbmVlZCZuYnNwO211Y2ggZmV3ZXIgYml0cyB0byBpZGVudGlmeSB0aGUgc2lnbmFsIHR5 cGUgKGUuZy4sIA0KT0RVaykpLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SG9wZSB0aGlzIGNhbiBj bGFyaWZ5IHlvdXIgY29uY2Vybi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+PC9GT05UPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPjxGT05UIA0KZmFj ZT1BcmlhbD48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+PEJSPjxGT05UIGZhY2U9QXJp YWw+QmVzdCANClJlZ2FyZHM8QlI+Jm5ic3A7PEJSPkZhdGFpPEJSPiZuYnNwOzwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwv Rk9OVD4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5Gcm9tOiAiSWdvciBCcnlza2luIiAmbHQ7PC9G T05UPjxBIA0KaHJlZj0ibWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbSI+PEZPTlQgDQpm YWNlPUFyaWFsPklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTwvRk9OVD48L0E+PEZPTlQgZmFjZT1B cmlhbD4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRvOiAiU25pZ2Ro byBCYXJkYWxhaSIgJmx0OzwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpTQmFyZGFsYWlAaW5maW5l cmEuY29tIj48Rk9OVCANCmZhY2U9QXJpYWw+U0JhcmRhbGFpQGluZmluZXJhLmNvbTwvRk9OVD48 L0E+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7OyAiU2FkbGVyLCANCkpvbmF0aGFuIEIuIiAmbHQ7PC9G T05UPjxBIGhyZWY9Im1haWx0bzpKb25hdGhhbi5TYWRsZXJAdGVsbGFicy5jb20iPjxGT05UIA0K ZmFjZT1BcmlhbD5Kb25hdGhhbi5TYWRsZXJAdGVsbGFicy5jb208L0ZPTlQ+PC9BPjxGT05UIGZh Y2U9QXJpYWw+Jmd0OzsgIkpvaG4gRSANCkRyYWtlIiAmbHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0 bzpqZHJha2VAanVuaXBlci5uZXQiPjxGT05UIA0KZmFjZT1BcmlhbD5qZHJha2VAanVuaXBlci5u ZXQ8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0OzsgIkZhdGFpIFpoYW5nIiANCiZsdDs8 L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbSI+PEZPTlQgDQpmYWNl PUFyaWFsPnpoYW5nZmF0YWlAaHVhd2VpLmNvbTwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD4m Z3Q7OyAiTG91IEJlcmdlciIgDQombHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxh Ym4ubmV0Ij48Rk9OVCANCmZhY2U9QXJpYWw+bGJlcmdlckBsYWJuLm5ldDwvRk9OVD48L0E+PEZP TlQgZmFjZT1BcmlhbD4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkNj OiAmbHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PEZPTlQgDQpmYWNl PUFyaWFsPmNjYW1wQGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiZndDs7ICZs dDs8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZy YW1ld29ya0B0b29scy5pZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIA0K ZmFjZT1BcmlhbD4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlNlbnQ6 IEZyaWRheSwgSnVseSAwOSwgMjAxMCA2OjE1IEFNPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsPlN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gDQpkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dDwvRk9OVD48L0RJVj48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbD48QlI+PC9GT05UPjwvRElWPjxGT05UIGZhY2U9QXJpYWw+Tm8sIGp1 c3QgbmV0d29yayANCnBvbGljaWVzIGFuZCBwbGFubmluZy48QlI+PEJSPkNoZWVycyw8QlI+SWdv cjxCUj48QlI+LS0tLS1PcmlnaW5hbCANCk1lc3NhZ2UtLS0tLTxCUj5Gcm9tOiBTbmlnZGhvIEJh cmRhbGFpIFttYWlsdG86U0JhcmRhbGFpQGluZmluZXJhLmNvbV08QlI+U2VudDogDQpUaHVyc2Rh eSwgSnVseSAwOCwgMjAxMCA2OjA4IFBNPEJSPlRvOiBJZ29yIEJyeXNraW47IFNhZGxlciwgSm9u YXRoYW4gQi47IEpvaG4gRSANCkRyYWtlOyBGYXRhaSBaaGFuZzsgTG91IEJlcmdlcjxCUj5DYzog PC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj48Rk9OVCBmYWNlPUFyaWFs PmNjYW1wQGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCANCmZhY2U9QXJpYWw+OyA8L0ZPTlQ+PEEg DQpocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29ya0B0b29s cy5pZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcw OS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCANCmZhY2U9QXJp YWw+U3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBvbiANCmRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtZzcwOS1mcmFtZXdvcmstMDEudHh0PEJSPjxCUj5JZ29yLDxCUj48QlI+SXQgaXMgbm90IGNs ZWFyIA0Kd2h5IGFyZSB5b3UgcmVxdWlyaW5nIHRoZSBjb25zdHJhaW50IGZvciBhIGNvbm5lY3Rp b24gdG8gdGFrZSBhIHNwZWNpZmljIGxldmVsIA0KaW4gdGhlIGhpZXJhcmNoeSBlbmQtdG8tZW5k PyBJcyBpdCBhIGhhcmR3YXJlIHNwZWNpZmljIGlzc3VlIHlvdSBhcmUgdHJ5aW5nIHRvIA0KYWRk cmVzcz88QlI+PEJSPlNuaWdkaG88QlI+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08QlI+Jmd0OyBGcm9tOiANCjwvRk9OVD48QSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L0ZPTlQ+ PC9BPjxGT05UIGZhY2U9QXJpYWw+IA0KW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGY8QlI+Jmd0OyBPZiBJZ29yIEJyeXNraW48QlI+Jmd0OyBTZW50OiANClRodXJzZGF5 LCBKdWx5IDA4LCAyMDEwIDExOjU4IEFNPEJSPiZndDsgVG86IFNuaWdkaG8gQmFyZGFsYWk7IFNh ZGxlciwgSm9uYXRoYW4gDQpCLjsgSm9obiBFIERyYWtlOyBGYXRhaSBaaGFuZzs8QlI+Jmd0OyBM b3UgQmVyZ2VyPEJSPiZndDsgQ2M6IDwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpjY2FtcEBpZXRm Lm9yZyI+PEZPTlQgZmFjZT1BcmlhbD5jY2FtcEBpZXRmLm9yZzwvRk9OVD48L0E+PEZPTlQgDQpm YWNlPUFyaWFsPjsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LTxCUj4mZ3Q7IDwvRk9OVD48 QSANCmhyZWY9Im1haWx0bzpmcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1B cmlhbD5mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCBmYWNlPUFy aWFsPiZndDsgU3ViamVjdDogDQpSZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstPEJSPiZndDsgDQowMS50eHQ8QlI+Jmd0OzxCUj4mZ3Q7 ICZndDtJZiB0aGF0IGlzIHRoZSBjYXNlIGhvdyBjYW4geW91IGNvbnN0cmFpbnQgYSANCmNvbm5l Y3Rpb24gdG8gYSAmZ3Q7c3BlY2lmaWM8QlI+Jmd0OyBoaWVyYXJjaHkgZW5kLXRvLWVuZD88QlI+ Jmd0OzxCUj4mZ3Q7IFlvdSANCmRvbid0IGhhdmUgdG8uIFlvdSBNQVkgY29uc3RyYWluIGEgY29u bmVjdGlvbiB0byB0YWtlLCBmb3IgZXhhbXBsZSw8QlI+Jmd0OyBvbmx5IA0KTE8gbGlua3MuIEJ1 dCB5b3UgY2FuIGFsc28gYWxsb3cgdGhlIGNvbm5lY3Rpb24gdG8gdGFrZSBlaXRoZXIgSE88QlI+ Jmd0OyBvciBMTyANCmxpbmtzLiBBbHNvLCBrZWVwIGluIG1pbmQgdGhhdCBHTVBMUyBhbGxvd3Mg dG8gYWR2ZXJ0aXNlIE9UTiBsaW5rPEJSPiZndDsgdG8gDQpiZWxvbmcgdG8gbW9yZSB0aGFuIG9u ZSBPVE4gbGF5ZXIuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IC0tLS0tT3JpZ2luYWwgDQpNZXNz YWdlLS0tLS08QlI+Jmd0OyBGcm9tOiBTbmlnZGhvIEJhcmRhbGFpIA0KW21haWx0bzpTQmFyZGFs YWlAaW5maW5lcmEuY29tXTxCUj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDI6 NTEgDQpQTTxCUj4mZ3Q7IFRvOiBJZ29yIEJyeXNraW47IFNhZGxlciwgSm9uYXRoYW4gQi47IEpv aG4gRSBEcmFrZTsgRmF0YWkgWmhhbmc7IA0KTG91PEJSPiZndDsgQmVyZ2VyPEJSPiZndDsgQ2M6 IDwvRk9OVD48QSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1Bcmlh bD5jY2FtcEBpZXRmLm9yZzwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD47IA0KZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1nNzA5LTxCUj4mZ3Q7IDwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpmcmFt ZXdvcmtAdG9vbHMuaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5mcmFtZXdvcmtAdG9vbHMu aWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCBmYWNlPUFyaWFsPiZndDsgU3ViamVjdDogDQpS RTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdv cmstPEJSPiZndDsgDQowMS50eHQ8QlI+Jmd0OzxCUj4mZ3Q7IFRoYXQgbWVhbnMgdGhhdCB0aGUg c2lnbmFsIGNhbiBiZSBhdCBkaWZmZXJlbnQgDQpoaWVyYXJjaGllcyBvdmVyPEJSPiZndDsgZGlm ZmVyZW50IE9UTiBsaW5rcyBhbG9uZyB0aGUgcm91dGUuPEJSPiZndDs8QlI+Jmd0OyBJZiANCnRo YXQgaXMgdGhlIGNhc2UgaG93IGNhbiB5b3UgY29uc3RyYWludCBhIGNvbm5lY3Rpb24gdG8gYSBz cGVjaWZpYzxCUj4mZ3Q7IA0KaGllcmFyY2h5IGVuZC10by1lbmQ/IEkgdGhpbmsgYWxsIHlvdSBj YW4gZG8gaXMgZmluZCBhbiBPVE4gbGluayB0aGF0PEJSPiZndDsgDQpjYW4gc3VwcG9ydCB0aGUg cmVxdWlyZWQgc2lnbmFsLXR5cGUuPEJSPiZndDs8QlI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwg DQpNZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7IEZyb206IElnb3IgQnJ5c2tpbiANClttYWlsdG86 SUJyeXNraW5AYWR2YW9wdGljYWwuY29tXTxCUj4mZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEp1 bHkgMDgsIDIwMTAgDQoxMTo0NiBBTTxCUj4mZ3Q7ICZndDsgVG86IFNuaWdkaG8gQmFyZGFsYWk7 IFNhZGxlciwgSm9uYXRoYW4gQi47IEpvaG4gRSBEcmFrZTsgDQpGYXRhaSBaaGFuZzs8QlI+Jmd0 OyAmZ3Q7IExvdSBCZXJnZXI8QlI+Jmd0OyAmZ3Q7IENjOiA8L0ZPTlQ+PEEgDQpocmVmPSJtYWls dG86Y2NhbXBAaWV0Zi5vcmciPjxGT05UIGZhY2U9QXJpYWw+Y2NhbXBAaWV0Zi5vcmc8L0ZPTlQ+ PC9BPjxGT05UIA0KZmFjZT1BcmlhbD47IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS08QlI+ Jmd0OyAmZ3Q7IDwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpmcmFtZXdvcmtAdG9vbHMuaWV0Zi5v cmciPjxGT05UIA0KZmFjZT1BcmlhbD5mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8L0ZPTlQ+PC9B PjxCUj48Rk9OVCBmYWNlPUFyaWFsPiZndDsgJmd0OyANClN1YmplY3Q6IFJFOiBbQ0NBTVBdIENv bW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LTxCUj4mZ3Q7IA0KZnJhbWV3b3Jr LTxCUj4mZ3Q7ICZndDsgMDEudHh0PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgQmVjYXVzZSB0 aGUgc2FtZSBzaWduYWwgDQooYW5kIGNvbm5lY3Rpb24pIGNvdWxkIGJlIG9uIGEgZGlmZmVyZW50 PEJSPiZndDsgJmd0OyBoaWVyYXJjaHkgbGV2ZWwuPEJSPiZndDsgDQomZ3Q7PEJSPiZndDsgJmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgRnJvbTogU25pZ2RobyBC YXJkYWxhaSANClttYWlsdG86U0JhcmRhbGFpQGluZmluZXJhLmNvbV08QlI+Jmd0OyAmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDI6NDQgDQpQTTxCUj4mZ3Q7ICZndDsgVG86IEln b3IgQnJ5c2tpbjsgU2FkbGVyLCBKb25hdGhhbiBCLjsgSm9obiBFIERyYWtlOyBGYXRhaSANClpo YW5nOyBMb3U8QlI+Jmd0OyAmZ3Q7IEJlcmdlcjxCUj4mZ3Q7ICZndDsgQ2M6IDwvRk9OVD48QSAN CmhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PEZPTlQgZmFjZT1BcmlhbD5jY2FtcEBpZXRm Lm9yZzwvRk9OVD48L0E+PEZPTlQgDQpmYWNlPUFyaWFsPjsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nNzA5LTxCUj4mZ3Q7ICZndDsgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmZyYW1ld29ya0B0 b29scy5pZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmZyYW1ld29ya0B0b29scy5pZXRmLm9y ZzwvRk9OVD48L0E+PEJSPjxGT05UIGZhY2U9QXJpYWw+Jmd0OyAmZ3Q7IA0KU3ViamVjdDogUkU6 IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktPEJSPiZndDsg DQpmcmFtZXdvcmstPEJSPiZndDsgJmd0OyAwMS50eHQ8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0 OyBXaHkgbm90IHNpbXBseSBjcmVhdGUgDQpzd2l0Y2hpbmcgY2FwYWJpbGl0eSBkZXNjcmlwdG9y cyBwZXIgaGllcmFyY2h5PEJSPiZndDsgJmd0OyAoaS5lLiBPRFUwLCANCk9EVTEsLi4uKT88QlI+ Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJS PiZndDsgDQomZ3Q7ICZndDsgRnJvbTogSWdvciBCcnlza2luIFttYWlsdG86SUJyeXNraW5AYWR2 YW9wdGljYWwuY29tXTxCUj4mZ3Q7ICZndDsgJmd0OyANClNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4 LCAyMDEwIDExOjQwIEFNPEJSPiZndDsgJmd0OyAmZ3Q7IFRvOiBTYWRsZXIsIEpvbmF0aGFuIA0K Qi47IEpvaG4gRSBEcmFrZTsgU25pZ2RobyBCYXJkYWxhaTsgRmF0YWk8QlI+Jmd0OyBaaGFuZzs8 QlI+Jmd0OyAmZ3Q7ICZndDsgTG91IA0KQmVyZ2VyPEJSPiZndDsgJmd0OyAmZ3Q7IENjOiA8L0ZP TlQ+PEEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+Y2Nh bXBAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+OyANCmRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZzcwOS08QlI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRv OmZyYW1ld29ya0B0b29scy5pZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmZyYW1ld29ya0B0 b29scy5pZXRmLm9yZzwvRk9OVD48L0E+PEJSPjxGT05UIGZhY2U9QXJpYWw+Jmd0OyAmZ3Q7IA0K Jmd0OyBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtZzcwOS08QlI+Jmd0OyAmZ3Q7IA0KZnJhbWV3b3JrLTxCUj4mZ3Q7ICZndDsgJmd0OyAwMS50 eHQ8QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgDQphIGxvdCBv ZiBzd2NhcHMgYXZhaWxhYmxlIDo9KTxCUj4mZ3Q7ICZndDsgJmd0OyBTZXBhcmF0ZSBzd2NhcHMg cHJvdmlkZSBhbiBlYXN5IA0Kd2F5IHRvIGNvbnN0cmFpbiBjb25uZWN0aW9uIHRvIGE8QlI+Jmd0 OyAmZ3Q7ICZndDsgZGVzaXJlZCBsZXZlbCBvZiANCmhpZXJhcmNoeS48QlI+Jmd0OyAmZ3Q7ICZn dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCANCk1lc3NhZ2UtLS0tLTxCUj4mZ3Q7 ICZndDsgJmd0OyBGcm9tOiBTYWRsZXIsIEpvbmF0aGFuIEIuIA0KW21haWx0bzpKb25hdGhhbi5T YWRsZXJAdGVsbGFicy5jb21dPEJSPiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5 IDA4LCANCjIwMTAgMjozNiBQTTxCUj4mZ3Q7ICZndDsgJmd0OyBUbzogSWdvciBCcnlza2luOyBK b2huIEUgRHJha2U7IFNuaWdkaG8gQmFyZGFsYWk7IA0KRmF0YWkgWmhhbmc7IExvdTxCUj4mZ3Q7 ICZndDsgJmd0OyBCZXJnZXI8QlI+Jmd0OyAmZ3Q7ICZndDsgQ2M6IDwvRk9OVD48QSANCmhyZWY9 Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PEZPTlQgZmFjZT1BcmlhbD5jY2FtcEBpZXRmLm9yZzwv Rk9OVD48L0E+PEZPTlQgDQpmYWNlPUFyaWFsPjsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5 LTxCUj4mZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86ZnJhbWV3b3JrQHRv b2xzLmlldGYub3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+ZnJhbWV3b3JrQHRvb2xzLmlldGYub3Jn PC9GT05UPjwvQT48QlI+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7ICZndDsgDQomZ3Q7IFN1YmplY3Q6 IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LTxCUj4m Z3Q7ICZndDsgDQpmcmFtZXdvcmstPEJSPiZndDsgJmd0OyAmZ3Q7IDAxLnR4dDxCUj4mZ3Q7ICZn dDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBGb3IgdGhlIA0KZXhpc3RpbmcgaGllcmFyY2h5LCB0 aGF0IHdvdWxkIGJlIDUgKE9EVTAgaW4gT0RVMSBpbiBPRFUyPEJSPiZndDsgaW48QlI+Jmd0OyAN CiZndDsgJmd0OyBPRFUzIGluIE9EVTQpIC0gd2hpbGUgdGhpcyBtYXkgYmUgdGhlIHdvcnN0IGNh c2UsIGl0IGlzIHRoZTxCUj4mZ3Q7IA0KcG9zc2libGU8QlI+Jmd0OyAmZ3Q7ICZndDsgY2FzZSB0 b28uPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEFzIG5ldyANCnNpZ25hbHMv cmF0ZXMgYXJlIGFkZGVkIChlLmcuIE9EVTUgZm9yICJ0aGUgbmV4dCBncmVhdDxCUj4mZ3Q7IHNw ZWVkIjxCUj4mZ3Q7IA0KJmd0OyAtLTxCUj4mZ3Q7ICZndDsgJmd0OyA0MDBHPykgdGhlIGRlcHRo IG9mIHRoZSBoaWVyYXJjaHkgd2lsbCBncm93LjxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OyAmZ3Q7IFRoaXMgbWFrZXMgbWUgd29uZGVyOiB3b3VsZG4ndCBhIGdlbmVyYWxpemVkIG1l dGhvZCANCmJlIGEgYmV0dGVyPEJSPiZndDsgJmd0OyAmZ3Q7IGFwcHJvYWNoIHRoYW4ganVzdCBj cmVhdGluZyBuZXcgU3dpdGNoaW5nVHlwZXMgLS0gDQplc3BlY2lhbGx5IHNpbmNlPEJSPiZndDsg Jmd0OyB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgc2lnbmFscyBzdXBwb3J0ZWQgd2l0aGluIA0KZWFj aCBvZiB0aGVzZSBpcyB0aGUgc2FtZSAoZS5nLiBhbiBPRFUxPEJSPiZndDsgb3ZlcjxCUj4mZ3Q7 ICZndDsgJmd0OyBhbiBPRFUyIA0KaXMgdGhlIHNhbWUgYXMgYW4gT0RVMSBvdmVyIGFuIE9EVTMu Li4pPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IA0KSm9uYXRoYW4gU2FkbGVy PEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgDQpNZXNz YWdlLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTogPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRv OmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5jY2FtcC1ib3VuY2Vz QGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiANClttYWlsdG86Y2NhbXAtYm91 bmNlc0BpZXRmLm9yZ10gT248QlI+Jmd0OyAmZ3Q7IEJlaGFsZjxCUj4mZ3Q7ICZndDsgJmd0OyBP ZiBJZ29yIA0KQnJ5c2tpbjxCUj4mZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAw OCwgMjAxMCAxOjMxIFBNPEJSPiZndDsgJmd0OyANCiZndDsgVG86IEpvaG4gRSBEcmFrZTsgU25p Z2RobyBCYXJkYWxhaTsgRmF0YWkgWmhhbmc7IExvdSBCZXJnZXI8QlI+Jmd0OyAmZ3Q7IA0KJmd0 OyBDYzogPC9GT05UPjxBIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PEZPTlQgDQpmYWNl PUFyaWFsPmNjYW1wQGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPjsgDQpkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktPEJSPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48QSANCmhy ZWY9Im1haWx0bzpmcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5m cmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCBmYWNlPUFyaWFsPiZn dDsgJmd0OyANCiZndDsgU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLWc3MDktPEJSPiZndDsgJmd0OyANCmZyYW1ld29yay08QlI+Jmd0OyAmZ3Q7 ICZndDsgMDEudHh0PEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEkgdGhpbmsg DQpPVE4gbGlua3MgcmVxdWlyZSBtb3JlIHRoYW4gb25lIHN3aXRjaGNhcHM6IGFzIG1hbnkgYXMg dGhlPEJSPiZndDsgJmd0OyAmZ3Q7IA0KZGVwdGggb2YgdGhlIGRlZXBlc3QgcG9zc2libGUgT1RO IERQIGhpZXJhcmNoeSwgZm9yIGV4YW1wbGU6PEJSPiZndDsgJmd0OyANCiZndDs8QlI+Jmd0OyAm Z3Q7ICZndDsgdHlwZWRlZiBlbnVtPEJSPiZndDsgJmd0OyAmZ3Q7IHs8QlI+Jmd0OyAmZ3Q7IA0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBMU1BTd2l0Y2hUeXBlX1Vua25vd24gDQo9MCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAvKiBVbmtub3duIA0KKi88QlI+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgLCBM U1BTd2l0Y2hUeXBlX1BTQ18xIA0KPTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyogUFNDLTEgDQoqLzxCUj4mZ3Q7ICZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAsIExTUFN3aXRjaFR5cGVfUFNDXzIgDQo9MiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAvKiBQU0MtMiANCiovPEJSPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICwg TFNQU3dpdGNoVHlwZV9QU0NfMyANCj0zJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8qIFBTQy0zIA0KKi88QlI+Jmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgLCBMU1BTd2l0Y2hUeXBlX1BTQ180IA0KPTQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLyogUFNDLTQgDQoqLzxCUj4mZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAs IExTUFN3aXRjaFR5cGVfTDJTQyZuYnNwOyANCj01MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvKiBMMlNDIA0KKi88QlI+Jmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgLCBMU1BTd2l0Y2hUeXBlX1RETSZuYnNwOyZuYnNw OyANCj0xMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLyogVERNICovPEJSPiZndDsgDQomZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgLyoq KioqLzxCUj4mZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAsIA0KTFNQU3dpdGNoVHlw ZV9PVE5fTE89MTI0Jm5ic3A7Jm5ic3A7IC8qIE9UTiBsb3cgb3JkZXIgKi88QlI+Jmd0OyAmZ3Q7 IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAsIExTUFN3aXRjaFR5cGVfT1ROX0hPPTEyNSZuYnNw OyZuYnNwOyAvKiBPVE4gaGlnaCBvcmRlciANCiovPEJSPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICwgTFNQU3dpdGNoVHlwZV9PVE5fU0hPPTEyNiZuYnNwOyAvKiBPVE4gDQpzdXBl ciBoaWdoIG9yZGVyICovPEJSPiZndDsgJmd0OyAmZ3Q7IC8qKioqKi88QlI+Jmd0OyAmZ3Q7IA0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAsIExTUFN3aXRjaFR5cGVfTFNDJm5ic3A7Jm5ic3A7IA0K PTE1MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAvKiBMU0MgKi88QlI+Jmd0OyANCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAsIExTUFN3 aXRjaFR5cGVfRlNDJm5ic3A7Jm5ic3A7IA0KPTIwMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvKiBGU0MgKi88QlI+Jmd0OyANCiZndDsgJmd0 OyB9ZV9MU1BTd2l0Y2hUeXBlOzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxC Uj4mZ3Q7ICZndDsgDQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgJmd0 OyAmZ3Q7IEZyb206IEpvaG4gRSBEcmFrZSANClttYWlsdG86amRyYWtlQGp1bmlwZXIubmV0XTxC Uj4mZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAxOjU5IA0KUE08 QlI+Jmd0OyAmZ3Q7ICZndDsgVG86IElnb3IgQnJ5c2tpbjsgU25pZ2RobyBCYXJkYWxhaTsgRmF0 YWkgWmhhbmc7IExvdSANCkJlcmdlcjxCUj4mZ3Q7ICZndDsgJmd0OyBDYzogPC9GT05UPjxBIGhy ZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmNjYW1wQGlldGYu b3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPjsgDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LWc3MDktPEJSPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpmcmFtZXdv cmtAdG9vbHMuaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5mcmFtZXdvcmtAdG9vbHMuaWV0 Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCBmYWNlPUFyaWFsPiZndDsgJmd0OyANCiZndDsgU3Vi amVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDkt PEJSPiZndDsgJmd0OyANCmZyYW1ld29yay08QlI+Jmd0OyAmZ3Q7ICZndDsgMDEudHh0PEJSPiZn dDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFdoYXQgZG8gDQp5b3UgbWVhbiBieSAiZGlm ZmVyZW50IHN3aXRjaGNhcHMiPzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBG cm9tOiA8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyI+PEZP TlQgDQpmYWNlPUFyaWFsPmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIGZh Y2U9QXJpYWw+IA0KW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbjxCUj4mZ3Q7ICZn dDsgJmd0OyBCZWhhbGYgT2Y8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7IElnb3IgQnJ5c2tpbjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDEwOjUz IA0KQU08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogU25pZ2RobyBCYXJkYWxhaTsgRmF0YWkg Wmhhbmc7IExvdSBCZXJnZXI8QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7IENjOiA8L0ZPTlQ+PEEg aHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+Y2NhbXBAaWV0 Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+OyANCmRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtZzcwOS08QlI+Jmd0OyAmZ3Q7ICZndDsgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmZyYW1l d29ya0B0b29scy5pZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmZyYW1ld29ya0B0b29scy5p ZXRmLm9yZzwvRk9OVD48L0E+PEJSPjxGT05UIGZhY2U9QXJpYWw+Jmd0OyAmZ3Q7IA0KJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nNzA5LTxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7IGZyYW1ld29yay08QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAwMS50eHQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgU25pZ2Robyw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZn dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OyAmZ3Q7IA0KJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7INgmbmJzcDsgSSB0aGluayB3 ZSBuZWVkIHRvIHNvcnQgb3V0IHRoZSBpc3N1ZXMgd2l0aCANCnRoZSBmcmFtZXdvcms8QlI+Jmd0 OyAmZ3Q7IGRvY3VtZW50PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmVmb3JlIHdlIGNhbiBlbWJh cmsgDQpvbiBhbnkgcHJvcG9zYWxzIHRvIHRoZSBwcm9ibGVtLiBJIGFtIHN0aWxsPEJSPiZndDsg Jmd0OyBub3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgDQpjbGVhcjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHdoeSBkbyB3ZSBoYXZlIHRvIGRldmlhdGUgZnJvbSB0aGUgZ2VuZXJhbCBhcHByb2FjaCANCnRo YXQgaGFzIGJlZW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBlc3RhYmxpc2hlZCBpbiBSRkMgNDIw Mi48QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KSUImZ3Q7Jmd0OyBBZ3Jl ZSBhYnNvbHV0ZWx5LiBHTVBMUyBpcyBpbmhlcmVudGx5IG11bHRpLWxheWVyIGNvbnRyb2w8QlI+ Jmd0OyANCiZndDsgcGxhbmUsPEJSPiZndDsgJmd0OyAmZ3Q7IGFuZDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGl0IGlzIGhpZ2hseSBkZXNpcmFibGUgDQp0byBhZGhlcmUgdG8gdGhlIGxheWVyIGlu ZGVwZW5kZW50PEJSPiZndDsgcGFyYWRpZ208QlI+Jmd0OyAmZ3Q7IG9mPEJSPiZndDsgJmd0OyAN CiZndDsgJmd0OyBhZHZlcnRpc2luZyBvZiBURSBsaW5rcywgYW5kIHRoZXJlIGlzIG5vIHJlYXNv biB0byBpbnZlbnQgYW4gDQpPVE48QlI+Jmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWM8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBJU0NELiBUaGUgY29tYmluYXRpb24gb2YgDQpTd2l0Y2hpbmcgQ2FwYWJp bGl0eSBhbmQgRW5jb2RpbmcgdHlwZTxCUj4mZ3Q7IG9mPEJSPiZndDsgJmd0OyAmZ3Q7IA0KUkZD NDIwMjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElTQ0QgYWxsb3dzIGZvciBzcGVjaWZ5aW5nIGJv dGggbXVsdGlwbGV4aW5nIA0KY2FwYWJpbGl0aWVzIGFuZCBPVE48QlI+Jmd0OyAmZ3Q7ICZndDsg bGF5ZXI8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAoTE8sIEhPLCANClNITykgb2YgYW4gT1ROIGxp bmssIGFuZCwgaWYgdGhpcyBub3Qgc3VmZmljaWVudCwgeW91PEJSPiZndDsgaGF2ZTxCUj4mZ3Q7 ICZndDsgDQomZ3Q7ICZndDsgYW5vdGhlciByZXNlcnZlZCAxNiBiaXRzLjxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0O0FkZGl0aW9uYWxseSwgSSBkbyBub3QgDQpzZWUg YW55IHJlYXNvbiB0byBhZHZlcnRpc2UgYSBuZXcgVEUtbGluazxCUj4mZ3Q7ICZndDsgdG88QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCnJlcHJlc2VudCAmZ3Q7dGhlIGxvdy1vcmRlciBPRFVqIGJh bmR3aWR0aCB3aXRoaW4gdGhlIGhpZ2gtb3JkZXI8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyBjb250YWlu ZXJzLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMgaXMgc2ltcGx5ICZndDtibG93aW5nIHVw IHRoZSANCnNvbHV0aW9uIHRvIGEgdmVyeSBzaW1wbGUgcHJvYmxlbS48QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElCJmd0OyZndDsgSGVyZSBJIGRpc2FncmVlLiANCkluIG9y ZGVyIHRvIGdpdmUgYSB1c2VyIHBvc3NpYmlsaXR5IHRvPEJSPiZndDsgY3JlYXRlPEJSPiZndDsg Jmd0OyAmZ3Q7IA0KT1ROPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaGllcmFyY2hpZXMgYW5kIGNv bnN0cmFpbiBMTyBjb25uZWN0aW9ucyB0byBITyANCmNvbnRhaW5lcnMsIG9uZTxCUj4mZ3Q7ICZn dDsgbmVlZHM8QlI+Jmd0OyAmZ3Q7ICZndDsgdG88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCmFk dmVydGlzZSBPVE4gbGlua3Mgd2l0aCBkaWZmZXJlbnQgc3dpdGNoY2Fwcy48QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OzxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IENoZWVycyw8QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSWdvcjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZn dDsgJmd0OyANCiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgUmVnYXJkczxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBTbmlnZGhvPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IA0KJmd0 OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9t OiBGYXRhaSBaaGFuZyANClttYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tXTxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgDQoyMDEwIDY6MzMgUE08QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogU25pZ2RobyBCYXJkYWxhaTsgTG91IEJlcmdlcjxCUj4m Z3Q7IA0KJmd0OyAmZ3Q7ICZndDsgQ2M6IDwvRk9OVD48QSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0 Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5jY2FtcEBpZXRmLm9yZzwvRk9OVD48L0E+PEZPTlQg ZmFjZT1BcmlhbD47IA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LTxCUj4mZ3Q7ICZndDsg Jmd0OyA8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86ZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnIj48 Rk9OVCANCmZhY2U9QXJpYWw+ZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPC9GT05UPjwvQT48QlI+ PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7ICZndDsgDQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtDQ0FN UF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktPEJSPiZndDsgDQomZ3Q7 ICZndDsgZnJhbWV3b3JrLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDAxLnR4dDxCUj4mZ3Q7ICZn dDsgJmd0OyANCiZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgDQpTbmlnZGhvIGFuZCBMb3UsPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAN CiZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZZXMsIHdlIGhhdmUgbG90cyBvZiBvZmYtbGlu ZSBkaXNjdXNzaW9ucyBhbW9uZyANCmF1dGhvcnMgYW5kIG90aGVyPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgaW50ZXJlc3RlZCBleHBlcnRzLCBhbmQgd2UgdGhpbmsgdGhlIA0KcHJvcG9zYWwgZGVz Y3JpYmVkIGluPEJSPiZndDsgImRyYWZ0LTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KY2VjY2Fy ZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDkiIFtPU1BGLUVuY29kaW5nXSBkcmFmdCBpcyBtb3Jl PEJSPiZndDsgJmd0OyANCiZndDsgZmVhc2libGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBmb3Ig T1ROIG5ldHdvcmtzLjxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIA0K ZnJhbWV3b3JrIGRyYWZ0IGp1c3QgdGVsbHMgeW91IHdoYXQgaW5mb3JtYXRpb24gbmVlZGVkIGZv cjxCUj4mZ3Q7ICZndDsgJmd0OyANCmNvbnRyb2w8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwbGFu ZSwgbm8gbWF0dGVyIGhvdyB5b3UgZW5jb2RlIHRoZSByb3V0aW5nIA0KaW5mb3JtYXRpb24uIEZv ciBURE08QlI+Jmd0OyAmZ3Q7ICZndDsgbmV0d29ya3MsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg eW91IGtub3cgDQp0aGUgcmVzb3VyY2UgaXMgYWxsb2NhdGVkIGJhc2VkIG9uIFRTLCBzbyB0aGUg YXZhaWxhYmxlPEJSPiZndDsgVFM8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyBzaG91bGQ8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBiZSBnZXQgb3IgaW5kdWNlZCBiZWZvcmUgY3JlYXRpbmcgDQpjcm9zcy1j b25uZWN0LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+ Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgeW91IGFyZSB0 cnlpbmcgdG8gZmluZCBob3cgdG8gZW5jb2RlIHRoZSByb3V0aW5nIA0KaW5mb3JtYXRpb24sPEJS PiZndDsgSTxCUj4mZ3Q7ICZndDsgJmd0OyB0aGluazxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHlv dSBuZWVkIA0KZ28gdG8gdGhlIHJvdXRpbmcgZHJhZnRzIChpbmZvIG1vZGVsIGFuZCBlbmNvZGlu ZykuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJZiB5b3UgDQpsb29rIGF0 IHRoZSByb3V0aW5nIGRyYWZ0cyAoaW5mbyBtb2RlbCBhbmQgZW5jb2RpbmcpLCB5b3U8QlI+Jmd0 OyAmZ3Q7IA0Kd2lsbDxCUj4mZ3Q7ICZndDsgJmd0OyBmaW5kPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgdGhhdCBvbmUgb2YgeW91ciBzdWdnZXN0aW9ucyANCmlzIGFkb3B0ZWQgKGkuZS4sIHNpbXBs eSBhZHZlcnRpemU8QlI+Jmd0OyB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhdmFpbGFibGUg DQpudW1iZXIgb2YgT0RVMCwgT0RVMSwgT0RVMiwgLi4uLCBPRFU0IGNvbnRhaW5lcjxCUj4mZ3Q7 ICZndDsgaW5zdGFuY2VzKS48QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAm Z3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsg T25lIG1vcmUgdGhpbmcgZm9yIHlvdXIgZmlyc3QgY29tbWVudDo8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OzxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDsgSWYgeW91IGNyZWF0ZSBhbiBPRFUyIExTUCAo dXN1YWxseSBvdmVyIG11bHRpIE9UVTMgbGlua3MpIGFzIA0KRkE8QlI+Jmd0OyBmb3I8QlI+Jmd0 OyAmZ3Q7ICZndDsgT0RVMSw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB5b3UgaGF2ZSB0byANCmFk dmVydGlzZSBhIG5ldyBURSBsaW5rIG9yIHB1dCB0aGlzIEZBIGFzIGEgY29tcG9uZW50PEJSPiZn dDsgJmd0OyAmZ3Q7IGxpbmsgDQpvZjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuIGV4aXN0aW5n IFRFIGxpbmsgKGxpa2UgUkZDNDIwNmJpcykuPEJSPiZndDsgJmd0OyANCiZndDsgJmd0OzxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQomZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJlc3QgDQpSZWdhcmRzPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGYXRhaTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDs8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgDQotLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgRnJvbTogIlNuaWdkaG8gQmFyZGFsYWkiIA0KJmx0OzwvRk9OVD48QSBocmVmPSJt YWlsdG86U0JhcmRhbGFpQGluZmluZXJhLmNvbSI+PEZPTlQgDQpmYWNlPUFyaWFsPlNCYXJkYWxh aUBpbmZpbmVyYS5jb208L0ZPTlQ+PC9BPjxCUj48Rk9OVCBmYWNlPUFyaWFsPiZndDsgJmd0OyAm Z3Q7IA0KJmd0OyAmbHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpTQmFyZGFsYWlAaW5maW5lcmEu Y29tIj48Rk9OVCANCmZhY2U9QXJpYWw+bWFpbHRvOlNCYXJkYWxhaUBpbmZpbmVyYS5jb208L0ZP TlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0OyANCiZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiAiTG91IEJlcmdlciIgDQombHQ7PC9GT05UPjxB IGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij48Rk9OVCANCmZhY2U9QXJpYWw+bGJlcmdl ckBsYWJuLm5ldDwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD4gJmx0OzwvRk9OVD48QSANCmhy ZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij48Rk9OVCANCmZhY2U9QXJpYWw+bWFpbHRvOmxi ZXJnZXJAbGFibi5uZXQ8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0OyAmZ3Q7PEJSPiZn dDsgDQomZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IENjOiAmbHQ7PC9GT05U PjxBIA0KaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj48Rk9OVCBmYWNlPUFyaWFsPmNjYW1w QGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCANCmZhY2U9QXJpYWw+ICZsdDs8L0ZPTlQ+PEEgaHJl Zj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+bWFpbHRvOmNjYW1w QGlldGYub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiZndDsgJmd0OzsgDQombHQ7ZHJh ZnQtaWV0Zi1jY2FtcC08QlI+Jmd0OyAmZ3Q7ICZndDsgZ21wbHMtPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmc3MDktZnJhbWV3b3JrQHRvb2xzLmlldGYu b3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+ZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8L0ZP TlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+IA0KJmx0OzwvRk9OVD48QSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscyI+PEZPTlQgDQpmYWNlPUFyaWFsPm1haWx0bzpkcmFmdC1pZXRm LWNjYW1wLWdtcGxzPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPi08QlI+Jmd0OyANCmc3MDkt PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmZyYW1ld29y a0B0b29scy5pZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPmZyYW1ld29ya0B0b29scy5pZXRm Lm9yZzwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7ICZndDs8QlI+Jmd0OyANCiZndDsg Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogV2VkbmVzZGF5LCBKdWx5IDA3 LCAyMDEwIDExOjQzIA0KUE08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gDQpkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLWc3MDktPEJSPiZndDsgJmd0OyAmZ3Q7IGZyYW1ld29yay08QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyANCjAxLnR4dDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBIaSBMb3U8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyANCiZndDsg Jmd0OyAmZ3Q7IFRoYW5rcywgSSBhbHNvIHdvdWxkIGxpa2UgdG8gaGVhciBhYm91dCB0aGUgc2Ft ZS48QlI+Jmd0OyAmZ3Q7IA0KJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IFNuaWdkaG88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiZndDs8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgJmd0OyAmZ3Q7 IA0KJmd0OyAmZ3Q7IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XTxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDcsIDIw MTAgODozNyBBTTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVG86IFNuaWdkaG8gDQpCYXJk YWxhaTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQ2M6IDwvRk9OVD48QSANCmhyZWY9Im1h aWx0bzpjY2FtcEBpZXRmLm9yZyI+PEZPTlQgZmFjZT1BcmlhbD5jY2FtcEBpZXRmLm9yZzwvRk9O VD48L0E+PEZPTlQgDQpmYWNlPUFyaWFsPiAmbHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpjY2Ft cEBpZXRmLm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPm1haWx0bzpjY2FtcEBpZXRmLm9yZzwvRk9O VD48L0E+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7IDsgDQpkcmFmdC1pZXRmLWNjYW1wLTxCUj4mZ3Q7 ICZndDsgJmd0OyBnbXBscy08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PEEgDQpocmVm PSJtYWlsdG86ZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1Bcmlh bD5nNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzwvRk9OVD48L0E+PEZPTlQgZmFjZT1Bcmlh bD4gDQombHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzIj48 Rk9OVCANCmZhY2U9QXJpYWw+bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHM8L0ZPTlQ+PC9B PjxGT05UIGZhY2U9QXJpYWw+LTxCUj4mZ3Q7IA0KZzcwOS08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyA8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86ZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnIj48Rk9O VCANCmZhY2U9QXJpYWw+ZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPC9GT05UPjwvQT48Rk9OVCBm YWNlPUFyaWFsPiZndDs8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6 IFtDQ0FNUF0gQ29tbWVudCBvbiANCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS08QlI+Jmd0 OyAmZ3Q7ICZndDsgZnJhbWV3b3JrLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KMDEudHh0PEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgU25p Z2Robyw8QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBiZWxpZXZlIHRoZXJlIGhhcyBi ZWVuIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBvbiBob3cgDQp0bzxCUj4mZ3Q7ICZndDsgYmV0 dGVyPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhbGlnbiB0aGUgd29yayB3aXRoIA0KNDIw Mi4mbmJzcDsgVXNlIG9mIGNvbW1vbiBhcHByb2FjaGVzIGlzIG9mPEJSPiZndDsgY291cnNlPEJS PiZndDsgJmd0OyAmZ3Q7IG9uZSANCm9mPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUg bWFpbiBvYmplY3RpdmVzIG9mICpDKkNBTVAuJm5ic3A7IEkgbG9vayANCmZvcndhcmQgdG8gaGVh cmluZyBmcm9tPEJSPiZndDsgJmd0OyB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRy YWZ0IGFuZCANCmRpc2N1c3Npb24gY29udHJpYnV0b3JzIG9uIHRoZXJlIHByb2dyZXNzIG9uIHRo aXM8QlI+Jmd0OyAmZ3Q7IHBvaW50LjxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgTG91PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQomZ3Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiA3LzYvMjAxMCAzOjU5IFBNLCBTbmlnZGhv IEJhcmRhbGFpIA0Kd3JvdGU6PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgSGVsbG8s PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7IEkgaGF2ZSBhIGNvbW1lbnQgYW5kIGEgcXVlc3Rpb24gb24gDQpTZWN0aW9uIDMu MS4yLjEuIFRoaXM8QlI+Jmd0OyBzZWN0aW9uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgZGVzY3JpYmVzIA0KdGhlIGxpbmstcGFyYW1ldGVycyB0aGF0IGFyZSByZXF1aXJlZCBmb3Ig T1ROPEJSPiZndDsgc2VydmljZTxCUj4mZ3Q7ICZndDsgJmd0OyANCnJvdXRpbmc8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBwdXJwb3Nlcy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAN CiZndDsmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgTXkgY29tbWVudCBpcyBo b3cgYXJlIHdlIGdvaW5nIHRvIA0KYWR2ZXJ0aXNlIHRoZSBsb3ctb3JkZXIgT0RVajxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IGF2YWlsYWJpbGl0eSB3aXRoaW4gDQphIGhpZ2hlci1v cmRlciBjb250YWluZXIuIEZvciBleGFtcGxlLDxCUj4mZ3Q7ICZndDsgJmd0OyBjb25zaWRlciBh bjxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgT1RVMyBsaW5rIHdoaWNoIGhhcyAx NiB0aW1lLXNsb3RzIG9mIDIuNUcgZ3JhbnVsYXJpdHkgDQphbmQgdGhlbjxCUj4mZ3Q7ICZndDsg d2U8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBlc3RhYmxpc2ggYW4gT0RVMiANCnNl cnZpY2Ugb3ZlciB0aGUgbGluay4gQXQgdGhpcyBwb2ludCBpbiB0aW1lPEJSPiZndDsgJmd0OyB0 aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQpPVFUzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgbGluayBoYXMgMTIgdGltZS1zbG90cyBhdmFpbGFibGUgZm9yIE9EVTIgDQpzZXJ2aWNlcyBh bmQgdXAgdG88QlI+Jmd0OyAmZ3Q7IDEyKzQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 OyB0aW1lLXNsb3RzIA0KYXZhaWxhYmxlIGZvciBPRFUxIHNlcnZpY2VzICg0IE9EVTFzIGFyZSBj b250YWluZWQ8QlI+Jmd0OyAmZ3Q7IG92ZXI8QlI+Jmd0OyANCiZndDsgJmd0OyB0aGU8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBPRFUyKS4gU28gaXQgaXMgb2J2aW91cyBmcm9tIHRo aXMgDQpleGFtcGxlIHRoYXQgdGhlIG51bWJlciBvZjxCUj4mZ3Q7ICZndDsgdGltZS08QlI+Jmd0 OyAmZ3Q7ICZndDsgc2xvdHM8QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IGF2YWls YWJsZSBpcyBkaWZmZXJlbnQgYmFzZWQgb24gdGhlIHNpZ25hbC10eXBlIChpLmUuIA0KT0RVMSBh bmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgT0RVMikuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgSG93IGRvIHdlIA0KYWRkcmVzcyB0aGlzIGlzc3VlIGJhc2VkIG9uIHRoZSBhcHByb2FjaCBz cGVjaWZpZWQ8QlI+Jmd0OyBpbjxCUj4mZ3Q7ICZndDsgJmd0OyANCnRoZTxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGRyYWZ0PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PEJSPiZndDsg Jmd0OyANCiZndDsgJmd0OyAmZ3Q7Jmd0OyBNeSBvdGhlciBxdWVzdGlvbiBpcyB3aHkgbm90IHNp bXBseSBhZHZlcnRpemUgdGhlIA0KYXZhaWxhYmxlPEJSPiZndDsgJmd0OyBudW1iZXI8QlI+Jmd0 OyAmZ3Q7ICZndDsgb2Y8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiZndDsmZ3Q7IE9EVTAsIE9E VTEsIE9EVTIsIC4uLiwgT0RVNCBjb250YWluZXIgaW5zdGFuY2VzIG9yIHRoZTxCUj4mZ3Q7ICZn dDsgDQplcXVpdmFsZW50PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgYmFuZHdpZHRo IGluIGJ5dGVzL3NlYyB3aXRoaW4gYSBsaW5rPyANClRoaXMgYXBwcm9hY2ggc2VlbXMgdG88QlI+ Jmd0OyBiZTxCUj4mZ3Q7ICZndDsgJmd0OyBtb3JlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQom Z3Q7Jmd0OyBpbi1saW5lIHdpdGggdGhlIGdlbmVyYWwgYXBwcm9hY2ggb3V0bGluZWQgaW4gUkZD LTQyMDIuIFJlZmVyPEJSPiZndDsgDQp0bzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNlY3Rpb248 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAzLjQgaW4gUkZDIA0KNDIwMiBmb3IgYW4g ZXhhbXBsZSB0aGF0IHNob3dzIG11bHRpcGxlIElTQ0RzIGJlaW5nPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQomZ3Q7Jmd0OyBhZHZlcnRpc2VkIHBlciBWQyByYXRlIGZvciBhbiBTREggbGluay4g VGhlIGFkZGl0aW9uYWwgYmVuZWZpdDxCUj4mZ3Q7IA0KJmd0OyBpczxCUj4mZ3Q7ICZndDsgJmd0 OyB0aGF0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgdGhlIGFkdmVydGlzZW1lbnQg DQppcyBUUyBzaXplIGluZGVwZW5kZW50IGFuZCBoZW5jZSB3aWxsPEJSPiZndDsgc2ltcGxpZnk8 QlI+Jmd0OyAmZ3Q7ICZndDsgDQp0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBp bXBsZW1lbnRhdGlvbi48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiZndDsmZ3Q7PEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgUmVnYXJkczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0K Jmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBTbmlnZGhvPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PEJSPiZndDsgDQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyANCjwvRk9OVD48QSBocmVmPSJtYWlsdG86Q0NB TVBAaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5DQ0FNUEBpZXRmLm9yZzwvRk9OVD48L0E+ PEZPTlQgZmFjZT1BcmlhbD4gJmx0OzwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpDQ0FNUEBpZXRm Lm9yZyI+PEZPTlQgDQpmYWNlPUFyaWFsPm1haWx0bzpDQ0FNUEBpZXRmLm9yZzwvRk9OVD48L0E+ PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7PEJSPiZndDsgJmd0OyANCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8 L0ZPTlQ+PEEgDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wIj48Rk9OVCANCmZhY2U9QXJpYWw+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jY2FtcDwvRk9OVD48L0E+PEJSPjxGT05UIA0KZmFjZT1BcmlhbD4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZsdDs8L0ZPTlQ+PEEgDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NjYW1wIj48Rk9OVCANCmZhY2U9QXJpYWw+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcDwvRk9OVD48L0E+PEZPTlQgDQpmYWNlPUFyaWFsPiZndDs8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KQ0NBTVAg bWFpbGluZyBsaXN0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PEEgDQpocmVm PSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciPjxGT05UIGZhY2U9QXJpYWw+Q0NBTVBAaWV0Zi5vcmc8 L0ZPTlQ+PC9BPjxGT05UIA0KZmFjZT1BcmlhbD4gJmx0OzwvRk9OVD48QSBocmVmPSJtYWlsdG86 Q0NBTVBAaWV0Zi5vcmciPjxGT05UIA0KZmFjZT1BcmlhbD5tYWlsdG86Q0NBTVBAaWV0Zi5vcmc8 L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0OzxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDsg Jmd0OyA8L0ZPTlQ+PEEgDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NjYW1wIj48Rk9OVCANCmZhY2U9QXJpYWw+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jY2FtcDwvRk9OVD48L0E+PEJSPjxGT05UIA0KZmFjZT1BcmlhbD4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZsdDs8L0ZPTlQ+PEEgDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wIj48Rk9OVCANCmZhY2U9QXJpYWw+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvRk9OVD48L0E+PEZPTlQgDQpmYWNlPUFyaWFs PiZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZn dDsgJmd0OyAmZ3Q7IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgQ0NBTVAgbWFpbGluZyANCmxpc3Q8QlI+Jmd0OyAmZ3Q7 ICZndDsgPC9GT05UPjxBIGhyZWY9Im1haWx0bzpDQ0FNUEBpZXRmLm9yZyI+PEZPTlQgDQpmYWNl PUFyaWFsPkNDQU1QQGlldGYub3JnPC9GT05UPjwvQT48QlI+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7 ICZndDsgJmd0OyANCjwvRk9OVD48QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NjYW1wIj48Rk9OVCANCmZhY2U9QXJpYWw+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcDwvRk9OVD48L0E+PEJSPjxGT05UIA0KZmFjZT1BcmlhbD4m Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZn dDsgQ0NBTVAgDQptYWlsaW5nIGxpc3Q8QlI+Jmd0OyA8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOkND QU1QQGlldGYub3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+Q0NBTVBAaWV0Zi5vcmc8L0ZPTlQ+PC9B PjxCUj48Rk9OVCBmYWNlPUFyaWFsPiZndDsgPC9GT05UPjxBIA0KaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcCI+PEZPTlQgDQpmYWNlPUFyaWFsPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L0ZPTlQ+PC9BPjxCUj48L0JP RFk+PC9IVE1MPg0K --Boundary_(ID_iHgPpmT1wkTQ/2vsDApcQg)-- From IBryskin@advaoptical.com Fri Jul 9 05:59:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4363A6A6F for ; Fri, 9 Jul 2010 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w-q9iohKwWl for ; Fri, 9 Jul 2010 05:59:39 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 726933A6A48 for ; Fri, 9 Jul 2010 05:59:37 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o69CxG8C022685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 9 Jul 2010 14:59:19 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Jul 2010 14:59:16 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Fri, 9 Jul 2010 08:59:13 -0400 From: Igor Bryskin To: "BELOTTI, SERGIO (SERGIO)" , "Sadler, Jonathan B." Date: Fri, 9 Jul 2010 08:58:47 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E32E@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-09_01:2010-02-06, 2010-07-09, 2010-07-09 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 12:59:40 -0000 Sergio, You wrote: " My understanding of Switching Cap is that different Switching Cap would b= e linked to different technologies imply different switching capabilities IB>> We do have PSC1-PSC4 for packet switching ( note, one per MPLS DP hier= archy level, I suggest the same for OTN). We have also agreed that a single= L2SC is not enough for Ethernet technology, in fact, we need separate swic= thcaps for STAG switching, EPL, EVPL, etc.=20 " : we have not created different Switching Cap for VC4 or VC12 in SDH".=20 IB>> IMO this is the reason why GMPLS in TDM has never really taken off. Igor Best Regards sergio Best Regards Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: gioved=EC 8 luglio 2010 20.40 A: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Be= rger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired le= vel of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in ODU3 i= n ODU4) - while this may be the worst case, it is the possible case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- 400= G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach th= an just creating new SwitchingTypes -- especially since the signals support= ed within each of these is the same (e.g. an ODU1 over an ODU2 is the same = as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I think OTN links require more than one switchcaps: as many as the depth of= the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework document > before we can embark on any proposals to the problem. I am still not clea= r > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN specific > ISCD. The combination of Switching Capability and Encoding type of RFC420= 2 > ISCD allows for specifying both multiplexing capabilities and OTN layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create OTN > hierarchies and constrain LO connections to HO containers, one needs to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM networks= , > you know the resource is allocated based on TS, so the available TS shoul= d > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will fin= d > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > you have to advertise a new TE link or put this FA as a component link of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service routin= g > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the OTU= 3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over the > >> ODU2). So it is obvious from this example that the number of time-slot= s > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is that > >> the advertisement is TS size independent and hence will simplify the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Fri Jul 9 06:02:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753B13A6A73 for ; Fri, 9 Jul 2010 06:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z7yRAK9Tm+i for ; Fri, 9 Jul 2010 06:02:03 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id F41763A6A48 for ; Fri, 9 Jul 2010 06:02:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTDcdvdd0h0Xdz73hOFeCgNiGwkJqE3Dg@postini.com; Fri, 09 Jul 2010 06:02:08 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 9 Jul 2010 05:59:15 -0700 From: John E Drake To: Fatai Zhang , Igor Bryskin , Snigdho Bardalai , "Sadler, Jonathan B." , Lou Berger Date: Fri, 9 Jul 2010 05:59:14 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsfS4I10GQAPXqrTvi2cb6gm9ZiGgAGQL4g Message-ID: <5E893DB832F57341992548CDBB3331639843878669@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> <0fdd01cb1f4b$1b913320$604c460a@china.huawei.com> In-Reply-To: <0fdd01cb1f4b$1b913320$604c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:02:05 -0000 > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Friday, July 09, 2010 2:43 AM > To: Igor Bryskin; Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Lo= u > Berger > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor and all, > > I think we are at the same line about the requrement of network policy an= d > planning. For transport networks, the tunnels for transporting service > usually should be planed under some policy. Therefore, we may need to > differentiate full lambda LSP or sub lambda LSP when creating a > connection. We would like to reflect the requirement much clearer in the > FWK document. > > However, to meet the requirment, I personally think that maybe we don't > need to extend ISC type. For example, Lo ODU, Ho ODU, SHO ODU, they are > relative to each other. For example, ODU1->ODU2->ODU3->ODU4, how to regar= d > ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if ther= e > is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 > (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in thi= s > case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? [JD] I agree. Switching capability is very different from network layer indicat= or. > > Another point is about why the existing ISCD is not competent. > > We all know the history of the GMPLS, which is inherited from MPLS. In > MPLS networks, we can only use floating point number to identify the > bandwidth. However, for the TDM network, the resource is alloacted based > on the TS, so it is very naturally to use TS (or per signal type) to > encode the bandwidth. [JD] You seem to be ignoring the fact that for both SDH/SONET and lambda switchi= ng, floating point bytes per second is currently used. > If we use the floating point number, the routing > still need to convert the floating point to see how many TS or signal > (ODUk) can be supported to create the connections. [JD] If bytes per second is used, there is no need to advertise TS. Your reason= for not using bytes per second boils down to you simply not liking it. > Secondly, if we use the > existing ISCD (we just advertise Max LSP bandwidth (e.g., ODU4) and Min > LSP bandwidth (ODU1), how to know whether it can support ODUflex; How to > know if it can support ODU2 and ODU3 if the equipments may have some > constraits. Thirdly, in TDM networks, it is not efficient for scalability > issue if we use the existing ISCD, because it needs 32 bits to indicate > the bandwidth (Actually, we only need much fewer bits to identify the > signal type (e.g., ODUk)). [JD] No one is advocating using the existing ISC, rather whatever is designed sh= ould be consistent with the rest of GMPLS. In particular we should have bandwidth advertised in bytes per second, eigh= t priority levels each with total unreserved bandwidth, a simple indication= (such as a bit vector) of what switching granularities are currently suppo= rted, and ODU flex bandwidth by priority level. > > Hope this can clarify your concern. > > > > > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > > To: "Snigdho Bardalai" >; "Sadler, Jonathan B." > >; "Joh= n > E Drake" >; "Fatai Zhang" > >; "Lou Berger" > > > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > > Sent: Friday, July 09, 2010 6:15 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > No, just network policies and planning. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 6:08 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org framework@tools.ietf.org> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > It is not clear why are you requiring the constraint for a connection to > take a specific level in the hierarchy end-to-end? Is it a hardware > specific issue you are trying to address? > > Snigdho > > > -----Original Message----- > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Igor Bryskin > > Sent: Thursday, July 08, 2010 11:58 AM > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > >If that is the case how can you constraint a connection to a >specific > > hierarchy end-to-end? > > > > You don't have to. You MAY constrain a connection to take, for example, > > only LO links. But you can also allow the connection to take either HO > > or LO links. Also, keep in mind that GMPLS allows to advertise OTN link > > to belong to more than one OTN layer. > > > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > That means that the signal can be at different hierarchies over > > different OTN links along the route. > > > > If that is the case how can you constraint a connection to a specific > > hierarchy end-to-end? I think all you can do is find an OTN link that > > can support the required signal-type. > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 11:46 AM > > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > > Lou Berger > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Because the same signal (and connection) could be on a different > > > hierarchy level. > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Thursday, July 08, 2010 2:44 PM > > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > > Berger > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Why not simply create switching capability descriptors per hierarchy > > > (i.e. ODU0, ODU1,...)? > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Thursday, July 08, 2010 11:40 AM > > > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai > > Zhang; > > > > Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > There is a lot of swcaps available :=3D) > > > > Separate swcaps provide an easy way to constrain connection to a > > > > desired level of hierarchy. > > > > > > > > -----Original Message----- > > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > > Sent: Thursday, July 08, 2010 2:36 PM > > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > > Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > > in > > > > ODU3 in ODU4) - while this may be the worst case, it is the > > possible > > > > case too. > > > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > > speed" > > > -- > > > > 400G?) the depth of the hierarchy will grow. > > > > > > > > This makes me wonder: wouldn't a generalized method be a better > > > > approach than just creating new SwitchingTypes -- especially since > > > the > > > > signals supported within each of these is the same (e.g. an ODU1 > > over > > > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > > > > > Jonathan Sadler > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 1:31 PM > > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls-g709- > > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document > > > > > before we can embark on any proposals to the problem. I am still > > > not > > > > clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > plane, > > > > and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > of > > > > > advertising of TE links, and there is no reason to invent an OTN > > > > specific > > > > > ISCD. The combination of Switching Capability and Encoding type > > of > > > > RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > > layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > > have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls-g709- > > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control > > > > > plane, no matter how you encode the routing information. For TDM > > > > networks, > > > > > you know the resource is allocated based on TS, so the available > > TS > > > > should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > > I > > > > think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > will > > > > find > > > > > that one of your suggestions is adopted (i.e., simply advertize > > the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > ODU1, > > > > > you have to advertise a new TE link or put this FA as a component > > > > link of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > = > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: > > >; > > > gmpls- > > > > > g709-framework@tools.ietf.org framework@tools.ietf.org> ietf-ccamp-gmpls> - > > g709- > > > > > framework@tools.ietf.org > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org > > ; draft-ietf-ccamp- > > > > gmpls- > > > > > g709-framework@tools.ietf.org framework@tools.ietf.org> ietf-ccamp-gmpls> - > > g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > one of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > > the > > > > > > draft and discussion contributors on there progress on this > > > point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, > > > > consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > > we > > > > > >> establish an ODU2 service over the link. At this point in time > > > the > > > > OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to > > > 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > > over > > > > the > > > > > >> ODU2). So it is obvious from this example that the number of > > > time- > > > > slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > > ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > number > > > > of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to > > be > > > > more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer > > to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit > > > is > > > > that > > > > > >> the advertisement is TS size independent and hence will > > simplify > > > > the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > From sergio.belotti@alcatel-lucent.com Fri Jul 9 06:28:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217B13A6A6C for ; Fri, 9 Jul 2010 06:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPJoaHffwRlS for ; Fri, 9 Jul 2010 06:28:18 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 2D8A63A69BF for ; Fri, 9 Jul 2010 06:28:18 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o69DRsvA016170 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jul 2010 15:28:16 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 9 Jul 2010 15:27:34 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: John E Drake Date: Fri, 9 Jul 2010 15:27:33 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsfS4I10GQAPXqrTvi2cb6gm9ZiGgAGQL4gAADtk/A= Message-ID: References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> <0fdd01cb1f4b$1b913320$604c460a@china.huawei.com> <5E893DB832F57341992548CDBB3331639843878669@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639843878669@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:28:21 -0000 Hi John, See in line Best Regards sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Joh= n E Drake Inviato: venerd=EC 9 luglio 2010 14.59 A: Fatai Zhang; Igor Bryskin; Snigdho Bardalai; Sadler, Jonathan B.; Lou Be= rger Cc: ccamp@ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Friday, July 09, 2010 2:43 AM > To: Igor Bryskin; Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Lo= u > Berger > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor and all, > > I think we are at the same line about the requrement of network policy an= d > planning. For transport networks, the tunnels for transporting service > usually should be planed under some policy. Therefore, we may need to > differentiate full lambda LSP or sub lambda LSP when creating a > connection. We would like to reflect the requirement much clearer in the > FWK document. > > However, to meet the requirment, I personally think that maybe we don't > need to extend ISC type. For example, Lo ODU, Ho ODU, SHO ODU, they are > relative to each other. For example, ODU1->ODU2->ODU3->ODU4, how to regar= d > ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if ther= e > is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 > (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in thi= s > case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? [JD] I agree. Switching capability is very different from network layer indicat= or. > > Another point is about why the existing ISCD is not competent. > > We all know the history of the GMPLS, which is inherited from MPLS. In > MPLS networks, we can only use floating point number to identify the > bandwidth. However, for the TDM network, the resource is alloacted based > on the TS, so it is very naturally to use TS (or per signal type) to > encode the bandwidth. [JD] You seem to be ignoring the fact that for both SDH/SONET and lambda switchi= ng, floating point bytes per second is currently used. [SB] I do not want to answer on behalf of Fatai, but I do not think Fatai i= s ignoring that. He simply pointed out the fact using byte per second is no= t the best way to advertise fixed containers like SDH or OTN. In fact,to be= practical, I would be interested to see implementation of transport equip= ment implementing GMPLS (and restoration) using the byte per second for BW = advertisement and not e.g. number of containers (VC12, VC3, or VC4 in case = of SDH). So, theoretically you're right but practically a different semanti= c it would be better. > If we use the floating point number, the routing > still need to convert the floating point to see how many TS or signal > (ODUk) can be supported to create the connections. [JD] If bytes per second is used, there is no need to advertise TS. Your reason= for not using bytes per second boils down to you simply not liking it. > Secondly, if we use the > existing ISCD (we just advertise Max LSP bandwidth (e.g., ODU4) and Min > LSP bandwidth (ODU1), how to know whether it can support ODUflex; How to > know if it can support ODU2 and ODU3 if the equipments may have some > constraits. Thirdly, in TDM networks, it is not efficient for scalability > issue if we use the existing ISCD, because it needs 32 bits to indicate > the bandwidth (Actually, we only need much fewer bits to identify the > signal type (e.g., ODUk)). [JD] No one is advocating using the existing ISC, rather whatever is designed sh= ould be consistent with the rest of GMPLS. In particular we should have bandwidth advertised in bytes per second, eigh= t priority levels each with total unreserved bandwidth, a simple indication= (such as a bit vector) of what switching granularities are currently suppo= rted, and ODU flex bandwidth by priority level. [SB] I think we are not too far here. We can discuss about the bytes per se= cond, but for the rest I think our attempt in the routing OTN draft is to f= ollow your basic suggestion. Please have a look also to the OTN routing dra= ft. It would be very beneficial to have you comment/suggestion on that. > > Hope this can clarify your concern. > > > > > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > > To: "Snigdho Bardalai" >; "Sadler, Jonathan B." > >; "Joh= n > E Drake" >; "Fatai Zhang" > >; "Lou Berger" > > > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > > Sent: Friday, July 09, 2010 6:15 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > No, just network policies and planning. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 6:08 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org framework@tools.ietf.org> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > It is not clear why are you requiring the constraint for a connection to > take a specific level in the hierarchy end-to-end? Is it a hardware > specific issue you are trying to address? > > Snigdho > > > -----Original Message----- > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Igor Bryskin > > Sent: Thursday, July 08, 2010 11:58 AM > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > >If that is the case how can you constraint a connection to a >specific > > hierarchy end-to-end? > > > > You don't have to. You MAY constrain a connection to take, for example, > > only LO links. But you can also allow the connection to take either HO > > or LO links. Also, keep in mind that GMPLS allows to advertise OTN link > > to belong to more than one OTN layer. > > > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > That means that the signal can be at different hierarchies over > > different OTN links along the route. > > > > If that is the case how can you constraint a connection to a specific > > hierarchy end-to-end? I think all you can do is find an OTN link that > > can support the required signal-type. > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 11:46 AM > > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > > Lou Berger > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Because the same signal (and connection) could be on a different > > > hierarchy level. > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Thursday, July 08, 2010 2:44 PM > > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > > Berger > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Why not simply create switching capability descriptors per hierarchy > > > (i.e. ODU0, ODU1,...)? > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Thursday, July 08, 2010 11:40 AM > > > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai > > Zhang; > > > > Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > There is a lot of swcaps available :=3D) > > > > Separate swcaps provide an easy way to constrain connection to a > > > > desired level of hierarchy. > > > > > > > > -----Original Message----- > > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > > Sent: Thursday, July 08, 2010 2:36 PM > > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > > Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > > in > > > > ODU3 in ODU4) - while this may be the worst case, it is the > > possible > > > > case too. > > > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > > speed" > > > -- > > > > 400G?) the depth of the hierarchy will grow. > > > > > > > > This makes me wonder: wouldn't a generalized method be a better > > > > approach than just creating new SwitchingTypes -- especially since > > > the > > > > signals supported within each of these is the same (e.g. an ODU1 > > over > > > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > > > > > Jonathan Sadler > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 1:31 PM > > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls-g709- > > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document > > > > > before we can embark on any proposals to the problem. I am still > > > not > > > > clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > plane, > > > > and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > of > > > > > advertising of TE links, and there is no reason to invent an OTN > > > > specific > > > > > ISCD. The combination of Switching Capability and Encoding type > > of > > > > RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > > layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > > have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls-g709- > > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control > > > > > plane, no matter how you encode the routing information. For TDM > > > > networks, > > > > > you know the resource is allocated based on TS, so the available > > TS > > > > should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > > I > > > > think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > will > > > > find > > > > > that one of your suggestions is adopted (i.e., simply advertize > > the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > ODU1, > > > > > you have to advertise a new TE link or put this FA as a component > > > > link of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > = > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: > > >; > > > gmpls- > > > > > g709-framework@tools.ietf.org framework@tools.ietf.org> ietf-ccamp-gmpls> - > > g709- > > > > > framework@tools.ietf.org > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org > > ; draft-ietf-ccamp- > > > > gmpls- > > > > > g709-framework@tools.ietf.org framework@tools.ietf.org> ietf-ccamp-gmpls> - > > g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > one of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > > the > > > > > > draft and discussion contributors on there progress on this > > > point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, > > > > consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > > we > > > > > >> establish an ODU2 service over the link. At this point in time > > > the > > > > OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to > > > 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > > over > > > > the > > > > > >> ODU2). So it is obvious from this example that the number of > > > time- > > > > slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > > ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > number > > > > of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to > > be > > > > more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer > > to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit > > > is > > > > that > > > > > >> the advertisement is TS size independent and hence will > > simplify > > > > the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Fri Jul 9 06:30:29 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D2E63A6A8E; Fri, 9 Jul 2010 06:30:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100709133024.6D2E63A6A8E@core3.amsl.com> Date: Fri, 9 Jul 2010 06:30:04 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:30:29 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using RSVP-TE Author(s) : E. Bellagamba, et al. Filename : draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-02.txt Pages : 19 Date : 2010-07-09 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a common set of TLVs that can be carried on RSVP-TE protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09061846.I-D@ietf.org> --NextPart-- From diego.caviglia@ericsson.com Fri Jul 9 06:32:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F413A6A9D for ; Fri, 9 Jul 2010 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H84Wj0x4yQ3O for ; Fri, 9 Jul 2010 06:32:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B09293A6A8C for ; Fri, 9 Jul 2010 06:30:48 -0700 (PDT) X-AuditID: c1b4fb39-b7c39ae000000c17-db-4c3724810712 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.A8.03095.184273C4; Fri, 9 Jul 2010 15:30:41 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jul 2010 15:30:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 15:27:39 +0200 Message-ID: In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E32E@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt [a little bit OT] Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAATus0A== References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com><4C349F23.5040301@labn.net><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com><07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com><0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E32E@atl-srv-exgen.atl.advaoptical.com> From: "Diego Caviglia" To: "Igor Bryskin" , "BELOTTI, SERGIO (SERGIO)" , "Sadler,Jonathan B." X-OriginalArrivalTime: 09 Jul 2010 13:30:41.0419 (UTC) FILETIME=[ED0C45B0:01CB1F6A] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt [a little bit OT] X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:32:34 -0000 Hi Igor, A quick one. " : we have not created different Switching Cap for VC4 or VC12 in = SDH".=20 IB>> IMO this is the reason why GMPLS in TDM has never really taken off. [dc] strange sentence for a thread where lots of people are struggling = to have GMPLS on OTN that is TDM :-) BTW I can give you a lot of examples of network where GMPLS is driving = SDH and I'm pretty sure the other colleagues can do the same. BR D line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Igor Bryskin Sent: venerd=EC 9 luglio 2010 14.59 To: BELOTTI, SERGIO (SERGIO); Sadler,Jonathan B. Cc: ccamp@ietf.org; Snigdho Bardalai; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Sergio, You wrote: " My understanding of Switching Cap is that different Switching Cap = would be linked to different technologies imply different switching = capabilities IB>> We do have PSC1-PSC4 for packet switching ( note, one per MPLS DP = hierarchy level, I suggest the same for OTN). We have also agreed that a = single L2SC is not enough for Ethernet technology, in fact, we need = separate swicthcaps for STAG switching, EPL, EVPL, etc.=20 " : we have not created different Switching Cap for VC4 or VC12 in = SDH".=20 IB>> IMO this is the reason why GMPLS in TDM has never really taken off. Igor Best Regards sergio Best Regards Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di = Igor Bryskin Inviato: gioved=EC 8 luglio 2010 20.40 A: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou = Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Oggetto: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt There is a lot of swcaps available :=3D) Separate swcaps provide an easy way to constrain connection to a desired = level of hierarchy.=20 -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Thursday, July 08, 2010 2:36 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou = Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in = ODU3 in ODU4) - while this may be the worst case, it is the possible = case too. As new signals/rates are added (e.g. ODU5 for "the next great speed" -- = 400G?) the depth of the hierarchy will grow. This makes me wonder: wouldn't a generalized method be a better approach = than just creating new SwitchingTypes -- especially since the signals = supported within each of these is the same (e.g. an ODU1 over an ODU2 is = the same as an ODU1 over an ODU3...) Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Igor Bryskin Sent: Thursday, July 08, 2010 1:31 PM To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt I think OTN links require more than one switchcaps: as many as the depth = of the deepest possible OTN DP hierarchy, for example: typedef enum { LSPSwitchType_Unknown =3D0 /* Unknown */ , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ , LSPSwitchType_L2SC =3D50 /* L2SC */ , LSPSwitchType_TDM =3D100 /* TDM */ /*****/ , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ , LSPSwitchType_LSC =3D150 /* LSC */ , LSPSwitchType_FSC =3D200 /* FSC */ }e_LSPSwitchType; -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 08, 2010 1:59 PM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt What do you mean by "different switchcaps"? > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of > Igor Bryskin > Sent: Thursday, July 08, 2010 10:53 AM > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > Snigdho, >=20 >=20 >=20 >=20 >=20 > =D8 I think we need to sort out the issues with the framework = document > before we can embark on any proposals to the problem. I am still not = clear > why do we have to deviate from the general approach that has been > established in RFC 4202. >=20 >=20 >=20 > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, = and > it is highly desirable to adhere to the layer independent paradigm of > advertising of TE links, and there is no reason to invent an OTN = specific > ISCD. The combination of Switching Capability and Encoding type of = RFC4202 > ISCD allows for specifying both multiplexing capabilities and OTN = layer > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > another reserved 16 bits. >=20 >=20 >=20 > >Additionally, I do not see any reason to advertise a new TE-link to > represent >the low-order ODUj bandwidth within the high-order = containers. > This is simply >blowing up the solution to a very simple problem. >=20 >=20 >=20 > IB>> Here I disagree. In order to give a user possibility to create = OTN > hierarchies and constrain LO connections to HO containers, one needs = to > advertise OTN links with different switchcaps. >=20 >=20 >=20 > Cheers, >=20 > Igor >=20 >=20 >=20 > Regards >=20 > Snigdho >=20 >=20 >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 07, 2010 6:33 PM > To: Snigdho Bardalai; Lou Berger > Cc: ccamp@ietf.org; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > Hi Snigdho and Lou, >=20 >=20 >=20 > Yes, we have lots of off-line discussions among authors and other > interested experts, and we think the proposal described in "draft- > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more = feasible > for OTN networks. >=20 >=20 >=20 > The framework draft just tells you what information needed for control > plane, no matter how you encode the routing information. For TDM = networks, > you know the resource is allocated based on TS, so the available TS = should > be get or induced before creating cross-connect. >=20 >=20 >=20 > If you are trying to find how to encode the routing information, I = think > you need go to the routing drafts (info model and encoding). >=20 >=20 >=20 > If you look at the routing drafts (info model and encoding), you will = find > that one of your suggestions is adopted (i.e., simply advertize the > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). >=20 >=20 >=20 > One more thing for your first comment: >=20 > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for = ODU1, > you have to advertise a new TE link or put this FA as a component link = of > an existing TE link (like RFC4206bis). >=20 >=20 >=20 >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > ----- Original Message ----- >=20 > From: "Snigdho Bardalai" > >=20 > To: "Lou Berger" > >=20 > Cc: >; = g709-framework@tools.ietf.org framework@tools.ietf.org> > >=20 > Sent: Wednesday, July 07, 2010 11:43 PM >=20 > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 >=20 >=20 > > Hi Lou > > > > Thanks, I also would like to hear about the same. > > > > Snigdho > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 07, 2010 8:37 AM > > To: Snigdho Bardalai > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709-framework@tools.ietf.org framework@tools.ietf.org> > > Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > > Snigdho, > > I believe there has been some off-line discussion on how to better > > align the work with 4202. Use of common approaches is of course one = of > > the main objectives of *C*CAMP. I look forward to hearing from the > > draft and discussion contributors on there progress on this point. > > > > Lou > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > >> Hello, > >> > >> I have a comment and a question on Section 3.1.2.1. This section > >> describes the link-parameters that are required for OTN service = routing > >> purposes. > >> > >> My comment is how are we going to advertise the low-order ODUj > >> availability within a higher-order container. For example, consider = an > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > >> establish an ODU2 service over the link. At this point in time the = OTU3 > >> link has 12 time-slots available for ODU2 services and up to 12+4 > >> time-slots available for ODU1 services (4 ODU1s are contained over = the > >> ODU2). So it is obvious from this example that the number of = time-slots > >> available is different based on the signal-type (i.e. ODU1 and = ODU2). > >> How do we address this issue based on the approach specified in the > draft? > >> > >> My other question is why not simply advertize the available number = of > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > >> bandwidth in bytes/sec within a link? This approach seems to be = more > >> in-line with the general approach outlined in RFC-4202. Refer to > section > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > >> advertised per VC rate for an SDH link. The additional benefit is = that > >> the advertisement is TS size independent and hence will simplify = the > >> implementation. > >> > >> Regards > >> > >> Snigdho > >> > >> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From pietro_vittorio.grandi@alcatel-lucent.com Fri Jul 9 06:32:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E187C3A6BA7 for ; Fri, 9 Jul 2010 06:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9AU+mNlPATO for ; Fri, 9 Jul 2010 06:32:35 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 821CD3A6AA8 for ; Fri, 9 Jul 2010 06:31:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o69DTfVD018693 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jul 2010 15:30:44 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 9 Jul 2010 15:29:54 +0200 From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" To: John E Drake , Fatai Zhang , Igor Bryskin , Snigdho Bardalai , "Sadler, Jonathan B." , Lou Berger Date: Fri, 9 Jul 2010 15:29:53 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsfS4I10GQAPXqrTvi2cb6gm9ZiGgAGQL4gAACul7A= Message-ID: References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> <0fdd01cb1f4b$1b913320$604c460a@china.huawei.com> <5E893DB832F57341992548CDBB3331639843878669@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639843878669@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:32:38 -0000 Hello John, in line. > Hi Igor and all, > > I think we are at the same line about the requrement of network policy an= d > planning. For transport networks, the tunnels for transporting service > usually should be planed under some policy. Therefore, we may need to > differentiate full lambda LSP or sub lambda LSP when creating a > connection. We would like to reflect the requirement much clearer in the > FWK document. > > However, to meet the requirment, I personally think that maybe we don't > need to extend ISC type. For example, Lo ODU, Ho ODU, SHO ODU, they are > relative to each other. For example, ODU1->ODU2->ODU3->ODU4, how to regar= d > ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if ther= e > is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 > (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in thi= s > case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? [JD] I agree. Switching capability is very different from network layer indicat= or. > > Another point is about why the existing ISCD is not competent. > > We all know the history of the GMPLS, which is inherited from MPLS. In > MPLS networks, we can only use floating point number to identify the > bandwidth. However, for the TDM network, the resource is alloacted based > on the TS, so it is very naturally to use TS (or per signal type) to > encode the bandwidth. [JD] You seem to be ignoring the fact that for both SDH/SONET and lambda switchi= ng, floating point bytes per second is currently used. [[PG]] I do not want to make any polemics here, but being in the transport= since a lot of years, I had the occasion to see several implementations in= field using the OIF format also for the I-NNI, and they are so many that I= am not really sure that IETF ISCD format is in field for something differe= nt from MPLS. The OIF format, I would recall, counts signal types. This is useful in order to minimize crank-backs and is also more compact with respect to c= urrent IETF ISCD, giving more information too. > If we use the floating point number, the routing > still need to convert the floating point to see how many TS or signal > (ODUk) can be supported to create the connections. [JD] If bytes per second is used, there is no need to advertise TS. Your reason= for not using bytes per second boils down to you simply not liking it. > Secondly, if we use the > existing ISCD (we just advertise Max LSP bandwidth (e.g., ODU4) and Min > LSP bandwidth (ODU1), how to know whether it can support ODUflex; How to > know if it can support ODU2 and ODU3 if the equipments may have some > constraits. Thirdly, in TDM networks, it is not efficient for scalability > issue if we use the existing ISCD, because it needs 32 bits to indicate > the bandwidth (Actually, we only need much fewer bits to identify the > signal type (e.g., ODUk)). [JD] No one is advocating using the existing ISC, rather whatever is designed sh= ould be consistent with the rest of GMPLS. In particular we should have bandwidth advertised in bytes per second, eigh= t priority levels each with total unreserved bandwidth, a simple indication= (such as a bit vector) of what switching granularities are currently suppo= rted, and ODU flex bandwidth by priority level. [[PG]] The encoding drafts fulfills requirements, may be you could read it = and comment. Your comments will be welcome. I would like to remark again that the bandwidth in bytes per second is not = useful in any situation, while counting signal types for sure is. So it is= in my mind too simple to say this just because of tradition and the subject should be fronted withou= t any bias. Pietro > > Hope this can clarify your concern. > > > > > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > > To: "Snigdho Bardalai" >; "Sadler, Jonathan B." > >; "Joh= n > E Drake" >; "Fatai Zhang" > >; "Lou Berger" > > > Cc: >; g709-framework@tools.ietf.org framework@tools.ietf.org> > > Sent: Friday, July 09, 2010 6:15 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > No, just network policies and planning. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 08, 2010 6:08 PM > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org framework@tools.ietf.org> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > It is not clear why are you requiring the constraint for a connection to > take a specific level in the hierarchy end-to-end? Is it a hardware > specific issue you are trying to address? > > Snigdho > > > -----Original Message----- > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Igor Bryskin > > Sent: Thursday, July 08, 2010 11:58 AM > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > Lou Berger > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > >If that is the case how can you constraint a connection to a >specific > > hierarchy end-to-end? > > > > You don't have to. You MAY constrain a connection to take, for example, > > only LO links. But you can also allow the connection to take either HO > > or LO links. Also, keep in mind that GMPLS allows to advertise OTN link > > to belong to more than one OTN layer. > > > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > Berger > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > That means that the signal can be at different hierarchies over > > different OTN links along the route. > > > > If that is the case how can you constraint a connection to a specific > > hierarchy end-to-end? I think all you can do is find an OTN link that > > can support the required signal-type. > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Thursday, July 08, 2010 11:46 AM > > > To: Snigdho Bardalai; Sadler, Jonathan B.; John E Drake; Fatai Zhang; > > > Lou Berger > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Because the same signal (and connection) could be on a different > > > hierarchy level. > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Thursday, July 08, 2010 2:44 PM > > > To: Igor Bryskin; Sadler, Jonathan B.; John E Drake; Fatai Zhang; Lou > > > Berger > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > g709- > > > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Why not simply create switching capability descriptors per hierarchy > > > (i.e. ODU0, ODU1,...)? > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Thursday, July 08, 2010 11:40 AM > > > > To: Sadler, Jonathan B.; John E Drake; Snigdho Bardalai; Fatai > > Zhang; > > > > Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > There is a lot of swcaps available :=3D) > > > > Separate swcaps provide an easy way to constrain connection to a > > > > desired level of hierarchy. > > > > > > > > -----Original Message----- > > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > > Sent: Thursday, July 08, 2010 2:36 PM > > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > > Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 > > in > > > > ODU3 in ODU4) - while this may be the worst case, it is the > > possible > > > > case too. > > > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great > > speed" > > > -- > > > > 400G?) the depth of the hierarchy will grow. > > > > > > > > This makes me wonder: wouldn't a generalized method be a better > > > > approach than just creating new SwitchingTypes -- especially since > > > the > > > > signals supported within each of these is the same (e.g. an ODU1 > > over > > > > an ODU2 is the same as an ODU1 over an ODU3...) > > > > > > > > Jonathan Sadler > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 1:31 PM > > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > g709- > > > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls-g709- > > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document > > > > > before we can embark on any proposals to the problem. I am still > > > not > > > > clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > plane, > > > > and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > of > > > > > advertising of TE links, and there is no reason to invent an OTN > > > > specific > > > > > ISCD. The combination of Switching Capability and Encoding type > > of > > > > RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > > > layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > > have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls-g709- > > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control > > > > > plane, no matter how you encode the routing information. For TDM > > > > networks, > > > > > you know the resource is allocated based on TS, so the available > > TS > > > > should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > > I > > > > think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > will > > > > find > > > > > that one of your suggestions is adopted (i.e., simply advertize > > the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > ODU1, > > > > > you have to advertise a new TE link or put this FA as a component > > > > link of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > = > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: > > >; > > > gmpls- > > > > > g709-framework@tools.ietf.org framework@tools.ietf.org> ietf-ccamp-gmpls> - > > g709- > > > > > framework@tools.ietf.org > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org > > ; draft-ietf-ccamp- > > > > gmpls- > > > > > g709-framework@tools.ietf.org framework@tools.ietf.org> ietf-ccamp-gmpls> - > > g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > one of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > > the > > > > > > draft and discussion contributors on there progress on this > > > point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, > > > > consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > > we > > > > > >> establish an ODU2 service over the link. At this point in time > > > the > > > > OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to > > > 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > > over > > > > the > > > > > >> ODU2). So it is obvious from this example that the number of > > > time- > > > > slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and > > > > ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > number > > > > of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to > > be > > > > more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer > > to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit > > > is > > > > that > > > > > >> the advertisement is TS size independent and hence will > > simplify > > > > the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Fri Jul 9 06:45:05 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 34C6B3A6A67; Fri, 9 Jul 2010 06:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100709134504.34C6B3A6A67@core3.amsl.com> Date: Fri, 9 Jul 2010 06:45:03 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using RSVP-TE Author(s) : E. Bellagamba, et al. Filename : draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03.txt Pages : 19 Date : 2010-07-09 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a common set of TLVs that can be carried on RSVP-TE protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09064239.I-D@ietf.org> --NextPart-- From benoit.c.tremblay@ericsson.com Fri Jul 9 07:03:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456723A69FC for ; Fri, 9 Jul 2010 07:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxWQYUCmThdU for ; Fri, 9 Jul 2010 07:03:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9B92E3A6A8D for ; Fri, 9 Jul 2010 07:03:08 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o69EBLTq021465; Fri, 9 Jul 2010 09:11:21 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.177]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 9 Jul 2010 10:03:07 -0400 From: Benoit C Tremblay To: Ashok K , "ccamp@ietf.org" Date: Fri, 9 Jul 2010 10:03:07 -0400 Thread-Topic: [CCAMP] Query on RFC-4202 (Routing Extensions in support of GMPLS) Thread-Index: Acsc/qcR7PvgddkTQ/qyz6rOU8RJawCb7Sjw Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_CE39F5249064D946AA3535E63A014619625C7B7F56EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [CCAMP] Query on RFC-4202 (Routing Extensions in support of GMPLS) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:03:12 -0000 --_000_CE39F5249064D946AA3535E63A014619625C7B7F56EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashok, I believe the problem comes from the fact that switching/encoding types do= not provide enough information to accurately describe a TE-link in a multi= -layer network (as illustrated by the current debate for OTN). Some extra = information needs to be provided to complete the description of the TE-link= . In SDH/Sonet, the min and max LSP bandwidths are used as discriminators. In my understanding, the scenario you describe includes links from two diff= erent layers and should be advertized as such using two ISCDs. Regards, Benoit ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= shok K Sent: July-06-10 7:15 AM To: ccamp@ietf.org Subject: [CCAMP] Query on RFC-4202 (Routing Extensions in support of GMPLS) Hi CCAMPers, I have a question regarding the intrepretation of an illustration (pertaini= ng to SDH ISCD) in RFC-4202 (Routing Extensions in support of GMPLS). Refer to the following ISCD encoding example specified in the section 3.2 o= f RFC-4202 (Page-15): 3.4. STM-64 SDH Interface on a Digital Cross Connect with Two Types of SDH Multiplexing Hierarchy Supported Interface Switching Capability Descriptor 1: Interface Switching Capability =3D TDM [Standard SDH] Encoding =3D SDH Min LSP Bandwidth =3D VC-3 Max LSP Bandwidth[p] =3D STM-64, for all p Interface Switching Capability Descriptor 2: Interface Switching Capability =3D TDM [Arbitrary SDH] Encoding =3D SDH Min LSP Bandwidth =3D VC-4 Max LSP Bandwidth[p] =3D STM-64, for all p If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used. Does the above mean that the ISCDs pertaining to both VC-3 and VC-4 should = be encoded if both are supported on a given interface? Here "Switching Capability" and "Encoding type" of both the ISCDs are exact= ly the same. The only distinguishing attribute here is the Min-LSP-Bandwidt= h which is encoded as a part of "Switch Capability Specific Information". I= somehow got the impression that "Switch Capability" and "Encoding type" co= mbination should be unique for an ISCD (within Link TLV). If the answer is Yes, Can we generalize this as follows? TE-LSA Link-TLV can contain multilple ISCD Sub-TLVs with same "Switching C= apability" and "Encoding type" - but distinguished solely through one or mo= re attribute(s) encoded in their "Switch Capability Specific Information". It would be of great help if the authors/someone in the mailing-list clarif= ies this. Thanks, Ashok --_000_CE39F5249064D946AA3535E63A014619625C7B7F56EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Ashok,
 
I=20 believe the problem comes from the fact that switching/encoding  = types=20 do not provide enough information to accurately describe a TE-link in a=20 multi-layer network (as illustrated by the current debate for OTN).  S= ome=20 extra information needs to be provided to complete the description of = the=20 TE-link.  In SDH/Sonet, the min and max LSP bandwidths are used a= s=20 discriminators. 
 
In my=20 understanding, the scenario you describe includes links from two different= =20 layers and should be advertized as such using two ISCDs.
 
Regards,
Benoit

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Ashok K
Sent:=20 July-06-10 7:15 AM
To: ccamp@ietf.org
Subject: [CCAMP= ]=20 Query on RFC-4202 (Routing Extensions in support of=20 GMPLS)

Hi CCAMPers,

I have a question regarding the intrepretation of an illustration=20 (pertaining to SDH ISCD) in RFC-4202 (Routing Extensions in support of GM= PLS).=20

Refer to the following ISCD encoding example specified in the se= ction=20 3.2 of RFC-4202 (Page-15):

<SNIP>

3.4.  STM-64 SDH Interface on a Digital Cross Connect with Two Ty= pes=20 of
      SDH Multiplexing Hierarchy Supported=

      Interface Switching Capability Descript= or=20 1:
         Interface Switchin= g=20 Capability =3D TDM [Standard=20 SDH]
         Encoding =3D=20 SDH
         Min LSP Bandwidth= =3D=20 VC-3
         Max LSP Bandwidt= h[p]=20 =3D STM-64, for all p

      Interface Switching Capability Descript= or=20 2:
         Interface Switchin= g=20 Capability =3D TDM [Arbitrary=20 SDH]
         Encoding =3D=20 SDH
         Min LSP Bandwidth= =3D=20 VC-4
         Max LSP Bandwidt= h[p]=20 =3D STM-64, for all p

   If multiple links with such interfaces at both ends were = to=20 be
   advertised as one TE link, link bundling techniques sh= ould=20 be used.

</SNIP>


Does the above mean that the ISCDs pertaining to both VC-3 and VC-= 4=20 should be encoded if both are supported on a given interface?

Here "Switching Capability" and "Encoding type" of both the ISCDs are= =20 exactly the same. The only distinguishing attribute here is the=20 Min-LSP-Bandwidth which is encoded as a part of "Switch Capability Specif= ic=20 Information". I somehow got the impression that "Switch Capability" and=20 "Encoding type" combination should be unique for an ISCD (within Link TLV= ).=20

If the answer is Yes, Can we generalize this as follows?

TE-LSA  Link-TLV can contain multilple ISCD Sub-TLVs with = same=20 "Switching Capability" and "Encoding type" - but distinguished solely thr= ough=20 one or more attribute(s) encoded in their "Switch Capability Specific=20 Information".

It would be of great help if the authors/someone in the=20 mailing-list clarifies this.

Thanks,
Ashok
--_000_CE39F5249064D946AA3535E63A014619625C7B7F56EUSAACMS0703e_-- From IBryskin@advaoptical.com Fri Jul 9 07:09:52 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D803A67B1 for ; Fri, 9 Jul 2010 07:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+cV9OdxlkDD for ; Fri, 9 Jul 2010 07:09:50 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 5C71B3A6407 for ; Fri, 9 Jul 2010 07:09:49 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o69E9iJH021167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 9 Jul 2010 16:09:44 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Jul 2010 16:09:44 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Fri, 9 Jul 2010 10:09:42 -0400 From: Igor Bryskin To: "Sadler, Jonathan B." , John E Drake , Snigdho Bardalai , Fatai Zhang , Lou Berger Date: Fri, 9 Jul 2010 10:09:13 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAAFyG4AAAiUxgAABDgXAAAUrEEAAATPHQAACZVAAAAZiD8AAh4ZRA Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E3B5@atl-srv-exgen.atl.advaoptical.com> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <4C349F23.5040301@labn.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC1A0C4@SV-EXDB1.infinera.com> <07cd01cb1e3d$716fc5e0$604c460a@china.huawei.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB3331639843878426@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E220@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878445@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E254@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639843878488@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E275@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5F9D@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5F9D@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-09_01:2010-02-06, 2010-07-09, 2010-07-09 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:09:52 -0000 Jonathan and all, Let's consider OTN connections recovery. Let me know if the following makes= sense to you. 1. Suppose an ODU0 connection is carried by ODU1 containers. IF you are sur= e that each of the ODU1 connections serving the containers is protected, yo= u don't really need end-to-end protection for your ODU0 connection. (Note t= hat this would be the case if a LO topology served by protected ODU1 connec= tions is planned and provisioned, and our ODU0 connection is constrained to= this topology.) Otherwise, you will have to provision some sort of end-to-= end recovery for the ODU0 connection and correlate it with the recovery of = the ODU1 connections should one or some of them happen to be protected as w= ell. Generally speaking, end-to-end recovery of an OTN connection must be c= orrelated with the recovery of all its containers, which in turn, should be= correlated with the recovery of their containers, etc. How this correlatio= n could be achieved when the connection can move at every hop freely and in= an uncontrollable way within 5-level hierarchy is not immediately obvious = for me. I am sure ITU folks have an answer, but in any case the configurati= on of such recovery correlation could be very confusing for the user. The t= hings could be significantly simplified if: a) HO topology is carefully planned and pre-provisioned; b) HO connections are constrained to the HO topology; c) LO topology is made of the HO connections; d) LO connections are constrained to the LO topology; etc. 2. Suppose, an ODU0 connection path can take either: a) an OTU2; b) an ODU1 mapped on to the same OTU2. Path computer will see the two as separate TE links and may select one for = the working path and another for the backup path, which, of course, would b= e wrong: as soon as the OTU2 goes down, so will both working and protection= connections. Generally speaking, it would be quite a formidable task to se= lect links for the working and backup paths sufficiently disjoint from each= other under circumstances when each of the paths could be at any hop anywh= ere in the hierarchy. One way to solve this problem: a) Prepare LO topology of HO mutually independent connections; b) Constrain computation of the working and backup paths for a LO topology = to the prepared topology. Cheers, Igor -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, July 08, 2010 5:14 PM To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor, I beg to differ with your characterization about the ITU-T's standards. G.7715 (2002) and G.7715.1 (2003) recognize the benefit of having a single = routing instance carrying information about multiple layers (see G.7715 Sec= tion 5.2). What is required is link attribute information is defined per l= ayer (see G.7715.1 section 9.5). This allows variable adaptation (such as = found in SONET/SDH) to have a single advertisement, but provide different a= ttribute information for each layer (e.g. separate information for VT1.5/VC= 11, STS1/VC3, STS3c/VC4, STS12c/VC4-4c). It also enables separate routing = instances to be used per layer if the service provider/vendor chooses to do= so. The ITU-T has recently consented an amendment to G.8080 that defines a new = construct - the transitional link. A liaison about this has been sent by I= TU-T to IETF (see https://datatracker.ietf.org/liaison/910/). Transitional links enable the routing information being carried from differ= ent layers in a single instance to show the relationships where termination= /adaptation points exist. And it only works when a single routing instance= is used to carry information about multiple layers. If you're not familiar with the ITU-T's transitional link - think of it as = information similar to the IACD defined in the MLN/MRN solution RFCs. (The= re are some differences, but the intent is the same.) This transitional link construct is certainly applicable to G.709 (2009) ne= tworks, and can show the relationship for how an ODU1 would be routed over = various server layers (e.g. ODU1 over OTU1, ODU1 over ODU2 over OTU2, ODU1 = over ODU2 over ODU3 over OTU3, ...). Jonathan Sadler P.S. I didn't write the quote you included in your email... but the situati= on you describe isn't specific to OTN -- it would exist for any multi-layer= interaction. (e.g. lighting a lambda to satisfy a 2.5G demand). Again, a = technology agnostic solution would make more sense to me than one that is t= echnology specific. -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Thursday, July 08, 2010 3:30 PM To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Jonathan, According to ITU-T each layer must have a separate routing instance, hence = ITU-T folks assume that it would be very awkward to model an OTN network as= a multi-layer network. IN GMPLS, however, we do not have such a limitation. it is OK to share a ro= uting instance between several layers and we can take advantage of this. Wi= th the multi-layer approach I suggest one can do everything what is possibl= e to do in a single-layer approach by constraining the routing to all OTN l= ayers. However. It gives certain flexibility in building OTN hierarchies an= d constraining connections to desired levels of hierarchy, which is not obv= ious how can be done within a single layer. Ypu wrote: "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." What if in the described scenario the operator wants to constrain or prefer= for a given ODU2 connections usage of only OTU2 links rather than other po= ssible combinations perhaps provisioned for different purposes? Cheers, Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 08, 2010 4:07 PM To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou B= erger Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, >From the I-D under discussion: "While [G872-2001] considered the ODU as a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-Am2] includes an agreement to model the ODU as a single layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO-ODU (which has a one-to-one relationship with the OTU)." "Therefore, this document only considers ODU layer for LO ODU connection re= quest." "GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor = of TDM which can be used for ODU." "Thus, for example, an ODU2 connection service request could be supported b= y: OTU2 links (here the connection service rate is the same as the link rat= e), a combination of OTU2 and OTU3 links, OTU3 links, etc." Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 08, 2010 12:49 PM > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > HO connections may make up a topology for LO connections. They may requir= e > different planning and created in different time frame. Ergo it is likely > that an operator may want to route a service LO connection over topology > he prepared rather than over any OTN capable links. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 3:10 PM > To: Igor Bryskin; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; Lou > Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > You are arguing backwards from a capability that might or might not be > needed. I don't recall seeing this requirement in any of the CCAMP OTN > documents to date. > > I actually have the impression that the requirement is actually the > opposite; viz, establish an LSP by whatever means. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 08, 2010 12:02 PM > > To: John E Drake; Sadler, Jonathan B.; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > This won't allow an easy way to constrain a connection to a desired > level > > of hierarchy. As Jonathan correctly wrote, ODU1 could be supported by > > different levels, and what if an operator wants to constrain the > > connection to a particular one? > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 2:51 PM > > To: Sadler, Jonathan B.; Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > Lou > > Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > I suppose you could do that but it doesn't seem necessary. I think the > > existing TDM ISC could be re-used: > > > > Switching capability =3D TDM > > Encoding =3D OTN > > Max LSP BW (0-7) =3D max ODU rate at that priority > > Min LSP BW =3D min ODU rate > > > > (where rates are expressed in bytes per second) > > > > There would be one or more of these advertised, such that every ODU rat= e > > currently supported by the advertising node is advertised either > > explicitly or implicitly, by being within the range covered by a Min/Ma= x > > LSP BW pair. > > > > Thanks, > > > > John > > > -----Original Message----- > > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] > > > Sent: Thursday, July 08, 2010 11:36 AM > > > To: Igor Bryskin; John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > For the existing hierarchy, that would be 5 (ODU0 in ODU1 in ODU2 in > > ODU3 > > > in ODU4) - while this may be the worst case, it is the possible case > > too. > > > > > > As new signals/rates are added (e.g. ODU5 for "the next great speed" = - > - > > > 400G?) the depth of the hierarchy will grow. > > > > > > This makes me wonder: wouldn't a generalized method be a better > approach > > > than just creating new SwitchingTypes -- especially since the signals > > > supported within each of these is the same (e.g. an ODU1 over an ODU2 > is > > > the same as an ODU1 over an ODU3...) > > > > > > Jonathan Sadler > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 1:31 PM > > > To: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > I think OTN links require more than one switchcaps: as many as the > depth > > > of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still no= t > > > clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, > > > and > > > > it is highly desirable to adhere to the layer independent paradigm > of > > > > advertising of TE links, and there is no reason to invent an OTN > > > specific > > > > ISCD. The combination of Switching Capability and Encoding type of > > > RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link t= o > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > OTN > > > > hierarchies and constrain LO connections to HO containers, one need= s > > to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > > > networks, > > > > you know the resource is allocated based on TS, so the available TS > > > should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will > > > find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link > > > of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to bette= r > > > > > align the work with 4202. Use of common approaches is of course > one > > > of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this point= . > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service > > > routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider > > > an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then w= e > > > > >> establish an ODU2 service over the link. At this point in time > the > > > OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+= 4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over > > > the > > > > >> ODU2). So it is obvious from this example that the number of > time- > > > slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > > >> How do we address this issue based on the approach specified in > the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number > > of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalen= t > > > > >> bandwidth in bytes/sec within a link? This approach seems to be > > more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit i= s > > > that > > > > >> the advertisement is TS size independent and hence will simplify > > the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Fri Jul 9 07:14:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BF23A6A59 for ; Fri, 9 Jul 2010 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fshRRSG-12A for ; Fri, 9 Jul 2010 07:14:29 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 6D14D3A69E6 for ; Fri, 9 Jul 2010 07:13:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTDcukF6n+SqXz56MUjMqTHQKQu8DcVzD@postini.com; Fri, 09 Jul 2010 07:14:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 9 Jul 2010 06:47:18 -0700 From: John E Drake To: "BELOTTI, SERGIO (SERGIO)" Date: Fri, 9 Jul 2010 06:47:17 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsfS4I10GQAPXqrTvi2cb6gm9ZiGgAGQL4gAADtk/AAARUXgA== Message-ID: <5E893DB832F57341992548CDBB333163984387867A@EMBX01-HQ.jnpr.net> References: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC19EF8@SV-EXDB1.infinera.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86947@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1C7@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398438783D8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <5292FFA96EC22A4386067E9DBCC0CD2BBC0B9E5D72@EX-NAP.tellabs-west.tellabsinc.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E206@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A39@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E208@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86A48@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E217@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDC86B09@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E2A5@atl-srv-exgen.atl.advaoptical.com> <0fdd01cb1f4b$1b913320$604c460a@china.huawei.com> <5E893DB832F57341992548CDBB3331639843878669@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:14:31 -0000 snipped > > Secondly, if we use the > > existing ISCD (we just advertise Max LSP bandwidth (e.g., ODU4) and Min > > LSP bandwidth (ODU1), how to know whether it can support ODUflex; How t= o > > know if it can support ODU2 and ODU3 if the equipments may have some > > constraits. Thirdly, in TDM networks, it is not efficient for > scalability > > issue if we use the existing ISCD, because it needs 32 bits to indicate > > the bandwidth (Actually, we only need much fewer bits to identify the > > signal type (e.g., ODUk)). > [JD] >=20 > No one is advocating using the existing ISC, rather whatever is designed > should be consistent with the rest of GMPLS. >=20 > In particular we should have bandwidth advertised in bytes per second, > eight priority levels each with total unreserved bandwidth, a simple > indication (such as a bit vector) of what switching granularities are > currently supported, and ODU flex bandwidth by priority level. >=20 > [SB] I think we are not too far here. We can discuss about the bytes per > second, but for the rest I think our attempt in the routing OTN draft is > to follow your basic suggestion. Please have a look also to the OTN > routing draft. It would be very beneficial to have you comment/suggestion > on that. [JD]=20 I will take a look at it. My comments, above, are based on the version a m= onth or so ago, and I gave Diego and Daniele comments on it. =20 From neil.2.harrison@bt.com Fri Jul 9 07:27:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C16E3A6A27 for ; Fri, 9 Jul 2010 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6yafNPUtiqw for ; Fri, 9 Jul 2010 07:27:34 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 25F4B3A6A0C for ; Fri, 9 Jul 2010 07:27:33 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:27:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 15:27:06 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C060F8D42@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E32E@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYA== From: To: , , X-OriginalArrivalTime: 09 Jul 2010 14:27:38.0109 (UTC) FILETIME=[E18DCAD0:01CB1F72] Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org, SBardalai@infinera.com Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:27:35 -0000 Some observations in-line:=20 Igor Bryskin wrote 09 July 2010 13:59 >=20 > Sergio, >=20 > You wrote: >=20 > " My understanding of Switching Cap is that different=20 > Switching Cap would be linked to different technologies imply=20 > different switching capabilities >=20 > IB>> We do have PSC1-PSC4 for packet switching ( note, one=20 > per MPLS DP hierarchy level, NH=3D> Do you really mean client/server here (as this is the only proper hierarchy case)? I query you on this because right now there is a DP problem in MPLS-TP that is being consciously ignored wrt the implications of the unnecessary carry-over of PWs and sublayering into MPL-TP. And one of the problems (its not the only one) is the potential for misconnectivity between MPLS layers, MPLS sublayers and PW layers when the LSP for each of these looks the same in the DP. Not only must we have a common method of (OAM) detection but this must contain a proper SA of the layer network (or sublayers) in order for quick/correct diagnosis of offending source. =20 > I suggest the same for OTN).=20 NH=3D> It's not a great idea to always blindly replicate the artificial hierarchies that past co-cs mode technologies (like PDH and SDH) created in the future. The PDH hierarchy simply reflected the maturity of silicon technology at the time. SDH replicated this with an increased step size and removed the async 'mux mountain' problem. However, the simple commercial reason for not replicating this fixed hierarchy structure is that each layer network represents a set of DP/CP/MP functions and stuff to configure/operate/etc...these are all costs and things that can fail, ie more layers =3D less reliable. What we really need here is to minimise the number of layer networks between the (external application interfacing) TOS layer network and the (EM wave modulating) BOS layer network. In other words, the future transport network should be migrating to a digital wrapper approach with no fixed hierarchy IMO. =20 > We=20 > have also agreed that a single L2SC is not enough for=20 > Ethernet technology, in fact, we need separate swicthcaps for=20 > STAG switching, EPL, EVPL, etc.=20 >=20 > " : we have not created different Switching Cap for VC4 or=20 > VC12 in SDH".=20 >=20 > IB>> IMO this is the reason why GMPLS in TDM has never really=20 > taken off. NH=3D> I don't agree with this. Though I would separate signalling from routing functions here....and wrt to latter distributed vs centralised cases. Real BOS transport networks must currently have very long information transfer phases (set-up and tear-down phases are very much smaller). So the CP components are nowhere near as important as the MP components...esp as the MP components have to be there anyway. So this is why IMO GMPLS has probably not been as successful as some hoped it would be. BTW - If one looks at the business case for trying to more rapidly set-up/tear-down BOS layer network connections you quickly find that the commercials do not figure for a useful GOS.....at least in today's environment. I got the traffic/maths group at BT labs to look at analysing this topic many years ago in a very general sense (ie very general calling/holding statistics). Though I must add here that today we do not have the truly massive external end-system application numbers we would need nor do we have the short-enough holding times to warrant a switched services case, eg like the PSTN say. If we had this however then would drive the GMPLS CP case.=20 regards, Neil=20 From root@core3.amsl.com Fri Jul 9 11:30:19 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D5B7B3A63C9; Fri, 9 Jul 2010 11:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100709183007.D5B7B3A63C9@core3.amsl.com> Date: Fri, 9 Jul 2010 11:30:03 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-impairments-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 18:30:21 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments Author(s) : G. Bernstein Filename : draft-ietf-ccamp-wson-impairments-03.txt Pages : 37 Date : 2010-07-09 The operation of optical networks requires information on the physical characterization of optical network elements, subsystems, devices, and cabling. These physical characteristics may be important to consider when using a GMPLS control plane to support path setup and maintenance. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with GMPLS control plane protocols and mechanisms to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-wson-impairments-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09111711.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Sun Jul 11 10:10:50 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA06F3A69D6 for ; Sun, 11 Jul 2010 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooILrAEmoBI7 for ; Sun, 11 Jul 2010 10:10:49 -0700 (PDT) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 35EF83A69C8 for ; Sun, 11 Jul 2010 10:10:48 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o6BHAq9w004359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jul 2010 13:10:54 -0400 Message-ID: <4C39FB1C.7060708@grotto-networking.com> Date: Sun, 11 Jul 2010 10:10:52 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "PELOSO, PIERRE (PIERRE)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=3JBjGC73ZgeMe+OftGZTgg9WNz2iVTvnTCd32hdiRMs= c=1 sm=1 a=nuu_g-mQhRUA:10 a=uEzv4HemXiYA:10 a=8nJEP1OIZ-IA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=-LsglLqdDBRlTmAjNXwA:9 a=wT-VomL05ZIK7Tm9ENgA:7 a=kQwptkh5Id12gCzrR2P82pI2oUQA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=klcgcZzC9IcC5God:21 a=e1PULwGenFjYnTLU:21 a=OkPnmgdRXU7//wtL+yd+jg==:117 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Proposed contribution to draft-bernstein-ccamp-wson-signaling-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 17:10:50 -0000 Hi all this sounds good to me. I've incorporated the changes and sent a pre-release version to Pierre for editing. Please let us know if there are any other concerns or desired changes and I can roll them into the final edit before posting. Cheers Greg On 7/1/2010 7:54 AM, PELOSO, PIERRE (PIERRE) wrote: > Hi ccampers and Greg, > > During the latest meeting in Anaheim, I was asked to propose on the list for discussion some text dealing with the re-introduction of wavelength metric inside the signalling draft by Greg. The wavelength metric object is to be used inside the path message when performing LSP request. > The interest of the metric is to enrich the information collected on the wavelength availability, which could be used to perform wavelength differentiations according varying criteria. > > So here is the text that I find fitting properly the needs, it actually is a slight adaptation of the text that was contained inside the first version of this draft: > > Distributed wavelength assignment makes extensive use of the label > set object/TLV of [RFC3471]. Some wavelength assignment algorithms > require supplemental information concerning the potential lambdas to > be used. An ordered set of TLVs in correspondence with the group of > one or more label set TLVs can be used to convey this information in > the form of a general wavelength "acceptability" metric. > > Note that the label set syntax of [RFC3471] allows group of > wavelengths into ranges. For the purpose of supplementing this > information with wavelength count only those wavelengths with the > same counts could be grouped. > > The general format for supplemental wavelength selection information > could be as follows: > > The information carried in a Wavelength Set Metric TLV is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Info Type | Metric Size | Num Metrics | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Wavelength Metric Info | > | From lowest to highest frequency if more that one value | > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Info Type: 8 bits > > 0 - Single Value > > The enclosed single value for the wavelength metric is given to all > wavelengths in the corresponding wavelength set. > > 1 - List > > The enclosed list gets applied in a one-to-one fashion to each > wavelength in the corresponding wavelength set. An error occurs if > the number of metrics in this list and the number of wavelengths in > the wavelength set is not equal. > > Metric Size: > > Indicates the size of the wavelength metric information as follows > > 0 - 8 bits > > 1 - 16 bits > > 2 - 32 bits > > Number 0f Metrics: 24 bits > > Wavelength Metric: (1, 2, or 4 octets) > > The wavelength metric represents in some fashion the > desirability or lack thereof to use this wavelength over another > available wavelength. Different wavelength assignment algorithms may > use this information differently. > > Regards, > > Pierre > _____________________________________________________ > Pierre Peloso Engineer > > +33 1 3077 2662 Network& Networking > rte de Villejust > 91620 Nozay (France) Alcatel-Lucent > > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From zhangfatai@huawei.com Sun Jul 11 20:15:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1392628C111 for ; Sun, 11 Jul 2010 20:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.604 X-Spam-Level: **** X-Spam-Status: No, score=4.604 tagged_above=-999 required=5 tests=[AWL=-3.615, BAYES_40=-0.185, EXTRA_MPART_TYPE=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MY_CID_AND_CLOSING=1.6, MY_CID_AND_STYLE=1.54, RDNS_NONE=0.1, STOCK_IMG_HDR_FROM=0.001, STOCK_IMG_OUTLOOK=0.001, T_TVD_FW_GRAPHIC_ID1=0.01] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZkO7835h7vw for ; Sun, 11 Jul 2010 20:15:23 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CE11B3A6A40 for ; Sun, 11 Jul 2010 20:14:44 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5F00M78CZH0U@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 12 Jul 2010 11:14:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5F00MPRCZGE9@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 12 Jul 2010 11:14:04 +0800 (CST) Received: from Z41162C ([10.70.76.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5F008R4CZFMU@szxml04-in.huawei.com> for ccamp@ietf.org; Mon, 12 Jul 2010 11:14:04 +0800 (CST) Date: Mon, 12 Jul 2010 11:14:03 +0800 From: Fatai Zhang To: PAPADIMITRIOU Dimitri , julien.meuric@orange-ftgroup.com Message-id: <016601cb2170$47d3fcc0$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/related; boundary="Boundary_(ID_z5azR8xcTBR12+9z5DOqyA)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal Cc: ccamp@ietf.org Subject: [CCAMP] Comment on Simplex and Hybrid node in RFC5212 and RFC5339 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 03:15:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_z5azR8xcTBR12+9z5DOqyA) Content-type: multipart/alternative; boundary="Boundary_(ID_ErCxJNADVXUstabXwUJYKg)" --Boundary_(ID_ErCxJNADVXUstabXwUJYKg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Dimitri and all, I have a comment about Simplex and Hybrid node for quite long time. When we look at the RFC5212 and RFC5339, we can see the following pictures (Figure 1 in RFC5212 and Figure 1a in RFC5339): These two pictures are different, is it your intention or mistake? According to the definition of Simplex and Hybrid node in RFC5212, Figure 1a looks like Simplex node. In addition, do you think if there is internal link within Simplex node as Hybrid node? Hope you(authors of these drafts) or other experts can explain this. Best Regards Fatai --Boundary_(ID_ErCxJNADVXUstabXwUJYKg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Dimitri and all,
 
I have a comment about Simplex and Hybrid node for quite long time.
 
When we look at the RFC5212 and RFC5339, we can see the following pictures (Figure 1 in RFC5212 and Figure 1a in RFC5339):
 
 
These two pictures are different, is it your intention or mistake?
 
According to the definition of Simplex and Hybrid node in RFC5212, Figure 1a looks like Simplex node.
 
In addition, do you think if there is internal link within Simplex node as Hybrid node?
 
Hope you(authors of these drafts) or other experts can explain this.
 
 
 

Best Regards
 
Fatai
 
--Boundary_(ID_ErCxJNADVXUstabXwUJYKg)-- --Boundary_(ID_z5azR8xcTBR12+9z5DOqyA) Content-id: <016001cb2170$47c0e9f0$514c460a@china.huawei.com> Content-type: image/jpeg; name=Image1.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=Image1.jpg /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCAE9AeQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7Looo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArMt/EOgXPiK58OW+uaZNrVrEJrjTo7t GuYUO0h3iB3KvzpyRj5l9RWnWZb+HtAtvEVz4jt9D0yHWrqIQ3Gox2iLczINoCPKBuZfkTgnHyr6 CgA1jxDoGjX2n2Or65pmnXepS+TYQXV2kUl0+VGyJWILtl1GFycsPUVNreraVoelzaprep2WmWEG 3zbq8nWGKPcwUbnYgDLEAZPUgVDrHh7QNZvtPvtX0PTNRu9Nl86wnurRJZLV8qd8TMCUbKKcrg5U egqbW9J0rXNLm0vW9MstTsJ9vm2t5As0Um1gw3IwIOGAIyOoBoAnsLu1v7G3vrG5hurS5iWaCeGQ PHKjDKurDhlIIII4INUvDfiHQPEti994c1zTNZtI5TC89hdpcRq4AJQshIDYZTjrgj1q7YWlrYWN vY2NtDa2ltEsMEEMYSOJFGFRVHCqAAABwAKpeG/D2geGrF7Hw5oemaNaSSmZ4LC0S3jZyAC5VAAW wqjPXAHpQAW/iHQLnxFc+HLfXNMm1q1iE1xp0d2jXMKHaQ7xA7lX505Ix8y+oo1jxDoGjX2n2Or6 5pmnXepS+TYQXV2kUl0+VGyJWILtl1GFycsPUUW/h7QLbxFc+I7fQ9Mh1q6iENxqMdoi3MyDaAjy gbmX5E4Jx8q+go1jw9oGs32n32r6Hpmo3emy+dYT3Vokslq+VO+JmBKNlFOVwcqPQUATa3q2laHp c2qa3qdlplhBt826vJ1hij3MFG52IAyxAGT1IFT2F3a39jb31jcw3VpcxLNBPDIHjlRhlXVhwykE EEcEGoNb0nStc0ubS9b0yy1Own2+ba3kCzRSbWDDcjAg4YAjI6gGp7C0tbCxt7GxtobW0tolhggh jCRxIowqKo4VQAAAOABQBS8N+IdA8S2L33hzXNM1m0jlMLz2F2lxGrgAlCyEgNhlOOuCPWi38Q6B c+Irnw5b65pk2tWsQmuNOju0a5hQ7SHeIHcq/OnJGPmX1FHhvw9oHhqxex8OaHpmjWkkpmeCwtEt 42cgAuVQAFsKoz1wB6UW/h7QLbxFc+I7fQ9Mh1q6iENxqMdoi3MyDaAjygbmX5E4Jx8q+goANY8Q 6Bo19p9jq+uaZp13qUvk2EF1dpFJdPlRsiViC7ZdRhcnLD1FTa3q2laHpc2qa3qdlplhBt826vJ1 hij3MFG52IAyxAGT1IFQ6x4e0DWb7T77V9D0zUbvTZfOsJ7q0SWS1fKnfEzAlGyinK4OVHoKm1vS dK1zS5tL1vTLLU7Cfb5treQLNFJtYMNyMCDhgCMjqAaAJ7C7tb+xt76xuYbq0uYlmgnhkDxyowyr qw4ZSCCCOCDVLw34h0DxLYvfeHNc0zWbSOUwvPYXaXEauACULISA2GU464I9au2Fpa2Fjb2NjbQ2 tpbRLDBBDGEjiRRhUVRwqgAAAcACqXhvw9oHhqxex8OaHpmjWkkpmeCwtEt42cgAuVQAFsKoz1wB 6UAFv4h0C58RXPhy31zTJtatYhNcadHdo1zCh2kO8QO5V+dOSMfMvqKNY8Q6Bo19p9jq+uaZp13q Uvk2EF1dpFJdPlRsiViC7ZdRhcnLD1FFv4e0C28RXPiO30PTIdauohDcajHaItzMg2gI8oG5l+RO CcfKvoKNY8PaBrN9p99q+h6ZqN3psvnWE91aJLJavlTviZgSjZRTlcHKj0FAE2t6tpWh6XNqmt6n ZaZYQbfNurydYYo9zBRudiAMsQBk9SBU9hd2t/Y299Y3MN1aXMSzQTwyB45UYZV1YcMpBBBHBBqD W9J0rXNLm0vW9MstTsJ9vm2t5As0Um1gw3IwIOGAIyOoBqewtLWwsbexsbaG1tLaJYYIIYwkcSKM KiqOFUAAADgAUAUvDfiHQPEti994c1zTNZtI5TC89hdpcRq4AJQshIDYZTjrgj1ot/EOgXPiK58O W+uaZNrVrEJrjTo7tGuYUO0h3iB3KvzpyRj5l9RR4b8PaB4asXsfDmh6Zo1pJKZngsLRLeNnIALl UABbCqM9cAelFv4e0C28RXPiO30PTIdauohDcajHaItzMg2gI8oG5l+ROCcfKvoKADWPEOgaNfaf Y6vrmmadd6lL5NhBdXaRSXT5UbIlYgu2XUYXJyw9RU2t6tpWh6XNqmt6nZaZYQbfNurydYYo9zBR udiAMsQBk9SBUOseHtA1m+0++1fQ9M1G702XzrCe6tElktXyp3xMwJRsopyuDlR6Cptb0nStc0ub S9b0yy1Own2+ba3kCzRSbWDDcjAg4YAjI6gGgCewu7W/sbe+sbmG6tLmJZoJ4ZA8cqMMq6sOGUgg gjgg1S8N+IdA8S2L33hzXNM1m0jlMLz2F2lxGrgAlCyEgNhlOOuCPWrthaWthY29jY20NraW0Sww QQxhI4kUYVFUcKoAAAHAAql4b8PaB4asXsfDmh6Zo1pJKZngsLRLeNnIALlUABbCqM9cAelABb+I dAufEVz4ct9c0ybWrWITXGnR3aNcwodpDvEDuVfnTkjHzL6ijWPEOgaNfafY6vrmmadd6lL5NhBd XaRSXT5UbIlYgu2XUYXJyw9RRb+HtAtvEVz4jt9D0yHWrqIQ3Gox2iLczINoCPKBuZfkTgnHyr6C jWPD2gazfaffavoemajd6bL51hPdWiSyWr5U74mYEo2UU5XByo9BQBNreraVoelzaprep2WmWEG3 zbq8nWGKPcwUbnYgDLEAZPUgVPYXdrf2NvfWNzDdWlzEs0E8MgeOVGGVdWHDKQQQRwQag1vSdK1z S5tL1vTLLU7Cfb5treQLNFJtYMNyMCDhgCMjqAansLS1sLG3sbG2htbS2iWGCCGMJHEijCoqjhVA AAA4AFAFLw34h0DxLYvfeHNc0zWbSOUwvPYXaXEauACULISA2GU464I9aLfxDoFz4iufDlvrmmTa 1axCa406O7RrmFDtId4gdyr86ckY+ZfUUeG/D2geGrF7Hw5oemaNaSSmZ4LC0S3jZyAC5VAAWwqj PXAHpRb+HtAtvEVz4jt9D0yHWrqIQ3Gox2iLczINoCPKBuZfkTgnHyr6CgA1jxDoGjX2n2Or65pm nXepS+TYQXV2kUl0+VGyJWILtl1GFycsPUVNreraVoelzaprep2WmWEG3zbq8nWGKPcwUbnYgDLE AZPUgVDrHh7QNZvtPvtX0PTNRu9Nl86wnurRJZLV8qd8TMCUbKKcrg5UegqbW9J0rXNLm0vW9Mst TsJ9vm2t5As0Um1gw3IwIOGAIyOoBoAnsLu1v7G3vrG5hurS5iWaCeGQPHKjDKurDhlIIII4INUv DfiHQPEti994c1zTNZtI5TC89hdpcRq4AJQshIDYZTjrgj1q7YWlrYWNvY2NtDa2ltEsMEEMYSOJ FGFRVHCqAAABwAKpeG/D2geGrF7Hw5oemaNaSSmZ4LC0S3jZyAC5VAAWwqjPXAHpQAW/iHQLnxFc +HLfXNMm1q1iE1xp0d2jXMKHaQ7xA7lX505Ix8y+orTrMt/D2gW3iK58R2+h6ZDrV1EIbjUY7RFu ZkG0BHlA3MvyJwTj5V9BWnQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAVjaRr/8AaPifXNC/sTWrT+yPs/8Ap11a7LS981C/+jyZ/ebMbX4G1iBzWzWNpH/C Vf8ACT65/a39i/2B/o/9i/ZfN+1/cPn/AGjd8n38bNn8Oc80AbNec/ETxnr/AIV+Ivh22VdMk8K3 Njc3WsF7d/tVqkU1vCZ1k8wRiJWvIpJC6gJFDM+48KPRq4zxH4e1XVviXpWoTabot54aj0S/0y/S 6uWMsv2p4GI8gxFHTFsqkM4yJW4+QBwClpPjHVbTV/GEOvy2V7Hp+tx6Xotlpti0d3du9pFdCP55 mV32zgFsRoqwySOVTd5e1pXi17z7Xa3XhrWtL1iG2e6g0m7a2+0XkS4BaF0maFvmKoQZAULIX2LI jN5/p3wk1Wbw9qVr4pbRfEdzb+JBqulxakWuob+CHT47CJb4yISZniRmeRQwWUrIFcL5Z6b4ceDv 7D1ybUf+Fe/D/wAJZtmg3aAvnXFxuZWw0v2eDYg2cptfeSpymzDgB8MvHXiDxQhGpeBNa0+P+0tQ tTfGWy+zxLb3M0SK6rcvKXAiVGKoVL5K/Jhq2vBfjKz8SaWt7Lp17oTyalc6ZBbanLbiWee3aRZR GIpZA2GhmGM5IidsbcMczw1pPjTQLuXRrO28PyaLLq93qDalLeTG52XN3JdPGLURBdw81og/n44E hU/6o4viH4ca/c+NdT8R6ZrcMSm+i1axtmd4w90q2EbRuy58tTDYSQ+aodtmoTrs2qRMAbWnfEi3 1TTopNJ8LeINQ1Qy3CXGkQm0FzZiC4ltneZmnECqZYZFTEpL7WKBgkhS7qvjzTtP8Bax4ubTNTmX RInfVNNjWIXloY1Dyo6vIqblQ+Zw5DptaMuroWxdC8Ga/wCCbHSH8LNpmuXdt4fsNBvItSuHsY5U sxJ5U8bxxzFGzNKGjKsGDIQ6+WRIeIvBmv33wx8c6bbtpj+I/GEUxuEkuHjs7Z5bWO0Co4jZ2WOG JDuKAyOrHEQcKgB0GleIv+El+12FppvibRY5rZ2s9TudN8jfjCsyJMpaN0ZhhbiJN+CyLIgYjmfh 38QtR1HQ/A+n3Wg61rmrat4bsNU1HUbT7Itvb+cqq0kwaVGTLb2Cqh3BX8sMY3C9Zo9340lsdQfV 9A8P2l3HFmwitdbmuI53w3yyu1rGYlyFG5VkOCTjgA8N8LfA/jD4c2+haPo9tot7pMmm2ieIGutZ uTL9vjjihee2DQOSgiiVRGzqpCRBVhCuZAD1muf8SeJ10q+TTNP0XU/EGqGITyWOmmASQwklRLI0 0kcaKzKVUFtzlX2qwjkK9BXnPxE+HlrrXioeKU8I+EvFd3JYxafLZ+IlCxwpG8siSQy+RMUbMzh0 KEOPLIZPLIkAOt0rVIfEuh3Ysp73Srxd9rcxskYu9OuNoyrKwdN6hldTh0dSjrvRlLYvw01m5/4Q G71HxNrn2n+ztS1a3uNRvfJh/cWt9cRLJIUVI1xHEu4hVHBNHhPRNV8MeELyLRPCHgzSr+a58+LS dMla1slyEQmSdYMu5VS28QL/AAR4O3zGxvC3hLxVdeDPEPgrxjp2i2ek61/azSXek6xLPcL9uuZp SgSS1RRtWdhvyclAdmGIAB0Fh43WW+t01Lwx4g0TT7uVYbPUtRjgjgndziJCiytNC0mQFE8cZ3FY ziRlQ8wfjfoEcKSXfhnxbaBZb1brzLBGW0Sxd1vZnZJCpig2pudC4czIkfmSB0SHQvhx9i1ywf8A 4VX8JrD7Jcxyf2zZW3+kfu2DeZHbfZl8p22/KPtDeUWB3S7MPi3fw28fahoF9Y3MHhm3mvtN8VWL +Xqs8ix/2rOlzC4JtlLbJFMbDA+XDgk/uwAep+JPE66VfJpmn6LqfiDVDEJ5LHTTAJIYSSolkaaS ONFZlKqC25yr7VYRyFczWfiLpWleGI9fuNK1qWOPUoNM1G0gt1ku9OnldIwJYQ258NJFgQ+YXWRH jEiMGON42+H/APbuuW3iy88F+DPEmrTabBY3mna4++3tvLaSQPb3BtpG+9NIrAxDzB5bZjMZV4L7 wVr8Hw+j0nw54U8DaJdt4gsdUfTrCd7W0jS2uIJjmVLfM0rm3UbvJjCq4HzeVmQA63RPFr6l/atr J4a1rT9Y022S6fSblrY3E0UnmCJkeOZofnaGVAGkUgoS21SrHF+GXjrxB4oQjUvAmtafH/aWoWpv jLZfZ4lt7maJFdVuXlLgRKjFUKl8lfkw1aml6Tr8PxZ13X7i20xdFvdIsrK3kjvHa5328lxIS8Ri CqrfanHEhI8pTj5yEpeGtJ8aaBdy6NZ23h+TRZdXu9QbUpbyY3Oy5u5Lp4xaiILuHmtEH8/HAkKn /VEA7miiigAooooAKKKKACiiigAooooAKKKKACiiigDG0jX/AO0fE+uaF/YmtWn9kfZ/9OurXZaX vmoX/wBHkz+82Y2vwNrEDmtmsbSP+Eq/4SfXP7W/sX+wP9H/ALF+y+b9r+4fP+0bvk+/jZs/hznm tmgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoormfDtt pUXjvxVcWni291O/n+x/bdHl1FZotJ2xER+XAOYPNXLnP3yMigDpqKKKACiiigAooooAKKKKACii igAooooAKKKKACiiuTv7/wCJKX1wlj4T8JT2iysIJZvEtxFI6Z+VmQWLBWIwSoZgDxk9aAOsorn/ ABJd+NIL5E8OaB4f1G0MQLy3+tzWkgfJyoRLWUFcbTu3A5JGOMkuLvxovh22nt9A8Pya00pFxaSa 3MltGnzYZJxalnbhPlMSj5m5+UbgDoKK5/R7vxpLY6g+r6B4ftLuOLNhFa63NcRzvhvlldrWMxLk KNyrIcEnHABh0S98fTapDHrfhnwzZWB3ebPZ+IJ7mVPlONsbWcYbLYBy4wCTzjBAOmork7+/+JKX 1wlj4T8JT2iysIJZvEtxFI6Z+VmQWLBWIwSoZgDxk9aueJLvxpBfInhzQPD+o2hiBeW/1ua0kD5O VCJaygrjad24HJIxxkgHQUVz9xd+NF8O209voHh+TWmlIuLSTW5kto0+bDJOLUs7cJ8piUfM3Pyj caPd+NJbHUH1fQPD9pdxxZsIrXW5riOd8N8srtaxmJchRuVZDgk44AIB0FFczol74+m1SGPW/DPh mysDu82ez8QT3MqfKcbY2s4w2WwDlxgEnnGD01ABRRRQAUUUUAFFFFABRRRQAUVzPh220qLx34qu LTxbe6nfz/Y/tujy6is0Wk7YiI/LgHMHmrlzn75GRXTUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFUrTSdKs9UvtUtNMsre/wBQ8v7bdRQKstz5a7Y/McDL 7VJAyTgcCrtY2ka//aPifXNC/sTWrT+yPs/+nXVrstL3zUL/AOjyZ/ebMbX4G1iBzQBs0UUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFczpuqX83xT17RJJ91haaJpl1BFsX5JZp79ZGzjJysEQwT gbeMZOemoAKKK5n4razqvh34aeJPEWiNZLf6Vps99ELyBpYn8lDIUZVdD8yqVBDcEg4OMEA6aiuM 0TVPFWn+OLPwz4mv9F1T+0dNur63uNO02Wy8j7PLbIyMrzzeZv8AtSkEFNvlnht3y8z4C+IHiTxJ r+h20Wp+DL37ZuuNb0a3lMeq+HohA58maNpmMrrO0MLvsiKkH918+YgD1miuGtdW8aeImu9W8MXP h+10u0vrmyjstRs5pJ7x7Wd4ZSZ0lC26tJG6r+6mIULIQSxiXpvCc2s3PhXSbjxHaQ2etS2ML6jb wnMcNwUBlRSGbKh9wHzNwOp60AadFFFABRRXM+MtUv8AT/Efgq0s5/Kh1PW5LW8XYp8yIadeTBck ZH7yGNsjB+XHQkEA6aiiigAooooAKKKKACiiigClaaTpVnql9qlppllb3+oeX9tuooFWW58tdsfm OBl9qkgZJwOBV2sbSNf/ALR8T65oX9ia1af2R9n/ANOurXZaXvmoX/0eTP7zZja/A2sQOa2aACii igAooooAKKKKACiiigAooqG/u7Wwsbi+vrmG1tLaJpp55pAkcSKMs7MeFUAEkngAUATUVjeGPFnh XxR9o/4RnxLout/Ztv2j+zr6K48rdnbu2MdudrYz1wfSrmo6h9jvNNt/sV7cfbrk2/mQRb0t8QyS +ZKc/Ih8vYDz87oO+aALtFFZniHXtM0CGzm1WWaKK8voLCF47aSVfOmcJEHKKfLVnKrvbC5ZQSCR kA06KK5/wt408L+Kb69tPDusQ6m1lFFNLLbqzQOkpkVHjmx5cq7opVJjZgrRspwwIoA6CiiigAoo ooAKKKKACiiigArG0j/hKv8AhJ9c/tb+xf7A/wBH/sX7L5v2v7h8/wC0bvk+/jZs/hznmtmigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooA5PSrS6T4w+I757aZbSbw/pMMU5jIjd0uNRLoG6FlE iEgcgOueorrKpQ6pYTa5daJHPuv7S2hup4tjfJFM0qxtnGDloJRgHI284yM0/EfinQvDvm/2xffZ fK0261R/3Tvi1tvL8+T5Qfu+bH8v3ju4BwcAGzXM/FbRtV8RfDTxJ4d0RbJr/VdNnsYjeTtFEnnI Yy7MqOflViwAXkgDIzkdNRQByfw18M2vh6xu3TwP4S8J3dzKBLF4fYPHOij5Gd/s8JLAs4ClSADk H5iBi+H9A+Id7c+EB43ufD9xL4el+3T6lYTSCS/uGs5rdkNuYlWJR9pdvMEh3GMERxiTbH6NRQBw 1rpvjTwu13p/hjSvD+saXcX1zqEcmo6vNZTwvczvPLGQltMsiiSRyr5Q7WVSpKGR+zsFuksbdL6a Ge7WJRPLDEYo3fHzMqFmKqTkhSzEDjJ61NRQAUUUUAFcn46tLq58UeAZre2mmitfEEs1w8cZZYUO mX6B3I+6u90XJ4yyjqRXWVS1HVLDT7zTbS8n8qbU7k2tmuxj5kohkmK5AwP3cMjZOB8uOpAIBdoo ooAKKKKACiiigAooooAxtI/4Sr/hJ9c/tb+xf7A/0f8AsX7L5v2v7h8/7Ru+T7+Nmz+HOea2aKKA CiiigAooooAKKKKACiiigAooqG/tLW/sbixvraG6tLmJoZ4Jow8cqMMMjKeGUgkEHgg0Aef+Adbt dA8AXN9eRzSRS+MtSslEQBbfc6/PboTkj5Q8qk98A4BPBu+Ordrb4ieAdTt77U4ZbrV5bC4hj1Cd baaEadfygPbh/KZt6I28ru+VecACrth8MvhtYX1vfWPw98JWt3bSrNBPDo1ukkTqcq6sEyrAgEEc giptb+HvgHXNUm1TW/A/hnU7+fb5t1eaVBNLJtUKNzspJwoAGT0AFAHP+NdIbV/jD4e0+TW/EFlY Xfh/UpLy1sNVnto7gwXFj5WfLYGNlM7nfGUdhhWYplDz+s6jft8E455VvdVm0/xvBZ28fmq1xNFa +JUhhj3ysAz+XEi75Hyx+Z2yS1emw+E/CsGqafqkPhrRYr/TLYWlhdJYxCW0gCsoiicLlECsw2qQ MMRjk1BYeCPBdhY29jY+EPD9raW18uowQQ6bCkcV0owtwqhcLKAAA4+YAdaAOf8AhHpyTf2j4lvt Q1o69d3Mq6lpVzq9zNb6PK2xzaJDJIUG0bWEoUBxIXi2wyRoLukf8lv8Uf8AYt6N/wClOqVtaV4T 8K6Trl3rul+GtFsNWvN/2q+trGKO4n3sHffIqhm3MAxyTkgE81mWHwy+G1hfW99Y/D3wla3dtKs0 E8OjW6SROpyrqwTKsCAQRyCKAOsrn/El340gvkTw5oHh/UbQxAvLf63NaSB8nKhEtZQVxtO7cDkk Y4yegooA5+4u/Gi+Hbae30Dw/JrTSkXFpJrcyW0afNhknFqWduE+UxKPmbn5RuNHu/GktjqD6voH h+0u44s2EVrrc1xHO+G+WV2tYzEuQo3KshwSccAHoKKAOZ0S98fTapDHrfhnwzZWB3ebPZ+IJ7mV PlONsbWcYbLYBy4wCTzjBhv7/wCJKX1wlj4T8JT2iysIJZvEtxFI6Z+VmQWLBWIwSoZgDxk9a6yi gDn/ABJd+NIL5E8OaB4f1G0MQLy3+tzWkgfJyoRLWUFcbTu3A5JGOMkuLvxovh22nt9A8Pya00pF xaSa3MltGnzYZJxalnbhPlMSj5m5+UbugooA5/R7vxpLY6g+r6B4ftLuOLNhFa63NcRzvhvlldrW MxLkKNyrIcEnHABh0S98fTapDHrfhnwzZWB3ebPZ+IJ7mVPlONsbWcYbLYBy4wCTzjB6aigDk7+/ +JKX1wlj4T8JT2iysIJZvEtxFI6Z+VmQWLBWIwSoZgDxk9aueJLvxpBfInhzQPD+o2hiBeW/1ua0 kD5OVCJaygrjad24HJIxxk9BRQBz9xd+NF8O209voHh+TWmlIuLSTW5kto0+bDJOLUs7cJ8piUfM 3PyjcaPd+NJbHUH1fQPD9pdxxZsIrXW5riOd8N8srtaxmJchRuVZDgk44APQUUAczol74+m1SGPW /DPhmysDu82ez8QT3MqfKcbY2s4w2WwDlxgEnnGDDf3/AMSUvrhLHwn4SntFlYQSzeJbiKR0z8rM gsWCsRglQzAHjJ611lFAHP8AiS78aQXyJ4c0Dw/qNoYgXlv9bmtJA+TlQiWsoK42nduBySMcZMOr 3vjiPwgLmx0HRW187/NtU1F5oolw+GiZo4vPfhP3bmBSSQZUA3npqKAPP/AjWF3/AGnqsF5/a3ju C2Meo2mpXTQPYSvki38gNKLOF2jUBow4lSKOQvcECRtrRL3x9NqkMet+GfDNlYHd5s9n4gnuZU+U 42xtZxhstgHLjAJPOMHoHtLV76K+e2ha7hieGKcxgyIjlS6BuoVjGhIHBKLnoKmoA8z1ub+yPF81 r8OJ/t2uSXKya3oqzedZQJIQ/nTBpVFg7sxbfGGeTzJZDb3JXdH02q3vj6P7J/ZfhnwzdbrZGuvt PiCeDypzneibbN96DjDnYTk5Rcc9BZWlrZQtDZ20NtE0skzJFGEUvI5d3IH8TOzMT1JYk8mpqAOf uLvxovh22nt9A8Pya00pFxaSa3MltGnzYZJxalnbhPlMSj5m5+Ubp/DFz4quPtH/AAk2jaLpu3b9 n/s7VZbzzOu7dvt4dmPlxjdnJ6Y52aKAOM0j/kt/ij/sW9G/9KdUrwz4r/8ACV/8LN8R+X/wsDy/ tPhrZ5f9h7Nn9tT+Rt3fNs3Z8nd8+/P2j5MV9J22iWsHiq/8RpJMbu+sbaylQkeWEged0IGM7ibl 85JGAuAMHMP/AAi2hf2v/a32H/Tf7S/tTzPNf/j6+yfY/MxnH+o+Tbjb3xu5oA4XxOdf8Q32n+GL C01O5u9N0i2v9TjvvEz6LIzXBkjiLy6fE5klU21xvRGSEFwQJPlMe18CNYutd+GdnqF3eQ3rC+1C 3imhvTdxtDDezxQhbhgGnURxoBKw3SAbm+Zia6DxP4T8K+KPs/8Awk3hrRdb+zbvs/8AaNjFceVu xu271O3O1c464HpVzStJ0rSftf8AZemWVh9suXu7r7NAsfnzvjfK+0Dc7YGWOScDJoAu0UUUAFFF FABRRRQAVxnxD/5G74cf9jJN/wCmnUa7OszWdEtdV1HRL64kmWXRr5r23EZAVna3mtyHyDldk7nj ByF5xkEA06KKKACiiigAooooAKKKKAOZ8O22lReO/FVxaeLb3U7+f7H9t0eXUVmi0nbERH5cA5g8 1cuc/fIyK6aqVppOlWeqX2qWmmWVvf6h5f226igVZbny12x+Y4GX2qSBknA4FXaACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsbSNf8A7R8T65oX9ia1af2R 9n/066tdlpe+ahf/AEeTP7zZja/A2sQOa2axtI/4Sr/hJ9c/tb+xf7A/0f8AsX7L5v2v7h8/7Ru+ T7+Nmz+HOeaANmiiigAooooAKKKKACiiigAooooAKKKKACiiigDmdN1S/m+KevaJJPusLTRNMuoI ti/JLNPfrI2cZOVgiGCcDbxjJz01cnpVpdJ8YfEd89tMtpN4f0mGKcxkRu6XGol0DdCyiRCQOQHX PUV1lABRRRQAUUUUAFFFFABRRRQAVzPjLVL/AE/xH4KtLOfyodT1uS1vF2KfMiGnXkwXJGR+8hjb Iwflx0JB6auT8dWl1c+KPAM1vbTTRWviCWa4eOMssKHTL9A7kfdXe6Lk8ZZR1IoA6yiiigAooooA KKKKACiiigDG0jX/AO0fE+uaF/YmtWn9kfZ/9OurXZaXvmoX/wBHkz+82Y2vwNrEDmtmsbSP+Eq/ 4SfXP7W/sX+wP9H/ALF+y+b9r+4fP+0bvk+/jZs/hznmtmgAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAoormfDttpUXjvxVcWni291O/n+x/bdHl1FZotJ2x ER+XAOYPNXLnP3yMigDpqKKKACobK7tb2FprO5huYllkhZ4pA6h43KOhI/iV1ZSOoKkHkVS8SQa/ PYonhzU9M067EoLy3+nvdxlMHKhEmiIbO07txGARjnI85+Ddt4+h8OX1x/bPhm+tk1vXf9C/sqe2 eecajdj/AI+PtEgiRpfm/wBTIVQ7fmI3EA9ZormdEvfH02qQx634Z8M2Vgd3mz2fiCe5lT5TjbG1 nGGy2AcuMAk84wYb+/8AiSl9cJY+E/CU9osrCCWbxLcRSOmflZkFiwViMEqGYA8ZPWgDrKK4z4j6 h4ys/JXQrLbpLbft2oWUQvL+3T5vMaO1cop2qAyupnfdhRbSg0aILaz8IQ3nwui0XxHDeXLSSXV5 4gmdbnAKNI13suHmdTGkYDZwqBdwCBaAOzorn9HXX9XsdQsfGnh3w/b2k8XkiC11J9QjuEYMJElW W3iAXGBj5gwJzjHPJ+DdT1VtcjtvAt1/wk/go43ajqF+0yROWXzVt75pJJbraMkI0bJvMifaU8sQ qAemUVyd/f8AxJS+uEsfCfhKe0WVhBLN4luIpHTPysyCxYKxGCVDMAeMnrVzxJd+NIL5E8OaB4f1 G0MQLy3+tzWkgfJyoRLWUFcbTu3A5JGOMkA6CiufuLvxovh22nt9A8Pya00pFxaSa3MltGnzYZJx alnbhPlMSj5m5+Ubp/DFz4quPtH/AAk2jaLpu3b9n/s7VZbzzOu7dvt4dmPlxjdnJ6Y5ALkOqWE2 uXWiRz7r+0tobqeLY3yRTNKsbZxg5aCUYByNvOMjNPxH4p0Lw75v9sX32XytNutUf9074tbby/Pk +UH7vmx/L947uAcHGLpH/Jb/ABR/2Lejf+lOqV4Z8V/+Er/4Wb4j8v8A4WB5f2nw1s8v+w9mz+2p /I27vm2bs+Tu+ffn7R8mKAPpN9e0xPFUXhh5Zl1Saxe/ijNtII3hR1jciXb5ZZWkTKBtwDqSMEGt OvJvE1jDqnxL+Hml65rOtadLdeG9VV4zfx2l7eSq+nOYnktiMONrSMLdlB8o4Jj3K3W/Da7upV1/ TXuZr3T9I1drDTbyaQyyTwrBCzhpT/rWimeeAuctmDDlpFdiAdZRRRQAUUUUAFFFFABVLUdUsNPv NNtLyfyptTuTa2a7GPmSiGSYrkDA/dwyNk4Hy46kA3a4z4h/8jd8OP8AsZJv/TTqNAHZ0UUUAFFF FABRRRQAUUUUAFFcz4dttKi8d+Kri08W3up38/2P7bo8uorNFpO2IiPy4BzB5q5c5++RkV01ABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABVK00nSrPVL7VLT TLK3v9Q8v7bdRQKstz5a7Y/McDL7VJAyTgcCrtY2ka//AGj4n1zQv7E1q0/sj7P/AKddWuy0vfNQ v/o8mf3mzG1+BtYgc0AbNFFFABRRXM/DTVL/AFjw5d3eoz+fNHrerWqtsVcRQajcQxLhQB8scaLn qcZOSSaAOmooooAKht7S1tprma3toYZbqUTXDxxhWmcIqB3I+82xEXJ5wqjoBU1FAEN/aWt/Y3Fj fW0N1aXMTQzwTRh45UYYZGU8MpBIIPBBqaiigAooooAKKKKAMy20S1g8VX/iNJJjd31jbWUqEjyw kDzuhAxncTcvnJIwFwBg5h/4RbQv7X/tb7D/AKb/AGl/anmea/8Ax9fZPsfmYzj/AFHybcbe+N3N bNFAGNrfhPwrrlxNca34a0XU5p7ZbSWS8sYpmkgWQSiJiyklBIA4U8bgDjPNadhaWthY29jY20Nr aW0SwwQQxhI4kUYVFUcKoAAAHAAqaigAooooAKKKKACiiigArM1nRLXVdR0S+uJJll0a+a9txGQF Z2t5rch8g5XZO54wchecZB06KACiiigAooooAKKKKACiiigClaaTpVnql9qlppllb3+oeX9tuooF WW58tdsfmOBl9qkgZJwOBV2sbSNf/tHxPrmhf2JrVp/ZH2f/AE66tdlpe+ahf/R5M/vNmNr8DaxA 5rZoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKxtI/4S r/hJ9c/tb+xf7A/0f+xfsvm/a/uHz/tG75Pv42bP4c55rZooAKKKKACuT+FFpdWXhe8hvLaa2lbx BrUypLGUYpJqd06OAf4WRlYHoQwI4NdZVLRtUsNYs5LvTp/PhjuZ7Vm2MuJYJnhlXDAH5ZI3XPQ4 yMgg0AXaKKKACiiigAooooAKKKKACiiigArk7/4ZfDa/vri+vvh74Suru5laaeebRrd5JXY5Z2Yp lmJJJJ5JNdZRQBz/AIk8EeC/Et8l94j8IeH9Zu44hCk9/psNxIqAkhAzqSFyzHHTJPrRceCPBdz4 dtvDlx4Q8PzaLayma306TTYWtoXO4l0iK7Vb535Az8zeproKKAOf0fwR4L0ax1Cx0jwh4f0601KL yb+C102GKO6TDDZKqqA64dhhsjDH1NQ6J8PfAOh6pDqmieB/DOmX8G7yrqz0qCGWPcpU7XVQRlSQ cHoSK6aigDk7/wCGXw2v764vr74e+Erq7uZWmnnm0a3eSV2OWdmKZZiSSSeSTVzxJ4I8F+Jb5L7x H4Q8P6zdxxCFJ7/TYbiRUBJCBnUkLlmOOmSfWugooA5+48EeC7nw7beHLjwh4fm0W1lM1vp0mmwt bQudxLpEV2q3zvyBn5m9TRo/gjwXo1jqFjpHhDw/p1pqUXk38FrpsMUd0mGGyVVUB1w7DDZGGPqa 6CigDmdE+HvgHQ9Uh1TRPA/hnTL+Dd5V1Z6VBDLHuUqdrqoIypIOD0JFdNRRQAUUUUAFFFFABRRR QAUUUUAY2kf8JV/wk+uf2t/Yv9gf6P8A2L9l837X9w+f9o3fJ9/GzZ/DnPNbNFFABRRRQAUUUUAF FFFABRRRQAUVw+leGfDes+KfF11rHh/SdRnXVoo1lurOOVwosbQhQWBOMknHua1f+ED8Df8AQmeH P/BXD/8AE0zvqYfDU2lKcr2T+FdUn/N5nR0Vzn/CB+Bv+hM8Of8Agrh/+Jo/4QPwN/0Jnhz/AMFc P/xNBnyYX+eX/gK/+TOjornP+ED8Df8AQmeHP/BXD/8AE0f8IH4G/wChM8Of+CuH/wCJoDkwv88v /AV/8mdHRXOf8IH4G/6Ezw5/4K4f/iaP+ED8Df8AQmeHP/BXD/8AE0ByYX+eX/gK/wDkzo6K5z/h A/A3/QmeHP8AwVw//E0f8IH4G/6Ezw5/4K4f/iaA5ML/ADy/8BX/AMmdHRXOf8IH4G/6Ezw5/wCC uH/4mo/hjbwWvhaS1tYY4IIdW1OOKKNQqIovpwFUDgADgAUDnQo+xdSnJuzSs0lun/efY6eiiikc YUUUUAFcz4dttKi8d+Kri08W3up38/2P7bo8uorNFpO2IiPy4BzB5q5c5++RkV01UrTSdKs9UvtU tNMsre/1Dy/tt1FAqy3Plrtj8xwMvtUkDJOBwKALtFFFABXGfBv/AJFG+/7GTXf/AE7XddnWZ4a0 S10DTpbGzkmkilvru9YykFt9zcSXDgYA+UPKwHfAGSTyQDTooooAKKKKACiiigAooooAKhv2uksb h7GGGe7WJjBFNKYo3fHyqzhWKqTgFgrEDnB6VNRQBzOiXvj6bVIY9b8M+GbKwO7zZ7PxBPcyp8px tjazjDZbAOXGASecYMN/f/ElL64Sx8J+Ep7RZWEEs3iW4ikdM/KzILFgrEYJUMwB4yetdZRQBz/i S78aQXyJ4c0Dw/qNoYgXlv8AW5rSQPk5UIlrKCuNp3bgckjHGSXF340Xw7bT2+geH5NaaUi4tJNb mS2jT5sMk4tSztwnymJR8zc/KN3QUUAc/o9340lsdQfV9A8P2l3HFmwitdbmuI53w3yyu1rGYlyF G5VkOCTjgAw6Je+PptUhj1vwz4ZsrA7vNns/EE9zKnynG2NrOMNlsA5cYBJ5xg9NRQByd/f/ABJS +uEsfCfhKe0WVhBLN4luIpHTPysyCxYKxGCVDMAeMnrVzxJd+NIL5E8OaB4f1G0MQLy3+tzWkgfJ yoRLWUFcbTu3A5JGOMnoKKAOfuLvxovh22nt9A8Pya00pFxaSa3MltGnzYZJxalnbhPlMSj5m5+U bjR7vxpLY6g+r6B4ftLuOLNhFa63NcRzvhvlldrWMxLkKNyrIcEnHAB6CigDmdEvfH02qQx634Z8 M2Vgd3mz2fiCe5lT5TjbG1nGGy2AcuMAk84wYb+/+JKX1wlj4T8JT2iysIJZvEtxFI6Z+VmQWLBW IwSoZgDxk9a6yigAooooAKKKKACiiigAooooA5nw7baVF478VXFp4tvdTv5/sf23R5dRWaLSdsRE flwDmDzVy5z98jIrpqpWmk6VZ6pfapaaZZW9/qHl/bbqKBVlufLXbH5jgZfapIGScDgVdoAKKKKA CiiigAooooAKKKKAOc8I/wDIf8Yf9hmP/wBILSrXjvUNV0nwPr2qaFZfb9Ws9NuLixtfKaTz50iZ o49iEM25gBhSCc4HNVfCP/If8Yf9hmP/ANILSujps68b/EX+GH/pKPIPEOu/F7Tr7xXY2OqeEtTu 9C8Pw6vBBD4YuvMvnlN2Ft1UXxIYm0ABG4kyfd452dM1L4k6p4l8VwWOq+EjaaHq4tILSbSLhJLp Da29yqtcC5YRti4EZkELgFd+w52Vd0fTfGkXxZ1bX7zSvD8ei39jbaeskWrzPcoltJdyJIYjbKpZ /tKgp5mE2khn6VS0zTfiTpfiXxXPY6V4SFprmri7gu5tXuHktUFrb2ys1uLZRI2LcSGMTICW2bxj fSOQzPDfxO1XVvifo1kIrI+E/EWiWN9pg+ytHfwT3UF1OiTN5rRsgjsLgkqAQzxKAwDPWn8DfGev +ObTXtX1VdMi05L6EaRDbW7pMtrNaQXcTTs0jK0piuolZUAVWR8FgRjMtfhLbXNxqXhXX9MstR8C SeG9I0S3D6nML2X+z5JJEaVY44wuWm6pJ/yyHGHITrfA2k6/pviXxne6vbaZFaavq6Xtg1rePNIU W1gtsSq0SBGxbK/ys4zIVz8oZgDrKKKKACiiigArnPh3/wAgC6/7DOqf+l9xXR1znw7/AOQBdf8A YZ1T/wBL7ig64f7rP/FH8pnR0UUUHIFFFFABWNpGv/2j4n1zQv7E1q0/sj7P/p11a7LS981C/wDo 8mf3mzG1+BtYgc1s1jaR/wAJV/wk+uf2t/Yv9gf6P/Yv2Xzftf3D5/2jd8n38bNn8Oc80AbNFFFA GZ4k8Q6B4asUvvEeuaZo1pJKIUnv7tLeNnIJCBnIBbCscdcA+lcl8Mvil4V8XobNfFfhmfWJNS1C 3trGz1CJpZYILmZIpFj3lm3QRpISOCCWGFIr0Cuf8OeF7XTPDV/oN8YdUtL6+1G5njmgHlyJd3U0 7RMhJDKBMUOeGAzgZwADoKK5nRPh74B0PVIdU0TwP4Z0y/g3eVdWelQQyx7lKna6qCMqSDg9CRUN /wDDL4bX99cX198PfCV1d3MrTTzzaNbvJK7HLOzFMsxJJJPJJoA2fEmv6N4csUvNa1GGzillEMCu cyXExBKwxIMtLK207Y0DMxGACaPDd/qepWL3Wp6HNojNKRDa3FxHLOEAHzSeUWjVi27Cq7jbtJIY lFpeJPCGja3fJqrJNp+tRRCKDVrCTyLuNASyoXH+siDnf5MoeJmALI2Kh/4Rz/hIdD/sv4jaT4Z8 ReRc+ZC39n7reT5flk8iYyeU43umA75A3bhvKKAdBftdJY3D2MMM92sTGCKaUxRu+PlVnCsVUnAL BWIHOD0rF8N+LNO1e+fSbiGbR9eiiM02jX7xC7SHIAmAjd1kiO5R5kbMoYlCQ6sqmj+FdA8KWOoP 4L8J+H9Lu7iLJitbZLKO5dA3lrK8UZIXLEbtrFQxIB6GnYeC47u+t9Y8Z3MPiLV7eVZbfMLxWNo6 HMbwWjSSKkq8nzmLy5dwHVCsagHWUVyd/wDDL4bX99cX198PfCV1d3MrTTzzaNbvJK7HLOzFMsxJ JJPJJq54k8EeC/Et8l94j8IeH9Zu44hCk9/psNxIqAkhAzqSFyzHHTJPrQB0Fcn4D166u/B+pavq 8s1y1pq+sQkw2xkk8m31C5ijRY4lLOwjjVQFBZiO7Hnf0TSdK0PS4dL0TTLLTLCDd5VrZwLDFHuY sdqKABliScDqSa5n4baXN/whOqabqUF7afadb1wkB5LeXypdSumR0dSrruR1ZXUg4IZT0NAHDeFP ixca/wCPdO01X8QW9pfavqUiwt4au9qW9q0dilsXMAwrzP8AanmJHkEeRJjOa9Av/G6xX1wmm+GP EGt6faStDealp0cEkEDocSoEaVZpmjwQwgjkO4NGMyKyDz/4YfCe407xNpOt6sniCwazsbi9aJvE t3Ov2u+vftL2pxOQy24hjR2IKXRl3uNyV2drpvjTwu13p/hjSvD+saXcX1zqEcmo6vNZTwvczvPL GQltMsiiSRyr5Q7WVSpKGRwDrNC1D+1tDsNU+xXth9sto7j7LexeXcQb1DeXImTtdc4YZOCCKu1D YLdJY26X00M92sSieWGIxRu+PmZULMVUnJClmIHGT1qagDG8d6hquk+B9e1TQrL7fq1nptxcWNr5 TSefOkTNHHsQhm3MAMKQTnA5rznxDrvxe06+8V2NjqnhLU7vQvD8OrwQQ+GLrzL55TdhbdVF8SGJ tAARuJMn3eOfX64bR9N8aRfFnVtfvNK8Px6Lf2Ntp6yRavM9yiW0l3IkhiNsqln+0qCnmYTaSGfp QBS0zUviTqniXxXBY6r4SNpoeri0gtJtIuEkukNrb3Kq1wLlhG2LgRmQQuAV37DnZWZ4b+J2q6t8 T9GshFZHwn4i0SxvtMH2Vo7+Ce6gup0SZvNaNkEdhcElQCGeJQGAZ609M034k6X4l8Vz2OleEhaa 5q4u4LubV7h5LVBa29srNbi2USNi3EhjEyAltm8Y31mWvwltrm41Lwrr+mWWo+BJPDekaJbh9TmF 7L/Z8kkiNKsccYXLTdUk/wCWQ4w5CAGn8DfGev8Ajm017V9VXTItOS+hGkQ21u6TLazWkF3E07NI ytKYrqJWVAFVkfBYEY9Grk/A2k6/pviXxne6vbaZFaavq6Xtg1rePNIUW1gtsSq0SBGxbK/ys4zI Vz8oZusoAKKKKAOZ+LGqX+h/Czxbrelz/Z7/AE/RL26tZdit5cscDsjYYEHDAHBBHrXTVyfxntLq /wDg940sbG2muru58P38MEEMZeSV2t3CoqjlmJIAA5JNdZQAUUUUAFFFFABRRRQBjaRr/wDaPifX NC/sTWrT+yPs/wDp11a7LS981C/+jyZ/ebMbX4G1iBzWzWNpH/CVf8JPrn9rf2L/AGB/o/8AYv2X zftf3D5/2jd8n38bNn8Oc81s0AFFFFABRRRQAUUUUAFFFFAHOeEf+Q/4w/7DMf8A6QWldHXOeEf+ Q/4w/wCwzH/6QWldHTZ143+Iv8MP/SUFQ3F3a201tDcXMMMt1KYbdJJArTOEZyiA/ebYjtgc4Vj0 BqavJviTZePj428EtD4m8MpDJ4kn+wI/h+dmg/4lt+R5rC8Al/d7l+UR5YhuAChRyHoHifxZ4V8L /Z/+Em8S6Lon2nd9n/tG+it/N243bd7DdjcucdMj1qay8Q6Be+HW8R2euaZc6KsUkzajFdo9sEjy Hcyg7dq7Wyc4G056Vw3xD/4Sq0n+HH/IF1rX08STf89dOtJc6ZqP/Xw8eEP+3lh/CD8sGv6THpPg rxJrnjjWNM8Oy6p4g0/VjLHI9zaafcQtZQ2oeRljaSIy2sLOSsWFkddyhfNoA9A0HxDoGvwibQdc 0zVYjEsweyu0mXYXdA+UJ+UvFKoPTMbjqpxSt/G/gu51a50i38X+H5tRtZRDcWkepQtNC5lWEI6B tyt5rpHgjO5lXqQK851u21uxt/ivbw29lP41n8Iw3a6roFlNZy3TNHfR20Yh82VjNG0LYlVtzCRF wPLUn0DUNL8D6p4Y0I3MGiyaHZ3NjdaLJG6Jbwyq6fZGt2UgDLFEQKcMH2chiCAdNRRRQAVznw7/ AOQBdf8AYZ1T/wBL7iujrnPh3/yALr/sM6p/6X3FB1w/3Wf+KP5TOjooooOQKKKKACiiuZ8O22lR eO/FVxaeLb3U7+f7H9t0eXUVmi0nbERH5cA5g81cuc/fIyKAOmooooAKKKKACiiigAooooAKKKKA CiiigAqlo2qWGsWcl3p0/nwx3M9qzbGXEsEzwyrhgD8skbrnocZGQQau1xnwb/5FG+/7GTXf/Ttd 0AdnRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFLXtUsND0O/1vVJ/s9hp9tJdXUuxm8uKNSzthQScK CcAE+lXa4z47f8kQ8ef9i3qP/pNJXZ0AFFFFABRRRQAUUUUAFFcz4dttKi8d+Kri08W3up38/wBj +26PLqKzRaTtiIj8uAcweauXOfvkZFdNQAUUUUAFFFFABRRRQAUUUUAc54R/5D/jD/sMx/8ApBaV 0dc54R/5D/jD/sMx/wDpBaVu363T2NwljNDBdtEwglmiMsaPj5WZAyllBwSoZSRxkdabOvG/xF/h h/6SiaiuM+E+qeKta0i/1DxNf6Lc7NSvLG3TTtNlttv2W7nt2di88u7f5SsANu3JGW61P4q1hbbx z4T0m4svEEMV1fSG3vrSaBbOaYWd0xt7hTJ5rLsR5BiPbvWI7sgikchp+J/CfhXxR9n/AOEm8NaL rf2bd9n/ALRsYrjyt2N23ep252rnHXA9KuLpOlLpdtpa6ZZLYWnk/ZrUQL5UPksrRbExhdjIhXA+ UqCMYFYHinxuuheKrLw1H4Y8Qatf6hYy3ln9gjgaOYRPGsqFpJUEbKJUbdJsQghVZnIQ5fizxTc3 3gnSPEXh++vdMceJNPsbuB4oWY7tSjsrq1l3Bx8rNKu6JvvICrlfvAHW+G/D2geGrF7Hw5oemaNa SSmZ4LC0S3jZyAC5VAAWwqjPXAHpVKy8EeC7LxE3iOz8IeH7bWmlkmbUYtNhS5LyZDuZQu7c25sn OTuOetZln4t1fxD/AMJJYeG/DV7a3Wm/arWy1TVGgOm3F5F8qqDDM0rJvOGIQbdkiNtkUoKVpF4g 0bx3pGkweM9a8T+fvk1W11C3slWyszFL5dwGt7eIq7TpHGqszb1MxCHy2eMA9AooooAK5z4d/wDI Auv+wzqn/pfcV0dc58O/+QBdf9hnVP8A0vuKDrh/us/8UfymdHRRRQcgUUUUAFUrTSdKs9UvtUtN Msre/wBQ8v7bdRQKstz5a7Y/McDL7VJAyTgcCrtFABRRRQAUUUUAFFFFABRWZ4k1/RvDlil5rWow 2cUsohgVzmS4mIJWGJBlpZW2nbGgZmIwATR4bv8AU9SsXutT0ObRGaUiG1uLiOWcIAPmk8otGrFt 2FV3G3aSQxKKAadFQ37XSWNw9jDDPdrExgimlMUbvj5VZwrFVJwCwViBzg9KxfDfizTtXvn0m4hm 0fXoojNNo1+8Qu0hyAJgI3dZIjuUeZGzKGJQkOrKoB0FFFFABWZ4a0S10DTpbGzkmkilvru9YykF t9zcSXDgYA+UPKwHfAGSTydOuT8B69dXfg/UtX1eWa5a01fWISYbYySeTb6hcxRoscSlnYRxqoCg sxHdjyAdZRXifhT4sXGv+PdO01X8QW9pfavqUiwt4au9qW9q0dilsXMAwrzP9qeYkeQR5EmM5rZ+ Mvj+907wF4ruvDFr4gVtLsblh4g0+2t57a2u4VY+UySFnkUOojkdInRNzhnRo5DGAep0UUUAFFFF ABRRRQAUUUUAFFFFAGZ4s0S18S+FdW8OX0k0dpqtjNZTvCQJFSVCjFSQQGwxxkEZ7GtOuZ+LGqX+ h/Czxbrelz/Z7/T9Evbq1l2K3lyxwOyNhgQcMAcEEetdNQAUUUUAFFFFABRRRQBStNJ0qz1S+1S0 0yyt7/UPL+23UUCrLc+Wu2PzHAy+1SQMk4HAq7WNpGv/ANo+J9c0L+xNatP7I+z/AOnXVrstL3zU L/6PJn95sxtfgbWIHNbNABRRRQAUUUUAFFFFABRRRQBznhH/AJD/AIw/7DMf/pBaVu37XSWNw9jD DPdrExgimlMUbvj5VZwrFVJwCwViBzg9KwvCP/If8Yf9hmP/ANILSujps68b/EX+GH/pKPJtE0D4 p2uiw6G1j4Z0+GTxI2rXN9Z+IblpVgk1U3ssKx/Y0D5jZ4Tl1DAknAJWtnx7p/j7UfFeg3miaJ4Z msND1I30T3muTwS3O6yntyjIto4jw1wSCGbIQcDd8voFFI5DjJdL8VXPxL8N+IprDRYrC00S7s78 JqUryxz3D28hESmACRFa1VdzMhYSE7V2ANzP/CD+MNQ+Gv8Awi2qW2i201z4u/tW6ey1m5Hl2bap /aD+XKsCP5wJMSgbOzh1Pyj1migDz/wrpfj7w9oeq+HNPsPDKabYW00PhSWXUp5XjRVC2sF0ggTK LggurlwgVT5jhpWPBOn+PtKvLS1u9E8M29lNcvcazqP9uT3t9euYWUPj7JCm8uIR1CJGmxEVQgX0 CigArn/EngjwX4lvkvvEfhDw/rN3HEIUnv8ATYbiRUBJCBnUkLlmOOmSfWugooA5+48EeC7nw7be HLjwh4fm0W1lM1vp0mmwtbQudxLpEV2q3zvyBn5m9TWH8MPCfhWz8L6vb2nhrRbeHUNQ1C0vY4rG JVuYI7u4ijikAXDosZKBTkBeAMcV3lc58O/+QBdf9hnVP/S+4oOuH+6z/wAUfymM0T4e+AdD1SHV NE8D+GdMv4N3lXVnpUEMse5Sp2uqgjKkg4PQkVDf/DL4bX99cX198PfCV1d3MrTTzzaNbvJK7HLO zFMsxJJJPJJrrKKDkOf8SeCPBfiW+S+8R+EPD+s3ccQhSe/02G4kVASQgZ1JC5Zjjpkn1ouPBHgu 58O23hy48IeH5tFtZTNb6dJpsLW0LncS6RFdqt878gZ+ZvU10FFAHP6P4I8F6NY6hY6R4Q8P6daa lF5N/Ba6bDFHdJhhslVVAdcOww2Rhj6modE+HvgHQ9Uh1TRPA/hnTL+Dd5V1Z6VBDLHuUqdrqoIy pIOD0JFdNRQByd/8Mvhtf31xfX3w98JXV3cytNPPNo1u8krscs7MUyzEkkk8kmrniTwR4L8S3yX3 iPwh4f1m7jiEKT3+mw3EioCSEDOpIXLMcdMk+tdBRQBz9x4I8F3Ph228OXHhDw/NotrKZrfTpNNh a2hc7iXSIrtVvnfkDPzN6mjR/BHgvRrHULHSPCHh/TrTUovJv4LXTYYo7pMMNkqqoDrh2GGyMMfU 10FFAHM6J8PfAOh6pDqmieB/DOmX8G7yrqz0qCGWPcpU7XVQRlSQcHoSKhv/AIZfDa/vri+vvh74 Suru5laaeebRrd5JXY5Z2YplmJJJJ5JNdZRQBz/iTwho2t3yaqyTafrUUQig1awk8i7jQEsqFx/r Ig53+TKHiZgCyNiof+Ec/wCEh0P+y/iNpPhnxF5Fz5kLf2fut5Pl+WTyJjJ5Tje6YDvkDduG8ovT UUAc/o/hXQPCljqD+C/Cfh/S7u4iyYrW2SyjuXQN5ayvFGSFyxG7axUMSAehp2HguO7vrfWPGdzD 4i1e3lWW3zC8VjaOhzG8Fo0kipKvJ85i8uXcB1QrGvWUUAcnf/DL4bX99cX198PfCV1d3MrTTzza NbvJK7HLOzFMsxJJJPJJq54k8EeC/Et8l94j8IeH9Zu44hCk9/psNxIqAkhAzqSFyzHHTJPrXQUU AUtE0nStD0uHS9E0yy0ywg3eVa2cCwxR7mLHaigAZYknA6kmuZ+G2lzf8ITqmm6lBe2n2nW9cJAe S3l8qXUrpkdHUq67kdWV1IOCGU9DXZ0UAeJ/DD4T3GneJtJ1vVk8QWDWdjcXrRN4lu51+13179pe 1OJyGW3EMaOxBS6Mu9xuStnxj4M8aS+CvFPgfww3h86Xr0WpPHf6jcTLPbPetLLLEYUjKyKZJXCy 70KK65jkMR831OigCGwa6ext3voYYLtolM8UMpljR8fMquVUsoOQGKqSOcDpU1FFABRRRQAUUUUA FFFFABRRRQByfxntLq/+D3jSxsbaa6u7nw/fwwQQxl5JXa3cKiqOWYkgADkk11lFFABRRRQAUUUU AFFFFAGNpH/CVf8ACT65/a39i/2B/o/9i/ZfN+1/cPn/AGjd8n38bNn8Oc81s0UUAFFFFABRRRQA UUUUAFFFFAHOT+F7j+1dQv7DxRrWmfb5lnmht0tWj3rEkWR5sLsPljXjOM0f8I7rH/Q+eI/+/Fh/ 8jV0dFO51/XatknZ2stYxe2i1aOc/wCEd1j/AKHzxH/34sP/AJGo/wCEd1j/AKHzxH/34sP/AJGr o6KLh9dqdo/+AR/yOc/4R3WP+h88R/8Afiw/+RqP+Ed1j/ofPEf/AH4sP/kaujoouH12p2j/AOAR /wAjnP8AhHdY/wCh88R/9+LD/wCRqP8AhHdY/wCh88R/9+LD/wCRq6Oii4fXanaP/gEf8jnP+Ed1 j/ofPEf/AH4sP/kaj/hHdY/6HzxH/wB+LD/5Gro6KLh9dqdo/wDgEf8AI5z/AIR3WP8AofPEf/fi w/8AkatLw3pMeiaUthHdXN3++mnea42eZI8sryuTsVV+87cAAYrRopEVMVUqQ5Ha2+iS/JLuwooo oOcKKKKACuZ8O22lReO/FVxaeLb3U7+f7H9t0eXUVmi0nbERH5cA5g81cuc/fIyK6aqVppOlWeqX 2qWmmWVvf6h5f226igVZbny12x+Y4GX2qSBknA4FAF2iiigAooooAKKKKACiiigAooooAKKKKACo b9rpLG4exhhnu1iYwRTSmKN3x8qs4Viqk4BYKxA5welTUUAczol74+m1SGPW/DPhmysDu82ez8QT 3MqfKcbY2s4w2WwDlxgEnnGDDf3/AMSUvrhLHwn4SntFlYQSzeJbiKR0z8rMgsWCsRglQzAHjJ61 1lFAHP8AiS78aQXyJ4c0Dw/qNoYgXlv9bmtJA+TlQiWsoK42nduBySMcZJcXfjRfDttPb6B4fk1p pSLi0k1uZLaNPmwyTi1LO3CfKYlHzNz8o3dBRQBz+j3fjSWx1B9X0Dw/aXccWbCK11ua4jnfDfLK 7WsZiXIUblWQ4JOOADDol74+m1SGPW/DPhmysDu82ez8QT3MqfKcbY2s4w2WwDlxgEnnGD01FAHJ 39/8SUvrhLHwn4SntFlYQSzeJbiKR0z8rMgsWCsRglQzAHjJ61c8SXfjSC+RPDmgeH9RtDEC8t/r c1pIHycqES1lBXG07twOSRjjJ6CigDn7i78aL4dtp7fQPD8mtNKRcWkmtzJbRp82GScWpZ24T5TE o+ZuflG40e78aS2OoPq+geH7S7jizYRWutzXEc74b5ZXa1jMS5CjcqyHBJxwAegooA5nRL3x9Nqk Met+GfDNlYHd5s9n4gnuZU+U42xtZxhstgHLjAJPOMGG/v8A4kpfXCWPhPwlPaLKwglm8S3EUjpn 5WZBYsFYjBKhmAPGT1rrKKACiiigAooooAKKKKACiiigDmfDttpUXjvxVcWni291O/n+x/bdHl1F ZotJ2xER+XAOYPNXLnP3yMiumqlaaTpVnql9qlppllb3+oeX9tuooFWW58tdsfmOBl9qkgZJwOBV 2gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArG0jX/wC0 fE+uaF/YmtWn9kfZ/wDTrq12Wl75qF/9Hkz+82Y2vwNrEDmtmsbSP+Eq/wCEn1z+1v7F/sD/AEf+ xfsvm/a/uHz/ALRu+T7+Nmz+HOeaANmiuZ8Yf8J9/bmgf8Ih/wAIz/ZP2n/ie/2p5/2jyN0f/Ht5 fy79vm/f4zs7Zq742/4Sr/hGLv8A4Qr+xf7f+T7J/a/m/ZPvrv3+V8/3N+MfxYzxmgDZoqloX9q/ 2HYf279i/tb7NH9u+xbvs/n7R5nl7/m2bs7d3OMZ5rG+HH/Cff2HN/wsb/hGf7W+0t5P9gef9n8j au3d53zb92/OOMbe+aAOmormdO/4T7/hYepf2h/wjP8AwhX2Yf2d5Hn/ANpefiPPm5/dbM+djbz9 z3o8Yf8ACff25oH/AAiH/CM/2T9p/wCJ7/ann/aPI3R/8e3l/Lv2+b9/jOztmgDpqKxvG3/CVf8A CMXf/CFf2L/b/wAn2T+1/N+yffXfv8r5/ub8Y/ixnjNXNC/tX+w7D+3fsX9rfZo/t32Ld9n8/aPM 8vf82zdnbu5xjPNAF2iuZ+HH/Cff2HN/wsb/AIRn+1vtLeT/AGB5/wBn8jau3d53zb92/OOMbe+a NO/4T7/hYepf2h/wjP8AwhX2Yf2d5Hn/ANpefiPPm5/dbM+djbz9z3oA6aiuZ8Yf8J9/bmgf8Ih/ wjP9k/af+J7/AGp5/wBo8jdH/wAe3l/Lv2+b9/jOztmrvjb/AISr/hGLv/hCv7F/t/5Psn9r+b9k ++u/f5Xz/c34x/FjPGaANmiqWhf2r/Ydh/bv2L+1vs0f277Fu+z+ftHmeXv+bZuzt3c4xnmsb4cf 8J9/Yc3/AAsb/hGf7W+0t5P9gef9n8jau3d53zb92/OOMbe+aAOmormdO/4T7/hYepf2h/wjP/CF fZh/Z3kef/aXn4jz5uf3WzPnY28/c96PGH/Cff25oH/CIf8ACM/2T9p/4nv9qef9o8jdH/x7eX8u /b5v3+M7O2aAOmorG8bf8JV/wjF3/wAIV/Yv9v8AyfZP7X837J99d+/yvn+5vxj+LGeM1c0L+1f7 DsP7d+xf2t9mj+3fYt32fz9o8zy9/wA2zdnbu5xjPNAF2iuZ+HH/AAn39hzf8LG/4Rn+1vtLeT/Y Hn/Z/I2rt3ed82/dvzjjG3vmjTv+E+/4WHqX9of8Iz/whX2Yf2d5Hn/2l5+I8+bn91sz52NvP3Pe gDpqK5nxh/wn39uaB/wiH/CM/wBk/af+J7/ann/aPI3R/wDHt5fy79vm/f4zs7Zq742/4Sr/AIRi 7/4Qr+xf7f8Ak+yf2v5v2T7679/lfP8Ac34x/FjPGaANmiqWhf2r/Ydh/bv2L+1vs0f277Fu+z+f tHmeXv8Am2bs7d3OMZ5rG+HH/Cff2HN/wsb/AIRn+1vtLeT/AGB5/wBn8jau3d53zb92/OOMbe+a AOmormdO/wCE+/4WHqX9of8ACM/8IV9mH9neR5/9pefiPPm5/dbM+djbz9z3o8Yf8J9/bmgf8Ih/ wjP9k/af+J7/AGp5/wBo8jdH/wAe3l/Lv2+b9/jOztmgDpqKxvG3/CVf8Ixd/wDCFf2L/b/yfZP7 X837J99d+/yvn+5vxj+LGeM1c0L+1f7DsP7d+xf2t9mj+3fYt32fz9o8zy9/zbN2du7nGM80AXaK 5n4cf8J9/Yc3/Cxv+EZ/tb7S3k/2B5/2fyNq7d3nfNv3b844xt75o07/AIT7/hYepf2h/wAIz/wh X2Yf2d5Hn/2l5+I8+bn91sz52NvP3PegDpqK5nxh/wAJ9/bmgf8ACIf8Iz/ZP2n/AInv9qef9o8j dH/x7eX8u/b5v3+M7O2au+Nv+Eq/4Ri7/wCEK/sX+3/k+yf2v5v2T7679/lfP9zfjH8WM8ZoA2aK paF/av8AYdh/bv2L+1vs0f277Fu+z+ftHmeXv+bZuzt3c4xnmsb4cf8ACff2HN/wsb/hGf7W+0t5 P9gef9n8jau3d53zb92/OOMbe+aAOmormdO/4T7/AIWHqX9of8Iz/wAIV9mH9neR5/8AaXn4jz5u f3WzPnY28/c966agAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACivLPjF481HwZ4q0y3m8X+EvDWi3ekXt69xrG my3MhmtngBjjCXMXmM6T5CKpbMRxu3YXrfDNx4yttP1w+KLWy1K5s7k/2c2k24tvt8H2eJxiOWdw j+a0sfzyKDsBO0HNAHTUVyfgHXNOm8DXOu3FxqdjaQ32pPeNrtxEZbMx3k4mR3R2jEUbK6phiFjR OeKpN8Rlj1nRtMuPBfi22bXL4WumzTW0CRzL5ckrzNmbdCqxxlzHMEmIOFjZlcKAdzRXGan8QrPT /DfjHW5tB1pk8I3MkN/bJ9nMsiJDFOZosy7CnkzLJhmV8Ajbuwpu+N/Glh4QvNFi1LTNauYdWuZL WOfTrJrvypVheUK0UeZm3LHJgxxuBsO7aMGgDpqK5n/hMYYtD+3X+h61p9+1z9jh0ieKM3dxcFd6 xxFHaKTKfMXWQoihzIyeXJsm8N+J11W+fTNQ0XU/D+qCIzx2OpGAyTQghTLG0MkkbqrMFYBtyFk3 KokjLAHQUUVw3iq68Uad8RPCZXX4V0XU9Xksjp0Ngqsyf2ddTEzSuzs7CW3Qp5YiABYMJMggA7mi iigAooooAKK8sg+Jdrp/iXxvoPizx94G0S702+W20eO7xbSKj2sU6SzJJc5mUGcJ8nlgmFyCN2En +F/xG1fXbfwjp+v+HL3+0vEGiDWRqNnFBFp/leXDI4VWuXnGw3MMRyuWYlgAmSoB6ZRXlnjrx/er p2qz6da+INEbwz4p0rT75/s1vcrqEc9xbiSOOOMzSsrQXKONqpJl0A+YOg7Pw34nXVb59M1DRdT8 P6oIjPHY6kYDJNCCFMsbQySRuqswVgG3IWTcqiSMsAdBRXDeF/iVa+IGjFr4T8Wwql9LYX8k2nDy 7GZJ2gwzq5WZTIjAvbmZYwMymNcmrvirWFtvHPhPSbiy8QQxXV9Ibe+tJoFs5phZ3TG3uFMnmsux HkGI9u9YjuyCKAOsorn/ABJ4nXSr5NM0/RdT8QaoYhPJY6aYBJDCSVEsjTSRxorMpVQW3OVfarCO QrmfBfWL/XPAMd/qOoXuozDUtStlub21W2uJIob6eGLzIljjCP5caBhsU5ByAc0AdnRUN/NJbWNx cQ2k15LFEzpbwlBJMQMhFLsqhj0G5lGTyQOa4zwf8S9O8SroNzF4f8Qabp3iCJW0q+v4Io47mQwN OYggkaVWCRyneyCNhGSrsGjLgHc0Vyd/43WK+uE03wx4g1vT7SVobzUtOjgkggdDiVAjSrNM0eCG EEch3BoxmRWQTar4ys4vskegade+K7m6tkvUg0eW3bbavnZO0ksscQRyCE+fc+HKBgjlQDpqK85+ HXjKT/hWdvq2s3mp6zfTavqOn2KS2aQX9+Yr25jhj8nZEqy+VEC25YwgR3k2KrsOm8N+J11W+fTN Q0XU/D+qCIzx2OpGAyTQghTLG0MkkbqrMFYBtyFk3KokjLAHQUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHn/j7QvFWoeON P1TS9A8M6zpMOiX2mXVrq2py2/n/AGqW3ZwUW2mUoFtgME/N5hBAC/N2etyarDpc0miWVle342+V BeXbW0T/ADDO6RY5CuFyRhDkgDjORdooA8z8LeEvFV14M8Q+CvGOnaLZ6TrX9rNJd6TrEs9wv265 mlKBJLVFG1Z2G/JyUB2YYgc/ZeLdR8Y/ETwPbWuqeEtctNK1eee7ufDV1Lfrg6deRLPOVXy7FWZw Fid5S5kwrnymL+2UUAeWePfBnjS/0zx9onhxvD/2TxjFK73t/cTLJaO1hFaGIQpGRIrCBT5vmKUM pPlv5e2Ta8c6b401K58GanpGleH5bvSL59Qv7e61eaGMO1nPb+XFIts5dc3LNvZUOIx8vzHb3NFA HDeNPCd1428K6V/wkeieH5dU0y+OoJpdxKb3TbhwksQjkd4VYq0crEP5eY5NrbZAm14Phx4O/sPX JtR/4V78P/CWbZoN2gL51xcbmVsNL9ng2INnKbX3kqcpsw/oFFABXn/j3T/H2o+K9BvNE0TwzNYa HqRvonvNcnglud1lPblGRbRxHhrgkEM2Qg4G75fQKKAOf8UN40fwVI/hiHw/B4qaKIxxajLNLYo+ 5fNUuirIyhd4VtqknaSByK09C/tX+w7D+3fsX9rfZo/t32Ld9n8/aPM8vf8ANs3Z27ucYzzV2igA ooooA4zwrpfirStX8dahc2Git/aupC+0lI9SlPmbbSG3VJyYB5WfsyMSvmY8xhg7AX8/8Q6ppXw7 +EHhDRfFHiPwzp3jXwpbWUunWa6qv+lvEDahV80IVS4iMsLSuhSDzXck+Vvr3OigDznX/A+vp8M9 J8LeH77TJtUj1ez1G/1O/V0jeZL1L24uRAmdzSTKx8kPGoEhAdQoFbWg6Tr994qg8U+KbbTNPu7G xn0+zs9NvHuoyk7wySySSyRREsTbxBUCAKFcln3gR9ZRQB5/8MtP8faGh0vW9E8MpYT6lqF9LdWe uTzSx/abma5CLE1ogba0oQkuvALY/ho8e6f4+1HxXoN5omieGZrDQ9SN9E95rk8Etzusp7coyLaO I8NcEghmyEHA3fL6BRQBxl/pfiq01weLNFsNFudWv9NtrHU9Ou9Slit4/JaaRHhuFgZjta4mUhoh vBRgYyhWSf4U6Jr/AIe8NXWmeI5NMnuzq+oXaXFgXEc6XF1JcBjG4zE2ZWXy90gAUfO2eOsooAhv 2uksbh7GGGe7WJjBFNKYo3fHyqzhWKqTgFgrEDnB6V5loXhDxpp3hn4UaU9p4feXwnLGNUcanNtZ I7KayVof9H+dikxkKtsAKBMkNvHqdFAHDWuk+NPDrXek+GLbw/daXd31zex3uo3k0c9m91O80oMC RFbhVkkdl/ewkqVjJBUytBYeDtV8Gf2fN4IistV8jRLLQpbbWL5rbdBZ+aYJVmihk+f99IHUx4bc hBj2FZPQKKAPJofhpquoeBItI8V2nhnWb/TPEl/rdpDLGz6fqPny3L7Z4pEYw5W7lUAGby2WN8y4 MZ2fhx4O/sPXJtR/4V78P/CWbZoN2gL51xcbmVsNL9ng2INnKbX3kqcpsw/oFFAHM6d/wn3/AAsP Uv7Q/wCEZ/4Qr7MP7O8jz/7S8/EefNz+62Z87G3n7nvXTUUUAFFFFABRRRQAUUUUAf/Z --Boundary_(ID_z5azR8xcTBR12+9z5DOqyA) Content-id: <016101cb2170$47c0e9f0$514c460a@china.huawei.com> Content-type: image/jpeg; name=Image2.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=Image2.jpg /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCAEbAdIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7Looo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiuZ0vx54Z1TVPEul2F1 ezX/AIY2/wBrWo025EsO5XZNiGPM25UYr5YbcMFc7lyAdNRWZ4V17TPE/h2y8QaLLNNp19F51tLL bSQNIh6OEkVWCnqCRgggjIIJm17VLDQ9Dv8AW9Un+z2Gn20l1dS7Gby4o1LO2FBJwoJwAT6UAXaK KKACiiigAorG8c+IYfCfhDVfE1zYXt/baXbPdXENn5fmmJBl2USOinaoLEbgSFIGTgHZoAKKKKAC iuf+IPidfB3hW88RzaLqerWljE892lgYPMhhRGd5SJpIwVAXopLEkYU846CgAooooAKKKKACiqWv apYaHod/reqT/Z7DT7aS6updjN5cUalnbCgk4UE4AJ9Ku0AFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAV4zEl5D4r8e+MdJ0jWjquja2JoY5dLuEGpac1lYRXcMAdAJ3ZrF/LMZH72KHLCKQiT2aigDwa8 0HxKfg98MrS6s4f7FsPD9vDrul6h4en1Ui4FvAITLZRSRySLGyyqV+fY7xuYvk82G6/gy68UfALx Z4fu9Mh1t3ivD4ZtrzQTpsdo5tdkK28F1I8sCrK0oRpChQEhAsIjz7ZRQB5/4Es/h9cf2npHhf4e f2VYXtsV1Qy+FX0u3uF5VYpEnijM+5Xl4VXVQGDFdyh/ObbSvHvhjw7/AMI5oXg2G60XQrG70C30 6a33W2pCf7WYZp4lYLMz+VpO+YAIv26937cSeR9DUUAeMt4T0Lw466F4m8Na14ohsba1s/B9xBYv cy2sENtFF5aTRqq2V0Z0eQ3DGEESQnzcQ4hu/FnTLyb4O+GbLxda3uua5balor3tzo9hcTypPFcQ td3MJtoxJD+6W4IkQIQG2jBYKfWaKAPJvGWjeGbb4CeNbrwb4VvYbnW9EurZhHolyupX87RyRRmd Hj+0yuXckySgk72cnBLVN8O4LLRfiTrlnr2hzXnjG9l8ybxTbeHLiK2vYXjDLAJyjJCsKQxR+X5r K2yNt7TPIqep0UAFeGfFLRtYl8d6je68LK5sJPKPh+dvBuoa1LYIIkEghks50e0mEwaTzAiuwaIr K/lBIfc6KAPLPinf6jbfAK+0HVrXxBqviPVvC1zaYtdDlnkmuza7G80WiyxQszv037M52sQpNbXi 7UdX8XfDbVG8CtqdlqPmxxr9u025sZnRZI2nSNZ/Ifc8JdFdXjG5hiWMgunc0UAeJ/DLTYLS+1hT YQjwq+kTjU9JsPh7eaPaTuSm1jb3EjtPK0YmTbBES64WUnbAp4Xwbo91ofhzw/dQ6D4zt7jT9E8L 3RT+ztRZo7mPUTBqjeWVOZhbBIsYL/Zvkj/c5FfU1FAHhnxS0bWJfHeo3uvCyubCTyj4fnbwbqGt S2CCJBIIZLOdHtJhMGk8wIrsGiKyv5QSHU8eaLHqp+Ett4v0fU9a1CO+26pcrpLsyo+nzRTC4Nrv iiikneASR7zE4yDvjRiPX6KAPDNR8I2HiPwH8WPBOneDsw2tzOfDFjd6O1raQytpscavZmZFiX/S hcnfGQAzl84kDN3Xw1/4Qi3vru38EeBptAiliD3twPDMmkRuVOI0IljiaVvmkI2q4UBtxUsgfuaK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKpWmraVeapfaXaanZXF/p/l/bbWKdWltvMXdH5iA5TcoJGQMjkVdqlaaTpVn ql9qlppllb3+oeX9tuooFWW58tdsfmOBl9qkgZJwOBQAXeraVZ6pY6Xd6nZW9/qHmfYrWWdVlufL XdJ5aE5fapBOAcDk0a3q2laHpc2qa3qdlplhBt826vJ1hij3MFG52IAyxAGT1IFF3pOlXmqWOqXe mWVxf6f5n2K6lgVpbbzF2yeW5GU3KADgjI4NGt6TpWuaXNpet6ZZanYT7fNtbyBZopNrBhuRgQcM ARkdQDQBdqlomraVrmlw6pomp2Wp2E+7yrqznWaKTaxU7XUkHDAg4PUEVdqlomk6Voelw6XommWW mWEG7yrWzgWGKPcxY7UUADLEk4HUk0AFpq2lXmqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3KCRk DI5FF3q2lWeqWOl3ep2Vvf6h5n2K1lnVZbny13SeWhOX2qQTgHA5NFppOlWeqX2qWmmWVvf6h5f2 26igVZbny12x+Y4GX2qSBknA4FF3pOlXmqWOqXemWVxf6f5n2K6lgVpbbzF2yeW5GU3KADgjI4NA BreraVoelzaprep2WmWEG3zbq8nWGKPcwUbnYgDLEAZPUgVdqlrek6VrmlzaXremWWp2E+3zbW8g WaKTawYbkYEHDAEZHUA1doApaJq2la5pcOqaJqdlqdhPu8q6s51mik2sVO11JBwwIOD1BFFpq2lX mqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3KCRkDI5FGiaTpWh6XDpeiaZZaZYQbvKtbOBYYo9zF jtRQAMsSTgdSTRaaTpVnql9qlppllb3+oeX9tuooFWW58tdsfmOBl9qkgZJwOBQAXeraVZ6pY6Xd 6nZW9/qHmfYrWWdVlufLXdJ5aE5fapBOAcDk0a3q2laHpc2qa3qdlplhBt826vJ1hij3MFG52IAy xAGT1IFF3pOlXmqWOqXemWVxf6f5n2K6lgVpbbzF2yeW5GU3KADgjI4NGt6TpWuaXNpet6ZZanYT 7fNtbyBZopNrBhuRgQcMARkdQDQBdqlomraVrmlw6pomp2Wp2E+7yrqznWaKTaxU7XUkHDAg4PUE Vdqlomk6Voelw6XommWWmWEG7yrWzgWGKPcxY7UUADLEk4HUk0AFpq2lXmqX2l2mp2Vxf6f5f221 inVpbbzF3R+YgOU3KCRkDI5FF3q2lWeqWOl3ep2Vvf6h5n2K1lnVZbny13SeWhOX2qQTgHA5NFpp OlWeqX2qWmmWVvf6h5f226igVZbny12x+Y4GX2qSBknA4FF3pOlXmqWOqXemWVxf6f5n2K6lgVpb bzF2yeW5GU3KADgjI4NABreraVoelzaprep2WmWEG3zbq8nWGKPcwUbnYgDLEAZPUgVdqlrek6Vr mlzaXremWWp2E+3zbW8gWaKTawYbkYEHDAEZHUA1doApaJq2la5pcOqaJqdlqdhPu8q6s51mik2s VO11JBwwIOD1BFFpq2lXmqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3KCRkDI5FGiaTpWh6XDpei aZZaZYQbvKtbOBYYo9zFjtRQAMsSTgdSTRaaTpVnql9qlppllb3+oeX9tuooFWW58tdsfmOBl9qk gZJwOBQAXeraVZ6pY6Xd6nZW9/qHmfYrWWdVlufLXdJ5aE5fapBOAcDk0a3q2laHpc2qa3qdlplh Bt826vJ1hij3MFG52IAyxAGT1IFF3pOlXmqWOqXemWVxf6f5n2K6lgVpbbzF2yeW5GU3KADgjI4N Gt6TpWuaXNpet6ZZanYT7fNtbyBZopNrBhuRgQcMARkdQDQBdqlomraVrmlw6pomp2Wp2E+7yrqz nWaKTaxU7XUkHDAg4PUEVdqlomk6Voelw6XommWWmWEG7yrWzgWGKPcxY7UUADLEk4HUk0AFpq2l XmqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3KCRkDI5FF3q2lWeqWOl3ep2Vvf6h5n2K1lnVZbny 13SeWhOX2qQTgHA5NFppOlWeqX2qWmmWVvf6h5f226igVZbny12x+Y4GX2qSBknA4FF3pOlXmqWO qXemWVxf6f5n2K6lgVpbbzF2yeW5GU3KADgjI4NABreraVoelzaprep2WmWEG3zbq8nWGKPcwUbn YgDLEAZPUgVdqlrek6VrmlzaXremWWp2E+3zbW8gWaKTawYbkYEHDAEZHUA1doApaJq2la5pcOqa JqdlqdhPu8q6s51mik2sVO11JBwwIOD1BFFpq2lXmqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3K CRkDI5FGiaTpWh6XDpeiaZZaZYQbvKtbOBYYo9zFjtRQAMsSTgdSTRaaTpVnql9qlppllb3+oeX9 tuooFWW58tdsfmOBl9qkgZJwOBQAXeraVZ6pY6Xd6nZW9/qHmfYrWWdVlufLXdJ5aE5fapBOAcDk 0a3q2laHpc2qa3qdlplhBt826vJ1hij3MFG52IAyxAGT1IFF3pOlXmqWOqXemWVxf6f5n2K6lgVp bbzF2yeW5GU3KADgjI4NGt6TpWuaXNpet6ZZanYT7fNtbyBZopNrBhuRgQcMARkdQDQBdqlomraV rmlw6pomp2Wp2E+7yrqznWaKTaxU7XUkHDAg4PUEVdqlomk6Voelw6XommWWmWEG7yrWzgWGKPcx Y7UUADLEk4HUk0AFpq2lXmqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3KCRkDI5FXapWmk6VZ6pf apaaZZW9/qHl/bbqKBVlufLXbH5jgZfapIGScDgVdoAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigArG0jUddufE+uafqHhz7BpNn9n/ALN1L7akn9o70Jl/dAbovLbC /NndnI4rZrG0jQP7O8T65rv9t61d/wBr/Z/9BurrfaWXlIU/0ePH7vfnc/J3MAeKANmiiigAoooo AKKKKACiiigAooooAKKKKACiiigArmdb8caLo+qTadd2XiaWaHbuaz8M6jdRHKhhtlhgZG4Izhjg 5BwQRXTUUAc/rHi/SdKsdPvLq08QSRX8Xmwra+H765kUYU4lSKFmhb5h8sgU5yMZU4LfxfpM/h25 15LTxALS2lETxyeH75Lkk7eUt2hEzr84+ZUI4bn5Wx0FFAHP+G/F+k6/fPZ2Np4ghlSIylr/AMP3 1lHgEDAeeFFLcj5Qc4ycYBxTsPiFoN7fW9nDYeLVlnlWJGm8J6nDGCxwCzvbhUXnlmIAHJIFdZRQ BzOt+ONF0fVJtOu7LxNLNDt3NZ+GdRuojlQw2ywwMjcEZwxwcg4IIqbWPF+k6VY6feXVp4gkiv4v NhW18P31zIowpxKkULNC3zD5ZApzkYypx0FFAHP2/i/SZ/DtzryWniAWltKInjk8P3yXJJ28pbtC JnX5x8yoRw3Pytg8N+L9J1++ezsbTxBDKkRlLX/h++so8AgYDzwopbkfKDnGTjAOOgooA5Ow+IWg 3t9b2cNh4tWWeVYkabwnqcMYLHALO9uFReeWYgAckgV1lFFABRRRQAUUUUAFFFFABRRRQBjaRqOu 3PifXNP1Dw59g0mz+z/2bqX21JP7R3oTL+6A3ReW2F+bO7ORxWzWNpGgf2d4n1zXf7b1q7/tf7P/ AKDdXW+0svKQp/o8eP3e/O5+TuYA8Vs0AFFFFABRRRQAUUUUAFFFFABRRRQBzPxJ8Q6r4Y0C31HS NIstUmm1KzsTDdX7Wqr9pnSBH3rFITiSWPI2j5dxBJAVsz/hPLrSbHxS/i7RIbK78N6QutXMWl3p vI5bVhcbdjyRwnzc2swKlQoGw7zuIWb4yeH9b8UeDE0bQobKWZ9Ssbmb7Tqc1jiK3uY7htksMbur sYggK7Su4sDlQDDpPhbV9L8Bayuixw6V4wv7GaOG6udZudXWKYLILbNzdIZGiRm37Cm1S8mFO4lg C7oOv+LpPFUGheIfB0NhFLYz3f8AaVhqTXlopR4UWEs0MTCVvMkbBUDag2lyXEeLf+PPF0nhW48Y +HPAcOveH2sWvdOSHVWTUr6PZuidbYwFQr/KwHmmQRtny/M/c0fDvwLdeHvFR1JNA8JeG7SKxltJ YvDsZij1Z2eJkuZofLQQtGInCIXnIFzIBJwTJNoOl+PvDGh2HhHQrDwzc6TpttHY2Oq3upTrcJAi hI3ktUg2yOigBgs6CUqSDCH2oAegUUUUAFFFFABRRRQAUUUUAFY2keKdC1bxPrnhnT77ztW0H7P/ AGlb+U6+R56F4vmICtuUE/KTjvg1s1jaR/wlX/CT65/a39i/2B/o/wDYv2Xzftf3D5/2jd8n38bN n8Oc80AbNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHP2Gt3U/wARdZ8OPHCLSx0jT72JwD5h eea8RwTnG0C2TGADktknIx0FcnpVpdJ8YfEd89tMtpN4f0mGKcxkRu6XGol0DdCyiRCQOQHXPUV1 lABUN+10ljcPYwwz3axMYIppTFG74+VWcKxVScAsFYgc4PSpqhv2uksbh7GGGe7WJjBFNKYo3fHy qzhWKqTgFgrEDnB6UAef+CPiBr+r2nhHUtd8MaZpmneLYkOmvZaw93MjvaSXarMjW8SqvlRSAsru Q20YIJZZv+E58STy/btL8Ff2loba3/Y6zwagTdxMl79knuJbfysLCjJMwZJHYqELKgZ2izPgj8Or 7wrpOlweJbCFr7R7GC2s54/E9/qcJdYjHJKlvcIkdq23Kr5YJCyOgKrkND/wr/xJdeLP7W1HTPBn 29tb+3L4ntIjDqsFnHdb4rQhYf3262RLd5PNj+SVlKybCZQDrdT8R6/dazf6Z4P0LTNUbS5Vg1Gb UtUexjjmeNJVij2QTNIwjkjdiQqgSIFZ23hNPwXrF/r2gLqWpaBe6Bctc3MJsbxlMqLFPJGjMVyp 3qiuNpZcONrMMMcW70vxVoOv6vqPhSw0XVodcuUvLuHU9Slsmt50gigzG8cEwdGjhi+UqpVlc7nD hY+m0T+1f7LhbW/sQv23NKlnuMUeWJCKzcvtUhS5C7yC2xM7FALtFFFABXP+KtbutK13wnY28cLR azq8llcGQEsqLY3VwCmCMNvgQc5GC3GcEdBXJ+OrS6ufFHgGa3tpporXxBLNcPHGWWFDpl+gdyPu rvdFyeMso6kUAdZRRRQAUUUUAFFFFABRRRQBjaR4p0LVvE+ueGdPvvO1bQfs/wDaVv5Tr5HnoXi+ YgK25QT8pOO+DWzWNpH/AAlX/CT65/a39i/2B/o/9i/ZfN+1/cPn/aN3yffxs2fw5zzWzQAUUUUA FFFFABRRRQAUUUUAcZN8TvCEGqahp802tRPplyba/nfQL4Wto4VWJluDD5SIEZX8xmCbGD52kGuz rwxrbWPEnjb4h+Dzd3ulaH4k1J7eb7R4O1Bmng/s22t55Ib4slvFnypVQujgsoYeYGUHoPF2m6Y3 i3VJvGvhbU/Eks8sZ8LS2OnyXDWaCGNWiimQAWNx9oEj/aHaIEPCfOIhIhAPU6pa9qlhoeh3+t6p P9nsNPtpLq6l2M3lxRqWdsKCThQTgAn0rzP4s6ZeTfB3wzZeLrW91zXLbUtFe9udHsLieVJ4riFr u5hNtGJIf3S3BEiBCA20YLBSeLPh74N8SfBjxLB4X8D2Ul/qmm3LWp1HSjb3s98sU0cM0rXSrL52 93ImlO4+YzbvmJIB6zXM2HjSwvfHB8KR6ZrUU32a5nS7ubJoLeQ28sMcqJ5m13wbiIiRUMTBjtdi rAZnw1/4Qi3vru38EeBptAiliD3twPDMmkRuVOI0IljiaVvmkI2q4UBtxUsgfF8QeLbCD4w6RfNp Hi2S003SNVsLqeHwtqUsYmkuLEoFZICJFYQSkOmVwvXlcgHqdFczrfhnWtQ1Sa8tPiF4m0iGTbts 7O305oo8KAdpmtXfkgk5Y8k4wMATaxoGrX1jp9va+N/EGly2sWya4tYbFpLw4Ub5RLbOobgn92qD LHjGAADoKK5+30DVovDtzpb+N/EE93NKHTVJIbEXMA+X5EVbYQlflP3o2Pztz93B4b0DVtKvnuL7 xv4g16Joigt7+GxSNTkHeDBbRtuGCOWIwx4zggA6CiuTsPCevW19b3E3xN8W3kUUqu9vNbaYI5gD koxSzVgp6HaynB4IPNTa34Z1rUNUmvLT4heJtIhk27bOzt9OaKPCgHaZrV35IJOWPJOMDAAB01Fc /rGgatfWOn29r438QaXLaxbJri1hsWkvDhRvlEts6huCf3aoMseMYALfQNWi8O3Olv438QT3c0od NUkhsRcwD5fkRVthCV+U/ejY/O3P3cAHQUVz/hvQNW0q+e4vvG/iDXomiKC3v4bFI1OQd4MFtG24 YI5YjDHjOCKdh4T162vre4m+Jvi28iilV3t5rbTBHMAclGKWasFPQ7WU4PBB5oA6yiuZ1vwzrWoa pNeWnxC8TaRDJt22dnb6c0UeFAO0zWrvyQScseScYGAJtY0DVr6x0+3tfG/iDS5bWLZNcWsNi0l4 cKN8oltnUNwT+7VBljxjAAB0FFc/b6Bq0Xh250t/G/iCe7mlDpqkkNiLmAfL8iKtsISvyn70bH52 5+7g8N6Bq2lXz3F9438Qa9E0RQW9/DYpGpyDvBgto23DBHLEYY8ZwQAdBRXJ2HhPXra+t7ib4m+L byKKVXe3mttMEcwByUYpZqwU9DtZTg8EHmptb8M61qGqTXlp8QvE2kQybdtnZ2+nNFHhQDtM1q78 kEnLHknGBgAA6aszR9e0zV77ULTTpZp20+XyZ5RbSLAXyyskcxURysrIyuEZijAq21uKxvGfhjU9 Y8O2tjDrU14baILc2d8I0ttaA2ZS7McYZVfawPlbU+c74pY8xMaLJJqvh2bw1aW2p+C7/TYobdhY 2aeTbAfdFpLLCbeaIqmBtUlVYB0if5VAOsrM8N69pniGxe70yWYrFKYZori2ktp4HADbJIZVWSNi rKwDKCVdWGVYE0vDegatpV89xfeN/EGvRNEUFvfw2KRqcg7wYLaNtwwRyxGGPGcEczcaddeNvEVt 4g0fT5vDEUERhTxDJbG31idBuzbpbzw/Lb73J/0gMCyMVhBMVwAD0aiuZ1vwzrWoapNeWnxC8TaR DJt22dnb6c0UeFAO0zWrvyQScseScYGAJtY0DVr6x0+3tfG/iDS5bWLZNcWsNi0l4cKN8oltnUNw T+7VBljxjAAB0FFc/b6Bq0Xh250t/G/iCe7mlDpqkkNiLmAfL8iKtsISvyn70bH525+7g8N6Bq2l Xz3F9438Qa9E0RQW9/DYpGpyDvBgto23DBHLEYY8ZwQAXbbW7WfxVf8AhxI5hd2NjbXsrkDyyk7z ogBzncDbPnIAwVwTk4zPGnjGw8LXllFepmF7a81C/ly3+h2FrDumuMBSZMSPbx+WvzHztwBCNVLS P+S3+KP+xb0b/wBKdUrxn9pDwV/bnjjXLm0s/Bk9y/huSA/aPDfmXf2q+lt7TT1a4MyhppJYZkin 2hbdVbeCHDUAfRmhXF/eaHYXeqad/Zl/PbRyXVl56zfZpWUF4vMXh9rEruHBxkVdryDx1odxo3gr QPCs2h+H5NISWeW6aw8IXd5pokDZihOlW0xYq/mSSb3Z41kgDFQ7xlbn7PC6jaWninSr7SZtLgg1 dJtNgTQpdLs/sklpBta3gZ3WNWkWZ2jD71d2MiRu5UAHqdFFFABRRRQAUUUUAFZms63a6VqOiWNx HM0us3zWVuYwCqutvNcEvkjC7IHHGTkrxjJGnXGfEP8A5G74cf8AYyTf+mnUaAOzooooAKKKKACi iigAooooAKK4zwla6FF8T/G9zp/hbWtO1af7B/aWrXUTraaptgIi+zsXKt5S5R9qrhiM5PNdnQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRXM+HZbl/HfiqKXxr ZavDH9j8rQ4oYVl0XMRz5jKS7ecfnG8DAHy5FAHTUUUUAFFUtbk1WHS5pNEsrK9vxt8qC8u2ton+ YZ3SLHIVwuSMIckAcZyOA+Alz4ql0W/j1fRtFtLD+29bYT2uqyzymc6rc708trdBsDGQB9+SFUlF 3EKAemUVydhf/El763S+8J+EoLRpVE8sPiW4lkRM/MyobFQzAZIUsoJ4yOtTa3e+PodUmj0Twz4Z vbAbfKnvPEE9tK/yjO6NbOQLhsgYc5AB4zgAHTUVyfjO+8XW/h21lsbCGBniB1aexka7ubAfJva0 haIC5YAyYLbSNoYQzN+5aDwxZWFp4YuNd8EWllrWsajtN1e6nM1rcX8qOVcXUqws6PGTIvlGMCIr 5QSJV2qAdnRXP+G7vxpPfOniPQPD+nWgiJSWw1ua7kL5GFKPaxALjcd24nIAxzkcn5P/AAjfif8A sP4ZQeZ5P/H74f8AJ+z6Labk3F/tCRN9lmOYW8mPfuEm8wDzXuFAPTKK5nW73x9Dqk0eieGfDN7Y Db5U954gntpX+UZ3RrZyBcNkDDnIAPGcCbWLvxpFY6e+kaB4fu7uSLN/Fda3NbxwPhflidbWQyrk sNzLGcAHHJAAOgorn7e78aN4duZ7jQPD8etLKBb2ketzPbSJ8uWec2oZG5f5REw+VefmO08N3fjS e+dPEegeH9OtBESkthrc13IXyMKUe1iAXG47txOQBjnIANOH+yv7cuvJ+xf2t9mh+07Nv2jyN0vk 78fNs3eftzxnzMc7qNR1Sw0+8020vJ/Km1O5NrZrsY+ZKIZJiuQMD93DI2TgfLjqQDzOkf8AJb/F H/Yt6N/6U6pXjP7UH/CR/wDCT619n/4TP7F/whGubPs/9k/ZPJ2WPm7fM/f+TnHm7v3u7b5Py7qA PoDTfFfhvUbfQprbWrL/AIqC2+1aRFLIIpb2LyxIWjjfDthGDEYyoPOK2a8g8aPqy6Z8MU1DW9T0 TUZ/FMlu17riWLXcZksNQRRi3P2bzWDBYsBhuaPcjncjdn4KvtTj8Ra34XvtSm1yLSoraRdVmjjS Vnm8wtbSiJVj82NUjkyqofLuIcrn95IAdZRRRQAUUUUAFFFFABVLUf7K+2ab/aH2L7T9pP8AZ3n7 d/n+TJnys87/ACvOzt52b+2au1xnxD/5G74cf9jJN/6adRoA7OiiigAooooAKKKKACiiigAormfD sty/jvxVFL41stXhj+x+VocUMKy6LmI58xlJdvOPzjeBgD5ciumoAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAqlaaTpVnql9qlppllb3+oeX9tuooFWW58tdsfmOB l9qkgZJwOBV2sbSNR1258T65p+oeHPsGk2f2f+zdS+2pJ/aO9CZf3QG6Ly2wvzZ3ZyOKANmiiigA qGytLWyhaGztobaJpZJmSKMIpeRy7uQP4mdmYnqSxJ5NTVyfwou7q98L3k15czXMq+INahV5ZC7B I9TukRAT/CqKqgdAFAHAoA6yiiigAqlaaTpVnql9qlppllb3+oeX9tuooFWW58tdsfmOBl9qkgZJ wOBV2igAqlomk6Voelw6XommWWmWEG7yrWzgWGKPcxY7UUADLEk4HUk1dooAKKKKACiiigDMttEt YPFV/wCI0kmN3fWNtZSoSPLCQPO6EDGdxNy+ckjAXAGDmHU/C2halqE+oXtj5tzP9h8x/Ndd32O4 a4tuAQBsldm/2s4bI4rZrmdb8caLo+qTadd2XiaWaHbuaz8M6jdRHKhhtlhgZG4Izhjg5BwQRQBp 614e0DW5oZta0PTNSlgimhhe7tEmaNJk2SopYHCunysBww4ORU2iaTpWh6XDpeiaZZaZYQbvKtbO BYYo9zFjtRQAMsSTgdSTWZrHi/SdKsdPvLq08QSRX8Xmwra+H765kUYU4lSKFmhb5h8sgU5yMZU4 LfxfpM/h2515LTxALS2lETxyeH75Lkk7eUt2hEzr84+ZUI4bn5WwAdBRXP8AhvxfpOv3z2djaeII ZUiMpa/8P31lHgEDAeeFFLcj5Qc4ycYBxTsPiFoN7fW9nDYeLVlnlWJGm8J6nDGCxwCzvbhUXnlm IAHJIFAHWUVzOt+ONF0fVJtOu7LxNLNDt3NZ+GdRuojlQw2ywwMjcEZwxwcg4IIqbWPF+k6VY6fe XVp4gkiv4vNhW18P31zIowpxKkULNC3zD5ZApzkYypwAdBRXP2/i/SZ/DtzryWniAWltKInjk8P3 yXJJ28pbtCJnX5x8yoRw3Pytg8N+L9J1++ezsbTxBDKkRlLX/h++so8AgYDzwopbkfKDnGTjAOAD oKzNZ0S11XUdEvriSZZdGvmvbcRkBWdrea3IfIOV2TueMHIXnGQcaw+IWg3t9b2cNh4tWWeVYkab wnqcMYLHALO9uFReeWYgAckgV1lABRRRQAUUUUAFFFFABRRRQBStNJ0qz1S+1S00yyt7/UPL+23U UCrLc+Wu2PzHAy+1SQMk4HAq7WNpGo67c+J9c0/UPDn2DSbP7P8A2bqX21JP7R3oTL+6A3ReW2F+ bO7ORxWzQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWNpGgf2 d4n1zXf7b1q7/tf7P/oN1db7Sy8pCn+jx4/d787n5O5gDxWzWNpHinQtW8T654Z0++87VtB+z/2l b+U6+R56F4vmICtuUE/KTjvg0AbNFFFABXP+AdEutA0K5sbySGSWXV9SvVMRJXZc309wgOQPmCSq D2yDgkcnoK5/wDrd1r+hXN9eRwxyxavqVkoiBC7La+nt0JyT8xSJSe2ScADgAHQUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBjaRoH9neJ 9c13+29au/7X+z/6DdXW+0svKQp/o8eP3e/O5+TuYA8Vs1jaR4p0LVvE+ueGdPvvO1bQfs/9pW/l OvkeeheL5iArblBPyk474NbNABRRRQAUUUUAFFFFABWT4s1WfRtG+22tpHdztc21tFFJMYkLTTpC CzhWIAMmThT0rWrnPiJ/yALX/sM6X/6X29COnBQjUxNOM1dOST+8Ptnjn/oXfDn/AIPZv/kSj7Z4 5/6F3w5/4PZv/kSujoplfWaf/PmP3y/+SOc+2eOf+hd8Of8Ag9m/+RKPtnjn/oXfDn/g9m/+RKZ4 48eeGfBfk/8ACQ3V7D5ttPdj7Nptzd7IINnnSv5Mb7ETzEyzYHzDmoV+IvhU+FdZ8TPcanDp2hym LU/O0e8intiEjkJaBohLtCSo5YLgKdxOASAPrNP/AJ8x++X/AMkWftnjn/oXfDn/AIPZv/kSj7Z4 5/6F3w5/4PZv/kSmaV468P6l9rWBdahmtbZ7o213od7a3E0SY3tDFLErz7SVBEasQXQHl1BzG+Lf gAeCtG8ZJrc02i65fDT9Mmh065lkubgtIojWJYzJuLROBleSOOoyB9Zp/wDPmP3y/wDkjW+2eOf+ hd8Of+D2b/5Eo+2eOf8AoXfDn/g9m/8AkSujooD6zT/58x++X/yRzn2zxz/0Lvhz/wAHs3/yJR9s 8c/9C74c/wDB7N/8iV0dFAfWaf8Az5j98v8A5I5z7Z45/wChd8Of+D2b/wCRKPtnjn/oXfDn/g9m /wDkSujooD6zT/58x++X/wAkc59s8c/9C74c/wDB7N/8iVZ8Lavfam2qW+pWFtZXenXgtZFt7pp4 3zDFKGDMiHpKBjb1FbVc54R/5D/jD/sMx/8ApBaUGkZUqtKp+7SaV01zfzJdW+50dY2kf8JV/wAJ Prn9rf2L/YH+j/2L9l837X9w+f8AaN3yffxs2fw5zzWzRSOAKKKKACuT+FFpdWXhe8hvLaa2lbxB rUypLGUYpJqd06OAf4WRlYHoQwI4NdZVLRtUsNYs5LvTp/PhjuZ7Vm2MuJYJnhlXDAH5ZI3XPQ4y Mgg0AXaKKKACiiszR9e0zV77ULTTpZp20+XyZ5RbSLAXyyskcxURysrIyuEZijAq21uKANOiiszw 3r2meIbF7vTJZisUphmiuLaS2ngcANskhlVZI2KsrAMoJV1YZVgSAadFFFABRRWZ4a1u11/Tpb6z jmjiivruyYSgBt9tcSW7kYJ+UvExHfBGQDwADGsPhl8NrC+t76x+HvhK1u7aVZoJ4dGt0kidTlXV gmVYEAgjkEVNrfw98A65qk2qa34H8M6nfz7fNurzSoJpZNqhRudlJOFAAyegAqlqfjr7P4nn0Ky0 v7ZImpWOlxv9o8vzLqVGuLmPBXjyLILcbs7ZN3lqQ4xXZ0Ac/rHgjwXrNjp9jq/hDw/qNppsXk2E F1psMsdqmFGyJWUhFwijC4GFHoKLfwR4LtvDtz4ct/CHh+HRbqUTXGnR6bCttM42kO8QXazfInJG flX0FdBRQBz/AIb8EeC/DV8994c8IeH9Gu5IjC89hpsNvIyEglCyKCVyqnHTIHpVOw+GXw2sL63v rH4e+ErW7tpVmgnh0a3SSJ1OVdWCZVgQCCOQRXWV5/pfxj8BalcWcNpe60ftn2QwSyeHtQjiZbqT y7ZzI8ARUlfKq5IViDg8GgDa1v4e+Adc1SbVNb8D+GdTv59vm3V5pUE0sm1Qo3OyknCgAZPQAVNr HgjwXrNjp9jq/hDw/qNppsXk2EF1psMsdqmFGyJWUhFwijC4GFHoKp6x8Q/DeleIrvw/cR+IJ9Rt Iopp4rLw7qF2qpJu2PvhhZSp2uAQSMo46qwE0vj3wnH4n0Hw3/a3mX/iG2e60gxW8slvexKhkZo5 1UxHCDdjfnDKf4lyATW/gjwXbeHbnw5b+EPD8Oi3UomuNOj02FbaZxtId4gu1m+ROSM/KvoKPDfg jwX4avnvvDnhDw/o13JEYXnsNNht5GQkEoWRQSuVU46ZA9KPCXjLw74rvtas9BvJruXQ759P1BjZ zRRxXCEh4w7oFkZcc7C2AVJ4Zc9BQBydh8MvhtYX1vfWPw98JWt3bSrNBPDo1ukkTqcq6sEyrAgE Ecgiptb+HvgHXNUm1TW/A/hnU7+fb5t1eaVBNLJtUKNzspJwoAGT0AFdNRQBDYWlrYWNvY2NtDa2 ltEsMEEMYSOJFGFRVHCqAAABwAKmrM8Wa3a+GvCureI76OaS00qxmvZ0hAMjJEhdgoJALYU4yQM9 xWnQAUUUUAFFFFABRRRQBjaR/wAJV/wk+uf2t/Yv9gf6P/Yv2Xzftf3D5/2jd8n38bNn8Oc81s0U UAFFFFABRRRQAUUUUAFc58RP+QBa/wDYZ0v/ANL7eujrnPiJ/wAgC1/7DOl/+l9vTW515f8A71S/ xL80dHRRRSOQ85/aCsrJ/h14gvF0rU7/AFq48P6lo2mrYWVxdyE3UIJQpCrbVZ4IvncAKQBuG7mH 4kJp158EPH+p+H9I1p7nxHpt3ut/7Luxd3F01sLOP/RnTzUyI4l+4F2jeeCWr0yigDznVdag8Ua7 4d1PTNN8QR2Phq+n1XUJb3Qry1Yp9huoFihjliWSeVmn3BY1YARtkhmjV/LNH8Gpovww8H+LJLTx M9+f7BhuNLTQrl7i2lhn0sXrPGsZkCLFpERXKgZEhDSebEq/TNc/ZeN/Bd74ibw5Z+L/AA/c60ss kLadFqUL3IePJdDEG3bl2tkYyNpz0oA6CiiigAooooAKKKKACuc8I/8AIf8AGH/YZj/9ILSujrnP CP8AyH/GH/YZj/8ASC0pnXhv4db/AAr/ANKidHXGeErXQovif43udP8AC2tadq0/2D+0tWuonW01 TbARF9nYuVbylyj7VXDEZyea7OikcgUUUUAUtbsrnUNLms7TVr3SJpNu28s0haWPDAnaJkdOQCDl TwTjBwRw3wQ8N65omlX02reI/EF0r6vq4Wwv7a1jjw2pTstwPLgSTdIvz/e2ESkqoXaF9GooA5Ow 8J69bX1vcTfE3xbeRRSq7281tpgjmAOSjFLNWCnodrKcHgg81NrfhnWtQ1Sa8tPiF4m0iGTbts7O 305oo8KAdpmtXfkgk5Y8k4wMAdNRQByfjPwxqeseHbWxh1qa8NtEFubO+EaW2tAbMpdmOMMqvtYH ytqfOd8UseYmNFkk1Xw7N4atLbU/Bd/psUNuwsbNPJtgPui0llhNvNEVTA2qSqsA6RP8q9ZRQBz/ AIb0DVtKvnuL7xv4g16Joigt7+GxSNTkHeDBbRtuGCOWIwx4zgjmbjTrrxt4itvEGj6fN4YigiMK eIZLY2+sToN2bdLeeH5bfe5P+kBgWRisIJiuB6NRQBzOt+Gda1DVJry0+IXibSIZNu2zs7fTmijw oB2ma1d+SCTljyTjAwBNrGgatfWOn29r438QaXLaxbJri1hsWkvDhRvlEts6huCf3aoMseMYA6Ci gDM8N6Ze6VYvb33iHU9elaUuLi/jt0kUYA2AQRRrtGCeVJyx5xgDn/g3/wAijff9jJrv/p2u67Oq Wjf2V9jk/sf7F9m+0z7/ALJt2ef5z+fnbxv83zN/ffuzzmgD5a0z4X/2l4+gt7LTPhlLHP4kvp4x /wAITtha1s7FbK5byzdDEKXrrH5GdzSnz1JTivX/ABdp/h3/AIS3VJ/iT4Tm8T2k0sbaA48PTaxD a24hjEsXlxRSeTL5wkdnZR5iyRAO/lbIu61PxToWm6hPp97feVcwfYfMTynbb9suGt7bkAg75UZf 9nGWwOa07+7tbCxuL6+uYbW0tommnnmkCRxIoyzsx4VQASSeABQBi/Dyx0zTvCVrb6Ppup6dYvLP PHDqUkj3LGWZ5GlkMrNJukZzJiQhxvwyqwKjoKhsLu1v7G3vrG5hurS5iWaCeGQPHKjDKurDhlII II4INTUAFeQeHLHw2fide+Fo/D3iCLRbTSNEsNNaXSNQjtlm0y6vJlAuWQKVT/RyHZysmQAXyRXr 9FAHmd14ktNB+M/iS5v9L8TPbS6JpdrHcWfhy/u4nljlvpHVXhhZTtW4iyQcZYjqrAckfCuo3Xiv w5ot/aanp93LFrerx3C6dLc21lcT61a6nZw3EsY8ncPszLIiyjOwqrjfG7e80UAeZ/AnTLbw/P4u 8N2VrrUdlp2pWlvZT6jYTQ/aYIdMs7USLI8aJL89rICU44DfdZCfTKKKACiiigDjPjt/yRDx5/2L eo/+k0ldnVLXv7K/sO//ALd+xf2T9mk+3fbdv2fyNp8zzN/y7Nud27jGc8VdoAKKKKACiiigAooo oA4zwla6FF8T/G9zp/hbWtO1af7B/aWrXUTraaptgIi+zsXKt5S5R9qrhiM5PNdnRRQAUUUUAFFF FABRRRQAVznxE/5AFr/2GdL/APS+3ro65z4if8gC1/7DOl/+l9vTW515f/vVL/EvzR45qvhGx1Lx R8UbHQvhjDc69c6vt03xLFb2Ea6VdS6ZZssxkaRbhGSZzOXiRmyxZdzkivRtW1HV9S1/xIB4t/4R G28M+W6rJBA8V1E0CzG7uTMu77Lu8yICJojm3uP3uSBF0Fl4I8F2XiJvEdn4Q8P22tNLJM2oxabC lyXkyHcyhd25tzZOcncc9au6x4e0DWb7T77V9D0zUbvTZfOsJ7q0SWS1fKnfEzAlGyinK4OVHoKR yHGeNte8UXPwr8O+I9Klm8K61fX2ima0ubZbhYTd3MEMtvOjqrMq+e2dpifKDDLyKzPjJ4d8QRfB DxzLqHj7WrmZtEu7iWOKzsorcBbabfBGpgZ1hcsPvSPKAi4lzuLejeJPD2geJbFLHxHoemazaRyi ZIL+0S4jVwCA4VwQGwzDPXBPrU2iaTpWh6XDpeiaZZaZYQbvKtbOBYYo9zFjtRQAMsSTgdSTQBme G7GfRb57HU/G2p69d3cRmt4NSFnHIiRkCR41t4Yiy5ljDFtwBKdM88nBBYavoGh6PpcdlpHw+0u5 04WGoTXjebfNbTwm1jt1cEGF5UhVZ3ctKFYIhWWOeuz8MeE/Cvhf7R/wjPhrRdE+07ftH9nWMVv5 u3O3dsUbsbmxnpk+tZlh8MvhtYX1vfWPw98JWt3bSrNBPDo1ukkTqcq6sEyrAgEEcgigDrKxvE9z 4qt/s/8AwjOjaLqW7d9o/tHVZbPy+m3bst5t+fmznbjA6542aKAOft7vxo3h25nuNA8Px60soFva R63M9tIny5Z5zahkbl/lETD5V5+Y7Tw3d+NJ7508R6B4f060ERKS2GtzXchfIwpR7WIBcbju3E5A GOcjoKKAOTsL/wCJL31ul94T8JQWjSqJ5YfEtxLIiZ+ZlQ2KhmAyQpZQTxkdam1u98fQ6pNHonhn wze2A2+VPeeIJ7aV/lGd0a2cgXDZAw5yADxnA6aigDn9Yu/GkVjp76RoHh+7u5Is38V1rc1vHA+F +WJ1tZDKuSw3MsZwAcckDD8I3Pir7P4wuP7G0X+3/wC2Y/8AQv7Vl+yf8edoP+Pj7Pv+583+p+98 vT5q7yuc8I/8h/xh/wBhmP8A9ILSmdeG/h1v8K/9KiP8N3fjSe+dPEegeH9OtBESkthrc13IXyMK Ue1iAXG47txOQBjnIp2F/wDEl763S+8J+EoLRpVE8sPiW4lkRM/MyobFQzAZIUsoJ4yOtdZRSOQ5 nW73x9Dqk0eieGfDN7YDb5U954gntpX+UZ3RrZyBcNkDDnIAPGcCbWLvxpFY6e+kaB4fu7uSLN/F da3NbxwPhflidbWQyrksNzLGcAHHJA6CigDn7e78aN4duZ7jQPD8etLKBb2ketzPbSJ8uWec2oZG 5f5REw+VefmO08N3fjSe+dPEegeH9OtBESkthrc13IXyMKUe1iAXG47txOQBjnI6CigDk7C/+JL3 1ul94T8JQWjSqJ5YfEtxLIiZ+ZlQ2KhmAyQpZQTxkdam1u98fQ6pNHonhnwze2A2+VPeeIJ7aV/l Gd0a2cgXDZAw5yADxnA6aigDk/Gd94ut/DtrLY2EMDPEDq09jI13c2A+Te1pC0QFywBkwW2kbQwh mb9y0HhiysLTwxca74ItLLWtY1Habq91OZrW4v5Ucq4upVhZ0eMmRfKMYERXygkSrtXs6pWmk6VZ 6pfapaaZZW9/qHl/bbqKBVlufLXbH5jgZfapIGScDgUAZnhu78aT3zp4j0Dw/p1oIiUlsNbmu5C+ RhSj2sQC43HduJyAMc5HJ+T/AMI34n/sP4ZQeZ5P/H74f8n7PotpuTcX+0JE32WY5hbyY9+4SbzA PNe4X0yqWiaTpWh6XDpeiaZZaZYQbvKtbOBYYo9zFjtRQAMsSTgdSTQBja3e+PodUmj0Twz4ZvbA bfKnvPEE9tK/yjO6NbOQLhsgYc5AB4zgTaxd+NIrHT30jQPD93dyRZv4rrW5reOB8L8sTrayGVcl huZYzgA45IHQUUAZnhufX57F38R6ZpmnXYlISKw1B7uMpgYYu8MRDZ3DbtIwAc84HP8Awb/5FG+/ 7GTXf/Ttd12dZnhrRLXQNOlsbOSaSKW+u71jKQW33NxJcOBgD5Q8rAd8AZJPJAPmD/itP+Fi/wDN TfP/AOE3/wCpe87zv+Ee/wC/fneX/wBsvK/6bV7lq2o6vqWv+JAPFv8AwiNt4Z8t1WSCB4rqJoFm N3cmZd32Xd5kQETRHNvcfvckCLp9M8LaFpuoQahZWPlXMH27y38122/bLhbi54JIO+VFb/ZxhcDi ptY8PaBrN9p99q+h6ZqN3psvnWE91aJLJavlTviZgSjZRTlcHKj0FAHP/An/AJIh4D/7FvTv/SaO uzqlomk6Voelw6XommWWmWEG7yrWzgWGKPcxY7UUADLEk4HUk1doAKKKKACiiigAooooAKKKKAOM +O3/ACRDx5/2Leo/+k0ldnWZ4s0S18S+FdW8OX0k0dpqtjNZTvCQJFSVCjFSQQGwxxkEZ7GtOgAo oooAKKKKACiiigDmfDsty/jvxVFL41stXhj+x+VocUMKy6LmI58xlJdvOPzjeBgD5ciumqlaaTpV nql9qlppllb3+oeX9tuooFWW58tdsfmOBl9qkgZJwOBV2gAooooAKKKKACiiigArnPiJ/wAgC1/7 DOl/+l9vXR1znxE/5AFr/wBhnS//AEvt6a3OvL/96pf4l+aOjooopHIFFFFABRRRQAUUUUAFFFFA BRRRQAVznhH/AJD/AIw/7DMf/pBaV0dc54R/5D/jD/sMx/8ApBaUzrw38Ot/hX/pUTo6xtI1HXbn xPrmn6h4c+waTZ/Z/wCzdS+2pJ/aO9CZf3QG6Ly2wvzZ3ZyOK2axtI0D+zvE+ua7/betXf8Aa/2f /Qbq632ll5SFP9Hjx+7353PydzAHikchs0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcnYfEL Qb2+t7OGw8WrLPKsSNN4T1OGMFjgFne3CovPLMQAOSQKm1vxxouj6pNp13ZeJpZodu5rPwzqN1Ec qGG2WGBkbgjOGODkHBBFdNRQBz+seL9J0qx0+8urTxBJFfxebCtr4fvrmRRhTiVIoWaFvmHyyBTn IxlTgt/F+kz+HbnXktPEAtLaURPHJ4fvkuSTt5S3aETOvzj5lQjhuflbHQUUAc/4b8X6Tr989nY2 niCGVIjKWv8Aw/fWUeAQMB54UUtyPlBzjJxgHFOw+IWg3t9b2cNh4tWWeVYkabwnqcMYLHALO9uF ReeWYgAckgV1lFAHM63440XR9Um067svE0s0O3c1n4Z1G6iOVDDbLDAyNwRnDHByDggiptY8X6Tp Vjp95dWniCSK/i82FbXw/fXMijCnEqRQs0LfMPlkCnORjKnHQUUAc/b+L9Jn8O3OvJaeIBaW0oie OTw/fJcknbylu0ImdfnHzKhHDc/K2Dw34v0nX757OxtPEEMqRGUtf+H76yjwCBgPPCiluR8oOcZO MA46CigDk7D4haDe31vZw2Hi1ZZ5ViRpvCepwxgscAs724VF55ZiABySBU2t+ONF0fVJtOu7LxNL NDt3NZ+GdRuojlQw2ywwMjcEZwxwcg4IIrpqKAIbC5jvbG3vIVmWKeJZUWaF4ZAGGQGRwGRueVYA g8EA1NRRQAUUUUAFFFFABRRRQBjaRqOu3PifXNP1Dw59g0mz+z/2bqX21JP7R3oTL+6A3ReW2F+b O7ORxWzWNpGgf2d4n1zXf7b1q7/tf7P/AKDdXW+0svKQp/o8eP3e/O5+TuYA8Vs0AFFFFABRRRQA UUUUAFc58RP+QBa/9hnS/wD0vt66Os7xJpMet6U1hJdXNp++hnSa32eZG8UqSoRvVl+8i8EEYoR0 YOpGniKc5bJpv7zRornP+Ed1j/ofPEf/AH4sP/kaj/hHdY/6HzxH/wB+LD/5Gpl/Vqf/AD+j90v/ AJE6Oiuc/wCEd1j/AKHzxH/34sP/AJGo/wCEd1j/AKHzxH/34sP/AJGoD6tT/wCf0ful/wDInR0V zn/CO6x/0PniP/vxYf8AyNR/wjusf9D54j/78WH/AMjUB9Wp/wDP6P3S/wDkTo6K5z/hHdY/6Hzx H/34sP8A5Go/4R3WP+h88R/9+LD/AORqA+rU/wDn9H7pf/InR0Vzn/CO6x/0PniP/vxYf/I1H/CO 6x/0PniP/vxYf/I1AfVqf/P6P3S/+ROjornP+Ed1j/ofPEf/AH4sP/kaj/hHdY/6HzxH/wB+LD/5 GoD6tT/5/R+6X/yJ0dc54R/5D/jD/sMx/wDpBaUf8I7rH/Q+eI/+/Fh/8jVd8N6INGW+ZtSvdRnv rn7TPPdCIOWEUcQAEaIoAWJe3rQaJU6NOolUUnJW05v5k+qXY1qxtI8U6Fq3ifXPDOn33natoP2f +0rfynXyPPQvF8xAVtygn5Scd8GtmsbSP+Eq/wCEn1z+1v7F/sD/AEf+xfsvm/a/uHz/ALRu+T7+ Nmz+HOeaRwGzRWNq/wDwlX/CT6H/AGT/AGL/AGB/pH9tfavN+1/cHkfZ9vyffzv3/wAOMc0eNv8A hKv+EYu/+EK/sX+3/k+yf2v5v2T7679/lfP9zfjH8WM8ZoA2aKKxvBP/AAlX/CMWn/Ca/wBi/wBv /P8Aa/7I837J99tmzzfn+5szn+LOOMUAbNFY2kf8JV/wk+uf2t/Yv9gf6P8A2L9l837X9w+f9o3f J9/GzZ/DnPNGr/8ACVf8JPof9k/2L/YH+kf219q837X9weR9n2/J9/O/f/DjHNAGzRWN42/4Sr/h GLv/AIQr+xf7f+T7J/a/m/ZPvrv3+V8/3N+MfxYzxmtmgAorG8E/8JV/wjFp/wAJr/Yv9v8Az/a/ 7I837J99tmzzfn+5szn+LOOMUaR/wlX/AAk+uf2t/Yv9gf6P/Yv2Xzftf3D5/wBo3fJ9/GzZ/DnP NAGzRWNq/wDwlX/CT6H/AGT/AGL/AGB/pH9tfavN+1/cHkfZ9vyffzv3/wAOMc0eNv8AhKv+EYu/ +EK/sX+3/k+yf2v5v2T7679/lfP9zfjH8WM8ZoA2aKKxvBP/AAlX/CMWn/Ca/wBi/wBv/P8Aa/7I 837J99tmzzfn+5szn+LOOMUAbNFY2kf8JV/wk+uf2t/Yv9gf6P8A2L9l837X9w+f9o3fJ9/GzZ/D nPNGr/8ACVf8JPof9k/2L/YH+kf219q837X9weR9n2/J9/O/f/DjHNAGzRWN42/4Sr/hGLv/AIQr +xf7f+T7J/a/m/ZPvrv3+V8/3N+MfxYzxmtmgAorG8E/8JV/wjFp/wAJr/Yv9v8Az/a/7I837J99 tmzzfn+5szn+LOOMUaR/wlX/AAk+uf2t/Yv9gf6P/Yv2Xzftf3D5/wBo3fJ9/GzZ/DnPNAGzRWNq /wDwlX/CT6H/AGT/AGL/AGB/pH9tfavN+1/cHkfZ9vyffzv3/wAOMc0eNv8AhKv+EYu/+EK/sX+3 /k+yf2v5v2T7679/lfP9zfjH8WM8ZoA2aKKxvBP/AAlX/CMWn/Ca/wBi/wBv/P8Aa/7I837J99tm zzfn+5szn+LOOMUAbNFY2kf8JV/wk+uf2t/Yv9gf6P8A2L9l837X9w+f9o3fJ9/GzZ/DnPNGr/8A CVf8JPof9k/2L/YH+kf219q837X9weR9n2/J9/O/f/DjHNAGzRWN42/4Sr/hGLv/AIQr+xf7f+T7 J/a/m/ZPvrv3+V8/3N+MfxYzxmtmgAorG8E/8JV/wjFp/wAJr/Yv9v8Az/a/7I837J99tmzzfn+5 szn+LOOMUaR/wlX/AAk+uf2t/Yv9gf6P/Yv2Xzftf3D5/wBo3fJ9/GzZ/DnPNAGzRWNq/wDwlX/C T6H/AGT/AGL/AGB/pH9tfavN+1/cHkfZ9vyffzv3/wAOMc0eNv8AhKv+EYu/+EK/sX+3/k+yf2v5 v2T7679/lfP9zfjH8WM8ZoA2aKKxvBP/AAlX/CMWn/Ca/wBi/wBv/P8Aa/7I837J99tmzzfn+5sz n+LOOMUAbNFY2kf8JV/wk+uf2t/Yv9gf6P8A2L9l837X9w+f9o3fJ9/GzZ/DnPNbNABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUVw37QVp a3vwK8dQ3ltDcxL4fvZlSWMOoeOF3RwD/ErqrA9QVBHIrM+FvgOHSfE994kvPA3hnwff23n6fZw+ HhGbe7s5UtJTJK4ijd3WaKRVyibRuG1shyAd/DqlhNrl1okc+6/tLaG6ni2N8kUzSrG2cYOWglGA cjbzjIzdrjPDNxq8HxT8U6Je67e6nYR6bp+oWkVzFAv2Rp575XjQxRoWQLBGBvLtwfmOTVLVtR1f Utf8SAeLf+ERtvDPluqyQQPFdRNAsxu7kzLu+y7vMiAiaI5t7j97kgRAHoFFeTeD9c8TT+Fvg1ql 74kvbubxDj+11kt7ZVu/O0u5uxnZEpTy5IkC7Cvy5D7zzXQeA9TvdeufiBpy+J5ruKw8QS6fY3kK 25ksgbO2kaNdsexmimllUeYrkFdr7iDQB3NFec/BpPGGu+DfCni7xL41mu5b3SLa5ewstOt7e2mE sCtum3K8hlDOSWjeJDtXEajcG5nwn458eag2k+KLrQ/EEFjqd9Da3ljezaRDptgJJxAyI4m+1i4i chSsgYySLJH5MLOohAPbKhv7u1sLG4vr65htbS2iaaeeaQJHEijLOzHhVABJJ4AFTVS1XSdK1b7J /ammWV/9juUu7X7TAsnkTpnZKm4Ha65OGGCMnBoAnsLu1v7G3vrG5hurS5iWaCeGQPHKjDKurDhl IIII4INTV5n4A1n+wf2afB+oI2Lk+G9Lt7MeR52+6mhhit02b0B3SyRry6Lzy6DLCl8PvE3iOP4p x+Dtam8TP9o0S41N4/ELaSbiLy54IozENPPCN5su4yjkxrsPyyAgHrNFUrTVtKvNUvtLtNTsri/0 /wAv7baxTq0tt5i7o/MQHKblBIyBkcirtABRRXDftBWlre/Arx1DeW0NzEvh+9mVJYw6h44XdHAP 8SuqsD1BUEcigDuaK8ZtdAv5/jP4bXV/Cvhnw1c2vhHVLbSrvRLlbuW1VJbGNNnnWkax+Us0gQbX XEsgIAJDT2WreKtSsdG8Ap4w1O38YWur3MWtanFbWZk+yW4WRpvLaAw7ZY7qx2omXjN0m5pPJmDA HqVpq2lXmqX2l2mp2Vxf6f5f221inVpbbzF3R+YgOU3KCRkDI5FXa8s1K1vdT+Put6XY+MZvD0r+ FtLuCllDbvd3AS61Bcr56SKIl8wb8Rk7ni+dRlXNf8T+KNR+E+k+IdI1WHSdUfxBZ2SXMVos1pfw vqaWYm8tyWNvNG4nUJIG2sm2Uj5mAPU6paNqlhrFnJd6dP58MdzPas2xlxLBM8Mq4YA/LJG656HG RkEGszR9E1y3sdQTUvGWp313exYWVbW1ijsHIbLWyCIkLlgQs7TEBFBLfMWp/CW+1O/8Hu+r6lNq d3bavqlkbqaONJJUt9QuIIywiVE3bI1B2qASM4oA39V1bStJ+yf2pqdlYfbLlLS1+0zrH58752RJ uI3O2DhRknBwKu14Z4n1HV9X8E+FfFepeLfsv9teJNDSTw7NBAIraUalbs1pE21Z/tUJiYSF3cEx T/uo8gRe50AFFcN8UJvESa74Ls9A8STaMuqavNYXm20hnV4TY3M+4CRSVlU242NnaC2XSVRsrMXx Truh+G/GEU99/as3h/W7bTY9Tv4kBjgnhspXurlYRGhSAXcjttEQ8qHllO6SgD0yqWq6tpWk/ZP7 U1OysPtlylpa/aZ1j8+d87Ik3EbnbBwoyTg4Fcz4euNX0jxwvhS81298Swz6bJqD3d3FAlxYMssc aRyfZ440KTBpDHlFbNtP80gOIvP/ABPqOr6v4J8K+K9S8W/Zf7a8SaGknh2aCARW0o1K3ZrSJtqz /aoTEwkLu4Jin/dR5AiAPc6K8m8V+JfG97471nR9B0vxNCmh+QbcabHpckV75sQkEtwt5NHK0Jff EBD5eTDNiYscQ9zp3irTh4C07xd4hu9M0O0ubG3uriSXUYntrcyquFFwCI3Xc4UODhsgjqKAOgoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gClrek6VrmlzaXremWWp2E+3zbW8gWaKTawYbkYEHDAEZHUA1D4b8PaB4asXsfDmh6Zo1pJKZngs LRLeNnIALlUABbCqM9cAeladFAHJ2Hwy+G1hfW99Y/D3wla3dtKs0E8OjW6SROpyrqwTKsCAQRyC Kg8d+E9V8Qa5pmo2b+DP+JZiSzbWfDLajcW0+4MZIZRcxeX92PgLnKZ3HgDs6KAOf07wdoFt4C07 wReWEOsaLY2NvZLBqUKTrMkCqEMildrN8it90DIyAKntPCfhWzt763tPDWi28OoW0dpexxWMSrcw Rx+VHFIAuHRYyUCnIC8AY4rZooAxvDHhPwr4X+0f8Iz4a0XRPtO37R/Z1jFb+btzt3bFG7G5sZ6Z PrR/wifhX/hJ/wDhKf8AhGtF/t//AKCn2GL7X9zy/wDW7d/3Pl6/d46Vs0UAFZniTw9oHiWxSx8R 6Hpms2kcomSC/tEuI1cAgOFcEBsMwz1wT61p0UAc/o/gjwXo1jqFjpHhDw/p1pqUXk38FrpsMUd0 mGGyVVUB1w7DDZGGPqaNH8EeC9GmtJtH8IeH9Ols5ZZrV7XTYYmgeVFSR0KqNrOiqrEYJCgHIAro KKAKVppOlWeqX2qWmmWVvf6h5f226igVZbny12x+Y4GX2qSBknA4FXaKKACqWt6TpWuaXNpet6ZZ anYT7fNtbyBZopNrBhuRgQcMARkdQDV2igDn7jwjoEc1tqWlaB4ftNa06xNnpN/JpaO1igRlRE27 WEQ3MPLV0BBYAjOap+CvDmv6Z4i1vXvEuu6ZrF9qUVtBG1lpb2S28MHmFYsNPLuXfLI4Jw2ZHBZl 2KnWUUAc/rHgjwXrM13NrHhDw/qMt5LFNdPdabDK07xIyRu5ZTuZEZlUnJAYgYBNXfEnh7QPEtil j4j0PTNZtI5RMkF/aJcRq4BAcK4IDYZhnrgn1rTooAxv+ET8K/8ACMf8It/wjWi/2B/0C/sMX2T7 /mf6rbs+/wDN0+9z1qDw34I8F+Gr577w54Q8P6NdyRGF57DTYbeRkJBKFkUErlVOOmQPSugooA5/ U/BHgvVL6/vtT8IeH7271GJYb6e402GSS6RShVJGZSXUGOMgNkAov90V0FFFAGZrHh7QNZvtPvtX 0PTNRu9Nl86wnurRJZLV8qd8TMCUbKKcrg5Uego0fw9oGjX2oX2kaHpmnXepS+dfz2tokUl0+WO+ VlALtl2OWycsfU1p0UAZnhvw9oHhqxex8OaHpmjWkkpmeCwtEt42cgAuVQAFsKoz1wB6VS1PwR4L 1S+v77U/CHh+9u9RiWG+nuNNhkkukUoVSRmUl1BjjIDZAKL/AHRXQUUAY3ifwn4V8UfZ/wDhJvDW i639m3fZ/wC0bGK48rdjdt3qdudq5x1wPSrmt6TpWuaXNpet6ZZanYT7fNtbyBZopNrBhuRgQcMA RkdQDV2igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP//Z --Boundary_(ID_z5azR8xcTBR12+9z5DOqyA)-- From root@core3.amsl.com Sun Jul 11 21:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3E7A228C111; Sun, 11 Jul 2010 21:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712040002.3E7A228C111@core3.amsl.com> Date: Sun, 11 Jul 2010 21:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g709-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 04:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of G.709 Optical Transport Networks Author(s) : F. Zhang, et al. Filename : draft-ietf-ccamp-gmpls-g709-framework-02.txt Pages : 26 Date : 2010-07-11 This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. Zhang Expires January 2011 [page 1] draft-ietf-ccamp-gmpls-g709-framework-02.txt July 2010 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-11205001.I-D@ietf.org> --NextPart-- From zhangfatai@huawei.com Sun Jul 11 23:50:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B413A697A for ; Sun, 11 Jul 2010 23:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.85 X-Spam-Level: X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoxW3cAx6H-h for ; Sun, 11 Jul 2010 23:50:11 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B17B43A6774 for ; Sun, 11 Jul 2010 23:50:10 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5F00AB6MZFTL@szxga01-in.huawei.com> for ccamp@ietf.org; Mon, 12 Jul 2010 14:50:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5F00HOAMZF2H@szxga01-in.huawei.com> for ccamp@ietf.org; Mon, 12 Jul 2010 14:50:03 +0800 (CST) Received: from Z41162C ([10.70.76.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5F00BDAMZFQR@szxml06-in.huawei.com> for ccamp@ietf.org; Mon, 12 Jul 2010 14:50:03 +0800 (CST) Date: Mon, 12 Jul 2010 14:50:01 +0800 From: Fatai Zhang To: ccamp@ietf.org Message-id: <02e501cb218e$7374d3e0$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_m1IuH5b8EJnX/25qhJ/Ptw)" X-Priority: 3 X-MSMail-priority: Normal References: <20100712040002.3E7A228C111@core3.amsl.com> Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g709-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 06:50:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_m1IuH5b8EJnX/25qhJ/Ptw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi All, The authors of this draft just submitted a new version of this draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-02 Major updates include: (1) Added some text in Section 5.1 and 5.3 to address multi-stage muxing. (2) Added a new sub-section 5.2.3. to describe the requirments for differentiating full lambda LSP or sub lambda LSP. (3) Fixed various nits. Best Regards Fatai ----- Original Message ----- From: To: Cc: Sent: Monday, July 12, 2010 12:00 PM Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g709-framework-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > Title : Framework for GMPLS and PCE Control of G.709 Optical Transport Networks > Author(s) : F. Zhang, et al. > Filename : draft-ietf-ccamp-gmpls-g709-framework-02.txt > Pages : 26 > Date : 2010-07-11 > > This document provides a framework to allow the development of > protocol extensions to support Generalized Multi-Protocol Label > Switching (GMPLS) and Path Computation Element (PCE) control of > Optical Transport Networks (OTN) as specified in ITU-T Recommendation > G.709 as consented in October 2009. > > > > > Zhang > > > > > > Expires January 2011 > > > > > > [page 1] > > draft-ietf-ccamp-gmpls-g709-framework-02.txt > > > > > > July 2010 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --Boundary_(ID_m1IuH5b8EJnX/25qhJ/Ptw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi All,

The authors of this draft just submitted a new version of this draft:

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-02

Major updates include:
(1) Added some text in Section 5.1 and 5.3 to address multi-stage muxing.
(2) Added a new sub-section 5.2.3. to describe the requirments for differentiating full lambda LSP or sub lambda LSP.
(3) Fixed various nits.



Best Regards
 
Fatai
 
----- Original Message -----
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc: <ccamp@ietf.org>
Sent: Monday, July 12, 2010 12:00 PM
Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g709-framework-02.txt


>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>
>
> Title           : Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
> Author(s)       : F. Zhang, et al.
> Filename        : draft-ietf-ccamp-gmpls-g709-framework-02.txt
> Pages           : 26
> Date            : 2010-07-11
>
> This document provides a framework to allow the development of
> protocol extensions to support Generalized Multi-Protocol Label
> Switching (GMPLS) and Path Computation Element (PCE) control of
> Optical Transport Networks (OTN) as specified in ITU-T Recommendation
> G.709 as consented in October 2009.
>
>
>
>
> Zhang
>
>
>
>
>
> Expires January 2011
>
>
>
>
>
> [page 1]
>
> draft-ietf-ccamp-gmpls-g709-framework-02.txt
>
>
>
>
>
> July 2010
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>



> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
--Boundary_(ID_m1IuH5b8EJnX/25qhJ/Ptw)-- From root@core3.amsl.com Mon Jul 12 01:30:19 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C5A1B3A6A6B; Mon, 12 Jul 2010 01:30:14 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712083015.C5A1B3A6A6B@core3.amsl.com> Date: Mon, 12 Jul 2010 01:30:14 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:30:19 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Ethernet OAM Configuration Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-rsvp-te-eth-oam-ext-03.txt Pages : 19 Date : 2010-07-12 The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK].Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-eth-oam-ext-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-eth-oam-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12012656.I-D@ietf.org> --NextPart-- From giomarti@cisco.com Mon Jul 12 03:17:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279843A68F6 for ; Mon, 12 Jul 2010 03:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+BmYPS7w1Ux for ; Mon, 12 Jul 2010 03:17:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7B27C3A6817 for ; Mon, 12 Jul 2010 03:17:45 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHqIOkxAZnwN/2dsb2JhbACgOXGiMZoDhScEiEw X-IronPort-AV: E=Sophos;i="4.55,187,1278288000"; d="scan'208,217";a="131269415" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 10:17:52 +0000 Received: from [144.254.166.113] (mnza1-dhcp-vl301-144-254-166-113.cisco.com [144.254.166.113]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6CAHpWa020513; Mon, 12 Jul 2010 10:17:52 GMT Message-ID: <4C3AEC88.6010703@cisco.com> Date: Mon, 12 Jul 2010 12:20:56 +0200 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: Greg Bernstein References: <4C39FB1C.7060708@grotto-networking.com> In-Reply-To: <4C39FB1C.7060708@grotto-networking.com> Content-Type: multipart/alternative; boundary="------------000303050404080607010803" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Proposed contribution to draft-bernstein-ccamp-wson-signaling-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 10:17:47 -0000 This is a multi-part message in MIME format. --------------000303050404080607010803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Greg, no editing to suggest yet but a consideration on this draft related to bi-directionality so sections 5 and 6. Having the same wavelength on forward and reverse direction is a common case but it's also a strong constrain so bi-directionality in general should cover both cases (same wl or different wl). As far as I see solution in section 5 cover this while section 6 is still tbd. We were trying to get around this constrain using much like solution proposed in section 5 but with a procedure in draft-martinelli-ccamp-synch-signaling-01. Now not sure how to move forward... we might discuss a bit at the next meeting. Cheers, G On 07/11/2010 07:10 PM, Greg Bernstein wrote: > Hi all this sounds good to me. I've incorporated the changes and sent > a pre-release version to Pierre for editing. Please let us know if > there are any other concerns or desired changes and I can roll them > into the final edit before posting. > Cheers > > Greg > > On 7/1/2010 7:54 AM, PELOSO, PIERRE (PIERRE) wrote: >> Hi ccampers and Greg, >> >> During the latest meeting in Anaheim, I was asked to propose on the >> list for discussion some text dealing with the re-introduction of >> wavelength metric inside the signalling draft by Greg. The wavelength >> metric object is to be used inside the path message when performing >> LSP request. >> The interest of the metric is to enrich the information collected on >> the wavelength availability, which could be used to perform >> wavelength differentiations according varying criteria. >> >> So here is the text that I find fitting properly the needs, it >> actually is a slight adaptation of the text that was contained inside >> the first version of this draft: >> >> Distributed wavelength assignment makes extensive use of the label >> set object/TLV of [RFC3471]. Some wavelength assignment algorithms >> require supplemental information concerning the potential lambdas to >> be used. An ordered set of TLVs in correspondence with the group of >> one or more label set TLVs can be used to convey this information in >> the form of a general wavelength "acceptability" metric. >> >> Note that the label set syntax of [RFC3471] allows group of >> wavelengths into ranges. For the purpose of supplementing this >> information with wavelength count only those wavelengths with the >> same counts could be grouped. >> >> The general format for supplemental wavelength selection information >> could be as follows: >> >> The information carried in a Wavelength Set Metric TLV is: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Info Type | Metric Size | Num Metrics | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Wavelength Metric Info | >> | From lowest to highest frequency if more that one value | >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Info Type: 8 bits >> >> 0 - Single Value >> >> The enclosed single value for the wavelength metric is given to all >> wavelengths in the corresponding wavelength set. >> >> 1 - List >> >> The enclosed list gets applied in a one-to-one fashion to each >> wavelength in the corresponding wavelength set. An error occurs if >> the number of metrics in this list and the number of wavelengths in >> the wavelength set is not equal. >> >> Metric Size: >> >> Indicates the size of the wavelength metric information as follows >> >> 0 - 8 bits >> >> 1 - 16 bits >> >> 2 - 32 bits >> >> Number 0f Metrics: 24 bits >> >> Wavelength Metric: (1, 2, or 4 octets) >> >> The wavelength metric represents in some fashion the >> desirability or lack thereof to use this wavelength over another >> available wavelength. Different wavelength assignment algorithms may >> use this information differently. >> >> Regards, >> >> Pierre >> _____________________________________________________ >> Pierre Peloso Engineer >> >> +33 1 3077 2662 Network& Networking >> rte de Villejust >> 91620 Nozay (France) Alcatel-Lucent >> >> >> > --------------000303050404080607010803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Greg,

no editing to suggest yet but a consideration on this draft  related to bi-directionality so sections 5 and 6.

Having the same wavelength on forward and reverse direction is a common case but it's also a strong constrain so bi-directionality in general should cover both cases (same wl or different wl). 

As far as I see solution in section 5 cover this while section 6 is still tbd. We were trying to get around this constrain using much like solution proposed in section 5 but with a procedure in draft-martinelli-ccamp-synch-signaling-01.

Now not sure how to move forward... we might discuss a bit at the next meeting.

Cheers,
G



On 07/11/2010 07:10 PM, Greg Bernstein wrote:
Hi all this sounds good to me. I've incorporated the changes and sent a pre-release version to Pierre for editing. Please let us know if there are any other concerns or desired changes and I can roll them into the final edit before posting.
Cheers

Greg

On 7/1/2010 7:54 AM, PELOSO, PIERRE (PIERRE) wrote:
Hi ccampers and Greg,

During the latest meeting in Anaheim, I was asked to propose on the list for discussion some text dealing with the re-introduction of wavelength metric inside the signalling draft by Greg. The wavelength metric object is to be used inside the path message when performing LSP request.
The interest of the metric is to enrich the information collected on the wavelength availability, which could be used to perform wavelength differentiations according varying criteria.

So here is the text that I find fitting properly the needs, it actually is a slight adaptation of the text that was contained inside the first version of this draft:

    Distributed wavelength assignment makes extensive use of the label
    set object/TLV of [RFC3471]. Some wavelength assignment algorithms
    require supplemental information concerning the potential lambdas to
    be used. An ordered set of TLVs in correspondence with the group of
    one or more label set TLVs can be used to convey this information in
    the form of a general wavelength "acceptability" metric.

    Note that the label set syntax of [RFC3471] allows group of
    wavelengths into ranges. For the purpose of supplementing this
    information with wavelength count only those wavelengths with the
    same counts could be grouped.

    The general format for supplemental wavelength selection information
    could be as follows:

    The information carried in a Wavelength Set Metric TLV is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Info Type   | Metric Size   |   Num Metrics                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Wavelength Metric Info               |
       |   From lowest to highest frequency if more that one value     |
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Info Type: 8 bits

          0 - Single Value

    The enclosed single value for the wavelength metric is given to all
    wavelengths in the corresponding wavelength set.

          1 - List

    The enclosed list gets applied in a one-to-one fashion to each
    wavelength in the corresponding wavelength set. An error occurs if
    the number of metrics in this list and the number of wavelengths in
    the wavelength set is not equal.

    Metric Size:

    Indicates the size of the wavelength metric information as follows

          0 - 8 bits

          1 - 16 bits

          2 - 32 bits

    Number 0f Metrics: 24 bits

    Wavelength Metric: (1, 2, or 4 octets)

          The wavelength metric represents in some fashion the
    desirability or lack thereof to use this wavelength over another
    available wavelength. Different wavelength assignment algorithms may
    use this information differently.

Regards,

Pierre
_____________________________________________________
Pierre Peloso                                Engineer

+33 1 3077 2662                  Network&  Networking
rte de Villejust
91620 Nozay (France)                   Alcatel-Lucent



  

--------------000303050404080607010803-- From eosborne@cisco.com Mon Jul 12 07:39:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD0F3A6985; Mon, 12 Jul 2010 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MneXOeZx2THw; Mon, 12 Jul 2010 07:39:36 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 074A43A63EC; Mon, 12 Jul 2010 07:39:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJfGOkytJV2d/2dsb2JhbACgPnGkZZpJhScEg3uGfw X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="scan'208";a="131356791" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 14:33:13 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o6CEXDII020865; Mon, 12 Jul 2010 14:33:13 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 09:33:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 09:33:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 Thread-Index: AcshyL90GhPgcnxAQ9GjiNSI5C9EEQ== From: "Eric Osborne (eosborne)" To: , , , X-OriginalArrivalTime: 12 Jul 2010 14:33:13.0137 (UTC) FILETIME=[287C4210:01CB21CF] Subject: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 14:39:40 -0000 I have a few questions. Nothing major, as the draft is in general pretty solid. 1) Section 4.1 reviews existing GMPLS functionality and describes applicability to TP. Section 4.1.8 defines LSP hierarchy but doesn't say anything about how it applies to TP. It probably needs a line like "Hierarchical LSPs may be used in MPLS-TP at the discretion of the network operator" or something similar ot what's in other subsections of 4.1. 2) Some of section 4.1.9 is out of sync with the surviveability framework (draft-ietf-mpls-tp-survive-fwk) - survive-fwk draws a distinction between protection and restoration that cp-framework lumps under 'recovery'. It may be worth calling out both protection and restoration as separate things. - Section 4.1.9 lists five recovery types: - 1+1 bidirectional protection for P2P LSPs - 1+1 unidirectional protection for P2MP LSPs - 1:n (including 1:1) protection with or without extra traffic - Rerouting without extra traffic (sometimes known as soft rerouting), including shared mesh restoration - Full LSP rerouting I don't see where these five types come from. rfc5654 requirements R65 and R67 list five MUST types (bidir 1+1 p2p, unidir 1+1 p2p, unidir 1+1 p2mp, bidir 1:n p2p, unidir 1:n p2mp) and one optional (undir 1:n p2p). R68 requires 1:n (including 1:1) ahread mesh recovery. =20 How do the five types in section 4.1. 9 map to the requirements in rfc5654? At first glance I don't see unidir 1+1 p2p in sec. 4.1.9, although perhaps it's implied in 'rerouting without extra traffic'. 'Full LSP rerouting' also seems like it may mean something specific to whomever wrote it but as far as I can tell there's no explicit definition of 'Full LSP rerouting' (as opposed to partial? as opposed to something other than rerouting?) anywhere in rfc5654 or survive-fwk. And 'soft rerouting appears to be survive-fwk's 'soft restoration'. 3) Section 4.1.9, "it's use is not precluded" , s/it's/its/ 4) Section 4.4.1 is entitled "MPLS to MPLS-TP Interworking". The section talks about " interworking of MPLS-TE and GMPLS control plane", so shouldn't the section be "MPLS-TE to MPLS-TP Interworking"? Unless things like LDP-to-TP interworking are in someone's plans, I think "TE to TP Interworking" is a better fit. eric From root@core3.amsl.com Mon Jul 12 09:45:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 72D7C3A693F; Mon, 12 Jul 2010 09:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712164502.72D7C3A693F@core3.amsl.com> Date: Mon, 12 Jul 2010 09:45:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-info-08.txt Pages : 24 Date : 2010-07-12 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-info-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12093949.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 10:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 37F763A6B79; Mon, 12 Jul 2010 10:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712171502.37F763A6B79@core3.amsl.com> Date: Mon, 12 Jul 2010 10:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-encode-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-encode-05.txt Pages : 34 Date : 2010-07-12 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-encode-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12100243.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 11:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4832D3A6BEA; Mon, 12 Jul 2010 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712180002.4832D3A6BEA@core3.amsl.com> Date: Mon, 12 Jul 2010 11:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-gmpls-vcat-lcas-10.txt Pages : 21 Date : 2010-07-12 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. This document updates the procedures for supporting virtual concatenation in [RFC4606]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-vcat-lcas-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12105128.I-D@ietf.org> --NextPart-- From swallow@cisco.com Mon Jul 12 13:32:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19243A6C87; Mon, 12 Jul 2010 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.435 X-Spam-Level: X-Spam-Status: No, score=-9.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVNclhL8RsYR; Mon, 12 Jul 2010 13:32:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CFC4E3A69FF; Mon, 12 Jul 2010 13:32:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFAJ4YO0ytJV2Y/2dsb2JhbACBQ54TY3GlBpp5AoJcgkkEiEyCLg X-IronPort-AV: E=Sophos;i="4.55,190,1278288000"; d="scan'208,217";a="131503398" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 20:32:05 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o6CKW57V011207; Mon, 12 Jul 2010 20:32:05 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 15:32:05 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Jul 2010 20:32:04 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 12 Jul 2010 16:32:01 -0400 From: George Swallow To: venkatesan mahalingam Message-ID: Thread-Topic: [PWE3] [mpls] [mpls-tp] mpls wg last call ondraft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrxGuIPFXGqnEbSTAOCqYWtKQomNww5mYI3 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3361797121_20969207" X-OriginalArrivalTime: 12 Jul 2010 20:32:05.0309 (UTC) FILETIME=[4AA8F6D0:01CB2201] Cc: mpls@ietf.org, ccamp@ietf.org, Attila Takacs , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [PWE3] [mpls] [mpls-tp] mpls wg last call ondraft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:32:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3361797121_20969207 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable In line - On 5/6/10 2:08 PM, "venkatesan mahalingam" wrote: > Hi George, >>> >> Is it there to support associated unidirectional Tunnels/LSPs? If so= it >>> should >>> >> be called out in the text. >=20 >> >That was not my original intent, but you are quite correct that this wo= uld >> >be very useful. =A0Particularly if the associated tunnels pass through a = share >> >mid-point somewhere along the path. > VM: Can you please explain the original intention with an example? >=20 > The original intent was to allow a compact form for a globally unique MEP= -ID > that is, >=20 > Node_ID::Tunnel_Num::LSP_ID would be unique within an operator. This req= uires > that Tunnel_Num be unique to the node (not the node pair). That makes it > impossible to coodinate the Tunnel_Num spaces across nodes, hence two tun= nel > numbers. >=20 >>> >> -In Section 5.3 Mapping to GMPLS signaling does not use the >>> Dst-Tunnel_Num. So >>> >> this means that we may have two different tunnels identified with >>> >> Src-Node_ID::Src-Tunnel_Num:: > Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, >>> >> e.g., the associated unidirectional case? >=20 >> >For the associated unidirectional, this works perfectly. =A0For bidirecti= onal, >> >I was thinking of two options. >=20 >> >1) =A0Strict binding =A0- =A0both ends are configure with the full identifier= and >> >will only accept the connection if everything matches. >=20 >> >2) =A0Dynamic binding - Source signals with just its Tunnel_Num. =A0RESV me= ssage >> >would carry back the destination's tunnel_num. =A0Note that both ends nee= d >> >both pieces for some of the OAM to work. > VM: Do we need extensions in the RSVP-TE signaling to carry back the > destination's tunnel_num in the RESV message? >=20 > Yes, this and probably quite a few more. Note that there is a draft for > adding signaling of OAM capabilities in the works. >=20 > ...George >=20 > Thanks, > Venkatesan Mahalingam >=20 > On Fri, Apr 16, 2010 at 10:15 PM, George Swallow wrot= e: >>=20 >>=20 >>=20 >> On 4/2/10 2:53 AM, "Attila Takacs" wrote: >>=20 >>> > Hi Matthew and George, >>> > >>> > Please find some comments/questions below. >>> > >>> > -In Section 5.1 you have: >>> > >>> > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num >>> > >>> > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_= Num? >>=20 >> Existing implementations of RSVP-TE have used the tunnel space as global= to >> the node. =A0It is difficult if not impossible to coordinate such spaces >> between nodes. =A0In RSVP-TE the coordination does not matter, since the t= ail >> end of the tunnel doesn't have a real interface - it only receives and >> usually with a PHP of the tunnel label, so the packets only belong to th= e >> physical interface. >>=20 >> In a bidirectional world, separate tunnel spaces at the two ends becomes >> useful. >>=20 >> If this independence is not need is some environments then one can confi= gure >> just one value and use it in both fields. >>=20 >>> > Is it there to support associated unidirectional Tunnels/LSPs? If so = it >>> should >>> > be called out in the text. >>=20 >> That was not my original intent, but you are quite correct that this wou= ld >> be very useful. =A0Particularly if the associated tunnels pass through a s= hare >> mid-point somewhere along the path. >>=20 >>> > Same applies to the globally unique case. >>=20 >> Of course. >>=20 >>> > -In Section 5.2 you simply append one LSP_Num to the above. This is a= bit >>> > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums w= ould >>> be >>> > needed too, wouldn't it? >>=20 >> Once, you have independent tunnel-ids, coordination of the LSP numbers >> becomes easy. =A0It also could be used to allow the two ends to readily >> identify which is working and which is protection. >>=20 >>> > -In Section 5.3 Mapping to GMPLS signaling does not use the >>> Dst-Tunnel_Num. So >>> > this means that we may have two different tunnels identified with >>> > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this >>> intentional, >>> > e.g., the associated unidirectional case? >>=20 >> For the associated unidirectional, this works perfectly. =A0For bidirectio= nal, >> I was thinking of two options. >>=20 >> 1) =A0Strict binding =A0- =A0both ends are configure with the full identifier = and >> will only accept the connection if everything matches. >>=20 >> 2) =A0Dynamic binding - Source signals with just its Tunnel_Num. =A0RESV mes= sage >> would carry back the destination's tunnel_num. =A0Note that both ends need >> both pieces for some of the OAM to work. >>=20 >>> > This should be clarified. >>=20 >> I'll see what I can do. =A0But this is not supposed to the MPLS-TP signali= ng >> draft. >>=20 >>> > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. >>=20 >> I'm planning to keep it. >>=20 >>> > -Section 7 has a note saying to be aligned with the OAM fwk, is this = still >>> to >>> > be done? >>=20 >> Yes. =A0That draft is also being updated. =A0We appear to be converging. >>=20 >>> > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. >>> > How would Tunnel and LSP MEGs be used? What OAM would run at the Tunn= el >>> level >>> > and not at the LSP level? >>> > >>> > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? >>=20 >> I had been told early on that MEGs were needed for tunnels. =A0Now getting >> comments that they are not (same comment is in the ITU liaison). =A0So I >> planning to remove it, unless I hear other opinions. >>=20 >>> > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. >>=20 >> See above. >>=20 >>> > -Section 8 talks about open issues? When will these be addressed? >>=20 >> Before it is re-issued. =A0Goal is end of next week. >>=20 >> ...George >>=20 >>> > Thanks, >>> > Attila >>> > >>>> >> -----Original Message----- >>>> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>> >> Behalf Of Loa Andersson >>>> >> Sent: Friday, March 12, 2010 12:33 AM >>>> >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >>>> >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers= -01 >>>> >> >>>> >> All, >>>> >> >>>> >> this is to start an MPLS working group last call on >>>> >> draft-ietf-mpls-tp-identifiers-01 >>>> >> >>>> >> There is a discussion on the OAM model for MS-PWs where we >>>> >> haven't been able to come to conclusion. Once we reach >>>> >> agreement the document will be updated. Comments in this area >>>> >> are welcome during the working group last call. >>>> >> >>>> >> >>>> >> Please send your comments to the mpls-tp@ietf.org mailing list. >>>> >> >>>> >> The working group last ends eob April 2nd. >>>> >> >>>> >> /Loa >>>> >> >>>> >> -- >>>> >> >>>> >> Loa Andersson >>>> >> >>>> >> Sr Strategy and Standards Manager >>>> >> Ericsson /// >>>> >> =A0 =A0phone: =A0+46 10 717 52 13 >>>> >> =A0 =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 >>>> >> >>>> >> =A0 =A0email: =A0loa.andersson@ericsson.com >>>> >> =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> mpls mailing list >>>> >> mpls@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/mpls >>>> >> >>> > _______________________________________________ >>> > mpls-tp mailing list >>> > mpls-tp@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 --B_3361797121_20969207 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] [mpls] [mpls-tp] mpls wg last call ondraft-ietf-mpls-tp-i= dentifiers-01 In line= -


On 5/6/10 2:08 PM, "venkatesan mahalingam" <venkatflex@gmail.com> wrote:

Hi George,
>> Is it there to support associated unidirectional Tunnels/LSPs? If = so it should
>> be called out in the text.

>That was not my original intent, but you are quite correct that this wo= uld
>be very useful. =A0Particularly if the associated tunnels pass through a = share
>mid-point somewhere along the path.
VM: Can you please explain the original intention with an example?

The original intent was to allow a compact form for a globally unique MEP-I= D that is,

Node_ID::Tunnel_Num::LSP_ID would be unique within an operator.  This = requires that Tunnel_Num be unique to the node (not the node pair).  Th= at makes it impossible to coodinate the Tunnel_Num spaces across nodes, henc= e two tunnel numbers.

>> -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tu= nnel_Num. So
>> this means that we may have two different tunnels identified with<= BR> >> Src-Node_ID::Src-Tunnel_Num::
Dst-Node_ID::Dst-Tunnel_Num. Is this intentional,
>> e.g., the associated unidirectional case?

>For the associated unidirectional, this works perfectly. =A0For bidirecti= onal,
>I was thinking of two options.

>1) =A0Strict binding =A0- =A0both ends are configure with the full identifier= and
>will only accept the connection if everything matches.

>2) =A0Dynamic binding - Source signals with just its Tunnel_Num. =A0RESV me= ssage
>would carry back the destination's tunnel_num. =A0Note that both ends nee= d
>both pieces for some of the OAM to work.
VM: Do we need extensions in the RSVP-TE signaling to carry back the destin= ation's tunnel_num in the RESV message?

Yes, this and probably quite a few more.   Note that there is a d= raft for adding signaling of OAM capabilities in the works.

...George

Thanks,
Venkatesan Mahalingam

On Fri, Apr 16, 2010 at 10:15 PM, George Swallow <swallow@cisco.com> wrote:



On 4/2/10 2:53 AM, "Attila Takacs" <Attila.Takacs@ericsson.com> wrote:

> Hi Matthew and George,
>
> Please find some comments/questions below.
>
> -In Section 5.1 you have:
>
> Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num
>
> What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_N= um?

Existing implementations of RSVP-TE have used the tunnel space as global to=
the node. =A0It is difficult if not impossible to coordinate such spaces
between nodes. =A0In RSVP-TE the coordination does not matter, since the tail=
end of the tunnel doesn't have a real interface - it only receives and
usually with a PHP of the tunnel label, so the packets only belong to the physical interface.

In a bidirectional world, separate tunnel spaces at the two ends becomes useful.

If this independence is not need is some environments then one can configur= e
just one value and use it in both fields.

> Is it there to support associated unidirectional Tunnels/LSPs? If so i= t should
> be called out in the text.

That was not my original intent, but you are quite correct that this would<= BR> be very useful. =A0Particularly if the associated tunnels pass through a shar= e
mid-point somewhere along the path.

> Same applies to the globally unique case.

Of course.

> -In Section 5.2 you simply append one LSP_Num to the above. This is a = bit
> confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums wo= uld be
> needed too, wouldn't it?

Once, you have independent tunnel-ids, coordination of the LSP numbers
becomes easy. =A0It also could be used to allow the two ends to readily
identify which is working and which is protection.

> -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel= _Num. So
> this means that we may have two different tunnels identified with
> Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this inte= ntional,
> e.g., the associated unidirectional case?

For the associated unidirectional, this works perfectly. =A0For bidirectional= ,
I was thinking of two options.

1) =A0Strict binding =A0- =A0both ends are configure with the full identifier and=
will only accept the connection if everything matches.

2) =A0Dynamic binding - Source signals with just its Tunnel_Num. =A0RESV messag= e
would carry back the destination's tunnel_num. =A0Note that both ends need both pieces for some of the OAM to work.

> This should be clarified.

I'll see what I can do. =A0But this is not supposed to the MPLS-TP signaling<= BR> draft.

> Hmm, maybe the Dst-Tunnel_Num should be omitted altogether.

I'm planning to keep it.

> -Section 7 has a note saying to be aligned with the OAM fwk, is this s= till to
> be done?

Yes. =A0That draft is also being updated. =A0We appear to be converging.

> -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs.
> How would Tunnel and LSP MEGs be used? What OAM would run at the Tunne= l level
> and not at the LSP level?
>
> Do we need Tunnel MEG_IDs as defined in 7.1.2.1?

I had been told early on that MEGs were needed for tunnels. =A0Now getting comments that they are not (same comment is in the ITU liaison). =A0So I
planning to remove it, unless I hear other opinions.

> -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too.

See above.

> -Section 8 talks about open issues? When will these be addressed?

Before it is re-issued. =A0Goal is end of next week.

...George

> Thanks,
> Attila
>
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [<= a href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson
>> Sent: Friday, March 12, 2010 12:33 AM
>> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org
>> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifier= s-01
>>
>> All,
>>
>> this is to start an MPLS working group last call on
>> draft-ietf-mpls-tp-identifiers-01
>>
>> There is a discussion on the OAM model for MS-PWs where we
>> haven't been able to come to conclusion. Once we reach
>> agreement the document will be updated. Comments in this area
>> are welcome during the working group last call.
>>
>>
>> Please send your comments to the mpls-t= p@ietf.org mailing list.
>>
>> The working group last ends eob April 2nd.
>>
>> /Loa
>>
>> --
>>
>> Loa Andersson
>>
>> Sr Strategy and Standards Manager
>> Ericsson ///
>> =A0 =A0phone: =A0+46 10 717 52 13
>> =A0 =A0 =A0 =A0 =A0 =A0+46 767 72 92 13
>>
>> =A0 =A0email: =A0loa.andersson@eric= sson.com
>> =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
>>
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.i= etf.org/mailman/listinfo/mpls
>>
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ie= tf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls


--B_3361797121_20969207-- From fu.xihua@zte.com.cn Mon Jul 12 19:51:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785D33A6965 for ; Mon, 12 Jul 2010 19:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.221 X-Spam-Level: X-Spam-Status: No, score=-95.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCkL61O3QFW6 for ; Mon, 12 Jul 2010 19:51:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CF4253A6844 for ; Mon, 12 Jul 2010 19:51:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 38343473195744; Tue, 13 Jul 2010 10:50:51 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.473195744; Tue, 13 Jul 2010 10:51:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6D2o8CT085488 for ; Tue, 13 Jul 2010 10:50:08 +0800 (CST) (envelope-from fu.xihua@zte.com.cn) To: ccamp@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Tue, 13 Jul 2010 10:52:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-13 10:50:05, Serialize complete at 2010-07-13 10:50:05 Content-Type: multipart/alternative; boundary="=_alternative 000F8F844825775F_=" X-MAIL: mse2.zte.com.cn o6D2o8CT085488 Subject: Re: [CCAMP] I-D Action:draft-fuxh-ccamp-multi-stage-multiplex-config-fwk-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:51:21 -0000 This is a multipart message in MIME format. --=_alternative 000F8F844825775F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpXZSB1cGxvYWRlZCB0aGUgZm9sbG93aW5nIGRvY3VtZW50IGFib3V0IG11bHRp IHN0YWdlcyBtdWx0aXBsZXhpbmcgDQpjb25maWd1cmF0aW9uIGluIEcuNzA5IG5ldHdvcmsuDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mdXhoLWNjYW1wLW11bHRpLXN0YWdlLW11 bHRpcGxleC1jb25maWctcmVxLTAxDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1m dXhoLWNjYW1wLW11bHRpLXN0YWdlLW11bHRpcGxleC1jb25maWctZndrLTAxDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mdXhoLWNjYW1wLW11bHRpLXN0YWdlLW11bHRpcGxleC1j b25maWctb3NwZi0wMA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnV4aC1jY2Ft cC1tdWx0aS1zdGFnZS1tdWx0aXBsZXgtY29uZmlnLXJzdnAtMDANCg0KV2lzaCB5b3VyIGNvbW1l bnRzLg0KDQpYaWh1YSBGdQ0KLS0tLS0g16q3osjLILi2zv27qjExNzgyOS91c2VyL3p0ZV9sdGQg yrG85CAyMDEwLTA3LTEzIMnPzucgMTA6NDEgLS0tLS0NCg0KSW50ZXJuZXQtRHJhZnRzQGlldGYu b3JnIA0Kt6K8/sjLOiAgaS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDctMTMg yc/O5yAxMjowMA0Kx+u08Li0ILj4DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCg0KDQrK1bz+ yMsNCmktZC1hbm5vdW5jZUBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpJLUQgQWN0aW9uOmRyYWZ0 LWZ1eGgtY2NhbXAtbXVsdGktc3RhZ2UtbXVsdGlwbGV4LWNvbmZpZy1md2stMDEudHh0DQoNCg0K DQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgDQpkaXJlY3Rvcmllcy4NCg0KICAgICAgICAgICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBGcmFtZXdvcmsgZm9yIE11bHRpIFN0YWdlcyBNdWx0aXBsZXhpbmcgDQpD b25maWd1cmF0aW9uIGluIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmsNCiAgICAgICAg ICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogWC4gRnUsIGV0IGFsLg0KICAgICAgICAgICAgICAg ICBGaWxlbmFtZSAgICAgICAgOiANCmRyYWZ0LWZ1eGgtY2NhbXAtbXVsdGktc3RhZ2UtbXVsdGlw bGV4LWNvbmZpZy1md2stMDEudHh0DQogICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6 IDE4DQogICAgICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTAtMDctMTINCg0KSW50 ZXJ3b3JraW5nIGJldHdlZW4gcmVnaW9ucyB3aXRoIDEuMjVHIFRTIGFuZCAyLjVHIFRTIGhhcyBi ZWVuDQpjb25zaWRlcmVkIGluIEcuNzA5LiAgTXVsdGkgc3RhZ2VzIG11bHRpcGxleGluZyB3b3Vs ZCBiZSBkZXNpcmFibGUgdG8NCmZhY2lsaXRhdGUgdGhlIGludHJvZHVjdGlvbiBvZiBuZXcgT0RV MCBhbmQgT0RVZmxleCBzaWduYWxzIHRvIGFuDQpleGlzdGluZyBuZXR3b3JrIHdpdGhvdXQgaGF2 aW5nIHRvIHVwZ3JhZGUgZXZlcnkgbm9kZSBpbiB0aGUgbmV0d29yay4NClNvIE9EVTAvT0RVZmxl eCBjYW4gYmUgbWFwcGVkIGludG8gT0RVMS9PRFUyL09EVTMgYW5kIHRyYW5zaXQgYWNyb3NzDQp0 aGUgMi41RyBUUyByZWdpb24uICBNdWx0aSBzdGFnZXMgbXVsdGlwbGV4aW5nIGFyZSBhbHNvIHVz ZWQgdG8NCnN1cHBvcnQgdGhlIG11bHRpLWRvbWFpbiBPVE4gYXBwbGljYXRpb25zIGJhc2VkIG9u IGNhcnJpZXItQ2FycmllciwNCnJlZ2lvbmFsLW5hdGlvbmFsIGNvcmUgaW50ZXJjb25uZWN0aW9u IG9yIG5ldHdvcmsgdHVubmVscyBkZXNpZ24uDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg ZnJhbWV3b3JrIGZvciBtdWx0aSBzdGFnZXMgbXVsdGlwbGV4aW5nDQpjb25maWd1cmF0aW9uIGlu IEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmsuDQoNCkEgVVJMIGZvciB0aGlzIEludGVy bmV0LURyYWZ0IGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt ZnV4aC1jY2FtcC1tdWx0aS1zdGFnZS1tdWx0aXBsZXgtY29uZmlnLWZ3ay0wMS50eHQNCg0KDQpJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3 aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRh dGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0K SW50ZXJuZXQtRHJhZnQuDQpmdHA6Ly9hbm9ueW1vdXNAZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1mdXhoLWNjYW1wLW11bHRpLXN0YWdlLW11bHRpcGxleC1jb25maWctZndrLTAx LnR4dA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkkt RC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0 IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQo= --=_alternative 000F8F844825775F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIHVwbG9hZGVkIHRoZSBmb2xs b3dpbmcgZG9jdW1lbnQgYWJvdXQNCm11bHRpIHN0YWdlcyBtdWx0aXBsZXhpbmcgY29uZmlndXJh dGlvbiBpbiBHLjcwOSBuZXR3b3JrLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnV4aC1jY2FtcC1tdWx0 aS1zdGFnZS1tdWx0aXBsZXgtY29uZmlnLXJlcS0wMTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnV4aC1j Y2FtcC1tdWx0aS1zdGFnZS1tdWx0aXBsZXgtY29uZmlnLWZ3ay0wMTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZnV4aC1jY2FtcC1tdWx0aS1zdGFnZS1tdWx0aXBsZXgtY29uZmlnLW9zcGYtMDA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWZ1eGgtY2NhbXAtbXVsdGktc3RhZ2UtbXVsdGlwbGV4LWNvbmZpZy1yc3Zw LTAwPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaXNo IHlvdXIgY29tbWVudHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5YaWh1YSBGdTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBm YWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsguLbO/buqMTE3ODI5L3VzZXIvenRlX2x0ZA0K yrG85CAyMDEwLTA3LTEzIMnPzucgMTA6NDEgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPC9iPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO2ktZC1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjIwMTAtMDctMTMgyc/O5yAxMjowMDwvZm9udD4NCjx0YWJsZSBib3JkZXI+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfrtPC4tCC4+Dxicj4NCmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SS1EIEFj dGlvbjpkcmFmdC1mdXhoLWNjYW1wLW11bHRpLXN0YWdlLW11bHRpcGxleC1jb25maWctZndrLTAx LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUN CkludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGl0bGUgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IEZyYW1ld29yayBmb3IgTXVsdGkgU3RhZ2VzIE11 bHRpcGxleGluZw0KQ29uZmlndXJhdGlvbiBpbiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3 b3JrPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCkF1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFguIEZ1LCBldCBhbC48 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KRmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1mdXhoLWNj YW1wLW11bHRpLXN0YWdlLW11bHRpcGxleC1jb25maWctZndrLTAxLnR4dDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpQYWdlcyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMTg8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KRGF0ZSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMC0wNy0xMjxicj4NCjxicj4N CkludGVyd29ya2luZyBiZXR3ZWVuIHJlZ2lvbnMgd2l0aCAxLjI1RyBUUyBhbmQgMi41RyBUUyBo YXMgYmVlbjxicj4NCmNvbnNpZGVyZWQgaW4gRy43MDkuICZuYnNwO011bHRpIHN0YWdlcyBtdWx0 aXBsZXhpbmcgd291bGQgYmUgZGVzaXJhYmxlDQp0bzxicj4NCmZhY2lsaXRhdGUgdGhlIGludHJv ZHVjdGlvbiBvZiBuZXcgT0RVMCBhbmQgT0RVZmxleCBzaWduYWxzIHRvIGFuPGJyPg0KZXhpc3Rp bmcgbmV0d29yayB3aXRob3V0IGhhdmluZyB0byB1cGdyYWRlIGV2ZXJ5IG5vZGUgaW4gdGhlIG5l dHdvcmsuPGJyPg0KU28gT0RVMC9PRFVmbGV4IGNhbiBiZSBtYXBwZWQgaW50byBPRFUxL09EVTIv T0RVMyBhbmQgdHJhbnNpdCBhY3Jvc3M8YnI+DQp0aGUgMi41RyBUUyByZWdpb24uICZuYnNwO011 bHRpIHN0YWdlcyBtdWx0aXBsZXhpbmcgYXJlIGFsc28gdXNlZCB0bzxicj4NCnN1cHBvcnQgdGhl IG11bHRpLWRvbWFpbiBPVE4gYXBwbGljYXRpb25zIGJhc2VkIG9uIGNhcnJpZXItQ2Fycmllciw8 YnI+DQpyZWdpb25hbC1uYXRpb25hbCBjb3JlIGludGVyY29ubmVjdGlvbiBvciBuZXR3b3JrIHR1 bm5lbHMgZGVzaWduLjxicj4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBmcmFtZXdvcmsg Zm9yIG11bHRpIHN0YWdlcyBtdWx0aXBsZXhpbmc8YnI+DQpjb25maWd1cmF0aW9uIGluIEcuNzA5 IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmsuPGJyPg0KPGJyPg0KQSBVUkwgZm9yIHRoaXMgSW50 ZXJuZXQtRHJhZnQgaXM6PGJyPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZnV4aC1jY2FtcC1tdWx0aS1zdGFnZS1tdWx0aXBsZXgtY29uZmlnLWZ3ay0wMS50eHQ8 YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6PGJyPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQo8 YnI+DQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50 IG1haWwgcmVhZGVyPGJyPg0KaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2 ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+DQpJbnRlcm5ldC1EcmFmdC48YnI+DQo8L3R0 PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZnRwOi8vYW5vbnltb3VzQGZ0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZnV4aC1jY2FtcC1tdWx0aS1zdGFnZS1t dWx0aXBsZXgtY29uZmlnLWZ3ay0wMS50eHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5j ZSBtYWlsaW5nIGxpc3Q8YnI+DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTxicj4NCkludGVybmV0LURy YWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPGJyPg0Kb3Ig ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8YnI+DQo8L3R0PjwvZm9u dD4NCg== --=_alternative 000F8F844825775F_=-- From venkatflex@gmail.com Mon Jul 12 22:51:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F813A67C0; Mon, 12 Jul 2010 22:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpLHOPp76rZf; Mon, 12 Jul 2010 22:51:51 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 080493A68CE; Mon, 12 Jul 2010 22:51:47 -0700 (PDT) Received: by pwj1 with SMTP id 1so2516566pwj.31 for ; Mon, 12 Jul 2010 22:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jaCUzhHCk4K7N7qlcTHL3b037+RINUX0G15/ecSNCNw=; b=pDfAiymXjINBSQDr57drIO3ENCAsQFxKzwyCVQ5t5DjykRQzC02mWIm/QjCBz6eZYC qmJ4GKHT2IZYfUQlWxiQnuu0H+Ce2PLyaQp51VPsGIKmUHvI9AoqSPURYqRYwMWlZ0RS HvOjULeFIWsS3I6I6efKN/10HpLWCzCCEGFkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TQ3HHqdf73B567nGfW56+vb4Z3APxHKqe3wUronlEuBUO4ChRHUKg95J3XNEsQzCqp 2waKibORTS6P2crvyPVwPPI+13zkf2fl4VcP/tri2b6urpinCJG9BL8BFuAkPXIgxs8B sosfg5dujvRyB61MUFJMrKEOiwXe47qQ/Agp8= MIME-Version: 1.0 Received: by 10.142.136.1 with SMTP id j1mr5555740wfd.26.1279000313134; Mon, 12 Jul 2010 22:51:53 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Mon, 12 Jul 2010 22:51:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 11:21:52 +0530 Message-ID: From: venkatesan mahalingam To: George Swallow Content-Type: multipart/alternative; boundary=000e0cd32cc6550100048b3e776e Cc: mpls@ietf.org, ccamp@ietf.org, Attila Takacs , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [PWE3] [mpls] [mpls-tp] mpls wg last call ondraft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 05:51:54 -0000 --000e0cd32cc6550100048b3e776e Content-Type: text/plain; charset=ISO-8859-1 George, Thanks for your response, please find the followup questions below, Even though Dest_Tunnel_Num is primarily required for bidirectional LSP, this is NOT required for unidirectional LSP. In MPLS_TP environment, if user configures an unidirectional LSP (I guess this is not a violation), then the Dest_Tunnel_Num should be ignored. Is this a correct understanding? And, for bidirectional LSPs, even though the Dest_Tunnel_Num is required to identify the reverse tunnel, it need not be an INDEX to identify the bidirectional Tunnel. Is this a correct understanding? BR, --Venkat. On Tue, Jul 13, 2010 at 2:02 AM, George Swallow wrote: > In line - > > > > On 5/6/10 2:08 PM, "venkatesan mahalingam" wrote: > > Hi George, > >> Is it there to support associated unidirectional Tunnels/LSPs? If so it > should > >> be called out in the text. > > >That was not my original intent, but you are quite correct that this would > >be very useful. Particularly if the associated tunnels pass through a > share > >mid-point somewhere along the path. > VM: Can you please explain the original intention with an example? > > The original intent was to allow a compact form for a globally unique > MEP-ID that is, > > Node_ID::Tunnel_Num::LSP_ID would be unique within an operator. This > requires that Tunnel_Num be unique to the node (not the node pair). That > makes it impossible to coodinate the Tunnel_Num spaces across nodes, hence > two tunnel numbers. > > > >> -In Section 5.3 Mapping to GMPLS signaling does not use the > Dst-Tunnel_Num. So > >> this means that we may have two different tunnels identified with > >> Src-Node_ID::Src-Tunnel_Num:: > Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, > >> e.g., the associated unidirectional case? > > >For the associated unidirectional, this works perfectly. For > bidirectional, > >I was thinking of two options. > > >1) Strict binding - both ends are configure with the full identifier > and > >will only accept the connection if everything matches. > > >2) Dynamic binding - Source signals with just its Tunnel_Num. RESV > message > >would carry back the destination's tunnel_num. Note that both ends need > >both pieces for some of the OAM to work. > VM: Do we need extensions in the RSVP-TE signaling to carry back the > destination's tunnel_num in the RESV message? > > Yes, this and probably quite a few more. Note that there is a draft for > adding signaling of OAM capabilities in the works. > > ...George > > > Thanks, > Venkatesan Mahalingam > > On Fri, Apr 16, 2010 at 10:15 PM, George Swallow > wrote: > > > > > On 4/2/10 2:53 AM, "Attila Takacs" wrote: > > > Hi Matthew and George, > > > > Please find some comments/questions below. > > > > -In Section 5.1 you have: > > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > > > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? > > Existing implementations of RSVP-TE have used the tunnel space as global to > the node. It is difficult if not impossible to coordinate such spaces > between nodes. In RSVP-TE the coordination does not matter, since the tail > end of the tunnel doesn't have a real interface - it only receives and > usually with a PHP of the tunnel label, so the packets only belong to the > physical interface. > > In a bidirectional world, separate tunnel spaces at the two ends becomes > useful. > > If this independence is not need is some environments then one can > configure > just one value and use it in both fields. > > > Is it there to support associated unidirectional Tunnels/LSPs? If so it > should > > be called out in the text. > > That was not my original intent, but you are quite correct that this would > be very useful. Particularly if the associated tunnels pass through a > share > mid-point somewhere along the path. > > > Same applies to the globally unique case. > > Of course. > > > -In Section 5.2 you simply append one LSP_Num to the above. This is a bit > > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would > be > > needed too, wouldn't it? > > Once, you have independent tunnel-ids, coordination of the LSP numbers > becomes easy. It also could be used to allow the two ends to readily > identify which is working and which is protection. > > > -In Section 5.3 Mapping to GMPLS signaling does not use the > Dst-Tunnel_Num. So > > this means that we may have two different tunnels identified with > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > intentional, > > e.g., the associated unidirectional case? > > For the associated unidirectional, this works perfectly. For > bidirectional, > I was thinking of two options. > > 1) Strict binding - both ends are configure with the full identifier and > will only accept the connection if everything matches. > > 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV > message > would carry back the destination's tunnel_num. Note that both ends need > both pieces for some of the OAM to work. > > > This should be clarified. > > I'll see what I can do. But this is not supposed to the MPLS-TP signaling > draft. > > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. > > I'm planning to keep it. > > > -Section 7 has a note saying to be aligned with the OAM fwk, is this > still to > > be done? > > Yes. That draft is also being updated. We appear to be converging. > > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel > level > > and not at the LSP level? > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? > > I had been told early on that MEGs were needed for tunnels. Now getting > comments that they are not (same comment is in the ITU liaison). So I > planning to remove it, unless I hear other opinions. > > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. > > See above. > > > -Section 8 talks about open issues? When will these be addressed? > > Before it is re-issued. Goal is end of next week. > > ...George > > > Thanks, > > Attila > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > >> Behalf Of Loa Andersson > >> Sent: Friday, March 12, 2010 12:33 AM > >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 > >> > >> All, > >> > >> this is to start an MPLS working group last call on > >> draft-ietf-mpls-tp-identifiers-01 > >> > >> There is a discussion on the OAM model for MS-PWs where we > >> haven't been able to come to conclusion. Once we reach > >> agreement the document will be updated. Comments in this area > >> are welcome during the working group last call. > >> > >> > >> Please send your comments to the mpls-tp@ietf.org mailing list. > >> > >> The working group last ends eob April 2nd. > >> > >> /Loa > >> > >> -- > >> > >> Loa Andersson > >> > >> Sr Strategy and Standards Manager > >> Ericsson /// > >> phone: +46 10 717 52 13 > >> +46 767 72 92 13 > >> > >> email: loa.andersson@ericsson.com > >> loa@pi.nu > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > -- Best Regards, Venkatesan Mahalingam. --000e0cd32cc6550100048b3e776e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
George,
Thanks for your response, please find=A0the followup questions below,<= /div>

Even though Dest_Tunnel_Num is primarily required for bidirectiona= l LSP, this is NOT required for unidirectional LSP.

In MPLS_TP environment, if= user configures an unidirectional LSP (I guess this is not a violation), t= hen the Dest_Tunnel_Num should be ignored.

Is this a correct understa= nding?

And, for bidirectional LSP= s, even though the Dest_Tunnel_Num is required to identify the reverse tunn= el, it need not be an INDEX to identify the bidirectional Tunnel.

Is this a correct understa= nding?

BR,

--Venkat.

On Tue, Jul 13, 2010 at 2:02 AM, George Swallow <swallow@cisco.com> wrote:

In line -=20



On 5/6/10 2:08 PM, "venkatesan mahalinga= m" <venka= tflex@gmail.com> wrote:
Hi George,
>> Is it there to support associated = unidirectional Tunnels/LSPs? If so it should
>> be called out in t= he text.

>That was not my original intent, but you are quite corr= ect that this would
>be very useful. =A0Particularly if the associated tunnels pass through = a share
>mid-point somewhere along the path.
VM: Can you please ex= plain the original intention with an example?

The original in= tent was to allow a compact form for a globally unique MEP-ID that is,

Node_ID::Tunnel_Num::LSP_ID would be unique within an operator. =A0This= requires that Tunnel_Num be unique to the node (not the node pair). =A0Tha= t makes it impossible to coodinate the Tunnel_Num spaces across nodes, henc= e two tunnel numbers.=20


>> -In Section 5.3 Mapping to GMPLS signali= ng does not use the Dst-Tunnel_Num. So
>> this means that we may h= ave two different tunnels identified with
>> Src-Node_ID::Src-Tunn= el_Num::
Dst-Node_ID::Dst-Tunnel_Num. Is this intentional,
>> e.g., the ass= ociated unidirectional case?

>For the associated unidirectional, = this works perfectly. =A0For bidirectional,
>I was thinking of two op= tions.

>1) =A0Strict binding =A0- =A0both ends are configure with the full = identifier and
>will only accept the connection if everything matches= .

>2) =A0Dynamic binding - Source signals with just its Tunnel_Nu= m. =A0RESV message
>would carry back the destination's tunnel_num. =A0Note that both en= ds need
>both pieces for some of the OAM to work.
VM: Do we need e= xtensions in the RSVP-TE signaling to carry back the destination's tunn= el_num in the RESV message?

Yes, this and probably quite a few more. =A0=A0Note that there is= a draft for adding signaling of OAM capabilities in the works.

...G= eorge=20


Thanks,
Venkatesan Mahalingam

On Fri, A= pr 16, 2010 at 10:15 PM, George Swallow <swallow@cisco.com> wrote:



On 4/2/10 2:53 AM, "Attila Takacs" <Attila.Takacs@e= ricsson.com> wrote:

> Hi Matthew and George,
>
> Please find some comments/q= uestions below.
>
> -In Section 5.1 you have:
>
> S= rc-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num
>
> Wha= t is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num?

Existing implementations of RSVP-TE have used the tunnel space as globa= l to
the node. =A0It is difficult if not impossible to coordinate such s= paces
between nodes. =A0In RSVP-TE the coordination does not matter, sin= ce the tail
end of the tunnel doesn't have a real interface - it only receives and<= br>usually with a PHP of the tunnel label, so the packets only belong to th= e
physical interface.

In a bidirectional world, separate tunnel s= paces at the two ends becomes
useful.

If this independence is not need is some environments then o= ne can configure
just one value and use it in both fields.

> I= s it there to support associated unidirectional Tunnels/LSPs? If so it shou= ld
> be called out in the text.

That was not my original intent, but= you are quite correct that this would
be very useful. =A0Particularly i= f the associated tunnels pass through a share
mid-point somewhere along = the path.

> Same applies to the globally unique case.

Of course.
> -In Section 5.2 you simply append one LSP_Num to the above. This is a= bit
> confusing to me, if there are Src/Dst Tunnel_Nums then two LSP= _Nums would be
> needed too, wouldn't it?

Once, you have independent tunnel-= ids, coordination of the LSP numbers
becomes easy. =A0It also could be u= sed to allow the two ends to readily
identify which is working and which= is protection.

> -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tu= nnel_Num. So
> this means that we may have two different tunnels iden= tified with
> Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Nu= m. Is this intentional,
> e.g., the associated unidirectional case?

For the associated un= idirectional, this works perfectly. =A0For bidirectional,
I was thinking= of two options.

1) =A0Strict binding =A0- =A0both ends are configur= e with the full identifier and
will only accept the connection if everything matches.

2) =A0Dynamic= binding - Source signals with just its Tunnel_Num. =A0RESV message
woul= d carry back the destination's tunnel_num. =A0Note that both ends need<= br> both pieces for some of the OAM to work.

> This should be clarifi= ed.

I'll see what I can do. =A0But this is not supposed to the M= PLS-TP signaling
draft.

> Hmm, maybe the Dst-Tunnel_Num should= be omitted altogether.

I'm planning to keep it.

> -Section 7 has a note saying t= o be aligned with the OAM fwk, is this still to
> be done?

Yes= . =A0That draft is also being updated. =A0We appear to be converging.
> -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs.
> H= ow would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel leve= l
> and not at the LSP level?
>
> Do we need Tunnel MEG_I= Ds as defined in 7.1.2.1?

I had been told early on that MEGs were needed for tunnels. =A0Now gett= ing
comments that they are not (same comment is in the ITU liaison). =A0= So I
planning to remove it, unless I hear other opinions.

> -S= ection 7.1.2.2, the Dst-Tunnel_Num question applies here too.

See above.

> -Section 8 talks about open issues? When will th= ese be addressed?

Before it is re-issued. =A0Goal is end of next wee= k.

...George

> Thanks,
> Attila
>
>> = -----Original Message-----
>> From: m= pls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
>> Behalf Of Loa = Andersson
>> Sent: Friday, March 12, 2010 12:33 AM
>> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org
>> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifier= s-01
>>
>> All,
>>
>> this is to start = an MPLS working group last call on
>> draft-ietf-mpls-tp-identifie= rs-01
>>
>> There is a discussion on the OAM model for MS-PWs wher= e we
>> haven't been able to come to conclusion. Once we reach=
>> agreement the document will be updated. Comments in this area<= br> >> are welcome during the working group last call.
>>
>= ;>
>> Please send your comments to the mpls-tp@ietf.org mailing list.
>>= ;
>> The working group last ends eob April 2nd.
>>
>>= /Loa
>>
>> --
>>
>> Loa Andersson
&= gt;>
>> Sr Strategy and Standards Manager
>> Ericsson = ///
>> =A0 =A0phone: =A0+46 10 717 52 13
>> =A0 =A0 =A0 =A0 =A0 = =A0+46 767 72 92 13
>>
>> =A0 =A0email: =A0loa.andersson@ericsson.co= m
>> =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
>>
>>
>>
>>
>> __________________= _____________________________
>> mpls mailing list
>> mpls@ietf.org
>&g= t; https://www.ietf.org/mailman/listinfo/mpls
>>
> _______________________________________________
> mp= ls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/m= pls-tp

_______________________________________________
mpls mailing listmpls@ietf.org
http= s://www.ietf.org/mailman/listinfo/mpls





--
Best Regards,
Ven= katesan Mahalingam.
--000e0cd32cc6550100048b3e776e-- From IBryskin@advaoptical.com Tue Jul 13 07:59:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F543A6978 for ; Tue, 13 Jul 2010 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gcAIrGjOeiL for ; Tue, 13 Jul 2010 07:59:33 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 85CBC3A68DD for ; Tue, 13 Jul 2010 07:59:31 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6DExX8F028306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 13 Jul 2010 16:59:33 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 13 Jul 2010 16:59:33 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 13 Jul 2010 10:59:31 -0400 From: Igor Bryskin To: "neil.2.harrison@bt.com" , "sergio.belotti@alcatel-lucent.com" , "Jonathan.Sadler@tellabs.com" Date: Tue, 13 Jul 2010 10:59:17 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTg Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E993@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E32E@atl-srv-exgen.atl.advaoptical.com> <2ECAA42C79676B42AEBAC11229CA7D0C060F8D42@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C060F8D42@E03MVB2-UKBR.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-13_02:2010-02-06, 2010-07-13, 2010-07-13 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , "SBardalai@infinera.com" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:59:34 -0000 Hi Neil, You response confuses me a bit. Would you agree that there are only two pos= sible ways to model OTN hierarchies: a) a multi-layer construct with a distinct layer per hierarchy level (this = is my suggestion); b) a single layer with several sub-layers (this is how I understand the ITU= model). You seem to disagree with me, which means that you agree with the latter. B= ut this position contradicts IMO with a lot of things you have said in the = context of MPLS-TP. On many occasions, for example, you have explained in g= reat details how you hate the multi-sub-layering in MPLS, that there should= be exactly one sub-layer per MPLS-TP layer, if one is stacking MPLS-TP lin= ks, one is stacking MPLS-TP layers (rather than sub-layers), that we should= n't even need S-bit, etc.... Did I get this right? If so, how come that the= same logic does not apply to OTN layering vs. OTN sub-layering? If anythin= g, the logic should make a better sense for OTN due to its cs-co nature. Further more, my suggestion to introduce several OTN related switching capa= bilities (specifically, 5: one per hierarchy level) has to do with how CP v= iews an OTN hierarchy, regardless whether its each level is a true layer, s= ub-layer or something else. You can think of this as a suggestion for CP to= control various OTN virtual topologies. This would give an operator an eas= y way to constrain a given connection, say, to use only OTUs and avoid usin= g any ODU containers, or, on the contrary, to avoid using OTUs and use ODU = containers, preferably smaller before larger ones. You can argue with the u= sefulness of such feature, but you can hardly argue with the fact that it t= akes nothing away from the current framework: the user can always constrain= the connection path to *any* of the hierarchy levels, and in this case all= OTN links will be considered as equal candidates in the path selection pro= cess. What do you think? I am also interested to hear from the authors of "multi = stage multiplexing configuration in G.709 network" documents. Cheers, Igor -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Friday, July 09, 2010 10:27 AM To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; Jonathan.Sadler@tellab= s.com Cc: ccamp@ietf.org; SBardalai@infinera.com; draft-ietf-ccamp-gmpls-g709-fra= mework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Some observations in-line:=20 Igor Bryskin wrote 09 July 2010 13:59 >=20 > Sergio, >=20 > You wrote: >=20 > " My understanding of Switching Cap is that different=20 > Switching Cap would be linked to different technologies imply=20 > different switching capabilities >=20 > IB>> We do have PSC1-PSC4 for packet switching ( note, one=20 > per MPLS DP hierarchy level, NH=3D> Do you really mean client/server here (as this is the only proper hierarchy case)? I query you on this because right now there is a DP problem in MPLS-TP that is being consciously ignored wrt the implications of the unnecessary carry-over of PWs and sublayering into MPL-TP. And one of the problems (its not the only one) is the potential for misconnectivity between MPLS layers, MPLS sublayers and PW layers when the LSP for each of these looks the same in the DP. Not only must we have a common method of (OAM) detection but this must contain a proper SA of the layer network (or sublayers) in order for quick/correct diagnosis of offending source. =20 > I suggest the same for OTN).=20 NH=3D> It's not a great idea to always blindly replicate the artificial hierarchies that past co-cs mode technologies (like PDH and SDH) created in the future. The PDH hierarchy simply reflected the maturity of silicon technology at the time. SDH replicated this with an increased step size and removed the async 'mux mountain' problem. However, the simple commercial reason for not replicating this fixed hierarchy structure is that each layer network represents a set of DP/CP/MP functions and stuff to configure/operate/etc...these are all costs and things that can fail, ie more layers =3D less reliable. What we really need here is to minimise the number of layer networks between the (external application interfacing) TOS layer network and the (EM wave modulating) BOS layer network. In other words, the future transport network should be migrating to a digital wrapper approach with no fixed hierarchy IMO. =20 > We=20 > have also agreed that a single L2SC is not enough for=20 > Ethernet technology, in fact, we need separate swicthcaps for=20 > STAG switching, EPL, EVPL, etc.=20 >=20 > " : we have not created different Switching Cap for VC4 or=20 > VC12 in SDH".=20 >=20 > IB>> IMO this is the reason why GMPLS in TDM has never really=20 > taken off. NH=3D> I don't agree with this. Though I would separate signalling from routing functions here....and wrt to latter distributed vs centralised cases. Real BOS transport networks must currently have very long information transfer phases (set-up and tear-down phases are very much smaller). So the CP components are nowhere near as important as the MP components...esp as the MP components have to be there anyway. So this is why IMO GMPLS has probably not been as successful as some hoped it would be. BTW - If one looks at the business case for trying to more rapidly set-up/tear-down BOS layer network connections you quickly find that the commercials do not figure for a useful GOS.....at least in today's environment. I got the traffic/maths group at BT labs to look at analysing this topic many years ago in a very general sense (ie very general calling/holding statistics). Though I must add here that today we do not have the truly massive external end-system application numbers we would need nor do we have the short-enough holding times to warrant a switched services case, eg like the PSTN say. If we had this however then would drive the GMPLS CP case.=20 regards, Neil=20 From neil.2.harrison@bt.com Tue Jul 13 08:20:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6763A67E7 for ; Tue, 13 Jul 2010 08:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jJuQlTuPkNo for ; Tue, 13 Jul 2010 08:20:24 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 190043A67DB for ; Tue, 13 Jul 2010 08:20:23 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jul 2010 16:20:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 16:20:28 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C060F948F@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E993@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTgAAGPwGA= From: To: , , X-OriginalArrivalTime: 13 Jul 2010 15:20:31.0997 (UTC) FILETIME=[EEFDAAD0:01CB229E] Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org, SBardalai@infinera.com Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:20:26 -0000 Hi Igor......=20 who wrote 13 July 2010 15:59 > > Hi Neil, >=20 > You response confuses me a bit. Would you agree that there=20 > are only two possible ways to model OTN hierarchies: > a) a multi-layer construct with a distinct layer per=20 > hierarchy level (this is my suggestion); NH=3D> Yes, this is clean BUT I do have a problem with always blindly following the PDH and SDH models.....as each layer =3D cost and less reliability....the key obsrevation being to always strive to minimise the number of layers networks TOS to BOS. Ergo my remarks in my original response below on the need to start thinking about a digital wrapper approach at BOS....and I do know of one vendor who has started to think about this point. =20 > b) a single layer with several sub-layers (this is how I=20 > understand the ITU model). NH=3D> Not a great idea IMO. >=20 > You seem to disagree with me, which means that you agree with=20 > the latter.=20 NH=3D> Now I am confused! The bit I was disagreeing with you on was the reasons you suggested why a GMPLS CP for co-cs mode layer networks had not really taken off. IMO this has nothing to do with technical issues (at least per se) but rather the real cost of providing 'BW on demand' to client X from server Y to meet a given GOS for a given set of calling rate demands and holding times. I asked for this to be modelled a long time ago at our labs (~10 years ago in fact) and the results stated what you have confirmed, ie there is no commercial driver given the population size of current applications that would demand this for a viable (acceptable) GOS....indeed, they are few/no external (to any network) applications today but simply client topology build cases, and here there is no case at all IMO. =20 > But this position contradicts IMO with a lot of=20 > things you have said in the context of MPLS-TP. On many=20 > occasions, for example, you have explained in great details=20 > how you hate the multi-sub-layering in MPLS, that there=20 > should be exactly one sub-layer per MPLS-TP layer, if one is=20 > stacking MPLS-TP links, one is stacking MPLS-TP layers=20 > (rather than sub-layers), that we shouldn't even need S-bit,=20 > etc.... Did I get this right? If so, how come that the same=20 > logic does not apply to OTN layering vs. OTN sub-layering? If=20 > anything, the logic should make a better sense for OTN due to=20 > its cs-co nature. NH=3D> All I have said with sublayering in MPLS-TP, no need for PWs, = etc still stands....they are just plainly obvious facts that anyone can figure out. I think you have simply misunderstood what I wrote as I have noted above. >=20 > Further more, my suggestion to introduce several OTN related=20 > switching capabilities (specifically, 5: one per hierarchy=20 > level) has to do with how CP views an OTN hierarchy,=20 > regardless whether its each level is a true layer, sub-layer=20 > or something else. You can think of this as a suggestion for=20 > CP to control various OTN virtual topologies. This would give=20 > an operator an easy way to constrain a given connection, say,=20 > to use only OTUs and avoid using any ODU containers, or, on=20 > the contrary, to avoid using OTUs and use ODU containers,=20 > preferably smaller before larger ones. You can argue with the=20 > usefulness of such feature, but you can hardly argue with the=20 > fact that it takes nothing away from the current framework:=20 > the user can always constrain the connection path to *any* of=20 > the hierarchy levels, and in this case all OTN links will be=20 > considered as equal candidates in the path selection process. >=20 > What do you think? NH=3D> I think the replication of the PDH/SDH hierarchy in OTN was a mistake...for the reasons I gave above. regards, Neil I am also interested to hear from the=20 > authors of "multi stage multiplexing configuration in G.709=20 > network" documents. >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, July 09, 2010 10:27 AM > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com;=20 > Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Some observations in-line:=20 >=20 > Igor Bryskin wrote 09 July 2010 13:59 > >=20 > > Sergio, > >=20 > > You wrote: > >=20 > > " My understanding of Switching Cap is that different Switching Cap=20 > > would be linked to different technologies imply different switching=20 > > capabilities > >=20 > > IB>> We do have PSC1-PSC4 for packet switching ( note, one > > per MPLS DP hierarchy level, >=20 > NH=3D> Do you really mean client/server here (as this is the only = proper > hierarchy case)? I query you on this because right now there is a DP > problem in MPLS-TP that is being consciously ignored wrt the > implications of the unnecessary carry-over of PWs and sublayering into > MPL-TP. And one of the problems (its not the only one) is=20 > the potential > for misconnectivity between MPLS layers, MPLS sublayers and PW layers > when the LSP for each of these looks the same in the DP. Not=20 > only must > we have a common method of (OAM) detection but this must contain a > proper SA of the layer network (or sublayers) in order for=20 > quick/correct > diagnosis of offending source. =20 >=20 >=20 > > I suggest the same for OTN).=20 >=20 > NH=3D> It's not a great idea to always blindly replicate the = artificial > hierarchies that past co-cs mode technologies (like PDH and=20 > SDH) created > in the future. The PDH hierarchy simply reflected the maturity of > silicon technology at the time. SDH replicated this with an increased > step size and removed the async 'mux mountain' problem. However, the > simple commercial reason for not replicating this fixed hierarchy > structure is that each layer network represents a set of DP/CP/MP > functions and stuff to configure/operate/etc...these are all costs and > things that can fail, ie more layers =3D less reliable. What we = really > need here is to minimise the number of layer networks between the > (external application interfacing) TOS layer network and the (EM wave > modulating) BOS layer network. In other words, the future transport > network should be migrating to a digital wrapper approach=20 > with no fixed > hierarchy IMO. =20 >=20 >=20 > > We=20 > > have also agreed that a single L2SC is not enough for=20 > > Ethernet technology, in fact, we need separate swicthcaps for=20 > > STAG switching, EPL, EVPL, etc.=20 > >=20 > > " : we have not created different Switching Cap for VC4 or=20 > > VC12 in SDH".=20 > >=20 > > IB>> IMO this is the reason why GMPLS in TDM has never really=20 > > taken off. >=20 > NH=3D> I don't agree with this. Though I would separate signalling = from > routing functions here....and wrt to latter distributed vs centralised > cases. Real BOS transport networks must currently have very long > information transfer phases (set-up and tear-down phases are very much > smaller). So the CP components are nowhere near as important=20 > as the MP > components...esp as the MP components have to be there=20 > anyway. So this > is why IMO GMPLS has probably not been as successful as some hoped it > would be. >=20 > BTW - If one looks at the business case for trying to more rapidly > set-up/tear-down BOS layer network connections you quickly=20 > find that the > commercials do not figure for a useful GOS.....at least in today's > environment. I got the traffic/maths group at BT labs to look at > analysing this topic many years ago in a very general sense (ie very > general calling/holding statistics). Though I must add here=20 > that today > we do not have the truly massive external end-system=20 > application numbers > we would need nor do we have the short-enough holding times=20 > to warrant a > switched services case, eg like the PSTN say. If we had this however > then would drive the GMPLS CP case.=20 >=20 > regards, Neil=20 >=20 > >=20 From IBryskin@advaoptical.com Tue Jul 13 08:34:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2643A6A50 for ; Tue, 13 Jul 2010 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-cYN-hnlQm0 for ; Tue, 13 Jul 2010 08:34:17 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id D5DA73A6A89 for ; Tue, 13 Jul 2010 08:34:13 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6DFYE59011420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 13 Jul 2010 17:34:14 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 13 Jul 2010 17:34:14 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 13 Jul 2010 11:34:12 -0400 From: Igor Bryskin To: "neil.2.harrison@bt.com" , "sergio.belotti@alcatel-lucent.com" , "Jonathan.Sadler@tellabs.com" Date: Tue, 13 Jul 2010 11:34:09 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTgAAGPwGAAALpQEA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E9BF@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E993@atl-srv-exgen.atl.advaoptical.com> <2ECAA42C79676B42AEBAC11229CA7D0C060F948F@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C060F948F@E03MVB2-UKBR.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-13_02:2010-02-06, 2010-07-13, 2010-07-13 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , "SBardalai@infinera.com" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:34:24 -0000 Neil,=20 > a) a multi-layer construct with a distinct layer per=20 > hierarchy level (this is my suggestion); > b) a single layer with several sub-layers (this is how I=20 > understand the ITU model). You are saying that a) is clean but wasteful and b) is not a good idea, So what is in your opinion a good model? Is it: c) a single layer and no sub-layers? But how OTN hierarchy fits in? Thanks, Igor -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Tuesday, July 13, 2010 11:20 AM To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; Jonathan.Sadler@tellab= s.com Cc: ccamp@ietf.org; SBardalai@infinera.com; draft-ietf-ccamp-gmpls-g709-fra= mework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor......=20 who wrote 13 July 2010 15:59 > > Hi Neil, >=20 > You response confuses me a bit. Would you agree that there=20 > are only two possible ways to model OTN hierarchies: > a) a multi-layer construct with a distinct layer per=20 > hierarchy level (this is my suggestion); NH=3D> Yes, this is clean BUT I do have a problem with always blindly following the PDH and SDH models.....as each layer =3D cost and less reliability....the key obsrevation being to always strive to minimise the number of layers networks TOS to BOS. Ergo my remarks in my original response below on the need to start thinking about a digital wrapper approach at BOS....and I do know of one vendor who has started to think about this point. =20 > b) a single layer with several sub-layers (this is how I=20 > understand the ITU model). NH=3D> Not a great idea IMO. >=20 > You seem to disagree with me, which means that you agree with=20 > the latter.=20 NH=3D> Now I am confused! The bit I was disagreeing with you on was the reasons you suggested why a GMPLS CP for co-cs mode layer networks had not really taken off. IMO this has nothing to do with technical issues (at least per se) but rather the real cost of providing 'BW on demand' to client X from server Y to meet a given GOS for a given set of calling rate demands and holding times. I asked for this to be modelled a long time ago at our labs (~10 years ago in fact) and the results stated what you have confirmed, ie there is no commercial driver given the population size of current applications that would demand this for a viable (acceptable) GOS....indeed, they are few/no external (to any network) applications today but simply client topology build cases, and here there is no case at all IMO. =20 > But this position contradicts IMO with a lot of=20 > things you have said in the context of MPLS-TP. On many=20 > occasions, for example, you have explained in great details=20 > how you hate the multi-sub-layering in MPLS, that there=20 > should be exactly one sub-layer per MPLS-TP layer, if one is=20 > stacking MPLS-TP links, one is stacking MPLS-TP layers=20 > (rather than sub-layers), that we shouldn't even need S-bit,=20 > etc.... Did I get this right? If so, how come that the same=20 > logic does not apply to OTN layering vs. OTN sub-layering? If=20 > anything, the logic should make a better sense for OTN due to=20 > its cs-co nature. NH=3D> All I have said with sublayering in MPLS-TP, no need for PWs, etc still stands....they are just plainly obvious facts that anyone can figure out. I think you have simply misunderstood what I wrote as I have noted above. >=20 > Further more, my suggestion to introduce several OTN related=20 > switching capabilities (specifically, 5: one per hierarchy=20 > level) has to do with how CP views an OTN hierarchy,=20 > regardless whether its each level is a true layer, sub-layer=20 > or something else. You can think of this as a suggestion for=20 > CP to control various OTN virtual topologies. This would give=20 > an operator an easy way to constrain a given connection, say,=20 > to use only OTUs and avoid using any ODU containers, or, on=20 > the contrary, to avoid using OTUs and use ODU containers,=20 > preferably smaller before larger ones. You can argue with the=20 > usefulness of such feature, but you can hardly argue with the=20 > fact that it takes nothing away from the current framework:=20 > the user can always constrain the connection path to *any* of=20 > the hierarchy levels, and in this case all OTN links will be=20 > considered as equal candidates in the path selection process. >=20 > What do you think? NH=3D> I think the replication of the PDH/SDH hierarchy in OTN was a mistake...for the reasons I gave above. regards, Neil I am also interested to hear from the=20 > authors of "multi stage multiplexing configuration in G.709=20 > network" documents. >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, July 09, 2010 10:27 AM > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com;=20 > Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Some observations in-line:=20 >=20 > Igor Bryskin wrote 09 July 2010 13:59 > >=20 > > Sergio, > >=20 > > You wrote: > >=20 > > " My understanding of Switching Cap is that different Switching Cap=20 > > would be linked to different technologies imply different switching=20 > > capabilities > >=20 > > IB>> We do have PSC1-PSC4 for packet switching ( note, one > > per MPLS DP hierarchy level, >=20 > NH=3D> Do you really mean client/server here (as this is the only proper > hierarchy case)? I query you on this because right now there is a DP > problem in MPLS-TP that is being consciously ignored wrt the > implications of the unnecessary carry-over of PWs and sublayering into > MPL-TP. And one of the problems (its not the only one) is=20 > the potential > for misconnectivity between MPLS layers, MPLS sublayers and PW layers > when the LSP for each of these looks the same in the DP. Not=20 > only must > we have a common method of (OAM) detection but this must contain a > proper SA of the layer network (or sublayers) in order for=20 > quick/correct > diagnosis of offending source. =20 >=20 >=20 > > I suggest the same for OTN).=20 >=20 > NH=3D> It's not a great idea to always blindly replicate the artificial > hierarchies that past co-cs mode technologies (like PDH and=20 > SDH) created > in the future. The PDH hierarchy simply reflected the maturity of > silicon technology at the time. SDH replicated this with an increased > step size and removed the async 'mux mountain' problem. However, the > simple commercial reason for not replicating this fixed hierarchy > structure is that each layer network represents a set of DP/CP/MP > functions and stuff to configure/operate/etc...these are all costs and > things that can fail, ie more layers =3D less reliable. What we really > need here is to minimise the number of layer networks between the > (external application interfacing) TOS layer network and the (EM wave > modulating) BOS layer network. In other words, the future transport > network should be migrating to a digital wrapper approach=20 > with no fixed > hierarchy IMO. =20 >=20 >=20 > > We=20 > > have also agreed that a single L2SC is not enough for=20 > > Ethernet technology, in fact, we need separate swicthcaps for=20 > > STAG switching, EPL, EVPL, etc.=20 > >=20 > > " : we have not created different Switching Cap for VC4 or=20 > > VC12 in SDH".=20 > >=20 > > IB>> IMO this is the reason why GMPLS in TDM has never really=20 > > taken off. >=20 > NH=3D> I don't agree with this. Though I would separate signalling from > routing functions here....and wrt to latter distributed vs centralised > cases. Real BOS transport networks must currently have very long > information transfer phases (set-up and tear-down phases are very much > smaller). So the CP components are nowhere near as important=20 > as the MP > components...esp as the MP components have to be there=20 > anyway. So this > is why IMO GMPLS has probably not been as successful as some hoped it > would be. >=20 > BTW - If one looks at the business case for trying to more rapidly > set-up/tear-down BOS layer network connections you quickly=20 > find that the > commercials do not figure for a useful GOS.....at least in today's > environment. I got the traffic/maths group at BT labs to look at > analysing this topic many years ago in a very general sense (ie very > general calling/holding statistics). Though I must add here=20 > that today > we do not have the truly massive external end-system=20 > application numbers > we would need nor do we have the short-enough holding times=20 > to warrant a > switched services case, eg like the PSTN say. If we had this however > then would drive the GMPLS CP case.=20 >=20 > regards, Neil=20 >=20 > >=20 From neil.2.harrison@bt.com Tue Jul 13 09:00:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA633A6A0F for ; Tue, 13 Jul 2010 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8aAM9UaF5Bs for ; Tue, 13 Jul 2010 09:00:43 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 14C6A3A695E for ; Tue, 13 Jul 2010 09:00:42 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jul 2010 17:00:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 17:00:48 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C060F94D3@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E9BF@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTgAAGPwGAAALpQEAAAz1JA From: To: , , X-OriginalArrivalTime: 13 Jul 2010 16:00:51.0528 (UTC) FILETIME=[9124CC80:01CB22A4] Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org, SBardalai@infinera.com Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:00:45 -0000 Hi Igor..=20 13 July 2010 16:34 =20 > Neil,=20 >=20 > > a) a multi-layer construct with a distinct layer per=20 > hierarchy level=20 > > (this is my suggestion); > > b) a single layer with several sub-layers (this is how I understand=20 > > the ITU model). >=20 > You are saying that a) is clean but wasteful and b) is not a=20 > good idea, So what is in your opinion a good model? Is it: >=20 > c) a single layer and no sub-layers? > But how OTN hierarchy fits in? NH=3D> I'm not sure you have followed what I said...so let me very = briefly recap one last time: - I very much believe each layer network should be a self contained instance in the general case....this includes a routing component for that (and only that) layer network - I believe sublayering is not required in a transport network (and I'd also add to the 'not required' the somewhat even more artificial case of TCM OAM here - noting carefully that there is no technical necessity for E-NNIs in non-TOS layer networks, so this is no justification for TCM at all) - the old PDH hierarchy came from silicon technology break-points.....SDH replicated this basic idea. =20 - we always must have TOS and BOS layer networks present in all networks cases, and to minimise cost and maximise reliability we should reduce to the minimum any additional layers networks between the TOS and BOS extremes. So just blindly carrying on replicating what happened in PDH/SDH is not a great idea....need to think out of the box a bit....ergo the digital wrapper approach is good idea. BTW Note carefully that one guy's transport network (layer N say) is another guy's service....and what this means is that we have to create layer network N+1 (ie downwards) to carry the whole bit rate of the layer N network in the payload of the layer N+1 traffic unit....and so we end-up generating more and more layer networks towards the duct. This approach is not a sustainable. - Too late for OTN....it did a me-too on the SDH/PDH way of doing things. Is that clear now? Hope so. regards, Neil=20 >=20 > Thanks, > Igor >=20 >=20 >=20 >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, July 13, 2010 11:20 AM > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com;=20 > Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Hi Igor......=20 > who wrote 13 July 2010 15:59 > > > > Hi Neil, > >=20 > > You response confuses me a bit. Would you agree that there are only=20 > > two possible ways to model OTN hierarchies: > > a) a multi-layer construct with a distinct layer per=20 > hierarchy level=20 > > (this is my suggestion); >=20 > NH=3D> Yes, this is clean BUT I do have a problem with always=20 > blindly following the PDH and SDH models.....as each layer =3D=20 > cost and less reliability....the key obsrevation being to=20 > always strive to minimise the number of layers networks TOS=20 > to BOS. Ergo my remarks in my original response below on the=20 > need to start thinking about a digital wrapper approach at=20 > BOS....and I do know of one vendor who has started to think=20 > about this point. >=20 > =20 > > b) a single layer with several sub-layers (this is how I understand=20 > > the ITU model). >=20 > NH=3D> Not a great idea IMO. > >=20 > > You seem to disagree with me, which means that you agree with the=20 > > latter. >=20 > NH=3D> Now I am confused! The bit I was disagreeing with you=20 > on was the reasons you suggested why a GMPLS CP for co-cs=20 > mode layer networks had not really taken off. IMO this has=20 > nothing to do with technical issues (at least per se) but=20 > rather the real cost of providing 'BW on demand' > to client X from server Y to meet a given GOS for a given set=20 > of calling rate demands and holding times. I asked for this=20 > to be modelled a long time ago at our labs (~10 years ago in=20 > fact) and the results stated what you have confirmed, ie=20 > there is no commercial driver given the population size of=20 > current applications that would demand this for a viable=20 > (acceptable) GOS....indeed, they are few/no external (to any > network) applications today but simply client topology build=20 > cases, and here there is no case at all IMO. =20 >=20 > > But this position contradicts IMO with a lot of things you=20 > have said=20 > > in the context of MPLS-TP. On many occasions, for example, you have=20 > > explained in great details how you hate the multi-sub-layering in=20 > > MPLS, that there should be exactly one sub-layer per=20 > MPLS-TP layer, if=20 > > one is stacking MPLS-TP links, one is stacking MPLS-TP=20 > layers (rather=20 > > than sub-layers), that we shouldn't even need S-bit,=20 > etc.... Did I get=20 > > this right? If so, how come that the same logic does not=20 > apply to OTN=20 > > layering vs. OTN sub-layering? If anything, the logic should make a=20 > > better sense for OTN due to its cs-co nature. >=20 > NH=3D> All I have said with sublayering in MPLS-TP, no need for=20 > PWs, etc still stands....they are just plainly obvious facts=20 > that anyone can figure out. I think you have simply=20 > misunderstood what I wrote as I have noted above. > >=20 > > Further more, my suggestion to introduce several OTN=20 > related switching=20 > > capabilities (specifically, 5: one per hierarchy > > level) has to do with how CP views an OTN hierarchy, regardless=20 > > whether its each level is a true layer, sub-layer or=20 > something else.=20 > > You can think of this as a suggestion for CP to control various OTN=20 > > virtual topologies. This would give an operator an easy way to=20 > > constrain a given connection, say, to use only OTUs and avoid using=20 > > any ODU containers, or, on the contrary, to avoid using=20 > OTUs and use=20 > > ODU containers, preferably smaller before larger ones. You=20 > can argue=20 > > with the usefulness of such feature, but you can hardly=20 > argue with the=20 > > fact that it takes nothing away from the current framework: > > the user can always constrain the connection path to *any* of the=20 > > hierarchy levels, and in this case all OTN links will be=20 > considered as=20 > > equal candidates in the path selection process. > >=20 > > What do you think? >=20 > NH=3D> I think the replication of the PDH/SDH hierarchy in OTN=20 > was a mistake...for the reasons I gave above. >=20 > regards, Neil >=20 >=20 > I am also interested to hear from the=20 > > authors of "multi stage multiplexing configuration in G.709=20 > network"=20 > > documents. > >=20 > > Cheers, > > Igor > >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Friday, July 09, 2010 10:27 AM > > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; > > Jonathan.Sadler@tellabs.com > > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > >=20 > > Some observations in-line:=20 > >=20 > > Igor Bryskin wrote 09 July 2010 13:59 > > >=20 > > > Sergio, > > >=20 > > > You wrote: > > >=20 > > > " My understanding of Switching Cap is that different=20 > Switching Cap=20 > > > would be linked to different technologies imply different=20 > switching=20 > > > capabilities > > >=20 > > > IB>> We do have PSC1-PSC4 for packet switching ( note, one > > > per MPLS DP hierarchy level, > >=20 > > NH=3D> Do you really mean client/server here (as this is the=20 > only proper=20 > > hierarchy case)? I query you on this because right now=20 > there is a DP=20 > > problem in MPLS-TP that is being consciously ignored wrt the=20 > > implications of the unnecessary carry-over of PWs and=20 > sublayering into=20 > > MPL-TP. And one of the problems (its not the only one) is the=20 > > potential for misconnectivity between MPLS layers, MPLS=20 > sublayers and=20 > > PW layers when the LSP for each of these looks the same in the DP. =20 > > Not only must we have a common method of (OAM) detection=20 > but this must=20 > > contain a proper SA of the layer network (or sublayers) in=20 > order for=20 > > quick/correct diagnosis of offending source. > >=20 > >=20 > > > I suggest the same for OTN).=20 > >=20 > > NH=3D> It's not a great idea to always blindly replicate the=20 > artificial=20 > > hierarchies that past co-cs mode technologies (like PDH and > > SDH) created > > in the future. The PDH hierarchy simply reflected the maturity of=20 > > silicon technology at the time. SDH replicated this with=20 > an increased=20 > > step size and removed the async 'mux mountain' problem. =20 > However, the=20 > > simple commercial reason for not replicating this fixed hierarchy=20 > > structure is that each layer network represents a set of DP/CP/MP=20 > > functions and stuff to configure/operate/etc...these are=20 > all costs and=20 > > things that can fail, ie more layers =3D less reliable. What=20 > we really=20 > > need here is to minimise the number of layer networks between the=20 > > (external application interfacing) TOS layer network and=20 > the (EM wave > > modulating) BOS layer network. In other words, the future=20 > transport=20 > > network should be migrating to a digital wrapper approach with no=20 > > fixed hierarchy IMO. > >=20 > >=20 > > > We > > > have also agreed that a single L2SC is not enough for Ethernet=20 > > > technology, in fact, we need separate swicthcaps for STAG=20 > switching,=20 > > > EPL, EVPL, etc. > > >=20 > > > " : we have not created different Switching Cap for VC4 or > > > VC12 in SDH".=20 > > >=20 > > > IB>> IMO this is the reason why GMPLS in TDM has never really > > > taken off. > >=20 > > NH=3D> I don't agree with this. Though I would separate=20 > signalling from=20 > > routing functions here....and wrt to latter distributed vs=20 > centralised=20 > > cases. Real BOS transport networks must currently have very long=20 > > information transfer phases (set-up and tear-down phases=20 > are very much=20 > > smaller). So the CP components are nowhere near as=20 > important as the=20 > > MP components...esp as the MP components have to be there=20 > anyway. So=20 > > this is why IMO GMPLS has probably not been as successful as some=20 > > hoped it would be. > >=20 > > BTW - If one looks at the business case for trying to more rapidly=20 > > set-up/tear-down BOS layer network connections you quickly=20 > find that=20 > > the commercials do not figure for a useful GOS.....at least=20 > in today's=20 > > environment. I got the traffic/maths group at BT labs to look at=20 > > analysing this topic many years ago in a very general sense=20 > (ie very=20 > > general calling/holding statistics). Though I must add here that=20 > > today we do not have the truly massive external end-system=20 > application=20 > > numbers we would need nor do we have the short-enough=20 > holding times to=20 > > warrant a switched services case, eg like the PSTN say. If we had=20 > > this however then would drive the GMPLS CP case. > >=20 > > regards, Neil > >=20 > > > >=20 >=20 From IBryskin@advaoptical.com Tue Jul 13 09:28:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29283A6A5B for ; Tue, 13 Jul 2010 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRS2u-obrJjj for ; Tue, 13 Jul 2010 09:28:40 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id B8AAC3A6A4C for ; Tue, 13 Jul 2010 09:28:39 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6DGSgLi020300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 13 Jul 2010 18:28:42 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 13 Jul 2010 18:28:42 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 13 Jul 2010 12:28:39 -0400 From: Igor Bryskin To: "neil.2.harrison@bt.com" , "sergio.belotti@alcatel-lucent.com" , "Jonathan.Sadler@tellabs.com" Date: Tue, 13 Jul 2010 12:28:05 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTgAAGPwGAAALpQEAAAz1JAAAEUDiA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E9F4@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E9BF@atl-srv-exgen.atl.advaoptical.com> <2ECAA42C79676B42AEBAC11229CA7D0C060F94D3@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C060F94D3@E03MVB2-UKBR.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-13_02:2010-02-06, 2010-07-13, 2010-07-13 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , "SBardalai@infinera.com" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:28:42 -0000 No Neil, it is not clear, because you didn't answer my question which is: If you and Y.800 folks model OTN today what in your opinion would be a corr= ect model: 1) multi-layer with no sub-layering; 2) single layer with sub-layers; 3) single layer with no sub-layers; 4) something else, e.g. you mentioned digital wrapper approach Can you give me a short answer: 1, 2, 3 or 4? If 4, can you elaborate how this will work for OTN. Thanks, Igor -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Tuesday, July 13, 2010 12:01 PM To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; Jonathan.Sadler@tellab= s.com Cc: ccamp@ietf.org; SBardalai@infinera.com; draft-ietf-ccamp-gmpls-g709-fra= mework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor..=20 13 July 2010 16:34 =20 > Neil,=20 >=20 > > a) a multi-layer construct with a distinct layer per=20 > hierarchy level=20 > > (this is my suggestion); > > b) a single layer with several sub-layers (this is how I understand=20 > > the ITU model). >=20 > You are saying that a) is clean but wasteful and b) is not a=20 > good idea, So what is in your opinion a good model? Is it: >=20 > c) a single layer and no sub-layers? > But how OTN hierarchy fits in? NH=3D> I'm not sure you have followed what I said...so let me very briefly recap one last time: - I very much believe each layer network should be a self contained instance in the general case....this includes a routing component for that (and only that) layer network - I believe sublayering is not required in a transport network (and I'd also add to the 'not required' the somewhat even more artificial case of TCM OAM here - noting carefully that there is no technical necessity for E-NNIs in non-TOS layer networks, so this is no justification for TCM at all) - the old PDH hierarchy came from silicon technology break-points.....SDH replicated this basic idea. =20 - we always must have TOS and BOS layer networks present in all networks cases, and to minimise cost and maximise reliability we should reduce to the minimum any additional layers networks between the TOS and BOS extremes. So just blindly carrying on replicating what happened in PDH/SDH is not a great idea....need to think out of the box a bit....ergo the digital wrapper approach is good idea. BTW Note carefully that one guy's transport network (layer N say) is another guy's service....and what this means is that we have to create layer network N+1 (ie downwards) to carry the whole bit rate of the layer N network in the payload of the layer N+1 traffic unit....and so we end-up generating more and more layer networks towards the duct. This approach is not a sustainable. - Too late for OTN....it did a me-too on the SDH/PDH way of doing things. Is that clear now? Hope so. regards, Neil=20 >=20 > Thanks, > Igor >=20 >=20 >=20 >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, July 13, 2010 11:20 AM > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com;=20 > Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Hi Igor......=20 > who wrote 13 July 2010 15:59 > > > > Hi Neil, > >=20 > > You response confuses me a bit. Would you agree that there are only=20 > > two possible ways to model OTN hierarchies: > > a) a multi-layer construct with a distinct layer per=20 > hierarchy level=20 > > (this is my suggestion); >=20 > NH=3D> Yes, this is clean BUT I do have a problem with always=20 > blindly following the PDH and SDH models.....as each layer =3D=20 > cost and less reliability....the key obsrevation being to=20 > always strive to minimise the number of layers networks TOS=20 > to BOS. Ergo my remarks in my original response below on the=20 > need to start thinking about a digital wrapper approach at=20 > BOS....and I do know of one vendor who has started to think=20 > about this point. >=20 > =20 > > b) a single layer with several sub-layers (this is how I understand=20 > > the ITU model). >=20 > NH=3D> Not a great idea IMO. > >=20 > > You seem to disagree with me, which means that you agree with the=20 > > latter. >=20 > NH=3D> Now I am confused! The bit I was disagreeing with you=20 > on was the reasons you suggested why a GMPLS CP for co-cs=20 > mode layer networks had not really taken off. IMO this has=20 > nothing to do with technical issues (at least per se) but=20 > rather the real cost of providing 'BW on demand' > to client X from server Y to meet a given GOS for a given set=20 > of calling rate demands and holding times. I asked for this=20 > to be modelled a long time ago at our labs (~10 years ago in=20 > fact) and the results stated what you have confirmed, ie=20 > there is no commercial driver given the population size of=20 > current applications that would demand this for a viable=20 > (acceptable) GOS....indeed, they are few/no external (to any > network) applications today but simply client topology build=20 > cases, and here there is no case at all IMO. =20 >=20 > > But this position contradicts IMO with a lot of things you=20 > have said=20 > > in the context of MPLS-TP. On many occasions, for example, you have=20 > > explained in great details how you hate the multi-sub-layering in=20 > > MPLS, that there should be exactly one sub-layer per=20 > MPLS-TP layer, if=20 > > one is stacking MPLS-TP links, one is stacking MPLS-TP=20 > layers (rather=20 > > than sub-layers), that we shouldn't even need S-bit,=20 > etc.... Did I get=20 > > this right? If so, how come that the same logic does not=20 > apply to OTN=20 > > layering vs. OTN sub-layering? If anything, the logic should make a=20 > > better sense for OTN due to its cs-co nature. >=20 > NH=3D> All I have said with sublayering in MPLS-TP, no need for=20 > PWs, etc still stands....they are just plainly obvious facts=20 > that anyone can figure out. I think you have simply=20 > misunderstood what I wrote as I have noted above. > >=20 > > Further more, my suggestion to introduce several OTN=20 > related switching=20 > > capabilities (specifically, 5: one per hierarchy > > level) has to do with how CP views an OTN hierarchy, regardless=20 > > whether its each level is a true layer, sub-layer or=20 > something else.=20 > > You can think of this as a suggestion for CP to control various OTN=20 > > virtual topologies. This would give an operator an easy way to=20 > > constrain a given connection, say, to use only OTUs and avoid using=20 > > any ODU containers, or, on the contrary, to avoid using=20 > OTUs and use=20 > > ODU containers, preferably smaller before larger ones. You=20 > can argue=20 > > with the usefulness of such feature, but you can hardly=20 > argue with the=20 > > fact that it takes nothing away from the current framework: > > the user can always constrain the connection path to *any* of the=20 > > hierarchy levels, and in this case all OTN links will be=20 > considered as=20 > > equal candidates in the path selection process. > >=20 > > What do you think? >=20 > NH=3D> I think the replication of the PDH/SDH hierarchy in OTN=20 > was a mistake...for the reasons I gave above. >=20 > regards, Neil >=20 >=20 > I am also interested to hear from the=20 > > authors of "multi stage multiplexing configuration in G.709=20 > network"=20 > > documents. > >=20 > > Cheers, > > Igor > >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Friday, July 09, 2010 10:27 AM > > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; > > Jonathan.Sadler@tellabs.com > > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > >=20 > > Some observations in-line:=20 > >=20 > > Igor Bryskin wrote 09 July 2010 13:59 > > >=20 > > > Sergio, > > >=20 > > > You wrote: > > >=20 > > > " My understanding of Switching Cap is that different=20 > Switching Cap=20 > > > would be linked to different technologies imply different=20 > switching=20 > > > capabilities > > >=20 > > > IB>> We do have PSC1-PSC4 for packet switching ( note, one > > > per MPLS DP hierarchy level, > >=20 > > NH=3D> Do you really mean client/server here (as this is the=20 > only proper=20 > > hierarchy case)? I query you on this because right now=20 > there is a DP=20 > > problem in MPLS-TP that is being consciously ignored wrt the=20 > > implications of the unnecessary carry-over of PWs and=20 > sublayering into=20 > > MPL-TP. And one of the problems (its not the only one) is the=20 > > potential for misconnectivity between MPLS layers, MPLS=20 > sublayers and=20 > > PW layers when the LSP for each of these looks the same in the DP. =20 > > Not only must we have a common method of (OAM) detection=20 > but this must=20 > > contain a proper SA of the layer network (or sublayers) in=20 > order for=20 > > quick/correct diagnosis of offending source. > >=20 > >=20 > > > I suggest the same for OTN).=20 > >=20 > > NH=3D> It's not a great idea to always blindly replicate the=20 > artificial=20 > > hierarchies that past co-cs mode technologies (like PDH and > > SDH) created > > in the future. The PDH hierarchy simply reflected the maturity of=20 > > silicon technology at the time. SDH replicated this with=20 > an increased=20 > > step size and removed the async 'mux mountain' problem. =20 > However, the=20 > > simple commercial reason for not replicating this fixed hierarchy=20 > > structure is that each layer network represents a set of DP/CP/MP=20 > > functions and stuff to configure/operate/etc...these are=20 > all costs and=20 > > things that can fail, ie more layers =3D less reliable. What=20 > we really=20 > > need here is to minimise the number of layer networks between the=20 > > (external application interfacing) TOS layer network and=20 > the (EM wave > > modulating) BOS layer network. In other words, the future=20 > transport=20 > > network should be migrating to a digital wrapper approach with no=20 > > fixed hierarchy IMO. > >=20 > >=20 > > > We > > > have also agreed that a single L2SC is not enough for Ethernet=20 > > > technology, in fact, we need separate swicthcaps for STAG=20 > switching,=20 > > > EPL, EVPL, etc. > > >=20 > > > " : we have not created different Switching Cap for VC4 or > > > VC12 in SDH".=20 > > >=20 > > > IB>> IMO this is the reason why GMPLS in TDM has never really > > > taken off. > >=20 > > NH=3D> I don't agree with this. Though I would separate=20 > signalling from=20 > > routing functions here....and wrt to latter distributed vs=20 > centralised=20 > > cases. Real BOS transport networks must currently have very long=20 > > information transfer phases (set-up and tear-down phases=20 > are very much=20 > > smaller). So the CP components are nowhere near as=20 > important as the=20 > > MP components...esp as the MP components have to be there=20 > anyway. So=20 > > this is why IMO GMPLS has probably not been as successful as some=20 > > hoped it would be. > >=20 > > BTW - If one looks at the business case for trying to more rapidly=20 > > set-up/tear-down BOS layer network connections you quickly=20 > find that=20 > > the commercials do not figure for a useful GOS.....at least=20 > in today's=20 > > environment. I got the traffic/maths group at BT labs to look at=20 > > analysing this topic many years ago in a very general sense=20 > (ie very=20 > > general calling/holding statistics). Though I must add here that=20 > > today we do not have the truly massive external end-system=20 > application=20 > > numbers we would need nor do we have the short-enough=20 > holding times to=20 > > warrant a switched services case, eg like the PSTN say. If we had=20 > > this however then would drive the GMPLS CP case. > >=20 > > regards, Neil > >=20 > > > >=20 >=20 From neil.2.harrison@bt.com Tue Jul 13 09:33:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265173A6824 for ; Tue, 13 Jul 2010 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WUlYZC-pTHZ for ; Tue, 13 Jul 2010 09:33:31 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 347E33A696F for ; Tue, 13 Jul 2010 09:33:30 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 17:33:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 17:33:37 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C060F94ED@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E9F4@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTgAAGPwGAAALpQEAAAz1JAAAEUDiAAAI/88A== From: To: , , X-OriginalArrivalTime: 13 Jul 2010 16:33:39.0413 (UTC) FILETIME=[26183850:01CB22A9] Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org, SBardalai@infinera.com Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:33:37 -0000 Given OTN as-is, my view is 1. BTW 4 will not work for OTN as-is...we would need a new approach. regards, Neil=20 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 > Sent: 13 July 2010 17:28 > To: Harrison,N,Neil,DKQ7 R;=20 > sergio.belotti@alcatel-lucent.com; Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > No Neil, it is not clear, because you didn't answer my=20 > question which is: >=20 > If you and Y.800 folks model OTN today what in your opinion=20 > would be a correct model: > 1) multi-layer with no sub-layering; > 2) single layer with sub-layers; > 3) single layer with no sub-layers; > 4) something else, e.g. you mentioned digital wrapper approach >=20 > Can you give me a short answer: 1, 2, 3 or 4? >=20 > If 4, can you elaborate how this will work for OTN. >=20 > Thanks, > Igor >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, July 13, 2010 12:01 PM > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com;=20 > Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Hi Igor..=20 > 13 July 2010 16:34 > =20 > > Neil, > >=20 > > > a) a multi-layer construct with a distinct layer per > > hierarchy level > > > (this is my suggestion); > > > b) a single layer with several sub-layers (this is how I=20 > understand=20 > > > the ITU model). > >=20 > > You are saying that a) is clean but wasteful and b) is not a good=20 > > idea, So what is in your opinion a good model? Is it: > >=20 > > c) a single layer and no sub-layers? > > But how OTN hierarchy fits in? >=20 > NH=3D> I'm not sure you have followed what I said...so let me=20 > very briefly recap one last time: >=20 > - I very much believe each layer network should be a self > contained instance in the general case....this includes a=20 > routing component for that (and only that) layer network >=20 > - I believe sublayering is not required in a transport network > (and I'd also add to the 'not required' the somewhat even=20 > more artificial case of TCM OAM here - noting carefully that=20 > there is no technical necessity for E-NNIs in non-TOS layer=20 > networks, so this is no justification for TCM at all) >=20 > - the old PDH hierarchy came from silicon technology > break-points.....SDH replicated this basic idea. =20 >=20 > - we always must have TOS and BOS layer networks present in all > networks cases, and to minimise cost and maximise reliability=20 > we should reduce to the minimum any additional layers=20 > networks between the TOS and BOS extremes. So just blindly=20 > carrying on replicating what happened in PDH/SDH is not a=20 > great idea....need to think out of the box a bit....ergo the=20 > digital wrapper approach is good idea. BTW Note carefully=20 > that one guy's transport network (layer N say) is another=20 > guy's service....and what this means is that we have to=20 > create layer network N+1 (ie downwards) to carry the whole=20 > bit rate of the layer N network in the payload of the layer=20 > N+1 traffic unit....and so we end-up generating more and more=20 > layer networks towards the duct. This approach is not a sustainable. >=20 > - Too late for OTN....it did a me-too on the SDH/PDH way of doing > things. >=20 > Is that clear now? Hope so. >=20 > regards, Neil=20 > >=20 > > Thanks, > > Igor > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Tuesday, July 13, 2010 11:20 AM > > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; > > Jonathan.Sadler@tellabs.com > > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > >=20 > > Hi Igor......=20 > > who wrote 13 July 2010 15:59 > > > > > > Hi Neil, > > >=20 > > > You response confuses me a bit. Would you agree that=20 > there are only=20 > > > two possible ways to model OTN hierarchies: > > > a) a multi-layer construct with a distinct layer per > > hierarchy level > > > (this is my suggestion); > >=20 > > NH=3D> Yes, this is clean BUT I do have a problem with always = blindly=20 > > following the PDH and SDH models.....as each layer =3D cost and less = > > reliability....the key obsrevation being to always strive=20 > to minimise=20 > > the number of layers networks TOS to BOS. Ergo my remarks in my=20 > > original response below on the need to start thinking about=20 > a digital=20 > > wrapper approach at BOS....and I do know of one vendor who=20 > has started=20 > > to think about this point. > >=20 > > =20 > > > b) a single layer with several sub-layers (this is how I=20 > understand=20 > > > the ITU model). > >=20 > > NH=3D> Not a great idea IMO. > > >=20 > > > You seem to disagree with me, which means that you agree with the=20 > > > latter. > >=20 > > NH=3D> Now I am confused! The bit I was disagreeing with you=20 > on was the=20 > > reasons you suggested why a GMPLS CP for co-cs mode layer=20 > networks had=20 > > not really taken off. IMO this has nothing to do with technical=20 > > issues (at least per se) but rather the real cost of=20 > providing 'BW on=20 > > demand' > > to client X from server Y to meet a given GOS for a given set of=20 > > calling rate demands and holding times. I asked for this to be=20 > > modelled a long time ago at our labs (~10 years ago in > > fact) and the results stated what you have confirmed, ie=20 > there is no=20 > > commercial driver given the population size of current applications=20 > > that would demand this for a viable > > (acceptable) GOS....indeed, they are few/no external (to any > > network) applications today but simply client topology build cases,=20 > > and here there is no case at all IMO. > >=20 > > > But this position contradicts IMO with a lot of things you > > have said > > > in the context of MPLS-TP. On many occasions, for=20 > example, you have=20 > > > explained in great details how you hate the multi-sub-layering in=20 > > > MPLS, that there should be exactly one sub-layer per > > MPLS-TP layer, if > > > one is stacking MPLS-TP links, one is stacking MPLS-TP > > layers (rather > > > than sub-layers), that we shouldn't even need S-bit, > > etc.... Did I get > > > this right? If so, how come that the same logic does not > > apply to OTN > > > layering vs. OTN sub-layering? If anything, the logic=20 > should make a=20 > > > better sense for OTN due to its cs-co nature. > >=20 > > NH=3D> All I have said with sublayering in MPLS-TP, no need for PWs, = =20 > > etc still stands....they are just plainly obvious facts that anyone=20 > > can figure out. I think you have simply misunderstood what=20 > I wrote as=20 > > I have noted above. > > >=20 > > > Further more, my suggestion to introduce several OTN > > related switching > > > capabilities (specifically, 5: one per hierarchy > > > level) has to do with how CP views an OTN hierarchy, regardless=20 > > > whether its each level is a true layer, sub-layer or > > something else.=20 > > > You can think of this as a suggestion for CP to control=20 > various OTN=20 > > > virtual topologies. This would give an operator an easy way to=20 > > > constrain a given connection, say, to use only OTUs and=20 > avoid using=20 > > > any ODU containers, or, on the contrary, to avoid using > > OTUs and use > > > ODU containers, preferably smaller before larger ones. You > > can argue > > > with the usefulness of such feature, but you can hardly > > argue with the > > > fact that it takes nothing away from the current framework: > > > the user can always constrain the connection path to *any* of the=20 > > > hierarchy levels, and in this case all OTN links will be > > considered as > > > equal candidates in the path selection process. > > >=20 > > > What do you think? > >=20 > > NH=3D> I think the replication of the PDH/SDH hierarchy in OTN was a = > > mistake...for the reasons I gave above. > >=20 > > regards, Neil > >=20 > >=20 > > I am also interested to hear from the > > > authors of "multi stage multiplexing configuration in G.709 > > network"=20 > > > documents. > > >=20 > > > Cheers, > > > Igor > > >=20 > > > -----Original Message----- > > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > Sent: Friday, July 09, 2010 10:27 AM > > > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; > > > Jonathan.Sadler@tellabs.com > > > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > >=20 > > > Some observations in-line:=20 > > >=20 > > > Igor Bryskin wrote 09 July 2010 13:59 > > > >=20 > > > > Sergio, > > > >=20 > > > > You wrote: > > > >=20 > > > > " My understanding of Switching Cap is that different > > Switching Cap > > > > would be linked to different technologies imply different > > switching > > > > capabilities > > > >=20 > > > > IB>> We do have PSC1-PSC4 for packet switching ( note, one > > > > per MPLS DP hierarchy level, > > >=20 > > > NH=3D> Do you really mean client/server here (as this is the > > only proper > > > hierarchy case)? I query you on this because right now > > there is a DP > > > problem in MPLS-TP that is being consciously ignored wrt the=20 > > > implications of the unnecessary carry-over of PWs and > > sublayering into > > > MPL-TP. And one of the problems (its not the only one) is the=20 > > > potential for misconnectivity between MPLS layers, MPLS > > sublayers and > > > PW layers when the LSP for each of these looks the same=20 > in the DP. =20 > > > Not only must we have a common method of (OAM) detection > > but this must > > > contain a proper SA of the layer network (or sublayers) in > > order for > > > quick/correct diagnosis of offending source. > > >=20 > > >=20 > > > > I suggest the same for OTN).=20 > > >=20 > > > NH=3D> It's not a great idea to always blindly replicate the > > artificial > > > hierarchies that past co-cs mode technologies (like PDH and > > > SDH) created > > > in the future. The PDH hierarchy simply reflected the=20 > maturity of=20 > > > silicon technology at the time. SDH replicated this with > > an increased > > > step size and removed the async 'mux mountain' problem. =20 > > However, the > > > simple commercial reason for not replicating this fixed hierarchy=20 > > > structure is that each layer network represents a set of DP/CP/MP=20 > > > functions and stuff to configure/operate/etc...these are > > all costs and > > > things that can fail, ie more layers =3D less reliable. What > > we really > > > need here is to minimise the number of layer networks between the=20 > > > (external application interfacing) TOS layer network and > > the (EM wave > > > modulating) BOS layer network. In other words, the future > > transport > > > network should be migrating to a digital wrapper approach with no=20 > > > fixed hierarchy IMO. > > >=20 > > >=20 > > > > We > > > > have also agreed that a single L2SC is not enough for Ethernet=20 > > > > technology, in fact, we need separate swicthcaps for STAG > > switching, > > > > EPL, EVPL, etc. > > > >=20 > > > > " : we have not created different Switching Cap for VC4 or > > > > VC12 in SDH".=20 > > > >=20 > > > > IB>> IMO this is the reason why GMPLS in TDM has never really > > > > taken off. > > >=20 > > > NH=3D> I don't agree with this. Though I would separate > > signalling from > > > routing functions here....and wrt to latter distributed vs > > centralised > > > cases. Real BOS transport networks must currently have very long=20 > > > information transfer phases (set-up and tear-down phases > > are very much > > > smaller). So the CP components are nowhere near as > > important as the > > > MP components...esp as the MP components have to be there > > anyway. So > > > this is why IMO GMPLS has probably not been as successful as some=20 > > > hoped it would be. > > >=20 > > > BTW - If one looks at the business case for trying to=20 > more rapidly=20 > > > set-up/tear-down BOS layer network connections you quickly > > find that > > > the commercials do not figure for a useful GOS.....at least > > in today's > > > environment. I got the traffic/maths group at BT labs to look at=20 > > > analysing this topic many years ago in a very general sense > > (ie very > > > general calling/holding statistics). Though I must add here that=20 > > > today we do not have the truly massive external end-system > > application > > > numbers we would need nor do we have the short-enough > > holding times to > > > warrant a switched services case, eg like the PSTN say. =20 > If we had=20 > > > this however then would drive the GMPLS CP case. > > >=20 > > > regards, Neil > > >=20 > > > > > >=20 > >=20 >=20 From IBryskin@advaoptical.com Tue Jul 13 09:45:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A753A6A70 for ; Tue, 13 Jul 2010 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Fag4XyGeN3 for ; Tue, 13 Jul 2010 09:45:43 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id ED45C3A6A96 for ; Tue, 13 Jul 2010 09:45:42 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6DGjlG3012739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 13 Jul 2010 18:45:47 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 13 Jul 2010 18:45:47 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 13 Jul 2010 18:45:46 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 13 Jul 2010 12:45:44 -0400 From: Igor Bryskin To: "neil.2.harrison@bt.com" , "sergio.belotti@alcatel-lucent.com" , "Jonathan.Sadler@tellabs.com" Date: Tue, 13 Jul 2010 12:45:42 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsePXhRhVrxuUFSTmqVlNzMUPhuzgAcJKzAAANHLbAAAv+eEAAAqg0wAACHrSAAACEgUAAd9sdAAAg3zoAAAgkRYADKKGTgAAGPwGAAALpQEAAAz1JAAAEUDiAAAI/88AAAQziA Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1EA07@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E9F4@atl-srv-exgen.atl.advaoptical.com> <2ECAA42C79676B42AEBAC11229CA7D0C060F94ED@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C060F94ED@E03MVB2-UKBR.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-13_02:2010-02-06, 2010-07-13, 2010-07-13 signatures=0 Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , "SBardalai@infinera.com" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:45:45 -0000 Thank you. I take it that under circumstances you kind of agree with me. I would want very much to talk to you in person. Any chance you could come = to Maastricht? Thanks for the very interesting discussion. Cheers, Igor -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Tuesday, July 13, 2010 12:34 PM To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; Jonathan.Sadler@tellab= s.com Cc: ccamp@ietf.org; SBardalai@infinera.com; draft-ietf-ccamp-gmpls-g709-fra= mework@tools.ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Given OTN as-is, my view is 1. BTW 4 will not work for OTN as-is...we would need a new approach. regards, Neil=20 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 > Sent: 13 July 2010 17:28 > To: Harrison,N,Neil,DKQ7 R;=20 > sergio.belotti@alcatel-lucent.com; Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > No Neil, it is not clear, because you didn't answer my=20 > question which is: >=20 > If you and Y.800 folks model OTN today what in your opinion=20 > would be a correct model: > 1) multi-layer with no sub-layering; > 2) single layer with sub-layers; > 3) single layer with no sub-layers; > 4) something else, e.g. you mentioned digital wrapper approach >=20 > Can you give me a short answer: 1, 2, 3 or 4? >=20 > If 4, can you elaborate how this will work for OTN. >=20 > Thanks, > Igor >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, July 13, 2010 12:01 PM > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com;=20 > Jonathan.Sadler@tellabs.com > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt >=20 > Hi Igor..=20 > 13 July 2010 16:34 > =20 > > Neil, > >=20 > > > a) a multi-layer construct with a distinct layer per > > hierarchy level > > > (this is my suggestion); > > > b) a single layer with several sub-layers (this is how I=20 > understand=20 > > > the ITU model). > >=20 > > You are saying that a) is clean but wasteful and b) is not a good=20 > > idea, So what is in your opinion a good model? Is it: > >=20 > > c) a single layer and no sub-layers? > > But how OTN hierarchy fits in? >=20 > NH=3D> I'm not sure you have followed what I said...so let me=20 > very briefly recap one last time: >=20 > - I very much believe each layer network should be a self > contained instance in the general case....this includes a=20 > routing component for that (and only that) layer network >=20 > - I believe sublayering is not required in a transport network > (and I'd also add to the 'not required' the somewhat even=20 > more artificial case of TCM OAM here - noting carefully that=20 > there is no technical necessity for E-NNIs in non-TOS layer=20 > networks, so this is no justification for TCM at all) >=20 > - the old PDH hierarchy came from silicon technology > break-points.....SDH replicated this basic idea. =20 >=20 > - we always must have TOS and BOS layer networks present in all > networks cases, and to minimise cost and maximise reliability=20 > we should reduce to the minimum any additional layers=20 > networks between the TOS and BOS extremes. So just blindly=20 > carrying on replicating what happened in PDH/SDH is not a=20 > great idea....need to think out of the box a bit....ergo the=20 > digital wrapper approach is good idea. BTW Note carefully=20 > that one guy's transport network (layer N say) is another=20 > guy's service....and what this means is that we have to=20 > create layer network N+1 (ie downwards) to carry the whole=20 > bit rate of the layer N network in the payload of the layer=20 > N+1 traffic unit....and so we end-up generating more and more=20 > layer networks towards the duct. This approach is not a sustainable. >=20 > - Too late for OTN....it did a me-too on the SDH/PDH way of doing > things. >=20 > Is that clear now? Hope so. >=20 > regards, Neil=20 > >=20 > > Thanks, > > Igor > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Tuesday, July 13, 2010 11:20 AM > > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; > > Jonathan.Sadler@tellabs.com > > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > >=20 > > Hi Igor......=20 > > who wrote 13 July 2010 15:59 > > > > > > Hi Neil, > > >=20 > > > You response confuses me a bit. Would you agree that=20 > there are only=20 > > > two possible ways to model OTN hierarchies: > > > a) a multi-layer construct with a distinct layer per > > hierarchy level > > > (this is my suggestion); > >=20 > > NH=3D> Yes, this is clean BUT I do have a problem with always blindly=20 > > following the PDH and SDH models.....as each layer =3D cost and less=20 > > reliability....the key obsrevation being to always strive=20 > to minimise=20 > > the number of layers networks TOS to BOS. Ergo my remarks in my=20 > > original response below on the need to start thinking about=20 > a digital=20 > > wrapper approach at BOS....and I do know of one vendor who=20 > has started=20 > > to think about this point. > >=20 > > =20 > > > b) a single layer with several sub-layers (this is how I=20 > understand=20 > > > the ITU model). > >=20 > > NH=3D> Not a great idea IMO. > > >=20 > > > You seem to disagree with me, which means that you agree with the=20 > > > latter. > >=20 > > NH=3D> Now I am confused! The bit I was disagreeing with you=20 > on was the=20 > > reasons you suggested why a GMPLS CP for co-cs mode layer=20 > networks had=20 > > not really taken off. IMO this has nothing to do with technical=20 > > issues (at least per se) but rather the real cost of=20 > providing 'BW on=20 > > demand' > > to client X from server Y to meet a given GOS for a given set of=20 > > calling rate demands and holding times. I asked for this to be=20 > > modelled a long time ago at our labs (~10 years ago in > > fact) and the results stated what you have confirmed, ie=20 > there is no=20 > > commercial driver given the population size of current applications=20 > > that would demand this for a viable > > (acceptable) GOS....indeed, they are few/no external (to any > > network) applications today but simply client topology build cases,=20 > > and here there is no case at all IMO. > >=20 > > > But this position contradicts IMO with a lot of things you > > have said > > > in the context of MPLS-TP. On many occasions, for=20 > example, you have=20 > > > explained in great details how you hate the multi-sub-layering in=20 > > > MPLS, that there should be exactly one sub-layer per > > MPLS-TP layer, if > > > one is stacking MPLS-TP links, one is stacking MPLS-TP > > layers (rather > > > than sub-layers), that we shouldn't even need S-bit, > > etc.... Did I get > > > this right? If so, how come that the same logic does not > > apply to OTN > > > layering vs. OTN sub-layering? If anything, the logic=20 > should make a=20 > > > better sense for OTN due to its cs-co nature. > >=20 > > NH=3D> All I have said with sublayering in MPLS-TP, no need for PWs, =20 > > etc still stands....they are just plainly obvious facts that anyone=20 > > can figure out. I think you have simply misunderstood what=20 > I wrote as=20 > > I have noted above. > > >=20 > > > Further more, my suggestion to introduce several OTN > > related switching > > > capabilities (specifically, 5: one per hierarchy > > > level) has to do with how CP views an OTN hierarchy, regardless=20 > > > whether its each level is a true layer, sub-layer or > > something else.=20 > > > You can think of this as a suggestion for CP to control=20 > various OTN=20 > > > virtual topologies. This would give an operator an easy way to=20 > > > constrain a given connection, say, to use only OTUs and=20 > avoid using=20 > > > any ODU containers, or, on the contrary, to avoid using > > OTUs and use > > > ODU containers, preferably smaller before larger ones. You > > can argue > > > with the usefulness of such feature, but you can hardly > > argue with the > > > fact that it takes nothing away from the current framework: > > > the user can always constrain the connection path to *any* of the=20 > > > hierarchy levels, and in this case all OTN links will be > > considered as > > > equal candidates in the path selection process. > > >=20 > > > What do you think? > >=20 > > NH=3D> I think the replication of the PDH/SDH hierarchy in OTN was a=20 > > mistake...for the reasons I gave above. > >=20 > > regards, Neil > >=20 > >=20 > > I am also interested to hear from the > > > authors of "multi stage multiplexing configuration in G.709 > > network"=20 > > > documents. > > >=20 > > > Cheers, > > > Igor > > >=20 > > > -----Original Message----- > > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > Sent: Friday, July 09, 2010 10:27 AM > > > To: Igor Bryskin; sergio.belotti@alcatel-lucent.com; > > > Jonathan.Sadler@tellabs.com > > > Cc: ccamp@ietf.org; SBardalai@infinera.com;=20 > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > >=20 > > > Some observations in-line:=20 > > >=20 > > > Igor Bryskin wrote 09 July 2010 13:59 > > > >=20 > > > > Sergio, > > > >=20 > > > > You wrote: > > > >=20 > > > > " My understanding of Switching Cap is that different > > Switching Cap > > > > would be linked to different technologies imply different > > switching > > > > capabilities > > > >=20 > > > > IB>> We do have PSC1-PSC4 for packet switching ( note, one > > > > per MPLS DP hierarchy level, > > >=20 > > > NH=3D> Do you really mean client/server here (as this is the > > only proper > > > hierarchy case)? I query you on this because right now > > there is a DP > > > problem in MPLS-TP that is being consciously ignored wrt the=20 > > > implications of the unnecessary carry-over of PWs and > > sublayering into > > > MPL-TP. And one of the problems (its not the only one) is the=20 > > > potential for misconnectivity between MPLS layers, MPLS > > sublayers and > > > PW layers when the LSP for each of these looks the same=20 > in the DP. =20 > > > Not only must we have a common method of (OAM) detection > > but this must > > > contain a proper SA of the layer network (or sublayers) in > > order for > > > quick/correct diagnosis of offending source. > > >=20 > > >=20 > > > > I suggest the same for OTN).=20 > > >=20 > > > NH=3D> It's not a great idea to always blindly replicate the > > artificial > > > hierarchies that past co-cs mode technologies (like PDH and > > > SDH) created > > > in the future. The PDH hierarchy simply reflected the=20 > maturity of=20 > > > silicon technology at the time. SDH replicated this with > > an increased > > > step size and removed the async 'mux mountain' problem. =20 > > However, the > > > simple commercial reason for not replicating this fixed hierarchy=20 > > > structure is that each layer network represents a set of DP/CP/MP=20 > > > functions and stuff to configure/operate/etc...these are > > all costs and > > > things that can fail, ie more layers =3D less reliable. What > > we really > > > need here is to minimise the number of layer networks between the=20 > > > (external application interfacing) TOS layer network and > > the (EM wave > > > modulating) BOS layer network. In other words, the future > > transport > > > network should be migrating to a digital wrapper approach with no=20 > > > fixed hierarchy IMO. > > >=20 > > >=20 > > > > We > > > > have also agreed that a single L2SC is not enough for Ethernet=20 > > > > technology, in fact, we need separate swicthcaps for STAG > > switching, > > > > EPL, EVPL, etc. > > > >=20 > > > > " : we have not created different Switching Cap for VC4 or > > > > VC12 in SDH".=20 > > > >=20 > > > > IB>> IMO this is the reason why GMPLS in TDM has never really > > > > taken off. > > >=20 > > > NH=3D> I don't agree with this. Though I would separate > > signalling from > > > routing functions here....and wrt to latter distributed vs > > centralised > > > cases. Real BOS transport networks must currently have very long=20 > > > information transfer phases (set-up and tear-down phases > > are very much > > > smaller). So the CP components are nowhere near as > > important as the > > > MP components...esp as the MP components have to be there > > anyway. So > > > this is why IMO GMPLS has probably not been as successful as some=20 > > > hoped it would be. > > >=20 > > > BTW - If one looks at the business case for trying to=20 > more rapidly=20 > > > set-up/tear-down BOS layer network connections you quickly > > find that > > > the commercials do not figure for a useful GOS.....at least > > in today's > > > environment. I got the traffic/maths group at BT labs to look at=20 > > > analysing this topic many years ago in a very general sense > > (ie very > > > general calling/holding statistics). Though I must add here that=20 > > > today we do not have the truly massive external end-system > > application > > > numbers we would need nor do we have the short-enough > > holding times to > > > warrant a switched services case, eg like the PSTN say. =20 > If we had=20 > > > this however then would drive the GMPLS CP case. > > >=20 > > > regards, Neil > > >=20 > > > > > >=20 > >=20 >=20 From curtis@occnc.com Tue Jul 13 15:23:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61553A6833 for ; Tue, 13 Jul 2010 15:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzRyh40XUgpC for ; Tue, 13 Jul 2010 15:23:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 246D83A67D1 for ; Tue, 13 Jul 2010 15:23:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6DMNXRc018986; Tue, 13 Jul 2010 18:23:34 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> Date: Tue, 13 Jul 2010 18:23:33 -0400 Sender: curtis@occnc.com Cc: "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:23:39 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > I think OTN links require more than one switchcaps: as many as the depth of the deepest possible OTN DP hierarchy, for example: > > typedef enum > { > LSPSwitchType_Unknown =0 /* Unknown */ > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > , LSPSwitchType_L2SC =50 /* L2SC */ > , LSPSwitchType_TDM =100 /* TDM */ > > /*****/ > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =150 /* LSC */ > , LSPSwitchType_FSC =200 /* FSC */ > }e_LSPSwitchType; It would be better IMHO to keep the Switch Type as TDM and make the Encoding Type OTN_LO, OTN_HO or OTN_SHO. This would replace the 20006 OTN Encoding Type for G.709 Digital Path layer and G.709 Optical Channel layer for 2009 OTN, which had in turn replaced the Encoding Type of "Digital Wrapper" a long time ago. Replacing the Encoding Type would insure that any LSR that did not understand what the TS type meant did not try to multiplex its LO ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to using a 1.25 TS granularity for another LO ODU. It could also be stated that if an LSR advertises OTN_LO, OTN_HO or OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter is for backward compatibility and should be ignored if OTN_LO, OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, then the corresponding G.709 Digital Path FA can be withdrawn. The Encoding type would be the lower encoding at each end of the LSP regardless of what goes on in the middle since that determines what can be wrapped inside it. For example: OTU3 OTU2 ODUk=3 -------------- OTU1 ODUk=2 -- ODUj=2 ODUk=1 --- ODUj=1 -- This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even though the ODUk=2 at the next hop could not directly contain an ODU0. If the SHO Encoding Type is used, then it indicates that two levels of multiplexing could be supported at that switch/LSR. The nominal bytes/sec rates can still be provided. RFC 4328 Switch Types currently don't include an ODUj or ODUk distinction but if Encoding Type indicated LO or HO, that may not be needed. Along with the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, and ODU2e, can be added. btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear how in an FA it can be indicated that either type is currently available (NE capable of both and hasn't committed to either one yet). BTW- Maybe I'm missing something but the number of messages on this would indicate a huge controversy and I'm not getting it (other than a strong preference to rely on bytes/sec or on enumerated type fields). draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other intent. Could someone (either draft) concisely summarize the multiplexing restrictions in one place, including restrictions on number of multiplexing layers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > What do you mean by "different switchcaps"? > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not clear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN specific > > ISCD. The combination of Switching Capability and Encoding type of RFC4202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM networks, > > you know the resource is allocated based on TS, so the available TS should > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I think > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will find > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > > you have to advertise a new TE link or put this FA as a component link of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service routing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the OTU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over the > > >> ODU2). So it is obvious from this example that the number of time-slots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number of > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is that > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From curtis@occnc.com Tue Jul 13 17:52:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17B33A6847 for ; Tue, 13 Jul 2010 17:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tfp6KJobKVK for ; Tue, 13 Jul 2010 17:52:53 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id C1D863A6822 for ; Tue, 13 Jul 2010 17:52:52 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6E0r0To020598; Tue, 13 Jul 2010 20:53:00 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007140053.o6E0r0To020598@harbor.orleans.occnc.com> To: "BRUNGARD, DEBORAH A (ATTLABS)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Jul 2010 12:40:15 EDT." Date: Tue, 13 Jul 2010 20:53:00 -0400 Sender: curtis@occnc.com Cc: CCAMP Subject: Re: [CCAMP] FW: Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 00:52:54 -0000 In message "BRUNGARD, DEBORAH A (ATTLABS)" writes: > > This WG Last Call will be extended to be a joint last call of the ccamp, > pwe3, and mpls wgs and the end date extended to July 26th. > > Thanks, > CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs This statement in draft-ietf-ccamp-mpls-tp-cp-framework-02.txt 94. Per-packet equal cost multi-path (ECMP) load balancing is not applicable to MPLS-TP [TP-DATA-PLANE , section 3.1.1., paragraph 6]. is in conflict with the cited statement in TP-DATA-PLANE. Per-packet Equal-Cost Multi-Path (ECMP) load-balancing is outside the scope of the MPLS-TP. Out of scope and not applicable are two different things. Out of scope is more accurate and cp-framework needs to reflect this. Curtis btw - does this get removed later? 102. Requirement intentionally blank. From IBryskin@advaoptical.com Wed Jul 14 07:36:57 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4FD3A67E2 for ; Wed, 14 Jul 2010 07:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk2jIAIhQbea for ; Wed, 14 Jul 2010 07:36:56 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id B3CF23A68A0 for ; Wed, 14 Jul 2010 07:36:55 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6EEaqE0021425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 14 Jul 2010 16:36:52 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 14 Jul 2010 16:36:53 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 14 Jul 2010 10:36:50 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Wed, 14 Jul 2010 10:36:34 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsi2hODoD/8GwDWS8StbgR22lt2BwAgm/4A Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> In-Reply-To: <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-14_03:2010-02-06, 2010-07-14, 2010-07-13 signatures=0 Cc: "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 14:36:57 -0000 Curtis, Thanks for your comment. I agree that there should be multiple OTN specific encoding types introduce= d. But IMO they should indicate the link's mux capabilities rather than the= link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link= 's role or roles IMO should be indicated with a separate switchcaps. I can = give you several reasons: 1. Links with the same mux capabilities may have different roles; 2. Link may advertise several roles (e.g. HO and SHO) with different mux.ca= pabilities per role; 3. Link's role and mux. capabilities can be advertised with ISCDs as define= d in RFC4202 (no OTN-style ISCD is required); 4. The combination of swicthcaps and encoding type will look to CP as a sep= arate layer, which is exactly how ITU models OTN hierarchies in all aspects= but routing (!?) 5. If the operator would want to constrain the routing of OTN connections t= o pre-configured topology with a specific role (e.g. constrain all ODUs it = sells to the clients to one or more pre-configured LO topologies), this wou= ld be possible to do in a technology independent way. Suppose an instance o= f GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links= will be no different from the separation of WDM links from OTUs. Cheers, Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Tuesday, July 13, 2010 6:24 PM To: Igor Bryskin Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org= ; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t=20 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > =20 > I think OTN links require more than one switchcaps: as many as the depth = of the deepest possible OTN DP hierarchy, for example: > =20 > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ > =20 > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; It would be better IMHO to keep the Switch Type as TDM and make the Encoding Type OTN_LO, OTN_HO or OTN_SHO. This would replace the 20006 OTN Encoding Type for G.709 Digital Path layer and G.709 Optical Channel layer for 2009 OTN, which had in turn replaced the Encoding Type of "Digital Wrapper" a long time ago. Replacing the Encoding Type would insure that any LSR that did not understand what the TS type meant did not try to multiplex its LO ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to using a 1.25 TS granularity for another LO ODU. It could also be stated that if an LSR advertises OTN_LO, OTN_HO or OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter is for backward compatibility and should be ignored if OTN_LO, OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, then the corresponding G.709 Digital Path FA can be withdrawn. The Encoding type would be the lower encoding at each end of the LSP regardless of what goes on in the middle since that determines what can be wrapped inside it. For example: OTU3 OTU2 ODUk=3D3 -------------- OTU1 ODUk=3D2 -- ODUj=3D2 ODUk=3D1 --- ODUj=3D1 -- This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex even though the ODUk=3D2 at the next hop could not directly contain an ODU0. If the SHO Encoding Type is used, then it indicates that two levels of multiplexing could be supported at that switch/LSR. The nominal bytes/sec rates can still be provided. RFC 4328 Switch Types currently don't include an ODUj or ODUk distinction but if Encoding Type indicated LO or HO, that may not be needed. Along with the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, and ODU2e, can be added. btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear how in an FA it can be indicated that either type is currently available (NE capable of both and hasn't committed to either one yet). BTW- Maybe I'm missing something but the number of messages on this would indicate a huge controversy and I'm not getting it (other than a strong preference to rely on bytes/sec or on enumerated type fields). draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other intent. Could someone (either draft) concisely summarize the multiplexing restrictions in one place, including restrictions on number of multiplexing layers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > =20 > What do you mean by "different switchcaps"? > =20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > >=20 > > Snigdho, > >=20 > >=20 > >=20 > >=20 > >=20 > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not cl= ear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > >=20 > >=20 > >=20 > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, a= nd > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN specif= ic > > ISCD. The combination of Switching Capability and Encoding type of RFC4= 202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > >=20 > >=20 > >=20 > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order container= s. > > This is simply >blowing up the solution to a very simple problem. > >=20 > >=20 > >=20 > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > >=20 > >=20 > >=20 > > Cheers, > >=20 > > Igor > >=20 > >=20 > >=20 > > Regards > >=20 > > Snigdho > >=20 > >=20 > >=20 > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > >=20 > >=20 > >=20 > > Hi Snigdho and Lou, > >=20 > >=20 > >=20 > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > >=20 > >=20 > >=20 > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM networ= ks, > > you know the resource is allocated based on TS, so the available TS sho= uld > > be get or induced before creating cross-connect. > >=20 > >=20 > >=20 > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > >=20 > >=20 > >=20 > > If you look at the routing drafts (info model and encoding), you will f= ind > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > >=20 > >=20 > >=20 > > One more thing for your first comment: > >=20 > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU= 1, > > you have to advertise a new TE link or put this FA as a component link = of > > an existing TE link (like RFC4206bis). > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Best Regards > >=20 > > Fatai > >=20 > >=20 > > ----- Original Message ----- > >=20 > > From: "Snigdho Bardalai" > > > >=20 > > To: "Lou Berger" > > >=20 > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > >=20 > > Sent: Wednesday, July 07, 2010 11:43 PM > >=20 > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > >=20 > >=20 > >=20 > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one = of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service rout= ing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider = an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the O= TU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over t= he > > >> ODU2). So it is obvious from this example that the number of time-sl= ots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is th= at > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > =20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > =20 > =20 From daniel@olddog.co.uk Wed Jul 14 08:41:06 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDD63A6B83 for ; Wed, 14 Jul 2010 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqXXAMGtk5sl for ; Wed, 14 Jul 2010 08:41:03 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id E96AB3A6B73 for ; Wed, 14 Jul 2010 08:41:02 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o6EFf8ra025313; Wed, 14 Jul 2010 16:41:08 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o6EFf6og025291; Wed, 14 Jul 2010 16:41:06 +0100 From: "Daniel King" To: Date: Wed, 14 Jul 2010 16:41:09 +0100 Message-ID: <000b01cb236a$fb96a310$f2c3e930$@co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CB2373.5D5B0B10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsjavrrW9usU9i1RYOUK43RZGdwvA== Content-Language: en-gb Subject: [CCAMP] Draft CCAMP Agenda for IETF 78 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:41:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01CB2373.5D5B0B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi CCAMP'rs, Please find our draft agenda for both CCAMP sessions at IETF 78. http://www.ietf.org/proceedings/78/agenda/ccamp.html We have a very tight schedule. If your presenting, please review your slot to confirm you are on the agenda. If you have a question or issue, please email the chairs and myself. Please also send me (CC'ing the chairs) your slides no later than Friday, 23rd July. Br, Dan. ------=_NextPart_000_000C_01CB2373.5D5B0B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi CCAMP’rs,

 

Please find our draft agenda for both CCAMP = sessions at IETF 78.

 

http://www.= ietf.org/proceedings/78/agenda/ccamp.html

 

We have a very tight schedule. If your presenting, = please review your slot to confirm you are on the agenda. If you have a question or = issue, please email the chairs and myself. Please also send me (CC’ing the = chairs) your slides no later than Friday, 23rd July.

 

Br, Dan.

------=_NextPart_000_000C_01CB2373.5D5B0B10-- From lberger@labn.net Wed Jul 14 12:25:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667EB3A680F for ; Wed, 14 Jul 2010 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_20=-0.74, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsAVSDBH91JN for ; Wed, 14 Jul 2010 12:25:54 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 209483A67D9 for ; Wed, 14 Jul 2010 12:25:54 -0700 (PDT) Received: (qmail 15471 invoked by uid 0); 14 Jul 2010 19:26:04 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 14 Jul 2010 19:26:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Fxl7Lej07v2mwbt4CKr/xJLoYDcms+2EcwFLYMjoYwizMxfN9TD6r5iF+0chpV6GqW6X+C88DQg9Db1q2rAlz3QkvI3A1CauLKF3RxrQ5d+CBMi4aldjt9QqoaS27p5/; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OZ7al-00018b-Q0 for ccamp@ietf.org; Wed, 14 Jul 2010 13:26:03 -0600 Message-ID: <4C3E0F4D.3020902@labn.net> Date: Wed, 14 Jul 2010 15:26:05 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Draft response to OIF letter regarding Interface Identifier dated May 21 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 19:25:55 -0000 All, The enclosed is a proposed response to a letter received from the OIF. Please send any comments you have by July 21. Thank you, Deborah and Lou ------------------------- To: "Kimberly Chiu" Cc: "'Ong, Lyndon'" , ccamp@ietf.org Subject: Response to OIF letter regarding Interface Identifier Dear Mr. Ong, Thank you for your letter regarding Interface Identifier dated May 21, 2010. The letter referenced several RFCs only some of which are products of the CCAMP working group. (RFC4202 and RFC4631 are products of CCAMP, while RFC3477, RFC3811, RFC4220 are products of MPLS.) In the letter you ask about the range of values allowed for an unnumbered link identifier. RFC 4202 (and RFC 3477) define an unnumbered link being identified by a "non-zero 32-bit number that is unique within the scope of the LSR". RFC4203 and RFC4205 contain parallel language. These documents therefore allow an implementation to select any value that can be represented in 32 bits other than zero. You note in your letter that "The RFC MIBs appear to imply that the range is restricted to a maximum value of 2147483647." This observation is further supported by the InterfaceIndex and InterfaceIndexOrZero textual convention defined in RFC 2863, both of which have a maximum value of 2147483647. Based on the above as well as the other MIBs you reference in your letter, it seems reasonable that an implementation will select values that can be fully represented in all MIBs that the implementation may support, i.e., up to 2147483647. That said, the choice of an unnumbered link identifier remains completely within the scope of an implementation and an implementation may choose to select larger values. Regards, Deborah Brungard and Lou Berger IETF CCAMP Working Group Co-Chairs From curtis@occnc.com Wed Jul 14 15:58:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B9A3A6979 for ; Wed, 14 Jul 2010 15:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sag7YbJBYyli for ; Wed, 14 Jul 2010 15:58:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id A72833A68A7 for ; Wed, 14 Jul 2010 15:58:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6EMw9KJ051582; Wed, 14 Jul 2010 18:58:09 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007142258.o6EMw9KJ051582@harbor.orleans.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Wed, 14 Jul 2010 15:26:05 EDT." <4C3E0F4D.3020902@labn.net> Date: Wed, 14 Jul 2010 18:58:09 -0400 Sender: curtis@occnc.com Cc: CCAMP WG Subject: Re: [CCAMP] Draft response to OIF letter regarding Interface Identifier dated May 21 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:58:01 -0000 In message <4C3E0F4D.3020902@labn.net> Lou Berger writes: > > All, > The enclosed is a proposed response to a letter received from the OIF. > Please send any comments you have by July 21. > > Thank you, > Deborah and Lou > > ------------------------- > To: "Kimberly Chiu" > Cc: "'Ong, Lyndon'" , > ccamp@ietf.org > Subject: Response to OIF letter regarding Interface Identifier > > Dear Mr. Ong, > > Thank you for your letter regarding Interface Identifier dated May > 21, 2010. The letter referenced several RFCs only some of which are > products of the CCAMP working group. (RFC4202 and RFC4631 are products > of CCAMP, while RFC3477, RFC3811, RFC4220 are products of MPLS.) > > In the letter you ask about the range of values allowed for an > unnumbered link identifier. RFC 4202 (and RFC 3477) define an > unnumbered link being identified by a "non-zero 32-bit number that is > unique within the scope of the LSR". RFC4203 and RFC4205 contain > parallel language. These documents therefore allow an implementation to > select any value that can be represented in 32 bits other than zero. > > You note in your letter that "The RFC MIBs appear to imply that the > range is restricted to a maximum value of 2147483647." This observation > is further supported by the InterfaceIndex and InterfaceIndexOrZero > textual convention defined in RFC 2863, both of which have a maximum > value of 2147483647. > > Based on the above as well as the other MIBs you reference in your > letter, it seems reasonable that an implementation will select values > that can be fully represented in all MIBs that the implementation may > support, i.e., up to 2147483647. That said, the choice of an unnumbered > link identifier remains completely within the scope of an implementation > and an implementation may choose to select larger values. > > Regards, > Deborah Brungard and Lou Berger > IETF CCAMP Working Group Co-Chairs > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp Seems fine. 2147483647 is just 2^31 - 1 so someone seems to have assumed that the ifindex is a signed 32 bit number. Also note that all ones is reserved in Link Bundling. You may want to point that out. Curtis From zhangfatai@huawei.com Wed Jul 14 18:52:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE9B3A6830 for ; Wed, 14 Jul 2010 18:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZGXRrYLO-09 for ; Wed, 14 Jul 2010 18:52:27 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C733A3A6822 for ; Wed, 14 Jul 2010 18:52:21 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5K00DNLT7J8F@szxga05-in.huawei.com> for ccamp@ietf.org; Thu, 15 Jul 2010 09:52:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5K00IXFT7H8N@szxga05-in.huawei.com> for ccamp@ietf.org; Thu, 15 Jul 2010 09:52:29 +0800 (CST) Received: from Z41162C ([10.70.76.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5K00BMMT7GHY@szxml06-in.huawei.com> for ccamp@ietf.org; Thu, 15 Jul 2010 09:52:29 +0800 (CST) Date: Thu, 15 Jul 2010 09:52:28 +0800 From: Fatai Zhang To: Igor Bryskin , curtis@occnc.com Message-id: <084e01cb23c0$61b58490$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com> Cc: ccamp@ietf.org, Snigdho Bardalai , draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 01:52:28 -0000 SGkgSWdvciBhbmQgYWxsLA0KDQpUaGFua3MgZm9yIGFsbCB5b3VyIGNvbW1lbnRzLg0KDQpJIHRo aW5rIHJvbGUgZG9lcyBub3QgZXF1YWwgc3dpdGNoaW5nIGNhcGFiaWxpdHkuIFRoZSBvcGVyYXRv cnMgY2FuIGRlZmluZSBkaWZmZXJlbnQgcm9sZXMgZGVwZW5kaW5nIG9uIHRoZWlyIHBvbGljeSBh bmQgYWNoaWV2ZSB0aGUgcm9sZSB0aHJvdWdoIGRpZmZlcmVudCBtZXRob2RzLiBIb3dldmVyLCBm b3IgT1ROIG5ldHdvcmtzLCB0aGUgY29udGFpbmVycyAoZS5nLiwgT0RVaykgYWxsIGhhdmUgdGhl IHNhbWUgc3dpdGNoaW5nIGNhcGFibGlsaXR5IChpLmUuLCBURE0gc3dpdGNoaW5nKSBhbmQgSSB0 aGluayB3ZSBzaG91bGQgcmVmbGVjdCB0aGUgbmF0dXJhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgbGlu a3MgaW4gdGhlIHJvdXRpbmcuIEluIGFkZGl0aW9uLCBpZiB3ZSBleHRlbmQgdGhlIElTQywgaXQg d2lsbCBtYWtlIHRoZSBlbmNvZGluZyB0eXBlIGxvc2UgaXRzJyBvd24gbWVhbmluZyhpZS4sIElT QyBvdmVycmlkZXMgZW5jb2RpbmcgdHlwZSkuDQoNCkFjY29yZGluZyB0byB0aGUgcG9pbnQgMywg SSBkb24ndCBrbm93IGhvdyB0byBhZHZlcnRpc2UgdGhlIHJvbGVzIGFuZCBtdXhpbmcgY2FwYWJp bGl0aWVzIHdpdGggdGhlIElTQ0Qgb2YgUkZDNDIwMiwgY291bGQgeW91IGNsYXJpZnk/DQoNCklu IGFkZGl0aW9uLCBjb3VsZCB5b3UgY2xhcmlmeSBteSBxdWVzdGlvbnMgaW4gYW5vdGhlciBlbWFp bCAoY29waWVkIGFzIGZvbGxvd3MpOg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KRm9yICBMbyBPRFUsIEhvIE9EVSwgU0hPIE9EVSwgdGhleSBhcmUgcmVsYXRp dmUgdG8gZWFjaCBvdGhlci4gRm9yIGV4YW1wbGUsIE9EVTEtPk9EVTItPk9EVTMtPk9EVTQsIGhv dyB0byByZWdhcmQgT0RVMiBvciBPRFUzIGFzIEhvIE9UTiBMZXZlbCBvciBMbyBPVE4gTGV2ZWw/ IEFub3RoZXIgZXhhbXBsZSBpcywgaWYgdGhlcmUgaXMgYSBPVFUzIGxpbmsgc3VwcG9ydGluZyBP RFUyIHN3aXRjaGluZywgd2hpY2ggY2FuIGJlIHVzZWQgYXMgTG8gT0RVMiAoc2VydmljZSBvdmVy IE9EVTIgZGlyZWN0bHkpIGFuZCBIbyBPRFUyIChPRFUxIGlzIG92ZXIgdGhpcyBPRFUyKSwgaW4g dGhpcyBjYXNlLCBob3cgdG8gZGlmZmVyZW50aWF0ZSBpZiB0aGlzIE9EVTIgaXMgTG8gT1ROIExl dmVsIG9yIEhvIE9UTiBMZXZlbD8NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQoNCg0KVGhhbmtzDQogDQpGYXRhaQ0KIA0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206ICJJZ29yIEJyeXNraW4iIDxJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20+ DQpUbzogPGN1cnRpc0BvY2NuYy5jb20+DQpDYzogIkpvaG4gRSBEcmFrZSIgPGpkcmFrZUBqdW5p cGVyLm5ldD47ICJTbmlnZGhvIEJhcmRhbGFpIiA8U0JhcmRhbGFpQGluZmluZXJhLmNvbT47ICJG YXRhaSBaaGFuZyIgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT47ICJMb3UgQmVyZ2VyIiA8bGJlcmdl ckBsYWJuLm5ldD47IDxjY2FtcEBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3 MDktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE0LCAy MDEwIDEwOjM2IFBNDQpTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDEudHh0DQoNCg0KQ3VydGlzLA0KDQpUaGFua3Mg Zm9yIHlvdXIgY29tbWVudC4NCg0KSSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSBtdWx0aXBs ZSBPVE4gc3BlY2lmaWMgZW5jb2RpbmcgdHlwZXMgaW50cm9kdWNlZC4gQnV0IElNTyB0aGV5IHNo b3VsZCBpbmRpY2F0ZSB0aGUgbGluaydzIG11eCBjYXBhYmlsaXRpZXMgcmF0aGVyIHRoYW4gdGhl IGxpbmsncyByb2xlIChpLmUuIGxldmVsIGluIHRoZSBPVE4gaGllcmFyY2h5OiBMTywgSE8sIFNI TywgZXRjLikuIFRoZSBsaW5rJ3Mgcm9sZSBvciByb2xlcyBJTU8gc2hvdWxkIGJlIGluZGljYXRl ZCB3aXRoIGEgc2VwYXJhdGUgc3dpdGNoY2Fwcy4gSSBjYW4gZ2l2ZSB5b3Ugc2V2ZXJhbCByZWFz b25zOg0KDQoxLiBMaW5rcyB3aXRoIHRoZSBzYW1lIG11eCBjYXBhYmlsaXRpZXMgbWF5IGhhdmUg ZGlmZmVyZW50IHJvbGVzOw0KMi4gTGluayBtYXkgYWR2ZXJ0aXNlIHNldmVyYWwgcm9sZXMgKGUu Zy4gSE8gYW5kIFNITykgd2l0aCBkaWZmZXJlbnQgbXV4LmNhcGFiaWxpdGllcyBwZXIgcm9sZTsN CjMuIExpbmsncyByb2xlIGFuZCBtdXguIGNhcGFiaWxpdGllcyBjYW4gYmUgYWR2ZXJ0aXNlZCB3 aXRoIElTQ0RzIGFzIGRlZmluZWQgaW4gUkZDNDIwMiAobm8gT1ROLXN0eWxlIElTQ0QgaXMgcmVx dWlyZWQpOw0KNC4gVGhlIGNvbWJpbmF0aW9uIG9mIHN3aWN0aGNhcHMgYW5kIGVuY29kaW5nIHR5 cGUgd2lsbCBsb29rIHRvIENQIGFzIGEgc2VwYXJhdGUgbGF5ZXIsIHdoaWNoIGlzIGV4YWN0bHkg aG93IElUVSBtb2RlbHMgT1ROIGhpZXJhcmNoaWVzIGluIGFsbCBhc3BlY3RzIGJ1dCByb3V0aW5n ICghPykNCjUuIElmIHRoZSBvcGVyYXRvciB3b3VsZCB3YW50IHRvIGNvbnN0cmFpbiB0aGUgcm91 dGluZyBvZiBPVE4gY29ubmVjdGlvbnMgdG8gcHJlLWNvbmZpZ3VyZWQgdG9wb2xvZ3kgd2l0aCBh IHNwZWNpZmljIHJvbGUgKGUuZy4gY29uc3RyYWluIGFsbCBPRFVzIGl0IHNlbGxzIHRvIHRoZSBj bGllbnRzIHRvIG9uZSBvciBtb3JlIHByZS1jb25maWd1cmVkIExPIHRvcG9sb2dpZXMpLCB0aGlz IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIGluIGEgdGVjaG5vbG9neSBpbmRlcGVuZGVudCB3YXku IFN1cHBvc2UgYW4gaW5zdGFuY2Ugb2YgR01QTFMgQ1AgbWFuYWdlcyBXRE0gYW5kIE9UTiBORXMu IFRoZW4gc2VwYXJhdGlvbiBvZiBMTyBmcm9tIEhPIE9UTiBsaW5rcyB3aWxsIGJlIG5vIGRpZmZl cmVudCBmcm9tIHRoZSBzZXBhcmF0aW9uIG9mIFdETSBsaW5rcyBmcm9tIE9UVXMuDQoNCkNoZWVy cywNCklnb3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGN1cnRpc0BvY2Nu Yy5jb20gW21haWx0bzpjdXJ0aXNAb2NjbmMuY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTMs IDIwMTAgNjoyNCBQTQ0KVG86IElnb3IgQnJ5c2tpbg0KQ2M6IEpvaG4gRSBEcmFrZTsgU25pZ2Ro byBCYXJkYWxhaTsgRmF0YWkgWmhhbmc7IExvdSBCZXJnZXI7IGNjYW1wQGlldGYub3JnOyBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFt ZXdvcmstMDEudHh0IA0KDQoNCkluIG1lc3NhZ2UgPDA1MkM2N0I0RUQ1NThENDFCQkRFQTdDQTlG QzZEQ0RDNTNDMEQxRTFGRUBhdGwtc3J2LWV4Z2VuLmF0bC5hZHZhb3B0aWNhbC5jb20+DQpJZ29y IEJyeXNraW4gd3JpdGVzOg0KPiAgDQo+IEkgdGhpbmsgT1ROIGxpbmtzIHJlcXVpcmUgbW9yZSB0 aGFuIG9uZSBzd2l0Y2hjYXBzOiBhcyBtYW55IGFzIHRoZSBkZXB0aCBvZiB0aGUgZGVlcGVzdCBw b3NzaWJsZSBPVE4gRFAgaGllcmFyY2h5LCBmb3IgZXhhbXBsZToNCj4gIA0KPiB0eXBlZGVmIGVu dW0NCj4gew0KPiAgICBMU1BTd2l0Y2hUeXBlX1Vua25vd24gPTAgICAgICAgICAgICAvKiBVbmtu b3duICovDQo+ICAgICwgTFNQU3dpdGNoVHlwZV9QU0NfMSA9MSAgICAgICAgICAgIC8qIFBTQy0x ICovDQo+ICAgICwgTFNQU3dpdGNoVHlwZV9QU0NfMiA9MiAgICAgICAgICAgIC8qIFBTQy0yICov DQo+ICAgICwgTFNQU3dpdGNoVHlwZV9QU0NfMyA9MyAgICAgICAgICAgIC8qIFBTQy0zICovDQo+ ICAgICwgTFNQU3dpdGNoVHlwZV9QU0NfNCA9NCAgICAgICAgICAgIC8qIFBTQy00ICovDQo+ICAg ICwgTFNQU3dpdGNoVHlwZV9MMlNDICA9NTAgICAgICAgICAgIC8qIEwyU0MgKi8NCj4gICAgLCBM U1BTd2l0Y2hUeXBlX1RETSAgID0xMDAgICAgICAgICAgLyogVERNICovDQo+ICANCj4gLyoqKioq Lw0KPiAgICAsIExTUFN3aXRjaFR5cGVfT1ROX0xPPTEyNCAgIC8qIE9UTiBsb3cgb3JkZXIgKi8N Cj4gICAgLCBMU1BTd2l0Y2hUeXBlX09UTl9ITz0xMjUgICAvKiBPVE4gaGlnaCBvcmRlciAqLw0K PiAgICAsIExTUFN3aXRjaFR5cGVfT1ROX1NITz0xMjYgIC8qIE9UTiBzdXBlciBoaWdoIG9yZGVy ICovDQo+IC8qKioqKi8NCj4gICAgLCBMU1BTd2l0Y2hUeXBlX0xTQyAgID0xNTAgICAgICAgICAg LyogTFNDICovDQo+ICAgICwgTFNQU3dpdGNoVHlwZV9GU0MgICA9MjAwICAgICAgICAgIC8qIEZT QyAqLw0KPiB9ZV9MU1BTd2l0Y2hUeXBlOw0KDQoNCkl0IHdvdWxkIGJlIGJldHRlciBJTUhPIHRv IGtlZXAgdGhlIFN3aXRjaCBUeXBlIGFzIFRETSBhbmQgbWFrZSB0aGUNCkVuY29kaW5nIFR5cGUg T1ROX0xPLCBPVE5fSE8gb3IgT1ROX1NITy4NCg0KVGhpcyB3b3VsZCByZXBsYWNlIHRoZSAyMDAw NiBPVE4gRW5jb2RpbmcgVHlwZSBmb3IgRy43MDkgRGlnaXRhbCBQYXRoDQpsYXllciBhbmQgRy43 MDkgT3B0aWNhbCBDaGFubmVsIGxheWVyIGZvciAyMDA5IE9UTiwgd2hpY2ggaGFkIGluIHR1cm4N CnJlcGxhY2VkIHRoZSBFbmNvZGluZyBUeXBlIG9mICJEaWdpdGFsIFdyYXBwZXIiIGEgbG9uZyB0 aW1lIGFnby4NCg0KUmVwbGFjaW5nIHRoZSBFbmNvZGluZyBUeXBlIHdvdWxkIGluc3VyZSB0aGF0 IGFueSBMU1IgdGhhdCBkaWQgbm90DQp1bmRlcnN0YW5kIHdoYXQgdGhlIFRTIHR5cGUgbWVhbnQg ZGlkIG5vdCB0cnkgdG8gbXVsdGlwbGV4IGl0cyBMTyBPRFUNCmF0IFRTIGdyYW51bGFyaXR5IDIu NSBvbnRvIGEgSE8gT0RVIHRoYXQgaGFkIGFscmFlZHkgY29tbWl0ZWQgdG8gdXNpbmcNCmEgMS4y NSBUUyBncmFudWxhcml0eSBmb3IgYW5vdGhlciBMTyBPRFUuDQoNCkl0IGNvdWxkIGFsc28gYmUg c3RhdGVkIHRoYXQgaWYgYW4gTFNSIGFkdmVydGlzZXMgT1ROX0xPLCBPVE5fSE8gb3INCk9UTl9T SE8gRkEsIGFuZCBhbHNvIGFkdmVydGlzZXMgRy43MDkgRGlnaXRhbCBQYXRoIEZBLCB0aGVuIHRo ZSBsYXR0ZXINCmlzIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFuZCBzaG91bGQgYmUgaWdu b3JlZCBpZiBPVE5fTE8sIE9UTl9ITw0Kb3IgT1ROX1NITyBpcyB1bmRlcnN0b29kLiAgSWYgdGhl IExTUiBjb21taXRzIHRvIDEuMjUgVFMgZ3JhbnVsYXJpdHksDQp0aGVuIHRoZSBjb3JyZXNwb25k aW5nIEcuNzA5IERpZ2l0YWwgUGF0aCBGQSBjYW4gYmUgd2l0aGRyYXduLg0KDQpUaGUgRW5jb2Rp bmcgdHlwZSB3b3VsZCBiZSB0aGUgbG93ZXIgZW5jb2RpbmcgYXQgZWFjaCBlbmQgb2YgdGhlIExT UA0KcmVnYXJkbGVzcyBvZiB3aGF0IGdvZXMgb24gaW4gdGhlIG1pZGRsZSBzaW5jZSB0aGF0IGRl dGVybWluZXMgd2hhdA0KY2FuIGJlIHdyYXBwZWQgaW5zaWRlIGl0Lg0KDQpGb3IgZXhhbXBsZToN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgT1RVMw0KICAgICAgICAgICAgICBPVFUyICAgICAg T0RVaz0zIC0tLS0tLS0tLS0tLS0tDQogICBPVFUxICAgICAgIE9EVWs9MiAtLSBPRFVqPTINCiAg IE9EVWs9MSAtLS0gT0RVaj0xIC0tDQoNClRoaXMgaXMgT0sgYW5kIHRoZSBvdXRlciBPRFVrPTEg Y291bGQgaG9sZCBhIE9EVWo9MCBvciBPRFVqPWZsZXggZXZlbg0KdGhvdWdoIHRoZSBPRFVrPTIg YXQgdGhlIG5leHQgaG9wIGNvdWxkIG5vdCBkaXJlY3RseSBjb250YWluIGFuIE9EVTAuDQpJZiB0 aGUgU0hPIEVuY29kaW5nIFR5cGUgaXMgdXNlZCwgdGhlbiBpdCBpbmRpY2F0ZXMgdGhhdCB0d28g bGV2ZWxzIG9mDQptdWx0aXBsZXhpbmcgY291bGQgYmUgc3VwcG9ydGVkIGF0IHRoYXQgc3dpdGNo L0xTUi4NCg0KVGhlIG5vbWluYWwgYnl0ZXMvc2VjIHJhdGVzIGNhbiBzdGlsbCBiZSBwcm92aWRl ZC4gIFJGQyA0MzI4IFN3aXRjaA0KVHlwZXMgY3VycmVudGx5IGRvbid0IGluY2x1ZGUgYW4gT0RV aiBvciBPRFVrIGRpc3RpbmN0aW9uIGJ1dCBpZg0KRW5jb2RpbmcgVHlwZSBpbmRpY2F0ZWQgTE8g b3IgSE8sIHRoYXQgbWF5IG5vdCBiZSBuZWVkZWQuICBBbG9uZyB3aXRoDQp0aGUgbmV3IEVuY29k aW5nIFR5cGUgbmV3IFNpZ25hbCBUeXBlcyBmb3IgT0RVMCwgT0RVNCwgYW5kIE9EVS1mbGV4LA0K YW5kIE9EVTJlLCBjYW4gYmUgYWRkZWQuDQoNCmJ0dyAtIHRoZSAxLjI1IG9yIDIuNSBUUyB0eXBl IGlzIGEgdmFsdWFibGUgYWRkaXRpb24gYnV0IEknbSBub3QgY2xlYXINCmhvdyBpbiBhbiBGQSBp dCBjYW4gYmUgaW5kaWNhdGVkIHRoYXQgZWl0aGVyIHR5cGUgaXMgY3VycmVudGx5DQphdmFpbGFi bGUgKE5FIGNhcGFibGUgb2YgYm90aCBhbmQgaGFzbid0IGNvbW1pdHRlZCB0byBlaXRoZXIgb25l IHlldCkuDQoNCkJUVy0gTWF5YmUgSSdtIG1pc3Npbmcgc29tZXRoaW5nIGJ1dCB0aGUgbnVtYmVy IG9mIG1lc3NhZ2VzIG9uIHRoaXMNCndvdWxkIGluZGljYXRlIGEgaHVnZSBjb250cm92ZXJzeSBh bmQgSSdtIG5vdCBnZXR0aW5nIGl0IChvdGhlciB0aGFuIGENCnN0cm9uZyBwcmVmZXJlbmNlIHRv IHJlbHkgb24gYnl0ZXMvc2VjIG9yIG9uIGVudW1lcmF0ZWQgdHlwZSBmaWVsZHMpLg0KDQpkcmFm dC1iY2NnLWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWwtMDEgaXMgbmljZSB3b3JrLiAgSSdtIG5v dCBzdXJlIGlmDQp0aGUgaW50ZW50IGlzIHRvIG1lcmdlIHdpdGggZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nNzA5LWZyYW1ld29yaywgb3INCm90aGVyIGludGVudC4gIENvdWxkIHNvbWVvbmUgKGVp dGhlciBkcmFmdCkgY29uY2lzZWx5IHN1bW1hcml6ZSB0aGUNCm11bHRpcGxleGluZyByZXN0cmlj dGlvbnMgaW4gb25lIHBsYWNlLCBpbmNsdWRpbmcgcmVzdHJpY3Rpb25zIG9uDQpudW1iZXIgb2Yg bXVsdGlwbGV4aW5nIGxheWVycyBhdCBvbmUgTFNSLiAgVGhhdCBtaWdodCBoZWxwLg0KDQpDdXJ0 aXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaG4gRSBEcmFr ZSBbbWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldF0gDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4 LCAyMDEwIDE6NTkgUE0NCj4gVG86IElnb3IgQnJ5c2tpbjsgU25pZ2RobyBCYXJkYWxhaTsgRmF0 YWkgWmhhbmc7IExvdSBCZXJnZXINCj4gQ2M6IGNjYW1wQGlldGYub3JnOyBkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBb Q0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0w MS50eHQNCj4gIA0KPiBXaGF0IGRvIHlvdSBtZWFuIGJ5ICJkaWZmZXJlbnQgc3dpdGNoY2FwcyI/ DQo+ICANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGNjYW1wLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gPiBJZ29yIEJyeXNraW4NCj4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAx MDo1MyBBTQ0KPiA+IFRvOiBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91IEJlcmdl cg0KPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZy YW1ld29ya0B0b29scy5pZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQg b24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0NCj4gPiAwMS50eHQNCj4g PiANCj4gPiBTbmlnZGhvLA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+INggIEkg dGhpbmsgd2UgbmVlZCB0byBzb3J0IG91dCB0aGUgaXNzdWVzIHdpdGggdGhlIGZyYW1ld29yayBk b2N1bWVudA0KPiA+IGJlZm9yZSB3ZSBjYW4gZW1iYXJrIG9uIGFueSBwcm9wb3NhbHMgdG8gdGhl IHByb2JsZW0uIEkgYW0gc3RpbGwgbm90IGNsZWFyDQo+ID4gd2h5IGRvIHdlIGhhdmUgdG8gZGV2 aWF0ZSBmcm9tIHRoZSBnZW5lcmFsIGFwcHJvYWNoIHRoYXQgaGFzIGJlZW4NCj4gPiBlc3RhYmxp c2hlZCBpbiBSRkMgNDIwMi4NCj4gPiANCj4gPiANCj4gPiANCj4gPiBJQj4+IEFncmVlIGFic29s dXRlbHkuIEdNUExTIGlzIGluaGVyZW50bHkgbXVsdGktbGF5ZXIgY29udHJvbCBwbGFuZSwgYW5k DQo+ID4gaXQgaXMgaGlnaGx5IGRlc2lyYWJsZSB0byBhZGhlcmUgdG8gdGhlIGxheWVyIGluZGVw ZW5kZW50IHBhcmFkaWdtIG9mDQo+ID4gYWR2ZXJ0aXNpbmcgb2YgVEUgbGlua3MsIGFuZCB0aGVy ZSBpcyBubyByZWFzb24gdG8gaW52ZW50IGFuIE9UTiBzcGVjaWZpYw0KPiA+IElTQ0QuIFRoZSBj b21iaW5hdGlvbiBvZiBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBhbmQgRW5jb2RpbmcgdHlwZSBvZiBS RkM0MjAyDQo+ID4gSVNDRCBhbGxvd3MgZm9yIHNwZWNpZnlpbmcgYm90aCBtdWx0aXBsZXhpbmcg Y2FwYWJpbGl0aWVzIGFuZCBPVE4gbGF5ZXINCj4gPiAoTE8sIEhPLCBTSE8pIG9mIGFuIE9UTiBs aW5rLCBhbmQsIGlmIHRoaXMgbm90IHN1ZmZpY2llbnQsIHlvdSBoYXZlDQo+ID4gYW5vdGhlciBy ZXNlcnZlZCAxNiBiaXRzLg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ID5BZGRpdGlvbmFsbHksIEkg ZG8gbm90IHNlZSBhbnkgcmVhc29uIHRvIGFkdmVydGlzZSBhIG5ldyBURS1saW5rIHRvDQo+ID4g cmVwcmVzZW50ID50aGUgbG93LW9yZGVyIE9EVWogYmFuZHdpZHRoIHdpdGhpbiB0aGUgaGlnaC1v cmRlciBjb250YWluZXJzLg0KPiA+IFRoaXMgaXMgc2ltcGx5ID5ibG93aW5nIHVwIHRoZSBzb2x1 dGlvbiB0byBhIHZlcnkgc2ltcGxlIHByb2JsZW0uDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gSUI+ PiBIZXJlIEkgZGlzYWdyZWUuIEluIG9yZGVyIHRvIGdpdmUgYSB1c2VyIHBvc3NpYmlsaXR5IHRv IGNyZWF0ZSBPVE4NCj4gPiBoaWVyYXJjaGllcyBhbmQgY29uc3RyYWluIExPIGNvbm5lY3Rpb25z IHRvIEhPIGNvbnRhaW5lcnMsIG9uZSBuZWVkcyB0bw0KPiA+IGFkdmVydGlzZSBPVE4gbGlua3Mg d2l0aCBkaWZmZXJlbnQgc3dpdGNoY2Fwcy4NCj4gPiANCj4gPiANCj4gPiANCj4gPiBDaGVlcnMs DQo+ID4gDQo+ID4gSWdvcg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFJlZ2FyZHMNCj4gPiANCj4g PiBTbmlnZGhvDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gRnJvbTogRmF0YWkgWmhhbmcgW21haWx0 bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDA3LCAy MDEwIDY6MzMgUE0NCj4gPiBUbzogU25pZ2RobyBCYXJkYWxhaTsgTG91IEJlcmdlcg0KPiA+IENj OiBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29ya0B0 b29scy5pZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0NCj4gPiAwMS50eHQNCj4gPiANCj4gPiAN Cj4gPiANCj4gPiBIaSBTbmlnZGhvIGFuZCBMb3UsDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gWWVz LCB3ZSBoYXZlIGxvdHMgb2Ygb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgYW1vbmcgYXV0aG9ycyBhbmQg b3RoZXINCj4gPiBpbnRlcmVzdGVkIGV4cGVydHMsIGFuZCB3ZSB0aGluayB0aGUgcHJvcG9zYWwg ZGVzY3JpYmVkIGluICJkcmFmdC0NCj4gPiBjZWNjYXJlbGxpLWNjYW1wLWdtcGxzLW9zcGYtZzcw OSIgW09TUEYtRW5jb2RpbmddIGRyYWZ0IGlzIG1vcmUgZmVhc2libGUNCj4gPiBmb3IgT1ROIG5l dHdvcmtzLg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFRoZSBmcmFtZXdvcmsgZHJhZnQganVzdCB0 ZWxscyB5b3Ugd2hhdCBpbmZvcm1hdGlvbiBuZWVkZWQgZm9yIGNvbnRyb2wNCj4gPiBwbGFuZSwg bm8gbWF0dGVyIGhvdyB5b3UgZW5jb2RlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLiBGb3IgVERN IG5ldHdvcmtzLA0KPiA+IHlvdSBrbm93IHRoZSByZXNvdXJjZSBpcyBhbGxvY2F0ZWQgYmFzZWQg b24gVFMsIHNvIHRoZSBhdmFpbGFibGUgVFMgc2hvdWxkDQo+ID4gYmUgZ2V0IG9yIGluZHVjZWQg YmVmb3JlIGNyZWF0aW5nIGNyb3NzLWNvbm5lY3QuDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gSWYg eW91IGFyZSB0cnlpbmcgdG8gZmluZCBob3cgdG8gZW5jb2RlIHRoZSByb3V0aW5nIGluZm9ybWF0 aW9uLCBJIHRoaW5rDQo+ID4geW91IG5lZWQgZ28gdG8gdGhlIHJvdXRpbmcgZHJhZnRzIChpbmZv IG1vZGVsIGFuZCBlbmNvZGluZykuDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gSWYgeW91IGxvb2sg YXQgdGhlIHJvdXRpbmcgZHJhZnRzIChpbmZvIG1vZGVsIGFuZCBlbmNvZGluZyksIHlvdSB3aWxs IGZpbmQNCj4gPiB0aGF0IG9uZSBvZiB5b3VyIHN1Z2dlc3Rpb25zIGlzIGFkb3B0ZWQgKGkuZS4s IHNpbXBseSBhZHZlcnRpemUgdGhlDQo+ID4gYXZhaWxhYmxlIG51bWJlciBvZiBPRFUwLCBPRFUx LCBPRFUyLCAuLi4sIE9EVTQgY29udGFpbmVyIGluc3RhbmNlcykuDQo+ID4gDQo+ID4gDQo+ID4g DQo+ID4gT25lIG1vcmUgdGhpbmcgZm9yIHlvdXIgZmlyc3QgY29tbWVudDoNCj4gPiANCj4gPiBJ ZiB5b3UgY3JlYXRlIGFuIE9EVTIgTFNQICh1c3VhbGx5IG92ZXIgbXVsdGkgT1RVMyBsaW5rcykg YXMgRkEgZm9yIE9EVTEsDQo+ID4geW91IGhhdmUgdG8gYWR2ZXJ0aXNlIGEgbmV3IFRFIGxpbmsg b3IgcHV0IHRoaXMgRkEgYXMgYSBjb21wb25lbnQgbGluayBvZg0KPiA+IGFuIGV4aXN0aW5nIFRF IGxpbmsgKGxpa2UgUkZDNDIwNmJpcykuDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ ID4gDQo+ID4gQmVzdCBSZWdhcmRzDQo+ID4gDQo+ID4gRmF0YWkNCj4gPiANCj4gPiANCj4gPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gDQo+ID4gRnJvbTogIlNuaWdkaG8gQmFy ZGFsYWkiIDxTQmFyZGFsYWlAaW5maW5lcmEuY29tDQo+ID4gPG1haWx0bzpTQmFyZGFsYWlAaW5m aW5lcmEuY29tPiA+DQo+ID4gDQo+ID4gVG86ICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5l dCA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+ID4NCj4gPiANCj4gPiBDYzogPGNjYW1wQGlldGYu b3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ID47IDxkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLQ0K PiA+IGc3MDktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnIDxtYWlsdG86ZHJhZnQtaWV0Zi1jY2Ft cC1nbXBscy1nNzA5LQ0KPiA+IGZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4gPg0KPiA+IA0KPiA+ IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCAxMTo0MyBQTQ0KPiA+IA0KPiA+IFN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZy YW1ld29yay0NCj4gPiAwMS50eHQNCj4gPiANCj4gPiANCj4gPiANCj4gPiA+IEhpIExvdQ0KPiA+ ID4NCj4gPiA+IFRoYW5rcywgSSBhbHNvIHdvdWxkIGxpa2UgdG8gaGVhciBhYm91dCB0aGUgc2Ft ZS4NCj4gPiA+DQo+ID4gPiBTbmlnZGhvDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0 XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDA3LCAyMDEwIDg6MzcgQU0NCj4gPiA+IFRv OiBTbmlnZGhvIEJhcmRhbGFpDQo+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2Ft cEBpZXRmLm9yZz4gOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLQ0KPiA+IGc3MDktZnJhbWV3b3Jr QHRvb2xzLmlldGYub3JnIDxtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ IGZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4NCj4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENv bW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0NCj4gPiAwMS50 eHQNCj4gPiA+DQo+ID4gPiBTbmlnZGhvLA0KPiA+ID4gSSBiZWxpZXZlIHRoZXJlIGhhcyBiZWVu IHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBvbiBob3cgdG8gYmV0dGVyDQo+ID4gPiBhbGlnbiB0 aGUgd29yayB3aXRoIDQyMDIuICBVc2Ugb2YgY29tbW9uIGFwcHJvYWNoZXMgaXMgb2YgY291cnNl IG9uZSBvZg0KPiA+ID4gdGhlIG1haW4gb2JqZWN0aXZlcyBvZiAqQypDQU1QLiAgSSBsb29rIGZv cndhcmQgdG8gaGVhcmluZyBmcm9tIHRoZQ0KPiA+ID4gZHJhZnQgYW5kIGRpc2N1c3Npb24gY29u dHJpYnV0b3JzIG9uIHRoZXJlIHByb2dyZXNzIG9uIHRoaXMgcG9pbnQuDQo+ID4gPg0KPiA+ID4g TG91DQo+ID4gPg0KPiA+ID4gT24gNy82LzIwMTAgMzo1OSBQTSwgU25pZ2RobyBCYXJkYWxhaSB3 cm90ZToNCj4gPiA+PiBIZWxsbywNCj4gPiA+Pg0KPiA+ID4+IEkgaGF2ZSBhIGNvbW1lbnQgYW5k IGEgcXVlc3Rpb24gb24gU2VjdGlvbiAzLjEuMi4xLiBUaGlzIHNlY3Rpb24NCj4gPiA+PiBkZXNj cmliZXMgdGhlIGxpbmstcGFyYW1ldGVycyB0aGF0IGFyZSByZXF1aXJlZCBmb3IgT1ROIHNlcnZp Y2Ugcm91dGluZw0KPiA+ID4+IHB1cnBvc2VzLg0KPiA+ID4+DQo+ID4gPj4gTXkgY29tbWVudCBp cyBob3cgYXJlIHdlIGdvaW5nIHRvIGFkdmVydGlzZSB0aGUgbG93LW9yZGVyIE9EVWoNCj4gPiA+ PiBhdmFpbGFiaWxpdHkgd2l0aGluIGEgaGlnaGVyLW9yZGVyIGNvbnRhaW5lci4gRm9yIGV4YW1w bGUsIGNvbnNpZGVyIGFuDQo+ID4gPj4gT1RVMyBsaW5rIHdoaWNoIGhhcyAxNiB0aW1lLXNsb3Rz IG9mIDIuNUcgZ3JhbnVsYXJpdHkgYW5kIHRoZW4gd2UNCj4gPiA+PiBlc3RhYmxpc2ggYW4gT0RV MiBzZXJ2aWNlIG92ZXIgdGhlIGxpbmsuIEF0IHRoaXMgcG9pbnQgaW4gdGltZSB0aGUgT1RVMw0K PiA+ID4+IGxpbmsgaGFzIDEyIHRpbWUtc2xvdHMgYXZhaWxhYmxlIGZvciBPRFUyIHNlcnZpY2Vz IGFuZCB1cCB0byAxMis0DQo+ID4gPj4gdGltZS1zbG90cyBhdmFpbGFibGUgZm9yIE9EVTEgc2Vy dmljZXMgKDQgT0RVMXMgYXJlIGNvbnRhaW5lZCBvdmVyIHRoZQ0KPiA+ID4+IE9EVTIpLiBTbyBp dCBpcyBvYnZpb3VzIGZyb20gdGhpcyBleGFtcGxlIHRoYXQgdGhlIG51bWJlciBvZiB0aW1lLXNs b3RzDQo+ID4gPj4gYXZhaWxhYmxlIGlzIGRpZmZlcmVudCBiYXNlZCBvbiB0aGUgc2lnbmFsLXR5 cGUgKGkuZS4gT0RVMSBhbmQgT0RVMikuDQo+ID4gPj4gSG93IGRvIHdlIGFkZHJlc3MgdGhpcyBp c3N1ZSBiYXNlZCBvbiB0aGUgYXBwcm9hY2ggc3BlY2lmaWVkIGluIHRoZQ0KPiA+IGRyYWZ0Pw0K PiA+ID4+DQo+ID4gPj4gTXkgb3RoZXIgcXVlc3Rpb24gaXMgd2h5IG5vdCBzaW1wbHkgYWR2ZXJ0 aXplIHRoZSBhdmFpbGFibGUgbnVtYmVyIG9mDQo+ID4gPj4gT0RVMCwgT0RVMSwgT0RVMiwgLi4u LCBPRFU0IGNvbnRhaW5lciBpbnN0YW5jZXMgb3IgdGhlIGVxdWl2YWxlbnQNCj4gPiA+PiBiYW5k d2lkdGggaW4gYnl0ZXMvc2VjIHdpdGhpbiBhIGxpbms/IFRoaXMgYXBwcm9hY2ggc2VlbXMgdG8g YmUgbW9yZQ0KPiA+ID4+IGluLWxpbmUgd2l0aCB0aGUgZ2VuZXJhbCBhcHByb2FjaCBvdXRsaW5l ZCBpbiBSRkMtNDIwMi4gUmVmZXIgdG8NCj4gPiBzZWN0aW9uDQo+ID4gPj4gMy40IGluIFJGQyA0 MjAyIGZvciBhbiBleGFtcGxlIHRoYXQgc2hvd3MgbXVsdGlwbGUgSVNDRHMgYmVpbmcNCj4gPiA+ PiBhZHZlcnRpc2VkIHBlciBWQyByYXRlIGZvciBhbiBTREggbGluay4gVGhlIGFkZGl0aW9uYWwg YmVuZWZpdCBpcyB0aGF0DQo+ID4gPj4gdGhlIGFkdmVydGlzZW1lbnQgaXMgVFMgc2l6ZSBpbmRl cGVuZGVudCBhbmQgaGVuY2Ugd2lsbCBzaW1wbGlmeSB0aGUNCj4gPiA+PiBpbXBsZW1lbnRhdGlv bi4NCj4gPiA+Pg0KPiA+ID4+IFJlZ2FyZHMNCj4gPiA+Pg0KPiA+ID4+IFNuaWdkaG8NCj4gPiA+ Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+ID4+IENDQU1Q QGlldGYub3JnIDxtYWlsdG86Q0NBTVBAaWV0Zi5vcmc+DQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+IDxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+ID4gQ0NB TVBAaWV0Zi5vcmcgPG1haWx0bzpDQ0FNUEBpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gPiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcD4NCj4gPiA+DQo+ICANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IEND QU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXANCj4gIA0KPiAg From sergio.belotti@alcatel-lucent.com Thu Jul 15 05:19:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31863A687D for ; Thu, 15 Jul 2010 05:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQPn-iQ4izZP for ; Thu, 15 Jul 2010 05:18:59 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id DD97D3A6898 for ; Thu, 15 Jul 2010 05:18:49 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6FCIkrg029415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Jul 2010 14:18:47 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 15 Jul 2010 14:18:47 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: "curtis@occnc.com" Date: Thu, 15 Jul 2010 14:18:46 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsi2hZdGrYG3MoXRcqIvq9NnsONrQBO6obw Message-ID: References: Your message of "Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> In-Reply-To: <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: Snigdho Bardalai , "ccamp@ietf.org" , Igor Bryskin , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" , Daniele Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 12:19:00 -0000 Hi Curtis, Regarding the note about draft-bccg-ccamp-otn-g709-info-model-01,thanks for= your comment to consider it a nice work. The original intent is to separate specific requirements into draft-ietf-cc= amp-gmpls-g709-framework and in draft-bccg, to analyze routing impact of th= ese requirements and how these requirements can match or not with the prese= nt tools.=20 We put in both drafts placeholder for multi-stage multiplexing since the is= sue can have impact both at requirement level and protocol routing impact. The discussion on this issue is still open also in ITU (SG15 Q12) and we ar= e waiting a more defined situation to better specify requirements, possible= constrains, and analyze those against actual IETF protocol tools. This is surely our intention to update. Best Regards=20 Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other intent. Could someone (either draft) concisely summarize the multiplexing restrictions in one place, including restrictions on number of multiplexing layers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > =20 > What do you mean by "different switchcaps"? > =20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > >=20 > > Snigdho, > >=20 > >=20 > >=20 > >=20 > >=20 > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not cl= ear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > >=20 > >=20 > >=20 > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, a= nd > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN specif= ic > > ISCD. The combination of Switching Capability and Encoding type of RFC4= 202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > >=20 > >=20 > >=20 > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order container= s. > > This is simply >blowing up the solution to a very simple problem. > >=20 > >=20 > >=20 > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > >=20 > >=20 > >=20 > > Cheers, > >=20 > > Igor > >=20 > >=20 > >=20 > > Regards > >=20 > > Snigdho > >=20 > >=20 > >=20 > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > >=20 > >=20 > >=20 > > Hi Snigdho and Lou, > >=20 > >=20 > >=20 > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > >=20 > >=20 > >=20 > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM networ= ks, > > you know the resource is allocated based on TS, so the available TS sho= uld > > be get or induced before creating cross-connect. > >=20 > >=20 > >=20 > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > >=20 > >=20 > >=20 > > If you look at the routing drafts (info model and encoding), you will f= ind > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > >=20 > >=20 > >=20 > > One more thing for your first comment: > >=20 > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU= 1, > > you have to advertise a new TE link or put this FA as a component link = of > > an existing TE link (like RFC4206bis). > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Best Regards > >=20 > > Fatai > >=20 > >=20 > > ----- Original Message ----- > >=20 > > From: "Snigdho Bardalai" > > > >=20 > > To: "Lou Berger" > > >=20 > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > >=20 > > Sent: Wednesday, July 07, 2010 11:43 PM > >=20 > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > >=20 > >=20 > >=20 > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one = of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service rout= ing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider = an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the O= TU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over t= he > > >> ODU2). So it is obvious from this example that the number of time-sl= ots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is th= at > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > =20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > =20 > =20 From IBryskin@advaoptical.com Thu Jul 15 09:35:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4943A69C6 for ; Thu, 15 Jul 2010 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5euj0bzRpfAS for ; Thu, 15 Jul 2010 09:35:22 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id C47C33A6AB2 for ; Thu, 15 Jul 2010 09:35:11 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6FGZ00s002508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 15 Jul 2010 18:35:00 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 15 Jul 2010 18:35:00 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 15 Jul 2010 12:34:57 -0400 From: Igor Bryskin To: Fatai Zhang , "curtis@occnc.com" Date: Thu, 15 Jul 2010 12:34:33 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsjwGpMsuWoeJcKRte/eYfKCsAQaQAdEt5A Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com> <084e01cb23c0$61b58490$514c460a@china.huawei.com> In-Reply-To: <084e01cb23c0$61b58490$514c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-15_04:2010-07-15, 2010-07-15, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 16:35:31 -0000 Fatai, Please, see my answers in line. -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 14, 2010 9:52 PM To: Igor Bryskin; curtis@occnc.com Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-ietf-= ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor and all, Thanks for all your comments. I think role does not equal switching capability. The operators can define = different roles depending on their policy and achieve the role through diff= erent methods. However, for OTN networks, the containers (e.g., ODUk) all h= ave the same switching capablility (i.e., TDM switching) and I think we sho= uld reflect the natural characteristics of links in the routing. In additio= n, if we extend the ISC, it will make the encoding type lose its' own meani= ng(ie., ISC overrides encoding type). IB>> When a GMPLS CP instance controls several layers, it views the network= as a stack of topologies. Whether a given topology is real or virtual is o= f no importance. The GMPLS ISCD link sub-tlv and, in particular, its switching capability fi= eld (confusing name as it is) is a good way to describe a layer in technolo= gy independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM lay= er stack could be perceived as a stack of topologies that could be easily s= eparated in technology independent way should path computation be constrain= ed to particular one or sub-stack of them. I think a good way to identify an OTN (virtual) topology is via (infrastruc= ture) ODU container role of ODUs comprising the topology. BTW IMO the role = of an ODU container does not change hop-by-hop (as some people seem to beli= eve). The role is only meaningful on the ODU terminating nodes and irreleva= nt on transit nodes. It is it's position in the hierarchy (but not role) th= at may change hop-by-hop. ODU's role is the level of topology it is provisi= oned for and it is the same for all ODUs that comprise the topology. For, e= xample a user may provision a LO topology and constrain ODUs he sells to a = set of clients to use the topology rather than any resources available on O= TN network. The bottom line: container's role is the same as the role of virtual topolo= gy the container is a part of and could be advertised as the corresponding = link switchcap. According to the point 3, I don't know how to advertise the roles and muxin= g capabilities with the ISCD of RFC4202, could you clarify? IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) encoding type =3D mux. capabilities code In addition, could you clarify my questions in another email (copied as fol= lows): =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. IB>> I disagree. You define role =3D=3D position in the hierarchy, which is= a mistake IMO. For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN L= evel or Lo OTN Level? Another example is, if there is a OTU3 link supportin= g ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly)= and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate i= f this ODU2 is Lo OTN Level or Ho OTN Level? IB>> As I mentioned earlier, ODU role is only important on the ODU terminat= ing nodes (i.e. on either side of corresponding link). What happens on the = ODU transit nodes and its place in the hierarchy on the transit nodes are o= f no importance. My LO container can be carried by somebody else's LO conta= iner and can carry my client's LO container. To some extent it is similar t= o MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it coul= d be anywhere in MPLS stack along its path. Cheers, Igor =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks Fatai ----- Original Message ----- From: "Igor Bryskin" To: Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; Sent: Wednesday, July 14, 2010 10:36 PM Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Curtis, Thanks for your comment. I agree that there should be multiple OTN specific encoding types introduce= d. But IMO they should indicate the link's mux capabilities rather than the= link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link= 's role or roles IMO should be indicated with a separate switchcaps. I can = give you several reasons: 1. Links with the same mux capabilities may have different roles; 2. Link may advertise several roles (e.g. HO and SHO) with different mux.ca= pabilities per role; 3. Link's role and mux. capabilities can be advertised with ISCDs as define= d in RFC4202 (no OTN-style ISCD is required); 4. The combination of swicthcaps and encoding type will look to CP as a sep= arate layer, which is exactly how ITU models OTN hierarchies in all aspects= but routing (!?) 5. If the operator would want to constrain the routing of OTN connections t= o pre-configured topology with a specific role (e.g. constrain all ODUs it = sells to the clients to one or more pre-configured LO topologies), this wou= ld be possible to do in a technology independent way. Suppose an instance o= f GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links= will be no different from the separation of WDM links from OTUs. Cheers, Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Tuesday, July 13, 2010 6:24 PM To: Igor Bryskin Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org= ; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > > I think OTN links require more than one switchcaps: as many as the depth = of the deepest possible OTN DP hierarchy, for example: > > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ > > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; It would be better IMHO to keep the Switch Type as TDM and make the Encoding Type OTN_LO, OTN_HO or OTN_SHO. This would replace the 20006 OTN Encoding Type for G.709 Digital Path layer and G.709 Optical Channel layer for 2009 OTN, which had in turn replaced the Encoding Type of "Digital Wrapper" a long time ago. Replacing the Encoding Type would insure that any LSR that did not understand what the TS type meant did not try to multiplex its LO ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to using a 1.25 TS granularity for another LO ODU. It could also be stated that if an LSR advertises OTN_LO, OTN_HO or OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter is for backward compatibility and should be ignored if OTN_LO, OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, then the corresponding G.709 Digital Path FA can be withdrawn. The Encoding type would be the lower encoding at each end of the LSP regardless of what goes on in the middle since that determines what can be wrapped inside it. For example: OTU3 OTU2 ODUk=3D3 -------------- OTU1 ODUk=3D2 -- ODUj=3D2 ODUk=3D1 --- ODUj=3D1 -- This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex even though the ODUk=3D2 at the next hop could not directly contain an ODU0. If the SHO Encoding Type is used, then it indicates that two levels of multiplexing could be supported at that switch/LSR. The nominal bytes/sec rates can still be provided. RFC 4328 Switch Types currently don't include an ODUj or ODUk distinction but if Encoding Type indicated LO or HO, that may not be needed. Along with the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, and ODU2e, can be added. btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear how in an FA it can be indicated that either type is currently available (NE capable of both and hasn't committed to either one yet). BTW- Maybe I'm missing something but the number of messages on this would indicate a huge controversy and I'm not getting it (other than a strong preference to rely on bytes/sec or on enumerated type fields). draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other intent. Could someone (either draft) concisely summarize the multiplexing restrictions in one place, including restrictions on number of multiplexing layers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > What do you mean by "different switchcaps"? > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not cl= ear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, a= nd > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN specif= ic > > ISCD. The combination of Switching Capability and Encoding type of RFC4= 202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order container= s. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM networ= ks, > > you know the resource is allocated based on TS, so the available TS sho= uld > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will f= ind > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU= 1, > > you have to advertise a new TE link or put this FA as a component link = of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one = of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service rout= ing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider = an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the O= TU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over t= he > > >> ODU2). So it is obvious from this example that the number of time-sl= ots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is th= at > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From lberger@labn.net Fri Jul 16 11:50:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FAA3A67E3 for ; Fri, 16 Jul 2010 11:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzuAQevcfcKJ for ; Fri, 16 Jul 2010 11:50:52 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id AEC023A67B1 for ; Fri, 16 Jul 2010 11:50:52 -0700 (PDT) Received: (qmail 8537 invoked by uid 0); 16 Jul 2010 18:51:04 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 16 Jul 2010 18:51:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Kwgzv9r6ZEPpHJWzVP4pTzR5lV0PWYJNmaT54n/WJ8TZJU1uk5h+TAMKBxYemzWL0Vn+3wND22uAlgzWGBtamM7qWFRhRhCeMXY2H9L9HM3Lr4B9ZcX3OSIvgvbbJL1z; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OZq00-0007mX-Bw for ccamp@ietf.org; Fri, 16 Jul 2010 12:51:04 -0600 Message-ID: <4C40AA18.1040602@labn.net> Date: Fri, 16 Jul 2010 14:51:04 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] G.709 Framework Discussion in Maastricht X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 18:50:54 -0000 WG, Please note on our agenda there is a slot allocated to facilitate the G.709 discussion that has been taking place on (and off-list). The slot is scheduled after the presentations of a number of related drafts. If you are interested in presenting an alternate technical approach as part of this discussion, please let us (the WG chairs) know. Discussion at the mic is always welcome and expected, but prior coordination is needed if you want to show any slides. Much thanks, Deborah and Lou From zhangfatai@huawei.com Sun Jul 18 19:48:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1013A681D for ; Sun, 18 Jul 2010 19:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.995 X-Spam-Level: ** X-Spam-Status: No, score=2.995 tagged_above=-999 required=5 tests=[AWL=-1.363, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kDa3sEG0682 for ; Sun, 18 Jul 2010 19:48:51 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8D9463A67D1 for ; Sun, 18 Jul 2010 19:48:45 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5S00NUIAHD4P@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 19 Jul 2010 10:48:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5S00CCTAHBH8@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 19 Jul 2010 10:48:47 +0800 (CST) Received: from Z41162C ([10.70.76.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5S00CYFAHA19@szxml04-in.huawei.com> for ccamp@ietf.org; Mon, 19 Jul 2010 10:48:47 +0800 (CST) Date: Mon, 19 Jul 2010 10:48:45 +0800 From: Fatai Zhang To: Igor Bryskin , curtis@occnc.com Message-id: <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com> <084e01cb23c0$61b58490$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com> Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 02:48:54 -0000 SGkgSWdvciwNCg0KVGhhbmtzLg0KSSB1bmRlcnN0YW5kIHdoYXQgeW91IHNhaWQuIFRoZXJlZm9y ZSwgd2UgaGF2ZSBhZGRlZCBzb21lIHRleHQgdG8gYWRkcmVzcyB0aGUgcmVxdWlybWVudCBpbiBG V0sgZG9jdW1lbnQuIEhvd2V2ZXIsIHdlIHN0aWxsIGRvbid0IHRoaW5rIHRoYXQgd2UgbmVlZCB0 byBleHRlbmQgSVNDIHRvIG1lZXQgdGhlIHJlcXVpcm1lbnQuIFRoZSByb2xlIG9mIHRoZSBPRFUg Y2FuIGJlIGdldCBmcm9tIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGltcGxpY2l0bHkuIEluIHRo ZSBbZHJhZnQtY2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDJdIGRyYWZ0LCBhIGtp bmQgb2YgICJGdWxsIExhbWJkYSIgaXMgaW50cm9kdWNlZC4NCg0KQSBxdWljayBxdWVzdGlvbiBv biB5b3VyIHN0YXRlbWVudDogInRoZSByb2xlIG9mIGFuIE9EVSBjb250YWluZXIgZG9lcyBub3Qg Y2hhbmdlIGhvcC1ieS1ob3AgKGFzIHNvbWUgcGVvcGxlIHNlZW0gdG8gYmVsaWV2ZSkuIFRoZSBy b2xlIGlzIG9ubHkgbWVhbmluZ2Z1bCBvbiB0aGUgT0RVIHRlcm1pbmF0aW5nIG5vZGVzIGFuZCBp cnJlbGV2YW50IG9uIHRyYW5zaXQgbm9kZXMuIEl0IGlzIGl0J3MgcG9zaXRpb24gaW4gdGhlIGhp ZXJhcmNoeSAoYnV0IG5vdCByb2xlKSB0aGF0IG1heSBjaGFuZ2UgaG9wLWJ5LWhvcC4gIg0KDQpG b3IgZXhhbXBsZSwgQShBSTEpLS0tLShCSTEpQihCSTIpLS0tLShDSTEpQywgIEludGVyZmFjZXMg QUkxIGFuZCBDSTEgY2FuIHN1cHBvcnQgSG8gT0RVMiBhbmQgTG8gT0RVMiwgSG93ZXZlciwgQkkx IGFuZCBCSTIgY2FuIG9ubHkgc3VwcG9ydCBMbyBPRFUyICh0aGUgcm9sZSBpcyBMbyBPVE4gTGV2 ZWwpLiBJZiBhIGNvbm5lY3Rpb24gT0RVMiB3aXRoIHRoZSByb2xlIG9mIEhvIE9EVSBsZXZlbCBp cyByZXF1ZXN0ZWQsICBhY2NvcmRpbmcgdG8geW91ciBzdGF0ZW1lbnQsIHRoaXMgY29ubmVjaXRv biB3aWxsIGJlIGFsbG93ZWQgdG8gYmUgY3JlYXRlZC4gSG93ZXZlciwgaXQgc2hvdWxkIG5vdCBi ZSBhbGxvd2VkIGJlY2F1c2UgdGhlIElTQyBpcyBub3QgY29uc2lzdGVudCBhbG9uZyB0aGUgTFNQ LiANCg0KUGxlYXNlIHNlZSB0aGUgdGV4dCBmcm9tIFJGQzM0NzM6ICAgIk5vZGVzIE1VU1QgdmVy aWZ5IHRoYXQgdGhlIHR5cGUgaW5kaWNhdGVkIGluIHRoZSBTd2l0Y2hpbmcgVHlwZSAgcGFyYW1l dGVyIGlzIHN1cHBvcnRlZCBvbiB0aGUgY29ycmVzcG9uZGluZyBpbmNvbWluZyBpbnRlcmZhY2Uu ICBJZiAgdGhlIHR5cGUgY2Fubm90IGJlIHN1cHBvcnRlZCwgdGhlIG5vZGUgTVVTVCBnZW5lcmF0 ZSBhIFBhdGhFcnIgbWVzc2FnZSB3aXRoIGEgIlJvdXRpbmcgcHJvYmxlbS9Td2l0Y2hpbmcgVHlw ZSIgaW5kaWNhdGlvbi4iDQoNCg0KDQoNCkJlc3QgUmVnYXJkcw0KIA0KRmF0YWkNCiANCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSWdvciBCcnlza2luIiA8SUJyeXNraW5A YWR2YW9wdGljYWwuY29tPg0KVG86ICJGYXRhaSBaaGFuZyIgPHpoYW5nZmF0YWlAaHVhd2VpLmNv bT47IDxjdXJ0aXNAb2NjbmMuY29tPg0KQ2M6ICJKb2huIEUgRHJha2UiIDxqZHJha2VAanVuaXBl ci5uZXQ+OyAiU25pZ2RobyBCYXJkYWxhaSIgPFNCYXJkYWxhaUBpbmZpbmVyYS5jb20+OyAiTG91 IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+OyA8Y2NhbXBAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4NClNlbnQ6IEZyaWRh eSwgSnVseSAxNiwgMjAxMCAxMjozNCBBTQ0KU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBv biBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dA0KDQoNCkZhdGFp LA0KUGxlYXNlLCBzZWUgbXkgYW5zd2VycyBpbiBsaW5lLg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21d DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTQsIDIwMTAgOTo1MiBQTQ0KVG86IElnb3IgQnJ5c2tp bjsgY3VydGlzQG9jY25jLmNvbQ0KQ2M6IEpvaG4gRSBEcmFrZTsgU25pZ2RobyBCYXJkYWxhaTsg TG91IEJlcmdlcjsgY2NhbXBAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1m cmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24g ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0KSGkgSWdvciBh bmQgYWxsLA0KDQpUaGFua3MgZm9yIGFsbCB5b3VyIGNvbW1lbnRzLg0KDQpJIHRoaW5rIHJvbGUg ZG9lcyBub3QgZXF1YWwgc3dpdGNoaW5nIGNhcGFiaWxpdHkuIFRoZSBvcGVyYXRvcnMgY2FuIGRl ZmluZSBkaWZmZXJlbnQgcm9sZXMgZGVwZW5kaW5nIG9uIHRoZWlyIHBvbGljeSBhbmQgYWNoaWV2 ZSB0aGUgcm9sZSB0aHJvdWdoIGRpZmZlcmVudCBtZXRob2RzLiBIb3dldmVyLCBmb3IgT1ROIG5l dHdvcmtzLCB0aGUgY29udGFpbmVycyAoZS5nLiwgT0RVaykgYWxsIGhhdmUgdGhlIHNhbWUgc3dp dGNoaW5nIGNhcGFibGlsaXR5IChpLmUuLCBURE0gc3dpdGNoaW5nKSBhbmQgSSB0aGluayB3ZSBz aG91bGQgcmVmbGVjdCB0aGUgbmF0dXJhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgbGlua3MgaW4gdGhl IHJvdXRpbmcuIEluIGFkZGl0aW9uLCBpZiB3ZSBleHRlbmQgdGhlIElTQywgaXQgd2lsbCBtYWtl IHRoZSBlbmNvZGluZyB0eXBlIGxvc2UgaXRzJyBvd24gbWVhbmluZyhpZS4sIElTQyBvdmVycmlk ZXMgZW5jb2RpbmcgdHlwZSkuDQoNCklCPj4gV2hlbiBhIEdNUExTIENQIGluc3RhbmNlIGNvbnRy b2xzIHNldmVyYWwgbGF5ZXJzLCBpdCB2aWV3cyB0aGUgbmV0d29yayBhcyBhIHN0YWNrIG9mIHRv cG9sb2dpZXMuIFdoZXRoZXIgYSBnaXZlbiB0b3BvbG9neSBpcyByZWFsIG9yIHZpcnR1YWwgaXMg b2Ygbm8gaW1wb3J0YW5jZS4NClRoZSBHTVBMUyBJU0NEIGxpbmsgc3ViLXRsdiBhbmQsIGluIHBh cnRpY3VsYXIsIGl0cyBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBmaWVsZCAoY29uZnVzaW5nIG5hbWUg YXMgaXQgaXMpIGlzIGEgZ29vZCB3YXkgdG8gZGVzY3JpYmUgYSBsYXllciBpbiB0ZWNobm9sb2d5 IGluZGVwZW5kZW50IHdheSwgc28gdGhhdCwgc2F5LCBNUExTLVRQLT5PVE5fTE8tPk9UTl9ITy0+ T1ROX1NITy0+V0RNIGxheWVyIHN0YWNrIGNvdWxkIGJlIHBlcmNlaXZlZCBhcyBhIHN0YWNrIG9m IHRvcG9sb2dpZXMgdGhhdCBjb3VsZCBiZSBlYXNpbHkgc2VwYXJhdGVkIGluIHRlY2hub2xvZ3kg aW5kZXBlbmRlbnQgd2F5IHNob3VsZCBwYXRoIGNvbXB1dGF0aW9uIGJlIGNvbnN0cmFpbmVkIHRv IHBhcnRpY3VsYXIgb25lIG9yIHN1Yi1zdGFjayBvZiB0aGVtLg0KSSB0aGluayBhIGdvb2Qgd2F5 IHRvIGlkZW50aWZ5IGFuIE9UTiAodmlydHVhbCkgdG9wb2xvZ3kgaXMgdmlhIChpbmZyYXN0cnVj dHVyZSkgT0RVIGNvbnRhaW5lciByb2xlIG9mIE9EVXMgY29tcHJpc2luZyB0aGUgdG9wb2xvZ3ku IEJUVyBJTU8gdGhlIHJvbGUgb2YgYW4gT0RVIGNvbnRhaW5lciBkb2VzIG5vdCBjaGFuZ2UgaG9w LWJ5LWhvcCAoYXMgc29tZSBwZW9wbGUgc2VlbSB0byBiZWxpZXZlKS4gVGhlIHJvbGUgaXMgb25s eSBtZWFuaW5nZnVsIG9uIHRoZSBPRFUgdGVybWluYXRpbmcgbm9kZXMgYW5kIGlycmVsZXZhbnQg b24gdHJhbnNpdCBub2Rlcy4gSXQgaXMgaXQncyBwb3NpdGlvbiBpbiB0aGUgaGllcmFyY2h5IChi dXQgbm90IHJvbGUpIHRoYXQgbWF5IGNoYW5nZSBob3AtYnktaG9wLiBPRFUncyByb2xlIGlzIHRo ZSBsZXZlbCBvZiB0b3BvbG9neSBpdCBpcyBwcm92aXNpb25lZCBmb3IgYW5kIGl0IGlzIHRoZSBz YW1lIGZvciBhbGwgT0RVcyB0aGF0IGNvbXByaXNlIHRoZSB0b3BvbG9neS4gRm9yLCBleGFtcGxl IGEgdXNlciBtYXkgcHJvdmlzaW9uIGEgTE8gdG9wb2xvZ3kgYW5kIGNvbnN0cmFpbiBPRFVzIGhl IHNlbGxzIHRvIGEgc2V0IG9mIGNsaWVudHMgdG8gdXNlIHRoZSB0b3BvbG9neSByYXRoZXIgdGhh biBhbnkgcmVzb3VyY2VzIGF2YWlsYWJsZSBvbiBPVE4gbmV0d29yay4NClRoZSBib3R0b20gbGlu ZTogY29udGFpbmVyJ3Mgcm9sZSBpcyB0aGUgc2FtZSBhcyB0aGUgcm9sZSBvZiB2aXJ0dWFsIHRv cG9sb2d5IHRoZSBjb250YWluZXIgaXMgYSBwYXJ0IG9mIGFuZCBjb3VsZCBiZSBhZHZlcnRpc2Vk IGFzIHRoZSBjb3JyZXNwb25kaW5nIGxpbmsgc3dpdGNoY2FwLg0KDQpBY2NvcmRpbmcgdG8gdGhl IHBvaW50IDMsIEkgZG9uJ3Qga25vdyBob3cgdG8gYWR2ZXJ0aXNlIHRoZSByb2xlcyBhbmQgbXV4 aW5nIGNhcGFiaWxpdGllcyB3aXRoIHRoZSBJU0NEIG9mIFJGQzQyMDIsIGNvdWxkIHlvdSBjbGFy aWZ5Pw0KDQpJQj4+IHN3aXRjaGNhcCA9IE9EVSByb2xlIChlLmcuIExPX09UTl9TQywgSE9fT1RO X1NDLCBldGMuKQ0KICAgICBlbmNvZGluZyB0eXBlID0gbXV4LiBjYXBhYmlsaXRpZXMgY29kZQ0K DQpJbiBhZGRpdGlvbiwgY291bGQgeW91IGNsYXJpZnkgbXkgcXVlc3Rpb25zIGluIGFub3RoZXIg ZW1haWwgKGNvcGllZCBhcyBmb2xsb3dzKToNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCkZvciAgTG8gT0RVLCBIbyBPRFUsIFNITyBPRFUsIHRoZXkgYXJlIHJl bGF0aXZlIHRvIGVhY2ggb3RoZXIuDQpJQj4+IEkgZGlzYWdyZWUuIFlvdSBkZWZpbmUgcm9sZSA9 PSBwb3NpdGlvbiBpbiB0aGUgaGllcmFyY2h5LCB3aGljaCBpcyBhIG1pc3Rha2UgSU1PLg0KDQpG b3IgZXhhbXBsZSwgT0RVMS0+T0RVMi0+T0RVMy0+T0RVNCwgaG93IHRvIHJlZ2FyZCBPRFUyIG9y IE9EVTMgYXMgSG8gT1ROIExldmVsIG9yIExvIE9UTiBMZXZlbD8gQW5vdGhlciBleGFtcGxlIGlz LCBpZiB0aGVyZSBpcyBhIE9UVTMgbGluayBzdXBwb3J0aW5nIE9EVTIgc3dpdGNoaW5nLCB3aGlj aCBjYW4gYmUgdXNlZCBhcyBMbyBPRFUyIChzZXJ2aWNlIG92ZXIgT0RVMiBkaXJlY3RseSkgYW5k IEhvIE9EVTIgKE9EVTEgaXMgb3ZlciB0aGlzIE9EVTIpLCBpbiB0aGlzIGNhc2UsIGhvdyB0byBk aWZmZXJlbnRpYXRlIGlmIHRoaXMgT0RVMiBpcyBMbyBPVE4gTGV2ZWwgb3IgSG8gT1ROIExldmVs Pw0KDQpJQj4+IEFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIE9EVSByb2xlIGlzIG9ubHkgaW1wb3J0 YW50IG9uIHRoZSBPRFUgdGVybWluYXRpbmcgbm9kZXMgKGkuZS4gb24gZWl0aGVyIHNpZGUgb2Yg Y29ycmVzcG9uZGluZyBsaW5rKS4gV2hhdCBoYXBwZW5zIG9uIHRoZSBPRFUgdHJhbnNpdCBub2Rl cyBhbmQgaXRzIHBsYWNlIGluIHRoZSBoaWVyYXJjaHkgb24gdGhlIHRyYW5zaXQgbm9kZXMgYXJl IG9mIG5vIGltcG9ydGFuY2UuIE15IExPIGNvbnRhaW5lciBjYW4gYmUgY2FycmllZCBieSBzb21l Ym9keSBlbHNlJ3MgTE8gY29udGFpbmVyIGFuZCBjYW4gY2FycnkgbXkgY2xpZW50J3MgTE8gY29u dGFpbmVyLiBUbyBzb21lIGV4dGVudCBpdCBpcyBzaW1pbGFyIHRvIE1QTFMgTFNQIHJvbGU6IExT UCBhbHdheXMgaGFzIGEgcm9sZSAoZS5nLiBQVyBMU1Agb3IgVEUtIExTUCkgYW5kIGl0IGNvdWxk IGJlIGFueXdoZXJlIGluIE1QTFMgc3RhY2sgYWxvbmcgaXRzIHBhdGguDQoNCkNoZWVycywNCkln b3INCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpU aGFua3MNCg0KRmF0YWkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkln b3IgQnJ5c2tpbiIgPElCcnlza2luQGFkdmFvcHRpY2FsLmNvbT4NClRvOiA8Y3VydGlzQG9jY25j LmNvbT4NCkNjOiAiSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIubmV0PjsgIlNuaWdkaG8g QmFyZGFsYWkiIDxTQmFyZGFsYWlAaW5maW5lcmEuY29tPjsgIkZhdGFpIFpoYW5nIiA8emhhbmdm YXRhaUBodWF3ZWkuY29tPjsgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PjsgPGNjYW1w QGlldGYub3JnPjsgPGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMu aWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTQsIDIwMTAgMTA6MzYgUE0NClN1Ympl Y3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZy YW1ld29yay0wMS50eHQNCg0KDQpDdXJ0aXMsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50Lg0K DQpJIGFncmVlIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG11bHRpcGxlIE9UTiBzcGVjaWZpYyBlbmNv ZGluZyB0eXBlcyBpbnRyb2R1Y2VkLiBCdXQgSU1PIHRoZXkgc2hvdWxkIGluZGljYXRlIHRoZSBs aW5rJ3MgbXV4IGNhcGFiaWxpdGllcyByYXRoZXIgdGhhbiB0aGUgbGluaydzIHJvbGUgKGkuZS4g bGV2ZWwgaW4gdGhlIE9UTiBoaWVyYXJjaHk6IExPLCBITywgU0hPLCBldGMuKS4gVGhlIGxpbmsn cyByb2xlIG9yIHJvbGVzIElNTyBzaG91bGQgYmUgaW5kaWNhdGVkIHdpdGggYSBzZXBhcmF0ZSBz d2l0Y2hjYXBzLiBJIGNhbiBnaXZlIHlvdSBzZXZlcmFsIHJlYXNvbnM6DQoNCjEuIExpbmtzIHdp dGggdGhlIHNhbWUgbXV4IGNhcGFiaWxpdGllcyBtYXkgaGF2ZSBkaWZmZXJlbnQgcm9sZXM7DQoy LiBMaW5rIG1heSBhZHZlcnRpc2Ugc2V2ZXJhbCByb2xlcyAoZS5nLiBITyBhbmQgU0hPKSB3aXRo IGRpZmZlcmVudCBtdXguY2FwYWJpbGl0aWVzIHBlciByb2xlOw0KMy4gTGluaydzIHJvbGUgYW5k IG11eC4gY2FwYWJpbGl0aWVzIGNhbiBiZSBhZHZlcnRpc2VkIHdpdGggSVNDRHMgYXMgZGVmaW5l ZCBpbiBSRkM0MjAyIChubyBPVE4tc3R5bGUgSVNDRCBpcyByZXF1aXJlZCk7DQo0LiBUaGUgY29t YmluYXRpb24gb2Ygc3dpY3RoY2FwcyBhbmQgZW5jb2RpbmcgdHlwZSB3aWxsIGxvb2sgdG8gQ1Ag YXMgYSBzZXBhcmF0ZSBsYXllciwgd2hpY2ggaXMgZXhhY3RseSBob3cgSVRVIG1vZGVscyBPVE4g aGllcmFyY2hpZXMgaW4gYWxsIGFzcGVjdHMgYnV0IHJvdXRpbmcgKCE/KQ0KNS4gSWYgdGhlIG9w ZXJhdG9yIHdvdWxkIHdhbnQgdG8gY29uc3RyYWluIHRoZSByb3V0aW5nIG9mIE9UTiBjb25uZWN0 aW9ucyB0byBwcmUtY29uZmlndXJlZCB0b3BvbG9neSB3aXRoIGEgc3BlY2lmaWMgcm9sZSAoZS5n LiBjb25zdHJhaW4gYWxsIE9EVXMgaXQgc2VsbHMgdG8gdGhlIGNsaWVudHMgdG8gb25lIG9yIG1v cmUgcHJlLWNvbmZpZ3VyZWQgTE8gdG9wb2xvZ2llcyksIHRoaXMgd291bGQgYmUgcG9zc2libGUg dG8gZG8gaW4gYSB0ZWNobm9sb2d5IGluZGVwZW5kZW50IHdheS4gU3VwcG9zZSBhbiBpbnN0YW5j ZSBvZiBHTVBMUyBDUCBtYW5hZ2VzIFdETSBhbmQgT1ROIE5Fcy4gVGhlbiBzZXBhcmF0aW9uIG9m IExPIGZyb20gSE8gT1ROIGxpbmtzIHdpbGwgYmUgbm8gZGlmZmVyZW50IGZyb20gdGhlIHNlcGFy YXRpb24gb2YgV0RNIGxpbmtzIGZyb20gT1RVcy4NCg0KQ2hlZXJzLA0KSWdvcg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY3VydGlzQG9jY25jLmNvbSBbbWFpbHRvOmN1cnRp c0BvY2NuYy5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDEzLCAyMDEwIDY6MjQgUE0NClRvOiBJ Z29yIEJyeXNraW4NCkNjOiBKb2huIEUgRHJha2U7IFNuaWdkaG8gQmFyZGFsYWk7IEZhdGFpIFpo YW5nOyBMb3UgQmVyZ2VyOyBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1n NzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVu dCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dA0KDQoNCklu IG1lc3NhZ2UgPDA1MkM2N0I0RUQ1NThENDFCQkRFQTdDQTlGQzZEQ0RDNTNDMEQxRTFGRUBhdGwt c3J2LWV4Z2VuLmF0bC5hZHZhb3B0aWNhbC5jb20+DQpJZ29yIEJyeXNraW4gd3JpdGVzOg0KPg0K PiBJIHRoaW5rIE9UTiBsaW5rcyByZXF1aXJlIG1vcmUgdGhhbiBvbmUgc3dpdGNoY2FwczogYXMg bWFueSBhcyB0aGUgZGVwdGggb2YgdGhlIGRlZXBlc3QgcG9zc2libGUgT1ROIERQIGhpZXJhcmNo eSwgZm9yIGV4YW1wbGU6DQo+DQo+IHR5cGVkZWYgZW51bQ0KPiB7DQo+ICAgIExTUFN3aXRjaFR5 cGVfVW5rbm93biA9MCAgICAgICAgICAgIC8qIFVua25vd24gKi8NCj4gICAgLCBMU1BTd2l0Y2hU eXBlX1BTQ18xID0xICAgICAgICAgICAgLyogUFNDLTEgKi8NCj4gICAgLCBMU1BTd2l0Y2hUeXBl X1BTQ18yID0yICAgICAgICAgICAgLyogUFNDLTIgKi8NCj4gICAgLCBMU1BTd2l0Y2hUeXBlX1BT Q18zID0zICAgICAgICAgICAgLyogUFNDLTMgKi8NCj4gICAgLCBMU1BTd2l0Y2hUeXBlX1BTQ180 ID00ICAgICAgICAgICAgLyogUFNDLTQgKi8NCj4gICAgLCBMU1BTd2l0Y2hUeXBlX0wyU0MgID01 MCAgICAgICAgICAgLyogTDJTQyAqLw0KPiAgICAsIExTUFN3aXRjaFR5cGVfVERNICAgPTEwMCAg ICAgICAgICAvKiBURE0gKi8NCj4NCj4gLyoqKioqLw0KPiAgICAsIExTUFN3aXRjaFR5cGVfT1RO X0xPPTEyNCAgIC8qIE9UTiBsb3cgb3JkZXIgKi8NCj4gICAgLCBMU1BTd2l0Y2hUeXBlX09UTl9I Tz0xMjUgICAvKiBPVE4gaGlnaCBvcmRlciAqLw0KPiAgICAsIExTUFN3aXRjaFR5cGVfT1ROX1NI Tz0xMjYgIC8qIE9UTiBzdXBlciBoaWdoIG9yZGVyICovDQo+IC8qKioqKi8NCj4gICAgLCBMU1BT d2l0Y2hUeXBlX0xTQyAgID0xNTAgICAgICAgICAgLyogTFNDICovDQo+ICAgICwgTFNQU3dpdGNo VHlwZV9GU0MgICA9MjAwICAgICAgICAgIC8qIEZTQyAqLw0KPiB9ZV9MU1BTd2l0Y2hUeXBlOw0K DQoNCkl0IHdvdWxkIGJlIGJldHRlciBJTUhPIHRvIGtlZXAgdGhlIFN3aXRjaCBUeXBlIGFzIFRE TSBhbmQgbWFrZSB0aGUNCkVuY29kaW5nIFR5cGUgT1ROX0xPLCBPVE5fSE8gb3IgT1ROX1NITy4N Cg0KVGhpcyB3b3VsZCByZXBsYWNlIHRoZSAyMDAwNiBPVE4gRW5jb2RpbmcgVHlwZSBmb3IgRy43 MDkgRGlnaXRhbCBQYXRoDQpsYXllciBhbmQgRy43MDkgT3B0aWNhbCBDaGFubmVsIGxheWVyIGZv ciAyMDA5IE9UTiwgd2hpY2ggaGFkIGluIHR1cm4NCnJlcGxhY2VkIHRoZSBFbmNvZGluZyBUeXBl IG9mICJEaWdpdGFsIFdyYXBwZXIiIGEgbG9uZyB0aW1lIGFnby4NCg0KUmVwbGFjaW5nIHRoZSBF bmNvZGluZyBUeXBlIHdvdWxkIGluc3VyZSB0aGF0IGFueSBMU1IgdGhhdCBkaWQgbm90DQp1bmRl cnN0YW5kIHdoYXQgdGhlIFRTIHR5cGUgbWVhbnQgZGlkIG5vdCB0cnkgdG8gbXVsdGlwbGV4IGl0 cyBMTyBPRFUNCmF0IFRTIGdyYW51bGFyaXR5IDIuNSBvbnRvIGEgSE8gT0RVIHRoYXQgaGFkIGFs cmFlZHkgY29tbWl0ZWQgdG8gdXNpbmcNCmEgMS4yNSBUUyBncmFudWxhcml0eSBmb3IgYW5vdGhl ciBMTyBPRFUuDQoNCkl0IGNvdWxkIGFsc28gYmUgc3RhdGVkIHRoYXQgaWYgYW4gTFNSIGFkdmVy dGlzZXMgT1ROX0xPLCBPVE5fSE8gb3INCk9UTl9TSE8gRkEsIGFuZCBhbHNvIGFkdmVydGlzZXMg Ry43MDkgRGlnaXRhbCBQYXRoIEZBLCB0aGVuIHRoZSBsYXR0ZXINCmlzIGZvciBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IGFuZCBzaG91bGQgYmUgaWdub3JlZCBpZiBPVE5fTE8sIE9UTl9ITw0Kb3Ig T1ROX1NITyBpcyB1bmRlcnN0b29kLiAgSWYgdGhlIExTUiBjb21taXRzIHRvIDEuMjUgVFMgZ3Jh bnVsYXJpdHksDQp0aGVuIHRoZSBjb3JyZXNwb25kaW5nIEcuNzA5IERpZ2l0YWwgUGF0aCBGQSBj YW4gYmUgd2l0aGRyYXduLg0KDQpUaGUgRW5jb2RpbmcgdHlwZSB3b3VsZCBiZSB0aGUgbG93ZXIg ZW5jb2RpbmcgYXQgZWFjaCBlbmQgb2YgdGhlIExTUA0KcmVnYXJkbGVzcyBvZiB3aGF0IGdvZXMg b24gaW4gdGhlIG1pZGRsZSBzaW5jZSB0aGF0IGRldGVybWluZXMgd2hhdA0KY2FuIGJlIHdyYXBw ZWQgaW5zaWRlIGl0Lg0KDQpGb3IgZXhhbXBsZToNCg0KICAgICAgICAgICAgICAgICAgICAgICAg T1RVMw0KICAgICAgICAgICAgICBPVFUyICAgICAgT0RVaz0zIC0tLS0tLS0tLS0tLS0tDQogICBP VFUxICAgICAgIE9EVWs9MiAtLSBPRFVqPTINCiAgIE9EVWs9MSAtLS0gT0RVaj0xIC0tDQoNClRo aXMgaXMgT0sgYW5kIHRoZSBvdXRlciBPRFVrPTEgY291bGQgaG9sZCBhIE9EVWo9MCBvciBPRFVq PWZsZXggZXZlbg0KdGhvdWdoIHRoZSBPRFVrPTIgYXQgdGhlIG5leHQgaG9wIGNvdWxkIG5vdCBk aXJlY3RseSBjb250YWluIGFuIE9EVTAuDQpJZiB0aGUgU0hPIEVuY29kaW5nIFR5cGUgaXMgdXNl ZCwgdGhlbiBpdCBpbmRpY2F0ZXMgdGhhdCB0d28gbGV2ZWxzIG9mDQptdWx0aXBsZXhpbmcgY291 bGQgYmUgc3VwcG9ydGVkIGF0IHRoYXQgc3dpdGNoL0xTUi4NCg0KVGhlIG5vbWluYWwgYnl0ZXMv c2VjIHJhdGVzIGNhbiBzdGlsbCBiZSBwcm92aWRlZC4gIFJGQyA0MzI4IFN3aXRjaA0KVHlwZXMg Y3VycmVudGx5IGRvbid0IGluY2x1ZGUgYW4gT0RVaiBvciBPRFVrIGRpc3RpbmN0aW9uIGJ1dCBp Zg0KRW5jb2RpbmcgVHlwZSBpbmRpY2F0ZWQgTE8gb3IgSE8sIHRoYXQgbWF5IG5vdCBiZSBuZWVk ZWQuICBBbG9uZyB3aXRoDQp0aGUgbmV3IEVuY29kaW5nIFR5cGUgbmV3IFNpZ25hbCBUeXBlcyBm b3IgT0RVMCwgT0RVNCwgYW5kIE9EVS1mbGV4LA0KYW5kIE9EVTJlLCBjYW4gYmUgYWRkZWQuDQoN CmJ0dyAtIHRoZSAxLjI1IG9yIDIuNSBUUyB0eXBlIGlzIGEgdmFsdWFibGUgYWRkaXRpb24gYnV0 IEknbSBub3QgY2xlYXINCmhvdyBpbiBhbiBGQSBpdCBjYW4gYmUgaW5kaWNhdGVkIHRoYXQgZWl0 aGVyIHR5cGUgaXMgY3VycmVudGx5DQphdmFpbGFibGUgKE5FIGNhcGFibGUgb2YgYm90aCBhbmQg aGFzbid0IGNvbW1pdHRlZCB0byBlaXRoZXIgb25lIHlldCkuDQoNCkJUVy0gTWF5YmUgSSdtIG1p c3Npbmcgc29tZXRoaW5nIGJ1dCB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIG9uIHRoaXMNCndvdWxk IGluZGljYXRlIGEgaHVnZSBjb250cm92ZXJzeSBhbmQgSSdtIG5vdCBnZXR0aW5nIGl0IChvdGhl ciB0aGFuIGENCnN0cm9uZyBwcmVmZXJlbmNlIHRvIHJlbHkgb24gYnl0ZXMvc2VjIG9yIG9uIGVu dW1lcmF0ZWQgdHlwZSBmaWVsZHMpLg0KDQpkcmFmdC1iY2NnLWNjYW1wLW90bi1nNzA5LWluZm8t bW9kZWwtMDEgaXMgbmljZSB3b3JrLiAgSSdtIG5vdCBzdXJlIGlmDQp0aGUgaW50ZW50IGlzIHRv IG1lcmdlIHdpdGggZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yaywgb3INCm90 aGVyIGludGVudC4gIENvdWxkIHNvbWVvbmUgKGVpdGhlciBkcmFmdCkgY29uY2lzZWx5IHN1bW1h cml6ZSB0aGUNCm11bHRpcGxleGluZyByZXN0cmljdGlvbnMgaW4gb25lIHBsYWNlLCBpbmNsdWRp bmcgcmVzdHJpY3Rpb25zIG9uDQpudW1iZXIgb2YgbXVsdGlwbGV4aW5nIGxheWVycyBhdCBvbmUg TFNSLiAgVGhhdCBtaWdodCBoZWxwLg0KDQpDdXJ0aXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEpvaG4gRSBEcmFrZSBbbWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5l dF0NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMTo1OSBQTQ0KPiBUbzogSWdvciBC cnlza2luOyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91IEJlcmdlcg0KPiBDYzog Y2NhbXBAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9v bHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dA0KPg0KPiBXaGF0IGRvIHlvdSBtZWFu IGJ5ICJkaWZmZXJlbnQgc3dpdGNoY2FwcyI/DQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gSWdvciBCcnlza2luDQo+ID4gU2VudDog VGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMTA6NTMgQU0NCj4gPiBUbzogU25pZ2RobyBCYXJkYWxh aTsgRmF0YWkgWmhhbmc7IExvdSBCZXJnZXINCj4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBSZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1m cmFtZXdvcmstDQo+ID4gMDEudHh0DQo+ID4NCj4gPiBTbmlnZGhvLA0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4NCj4gPiDYICBJIHRoaW5rIHdlIG5lZWQgdG8gc29ydCBvdXQgdGhlIGlzc3VlcyB3 aXRoIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQNCj4gPiBiZWZvcmUgd2UgY2FuIGVtYmFyayBvbiBh bnkgcHJvcG9zYWxzIHRvIHRoZSBwcm9ibGVtLiBJIGFtIHN0aWxsIG5vdCBjbGVhcg0KPiA+IHdo eSBkbyB3ZSBoYXZlIHRvIGRldmlhdGUgZnJvbSB0aGUgZ2VuZXJhbCBhcHByb2FjaCB0aGF0IGhh cyBiZWVuDQo+ID4gZXN0YWJsaXNoZWQgaW4gUkZDIDQyMDIuDQo+ID4NCj4gPg0KPiA+DQo+ID4g SUI+PiBBZ3JlZSBhYnNvbHV0ZWx5LiBHTVBMUyBpcyBpbmhlcmVudGx5IG11bHRpLWxheWVyIGNv bnRyb2wgcGxhbmUsIGFuZA0KPiA+IGl0IGlzIGhpZ2hseSBkZXNpcmFibGUgdG8gYWRoZXJlIHRv IHRoZSBsYXllciBpbmRlcGVuZGVudCBwYXJhZGlnbSBvZg0KPiA+IGFkdmVydGlzaW5nIG9mIFRF IGxpbmtzLCBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGludmVudCBhbiBPVE4gc3BlY2lmaWMN Cj4gPiBJU0NELiBUaGUgY29tYmluYXRpb24gb2YgU3dpdGNoaW5nIENhcGFiaWxpdHkgYW5kIEVu Y29kaW5nIHR5cGUgb2YgUkZDNDIwMg0KPiA+IElTQ0QgYWxsb3dzIGZvciBzcGVjaWZ5aW5nIGJv dGggbXVsdGlwbGV4aW5nIGNhcGFiaWxpdGllcyBhbmQgT1ROIGxheWVyDQo+ID4gKExPLCBITywg U0hPKSBvZiBhbiBPVE4gbGluaywgYW5kLCBpZiB0aGlzIG5vdCBzdWZmaWNpZW50LCB5b3UgaGF2 ZQ0KPiA+IGFub3RoZXIgcmVzZXJ2ZWQgMTYgYml0cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiA+QWRk aXRpb25hbGx5LCBJIGRvIG5vdCBzZWUgYW55IHJlYXNvbiB0byBhZHZlcnRpc2UgYSBuZXcgVEUt bGluayB0bw0KPiA+IHJlcHJlc2VudCA+dGhlIGxvdy1vcmRlciBPRFVqIGJhbmR3aWR0aCB3aXRo aW4gdGhlIGhpZ2gtb3JkZXIgY29udGFpbmVycy4NCj4gPiBUaGlzIGlzIHNpbXBseSA+Ymxvd2lu ZyB1cCB0aGUgc29sdXRpb24gdG8gYSB2ZXJ5IHNpbXBsZSBwcm9ibGVtLg0KPiA+DQo+ID4NCj4g Pg0KPiA+IElCPj4gSGVyZSBJIGRpc2FncmVlLiBJbiBvcmRlciB0byBnaXZlIGEgdXNlciBwb3Nz aWJpbGl0eSB0byBjcmVhdGUgT1RODQo+ID4gaGllcmFyY2hpZXMgYW5kIGNvbnN0cmFpbiBMTyBj b25uZWN0aW9ucyB0byBITyBjb250YWluZXJzLCBvbmUgbmVlZHMgdG8NCj4gPiBhZHZlcnRpc2Ug T1ROIGxpbmtzIHdpdGggZGlmZmVyZW50IHN3aXRjaGNhcHMuDQo+ID4NCj4gPg0KPiA+DQo+ID4g Q2hlZXJzLA0KPiA+DQo+ID4gSWdvcg0KPiA+DQo+ID4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPg0K PiA+IFNuaWdkaG8NCj4gPg0KPiA+DQo+ID4NCj4gPiBGcm9tOiBGYXRhaSBaaGFuZyBbbWFpbHRv OnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDcsIDIw MTAgNjozMyBQTQ0KPiA+IFRvOiBTbmlnZGhvIEJhcmRhbGFpOyBMb3UgQmVyZ2VyDQo+ID4gQ2M6 IGNjYW1wQGlldGYub3JnOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrQHRv b2xzLmlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLQ0KPiA+IDAxLnR4dA0KPiA+DQo+ID4NCj4g Pg0KPiA+IEhpIFNuaWdkaG8gYW5kIExvdSwNCj4gPg0KPiA+DQo+ID4NCj4gPiBZZXMsIHdlIGhh dmUgbG90cyBvZiBvZmYtbGluZSBkaXNjdXNzaW9ucyBhbW9uZyBhdXRob3JzIGFuZCBvdGhlcg0K PiA+IGludGVyZXN0ZWQgZXhwZXJ0cywgYW5kIHdlIHRoaW5rIHRoZSBwcm9wb3NhbCBkZXNjcmli ZWQgaW4gImRyYWZ0LQ0KPiA+IGNlY2NhcmVsbGktY2NhbXAtZ21wbHMtb3NwZi1nNzA5IiBbT1NQ Ri1FbmNvZGluZ10gZHJhZnQgaXMgbW9yZSBmZWFzaWJsZQ0KPiA+IGZvciBPVE4gbmV0d29ya3Mu DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIGZyYW1ld29yayBkcmFmdCBqdXN0IHRlbGxzIHlvdSB3 aGF0IGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgY29udHJvbA0KPiA+IHBsYW5lLCBubyBtYXR0ZXIg aG93IHlvdSBlbmNvZGUgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24uIEZvciBURE0gbmV0d29ya3Ms DQo+ID4geW91IGtub3cgdGhlIHJlc291cmNlIGlzIGFsbG9jYXRlZCBiYXNlZCBvbiBUUywgc28g dGhlIGF2YWlsYWJsZSBUUyBzaG91bGQNCj4gPiBiZSBnZXQgb3IgaW5kdWNlZCBiZWZvcmUgY3Jl YXRpbmcgY3Jvc3MtY29ubmVjdC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJZiB5b3UgYXJlIHRyeWlu ZyB0byBmaW5kIGhvdyB0byBlbmNvZGUgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24sIEkgdGhpbmsN Cj4gPiB5b3UgbmVlZCBnbyB0byB0aGUgcm91dGluZyBkcmFmdHMgKGluZm8gbW9kZWwgYW5kIGVu Y29kaW5nKS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJZiB5b3UgbG9vayBhdCB0aGUgcm91dGluZyBk cmFmdHMgKGluZm8gbW9kZWwgYW5kIGVuY29kaW5nKSwgeW91IHdpbGwgZmluZA0KPiA+IHRoYXQg b25lIG9mIHlvdXIgc3VnZ2VzdGlvbnMgaXMgYWRvcHRlZCAoaS5lLiwgc2ltcGx5IGFkdmVydGl6 ZSB0aGUNCj4gPiBhdmFpbGFibGUgbnVtYmVyIG9mIE9EVTAsIE9EVTEsIE9EVTIsIC4uLiwgT0RV NCBjb250YWluZXIgaW5zdGFuY2VzKS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbmUgbW9yZSB0aGlu ZyBmb3IgeW91ciBmaXJzdCBjb21tZW50Og0KPiA+DQo+ID4gSWYgeW91IGNyZWF0ZSBhbiBPRFUy IExTUCAodXN1YWxseSBvdmVyIG11bHRpIE9UVTMgbGlua3MpIGFzIEZBIGZvciBPRFUxLA0KPiA+ IHlvdSBoYXZlIHRvIGFkdmVydGlzZSBhIG5ldyBURSBsaW5rIG9yIHB1dCB0aGlzIEZBIGFzIGEg Y29tcG9uZW50IGxpbmsgb2YNCj4gPiBhbiBleGlzdGluZyBURSBsaW5rIChsaWtlIFJGQzQyMDZi aXMpLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEJlc3QgUmVnYXJkcw0KPiA+ DQo+ID4gRmF0YWkNCj4gPg0KPiA+DQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K PiA+DQo+ID4gRnJvbTogIlNuaWdkaG8gQmFyZGFsYWkiIDxTQmFyZGFsYWlAaW5maW5lcmEuY29t DQo+ID4gPG1haWx0bzpTQmFyZGFsYWlAaW5maW5lcmEuY29tPiA+DQo+ID4NCj4gPiBUbzogIkxv dSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0IDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4gPg0K PiA+DQo+ID4gQ2M6IDxjY2FtcEBpZXRmLm9yZyA8bWFpbHRvOmNjYW1wQGlldGYub3JnPiA+OyA8 ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy0NCj4gPiBnNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9y ZyA8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiBmcmFtZXdvcmtAdG9v bHMuaWV0Zi5vcmc+ID4NCj4gPg0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCAx MTo0MyBQTQ0KPiA+DQo+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLQ0KPiA+IDAxLnR4dA0KPiA+DQo+ID4NCj4g Pg0KPiA+ID4gSGkgTG91DQo+ID4gPg0KPiA+ID4gVGhhbmtzLCBJIGFsc28gd291bGQgbGlrZSB0 byBoZWFyIGFib3V0IHRoZSBzYW1lLg0KPiA+ID4NCj4gPiA+IFNuaWdkaG8NCj4gPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogTG91IEJlcmdlciBbbWFp bHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDcsIDIw MTAgODozNyBBTQ0KPiA+ID4gVG86IFNuaWdkaG8gQmFyZGFsYWkNCj4gPiA+IENjOiBjY2FtcEBp ZXRmLm9yZyA8bWFpbHRvOmNjYW1wQGlldGYub3JnPiA7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt DQo+ID4gZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcgPG1haWx0bzpkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLWc3MDktDQo+ID4gZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPg0KPiA+ID4gU3Vi amVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDkt ZnJhbWV3b3JrLQ0KPiA+IDAxLnR4dA0KPiA+ID4NCj4gPiA+IFNuaWdkaG8sDQo+ID4gPiBJIGJl bGlldmUgdGhlcmUgaGFzIGJlZW4gc29tZSBvZmYtbGluZSBkaXNjdXNzaW9uIG9uIGhvdyB0byBi ZXR0ZXINCj4gPiA+IGFsaWduIHRoZSB3b3JrIHdpdGggNDIwMi4gIFVzZSBvZiBjb21tb24gYXBw cm9hY2hlcyBpcyBvZiBjb3Vyc2Ugb25lIG9mDQo+ID4gPiB0aGUgbWFpbiBvYmplY3RpdmVzIG9m ICpDKkNBTVAuICBJIGxvb2sgZm9yd2FyZCB0byBoZWFyaW5nIGZyb20gdGhlDQo+ID4gPiBkcmFm dCBhbmQgZGlzY3Vzc2lvbiBjb250cmlidXRvcnMgb24gdGhlcmUgcHJvZ3Jlc3Mgb24gdGhpcyBw b2ludC4NCj4gPiA+DQo+ID4gPiBMb3UNCj4gPiA+DQo+ID4gPiBPbiA3LzYvMjAxMCAzOjU5IFBN LCBTbmlnZGhvIEJhcmRhbGFpIHdyb3RlOg0KPiA+ID4+IEhlbGxvLA0KPiA+ID4+DQo+ID4gPj4g SSBoYXZlIGEgY29tbWVudCBhbmQgYSBxdWVzdGlvbiBvbiBTZWN0aW9uIDMuMS4yLjEuIFRoaXMg c2VjdGlvbg0KPiA+ID4+IGRlc2NyaWJlcyB0aGUgbGluay1wYXJhbWV0ZXJzIHRoYXQgYXJlIHJl cXVpcmVkIGZvciBPVE4gc2VydmljZSByb3V0aW5nDQo+ID4gPj4gcHVycG9zZXMuDQo+ID4gPj4N Cj4gPiA+PiBNeSBjb21tZW50IGlzIGhvdyBhcmUgd2UgZ29pbmcgdG8gYWR2ZXJ0aXNlIHRoZSBs b3ctb3JkZXIgT0RVag0KPiA+ID4+IGF2YWlsYWJpbGl0eSB3aXRoaW4gYSBoaWdoZXItb3JkZXIg Y29udGFpbmVyLiBGb3IgZXhhbXBsZSwgY29uc2lkZXIgYW4NCj4gPiA+PiBPVFUzIGxpbmsgd2hp Y2ggaGFzIDE2IHRpbWUtc2xvdHMgb2YgMi41RyBncmFudWxhcml0eSBhbmQgdGhlbiB3ZQ0KPiA+ ID4+IGVzdGFibGlzaCBhbiBPRFUyIHNlcnZpY2Ugb3ZlciB0aGUgbGluay4gQXQgdGhpcyBwb2lu dCBpbiB0aW1lIHRoZSBPVFUzDQo+ID4gPj4gbGluayBoYXMgMTIgdGltZS1zbG90cyBhdmFpbGFi bGUgZm9yIE9EVTIgc2VydmljZXMgYW5kIHVwIHRvIDEyKzQNCj4gPiA+PiB0aW1lLXNsb3RzIGF2 YWlsYWJsZSBmb3IgT0RVMSBzZXJ2aWNlcyAoNCBPRFUxcyBhcmUgY29udGFpbmVkIG92ZXIgdGhl DQo+ID4gPj4gT0RVMikuIFNvIGl0IGlzIG9idmlvdXMgZnJvbSB0aGlzIGV4YW1wbGUgdGhhdCB0 aGUgbnVtYmVyIG9mIHRpbWUtc2xvdHMNCj4gPiA+PiBhdmFpbGFibGUgaXMgZGlmZmVyZW50IGJh c2VkIG9uIHRoZSBzaWduYWwtdHlwZSAoaS5lLiBPRFUxIGFuZCBPRFUyKS4NCj4gPiA+PiBIb3cg ZG8gd2UgYWRkcmVzcyB0aGlzIGlzc3VlIGJhc2VkIG9uIHRoZSBhcHByb2FjaCBzcGVjaWZpZWQg aW4gdGhlDQo+ID4gZHJhZnQ/DQo+ID4gPj4NCj4gPiA+PiBNeSBvdGhlciBxdWVzdGlvbiBpcyB3 aHkgbm90IHNpbXBseSBhZHZlcnRpemUgdGhlIGF2YWlsYWJsZSBudW1iZXIgb2YNCj4gPiA+PiBP RFUwLCBPRFUxLCBPRFUyLCAuLi4sIE9EVTQgY29udGFpbmVyIGluc3RhbmNlcyBvciB0aGUgZXF1 aXZhbGVudA0KPiA+ID4+IGJhbmR3aWR0aCBpbiBieXRlcy9zZWMgd2l0aGluIGEgbGluaz8gVGhp cyBhcHByb2FjaCBzZWVtcyB0byBiZSBtb3JlDQo+ID4gPj4gaW4tbGluZSB3aXRoIHRoZSBnZW5l cmFsIGFwcHJvYWNoIG91dGxpbmVkIGluIFJGQy00MjAyLiBSZWZlciB0bw0KPiA+IHNlY3Rpb24N Cj4gPiA+PiAzLjQgaW4gUkZDIDQyMDIgZm9yIGFuIGV4YW1wbGUgdGhhdCBzaG93cyBtdWx0aXBs ZSBJU0NEcyBiZWluZw0KPiA+ID4+IGFkdmVydGlzZWQgcGVyIFZDIHJhdGUgZm9yIGFuIFNESCBs aW5rLiBUaGUgYWRkaXRpb25hbCBiZW5lZml0IGlzIHRoYXQNCj4gPiA+PiB0aGUgYWR2ZXJ0aXNl bWVudCBpcyBUUyBzaXplIGluZGVwZW5kZW50IGFuZCBoZW5jZSB3aWxsIHNpbXBsaWZ5IHRoZQ0K PiA+ID4+IGltcGxlbWVudGF0aW9uLg0KPiA+ID4+DQo+ID4gPj4gUmVnYXJkcw0KPiA+ID4+DQo+ ID4gPj4gU25pZ2Robw0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gQ0NBTVAgbWFpbGlu ZyBsaXN0DQo+ID4gPj4gQ0NBTVBAaWV0Zi5vcmcgPG1haWx0bzpDQ0FNUEBpZXRmLm9yZz4NCj4g PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ID4gPGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA+DQo+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gQ0NBTVAgbWFp bGluZyBsaXN0DQo+ID4gPiBDQ0FNUEBpZXRmLm9yZyA8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0K PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+IDxo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPg0KPiA+ID4NCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCj4NCj4NCg== From IBryskin@advaoptical.com Mon Jul 19 06:39:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2CA3A689B for ; Mon, 19 Jul 2010 06:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_20=-0.74, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMbSKECQ2jlR for ; Mon, 19 Jul 2010 06:39:49 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 068293A694A for ; Mon, 19 Jul 2010 06:39:48 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6JDddal024774 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 19 Jul 2010 15:39:39 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Jul 2010 15:39:39 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Mon, 19 Jul 2010 15:39:39 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Mon, 19 Jul 2010 09:39:36 -0400 From: Igor Bryskin To: Fatai Zhang , "curtis@occnc.com" Date: Mon, 19 Jul 2010 09:39:34 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6w Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com> <084e01cb23c0$61b58490$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com> <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> In-Reply-To: <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-19_05:2010-07-19, 2010-07-19, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 13:39:51 -0000 Fatai, Please, see my responses on-line. Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Sunday, July 18, 2010 10:49 PM To: Igor Bryskin; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor, Thanks. I understand what you said. Therefore, we have added some text to address t= he requirment in FWK document. However, we still don't think that we need t= o extend ISC to meet the requirment. The role of the ODU can be get from th= e routing information implicitly. In the [draft-ceccarelli-ccamp-gmpls-ospf= -g709-02] draft, a kind of "Full Lambda" is introduced. IB>> This is possible, however: a) this requires OTN specific advertising and processing rules; b) disallows topology separation in technology independent way A quick question on your statement: "the role of an ODU container does not = change hop-by-hop (as some people seem to believe). The role is only meanin= gful on the ODU terminating nodes and irrelevant on transit nodes. It is it= 's position in the hierarchy (but not role) that may change hop-by-hop. " For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 can s= upport Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support Lo ODU2 (= the role is Lo OTN Level). If a connection ODU2 with the role of Ho ODU lev= el is requested, according to your statement, this conneciton will be allo= wed to be created. However, it should not be allowed because the ISC is not= consistent along the LSP. IB>> No, your understanding is not correct. A11 and C11 TE link ends will b= e advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 and B12 - o= nly with a single ISCD: OTN_LO_SC. If the path computation is constrained t= o the OTN_HO_SC topology, B11 and B12 TE links will be disallowed, and the = resulting path (if any) will not go through B11 and B12. If one circumvents= the path computation by providing the fully explicit path, the signaling s= hould fail on node B for the same reason: inconsistency of required (signal= ed) and supported (by local interfaces) switchcap. Please see the text from RFC3473: "Nodes MUST verify that the type indica= ted in the Switching Type parameter is supported on the corresponding inco= ming interface. If the type cannot be supported, the node MUST generate a= PathErr message with a "Routing problem/Switching Type" indication." IB>> Indeed Best Regards Fatai ----- Original Message ----- From: "Igor Bryskin" To: "Fatai Zhang" ; Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; Sent: Friday, July 16, 2010 12:34 AM Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Fatai, Please, see my answers in line. -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 14, 2010 9:52 PM To: Igor Bryskin; curtis@occnc.com Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-ietf-= ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor and all, Thanks for all your comments. I think role does not equal switching capability. The operators can define = different roles depending on their policy and achieve the role through diff= erent methods. However, for OTN networks, the containers (e.g., ODUk) all h= ave the same switching capablility (i.e., TDM switching) and I think we sho= uld reflect the natural characteristics of links in the routing. In additio= n, if we extend the ISC, it will make the encoding type lose its' own meani= ng(ie., ISC overrides encoding type). IB>> When a GMPLS CP instance controls several layers, it views the network= as a stack of topologies. Whether a given topology is real or virtual is o= f no importance. The GMPLS ISCD link sub-tlv and, in particular, its switching capability fi= eld (confusing name as it is) is a good way to describe a layer in technolo= gy independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM lay= er stack could be perceived as a stack of topologies that could be easily s= eparated in technology independent way should path computation be constrain= ed to particular one or sub-stack of them. I think a good way to identify an OTN (virtual) topology is via (infrastruc= ture) ODU container role of ODUs comprising the topology. BTW IMO the role = of an ODU container does not change hop-by-hop (as some people seem to beli= eve). The role is only meaningful on the ODU terminating nodes and irreleva= nt on transit nodes. It is it's position in the hierarchy (but not role) th= at may change hop-by-hop. ODU's role is the level of topology it is provisi= oned for and it is the same for all ODUs that comprise the topology. For, e= xample a user may provision a LO topology and constrain ODUs he sells to a = set of clients to use the topology rather than any resources available on O= TN network. The bottom line: container's role is the same as the role of virtual topolo= gy the container is a part of and could be advertised as the corresponding = link switchcap. According to the point 3, I don't know how to advertise the roles and muxin= g capabilities with the ISCD of RFC4202, could you clarify? IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) encoding type =3D mux. capabilities code In addition, could you clarify my questions in another email (copied as fol= lows): =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. IB>> I disagree. You define role =3D=3D position in the hierarchy, which is= a mistake IMO. For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN L= evel or Lo OTN Level? Another example is, if there is a OTU3 link supportin= g ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly)= and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate i= f this ODU2 is Lo OTN Level or Ho OTN Level? IB>> As I mentioned earlier, ODU role is only important on the ODU terminat= ing nodes (i.e. on either side of corresponding link). What happens on the = ODU transit nodes and its place in the hierarchy on the transit nodes are o= f no importance. My LO container can be carried by somebody else's LO conta= iner and can carry my client's LO container. To some extent it is similar t= o MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it coul= d be anywhere in MPLS stack along its path. Cheers, Igor =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks Fatai ----- Original Message ----- From: "Igor Bryskin" To: Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; Sent: Wednesday, July 14, 2010 10:36 PM Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Curtis, Thanks for your comment. I agree that there should be multiple OTN specific encoding types introduce= d. But IMO they should indicate the link's mux capabilities rather than the= link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link= 's role or roles IMO should be indicated with a separate switchcaps. I can = give you several reasons: 1. Links with the same mux capabilities may have different roles; 2. Link may advertise several roles (e.g. HO and SHO) with different mux.ca= pabilities per role; 3. Link's role and mux. capabilities can be advertised with ISCDs as define= d in RFC4202 (no OTN-style ISCD is required); 4. The combination of swicthcaps and encoding type will look to CP as a sep= arate layer, which is exactly how ITU models OTN hierarchies in all aspects= but routing (!?) 5. If the operator would want to constrain the routing of OTN connections t= o pre-configured topology with a specific role (e.g. constrain all ODUs it = sells to the clients to one or more pre-configured LO topologies), this wou= ld be possible to do in a technology independent way. Suppose an instance o= f GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links= will be no different from the separation of WDM links from OTUs. Cheers, Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Tuesday, July 13, 2010 6:24 PM To: Igor Bryskin Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org= ; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > > I think OTN links require more than one switchcaps: as many as the depth = of the deepest possible OTN DP hierarchy, for example: > > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ > > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; It would be better IMHO to keep the Switch Type as TDM and make the Encoding Type OTN_LO, OTN_HO or OTN_SHO. This would replace the 20006 OTN Encoding Type for G.709 Digital Path layer and G.709 Optical Channel layer for 2009 OTN, which had in turn replaced the Encoding Type of "Digital Wrapper" a long time ago. Replacing the Encoding Type would insure that any LSR that did not understand what the TS type meant did not try to multiplex its LO ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to using a 1.25 TS granularity for another LO ODU. It could also be stated that if an LSR advertises OTN_LO, OTN_HO or OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter is for backward compatibility and should be ignored if OTN_LO, OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, then the corresponding G.709 Digital Path FA can be withdrawn. The Encoding type would be the lower encoding at each end of the LSP regardless of what goes on in the middle since that determines what can be wrapped inside it. For example: OTU3 OTU2 ODUk=3D3 -------------- OTU1 ODUk=3D2 -- ODUj=3D2 ODUk=3D1 --- ODUj=3D1 -- This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex even though the ODUk=3D2 at the next hop could not directly contain an ODU0. If the SHO Encoding Type is used, then it indicates that two levels of multiplexing could be supported at that switch/LSR. The nominal bytes/sec rates can still be provided. RFC 4328 Switch Types currently don't include an ODUj or ODUk distinction but if Encoding Type indicated LO or HO, that may not be needed. Along with the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, and ODU2e, can be added. btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear how in an FA it can be indicated that either type is currently available (NE capable of both and hasn't committed to either one yet). BTW- Maybe I'm missing something but the number of messages on this would indicate a huge controversy and I'm not getting it (other than a strong preference to rely on bytes/sec or on enumerated type fields). draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other intent. Could someone (either draft) concisely summarize the multiplexing restrictions in one place, including restrictions on number of multiplexing layers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > What do you mean by "different switchcaps"? > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of > > Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework document > > before we can embark on any proposals to the problem. I am still not cl= ear > > why do we have to deviate from the general approach that has been > > established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, a= nd > > it is highly desirable to adhere to the layer independent paradigm of > > advertising of TE links, and there is no reason to invent an OTN specif= ic > > ISCD. The combination of Switching Capability and Encoding type of RFC4= 202 > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order container= s. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > hierarchies and constrain LO connections to HO containers, one needs to > > advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasibl= e > > for OTN networks. > > > > > > > > The framework draft just tells you what information needed for control > > plane, no matter how you encode the routing information. For TDM networ= ks, > > you know the resource is allocated based on TS, so the available TS sho= uld > > be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I thin= k > > you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you will f= ind > > that one of your suggestions is adopted (i.e., simply advertize the > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU= 1, > > you have to advertise a new TE link or put this FA as a component link = of > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course one = of > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > draft and discussion contributors on there progress on this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service rout= ing > > >> purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, consider = an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time the O= TU3 > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > >> time-slots available for ODU1 services (4 ODU1s are contained over t= he > > >> ODU2). So it is obvious from this example that the number of time-sl= ots > > >> available is different based on the signal-type (i.e. ODU1 and ODU2)= . > > >> How do we address this issue based on the approach specified in the > > draft? > > >> > > >> My other question is why not simply advertize the available number o= f > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > >> in-line with the general approach outlined in RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is th= at > > >> the advertisement is TS size independent and hence will simplify the > > >> implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Mon Jul 19 07:32:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134363A699A for ; Mon, 19 Jul 2010 07:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-3.507, BAYES_40=-0.185, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2hrnXYlGCi7 for ; Mon, 19 Jul 2010 07:31:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 52C323A69F1 for ; Mon, 19 Jul 2010 07:31:39 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-f6-4c4461d8351f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.8B.06895.8D1644C4; Mon, 19 Jul 2010 16:31:53 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 16:31:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2010 16:31:27 +0200 Message-ID: In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOA= References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> From: "Daniele Ceccarelli" To: "Igor Bryskin" , "Fatai Zhang" , X-OriginalArrivalTime: 19 Jul 2010 14:31:52.0410 (UTC) FILETIME=[21428BA0:01CB274F] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 14:32:00 -0000 Hi Igor, I didn't understand if you're proposing to (a) send an ISCD per role = (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. In case (a) you're still missing a lot of information. For each role you = would advertise just the unreserved bandwidth but you wouldn't know if = such bandwidth is available for a certain type of ODUj LSP (e.g. 15 Gbps = available on 3 component links: you advertise 45 Gbps available but no = ODU3 can be set up on such TE link). In case (b) the number of ISCDs would cause serious scalability issues = and the requirement of being able to bundle component links together = wouldn't be satisfied. Cheers, Daniele=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Igor Bryskin Sent: luned=EC 19 luglio 2010 15.40 To: Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Fatai, Please, see my responses on-line. Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Fatai Zhang Sent: Sunday, July 18, 2010 10:49 PM To: Igor Bryskin; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Hi Igor, Thanks. I understand what you said. Therefore, we have added some text to = address the requirment in FWK document. However, we still don't think = that we need to extend ISC to meet the requirment. The role of the ODU = can be get from the routing information implicitly. In the = [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full = Lambda" is introduced. IB>> This is possible, however: a) this requires OTN specific advertising and processing rules; b) disallows topology separation in technology independent way A quick question on your statement: "the role of an ODU container does = not change hop-by-hop (as some people seem to believe). The role is only = meaningful on the ODU terminating nodes and irrelevant on transit nodes. = It is it's position in the hierarchy (but not role) that may change = hop-by-hop. " For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 = can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support = Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role = of Ho ODU level is requested, according to your statement, this = conneciton will be allowed to be created. However, it should not be = allowed because the ISC is not consistent along the LSP. IB>> No, your understanding is not correct. A11 and C11 TE link ends = will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 = and B12 - only with a single ISCD: OTN_LO_SC. If the path computation is = constrained to the OTN_HO_SC topology, B11 and B12 TE links will be = disallowed, and the resulting path (if any) will not go through B11 and = B12. If one circumvents the path computation by providing the fully = explicit path, the signaling should fail on node B for the same reason: = inconsistency of required (signaled) and supported (by local interfaces) = switchcap. Please see the text from RFC3473: "Nodes MUST verify that the type = indicated in the Switching Type parameter is supported on the = corresponding incoming interface. If the type cannot be supported, the = node MUST generate a PathErr message with a "Routing problem/Switching = Type" indication." IB>> Indeed Best Regards Fatai ----- Original Message ----- From: "Igor Bryskin" To: "Fatai Zhang" ; Cc: "John E Drake" ; "Snigdho Bardalai" = ; "Lou Berger" ; = ; Sent: Friday, July 16, 2010 12:34 AM Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Fatai, Please, see my answers in line. -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 14, 2010 9:52 PM To: Igor Bryskin; curtis@occnc.com Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Hi Igor and all, Thanks for all your comments. I think role does not equal switching capability. The operators can = define different roles depending on their policy and achieve the role = through different methods. However, for OTN networks, the containers = (e.g., ODUk) all have the same switching capablility (i.e., TDM = switching) and I think we should reflect the natural characteristics of = links in the routing. In addition, if we extend the ISC, it will make = the encoding type lose its' own meaning(ie., ISC overrides encoding = type). IB>> When a GMPLS CP instance controls several layers, it views the = network as a stack of topologies. Whether a given topology is real or = virtual is of no importance. The GMPLS ISCD link sub-tlv and, in particular, its switching capability = field (confusing name as it is) is a good way to describe a layer in = technology independent way, so that, say, = MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM layer stack could be perceived as = a stack of topologies that could be easily separated in technology = independent way should path computation be constrained to particular one = or sub-stack of them. I think a good way to identify an OTN (virtual) topology is via = (infrastructure) ODU container role of ODUs comprising the topology. BTW = IMO the role of an ODU container does not change hop-by-hop (as some = people seem to believe). The role is only meaningful on the ODU = terminating nodes and irrelevant on transit nodes. It is it's position = in the hierarchy (but not role) that may change hop-by-hop. ODU's role = is the level of topology it is provisioned for and it is the same for = all ODUs that comprise the topology. For, example a user may provision a = LO topology and constrain ODUs he sells to a set of clients to use the = topology rather than any resources available on OTN network. The bottom line: container's role is the same as the role of virtual = topology the container is a part of and could be advertised as the = corresponding link switchcap. According to the point 3, I don't know how to advertise the roles and = muxing capabilities with the ISCD of RFC4202, could you clarify? IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) encoding type =3D mux. capabilities code In addition, could you clarify my questions in another email (copied as = follows): =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. IB>> I disagree. You define role =3D=3D position in the hierarchy, which = is a mistake IMO. For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho = OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link = supporting ODU2 switching, which can be used as Lo ODU2 (service over = ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how = to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? IB>> As I mentioned earlier, ODU role is only important on the ODU = terminating nodes (i.e. on either side of corresponding link). What = happens on the ODU transit nodes and its place in the hierarchy on the = transit nodes are of no importance. My LO container can be carried by = somebody else's LO container and can carry my client's LO container. To = some extent it is similar to MPLS LSP role: LSP always has a role (e.g. = PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its = path. Cheers, Igor =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks Fatai ----- Original Message ----- From: "Igor Bryskin" To: Cc: "John E Drake" ; "Snigdho Bardalai" = ; "Fatai Zhang" ; "Lou = Berger" ; ; = Sent: Wednesday, July 14, 2010 10:36 PM Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Curtis, Thanks for your comment. I agree that there should be multiple OTN specific encoding types = introduced. But IMO they should indicate the link's mux capabilities = rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, = SHO, etc.). The link's role or roles IMO should be indicated with a = separate switchcaps. I can give you several reasons: 1. Links with the same mux capabilities may have different roles; 2. = Link may advertise several roles (e.g. HO and SHO) with different = mux.capabilities per role; 3. Link's role and mux. capabilities can be = advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is = required); 4. The combination of swicthcaps and encoding type will look = to CP as a separate layer, which is exactly how ITU models OTN = hierarchies in all aspects but routing (!?) 5. If the operator would = want to constrain the routing of OTN connections to pre-configured = topology with a specific role (e.g. constrain all ODUs it sells to the = clients to one or more pre-configured LO topologies), this would be = possible to do in a technology independent way. Suppose an instance of = GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN = links will be no different from the separation of WDM links from OTUs. Cheers, Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Tuesday, July 13, 2010 6:24 PM To: Igor Bryskin Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; = ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt In message = <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical= .com> Igor Bryskin writes: > > I think OTN links require more than one switchcaps: as many as the = depth of the deepest possible OTN DP hierarchy, for example: > > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ > > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; It would be better IMHO to keep the Switch Type as TDM and make the = Encoding Type OTN_LO, OTN_HO or OTN_SHO. This would replace the 20006 OTN Encoding Type for G.709 Digital Path = layer and G.709 Optical Channel layer for 2009 OTN, which had in turn = replaced the Encoding Type of "Digital Wrapper" a long time ago. Replacing the Encoding Type would insure that any LSR that did not = understand what the TS type meant did not try to multiplex its LO ODU at = TS granularity 2.5 onto a HO ODU that had alraedy commited to using a = 1.25 TS granularity for another LO ODU. It could also be stated that if an LSR advertises OTN_LO, OTN_HO or = OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter = is for backward compatibility and should be ignored if OTN_LO, OTN_HO or = OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, then = the corresponding G.709 Digital Path FA can be withdrawn. The Encoding type would be the lower encoding at each end of the LSP = regardless of what goes on in the middle since that determines what can = be wrapped inside it. For example: OTU3 OTU2 ODUk=3D3 -------------- OTU1 ODUk=3D2 -- ODUj=3D2 ODUk=3D1 --- ODUj=3D1 -- This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex = even though the ODUk=3D2 at the next hop could not directly contain an = ODU0. If the SHO Encoding Type is used, then it indicates that two levels of = multiplexing could be supported at that switch/LSR. The nominal bytes/sec rates can still be provided. RFC 4328 Switch = Types currently don't include an ODUj or ODUk distinction but if = Encoding Type indicated LO or HO, that may not be needed. Along with = the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, and = ODU2e, can be added. btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear = how in an FA it can be indicated that either type is currently available = (NE capable of both and hasn't committed to either one yet). BTW- Maybe I'm missing something but the number of messages on this = would indicate a huge controversy and I'm not getting it (other than a = strong preference to rely on bytes/sec or on enumerated type fields). draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if = the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or = other intent. Could someone (either draft) concisely summarize the = multiplexing restrictions in one place, including restrictions on number = of multiplexing layers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > What do you mean by "different switchcaps"? > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > > Behalf Of Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org;=20 > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on=20 > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework=20 > > document before we can embark on any proposals to the problem. I am=20 > > still not clear why do we have to deviate from the general approach=20 > > that has been established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control=20 > > IB>> plane, and > > it is highly desirable to adhere to the layer independent paradigm=20 > > of advertising of TE links, and there is no reason to invent an OTN=20 > > specific ISCD. The combination of Switching Capability and Encoding=20 > > type of RFC4202 ISCD allows for specifying both multiplexing=20 > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if=20 > > this not sufficient, you have another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order = containers. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create=20 > > IB>> OTN > > hierarchies and constrain LO connections to HO containers, one needs = > > to advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org;=20 > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on=20 > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other=20 > > interested experts, and we think the proposal described in "draft-=20 > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more=20 > > feasible for OTN networks. > > > > > > > > The framework draft just tells you what information needed for=20 > > control plane, no matter how you encode the routing information. For = > > TDM networks, you know the resource is allocated based on TS, so the = > > available TS should be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I=20 > > think you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you=20 > > will find that one of your suggestions is adopted (i.e., simply=20 > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 = container instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for=20 > > ODU1, you have to advertise a new TE link or put this FA as a=20 > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >;=20 > > > > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on=20 > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ;=20 > > > draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on=20 > > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better = > > > align the work with 4202. Use of common approaches is of course=20 > > > one of the main objectives of *C*CAMP. I look forward to hearing=20 > > > from the draft and discussion contributors on there progress on = this point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section=20 > > >> describes the link-parameters that are required for OTN service=20 > > >> routing purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj=20 > > >> availability within a higher-order container. For example,=20 > > >> consider an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we = > > >> establish an ODU2 service over the link. At this point in time=20 > > >> the OTU3 link has 12 time-slots available for ODU2 services and=20 > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s are=20 > > >> contained over the ODU2). So it is obvious from this example that = > > >> the number of time-slots available is different based on the = signal-type (i.e. ODU1 and ODU2). > > >> How do we address this issue based on the approach specified in=20 > > >> the > > draft? > > >> > > >> My other question is why not simply advertize the available=20 > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or the=20 > > >> equivalent bandwidth in bytes/sec within a link? This approach=20 > > >> seems to be more in-line with the general approach outlined in=20 > > >> RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being=20 > > >> advertised per VC rate for an SDH link. The additional benefit is = > > >> that the advertisement is TS size independent and hence will=20 > > >> simplify the implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org =20 > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org =20 > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Mon Jul 19 07:43:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9FC3A67C3 for ; Mon, 19 Jul 2010 07:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DjQne6WbnJ5 for ; Mon, 19 Jul 2010 07:43:11 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 029063A6990 for ; Mon, 19 Jul 2010 07:43:10 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6JEhEc3016197 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 19 Jul 2010 16:43:14 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Jul 2010 16:43:14 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Mon, 19 Jul 2010 10:43:11 -0400 From: Igor Bryskin To: Daniele Ceccarelli , Fatai Zhang , "curtis@occnc.com" Date: Mon, 19 Jul 2010 10:42:58 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-19_06:2010-07-19, 2010-07-19, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 14:43:13 -0000 Daniele, Please, see in line. Cheers, Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Monday, July 19, 2010 10:31 AM To: Igor Bryskin; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor, I didn't understand if you're proposing to (a) send an ISCD per role (i.e. = OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. IB>> in ISCD: switchCap =3D role; encodeType =3D muxCap & signal type; We also have 16 reserved bits which can use for OTN specific info in case w= e need it. In case (a) you're still missing a lot of information. For each role you wo= uld advertise just the unreserved bandwidth but you wouldn't know if such b= andwidth is available for a certain type of ODUj LSP (e.g. 15 Gbps availabl= e on 3 component links: you advertise 45 Gbps available but no ODU3 can be = set up on such TE link). In case (b) the number of ISCDs would cause serious scalability issues and = the requirement of being able to bundle component links together wouldn't b= e satisfied. IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will provid= e a lot of flexibility: you can specify different things (e.g. available ba= ndwidth) for the same link in different roles. Cheers, Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: luned=EC 19 luglio 2010 15.40 To: Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Fatai, Please, see my responses on-line. Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Sunday, July 18, 2010 10:49 PM To: Igor Bryskin; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor, Thanks. I understand what you said. Therefore, we have added some text to address t= he requirment in FWK document. However, we still don't think that we need t= o extend ISC to meet the requirment. The role of the ODU can be get from th= e routing information implicitly. In the [draft-ceccarelli-ccamp-gmpls-ospf= -g709-02] draft, a kind of "Full Lambda" is introduced. IB>> This is possible, however: a) this requires OTN specific advertising and processing rules; b) disallows topology separation in technology independent way A quick question on your statement: "the role of an ODU container does not = change hop-by-hop (as some people seem to believe). The role is only meanin= gful on the ODU terminating nodes and irrelevant on transit nodes. It is it= 's position in the hierarchy (but not role) that may change hop-by-hop. " For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 can s= upport Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support Lo ODU2 (= the role is Lo OTN Level). If a connection ODU2 with the role of Ho ODU lev= el is requested, according to your statement, this conneciton will be allo= wed to be created. However, it should not be allowed because the ISC is not= consistent along the LSP. IB>> No, your understanding is not correct. A11 and C11 TE link ends will b= e advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 and B12 - o= nly with a single ISCD: OTN_LO_SC. If the path computation is constrained t= o the OTN_HO_SC topology, B11 and B12 TE links will be disallowed, and the = resulting path (if any) will not go through B11 and B12. If one circumvents= the path computation by providing the fully explicit path, the signaling s= hould fail on node B for the same reason: inconsistency of required (signal= ed) and supported (by local interfaces) switchcap. Please see the text from RFC3473: "Nodes MUST verify that the type indica= ted in the Switching Type parameter is supported on the corresponding inco= ming interface. If the type cannot be supported, the node MUST generate a= PathErr message with a "Routing problem/Switching Type" indication." IB>> Indeed Best Regards Fatai ----- Original Message ----- From: "Igor Bryskin" To: "Fatai Zhang" ; Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; Sent: Friday, July 16, 2010 12:34 AM Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Fatai, Please, see my answers in line. -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Wednesday, July 14, 2010 9:52 PM To: Igor Bryskin; curtis@occnc.com Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-ietf-= ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor and all, Thanks for all your comments. I think role does not equal switching capability. The operators can define = different roles depending on their policy and achieve the role through diff= erent methods. However, for OTN networks, the containers (e.g., ODUk) all h= ave the same switching capablility (i.e., TDM switching) and I think we sho= uld reflect the natural characteristics of links in the routing. In additio= n, if we extend the ISC, it will make the encoding type lose its' own meani= ng(ie., ISC overrides encoding type). IB>> When a GMPLS CP instance controls several layers, it views the network= as a stack of topologies. Whether a given topology is real or virtual is o= f no importance. The GMPLS ISCD link sub-tlv and, in particular, its switching capability fi= eld (confusing name as it is) is a good way to describe a layer in technolo= gy independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM lay= er stack could be perceived as a stack of topologies that could be easily s= eparated in technology independent way should path computation be constrain= ed to particular one or sub-stack of them. I think a good way to identify an OTN (virtual) topology is via (infrastruc= ture) ODU container role of ODUs comprising the topology. BTW IMO the role = of an ODU container does not change hop-by-hop (as some people seem to beli= eve). The role is only meaningful on the ODU terminating nodes and irreleva= nt on transit nodes. It is it's position in the hierarchy (but not role) th= at may change hop-by-hop. ODU's role is the level of topology it is provisi= oned for and it is the same for all ODUs that comprise the topology. For, e= xample a user may provision a LO topology and constrain ODUs he sells to a = set of clients to use the topology rather than any resources available on O= TN network. The bottom line: container's role is the same as the role of virtual topolo= gy the container is a part of and could be advertised as the corresponding = link switchcap. According to the point 3, I don't know how to advertise the roles and muxin= g capabilities with the ISCD of RFC4202, could you clarify? IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) encoding type =3D mux. capabilities code In addition, could you clarify my questions in another email (copied as fol= lows): =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. IB>> I disagree. You define role =3D=3D position in the hierarchy, which is= a mistake IMO. For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN L= evel or Lo OTN Level? Another example is, if there is a OTU3 link supportin= g ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly)= and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate i= f this ODU2 is Lo OTN Level or Ho OTN Level? IB>> As I mentioned earlier, ODU role is only important on the ODU terminat= ing nodes (i.e. on either side of corresponding link). What happens on the = ODU transit nodes and its place in the hierarchy on the transit nodes are o= f no importance. My LO container can be carried by somebody else's LO conta= iner and can carry my client's LO container. To some extent it is similar t= o MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it coul= d be anywhere in MPLS stack along its path. Cheers, Igor =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks Fatai ----- Original Message ----- From: "Igor Bryskin" To: Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; Sent: Wednesday, July 14, 2010 10:36 PM Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Curtis, Thanks for your comment. I agree that there should be multiple OTN specific encoding types introduce= d. But IMO they should indicate the link's mux capabilities rather than the= link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link= 's role or roles IMO should be indicated with a separate switchcaps. I can = give you several reasons: 1. Links with the same mux capabilities may have different roles; 2. Link m= ay advertise several roles (e.g. HO and SHO) with different mux.capabilitie= s per role; 3. Link's role and mux. capabilities can be advertised with ISC= Ds as defined in RFC4202 (no OTN-style ISCD is required); 4. The combinatio= n of swicthcaps and encoding type will look to CP as a separate layer, whic= h is exactly how ITU models OTN hierarchies in all aspects but routing (!?)= 5. If the operator would want to constrain the routing of OTN connections = to pre-configured topology with a specific role (e.g. constrain all ODUs it= sells to the clients to one or more pre-configured LO topologies), this wo= uld be possible to do in a technology independent way. Suppose an instance = of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN link= s will be no different from the separation of WDM links from OTUs. Cheers, Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Tuesday, July 13, 2010 6:24 PM To: Igor Bryskin Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org= ; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > > I think OTN links require more than one switchcaps: as many as the depth = of the deepest possible OTN DP hierarchy, for example: > > typedef enum > { > LSPSwitchType_Unknown =3D0 /* Unknown */ > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > , LSPSwitchType_L2SC =3D50 /* L2SC */ > , LSPSwitchType_TDM =3D100 /* TDM */ > > /*****/ > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > , LSPSwitchType_LSC =3D150 /* LSC */ > , LSPSwitchType_FSC =3D200 /* FSC */ > }e_LSPSwitchType; It would be better IMHO to keep the Switch Type as TDM and make the Encodin= g Type OTN_LO, OTN_HO or OTN_SHO. This would replace the 20006 OTN Encoding Type for G.709 Digital Path layer= and G.709 Optical Channel layer for 2009 OTN, which had in turn replaced t= he Encoding Type of "Digital Wrapper" a long time ago. Replacing the Encoding Type would insure that any LSR that did not understa= nd what the TS type meant did not try to multiplex its LO ODU at TS granula= rity 2.5 onto a HO ODU that had alraedy commited to using a 1.25 TS granula= rity for another LO ODU. It could also be stated that if an LSR advertises OTN_LO, OTN_HO or OTN_SHO= FA, and also advertises G.709 Digital Path FA, then the latter is for back= ward compatibility and should be ignored if OTN_LO, OTN_HO or OTN_SHO is un= derstood. If the LSR commits to 1.25 TS granularity, then the correspondin= g G.709 Digital Path FA can be withdrawn. The Encoding type would be the lower encoding at each end of the LSP regard= less of what goes on in the middle since that determines what can be wrappe= d inside it. For example: OTU3 OTU2 ODUk=3D3 -------------- OTU1 ODUk=3D2 -- ODUj=3D2 ODUk=3D1 --- ODUj=3D1 -- This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex even= though the ODUk=3D2 at the next hop could not directly contain an ODU0. If the SHO Encoding Type is used, then it indicates that two levels of mult= iplexing could be supported at that switch/LSR. The nominal bytes/sec rates can still be provided. RFC 4328 Switch Types c= urrently don't include an ODUj or ODUk distinction but if Encoding Type ind= icated LO or HO, that may not be needed. Along with the new Encoding Type = new Signal Types for ODU0, ODU4, and ODU-flex, and ODU2e, can be added. btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear how = in an FA it can be indicated that either type is currently available (NE ca= pable of both and hasn't committed to either one yet). BTW- Maybe I'm missing something but the number of messages on this would i= ndicate a huge controversy and I'm not getting it (other than a strong pref= erence to rely on bytes/sec or on enumerated type fields). draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if the = intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or other int= ent. Could someone (either draft) concisely summarize the multiplexing res= trictions in one place, including restrictions on number of multiplexing la= yers at one LSR. That might help. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 08, 2010 1:59 PM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > Cc: ccamp@ietf.org; > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: RE: [CCAMP] Comment on > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > What do you mean by "different switchcaps"? > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf Of Igor Bryskin > > Sent: Thursday, July 08, 2010 10:53 AM > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Snigdho, > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > document before we can embark on any proposals to the problem. I am > > still not clear why do we have to deviate from the general approach > > that has been established in RFC 4202. > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > IB>> plane, and > > it is highly desirable to adhere to the layer independent paradigm > > of advertising of TE links, and there is no reason to invent an OTN > > specific ISCD. The combination of Switching Capability and Encoding > > type of RFC4202 ISCD allows for specifying both multiplexing > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > this not sufficient, you have another reserved 16 bits. > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > represent >the low-order ODUj bandwidth within the high-order container= s. > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > IB>> OTN > > hierarchies and constrain LO connections to HO containers, one needs > > to advertise OTN links with different switchcaps. > > > > > > > > Cheers, > > > > Igor > > > > > > > > Regards > > > > Snigdho > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 07, 2010 6:33 PM > > To: Snigdho Bardalai; Lou Berger > > Cc: ccamp@ietf.org; > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > Hi Snigdho and Lou, > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > interested experts, and we think the proposal described in "draft- > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible for OTN networks. > > > > > > > > The framework draft just tells you what information needed for > > control plane, no matter how you encode the routing information. For > > TDM networks, you know the resource is allocated based on TS, so the > > available TS should be get or induced before creating cross-connect. > > > > > > > > If you are trying to find how to encode the routing information, I > > think you need go to the routing drafts (info model and encoding). > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will find that one of your suggestions is adopted (i.e., simply > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 container= instances). > > > > > > > > One more thing for your first comment: > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > ODU1, you have to advertise a new TE link or put this FA as a > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > ----- Original Message ----- > > > > From: "Snigdho Bardalai" > > > > > > To: "Lou Berger" > > > > > Cc: >; > > > > framework@tools.ietf.org> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > Subject: Re: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > > > > Hi Lou > > > > > > Thanks, I also would like to hear about the same. > > > > > > Snigdho > > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > To: Snigdho Bardalai > > > Cc: ccamp@ietf.org ; > > > draft-ietf-ccamp-gmpls- > > g709-framework@tools.ietf.org > framework@tools.ietf.org> > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > Snigdho, > > > I believe there has been some off-line discussion on how to better > > > align the work with 4202. Use of common approaches is of course > > > one of the main objectives of *C*CAMP. I look forward to hearing > > > from the draft and discussion contributors on there progress on this = point. > > > > > > Lou > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > >> Hello, > > >> > > >> I have a comment and a question on Section 3.1.2.1. This section > > >> describes the link-parameters that are required for OTN service > > >> routing purposes. > > >> > > >> My comment is how are we going to advertise the low-order ODUj > > >> availability within a higher-order container. For example, > > >> consider an > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > >> establish an ODU2 service over the link. At this point in time > > >> the OTU3 link has 12 time-slots available for ODU2 services and > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s are > > >> contained over the ODU2). So it is obvious from this example that > > >> the number of time-slots available is different based on the signal-= type (i.e. ODU1 and ODU2). > > >> How do we address this issue based on the approach specified in > > >> the > > draft? > > >> > > >> My other question is why not simply advertize the available > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > >> equivalent bandwidth in bytes/sec within a link? This approach > > >> seems to be more in-line with the general approach outlined in > > >> RFC-4202. Refer to > > section > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > >> advertised per VC rate for an SDH link. The additional benefit is > > >> that the advertisement is TS size independent and hence will > > >> simplify the implementation. > > >> > > >> Regards > > >> > > >> Snigdho > > >> > > >> > > >> > > >> _______________________________________________ > > >> CCAMP mailing list > > >> CCAMP@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Mon Jul 19 08:33:48 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9663A6B38 for ; Mon, 19 Jul 2010 08:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_20=-0.74, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bWPxAYzusAK for ; Mon, 19 Jul 2010 08:32:53 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 903963A6B3A for ; Mon, 19 Jul 2010 08:30:53 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Mon, 19 Jul 2010 08:30:46 -0700 From: Snigdho Bardalai To: Igor Bryskin , Daniele Ceccarelli , Fatai Zhang , "curtis@occnc.com" Date: Mon, 19 Jul 2010 08:30:44 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6Og Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:33:58 -0000 Igor Please see inline. Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 7:43 AM > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Daniele, > > Please, see in line. > > Cheers, > Igor > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Monday, July 19, 2010 10:31 AM > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor, > > I didn't understand if you're proposing to (a) send an ISCD per role > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > IB>> in ISCD: > switchCap =3D role; > encodeType =3D muxCap & signal type; > We also have 16 reserved bits which can use for OTN specific info in > case we need it. [SCB] I am yet to clearly understand what the role of "role" is, but agree = with your observation on the encode-type and the 16 reserved-bits to furthe= r classify the switching information. > > In case (a) you're still missing a lot of information. For each role > you would advertise just the unreserved bandwidth but you wouldn't know > if such bandwidth is available for a certain type of ODUj LSP (e.g. 15 > Gbps available on 3 component links: you advertise 45 Gbps available > but no ODU3 can be set up on such TE link). > > In case (b) the number of ISCDs would cause serious scalability issues > and the requirement of being able to bundle component links together > wouldn't be satisfied. > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > provide a lot of flexibility: you can specify different things (e.g. > available bandwidth) for the same link in different roles. [SCB] Are you saying the ISCD as defined today with minor extensions (i.e. = to further classify the information) will be sufficient? > > Cheers, > Daniele > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: luned=EC 19 luglio 2010 15.40 > To: Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Fatai, > > Please, see my responses on-line. > > Cheers, > Igor > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Fatai Zhang > Sent: Sunday, July 18, 2010 10:49 PM > To: Igor Bryskin; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor, > > Thanks. > I understand what you said. Therefore, we have added some text to > address the requirment in FWK document. However, we still don't think > that we need to extend ISC to meet the requirment. The role of the ODU > can be get from the routing information implicitly. In the [draft- > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" is > introduced. > > IB>> This is possible, however: > a) this requires OTN specific advertising and processing rules; > b) disallows topology separation in technology independent way > > A quick question on your statement: "the role of an ODU container does > not change hop-by-hop (as some people seem to believe). The role is > only meaningful on the ODU terminating nodes and irrelevant on transit > nodes. It is it's position in the hierarchy (but not role) that may > change hop-by-hop. " > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > of Ho ODU level is requested, according to your statement, this > conneciton will be allowed to be created. However, it should not be > allowed because the ISC is not consistent along the LSP. > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 > and B12 - only with a single ISCD: OTN_LO_SC. If the path computation > is constrained to the OTN_HO_SC topology, B11 and B12 TE links will be > disallowed, and the resulting path (if any) will not go through B11 and > B12. If one circumvents the path computation by providing the fully > explicit path, the signaling should fail on node B for the same reason: > inconsistency of required (signaled) and supported (by local > interfaces) switchcap. > > Please see the text from RFC3473: "Nodes MUST verify that the type > indicated in the Switching Type parameter is supported on the > corresponding incoming interface. If the type cannot be supported, > the node MUST generate a PathErr message with a "Routing > problem/Switching Type" indication." > IB>> Indeed > > > > > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: "Fatai Zhang" ; > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Lou Berger" ; > ; framework@tools.ietf.org> > Sent: Friday, July 16, 2010 12:34 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > Fatai, > Please, see my answers in line. > > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 14, 2010 9:52 PM > To: Igor Bryskin; curtis@occnc.com > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft- > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor and all, > > Thanks for all your comments. > > I think role does not equal switching capability. The operators can > define different roles depending on their policy and achieve the role > through different methods. However, for OTN networks, the containers > (e.g., ODUk) all have the same switching capablility (i.e., TDM > switching) and I think we should reflect the natural characteristics of > links in the routing. In addition, if we extend the ISC, it will make > the encoding type lose its' own meaning(ie., ISC overrides encoding > type). > > IB>> When a GMPLS CP instance controls several layers, it views the > network as a stack of topologies. Whether a given topology is real or > virtual is of no importance. > The GMPLS ISCD link sub-tlv and, in particular, its switching > capability field (confusing name as it is) is a good way to describe a > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > topologies that could be easily separated in technology independent way > should path computation be constrained to particular one or sub-stack > of them. > I think a good way to identify an OTN (virtual) topology is via > (infrastructure) ODU container role of ODUs comprising the topology. > BTW IMO the role of an ODU container does not change hop-by-hop (as > some people seem to believe). The role is only meaningful on the ODU > terminating nodes and irrelevant on transit nodes. It is it's position > in the hierarchy (but not role) that may change hop-by-hop. ODU's role > is the level of topology it is provisioned for and it is the same for > all ODUs that comprise the topology. For, example a user may provision > a LO topology and constrain ODUs he sells to a set of clients to use > the topology rather than any resources available on OTN network. > The bottom line: container's role is the same as the role of virtual > topology the container is a part of and could be advertised as the > corresponding link switchcap. > > According to the point 3, I don't know how to advertise the roles and > muxing capabilities with the ISCD of RFC4202, could you clarify? > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > encoding type =3D mux. capabilities code > > In addition, could you clarify my questions in another email (copied as > follows): > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > IB>> I disagree. You define role =3D=3D position in the hierarchy, which = is > a mistake IMO. > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link > supporting ODU2 switching, which can be used as Lo ODU2 (service over > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > IB>> As I mentioned earlier, ODU role is only important on the ODU > terminating nodes (i.e. on either side of corresponding link). What > happens on the ODU transit nodes and its place in the hierarchy on the > transit nodes are of no importance. My LO container can be carried by > somebody else's LO container and can carry my client's LO container. To > some extent it is similar to MPLS LSP role: LSP always has a role (e.g. > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > path. > > Cheers, > Igor > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Thanks > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Fatai Zhang" ; "Lou > Berger" ; ; g709-framework@tools.ietf.org> > Sent: Wednesday, July 14, 2010 10:36 PM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > Curtis, > > Thanks for your comment. > > I agree that there should be multiple OTN specific encoding types > introduced. But IMO they should indicate the link's mux capabilities > rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, > SHO, etc.). The link's role or roles IMO should be indicated with a > separate switchcaps. I can give you several reasons: > > 1. Links with the same mux capabilities may have different roles; 2. > Link may advertise several roles (e.g. HO and SHO) with different > mux.capabilities per role; 3. Link's role and mux. capabilities can be > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > required); 4. The combination of swicthcaps and encoding type will look > to CP as a separate layer, which is exactly how ITU models OTN > hierarchies in all aspects but routing (!?) 5. If the operator would > want to constrain the routing of OTN connections to pre-configured > topology with a specific role (e.g. constrain all ODUs it sells to the > clients to one or more pre-configured LO topologies), this would be > possible to do in a technology independent way. Suppose an instance of > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > links will be no different from the separation of WDM links from OTUs. > > Cheers, > Igor > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 13, 2010 6:24 PM > To: Igor Bryskin > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > I think OTN links require more than one switchcaps: as many as the > depth of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > It would be better IMHO to keep the Switch Type as TDM and make the > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > Replacing the Encoding Type would insure that any LSR that did not > understand what the TS type meant did not try to multiplex its LO ODU > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > a 1.25 TS granularity for another LO ODU. > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > then the corresponding G.709 Digital Path FA can be withdrawn. > > The Encoding type would be the lower encoding at each end of the LSP > regardless of what goes on in the middle since that determines what can > be wrapped inside it. > > For example: > > OTU3 > OTU2 ODUk=3D3 -------------- > OTU1 ODUk=3D2 -- ODUj=3D2 > ODUk=3D1 --- ODUj=3D1 -- > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex ev= en > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > If the SHO Encoding Type is used, then it indicates that two levels of > multiplexing could be supported at that switch/LSR. > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > Types currently don't include an ODUj or ODUk distinction but if > Encoding Type indicated LO or HO, that may not be needed. Along with > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > and ODU2e, can be added. > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > how in an FA it can be indicated that either type is currently > available (NE capable of both and hasn't committed to either one yet). > > BTW- Maybe I'm missing something but the number of messages on this > would indicate a huge controversy and I'm not getting it (other than a > strong preference to rely on bytes/sec or on enumerated type fields). > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > other intent. Could someone (either draft) concisely summarize the > multiplexing restrictions in one place, including restrictions on > number of multiplexing layers at one LSR. That might help. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document before we can embark on any proposals to the problem. I am > > > still not clear why do we have to deviate from the general approach > > > that has been established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > IB>> plane, and > > > it is highly desirable to adhere to the layer independent paradigm > > > of advertising of TE links, and there is no reason to invent an OTN > > > specific ISCD. The combination of Switching Capability and Encoding > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > represent >the low-order ODUj bandwidth within the high-order > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > > IB>> OTN > > > hierarchies and constrain LO connections to HO containers, one > needs > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for > > > control plane, no matter how you encode the routing information. > For > > > TDM networks, you know the resource is allocated based on TS, so > the > > > available TS should be get or induced before creating cross- > connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > > think you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > will find that one of your suggestions is adopted (i.e., simply > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, you have to advertise a new TE link or put this FA as a > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; > > > > > > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; > > > > draft-ietf-ccamp-gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to > better > > > > align the work with 4202. Use of common approaches is of course > > > > one of the main objectives of *C*CAMP. I look forward to hearing > > > > from the draft and discussion contributors on there progress on > this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > > >> routing purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, > > > >> consider an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > >> establish an ODU2 service over the link. At this point in time > > > >> the OTU3 link has 12 time-slots available for ODU2 services and > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s are > > > >> contained over the ODU2). So it is obvious from this example > that > > > >> the number of time-slots available is different based on the > signal-type (i.e. ODU1 and ODU2). > > > >> How do we address this issue based on the approach specified in > > > >> the > > > draft? > > > >> > > > >> My other question is why not simply advertize the available > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > >> equivalent bandwidth in bytes/sec within a link? This approach > > > >> seems to be more in-line with the general approach outlined in > > > >> RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit > is > > > >> that the advertisement is TS size independent and hence will > > > >> simplify the implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Mon Jul 19 08:45:57 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8646F3A6A6C for ; Mon, 19 Jul 2010 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_20=-0.74, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l9RTgWmjjN0 for ; Mon, 19 Jul 2010 08:45:55 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 693513A6922 for ; Mon, 19 Jul 2010 08:45:54 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6JFjwI4006286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 19 Jul 2010 17:45:58 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Jul 2010 17:45:58 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Mon, 19 Jul 2010 11:45:55 -0400 From: Igor Bryskin To: Snigdho Bardalai , Daniele Ceccarelli , Fatai Zhang , "curtis@occnc.com" Date: Mon, 19 Jul 2010 11:45:42 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0A= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-19_06:2010-07-19, 2010-07-19, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:45:57 -0000 [SCB] Are you saying the ISCD as defined today with minor extensions (i.e. = to further classify the information) will be sufficient That's exactly what I've been trying to say all along. Cheers, Igor -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: Monday, July 19, 2010 11:31 AM To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor Please see inline. Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 7:43 AM > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Daniele, > > Please, see in line. > > Cheers, > Igor > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Monday, July 19, 2010 10:31 AM > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor, > > I didn't understand if you're proposing to (a) send an ISCD per role > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > IB>> in ISCD: > switchCap =3D role; > encodeType =3D muxCap & signal type; > We also have 16 reserved bits which can use for OTN specific info in > case we need it. [SCB] I am yet to clearly understand what the role of "role" is, but agree = with your observation on the encode-type and the 16 reserved-bits to furthe= r classify the switching information. > > In case (a) you're still missing a lot of information. For each role > you would advertise just the unreserved bandwidth but you wouldn't know > if such bandwidth is available for a certain type of ODUj LSP (e.g. 15 > Gbps available on 3 component links: you advertise 45 Gbps available > but no ODU3 can be set up on such TE link). > > In case (b) the number of ISCDs would cause serious scalability issues > and the requirement of being able to bundle component links together > wouldn't be satisfied. > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > provide a lot of flexibility: you can specify different things (e.g. > available bandwidth) for the same link in different roles. [SCB] Are you saying the ISCD as defined today with minor extensions (i.e. = to further classify the information) will be sufficient? > > Cheers, > Daniele > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: luned=EC 19 luglio 2010 15.40 > To: Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Fatai, > > Please, see my responses on-line. > > Cheers, > Igor > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Fatai Zhang > Sent: Sunday, July 18, 2010 10:49 PM > To: Igor Bryskin; curtis@occnc.com > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor, > > Thanks. > I understand what you said. Therefore, we have added some text to > address the requirment in FWK document. However, we still don't think > that we need to extend ISC to meet the requirment. The role of the ODU > can be get from the routing information implicitly. In the [draft- > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" is > introduced. > > IB>> This is possible, however: > a) this requires OTN specific advertising and processing rules; > b) disallows topology separation in technology independent way > > A quick question on your statement: "the role of an ODU container does > not change hop-by-hop (as some people seem to believe). The role is > only meaningful on the ODU terminating nodes and irrelevant on transit > nodes. It is it's position in the hierarchy (but not role) that may > change hop-by-hop. " > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > of Ho ODU level is requested, according to your statement, this > conneciton will be allowed to be created. However, it should not be > allowed because the ISC is not consistent along the LSP. > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 > and B12 - only with a single ISCD: OTN_LO_SC. If the path computation > is constrained to the OTN_HO_SC topology, B11 and B12 TE links will be > disallowed, and the resulting path (if any) will not go through B11 and > B12. If one circumvents the path computation by providing the fully > explicit path, the signaling should fail on node B for the same reason: > inconsistency of required (signaled) and supported (by local > interfaces) switchcap. > > Please see the text from RFC3473: "Nodes MUST verify that the type > indicated in the Switching Type parameter is supported on the > corresponding incoming interface. If the type cannot be supported, > the node MUST generate a PathErr message with a "Routing > problem/Switching Type" indication." > IB>> Indeed > > > > > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: "Fatai Zhang" ; > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Lou Berger" ; > ; framework@tools.ietf.org> > Sent: Friday, July 16, 2010 12:34 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > Fatai, > Please, see my answers in line. > > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 14, 2010 9:52 PM > To: Igor Bryskin; curtis@occnc.com > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft- > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Hi Igor and all, > > Thanks for all your comments. > > I think role does not equal switching capability. The operators can > define different roles depending on their policy and achieve the role > through different methods. However, for OTN networks, the containers > (e.g., ODUk) all have the same switching capablility (i.e., TDM > switching) and I think we should reflect the natural characteristics of > links in the routing. In addition, if we extend the ISC, it will make > the encoding type lose its' own meaning(ie., ISC overrides encoding > type). > > IB>> When a GMPLS CP instance controls several layers, it views the > network as a stack of topologies. Whether a given topology is real or > virtual is of no importance. > The GMPLS ISCD link sub-tlv and, in particular, its switching > capability field (confusing name as it is) is a good way to describe a > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > topologies that could be easily separated in technology independent way > should path computation be constrained to particular one or sub-stack > of them. > I think a good way to identify an OTN (virtual) topology is via > (infrastructure) ODU container role of ODUs comprising the topology. > BTW IMO the role of an ODU container does not change hop-by-hop (as > some people seem to believe). The role is only meaningful on the ODU > terminating nodes and irrelevant on transit nodes. It is it's position > in the hierarchy (but not role) that may change hop-by-hop. ODU's role > is the level of topology it is provisioned for and it is the same for > all ODUs that comprise the topology. For, example a user may provision > a LO topology and constrain ODUs he sells to a set of clients to use > the topology rather than any resources available on OTN network. > The bottom line: container's role is the same as the role of virtual > topology the container is a part of and could be advertised as the > corresponding link switchcap. > > According to the point 3, I don't know how to advertise the roles and > muxing capabilities with the ISCD of RFC4202, could you clarify? > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > encoding type =3D mux. capabilities code > > In addition, could you clarify my questions in another email (copied as > follows): > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > IB>> I disagree. You define role =3D=3D position in the hierarchy, which = is > a mistake IMO. > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link > supporting ODU2 switching, which can be used as Lo ODU2 (service over > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > IB>> As I mentioned earlier, ODU role is only important on the ODU > terminating nodes (i.e. on either side of corresponding link). What > happens on the ODU transit nodes and its place in the hierarchy on the > transit nodes are of no importance. My LO container can be carried by > somebody else's LO container and can carry my client's LO container. To > some extent it is similar to MPLS LSP role: LSP always has a role (e.g. > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > path. > > Cheers, > Igor > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Thanks > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Fatai Zhang" ; "Lou > Berger" ; ; g709-framework@tools.ietf.org> > Sent: Wednesday, July 14, 2010 10:36 PM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > Curtis, > > Thanks for your comment. > > I agree that there should be multiple OTN specific encoding types > introduced. But IMO they should indicate the link's mux capabilities > rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, > SHO, etc.). The link's role or roles IMO should be indicated with a > separate switchcaps. I can give you several reasons: > > 1. Links with the same mux capabilities may have different roles; 2. > Link may advertise several roles (e.g. HO and SHO) with different > mux.capabilities per role; 3. Link's role and mux. capabilities can be > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > required); 4. The combination of swicthcaps and encoding type will look > to CP as a separate layer, which is exactly how ITU models OTN > hierarchies in all aspects but routing (!?) 5. If the operator would > want to constrain the routing of OTN connections to pre-configured > topology with a specific role (e.g. constrain all ODUs it sells to the > clients to one or more pre-configured LO topologies), this would be > possible to do in a technology independent way. Suppose an instance of > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > links will be no different from the separation of WDM links from OTUs. > > Cheers, > Igor > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 13, 2010 6:24 PM > To: Igor Bryskin > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > I think OTN links require more than one switchcaps: as many as the > depth of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > It would be better IMHO to keep the Switch Type as TDM and make the > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > Replacing the Encoding Type would insure that any LSR that did not > understand what the TS type meant did not try to multiplex its LO ODU > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > a 1.25 TS granularity for another LO ODU. > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > then the corresponding G.709 Digital Path FA can be withdrawn. > > The Encoding type would be the lower encoding at each end of the LSP > regardless of what goes on in the middle since that determines what can > be wrapped inside it. > > For example: > > OTU3 > OTU2 ODUk=3D3 -------------- > OTU1 ODUk=3D2 -- ODUj=3D2 > ODUk=3D1 --- ODUj=3D1 -- > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex ev= en > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > If the SHO Encoding Type is used, then it indicates that two levels of > multiplexing could be supported at that switch/LSR. > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > Types currently don't include an ODUj or ODUk distinction but if > Encoding Type indicated LO or HO, that may not be needed. Along with > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > and ODU2e, can be added. > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > how in an FA it can be indicated that either type is currently > available (NE capable of both and hasn't committed to either one yet). > > BTW- Maybe I'm missing something but the number of messages on this > would indicate a huge controversy and I'm not getting it (other than a > strong preference to rely on bytes/sec or on enumerated type fields). > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > other intent. Could someone (either draft) concisely summarize the > multiplexing restrictions in one place, including restrictions on > number of multiplexing layers at one LSR. That might help. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document before we can embark on any proposals to the problem. I am > > > still not clear why do we have to deviate from the general approach > > > that has been established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > IB>> plane, and > > > it is highly desirable to adhere to the layer independent paradigm > > > of advertising of TE links, and there is no reason to invent an OTN > > > specific ISCD. The combination of Switching Capability and Encoding > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > represent >the low-order ODUj bandwidth within the high-order > containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create > > > IB>> OTN > > > hierarchies and constrain LO connections to HO containers, one > needs > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > feasible for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for > > > control plane, no matter how you encode the routing information. > For > > > TDM networks, you know the resource is allocated based on TS, so > the > > > available TS should be get or induced before creating cross- > connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I > > > think you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > will find that one of your suggestions is adopted (i.e., simply > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for > > > ODU1, you have to advertise a new TE link or put this FA as a > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; > > > > > > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; > > > > draft-ietf-ccamp-gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to > better > > > > align the work with 4202. Use of common approaches is of course > > > > one of the main objectives of *C*CAMP. I look forward to hearing > > > > from the draft and discussion contributors on there progress on > this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service > > > >> routing purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, > > > >> consider an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > >> establish an ODU2 service over the link. At this point in time > > > >> the OTU3 link has 12 time-slots available for ODU2 services and > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s are > > > >> contained over the ODU2). So it is obvious from this example > that > > > >> the number of time-slots available is different based on the > signal-type (i.e. ODU1 and ODU2). > > > >> How do we address this issue based on the approach specified in > > > >> the > > > draft? > > > >> > > > >> My other question is why not simply advertize the available > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > >> equivalent bandwidth in bytes/sec within a link? This approach > > > >> seems to be more in-line with the general approach outlined in > > > >> RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit > is > > > >> that the advertisement is TS size independent and hence will > > > >> simplify the implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> CCAMP mailing list > > > >> CCAMP@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Mon Jul 19 08:47:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292C93A694D for ; Mon, 19 Jul 2010 08:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_20=-0.74, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk16KNa+tX4T for ; Mon, 19 Jul 2010 08:47:35 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id CEE6A3A6B24 for ; Mon, 19 Jul 2010 08:47:34 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Mon, 19 Jul 2010 08:47:32 -0700 From: Snigdho Bardalai To: Igor Bryskin , Daniele Ceccarelli , Fatai Zhang , "curtis@occnc.com" Date: Mon, 19 Jul 2010 08:47:30 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oA== Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:47:37 -0000 Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but > agree with your observation on the encode-type and the 16 reserved-bits > to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't think > > that we need to extend ISC to meet the requirment. The role of the > ODU > > can be get from the routing information implicitly. In the [draft- > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while B11 > > and B12 - only with a single ISCD: OTN_LO_SC. If the path computation > > is constrained to the OTN_HO_SC topology, B11 and B12 TE links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ; > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > > define different roles depending on their policy and achieve the role > > through different methods. However, for OTN networks, the containers > > (e.g., ODUk) all have the same switching capablility (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will make > > the encoding type lose its' own meaning(ie., ISC overrides encoding > > type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real or > > virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or sub-stack > > of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > some people seem to believe). The role is only meaningful on the ODU > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same for > > all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > > topology the container is a part of and could be advertised as the > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles and > > muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho > > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried by > > somebody else's LO container and can carry my client's LO container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ; "Lou > > Berger" ; ; gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > > introduced. But IMO they should indicate the link's mux capabilities > > rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, > > SHO, etc.). The link's role or roles IMO should be indicated with a > > separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN > > hierarchies in all aspects but routing (!?) 5. If the operator would > > want to constrain the routing of OTN connections to pre-configured > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO ODU > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex = even > > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along with > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > other intent. Could someone (either draft) concisely summarize the > > multiplexing restrictions in one place, including restrictions on > > number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > will find that one of your suggestions is adopted (i.e., simply > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > > > > >> consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > we > > > > >> establish an ODU2 service over the link. At this point in time > > > > >> the OTU3 link has 12 time-slots available for ODU2 services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s are > > > > >> contained over the ODU2). So it is obvious from this example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This approach > > > > >> seems to be more in-line with the general approach outlined in > > > > >> RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit > > is > > > > >> that the advertisement is TS size independent and hence will > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Tue Jul 20 01:38:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3E03A6C55 for ; Tue, 20 Jul 2010 01:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AncSHBveIHTR for ; Tue, 20 Jul 2010 01:38:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 208FE3A6C5C for ; Tue, 20 Jul 2010 01:31:38 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-18-4c455ef0dae1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.31.06895.0FE554C4; Tue, 20 Jul 2010 10:31:44 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 10:31:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 10:31:40 +0200 Message-ID: In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQ References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> From: "Daniele Ceccarelli" To: "Snigdho Bardalai" , "Igor Bryskin" , "Fatai Zhang" , X-OriginalArrivalTime: 20 Jul 2010 08:31:44.0122 (UTC) FILETIME=[FC2135A0:01CB27E5] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:38:19 -0000 Igor, one more question. What about the unreserved bandwidth?=20 If you're advertising the max lsp bandwidth by 1 ISCD per role per = (muxCap & signal type) you also need to advertise the unreserved = bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This = also implies extending the unreserved bandwidth TLV so to create a = corrispondence between the couples (ISCD-unreserved bandwidth subTLV). Thanks Daniele -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com]=20 Sent: luned=EC 19 luglio 2010 17.48 To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang;=20 > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions=20 > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role = > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in = > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but=20 > agree with your observation on the encode-type and the 16=20 > reserved-bits to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role = > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available = > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together = > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions=20 > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to=20 > > address the requirment in FWK document. However, we still don't=20 > > think that we need to extend ISC to meet the requirment. The role of = > > the > ODU > > can be get from the routing information implicitly. In the [draft-=20 > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is=20 > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may=20 > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and=20 > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this=20 > > conneciton will be allowed to be created. However, it should not be=20 > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while=20 > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path=20 > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE = > > links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully=20 > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the=20 > > corresponding incoming interface. If the type cannot be supported, = > > the node MUST generate a PathErr message with a "Routing=20 > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ;=20 > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can=20 > > define different roles depending on their policy and achieve the=20 > > role through different methods. However, for OTN networks, the=20 > > containers (e.g., ODUk) all have the same switching capablility=20 > > (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will=20 > > make the encoding type lose its' own meaning(ie., ISC overrides=20 > > encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real=20 > > or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching=20 > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or=20 > > sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as=20 > > some people seem to believe). The role is only meaningful on the ODU = > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same=20 > > for all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use = > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual = > > topology the container is a part of and could be advertised as the=20 > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles=20 > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > = =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, = which > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as=20 > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service=20 > > over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What=20 > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried=20 > > by somebody else's LO container and can carry my client's LO = container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its=20 > > path. > > > > Cheers, > > Igor > > > > > = =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ;=20 > > "Lou Berger" ; ;=20 > > gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types=20 > > introduced. But IMO they should indicate the link's mux capabilities = > > rather than the link's role (i.e. level in the OTN hierarchy: LO,=20 > > HO, SHO, etc.). The link's role or roles IMO should be indicated=20 > > with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different=20 > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is=20 > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN=20 > > hierarchies in all aspects but routing (!?) 5. If the operator would = > > want to constrain the routing of OTN connections to pre-configured=20 > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be=20 > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN=20 > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger;=20 > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ = /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the=20 > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital=20 > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had=20 > > in turn replaced the Encoding Type of "Digital Wrapper" a long time = ago. > > > > Replacing the Encoding Type would insure that any LSR that did not=20 > > understand what the TS type meant did not try to multiplex its LO=20 > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or=20 > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO,=20 > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS=20 > > granularity, then the corresponding G.709 Digital Path FA can be = withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP = > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or = ODUj=3Dflex=20 > > even though the ODUk=3D2 at the next hop could not directly contain = an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch=20 > > Types currently don't include an ODUj or ODUk distinction but if=20 > > Encoding Type indicated LO or HO, that may not be needed. Along=20 > > with the new Encoding Type new Signal Types for ODU0, ODU4, and=20 > > ODU-flex, and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently=20 > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this=20 > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type = fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework,=20 > > or other intent. Could someone (either draft) concisely summarize=20 > > the multiplexing restrictions in one place, including restrictions=20 > > on number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework=20 > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control=20 > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing=20 > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if = > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new=20 > > > > >TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple = problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and=20 > > > > other interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more=20 > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for=20 > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you = > > > > will find that one of your suggestions is adopted (i.e., simply=20 > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a=20 > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress=20 > > > > > on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order=20 > > > > >> ODUj availability within a higher-order container. For=20 > > > > >> example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and=20 > > > > >> then > > we > > > > >> establish an ODU2 service over the link. At this point in=20 > > > > >> time the OTU3 link has 12 time-slots available for ODU2=20 > > > > >> services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s=20 > > > > >> are contained over the ODU2). So it is obvious from this=20 > > > > >> example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available=20 > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This=20 > > > > >> approach seems to be more in-line with the general approach=20 > > > > >> outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs=20 > > > > >> being advertised per VC rate for an SDH link. The additional=20 > > > > >> benefit > > is > > > > >> that the advertisement is TS size independent and hence will=20 > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org =20 > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org =20 > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Tue Jul 20 07:15:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B4F3A6B1A for ; Tue, 20 Jul 2010 07:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkNxJ-91aUBi for ; Tue, 20 Jul 2010 07:15:51 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id E01603A6AF3 for ; Tue, 20 Jul 2010 07:15:50 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KEFrhr019393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 16:15:53 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 16:15:53 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 16:15:53 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 10:15:49 -0400 From: Igor Bryskin To: Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 10:15:36 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7607D@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_06:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:15:54 -0000 In line -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 4:32 AM To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, one more question. What about the unreserved bandwidth? If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCap = & signal type) you also need to advertise the unreserved bandwidth using 1 = unreserved bandwidth sub-TLV per ISCD, correct? This also implies extending= the unreserved bandwidth TLV so to create a corrispondence between the cou= ples (ISCD-unreserved bandwidth subTLV). IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per role p= er (muxCap & signal type) per priority level. However, total unreserved ban= dwidth IMO is OK to share between roles unless you see a compelling reason = to the contrary (which I don't) Igor Thanks Daniele -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: luned=EC 19 luglio 2010 17.48 To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but > agree with your observation on the encode-type and the 16 > reserved-bits to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't > > think that we need to extend ISC to meet the requirment. The role of > > the > ODU > > can be get from the routing information implicitly. In the [draft- > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE > > links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ; > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > > define different roles depending on their policy and achieve the > > role through different methods. However, for OTN networks, the > > containers (e.g., ODUk) all have the same switching capablility > > (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will > > make the encoding type lose its' own meaning(ie., ISC overrides > > encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real > > or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or > > sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > some people seem to believe). The role is only meaningful on the ODU > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same > > for all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > > topology the container is a part of and could be advertised as the > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried > > by somebody else's LO container and can carry my client's LO container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ; > > "Lou Berger" ; ; > > gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > > introduced. But IMO they should indicate the link's mux capabilities > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN > > hierarchies in all aspects but routing (!?) 5. If the operator would > > want to constrain the routing of OTN connections to pre-configured > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > in turn replaced the Encoding Type of "Digital Wrapper" a long time ago= . > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > granularity, then the corresponding G.709 Digital Path FA can be withdr= awn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex > > even though the ODUk=3D2 at the next hop could not directly contain an = ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > ODU-flex, and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > or other intent. Could someone (either draft) concisely summarize > > the multiplexing restrictions in one place, including restrictions > > on number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > >TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > other interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > will find that one of your suggestions is adopted (i.e., simply > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress > > > > > on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order > > > > >> ODUj availability within a higher-order container. For > > > > >> example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > >> then > > we > > > > >> establish an ODU2 service over the link. At this point in > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > >> services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > >> are contained over the ODU2). So it is obvious from this > > > > >> example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > >> approach seems to be more in-line with the general approach > > > > >> outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > >> being advertised per VC rate for an SDH link. The additional > > > > >> benefit > > is > > > > >> that the advertisement is TS size independent and hence will > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Tue Jul 20 07:52:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2192E3A6B23 for ; Tue, 20 Jul 2010 07:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ0BkXSU1Ybm for ; Tue, 20 Jul 2010 07:52:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id DB6D43A6981 for ; Tue, 20 Jul 2010 07:52:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KEqPhK062342; Tue, 20 Jul 2010 10:52:25 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> To: Fatai Zhang From: Curtis Villamizar In-reply-to: Your message of "Mon, 19 Jul 2010 10:48:45 +0800." <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> Date: Tue, 20 Jul 2010 10:52:25 -0400 Sender: curtis@occnc.com Cc: Igor Bryskin , ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:52:30 -0000 In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> Fatai Zhang writes: > > Hi Igor, > > Thanks. Sorry to jump in but I think I understand Igor's objection (and Snigdho's objection, and the reason this thread is going on). > I understand what you said. Therefore, we have added some text to > address the requirment in FWK document. However, we still don't think > that we need to extend ISC to meet the requirment. The role of the ODU > can be get from the routing information implicitly. In the > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > Lambda" is introduced. > > A quick question on your statement: "the role of an ODU container does > not change hop-by-hop (as some people seem to believe). The role is > only meaningful on the ODU terminating nodes and irrelevant on transit > nodes. It is it's position in the hierarchy (but not role) that may > change hop-by-hop. " > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > of Ho ODU level is requested, according to your statement, this > conneciton will be allowed to be created. However, it should not be > allowed because the ISC is not consistent along the LSP. > > Please see the text from RFC3473: "Nodes MUST verify that the type > indicated in the Switching Type parameter is supported on the > corresponding incoming interface. If the type cannot be supported, > the node MUST generate a PathErr message with a "Routing > problem/Switching Type" indication." I think the objection, which would be a very valid one, is that the ingress has no way to know apriori that a path is infeasible. Each crankback delays convergence. Crankback should only occur if another ingress has reserved resources before signaling was completed, not because inadequate routing information is provided in quiescent state. Curtis > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: "Fatai Zhang" ; > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; > Sent: Friday, July 16, 2010 12:34 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > Fatai, > Please, see my answers in line. > > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 14, 2010 9:52 PM > To: Igor Bryskin; curtis@occnc.com > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Hi Igor and all, > > Thanks for all your comments. > > I think role does not equal switching capability. The operators can define different roles depending on their policy and achieve the role through different methods. However, for OTN networks, the containers (e.g., ODUk) all have the same switching capablility (i.e., TDM switching) and I think we should reflect the natural characteristics of links in the routing. In addition, if we extend the ISC, it will make the encoding type lose its' own meaning(ie., ISC overrides encoding type). > > IB>> When a GMPLS CP instance controls several layers, it views the network as a stack of topologies. Whether a given topology is real or virtual is of no importance. > The GMPLS ISCD link sub-tlv and, in particular, its switching capability field (confusing name as it is) is a good way to describe a layer in technology independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of topologies that could be easily separated in technology independent way should path computation be constrained to particular one or sub-stack of them. > I think a good way to identify an OTN (virtual) topology is via (infrastructure) ODU container role of ODUs comprising the topology. BTW IMO the role of an ODU container does not change hop-by-hop (as some people seem to believe). The role is only meaningful on the ODU terminating nodes and irrelevant on transit nodes. It is it's position in the hierarchy (but not role) that may change hop-by-hop. ODU's role is the level of topology it is provisioned for and it is the same for all ODUs that comprise the topology. For, example a user may provision a LO topology and constrain ODUs he sells to a set of clients to use the topology rather than any resources available on OTN network. > The bottom line: container's role is the same as the role of virtual topology the container is a part of and could be advertised as the corresponding link switchcap. > > According to the point 3, I don't know how to advertise the roles and muxing capabilities with the ISCD of RFC4202, could you clarify? > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > encoding type = mux. capabilities code > > In addition, could you clarify my questions in another email (copied as follows): > ==================================================================================================== > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > IB>> I disagree. You define role == position in the hierarchy, which is a mistake IMO. > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > IB>> As I mentioned earlier, ODU role is only important on the ODU terminating nodes (i.e. on either side of corresponding link). What happens on the ODU transit nodes and its place in the hierarchy on the transit nodes are of no importance. My LO container can be carried by somebody else's LO container and can carry my client's LO container. To some extent it is similar to MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its path. > > Cheers, > Igor > > =================================================================================================== > > > > Thanks > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; > Sent: Wednesday, July 14, 2010 10:36 PM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > Curtis, > > Thanks for your comment. > > I agree that there should be multiple OTN specific encoding types introduced. But IMO they should indicate the link's mux capabilities rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link's role or roles IMO should be indicated with a separate switchcaps. I can give you several reasons: > > 1. Links with the same mux capabilities may have different roles; > 2. Link may advertise several roles (e.g. HO and SHO) with different mux.capabilities per role; > 3. Link's role and mux. capabilities can be advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is required); > 4. The combination of swicthcaps and encoding type will look to CP as a separate layer, which is exactly how ITU models OTN hierarchies in all aspects but routing (!?) > 5. If the operator would want to constrain the routing of OTN connections to pre-configured topology with a specific role (e.g. constrain all ODUs it sells to the clients to one or more pre-configured LO topologies), this would be possible to do in a technology independent way. Suppose an instance of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links will be no different from the separation of WDM links from OTUs. > > Cheers, > Igor > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 13, 2010 6:24 PM > To: Igor Bryskin > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > I think OTN links require more than one switchcaps: as many as the depth of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =0 /* Unknown */ > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > , LSPSwitchType_L2SC =50 /* L2SC */ > > , LSPSwitchType_TDM =100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =150 /* LSC */ > > , LSPSwitchType_FSC =200 /* FSC */ > > }e_LSPSwitchType; > > > It would be better IMHO to keep the Switch Type as TDM and make the > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > Replacing the Encoding Type would insure that any LSR that did not > understand what the TS type meant did not try to multiplex its LO ODU > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > a 1.25 TS granularity for another LO ODU. > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > then the corresponding G.709 Digital Path FA can be withdrawn. > > The Encoding type would be the lower encoding at each end of the LSP > regardless of what goes on in the middle since that determines what > can be wrapped inside it. > > For example: > > OTU3 > OTU2 ODUk=3 -------------- > OTU1 ODUk=2 -- ODUj=2 > ODUk=1 --- ODUj=1 -- > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even > though the ODUk=2 at the next hop could not directly contain an ODU0. > If the SHO Encoding Type is used, then it indicates that two levels of > multiplexing could be supported at that switch/LSR. > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > Types currently don't include an ODUj or ODUk distinction but if > Encoding Type indicated LO or HO, that may not be needed. Along with > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > and ODU2e, can be added. > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > how in an FA it can be indicated that either type is currently > available (NE capable of both and hasn't committed to either one yet). > > BTW- Maybe I'm missing something but the number of messages on this > would indicate a huge controversy and I'm not getting it (other than a > strong preference to rely on bytes/sec or on enumerated type fields). > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > other intent. Could someone (either draft) concisely summarize the > multiplexing restrictions in one place, including restrictions on > number of multiplexing layers at one LSR. That might help. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework document > > > before we can embark on any proposals to the problem. I am still not clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > > > it is highly desirable to adhere to the layer independent paradigm of > > > advertising of TE links, and there is no reason to invent an OTN specific > > > ISCD. The combination of Switching Capability and Encoding type of RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > represent >the low-order ODUj bandwidth within the high-order containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > > hierarchies and constrain LO connections to HO containers, one needs to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for control > > > plane, no matter how you encode the routing information. For TDM networks, > > > you know the resource is allocated based on TS, so the available TS should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > > > you have to advertise a new TE link or put this FA as a component link of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to better > > > > align the work with 4202. Use of common approaches is of course one of > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > draft and discussion contributors on there progress on this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, consider an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > >> establish an ODU2 service over the link. At this point in time the OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained over the > > > >> ODU2). So it is obvious from this example that the number of time-slots > > > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > > > >> How do we address this issue based on the approach specified in the > > > draft? > > > >> > > > >> My other question is why not simply advertize the available number of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit is that > > > >> the advertisement is TS size independent and hence will simplify the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho From daniele.ceccarelli@ericsson.com Tue Jul 20 07:57:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4718B3A69EF for ; Tue, 20 Jul 2010 07:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.247 X-Spam-Level: X-Spam-Status: No, score=-4.247 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5CgFN-dmiiT for ; Tue, 20 Jul 2010 07:57:15 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9C8B23A6C05 for ; Tue, 20 Jul 2010 07:57:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-c0-4c45b959627a Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.1D.10125.959B54C4; Tue, 20 Jul 2010 16:57:29 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 16:57:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 16:57:27 +0200 Message-ID: In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7607D@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIA== References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC 6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> From: "Daniele Ceccarelli" To: "Igor Bryskin" , "Snigdho Bardalai" , "Fatai Zhang" , X-OriginalArrivalTime: 20 Jul 2010 14:57:28.0494 (UTC) FILETIME=[DF401CE0:01CB281B] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:57:18 -0000 Igor, The need for unreserved resources advertised per signal type is the = concurrent path computation. I'll answer quoting a section from the = info-model draft, please have a look in particular to the example: " Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority, this leads not to know how many LSPs of a specific signal type can be restored. As example it is possible to consider the scenario depicted in the following figure. +------+ component link 1 +------+ | +------------------+ | | | component link 2 | | | N1 +------------------+ N2 | | | component link 3 | | | +------------------+ | +------+ +---+--+ =20 Suppose to have a TE link comprising 3 ODU3 component links with 32TSs available on the first one, 24TSs on the second, 24TSs on the third and supporting ODU2 and ODU3 signal types. The node would advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the network could try to restore 2 ODU3 (64TSs) in such TE-link while only a single ODU3 can be set up and a crank-back would be originated. In more complex network scenarios the number of crank-backs can be much higher." In other words, advertising the number of availble resources per signal = type does not avoid the possibility of cranck-back but decreases it as = much as possible. For sure a good routing prevents from crank-backs = caused by the restoration of LSP originating on the same Ingress. The = cranck-backs due to the concurrent restoration of LSPs originating on = different ingress nodes cannot be avoided. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: marted=EC 20 luglio 2010 16.16 To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt In line -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 4:32 AM To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, one more question. What about the unreserved bandwidth? If you're advertising the max lsp bandwidth by 1 ISCD per role per = (muxCap & signal type) you also need to advertise the unreserved = bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This = also implies extending the unreserved bandwidth TLV so to create a = corrispondence between the couples (ISCD-unreserved bandwidth subTLV). IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per=20 IB>> role per (muxCap & signal type) per priority level. However, total=20 IB>> unreserved bandwidth IMO is OK to share between roles unless you=20 IB>> see a compelling reason to the contrary (which I don't) Igor Thanks Daniele -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: luned=EC 19 luglio 2010 17.48 To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang;=20 > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions=20 > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role = > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in = > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but=20 > agree with your observation on the encode-type and the 16=20 > reserved-bits to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role = > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available = > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together = > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions=20 > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to=20 > > address the requirment in FWK document. However, we still don't=20 > > think that we need to extend ISC to meet the requirment. The role of = > > the > ODU > > can be get from the routing information implicitly. In the [draft-=20 > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is=20 > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may=20 > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this=20 > > conneciton will be allowed to be created. However, it should not be=20 > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path=20 > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE = > > links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully=20 > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the=20 > > corresponding incoming interface. If the type cannot be supported, = > > the node MUST generate a PathErr message with a "Routing=20 > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ;=20 > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can=20 > > define different roles depending on their policy and achieve the=20 > > role through different methods. However, for OTN networks, the=20 > > containers (e.g., ODUk) all have the same switching capablility=20 > > (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will=20 > > make the encoding type lose its' own meaning(ie., ISC overrides=20 > > encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real=20 > > or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching=20 > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or=20 > > sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as=20 > > some people seem to believe). The role is only meaningful on the ODU = > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same=20 > > for all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use = > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual = > > topology the container is a part of and could be advertised as the=20 > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles=20 > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > = =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, = which > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as=20 > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service=20 > > over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What=20 > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried=20 > > by somebody else's LO container and can carry my client's LO = container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its=20 > > path. > > > > Cheers, > > Igor > > > > > = =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ;=20 > > "Lou Berger" ; ; > > gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types=20 > > introduced. But IMO they should indicate the link's mux capabilities = > > rather than the link's role (i.e. level in the OTN hierarchy: LO,=20 > > HO, SHO, etc.). The link's role or roles IMO should be indicated=20 > > with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different=20 > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is=20 > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN=20 > > hierarchies in all aspects but routing (!?) 5. If the operator would = > > want to constrain the routing of OTN connections to pre-configured=20 > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be=20 > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN=20 > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger;=20 > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ = /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the=20 > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital=20 > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had=20 > > in turn replaced the Encoding Type of "Digital Wrapper" a long time = ago. > > > > Replacing the Encoding Type would insure that any LSR that did not=20 > > understand what the TS type meant did not try to multiplex its LO=20 > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or=20 > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO,=20 > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS=20 > > granularity, then the corresponding G.709 Digital Path FA can be = withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP = > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or = ODUj=3Dflex=20 > > even though the ODUk=3D2 at the next hop could not directly contain = an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch=20 > > Types currently don't include an ODUj or ODUk distinction but if=20 > > Encoding Type indicated LO or HO, that may not be needed. Along=20 > > with the new Encoding Type new Signal Types for ODU0, ODU4, and=20 > > ODU-flex, and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently=20 > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this=20 > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type = fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > or other intent. Could someone (either draft) concisely summarize=20 > > the multiplexing restrictions in one place, including restrictions=20 > > on number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework=20 > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control=20 > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing=20 > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if = > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new=20 > > > > >TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple = problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and=20 > > > > other interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more=20 > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for=20 > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you = > > > > will find that one of your suggestions is adopted (i.e., simply=20 > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a=20 > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress=20 > > > > > on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order=20 > > > > >> ODUj availability within a higher-order container. For=20 > > > > >> example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and=20 > > > > >> then > > we > > > > >> establish an ODU2 service over the link. At this point in=20 > > > > >> time the OTU3 link has 12 time-slots available for ODU2=20 > > > > >> services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s=20 > > > > >> are contained over the ODU2). So it is obvious from this=20 > > > > >> example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available=20 > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This=20 > > > > >> approach seems to be more in-line with the general approach=20 > > > > >> outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs=20 > > > > >> being advertised per VC rate for an SDH link. The additional=20 > > > > >> benefit > > is > > > > >> that the advertisement is TS size independent and hence will=20 > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org =20 > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org =20 > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Tue Jul 20 08:02:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AAA3A69EF for ; Tue, 20 Jul 2010 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDHrn1H8kEKb for ; Tue, 20 Jul 2010 08:02:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CA3FD3A6BF7 for ; Tue, 20 Jul 2010 08:02:24 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-9c-4c45ba8fec36 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 11.73.06895.F8AB54C4; Tue, 20 Jul 2010 17:02:39 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 17:02:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 17:02:36 +0200 Message-ID: In-Reply-To: <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoGz1tX37tvH9VRYCfW8enoeYe3AAAN/yg References: Your message of "Mon, 19 Jul 2010 10:48:45 +0800."<0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> From: "Daniele Ceccarelli" To: , "Fatai Zhang" X-OriginalArrivalTime: 20 Jul 2010 15:02:38.0787 (UTC) FILETIME=[98331130:01CB281C] X-Brightmail-Tracker: AAAAAA== Cc: Snigdho Bardalai , ccamp@ietf.org, Igor Bryskin Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 15:02:27 -0000 Hi Curtis, Thanks for jumping in :-) You got the point. I hope my last mail can further clarify it. BR Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Curtis Villamizar Sent: marted=EC 20 luglio 2010 16.52 To: Fatai Zhang Cc: Igor Bryskin; ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> Fatai Zhang writes: > =20 > Hi Igor, > =20 > Thanks. Sorry to jump in but I think I understand Igor's objection (and = Snigdho's objection, and the reason this thread is going on). > I understand what you said. Therefore, we have added some text to=20 > address the requirment in FWK document. However, we still don't think=20 > that we need to extend ISC to meet the requirment. The role of the ODU = > can be get from the routing information implicitly. In the=20 > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full=20 > Lambda" is introduced. > =20 > A quick question on your statement: "the role of an ODU container does = > not change hop-by-hop (as some people seem to believe). The role is=20 > only meaningful on the ODU terminating nodes and irrelevant on transit = > nodes. It is it's position in the hierarchy (but not role) that may=20 > change hop-by-hop. " > =20 > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1=20 > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support = > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role = > of Ho ODU level is requested, according to your statement, this=20 > conneciton will be allowed to be created. However, it should not be=20 > allowed because the ISC is not consistent along the LSP. > =20 > Please see the text from RFC3473: "Nodes MUST verify that the type=20 > indicated in the Switching Type parameter is supported on the=20 > corresponding incoming interface. If the type cannot be supported,=20 > the node MUST generate a PathErr message with a "Routing=20 > problem/Switching Type" indication." I think the objection, which would be a very valid one, is that the = ingress has no way to know apriori that a path is infeasible. Each = crankback delays convergence. Crankback should only occur if another = ingress has reserved resources before signaling was completed, not = because inadequate routing information is provided in quiescent state. Curtis > Best Regards > =20 > Fatai > =20 > ----- Original Message ----- > From: "Igor Bryskin" > To: "Fatai Zhang" ; > Cc: "John E Drake" ; "Snigdho Bardalai"=20 > ; "Lou Berger" ;=20 > ;=20 > > Sent: Friday, July 16, 2010 12:34 AM > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > =20 > Fatai, > Please, see my answers in line. > =20 > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 14, 2010 9:52 PM > To: Igor Bryskin; curtis@occnc.com > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org;=20 > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > Hi Igor and all, > =20 > Thanks for all your comments. > =20 > I think role does not equal switching capability. The operators can = define different roles depending on their policy and achieve the role = through different methods. However, for OTN networks, the containers = (e.g., ODUk) all have the same switching capablility (i.e., TDM = switching) and I think we should reflect the natural characteristics of = links in the routing. In addition, if we extend the ISC, it will make = the encoding type lose its' own meaning(ie., ISC overrides encoding = type). > =20 > IB>> When a GMPLS CP instance controls several layers, it views the = network as a stack of topologies. Whether a given topology is real or = virtual is of no importance. > The GMPLS ISCD link sub-tlv and, in particular, its switching = capability field (confusing name as it is) is a good way to describe a = layer in technology independent way, so that, say, = MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM layer stack could be perceived as = a stack of topologies that could be easily separated in technology = independent way should path computation be constrained to particular one = or sub-stack of them. > I think a good way to identify an OTN (virtual) topology is via = (infrastructure) ODU container role of ODUs comprising the topology. BTW = IMO the role of an ODU container does not change hop-by-hop (as some = people seem to believe). The role is only meaningful on the ODU = terminating nodes and irrelevant on transit nodes. It is it's position = in the hierarchy (but not role) that may change hop-by-hop. ODU's role = is the level of topology it is provisioned for and it is the same for = all ODUs that comprise the topology. For, example a user may provision a = LO topology and constrain ODUs he sells to a set of clients to use the = topology rather than any resources available on OTN network. > The bottom line: container's role is the same as the role of virtual = topology the container is a part of and could be advertised as the = corresponding link switchcap. > =20 > According to the point 3, I don't know how to advertise the roles and = muxing capabilities with the ISCD of RFC4202, could you clarify? > =20 > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > encoding type =3D mux. capabilities code > =20 > In addition, could you clarify my questions in another email (copied = as follows): > = =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D For Lo ODU, Ho ODU, SHO ODU, they are=20 > relative to each other. > IB>> I disagree. You define role =3D=3D position in the hierarchy, = which is a mistake IMO. > =20 > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho = OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link = supporting ODU2 switching, which can be used as Lo ODU2 (service over = ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how = to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > =20 > IB>> As I mentioned earlier, ODU role is only important on the ODU = terminating nodes (i.e. on either side of corresponding link). What = happens on the ODU transit nodes and its place in the hierarchy on the = transit nodes are of no importance. My LO container can be carried by = somebody else's LO container and can carry my client's LO container. To = some extent it is similar to MPLS LSP role: LSP always has a role (e.g. = PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its = path. > =20 > Cheers, > Igor > =20 > = =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > =20 > =20 > =20 > Thanks > =20 > Fatai > =20 > ----- Original Message ----- > From: "Igor Bryskin" > To: > Cc: "John E Drake" ; "Snigdho Bardalai"=20 > ; "Fatai Zhang" ; "Lou=20 > Berger" ; ;=20 > > Sent: Wednesday, July 14, 2010 10:36 PM > Subject: RE: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > =20 > Curtis, > =20 > Thanks for your comment. > =20 > I agree that there should be multiple OTN specific encoding types = introduced. But IMO they should indicate the link's mux capabilities = rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, = SHO, etc.). The link's role or roles IMO should be indicated with a = separate switchcaps. I can give you several reasons: > =20 > 1. Links with the same mux capabilities may have different roles; 2.=20 > Link may advertise several roles (e.g. HO and SHO) with different=20 > mux.capabilities per role; 3. Link's role and mux. capabilities can be = > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is=20 > required); 4. The combination of swicthcaps and encoding type will = look to CP as a separate layer, which is exactly how ITU models OTN = hierarchies in all aspects but routing (!?) 5. If the operator would = want to constrain the routing of OTN connections to pre-configured = topology with a specific role (e.g. constrain all ODUs it sells to the = clients to one or more pre-configured LO topologies), this would be = possible to do in a technology independent way. Suppose an instance of = GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN = links will be no different from the separation of WDM links from OTUs. > =20 > Cheers, > Igor > =20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 13, 2010 6:24 PM > To: Igor Bryskin > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger;=20 > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > =20 > In message=20 > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaopti > cal.com> > Igor Bryskin writes: > > > > I think OTN links require more than one switchcaps: as many as the = depth of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > =20 > =20 > It would be better IMHO to keep the Switch Type as TDM and make the > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > =20 > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > replaced the Encoding Type of "Digital Wrapper" a long time ago. > =20 > Replacing the Encoding Type would insure that any LSR that did not > understand what the TS type meant did not try to multiplex its LO ODU > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > a 1.25 TS granularity for another LO ODU. > =20 > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > then the corresponding G.709 Digital Path FA can be withdrawn. > =20 > The Encoding type would be the lower encoding at each end of the LSP > regardless of what goes on in the middle since that determines what > can be wrapped inside it. > =20 > For example: > =20 > OTU3 > OTU2 ODUk=3D3 -------------- > OTU1 ODUk=3D2 -- ODUj=3D2 > ODUk=3D1 --- ODUj=3D1 -- > =20 > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex = even > though the ODUk=3D2 at the next hop could not directly contain an = ODU0. > If the SHO Encoding Type is used, then it indicates that two levels of > multiplexing could be supported at that switch/LSR. > =20 > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > Types currently don't include an ODUj or ODUk distinction but if > Encoding Type indicated LO or HO, that may not be needed. Along with > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > and ODU2e, can be added. > =20 > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > how in an FA it can be indicated that either type is currently > available (NE capable of both and hasn't committed to either one yet). > =20 > BTW- Maybe I'm missing something but the number of messages on this > would indicate a huge controversy and I'm not getting it (other than a > strong preference to rely on bytes/sec or on enumerated type fields). > =20 > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > other intent. Could someone (either draft) concisely summarize the > multiplexing restrictions in one place, including restrictions on > number of multiplexing layers at one LSR. That might help. > =20 > Curtis > =20 > =20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On = Behalf Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework = document > > > before we can embark on any proposals to the problem. I am still = not clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control = plane, and > > > it is highly desirable to adhere to the layer independent paradigm = of > > > advertising of TE links, and there is no reason to invent an OTN = specific > > > ISCD. The combination of Switching Capability and Encoding type of = RFC4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN = layer > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you = have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link = to > > > represent >the low-order ODUj bandwidth within the high-order = containers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to = create OTN > > > hierarchies and constrain LO connections to HO containers, one = needs to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; = draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more = feasible > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for = control > > > plane, no matter how you encode the routing information. For TDM = networks, > > > you know the resource is allocated based on TS, so the available = TS should > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I = think > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you = will find > > > that one of your suggestions is adopted (i.e., simply advertize = the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container = instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA = for ODU1, > > > you have to advertise a new TE link or put this FA as a component = link of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; = > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; = draft-ietf-ccamp-gmpls- > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to = better > > > > align the work with 4202. Use of common approaches is of course = one of > > > > the main objectives of *C*CAMP. I look forward to hearing from = the > > > > draft and discussion contributors on there progress on this = point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This = section > > > >> describes the link-parameters that are required for OTN service = routing > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, = consider an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then = we > > > >> establish an ODU2 service over the link. At this point in time = the OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to = 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained = over the > > > >> ODU2). So it is obvious from this example that the number of = time-slots > > > >> available is different based on the signal-type (i.e. ODU1 and = ODU2). > > > >> How do we address this issue based on the approach specified in = the > > > draft? > > > >> > > > >> My other question is why not simply advertize the available = number of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the = equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be = more > > > >> in-line with the general approach outlined in RFC-4202. Refer = to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit = is that > > > >> the advertisement is TS size independent and hence will = simplify the > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho From SBardalai@infinera.com Tue Jul 20 08:10:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091C23A6896 for ; Tue, 20 Jul 2010 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8RFStBn2M38 for ; Tue, 20 Jul 2010 08:10:06 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id 577C53A67E1 for ; Tue, 20 Jul 2010 08:10:06 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Tue, 20 Jul 2010 08:10:21 -0700 From: Snigdho Bardalai To: "curtis@occnc.com" , Fatai Zhang Date: Tue, 20 Jul 2010 08:10:04 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoGzAkjssJjan2Qh+rbaf7uUN0bQAAd82w Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE726B@SV-EXDB1.infinera.com> References: Your message of "Mon, 19 Jul 2010 10:48:45 +0800." <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> In-Reply-To: <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Igor Bryskin Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 15:10:10 -0000 Curtis, very well put...the issue gets amplified with the inverse-multiplex= ing use-cases. Thanks, Snigdho > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 7:52 AM > To: Fatai Zhang > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou > Berger; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > Fatai Zhang writes: > > > > Hi Igor, > > > > Thanks. > > Sorry to jump in but I think I understand Igor's objection (and > Snigdho's objection, and the reason this thread is going on). > > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't think > > that we need to extend ISC to meet the requirment. The role of the > ODU > > can be get from the routing information implicitly. In the > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" is introduced. > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > I think the objection, which would be a very valid one, is that the > ingress has no way to know apriori that a path is infeasible. Each > crankback delays convergence. Crankback should only occur if another > ingress has reserved resources before signaling was completed, not > because inadequate routing information is provided in quiescent state. > > Curtis > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Lou Berger" ; > ; framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > define different roles depending on their policy and achieve the role > through different methods. However, for OTN networks, the containers > (e.g., ODUk) all have the same switching capablility (i.e., TDM > switching) and I think we should reflect the natural characteristics of > links in the routing. In addition, if we extend the ISC, it will make > the encoding type lose its' own meaning(ie., ISC overrides encoding > type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > network as a stack of topologies. Whether a given topology is real or > virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > capability field (confusing name as it is) is a good way to describe a > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > topologies that could be easily separated in technology independent way > should path computation be constrained to particular one or sub-stack > of them. > > I think a good way to identify an OTN (virtual) topology is via > (infrastructure) ODU container role of ODUs comprising the topology. > BTW IMO the role of an ODU container does not change hop-by-hop (as > some people seem to believe). The role is only meaningful on the ODU > terminating nodes and irrelevant on transit nodes. It is it's position > in the hierarchy (but not role) that may change hop-by-hop. ODU's role > is the level of topology it is provisioned for and it is the same for > all ODUs that comprise the topology. For, example a user may provision > a LO topology and constrain ODUs he sells to a set of clients to use > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > topology the container is a part of and could be advertised as the > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles and > muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link > supporting ODU2 switching, which can be used as Lo ODU2 (service over > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > terminating nodes (i.e. on either side of corresponding link). What > happens on the ODU transit nodes and its place in the hierarchy on the > transit nodes are of no importance. My LO container can be carried by > somebody else's LO container and can carry my client's LO container. To > some extent it is similar to MPLS LSP role: LSP always has a role (e.g. > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Fatai Zhang" ; "Lou > Berger" ; ; g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > introduced. But IMO they should indicate the link's mux capabilities > rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, > SHO, etc.). The link's role or roles IMO should be indicated with a > separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; > > 2. Link may advertise several roles (e.g. HO and SHO) with different > mux.capabilities per role; > > 3. Link's role and mux. capabilities can be advertised with ISCDs as > defined in RFC4202 (no OTN-style ISCD is required); > > 4. The combination of swicthcaps and encoding type will look to CP as > a separate layer, which is exactly how ITU models OTN hierarchies in > all aspects but routing (!?) > > 5. If the operator would want to constrain the routing of OTN > connections to pre-configured topology with a specific role (e.g. > constrain all ODUs it sells to the clients to one or more pre- > configured LO topologies), this would be possible to do in a technology > independent way. Suppose an instance of GMPLS CP manages WDM and OTN > NEs. Then separation of LO from HO OTN links will be no different from > the separation of WDM links from OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO ODU > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > > can be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex = even > > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along with > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > other intent. Could someone (either draft) concisely summarize the > > multiplexing restrictions in one place, including restrictions on > > number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still > not clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm of > > > > advertising of TE links, and there is no reason to invent an OTN > specific > > > > ISCD. The combination of Switching Capability and Encoding type > of RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > > represent >the low-order ODUj bandwidth within the high-order > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create OTN > > > > hierarchies and constrain LO connections to HO containers, one > needs to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > networks, > > > > you know the resource is allocated based on TS, so the available > TS should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will find > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > better > > > > > align the work with 4202. Use of common approaches is of > course one of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this > point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > > >> establish an ODU2 service over the link. At this point in time > the OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to > 12+4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over the > > > > >> ODU2). So it is obvious from this example that the number of > time-slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > > > >> How do we address this issue based on the approach specified > in the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > equivalent > > > > >> bandwidth in bytes/sec within a link? This approach seems to > be more > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit > is that > > > > >> the advertisement is TS size independent and hence will > simplify the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 08:21:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583663A68B5 for ; Tue, 20 Jul 2010 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pruZF5n9sAvZ for ; Tue, 20 Jul 2010 08:21:25 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 8A65B3A67E1 for ; Tue, 20 Jul 2010 08:21:24 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KFLUrD012716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 17:21:30 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 17:21:30 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 17:21:30 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 11:21:26 -0400 From: Igor Bryskin To: Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 11:21:13 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQg Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_06:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 15:21:28 -0000 It is a valid point, but the suggested solution is way too expensive. All y= ou need is a way to say how the advertised unreserved bandwidth is partitio= ned between ISCDs in case the TE link advertisement contains several of the= m. One cheap way of doing so is to allocate 3-4 bits out of the ISCD sub-TL= V reserved bits to indicate the fraction of total unreserved bandwidth asso= ciated with the ISCD. Another way is to use swicthcap specific extension. BTW: this is not an OTN specific issue, rather more general: any time when = a TE link advertises more than one ISCD (which is perfectly Ok according to= 4203) you'll have the same problem. Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 10:57 AM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, The need for unreserved resources advertised per signal type is the concurr= ent path computation. I'll answer quoting a section from the info-model dra= ft, please have a look in particular to the example: " Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority, this leads not to know how many LSPs of a specific signal type can be restored. As example it is possible to consider the scenario depicted in the following figure. +------+ component link 1 +------+ | +------------------+ | | | component link 2 | | | N1 +------------------+ N2 | | | component link 3 | | | +------------------+ | +------+ +---+--+ Suppose to have a TE link comprising 3 ODU3 component links with 32TSs available on the first one, 24TSs on the second, 24TSs on the third and supporting ODU2 and ODU3 signal types. The node would advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the network could try to restore 2 ODU3 (64TSs) in such TE-link while only a single ODU3 can be set up and a crank-back would be originated. In more complex network scenarios the number of crank-backs can be much higher." In other words, advertising the number of availble resources per signal typ= e does not avoid the possibility of cranck-back but decreases it as much as= possible. For sure a good routing prevents from crank-backs caused by the = restoration of LSP originating on the same Ingress. The cranck-backs due to= the concurrent restoration of LSPs originating on different ingress nodes = cannot be avoided. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: marted=EC 20 luglio 2010 16.16 To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In line -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 4:32 AM To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, one more question. What about the unreserved bandwidth? If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCap = & signal type) you also need to advertise the unreserved bandwidth using 1 = unreserved bandwidth sub-TLV per ISCD, correct? This also implies extending= the unreserved bandwidth TLV so to create a corrispondence between the cou= ples (ISCD-unreserved bandwidth subTLV). IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per IB>> role per (muxCap & signal type) per priority level. However, total IB>> unreserved bandwidth IMO is OK to share between roles unless you IB>> see a compelling reason to the contrary (which I don't) Igor Thanks Daniele -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: luned=EC 19 luglio 2010 17.48 To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but > agree with your observation on the encode-type and the 16 > reserved-bits to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't > > think that we need to extend ISC to meet the requirment. The role of > > the > ODU > > can be get from the routing information implicitly. In the [draft- > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE > > links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ; > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > > define different roles depending on their policy and achieve the > > role through different methods. However, for OTN networks, the > > containers (e.g., ODUk) all have the same switching capablility > > (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will > > make the encoding type lose its' own meaning(ie., ISC overrides > > encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real > > or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or > > sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > some people seem to believe). The role is only meaningful on the ODU > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same > > for all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > > topology the container is a part of and could be advertised as the > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried > > by somebody else's LO container and can carry my client's LO container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ; > > "Lou Berger" ; ; > > gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > > introduced. But IMO they should indicate the link's mux capabilities > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN > > hierarchies in all aspects but routing (!?) 5. If the operator would > > want to constrain the routing of OTN connections to pre-configured > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > in turn replaced the Encoding Type of "Digital Wrapper" a long time ago= . > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > granularity, then the corresponding G.709 Digital Path FA can be withdr= awn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex > > even though the ODUk=3D2 at the next hop could not directly contain an = ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > ODU-flex, and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > or other intent. Could someone (either draft) concisely summarize > > the multiplexing restrictions in one place, including restrictions > > on number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > >TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > other interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > will find that one of your suggestions is adopted (i.e., simply > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress > > > > > on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order > > > > >> ODUj availability within a higher-order container. For > > > > >> example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > >> then > > we > > > > >> establish an ODU2 service over the link. At this point in > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > >> services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > >> are contained over the ODU2). So it is obvious from this > > > > >> example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > >> approach seems to be more in-line with the general approach > > > > >> outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > >> being advertised per VC rate for an SDH link. The additional > > > > >> benefit > > is > > > > >> that the advertisement is TS size independent and hence will > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Tue Jul 20 08:27:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C32A3A6831 for ; Tue, 20 Jul 2010 08:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reTufp8TI14P for ; Tue, 20 Jul 2010 08:27:15 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 2D5AE3A6887 for ; Tue, 20 Jul 2010 08:27:11 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KFRFUo020695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 17:27:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 17:27:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 11:27:12 -0400 From: Igor Bryskin To: "curtis@occnc.com" , Fatai Zhang Date: Tue, 20 Jul 2010 11:27:10 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoGzic6LEOz9fYTFWxk3RTTB+clAABDYWw Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760D1@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Mon, 19 Jul 2010 10:48:45 +0800." <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> In-Reply-To: <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_06:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 15:27:17 -0000 Curtis, I agree with your concerns about cranbacks. I never liked solutions that re= ly on crankbacks. But what I was saying is that path computation in the des= cribed example will be able to figure that the path is not feasible, hence = the ingress node will know that without signaling failure. Cheers and hope to see you in Maastricht. Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Tuesday, July 20, 2010 10:52 AM To: Fatai Zhang Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou Ber= ger; ccamp@ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> Fatai Zhang writes: > > Hi Igor, > > Thanks. Sorry to jump in but I think I understand Igor's objection (and Snigdho's objection, and the reason this thread is going on). > I understand what you said. Therefore, we have added some text to > address the requirment in FWK document. However, we still don't think > that we need to extend ISC to meet the requirment. The role of the ODU > can be get from the routing information implicitly. In the > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > Lambda" is introduced. > > A quick question on your statement: "the role of an ODU container does > not change hop-by-hop (as some people seem to believe). The role is > only meaningful on the ODU terminating nodes and irrelevant on transit > nodes. It is it's position in the hierarchy (but not role) that may > change hop-by-hop. " > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > of Ho ODU level is requested, according to your statement, this > conneciton will be allowed to be created. However, it should not be > allowed because the ISC is not consistent along the LSP. > > Please see the text from RFC3473: "Nodes MUST verify that the type > indicated in the Switching Type parameter is supported on the > corresponding incoming interface. If the type cannot be supported, > the node MUST generate a PathErr message with a "Routing > problem/Switching Type" indication." I think the objection, which would be a very valid one, is that the ingress has no way to know apriori that a path is infeasible. Each crankback delays convergence. Crankback should only occur if another ingress has reserved resources before signaling was completed, not because inadequate routing information is provided in quiescent state. Curtis > Best Regards > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: "Fatai Zhang" ; > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; > Sent: Friday, July 16, 2010 12:34 AM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > > Fatai, > Please, see my answers in line. > > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, July 14, 2010 9:52 PM > To: Igor Bryskin; curtis@occnc.com > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-iet= f-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Hi Igor and all, > > Thanks for all your comments. > > I think role does not equal switching capability. The operators can defin= e different roles depending on their policy and achieve the role through di= fferent methods. However, for OTN networks, the containers (e.g., ODUk) all= have the same switching capablility (i.e., TDM switching) and I think we s= hould reflect the natural characteristics of links in the routing. In addit= ion, if we extend the ISC, it will make the encoding type lose its' own mea= ning(ie., ISC overrides encoding type). > > IB>> When a GMPLS CP instance controls several layers, it views the netwo= rk as a stack of topologies. Whether a given topology is real or virtual is= of no importance. > The GMPLS ISCD link sub-tlv and, in particular, its switching capability = field (confusing name as it is) is a good way to describe a layer in techno= logy independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM l= ayer stack could be perceived as a stack of topologies that could be easily= separated in technology independent way should path computation be constra= ined to particular one or sub-stack of them. > I think a good way to identify an OTN (virtual) topology is via (infrastr= ucture) ODU container role of ODUs comprising the topology. BTW IMO the rol= e of an ODU container does not change hop-by-hop (as some people seem to be= lieve). The role is only meaningful on the ODU terminating nodes and irrele= vant on transit nodes. It is it's position in the hierarchy (but not role) = that may change hop-by-hop. ODU's role is the level of topology it is provi= sioned for and it is the same for all ODUs that comprise the topology. For,= example a user may provision a LO topology and constrain ODUs he sells to = a set of clients to use the topology rather than any resources available on= OTN network. > The bottom line: container's role is the same as the role of virtual topo= logy the container is a part of and could be advertised as the correspondin= g link switchcap. > > According to the point 3, I don't know how to advertise the roles and mux= ing capabilities with the ISCD of RFC4202, could you clarify? > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > encoding type =3D mux. capabilities code > > In addition, could you clarify my questions in another email (copied as f= ollows): > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > IB>> I disagree. You define role =3D=3D position in the hierarchy, which = is a mistake IMO. > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN= Level or Lo OTN Level? Another example is, if there is a OTU3 link support= ing ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directl= y) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate= if this ODU2 is Lo OTN Level or Ho OTN Level? > > IB>> As I mentioned earlier, ODU role is only important on the ODU termin= ating nodes (i.e. on either side of corresponding link). What happens on th= e ODU transit nodes and its place in the hierarchy on the transit nodes are= of no importance. My LO container can be carried by somebody else's LO con= tainer and can carry my client's LO container. To some extent it is similar= to MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it co= uld be anywhere in MPLS stack along its path. > > Cheers, > Igor > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Thanks > > Fatai > > ----- Original Message ----- > From: "Igor Bryskin" > To: > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; > Sent: Wednesday, July 14, 2010 10:36 PM > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > > Curtis, > > Thanks for your comment. > > I agree that there should be multiple OTN specific encoding types introdu= ced. But IMO they should indicate the link's mux capabilities rather than t= he link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The li= nk's role or roles IMO should be indicated with a separate switchcaps. I ca= n give you several reasons: > > 1. Links with the same mux capabilities may have different roles; > 2. Link may advertise several roles (e.g. HO and SHO) with different mux.= capabilities per role; > 3. Link's role and mux. capabilities can be advertised with ISCDs as defi= ned in RFC4202 (no OTN-style ISCD is required); > 4. The combination of swicthcaps and encoding type will look to CP as a s= eparate layer, which is exactly how ITU models OTN hierarchies in all aspec= ts but routing (!?) > 5. If the operator would want to constrain the routing of OTN connections= to pre-configured topology with a specific role (e.g. constrain all ODUs i= t sells to the clients to one or more pre-configured LO topologies), this w= ould be possible to do in a technology independent way. Suppose an instance= of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN lin= ks will be no different from the separation of WDM links from OTUs. > > Cheers, > Igor > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 13, 2010 6:24 PM > To: Igor Bryskin > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.o= rg; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.= advaoptical.com> > Igor Bryskin writes: > > > > I think OTN links require more than one switchcaps: as many as the dept= h of the deepest possible OTN DP hierarchy, for example: > > > > typedef enum > > { > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > /*****/ > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > , LSPSwitchType_LSC =3D150 /* LSC */ > > , LSPSwitchType_FSC =3D200 /* FSC */ > > }e_LSPSwitchType; > > > It would be better IMHO to keep the Switch Type as TDM and make the > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > Replacing the Encoding Type would insure that any LSR that did not > understand what the TS type meant did not try to multiplex its LO ODU > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > a 1.25 TS granularity for another LO ODU. > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > then the corresponding G.709 Digital Path FA can be withdrawn. > > The Encoding type would be the lower encoding at each end of the LSP > regardless of what goes on in the middle since that determines what > can be wrapped inside it. > > For example: > > OTU3 > OTU2 ODUk=3D3 -------------- > OTU1 ODUk=3D2 -- ODUj=3D2 > ODUk=3D1 --- ODUj=3D1 -- > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex ev= en > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > If the SHO Encoding Type is used, then it indicates that two levels of > multiplexing could be supported at that switch/LSR. > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > Types currently don't include an ODUj or ODUk distinction but if > Encoding Type indicated LO or HO, that may not be needed. Along with > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > and ODU2e, can be added. > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > how in an FA it can be indicated that either type is currently > available (NE capable of both and hasn't committed to either one yet). > > BTW- Maybe I'm missing something but the number of messages on this > would indicate a huge controversy and I'm not getting it (other than a > strong preference to rely on bytes/sec or on enumerated type fields). > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > other intent. Could someone (either draft) concisely summarize the > multiplexing restrictions in one place, including restrictions on > number of multiplexing layers at one LSR. That might help. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 08, 2010 1:59 PM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.or= g > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-0= 1.txt > > > > What do you mean by "different switchcaps"? > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f Of > > > Igor Bryskin > > > Sent: Thursday, July 08, 2010 10:53 AM > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.= org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework docume= nt > > > before we can embark on any proposals to the problem. I am still not = clear > > > why do we have to deviate from the general approach that has been > > > established in RFC 4202. > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane,= and > > > it is highly desirable to adhere to the layer independent paradigm of > > > advertising of TE links, and there is no reason to invent an OTN spec= ific > > > ISCD. The combination of Switching Capability and Encoding type of RF= C4202 > > > ISCD allows for specifying both multiplexing capabilities and OTN lay= er > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > another reserved 16 bits. > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > represent >the low-order ODUj bandwidth within the high-order contain= ers. > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create O= TN > > > hierarchies and constrain LO connections to HO containers, one needs = to > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > To: Snigdho Bardalai; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.= org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > interested experts, and we think the proposal described in "draft- > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasi= ble > > > for OTN networks. > > > > > > > > > > > > The framework draft just tells you what information needed for contro= l > > > plane, no matter how you encode the routing information. For TDM netw= orks, > > > you know the resource is allocated based on TS, so the available TS s= hould > > > be get or induced before creating cross-connect. > > > > > > > > > > > > If you are trying to find how to encode the routing information, I th= ink > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will= find > > > that one of your suggestions is adopted (i.e., simply advertize the > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > One more thing for your first comment: > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for O= DU1, > > > you have to advertise a new TE link or put this FA as a component lin= k of > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > > > > ----- Original Message ----- > > > > > > From: "Snigdho Bardalai" > > > > > > > > > To: "Lou Berger" > > > > > > > Cc: >; > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > > > > > > > > Hi Lou > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > Snigdho > > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > To: Snigdho Bardalai > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls= - > > > g709-framework@tools.ietf.org > > framework@tools.ietf.org> > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewo= rk- > > > 01.txt > > > > > > > > Snigdho, > > > > I believe there has been some off-line discussion on how to better > > > > align the work with 4202. Use of common approaches is of course on= e of > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > draft and discussion contributors on there progress on this point. > > > > > > > > Lou > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > >> Hello, > > > >> > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > >> describes the link-parameters that are required for OTN service ro= uting > > > >> purposes. > > > >> > > > >> My comment is how are we going to advertise the low-order ODUj > > > >> availability within a higher-order container. For example, conside= r an > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > >> establish an ODU2 service over the link. At this point in time the= OTU3 > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > >> time-slots available for ODU1 services (4 ODU1s are contained over= the > > > >> ODU2). So it is obvious from this example that the number of time-= slots > > > >> available is different based on the signal-type (i.e. ODU1 and ODU= 2). > > > >> How do we address this issue based on the approach specified in th= e > > > draft? > > > >> > > > >> My other question is why not simply advertize the available number= of > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > >> bandwidth in bytes/sec within a link? This approach seems to be mo= re > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > section > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > >> advertised per VC rate for an SDH link. The additional benefit is = that > > > >> the advertisement is TS size independent and hence will simplify t= he > > > >> implementation. > > > >> > > > >> Regards > > > >> > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 09:00:25 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8233A6B2C for ; Tue, 20 Jul 2010 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.731 X-Spam-Level: X-Spam-Status: No, score=-5.731 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vMM-tFuieIT for ; Tue, 20 Jul 2010 09:00:18 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 5B0133A6BDA for ; Tue, 20 Jul 2010 09:00:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXH+11YO9k3+VzqbUQ9oDA9NOQp7whs@postini.com; Tue, 20 Jul 2010 09:00:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Jul 2010 08:54:05 -0700 From: John E Drake To: Igor Bryskin , Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 08:54:03 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAADrhiA= Message-ID: <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:00:25 -0000 Igor, Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue of = partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs i= s actually a non-issue. Unreserved bandwidth by priority has always been advertised using the MPLS = sub-TLV. My point has been that we have never had a requirement (including= SDH/SONET) in the past to advertise unreserved bandwidth by signal type, s= o what is special about OTN? A further point would be that if we do decide that it is necessary to adver= tise unreserved bandwidth by signal type, it should be done in a general wa= y and not in an OTN specific manner. (And in fact, the arguments that unre= served bandwidth by signal type needs to be advertised, such as the latest = e-mail from Curtis, are not OTN specific.) Thanks, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: Tuesday, July 20, 2010 8:21 AM > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > It is a valid point, but the suggested solution is way too expensive. > All you need is a way to say how the advertised unreserved bandwidth is > partitioned between ISCDs in case the TE link advertisement contains > several of them. One cheap way of doing so is to allocate 3-4 bits out > of the ISCD sub-TLV reserved bits to indicate the fraction of total > unreserved bandwidth associated with the ISCD. Another way is to use > swicthcap specific extension. > BTW: this is not an OTN specific issue, rather more general: any time > when a TE link advertises more than one ISCD (which is perfectly Ok > according to 4203) you'll have the same problem. > > Igor > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 10:57 AM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > The need for unreserved resources advertised per signal type is the > concurrent path computation. I'll answer quoting a section from the > info-model draft, please have a look in particular to the example: > > > " Unreserved resources need to be advertised per priority and per > signal type in order to allow the correct functioning of the > restoration process. [RFC4203] only allows advertising unreserved > resources per priority, this leads not to know how many LSPs of a > specific signal type can be restored. As example it is possible to > consider the scenario depicted in the following figure. > > +------+ component link 1 +------+ > | +------------------+ | > | | component link 2 | | > | N1 +------------------+ N2 | > | | component link 3 | | > | +------------------+ | > +------+ +---+--+ > > Suppose to have a TE link comprising 3 ODU3 component links with > 32TSs available on the first one, 24TSs on the second, 24TSs on the > third and supporting ODU2 and ODU3 signal types. The node would > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > LSP bandwidth equal to 32 TSs. In case of restoration the network > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > single ODU3 can be set up and a crank-back would be originated. In > more complex network scenarios the number of crank-backs can be much > higher." > > In other words, advertising the number of availble resources per signal > type does not avoid the possibility of cranck-back but decreases it as > much as possible. For sure a good routing prevents from crank-backs > caused by the restoration of LSP originating on the same Ingress. The > cranck-backs due to the concurrent restoration of LSPs originating on > different ingress nodes cannot be avoided. > > BR > Daniele > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: marted=EC 20 luglio 2010 16.16 > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > In line > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 4:32 AM > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, one more question. > > What about the unreserved bandwidth? > If you're advertising the max lsp bandwidth by 1 ISCD per role per > (muxCap & signal type) you also need to advertise the unreserved > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > also implies extending the unreserved bandwidth TLV so to create a > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > IB>> role per (muxCap & signal type) per priority level. However, total > IB>> unreserved bandwidth IMO is OK to share between roles unless you > IB>> see a compelling reason to the contrary (which I don't) > > Igor > > Thanks > Daniele > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: luned=EC 19 luglio 2010 17.48 > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Understood... > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 8:46 AM > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient > > > > That's exactly what I've been > > trying to say all along. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Monday, July 19, 2010 11:31 AM > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor > > > > Please see inline. > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 7:43 AM > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Daniele, > > > > > > Please, see in line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Monday, July 19, 2010 10:31 AM > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > role > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > type. > > > > > > IB>> in ISCD: > > > switchCap =3D role; > > > encodeType =3D muxCap & signal type; > > > We also have 16 reserved bits which can use for OTN specific info > in > > > case we need it. > > [SCB] I am yet to clearly understand what the role of "role" is, but > > agree with your observation on the encode-type and the 16 > > reserved-bits to further classify the switching information. > > > > > > In case (a) you're still missing a lot of information. For each > role > > > you would advertise just the unreserved bandwidth but you wouldn't > > know > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > 15 > > > Gbps available on 3 component links: you advertise 45 Gbps > available > > > but no ODU3 can be set up on such TE link). > > > > > > In case (b) the number of ISCDs would cause serious scalability > > issues > > > and the requirement of being able to bundle component links > together > > > wouldn't be satisfied. > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > will > > > provide a lot of flexibility: you can specify different things > (e.g. > > > available bandwidth) for the same link in different roles. > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient? > > > > > > Cheers, > > > Daniele > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: luned=EC 19 luglio 2010 15.40 > > > To: Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Fatai, > > > > > > Please, see my responses on-line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Fatai Zhang > > > Sent: Sunday, July 18, 2010 10:49 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > Thanks. > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't > > > think that we need to extend ISC to meet the requirment. The role > of > > > the > > ODU > > > can be get from the routing information implicitly. In the [draft- > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > Lambda" > > is > > > introduced. > > > > > > IB>> This is possible, however: > > > a) this requires OTN specific advertising and processing rules; > > > b) disallows topology separation in technology independent way > > > > > > A quick question on your statement: "the role of an ODU container > > does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on > > transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > ends > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > TE > > > links will > > be > > > disallowed, and the resulting path (if any) will not go through B11 > > and > > > B12. If one circumvents the path computation by providing the fully > > > explicit path, the signaling should fail on node B for the same > > reason: > > > inconsistency of required (signaled) and supported (by local > > > interfaces) switchcap. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be > supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > IB>> Indeed > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Lou Berger" ; > > > ; > > framework@tools.ietf.org> > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > draft- > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can > > > define different roles depending on their policy and achieve the > > > role through different methods. However, for OTN networks, the > > > containers (e.g., ODUk) all have the same switching capablility > > > (i.e., TDM > > > switching) and I think we should reflect the natural > characteristics > > of > > > links in the routing. In addition, if we extend the ISC, it will > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > encoding type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > network as a stack of topologies. Whether a given topology is real > > > or virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > capability field (confusing name as it is) is a good way to > describe > > a > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > topologies that could be easily separated in technology independent > > way > > > should path computation be constrained to particular one or > > > sub-stack of them. > > > I think a good way to identify an OTN (virtual) topology is via > > > (infrastructure) ODU container role of ODUs comprising the > topology. > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > some people seem to believe). The role is only meaningful on the > ODU > > > terminating nodes and irrelevant on transit nodes. It is it's > > position > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > role > > > is the level of topology it is provisioned for and it is the same > > > for all ODUs that comprise the topology. For, example a user may > > provision > > > a LO topology and constrain ODUs he sells to a set of clients to > use > > > the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of > virtual > > > topology the container is a part of and could be advertised as the > > > corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles > > > and muxing capabilities with the ISCD of RFC4202, could you > clarify? > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type =3D mux. capabilities code > > > > > > In addition, could you clarify my questions in another email > (copied > > as > > > follows): > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > which > > is > > > a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > OTU3 > > link > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > over > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > how > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > terminating nodes (i.e. on either side of corresponding link). What > > > happens on the ODU transit nodes and its place in the hierarchy on > > the > > > transit nodes are of no importance. My LO container can be carried > > > by somebody else's LO container and can carry my client's LO > container. > > To > > > some extent it is similar to MPLS LSP role: LSP always has a role > > (e.g. > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > path. > > > > > > Cheers, > > > Igor > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Fatai Zhang" ; > > > "Lou Berger" ; ; > > > > gmpls- > > > g709-framework@tools.ietf.org> > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types > > > introduced. But IMO they should indicate the link's mux > capabilities > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > with a separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; > 2. > > > Link may advertise several roles (e.g. HO and SHO) with different > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > be > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > required); 4. The combination of swicthcaps and encoding type will > > look > > > to CP as a separate layer, which is exactly how ITU models OTN > > > hierarchies in all aspects but routing (!?) 5. If the operator > would > > > want to constrain the routing of OTN connections to pre-configured > > > topology with a specific role (e.g. constrain all ODUs it sells to > > the > > > clients to one or more pre-configured LO topologies), this would be > > > possible to do in a technology independent way. Suppose an instance > > of > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > links will be no different from the separation of WDM links from > > OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as > the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > ago. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > to > > using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > latter > > > is for backward compatibility and should be ignored if OTN_LO, > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > granularity, then the corresponding G.709 Digital Path FA can be > withdrawn. > > > > > > The Encoding type would be the lower encoding at each end of the > LSP > > > regardless of what goes on in the middle since that determines what > > can > > > be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3D3 -------------- > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dfle= x > > > even though the ODUk=3D2 at the next hop could not directly contain > an ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels > > of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > ODU-flex, and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one > > yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other > than > > a > > > strong preference to rely on bytes/sec or on enumerated type > fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > or other intent. Could someone (either draft) concisely summarize > > > the multiplexing restrictions in one place, including restrictions > > > on number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > Behalf Of Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > document before we can embark on any proposals to the problem. > I > > am > > > > > still not clear why do we have to deviate from the general > > approach > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > IB>> plane, and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > > > of advertising of TE links, and there is no reason to invent an > > OTN > > > > > specific ISCD. The combination of Switching Capability and > > Encoding > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > if > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > >TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > > This is simply >blowing up the solution to a very simple > problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > > IB>> OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > other interested experts, and we think the proposal described > in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > control plane, no matter how you encode the routing > information. > > > For > > > > > TDM networks, you know the resource is allocated based on TS, > so > > > the > > > > > available TS should be get or induced before creating cross- > > > connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > information, > > I > > > > > think you need go to the routing drafts (info model and > > encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > you > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > container instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; > > > > > > draft-ietf-ccamp-gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > > > one of the main objectives of *C*CAMP. I look forward to > > hearing > > > > > > from the draft and discussion contributors on there progress > > > > > > on > > > this point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > > >> routing purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order > > > > > >> ODUj availability within a higher-order container. For > > > > > >> example, consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > >> then > > > we > > > > > >> establish an ODU2 service over the link. At this point in > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > >> services > > and > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > >> example > > > that > > > > > >> the number of time-slots available is different based on the > > > signal-type (i.e. ODU1 and ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > > >> the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > the > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > >> approach seems to be more in-line with the general approach > > > > > >> outlined in RFC-4202. Refer to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > >> benefit > > > is > > > > > >> that the advertisement is TS size independent and hence will > > > > > >> simplify the implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Tue Jul 20 09:16:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634EE3A69FF for ; Tue, 20 Jul 2010 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE9IUfZOvyXT for ; Tue, 20 Jul 2010 09:15:57 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E782E3A6AF6 for ; Tue, 20 Jul 2010 09:15:56 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6KGG3iI024105 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Jul 2010 18:16:03 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 20 Jul 2010 18:16:03 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin Date: Tue, 20 Jul 2010 18:16:01 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzA= Message-ID: References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:16:00 -0000 Igor, You jump right now at the solution ! There is a problem of spatial allocati= on and we tried to solve it suggesting a format. This cannot be the best one but at least before saying it is too expensive = , the comparison has to be made with one can address the issue as well. Thi= s is not the case for the present RFC 4202/4203 as you admit proposing a mo= dification. We are open to discuss the "best way" to solve different issues= we depicted in the info draft. On the other hand you pointed out correctly that this is not an OTN specifi= c issue: in fact in SDH we have the same problem and btw a similar approach= of what proposed by us is proposed also in the draft-ong-gmpls-ason-routin= g-exper-02. I realized from someone in this thread (not from you) this was due just to = ignorance and misunderstanding of RFC 4202/4203 bandwidth advertisement for= SDH . Anyway it is a fact that the alternative format is used in many impl= ementations "in field" for SDH control plane. I think could be a good point try to have at the end one single format that= can accomplish issues coming from different TDM technologies. Once that we have a common understanding of requirements and issues nothing= prevent to progress the format in the best way. Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: marted=EC 20 luglio 2010 17.21 A: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t It is a valid point, but the suggested solution is way too expensive. All y= ou need is a way to say how the advertised unreserved bandwidth is partitio= ned between ISCDs in case the TE link advertisement contains several of the= m. One cheap way of doing so is to allocate 3-4 bits out of the ISCD sub-TL= V reserved bits to indicate the fraction of total unreserved bandwidth asso= ciated with the ISCD. Another way is to use swicthcap specific extension. BTW: this is not an OTN specific issue, rather more general: any time when = a TE link advertises more than one ISCD (which is perfectly Ok according to= 4203) you'll have the same problem. Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 10:57 AM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, The need for unreserved resources advertised per signal type is the concurr= ent path computation. I'll answer quoting a section from the info-model dra= ft, please have a look in particular to the example: " Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority, this leads not to know how many LSPs of a specific signal type can be restored. As example it is possible to consider the scenario depicted in the following figure. +------+ component link 1 +------+ | +------------------+ | | | component link 2 | | | N1 +------------------+ N2 | | | component link 3 | | | +------------------+ | +------+ +---+--+ Suppose to have a TE link comprising 3 ODU3 component links with 32TSs available on the first one, 24TSs on the second, 24TSs on the third and supporting ODU2 and ODU3 signal types. The node would advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the network could try to restore 2 ODU3 (64TSs) in such TE-link while only a single ODU3 can be set up and a crank-back would be originated. In more complex network scenarios the number of crank-backs can be much higher." In other words, advertising the number of availble resources per signal typ= e does not avoid the possibility of cranck-back but decreases it as much as= possible. For sure a good routing prevents from crank-backs caused by the = restoration of LSP originating on the same Ingress. The cranck-backs due to= the concurrent restoration of LSPs originating on different ingress nodes = cannot be avoided. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: marted=EC 20 luglio 2010 16.16 To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In line -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 4:32 AM To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, one more question. What about the unreserved bandwidth? If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCap = & signal type) you also need to advertise the unreserved bandwidth using 1 = unreserved bandwidth sub-TLV per ISCD, correct? This also implies extending= the unreserved bandwidth TLV so to create a corrispondence between the cou= ples (ISCD-unreserved bandwidth subTLV). IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per IB>> role per (muxCap & signal type) per priority level. However, total IB>> unreserved bandwidth IMO is OK to share between roles unless you IB>> see a compelling reason to the contrary (which I don't) Igor Thanks Daniele -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: luned=EC 19 luglio 2010 17.48 To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but > agree with your observation on the encode-type and the 16 > reserved-bits to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't > > think that we need to extend ISC to meet the requirment. The role of > > the > ODU > > can be get from the routing information implicitly. In the [draft- > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE > > links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ; > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > > define different roles depending on their policy and achieve the > > role through different methods. However, for OTN networks, the > > containers (e.g., ODUk) all have the same switching capablility > > (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will > > make the encoding type lose its' own meaning(ie., ISC overrides > > encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real > > or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or > > sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > some people seem to believe). The role is only meaningful on the ODU > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same > > for all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > > topology the container is a part of and could be advertised as the > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried > > by somebody else's LO container and can carry my client's LO container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ; > > "Lou Berger" ; ; > > gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > > introduced. But IMO they should indicate the link's mux capabilities > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN > > hierarchies in all aspects but routing (!?) 5. If the operator would > > want to constrain the routing of OTN connections to pre-configured > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > in turn replaced the Encoding Type of "Digital Wrapper" a long time ago= . > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > granularity, then the corresponding G.709 Digital Path FA can be withdr= awn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex > > even though the ODUk=3D2 at the next hop could not directly contain an = ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > ODU-flex, and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > or other intent. Could someone (either draft) concisely summarize > > the multiplexing restrictions in one place, including restrictions > > on number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > >TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > other interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > will find that one of your suggestions is adopted (i.e., simply > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress > > > > > on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order > > > > >> ODUj availability within a higher-order container. For > > > > >> example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > >> then > > we > > > > >> establish an ODU2 service over the link. At this point in > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > >> services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > >> are contained over the ODU2). So it is obvious from this > > > > >> example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > >> approach seems to be more in-line with the general approach > > > > >> outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > >> being advertised per VC rate for an SDH link. The additional > > > > >> benefit > > is > > > > >> that the advertisement is TS size independent and hence will > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Tue Jul 20 09:17:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3118B3A69F1 for ; Tue, 20 Jul 2010 09:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vow4oRGq2j8T for ; Tue, 20 Jul 2010 09:16:55 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id D6E983A69A6 for ; Tue, 20 Jul 2010 09:16:54 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KGGvHw023955 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 18:16:57 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 18:16:57 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 18:16:56 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 12:16:54 -0400 From: Igor Bryskin To: John E Drake , Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 12:16:17 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAADrhiAAAUKmgA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_06:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:17:01 -0000 John, I totally agree with you. It is absolutely non OTN specific. However if a T= E link advertises more than one ISCD (with each ISCD containing only max ls= p bandwidth per priority), it is necessary to indicate how the total link u= nreserved bandwidth is partitioned between several ISCDs. What I am suggest= ing is instead of advertising the unreserved bandwidth multiple times (one = per ISCD), indicate how the bandwidth is split between the ISCDs: e.g ISCD1= 75%, ISCD2 25%. Igor. -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 11:54 AM To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis= @occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue of = partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs i= s actually a non-issue. Unreserved bandwidth by priority has always been advertised using the MPLS = sub-TLV. My point has been that we have never had a requirement (including= SDH/SONET) in the past to advertise unreserved bandwidth by signal type, s= o what is special about OTN? A further point would be that if we do decide that it is necessary to adver= tise unreserved bandwidth by signal type, it should be done in a general wa= y and not in an OTN specific manner. (And in fact, the arguments that unre= served bandwidth by signal type needs to be advertised, such as the latest = e-mail from Curtis, are not OTN specific.) Thanks, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: Tuesday, July 20, 2010 8:21 AM > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > It is a valid point, but the suggested solution is way too expensive. > All you need is a way to say how the advertised unreserved bandwidth is > partitioned between ISCDs in case the TE link advertisement contains > several of them. One cheap way of doing so is to allocate 3-4 bits out > of the ISCD sub-TLV reserved bits to indicate the fraction of total > unreserved bandwidth associated with the ISCD. Another way is to use > swicthcap specific extension. > BTW: this is not an OTN specific issue, rather more general: any time > when a TE link advertises more than one ISCD (which is perfectly Ok > according to 4203) you'll have the same problem. > > Igor > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 10:57 AM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > The need for unreserved resources advertised per signal type is the > concurrent path computation. I'll answer quoting a section from the > info-model draft, please have a look in particular to the example: > > > " Unreserved resources need to be advertised per priority and per > signal type in order to allow the correct functioning of the > restoration process. [RFC4203] only allows advertising unreserved > resources per priority, this leads not to know how many LSPs of a > specific signal type can be restored. As example it is possible to > consider the scenario depicted in the following figure. > > +------+ component link 1 +------+ > | +------------------+ | > | | component link 2 | | > | N1 +------------------+ N2 | > | | component link 3 | | > | +------------------+ | > +------+ +---+--+ > > Suppose to have a TE link comprising 3 ODU3 component links with > 32TSs available on the first one, 24TSs on the second, 24TSs on the > third and supporting ODU2 and ODU3 signal types. The node would > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > LSP bandwidth equal to 32 TSs. In case of restoration the network > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > single ODU3 can be set up and a crank-back would be originated. In > more complex network scenarios the number of crank-backs can be much > higher." > > In other words, advertising the number of availble resources per signal > type does not avoid the possibility of cranck-back but decreases it as > much as possible. For sure a good routing prevents from crank-backs > caused by the restoration of LSP originating on the same Ingress. The > cranck-backs due to the concurrent restoration of LSPs originating on > different ingress nodes cannot be avoided. > > BR > Daniele > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: marted=EC 20 luglio 2010 16.16 > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > In line > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 4:32 AM > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, one more question. > > What about the unreserved bandwidth? > If you're advertising the max lsp bandwidth by 1 ISCD per role per > (muxCap & signal type) you also need to advertise the unreserved > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > also implies extending the unreserved bandwidth TLV so to create a > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > IB>> role per (muxCap & signal type) per priority level. However, total > IB>> unreserved bandwidth IMO is OK to share between roles unless you > IB>> see a compelling reason to the contrary (which I don't) > > Igor > > Thanks > Daniele > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: luned=EC 19 luglio 2010 17.48 > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Understood... > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 8:46 AM > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient > > > > That's exactly what I've been > > trying to say all along. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Monday, July 19, 2010 11:31 AM > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor > > > > Please see inline. > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 7:43 AM > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Daniele, > > > > > > Please, see in line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Monday, July 19, 2010 10:31 AM > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > role > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > type. > > > > > > IB>> in ISCD: > > > switchCap =3D role; > > > encodeType =3D muxCap & signal type; > > > We also have 16 reserved bits which can use for OTN specific info > in > > > case we need it. > > [SCB] I am yet to clearly understand what the role of "role" is, but > > agree with your observation on the encode-type and the 16 > > reserved-bits to further classify the switching information. > > > > > > In case (a) you're still missing a lot of information. For each > role > > > you would advertise just the unreserved bandwidth but you wouldn't > > know > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > 15 > > > Gbps available on 3 component links: you advertise 45 Gbps > available > > > but no ODU3 can be set up on such TE link). > > > > > > In case (b) the number of ISCDs would cause serious scalability > > issues > > > and the requirement of being able to bundle component links > together > > > wouldn't be satisfied. > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > will > > > provide a lot of flexibility: you can specify different things > (e.g. > > > available bandwidth) for the same link in different roles. > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient? > > > > > > Cheers, > > > Daniele > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: luned=EC 19 luglio 2010 15.40 > > > To: Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Fatai, > > > > > > Please, see my responses on-line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Fatai Zhang > > > Sent: Sunday, July 18, 2010 10:49 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > Thanks. > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't > > > think that we need to extend ISC to meet the requirment. The role > of > > > the > > ODU > > > can be get from the routing information implicitly. In the [draft- > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > Lambda" > > is > > > introduced. > > > > > > IB>> This is possible, however: > > > a) this requires OTN specific advertising and processing rules; > > > b) disallows topology separation in technology independent way > > > > > > A quick question on your statement: "the role of an ODU container > > does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on > > transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > ends > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > TE > > > links will > > be > > > disallowed, and the resulting path (if any) will not go through B11 > > and > > > B12. If one circumvents the path computation by providing the fully > > > explicit path, the signaling should fail on node B for the same > > reason: > > > inconsistency of required (signaled) and supported (by local > > > interfaces) switchcap. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be > supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > IB>> Indeed > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Lou Berger" ; > > > ; > > framework@tools.ietf.org> > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > draft- > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can > > > define different roles depending on their policy and achieve the > > > role through different methods. However, for OTN networks, the > > > containers (e.g., ODUk) all have the same switching capablility > > > (i.e., TDM > > > switching) and I think we should reflect the natural > characteristics > > of > > > links in the routing. In addition, if we extend the ISC, it will > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > encoding type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > network as a stack of topologies. Whether a given topology is real > > > or virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > capability field (confusing name as it is) is a good way to > describe > > a > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > topologies that could be easily separated in technology independent > > way > > > should path computation be constrained to particular one or > > > sub-stack of them. > > > I think a good way to identify an OTN (virtual) topology is via > > > (infrastructure) ODU container role of ODUs comprising the > topology. > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > some people seem to believe). The role is only meaningful on the > ODU > > > terminating nodes and irrelevant on transit nodes. It is it's > > position > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > role > > > is the level of topology it is provisioned for and it is the same > > > for all ODUs that comprise the topology. For, example a user may > > provision > > > a LO topology and constrain ODUs he sells to a set of clients to > use > > > the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of > virtual > > > topology the container is a part of and could be advertised as the > > > corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles > > > and muxing capabilities with the ISCD of RFC4202, could you > clarify? > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type =3D mux. capabilities code > > > > > > In addition, could you clarify my questions in another email > (copied > > as > > > follows): > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > which > > is > > > a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > OTU3 > > link > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > over > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > how > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > terminating nodes (i.e. on either side of corresponding link). What > > > happens on the ODU transit nodes and its place in the hierarchy on > > the > > > transit nodes are of no importance. My LO container can be carried > > > by somebody else's LO container and can carry my client's LO > container. > > To > > > some extent it is similar to MPLS LSP role: LSP always has a role > > (e.g. > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > path. > > > > > > Cheers, > > > Igor > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Fatai Zhang" ; > > > "Lou Berger" ; ; > > > > gmpls- > > > g709-framework@tools.ietf.org> > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types > > > introduced. But IMO they should indicate the link's mux > capabilities > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > with a separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; > 2. > > > Link may advertise several roles (e.g. HO and SHO) with different > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > be > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > required); 4. The combination of swicthcaps and encoding type will > > look > > > to CP as a separate layer, which is exactly how ITU models OTN > > > hierarchies in all aspects but routing (!?) 5. If the operator > would > > > want to constrain the routing of OTN connections to pre-configured > > > topology with a specific role (e.g. constrain all ODUs it sells to > > the > > > clients to one or more pre-configured LO topologies), this would be > > > possible to do in a technology independent way. Suppose an instance > > of > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > links will be no different from the separation of WDM links from > > OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as > the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > ago. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > to > > using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > latter > > > is for backward compatibility and should be ignored if OTN_LO, > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > granularity, then the corresponding G.709 Digital Path FA can be > withdrawn. > > > > > > The Encoding type would be the lower encoding at each end of the > LSP > > > regardless of what goes on in the middle since that determines what > > can > > > be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3D3 -------------- > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dfle= x > > > even though the ODUk=3D2 at the next hop could not directly contain > an ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels > > of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > ODU-flex, and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one > > yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other > than > > a > > > strong preference to rely on bytes/sec or on enumerated type > fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > or other intent. Could someone (either draft) concisely summarize > > > the multiplexing restrictions in one place, including restrictions > > > on number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > Behalf Of Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > document before we can embark on any proposals to the problem. > I > > am > > > > > still not clear why do we have to deviate from the general > > approach > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > IB>> plane, and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > > > of advertising of TE links, and there is no reason to invent an > > OTN > > > > > specific ISCD. The combination of Switching Capability and > > Encoding > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > if > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > >TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > > This is simply >blowing up the solution to a very simple > problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > > IB>> OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > other interested experts, and we think the proposal described > in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > control plane, no matter how you encode the routing > information. > > > For > > > > > TDM networks, you know the resource is allocated based on TS, > so > > > the > > > > > available TS should be get or induced before creating cross- > > > connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > information, > > I > > > > > think you need go to the routing drafts (info model and > > encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > you > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > container instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; > > > > > > draft-ietf-ccamp-gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > > > one of the main objectives of *C*CAMP. I look forward to > > hearing > > > > > > from the draft and discussion contributors on there progress > > > > > > on > > > this point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > > >> routing purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order > > > > > >> ODUj availability within a higher-order container. For > > > > > >> example, consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > >> then > > > we > > > > > >> establish an ODU2 service over the link. At this point in > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > >> services > > and > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > >> example > > > that > > > > > >> the number of time-slots available is different based on the > > > signal-type (i.e. ODU1 and ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > > >> the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > the > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > >> approach seems to be more in-line with the general approach > > > > > >> outlined in RFC-4202. Refer to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > >> benefit > > > is > > > > > >> that the advertisement is TS size independent and hence will > > > > > >> simplify the implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From sbardalai1@gmail.com Tue Jul 20 09:21:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCB83A68DF for ; Tue, 20 Jul 2010 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1M-a9MZOkXy for ; Tue, 20 Jul 2010 09:21:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 539D43A67F8 for ; Tue, 20 Jul 2010 09:21:39 -0700 (PDT) Received: by yxj4 with SMTP id 4so1668466yxj.31 for ; Tue, 20 Jul 2010 09:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=U1h+Zw+PYmYWTc+tRENMWk9VtkSsk1TwXZS5l/I/eCY=; b=SVonHQQijAO4EVUTv1c3dZ6trXcS3Mlq49u2XamCwxLiiwfcKSCTqQ9H5QxdsWHV98 h1hAm4pubXYMshy+AiOOsrTJPb4c60U0axO93R67cpcRQzJtcSzrPJUBsVQTgndgtPTu 0r/2CSgLn23kCOJslMV/AqBEGw2+psl20Fh28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O32GB21DsGRemC11O6CPBjI3nHXbczfWSzmNLuZR15b33viPEchXrgjHsrqIDwKVuc 59H29wEHYvdbNr3Hk+vBZ2egm3EC0hXjskRNipgw5WVlYoGKFrXkjSLmfk4aKVLs5Cna jbgn5RqyC8QE2s1XY2V1Z/642HZL9G1tXfjrU= MIME-Version: 1.0 Received: by 10.150.56.21 with SMTP id e21mr489417yba.141.1279642914474; Tue, 20 Jul 2010 09:21:54 -0700 (PDT) Received: by 10.231.118.28 with HTTP; Tue, 20 Jul 2010 09:21:53 -0700 (PDT) In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> <201007132223.o6DMNXRc018986@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com> <084e01cb23c0$61b58490$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com> <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> Date: Tue, 20 Jul 2010 09:21:53 -0700 Message-ID: From: Snigdho Bardalai To: Igor Bryskin Content-Type: multipart/alternative; boundary=000e0cd61a345b4b33048bd415f0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:23:06 -0000 --000e0cd61a345b4b33048bd415f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Igor, Would you not need percentage per priority per signal-type? Regards Snigdho On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin wro= te: > John, > > I totally agree with you. It is absolutely non OTN specific. However if a > TE link advertises more than one ISCD (with each ISCD containing only max > lsp bandwidth per priority), it is necessary to indicate how the total li= nk > unreserved bandwidth is partitioned between several ISCDs. What I am > suggesting is instead of advertising the unreserved bandwidth multiple ti= mes > (one per ISCD), indicate how the bandwidth is split between the ISCDs: e.= g > ISCD1 75%, ISCD2 25%. > > Igor. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 11:54 AM > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Igor, > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue o= f > partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs= is > actually a non-issue. > > Unreserved bandwidth by priority has always been advertised using the MPL= S > sub-TLV. My point has been that we have never had a requirement (includi= ng > SDH/SONET) in the past to advertise unreserved bandwidth by signal type, = so > what is special about OTN? > > A further point would be that if we do decide that it is necessary to > advertise unreserved bandwidth by signal type, it should be done in a > general way and not in an OTN specific manner. (And in fact, the argumen= ts > that unreserved bandwidth by signal type needs to be advertised, such as = the > latest e-mail from Curtis, are not OTN specific.) > > Thanks, > > John > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Igor Bryskin > > Sent: Tuesday, July 20, 2010 8:21 AM > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > It is a valid point, but the suggested solution is way too expensive. > > All you need is a way to say how the advertised unreserved bandwidth is > > partitioned between ISCDs in case the TE link advertisement contains > > several of them. One cheap way of doing so is to allocate 3-4 bits out > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > unreserved bandwidth associated with the ISCD. Another way is to use > > swicthcap specific extension. > > BTW: this is not an OTN specific issue, rather more general: any time > > when a TE link advertises more than one ISCD (which is perfectly Ok > > according to 4203) you'll have the same problem. > > > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 10:57 AM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > The need for unreserved resources advertised per signal type is the > > concurrent path computation. I'll answer quoting a section from the > > info-model draft, please have a look in particular to the example: > > > > > > " Unreserved resources need to be advertised per priority and per > > signal type in order to allow the correct functioning of the > > restoration process. [RFC4203] only allows advertising unreserved > > resources per priority, this leads not to know how many LSPs of a > > specific signal type can be restored. As example it is possible to > > consider the scenario depicted in the following figure. > > > > +------+ component link 1 +------+ > > | +------------------+ | > > | | component link 2 | | > > | N1 +------------------+ N2 | > > | | component link 3 | | > > | +------------------+ | > > +------+ +---+--+ > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > 32TSs available on the first one, 24TSs on the second, 24TSs on the > > third and supporting ODU2 and ODU3 signal types. The node would > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > single ODU3 can be set up and a crank-back would be originated. In > > more complex network scenarios the number of crank-backs can be much > > higher." > > > > In other words, advertising the number of availble resources per signal > > type does not avoid the possibility of cranck-back but decreases it as > > much as possible. For sure a good routing prevents from crank-backs > > caused by the restoration of LSP originating on the same Ingress. The > > cranck-backs due to the concurrent restoration of LSPs originating on > > different ingress nodes cannot be avoided. > > > > BR > > Daniele > > > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 16.16 > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > In line > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 4:32 AM > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, one more question. > > > > What about the unreserved bandwidth? > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > (muxCap & signal type) you also need to advertise the unreserved > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > > also implies extending the unreserved bandwidth TLV so to create a > > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > IB>> role per (muxCap & signal type) per priority level. However, total > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > IB>> see a compelling reason to the contrary (which I don't) > > > > Igor > > > > Thanks > > Daniele > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: luned=EC 19 luglio 2010 17.48 > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Understood... > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 8:46 AM > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > (i.e. to further classify the information) will be sufficient > > > > > > That's exactly what I've been > > > trying to say all along. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Monday, July 19, 2010 11:31 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor > > > > > > Please see inline. > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Daniele, > > > > > > > > Please, see in line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > role > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > type. > > > > > > > > IB>> in ISCD: > > > > switchCap =3D role; > > > > encodeType =3D muxCap & signal type; > > > > We also have 16 reserved bits which can use for OTN specific info > > in > > > > case we need it. > > > [SCB] I am yet to clearly understand what the role of "role" is, but > > > agree with your observation on the encode-type and the 16 > > > reserved-bits to further classify the switching information. > > > > > > > > In case (a) you're still missing a lot of information. For each > > role > > > > you would advertise just the unreserved bandwidth but you wouldn't > > > know > > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > > 15 > > > > Gbps available on 3 component links: you advertise 45 Gbps > > available > > > > but no ODU3 can be set up on such TE link). > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > issues > > > > and the requirement of being able to bundle component links > > together > > > > wouldn't be satisfied. > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > will > > > > provide a lot of flexibility: you can specify different things > > (e.g. > > > > available bandwidth) for the same link in different roles. > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > Cheers, > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > To: Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Fatai, > > > > > > > > Please, see my responses on-line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Fatai Zhang > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > Thanks. > > > > I understand what you said. Therefore, we have added some text to > > > > address the requirment in FWK document. However, we still don't > > > > think that we need to extend ISC to meet the requirment. The role > > of > > > > the > > > ODU > > > > can be get from the routing information implicitly. In the [draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" > > > is > > > > introduced. > > > > > > > > IB>> This is possible, however: > > > > a) this requires OTN specific advertising and processing rules; > > > > b) disallows topology separation in technology independent way > > > > > > > > A quick question on your statement: "the role of an ODU container > > > does > > > > not change hop-by-hop (as some people seem to believe). The role is > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > transit > > > > nodes. It is it's position in the hierarchy (but not role) that may > > > > change hop-by-hop. " > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > support > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > role > > > > of Ho ODU level is requested, according to your statement, this > > > > conneciton will be allowed to be created. However, it should not be > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > ends > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > TE > > > > links will > > > be > > > > disallowed, and the resulting path (if any) will not go through B11 > > > and > > > > B12. If one circumvents the path computation by providing the fully > > > > explicit path, the signaling should fail on node B for the same > > > reason: > > > > inconsistency of required (signaled) and supported (by local > > > > interfaces) switchcap. > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > type > > > > indicated in the Switching Type parameter is supported on the > > > > corresponding incoming interface. If the type cannot be > > supported, > > > > the node MUST generate a PathErr message with a "Routing > > > > problem/Switching Type" indication." > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: "Fatai Zhang" ; > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Lou Berger" ; > > > > ; > > > framework@tools.ietf.org> > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > Please, see my answers in line. > > > > > > > > -----Original Message----- > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > draft- > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor and all, > > > > > > > > Thanks for all your comments. > > > > > > > > I think role does not equal switching capability. The operators can > > > > define different roles depending on their policy and achieve the > > > > role through different methods. However, for OTN networks, the > > > > containers (e.g., ODUk) all have the same switching capablility > > > > (i.e., TDM > > > > switching) and I think we should reflect the natural > > characteristics > > > of > > > > links in the routing. In addition, if we extend the ISC, it will > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > encoding type). > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > > network as a stack of topologies. Whether a given topology is real > > > > or virtual is of no importance. > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > capability field (confusing name as it is) is a good way to > > describe > > > a > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > > topologies that could be easily separated in technology independent > > > way > > > > should path computation be constrained to particular one or > > > > sub-stack of them. > > > > I think a good way to identify an OTN (virtual) topology is via > > > > (infrastructure) ODU container role of ODUs comprising the > > topology. > > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > > some people seem to believe). The role is only meaningful on the > > ODU > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > position > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > role > > > > is the level of topology it is provisioned for and it is the same > > > > for all ODUs that comprise the topology. For, example a user may > > > provision > > > > a LO topology and constrain ODUs he sells to a set of clients to > > use > > > > the topology rather than any resources available on OTN network. > > > > The bottom line: container's role is the same as the role of > > virtual > > > > topology the container is a part of and could be advertised as the > > > > corresponding link switchcap. > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > and muxing capabilities with the ISCD of RFC4202, could you > > clarify? > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > encoding type =3D mux. capabilities code > > > > > > > > In addition, could you clarify my questions in another email > > (copied > > > as > > > > follows): > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > > which > > > is > > > > a mistake IMO. > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > OTU3 > > > link > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > over > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > > how > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > > terminating nodes (i.e. on either side of corresponding link). What > > > > happens on the ODU transit nodes and its place in the hierarchy on > > > the > > > > transit nodes are of no importance. My LO container can be carried > > > > by somebody else's LO container and can carry my client's LO > > container. > > > To > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > (e.g. > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > > path. > > > > > > > > Cheers, > > > > Igor > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > Thanks > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Fatai Zhang" ; > > > > "Lou Berger" ; ; > > > > > > gmpls- > > > > g709-framework@tools.ietf.org> > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Curtis, > > > > > > > > Thanks for your comment. > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > introduced. But IMO they should indicate the link's mux > > capabilities > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > 2. > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > > be > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > required); 4. The combination of swicthcaps and encoding type will > > > look > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > would > > > > want to constrain the routing of OTN connections to pre-configured > > > > topology with a specific role (e.g. constrain all ODUs it sells to > > > the > > > > clients to one or more pre-configured LO topologies), this would be > > > > possible to do in a technology independent way. Suppose an instance > > > of > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > > links will be no different from the separation of WDM links from > > > OTUs. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > To: Igor Bryskin > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > > ago. > > > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > > understand what the TS type meant did not try to multiplex its LO > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > to > > > using > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > latter > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > granularity, then the corresponding G.709 Digital Path FA can be > > withdrawn. > > > > > > > > The Encoding type would be the lower encoding at each end of the > > LSP > > > > regardless of what goes on in the middle since that determines what > > > can > > > > be wrapped inside it. > > > > > > > > For example: > > > > > > > > OTU3 > > > > OTU2 ODUk=3D3 -------------- > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= lex > > > > even though the ODUk=3D2 at the next hop could not directly contain > > an ODU0. > > > > If the SHO Encoding Type is used, then it indicates that two levels > > > of > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > clear > > > > how in an FA it can be indicated that either type is currently > > > > available (NE capable of both and hasn't committed to either one > > > yet). > > > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > > would indicate a huge controversy and I'm not getting it (other > > than > > > a > > > > strong preference to rely on bytes/sec or on enumerated type > > fields). > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > > if > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > > or other intent. Could someone (either draft) concisely summarize > > > > the multiplexing restrictions in one place, including restrictions > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > > Behalf Of Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > > document before we can embark on any proposals to the problem. > > I > > > am > > > > > > still not clear why do we have to deviate from the general > > > approach > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > > IB>> plane, and > > > > > > it is highly desirable to adhere to the layer independent > > > paradigm > > > > > > of advertising of TE links, and there is no reason to invent an > > > OTN > > > > > > specific ISCD. The combination of Switching Capability and > > > Encoding > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > if > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > >TE-link > > > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > create > > > > > > IB>> OTN > > > > > > hierarchies and constrain LO connections to HO containers, one > > > > needs > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > other interested experts, and we think the proposal described > > in > > > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > > control plane, no matter how you encode the routing > > information. > > > > For > > > > > > TDM networks, you know the resource is allocated based on TS, > > so > > > > the > > > > > > available TS should be get or induced before creating cross- > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > information, > > > I > > > > > > think you need go to the routing drafts (info model and > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > you > > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > > for > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > > > better > > > > > > > align the work with 4202. Use of common approaches is of > > > course > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > hearing > > > > > > > from the draft and discussion contributors on there progress > > > > > > > on > > > > this point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > section > > > > > > >> describes the link-parameters that are required for OTN > > > service > > > > > > >> routing purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > >> ODUj availability within a higher-order container. For > > > > > > >> example, consider an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > >> then > > > > we > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > >> services > > > and > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > >> example > > > > that > > > > > > >> the number of time-slots available is different based on the > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > >> How do we address this issue based on the approach specified > > > in > > > > > > >> the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the available > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > > the > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > >> approach seems to be more in-line with the general approach > > > > > > >> outlined in RFC-4202. Refer to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > > >> benefit > > > > is > > > > > > >> that the advertisement is TS size independent and hence will > > > > > > >> simplify the implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> CCAMP mailing list > > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > > CCAMP mailing list > > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --000e0cd61a345b4b33048bd415f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Igor,
=A0
Would you not need percentage per priority per signal-type?
=A0
Regards
Snigdho

On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin <IBryskin@ad= vaoptical.com> wrote:
John,

I totally agree wit= h you. It is absolutely non OTN specific. However if a TE link advertises m= ore than one ISCD (with each ISCD containing only max lsp bandwidth per pri= ority), it is necessary to indicate how the total link unreserved bandwidth= is partitioned between several ISCDs. What I am suggesting is instead of a= dvertising the unreserved bandwidth multiple times (one per ISCD), indicate= how the bandwidth is split between the ISCDs: e.g ISCD1 75%, ISCD2 25%.
Igor.

-----Original Message-----
From: John E Drake [mai= lto:jdrake@juniper.net]
Sent: Tuesday, July 20, 2010 11:54 AM
To: Igor Bryskin= ; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t

Igor,

Unreserved bandwidth is not advertised in the TDM ISC= TLV, so the issue of partitioning unreserved bandwidth across multiple adv= ertised TDM ISC TLVs is actually a non-issue.

Unreserved bandwidth by priority has always been advertised using the M= PLS sub-TLV. =A0My point has been that we have never had a requirement (inc= luding SDH/SONET) in the past to advertise unreserved bandwidth by signal t= ype, so what is special about OTN?

A further point would be that if we do decide that it is necessary to a= dvertise unreserved bandwidth by signal type, it should be done in a genera= l way and not in an OTN specific manner. =A0(And in fact, the arguments tha= t unreserved bandwidth by signal type needs to be advertised, such as the l= atest e-mail from Curtis, are not OTN specific.)

Thanks,

John

> -----Original Message-----
> From= : ccamp-bounces@ietf.org [mai= lto:ccamp-bounces@ietf.org] O= n Behalf
> Of Igor Bryskin
> Sent: Tuesday, July 20, 2010 8:21 AM
> T= o: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-=
> 01.txt
>
> It is a valid point, but the suggested solu= tion is way too expensive.
> All you need is a way to say how the adv= ertised unreserved bandwidth is
> partitioned between ISCDs in case the TE link advertisement contains> several of them. One cheap way of doing so is to allocate 3-4 bits o= ut
> of the ISCD sub-TLV reserved bits to indicate the fraction of to= tal
> unreserved bandwidth associated with the ISCD. Another way is to use> swicthcap specific extension.
> BTW: this is not an OTN specif= ic issue, rather more general: any time
> when a TE link advertises m= ore than one ISCD (which is perfectly Ok
> according to 4203) you'll have the same problem.
>
> I= gor
>
> -----Original Message-----
> From: Daniele Ceccar= elli [mailto:daniele.cec= carelli@ericsson.com]
> Sent: Tuesday, July 20, 2010 10:57 AM
> To: Igor Bryskin; Snigdh= o Bardalai; Fatai Zhang; curtis@occnc.c= om
> Cc: ccamp@ietf.org
> Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-=
> 01.txt
>
> Igor,
>
> The need for unreserv= ed resources advertised per signal type is the
> concurrent path comp= utation. I'll answer quoting a section from the
> info-model draft, please have a look in particular to the example:
= >
>
> =A0 =A0" Unreserved resources need to be advertis= ed per priority and per
> =A0 =A0signal type in order to allow the co= rrect functioning of the
> =A0 =A0restoration process. =A0[RFC4203] only allows advertising unres= erved
> =A0 =A0resources per priority, this leads not to know how man= y LSPs of a
> =A0 =A0specific signal type can be restored. =A0As exam= ple it is possible to
> =A0 =A0consider the scenario depicted in the following figure.
>=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +------+ component link 1 +---= ---+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0+------------= ------+ =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0| component link 2 | =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0N1 =A0+------------------+ = =A0N2 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0| compo= nent link 3 | =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 =A0+------------------+ =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---+--+
>
> =A0 =A0Suppose to have a TE link comprising 3 ODU3 component l= inks with
> =A0 =A032TSs available on the first one, 24TSs on the sec= ond, 24TSs on the
> =A0 =A0third and supporting ODU2 and ODU3 signal = types. =A0The node would
> =A0 =A0advertise a TE link unreserved bandwidth equal to 80 TSs and a = MAX
> =A0 =A0LSP bandwidth equal to 32 TSs. =A0In case of restoration= the network
> =A0 =A0could try to restore 2 ODU3 (64TSs) in such TE-= link while only a
> =A0 =A0single ODU3 can be set up and a crank-back would be originated.= =A0In
> =A0 =A0more complex network scenarios the number of crank-ba= cks can be much
> =A0 =A0higher."
>
> In other words= , advertising the number of availble resources per signal
> type does not avoid the possibility of cranck-back but decreases it as=
> much as possible. For sure a good routing prevents from crank-back= s
> caused by the restoration of LSP originating on the same Ingress.= The
> cranck-backs due to the concurrent restoration of LSPs originating on<= br>> different ingress nodes cannot be avoided.
>
> BR
&g= t; Daniele
>
>
> -----Original Message-----
> From:= Igor Bryskin [mailto:IBryskin@= advaoptical.com]
> Sent: marted=EC 20 luglio 2010 16.16
> To: Daniele Ceccarelli; S= nigdho Bardalai; Fatai Zhang; curtis@oc= cnc.com
> Cc: ccamp@ietf.org
> Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-=
> 01.txt
>
> In line
>
> -----Original Messa= ge-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: Tuesday, July 20, 2010 4:32 AM
> To: Snigdho Bardalai; Igo= r Bryskin; Fatai Zhang; curtis@occnc.co= m
> Cc: ccamp@ietf.org
&= gt; Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-<= br> > 01.txt
>
> Igor, one more question.
>
> What a= bout the unreserved bandwidth?
> If you're advertising the max ls= p bandwidth by 1 ISCD per role per
> (muxCap & signal type) you a= lso need to advertise the unreserved
> bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This=
> also implies extending the unreserved bandwidth TLV so to create a=
> corrispondence between the couples (ISCD-unreserved bandwidth subT= LV).
>
> IB>> Agree that max lsp bandwidth should be advertised b= y 1 ISCD per
> IB>> role per (muxCap & signal type) per pri= ority level. However, total
> IB>> unreserved bandwidth IMO is = OK to share between roles unless you
> IB>> see a compelling reason to the contrary (which I don't)=
>
> Igor
>
> Thanks
> Daniele
>
>= ; -----Original Message-----
> From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
> Sent: luned=EC 19 luglio 2010 17.48
> To: Igor Bryskin; Daniele = Ceccarelli; Fatai Zhang; curtis@occnc.c= om
> Cc: ccamp@ietf.org
= > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-=
> 01.txt
>
> Understood...
>
> Regards
> S= nigdho
>
> > -----Original Message-----
> > From: I= gor Bryskin [mailto:IBryskin@ad= vaoptical.com]
> > Sent: Monday, July 19, 2010 8:46 AM
> > To: Snigdho Bard= alai; Daniele Ceccarelli; Fatai Zhang;
> > curtis@occnc.com
> > Cc: ccamp@ietf.org
> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
&= gt; framework-
> > 01.txt
> >
> > [SCB] Are you = saying the ISCD as defined today with minor extensions
> > (i.e. t= o further classify the information) will be sufficient
> >
> > That's exactly what I've been
> > t= rying to say all along.
> >
> > Cheers,
> > Igor=
> >
> > -----Original Message-----
> > From: Sn= igdho Bardalai [mailto:SBardalai@= infinera.com]
> > Sent: Monday, July 19, 2010 11:31 AM
> > To: Igor Bryski= n; Daniele Ceccarelli; Fatai Zhang; cur= tis@occnc.com
> > Cc: ccamp@= ietf.org
> > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
&= gt; framework-
> > 01.txt
> >
> > Igor
> &= gt;
> > Please see inline.
> >
> > Regards
> > Snigdho
> >
> > > -----Original Message-----=
> > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> > > Sent: Monday= , July 19, 2010 7:43 AM
> > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com
> > > Cc: ccamp@ietf.org; Snigdho Bardalai
> > > Subje= ct: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > framework-
> > > 01.txt
> > >
> >= ; > Daniele,
> > >
> > > Please, see in line.> > >
> > > Cheers,
> > > Igor
> &g= t; >
> > > -----Original Message-----
> > > From: Daniele C= eccarelli [mailto:daniel= e.ceccarelli@ericsson.com]
> > > Sent: Monday, July 19, 201= 0 10:31 AM
> > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com
> > > Cc: ccamp@ietf.org; Snigdho Bardalai
> > > Subject: RE= : [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > framework-
> > > 01.txt
> > >
> >= ; > Hi Igor,
> > >
> > > I didn't understand= if you're proposing to (a) send an ISCD per
> role
> > = > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal
> type.
> > >
> > > IB>> in ISCD:
> = > > switchCap =3D role;
> > > encodeType =3D muxCap &= signal type;
> > > We also have 16 reserved bits which can use= for OTN specific info
> in
> > > case we need it.
> > [SCB] I am yet to c= learly understand what the role of "role" is, but
> > ag= ree with your observation on the encode-type and the 16
> > reserv= ed-bits to further classify the switching information.
> > >
> > > In case (a) you're still missing a lot= of information. For each
> role
> > > you would advertis= e just the unreserved bandwidth but you wouldn't
> > know
> > > if such bandwidth is available for a certain type of ODUj LS= P (e.g.
> > 15
> > > Gbps available on 3 component lin= ks: you advertise 45 Gbps
> available
> > > but no ODU3 c= an be set up on such TE link).
> > >
> > > In case (b) the number of ISCDs would caus= e serious scalability
> > issues
> > > and the require= ment of being able to bundle component links
> together
> > = > wouldn't be satisfied.
> > >
> > > IB>> Disagree. ISCD is a relatively = small subTLV, several ISDCs
> will
> > > provide a lot of= flexibility: you can specify different things
> (e.g.
> > &= gt; available bandwidth) for the same link in different roles.
> > [SCB] Are you saying the ISCD as defined today with minor extensi= ons
> > (i.e. to further classify the information) will be suffici= ent?
> > >
> > > Cheers,
> > > Daniele<= br> > > >
> > > -----Original Message-----
> > &g= t; From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On
> > Behalf
> > > Of Igor Bryskin
> > > Sent: = luned=EC 19 luglio 2010 15.40
> > > To: Fatai Zhang; curtis@occnc.com
> > > Cc: ccamp@ietf.org; Snigdho Bardalai
> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-=
> > framework-
> > > 01.txt
> > >
>= > > Fatai,
> > >
> > > Please, see my respon= ses on-line.
> > >
> > > Cheers,
> > > Igor
> >= ; >
> > > -----Original Message-----
> > > From:= ccamp-bounces@ietf.org [mail= to:ccamp-bounces@ietf.org] On=
> > Behalf
> > > Of Fatai Zhang
> > > Sent: S= unday, July 18, 2010 10:49 PM
> > > To: Igor Bryskin; curtis@occnc.com
> > > Cc: ccamp@ietf.org; Snigdho Bardalai
> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-=
> > framework-
> > > 01.txt
> > >
>= > > Hi Igor,
> > >
> > > Thanks.
> >= ; > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still do= n't
> > > think that we need to extend ISC to meet the requ= irment. The role
> of
> > > the
> > ODU
> = > > can be get from the routing information implicitly. In the [draft= -
> > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of =A0&qu= ot;Full
> Lambda"
> > is
> > > introduced.<= br>> > >
> > > IB>> This is possible, however: > > > a) this requires OTN specific advertising and processing rul= es;
> > > b) disallows topology separation in technology indepe= ndent way
> > >
> > > A quick question on your stat= ement: "the role of an ODU container
> > does
> > > not change hop-by-hop (as some people seem= to believe). The role is
> > > only meaningful on the ODU term= inating nodes and irrelevant on
> > transit
> > > node= s. It is it's position in the hierarchy (but not role) that may
> > > change hop-by-hop. "
> > >
> > >= ; For example, A(AI1)----(BI1)B(BI2)----(CI1)C, =A0Interfaces AI1 and
&g= t; > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can = only
> > support
> > > Lo ODU2 (the role is Lo OTN Level). If = a connection ODU2 with the
> > role
> > > of Ho ODU le= vel is requested, =A0according to your statement, this
> > > co= nneciton will be allowed to be created. However, it should not be
> > > allowed because the ISC is not consistent along the LSP.
= > > >
> > > IB>> No, your understanding is not c= orrect. A11 and C11 TE link
> ends
> > > will be advertis= ed with two ISCDs: OTN_HO_SC and OIN_LO_SC, while
> > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the pat= h
> > > computation is constrained to the OTN_HO_SC topology, B= 11 and B12
> TE
> > > links will
> > be
> = > > disallowed, and the resulting path (if any) will not go through B= 11
> > and
> > > B12. If one circumvents the path computatio= n by providing the fully
> > > explicit path, the signaling sho= uld fail on node B for the same
> > reason:
> > > inco= nsistency of required (signaled) and supported (by local
> > > interfaces) switchcap.
> > >
> > > P= lease see the text from RFC3473: =A0 "Nodes MUST verify that the
&g= t; type
> > > indicated in the Switching Type =A0parameter is s= upported on the
> > > corresponding incoming interface. =A0If =A0the type cannot b= e
> supported,
> > > the node MUST generate a PathErr mes= sage with a "Routing
> > > problem/Switching Type" in= dication."
> > > IB>> Indeed
> > >
> > >
>= ; > >
> > >
> > > Best Regards
> > &= gt;
> > > Fatai
> > >
> > > ----- Origi= nal Message -----
> > > From: "Igor Bryskin" <IBryskin@advaoptical.com>
> > > To: &= quot;Fatai Zhang" <zhangfa= tai@huawei.com>; <curtis@occn= c.com>
> > > Cc: "John E Drake" <jdrake@juniper.net>; "Snigdho Bardalai"
>= > > <SBardalai@infinera= .com>; "Lou Berger" <lberger@labn.net>;
> > > <ccamp@ietf.org>= ; <draft-ietf-ccamp-gmpls-g709-
> > > framework@tools.ietf.org>
> > > Se= nt: Friday, July 16, 2010 12:34 AM
> > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-=
> > framework-
> > > 01.txt
> > >
>= > >
> > > Fatai,
> > > Please, see my answer= s in line.
> > >
> > > -----Original Message-----
> > &g= t; From: Fatai Zhang [mailto:zhang= fatai@huawei.com]
> > > Sent: Wednesday, July 14, 2010 9:52= PM
> > > To: Igor Bryskin; curtis= @occnc.com
> > > Cc: John E Drake; Snigdho Bardalai; Lou Be= rger; ccamp@ietf.org;
> > dr= aft-
> > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org
> > > = Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > f= ramework-
> > > 01.txt
> > >
> > > Hi Igor and all,<= br>> > >
> > > Thanks for all your comments.
> &= gt; >
> > > I think role does not equal switching capability= . The operators can
> > > define different roles depending on their policy and achieve= the
> > > role through different methods. However, for OTN net= works, the
> > > containers (e.g., ODUk) all have the same swit= ching capablility
> > > (i.e., TDM
> > > switching) and I think we shoul= d reflect the natural
> characteristics
> > of
> > = > links in the routing. In addition, if we extend the ISC, it will
> > > make the encoding type lose its' own meaning(ie., ISC ov= errides
> > > encoding type).
> > >
> > &g= t; IB>> When a GMPLS CP instance controls several layers, it views th= e
> > > network as a stack of topologies. Whether a given topology i= s real
> > > or virtual is of no importance.
> > > = The GMPLS ISCD link sub-tlv and, in particular, its switching
> > = > capability field (confusing name as it is) is a good way to
> describe
> > a
> > > layer in technology independ= ent way, so that, say, MPLS-TP->OTN_LO-
> > > >OTN_HO->= ;OTN_SHO->WDM layer stack could be perceived as a stack of
> > = > topologies that could be easily separated in technology independent > > way
> > > should path computation be constrained to p= articular one or
> > > sub-stack of them.
> > > I t= hink a good way to identify an OTN (virtual) topology is via
> > &= gt; (infrastructure) ODU container role of ODUs comprising the
> topology.
> > > BTW IMO the role of an ODU container does = not change hop-by-hop (as
> > > some people seem to believe). T= he role is only meaningful on the
> ODU
> > > terminating= nodes and irrelevant on transit nodes. It is it's
> > position
> > > in the hierarchy (but not role) that m= ay change hop-by-hop. ODU's
> > role
> > > is the = level of topology it is provisioned for and it is the same
> > >= ; for all ODUs that comprise the topology. For, example a user may
> > provision
> > > a LO topology and constrain ODUs he s= ells to a set of clients to
> use
> > > the topology rath= er than any resources available on OTN network.
> > > The botto= m line: container's role is the same as the role of
> virtual
> > > topology the container is a part of and coul= d be advertised as the
> > > corresponding link switchcap.
&= gt; > >
> > > According to the point 3, I don't know = how to advertise the roles
> > > and muxing capabilities with the ISCD of RFC4202, could you<= br>> clarify?
> > >
> > > IB>> switchcap = =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.)
> > > =A0 =A0 = =A0encoding type =3D mux. capabilities code
> > >
> > > In addition, could you clarify my question= s in another email
> (copied
> > as
> > > follow= s):
> > >
> >
> =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > For =A0Lo O= DU, Ho ODU, SHO ODU, they are relative to each other.
> > > IB&= gt;> I disagree. You define role =3D=3D position in the hierarchy,
> which
> > is
> > > a mistake IMO.
> > &g= t;
> > > For example, ODU1->ODU2->ODU3->ODU4, how to r= egard ODU2 or ODU3 as
> > > Ho OTN Level or Lo OTN Level? Anoth= er example is, if there is a
> OTU3
> > link
> > > supporting ODU2 switching, wh= ich can be used as Lo ODU2 (service
> > > over
> > >= ; ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case,
> > how
> > > to differentiate if this ODU2 is Lo OTN Lev= el or Ho OTN Level?
> > >
> > > IB>> As I men= tioned earlier, ODU role is only important on the ODU
> > > ter= minating nodes (i.e. on either side of corresponding link). What
> > > happens on the ODU transit nodes and its place in the hierar= chy on
> > the
> > > transit nodes are of no importanc= e. My LO container can be carried
> > > by somebody else's = LO container and can carry my client's LO
> container.
> > To
> > > some extent it is similar= to MPLS LSP role: LSP always has a role
> > (e.g.
> > &g= t; PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its
> > > path.
> > >
> > > Cheers,
> &g= t; > Igor
> > >
> > >
> >
> =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > =3D<= br> > > > =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
> > >
> > >
> > &= gt;
> > > Thanks
> > >
> > > Fatai
&= gt; > >
> > > ----- Original Message -----
> > > From: "Igor Bryskin" <IBryskin@advaoptical.com>
> > > To: &= lt;curtis@occnc.com>
> >= ; > Cc: "John E Drake" <jdrake@juniper.net>; "Snigdho Bardalai"
> > > <SBardalai@infi= nera.com>; "Fatai Zhang" <zhangfatai@huawei.com>;
> > > "Lou Berg= er" <lberger@labn.net>; = <ccamp@ietf.org>;
> > > <draft-ietf-ccamp-
> > gmpls-
> > > = g709-framework@tools.ietf.= org>
> > > Sent: Wednesday, July 14, 2010 10:36 PM
> > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-=
> > framework-
> > > 01.txt
> > >
>= > >
> > > Curtis,
> > >
> > > Th= anks for your comment.
> > >
> > > I agree that there should be multiple OTN = specific encoding types
> > > introduced. But IMO they should i= ndicate the link's mux
> capabilities
> > > rather th= an the link's role (i.e. level in the OTN hierarchy: LO,
> > > HO, SHO, etc.). The link's role or roles IMO should be i= ndicated
> > > with a separate switchcaps. I can give you sever= al reasons:
> > >
> > > 1. Links with the same mux = capabilities may have different roles;
> 2.
> > > Link may advertise several roles (e.g. HO and SHO= ) with different
> > > mux.capabilities per role; 3. Link's= role and mux. capabilities can
> > be
> > > advertise= d with ISCDs as defined in RFC4202 (no OTN-style ISCD is
> > > required); 4. The combination of swicthcaps and encoding typ= e will
> > look
> > > to CP as a separate layer, which= is exactly how ITU models OTN
> > > hierarchies in all aspects= but routing (!?) 5. If the operator
> would
> > > want to constrain the routing of OTN connectio= ns to pre-configured
> > > topology with a specific role (e.g. = constrain all ODUs it sells to
> > the
> > > clients t= o one or more pre-configured LO topologies), this would be
> > > possible to do in a technology independent way. Suppose an i= nstance
> > of
> > > GMPLS CP manages WDM and OTN NEs.= Then separation of LO from HO OTN
> > > links will be no diffe= rent from the separation of WDM links from
> > OTUs.
> > >
> > > Cheers,
> > &g= t; Igor
> > >
> > > -----Original Message-----
&= gt; > > From: curtis@occnc.com [mailto:curtis@occnc.com]
> > > Sent: Tuesday, July 13, 2010 6:24 PM
> > > To: I= gor Bryskin
> > > Cc: John E Drake; Snigdho Bardalai; Fatai Zha= ng; Lou Berger;
> > > ccamp@i= etf.org; draft-ietf-ccamp-gmpls-g709-
> framework@tools.ietf.org
> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls= -g709-
> > framework-
> > > 01.txt
> > > > > >
> > > In message <052C67B4ED558D41BBDEA7CA9FC= 6DCDC53C0D1E1FE@atl-srv-
> > > exgen.atl.advaoptical.com>
> &= gt; > Igor Bryskin writes:
> > > >
> > > > I think OTN links require more t= han one switchcaps: as many as
> the
> > > depth of the d= eepest possible OTN DP hierarchy, for example:
> > > >
> > > > typedef enum
> > > > {
> > >= > =A0 =A0LSPSwitchType_Unknown =3D0 =A0 =A0 =A0 =A0 =A0 =A0/* Unknown *= /
> > > > =A0 =A0, LSPSwitchType_PSC_1 =3D1 =A0 =A0 =A0 =A0 = =A0 =A0/* PSC-1 */
> > > > =A0 =A0, LSPSwitchType_PSC_2 =3D2= =A0 =A0 =A0 =A0 =A0 =A0/* PSC-2 */
> > > > =A0 =A0, LSPSwitchType_PSC_3 =3D3 =A0 =A0 =A0 =A0 =A0 = =A0/* PSC-3 */
> > > > =A0 =A0, LSPSwitchType_PSC_4 =3D4 =A0= =A0 =A0 =A0 =A0 =A0/* PSC-4 */
> > > > =A0 =A0, LSPSwitchTy= pe_L2SC =A0=3D50 =A0 =A0 =A0 =A0 =A0 /* L2SC */
> > > > =A0 =A0, LSPSwitchType_TDM =A0 =3D100 =A0 =A0 =A0 =A0 = =A0/* TDM */
> > > >
> > > > /*****/
> = > > > =A0 =A0, LSPSwitchType_OTN_LO=3D124 =A0 /* OTN low order */<= br>> > > > =A0 =A0, LSPSwitchType_OTN_HO=3D125 =A0 /* OTN high = order */
> > > > =A0 =A0, LSPSwitchType_OTN_SHO=3D126 =A0/* OTN super hi= gh order */
> /*****/
> > > > =A0 =A0, LSPSwitchType_L= SC =A0 =3D150 =A0 =A0 =A0 =A0 =A0/* LSC */
> > > > =A0 =A0, = LSPSwitchType_FSC =A0 =3D200 =A0 =A0 =A0 =A0 =A0/* FSC */
> > > > }e_LSPSwitchType;
> > >
> > >> > > It would be better IMHO to keep the Switch Type as TDM and= make the
> > > Encoding Type OTN_LO, OTN_HO or OTN_SHO.
> > >
> > > This would replace the 20006 OTN Encoding = Type for G.709 Digital
> > > Path layer and G.709 Optical Chann= el layer for 2009 OTN, which had
> > > in turn replaced the Enc= oding Type of "Digital Wrapper" a long time
> ago.
> > >
> > > Replacing the Encoding Type w= ould insure that any LSR that did not
> > > understand what the= TS type meant did not try to multiplex its LO
> > > ODU at TS = granularity 2.5 onto a HO ODU that had alraedy commited
> to
> > using
> > > a 1.25 TS granularity for anot= her LO ODU.
> > >
> > > It could also be stated tha= t if an LSR advertises OTN_LO, OTN_HO or
> > > OTN_SHO FA, and = also advertises G.709 Digital Path FA, then the
> > latter
> > > is for backward compatibility and should= be ignored if OTN_LO,
> > > OTN_HO or OTN_SHO is understood. = =A0If the LSR commits to 1.25 TS
> > > granularity, then the co= rresponding G.709 Digital Path FA can be
> withdrawn.
> > >
> > > The Encoding type would= be the lower encoding at each end of the
> LSP
> > > reg= ardless of what goes on in the middle since that determines what
> &g= t; can
> > > be wrapped inside it.
> > >
> > > Fo= r example:
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 OTU3
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 OTU2= =A0 =A0 =A0ODUk=3D3 --------------
> > > =A0 =A0OTU1 =A0 =A0 = =A0 ODUk=3D2 -- ODUj=3D2
> > > =A0 =A0ODUk=3D1 --- ODUj=3D1 --
> > >
> &g= t; > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= lex
> > > even though the ODUk=3D2 at the next hop could not di= rectly contain
> an ODU0.
> > > If the SHO Encoding Type is used, then it i= ndicates that two levels
> > of
> > > multiplexing cou= ld be supported at that switch/LSR.
> > >
> > > The= nominal bytes/sec rates can still be provided. =A0RFC 4328 Switch
> > > Types currently don't include an ODUj or ODUk distinctio= n but if
> > > Encoding Type indicated LO or HO, that may not b= e needed. =A0Along
> > > with the new Encoding Type new Signal = Types for ODU0, ODU4, and
> > > ODU-flex, and ODU2e, can be added.
> > >
>= > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm= not
> > clear
> > > how in an FA it can be indicated = that either type is currently
> > > available (NE capable of both and hasn't committed to ei= ther one
> > yet).
> > >
> > > BTW- Maybe = I'm missing something but the number of messages on this
> > &= gt; would indicate a huge controversy and I'm not getting it (other
> than
> > a
> > > strong preference to rely on byt= es/sec or on enumerated type
> fields).
> > >
> >= ; > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. =A0I'm not= sure
> > if
> > > the intent is to merge with draft-ietf-ccamp= -gmpls-g709-framework,
> > > or other intent. =A0Could someone = (either draft) concisely summarize
> > > the multiplexing restr= ictions in one place, including restrictions
> > > on number of multiplexing layers at one LSR. =A0That might h= elp.
> > >
> > > Curtis
> > >
> &= gt; >
> > > > -----Original Message-----
> > >= ; > From: John E Drake [mailto:jdr= ake@juniper.net]
> > > > Sent: Thursday, July 08, 2010 1:59 PM
> > >= > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger
> &= gt; > > Cc: ccamp@ietf.org;
> > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org> > > > Subject: RE: [CCAMP] Comment on
> > > >= ; draft-ietf-ccamp-gmpls-g709-framework-01.txt
> > > >
> > > > What do you mean by "differ= ent switchcaps"?
> > > >
> > > > > --= ---Original Message-----
> > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> > > > > Behalf Of Igor Bryskin
> > > > >= Sent: Thursday, July 08, 2010 10:53 AM
> > > > > To: Sni= gdho Bardalai; Fatai Zhang; Lou Berger
> > > > > Cc: ccamp@ietf.org;
> > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org<= /a>
> > > > > Subject: Re: [CCAMP] Comment on
> >= ; > > > draft-ietf-ccamp-gmpls-g709-framework-
> > > > > 01.txt
> > > > >
> > &g= t; > > Snigdho,
> > > > >
> > > > &g= t;
> > > > >
> > > > >
> > >= ; > >
> > > > > =D8 =A0I think we need to sort out the issues with= the framework
> > > > > document before we can embark on= any proposals to the problem.
> I
> > am
> > > = > > still not clear why do we have to deviate from the general
> > approach
> > > > > that has been established in= RFC 4202.
> > > > >
> > > > >
> = > > > >
> > > > > IB>> Agree absolutely= . GMPLS is inherently multi-layer control
> > > > > IB>> plane, and
> > > > > = it is highly desirable to adhere to the layer independent
> > para= digm
> > > > > of advertising of TE links, and there is n= o reason to invent an
> > OTN
> > > > > specific ISCD. The combination of= Switching Capability and
> > Encoding
> > > > >= type of RFC4202 ISCD allows for specifying both multiplexing
> > = > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and= ,
> if
> > > > > this not sufficient, you have another r= eserved 16 bits.
> > > > >
> > > > >> > > > >
> > > > > >Additionally, I d= o not see any reason to advertise a new
> > > > > >TE-link
> > > to
> > >= > > represent >the low-order ODUj bandwidth within the high-order=
> > > containers.
> > > > > This is simply &= gt;blowing up the solution to a very simple
> problem.
> > > > >
> > > > >
&g= t; > > > >
> > > > > IB>> Here I disagr= ee. In order to give a user possibility to
> > create
> >= > > > IB>> OTN
> > > > > hierarchies and constrain LO connections to HO con= tainers, one
> > > needs
> > > > > to adverti= se OTN links with different switchcaps.
> > > > >
> > > > >
> > > > >
> > > >= > Cheers,
> > > > >
> > > > > Igor<= br>> > > > >
> > > > >
> > > &= gt; >
> > > > > Regards
> > > > >
> > &= gt; > > Snigdho
> > > > >
> > > > &g= t;
> > > > >
> > > > > From: Fatai Zhan= g [mailto:zhangfatai@huawei.com]
> > > > > Sent: Wednesday, July 07, 2010 6:33 PM
> >= ; > > > To: Snigdho Bardalai; Lou Berger
> > > > &g= t; Cc: ccamp@ietf.org;
> > &= gt; > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org
> > > > > Subject: Re: [CCAMP] Comment on
> > > = > > draft-ietf-ccamp-gmpls-g709-framework-
> > > > >= ; 01.txt
> > > > >
> > > > >
> &g= t; > > >
> > > > > Hi Snigdho and Lou,
> > > > >> > > > >
> > > > >
> > > >= ; > Yes, we have lots of off-line discussions among authors and
> = > > > > other interested experts, and we think the proposal des= cribed
> in
> > "draft-
> > > > > ceccarelli-cc= amp-gmpls-ospf-g709" [OSPF-Encoding] draft is more
> > > &= gt; > feasible for OTN networks.
> > > > >
> >= ; > > >
> > > > >
> > > > > The framework draft ju= st tells you what information needed for
> > > > > contro= l plane, no matter how you encode the routing
> information.
> = > > For
> > > > > TDM networks, you know the resource is allocated b= ased on TS,
> so
> > > the
> > > > > av= ailable TS should be get or induced before creating cross-
> > >= ; connect.
> > > > >
> > > > >
> > > >= >
> > > > > If you are trying to find how to encode t= he routing
> information,
> > I
> > > > > = think you need go to the routing drafts (info model and
> > encoding).
> > > > >
> > > > >= ;
> > > > >
> > > > > If you look at th= e routing drafts (info model and encoding),
> you
> > > &= gt; > will find that one of your suggestions is adopted (i.e., simply > > > > > advertize the available number of ODU0, ODU1, ODU2= , ..., ODU4
> > > container instances).
> > > > = >
> > > > >
> > > > >
> > &= gt; > > One more thing for your first comment:
> > > > >
> > > > > If you create an ODU2 = LSP (usually over multi OTU3 links) as FA
> > for
> > >= ; > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > component link of an existing TE link (like RFC420= 6bis).
> > > > >
> > > > >
> >= > > >
> > > > >
> > > > >
> > > > >
> > > > > Best Regards
> &= gt; > > >
> > > > > Fatai
> > > >= >
> > > > >
> > > > > ----- Origina= l Message -----
> > > > >
> > > > > From: "Snigdho Ba= rdalai" <SBardalai@infine= ra.com
> > > > > <mailto:SBardalai@infinera.com> >
> > > > >
> > > > > To: "Lou Berger&q= uot; <lberger@labn.net <mailt= o:lberger@labn.net> >
>= > > > >
> > > > > Cc: <ccamp@ie= tf.org <mailto:ccamp@ietf.org&= gt; >;
> > > > > <draft-ietf-ccamp-gmpls- g709-framework@tools.ietf.org=
> > > > > <mailto:draft-ietf-ccamp-gmpls-g709-
> > > > > framework@tools.ietf.org> >= ;
> > > > >
> > > > > Sent: Wednesday, July = 07, 2010 11:43 PM
> > > > >
> > > > > S= ubject: Re: [CCAMP] Comment on
> > > > > draft-ietf-ccamp= -gmpls-g709-framework-
> > > > > 01.txt
> > > > >
> > &g= t; > >
> > > > >
> > > > > > H= i Lou
> > > > > >
> > > > > > Tha= nks, I also would like to hear about the same.
> > > > > >
> > > > > > Snigdho
&= gt; > > > > >
> > > > > > -----Original= Message-----
> > > > > > From: Lou Berger [mailto:lberger@labn.net]
> > > > > > Sent: Wednesday, July 07, 2010 8:37 AM
>= ; > > > > > To: Snigdho Bardalai
> > > > >= > Cc: ccamp@ietf.org <mailto:<= a href=3D"mailto:ccamp@ietf.org">ccamp@ietf.org> ;
> > > > > > draft-ietf-ccamp-gmpls-
> > > >= ; > g709-framework@tool= s.ietf.org <mailto:draft-= ietf-ccamp-gmpls-
> > g709-
> > > > > framework@tools.ietf.org>
> > > > > &= gt; Subject: Re: [CCAMP] Comment on
> > > > > > draft-= ietf-ccamp-gmpls-g709-framework-
> > > > > 01.txt
> > > > > >
> &g= t; > > > > Snigdho,
> > > > > > I believe = there has been some off-line discussion on how to
> > > better<= br> > > > > > > align the work with 4202. =A0Use of common ap= proaches is of
> > course
> > > > > > one of = the main objectives of *C*CAMP. =A0I look forward to
> > hearing > > > > > > from the draft and discussion contributors on= there progress
> > > > > > on
> > > this = point.
> > > > > >
> > > > > > Lo= u
> > > > > >
> > > > > > On 7/6/2010 = 3:59 PM, Snigdho Bardalai wrote:
> > > > > >> Hello= ,
> > > > > >>
> > > > > >>= I have a comment and a question on Section 3.1.2.1. This
> > section
> > > > > >> describes the link-p= arameters that are required for OTN
> > service
> > > = > > >> routing purposes.
> > > > > >> > > > > > >> My comment is how are we going to adverti= se the low-order
> > > > > >> ODUj availability wit= hin a higher-order container. For
> > > > > >> exam= ple, consider an
> > > > > >> OTU3 link which has 16 time-slots of 2.5G= granularity and
> > > > > >> then
> > >= ; we
> > > > > >> establish an ODU2 service over th= e link. At this point in
> > > > > >> time the OTU3 link has 12 time-slots avai= lable for ODU2
> > > > > >> services
> > a= nd
> > > > > >> up to 12+4 time-slots available for= ODU1 services (4 ODU1s
> > > > > >> are contained over the ODU2). So it is ob= vious from this
> > > > > >> example
> > &= gt; that
> > > > > >> the number of time-slots avai= lable is different based on the
> > > signal-type (i.e. ODU1 and ODU2).
> > > > >= ; >> How do we address this issue based on the approach specified
= > > in
> > > > > >> the
> > > >= ; > draft?
> > > > > >>
> > > > > >> My o= ther question is why not simply advertize the available
> > > &= gt; > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances= or
> > the
> > > > > >> equivalent bandwidth in = bytes/sec within a link? This
> > > > > >> approach= seems to be more in-line with the general approach
> > > > = > >> outlined in RFC-4202. Refer to
> > > > > section
> > > > > >> 3.4 i= n RFC 4202 for an example that shows multiple ISCDs
> > > > = > >> being advertised per VC rate for an SDH link. The additional<= br> > > > > > >> benefit
> > > is
> >= > > > >> that the advertisement is TS size independent and = hence will
> > > > > >> simplify the implementation= .
> > > > > >>
> > > > > >> Rega= rds
> > > > > >>
> > > > > >&g= t; Snigdho
> > > > > >>
> > > > >= >>
> > > > > >>
> > > > > >> ____= ___________________________________________
> > > > > >= ;> CCAMP mailing list
> > > > > >> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
> > > > > >> https://www.ietf.org/mailman/listinfo/ccam= p
> > > > > <https://www.ietf.org/mailman/listinfo/= ccamp>
> > > > > > _____________________________________________= __
> > > > > > CCAMP mailing list
> > > &g= t; > > CCAMP@ietf.org <mailt= o:CCAMP@ietf.org>
> > > > > > https://www.ietf.org/mailman/listinfo/ccamp
> > > > > <https://www.ietf.org/mailman/listinfo/ccam= p>
> > > > > >
> > > >
> > > >= _______________________________________________
> > > > CCA= MP mailing list
> > > > CC= AMP@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ccamp
> = > > >
> > > >
> > > ___________________= ____________________________
> > > CCAMP mailing list
> > > CCAMP@ietf.org
> > > https://www.ietf.org/mailman= /listinfo/ccamp
> > > _______________________________________________
> >= > CCAMP mailing list
> > > CCAMP@ietf.org
> > > https://www.ietf.org/mailman/listinfo= /ccamp
> _______________________________________________
> CCAMP mailing = list
> CCAMP@ietf.org
> <= a href=3D"https://www.ietf.org/mailman/listinfo/ccamp" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ccamp

--000e0cd61a345b4b33048bd415f0-- From jdrake@juniper.net Tue Jul 20 09:57:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4803A6C19 for ; Tue, 20 Jul 2010 09:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2PNwQiW3FyE for ; Tue, 20 Jul 2010 09:57:16 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id B833C3A6934 for ; Tue, 20 Jul 2010 09:57:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXVcd/MLQEm+7RiC/MjMJhuRlzV4sWP@postini.com; Tue, 20 Jul 2010 09:57:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 20 Jul 2010 09:56:31 -0700 From: John E Drake To: Igor Bryskin , Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 09:56:29 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAADrhiAAAUKmgAABzojg Message-ID: <5E893DB832F57341992548CDBB333163984487C383@EMBX01-HQ.jnpr.net> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:57:19 -0000 Igor, You seem to have missed the first point in my email, regarding what is actu= ally advertised. Wrt your proposed solution, it won't work because there is no constraint re= quiring different ISC TLVs to use a common bandwidth pool. Further, if the= y did share a common bandwidth pool, then at any point in time the unreserv= ed bandwidth is available to all of them. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 9:16 AM > To: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > I totally agree with you. It is absolutely non OTN specific. However if > a TE link advertises more than one ISCD (with each ISCD containing only > max lsp bandwidth per priority), it is necessary to indicate how the > total link unreserved bandwidth is partitioned between several ISCDs. > What I am suggesting is instead of advertising the unreserved bandwidth > multiple times (one per ISCD), indicate how the bandwidth is split > between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > Igor. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 11:54 AM > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue > of partitioning unreserved bandwidth across multiple advertised TDM ISC > TLVs is actually a non-issue. > > Unreserved bandwidth by priority has always been advertised using the > MPLS sub-TLV. My point has been that we have never had a requirement > (including SDH/SONET) in the past to advertise unreserved bandwidth by > signal type, so what is special about OTN? > > A further point would be that if we do decide that it is necessary to > advertise unreserved bandwidth by signal type, it should be done in a > general way and not in an OTN specific manner. (And in fact, the > arguments that unreserved bandwidth by signal type needs to be > advertised, such as the latest e-mail from Curtis, are not OTN > specific.) > > Thanks, > > John > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: Tuesday, July 20, 2010 8:21 AM > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > It is a valid point, but the suggested solution is way too expensive. > > All you need is a way to say how the advertised unreserved bandwidth > is > > partitioned between ISCDs in case the TE link advertisement contains > > several of them. One cheap way of doing so is to allocate 3-4 bits > out > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > unreserved bandwidth associated with the ISCD. Another way is to use > > swicthcap specific extension. > > BTW: this is not an OTN specific issue, rather more general: any time > > when a TE link advertises more than one ISCD (which is perfectly Ok > > according to 4203) you'll have the same problem. > > > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 10:57 AM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > The need for unreserved resources advertised per signal type is the > > concurrent path computation. I'll answer quoting a section from the > > info-model draft, please have a look in particular to the example: > > > > > > " Unreserved resources need to be advertised per priority and per > > signal type in order to allow the correct functioning of the > > restoration process. [RFC4203] only allows advertising unreserved > > resources per priority, this leads not to know how many LSPs of a > > specific signal type can be restored. As example it is possible > to > > consider the scenario depicted in the following figure. > > > > +------+ component link 1 +------+ > > | +------------------+ | > > | | component link 2 | | > > | N1 +------------------+ N2 | > > | | component link 3 | | > > | +------------------+ | > > +------+ +---+--+ > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > 32TSs available on the first one, 24TSs on the second, 24TSs on > the > > third and supporting ODU2 and ODU3 signal types. The node would > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > single ODU3 can be set up and a crank-back would be originated. > In > > more complex network scenarios the number of crank-backs can be > much > > higher." > > > > In other words, advertising the number of availble resources per > signal > > type does not avoid the possibility of cranck-back but decreases it > as > > much as possible. For sure a good routing prevents from crank-backs > > caused by the restoration of LSP originating on the same Ingress. The > > cranck-backs due to the concurrent restoration of LSPs originating on > > different ingress nodes cannot be avoided. > > > > BR > > Daniele > > > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 16.16 > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > In line > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 4:32 AM > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, one more question. > > > > What about the unreserved bandwidth? > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > (muxCap & signal type) you also need to advertise the unreserved > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > also implies extending the unreserved bandwidth TLV so to create a > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > IB>> role per (muxCap & signal type) per priority level. However, > total > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > IB>> see a compelling reason to the contrary (which I don't) > > > > Igor > > > > Thanks > > Daniele > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: luned=EC 19 luglio 2010 17.48 > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Understood... > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 8:46 AM > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > (i.e. to further classify the information) will be sufficient > > > > > > That's exactly what I've been > > > trying to say all along. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Monday, July 19, 2010 11:31 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor > > > > > > Please see inline. > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Daniele, > > > > > > > > Please, see in line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > role > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > type. > > > > > > > > IB>> in ISCD: > > > > switchCap =3D role; > > > > encodeType =3D muxCap & signal type; > > > > We also have 16 reserved bits which can use for OTN specific info > > in > > > > case we need it. > > > [SCB] I am yet to clearly understand what the role of "role" is, > but > > > agree with your observation on the encode-type and the 16 > > > reserved-bits to further classify the switching information. > > > > > > > > In case (a) you're still missing a lot of information. For each > > role > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > know > > > > if such bandwidth is available for a certain type of ODUj LSP > (e.g. > > > 15 > > > > Gbps available on 3 component links: you advertise 45 Gbps > > available > > > > but no ODU3 can be set up on such TE link). > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > issues > > > > and the requirement of being able to bundle component links > > together > > > > wouldn't be satisfied. > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > will > > > > provide a lot of flexibility: you can specify different things > > (e.g. > > > > available bandwidth) for the same link in different roles. > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > Cheers, > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > To: Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Fatai, > > > > > > > > Please, see my responses on-line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Fatai Zhang > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > Thanks. > > > > I understand what you said. Therefore, we have added some text to > > > > address the requirment in FWK document. However, we still don't > > > > think that we need to extend ISC to meet the requirment. The role > > of > > > > the > > > ODU > > > > can be get from the routing information implicitly. In the > [draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" > > > is > > > > introduced. > > > > > > > > IB>> This is possible, however: > > > > a) this requires OTN specific advertising and processing rules; > > > > b) disallows topology separation in technology independent way > > > > > > > > A quick question on your statement: "the role of an ODU container > > > does > > > > not change hop-by-hop (as some people seem to believe). The role > is > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > transit > > > > nodes. It is it's position in the hierarchy (but not role) that > may > > > > change hop-by-hop. " > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > support > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > role > > > > of Ho ODU level is requested, according to your statement, this > > > > conneciton will be allowed to be created. However, it should not > be > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > ends > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > TE > > > > links will > > > be > > > > disallowed, and the resulting path (if any) will not go through > B11 > > > and > > > > B12. If one circumvents the path computation by providing the > fully > > > > explicit path, the signaling should fail on node B for the same > > > reason: > > > > inconsistency of required (signaled) and supported (by local > > > > interfaces) switchcap. > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > type > > > > indicated in the Switching Type parameter is supported on the > > > > corresponding incoming interface. If the type cannot be > > supported, > > > > the node MUST generate a PathErr message with a "Routing > > > > problem/Switching Type" indication." > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: "Fatai Zhang" ; > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Lou Berger" ; > > > > ; > > > framework@tools.ietf.org> > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > Please, see my answers in line. > > > > > > > > -----Original Message----- > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > draft- > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor and all, > > > > > > > > Thanks for all your comments. > > > > > > > > I think role does not equal switching capability. The operators > can > > > > define different roles depending on their policy and achieve the > > > > role through different methods. However, for OTN networks, the > > > > containers (e.g., ODUk) all have the same switching capablility > > > > (i.e., TDM > > > > switching) and I think we should reflect the natural > > characteristics > > > of > > > > links in the routing. In addition, if we extend the ISC, it will > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > encoding type). > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > the > > > > network as a stack of topologies. Whether a given topology is > real > > > > or virtual is of no importance. > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > capability field (confusing name as it is) is a good way to > > describe > > > a > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > of > > > > topologies that could be easily separated in technology > independent > > > way > > > > should path computation be constrained to particular one or > > > > sub-stack of them. > > > > I think a good way to identify an OTN (virtual) topology is via > > > > (infrastructure) ODU container role of ODUs comprising the > > topology. > > > > BTW IMO the role of an ODU container does not change hop-by-hop > (as > > > > some people seem to believe). The role is only meaningful on the > > ODU > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > position > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > role > > > > is the level of topology it is provisioned for and it is the same > > > > for all ODUs that comprise the topology. For, example a user may > > > provision > > > > a LO topology and constrain ODUs he sells to a set of clients to > > use > > > > the topology rather than any resources available on OTN network. > > > > The bottom line: container's role is the same as the role of > > virtual > > > > topology the container is a part of and could be advertised as > the > > > > corresponding link switchcap. > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > and muxing capabilities with the ISCD of RFC4202, could you > > clarify? > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > encoding type =3D mux. capabilities code > > > > > > > > In addition, could you clarify my questions in another email > > (copied > > > as > > > > follows): > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > > which > > > is > > > > a mistake IMO. > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > as > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > OTU3 > > > link > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > over > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > how > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > ODU > > > > terminating nodes (i.e. on either side of corresponding link). > What > > > > happens on the ODU transit nodes and its place in the hierarchy > on > > > the > > > > transit nodes are of no importance. My LO container can be > carried > > > > by somebody else's LO container and can carry my client's LO > > container. > > > To > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > (e.g. > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > its > > > > path. > > > > > > > > Cheers, > > > > Igor > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > Thanks > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Fatai Zhang" ; > > > > "Lou Berger" ; ; > > > > > > gmpls- > > > > g709-framework@tools.ietf.org> > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Curtis, > > > > > > > > Thanks for your comment. > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > introduced. But IMO they should indicate the link's mux > > capabilities > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > 2. > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > mux.capabilities per role; 3. Link's role and mux. capabilities > can > > > be > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > required); 4. The combination of swicthcaps and encoding type > will > > > look > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > would > > > > want to constrain the routing of OTN connections to pre- > configured > > > > topology with a specific role (e.g. constrain all ODUs it sells > to > > > the > > > > clients to one or more pre-configured LO topologies), this would > be > > > > possible to do in a technology independent way. Suppose an > instance > > > of > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO > OTN > > > > links will be no different from the separation of WDM links from > > > OTUs. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > To: Igor Bryskin > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > the > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which > had > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long > time > > ago. > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > not > > > > understand what the TS type meant did not try to multiplex its LO > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > to > > > using > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO > or > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > latter > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > granularity, then the corresponding G.709 Digital Path FA can be > > withdrawn. > > > > > > > > The Encoding type would be the lower encoding at each end of the > > LSP > > > > regardless of what goes on in the middle since that determines > what > > > can > > > > be wrapped inside it. > > > > > > > > For example: > > > > > > > > OTU3 > > > > OTU2 ODUk=3D3 -------------- > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= lex > > > > even though the ODUk=3D2 at the next hop could not directly contain > > an ODU0. > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > of > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > clear > > > > how in an FA it can be indicated that either type is currently > > > > available (NE capable of both and hasn't committed to either one > > > yet). > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > this > > > > would indicate a huge controversy and I'm not getting it (other > > than > > > a > > > > strong preference to rely on bytes/sec or on enumerated type > > fields). > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > sure > > > if > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > or other intent. Could someone (either draft) concisely > summarize > > > > the multiplexing restrictions in one place, including > restrictions > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > > Behalf Of Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > > document before we can embark on any proposals to the > problem. > > I > > > am > > > > > > still not clear why do we have to deviate from the general > > > approach > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > IB>> plane, and > > > > > > it is highly desirable to adhere to the layer independent > > > paradigm > > > > > > of advertising of TE links, and there is no reason to invent > an > > > OTN > > > > > > specific ISCD. The combination of Switching Capability and > > > Encoding > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > if > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > >TE-link > > > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > create > > > > > > IB>> OTN > > > > > > hierarchies and constrain LO connections to HO containers, > one > > > > needs > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > other interested experts, and we think the proposal described > > in > > > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > more > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > for > > > > > > control plane, no matter how you encode the routing > > information. > > > > For > > > > > > TDM networks, you know the resource is allocated based on TS, > > so > > > > the > > > > > > available TS should be get or induced before creating cross- > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > information, > > > I > > > > > > think you need go to the routing drafts (info model and > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > you > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as > FA > > > for > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > > > better > > > > > > > align the work with 4202. Use of common approaches is of > > > course > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > hearing > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > on > > > > this point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > section > > > > > > >> describes the link-parameters that are required for OTN > > > service > > > > > > >> routing purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > >> ODUj availability within a higher-order container. For > > > > > > >> example, consider an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > >> then > > > > we > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > >> services > > > and > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > >> example > > > > that > > > > > > >> the number of time-slots available is different based on > the > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > >> How do we address this issue based on the approach > specified > > > in > > > > > > >> the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the > available > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances > or > > > the > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > >> outlined in RFC-4202. Refer to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > >> benefit > > > > is > > > > > > >> that the advertisement is TS size independent and hence > will > > > > > > >> simplify the implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> CCAMP mailing list > > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > > CCAMP mailing list > > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Tue Jul 20 10:03:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D04C3A6B3E for ; Tue, 20 Jul 2010 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie3KXgEv7QJU for ; Tue, 20 Jul 2010 10:03:46 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id AACB53A6B31 for ; Tue, 20 Jul 2010 10:03:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXW+xRWFPpm35pIbKFOVzgBKPFl1ccp@postini.com; Tue, 20 Jul 2010 10:04:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 20 Jul 2010 10:01:16 -0700 From: John E Drake To: "curtis@occnc.com" , Fatai Zhang Date: Tue, 20 Jul 2010 10:01:15 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoGzmshSMkcu6uRsyKPkD6yri5KAAEVFTQ Message-ID: <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01-HQ.jnpr.net> References: Your message of "Mon, 19 Jul 2010 10:48:45 +0800." <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> In-Reply-To: <201007201452.o6KEqPhK062342@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Snigdho Bardalai , "ccamp@ietf.org" , Igor Bryskin Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:03:49 -0000 Curtis, Unless you are proposing to issue a new advertisement every time an LSP is = activated or deactivated, which has issues of its own, you will be dealing = with thresholding so what is being advertised is only an approximation (e.g= ., advertise 5 ODUj if the unreserved bandwidth is between 0 ODUj and 10 OD= Uj), so you will never know with certainty whether a given LSP can be activ= ated until you try to activate it. Thanks, John > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 7:52 AM > To: Fatai Zhang > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou > Berger; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > Fatai Zhang writes: > > > > Hi Igor, > > > > Thanks. > > Sorry to jump in but I think I understand Igor's objection (and > Snigdho's objection, and the reason this thread is going on). > > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't think > > that we need to extend ISC to meet the requirment. The role of the > ODU > > can be get from the routing information implicitly. In the > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" is introduced. > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > I think the objection, which would be a very valid one, is that the > ingress has no way to know apriori that a path is infeasible. Each > crankback delays convergence. Crankback should only occur if another > ingress has reserved resources before signaling was completed, not > because inadequate routing information is provided in quiescent state. > > Curtis > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Lou Berger" ; > ; framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > define different roles depending on their policy and achieve the role > through different methods. However, for OTN networks, the containers > (e.g., ODUk) all have the same switching capablility (i.e., TDM > switching) and I think we should reflect the natural characteristics of > links in the routing. In addition, if we extend the ISC, it will make > the encoding type lose its' own meaning(ie., ISC overrides encoding > type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > network as a stack of topologies. Whether a given topology is real or > virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > capability field (confusing name as it is) is a good way to describe a > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > topologies that could be easily separated in technology independent way > should path computation be constrained to particular one or sub-stack > of them. > > I think a good way to identify an OTN (virtual) topology is via > (infrastructure) ODU container role of ODUs comprising the topology. > BTW IMO the role of an ODU container does not change hop-by-hop (as > some people seem to believe). The role is only meaningful on the ODU > terminating nodes and irrelevant on transit nodes. It is it's position > in the hierarchy (but not role) that may change hop-by-hop. ODU's role > is the level of topology it is provisioned for and it is the same for > all ODUs that comprise the topology. For, example a user may provision > a LO topology and constrain ODUs he sells to a set of clients to use > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > topology the container is a part of and could be advertised as the > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles and > muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link > supporting ODU2 switching, which can be used as Lo ODU2 (service over > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > terminating nodes (i.e. on either side of corresponding link). What > happens on the ODU transit nodes and its place in the hierarchy on the > transit nodes are of no importance. My LO container can be carried by > somebody else's LO container and can carry my client's LO container. To > some extent it is similar to MPLS LSP role: LSP always has a role (e.g. > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > ; "Fatai Zhang" ; "Lou > Berger" ; ; g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > introduced. But IMO they should indicate the link's mux capabilities > rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, > SHO, etc.). The link's role or roles IMO should be indicated with a > separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; > > 2. Link may advertise several roles (e.g. HO and SHO) with different > mux.capabilities per role; > > 3. Link's role and mux. capabilities can be advertised with ISCDs as > defined in RFC4202 (no OTN-style ISCD is required); > > 4. The combination of swicthcaps and encoding type will look to CP as > a separate layer, which is exactly how ITU models OTN hierarchies in > all aspects but routing (!?) > > 5. If the operator would want to constrain the routing of OTN > connections to pre-configured topology with a specific role (e.g. > constrain all ODUs it sells to the clients to one or more pre- > configured LO topologies), this would be possible to do in a technology > independent way. Suppose an instance of GMPLS CP manages WDM and OTN > NEs. Then separation of LO from HO OTN links will be no different from > the separation of WDM links from OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO ODU > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > > can be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex = even > > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along with > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > other intent. Could someone (either draft) concisely summarize the > > multiplexing restrictions in one place, including restrictions on > > number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > document > > > > before we can embark on any proposals to the problem. I am still > not clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm of > > > > advertising of TE links, and there is no reason to invent an OTN > specific > > > > ISCD. The combination of Switching Capability and Encoding type > of RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN > layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > to > > > > represent >the low-order ODUj bandwidth within the high-order > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create OTN > > > > hierarchies and constrain LO connections to HO containers, one > needs to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > control > > > > plane, no matter how you encode the routing information. For TDM > networks, > > > > you know the resource is allocated based on TS, so the available > TS should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > will find > > > > that one of your suggestions is adopted (i.e., simply advertize > the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for ODU1, > > > > you have to advertise a new TE link or put this FA as a component > link of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > better > > > > > align the work with 4202. Use of common approaches is of > course one of > > > > > the main objectives of *C*CAMP. I look forward to hearing from > the > > > > > draft and discussion contributors on there progress on this > point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, > consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > we > > > > >> establish an ODU2 service over the link. At this point in time > the OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to > 12+4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > over the > > > > >> ODU2). So it is obvious from this example that the number of > time-slots > > > > >> available is different based on the signal-type (i.e. ODU1 and > ODU2). > > > > >> How do we address this issue based on the approach specified > in the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > number of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > equivalent > > > > >> bandwidth in bytes/sec within a link? This approach seems to > be more > > > > >> in-line with the general approach outlined in RFC-4202. Refer > to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit > is that > > > > >> the advertisement is TS size independent and hence will > simplify the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 10:09:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4803A68DB for ; Tue, 20 Jul 2010 10:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg4yovohhDWe for ; Tue, 20 Jul 2010 10:09:54 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6A9A03A68EC for ; Tue, 20 Jul 2010 10:09:53 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXYboQhiGJ8rrBFAev/oc7Xn78SancN@postini.com; Tue, 20 Jul 2010 10:10:10 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Jul 2010 10:04:02 -0700 From: John E Drake To: "BELOTTI, SERGIO (SERGIO)" , Igor Bryskin Date: Tue, 20 Jul 2010 10:04:00 -0700 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzAAAl3rYA== Message-ID: <5E893DB832F57341992548CDBB333163984487C3CF@EMBX01-HQ.jnpr.net> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:09:55 -0000 Snipped.... >=20 > I realized from someone in this thread (not from you) this was due just > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > advertisement for SDH . Anyway it is a fact that the alternative format > is used in many implementations "in field" for SDH control plane. >=20 JD: As the person to whom I believe you are referring, I would suggest tha= t you actually read RFC 4202 and 4206. From jdrake@juniper.net Tue Jul 20 10:51:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09DB3A687D for ; Tue, 20 Jul 2010 10:51:47 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...7F4@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>\n \n X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3StPwRTEtFs for ; Tue, 20 Jul 2010 10:51:47 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 3FCF63A67D4 for ; Tue, 20 Jul 2010 10:51:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXiPjKGCycl4odzoHakoIYN9MxSe9r7@postini.com; Tue, 20 Jul 2010 10:52:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 20 Jul 2010 10:13:11 -0700 From: John E Drake To: "BELOTTI, SERGIO (SERGIO)" , Igor Bryskin Date: Tue, 20 Jul 2010 10:13:09 -0700 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzAAAl3rYAAASqfw Message-ID: <5E893DB832F57341992548CDBB333163984487C427@EMBX01-HQ.jnpr.net> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:51:48 -0000 >From RFC 4202: For a simple (unbundled) link the Maximum LSP Bandwidth at priority p is defined as the maximum bandwidth an LSP at priority p could reserve. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE]. The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve. Typical values for the Minimum LSP Bandwidth and for the Maximum LSP Bandwidth are enumerated in [GMPLS-SIG]. On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p. On an interface having Arbitrary SDH multiplexing, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, provided that the bandwidth reserved by the LSP is a multiple of the Minimum LSP Bandwidth. >From RFC 4201: 3.10. Maximum LSP Bandwidth The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. For an unbundled link, the Maximum Bandwidth is defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p is defined to be the maximum of the Maximum LSP Bandwidth at priority p of all of its component links. > -----Original Message----- > From: John E Drake > Sent: Tuesday, July 20, 2010 10:04 AM > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > Snipped.... >=20 > > > > I realized from someone in this thread (not from you) this was due > just > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > advertisement for SDH . Anyway it is a fact that the alternative > format > > is used in many implementations "in field" for SDH control plane. > > >=20 > JD: As the person to whom I believe you are referring, I would suggest > that you actually read RFC 4202 and 4206. From IBryskin@advaoptical.com Tue Jul 20 11:02:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AB13A6A92 for ; Tue, 20 Jul 2010 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBrVCzi2Liyo for ; Tue, 20 Jul 2010 11:02:05 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id CB3973A67D4 for ; Tue, 20 Jul 2010 11:02:04 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KI2BKu004776 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 20:02:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 20:02:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 14:02:08 -0400 From: Igor Bryskin To: John E Drake , Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 14:01:53 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAADrhiAAAUKmgAABzojgAAHqoyA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7615A@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C383@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487C383@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_07:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:02:09 -0000 John, You seem to have missed the first point in my email, regarding what is actu= ally advertised. IB>> I always do :=3D) On the other hand you seem not to get about everythi= ng that I am saying. Wrt your proposed solution, it won't work because there is no constraint re= quiring different ISC TLVs to use a common bandwidth pool. IB>> If a TE link advertising contains, say, 2 ISCDs, and a single unreserv= ed bandwidth sub-TLV, how would you interpret this advertising other than t= he two sharing the common pool? Further, if they did share a common bandwidth pool, then at any point in t= ime the unreserved bandwidth is available to all of them. IB>> What if the user preference/policy is to partition the common pool in = a certain way so that the bandwidth fragmentation (as Snigdho correctly poi= nted out) could be avoided? Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 9:16 AM > To: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > I totally agree with you. It is absolutely non OTN specific. However if > a TE link advertises more than one ISCD (with each ISCD containing only > max lsp bandwidth per priority), it is necessary to indicate how the > total link unreserved bandwidth is partitioned between several ISCDs. > What I am suggesting is instead of advertising the unreserved bandwidth > multiple times (one per ISCD), indicate how the bandwidth is split > between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > Igor. > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 11:54 AM > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue > of partitioning unreserved bandwidth across multiple advertised TDM ISC > TLVs is actually a non-issue. > > Unreserved bandwidth by priority has always been advertised using the > MPLS sub-TLV. My point has been that we have never had a requirement > (including SDH/SONET) in the past to advertise unreserved bandwidth by > signal type, so what is special about OTN? > > A further point would be that if we do decide that it is necessary to > advertise unreserved bandwidth by signal type, it should be done in a > general way and not in an OTN specific manner. (And in fact, the > arguments that unreserved bandwidth by signal type needs to be > advertised, such as the latest e-mail from Curtis, are not OTN > specific.) > > Thanks, > > John > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: Tuesday, July 20, 2010 8:21 AM > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > It is a valid point, but the suggested solution is way too expensive. > > All you need is a way to say how the advertised unreserved bandwidth > is > > partitioned between ISCDs in case the TE link advertisement contains > > several of them. One cheap way of doing so is to allocate 3-4 bits > out > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > unreserved bandwidth associated with the ISCD. Another way is to use > > swicthcap specific extension. > > BTW: this is not an OTN specific issue, rather more general: any time > > when a TE link advertises more than one ISCD (which is perfectly Ok > > according to 4203) you'll have the same problem. > > > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 10:57 AM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > The need for unreserved resources advertised per signal type is the > > concurrent path computation. I'll answer quoting a section from the > > info-model draft, please have a look in particular to the example: > > > > > > " Unreserved resources need to be advertised per priority and per > > signal type in order to allow the correct functioning of the > > restoration process. [RFC4203] only allows advertising unreserved > > resources per priority, this leads not to know how many LSPs of a > > specific signal type can be restored. As example it is possible > to > > consider the scenario depicted in the following figure. > > > > +------+ component link 1 +------+ > > | +------------------+ | > > | | component link 2 | | > > | N1 +------------------+ N2 | > > | | component link 3 | | > > | +------------------+ | > > +------+ +---+--+ > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > 32TSs available on the first one, 24TSs on the second, 24TSs on > the > > third and supporting ODU2 and ODU3 signal types. The node would > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > single ODU3 can be set up and a crank-back would be originated. > In > > more complex network scenarios the number of crank-backs can be > much > > higher." > > > > In other words, advertising the number of availble resources per > signal > > type does not avoid the possibility of cranck-back but decreases it > as > > much as possible. For sure a good routing prevents from crank-backs > > caused by the restoration of LSP originating on the same Ingress. The > > cranck-backs due to the concurrent restoration of LSPs originating on > > different ingress nodes cannot be avoided. > > > > BR > > Daniele > > > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 16.16 > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > In line > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 4:32 AM > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, one more question. > > > > What about the unreserved bandwidth? > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > (muxCap & signal type) you also need to advertise the unreserved > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > also implies extending the unreserved bandwidth TLV so to create a > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > IB>> role per (muxCap & signal type) per priority level. However, > total > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > IB>> see a compelling reason to the contrary (which I don't) > > > > Igor > > > > Thanks > > Daniele > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: luned=EC 19 luglio 2010 17.48 > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Understood... > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 8:46 AM > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > (i.e. to further classify the information) will be sufficient > > > > > > That's exactly what I've been > > > trying to say all along. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Monday, July 19, 2010 11:31 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor > > > > > > Please see inline. > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Daniele, > > > > > > > > Please, see in line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > role > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > type. > > > > > > > > IB>> in ISCD: > > > > switchCap =3D role; > > > > encodeType =3D muxCap & signal type; > > > > We also have 16 reserved bits which can use for OTN specific info > > in > > > > case we need it. > > > [SCB] I am yet to clearly understand what the role of "role" is, > but > > > agree with your observation on the encode-type and the 16 > > > reserved-bits to further classify the switching information. > > > > > > > > In case (a) you're still missing a lot of information. For each > > role > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > know > > > > if such bandwidth is available for a certain type of ODUj LSP > (e.g. > > > 15 > > > > Gbps available on 3 component links: you advertise 45 Gbps > > available > > > > but no ODU3 can be set up on such TE link). > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > issues > > > > and the requirement of being able to bundle component links > > together > > > > wouldn't be satisfied. > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > will > > > > provide a lot of flexibility: you can specify different things > > (e.g. > > > > available bandwidth) for the same link in different roles. > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > Cheers, > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > To: Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Fatai, > > > > > > > > Please, see my responses on-line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Fatai Zhang > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > Thanks. > > > > I understand what you said. Therefore, we have added some text to > > > > address the requirment in FWK document. However, we still don't > > > > think that we need to extend ISC to meet the requirment. The role > > of > > > > the > > > ODU > > > > can be get from the routing information implicitly. In the > [draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" > > > is > > > > introduced. > > > > > > > > IB>> This is possible, however: > > > > a) this requires OTN specific advertising and processing rules; > > > > b) disallows topology separation in technology independent way > > > > > > > > A quick question on your statement: "the role of an ODU container > > > does > > > > not change hop-by-hop (as some people seem to believe). The role > is > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > transit > > > > nodes. It is it's position in the hierarchy (but not role) that > may > > > > change hop-by-hop. " > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > support > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > role > > > > of Ho ODU level is requested, according to your statement, this > > > > conneciton will be allowed to be created. However, it should not > be > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > ends > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > TE > > > > links will > > > be > > > > disallowed, and the resulting path (if any) will not go through > B11 > > > and > > > > B12. If one circumvents the path computation by providing the > fully > > > > explicit path, the signaling should fail on node B for the same > > > reason: > > > > inconsistency of required (signaled) and supported (by local > > > > interfaces) switchcap. > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > type > > > > indicated in the Switching Type parameter is supported on the > > > > corresponding incoming interface. If the type cannot be > > supported, > > > > the node MUST generate a PathErr message with a "Routing > > > > problem/Switching Type" indication." > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: "Fatai Zhang" ; > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Lou Berger" ; > > > > ; > > > framework@tools.ietf.org> > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > Please, see my answers in line. > > > > > > > > -----Original Message----- > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > draft- > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor and all, > > > > > > > > Thanks for all your comments. > > > > > > > > I think role does not equal switching capability. The operators > can > > > > define different roles depending on their policy and achieve the > > > > role through different methods. However, for OTN networks, the > > > > containers (e.g., ODUk) all have the same switching capablility > > > > (i.e., TDM > > > > switching) and I think we should reflect the natural > > characteristics > > > of > > > > links in the routing. In addition, if we extend the ISC, it will > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > encoding type). > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > the > > > > network as a stack of topologies. Whether a given topology is > real > > > > or virtual is of no importance. > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > capability field (confusing name as it is) is a good way to > > describe > > > a > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > of > > > > topologies that could be easily separated in technology > independent > > > way > > > > should path computation be constrained to particular one or > > > > sub-stack of them. > > > > I think a good way to identify an OTN (virtual) topology is via > > > > (infrastructure) ODU container role of ODUs comprising the > > topology. > > > > BTW IMO the role of an ODU container does not change hop-by-hop > (as > > > > some people seem to believe). The role is only meaningful on the > > ODU > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > position > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > role > > > > is the level of topology it is provisioned for and it is the same > > > > for all ODUs that comprise the topology. For, example a user may > > > provision > > > > a LO topology and constrain ODUs he sells to a set of clients to > > use > > > > the topology rather than any resources available on OTN network. > > > > The bottom line: container's role is the same as the role of > > virtual > > > > topology the container is a part of and could be advertised as > the > > > > corresponding link switchcap. > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > and muxing capabilities with the ISCD of RFC4202, could you > > clarify? > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > encoding type =3D mux. capabilities code > > > > > > > > In addition, could you clarify my questions in another email > > (copied > > > as > > > > follows): > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > > which > > > is > > > > a mistake IMO. > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > as > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > OTU3 > > > link > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > over > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > how > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > ODU > > > > terminating nodes (i.e. on either side of corresponding link). > What > > > > happens on the ODU transit nodes and its place in the hierarchy > on > > > the > > > > transit nodes are of no importance. My LO container can be > carried > > > > by somebody else's LO container and can carry my client's LO > > container. > > > To > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > (e.g. > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > its > > > > path. > > > > > > > > Cheers, > > > > Igor > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > Thanks > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Fatai Zhang" ; > > > > "Lou Berger" ; ; > > > > > > gmpls- > > > > g709-framework@tools.ietf.org> > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Curtis, > > > > > > > > Thanks for your comment. > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > introduced. But IMO they should indicate the link's mux > > capabilities > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > 2. > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > mux.capabilities per role; 3. Link's role and mux. capabilities > can > > > be > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > required); 4. The combination of swicthcaps and encoding type > will > > > look > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > would > > > > want to constrain the routing of OTN connections to pre- > configured > > > > topology with a specific role (e.g. constrain all ODUs it sells > to > > > the > > > > clients to one or more pre-configured LO topologies), this would > be > > > > possible to do in a technology independent way. Suppose an > instance > > > of > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO > OTN > > > > links will be no different from the separation of WDM links from > > > OTUs. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > To: Igor Bryskin > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > the > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which > had > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long > time > > ago. > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > not > > > > understand what the TS type meant did not try to multiplex its LO > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > to > > > using > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO > or > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > latter > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > granularity, then the corresponding G.709 Digital Path FA can be > > withdrawn. > > > > > > > > The Encoding type would be the lower encoding at each end of the > > LSP > > > > regardless of what goes on in the middle since that determines > what > > > can > > > > be wrapped inside it. > > > > > > > > For example: > > > > > > > > OTU3 > > > > OTU2 ODUk=3D3 -------------- > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= lex > > > > even though the ODUk=3D2 at the next hop could not directly contain > > an ODU0. > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > of > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > clear > > > > how in an FA it can be indicated that either type is currently > > > > available (NE capable of both and hasn't committed to either one > > > yet). > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > this > > > > would indicate a huge controversy and I'm not getting it (other > > than > > > a > > > > strong preference to rely on bytes/sec or on enumerated type > > fields). > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > sure > > > if > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > or other intent. Could someone (either draft) concisely > summarize > > > > the multiplexing restrictions in one place, including > restrictions > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > > Behalf Of Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > > document before we can embark on any proposals to the > problem. > > I > > > am > > > > > > still not clear why do we have to deviate from the general > > > approach > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > IB>> plane, and > > > > > > it is highly desirable to adhere to the layer independent > > > paradigm > > > > > > of advertising of TE links, and there is no reason to invent > an > > > OTN > > > > > > specific ISCD. The combination of Switching Capability and > > > Encoding > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > if > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > >TE-link > > > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > create > > > > > > IB>> OTN > > > > > > hierarchies and constrain LO connections to HO containers, > one > > > > needs > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > other interested experts, and we think the proposal described > > in > > > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > more > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > for > > > > > > control plane, no matter how you encode the routing > > information. > > > > For > > > > > > TDM networks, you know the resource is allocated based on TS, > > so > > > > the > > > > > > available TS should be get or induced before creating cross- > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > information, > > > I > > > > > > think you need go to the routing drafts (info model and > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > you > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as > FA > > > for > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > > > better > > > > > > > align the work with 4202. Use of common approaches is of > > > course > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > hearing > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > on > > > > this point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > section > > > > > > >> describes the link-parameters that are required for OTN > > > service > > > > > > >> routing purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > >> ODUj availability within a higher-order container. For > > > > > > >> example, consider an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > >> then > > > > we > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > >> services > > > and > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > >> example > > > > that > > > > > > >> the number of time-slots available is different based on > the > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > >> How do we address this issue based on the approach > specified > > > in > > > > > > >> the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the > available > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances > or > > > the > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > >> outlined in RFC-4202. Refer to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > >> benefit > > > > is > > > > > > >> that the advertisement is TS size independent and hence > will > > > > > > >> simplify the implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> CCAMP mailing list > > > > > > >> CCAMP@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > _______________________________________________ > > > > > > > CCAMP mailing list > > > > > > > CCAMP@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Tue Jul 20 11:16:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0863A6C56 for ; Tue, 20 Jul 2010 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpU-jsphmWu8 for ; Tue, 20 Jul 2010 11:16:34 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 1F80F3A6C0E for ; Tue, 20 Jul 2010 11:16:22 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KIGSxB023597 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 20:16:28 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 20:16:28 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 20:16:28 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 14:16:25 -0400 From: Igor Bryskin To: "BELOTTI, SERGIO (SERGIO)" Date: Tue, 20 Jul 2010 14:16:22 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzAABJqrMA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76167@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_07:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:16:49 -0000 Sergio, I am not jumping at the solution because the solution exists for a long tim= e already. I'd like to make it abundantly clear. All I am saying, have been saying and= still stand by is that for the routing in the OTN space we don't need anyt= hing outside of RFC 4203. All we have to do: 1) define a bunch of OTN switchcaps (one per role); 2) define a bunch of encoding types (on per mux. caps & signal type). One thing worth of considering is enhancing 4203 to indicate how the advert= ised pool of unreserved bandwidth is split between several ISCDs, but this = is not an OTN specific issue. Cheers, Igor -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Tuesday, July 20, 2010 12:16 PM To: Igor Bryskin Cc: ccamp@ietf.org; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curt= is@occnc.com Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, You jump right now at the solution ! There is a problem of spatial allocati= on and we tried to solve it suggesting a format. This cannot be the best one but at least before saying it is too expensive = , the comparison has to be made with one can address the issue as well. Thi= s is not the case for the present RFC 4202/4203 as you admit proposing a mo= dification. We are open to discuss the "best way" to solve different issues= we depicted in the info draft. On the other hand you pointed out correctly that this is not an OTN specifi= c issue: in fact in SDH we have the same problem and btw a similar approach= of what proposed by us is proposed also in the draft-ong-gmpls-ason-routin= g-exper-02. I realized from someone in this thread (not from you) this was due just to = ignorance and misunderstanding of RFC 4202/4203 bandwidth advertisement for= SDH . Anyway it is a fact that the alternative format is used in many impl= ementations "in field" for SDH control plane. I think could be a good point try to have at the end one single format that= can accomplish issues coming from different TDM technologies. Once that we have a common understanding of requirements and issues nothing= prevent to progress the format in the best way. Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: marted=EC 20 luglio 2010 17.21 A: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t It is a valid point, but the suggested solution is way too expensive. All y= ou need is a way to say how the advertised unreserved bandwidth is partitio= ned between ISCDs in case the TE link advertisement contains several of the= m. One cheap way of doing so is to allocate 3-4 bits out of the ISCD sub-TL= V reserved bits to indicate the fraction of total unreserved bandwidth asso= ciated with the ISCD. Another way is to use swicthcap specific extension. BTW: this is not an OTN specific issue, rather more general: any time when = a TE link advertises more than one ISCD (which is perfectly Ok according to= 4203) you'll have the same problem. Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 10:57 AM To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, The need for unreserved resources advertised per signal type is the concurr= ent path computation. I'll answer quoting a section from the info-model dra= ft, please have a look in particular to the example: " Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority, this leads not to know how many LSPs of a specific signal type can be restored. As example it is possible to consider the scenario depicted in the following figure. +------+ component link 1 +------+ | +------------------+ | | | component link 2 | | | N1 +------------------+ N2 | | | component link 3 | | | +------------------+ | +------+ +---+--+ Suppose to have a TE link comprising 3 ODU3 component links with 32TSs available on the first one, 24TSs on the second, 24TSs on the third and supporting ODU2 and ODU3 signal types. The node would advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the network could try to restore 2 ODU3 (64TSs) in such TE-link while only a single ODU3 can be set up and a crank-back would be originated. In more complex network scenarios the number of crank-backs can be much higher." In other words, advertising the number of availble resources per signal typ= e does not avoid the possibility of cranck-back but decreases it as much as= possible. For sure a good routing prevents from crank-backs caused by the = restoration of LSP originating on the same Ingress. The cranck-backs due to= the concurrent restoration of LSPs originating on different ingress nodes = cannot be avoided. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: marted=EC 20 luglio 2010 16.16 To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In line -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, July 20, 2010 4:32 AM To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, one more question. What about the unreserved bandwidth? If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCap = & signal type) you also need to advertise the unreserved bandwidth using 1 = unreserved bandwidth sub-TLV per ISCD, correct? This also implies extending= the unreserved bandwidth TLV so to create a corrispondence between the cou= ples (ISCD-unreserved bandwidth subTLV). IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per IB>> role per (muxCap & signal type) per priority level. However, total IB>> unreserved bandwidth IMO is OK to share between roles unless you IB>> see a compelling reason to the contrary (which I don't) Igor Thanks Daniele -----Original Message----- From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: luned=EC 19 luglio 2010 17.48 To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com Cc: ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Understood... Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, July 19, 2010 8:46 AM > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient > > That's exactly what I've been > trying to say all along. > > Cheers, > Igor > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Monday, July 19, 2010 11:31 AM > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor > > Please see inline. > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 7:43 AM > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Daniele, > > > > Please, see in line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Monday, July 19, 2010 10:31 AM > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > IB>> in ISCD: > > switchCap =3D role; > > encodeType =3D muxCap & signal type; > > We also have 16 reserved bits which can use for OTN specific info in > > case we need it. > [SCB] I am yet to clearly understand what the role of "role" is, but > agree with your observation on the encode-type and the 16 > reserved-bits to further classify the switching information. > > > > In case (a) you're still missing a lot of information. For each role > > you would advertise just the unreserved bandwidth but you wouldn't > know > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > 15 > > Gbps available on 3 component links: you advertise 45 Gbps available > > but no ODU3 can be set up on such TE link). > > > > In case (b) the number of ISCDs would cause serious scalability > issues > > and the requirement of being able to bundle component links together > > wouldn't be satisfied. > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > provide a lot of flexibility: you can specify different things (e.g. > > available bandwidth) for the same link in different roles. > [SCB] Are you saying the ISCD as defined today with minor extensions > (i.e. to further classify the information) will be sufficient? > > > > Cheers, > > Daniele > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Igor Bryskin > > Sent: luned=EC 19 luglio 2010 15.40 > > To: Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Fatai, > > > > Please, see my responses on-line. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Fatai Zhang > > Sent: Sunday, July 18, 2010 10:49 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor, > > > > Thanks. > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't > > think that we need to extend ISC to meet the requirment. The role of > > the > ODU > > can be get from the routing information implicitly. In the [draft- > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > is > > introduced. > > > > IB>> This is possible, however: > > a) this requires OTN specific advertising and processing rules; > > b) disallows topology separation in technology independent way > > > > A quick question on your statement: "the role of an ODU container > does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on > transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE > > links will > be > > disallowed, and the resulting path (if any) will not go through B11 > and > > B12. If one circumvents the path computation by providing the fully > > explicit path, the signaling should fail on node B for the same > reason: > > inconsistency of required (signaled) and supported (by local > > interfaces) switchcap. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > IB>> Indeed > > > > > > > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ; > > ; > framework@tools.ietf.org> > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > draft- > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can > > define different roles depending on their policy and achieve the > > role through different methods. However, for OTN networks, the > > containers (e.g., ODUk) all have the same switching capablility > > (i.e., TDM > > switching) and I think we should reflect the natural characteristics > of > > links in the routing. In addition, if we extend the ISC, it will > > make the encoding type lose its' own meaning(ie., ISC overrides > > encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real > > or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > capability field (confusing name as it is) is a good way to describe > a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent > way > > should path computation be constrained to particular one or > > sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > some people seem to believe). The role is only meaningful on the ODU > > terminating nodes and irrelevant on transit nodes. It is it's > position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > is the level of topology it is provisioned for and it is the same > > for all ODUs that comprise the topology. For, example a user may > provision > > a LO topology and constrain ODUs he sells to a set of clients to use > > the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual > > topology the container is a part of and could be advertised as the > > corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied > as > > follows): > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h > is > > a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What > > happens on the ODU transit nodes and its place in the hierarchy on > the > > transit nodes are of no importance. My LO container can be carried > > by somebody else's LO container and can carry my client's LO container. > To > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > path. > > > > Cheers, > > Igor > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ; > > "Lou Berger" ; ; > > gmpls- > > g709-framework@tools.ietf.org> > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types > > introduced. But IMO they should indicate the link's mux capabilities > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; 2. > > Link may advertise several roles (e.g. HO and SHO) with different > > mux.capabilities per role; 3. Link's role and mux. capabilities can > be > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > required); 4. The combination of swicthcaps and encoding type will > look > > to CP as a separate layer, which is exactly how ITU models OTN > > hierarchies in all aspects but routing (!?) 5. If the operator would > > want to constrain the routing of OTN connections to pre-configured > > topology with a specific role (e.g. constrain all ODUs it sells to > the > > clients to one or more pre-configured LO topologies), this would be > > possible to do in a technology independent way. Suppose an instance > of > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > links will be no different from the separation of WDM links from > OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > in turn replaced the Encoding Type of "Digital Wrapper" a long time ago= . > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > latter > > is for backward compatibility and should be ignored if OTN_LO, > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > granularity, then the corresponding G.709 Digital Path FA can be withdr= awn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > can > > be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex > > even though the ODUk=3D2 at the next hop could not directly contain an = ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels > of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > ODU-flex, and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one > yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than > a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > or other intent. Could someone (either draft) concisely summarize > > the multiplexing restrictions in one place, including restrictions > > on number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > document before we can embark on any proposals to the problem. I > am > > > > still not clear why do we have to deviate from the general > approach > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > IB>> plane, and > > > > it is highly desirable to adhere to the layer independent > paradigm > > > > of advertising of TE links, and there is no reason to invent an > OTN > > > > specific ISCD. The combination of Switching Capability and > Encoding > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > >TE-link > > to > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > create > > > > IB>> OTN > > > > hierarchies and constrain LO connections to HO containers, one > > needs > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > other interested experts, and we think the proposal described in > "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > control plane, no matter how you encode the routing information. > > For > > > > TDM networks, you know the resource is allocated based on TS, so > > the > > > > available TS should be get or induced before creating cross- > > connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > I > > > > think you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > will find that one of your suggestions is adopted (i.e., simply > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > for > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; > > > > > draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org g709- > > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to > > better > > > > > align the work with 4202. Use of common approaches is of > course > > > > > one of the main objectives of *C*CAMP. I look forward to > hearing > > > > > from the draft and discussion contributors on there progress > > > > > on > > this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This > section > > > > >> describes the link-parameters that are required for OTN > service > > > > >> routing purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order > > > > >> ODUj availability within a higher-order container. For > > > > >> example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > >> then > > we > > > > >> establish an ODU2 service over the link. At this point in > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > >> services > and > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > >> are contained over the ODU2). So it is obvious from this > > > > >> example > > that > > > > >> the number of time-slots available is different based on the > > signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified > in > > > > >> the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > the > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > >> approach seems to be more in-line with the general approach > > > > >> outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > >> being advertised per VC rate for an SDH link. The additional > > > > >> benefit > > is > > > > >> that the advertisement is TS size independent and hence will > > > > >> simplify the implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> CCAMP mailing list > > > > >> CCAMP@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Tue Jul 20 08:47:48 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0CD3A68DF for ; Tue, 20 Jul 2010 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GED0EGCwz2WB for ; Tue, 20 Jul 2010 08:47:45 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 5F4F93A68D7 for ; Tue, 20 Jul 2010 08:47:45 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Tue, 20 Jul 2010 08:47:42 -0700 From: Snigdho Bardalai To: Igor Bryskin , Daniele Ceccarelli , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 08:47:42 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAFVAXA= Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE7280@SV-EXDB1.infinera.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Jul 2010 11:19:43 -0700 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 15:47:48 -0000 Generally speaking - unreserved bandwidth per signal-type is desirable to a= ddress potential fragmentation of bandwidth across component links in a bun= dle. Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 8:21 AM > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > It is a valid point, but the suggested solution is way too expensive. > All you need is a way to say how the advertised unreserved bandwidth is > partitioned between ISCDs in case the TE link advertisement contains > several of them. One cheap way of doing so is to allocate 3-4 bits out > of the ISCD sub-TLV reserved bits to indicate the fraction of total > unreserved bandwidth associated with the ISCD. Another way is to use > swicthcap specific extension. > BTW: this is not an OTN specific issue, rather more general: any time > when a TE link advertises more than one ISCD (which is perfectly Ok > according to 4203) you'll have the same problem. > > Igor > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 10:57 AM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > The need for unreserved resources advertised per signal type is the > concurrent path computation. I'll answer quoting a section from the > info-model draft, please have a look in particular to the example: > > > " Unreserved resources need to be advertised per priority and per > signal type in order to allow the correct functioning of the > restoration process. [RFC4203] only allows advertising unreserved > resources per priority, this leads not to know how many LSPs of a > specific signal type can be restored. As example it is possible to > consider the scenario depicted in the following figure. > > +------+ component link 1 +------+ > | +------------------+ | > | | component link 2 | | > | N1 +------------------+ N2 | > | | component link 3 | | > | +------------------+ | > +------+ +---+--+ > > Suppose to have a TE link comprising 3 ODU3 component links with > 32TSs available on the first one, 24TSs on the second, 24TSs on the > third and supporting ODU2 and ODU3 signal types. The node would > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > LSP bandwidth equal to 32 TSs. In case of restoration the network > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > single ODU3 can be set up and a crank-back would be originated. In > more complex network scenarios the number of crank-backs can be much > higher." > > In other words, advertising the number of availble resources per signal > type does not avoid the possibility of cranck-back but decreases it as > much as possible. For sure a good routing prevents from crank-backs > caused by the restoration of LSP originating on the same Ingress. The > cranck-backs due to the concurrent restoration of LSPs originating on > different ingress nodes cannot be avoided. > > BR > Daniele > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: marted=EC 20 luglio 2010 16.16 > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > In line > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 4:32 AM > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, one more question. > > What about the unreserved bandwidth? > If you're advertising the max lsp bandwidth by 1 ISCD per role per > (muxCap & signal type) you also need to advertise the unreserved > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > also implies extending the unreserved bandwidth TLV so to create a > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > IB>> role per (muxCap & signal type) per priority level. However, total > IB>> unreserved bandwidth IMO is OK to share between roles unless you > IB>> see a compelling reason to the contrary (which I don't) > > Igor > > Thanks > Daniele > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: luned=EC 19 luglio 2010 17.48 > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Understood... > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 8:46 AM > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient > > > > That's exactly what I've been > > trying to say all along. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Monday, July 19, 2010 11:31 AM > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor > > > > Please see inline. > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 7:43 AM > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Daniele, > > > > > > Please, see in line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Monday, July 19, 2010 10:31 AM > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > role > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > type. > > > > > > IB>> in ISCD: > > > switchCap =3D role; > > > encodeType =3D muxCap & signal type; > > > We also have 16 reserved bits which can use for OTN specific info > in > > > case we need it. > > [SCB] I am yet to clearly understand what the role of "role" is, but > > agree with your observation on the encode-type and the 16 > > reserved-bits to further classify the switching information. > > > > > > In case (a) you're still missing a lot of information. For each > role > > > you would advertise just the unreserved bandwidth but you wouldn't > > know > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > 15 > > > Gbps available on 3 component links: you advertise 45 Gbps > available > > > but no ODU3 can be set up on such TE link). > > > > > > In case (b) the number of ISCDs would cause serious scalability > > issues > > > and the requirement of being able to bundle component links > together > > > wouldn't be satisfied. > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > will > > > provide a lot of flexibility: you can specify different things > (e.g. > > > available bandwidth) for the same link in different roles. > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient? > > > > > > Cheers, > > > Daniele > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: luned=EC 19 luglio 2010 15.40 > > > To: Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Fatai, > > > > > > Please, see my responses on-line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Fatai Zhang > > > Sent: Sunday, July 18, 2010 10:49 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > Thanks. > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't > > > think that we need to extend ISC to meet the requirment. The role > of > > > the > > ODU > > > can be get from the routing information implicitly. In the [draft- > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > Lambda" > > is > > > introduced. > > > > > > IB>> This is possible, however: > > > a) this requires OTN specific advertising and processing rules; > > > b) disallows topology separation in technology independent way > > > > > > A quick question on your statement: "the role of an ODU container > > does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on > > transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > ends > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > TE > > > links will > > be > > > disallowed, and the resulting path (if any) will not go through B11 > > and > > > B12. If one circumvents the path computation by providing the fully > > > explicit path, the signaling should fail on node B for the same > > reason: > > > inconsistency of required (signaled) and supported (by local > > > interfaces) switchcap. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be > supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > IB>> Indeed > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Lou Berger" ; > > > ; > > framework@tools.ietf.org> > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > draft- > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can > > > define different roles depending on their policy and achieve the > > > role through different methods. However, for OTN networks, the > > > containers (e.g., ODUk) all have the same switching capablility > > > (i.e., TDM > > > switching) and I think we should reflect the natural > characteristics > > of > > > links in the routing. In addition, if we extend the ISC, it will > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > encoding type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > network as a stack of topologies. Whether a given topology is real > > > or virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > capability field (confusing name as it is) is a good way to > describe > > a > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > topologies that could be easily separated in technology independent > > way > > > should path computation be constrained to particular one or > > > sub-stack of them. > > > I think a good way to identify an OTN (virtual) topology is via > > > (infrastructure) ODU container role of ODUs comprising the > topology. > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > some people seem to believe). The role is only meaningful on the > ODU > > > terminating nodes and irrelevant on transit nodes. It is it's > > position > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > role > > > is the level of topology it is provisioned for and it is the same > > > for all ODUs that comprise the topology. For, example a user may > > provision > > > a LO topology and constrain ODUs he sells to a set of clients to > use > > > the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of > virtual > > > topology the container is a part of and could be advertised as the > > > corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles > > > and muxing capabilities with the ISCD of RFC4202, could you > clarify? > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type =3D mux. capabilities code > > > > > > In addition, could you clarify my questions in another email > (copied > > as > > > follows): > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > which > > is > > > a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > OTU3 > > link > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > over > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > how > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > terminating nodes (i.e. on either side of corresponding link). What > > > happens on the ODU transit nodes and its place in the hierarchy on > > the > > > transit nodes are of no importance. My LO container can be carried > > > by somebody else's LO container and can carry my client's LO > container. > > To > > > some extent it is similar to MPLS LSP role: LSP always has a role > > (e.g. > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > path. > > > > > > Cheers, > > > Igor > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Fatai Zhang" ; > > > "Lou Berger" ; ; > > > > gmpls- > > > g709-framework@tools.ietf.org> > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types > > > introduced. But IMO they should indicate the link's mux > capabilities > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > with a separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; > 2. > > > Link may advertise several roles (e.g. HO and SHO) with different > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > be > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > required); 4. The combination of swicthcaps and encoding type will > > look > > > to CP as a separate layer, which is exactly how ITU models OTN > > > hierarchies in all aspects but routing (!?) 5. If the operator > would > > > want to constrain the routing of OTN connections to pre-configured > > > topology with a specific role (e.g. constrain all ODUs it sells to > > the > > > clients to one or more pre-configured LO topologies), this would be > > > possible to do in a technology independent way. Suppose an instance > > of > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > links will be no different from the separation of WDM links from > > OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as > the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > /*****/ > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > ago. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > to > > using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > latter > > > is for backward compatibility and should be ignored if OTN_LO, > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > granularity, then the corresponding G.709 Digital Path FA can be > withdrawn. > > > > > > The Encoding type would be the lower encoding at each end of the > LSP > > > regardless of what goes on in the middle since that determines what > > can > > > be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3D3 -------------- > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dfle= x > > > even though the ODUk=3D2 at the next hop could not directly contain > an ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels > > of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > ODU-flex, and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one > > yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other > than > > a > > > strong preference to rely on bytes/sec or on enumerated type > fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > or other intent. Could someone (either draft) concisely summarize > > > the multiplexing restrictions in one place, including restrictions > > > on number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > Behalf Of Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > document before we can embark on any proposals to the problem. > I > > am > > > > > still not clear why do we have to deviate from the general > > approach > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > IB>> plane, and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > > > of advertising of TE links, and there is no reason to invent an > > OTN > > > > > specific ISCD. The combination of Switching Capability and > > Encoding > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > if > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > >TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > > This is simply >blowing up the solution to a very simple > problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > > IB>> OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > other interested experts, and we think the proposal described > in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > control plane, no matter how you encode the routing > information. > > > For > > > > > TDM networks, you know the resource is allocated based on TS, > so > > > the > > > > > available TS should be get or induced before creating cross- > > > connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > information, > > I > > > > > think you need go to the routing drafts (info model and > > encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > you > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > container instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; > > > > > > draft-ietf-ccamp-gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > > > one of the main objectives of *C*CAMP. I look forward to > > hearing > > > > > > from the draft and discussion contributors on there progress > > > > > > on > > > this point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > > >> routing purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order > > > > > >> ODUj availability within a higher-order container. For > > > > > >> example, consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > >> then > > > we > > > > > >> establish an ODU2 service over the link. At this point in > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > >> services > > and > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > >> example > > > that > > > > > >> the number of time-slots available is different based on the > > > signal-type (i.e. ODU1 and ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > > >> the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > the > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > >> approach seems to be more in-line with the general approach > > > > > >> outlined in RFC-4202. Refer to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > >> benefit > > > is > > > > > >> that the advertisement is TS size independent and hence will > > > > > >> simplify the implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> CCAMP mailing list > > > > > >> CCAMP@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Tue Jul 20 11:20:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FA33A6B70 for ; Tue, 20 Jul 2010 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfENHmVs20Y2 for ; Tue, 20 Jul 2010 11:20:39 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 5B3273A6B47 for ; Tue, 20 Jul 2010 11:20:39 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KIKlpk028739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 20:20:47 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 20:20:47 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 14:20:44 -0400 From: Igor Bryskin To: John E Drake , "BELOTTI, SERGIO (SERGIO)" Date: Tue, 20 Jul 2010 14:20:42 -0400 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzAAAl3rYAAASqfwAAJNwHA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C427@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487C427@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_07:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:20:40 -0000 John, The point is that from ISCD you can not figure out how *many* LSPs matching= the ISCD you can accommodate on the link. Such information is important in= case of con-current routing (e.g. restoration after link failure). Igor=20 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Tuesday, July 20, 2010 1:13 PM To: BELOTTI, SERGIO (SERGIO); Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01= .txt >From RFC 4202: For a simple (unbundled) link the Maximum LSP Bandwidth at priority p is defined as the maximum bandwidth an LSP at priority p could reserve. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE]. The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve. Typical values for the Minimum LSP Bandwidth and for the Maximum LSP Bandwidth are enumerated in [GMPLS-SIG]. On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p. On an interface having Arbitrary SDH multiplexing, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, provided that the bandwidth reserved by the LSP is a multiple of the Minimum LSP Bandwidth. >From RFC 4201: 3.10. Maximum LSP Bandwidth The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. For an unbundled link, the Maximum Bandwidth is defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p is defined to be the maximum of the Maximum LSP Bandwidth at priority p of all of its component links. > -----Original Message----- > From: John E Drake > Sent: Tuesday, July 20, 2010 10:04 AM > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > Snipped.... >=20 > > > > I realized from someone in this thread (not from you) this was due > just > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > advertisement for SDH . Anyway it is a fact that the alternative > format > > is used in many implementations "in field" for SDH control plane. > > >=20 > JD: As the person to whom I believe you are referring, I would suggest > that you actually read RFC 4202 and 4206. From lberger@labn.net Tue Jul 20 11:23:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D4B3A687D for ; Tue, 20 Jul 2010 11:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5LtvcFxd79d for ; Tue, 20 Jul 2010 11:23:47 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 45DD03A67A7 for ; Tue, 20 Jul 2010 11:23:47 -0700 (PDT) Received: (qmail 32271 invoked by uid 0); 20 Jul 2010 18:24:02 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 20 Jul 2010 18:24:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=NR4VaRui0e0ovxJwbxstuJKxFunAwt4QP466tgU7pSmr6FalC64ehlahRwmnRMoaklCExOVnPYXKkPErW4PLYWuQbzEmXcrjowew4pV3E8c10VH/EFOJI/gf7u+fegos; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1ObHU2-0000nL-J0; Tue, 20 Jul 2010 12:24:02 -0600 Message-ID: <4C45E9C3.20003@labn.net> Date: Tue, 20 Jul 2010 14:24:03 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: curtis@occnc.com References: <201007142258.o6EMw9KJ051582@harbor.orleans.occnc.com> In-Reply-To: <201007142258.o6EMw9KJ051582@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP WG Subject: Re: [CCAMP] Draft response to OIF letter regarding Interface Identifier dated May 21 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:23:49 -0000 Curtis, Much thanks! All, The OIF has asked that we send this response ASAP, so it will be sent in a few minutes. We don't expect that we'll miss any comments by sending it a day early. Lou (and Deborah) On 7/14/2010 6:58 PM, Curtis Villamizar wrote: > In message<4C3E0F4D.3020902@labn.net> > Lou Berger writes: >> >> All, >> The enclosed is a proposed response to a letter received from the OIF. >> Please send any comments you have by July 21. >> >> Thank you, >> Deborah and Lou >> >> ------------------------- >> To: "Kimberly Chiu" >> Cc: "'Ong, Lyndon'", >> ccamp@ietf.org >> Subject: Response to OIF letter regarding Interface Identifier >> >> Dear Mr. Ong, >> >> Thank you for your letter regarding Interface Identifier dated May >> 21, 2010. The letter referenced several RFCs only some of which are >> products of the CCAMP working group. (RFC4202 and RFC4631 are products >> of CCAMP, while RFC3477, RFC3811, RFC4220 are products of MPLS.) >> >> In the letter you ask about the range of values allowed for an >> unnumbered link identifier. RFC 4202 (and RFC 3477) define an >> unnumbered link being identified by a "non-zero 32-bit number that is >> unique within the scope of the LSR". RFC4203 and RFC4205 contain >> parallel language. These documents therefore allow an implementation to >> select any value that can be represented in 32 bits other than zero. >> >> You note in your letter that "The RFC MIBs appear to imply that the >> range is restricted to a maximum value of 2147483647." This observation >> is further supported by the InterfaceIndex and InterfaceIndexOrZero >> textual convention defined in RFC 2863, both of which have a maximum >> value of 2147483647. >> >> Based on the above as well as the other MIBs you reference in your >> letter, it seems reasonable that an implementation will select values >> that can be fully represented in all MIBs that the implementation may >> support, i.e., up to 2147483647. That said, the choice of an unnumbered >> link identifier remains completely within the scope of an implementation >> and an implementation may choose to select larger values. >> >> Regards, >> Deborah Brungard and Lou Berger >> IETF CCAMP Working Group Co-Chairs >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > Seems fine. 2147483647 is just 2^31 - 1 so someone seems to have > assumed that the ifindex is a signed 32 bit number. > > Also note that all ones is reserved in Link Bundling. You may want to > point that out. > > Curtis > > > > From lberger@labn.net Tue Jul 20 11:29:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C3A3A6C61 for ; Tue, 20 Jul 2010 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0n7nUzGFJ-e for ; Tue, 20 Jul 2010 11:29:09 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id D9E6B3A6C36 for ; Tue, 20 Jul 2010 11:29:08 -0700 (PDT) Received: (qmail 28538 invoked by uid 0); 20 Jul 2010 18:29:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 20 Jul 2010 18:29:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=hcx6FSgHHKX2Mnq17iQAe+AGQaH/Di/wFXJ34S6Vj0xdfGlbn4arMTET71XKQgmlbROjKKtLJ08e6InizY7Bj5FWYuDLCKye4SWFEPvwYc6h3+NTHWJTW0meaHuVjdPy; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1ObHZE-0002Ut-90; Tue, 20 Jul 2010 12:29:24 -0600 Message-ID: <4C45EB01.7050606@labn.net> Date: Tue, 20 Jul 2010 14:29:21 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kimberly Chiu , "Ong, Lyndon" , CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Response to OIF letter regarding Interface Identifier X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:29:10 -0000 Dear Mr. Ong, Thank you for your letter regarding Interface Identifier dated May 21, 2010. The letter referenced several RFCs only some of which are products of the CCAMP working group. (RFC4202 and RFC4631 are products of CCAMP, while RFC3477, RFC3811, RFC4220 are products of MPLS.) In the letter you ask about the range of values allowed for an unnumbered link identifier. RFC 4202 (and RFC 3477) define an unnumbered link being identified by a "non-zero 32-bit number that is unique within the scope of the LSR". RFC4203 and RFC4205 contain parallel language. RFC4201 effectively adds an additional restriction by introducing special semantics for the value 0xFFFFFFFF. These documents therefore allow an implementation to select any value that can be represented in 32 bits other than zero and 0xFFFFFFFF. You note in your letter that "The RFC MIBs appear to imply that the range is restricted to a maximum value of 2147483647." This observation is further supported by the InterfaceIndex and InterfaceIndexOrZero textual convention defined in RFC 2863, both of which have a maximum value of 2147483647. Based on the above as well as the other MIBs you reference in your letter, it seems reasonable that an implementation will select values that can be fully represented in all MIBs that the implementation may support, i.e., up to 2147483647. That said, the choice of an unnumbered link identifier remains completely within the scope of an implementation and an implementation may choose to select larger values. Regards, Deborah Brungard and Lou Berger IETF CCAMP Working Group Co-Chairs From Lyong@Ciena.com Tue Jul 20 11:32:06 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BAE3A686C for ; Tue, 20 Jul 2010 11:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=3.219, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1irPvPap5Z-P for ; Tue, 20 Jul 2010 11:32:04 -0700 (PDT) Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 846223A67A7 for ; Tue, 20 Jul 2010 11:32:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:31:59 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901C29DDC@mdmxm03.ciena.com> In-Reply-To: <4C45EB01.7050606@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Response to OIF letter regarding Interface Identifier Thread-Index: AcsoOYUBQfRMRp8NQrCtCNZfRwEuFgAAAaHg References: <4C45EB01.7050606@labn.net> Importance: normal Priority: normal From: "Ong, Lyndon" To: "Lou Berger" , "Kimberly Chiu" , "CCAMP" Subject: Re: [CCAMP] Response to OIF letter regarding Interface Identifier X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:32:06 -0000 Dear Lou, Thanks very much to you and the CCAMP members for the response to our note, I will forward this to the OIF participants. We appreciate your effort to complete this in time for our current meeting. Best regards, Lyndon Ong -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, July 20, 2010 11:29 AM To: Kimberly Chiu; Ong, Lyndon; CCAMP Subject: Response to OIF letter regarding Interface Identifier Dear Mr. Ong, Thank you for your letter regarding Interface Identifier dated May 21,=20 2010. The letter referenced several RFCs only some of which are=20 products of the CCAMP working group. (RFC4202 and RFC4631 are products=20 of CCAMP, while RFC3477, RFC3811, RFC4220 are products of MPLS.) In the letter you ask about the range of values allowed for an=20 unnumbered link identifier. RFC 4202 (and RFC 3477) define an=20 unnumbered link being identified by a "non-zero 32-bit number that is=20 unique within the scope of the LSR". RFC4203 and RFC4205 contain=20 parallel language. RFC4201 effectively adds an additional restriction=20 by introducing special semantics for the value 0xFFFFFFFF. These=20 documents therefore allow an implementation to select any value that can be represented in 32 bits other than zero and 0xFFFFFFFF. You note in your letter that "The RFC MIBs appear to imply that the=20 range is restricted to a maximum value of 2147483647." This observation is further supported by the InterfaceIndex and InterfaceIndexOrZero=20 textual convention defined in RFC 2863, both of which have a maximum=20 value of 2147483647. Based on the above as well as the other MIBs you reference in your=20 letter, it seems reasonable that an implementation will select values=20 that can be fully represented in all MIBs that the implementation may=20 support, i.e., up to 2147483647. That said, the choice of an unnumbered link identifier remains completely within the scope of an implementation and an implementation may choose to select larger values. Regards, Deborah Brungard and Lou Berger IETF CCAMP Working Group Co-Chairs From jdrake@juniper.net Tue Jul 20 11:33:25 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519B93A6C7E for ; Tue, 20 Jul 2010 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.705 X-Spam-Level: X-Spam-Status: No, score=-5.705 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N875kVy3UIAH for ; Tue, 20 Jul 2010 11:33:20 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id A59643A687D for ; Tue, 20 Jul 2010 11:32:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXrzvKiU9Ii+M6beZRanuuE91UMumi6@postini.com; Tue, 20 Jul 2010 11:33:30 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Jul 2010 11:27:01 -0700 From: John E Drake To: Igor Bryskin , Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 11:26:59 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAADrhiAAAUKmgAABzojgAAHqoyAAAJjlgA== Message-ID: <5E893DB832F57341992548CDBB333163984487C6FA@EMBX01-HQ.jnpr.net> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C383@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7615A@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7615A@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:33:25 -0000 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 11:02 AM > To: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > You seem to have missed the first point in my email, regarding what is > actually advertised. > IB>> I always do :=3D) On the other hand you seem not to get about > everything that I am saying. > > Wrt your proposed solution, it won't work because there is no > constraint requiring different ISC TLVs to use a common bandwidth pool. > > IB>> If a TE link advertising contains, say, 2 ISCDs, and a single > unreserved bandwidth sub-TLV, how would you interpret this advertising > other than the two sharing the common pool? JD: The advertisement of the two ISCDs is independent and dynamic, and if = the independent bandwidth pool for one of them became depleted, it would be= withdrawn. The advertised unreserved bandwidth is computed by a node according to some= unspecified function. This actually points out another problem with putti= ng much credence in the advertised unreserved bandwidth; viz, there are not= even guidelines, let alone rules, for what is advertised. In your example, if the two ISCDs used independent bandwidth pools, the adv= ertised unreserved bandwidth could equally well be the min, max, sum, or so= me other function of the unreserved bandwidth in the two pools. > > Further, if they did share a common bandwidth pool, then at any point > in time the unreserved bandwidth is available to all of them. > > IB>> What if the user preference/policy is to partition the common pool > in a certain way so that the bandwidth fragmentation (as Snigdho > correctly pointed out) could be avoided? JD: As always, you argue backwards from your proposed solution to a percei= ved requirement. As I explained above, today's encodings already cover this case, unless one= wants to attempt to improve the accuracy of the advertised unreserved band= width. This is the point for which I have yet to be convinced, for reasons= that I pointed out in my email to Curtis. (In your example above, the common bandwidth pool is partitioned between th= e two ISCDs and then each is managed independently.) In order to do this and to allow any combination of shared and independent = bandwidth pools between advertised ISCDs, I think a generalization of the s= cheme being proposed for OTN should be used. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Tuesday, July 20, 2010 9:16 AM > > To: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However > if > > a TE link advertises more than one ISCD (with each ISCD containing > only > > max lsp bandwidth per priority), it is necessary to indicate how the > > total link unreserved bandwidth is partitioned between several ISCDs. > > What I am suggesting is instead of advertising the unreserved > bandwidth > > multiple times (one per ISCD), indicate how the bandwidth is split > > between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > > > Igor. > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue > > of partitioning unreserved bandwidth across multiple advertised TDM > ISC > > TLVs is actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the > > MPLS sub-TLV. My point has been that we have never had a requirement > > (including SDH/SONET) in the past to advertise unreserved bandwidth > by > > signal type, so what is special about OTN? > > > > A further point would be that if we do decide that it is necessary to > > advertise unreserved bandwidth by signal type, it should be done in a > > general way and not in an OTN specific manner. (And in fact, the > > arguments that unreserved bandwidth by signal type needs to be > > advertised, such as the latest e-mail from Curtis, are not OTN > > specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > All you need is a way to say how the advertised unreserved > bandwidth > > is > > > partitioned between ISCDs in case the TE link advertisement > contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits > > out > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising > unreserved > > > resources per priority, this leads not to know how many LSPs of > a > > > specific signal type can be restored. As example it is possible > > to > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on > > the > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a > MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. > > In > > > more complex network scenarios the number of crank-backs can be > > much > > > higher." > > > > > > In other words, advertising the number of availble resources per > > signal > > > type does not avoid the possibility of cranck-back but decreases it > > as > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. > The > > > cranck-backs due to the concurrent restoration of LSPs originating > on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=EC 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > > This > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth > > subTLV). > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > IB>> role per (muxCap & signal type) per priority level. However, > > total > > > IB>> unreserved bandwidth IMO is OK to share between roles unless > you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: luned=EC 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap =3D role; > > > > > encodeType =3D muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific > info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, > > but > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you > > wouldn't > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP > > (e.g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text > to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The > role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the > > [draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The > role > > is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that > > may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > > only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > role > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > conneciton will be allowed to be created. However, it should > not > > be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and > B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through > > B11 > > > > and > > > > > B12. If one circumvents the path computation by providing the > > fully > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators > > can > > > > > define different roles depending on their policy and achieve > the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > > the > > > > > network as a stack of topologies. Whether a given topology is > > real > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP- > > >OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > > of > > > > > topologies that could be easily separated in technology > > independent > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop > > (as > > > > > some people seem to believe). The role is only meaningful on > the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the > same > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > use > > > > > the topology rather than any resources available on OTN > network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as > > the > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy= , > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > > as > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > > case, > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > > ODU > > > > > terminating nodes (i.e. on either side of corresponding link). > > What > > > > > happens on the ODU transit nodes and its place in the hierarchy > > on > > > > the > > > > > transit nodes are of no importance. My LO container can be > > carried > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > > its > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" > ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities > > can > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD > is > > > > > required); 4. The combination of swicthcaps and encoding type > > will > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre- > > configured > > > > > topology with a specific role (e.g. constrain all ODUs it sells > > to > > > > the > > > > > clients to one or more pre-configured LO topologies), this > would > > be > > > > > possible to do in a technology independent way. Suppose an > > instance > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO > > OTN > > > > > links will be no different from the separation of WDM links > from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > > the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which > > had > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long > > time > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > > not > > > > > understand what the TS type meant did not try to multiplex its > LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO > > or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can > be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > LSP > > > > > regardless of what goes on in the middle since that determines > > what > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3D3 -------------- > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or > ODUj=3Dflex > > > > > even though the ODUk=3D2 at the next hop could not directly > contain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two > > levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > > Switch > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either > one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > > this > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > > sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, > > > > > or other intent. Could someone (either draft) concisely > > summarize > > > > > the multiplexing restrictions in one place, including > > restrictions > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the > framework > > > > > > > document before we can embark on any proposals to the > > problem. > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to > invent > > an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, > > one > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal > described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > > more > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > > for > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on > TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating > cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., > > simply > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as > > FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as > a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how > to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there > > progress > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on > > the > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach > > specified > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the > > available > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances > > or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general > > approach > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The > > additional > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence > > will > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> CCAMP mailing list > > > > > > > >> CCAMP@ietf.org > > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > CCAMP mailing list > > > > > > > > CCAMP@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Tue Jul 20 11:39:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77B13A6803 for ; Tue, 20 Jul 2010 11:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+WuaMiv0Ene for ; Tue, 20 Jul 2010 11:39:15 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 9AC033A67AC for ; Tue, 20 Jul 2010 11:39:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTEXtXhdSl0aJcTqGmRyxqks9j/W7GSFp@postini.com; Tue, 20 Jul 2010 11:39:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 20 Jul 2010 11:38:07 -0700 From: John E Drake To: Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" Date: Tue, 20 Jul 2010 11:38:06 -0700 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzAAAl3rYAAASqfwAAJNwHAAAHKIcA== Message-ID: <5E893DB832F57341992548CDBB333163984487C76F@EMBX01-HQ.jnpr.net> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C427@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:39:17 -0000 Igor, The unreserved bandwidth advertised in the MPLS sub-TLV is there to provide= a hint, nothing more, and you seemed quite happy with this in the e-mail y= ou sent to Sergio. So why do you now perceive it to be an issue? It's not clear to me that advertising unreserved bandwidth by signal type a= ctually provides the improvement in accuracy that people claim for it, and = it does come with a cost, more bandwidth and more message processing. However, if that's what folks want, then it should be done in a general, ra= ther than an OTN specific, manner. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 11:21 AM > To: John E Drake; BELOTTI, SERGIO (SERGIO) > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > John, >=20 > The point is that from ISCD you can not figure out how *many* LSPs > matching the ISCD you can accommodate on the link. Such information is > important in case of con-current routing (e.g. restoration after link > failure). >=20 > Igor >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > From RFC 4202: >=20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority > p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. >=20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. >=20 > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > Bandwidth are enumerated in [GMPLS-SIG]. >=20 > On an interface having Standard SDH multiplexing, an LSP at priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. >=20 > On an interface having Arbitrary SDH multiplexing, an LSP at > priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. >=20 > From RFC 4201: >=20 > 3.10. Maximum LSP Bandwidth >=20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP Bandwidth > at priority p of all of its component links. >=20 >=20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > Snipped.... > > > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > > > > JD: As the person to whom I believe you are referring, I would > suggest > > that you actually read RFC 4202 and 4206. From IBryskin@advaoptical.com Tue Jul 20 11:51:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FB33A6BF7 for ; Tue, 20 Jul 2010 11:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxirIJsg-4xB for ; Tue, 20 Jul 2010 11:51:01 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 82BEC3A691B for ; Tue, 20 Jul 2010 11:50:59 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KIp6Fi005318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 20:51:06 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 20:51:06 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 20:51:06 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 14:51:03 -0400 From: Igor Bryskin To: John E Drake , Daniele Ceccarelli , Snigdho Bardalai , Fatai Zhang , "curtis@occnc.com" Date: Tue, 20 Jul 2010 14:51:00 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAADrhiAAAUKmgAABzojgAAHqoyAAAJjlgAABFvag Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7618B@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C124@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C383@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7615A@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C6FA@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487C6FA@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_07:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:51:05 -0000 > > Wrt your proposed solution, it won't work because there is no > constraint requiring different ISC TLVs to use a common bandwidth pool. > > IB>> If a TE link advertising contains, say, 2 ISCDs, and a single > unreserved bandwidth sub-TLV, how would you interpret this advertising > other than the two sharing the common pool? JD: The advertisement of the two ISCDs is independent and dynamic, and if = the independent bandwidth pool for one of them became depleted, it would be= withdrawn. IB>> ... unless you have a policy that *administratively* partitions the po= ol in certain way. In such case allocation requests for one ISDC will fail = even when the bandwidth is still available. For example, LO and HO ODU2s ma= y share the same pool, but the operator may want that 75% of the pool to be= available for HO and 25% for LO. The advertised unreserved bandwidth is computed by a node according to some= unspecified function. This actually points out another problem with putti= ng much credence in the advertised unreserved bandwidth; viz, there are not= even guidelines, let alone rules, for what is advertised. IB>> No problem here. It is a simple matter of local discovery and policy (= e.g. via configuration) In your example, if the two ISCDs used independent bandwidth pools, the adv= ertised unreserved bandwidth could equally well be the min, max, sum, or so= me other function of the unreserved bandwidth in the two pools. IB>> I never said independent. It is shared but administratively partitione= d. > > Further, if they did share a common bandwidth pool, then at any point > in time the unreserved bandwidth is available to all of them. > > IB>> What if the user preference/policy is to partition the common pool > in a certain way so that the bandwidth fragmentation (as Snigdho > correctly pointed out) could be avoided? JD: As always, you argue backwards from your proposed solution to a percei= ved requirement. As I explained above, today's encodings already cover this case, unless one= wants to attempt to improve the accuracy of the advertised unreserved band= width. This is the point for which I have yet to be convinced, for reasons= that I pointed out in my email to Curtis. (In your example above, the common bandwidth pool is partitioned between th= e two ISCDs and then each is managed independently.) In order to do this and to allow any combination of shared and independent = bandwidth pools between advertised ISCDs, I think a generalization of the s= cheme being proposed for OTN should be used. IB>> But why is it OTN matter? It is a generic issue of several ISCDs adver= tised for a single link. > > Thanks, > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Tuesday, July 20, 2010 9:16 AM > > To: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However > if > > a TE link advertises more than one ISCD (with each ISCD containing > only > > max lsp bandwidth per priority), it is necessary to indicate how the > > total link unreserved bandwidth is partitioned between several ISCDs. > > What I am suggesting is instead of advertising the unreserved > bandwidth > > multiple times (one per ISCD), indicate how the bandwidth is split > > between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > > > Igor. > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue > > of partitioning unreserved bandwidth across multiple advertised TDM > ISC > > TLVs is actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the > > MPLS sub-TLV. My point has been that we have never had a requirement > > (including SDH/SONET) in the past to advertise unreserved bandwidth > by > > signal type, so what is special about OTN? > > > > A further point would be that if we do decide that it is necessary to > > advertise unreserved bandwidth by signal type, it should be done in a > > general way and not in an OTN specific manner. (And in fact, the > > arguments that unreserved bandwidth by signal type needs to be > > advertised, such as the latest e-mail from Curtis, are not OTN > > specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > All you need is a way to say how the advertised unreserved > bandwidth > > is > > > partitioned between ISCDs in case the TE link advertisement > contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits > > out > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising > unreserved > > > resources per priority, this leads not to know how many LSPs of > a > > > specific signal type can be restored. As example it is possible > > to > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on > > the > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a > MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. > > In > > > more complex network scenarios the number of crank-backs can be > > much > > > higher." > > > > > > In other words, advertising the number of availble resources per > > signal > > > type does not avoid the possibility of cranck-back but decreases it > > as > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. > The > > > cranck-backs due to the concurrent restoration of LSPs originating > on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=EC 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > > This > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth > > subTLV). > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > IB>> role per (muxCap & signal type) per priority level. However, > > total > > > IB>> unreserved bandwidth IMO is OK to share between roles unless > you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: luned=EC 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap =3D role; > > > > > encodeType =3D muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific > info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, > > but > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you > > wouldn't > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP > > (e.g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text > to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The > role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the > > [draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The > role > > is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that > > may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > > only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > role > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > conneciton will be allowed to be created. However, it should > not > > be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and > B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through > > B11 > > > > and > > > > > B12. If one circumvents the path computation by providing the > > fully > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators > > can > > > > > define different roles depending on their policy and achieve > the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > > the > > > > > network as a stack of topologies. Whether a given topology is > > real > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP- > > >OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > > of > > > > > topologies that could be easily separated in technology > > independent > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop > > (as > > > > > some people seem to believe). The role is only meaningful on > the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the > same > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > use > > > > > the topology rather than any resources available on OTN > network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as > > the > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy= , > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > > as > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > > case, > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > > ODU > > > > > terminating nodes (i.e. on either side of corresponding link). > > What > > > > > happens on the ODU transit nodes and its place in the hierarchy > > on > > > > the > > > > > transit nodes are of no importance. My LO container can be > > carried > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > > its > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" > ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities > > can > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD > is > > > > > required); 4. The combination of swicthcaps and encoding type > > will > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre- > > configured > > > > > topology with a specific role (e.g. constrain all ODUs it sells > > to > > > > the > > > > > clients to one or more pre-configured LO topologies), this > would > > be > > > > > possible to do in a technology independent way. Suppose an > > instance > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO > > OTN > > > > > links will be no different from the separation of WDM links > from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > > the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which > > had > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long > > time > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > > not > > > > > understand what the TS type meant did not try to multiplex its > LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO > > or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can > be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > LSP > > > > > regardless of what goes on in the middle since that determines > > what > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3D3 -------------- > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or > ODUj=3Dflex > > > > > even though the ODUk=3D2 at the next hop could not directly > contain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two > > levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > > Switch > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either > one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > > this > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > > sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, > > > > > or other intent. Could someone (either draft) concisely > > summarize > > > > > the multiplexing restrictions in one place, including > > restrictions > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the > framework > > > > > > > document before we can embark on any proposals to the > > problem. > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to > invent > > an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, > > one > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal > described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > > more > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > > for > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on > TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating > cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., > > simply > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as > > FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as > a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how > to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there > > progress > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on > > the > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach > > specified > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the > > available > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances > > or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general > > approach > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The > > additional > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence > > will > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> CCAMP mailing list > > > > > > > >> CCAMP@ietf.org > > > > > > > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > CCAMP mailing list > > > > > > > > CCAMP@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > CCAMP mailing list > > > > > > CCAMP@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > _______________________________________________ > > > > > CCAMP mailing list > > > > > CCAMP@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Tue Jul 20 11:57:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0BB3A6868 for ; Tue, 20 Jul 2010 11:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGVpCbbGqw6u for ; Tue, 20 Jul 2010 11:56:58 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 271C03A6803 for ; Tue, 20 Jul 2010 11:56:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KIv2lS066189; Tue, 20 Jul 2010 14:57:02 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007201857.o6KIv2lS066189@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 11:21:13 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> Date: Tue, 20 Jul 2010 14:57:02 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:57:01 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > It is a valid point, but the suggested solution is way too > expensive. All you need is a way to say how the advertised unreserved > bandwidth is partitioned between ISCDs in case the TE link > advertisement contains several of them. One cheap way of doing so is > to allocate 3-4 bits out of the ISCD sub-TLV reserved bits to indicate > the fraction of total unreserved bandwidth associated with the > ISCD. Another way is to use swicthcap specific extension. BTW: this > is not an OTN specific issue, rather more general: any time when a TE > link advertises more than one ISCD (which is perfectly Ok according to > 4203) you'll have the same problem. > > Igor Igor, Perhaps at the meeting we can try to agree as to whether minimizing unecessary crankback is a goal or not. It has always been a goal in the past. Also when a link advertises more than one ISCD it means it can accept a reservation (ie: LSP) using any of them. That is what I get out of the examples in RFC4202. The examples are LSC+TDM, OXC+TDM, PWC+LSR, TDM+LSR. For example, in TDM+LSR, it should be possible to set up a TDM LSP from an adjacent TDM only LSR or a PSC LSP from a PSC only LSR, or either type from an adjacent TDM+LSR device. Do you interpret this differently? Curtis > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 10:57 AM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Igor, > > The need for unreserved resources advertised per signal type is the concurrent path computation. I'll answer quoting a section from the info-model draft, please have a look in particular to the example: > > > " Unreserved resources need to be advertised per priority and per > signal type in order to allow the correct functioning of the > restoration process. [RFC4203] only allows advertising unreserved > resources per priority, this leads not to know how many LSPs of a > specific signal type can be restored. As example it is possible to > consider the scenario depicted in the following figure. > > +------+ component link 1 +------+ > | +------------------+ | > | | component link 2 | | > | N1 +------------------+ N2 | > | | component link 3 | | > | +------------------+ | > +------+ +---+--+ > > Suppose to have a TE link comprising 3 ODU3 component links with > 32TSs available on the first one, 24TSs on the second, 24TSs on the > third and supporting ODU2 and ODU3 signal types. The node would > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > LSP bandwidth equal to 32 TSs. In case of restoration the network > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > single ODU3 can be set up and a crank-back would be originated. In > more complex network scenarios the number of crank-backs can be much > higher." > > In other words, advertising the number of availble resources per signal type does not avoid the possibility of cranck-back but decreases it as much as possible. For sure a good routing prevents from crank-backs caused by the restoration of LSP originating on the same Ingress. The cranck-backs due to the concurrent restoration of LSPs originating on different ingress nodes cannot be avoided. > > BR > Daniele > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: martedì 20 luglio 2010 16.16 > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > In line > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 4:32 AM > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Igor, one more question. > > What about the unreserved bandwidth? > If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCap & signal type) you also need to advertise the unreserved bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This also implies extending the unreserved bandwidth TLV so to create a corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > IB>> role per (muxCap & signal type) per priority level. However, total > IB>> unreserved bandwidth IMO is OK to share between roles unless you > IB>> see a compelling reason to the contrary (which I don't) > > Igor > > Thanks > Daniele > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: lunedì 19 luglio 2010 17.48 > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Understood... > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 8:46 AM > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient > > > > That's exactly what I've been > > trying to say all along. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Monday, July 19, 2010 11:31 AM > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor > > > > Please see inline. > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 7:43 AM > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Daniele, > > > > > > Please, see in line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Monday, July 19, 2010 10:31 AM > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > > > IB>> in ISCD: > > > switchCap = role; > > > encodeType = muxCap & signal type; > > > We also have 16 reserved bits which can use for OTN specific info in > > > case we need it. > > [SCB] I am yet to clearly understand what the role of "role" is, but > > agree with your observation on the encode-type and the 16 > > reserved-bits to further classify the switching information. > > > > > > In case (a) you're still missing a lot of information. For each role > > > you would advertise just the unreserved bandwidth but you wouldn't > > know > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > 15 > > > Gbps available on 3 component links: you advertise 45 Gbps available > > > but no ODU3 can be set up on such TE link). > > > > > > In case (b) the number of ISCDs would cause serious scalability > > issues > > > and the requirement of being able to bundle component links together > > > wouldn't be satisfied. > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > > provide a lot of flexibility: you can specify different things (e.g. > > > available bandwidth) for the same link in different roles. > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient? > > > > > > Cheers, > > > Daniele > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: lunedì 19 luglio 2010 15.40 > > > To: Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Fatai, > > > > > > Please, see my responses on-line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Fatai Zhang > > > Sent: Sunday, July 18, 2010 10:49 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > Thanks. > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't > > > think that we need to extend ISC to meet the requirment. The role of > > > the > > ODU > > > can be get from the routing information implicitly. In the [draft- > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > > is > > > introduced. > > > > > > IB>> This is possible, however: > > > a) this requires OTN specific advertising and processing rules; > > > b) disallows topology separation in technology independent way > > > > > > A quick question on your statement: "the role of an ODU container > > does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on > > transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE > > > links will > > be > > > disallowed, and the resulting path (if any) will not go through B11 > > and > > > B12. If one circumvents the path computation by providing the fully > > > explicit path, the signaling should fail on node B for the same > > reason: > > > inconsistency of required (signaled) and supported (by local > > > interfaces) switchcap. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > IB>> Indeed > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Lou Berger" ; > > > ; > > framework@tools.ietf.org> > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > draft- > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can > > > define different roles depending on their policy and achieve the > > > role through different methods. However, for OTN networks, the > > > containers (e.g., ODUk) all have the same switching capablility > > > (i.e., TDM > > > switching) and I think we should reflect the natural characteristics > > of > > > links in the routing. In addition, if we extend the ISC, it will > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > encoding type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > network as a stack of topologies. Whether a given topology is real > > > or virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > capability field (confusing name as it is) is a good way to describe > > a > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > topologies that could be easily separated in technology independent > > way > > > should path computation be constrained to particular one or > > > sub-stack of them. > > > I think a good way to identify an OTN (virtual) topology is via > > > (infrastructure) ODU container role of ODUs comprising the topology. > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > some people seem to believe). The role is only meaningful on the ODU > > > terminating nodes and irrelevant on transit nodes. It is it's > > position > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > role > > > is the level of topology it is provisioned for and it is the same > > > for all ODUs that comprise the topology. For, example a user may > > provision > > > a LO topology and constrain ODUs he sells to a set of clients to use > > > the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of virtual > > > topology the container is a part of and could be advertised as the > > > corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles > > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type = mux. capabilities code > > > > > > In addition, could you clarify my questions in another email (copied > > as > > > follows): > > > > > ====================================================================== > > = > > > ============================= > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role == position in the hierarchy, which > > is > > > a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > > link > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > over > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > how > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > terminating nodes (i.e. on either side of corresponding link). What > > > happens on the ODU transit nodes and its place in the hierarchy on > > the > > > transit nodes are of no importance. My LO container can be carried > > > by somebody else's LO container and can carry my client's LO container. > > To > > > some extent it is similar to MPLS LSP role: LSP always has a role > > (e.g. > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > path. > > > > > > Cheers, > > > Igor > > > > > > > > ====================================================================== > > = > > > ============================ > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Fatai Zhang" ; > > > "Lou Berger" ; ; > > > > gmpls- > > > g709-framework@tools.ietf.org> > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types > > > introduced. But IMO they should indicate the link's mux capabilities > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > with a separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; 2. > > > Link may advertise several roles (e.g. HO and SHO) with different > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > be > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > required); 4. The combination of swicthcaps and encoding type will > > look > > > to CP as a separate layer, which is exactly how ITU models OTN > > > hierarchies in all aspects but routing (!?) 5. If the operator would > > > want to constrain the routing of OTN connections to pre-configured > > > topology with a specific role (e.g. constrain all ODUs it sells to > > the > > > clients to one or more pre-configured LO topologies), this would be > > > possible to do in a technology independent way. Suppose an instance > > of > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > links will be no different from the separation of WDM links from > > OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ /*****/ > > > > , LSPSwitchType_LSC =150 /* LSC */ > > > > , LSPSwitchType_FSC =200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > > using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > latter > > > is for backward compatibility and should be ignored if OTN_LO, > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > granularity, then the corresponding G.709 Digital Path FA can be withdrawn. > > > > > > The Encoding type would be the lower encoding at each end of the LSP > > > regardless of what goes on in the middle since that determines what > > can > > > be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3 -------------- > > > OTU1 ODUk=2 -- ODUj=2 > > > ODUk=1 --- ODUj=1 -- > > > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex > > > even though the ODUk=2 at the next hop could not directly contain an ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels > > of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > ODU-flex, and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one > > yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other than > > a > > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > or other intent. Could someone (either draft) concisely summarize > > > the multiplexing restrictions in one place, including restrictions > > > on number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > Behalf Of Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework > > > > > document before we can embark on any proposals to the problem. I > > am > > > > > still not clear why do we have to deviate from the general > > approach > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > IB>> plane, and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > > > of advertising of TE links, and there is no reason to invent an > > OTN > > > > > specific ISCD. The combination of Switching Capability and > > Encoding > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > >TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > > IB>> OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > other interested experts, and we think the proposal described in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > control plane, no matter how you encode the routing information. > > > For > > > > > TDM networks, you know the resource is allocated based on TS, so > > > the > > > > > available TS should be get or induced before creating cross- > > > connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > > I > > > > > think you need go to the routing drafts (info model and > > encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > container instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; > > > > > > draft-ietf-ccamp-gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > > > one of the main objectives of *C*CAMP. I look forward to > > hearing > > > > > > from the draft and discussion contributors on there progress > > > > > > on > > > this point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > > >> routing purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order > > > > > >> ODUj availability within a higher-order container. For > > > > > >> example, consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > >> then > > > we > > > > > >> establish an ODU2 service over the link. At this point in > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > >> services > > and > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > >> example > > > that > > > > > >> the number of time-slots available is different based on the > > > signal-type (i.e. ODU1 and ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > > >> the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > the > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > >> approach seems to be more in-line with the general approach > > > > > >> outlined in RFC-4202. Refer to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > >> benefit > > > is > > > > > >> that the advertisement is TS size independent and hence will > > > > > >> simplify the implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 12:02:02 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DBB3A6768 for ; Tue, 20 Jul 2010 12:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHjPFkUtuUFC for ; Tue, 20 Jul 2010 12:02:00 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 5CAB93A68BC for ; Tue, 20 Jul 2010 12:01:59 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KJ2Bau020471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 21:02:11 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 21:02:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 21:02:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 15:02:08 -0400 From: Igor Bryskin To: John E Drake , "BELOTTI, SERGIO (SERGIO)" Date: Tue, 20 Jul 2010 15:02:06 -0400 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acsm7PtShpxlGT8CQjSif4GI/BmqKwAVij6wAAJxrOAAAJr4AAABw6OgAACpx0AAACF+oAAi35SQAAulVmAAAcyBIAAATBQgAAHzDzAAAl3rYAAASqfwAAJNwHAAAHKIcAAAw+MA Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76194@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Thu, 08 Jul 2010 14:31:02 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com><201007132223.o6DMNXRc018986@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75676@atl-srv-exgen.atl.advaoptical.com><084e01cb23c0$61b58490$514c460a@china.huawei.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D759A8@atl-srv-exgen.atl.advaoptical.com><0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75D98@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75DEE@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FA5@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D75E40@atl-srv-exgen.atl.advaoptical.com> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE6FB0@SV-EXDB1.infinera.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C 0D7607D@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C427@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487C76F@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487C76F@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_07:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:02:02 -0000 John, >The unreserved bandwidth advertised in the MPLS sub-TLV is there to provid= e a hint, > nothing more, and you seemed quite happy with this in the e-mai= l you sent to >Sergio. So why do you now perceive it to be an issue? IB>> Because there are cases when you need to know how many LSPs of certain= type can be placed on a link. 4203 needs an enhancement to allow for this = IMO. >It's not clear to me that advertising unreserved bandwidth by signal type = actually >provides the improvement in accuracy that people claim for it, an= d it does come with >a cost, more bandwidth and more message processing. IB>> From my personal experience the overhead is negligible. =20 >However, if that's what folks want, then it should be done in a general, r= ather than >an OTN specific, manner. IB>> Exactly my point. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 11:21 AM > To: John E Drake; BELOTTI, SERGIO (SERGIO) > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > John, >=20 > The point is that from ISCD you can not figure out how *many* LSPs > matching the ISCD you can accommodate on the link. Such information is > important in case of con-current routing (e.g. restoration after link > failure). >=20 > Igor >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > From RFC 4202: >=20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority > p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. >=20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. >=20 > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > Bandwidth are enumerated in [GMPLS-SIG]. >=20 > On an interface having Standard SDH multiplexing, an LSP at priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. >=20 > On an interface having Arbitrary SDH multiplexing, an LSP at > priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. >=20 > From RFC 4201: >=20 > 3.10. Maximum LSP Bandwidth >=20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP Bandwidth > at priority p of all of its component links. >=20 >=20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > Snipped.... > > > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > > > > JD: As the person to whom I believe you are referring, I would > suggest > > that you actually read RFC 4202 and 4206. From curtis@occnc.com Tue Jul 20 12:03:43 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5381B3A686E for ; Tue, 20 Jul 2010 12:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uobUAUFnJkF for ; Tue, 20 Jul 2010 12:03:39 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 12E7A3A6768 for ; Tue, 20 Jul 2010 12:03:35 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KJ3QGd066313; Tue, 20 Jul 2010 15:03:26 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007201903.o6KJ3QGd066313@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 11:27:10 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760D1@atl-srv-exgen.atl.advaoptical.com> Date: Tue, 20 Jul 2010 15:03:26 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:03:43 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760D1@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > Curtis, > > I agree with your concerns about cranbacks. I never liked solutions > that rely on crankbacks. But what I was saying is that path > computation in the described example will be able to figure that the > path is not feasible, hence the ingress node will know that without > signaling failure. > > Cheers and hope to see you in Maastricht. > Igor Igor, I don't follow that. Are you claiming that the PathErr is significantly different from crankback? Or did I miss something about the example? Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 10:52 AM > To: Fatai Zhang > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > Fatai Zhang writes: > > > > Hi Igor, > > > > Thanks. > > Sorry to jump in but I think I understand Igor's objection (and > Snigdho's objection, and the reason this thread is going on). > > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't think > > that we need to extend ISC to meet the requirment. The role of the ODU > > can be get from the routing information implicitly. In the > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" is introduced. > > > > A quick question on your statement: "the role of an ODU container does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > I think the objection, which would be a very valid one, is that the > ingress has no way to know apriori that a path is infeasible. Each > crankback delays convergence. Crankback should only occur if another > ingress has reserved resources before signaling was completed, not > because inadequate routing information is provided in quiescent state. > > Curtis > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can define different roles depending on their policy and achieve the role through different methods. However, for OTN networks, the containers (e.g., ODUk) all have the same switching capablility (i.e., TDM switching) and I think we should reflect the natural characteristics of links in the routing. In addition, if we extend the ISC, it will make the encoding type lose its' own meaning(ie., ISC overrides encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the network as a stack of topologies. Whether a given topology is real or virtual is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching capability field (confusing name as it is) is a good way to describe a layer in technology independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of topologies that could be easily separated in technology independent way should path computation be constrained to particular one or sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via (infrastructure) ODU container role of ODUs comprising the topology. BTW IMO the role of an ODU container does not change hop-by-hop (as some people seem to believe). The role is only meaningful on the ODU terminating nodes and irrelevant on transit nodes. It is it's position in the hierarchy (but not role) that may change hop-by-hop. ODU's role is the level of topology it is provisioned for and it is the same for all ODUs that comprise the topology. For, example a user may provision a LO topology and constrain ODUs he sells to a set of clients to use the topology rather than any resources available on OTN network. > > The bottom line: container's role is the same as the role of virtual topology the container is a part of and could be advertised as the corresponding link switchcap. > > > > According to the point 3, I don't know how to advertise the roles and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type = mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied as follows): > > ==================================================================================================== > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role == position in the hierarchy, which is a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU terminating nodes (i.e. on either side of corresponding link). What happens on the ODU transit nodes and its place in the hierarchy on the transit nodes are of no importance. My LO container can be carried by somebody else's LO container and can carry my client's LO container. To some extent it is similar to MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its path. > > > > Cheers, > > Igor > > > > =================================================================================================== > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types introduced. But IMO they should indicate the link's mux capabilities rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link's role or roles IMO should be indicated with a separate switchcaps. I can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; > > 2. Link may advertise several roles (e.g. HO and SHO) with different mux.capabilities per role; > > 3. Link's role and mux. capabilities can be advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is required); > > 4. The combination of swicthcaps and encoding type will look to CP as a separate layer, which is exactly how ITU models OTN hierarchies in all aspects but routing (!?) > > 5. If the operator would want to constrain the routing of OTN connections to pre-configured topology with a specific role (e.g. constrain all ODUs it sells to the clients to one or more pre-configured LO topologies), this would be possible to do in a technology independent way. Suppose an instance of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links will be no different from the separation of WDM links from OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the depth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =150 /* LSC */ > > > , LSPSwitchType_FSC =200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO ODU > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > > can be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3 -------------- > > OTU1 ODUk=2 -- ODUj=2 > > ODUk=1 --- ODUj=1 -- > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even > > though the ODUk=2 at the next hop could not directly contain an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along with > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > other intent. Could someone (either draft) concisely summarize the > > multiplexing restrictions in one place, including restrictions on > > number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework document > > > > before we can embark on any proposals to the problem. I am still not clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > > > > it is highly desirable to adhere to the layer independent paradigm of > > > > advertising of TE links, and there is no reason to invent an OTN specific > > > > ISCD. The combination of Switching Capability and Encoding type of RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > > represent >the low-order ODUj bandwidth within the high-order containers. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > > > hierarchies and constrain LO connections to HO containers, one needs to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for control > > > > plane, no matter how you encode the routing information. For TDM networks, > > > > you know the resource is allocated based on TS, so the available TS should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > > > > you have to advertise a new TE link or put this FA as a component link of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to better > > > > > align the work with 4202. Use of common approaches is of course one of > > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > > draft and discussion contributors on there progress on this point. > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, consider an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > > >> establish an ODU2 service over the link. At this point in time the OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained over the > > > > >> ODU2). So it is obvious from this example that the number of time-slots > > > > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > > > > >> How do we address this issue based on the approach specified in the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available number of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit is that > > > > >> the advertisement is TS size independent and hence will simplify the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 12:10:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFB83A682A for ; Tue, 20 Jul 2010 12:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJauxD6KX+d3 for ; Tue, 20 Jul 2010 12:10:25 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 0F6333A68A2 for ; Tue, 20 Jul 2010 12:10:24 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KJAY7s031109 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 21:10:34 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 21:10:34 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 15:10:31 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Tue, 20 Jul 2010 15:10:29 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoPVp0jHclbtO5Qc6n8lYHyZqzUQAAL6HQ Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76198@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 11:21:13 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760C9@atl-srv-exgen.atl.advaoptical.com> <201007201857.o6KIv2lS066189@harbor.orleans.occnc.com> In-Reply-To: <201007201857.o6KIv2lS066189@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:10:29 -0000 Curtis, > > It is a valid point, but the suggested solution is way too > expensive. All you need is a way to say how the advertised unreserved > bandwidth is partitioned between ISCDs in case the TE link > advertisement contains several of them. One cheap way of doing so is > to allocate 3-4 bits out of the ISCD sub-TLV reserved bits to indicate > the fraction of total unreserved bandwidth associated with the > ISCD. Another way is to use swicthcap specific extension. BTW: this > is not an OTN specific issue, rather more general: any time when a TE > link advertises more than one ISCD (which is perfectly Ok according to > 4203) you'll have the same problem. > > Igor Perhaps at the meeting we can try to agree as to whether minimizing unecessary crankback is a goal or not. It has always been a goal in the past. IB>> I don't understand why do you keep bringing up crankbacks. None of wha= t I have said so far in this discussion will cause a crankback, quite to th= e contrary. Also when a link advertises more than one ISCD it means it can accept a reservation (ie: LSP) using any of them. That is what I get out of the examples in RFC4202. The examples are LSC+TDM, OXC+TDM, PWC+LSR, TDM+LSR. For example, in TDM+LSR, it should be possible to set up a TDM LSP from an adjacent TDM only LSR or a PSC LSP from a PSC only LSR, or either type from an adjacent TDM+LSR device. Do you interpret this differently? IB>> Correct. In the context of OTN if a link advertises two ISDCs: OTN_HO = and OTN_LO, it means it is willing to accept the setup of ODUs for any of t= he two roles. Igor Curtis > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 10:57 AM > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Igor, > > The need for unreserved resources advertised per signal type is the concu= rrent path computation. I'll answer quoting a section from the info-model d= raft, please have a look in particular to the example: > > > " Unreserved resources need to be advertised per priority and per > signal type in order to allow the correct functioning of the > restoration process. [RFC4203] only allows advertising unreserved > resources per priority, this leads not to know how many LSPs of a > specific signal type can be restored. As example it is possible to > consider the scenario depicted in the following figure. > > +------+ component link 1 +------+ > | +------------------+ | > | | component link 2 | | > | N1 +------------------+ N2 | > | | component link 3 | | > | +------------------+ | > +------+ +---+--+ > > Suppose to have a TE link comprising 3 ODU3 component links with > 32TSs available on the first one, 24TSs on the second, 24TSs on the > third and supporting ODU2 and ODU3 signal types. The node would > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > LSP bandwidth equal to 32 TSs. In case of restoration the network > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > single ODU3 can be set up and a crank-back would be originated. In > more complex network scenarios the number of crank-backs can be much > higher." > > In other words, advertising the number of availble resources per signal t= ype does not avoid the possibility of cranck-back but decreases it as much = as possible. For sure a good routing prevents from crank-backs caused by th= e restoration of LSP originating on the same Ingress. The cranck-backs due = to the concurrent restoration of LSPs originating on different ingress node= s cannot be avoided. > > BR > Daniele > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: marted=EC 20 luglio 2010 16.16 > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > In line > > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Tuesday, July 20, 2010 4:32 AM > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Igor, one more question. > > What about the unreserved bandwidth? > If you're advertising the max lsp bandwidth by 1 ISCD per role per (muxCa= p & signal type) you also need to advertise the unreserved bandwidth using = 1 unreserved bandwidth sub-TLV per ISCD, correct? This also implies extendi= ng the unreserved bandwidth TLV so to create a corrispondence between the c= ouples (ISCD-unreserved bandwidth subTLV). > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > IB>> role per (muxCap & signal type) per priority level. However, total > IB>> unreserved bandwidth IMO is OK to share between roles unless you > IB>> see a compelling reason to the contrary (which I don't) > > Igor > > Thanks > Daniele > > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: luned=EC 19 luglio 2010 17.48 > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Understood... > > Regards > Snigdho > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Monday, July 19, 2010 8:46 AM > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient > > > > That's exactly what I've been > > trying to say all along. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: Monday, July 19, 2010 11:31 AM > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor > > > > Please see inline. > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 7:43 AM > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Daniele, > > > > > > Please, see in line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Monday, July 19, 2010 10:31 AM > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > I didn't understand if you're proposing to (a) send an ISCD per role > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal type. > > > > > > IB>> in ISCD: > > > switchCap =3D role; > > > encodeType =3D muxCap & signal type; > > > We also have 16 reserved bits which can use for OTN specific info in > > > case we need it. > > [SCB] I am yet to clearly understand what the role of "role" is, but > > agree with your observation on the encode-type and the 16 > > reserved-bits to further classify the switching information. > > > > > > In case (a) you're still missing a lot of information. For each role > > > you would advertise just the unreserved bandwidth but you wouldn't > > know > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > 15 > > > Gbps available on 3 component links: you advertise 45 Gbps available > > > but no ODU3 can be set up on such TE link). > > > > > > In case (b) the number of ISCDs would cause serious scalability > > issues > > > and the requirement of being able to bundle component links together > > > wouldn't be satisfied. > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs will > > > provide a lot of flexibility: you can specify different things (e.g. > > > available bandwidth) for the same link in different roles. > > [SCB] Are you saying the ISCD as defined today with minor extensions > > (i.e. to further classify the information) will be sufficient? > > > > > > Cheers, > > > Daniele > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Igor Bryskin > > > Sent: luned=EC 19 luglio 2010 15.40 > > > To: Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Fatai, > > > > > > Please, see my responses on-line. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Fatai Zhang > > > Sent: Sunday, July 18, 2010 10:49 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor, > > > > > > Thanks. > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't > > > think that we need to extend ISC to meet the requirment. The role of > > > the > > ODU > > > can be get from the routing information implicitly. In the [draft- > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full Lambda" > > is > > > introduced. > > > > > > IB>> This is possible, however: > > > a) this requires OTN specific advertising and processing rules; > > > b) disallows topology separation in technology independent way > > > > > > A quick question on your statement: "the role of an ODU container > > does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on > > transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link ends > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 TE > > > links will > > be > > > disallowed, and the resulting path (if any) will not go through B11 > > and > > > B12. If one circumvents the path computation by providing the fully > > > explicit path, the signaling should fail on node B for the same > > reason: > > > inconsistency of required (signaled) and supported (by local > > > interfaces) switchcap. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > IB>> Indeed > > > > > > > > > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Lou Berger" ; > > > ; > > framework@tools.ietf.org> > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > draft- > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can > > > define different roles depending on their policy and achieve the > > > role through different methods. However, for OTN networks, the > > > containers (e.g., ODUk) all have the same switching capablility > > > (i.e., TDM > > > switching) and I think we should reflect the natural characteristics > > of > > > links in the routing. In addition, if we extend the ISC, it will > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > encoding type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > network as a stack of topologies. Whether a given topology is real > > > or virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > capability field (confusing name as it is) is a good way to describe > > a > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > topologies that could be easily separated in technology independent > > way > > > should path computation be constrained to particular one or > > > sub-stack of them. > > > I think a good way to identify an OTN (virtual) topology is via > > > (infrastructure) ODU container role of ODUs comprising the topology. > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > some people seem to believe). The role is only meaningful on the ODU > > > terminating nodes and irrelevant on transit nodes. It is it's > > position > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > role > > > is the level of topology it is provisioned for and it is the same > > > for all ODUs that comprise the topology. For, example a user may > > provision > > > a LO topology and constrain ODUs he sells to a set of clients to use > > > the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of virtual > > > topology the container is a part of and could be advertised as the > > > corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles > > > and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type =3D mux. capabilities code > > > > > > In addition, could you clarify my questions in another email (copied > > as > > > follows): > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, wh= ich > > is > > > a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > > link > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > over > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > how > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > terminating nodes (i.e. on either side of corresponding link). What > > > happens on the ODU transit nodes and its place in the hierarchy on > > the > > > transit nodes are of no importance. My LO container can be carried > > > by somebody else's LO container and can carry my client's LO containe= r. > > To > > > some extent it is similar to MPLS LSP role: LSP always has a role > > (e.g. > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > path. > > > > > > Cheers, > > > Igor > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Fatai Zhang" ; > > > "Lou Berger" ; ; > > > > gmpls- > > > g709-framework@tools.ietf.org> > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types > > > introduced. But IMO they should indicate the link's mux capabilities > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > with a separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; 2. > > > Link may advertise several roles (e.g. HO and SHO) with different > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > be > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > required); 4. The combination of swicthcaps and encoding type will > > look > > > to CP as a separate layer, which is exactly how ITU models OTN > > > hierarchies in all aspects but routing (!?) 5. If the operator would > > > want to constrain the routing of OTN connections to pre-configured > > > topology with a specific role (e.g. constrain all ODUs it sells to > > the > > > clients to one or more pre-configured LO topologies), this would be > > > possible to do in a technology independent way. Suppose an instance > > of > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > links will be no different from the separation of WDM links from > > OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ /*****= / > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time a= go. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited to > > using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > latter > > > is for backward compatibility and should be ignored if OTN_LO, > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > granularity, then the corresponding G.709 Digital Path FA can be with= drawn. > > > > > > The Encoding type would be the lower encoding at each end of the LSP > > > regardless of what goes on in the middle since that determines what > > can > > > be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3D3 -------------- > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dfle= x > > > even though the ODUk=3D2 at the next hop could not directly contain a= n ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels > > of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > ODU-flex, and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one > > yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other than > > a > > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > or other intent. Could someone (either draft) concisely summarize > > > the multiplexing restrictions in one place, including restrictions > > > on number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > Behalf Of Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > document before we can embark on any proposals to the problem. I > > am > > > > > still not clear why do we have to deviate from the general > > approach > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > IB>> plane, and > > > > > it is highly desirable to adhere to the layer independent > > paradigm > > > > > of advertising of TE links, and there is no reason to invent an > > OTN > > > > > specific ISCD. The combination of Switching Capability and > > Encoding > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, if > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > >TE-link > > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create > > > > > IB>> OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > > needs > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > other interested experts, and we think the proposal described in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > control plane, no matter how you encode the routing information. > > > For > > > > > TDM networks, you know the resource is allocated based on TS, so > > > the > > > > > available TS should be get or induced before creating cross- > > > connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > > I > > > > > think you need go to the routing drafts (info model and > > encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > container instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; > > > > > > draft-ietf-ccamp-gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > align the work with 4202. Use of common approaches is of > > course > > > > > > one of the main objectives of *C*CAMP. I look forward to > > hearing > > > > > > from the draft and discussion contributors on there progress > > > > > > on > > > this point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service > > > > > >> routing purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order > > > > > >> ODUj availability within a higher-order container. For > > > > > >> example, consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > >> then > > > we > > > > > >> establish an ODU2 service over the link. At this point in > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > >> services > > and > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > >> example > > > that > > > > > >> the number of time-slots available is different based on the > > > signal-type (i.e. ODU1 and ODU2). > > > > > >> How do we address this issue based on the approach specified > > in > > > > > >> the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > the > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > >> approach seems to be more in-line with the general approach > > > > > >> outlined in RFC-4202. Refer to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > >> benefit > > > is > > > > > >> that the advertisement is TS size independent and hence will > > > > > >> simplify the implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 12:16:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6898C3A682A for ; Tue, 20 Jul 2010 12:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFfY4FGO7Tr0 for ; Tue, 20 Jul 2010 12:16:56 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 079A43A6893 for ; Tue, 20 Jul 2010 12:16:55 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KJH7V2008117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 21:17:07 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 21:17:07 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 21:17:07 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 15:17:04 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Tue, 20 Jul 2010 15:17:02 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoPlBVLaTZ2maDTve/RX8OLj+UJQAAQYig Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7619B@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 11:27:10 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760D1@atl-srv-exgen.atl.advaoptical.com> <201007201903.o6KJ3QGd066313@harbor.orleans.occnc.com> In-Reply-To: <201007201903.o6KJ3QGd066313@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: Snigdho Bardalai , "ccamp@ietf.org" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:16:59 -0000 Curtis, > > Curtis, > > I agree with your concerns about cranbacks. I never liked solutions > that rely on crankbacks. But what I was saying is that path > computation in the described example will be able to figure that the > path is not feasible, hence the ingress node will know that without > signaling failure. > > Cheers and hope to see you in Maastricht. > Igor Igor, I don't follow that. Are you claiming that the PathErr is significantly different from crankback? Or did I miss something about the example? IB>> Curtis, I don't follow you either. When did I mention either crankback= or pathErr? I was saying that not feasible paths should be failed by path = computation. The advertising based solely on 4203 has everything to achieve= that. Igor Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 10:52 AM > To: Fatai Zhang > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou B= erger; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > Fatai Zhang writes: > > > > Hi Igor, > > > > Thanks. > > Sorry to jump in but I think I understand Igor's objection (and > Snigdho's objection, and the reason this thread is going on). > > > I understand what you said. Therefore, we have added some text to > > address the requirment in FWK document. However, we still don't think > > that we need to extend ISC to meet the requirment. The role of the ODU > > can be get from the routing information implicitly. In the > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" is introduced. > > > > A quick question on your statement: "the role of an ODU container does > > not change hop-by-hop (as some people seem to believe). The role is > > only meaningful on the ODU terminating nodes and irrelevant on transit > > nodes. It is it's position in the hierarchy (but not role) that may > > change hop-by-hop. " > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > > of Ho ODU level is requested, according to your statement, this > > conneciton will be allowed to be created. However, it should not be > > allowed because the ISC is not consistent along the LSP. > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." > > I think the objection, which would be a very valid one, is that the > ingress has no way to know apriori that a path is infeasible. Each > crankback delays convergence. Crankback should only occur if another > ingress has reserved resources before signaling was completed, not > because inadequate routing information is provided in quiescent state. > > Curtis > > > > Best Regards > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: "Fatai Zhang" ; > > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; > > Sent: Friday, July 16, 2010 12:34 AM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-0= 1.txt > > > > > > Fatai, > > Please, see my answers in line. > > > > -----Original Message----- > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > Sent: Wednesday, July 14, 2010 9:52 PM > > To: Igor Bryskin; curtis@occnc.com > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-i= etf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-0= 1.txt > > > > Hi Igor and all, > > > > Thanks for all your comments. > > > > I think role does not equal switching capability. The operators can def= ine different roles depending on their policy and achieve the role through = different methods. However, for OTN networks, the containers (e.g., ODUk) a= ll have the same switching capablility (i.e., TDM switching) and I think we= should reflect the natural characteristics of links in the routing. In add= ition, if we extend the ISC, it will make the encoding type lose its' own m= eaning(ie., ISC overrides encoding type). > > > > IB>> When a GMPLS CP instance controls several layers, it views the net= work as a stack of topologies. Whether a given topology is real or virtual = is of no importance. > > The GMPLS ISCD link sub-tlv and, in particular, its switching capabilit= y field (confusing name as it is) is a good way to describe a layer in tech= nology independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM= layer stack could be perceived as a stack of topologies that could be easi= ly separated in technology independent way should path computation be const= rained to particular one or sub-stack of them. > > I think a good way to identify an OTN (virtual) topology is via (infras= tructure) ODU container role of ODUs comprising the topology. BTW IMO the r= ole of an ODU container does not change hop-by-hop (as some people seem to = believe). The role is only meaningful on the ODU terminating nodes and irre= levant on transit nodes. It is it's position in the hierarchy (but not role= ) that may change hop-by-hop. ODU's role is the level of topology it is pro= visioned for and it is the same for all ODUs that comprise the topology. Fo= r, example a user may provision a LO topology and constrain ODUs he sells t= o a set of clients to use the topology rather than any resources available = on OTN network. > > The bottom line: container's role is the same as the role of virtual to= pology the container is a part of and could be advertised as the correspond= ing link switchcap. > > > > According to the point 3, I don't know how to advertise the roles and m= uxing capabilities with the ISCD of RFC4202, could you clarify? > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > encoding type =3D mux. capabilities code > > > > In addition, could you clarify my questions in another email (copied as= follows): > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > IB>> I disagree. You define role =3D=3D position in the hierarchy, whic= h is a mistake IMO. > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho O= TN Level or Lo OTN Level? Another example is, if there is a OTU3 link suppo= rting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 direc= tly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentia= te if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU term= inating nodes (i.e. on either side of corresponding link). What happens on = the ODU transit nodes and its place in the hierarchy on the transit nodes a= re of no importance. My LO container can be carried by somebody else's LO c= ontainer and can carry my client's LO container. To some extent it is simil= ar to MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it = could be anywhere in MPLS stack along its path. > > > > Cheers, > > Igor > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > > > Thanks > > > > Fatai > > > > ----- Original Message ----- > > From: "Igor Bryskin" > > To: > > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; > > Sent: Wednesday, July 14, 2010 10:36 PM > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-0= 1.txt > > > > > > Curtis, > > > > Thanks for your comment. > > > > I agree that there should be multiple OTN specific encoding types intro= duced. But IMO they should indicate the link's mux capabilities rather than= the link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The = link's role or roles IMO should be indicated with a separate switchcaps. I = can give you several reasons: > > > > 1. Links with the same mux capabilities may have different roles; > > 2. Link may advertise several roles (e.g. HO and SHO) with different mu= x.capabilities per role; > > 3. Link's role and mux. capabilities can be advertised with ISCDs as de= fined in RFC4202 (no OTN-style ISCD is required); > > 4. The combination of swicthcaps and encoding type will look to CP as a= separate layer, which is exactly how ITU models OTN hierarchies in all asp= ects but routing (!?) > > 5. If the operator would want to constrain the routing of OTN connectio= ns to pre-configured topology with a specific role (e.g. constrain all ODUs= it sells to the clients to one or more pre-configured LO topologies), this= would be possible to do in a technology independent way. Suppose an instan= ce of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN l= inks will be no different from the separation of WDM links from OTUs. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 13, 2010 6:24 PM > > To: Igor Bryskin > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf= .org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-0= 1.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.at= l.advaoptical.com> > > Igor Bryskin writes: > > > > > > I think OTN links require more than one switchcaps: as many as the de= pth of the deepest possible OTN DP hierarchy, for example: > > > > > > typedef enum > > > { > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > /*****/ > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > }e_LSPSwitchType; > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > Replacing the Encoding Type would insure that any LSR that did not > > understand what the TS type meant did not try to multiplex its LO ODU > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > > a 1.25 TS granularity for another LO ODU. > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > The Encoding type would be the lower encoding at each end of the LSP > > regardless of what goes on in the middle since that determines what > > can be wrapped inside it. > > > > For example: > > > > OTU3 > > OTU2 ODUk=3D3 -------------- > > OTU1 ODUk=3D2 -- ODUj=3D2 > > ODUk=3D1 --- ODUj=3D1 -- > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Dflex = even > > though the ODUk=3D2 at the next hop could not directly contain an ODU0. > > If the SHO Encoding Type is used, then it indicates that two levels of > > multiplexing could be supported at that switch/LSR. > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > Types currently don't include an ODUj or ODUk distinction but if > > Encoding Type indicated LO or HO, that may not be needed. Along with > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > and ODU2e, can be added. > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > > how in an FA it can be indicated that either type is currently > > available (NE capable of both and hasn't committed to either one yet). > > > > BTW- Maybe I'm missing something but the number of messages on this > > would indicate a huge controversy and I'm not getting it (other than a > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > other intent. Could someone (either draft) concisely summarize the > > multiplexing restrictions in one place, including restrictions on > > number of multiplexing layers at one LSR. That might help. > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, July 08, 2010 1:59 PM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.= org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= -01.txt > > > > > > What do you mean by "different switchcaps"? > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Beh= alf Of > > > > Igor Bryskin > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.iet= f.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewo= rk- > > > > 01.txt > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework docu= ment > > > > before we can embark on any proposals to the problem. I am still no= t clear > > > > why do we have to deviate from the general approach that has been > > > > established in RFC 4202. > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plan= e, and > > > > it is highly desirable to adhere to the layer independent paradigm = of > > > > advertising of TE links, and there is no reason to invent an OTN sp= ecific > > > > ISCD. The combination of Switching Capability and Encoding type of = RFC4202 > > > > ISCD allows for specifying both multiplexing capabilities and OTN l= ayer > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link t= o > > > > represent >the low-order ODUj bandwidth within the high-order conta= iners. > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create= OTN > > > > hierarchies and constrain LO connections to HO containers, one need= s to > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > To: Snigdho Bardalai; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.iet= f.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewo= rk- > > > > 01.txt > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > interested experts, and we think the proposal described in "draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more fea= sible > > > > for OTN networks. > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for cont= rol > > > > plane, no matter how you encode the routing information. For TDM ne= tworks, > > > > you know the resource is allocated based on TS, so the available TS= should > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I = think > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you wi= ll find > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances= ). > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for= ODU1, > > > > you have to advertise a new TE link or put this FA as a component l= ink of > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > Cc: >; > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framewo= rk- > > > > 01.txt > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > Snigdho > > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > To: Snigdho Bardalai > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmp= ls- > > > > g709-framework@tools.ietf.org > > > framework@tools.ietf.org> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-frame= work- > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > I believe there has been some off-line discussion on how to bette= r > > > > > align the work with 4202. Use of common approaches is of course = one of > > > > > the main objectives of *C*CAMP. I look forward to hearing from t= he > > > > > draft and discussion contributors on there progress on this point= . > > > > > > > > > > Lou > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > >> Hello, > > > > >> > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > >> describes the link-parameters that are required for OTN service = routing > > > > >> purposes. > > > > >> > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > >> availability within a higher-order container. For example, consi= der an > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then w= e > > > > >> establish an ODU2 service over the link. At this point in time t= he OTU3 > > > > >> link has 12 time-slots available for ODU2 services and up to 12+= 4 > > > > >> time-slots available for ODU1 services (4 ODU1s are contained ov= er the > > > > >> ODU2). So it is obvious from this example that the number of tim= e-slots > > > > >> available is different based on the signal-type (i.e. ODU1 and O= DU2). > > > > >> How do we address this issue based on the approach specified in = the > > > > draft? > > > > >> > > > > >> My other question is why not simply advertize the available numb= er of > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalen= t > > > > >> bandwidth in bytes/sec within a link? This approach seems to be = more > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > section > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > >> advertised per VC rate for an SDH link. The additional benefit i= s that > > > > >> the advertisement is TS size independent and hence will simplify= the > > > > >> implementation. > > > > >> > > > > >> Regards > > > > >> > > > > >> Snigdho From curtis@occnc.com Tue Jul 20 12:29:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AA83A6958 for ; Tue, 20 Jul 2010 12:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBSykW0DLR6X for ; Tue, 20 Jul 2010 12:28:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 390493A67DB for ; Tue, 20 Jul 2010 12:28:56 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KJTBMa066582; Tue, 20 Jul 2010 15:29:11 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007201929.o6KJTBMa066582@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 12:16:17 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> Date: Tue, 20 Jul 2010 15:29:11 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:29:00 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > John, > > I totally agree with you. It is absolutely non OTN specific. However > if a TE link advertises more than one ISCD (with each ISCD containing > only max lsp bandwidth per priority), it is necessary to indicate how > the total link unreserved bandwidth is partitioned between several > ISCDs. What I am suggesting is instead of advertising the unreserved > bandwidth multiple times (one per ISCD), indicate how the bandwidth is > split between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > Igor. Igor, If there are two ISCs and nothing reserved, then there is one FA. One ISC is always lower in the hierarchy than the other. Consider the TDM+LSR example in RFC4202 and assume the exact advertisement is TDM+PSC-4. If a 1Gb/s PSC-3 LSP from far away is created on a STM64 and uses an STM16 worth of bandwidth, then the original FA has 75% reservable and there is a new PSC-4 only FA with 2.5G and 1.5G reservable. The new PSC-4 FA can take more PSC-3 but not more TDM. The original TDM+PSC-4 FA can take 7.5G of TDM or PSC capacity. The far away LSR would advertise a PSC-3 FA. The same should apply to the above example if an STM16 was added from a far away LSR. A new FA would be created at STM16 advertised by the new TDM LSP ingress. The old FA would now have 75% remaining for either TDM or PSC-4. Of course with 75% remaining it may not be possible to create a 5 Gb/s PSC LSP if it is not possible to link bundle two PSC-4 each over a STM16, but that brings us into the realm of discussing multipath (or pointing out that maxlsp can be set to 2.5G and avoid it). BTW- I am wondering what TDM capable LSR in the field actually do if this is not what they do. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 11:54 AM > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > Igor, > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue of partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs is actually a non-issue. > > Unreserved bandwidth by priority has always been advertised using the MPLS sub-TLV. My point has been that we have never had a requirement (including SDH/SONET) in the past to advertise unreserved bandwidth by signal type, so what is special about OTN? > > A further point would be that if we do decide that it is necessary to advertise unreserved bandwidth by signal type, it should be done in a general way and not in an OTN specific manner. (And in fact, the arguments that unreserved bandwidth by signal type needs to be advertised, such as the latest e-mail from Curtis, are not OTN specific.) > > Thanks, > > John > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Igor Bryskin > > Sent: Tuesday, July 20, 2010 8:21 AM > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > It is a valid point, but the suggested solution is way too expensive. > > All you need is a way to say how the advertised unreserved bandwidth is > > partitioned between ISCDs in case the TE link advertisement contains > > several of them. One cheap way of doing so is to allocate 3-4 bits out > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > unreserved bandwidth associated with the ISCD. Another way is to use > > swicthcap specific extension. > > BTW: this is not an OTN specific issue, rather more general: any time > > when a TE link advertises more than one ISCD (which is perfectly Ok > > according to 4203) you'll have the same problem. > > > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 10:57 AM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > The need for unreserved resources advertised per signal type is the > > concurrent path computation. I'll answer quoting a section from the > > info-model draft, please have a look in particular to the example: > > > > > > " Unreserved resources need to be advertised per priority and per > > signal type in order to allow the correct functioning of the > > restoration process. [RFC4203] only allows advertising unreserved > > resources per priority, this leads not to know how many LSPs of a > > specific signal type can be restored. As example it is possible to > > consider the scenario depicted in the following figure. > > > > +------+ component link 1 +------+ > > | +------------------+ | > > | | component link 2 | | > > | N1 +------------------+ N2 | > > | | component link 3 | | > > | +------------------+ | > > +------+ +---+--+ > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > 32TSs available on the first one, 24TSs on the second, 24TSs on the > > third and supporting ODU2 and ODU3 signal types. The node would > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > single ODU3 can be set up and a crank-back would be originated. In > > more complex network scenarios the number of crank-backs can be much > > higher." > > > > In other words, advertising the number of availble resources per signal > > type does not avoid the possibility of cranck-back but decreases it as > > much as possible. For sure a good routing prevents from crank-backs > > caused by the restoration of LSP originating on the same Ingress. The > > cranck-backs due to the concurrent restoration of LSPs originating on > > different ingress nodes cannot be avoided. > > > > BR > > Daniele > > > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: martedì 20 luglio 2010 16.16 > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > In line > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 4:32 AM > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, one more question. > > > > What about the unreserved bandwidth? > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > (muxCap & signal type) you also need to advertise the unreserved > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > > also implies extending the unreserved bandwidth TLV so to create a > > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > IB>> role per (muxCap & signal type) per priority level. However, total > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > IB>> see a compelling reason to the contrary (which I don't) > > > > Igor > > > > Thanks > > Daniele > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: lunedì 19 luglio 2010 17.48 > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Understood... > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 8:46 AM > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > (i.e. to further classify the information) will be sufficient > > > > > > That's exactly what I've been > > > trying to say all along. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Monday, July 19, 2010 11:31 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor > > > > > > Please see inline. > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Daniele, > > > > > > > > Please, see in line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > role > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > type. > > > > > > > > IB>> in ISCD: > > > > switchCap = role; > > > > encodeType = muxCap & signal type; > > > > We also have 16 reserved bits which can use for OTN specific info > > in > > > > case we need it. > > > [SCB] I am yet to clearly understand what the role of "role" is, but > > > agree with your observation on the encode-type and the 16 > > > reserved-bits to further classify the switching information. > > > > > > > > In case (a) you're still missing a lot of information. For each > > role > > > > you would advertise just the unreserved bandwidth but you wouldn't > > > know > > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > > 15 > > > > Gbps available on 3 component links: you advertise 45 Gbps > > available > > > > but no ODU3 can be set up on such TE link). > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > issues > > > > and the requirement of being able to bundle component links > > together > > > > wouldn't be satisfied. > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > will > > > > provide a lot of flexibility: you can specify different things > > (e.g. > > > > available bandwidth) for the same link in different roles. > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > Cheers, > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: lunedì 19 luglio 2010 15.40 > > > > To: Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Fatai, > > > > > > > > Please, see my responses on-line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Fatai Zhang > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > Thanks. > > > > I understand what you said. Therefore, we have added some text to > > > > address the requirment in FWK document. However, we still don't > > > > think that we need to extend ISC to meet the requirment. The role > > of > > > > the > > > ODU > > > > can be get from the routing information implicitly. In the [draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" > > > is > > > > introduced. > > > > > > > > IB>> This is possible, however: > > > > a) this requires OTN specific advertising and processing rules; > > > > b) disallows topology separation in technology independent way > > > > > > > > A quick question on your statement: "the role of an ODU container > > > does > > > > not change hop-by-hop (as some people seem to believe). The role is > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > transit > > > > nodes. It is it's position in the hierarchy (but not role) that may > > > > change hop-by-hop. " > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > support > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > role > > > > of Ho ODU level is requested, according to your statement, this > > > > conneciton will be allowed to be created. However, it should not be > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > ends > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > TE > > > > links will > > > be > > > > disallowed, and the resulting path (if any) will not go through B11 > > > and > > > > B12. If one circumvents the path computation by providing the fully > > > > explicit path, the signaling should fail on node B for the same > > > reason: > > > > inconsistency of required (signaled) and supported (by local > > > > interfaces) switchcap. > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > type > > > > indicated in the Switching Type parameter is supported on the > > > > corresponding incoming interface. If the type cannot be > > supported, > > > > the node MUST generate a PathErr message with a "Routing > > > > problem/Switching Type" indication." > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: "Fatai Zhang" ; > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Lou Berger" ; > > > > ; > > > framework@tools.ietf.org> > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > Please, see my answers in line. > > > > > > > > -----Original Message----- > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > draft- > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor and all, > > > > > > > > Thanks for all your comments. > > > > > > > > I think role does not equal switching capability. The operators can > > > > define different roles depending on their policy and achieve the > > > > role through different methods. However, for OTN networks, the > > > > containers (e.g., ODUk) all have the same switching capablility > > > > (i.e., TDM > > > > switching) and I think we should reflect the natural > > characteristics > > > of > > > > links in the routing. In addition, if we extend the ISC, it will > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > encoding type). > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > > network as a stack of topologies. Whether a given topology is real > > > > or virtual is of no importance. > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > capability field (confusing name as it is) is a good way to > > describe > > > a > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > > topologies that could be easily separated in technology independent > > > way > > > > should path computation be constrained to particular one or > > > > sub-stack of them. > > > > I think a good way to identify an OTN (virtual) topology is via > > > > (infrastructure) ODU container role of ODUs comprising the > > topology. > > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > > some people seem to believe). The role is only meaningful on the > > ODU > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > position > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > role > > > > is the level of topology it is provisioned for and it is the same > > > > for all ODUs that comprise the topology. For, example a user may > > > provision > > > > a LO topology and constrain ODUs he sells to a set of clients to > > use > > > > the topology rather than any resources available on OTN network. > > > > The bottom line: container's role is the same as the role of > > virtual > > > > topology the container is a part of and could be advertised as the > > > > corresponding link switchcap. > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > and muxing capabilities with the ISCD of RFC4202, could you > > clarify? > > > > > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > encoding type = mux. capabilities code > > > > > > > > In addition, could you clarify my questions in another email > > (copied > > > as > > > > follows): > > > > > > > > > ====================================================================== > > > = > > > > ============================= > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > IB>> I disagree. You define role == position in the hierarchy, > > which > > > is > > > > a mistake IMO. > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > OTU3 > > > link > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > over > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > > how > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > > terminating nodes (i.e. on either side of corresponding link). What > > > > happens on the ODU transit nodes and its place in the hierarchy on > > > the > > > > transit nodes are of no importance. My LO container can be carried > > > > by somebody else's LO container and can carry my client's LO > > container. > > > To > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > (e.g. > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > > path. > > > > > > > > Cheers, > > > > Igor > > > > > > > > > > > > > ====================================================================== > > > = > > > > ============================ > > > > > > > > > > > > > > > > Thanks > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Fatai Zhang" ; > > > > "Lou Berger" ; ; > > > > > > gmpls- > > > > g709-framework@tools.ietf.org> > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Curtis, > > > > > > > > Thanks for your comment. > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > introduced. But IMO they should indicate the link's mux > > capabilities > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > 2. > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > > be > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > required); 4. The combination of swicthcaps and encoding type will > > > look > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > would > > > > want to constrain the routing of OTN connections to pre-configured > > > > topology with a specific role (e.g. constrain all ODUs it sells to > > > the > > > > clients to one or more pre-configured LO topologies), this would be > > > > possible to do in a technology independent way. Suppose an instance > > > of > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > > links will be no different from the separation of WDM links from > > > OTUs. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > To: Igor Bryskin > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > /*****/ > > > > > , LSPSwitchType_LSC =150 /* LSC */ > > > > > , LSPSwitchType_FSC =200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > > ago. > > > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > > understand what the TS type meant did not try to multiplex its LO > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > to > > > using > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > latter > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > granularity, then the corresponding G.709 Digital Path FA can be > > withdrawn. > > > > > > > > The Encoding type would be the lower encoding at each end of the > > LSP > > > > regardless of what goes on in the middle since that determines what > > > can > > > > be wrapped inside it. > > > > > > > > For example: > > > > > > > > OTU3 > > > > OTU2 ODUk=3 -------------- > > > > OTU1 ODUk=2 -- ODUj=2 > > > > ODUk=1 --- ODUj=1 -- > > > > > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex > > > > even though the ODUk=2 at the next hop could not directly contain > > an ODU0. > > > > If the SHO Encoding Type is used, then it indicates that two levels > > > of > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > clear > > > > how in an FA it can be indicated that either type is currently > > > > available (NE capable of both and hasn't committed to either one > > > yet). > > > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > > would indicate a huge controversy and I'm not getting it (other > > than > > > a > > > > strong preference to rely on bytes/sec or on enumerated type > > fields). > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > > if > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > > or other intent. Could someone (either draft) concisely summarize > > > > the multiplexing restrictions in one place, including restrictions > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > > Behalf Of Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework > > > > > > document before we can embark on any proposals to the problem. > > I > > > am > > > > > > still not clear why do we have to deviate from the general > > > approach > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > > IB>> plane, and > > > > > > it is highly desirable to adhere to the layer independent > > > paradigm > > > > > > of advertising of TE links, and there is no reason to invent an > > > OTN > > > > > > specific ISCD. The combination of Switching Capability and > > > Encoding > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > if > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > >TE-link > > > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > create > > > > > > IB>> OTN > > > > > > hierarchies and constrain LO connections to HO containers, one > > > > needs > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > other interested experts, and we think the proposal described > > in > > > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > > control plane, no matter how you encode the routing > > information. > > > > For > > > > > > TDM networks, you know the resource is allocated based on TS, > > so > > > > the > > > > > > available TS should be get or induced before creating cross- > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > information, > > > I > > > > > > think you need go to the routing drafts (info model and > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > you > > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > > for > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > > > better > > > > > > > align the work with 4202. Use of common approaches is of > > > course > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > hearing > > > > > > > from the draft and discussion contributors on there progress > > > > > > > on > > > > this point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > section > > > > > > >> describes the link-parameters that are required for OTN > > > service > > > > > > >> routing purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > >> ODUj availability within a higher-order container. For > > > > > > >> example, consider an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > >> then > > > > we > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > >> services > > > and > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > >> example > > > > that > > > > > > >> the number of time-slots available is different based on the > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > >> How do we address this issue based on the approach specified > > > in > > > > > > >> the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the available > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > > the > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > >> approach seems to be more in-line with the general approach > > > > > > >> outlined in RFC-4202. Refer to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > > >> benefit > > > > is > > > > > > >> that the advertisement is TS size independent and hence will > > > > > > >> simplify the implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho From curtis@occnc.com Tue Jul 20 12:32:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8DD3A6A4F for ; Tue, 20 Jul 2010 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[AWL=-3.021, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, MANGLED_INCLDN=2.3, MANGLED_LINKS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiwF16W7nu6u for ; Tue, 20 Jul 2010 12:32:35 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 8D1BC3A685F for ; Tue, 20 Jul 2010 12:32:33 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KJWZ1u066615; Tue, 20 Jul 2010 15:32:35 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> To: Snigdho Bardalai From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." Date: Tue, 20 Jul 2010 15:32:34 -0400 Sender: curtis@occnc.com Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:32:40 -0000 In message Snigdho Bardalai writes: > > Igor, > > Would you not need percentage per priority per signal-type? > > Regards > Snigdho You would if you wanted to be able to preempt LSPs, therefore you do. I take it that was a rhetorical question for which you knew the answer already but I fell for it and answered. :-) Curtis > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin wro= > te: > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However if a > > TE link advertises more than one ISCD (with each ISCD containing only max > > lsp bandwidth per priority), it is necessary to indicate how the total li= > nk > > unreserved bandwidth is partitioned between several ISCDs. What I am > > suggesting is instead of advertising the unreserved bandwidth multiple ti= > mes > > (one per ISCD), indicate how the bandwidth is split between the ISCDs: e.= > g > > ISCD1 75%, ISCD2 25%. > > > > Igor. > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue o= > f > > partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs= > is > > actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the MPL= > S > > sub-TLV. My point has been that we have never had a requirement (includi= > ng > > SDH/SONET) in the past to advertise unreserved bandwidth by signal type, = > so > > what is special about OTN? > > > > A further point would be that if we do decide that it is necessary to > > advertise unreserved bandwidth by signal type, it should be done in a > > general way and not in an OTN specific manner. (And in fact, the argumen= > ts > > that unreserved bandwidth by signal type needs to be advertised, such as = > the > > latest e-mail from Curtis, are not OTN specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too expensive. > > > All you need is a way to say how the advertised unreserved bandwidth is > > > partitioned between ISCDs in case the TE link advertisement contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits out > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising unreserved > > > resources per priority, this leads not to know how many LSPs of a > > > specific signal type can be restored. As example it is possible to > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on the > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. In > > > more complex network scenarios the number of crank-backs can be much > > > higher." > > > > > > In other words, advertising the number of availble resources per signal > > > type does not avoid the possibility of cranck-back but decreases it as > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. The > > > cranck-backs due to the concurrent restoration of LSPs originating on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=EC 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > > IB>> role per (muxCap & signal type) per priority level. However, total > > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: luned=EC 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap =3D role; > > > > > encodeType =3D muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, but > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you wouldn't > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the [draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The role is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > > role > > > > > of Ho ODU level is requested, according to your statement, this > > > > > conneciton will be allowed to be created. However, it should not be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through B11 > > > > and > > > > > B12. If one circumvents the path computation by providing the fully > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators can > > > > > define different roles depending on their policy and achieve the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > > > network as a stack of topologies. Whether a given topology is real > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > > > topologies that could be easily separated in technology independent > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > > > some people seem to believe). The role is only meaningful on the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the same > > > > > for all ODUs that comprise the topology. For, example a user may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients to > > > use > > > > > the topology rather than any resources available on OTN network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as the > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > > > terminating nodes (i.e. on either side of corresponding link). What > > > > > happens on the ODU transit nodes and its place in the hierarchy on > > > > the > > > > > transit nodes are of no importance. My LO container can be carried > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > > required); 4. The combination of swicthcaps and encoding type will > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre-configured > > > > > topology with a specific role (e.g. constrain all ODUs it sells to > > > > the > > > > > clients to one or more pre-configured LO topologies), this would be > > > > > possible to do in a technology independent way. Suppose an instance > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > > > links will be no different from the separation of WDM links from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > > > understand what the TS type meant did not try to multiplex its LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of the > > > LSP > > > > > regardless of what goes on in the middle since that determines what > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3D3 -------------- > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= > lex > > > > > even though the ODUk=3D2 at the next hop could not directly contain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > > > or other intent. Could someone (either draft) concisely summarize > > > > > the multiplexing restrictions in one place, including restrictions > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > > > document before we can embark on any proposals to the problem. > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to invent an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, one > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there progress > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on the > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach specified > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the available > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general approach > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence will > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho From curtis@occnc.com Tue Jul 20 12:39:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866A83A685F for ; Tue, 20 Jul 2010 12:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJG1IMeo+MaL for ; Tue, 20 Jul 2010 12:39:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 7FC2E3A680C for ; Tue, 20 Jul 2010 12:39:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KJdbJF066724; Tue, 20 Jul 2010 15:39:37 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007201939.o6KJdbJF066724@harbor.orleans.occnc.com> To: John E Drake From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 10:01:15 PDT." <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01-HQ.jnpr.net> Date: Tue, 20 Jul 2010 15:39:37 -0400 Sender: curtis@occnc.com Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:39:30 -0000 In message <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01-HQ.jnpr.net> John E Drake writes: > > Curtis, > > Unless you are proposing to issue a new advertisement every time an > LSP is activated or deactivated, which has issues of its own, you will > be dealing with thresholding so what is being advertised is only an > approximation (e.g., advertise 5 ODUj if the unreserved bandwidth is > between 0 ODUj and 10 ODUj), so you will never know with certainty > whether a given LSP can be activated until you try to activate it. > > Thanks, > > John John, When you create a new LSP you must deduct from the existing FA and create an FA for the new LSP. The endpoints of the new LSP may not be the same as the endpoints of the old FA, more likely it is just a hop along the way. Curtis > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 20, 2010 7:52 AM > > To: Fatai Zhang > > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou > > Berger; ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > > Fatai Zhang writes: > > > > > > Hi Igor, > > > > > > Thanks. > > > > Sorry to jump in but I think I understand Igor's objection (and > > Snigdho's objection, and the reason this thread is going on). > > > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't think > > > that we need to extend ISC to meet the requirment. The role of the > > ODU > > > can be get from the routing information implicitly. In the > > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" is introduced. > > > > > > A quick question on your statement: "the role of an ODU container > > does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on > > transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > > I think the objection, which would be a very valid one, is that the > > ingress has no way to know apriori that a path is infeasible. Each > > crankback delays convergence. Crankback should only occur if another > > ingress has reserved resources before signaling was completed, not > > because inadequate routing information is provided in quiescent state. > > > > Curtis > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Lou Berger" ; > > ; > framework@tools.ietf.org> > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can > > define different roles depending on their policy and achieve the role > > through different methods. However, for OTN networks, the containers > > (e.g., ODUk) all have the same switching capablility (i.e., TDM > > switching) and I think we should reflect the natural characteristics of > > links in the routing. In addition, if we extend the ISC, it will make > > the encoding type lose its' own meaning(ie., ISC overrides encoding > > type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > network as a stack of topologies. Whether a given topology is real or > > virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > capability field (confusing name as it is) is a good way to describe a > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > topologies that could be easily separated in technology independent way > > should path computation be constrained to particular one or sub-stack > > of them. > > > I think a good way to identify an OTN (virtual) topology is via > > (infrastructure) ODU container role of ODUs comprising the topology. > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > some people seem to believe). The role is only meaningful on the ODU > > terminating nodes and irrelevant on transit nodes. It is it's position > > in the hierarchy (but not role) that may change hop-by-hop. ODU's role > > is the level of topology it is provisioned for and it is the same for > > all ODUs that comprise the topology. For, example a user may provision > > a LO topology and constrain ODUs he sells to a set of clients to use > > the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of virtual > > topology the container is a part of and could be advertised as the > > corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles and > > muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type = mux. capabilities code > > > > > > In addition, could you clarify my questions in another email (copied > > as follows): > > > > > ======================================================================= > > ============================= > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role == position in the hierarchy, which > > is a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho > > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link > > supporting ODU2 switching, which can be used as Lo ODU2 (service over > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > terminating nodes (i.e. on either side of corresponding link). What > > happens on the ODU transit nodes and its place in the hierarchy on the > > transit nodes are of no importance. My LO container can be carried by > > somebody else's LO container and can carry my client's LO container. To > > some extent it is similar to MPLS LSP role: LSP always has a role (e.g. > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > path. > > > > > > Cheers, > > > Igor > > > > > > > > ======================================================================= > > ============================ > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > ; "Fatai Zhang" ; "Lou > > Berger" ; ; > g709-framework@tools.ietf.org> > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types > > introduced. But IMO they should indicate the link's mux capabilities > > rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, > > SHO, etc.). The link's role or roles IMO should be indicated with a > > separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; > > > 2. Link may advertise several roles (e.g. HO and SHO) with different > > mux.capabilities per role; > > > 3. Link's role and mux. capabilities can be advertised with ISCDs as > > defined in RFC4202 (no OTN-style ISCD is required); > > > 4. The combination of swicthcaps and encoding type will look to CP as > > a separate layer, which is exactly how ITU models OTN hierarchies in > > all aspects but routing (!?) > > > 5. If the operator would want to constrain the routing of OTN > > connections to pre-configured topology with a specific role (e.g. > > constrain all ODUs it sells to the clients to one or more pre- > > configured LO topologies), this would be possible to do in a technology > > independent way. Suppose an instance of GMPLS CP manages WDM and OTN > > NEs. Then separation of LO from HO OTN links will be no different from > > the separation of WDM links from OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as the > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =150 /* LSC */ > > > > , LSPSwitchType_FSC =200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO ODU > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to > > using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > latter > > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > > > The Encoding type would be the lower encoding at each end of the LSP > > > regardless of what goes on in the middle since that determines what > > > can be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3 -------------- > > > OTU1 ODUk=2 -- ODUj=2 > > > ODUk=1 --- ODUj=1 -- > > > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even > > > though the ODUk=2 at the next hop could not directly contain an ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels > > of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along with > > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > > and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one > > yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other than > > a > > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > > other intent. Could someone (either draft) concisely summarize the > > > multiplexing restrictions in one place, including restrictions on > > > number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework > > document > > > > > before we can embark on any proposals to the problem. I am still > > not clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > plane, and > > > > > it is highly desirable to adhere to the layer independent > > paradigm of > > > > > advertising of TE links, and there is no reason to invent an OTN > > specific > > > > > ISCD. The combination of Switching Capability and Encoding type > > of RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN > > layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you > > have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link > > to > > > > > represent >the low-order ODUj bandwidth within the high-order > > containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > create OTN > > > > > hierarchies and constrain LO connections to HO containers, one > > needs to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in > > "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > control > > > > > plane, no matter how you encode the routing information. For TDM > > networks, > > > > > you know the resource is allocated based on TS, so the available > > TS should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, > > I think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you > > will find > > > > > that one of your suggestions is adopted (i.e., simply advertize > > the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > for ODU1, > > > > > you have to advertise a new TE link or put this FA as a component > > link of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp- > > gmpls- > > > > > g709-framework@tools.ietf.org > g709- > > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to > > better > > > > > > align the work with 4202. Use of common approaches is of > > course one of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from > > the > > > > > > draft and discussion contributors on there progress on this > > point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > section > > > > > >> describes the link-parameters that are required for OTN > > service routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, > > consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then > > we > > > > > >> establish an ODU2 service over the link. At this point in time > > the OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to > > 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained > > over the > > > > > >> ODU2). So it is obvious from this example that the number of > > time-slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and > > ODU2). > > > > > >> How do we address this issue based on the approach specified > > in the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available > > number of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to > > be more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer > > to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit > > is that > > > > > >> the advertisement is TS size independent and hence will > > simplify the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 12:44:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED983A6821 for ; Tue, 20 Jul 2010 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMz0ECy0FGQY for ; Tue, 20 Jul 2010 12:44:09 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 490A23A680C for ; Tue, 20 Jul 2010 12:44:08 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KJiFEo012377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 21:44:16 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 21:44:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 15:44:13 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Tue, 20 Jul 2010 15:44:11 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQdxVh5yfH6xgTB6HKnuuZvTiXgAAJ0Hg Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 12:16:17 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <201007201929.o6KJTBMa066582@harbor.orleans.occnc.com> In-Reply-To: <201007201929.o6KJTBMa066582@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:44:12 -0000 Curtis, When a link advertises two ISCDs it means that it is immediately ready to a= ccept an LSP of any type. Hence the TDM+PSC-4 advertisement (albeit allowed= ) does not make any practical sense to me. You need, first, create a TDM LS= P, advertise it as an FA and use FA as a link (which is likely to be a diff= erent link, because, for example, it will have a different remote end) for = PSC-4 LSP. However, if an OTN link advertises two IDSCc - OTN_LO and OTN_HO= - it is quite a different ball game. It will mean that the link could part= icipate in the two topologies immediately. Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Tuesday, July 20, 2010 3:29 PM To: Igor Bryskin Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis= @occnc.com; ccamp@ietf.org Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > > John, > > I totally agree with you. It is absolutely non OTN specific. However > if a TE link advertises more than one ISCD (with each ISCD containing > only max lsp bandwidth per priority), it is necessary to indicate how > the total link unreserved bandwidth is partitioned between several > ISCDs. What I am suggesting is instead of advertising the unreserved > bandwidth multiple times (one per ISCD), indicate how the bandwidth is > split between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > Igor. Igor, If there are two ISCs and nothing reserved, then there is one FA. One ISC is always lower in the hierarchy than the other. Consider the TDM+LSR example in RFC4202 and assume the exact advertisement is TDM+PSC-4. If a 1Gb/s PSC-3 LSP from far away is created on a STM64 and uses an STM16 worth of bandwidth, then the original FA has 75% reservable and there is a new PSC-4 only FA with 2.5G and 1.5G reservable. The new PSC-4 FA can take more PSC-3 but not more TDM. The original TDM+PSC-4 FA can take 7.5G of TDM or PSC capacity. The far away LSR would advertise a PSC-3 FA. The same should apply to the above example if an STM16 was added from a far away LSR. A new FA would be created at STM16 advertised by the new TDM LSP ingress. The old FA would now have 75% remaining for either TDM or PSC-4. Of course with 75% remaining it may not be possible to create a 5 Gb/s PSC LSP if it is not possible to link bundle two PSC-4 each over a STM16, but that brings us into the realm of discussing multipath (or pointing out that maxlsp can be set to 2.5G and avoid it). BTW- I am wondering what TDM capable LSR in the field actually do if this is not what they do. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 11:54 AM > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curt= is@occnc.com > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.= txt > > Igor, > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue o= f partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs= is actually a non-issue. > > Unreserved bandwidth by priority has always been advertised using the MPL= S sub-TLV. My point has been that we have never had a requirement (includi= ng SDH/SONET) in the past to advertise unreserved bandwidth by signal type,= so what is special about OTN? > > A further point would be that if we do decide that it is necessary to adv= ertise unreserved bandwidth by signal type, it should be done in a general = way and not in an OTN specific manner. (And in fact, the arguments that un= reserved bandwidth by signal type needs to be advertised, such as the lates= t e-mail from Curtis, are not OTN specific.) > > Thanks, > > John > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Igor Bryskin > > Sent: Tuesday, July 20, 2010 8:21 AM > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > It is a valid point, but the suggested solution is way too expensive. > > All you need is a way to say how the advertised unreserved bandwidth is > > partitioned between ISCDs in case the TE link advertisement contains > > several of them. One cheap way of doing so is to allocate 3-4 bits out > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > unreserved bandwidth associated with the ISCD. Another way is to use > > swicthcap specific extension. > > BTW: this is not an OTN specific issue, rather more general: any time > > when a TE link advertises more than one ISCD (which is perfectly Ok > > according to 4203) you'll have the same problem. > > > > Igor > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 10:57 AM > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > The need for unreserved resources advertised per signal type is the > > concurrent path computation. I'll answer quoting a section from the > > info-model draft, please have a look in particular to the example: > > > > > > " Unreserved resources need to be advertised per priority and per > > signal type in order to allow the correct functioning of the > > restoration process. [RFC4203] only allows advertising unreserved > > resources per priority, this leads not to know how many LSPs of a > > specific signal type can be restored. As example it is possible to > > consider the scenario depicted in the following figure. > > > > +------+ component link 1 +------+ > > | +------------------+ | > > | | component link 2 | | > > | N1 +------------------+ N2 | > > | | component link 3 | | > > | +------------------+ | > > +------+ +---+--+ > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > 32TSs available on the first one, 24TSs on the second, 24TSs on the > > third and supporting ODU2 and ODU3 signal types. The node would > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > single ODU3 can be set up and a crank-back would be originated. In > > more complex network scenarios the number of crank-backs can be much > > higher." > > > > In other words, advertising the number of availble resources per signal > > type does not avoid the possibility of cranck-back but decreases it as > > much as possible. For sure a good routing prevents from crank-backs > > caused by the restoration of LSP originating on the same Ingress. The > > cranck-backs due to the concurrent restoration of LSPs originating on > > different ingress nodes cannot be avoided. > > > > BR > > Daniele > > > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 16.16 > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > In line > > > > -----Original Message----- > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > Sent: Tuesday, July 20, 2010 4:32 AM > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, one more question. > > > > What about the unreserved bandwidth? > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > (muxCap & signal type) you also need to advertise the unreserved > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > > also implies extending the unreserved bandwidth TLV so to create a > > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > IB>> role per (muxCap & signal type) per priority level. However, total > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > IB>> see a compelling reason to the contrary (which I don't) > > > > Igor > > > > Thanks > > Daniele > > > > -----Original Message----- > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > Sent: luned=EC 19 luglio 2010 17.48 > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Understood... > > > > Regards > > Snigdho > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: Monday, July 19, 2010 8:46 AM > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > (i.e. to further classify the information) will be sufficient > > > > > > That's exactly what I've been > > > trying to say all along. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: Monday, July 19, 2010 11:31 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor > > > > > > Please see inline. > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Daniele, > > > > > > > > Please, see in line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > role > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > type. > > > > > > > > IB>> in ISCD: > > > > switchCap =3D role; > > > > encodeType =3D muxCap & signal type; > > > > We also have 16 reserved bits which can use for OTN specific info > > in > > > > case we need it. > > > [SCB] I am yet to clearly understand what the role of "role" is, but > > > agree with your observation on the encode-type and the 16 > > > reserved-bits to further classify the switching information. > > > > > > > > In case (a) you're still missing a lot of information. For each > > role > > > > you would advertise just the unreserved bandwidth but you wouldn't > > > know > > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > > 15 > > > > Gbps available on 3 component links: you advertise 45 Gbps > > available > > > > but no ODU3 can be set up on such TE link). > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > issues > > > > and the requirement of being able to bundle component links > > together > > > > wouldn't be satisfied. > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > will > > > > provide a lot of flexibility: you can specify different things > > (e.g. > > > > available bandwidth) for the same link in different roles. > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > Cheers, > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Igor Bryskin > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > To: Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Fatai, > > > > > > > > Please, see my responses on-line. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf > > > > Of Fatai Zhang > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor, > > > > > > > > Thanks. > > > > I understand what you said. Therefore, we have added some text to > > > > address the requirment in FWK document. However, we still don't > > > > think that we need to extend ISC to meet the requirment. The role > > of > > > > the > > > ODU > > > > can be get from the routing information implicitly. In the [draft- > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > Lambda" > > > is > > > > introduced. > > > > > > > > IB>> This is possible, however: > > > > a) this requires OTN specific advertising and processing rules; > > > > b) disallows topology separation in technology independent way > > > > > > > > A quick question on your statement: "the role of an ODU container > > > does > > > > not change hop-by-hop (as some people seem to believe). The role is > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > transit > > > > nodes. It is it's position in the hierarchy (but not role) that may > > > > change hop-by-hop. " > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > support > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > role > > > > of Ho ODU level is requested, according to your statement, this > > > > conneciton will be allowed to be created. However, it should not be > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > ends > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > TE > > > > links will > > > be > > > > disallowed, and the resulting path (if any) will not go through B11 > > > and > > > > B12. If one circumvents the path computation by providing the fully > > > > explicit path, the signaling should fail on node B for the same > > > reason: > > > > inconsistency of required (signaled) and supported (by local > > > > interfaces) switchcap. > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > type > > > > indicated in the Switching Type parameter is supported on the > > > > corresponding incoming interface. If the type cannot be > > supported, > > > > the node MUST generate a PathErr message with a "Routing > > > > problem/Switching Type" indication." > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: "Fatai Zhang" ; > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Lou Berger" ; > > > > ; > > > framework@tools.ietf.org> > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > Please, see my answers in line. > > > > > > > > -----Original Message----- > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > draft- > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Hi Igor and all, > > > > > > > > Thanks for all your comments. > > > > > > > > I think role does not equal switching capability. The operators can > > > > define different roles depending on their policy and achieve the > > > > role through different methods. However, for OTN networks, the > > > > containers (e.g., ODUk) all have the same switching capablility > > > > (i.e., TDM > > > > switching) and I think we should reflect the natural > > characteristics > > > of > > > > links in the routing. In addition, if we extend the ISC, it will > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > encoding type). > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > > network as a stack of topologies. Whether a given topology is real > > > > or virtual is of no importance. > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > capability field (confusing name as it is) is a good way to > > describe > > > a > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > > topologies that could be easily separated in technology independent > > > way > > > > should path computation be constrained to particular one or > > > > sub-stack of them. > > > > I think a good way to identify an OTN (virtual) topology is via > > > > (infrastructure) ODU container role of ODUs comprising the > > topology. > > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > > some people seem to believe). The role is only meaningful on the > > ODU > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > position > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > role > > > > is the level of topology it is provisioned for and it is the same > > > > for all ODUs that comprise the topology. For, example a user may > > > provision > > > > a LO topology and constrain ODUs he sells to a set of clients to > > use > > > > the topology rather than any resources available on OTN network. > > > > The bottom line: container's role is the same as the role of > > virtual > > > > topology the container is a part of and could be advertised as the > > > > corresponding link switchcap. > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > and muxing capabilities with the ISCD of RFC4202, could you > > clarify? > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > encoding type =3D mux. capabilities code > > > > > > > > In addition, could you clarify my questions in another email > > (copied > > > as > > > > follows): > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > > which > > > is > > > > a mistake IMO. > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > OTU3 > > > link > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > over > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > > how > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > > terminating nodes (i.e. on either side of corresponding link). What > > > > happens on the ODU transit nodes and its place in the hierarchy on > > > the > > > > transit nodes are of no importance. My LO container can be carried > > > > by somebody else's LO container and can carry my client's LO > > container. > > > To > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > (e.g. > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > > path. > > > > > > > > Cheers, > > > > Igor > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > Thanks > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Fatai Zhang" ; > > > > "Lou Berger" ; ; > > > > > > gmpls- > > > > g709-framework@tools.ietf.org> > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > Curtis, > > > > > > > > Thanks for your comment. > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > introduced. But IMO they should indicate the link's mux > > capabilities > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > 2. > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > > be > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > required); 4. The combination of swicthcaps and encoding type will > > > look > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > would > > > > want to constrain the routing of OTN connections to pre-configured > > > > topology with a specific role (e.g. constrain all ODUs it sells to > > > the > > > > clients to one or more pre-configured LO topologies), this would be > > > > possible to do in a technology independent way. Suppose an instance > > > of > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > > links will be no different from the separation of WDM links from > > > OTUs. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > To: Igor Bryskin > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > /*****/ > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > > ago. > > > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > > understand what the TS type meant did not try to multiplex its LO > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > to > > > using > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > latter > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > granularity, then the corresponding G.709 Digital Path FA can be > > withdrawn. > > > > > > > > The Encoding type would be the lower encoding at each end of the > > LSP > > > > regardless of what goes on in the middle since that determines what > > > can > > > > be wrapped inside it. > > > > > > > > For example: > > > > > > > > OTU3 > > > > OTU2 ODUk=3D3 -------------- > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= lex > > > > even though the ODUk=3D2 at the next hop could not directly contain > > an ODU0. > > > > If the SHO Encoding Type is used, then it indicates that two levels > > > of > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > clear > > > > how in an FA it can be indicated that either type is currently > > > > available (NE capable of both and hasn't committed to either one > > > yet). > > > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > > would indicate a huge controversy and I'm not getting it (other > > than > > > a > > > > strong preference to rely on bytes/sec or on enumerated type > > fields). > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > > if > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > > or other intent. Could someone (either draft) concisely summarize > > > > the multiplexing restrictions in one place, including restrictions > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > > Behalf Of Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > > > > document before we can embark on any proposals to the problem. > > I > > > am > > > > > > still not clear why do we have to deviate from the general > > > approach > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > > IB>> plane, and > > > > > > it is highly desirable to adhere to the layer independent > > > paradigm > > > > > > of advertising of TE links, and there is no reason to invent an > > > OTN > > > > > > specific ISCD. The combination of Switching Capability and > > > Encoding > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > if > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > >TE-link > > > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > create > > > > > > IB>> OTN > > > > > > hierarchies and constrain LO connections to HO containers, one > > > > needs > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > other interested experts, and we think the proposal described > > in > > > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > > control plane, no matter how you encode the routing > > information. > > > > For > > > > > > TDM networks, you know the resource is allocated based on TS, > > so > > > > the > > > > > > available TS should be get or induced before creating cross- > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > information, > > > I > > > > > > think you need go to the routing drafts (info model and > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > you > > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > > for > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > > > better > > > > > > > align the work with 4202. Use of common approaches is of > > > course > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > hearing > > > > > > > from the draft and discussion contributors on there progress > > > > > > > on > > > > this point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > section > > > > > > >> describes the link-parameters that are required for OTN > > > service > > > > > > >> routing purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > >> ODUj availability within a higher-order container. For > > > > > > >> example, consider an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > >> then > > > > we > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > >> services > > > and > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > >> example > > > > that > > > > > > >> the number of time-slots available is different based on the > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > >> How do we address this issue based on the approach specified > > > in > > > > > > >> the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the available > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > > the > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > >> approach seems to be more in-line with the general approach > > > > > > >> outlined in RFC-4202. Refer to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > > >> benefit > > > > is > > > > > > >> that the advertisement is TS size independent and hence will > > > > > > >> simplify the implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 13:21:52 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A6F3A67B1 for ; Tue, 20 Jul 2010 13:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.705 X-Spam-Level: X-Spam-Status: No, score=-5.705 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSng4jheWFxc for ; Tue, 20 Jul 2010 13:21:49 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 2B1613A63EC for ; Tue, 20 Jul 2010 13:21:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYFZLYJkuh43rjaXhnrouZYNTjXlrzr@postini.com; Tue, 20 Jul 2010 13:22:05 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Jul 2010 13:17:33 -0700 From: John E Drake To: "curtis@occnc.com" Date: Tue, 20 Jul 2010 13:17:32 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQ1DgOypHMj+gRiaK39c8uPerfwAAfljg Message-ID: <5E893DB832F57341992548CDBB333163984487CA7D@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 10:01:15 PDT." <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01-HQ.jnpr.net> <201007201939.o6KJdbJF066724@harbor.orleans.occnc.com> In-Reply-To: <201007201939.o6KJdbJF066724@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai , Lou Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:21:52 -0000 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 12:40 PM > To: John E Drake > Cc: curtis@occnc.com; Fatai Zhang; Igor Bryskin; Snigdho Bardalai; Lou > Berger; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01- > HQ.jnpr.net> > John E Drake writes: > > > > Curtis, > > > > Unless you are proposing to issue a new advertisement every time an > > LSP is activated or deactivated, which has issues of its own, you > will > > be dealing with thresholding so what is being advertised is only an > > approximation (e.g., advertise 5 ODUj if the unreserved bandwidth is > > between 0 ODUj and 10 ODUj), so you will never know with certainty > > whether a given LSP can be activated until you try to activate it. > > > > Thanks, > > > > John > > > John, > > When you create a new LSP you must deduct from the existing FA and > create an FA for the new LSP. The endpoints of the new LSP may not be > the same as the endpoints of the old FA, more likely it is just a hop > along the way. > > Curtis JD: I agree with what you wrote, above, but I am not sure what it has to d= o with my e-mail. The question we have been discussing is whether an intermediate node should= be advertising the total unreserved bandwidth or unreserved bandwidth by s= ervice category for each of its links. I thought your e-mail indicated sup= port for the latter position. What I was trying to point out was that unless an intermediate node issues = a new advertisement every it activates or deactivates an LSP across its lin= ks, the state of its links in its last advertisement may be very different = from its current state, and that hence an ingress node does not have a reli= able indication of that state. The example I used was that what was advertised for a given link was 5 ODUj= , even though the current unreserved bandwidth for ODUj is anywhere in the = range 0 ODUj to 10 ODUj. I.e., advertising unreserved bandwidth by service category gives a false se= nse of security wrt the distributed awareness of the current state of the n= etwork. > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 20, 2010 7:52 AM > > > To: Fatai Zhang > > > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; > Lou > > > Berger; ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > > > Fatai Zhang writes: > > > > > > > > Hi Igor, > > > > > > > > Thanks. > > > > > > Sorry to jump in but I think I understand Igor's objection (and > > > Snigdho's objection, and the reason this thread is going on). > > > > > > > I understand what you said. Therefore, we have added some text to > > > > address the requirment in FWK document. However, we still don't > think > > > > that we need to extend ISC to meet the requirment. The role of > the > > > ODU > > > > can be get from the routing information implicitly. In the > > > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > "Full > > > > Lambda" is introduced. > > > > > > > > A quick question on your statement: "the role of an ODU container > > > does > > > > not change hop-by-hop (as some people seem to believe). The role > is > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > transit > > > > nodes. It is it's position in the hierarchy (but not role) that > may > > > > change hop-by-hop. " > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > CI1 > > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > support > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > role > > > > of Ho ODU level is requested, according to your statement, this > > > > conneciton will be allowed to be created. However, it should not > be > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > type > > > > indicated in the Switching Type parameter is supported on the > > > > corresponding incoming interface. If the type cannot be > supported, > > > > the node MUST generate a PathErr message with a "Routing > > > > problem/Switching Type" indication." > > > > > > I think the objection, which would be a very valid one, is that the > > > ingress has no way to know apriori that a path is infeasible. Each > > > crankback delays convergence. Crankback should only occur if > another > > > ingress has reserved resources before signaling was completed, not > > > because inadequate routing information is provided in quiescent > state. > > > > > > Curtis > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: "Fatai Zhang" ; > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Lou Berger" ; > > > ; > > framework@tools.ietf.org> > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > > > Fatai, > > > > Please, see my answers in line. > > > > > > > > -----Original Message----- > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > To: Igor Bryskin; curtis@occnc.com > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > Hi Igor and all, > > > > > > > > Thanks for all your comments. > > > > > > > > I think role does not equal switching capability. The operators > can > > > define different roles depending on their policy and achieve the > role > > > through different methods. However, for OTN networks, the > containers > > > (e.g., ODUk) all have the same switching capablility (i.e., TDM > > > switching) and I think we should reflect the natural > characteristics of > > > links in the routing. In addition, if we extend the ISC, it will > make > > > the encoding type lose its' own meaning(ie., ISC overrides encoding > > > type). > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > the > > > network as a stack of topologies. Whether a given topology is real > or > > > virtual is of no importance. > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > capability field (confusing name as it is) is a good way to > describe a > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > topologies that could be easily separated in technology independent > way > > > should path computation be constrained to particular one or sub- > stack > > > of them. > > > > I think a good way to identify an OTN (virtual) topology is via > > > (infrastructure) ODU container role of ODUs comprising the > topology. > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > some people seem to believe). The role is only meaningful on the > ODU > > > terminating nodes and irrelevant on transit nodes. It is it's > position > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > role > > > is the level of topology it is provisioned for and it is the same > for > > > all ODUs that comprise the topology. For, example a user may > provision > > > a LO topology and constrain ODUs he sells to a set of clients to > use > > > the topology rather than any resources available on OTN network. > > > > The bottom line: container's role is the same as the role of > virtual > > > topology the container is a part of and could be advertised as the > > > corresponding link switchcap. > > > > > > > > According to the point 3, I don't know how to advertise the roles > and > > > muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > encoding type =3D mux. capabilities code > > > > > > > > In addition, could you clarify my questions in another email > (copied > > > as follows): > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, > which > > > is a mistake IMO. > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > as Ho > > > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > link > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > over > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > how > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > ODU > > > terminating nodes (i.e. on either side of corresponding link). What > > > happens on the ODU transit nodes and its place in the hierarchy on > the > > > transit nodes are of no importance. My LO container can be carried > by > > > somebody else's LO container and can carry my client's LO > container. To > > > some extent it is similar to MPLS LSP role: LSP always has a role > (e.g. > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > path. > > > > > > > > Cheers, > > > > Igor > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > Thanks > > > > > > > > Fatai > > > > > > > > ----- Original Message ----- > > > > From: "Igor Bryskin" > > > > To: > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > ; "Fatai Zhang" ; > "Lou > > > Berger" ; ; gmpls- > > > g709-framework@tools.ietf.org> > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > > > Curtis, > > > > > > > > Thanks for your comment. > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > introduced. But IMO they should indicate the link's mux > capabilities > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > HO, > > > SHO, etc.). The link's role or roles IMO should be indicated with a > > > separate switchcaps. I can give you several reasons: > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > > > 2. Link may advertise several roles (e.g. HO and SHO) with > different > > > mux.capabilities per role; > > > > 3. Link's role and mux. capabilities can be advertised with ISCDs > as > > > defined in RFC4202 (no OTN-style ISCD is required); > > > > 4. The combination of swicthcaps and encoding type will look to > CP as > > > a separate layer, which is exactly how ITU models OTN hierarchies > in > > > all aspects but routing (!?) > > > > 5. If the operator would want to constrain the routing of OTN > > > connections to pre-configured topology with a specific role (e.g. > > > constrain all ODUs it sells to the clients to one or more pre- > > > configured LO topologies), this would be possible to do in a > technology > > > independent way. Suppose an instance of GMPLS CP manages WDM and > OTN > > > NEs. Then separation of LO from HO OTN links will be no different > from > > > the separation of WDM links from OTUs. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > To: Igor Bryskin > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > the > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > typedef enum > > > > > { > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > /*****/ > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > > /*****/ > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > }e_LSPSwitchType; > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > the > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > Path > > > > layer and G.709 Optical Channel layer for 2009 OTN, which had in > turn > > > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > not > > > > understand what the TS type meant did not try to multiplex its LO > ODU > > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to > > > using > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO > or > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > latter > > > > is for backward compatibility and should be ignored if OTN_LO, > OTN_HO > > > > or OTN_SHO is understood. If the LSR commits to 1.25 TS > granularity, > > > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > > > > > The Encoding type would be the lower encoding at each end of the > LSP > > > > regardless of what goes on in the middle since that determines > what > > > > can be wrapped inside it. > > > > > > > > For example: > > > > > > > > OTU3 > > > > OTU2 ODUk=3D3 -------------- > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3Df= lex > even > > > > though the ODUk=3D2 at the next hop could not directly contain an > ODU0. > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > of > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > Encoding Type indicated LO or HO, that may not be needed. Along > with > > > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU- > flex, > > > > and ODU2e, can be added. > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > clear > > > > how in an FA it can be indicated that either type is currently > > > > available (NE capable of both and hasn't committed to either one > > > yet). > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > this > > > > would indicate a huge controversy and I'm not getting it (other > than > > > a > > > > strong preference to rely on bytes/sec or on enumerated type > fields). > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > sure > > > if > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, or > > > > other intent. Could someone (either draft) concisely summarize > the > > > > multiplexing restrictions in one place, including restrictions on > > > > number of multiplexing layers at one LSR. That might help. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > Behalf Of > > > > > > Igor Bryskin > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the framework > > > document > > > > > > before we can embark on any proposals to the problem. I am > still > > > not clear > > > > > > why do we have to deviate from the general approach that has > been > > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > plane, and > > > > > > it is highly desirable to adhere to the layer independent > > > paradigm of > > > > > > advertising of TE links, and there is no reason to invent an > OTN > > > specific > > > > > > ISCD. The combination of Switching Capability and Encoding > type > > > of RFC4202 > > > > > > ISCD allows for specifying both multiplexing capabilities and > OTN > > > layer > > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, > you > > > have > > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE- > link > > > to > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > containers. > > > > > > This is simply >blowing up the solution to a very simple > problem. > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > create OTN > > > > > > hierarchies and constrain LO connections to HO containers, > one > > > needs to > > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > other > > > > > > interested experts, and we think the proposal described in > > > "draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > more > > > feasible > > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > for > > > control > > > > > > plane, no matter how you encode the routing information. For > TDM > > > networks, > > > > > > you know the resource is allocated based on TS, so the > available > > > TS should > > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > information, > > > I think > > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > you > > > will find > > > > > > that one of your suggestions is adopted (i.e., simply > advertize > > > the > > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances). > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as > FA > > > for ODU1, > > > > > > you have to advertise a new TE link or put this FA as a > component > > > link of > > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > Cc: >; ccamp- > > > gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > To: Snigdho Bardalai > > > > > > > Cc: ccamp@ietf.org ; draft-ietf- > ccamp- > > > gmpls- > > > > > > g709-framework@tools.ietf.org > > g709- > > > > > > framework@tools.ietf.org> > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > I believe there has been some off-line discussion on how to > > > better > > > > > > > align the work with 4202. Use of common approaches is of > > > course one of > > > > > > > the main objectives of *C*CAMP. I look forward to hearing > from > > > the > > > > > > > draft and discussion contributors on there progress on this > > > point. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > >> Hello, > > > > > > >> > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > section > > > > > > >> describes the link-parameters that are required for OTN > > > service routing > > > > > > >> purposes. > > > > > > >> > > > > > > >> My comment is how are we going to advertise the low-order > ODUj > > > > > > >> availability within a higher-order container. For example, > > > consider an > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > then > > > we > > > > > > >> establish an ODU2 service over the link. At this point in > time > > > the OTU3 > > > > > > >> link has 12 time-slots available for ODU2 services and up > to > > > 12+4 > > > > > > >> time-slots available for ODU1 services (4 ODU1s are > contained > > > over the > > > > > > >> ODU2). So it is obvious from this example that the number > of > > > time-slots > > > > > > >> available is different based on the signal-type (i.e. ODU1 > and > > > ODU2). > > > > > > >> How do we address this issue based on the approach > specified > > > in the > > > > > > draft? > > > > > > >> > > > > > > >> My other question is why not simply advertize the > available > > > number of > > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > equivalent > > > > > > >> bandwidth in bytes/sec within a link? This approach seems > to > > > be more > > > > > > >> in-line with the general approach outlined in RFC-4202. > Refer > > > to > > > > > > section > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > being > > > > > > >> advertised per VC rate for an SDH link. The additional > benefit > > > is that > > > > > > >> the advertisement is TS size independent and hence will > > > simplify the > > > > > > >> implementation. > > > > > > >> > > > > > > >> Regards > > > > > > >> > > > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 13:26:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A523A67BD for ; Tue, 20 Jul 2010 13:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[AWL=-2.693, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, MANGLED_INCLDN=2.3, MANGLED_LINKS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKsP08Uf7+Kv for ; Tue, 20 Jul 2010 13:26:23 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 01A013A63EC for ; Tue, 20 Jul 2010 13:26:22 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KKQRrJ004767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 22:26:28 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 22:26:27 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 20 Jul 2010 22:26:27 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 16:26:24 -0400 From: Igor Bryskin To: "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 16:26:04 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuA Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> In-Reply-To: <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:26:26 -0000 Curtis, Igor, > > Would you not need percentage per priority per signal-type? > > Regards > Snigdho You would if you wanted to be able to preempt LSPs, therefore you do. I take it that was a rhetorical question for which you knew the answer already but I fell for it and answered. :-) Curtis IB>> The question is not rhetorical. Keep in mind that this information is = only needed for concurrent path computations performed on the same node. Fo= r example, a link has failed and *all* LSPs going through the link are orig= inated on the same NE, and the NE is trying to reroute all of them concurre= ntly. I don't think you will want to preempt other connections knowing that= it may not help, because at the same time other NEs (terminating other LSP= s going over the failed link) may do the same thing. If you use preemption in this case your restoration will do more harm than = good. In all other case the info does not help much. I think it is Ok to say that= ISDCs share the common pool in, say, 60% to 40% ratio and extrapolate the = ratio for all priority levels. I say it is overkill to partition the unrese= rved bandwidth pool on per priority level. However, if you insist on such p= artitioning then 4203 allows you to expand the IDSC sub-TLV and you can spe= cify the unreserved bandwidth per priority level for every ISCD. Igor > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin w= ro=3D > te: > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However if= a > > TE link advertises more than one ISCD (with each ISCD containing only m= ax > > lsp bandwidth per priority), it is necessary to indicate how the total = li=3D > nk > > unreserved bandwidth is partitioned between several ISCDs. What I am > > suggesting is instead of advertising the unreserved bandwidth multiple = ti=3D > mes > > (one per ISCD), indicate how the bandwidth is split between the ISCDs: = e.=3D > g > > ISCD1 75%, ISCD2 25%. > > > > Igor. > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue= o=3D > f > > partitioning unreserved bandwidth across multiple advertised TDM ISC TL= Vs=3D > is > > actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the M= PL=3D > S > > sub-TLV. My point has been that we have never had a requirement (inclu= di=3D > ng > > SDH/SONET) in the past to advertise unreserved bandwidth by signal type= , =3D > so > > what is special about OTN? > > > > A further point would be that if we do decide that it is necessary to > > advertise unreserved bandwidth by signal type, it should be done in a > > general way and not in an OTN specific manner. (And in fact, the argum= en=3D > ts > > that unreserved bandwidth by signal type needs to be advertised, such a= s =3D > the > > latest e-mail from Curtis, are not OTN specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.c= om > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too expensive. > > > All you need is a way to say how the advertised unreserved bandwidth = is > > > partitioned between ISCDs in case the TE link advertisement contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits ou= t > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising unreserved > > > resources per priority, this leads not to know how many LSPs of a > > > specific signal type can be restored. As example it is possible t= o > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on th= e > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. I= n > > > more complex network scenarios the number of crank-backs can be mu= ch > > > higher." > > > > > > In other words, advertising the number of availble resources per sign= al > > > type does not avoid the possibility of cranck-back but decreases it a= s > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. The > > > cranck-backs due to the concurrent restoration of LSPs originating on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.c= om > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? Thi= s > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth subTLV)= . > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > > IB>> role per (muxCap & signal type) per priority level. However, tot= al > > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework= - > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor extension= s > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap =3D3D role; > > > > > encodeType =3D3D muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, bu= t > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you wouldn'= t > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP (e.= g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor extension= s > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the [draft= - > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The role = is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that m= ay > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can onl= y > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > > role > > > > > of Ho ODU level is requested, according to your statement, this > > > > > conneciton will be allowed to be created. However, it should not = be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through B= 11 > > > > and > > > > > B12. If one circumvents the path computation by providing the ful= ly > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators c= an > > > > > define different roles depending on their policy and achieve the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views t= he > > > > > network as a stack of topologies. Whether a given topology is rea= l > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_L= O- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack o= f > > > > > topologies that could be easily separated in technology independe= nt > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop (= as > > > > > some people seem to believe). The role is only meaningful on the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the same > > > > > for all ODUs that comprise the topology. For, example a user may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients to > > > use > > > > > the topology rather than any resources available on OTN network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as th= e > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > =3D3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the hiera= rchy, > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 a= s > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case= , > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the OD= U > > > > > terminating nodes (i.e. on either side of corresponding link). Wh= at > > > > > happens on the ODU transit nodes and its place in the hierarchy o= n > > > > the > > > > > transit nodes are of no importance. My LO container can be carrie= d > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along i= ts > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > =3D3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities c= an > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > > required); 4. The combination of swicthcaps and encoding type wil= l > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre-configure= d > > > > > topology with a specific role (e.g. constrain all ODUs it sells t= o > > > > the > > > > > clients to one or more pre-configured LO topologies), this would = be > > > > > possible to do in a technology independent way. Suppose an instan= ce > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO O= TN > > > > > links will be no different from the separation of WDM links from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make t= he > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which ha= d > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long ti= me > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did no= t > > > > > understand what the TS type meant did not try to multiplex its LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO = or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of the > > > LSP > > > > > regardless of what goes on in the middle since that determines wh= at > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 or OD= Uj=3D3Df=3D > lex > > > > > even though the ODUk=3D3D2 at the next hop could not directly con= tain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two leve= ls > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Swit= ch > > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on th= is > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not su= re > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework= , > > > > > or other intent. Could someone (either draft) concisely summariz= e > > > > > the multiplexing restrictions in one place, including restriction= s > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] = On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the framew= ork > > > > > > > document before we can embark on any proposals to the problem= . > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer contro= l > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to invent = an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, on= e > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is mo= re > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed fo= r > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., simp= ly > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as = FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" = > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there progres= s > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on t= he > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach specifi= ed > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the availabl= e > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances = or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general approac= h > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The addition= al > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence wi= ll > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 13:32:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D443A691D for ; Tue, 20 Jul 2010 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB-eNkrCKPoh for ; Tue, 20 Jul 2010 13:32:13 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id D9E573A6950 for ; Tue, 20 Jul 2010 13:32:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYHy0kCpfTesKGJhYcnxJSQ2tuy/Ek8@postini.com; Tue, 20 Jul 2010 13:32:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 20 Jul 2010 13:28:06 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" Date: Tue, 20 Jul 2010 13:28:04 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQdxVh5yfH6xgTB6HKnuuZvTiXgAAJ0HgAAGL8BA= Message-ID: <5E893DB832F57341992548CDBB333163984487CAC8@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 12:16:17 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <201007201929.o6KJTBMa066582@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:32:19 -0000 Igor, It is quite possible for a node to concurrently switch both PSC and TDM LSP= s. (Or TDM and Lambda LSPs.) That is why the TLV is called ISCD and why m= ultiple of them may be advertised for all of that node's links. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 12:44 PM > To: curtis@occnc.com > Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Curtis, > > When a link advertises two ISCDs it means that it is immediately ready > to accept an LSP of any type. Hence the TDM+PSC-4 advertisement (albeit > allowed) does not make any practical sense to me. You need, first, > create a TDM LSP, advertise it as an FA and use FA as a link (which is > likely to be a different link, because, for example, it will have a > different remote end) for PSC-4 LSP. However, if an OTN link advertises > two IDSCc - OTN_LO and OTN_HO - it is quite a different ball game. It > will mean that the link could participate in the two topologies > immediately. > > Igor > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 3:29 PM > To: Igor Bryskin > Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However > > if a TE link advertises more than one ISCD (with each ISCD containing > > only max lsp bandwidth per priority), it is necessary to indicate how > > the total link unreserved bandwidth is partitioned between several > > ISCDs. What I am suggesting is instead of advertising the unreserved > > bandwidth multiple times (one per ISCD), indicate how the bandwidth > is > > split between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > > > Igor. > > > Igor, > > If there are two ISCs and nothing reserved, then there is one FA. One > ISC is always lower in the hierarchy than the other. Consider the > TDM+LSR example in RFC4202 and assume the exact advertisement is > TDM+PSC-4. If a 1Gb/s PSC-3 LSP from far away is created on a STM64 > and uses an STM16 worth of bandwidth, then the original FA has 75% > reservable and there is a new PSC-4 only FA with 2.5G and 1.5G > reservable. The new PSC-4 FA can take more PSC-3 but not more TDM. > The original TDM+PSC-4 FA can take 7.5G of TDM or PSC capacity. The > far away LSR would advertise a PSC-3 FA. > > The same should apply to the above example if an STM16 was added from > a far away LSR. A new FA would be created at STM16 advertised by the > new TDM LSP ingress. The old FA would now have 75% remaining for > either TDM or PSC-4. > > Of course with 75% remaining it may not be possible to create a 5 Gb/s > PSC LSP if it is not possible to link bundle two PSC-4 each over a > STM16, but that brings us into the realm of discussing multipath (or > pointing out that maxlsp can be set to 2.5G and avoid it). > > BTW- I am wondering what TDM capable LSR in the field actually do if > this is not what they do. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue of partitioning unreserved bandwidth across multiple advertised > TDM ISC TLVs is actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the > MPLS sub-TLV. My point has been that we have never had a requirement > (including SDH/SONET) in the past to advertise unreserved bandwidth by > signal type, so what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary to > advertise unreserved bandwidth by signal type, it should be done in a > general way and not in an OTN specific manner. (And in fact, the > arguments that unreserved bandwidth by signal type needs to be > advertised, such as the latest e-mail from Curtis, are not OTN > specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > partitioned between ISCDs in case the TE link advertisement > contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits > out > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising > unreserved > > > resources per priority, this leads not to know how many LSPs of > a > > > specific signal type can be restored. As example it is possible > to > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on > the > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a > MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. > In > > > more complex network scenarios the number of crank-backs can be > much > > > higher." > > > > > > In other words, advertising the number of availble resources per > signal > > > type does not avoid the possibility of cranck-back but decreases it > as > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. > The > > > cranck-backs due to the concurrent restoration of LSPs originating > on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=EC 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > IB>> role per (muxCap & signal type) per priority level. However, > total > > > IB>> unreserved bandwidth IMO is OK to share between roles unless > you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: luned=EC 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap =3D role; > > > > > encodeType =3D muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific > info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, > but > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP > (e.g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text > to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The > role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that > may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > role > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and > B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through > B11 > > > > and > > > > > B12. If one circumvents the path computation by providing the > fully > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators > can > > > > > define different roles depending on their policy and achieve > the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > the > > > > > network as a stack of topologies. Whether a given topology is > real > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > of > > > > > topologies that could be easily separated in technology > independent > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop > (as > > > > > some people seem to believe). The role is only meaningful on > the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the > same > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > use > > > > > the topology rather than any resources available on OTN > network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as > the > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy= , > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > as > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > ODU > > > > > terminating nodes (i.e. on either side of corresponding link). > What > > > > > happens on the ODU transit nodes and its place in the hierarchy > on > > > > the > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > its > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" > ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities > can > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD > is > > > > > required); 4. The combination of swicthcaps and encoding type > will > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > topology with a specific role (e.g. constrain all ODUs it sells > to > > > > the > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > possible to do in a technology independent way. Suppose an > instance > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO > OTN > > > > > links will be no different from the separation of WDM links > from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which > had > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long > time > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > not > > > > > understand what the TS type meant did not try to multiplex its > LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can > be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > LSP > > > > > regardless of what goes on in the middle since that determines > what > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3D3 -------------- > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or > ODUj=3Dflex > > > > > even though the ODUk=3D2 at the next hop could not directly > contain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either > one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > this > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the > framework > > > > > > > document before we can embark on any proposals to the > problem. > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, > one > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal > described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > more > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > for > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on > TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating > cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as > a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how > to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on > the > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach > specified > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence > will > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 13:39:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52573A67BD for ; Tue, 20 Jul 2010 13:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PczWMWcm+LFO for ; Tue, 20 Jul 2010 13:39:11 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C0DC83A65A5 for ; Tue, 20 Jul 2010 13:39:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYJZUZwfnSzqfuBe/H8VciWP7cTwE1t@postini.com; Tue, 20 Jul 2010 13:39:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 20 Jul 2010 13:35:28 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 13:35:26 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarA= Message-ID: <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:39:14 -0000 Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? You= do not advertise unreserved bandwidth in the ISCD TLV. In particular, for= TDM, what is advertised is the max and min bandwidth allowed for a single = LSP. It was designed to produce a compact representation by taking advanta= ge of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but wasteful= . > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level. However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; > > > > > > We also have 16 reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > > computation is constrained to the OTN_HO_SC topology, B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ; > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > > capability field (confusing name as it is) is a good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > > >TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > > >> example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 13:54:23 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC013A6902 for ; Tue, 20 Jul 2010 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSOYotX8Bfxj for ; Tue, 20 Jul 2010 13:54:20 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 475673A65A5 for ; Tue, 20 Jul 2010 13:54:18 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KKsSoF010419 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 22:54:28 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 22:54:28 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 16:54:25 -0400 From: Igor Bryskin To: John E Drake , "curtis@occnc.com" Date: Tue, 20 Jul 2010 16:54:23 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQdxVh5yfH6xgTB6HKnuuZvTiXgAAJ0HgAAGL8BAAANrT4A== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761ED@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 12:16:17 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <201007201929.o6KJTBMa066582@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CAC8@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487CAC8@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:54:23 -0000 John, > It is quite possible for a node to concurrently switch both PSC and TDM L= SPs. (Or > TDM and Lambda LSPs.) That is why the TLV is called ISCD and w= hy multiple of them > may be advertised for all of that node's links. IB>> It is possible from the RFC4203 point of view. What I am saying is tha= t it is not practical to advertise for the same link both TDM and PSC ISCDs= . It is only possible when: a) TDM topology and PSC topology are congruent (at least partially); b) TDM topology and PSC topology share the same address space; c) TDM and PSC share the same routing instance. Igor Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 12:44 PM > To: curtis@occnc.com > Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Curtis, > > When a link advertises two ISCDs it means that it is immediately ready > to accept an LSP of any type. Hence the TDM+PSC-4 advertisement (albeit > allowed) does not make any practical sense to me. You need, first, > create a TDM LSP, advertise it as an FA and use FA as a link (which is > likely to be a different link, because, for example, it will have a > different remote end) for PSC-4 LSP. However, if an OTN link advertises > two IDSCc - OTN_LO and OTN_HO - it is quite a different ball game. It > will mean that the link could participate in the two topologies > immediately. > > Igor > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 3:29 PM > To: Igor Bryskin > Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However > > if a TE link advertises more than one ISCD (with each ISCD containing > > only max lsp bandwidth per priority), it is necessary to indicate how > > the total link unreserved bandwidth is partitioned between several > > ISCDs. What I am suggesting is instead of advertising the unreserved > > bandwidth multiple times (one per ISCD), indicate how the bandwidth > is > > split between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > > > Igor. > > > Igor, > > If there are two ISCs and nothing reserved, then there is one FA. One > ISC is always lower in the hierarchy than the other. Consider the > TDM+LSR example in RFC4202 and assume the exact advertisement is > TDM+PSC-4. If a 1Gb/s PSC-3 LSP from far away is created on a STM64 > and uses an STM16 worth of bandwidth, then the original FA has 75% > reservable and there is a new PSC-4 only FA with 2.5G and 1.5G > reservable. The new PSC-4 FA can take more PSC-3 but not more TDM. > The original TDM+PSC-4 FA can take 7.5G of TDM or PSC capacity. The > far away LSR would advertise a PSC-3 FA. > > The same should apply to the above example if an STM16 was added from > a far away LSR. A new FA would be created at STM16 advertised by the > new TDM LSP ingress. The old FA would now have 75% remaining for > either TDM or PSC-4. > > Of course with 75% remaining it may not be possible to create a 5 Gb/s > PSC LSP if it is not possible to link bundle two PSC-4 each over a > STM16, but that brings us into the realm of discussing multipath (or > pointing out that maxlsp can be set to 2.5G and avoid it). > > BTW- I am wondering what TDM capable LSR in the field actually do if > this is not what they do. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue of partitioning unreserved bandwidth across multiple advertised > TDM ISC TLVs is actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the > MPLS sub-TLV. My point has been that we have never had a requirement > (including SDH/SONET) in the past to advertise unreserved bandwidth by > signal type, so what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary to > advertise unreserved bandwidth by signal type, it should be done in a > general way and not in an OTN specific manner. (And in fact, the > arguments that unreserved bandwidth by signal type needs to be > advertised, such as the latest e-mail from Curtis, are not OTN > specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > partitioned between ISCDs in case the TE link advertisement > contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits > out > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising > unreserved > > > resources per priority, this leads not to know how many LSPs of > a > > > specific signal type can be restored. As example it is possible > to > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on > the > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a > MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. > In > > > more complex network scenarios the number of crank-backs can be > much > > > higher." > > > > > > In other words, advertising the number of availble resources per > signal > > > type does not avoid the possibility of cranck-back but decreases it > as > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. > The > > > cranck-backs due to the concurrent restoration of LSPs originating > on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=EC 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > IB>> role per (muxCap & signal type) per priority level. However, > total > > > IB>> unreserved bandwidth IMO is OK to share between roles unless > you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: luned=EC 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap =3D role; > > > > > encodeType =3D muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific > info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, > but > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP > (e.g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text > to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The > role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that > may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > role > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and > B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through > B11 > > > > and > > > > > B12. If one circumvents the path computation by providing the > fully > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators > can > > > > > define different roles depending on their policy and achieve > the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > the > > > > > network as a stack of topologies. Whether a given topology is > real > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > of > > > > > topologies that could be easily separated in technology > independent > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop > (as > > > > > some people seem to believe). The role is only meaningful on > the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the > same > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > use > > > > > the topology rather than any resources available on OTN > network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as > the > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role =3D=3D position in the hierarchy= , > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > as > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > ODU > > > > > terminating nodes (i.e. on either side of corresponding link). > What > > > > > happens on the ODU transit nodes and its place in the hierarchy > on > > > > the > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > its > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" > ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities > can > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD > is > > > > > required); 4. The combination of swicthcaps and encoding type > will > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > topology with a specific role (e.g. constrain all ODUs it sells > to > > > > the > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > possible to do in a technology independent way. Suppose an > instance > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO > OTN > > > > > links will be no different from the separation of WDM links > from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which > had > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long > time > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > not > > > > > understand what the TS type meant did not try to multiplex its > LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can > be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > LSP > > > > > regardless of what goes on in the middle since that determines > what > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3D3 -------------- > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or > ODUj=3Dflex > > > > > even though the ODUk=3D2 at the next hop could not directly > contain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either > one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > this > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the > framework > > > > > > > document before we can embark on any proposals to the > problem. > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, > one > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal > described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > more > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > for > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on > TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating > cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as > a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how > to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on > the > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach > specified > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence > will > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho From gregimirsky@gmail.com Tue Jul 20 13:59:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAF93A6891 for ; Tue, 20 Jul 2010 13:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKa9RoeFjaay for ; Tue, 20 Jul 2010 13:59:41 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3B9303A65A5 for ; Tue, 20 Jul 2010 13:59:41 -0700 (PDT) Received: by vws13 with SMTP id 13so1021010vws.31 for ; Tue, 20 Jul 2010 13:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qCRguUdEBm8ktn8dlB/l/IIVlQEKBiV35u5gEk8CBiw=; b=KbwPIPuI4T2+yuNuGDjI0CIK154ktE//WmqqQhmKyoZmh2yj77nflEOZwxaJLi74uf L1MvCIer4fMZrnqrOEjM4/lGtUwGAXeJ0ivULd1eHtOwrhDg8RbTHRxTE5gbkbeoTam+ FWPsnsGfM0iOcW7ClF57tfJmD4qRlnJYgm18I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CMQNa96BY+VhKZmYbkNvXQb25weKo7TcPQY+1kWC88fRAl5rQjW/OGAlmkgJtdtujB g5vWLc17W7I+Rhi/pAasdJqK3nluYnYWqCOLBnRvReUm4mppdaADhUNqNgZsXxwR/9vK fR5O0xMDoifXfTL5ve9jNYMon50pYB+WVbeVg= MIME-Version: 1.0 Received: by 10.220.90.212 with SMTP id j20mr4483533vcm.67.1279659596083; Tue, 20 Jul 2010 13:59:56 -0700 (PDT) Received: by 10.220.86.72 with HTTP; Tue, 20 Jul 2010 13:59:55 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163984487CA7D@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01-HQ.jnpr.net> <201007201939.o6KJdbJF066724@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163984487CA7D@EMBX01-HQ.jnpr.net> Date: Tue, 20 Jul 2010 13:59:55 -0700 Message-ID: From: Greg Mirsky To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Snigdho Bardalai , "ccamp@ietf.org" , Igor Bryskin , Lou@core3.amsl.com Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:59:44 -0000 Dear John, > What I was trying to point out was that unless an intermediate node issue= s a new advertisement every it activates or deactivates an LSP across its l= inks, the state of its links in its last advertisement may be very differen= t from its current state, and that hence an ingress node does not have a re= liable indication of that state. I think that this is the case, certain lagging behind between allocated BW and knowledge of it in the ingress or any other node in the network, in general and not unique to this scenario. Regards, Greg On Tue, Jul 20, 2010 at 1:17 PM, John E Drake wrote: > > >> -----Original Message----- >> From: curtis@occnc.com [mailto:curtis@occnc.com] >> Sent: Tuesday, July 20, 2010 12:40 PM >> To: John E Drake >> Cc: curtis@occnc.com; Fatai Zhang; Igor Bryskin; Snigdho Bardalai; Lou >> Berger; ccamp@ietf.org >> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- >> 01.txt >> >> >> In message <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01- >> HQ.jnpr.net> >> John E Drake writes: >> > >> > Curtis, >> > >> > Unless you are proposing to issue a new advertisement every time an >> > LSP is activated or deactivated, which has issues of its own, you >> will >> > be dealing with thresholding so what is being advertised is only an >> > approximation (e.g., advertise 5 ODUj if the unreserved bandwidth is >> > between 0 ODUj and 10 ODUj), so you will never know with certainty >> > whether a given LSP can be activated until you try to activate it. >> > >> > Thanks, >> > >> > John >> >> >> John, >> >> When you create a new LSP you must deduct from the existing FA and >> create an FA for the new LSP. =A0The endpoints of the new LSP may not be >> the same as the endpoints of the old FA, more likely it is just a hop >> along the way. >> >> Curtis > > JD: =A0I agree with what you wrote, above, but I am not sure what it has = to do with my e-mail. > > The question we have been discussing is whether an intermediate node shou= ld be advertising the total unreserved bandwidth or unreserved bandwidth by= service category for each of its links. =A0I thought your e-mail indicated= support for the latter position. > > What I was trying to point out was that unless an intermediate node issue= s a new advertisement every it activates or deactivates an LSP across its l= inks, the state of its links in its last advertisement may be very differen= t from its current state, and that hence an ingress node does not have a re= liable indication of that state. > > The example I used was that what was advertised for a given link was 5 OD= Uj, even though the current unreserved bandwidth for ODUj is anywhere in th= e range 0 ODUj to 10 ODUj. > > I.e., advertising unreserved bandwidth by service category gives a false = sense of security wrt the distributed awareness of the current state of the= network. > >> >> >> > > -----Original Message----- >> > > From: curtis@occnc.com [mailto:curtis@occnc.com] >> > > Sent: Tuesday, July 20, 2010 7:52 AM >> > > To: Fatai Zhang >> > > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; >> Lou >> > > Berger; ccamp@ietf.org >> > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> framework- >> > > 01.txt >> > > >> > > >> > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> >> > > Fatai Zhang writes: >> > > > >> > > > Hi Igor, >> > > > >> > > > Thanks. >> > > >> > > Sorry to jump in but I think I understand Igor's objection (and >> > > Snigdho's objection, and the reason this thread is going on). >> > > >> > > > I understand what you said. Therefore, we have added some text to >> > > > address the requirment in FWK document. However, we still don't >> think >> > > > that we need to extend ISC to meet the requirment. The role of >> the >> > > ODU >> > > > can be get from the routing information implicitly. In the >> > > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of >> "Full >> > > > Lambda" is introduced. >> > > > >> > > > A quick question on your statement: "the role of an ODU container >> > > does >> > > > not change hop-by-hop (as some people seem to believe). The role >> is >> > > > only meaningful on the ODU terminating nodes and irrelevant on >> > > transit >> > > > nodes. It is it's position in the hierarchy (but not role) that >> may >> > > > change hop-by-hop. " >> > > > >> > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and >> CI1 >> > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only >> > > support >> > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the >> > > role >> > > > of Ho ODU level is requested, according to your statement, this >> > > > conneciton will be allowed to be created. However, it should not >> be >> > > > allowed because the ISC is not consistent along the LSP. >> > > > >> > > > Please see the text from RFC3473: "Nodes MUST verify that the >> type >> > > > indicated in the Switching Type parameter is supported on the >> > > > corresponding incoming interface. =A0If the type cannot be >> supported, >> > > > the node MUST generate a PathErr message with a "Routing >> > > > problem/Switching Type" indication." >> > > >> > > I think the objection, which would be a very valid one, is that the >> > > ingress has no way to know apriori that a path is infeasible. =A0Eac= h >> > > crankback delays convergence. =A0Crankback should only occur if >> another >> > > ingress has reserved resources before signaling was completed, not >> > > because inadequate routing information is provided in quiescent >> state. >> > > >> > > Curtis >> > > >> > > >> > > > Best Regards >> > > > >> > > > Fatai >> > > > >> > > > ----- Original Message ----- >> > > > From: "Igor Bryskin" >> > > > To: "Fatai Zhang" ; >> > > > Cc: "John E Drake" ; "Snigdho Bardalai" >> > > ; "Lou Berger" ; >> > > ; > > > framework@tools.ietf.org> >> > > > Sent: Friday, July 16, 2010 12:34 AM >> > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework-01.txt >> > > > >> > > > >> > > > Fatai, >> > > > Please, see my answers in line. >> > > > >> > > > -----Original Message----- >> > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] >> > > > Sent: Wednesday, July 14, 2010 9:52 PM >> > > > To: Igor Bryskin; curtis@occnc.com >> > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; >> > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org >> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework-01.txt >> > > > >> > > > Hi Igor and all, >> > > > >> > > > Thanks for all your comments. >> > > > >> > > > I think role does not equal switching capability. The operators >> can >> > > define different roles depending on their policy and achieve the >> role >> > > through different methods. However, for OTN networks, the >> containers >> > > (e.g., ODUk) all have the same switching capablility (i.e., TDM >> > > switching) and I think we should reflect the natural >> characteristics of >> > > links in the routing. In addition, if we extend the ISC, it will >> make >> > > the encoding type lose its' own meaning(ie., ISC overrides encoding >> > > type). >> > > > >> > > > IB>> When a GMPLS CP instance controls several layers, it views >> the >> > > network as a stack of topologies. Whether a given topology is real >> or >> > > virtual is of no importance. >> > > > The GMPLS ISCD link sub-tlv and, in particular, its switching >> > > capability field (confusing name as it is) is a good way to >> describe a >> > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- >> > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of >> > > topologies that could be easily separated in technology independent >> way >> > > should path computation be constrained to particular one or sub- >> stack >> > > of them. >> > > > I think a good way to identify an OTN (virtual) topology is via >> > > (infrastructure) ODU container role of ODUs comprising the >> topology. >> > > BTW IMO the role of an ODU container does not change hop-by-hop (as >> > > some people seem to believe). The role is only meaningful on the >> ODU >> > > terminating nodes and irrelevant on transit nodes. It is it's >> position >> > > in the hierarchy (but not role) that may change hop-by-hop. ODU's >> role >> > > is the level of topology it is provisioned for and it is the same >> for >> > > all ODUs that comprise the topology. For, example a user may >> provision >> > > a LO topology and constrain ODUs he sells to a set of clients to >> use >> > > the topology rather than any resources available on OTN network. >> > > > The bottom line: container's role is the same as the role of >> virtual >> > > topology the container is a part of and could be advertised as the >> > > corresponding link switchcap. >> > > > >> > > > According to the point 3, I don't know how to advertise the roles >> and >> > > muxing capabilities with the ISCD of RFC4202, could you clarify? >> > > > >> > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) >> > > > =A0 =A0 =A0encoding type =3D mux. capabilities code >> > > > >> > > > In addition, could you clarify my questions in another email >> (copied >> > > as follows): >> > > > >> > > >> =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> > > > For =A0Lo ODU, Ho ODU, SHO ODU, they are relative to each other. >> > > > IB>> I disagree. You define role =3D=3D position in the hierarchy, >> which >> > > is a mistake IMO. >> > > > >> > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 >> as Ho >> > > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 >> link >> > > supporting ODU2 switching, which can be used as Lo ODU2 (service >> over >> > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, >> how >> > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? >> > > > >> > > > IB>> As I mentioned earlier, ODU role is only important on the >> ODU >> > > terminating nodes (i.e. on either side of corresponding link). What >> > > happens on the ODU transit nodes and its place in the hierarchy on >> the >> > > transit nodes are of no importance. My LO container can be carried >> by >> > > somebody else's LO container and can carry my client's LO >> container. To >> > > some extent it is similar to MPLS LSP role: LSP always has a role >> (e.g. >> > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its >> > > path. >> > > > >> > > > Cheers, >> > > > Igor >> > > > >> > > > >> > > >> =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=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=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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> > > > >> > > > >> > > > >> > > > Thanks >> > > > >> > > > Fatai >> > > > >> > > > ----- Original Message ----- >> > > > From: "Igor Bryskin" >> > > > To: >> > > > Cc: "John E Drake" ; "Snigdho Bardalai" >> > > ; "Fatai Zhang" ; >> "Lou >> > > Berger" ; ; > gmpls- >> > > g709-framework@tools.ietf.org> >> > > > Sent: Wednesday, July 14, 2010 10:36 PM >> > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework-01.txt >> > > > >> > > > >> > > > Curtis, >> > > > >> > > > Thanks for your comment. >> > > > >> > > > I agree that there should be multiple OTN specific encoding types >> > > introduced. But IMO they should indicate the link's mux >> capabilities >> > > rather than the link's role (i.e. level in the OTN hierarchy: LO, >> HO, >> > > SHO, etc.). The link's role or roles IMO should be indicated with a >> > > separate switchcaps. I can give you several reasons: >> > > > >> > > > 1. Links with the same mux capabilities may have different roles; >> > > > 2. Link may advertise several roles (e.g. HO and SHO) with >> different >> > > mux.capabilities per role; >> > > > 3. Link's role and mux. capabilities can be advertised with ISCDs >> as >> > > defined in RFC4202 (no OTN-style ISCD is required); >> > > > 4. The combination of swicthcaps and encoding type will look to >> CP as >> > > a separate layer, which is exactly how ITU models OTN hierarchies >> in >> > > all aspects but routing (!?) >> > > > 5. If the operator would want to constrain the routing of OTN >> > > connections to pre-configured topology with a specific role (e.g. >> > > constrain all ODUs it sells to the clients to one or more pre- >> > > configured LO topologies), this would be possible to do in a >> technology >> > > independent way. Suppose an instance of GMPLS CP manages WDM and >> OTN >> > > NEs. Then separation of LO from HO OTN links will be no different >> from >> > > the separation of WDM links from OTUs. >> > > > >> > > > Cheers, >> > > > Igor >> > > > >> > > > -----Original Message----- >> > > > From: curtis@occnc.com [mailto:curtis@occnc.com] >> > > > Sent: Tuesday, July 13, 2010 6:24 PM >> > > > To: Igor Bryskin >> > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; >> > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- >> framework@tools.ietf.org >> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework-01.txt >> > > > >> > > > >> > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- >> > > exgen.atl.advaoptical.com> >> > > > Igor Bryskin writes: >> > > > > >> > > > > I think OTN links require more than one switchcaps: as many as >> the >> > > depth of the deepest possible OTN DP hierarchy, for example: >> > > > > >> > > > > typedef enum >> > > > > { >> > > > > =A0 =A0LSPSwitchType_Unknown =3D0 =A0 =A0 =A0 =A0 =A0 =A0/* Unkn= own */ >> > > > > =A0 =A0, LSPSwitchType_PSC_1 =3D1 =A0 =A0 =A0 =A0 =A0 =A0/* PSC-= 1 */ >> > > > > =A0 =A0, LSPSwitchType_PSC_2 =3D2 =A0 =A0 =A0 =A0 =A0 =A0/* PSC-= 2 */ >> > > > > =A0 =A0, LSPSwitchType_PSC_3 =3D3 =A0 =A0 =A0 =A0 =A0 =A0/* PSC-= 3 */ >> > > > > =A0 =A0, LSPSwitchType_PSC_4 =3D4 =A0 =A0 =A0 =A0 =A0 =A0/* PSC-= 4 */ >> > > > > =A0 =A0, LSPSwitchType_L2SC =A0=3D50 =A0 =A0 =A0 =A0 =A0 /* L2SC= */ >> > > > > =A0 =A0, LSPSwitchType_TDM =A0 =3D100 =A0 =A0 =A0 =A0 =A0/* TDM = */ >> > > > > >> > > > > /*****/ >> > > > > =A0 =A0, LSPSwitchType_OTN_LO=3D124 =A0 /* OTN low order */ >> > > > > =A0 =A0, LSPSwitchType_OTN_HO=3D125 =A0 /* OTN high order */ >> > > > > =A0 =A0, LSPSwitchType_OTN_SHO=3D126 =A0/* OTN super high order = */ >> > > > > /*****/ >> > > > > =A0 =A0, LSPSwitchType_LSC =A0 =3D150 =A0 =A0 =A0 =A0 =A0/* LSC = */ >> > > > > =A0 =A0, LSPSwitchType_FSC =A0 =3D200 =A0 =A0 =A0 =A0 =A0/* FSC = */ >> > > > > }e_LSPSwitchType; >> > > > >> > > > >> > > > It would be better IMHO to keep the Switch Type as TDM and make >> the >> > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. >> > > > >> > > > This would replace the 20006 OTN Encoding Type for G.709 Digital >> Path >> > > > layer and G.709 Optical Channel layer for 2009 OTN, which had in >> turn >> > > > replaced the Encoding Type of "Digital Wrapper" a long time ago. >> > > > >> > > > Replacing the Encoding Type would insure that any LSR that did >> not >> > > > understand what the TS type meant did not try to multiplex its LO >> ODU >> > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to >> > > using >> > > > a 1.25 TS granularity for another LO ODU. >> > > > >> > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO >> or >> > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the >> > > latter >> > > > is for backward compatibility and should be ignored if OTN_LO, >> OTN_HO >> > > > or OTN_SHO is understood. =A0If the LSR commits to 1.25 TS >> granularity, >> > > > then the corresponding G.709 Digital Path FA can be withdrawn. >> > > > >> > > > The Encoding type would be the lower encoding at each end of the >> LSP >> > > > regardless of what goes on in the middle since that determines >> what >> > > > can be wrapped inside it. >> > > > >> > > > For example: >> > > > >> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 OTU3 >> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 OTU2 =A0 =A0 =A0ODUk=3D3 -------------= - >> > > > =A0 =A0OTU1 =A0 =A0 =A0 ODUk=3D2 -- ODUj=3D2 >> > > > =A0 =A0ODUk=3D1 --- ODUj=3D1 -- >> > > > >> > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or ODUj=3D= flex >> even >> > > > though the ODUk=3D2 at the next hop could not directly contain an >> ODU0. >> > > > If the SHO Encoding Type is used, then it indicates that two >> levels >> > > of >> > > > multiplexing could be supported at that switch/LSR. >> > > > >> > > > The nominal bytes/sec rates can still be provided. =A0RFC 4328 >> Switch >> > > > Types currently don't include an ODUj or ODUk distinction but if >> > > > Encoding Type indicated LO or HO, that may not be needed. =A0Along >> with >> > > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU- >> flex, >> > > > and ODU2e, can be added. >> > > > >> > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not >> > > clear >> > > > how in an FA it can be indicated that either type is currently >> > > > available (NE capable of both and hasn't committed to either one >> > > yet). >> > > > >> > > > BTW- Maybe I'm missing something but the number of messages on >> this >> > > > would indicate a huge controversy and I'm not getting it (other >> than >> > > a >> > > > strong preference to rely on bytes/sec or on enumerated type >> fields). >> > > > >> > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. =A0I'm not >> sure >> > > if >> > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- >> framework, or >> > > > other intent. =A0Could someone (either draft) concisely summarize >> the >> > > > multiplexing restrictions in one place, including restrictions on >> > > > number of multiplexing layers at one LSR. =A0That might help. >> > > > >> > > > Curtis >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: John E Drake [mailto:jdrake@juniper.net] >> > > > > Sent: Thursday, July 08, 2010 1:59 PM >> > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger >> > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- >> > > framework@tools.ietf.org >> > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework-01.txt >> > > > > >> > > > > What do you mean by "different switchcaps"? >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On >> > > Behalf Of >> > > > > > Igor Bryskin >> > > > > > Sent: Thursday, July 08, 2010 10:53 AM >> > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger >> > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- >> > > framework@tools.ietf.org >> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework- >> > > > > > 01.txt >> > > > > > >> > > > > > Snigdho, >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > =D8 =A0I think we need to sort out the issues with the framewo= rk >> > > document >> > > > > > before we can embark on any proposals to the problem. I am >> still >> > > not clear >> > > > > > why do we have to deviate from the general approach that has >> been >> > > > > > established in RFC 4202. >> > > > > > >> > > > > > >> > > > > > >> > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer >> control >> > > plane, and >> > > > > > it is highly desirable to adhere to the layer independent >> > > paradigm of >> > > > > > advertising of TE links, and there is no reason to invent an >> OTN >> > > specific >> > > > > > ISCD. The combination of Switching Capability and Encoding >> type >> > > of RFC4202 >> > > > > > ISCD allows for specifying both multiplexing capabilities and >> OTN >> > > layer >> > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, >> you >> > > have >> > > > > > another reserved 16 bits. >> > > > > > >> > > > > > >> > > > > > >> > > > > > >Additionally, I do not see any reason to advertise a new TE- >> link >> > > to >> > > > > > represent >the low-order ODUj bandwidth within the high-order >> > > containers. >> > > > > > This is simply >blowing up the solution to a very simple >> problem. >> > > > > > >> > > > > > >> > > > > > >> > > > > > IB>> Here I disagree. In order to give a user possibility to >> > > create OTN >> > > > > > hierarchies and constrain LO connections to HO containers, >> one >> > > needs to >> > > > > > advertise OTN links with different switchcaps. >> > > > > > >> > > > > > >> > > > > > >> > > > > > Cheers, >> > > > > > >> > > > > > Igor >> > > > > > >> > > > > > >> > > > > > >> > > > > > Regards >> > > > > > >> > > > > > Snigdho >> > > > > > >> > > > > > >> > > > > > >> > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] >> > > > > > Sent: Wednesday, July 07, 2010 6:33 PM >> > > > > > To: Snigdho Bardalai; Lou Berger >> > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- >> > > framework@tools.ietf.org >> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework- >> > > > > > 01.txt >> > > > > > >> > > > > > >> > > > > > >> > > > > > Hi Snigdho and Lou, >> > > > > > >> > > > > > >> > > > > > >> > > > > > Yes, we have lots of off-line discussions among authors and >> other >> > > > > > interested experts, and we think the proposal described in >> > > "draft- >> > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is >> more >> > > feasible >> > > > > > for OTN networks. >> > > > > > >> > > > > > >> > > > > > >> > > > > > The framework draft just tells you what information needed >> for >> > > control >> > > > > > plane, no matter how you encode the routing information. For >> TDM >> > > networks, >> > > > > > you know the resource is allocated based on TS, so the >> available >> > > TS should >> > > > > > be get or induced before creating cross-connect. >> > > > > > >> > > > > > >> > > > > > >> > > > > > If you are trying to find how to encode the routing >> information, >> > > I think >> > > > > > you need go to the routing drafts (info model and encoding). >> > > > > > >> > > > > > >> > > > > > >> > > > > > If you look at the routing drafts (info model and encoding), >> you >> > > will find >> > > > > > that one of your suggestions is adopted (i.e., simply >> advertize >> > > the >> > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container >> > > instances). >> > > > > > >> > > > > > >> > > > > > >> > > > > > One more thing for your first comment: >> > > > > > >> > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as >> FA >> > > for ODU1, >> > > > > > you have to advertise a new TE link or put this FA as a >> component >> > > link of >> > > > > > an existing TE link (like RFC4206bis). >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Best Regards >> > > > > > >> > > > > > Fatai >> > > > > > >> > > > > > >> > > > > > ----- Original Message ----- >> > > > > > >> > > > > > From: "Snigdho Bardalai" > > > > > > > >> > > > > > >> > > > > > To: "Lou Berger" >> > >> > > > > > >> > > > > > Cc: >; > ccamp- >> > > gmpls- >> > > > > > g709-framework@tools.ietf.org > > > g709- >> > > > > > framework@tools.ietf.org> > >> > > > > > >> > > > > > Sent: Wednesday, July 07, 2010 11:43 PM >> > > > > > >> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- >> > > framework- >> > > > > > 01.txt >> > > > > > >> > > > > > >> > > > > > >> > > > > > > Hi Lou >> > > > > > > >> > > > > > > Thanks, I also would like to hear about the same. >> > > > > > > >> > > > > > > Snigdho >> > > > > > > >> > > > > > > -----Original Message----- >> > > > > > > From: Lou Berger [mailto:lberger@labn.net] >> > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM >> > > > > > > To: Snigdho Bardalai >> > > > > > > Cc: ccamp@ietf.org ; draft-ietf- >> ccamp- >> > > gmpls- >> > > > > > g709-framework@tools.ietf.org > > > g709- >> > > > > > framework@tools.ietf.org> >> > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- >> g709- >> > > framework- >> > > > > > 01.txt >> > > > > > > >> > > > > > > Snigdho, >> > > > > > > I believe there has been some off-line discussion on how to >> > > better >> > > > > > > align the work with 4202. =A0Use of common approaches is of >> > > course one of >> > > > > > > the main objectives of *C*CAMP. =A0I look forward to hearing >> from >> > > the >> > > > > > > draft and discussion contributors on there progress on this >> > > point. >> > > > > > > >> > > > > > > Lou >> > > > > > > >> > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: >> > > > > > >> Hello, >> > > > > > >> >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This >> > > section >> > > > > > >> describes the link-parameters that are required for OTN >> > > service routing >> > > > > > >> purposes. >> > > > > > >> >> > > > > > >> My comment is how are we going to advertise the low-order >> ODUj >> > > > > > >> availability within a higher-order container. For example, >> > > consider an >> > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and >> then >> > > we >> > > > > > >> establish an ODU2 service over the link. At this point in >> time >> > > the OTU3 >> > > > > > >> link has 12 time-slots available for ODU2 services and up >> to >> > > 12+4 >> > > > > > >> time-slots available for ODU1 services (4 ODU1s are >> contained >> > > over the >> > > > > > >> ODU2). So it is obvious from this example that the number >> of >> > > time-slots >> > > > > > >> available is different based on the signal-type (i.e. ODU1 >> and >> > > ODU2). >> > > > > > >> How do we address this issue based on the approach >> specified >> > > in the >> > > > > > draft? >> > > > > > >> >> > > > > > >> My other question is why not simply advertize the >> available >> > > number of >> > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the >> > > equivalent >> > > > > > >> bandwidth in bytes/sec within a link? This approach seems >> to >> > > be more >> > > > > > >> in-line with the general approach outlined in RFC-4202. >> Refer >> > > to >> > > > > > section >> > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs >> being >> > > > > > >> advertised per VC rate for an SDH link. The additional >> benefit >> > > is that >> > > > > > >> the advertisement is TS size independent and hence will >> > > simplify the >> > > > > > >> implementation. >> > > > > > >> >> > > > > > >> Regards >> > > > > > >> >> > > > > > >> Snigdho > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From IBryskin@advaoptical.com Tue Jul 20 14:02:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1BA3A6964 for ; Tue, 20 Jul 2010 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyueUECDPTd3 for ; Tue, 20 Jul 2010 14:02:27 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id F3A663A6899 for ; Tue, 20 Jul 2010 14:02:25 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KL2VOH021743 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 23:02:31 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 23:02:31 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 17:02:28 -0400 From: Igor Bryskin To: John E Drake , "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 17:02:25 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:02:30 -0000 John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved bandwi= dth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? You= do not advertise unreserved bandwidth in the ISCD TLV. In particular, for= TDM, what is advertised is the max and min bandwidth allowed for a single = LSP. It was designed to produce a compact representation by taking advanta= ge of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but wasteful= . > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level. However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; > > > > > > We also have 16 reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > > computation is constrained to the OTN_HO_SC topology, B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ; > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > > capability field (confusing name as it is) is a good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > > >TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > > >> example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 14:08:04 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E963B3A6B63 for ; Tue, 20 Jul 2010 14:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h6DKgLfD4Fp for ; Tue, 20 Jul 2010 14:08:04 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id C9C483A6B61 for ; Tue, 20 Jul 2010 14:08:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYQF0Zpacn4+WAFw8JaFGo4kQxSPeTw@postini.com; Tue, 20 Jul 2010 14:08:19 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Jul 2010 14:04:54 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" Date: Tue, 20 Jul 2010 14:04:52 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQdxVh5yfH6xgTB6HKnuuZvTiXgAAJ0HgAAGL8BAAANrT4AAAq+2Q Message-ID: <5E893DB832F57341992548CDBB333163984487CC22@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 12:16:17 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> <201007201929.o6KJTBMa066582@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CAC8@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761ED@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761ED@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:08:05 -0000 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 1:54 PM > To: John E Drake; curtis@occnc.com > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt >=20 > John, >=20 > > It is quite possible for a node to concurrently switch both PSC and > TDM LSPs. (Or > TDM and Lambda LSPs.) That is why the TLV is called > ISCD and why multiple of them > may be advertised for all of that > node's links. >=20 > IB>> It is possible from the RFC4203 point of view. What I am saying is > that it is not practical to advertise for the same link both TDM and > PSC ISCDs. It is only possible when: > a) TDM topology and PSC topology are congruent (at least partially); > b) TDM topology and PSC topology share the same address space; > c) TDM and PSC share the same routing instance. JD: Correct. From jdrake@juniper.net Tue Jul 20 14:11:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9163A6B40 for ; Tue, 20 Jul 2010 14:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaEukj3lZjgu for ; Tue, 20 Jul 2010 14:11:24 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 114283A6961 for ; Tue, 20 Jul 2010 14:11:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYQ660ebvH816jVQuld3dU64BUDTk3c@postini.com; Tue, 20 Jul 2010 14:11:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Jul 2010 14:09:44 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 14:09:42 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAAasgA Message-ID: <5E893DB832F57341992548CDBB333163984487CC50@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:11:29 -0000 Igor, I was describing SDH/SONET not OTN, I have no idea what you mean by "last f= ield", and I have no idea what you mean by "unresolved bandwidth". John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 2:02 PM > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > Do you understand the quote from RFC4203: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Cap | Encoding | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Capability-specific information | > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > You can use the last field for OTN switchcap to advertise unresolved > bandwidth available for the ISCD on per priority level. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 4:35 PM > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Snipped... > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > priority > > level for every ISCD. > > JD: Igor, what part of my quote from RFC 4202 did you not understand? > You do not advertise unreserved bandwidth in the ISCD TLV. In > particular, for TDM, what is advertised is the max and min bandwidth > allowed for a single LSP. It was designed to produce a compact > representation by taking advantage of the SDH/SONET hierarchy. > > Advertising a separate ISCD for each supported rate is allowed but > wasteful. > > > > > Igor > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > wro=3D > > > te: > > > > > > > John, > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > However if a > > > > TE link advertises more than one ISCD (with each ISCD containing > > only max > > > > lsp bandwidth per priority), it is necessary to indicate how the > > total li=3D > > > nk > > > > unreserved bandwidth is partitioned between several ISCDs. What I > > am > > > > suggesting is instead of advertising the unreserved bandwidth > > multiple ti=3D > > > mes > > > > (one per ISCD), indicate how the bandwidth is split between the > > ISCDs: e.=3D > > > g > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > Igor. > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > Igor, > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > > issue o=3D > > > f > > > > partitioning unreserved bandwidth across multiple advertised TDM > > ISC TLVs=3D > > > is > > > > actually a non-issue. > > > > > > > > Unreserved bandwidth by priority has always been advertised using > > the MPL=3D > > > S > > > > sub-TLV. My point has been that we have never had a requirement > > (includi=3D > > > ng > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > signal > > type, =3D > > > so > > > > what is special about OTN? > > > > > > > > A further point would be that if we do decide that it is > necessary > > to > > > > advertise unreserved bandwidth by signal type, it should be done > in > > a > > > > general way and not in an OTN specific manner. (And in fact, the > > argumen=3D > > > ts > > > > that unreserved bandwidth by signal type needs to be advertised, > > such as =3D > > > the > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > It is a valid point, but the suggested solution is way too > > expensive. > > > > > All you need is a way to say how the advertised unreserved > > bandwidth is > > > > > partitioned between ISCDs in case the TE link advertisement > > contains > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > bits out > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > total > > > > > unreserved bandwidth associated with the ISCD. Another way is > to > > use > > > > > swicthcap specific extension. > > > > > BTW: this is not an OTN specific issue, rather more general: > any > > time > > > > > when a TE link advertises more than one ISCD (which is > perfectly > > Ok > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, > > > > > > > > > > The need for unreserved resources advertised per signal type is > > the > > > > > concurrent path computation. I'll answer quoting a section from > > the > > > > > info-model draft, please have a look in particular to the > > example: > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > and > > per > > > > > signal type in order to allow the correct functioning of the > > > > > restoration process. [RFC4203] only allows advertising > > unreserved > > > > > resources per priority, this leads not to know how many LSPs > > of a > > > > > specific signal type can be restored. As example it is > > possible to > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > +------+ component link 1 +------+ > > > > > | +------------------+ | > > > > > | | component link 2 | | > > > > > | N1 +------------------+ N2 | > > > > > | | component link 3 | | > > > > > | +------------------+ | > > > > > +------+ +---+--+ > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > > with > > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > > on the > > > > > third and supporting ODU2 and ODU3 signal types. The node > > would > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > a > > MAX > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > network > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > only > > a > > > > > single ODU3 can be set up and a crank-back would be > > originated. In > > > > > more complex network scenarios the number of crank-backs can > > be much > > > > > higher." > > > > > > > > > > In other words, advertising the number of availble resources > per > > signal > > > > > type does not avoid the possibility of cranck-back but > decreases > > it as > > > > > much as possible. For sure a good routing prevents from crank- > > backs > > > > > caused by the restoration of LSP originating on the same > Ingress. > > The > > > > > cranck-backs due to the concurrent restoration of LSPs > > originating on > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > BR > > > > > Daniele > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > In line > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, one more question. > > > > > > > > > > What about the unreserved bandwidth? > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > > per > > > > > (muxCap & signal type) you also need to advertise the > unreserved > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > correct? > > This > > > > > also implies extending the unreserved bandwidth TLV so to > create > > a > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > subTLV). > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > ISCD > > per > > > > > IB>> role per (muxCap & signal type) per priority level. > However, > > total > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > unless > > you > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > Igor > > > > > > > > > > Thanks > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Understood... > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > > > That's exactly what I've been > > > > > > trying to say all along. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > > per > > > > > role > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > signal > > > > > type. > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > switchCap =3D3D role; > > > > > > > encodeType =3D3D muxCap & signal type; > > > > > > > We also have 16 reserved bits which can use for OTN > specific > > info > > > > > in > > > > > > > case we need it. > > > > > > [SCB] I am yet to clearly understand what the role of "role" > > is, but > > > > > > agree with your observation on the encode-type and the 16 > > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > > each > > > > > role > > > > > > > you would advertise just the unreserved bandwidth but you > > wouldn't > > > > > > know > > > > > > > if such bandwidth is available for a certain type of ODUj > LSP > > (e.g. > > > > > > 15 > > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > > available > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > scalability > > > > > > issues > > > > > > > and the requirement of being able to bundle component links > > > > > together > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > ISDCs > > > > > will > > > > > > > provide a lot of flexibility: you can specify different > > things > > > > > (e.g. > > > > > > > available bandwidth) for the same link in different roles. > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be > sufficient? > > > > > > > > > > > > > > Cheers, > > > > > > > Daniele > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Igor Bryskin > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Fatai Zhang > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > Thanks. > > > > > > > I understand what you said. Therefore, we have added some > > text to > > > > > > > address the requirment in FWK document. However, we still > > don't > > > > > > > think that we need to extend ISC to meet the requirment. > The > > role > > > > > of > > > > > > > the > > > > > > ODU > > > > > > > can be get from the routing information implicitly. In the > > [draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > "Full > > > > > Lambda" > > > > > > is > > > > > > > introduced. > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > a) this requires OTN specific advertising and processing > > rules; > > > > > > > b) disallows topology separation in technology independent > > way > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > container > > > > > > does > > > > > > > not change hop-by-hop (as some people seem to believe). The > > role is > > > > > > > only meaningful on the ODU terminating nodes and irrelevant > > on > > > > > > transit > > > > > > > nodes. It is it's position in the hierarchy (but not role) > > that may > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > AI1 > > and > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > can > > only > > > > > > support > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > with > > the > > > > > > role > > > > > > > of Ho ODU level is requested, according to your statement, > > this > > > > > > > conneciton will be allowed to be created. However, it > should > > not be > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > > link > > > > > ends > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > > while > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > path > > > > > > > computation is constrained to the OTN_HO_SC topology, B11 > and > > B12 > > > > > TE > > > > > > > links will > > > > > > be > > > > > > > disallowed, and the resulting path (if any) will not go > > through B11 > > > > > > and > > > > > > > B12. If one circumvents the path computation by providing > the > > fully > > > > > > > explicit path, the signaling should fail on node B for the > > same > > > > > > reason: > > > > > > > inconsistency of required (signaled) and supported (by > local > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > > the > > > > > type > > > > > > > indicated in the Switching Type parameter is supported on > > the > > > > > > > corresponding incoming interface. If the type cannot be > > > > > supported, > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > problem/Switching Type" indication." > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: "Fatai Zhang" ; > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Lou Berger" ; > > > > > > > ; > > > > > > framework@tools.ietf.org> > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > ccamp@ietf.org; > > > > > > draft- > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > I think role does not equal switching capability. The > > operators can > > > > > > > define different roles depending on their policy and > achieve > > the > > > > > > > role through different methods. However, for OTN networks, > > the > > > > > > > containers (e.g., ODUk) all have the same switching > > capablility > > > > > > > (i.e., TDM > > > > > > > switching) and I think we should reflect the natural > > > > > characteristics > > > > > > of > > > > > > > links in the routing. In addition, if we extend the ISC, it > > will > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > overrides > > > > > > > encoding type). > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > views the > > > > > > > network as a stack of topologies. Whether a given topology > is > > real > > > > > > > or virtual is of no importance. > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > switching > > > > > > > capability field (confusing name as it is) is a good way to > > > > > describe > > > > > > a > > > > > > > layer in technology independent way, so that, say, MPLS-TP- > > >OTN_LO- > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > stack of > > > > > > > topologies that could be easily separated in technology > > independent > > > > > > way > > > > > > > should path computation be constrained to particular one or > > > > > > > sub-stack of them. > > > > > > > I think a good way to identify an OTN (virtual) topology is > > via > > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > > topology. > > > > > > > BTW IMO the role of an ODU container does not change hop- > by- > > hop (as > > > > > > > some people seem to believe). The role is only meaningful > on > > the > > > > > ODU > > > > > > > terminating nodes and irrelevant on transit nodes. It is > it's > > > > > > position > > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > > ODU's > > > > > > role > > > > > > > is the level of topology it is provisioned for and it is > the > > same > > > > > > > for all ODUs that comprise the topology. For, example a > user > > may > > > > > > provision > > > > > > > a LO topology and constrain ODUs he sells to a set of > clients > > to > > > > > use > > > > > > > the topology rather than any resources available on OTN > > network. > > > > > > > The bottom line: container's role is the same as the role > of > > > > > virtual > > > > > > > topology the container is a part of and could be advertised > > as the > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > > roles > > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > > clarify? > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > etc.) > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > In addition, could you clarify my questions in another > email > > > > > (copied > > > > > > as > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > other. > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > hierarchy, > > > > > which > > > > > > is > > > > > > > a mistake IMO. > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > > ODU3 as > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > is > > a > > > > > OTU3 > > > > > > link > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > (service > > > > > > > over > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > this > > case, > > > > > > how > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > Level? > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > > the ODU > > > > > > > terminating nodes (i.e. on either side of corresponding > > link). What > > > > > > > happens on the ODU transit nodes and its place in the > > hierarchy on > > > > > > the > > > > > > > transit nodes are of no importance. My LO container can be > > carried > > > > > > > by somebody else's LO container and can carry my client's > LO > > > > > container. > > > > > > To > > > > > > > some extent it is similar to MPLS LSP role: LSP always has > a > > role > > > > > > (e.g. > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > along its > > > > > > > path. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Fatai Zhang" > > ; > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > gmpls- > > > > > > > g709-framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > > types > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > capabilities > > > > > > > rather than the link's role (i.e. level in the OTN > hierarchy: > > LO, > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > indicated > > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > > roles; > > > > > 2. > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > different > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > capabilities can > > > > > > be > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > ISCD is > > > > > > > required); 4. The combination of swicthcaps and encoding > type > > will > > > > > > look > > > > > > > to CP as a separate layer, which is exactly how ITU models > > OTN > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > operator > > > > > would > > > > > > > want to constrain the routing of OTN connections to pre- > > configured > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > sells to > > > > > > the > > > > > > > clients to one or more pre-configured LO topologies), this > > would be > > > > > > > possible to do in a technology independent way. Suppose an > > instance > > > > > > of > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > from > > HO OTN > > > > > > > links will be no different from the separation of WDM links > > from > > > > > > OTUs. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > To: Igor Bryskin > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger; > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > srv- > > > > > > > exgen.atl.advaoptical.com> > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > many > > as > > > > > the > > > > > > > depth of the deepest possible OTN DP hierarchy, for > example: > > > > > > > > > > > > > > > > typedef enum > > > > > > > > { > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > /*****/ > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > > */ > > > > > /*****/ > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > > make the > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > Digital > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > which had > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > long time > > > > > ago. > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > > did not > > > > > > > understand what the TS type meant did not try to multiplex > > its LO > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > commited > > > > > to > > > > > > using > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > OTN_HO or > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > > the > > > > > > latter > > > > > > > is for backward compatibility and should be ignored if > > OTN_LO, > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > 1.25 > > TS > > > > > > > granularity, then the corresponding G.709 Digital Path FA > can > > be > > > > > withdrawn. > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > of > > the > > > > > LSP > > > > > > > regardless of what goes on in the middle since that > > determines what > > > > > > can > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > OTU3 > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 o= r > > ODUj=3D3Df=3D > > > lex > > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > > contain > > > > > an ODU0. > > > > > > > If the SHO Encoding Type is used, then it indicates that > two > > levels > > > > > > of > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > 4328 > > Switch > > > > > > > Types currently don't include an ODUj or ODUk distinction > but > > if > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > Along > > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > > and > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > I'm > > not > > > > > > clear > > > > > > > how in an FA it can be indicated that either type is > > currently > > > > > > > available (NE capable of both and hasn't committed to > either > > one > > > > > > yet). > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > > on this > > > > > > > would indicate a huge controversy and I'm not getting it > > (other > > > > > than > > > > > > a > > > > > > > strong preference to rely on bytes/sec or on enumerated > type > > > > > fields). > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > > not sure > > > > > > if > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, > > > > > > > or other intent. Could someone (either draft) concisely > > summarize > > > > > > > the multiplexing restrictions in one place, including > > restrictions > > > > > > > on number of multiplexing layers at one LSR. That might > > help. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] On > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > framework > > > > > > > > > document before we can embark on any proposals to the > > problem. > > > > > I > > > > > > am > > > > > > > > > still not clear why do we have to deviate from the > > general > > > > > > approach > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > > > > > > IB>> plane, and > > > > > > > > > it is highly desirable to adhere to the layer > independent > > > > > > paradigm > > > > > > > > > of advertising of TE links, and there is no reason to > > invent an > > > > > > OTN > > > > > > > > > specific ISCD. The combination of Switching Capability > > and > > > > > > Encoding > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > multiplexing > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > link, > > and, > > > > > if > > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > new > > > > > > > > > >TE-link > > > > > > > to > > > > > > > > > represent >the low-order ODUj bandwidth within the > high- > > order > > > > > > > containers. > > > > > > > > > This is simply >blowing up the solution to a very > simple > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > possibility > > to > > > > > > create > > > > > > > > > IB>> OTN > > > > > > > > > hierarchies and constrain LO connections to HO > > containers, one > > > > > > > needs > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > > and > > > > > > > > > other interested experts, and we think the proposal > > described > > > > > in > > > > > > "draft- > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > > is more > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > needed for > > > > > > > > > control plane, no matter how you encode the routing > > > > > information. > > > > > > > For > > > > > > > > > TDM networks, you know the resource is allocated based > on > > TS, > > > > > so > > > > > > > the > > > > > > > > > available TS should be get or induced before creating > > cross- > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > information, > > > > > > I > > > > > > > > > think you need go to the routing drafts (info model and > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > encoding), > > > > > you > > > > > > > > > will find that one of your suggestions is adopted > (i.e., > > simply > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > ..., > > ODU4 > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > links) > > as FA > > > > > > for > > > > > > > > > ODU1, you have to advertise a new TE link or put this > FA > > as a > > > > > > > > > component link of an existing TE link (like > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > g709-framework@tools.ietf.org > gmpls- > > > > > > g709- > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > I believe there has been some off-line discussion on > > how to > > > > > > > better > > > > > > > > > > align the work with 4202. Use of common approaches > is > > of > > > > > > course > > > > > > > > > > one of the main objectives of *C*CAMP. I look > forward > > to > > > > > > hearing > > > > > > > > > > from the draft and discussion contributors on there > > progress > > > > > > > > > > on > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > >> Hello, > > > > > > > > > >> > > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > > This > > > > > > section > > > > > > > > > >> describes the link-parameters that are required for > > OTN > > > > > > service > > > > > > > > > >> routing purposes. > > > > > > > > > >> > > > > > > > > > >> My comment is how are we going to advertise the low- > > order > > > > > > > > > >> ODUj availability within a higher-order container. > For > > > > > > > > > >> example, consider an > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > granularity > > and > > > > > > > > > >> then > > > > > > > we > > > > > > > > > >> establish an ODU2 service over the link. At this > point > > in > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > ODU2 > > > > > > > > > >> services > > > > > > and > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > > ODU1s > > > > > > > > > >> are contained over the ODU2). So it is obvious from > > this > > > > > > > > > >> example > > > > > > > that > > > > > > > > > >> the number of time-slots available is different > based > > on the > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > >> How do we address this issue based on the approach > > specified > > > > > > in > > > > > > > > > >> the > > > > > > > > > draft? > > > > > > > > > >> > > > > > > > > > >> My other question is why not simply advertize the > > available > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances or > > > > > > the > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > This > > > > > > > > > >> approach seems to be more in-line with the general > > approach > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > section > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > ISCDs > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > additional > > > > > > > > > >> benefit > > > > > > > is > > > > > > > > > >> that the advertisement is TS size independent and > > hence will > > > > > > > > > >> simplify the implementation. > > > > > > > > > >> > > > > > > > > > >> Regards > > > > > > > > > >> > > > > > > > > > >> Snigdho From IBryskin@advaoptical.com Tue Jul 20 14:19:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329583A6B39 for ; Tue, 20 Jul 2010 14:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ignlNHHgiZfh for ; Tue, 20 Jul 2010 14:19:34 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id D4C7F3A6C8D for ; Tue, 20 Jul 2010 14:19:33 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6KLJgYn011574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 20 Jul 2010 23:19:42 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 23:19:42 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 20 Jul 2010 17:19:39 -0400 From: Igor Bryskin To: John E Drake , "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 17:19:35 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAAasgAAAA3JUA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76201@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CC50@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163984487CC50@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-20_08:2010-07-20, 2010-07-20, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:19:38 -0000 John, What I meant to say is that for OTN link advertisements it is possible to u= se "| Switching Capability-specific information" for advertisement o= f unreserved bandwidth on per priority level available for the ISCD, if we = decide to make such information available (which I don't think we should). Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 5:10 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, I was describing SDH/SONET not OTN, I have no idea what you mean by "last f= ield", and I have no idea what you mean by "unresolved bandwidth". John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 2:02 PM > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > Do you understand the quote from RFC4203: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Cap | Encoding | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Capability-specific information | > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > You can use the last field for OTN switchcap to advertise unresolved > bandwidth available for the ISCD on per priority level. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 4:35 PM > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Snipped... > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > priority > > level for every ISCD. > > JD: Igor, what part of my quote from RFC 4202 did you not understand? > You do not advertise unreserved bandwidth in the ISCD TLV. In > particular, for TDM, what is advertised is the max and min bandwidth > allowed for a single LSP. It was designed to produce a compact > representation by taking advantage of the SDH/SONET hierarchy. > > Advertising a separate ISCD for each supported rate is allowed but > wasteful. > > > > > Igor > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > wro=3D > > > te: > > > > > > > John, > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > However if a > > > > TE link advertises more than one ISCD (with each ISCD containing > > only max > > > > lsp bandwidth per priority), it is necessary to indicate how the > > total li=3D > > > nk > > > > unreserved bandwidth is partitioned between several ISCDs. What I > > am > > > > suggesting is instead of advertising the unreserved bandwidth > > multiple ti=3D > > > mes > > > > (one per ISCD), indicate how the bandwidth is split between the > > ISCDs: e.=3D > > > g > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > Igor. > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > Igor, > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > > issue o=3D > > > f > > > > partitioning unreserved bandwidth across multiple advertised TDM > > ISC TLVs=3D > > > is > > > > actually a non-issue. > > > > > > > > Unreserved bandwidth by priority has always been advertised using > > the MPL=3D > > > S > > > > sub-TLV. My point has been that we have never had a requirement > > (includi=3D > > > ng > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > signal > > type, =3D > > > so > > > > what is special about OTN? > > > > > > > > A further point would be that if we do decide that it is > necessary > > to > > > > advertise unreserved bandwidth by signal type, it should be done > in > > a > > > > general way and not in an OTN specific manner. (And in fact, the > > argumen=3D > > > ts > > > > that unreserved bandwidth by signal type needs to be advertised, > > such as =3D > > > the > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > It is a valid point, but the suggested solution is way too > > expensive. > > > > > All you need is a way to say how the advertised unreserved > > bandwidth is > > > > > partitioned between ISCDs in case the TE link advertisement > > contains > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > bits out > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > total > > > > > unreserved bandwidth associated with the ISCD. Another way is > to > > use > > > > > swicthcap specific extension. > > > > > BTW: this is not an OTN specific issue, rather more general: > any > > time > > > > > when a TE link advertises more than one ISCD (which is > perfectly > > Ok > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, > > > > > > > > > > The need for unreserved resources advertised per signal type is > > the > > > > > concurrent path computation. I'll answer quoting a section from > > the > > > > > info-model draft, please have a look in particular to the > > example: > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > and > > per > > > > > signal type in order to allow the correct functioning of the > > > > > restoration process. [RFC4203] only allows advertising > > unreserved > > > > > resources per priority, this leads not to know how many LSPs > > of a > > > > > specific signal type can be restored. As example it is > > possible to > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > +------+ component link 1 +------+ > > > > > | +------------------+ | > > > > > | | component link 2 | | > > > > > | N1 +------------------+ N2 | > > > > > | | component link 3 | | > > > > > | +------------------+ | > > > > > +------+ +---+--+ > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > > with > > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > > on the > > > > > third and supporting ODU2 and ODU3 signal types. The node > > would > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > a > > MAX > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > network > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > only > > a > > > > > single ODU3 can be set up and a crank-back would be > > originated. In > > > > > more complex network scenarios the number of crank-backs can > > be much > > > > > higher." > > > > > > > > > > In other words, advertising the number of availble resources > per > > signal > > > > > type does not avoid the possibility of cranck-back but > decreases > > it as > > > > > much as possible. For sure a good routing prevents from crank- > > backs > > > > > caused by the restoration of LSP originating on the same > Ingress. > > The > > > > > cranck-backs due to the concurrent restoration of LSPs > > originating on > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > BR > > > > > Daniele > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > In line > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, one more question. > > > > > > > > > > What about the unreserved bandwidth? > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > > per > > > > > (muxCap & signal type) you also need to advertise the > unreserved > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > correct? > > This > > > > > also implies extending the unreserved bandwidth TLV so to > create > > a > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > subTLV). > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > ISCD > > per > > > > > IB>> role per (muxCap & signal type) per priority level. > However, > > total > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > unless > > you > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > Igor > > > > > > > > > > Thanks > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Understood... > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > > > That's exactly what I've been > > > > > > trying to say all along. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > > per > > > > > role > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > signal > > > > > type. > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > switchCap =3D3D role; > > > > > > > encodeType =3D3D muxCap & signal type; > > > > > > > We also have 16 reserved bits which can use for OTN > specific > > info > > > > > in > > > > > > > case we need it. > > > > > > [SCB] I am yet to clearly understand what the role of "role" > > is, but > > > > > > agree with your observation on the encode-type and the 16 > > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > > each > > > > > role > > > > > > > you would advertise just the unreserved bandwidth but you > > wouldn't > > > > > > know > > > > > > > if such bandwidth is available for a certain type of ODUj > LSP > > (e.g. > > > > > > 15 > > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > > available > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > scalability > > > > > > issues > > > > > > > and the requirement of being able to bundle component links > > > > > together > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > ISDCs > > > > > will > > > > > > > provide a lot of flexibility: you can specify different > > things > > > > > (e.g. > > > > > > > available bandwidth) for the same link in different roles. > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be > sufficient? > > > > > > > > > > > > > > Cheers, > > > > > > > Daniele > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Igor Bryskin > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Fatai Zhang > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > Thanks. > > > > > > > I understand what you said. Therefore, we have added some > > text to > > > > > > > address the requirment in FWK document. However, we still > > don't > > > > > > > think that we need to extend ISC to meet the requirment. > The > > role > > > > > of > > > > > > > the > > > > > > ODU > > > > > > > can be get from the routing information implicitly. In the > > [draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > "Full > > > > > Lambda" > > > > > > is > > > > > > > introduced. > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > a) this requires OTN specific advertising and processing > > rules; > > > > > > > b) disallows topology separation in technology independent > > way > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > container > > > > > > does > > > > > > > not change hop-by-hop (as some people seem to believe). The > > role is > > > > > > > only meaningful on the ODU terminating nodes and irrelevant > > on > > > > > > transit > > > > > > > nodes. It is it's position in the hierarchy (but not role) > > that may > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > AI1 > > and > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > can > > only > > > > > > support > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > with > > the > > > > > > role > > > > > > > of Ho ODU level is requested, according to your statement, > > this > > > > > > > conneciton will be allowed to be created. However, it > should > > not be > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > > link > > > > > ends > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > > while > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > path > > > > > > > computation is constrained to the OTN_HO_SC topology, B11 > and > > B12 > > > > > TE > > > > > > > links will > > > > > > be > > > > > > > disallowed, and the resulting path (if any) will not go > > through B11 > > > > > > and > > > > > > > B12. If one circumvents the path computation by providing > the > > fully > > > > > > > explicit path, the signaling should fail on node B for the > > same > > > > > > reason: > > > > > > > inconsistency of required (signaled) and supported (by > local > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > > the > > > > > type > > > > > > > indicated in the Switching Type parameter is supported on > > the > > > > > > > corresponding incoming interface. If the type cannot be > > > > > supported, > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > problem/Switching Type" indication." > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: "Fatai Zhang" ; > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Lou Berger" ; > > > > > > > ; > > > > > > framework@tools.ietf.org> > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > ccamp@ietf.org; > > > > > > draft- > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > I think role does not equal switching capability. The > > operators can > > > > > > > define different roles depending on their policy and > achieve > > the > > > > > > > role through different methods. However, for OTN networks, > > the > > > > > > > containers (e.g., ODUk) all have the same switching > > capablility > > > > > > > (i.e., TDM > > > > > > > switching) and I think we should reflect the natural > > > > > characteristics > > > > > > of > > > > > > > links in the routing. In addition, if we extend the ISC, it > > will > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > overrides > > > > > > > encoding type). > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > views the > > > > > > > network as a stack of topologies. Whether a given topology > is > > real > > > > > > > or virtual is of no importance. > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > switching > > > > > > > capability field (confusing name as it is) is a good way to > > > > > describe > > > > > > a > > > > > > > layer in technology independent way, so that, say, MPLS-TP- > > >OTN_LO- > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > stack of > > > > > > > topologies that could be easily separated in technology > > independent > > > > > > way > > > > > > > should path computation be constrained to particular one or > > > > > > > sub-stack of them. > > > > > > > I think a good way to identify an OTN (virtual) topology is > > via > > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > > topology. > > > > > > > BTW IMO the role of an ODU container does not change hop- > by- > > hop (as > > > > > > > some people seem to believe). The role is only meaningful > on > > the > > > > > ODU > > > > > > > terminating nodes and irrelevant on transit nodes. It is > it's > > > > > > position > > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > > ODU's > > > > > > role > > > > > > > is the level of topology it is provisioned for and it is > the > > same > > > > > > > for all ODUs that comprise the topology. For, example a > user > > may > > > > > > provision > > > > > > > a LO topology and constrain ODUs he sells to a set of > clients > > to > > > > > use > > > > > > > the topology rather than any resources available on OTN > > network. > > > > > > > The bottom line: container's role is the same as the role > of > > > > > virtual > > > > > > > topology the container is a part of and could be advertised > > as the > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > > roles > > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > > clarify? > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > etc.) > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > In addition, could you clarify my questions in another > email > > > > > (copied > > > > > > as > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > other. > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > hierarchy, > > > > > which > > > > > > is > > > > > > > a mistake IMO. > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > > ODU3 as > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > is > > a > > > > > OTU3 > > > > > > link > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > (service > > > > > > > over > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > this > > case, > > > > > > how > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > Level? > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > > the ODU > > > > > > > terminating nodes (i.e. on either side of corresponding > > link). What > > > > > > > happens on the ODU transit nodes and its place in the > > hierarchy on > > > > > > the > > > > > > > transit nodes are of no importance. My LO container can be > > carried > > > > > > > by somebody else's LO container and can carry my client's > LO > > > > > container. > > > > > > To > > > > > > > some extent it is similar to MPLS LSP role: LSP always has > a > > role > > > > > > (e.g. > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > along its > > > > > > > path. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Fatai Zhang" > > ; > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > gmpls- > > > > > > > g709-framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > > types > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > capabilities > > > > > > > rather than the link's role (i.e. level in the OTN > hierarchy: > > LO, > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > indicated > > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > > roles; > > > > > 2. > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > different > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > capabilities can > > > > > > be > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > ISCD is > > > > > > > required); 4. The combination of swicthcaps and encoding > type > > will > > > > > > look > > > > > > > to CP as a separate layer, which is exactly how ITU models > > OTN > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > operator > > > > > would > > > > > > > want to constrain the routing of OTN connections to pre- > > configured > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > sells to > > > > > > the > > > > > > > clients to one or more pre-configured LO topologies), this > > would be > > > > > > > possible to do in a technology independent way. Suppose an > > instance > > > > > > of > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > from > > HO OTN > > > > > > > links will be no different from the separation of WDM links > > from > > > > > > OTUs. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > To: Igor Bryskin > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger; > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > srv- > > > > > > > exgen.atl.advaoptical.com> > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > many > > as > > > > > the > > > > > > > depth of the deepest possible OTN DP hierarchy, for > example: > > > > > > > > > > > > > > > > typedef enum > > > > > > > > { > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > /*****/ > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > > */ > > > > > /*****/ > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > > make the > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > Digital > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > which had > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > long time > > > > > ago. > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > > did not > > > > > > > understand what the TS type meant did not try to multiplex > > its LO > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > commited > > > > > to > > > > > > using > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > OTN_HO or > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > > the > > > > > > latter > > > > > > > is for backward compatibility and should be ignored if > > OTN_LO, > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > 1.25 > > TS > > > > > > > granularity, then the corresponding G.709 Digital Path FA > can > > be > > > > > withdrawn. > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > of > > the > > > > > LSP > > > > > > > regardless of what goes on in the middle since that > > determines what > > > > > > can > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > OTU3 > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 o= r > > ODUj=3D3Df=3D > > > lex > > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > > contain > > > > > an ODU0. > > > > > > > If the SHO Encoding Type is used, then it indicates that > two > > levels > > > > > > of > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > 4328 > > Switch > > > > > > > Types currently don't include an ODUj or ODUk distinction > but > > if > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > Along > > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > > and > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > I'm > > not > > > > > > clear > > > > > > > how in an FA it can be indicated that either type is > > currently > > > > > > > available (NE capable of both and hasn't committed to > either > > one > > > > > > yet). > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > > on this > > > > > > > would indicate a huge controversy and I'm not getting it > > (other > > > > > than > > > > > > a > > > > > > > strong preference to rely on bytes/sec or on enumerated > type > > > > > fields). > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > > not sure > > > > > > if > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, > > > > > > > or other intent. Could someone (either draft) concisely > > summarize > > > > > > > the multiplexing restrictions in one place, including > > restrictions > > > > > > > on number of multiplexing layers at one LSR. That might > > help. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] On > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > framework > > > > > > > > > document before we can embark on any proposals to the > > problem. > > > > > I > > > > > > am > > > > > > > > > still not clear why do we have to deviate from the > > general > > > > > > approach > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > > > > > > IB>> plane, and > > > > > > > > > it is highly desirable to adhere to the layer > independent > > > > > > paradigm > > > > > > > > > of advertising of TE links, and there is no reason to > > invent an > > > > > > OTN > > > > > > > > > specific ISCD. The combination of Switching Capability > > and > > > > > > Encoding > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > multiplexing > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > link, > > and, > > > > > if > > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > new > > > > > > > > > >TE-link > > > > > > > to > > > > > > > > > represent >the low-order ODUj bandwidth within the > high- > > order > > > > > > > containers. > > > > > > > > > This is simply >blowing up the solution to a very > simple > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > possibility > > to > > > > > > create > > > > > > > > > IB>> OTN > > > > > > > > > hierarchies and constrain LO connections to HO > > containers, one > > > > > > > needs > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > > and > > > > > > > > > other interested experts, and we think the proposal > > described > > > > > in > > > > > > "draft- > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > > is more > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > needed for > > > > > > > > > control plane, no matter how you encode the routing > > > > > information. > > > > > > > For > > > > > > > > > TDM networks, you know the resource is allocated based > on > > TS, > > > > > so > > > > > > > the > > > > > > > > > available TS should be get or induced before creating > > cross- > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > information, > > > > > > I > > > > > > > > > think you need go to the routing drafts (info model and > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > encoding), > > > > > you > > > > > > > > > will find that one of your suggestions is adopted > (i.e., > > simply > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > ..., > > ODU4 > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > links) > > as FA > > > > > > for > > > > > > > > > ODU1, you have to advertise a new TE link or put this > FA > > as a > > > > > > > > > component link of an existing TE link (like > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > g709-framework@tools.ietf.org > gmpls- > > > > > > g709- > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > I believe there has been some off-line discussion on > > how to > > > > > > > better > > > > > > > > > > align the work with 4202. Use of common approaches > is > > of > > > > > > course > > > > > > > > > > one of the main objectives of *C*CAMP. I look > forward > > to > > > > > > hearing > > > > > > > > > > from the draft and discussion contributors on there > > progress > > > > > > > > > > on > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > >> Hello, > > > > > > > > > >> > > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > > This > > > > > > section > > > > > > > > > >> describes the link-parameters that are required for > > OTN > > > > > > service > > > > > > > > > >> routing purposes. > > > > > > > > > >> > > > > > > > > > >> My comment is how are we going to advertise the low- > > order > > > > > > > > > >> ODUj availability within a higher-order container. > For > > > > > > > > > >> example, consider an > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > granularity > > and > > > > > > > > > >> then > > > > > > > we > > > > > > > > > >> establish an ODU2 service over the link. At this > point > > in > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > ODU2 > > > > > > > > > >> services > > > > > > and > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > > ODU1s > > > > > > > > > >> are contained over the ODU2). So it is obvious from > > this > > > > > > > > > >> example > > > > > > > that > > > > > > > > > >> the number of time-slots available is different > based > > on the > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > >> How do we address this issue based on the approach > > specified > > > > > > in > > > > > > > > > >> the > > > > > > > > > draft? > > > > > > > > > >> > > > > > > > > > >> My other question is why not simply advertize the > > available > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances or > > > > > > the > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > This > > > > > > > > > >> approach seems to be more in-line with the general > > approach > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > section > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > ISCDs > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > additional > > > > > > > > > >> benefit > > > > > > > is > > > > > > > > > >> that the advertisement is TS size independent and > > hence will > > > > > > > > > >> simplify the implementation. > > > > > > > > > >> > > > > > > > > > >> Regards > > > > > > > > > >> > > > > > > > > > >> Snigdho From lberger@labn.net Tue Jul 20 14:25:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730BA3A6863 for ; Tue, 20 Jul 2010 14:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szv7zpkawRPe for ; Tue, 20 Jul 2010 14:25:55 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 44A283A681A for ; Tue, 20 Jul 2010 14:25:55 -0700 (PDT) Received: (qmail 20661 invoked by uid 0); 20 Jul 2010 21:19:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 20 Jul 2010 21:19:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=HIdFrdVP+hpHK8LH+aTs5I+l4RXFS1pcgA0jJQ+ro6WyHXHDTPLMRo4iP+4tPy3jZDTh50nNhFQH2IyvKymwnCPupc7i6/siwEtTNQkogvmYb1nCEJFgGsTYrnfO9xUL; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1ObKDq-00017O-Tu; Tue, 20 Jul 2010 15:19:31 -0600 Message-ID: <4C4612F0.9050208@labn.net> Date: Tue, 20 Jul 2010 17:19:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: mpls@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-mpls-tp-cp-frameworks@tools.ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:25:55 -0000 Eric, Thank you for the comments. Please see below for in-line responses. On 7/12/2010 10:33 AM, Eric Osborne (eosborne) wrote: > I have a few questions. Nothing major, as the draft is in general > pretty solid. > > > > 1) Section 4.1 reviews existing GMPLS functionality and describes > applicability to TP. Section 4.1.8 defines LSP hierarchy but doesn't > say anything about how it applies to TP. It probably needs a line like > "Hierarchical LSPs may be used in MPLS-TP at the discretion of the > network operator" or something similar ot what's in other subsections of > 4.1. > Good point! Something along the lines of the following will be added: LSP hierarchy is expected to play an important role in MPLS-TP networks, particularly in the context of scaling and recovery. > > 2) Some of section 4.1.9 is out of sync with the surviveability > framework (draft-ietf-mpls-tp-survive-fwk) > > - survive-fwk draws a distinction between protection and restoration > that cp-framework lumps under 'recovery'. It may be worth calling out > both protection and restoration as separate things. This is a carry over from GMPLS terminology, see [RFC4427], [RFC4426], [RFC4872], [RFC4873] > > - Section 4.1.9 lists five recovery types: > > - 1+1 bidirectional protection for P2P LSPs > - 1+1 unidirectional protection for P2MP LSPs > - 1:n (including 1:1) protection with or without extra traffic > - Rerouting without extra traffic (sometimes known as soft > rerouting), including shared mesh restoration > - Full LSP rerouting > > > I don't see where these five types come from. from GMPLS. The five types should be identified in that context and can be used to support [TP-SURVIVE]. The text should make this more clear. > rfc5654 requirements R65 > and R67 list five MUST types (bidir 1+1 p2p, unidir 1+1 p2p, unidir 1+1 > p2mp, bidir 1:n p2p, unidir 1:n p2mp) and one optional (undir 1:n p2p). > R68 requires 1:n (including 1:1) ahread mesh recovery. > > How do the five types in section 4.1. 9 map to the requirements in > rfc5654? I must be missing something. This looks like a straightforward mapping. (The table also shows mapping of requirements to mechanisms) for example: At first glance I don't see unidir 1+1 p2p in sec. 4.1.9, it's the second in the list. > although perhaps it's implied in 'rerouting without extra traffic'. > 'Full LSP rerouting' also seems like it may mean something specific to > whomever wrote it but as far as I can tell there's no explicit > definition of 'Full LSP rerouting' (as opposed to partial? as opposed > to something other than rerouting?) anywhere in rfc5654 or survive-fwk. > And 'soft rerouting appears to be survive-fwk's 'soft restoration'. > > 3) Section 4.1.9, "it's use is not precluded" , s/it's/its/ > Thanks! > > 4) Section 4.4.1 is entitled "MPLS to MPLS-TP Interworking". The > section talks about " interworking of MPLS-TE and GMPLS control plane", > so shouldn't the section be "MPLS-TE to MPLS-TP Interworking"? Unless > things like LDP-to-TP interworking are in someone's plans, I think "TE > to TP Interworking" is a better fit. Agreed. Changed to "MPLS-TE to MPLS-TP LSP Control Plane Interworking" Thanks again! Lou > > > > > > > > eric > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From lberger@labn.net Tue Jul 20 14:32:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1C83A6A51 for ; Tue, 20 Jul 2010 14:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIfasG2HtUe6 for ; Tue, 20 Jul 2010 14:32:25 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 951463A6A50 for ; Tue, 20 Jul 2010 14:31:53 -0700 (PDT) Received: (qmail 9823 invoked by uid 0); 20 Jul 2010 21:32:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 20 Jul 2010 21:32:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=GBfZYVd6oTkRMmhy6HU4HF+QkIPkCZIod5Hex+jDdPftLJpdvflSKNYoy0LuqT9enukX6qPI6Q4dJYgE3A0zldGgDrZ1NGDRvawiLIdgYwiY9+HNZPPeuArF6NDhUUtF; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1ObKQ2-0005DC-AO; Tue, 20 Jul 2010 15:32:06 -0600 Message-ID: <4C4615E4.9070005@labn.net> Date: Tue, 20 Jul 2010 17:32:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: curtis@occnc.com References: <201007140053.o6E0r0To020598@harbor.orleans.occnc.com> In-Reply-To: <201007140053.o6E0r0To020598@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "mpls-tp@ietf.org" , draft-ietf-ccamp-mpls-tp-cp-frameworks@tools.ietf.org Subject: Re: [CCAMP] FW: Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:32:27 -0000 Curtis, Please see below. On 7/13/2010 8:53 PM, Curtis Villamizar wrote: > > In message > "BRUNGARD, DEBORAH A (ATTLABS)" writes: >> >> This WG Last Call will be extended to be a joint last call of the ccamp, >> pwe3, and mpls wgs and the end date extended to July 26th. >> >> Thanks, >> CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs > > > This statement in draft-ietf-ccamp-mpls-tp-cp-framework-02.txt > > 94. Per-packet equal cost multi-path (ECMP) load balancing is not > applicable to MPLS-TP [TP-DATA-PLANE , section 3.1.1., > paragraph 6]. > > is in conflict with the cited statement in TP-DATA-PLANE. > > Per-packet Equal-Cost Multi-Path (ECMP) load-balancing is outside the > scope of the MPLS-TP. > > Out of scope and not applicable are two different things. Out of > scope is more accurate and cp-framework needs to reflect this. The DP document (http://tools.ietf.org/html/draft-ietf-mpls-tp-data-plane-04) says: Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on an MPLS-TP LSP... seems pretty strong to me.... That said, I don't think it is such a significant point in this document, so have no issue changing to : Per-packet equal cost multi-path (ECMP) load balancing is currently outside the scope of MPLS-TP [TP-DATA-PLANE , section 3.1.1., paragraph 6]. Lou > > Curtis > > > btw - does this get removed later? > > 102. Requirement intentionally blank. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From jdrake@juniper.net Tue Jul 20 14:32:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03633A6C88 for ; Tue, 20 Jul 2010 14:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.334 X-Spam-Level: X-Spam-Status: No, score=-5.334 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJjLqvU91VwE for ; Tue, 20 Jul 2010 14:32:27 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id E284B3A6B63 for ; Tue, 20 Jul 2010 14:32:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYV6vK9wu8VS9Noq7MI1p5Hh2U+Y28g@postini.com; Tue, 20 Jul 2010 14:32:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 20 Jul 2010 14:28:12 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 14:28:10 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAAasgAAAA3JUAAAGGRgA== Message-ID: <5E893DB832F57341992548CDBB333163984487CCF8@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CC50@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76201@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76201@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:32:35 -0000 Igor, My apologies, that is certainly a true statement. But again, if we decide = to do advertise unreserved bandwidth by service category it shouldn't be ju= st for OTN, which sort of argues for a new TLV. I have been using the term= 'service category' as a generic term. In the OTN context it probably mean= s bandwidth granularity, but in other contexts probably different things. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, July 20, 2010 2:20 PM > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > What I meant to say is that for OTN link advertisements it is possible > to use "| Switching Capability-specific information" for > advertisement of unreserved bandwidth on per priority level available > for the ISCD, if we decide to make such information available (which I > don't think we should). > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 5:10 PM > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > I was describing SDH/SONET not OTN, I have no idea what you mean by > "last field", and I have no idea what you mean by "unresolved > bandwidth". > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Tuesday, July 20, 2010 2:02 PM > > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > Do you understand the quote from RFC4203: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Capability-specific information | > > | (variable) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > You can use the last field for OTN switchcap to advertise unresolved > > bandwidth available for the ISCD on per priority level. > > > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 4:35 PM > > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snipped... > > > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > > priority > > > level for every ISCD. > > > > JD: Igor, what part of my quote from RFC 4202 did you not > understand? > > You do not advertise unreserved bandwidth in the ISCD TLV. In > > particular, for TDM, what is advertised is the max and min bandwidth > > allowed for a single LSP. It was designed to produce a compact > > representation by taking advantage of the SDH/SONET hierarchy. > > > > Advertising a separate ISCD for each supported rate is allowed but > > wasteful. > > > > > > > > Igor > > > > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > > wro=3D > > > > te: > > > > > > > > > John, > > > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > > However if a > > > > > TE link advertises more than one ISCD (with each ISCD > containing > > > only max > > > > > lsp bandwidth per priority), it is necessary to indicate how > the > > > total li=3D > > > > nk > > > > > unreserved bandwidth is partitioned between several ISCDs. What > I > > > am > > > > > suggesting is instead of advertising the unreserved bandwidth > > > multiple ti=3D > > > > mes > > > > > (one per ISCD), indicate how the bandwidth is split between the > > > ISCDs: e.=3D > > > > g > > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > > > Igor. > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > > Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > Igor, > > > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so > the > > > issue o=3D > > > > f > > > > > partitioning unreserved bandwidth across multiple advertised > TDM > > > ISC TLVs=3D > > > > is > > > > > actually a non-issue. > > > > > > > > > > Unreserved bandwidth by priority has always been advertised > using > > > the MPL=3D > > > > S > > > > > sub-TLV. My point has been that we have never had a > requirement > > > (includi=3D > > > > ng > > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > > signal > > > type, =3D > > > > so > > > > > what is special about OTN? > > > > > > > > > > A further point would be that if we do decide that it is > > necessary > > > to > > > > > advertise unreserved bandwidth by signal type, it should be > done > > in > > > a > > > > > general way and not in an OTN specific manner. (And in fact, > the > > > argumen=3D > > > > ts > > > > > that unreserved bandwidth by signal type needs to be > advertised, > > > such as =3D > > > > the > > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > It is a valid point, but the suggested solution is way too > > > expensive. > > > > > > All you need is a way to say how the advertised unreserved > > > bandwidth is > > > > > > partitioned between ISCDs in case the TE link advertisement > > > contains > > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > > bits out > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > > total > > > > > > unreserved bandwidth associated with the ISCD. Another way is > > to > > > use > > > > > > swicthcap specific extension. > > > > > > BTW: this is not an OTN specific issue, rather more general: > > any > > > time > > > > > > when a TE link advertises more than one ISCD (which is > > perfectly > > > Ok > > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, > > > > > > > > > > > > The need for unreserved resources advertised per signal type > is > > > the > > > > > > concurrent path computation. I'll answer quoting a section > from > > > the > > > > > > info-model draft, please have a look in particular to the > > > example: > > > > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > > and > > > per > > > > > > signal type in order to allow the correct functioning of > the > > > > > > restoration process. [RFC4203] only allows advertising > > > unreserved > > > > > > resources per priority, this leads not to know how many > LSPs > > > of a > > > > > > specific signal type can be restored. As example it is > > > possible to > > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > > > +------+ component link 1 +------+ > > > > > > | +------------------+ | > > > > > > | | component link 2 | | > > > > > > | N1 +------------------+ N2 | > > > > > > | | component link 3 | | > > > > > > | +------------------+ | > > > > > > +------+ +---+--+ > > > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component > links > > > with > > > > > > 32TSs available on the first one, 24TSs on the second, > 24TSs > > > on the > > > > > > third and supporting ODU2 and ODU3 signal types. The node > > > would > > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs > and > > a > > > MAX > > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > > network > > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > only > > > a > > > > > > single ODU3 can be set up and a crank-back would be > > > originated. In > > > > > > more complex network scenarios the number of crank-backs > can > > > be much > > > > > > higher." > > > > > > > > > > > > In other words, advertising the number of availble resources > > per > > > signal > > > > > > type does not avoid the possibility of cranck-back but > > decreases > > > it as > > > > > > much as possible. For sure a good routing prevents from > crank- > > > backs > > > > > > caused by the restoration of LSP originating on the same > > Ingress. > > > The > > > > > > cranck-backs due to the concurrent restoration of LSPs > > > originating on > > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > > > BR > > > > > > Daniele > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > In line > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, one more question. > > > > > > > > > > > > What about the unreserved bandwidth? > > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per > role > > > per > > > > > > (muxCap & signal type) you also need to advertise the > > unreserved > > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > > correct? > > > This > > > > > > also implies extending the unreserved bandwidth TLV so to > > create > > > a > > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > > subTLV). > > > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > > ISCD > > > per > > > > > > IB>> role per (muxCap & signal type) per priority level. > > However, > > > total > > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > unless > > > you > > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > > > Igor > > > > > > > > > > > > Thanks > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Understood... > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > sufficient > > > > > > > > > > > > > > That's exactly what I've been > > > > > > > trying to say all along. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Regards > > > > > > > Snigdho > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Daniele Ceccarelli > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an > ISCD > > > per > > > > > > role > > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > > signal > > > > > > type. > > > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > > switchCap =3D3D role; > > > > > > > > encodeType =3D3D muxCap & signal type; > > > > > > > > We also have 16 reserved bits which can use for OTN > > specific > > > info > > > > > > in > > > > > > > > case we need it. > > > > > > > [SCB] I am yet to clearly understand what the role of > "role" > > > is, but > > > > > > > agree with your observation on the encode-type and the 16 > > > > > > > reserved-bits to further classify the switching > information. > > > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. > For > > > each > > > > > > role > > > > > > > > you would advertise just the unreserved bandwidth but you > > > wouldn't > > > > > > > know > > > > > > > > if such bandwidth is available for a certain type of ODUj > > LSP > > > (e.g. > > > > > > > 15 > > > > > > > > Gbps available on 3 component links: you advertise 45 > Gbps > > > > > > available > > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > > scalability > > > > > > > issues > > > > > > > > and the requirement of being able to bundle component > links > > > > > > together > > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > > ISDCs > > > > > > will > > > > > > > > provide a lot of flexibility: you can specify different > > > things > > > > > > (e.g. > > > > > > > > available bandwidth) for the same link in different > roles. > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > > sufficient? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Daniele > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Igor Bryskin > > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Fatai Zhang > > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > Thanks. > > > > > > > > I understand what you said. Therefore, we have added some > > > text to > > > > > > > > address the requirment in FWK document. However, we still > > > don't > > > > > > > > think that we need to extend ISC to meet the requirment. > > The > > > role > > > > > > of > > > > > > > > the > > > > > > > ODU > > > > > > > > can be get from the routing information implicitly. In > the > > > [draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > "Full > > > > > > Lambda" > > > > > > > is > > > > > > > > introduced. > > > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > > a) this requires OTN specific advertising and processing > > > rules; > > > > > > > > b) disallows topology separation in technology > independent > > > way > > > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > > container > > > > > > > does > > > > > > > > not change hop-by-hop (as some people seem to believe). > The > > > role is > > > > > > > > only meaningful on the ODU terminating nodes and > irrelevant > > > on > > > > > > > transit > > > > > > > > nodes. It is it's position in the hierarchy (but not > role) > > > that may > > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > AI1 > > > and > > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > can > > > only > > > > > > > support > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > with > > > the > > > > > > > role > > > > > > > > of Ho ODU level is requested, according to your > statement, > > > this > > > > > > > > conneciton will be allowed to be created. However, it > > should > > > not be > > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 > TE > > > link > > > > > > ends > > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and > OIN_LO_SC, > > > while > > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > path > > > > > > > > computation is constrained to the OTN_HO_SC topology, B11 > > and > > > B12 > > > > > > TE > > > > > > > > links will > > > > > > > be > > > > > > > > disallowed, and the resulting path (if any) will not go > > > through B11 > > > > > > > and > > > > > > > > B12. If one circumvents the path computation by providing > > the > > > fully > > > > > > > > explicit path, the signaling should fail on node B for > the > > > same > > > > > > > reason: > > > > > > > > inconsistency of required (signaled) and supported (by > > local > > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify > that > > > the > > > > > > type > > > > > > > > indicated in the Switching Type parameter is supported > on > > > the > > > > > > > > corresponding incoming interface. If the type cannot be > > > > > > supported, > > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > > problem/Switching Type" indication." > > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Lou Berger" > ; > > > > > > > > ; > > > > > > > framework@tools.ietf.org> > > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > > ccamp@ietf.org; > > > > > > > draft- > > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > > > I think role does not equal switching capability. The > > > operators can > > > > > > > > define different roles depending on their policy and > > achieve > > > the > > > > > > > > role through different methods. However, for OTN > networks, > > > the > > > > > > > > containers (e.g., ODUk) all have the same switching > > > capablility > > > > > > > > (i.e., TDM > > > > > > > > switching) and I think we should reflect the natural > > > > > > characteristics > > > > > > > of > > > > > > > > links in the routing. In addition, if we extend the ISC, > it > > > will > > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > > overrides > > > > > > > > encoding type). > > > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > > views the > > > > > > > > network as a stack of topologies. Whether a given > topology > > is > > > real > > > > > > > > or virtual is of no importance. > > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > switching > > > > > > > > capability field (confusing name as it is) is a good way > to > > > > > > describe > > > > > > > a > > > > > > > > layer in technology independent way, so that, say, MPLS- > TP- > > > >OTN_LO- > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > > stack of > > > > > > > > topologies that could be easily separated in technology > > > independent > > > > > > > way > > > > > > > > should path computation be constrained to particular one > or > > > > > > > > sub-stack of them. > > > > > > > > I think a good way to identify an OTN (virtual) topology > is > > > via > > > > > > > > (infrastructure) ODU container role of ODUs comprising > the > > > > > > topology. > > > > > > > > BTW IMO the role of an ODU container does not change hop- > > by- > > > hop (as > > > > > > > > some people seem to believe). The role is only meaningful > > on > > > the > > > > > > ODU > > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > it's > > > > > > > position > > > > > > > > in the hierarchy (but not role) that may change hop-by- > hop. > > > ODU's > > > > > > > role > > > > > > > > is the level of topology it is provisioned for and it is > > the > > > same > > > > > > > > for all ODUs that comprise the topology. For, example a > > user > > > may > > > > > > > provision > > > > > > > > a LO topology and constrain ODUs he sells to a set of > > clients > > > to > > > > > > use > > > > > > > > the topology rather than any resources available on OTN > > > network. > > > > > > > > The bottom line: container's role is the same as the role > > of > > > > > > virtual > > > > > > > > topology the container is a part of and could be > advertised > > > as the > > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise > the > > > roles > > > > > > > > and muxing capabilities with the ISCD of RFC4202, could > you > > > > > > clarify? > > > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > etc.) > > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > > > In addition, could you clarify my questions in another > > email > > > > > > (copied > > > > > > > as > > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > > other. > > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > > hierarchy, > > > > > > which > > > > > > > is > > > > > > > > a mistake IMO. > > > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 > or > > > ODU3 as > > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if > there > > is > > > a > > > > > > OTU3 > > > > > > > link > > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > > (service > > > > > > > > over > > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > > this > > > case, > > > > > > > how > > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > > Level? > > > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important > on > > > the ODU > > > > > > > > terminating nodes (i.e. on either side of corresponding > > > link). What > > > > > > > > happens on the ODU transit nodes and its place in the > > > hierarchy on > > > > > > > the > > > > > > > > transit nodes are of no importance. My LO container can > be > > > carried > > > > > > > > by somebody else's LO container and can carry my client's > > LO > > > > > > container. > > > > > > > To > > > > > > > > some extent it is similar to MPLS LSP role: LSP always > has > > a > > > role > > > > > > > (e.g. > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > > along its > > > > > > > > path. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Fatai Zhang" > > > ; > > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org> > > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > > > I agree that there should be multiple OTN specific > encoding > > > types > > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > > capabilities > > > > > > > > rather than the link's role (i.e. level in the OTN > > hierarchy: > > > LO, > > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > > indicated > > > > > > > > with a separate switchcaps. I can give you several > reasons: > > > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have > different > > > roles; > > > > > > 2. > > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > > different > > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > > capabilities can > > > > > > > be > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > > ISCD is > > > > > > > > required); 4. The combination of swicthcaps and encoding > > type > > > will > > > > > > > look > > > > > > > > to CP as a separate layer, which is exactly how ITU > models > > > OTN > > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > > operator > > > > > > would > > > > > > > > want to constrain the routing of OTN connections to pre- > > > configured > > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > > sells to > > > > > > > the > > > > > > > > clients to one or more pre-configured LO topologies), > this > > > would be > > > > > > > > possible to do in a technology independent way. Suppose > an > > > instance > > > > > > > of > > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > > from > > > HO OTN > > > > > > > > links will be no different from the separation of WDM > links > > > from > > > > > > > OTUs. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > > To: Igor Bryskin > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger; > > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > In message > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > > srv- > > > > > > > > exgen.atl.advaoptical.com> > > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > many > > > as > > > > > > the > > > > > > > > depth of the deepest possible OTN DP hierarchy, for > > example: > > > > > > > > > > > > > > > > > > typedef enum > > > > > > > > > { > > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high > order > > > */ > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM > and > > > make the > > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > > Digital > > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > > which had > > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > > long time > > > > > > ago. > > > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR > that > > > did not > > > > > > > > understand what the TS type meant did not try to > multiplex > > > its LO > > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > > commited > > > > > > to > > > > > > > using > > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > > OTN_HO or > > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, > then > > > the > > > > > > > latter > > > > > > > > is for backward compatibility and should be ignored if > > > OTN_LO, > > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > > 1.25 > > > TS > > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > can > > > be > > > > > > withdrawn. > > > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > > of > > > the > > > > > > LSP > > > > > > > > regardless of what goes on in the middle since that > > > determines what > > > > > > > can > > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > OTU3 > > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 > or > > > ODUj=3D3Df=3D > > > > lex > > > > > > > > even though the ODUk=3D3D2 at the next hop could not > directly > > > contain > > > > > > an ODU0. > > > > > > > > If the SHO Encoding Type is used, then it indicates that > > two > > > levels > > > > > > > of > > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > > 4328 > > > Switch > > > > > > > > Types currently don't include an ODUj or ODUk distinction > > but > > > if > > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > > Along > > > > > > > > with the new Encoding Type new Signal Types for ODU0, > ODU4, > > > and > > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > > I'm > > > not > > > > > > > clear > > > > > > > > how in an FA it can be indicated that either type is > > > currently > > > > > > > > available (NE capable of both and hasn't committed to > > either > > > one > > > > > > > yet). > > > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of > messages > > > on this > > > > > > > > would indicate a huge controversy and I'm not getting it > > > (other > > > > > > than > > > > > > > a > > > > > > > > strong preference to rely on bytes/sec or on enumerated > > type > > > > > > fields). > > > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. > I'm > > > not sure > > > > > > > if > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > > framework, > > > > > > > > or other intent. Could someone (either draft) concisely > > > summarize > > > > > > > > the multiplexing restrictions in one place, including > > > restrictions > > > > > > > > on number of multiplexing layers at one LSR. That might > > > help. > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] On > > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > > framework > > > > > > > > > > document before we can embark on any proposals to the > > > problem. > > > > > > I > > > > > > > am > > > > > > > > > > still not clear why do we have to deviate from the > > > general > > > > > > > approach > > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi- > layer > > > control > > > > > > > > > > IB>> plane, and > > > > > > > > > > it is highly desirable to adhere to the layer > > independent > > > > > > > paradigm > > > > > > > > > > of advertising of TE links, and there is no reason to > > > invent an > > > > > > > OTN > > > > > > > > > > specific ISCD. The combination of Switching > Capability > > > and > > > > > > > Encoding > > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > > multiplexing > > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > > link, > > > and, > > > > > > if > > > > > > > > > > this not sufficient, you have another reserved 16 > bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > new > > > > > > > > > > >TE-link > > > > > > > > to > > > > > > > > > > represent >the low-order ODUj bandwidth within the > > high- > > > order > > > > > > > > containers. > > > > > > > > > > This is simply >blowing up the solution to a very > > simple > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > possibility > > > to > > > > > > > create > > > > > > > > > > IB>> OTN > > > > > > > > > > hierarchies and constrain LO connections to HO > > > containers, one > > > > > > > > needs > > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among > authors > > > and > > > > > > > > > > other interested experts, and we think the proposal > > > described > > > > > > in > > > > > > > "draft- > > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] > draft > > > is more > > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > > needed for > > > > > > > > > > control plane, no matter how you encode the routing > > > > > > information. > > > > > > > > For > > > > > > > > > > TDM networks, you know the resource is allocated > based > > on > > > TS, > > > > > > so > > > > > > > > the > > > > > > > > > > available TS should be get or induced before creating > > > cross- > > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > > information, > > > > > > > I > > > > > > > > > > think you need go to the routing drafts (info model > and > > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > > encoding), > > > > > > you > > > > > > > > > > will find that one of your suggestions is adopted > > (i.e., > > > simply > > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > > ..., > > > ODU4 > > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > links) > > > as FA > > > > > > > for > > > > > > > > > > ODU1, you have to advertise a new TE link or put this > > FA > > > as a > > > > > > > > > > component link of an existing TE link (like > > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > > g709-framework@tools.ietf.org ccamp- > > > gmpls- > > > > > > > g709- > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > I believe there has been some off-line discussion > on > > > how to > > > > > > > > better > > > > > > > > > > > align the work with 4202. Use of common approaches > > is > > > of > > > > > > > course > > > > > > > > > > > one of the main objectives of *C*CAMP. I look > > forward > > > to > > > > > > > hearing > > > > > > > > > > > from the draft and discussion contributors on there > > > progress > > > > > > > > > > > on > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > > >> Hello, > > > > > > > > > > >> > > > > > > > > > > >> I have a comment and a question on Section > 3.1.2.1. > > > This > > > > > > > section > > > > > > > > > > >> describes the link-parameters that are required > for > > > OTN > > > > > > > service > > > > > > > > > > >> routing purposes. > > > > > > > > > > >> > > > > > > > > > > >> My comment is how are we going to advertise the > low- > > > order > > > > > > > > > > >> ODUj availability within a higher-order container. > > For > > > > > > > > > > >> example, consider an > > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > > granularity > > > and > > > > > > > > > > >> then > > > > > > > > we > > > > > > > > > > >> establish an ODU2 service over the link. At this > > point > > > in > > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > > ODU2 > > > > > > > > > > >> services > > > > > > > and > > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services > (4 > > > ODU1s > > > > > > > > > > >> are contained over the ODU2). So it is obvious > from > > > this > > > > > > > > > > >> example > > > > > > > > that > > > > > > > > > > >> the number of time-slots available is different > > based > > > on the > > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > > >> How do we address this issue based on the approach > > > specified > > > > > > > in > > > > > > > > > > >> the > > > > > > > > > > draft? > > > > > > > > > > >> > > > > > > > > > > >> My other question is why not simply advertize the > > > available > > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances or > > > > > > > the > > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > > This > > > > > > > > > > >> approach seems to be more in-line with the general > > > approach > > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > > section > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > > ISCDs > > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > > additional > > > > > > > > > > >> benefit > > > > > > > > is > > > > > > > > > > >> that the advertisement is TS size independent and > > > hence will > > > > > > > > > > >> simplify the implementation. > > > > > > > > > > >> > > > > > > > > > > >> Regards > > > > > > > > > > >> > > > > > > > > > > >> Snigdho From jdrake@juniper.net Tue Jul 20 15:03:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A83C3A693B for ; Tue, 20 Jul 2010 15:03:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...C0D761EF@atl-srv-exgen.atl.advaoptical.com>\n \n X-Spam-Flag: NO X-Spam-Score: -5.314 X-Spam-Level: X-Spam-Status: No, score=-5.314 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-oBqJbPCOFg for ; Tue, 20 Jul 2010 15:03:26 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BC4CF3A67E7 for ; Tue, 20 Jul 2010 15:03:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTEYdMwgYMO/6bHTPpX9IhdvIovOR/6Aw@postini.com; Tue, 20 Jul 2010 15:03:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 20 Jul 2010 14:22:39 -0700 From: John E Drake To: John E Drake , Igor Bryskin , "curtis@occnc.com" , Snigdho Bardalai Date: Tue, 20 Jul 2010 14:22:37 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAAasgAAAAvvsA= Message-ID: <5E893DB832F57341992548CDBB333163984487CCCC@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 22:03:30 -0000 Igor, In the same way that RFC 3471 describes the GMPLS signaling functions and R= FC 3473 describes the RSVP encodings, RFC 4202 describes the GMPLS routing = functions and RFC 4203 describes the OSPF encodings (and has normative refe= rences to RFC 4202). The fact that RFC 4203 contains no description of min= or max bandwidth should have been a clue to check the normative references= , as opposed to just deciding that you know what they mean. Thanks, John > -----Original Message----- > From: John E Drake > Sent: Tuesday, July 20, 2010 2:10 PM > To: 'Igor Bryskin'; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > I was describing SDH/SONET not OTN, I have no idea what you mean by > "last field", and I have no idea what you mean by "unresolved > bandwidth". > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Tuesday, July 20, 2010 2:02 PM > > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > Do you understand the quote from RFC4203: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Capability-specific information | > > | (variable) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > You can use the last field for OTN switchcap to advertise unresolved > > bandwidth available for the ISCD on per priority level. > > > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 4:35 PM > > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snipped... > > > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > > priority > > > level for every ISCD. > > > > JD: Igor, what part of my quote from RFC 4202 did you not > understand? > > You do not advertise unreserved bandwidth in the ISCD TLV. In > > particular, for TDM, what is advertised is the max and min bandwidth > > allowed for a single LSP. It was designed to produce a compact > > representation by taking advantage of the SDH/SONET hierarchy. > > > > Advertising a separate ISCD for each supported rate is allowed but > > wasteful. > > > > > > > > Igor > > > > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > > wro=3D > > > > te: > > > > > > > > > John, > > > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > > However if a > > > > > TE link advertises more than one ISCD (with each ISCD > containing > > > only max > > > > > lsp bandwidth per priority), it is necessary to indicate how > the > > > total li=3D > > > > nk > > > > > unreserved bandwidth is partitioned between several ISCDs. What > I > > > am > > > > > suggesting is instead of advertising the unreserved bandwidth > > > multiple ti=3D > > > > mes > > > > > (one per ISCD), indicate how the bandwidth is split between the > > > ISCDs: e.=3D > > > > g > > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > > > Igor. > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > > Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > Igor, > > > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so > the > > > issue o=3D > > > > f > > > > > partitioning unreserved bandwidth across multiple advertised > TDM > > > ISC TLVs=3D > > > > is > > > > > actually a non-issue. > > > > > > > > > > Unreserved bandwidth by priority has always been advertised > using > > > the MPL=3D > > > > S > > > > > sub-TLV. My point has been that we have never had a > requirement > > > (includi=3D > > > > ng > > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > > signal > > > type, =3D > > > > so > > > > > what is special about OTN? > > > > > > > > > > A further point would be that if we do decide that it is > > necessary > > > to > > > > > advertise unreserved bandwidth by signal type, it should be > done > > in > > > a > > > > > general way and not in an OTN specific manner. (And in fact, > the > > > argumen=3D > > > > ts > > > > > that unreserved bandwidth by signal type needs to be > advertised, > > > such as =3D > > > > the > > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > It is a valid point, but the suggested solution is way too > > > expensive. > > > > > > All you need is a way to say how the advertised unreserved > > > bandwidth is > > > > > > partitioned between ISCDs in case the TE link advertisement > > > contains > > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > > bits out > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > > total > > > > > > unreserved bandwidth associated with the ISCD. Another way is > > to > > > use > > > > > > swicthcap specific extension. > > > > > > BTW: this is not an OTN specific issue, rather more general: > > any > > > time > > > > > > when a TE link advertises more than one ISCD (which is > > perfectly > > > Ok > > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, > > > > > > > > > > > > The need for unreserved resources advertised per signal type > is > > > the > > > > > > concurrent path computation. I'll answer quoting a section > from > > > the > > > > > > info-model draft, please have a look in particular to the > > > example: > > > > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > > and > > > per > > > > > > signal type in order to allow the correct functioning of > the > > > > > > restoration process. [RFC4203] only allows advertising > > > unreserved > > > > > > resources per priority, this leads not to know how many > LSPs > > > of a > > > > > > specific signal type can be restored. As example it is > > > possible to > > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > > > +------+ component link 1 +------+ > > > > > > | +------------------+ | > > > > > > | | component link 2 | | > > > > > > | N1 +------------------+ N2 | > > > > > > | | component link 3 | | > > > > > > | +------------------+ | > > > > > > +------+ +---+--+ > > > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component > links > > > with > > > > > > 32TSs available on the first one, 24TSs on the second, > 24TSs > > > on the > > > > > > third and supporting ODU2 and ODU3 signal types. The node > > > would > > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs > and > > a > > > MAX > > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > > network > > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > only > > > a > > > > > > single ODU3 can be set up and a crank-back would be > > > originated. In > > > > > > more complex network scenarios the number of crank-backs > can > > > be much > > > > > > higher." > > > > > > > > > > > > In other words, advertising the number of availble resources > > per > > > signal > > > > > > type does not avoid the possibility of cranck-back but > > decreases > > > it as > > > > > > much as possible. For sure a good routing prevents from > crank- > > > backs > > > > > > caused by the restoration of LSP originating on the same > > Ingress. > > > The > > > > > > cranck-backs due to the concurrent restoration of LSPs > > > originating on > > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > > > BR > > > > > > Daniele > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > In line > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, one more question. > > > > > > > > > > > > What about the unreserved bandwidth? > > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per > role > > > per > > > > > > (muxCap & signal type) you also need to advertise the > > unreserved > > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > > correct? > > > This > > > > > > also implies extending the unreserved bandwidth TLV so to > > create > > > a > > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > > subTLV). > > > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > > ISCD > > > per > > > > > > IB>> role per (muxCap & signal type) per priority level. > > However, > > > total > > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > unless > > > you > > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > > > Igor > > > > > > > > > > > > Thanks > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Understood... > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > sufficient > > > > > > > > > > > > > > That's exactly what I've been > > > > > > > trying to say all along. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Regards > > > > > > > Snigdho > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Daniele Ceccarelli > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an > ISCD > > > per > > > > > > role > > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > > signal > > > > > > type. > > > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > > switchCap =3D3D role; > > > > > > > > encodeType =3D3D muxCap & signal type; > > > > > > > > We also have 16 reserved bits which can use for OTN > > specific > > > info > > > > > > in > > > > > > > > case we need it. > > > > > > > [SCB] I am yet to clearly understand what the role of > "role" > > > is, but > > > > > > > agree with your observation on the encode-type and the 16 > > > > > > > reserved-bits to further classify the switching > information. > > > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. > For > > > each > > > > > > role > > > > > > > > you would advertise just the unreserved bandwidth but you > > > wouldn't > > > > > > > know > > > > > > > > if such bandwidth is available for a certain type of ODUj > > LSP > > > (e.g. > > > > > > > 15 > > > > > > > > Gbps available on 3 component links: you advertise 45 > Gbps > > > > > > available > > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > > scalability > > > > > > > issues > > > > > > > > and the requirement of being able to bundle component > links > > > > > > together > > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > > ISDCs > > > > > > will > > > > > > > > provide a lot of flexibility: you can specify different > > > things > > > > > > (e.g. > > > > > > > > available bandwidth) for the same link in different > roles. > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > > sufficient? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Daniele > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Igor Bryskin > > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Fatai Zhang > > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > Thanks. > > > > > > > > I understand what you said. Therefore, we have added some > > > text to > > > > > > > > address the requirment in FWK document. However, we still > > > don't > > > > > > > > think that we need to extend ISC to meet the requirment. > > The > > > role > > > > > > of > > > > > > > > the > > > > > > > ODU > > > > > > > > can be get from the routing information implicitly. In > the > > > [draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > "Full > > > > > > Lambda" > > > > > > > is > > > > > > > > introduced. > > > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > > a) this requires OTN specific advertising and processing > > > rules; > > > > > > > > b) disallows topology separation in technology > independent > > > way > > > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > > container > > > > > > > does > > > > > > > > not change hop-by-hop (as some people seem to believe). > The > > > role is > > > > > > > > only meaningful on the ODU terminating nodes and > irrelevant > > > on > > > > > > > transit > > > > > > > > nodes. It is it's position in the hierarchy (but not > role) > > > that may > > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > AI1 > > > and > > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > can > > > only > > > > > > > support > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > with > > > the > > > > > > > role > > > > > > > > of Ho ODU level is requested, according to your > statement, > > > this > > > > > > > > conneciton will be allowed to be created. However, it > > should > > > not be > > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 > TE > > > link > > > > > > ends > > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and > OIN_LO_SC, > > > while > > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > path > > > > > > > > computation is constrained to the OTN_HO_SC topology, B11 > > and > > > B12 > > > > > > TE > > > > > > > > links will > > > > > > > be > > > > > > > > disallowed, and the resulting path (if any) will not go > > > through B11 > > > > > > > and > > > > > > > > B12. If one circumvents the path computation by providing > > the > > > fully > > > > > > > > explicit path, the signaling should fail on node B for > the > > > same > > > > > > > reason: > > > > > > > > inconsistency of required (signaled) and supported (by > > local > > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify > that > > > the > > > > > > type > > > > > > > > indicated in the Switching Type parameter is supported > on > > > the > > > > > > > > corresponding incoming interface. If the type cannot be > > > > > > supported, > > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > > problem/Switching Type" indication." > > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Lou Berger" > ; > > > > > > > > ; > > > > > > > framework@tools.ietf.org> > > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > > ccamp@ietf.org; > > > > > > > draft- > > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > > > I think role does not equal switching capability. The > > > operators can > > > > > > > > define different roles depending on their policy and > > achieve > > > the > > > > > > > > role through different methods. However, for OTN > networks, > > > the > > > > > > > > containers (e.g., ODUk) all have the same switching > > > capablility > > > > > > > > (i.e., TDM > > > > > > > > switching) and I think we should reflect the natural > > > > > > characteristics > > > > > > > of > > > > > > > > links in the routing. In addition, if we extend the ISC, > it > > > will > > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > > overrides > > > > > > > > encoding type). > > > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > > views the > > > > > > > > network as a stack of topologies. Whether a given > topology > > is > > > real > > > > > > > > or virtual is of no importance. > > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > switching > > > > > > > > capability field (confusing name as it is) is a good way > to > > > > > > describe > > > > > > > a > > > > > > > > layer in technology independent way, so that, say, MPLS- > TP- > > > >OTN_LO- > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > > stack of > > > > > > > > topologies that could be easily separated in technology > > > independent > > > > > > > way > > > > > > > > should path computation be constrained to particular one > or > > > > > > > > sub-stack of them. > > > > > > > > I think a good way to identify an OTN (virtual) topology > is > > > via > > > > > > > > (infrastructure) ODU container role of ODUs comprising > the > > > > > > topology. > > > > > > > > BTW IMO the role of an ODU container does not change hop- > > by- > > > hop (as > > > > > > > > some people seem to believe). The role is only meaningful > > on > > > the > > > > > > ODU > > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > it's > > > > > > > position > > > > > > > > in the hierarchy (but not role) that may change hop-by- > hop. > > > ODU's > > > > > > > role > > > > > > > > is the level of topology it is provisioned for and it is > > the > > > same > > > > > > > > for all ODUs that comprise the topology. For, example a > > user > > > may > > > > > > > provision > > > > > > > > a LO topology and constrain ODUs he sells to a set of > > clients > > > to > > > > > > use > > > > > > > > the topology rather than any resources available on OTN > > > network. > > > > > > > > The bottom line: container's role is the same as the role > > of > > > > > > virtual > > > > > > > > topology the container is a part of and could be > advertised > > > as the > > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise > the > > > roles > > > > > > > > and muxing capabilities with the ISCD of RFC4202, could > you > > > > > > clarify? > > > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > etc.) > > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > > > In addition, could you clarify my questions in another > > email > > > > > > (copied > > > > > > > as > > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > > other. > > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > > hierarchy, > > > > > > which > > > > > > > is > > > > > > > > a mistake IMO. > > > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 > or > > > ODU3 as > > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if > there > > is > > > a > > > > > > OTU3 > > > > > > > link > > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > > (service > > > > > > > > over > > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > > this > > > case, > > > > > > > how > > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > > Level? > > > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important > on > > > the ODU > > > > > > > > terminating nodes (i.e. on either side of corresponding > > > link). What > > > > > > > > happens on the ODU transit nodes and its place in the > > > hierarchy on > > > > > > > the > > > > > > > > transit nodes are of no importance. My LO container can > be > > > carried > > > > > > > > by somebody else's LO container and can carry my client's > > LO > > > > > > container. > > > > > > > To > > > > > > > > some extent it is similar to MPLS LSP role: LSP always > has > > a > > > role > > > > > > > (e.g. > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > > along its > > > > > > > > path. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Fatai Zhang" > > > ; > > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org> > > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > > > I agree that there should be multiple OTN specific > encoding > > > types > > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > > capabilities > > > > > > > > rather than the link's role (i.e. level in the OTN > > hierarchy: > > > LO, > > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > > indicated > > > > > > > > with a separate switchcaps. I can give you several > reasons: > > > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have > different > > > roles; > > > > > > 2. > > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > > different > > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > > capabilities can > > > > > > > be > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > > ISCD is > > > > > > > > required); 4. The combination of swicthcaps and encoding > > type > > > will > > > > > > > look > > > > > > > > to CP as a separate layer, which is exactly how ITU > models > > > OTN > > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > > operator > > > > > > would > > > > > > > > want to constrain the routing of OTN connections to pre- > > > configured > > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > > sells to > > > > > > > the > > > > > > > > clients to one or more pre-configured LO topologies), > this > > > would be > > > > > > > > possible to do in a technology independent way. Suppose > an > > > instance > > > > > > > of > > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > > from > > > HO OTN > > > > > > > > links will be no different from the separation of WDM > links > > > from > > > > > > > OTUs. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > > To: Igor Bryskin > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger; > > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > In message > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > > srv- > > > > > > > > exgen.atl.advaoptical.com> > > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > many > > > as > > > > > > the > > > > > > > > depth of the deepest possible OTN DP hierarchy, for > > example: > > > > > > > > > > > > > > > > > > typedef enum > > > > > > > > > { > > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high > order > > > */ > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM > and > > > make the > > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > > Digital > > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > > which had > > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > > long time > > > > > > ago. > > > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR > that > > > did not > > > > > > > > understand what the TS type meant did not try to > multiplex > > > its LO > > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > > commited > > > > > > to > > > > > > > using > > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > > OTN_HO or > > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, > then > > > the > > > > > > > latter > > > > > > > > is for backward compatibility and should be ignored if > > > OTN_LO, > > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > > 1.25 > > > TS > > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > can > > > be > > > > > > withdrawn. > > > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > > of > > > the > > > > > > LSP > > > > > > > > regardless of what goes on in the middle since that > > > determines what > > > > > > > can > > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > OTU3 > > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 > or > > > ODUj=3D3Df=3D > > > > lex > > > > > > > > even though the ODUk=3D3D2 at the next hop could not > directly > > > contain > > > > > > an ODU0. > > > > > > > > If the SHO Encoding Type is used, then it indicates that > > two > > > levels > > > > > > > of > > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > > 4328 > > > Switch > > > > > > > > Types currently don't include an ODUj or ODUk distinction > > but > > > if > > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > > Along > > > > > > > > with the new Encoding Type new Signal Types for ODU0, > ODU4, > > > and > > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > > I'm > > > not > > > > > > > clear > > > > > > > > how in an FA it can be indicated that either type is > > > currently > > > > > > > > available (NE capable of both and hasn't committed to > > either > > > one > > > > > > > yet). > > > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of > messages > > > on this > > > > > > > > would indicate a huge controversy and I'm not getting it > > > (other > > > > > > than > > > > > > > a > > > > > > > > strong preference to rely on bytes/sec or on enumerated > > type > > > > > > fields). > > > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. > I'm > > > not sure > > > > > > > if > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > > framework, > > > > > > > > or other intent. Could someone (either draft) concisely > > > summarize > > > > > > > > the multiplexing restrictions in one place, including > > > restrictions > > > > > > > > on number of multiplexing layers at one LSR. That might > > > help. > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] On > > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > > framework > > > > > > > > > > document before we can embark on any proposals to the > > > problem. > > > > > > I > > > > > > > am > > > > > > > > > > still not clear why do we have to deviate from the > > > general > > > > > > > approach > > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi- > layer > > > control > > > > > > > > > > IB>> plane, and > > > > > > > > > > it is highly desirable to adhere to the layer > > independent > > > > > > > paradigm > > > > > > > > > > of advertising of TE links, and there is no reason to > > > invent an > > > > > > > OTN > > > > > > > > > > specific ISCD. The combination of Switching > Capability > > > and > > > > > > > Encoding > > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > > multiplexing > > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > > link, > > > and, > > > > > > if > > > > > > > > > > this not sufficient, you have another reserved 16 > bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > new > > > > > > > > > > >TE-link > > > > > > > > to > > > > > > > > > > represent >the low-order ODUj bandwidth within the > > high- > > > order > > > > > > > > containers. > > > > > > > > > > This is simply >blowing up the solution to a very > > simple > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > possibility > > > to > > > > > > > create > > > > > > > > > > IB>> OTN > > > > > > > > > > hierarchies and constrain LO connections to HO > > > containers, one > > > > > > > > needs > > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among > authors > > > and > > > > > > > > > > other interested experts, and we think the proposal > > > described > > > > > > in > > > > > > > "draft- > > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] > draft > > > is more > > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > > needed for > > > > > > > > > > control plane, no matter how you encode the routing > > > > > > information. > > > > > > > > For > > > > > > > > > > TDM networks, you know the resource is allocated > based > > on > > > TS, > > > > > > so > > > > > > > > the > > > > > > > > > > available TS should be get or induced before creating > > > cross- > > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > > information, > > > > > > > I > > > > > > > > > > think you need go to the routing drafts (info model > and > > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > > encoding), > > > > > > you > > > > > > > > > > will find that one of your suggestions is adopted > > (i.e., > > > simply > > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > > ..., > > > ODU4 > > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > links) > > > as FA > > > > > > > for > > > > > > > > > > ODU1, you have to advertise a new TE link or put this > > FA > > > as a > > > > > > > > > > component link of an existing TE link (like > > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > > g709-framework@tools.ietf.org ccamp- > > > gmpls- > > > > > > > g709- > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > I believe there has been some off-line discussion > on > > > how to > > > > > > > > better > > > > > > > > > > > align the work with 4202. Use of common approaches > > is > > > of > > > > > > > course > > > > > > > > > > > one of the main objectives of *C*CAMP. I look > > forward > > > to > > > > > > > hearing > > > > > > > > > > > from the draft and discussion contributors on there > > > progress > > > > > > > > > > > on > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > > >> Hello, > > > > > > > > > > >> > > > > > > > > > > >> I have a comment and a question on Section > 3.1.2.1. > > > This > > > > > > > section > > > > > > > > > > >> describes the link-parameters that are required > for > > > OTN > > > > > > > service > > > > > > > > > > >> routing purposes. > > > > > > > > > > >> > > > > > > > > > > >> My comment is how are we going to advertise the > low- > > > order > > > > > > > > > > >> ODUj availability within a higher-order container. > > For > > > > > > > > > > >> example, consider an > > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > > granularity > > > and > > > > > > > > > > >> then > > > > > > > > we > > > > > > > > > > >> establish an ODU2 service over the link. At this > > point > > > in > > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > > ODU2 > > > > > > > > > > >> services > > > > > > > and > > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services > (4 > > > ODU1s > > > > > > > > > > >> are contained over the ODU2). So it is obvious > from > > > this > > > > > > > > > > >> example > > > > > > > > that > > > > > > > > > > >> the number of time-slots available is different > > based > > > on the > > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > > >> How do we address this issue based on the approach > > > specified > > > > > > > in > > > > > > > > > > >> the > > > > > > > > > > draft? > > > > > > > > > > >> > > > > > > > > > > >> My other question is why not simply advertize the > > > available > > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances or > > > > > > > the > > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > > This > > > > > > > > > > >> approach seems to be more in-line with the general > > > approach > > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > > section > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > > ISCDs > > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > > additional > > > > > > > > > > >> benefit > > > > > > > > is > > > > > > > > > > >> that the advertisement is TS size independent and > > > hence will > > > > > > > > > > >> simplify the implementation. > > > > > > > > > > >> > > > > > > > > > > >> Regards > > > > > > > > > > >> > > > > > > > > > > >> Snigdho From curtis@occnc.com Tue Jul 20 16:36:15 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8873A68E7 for ; Tue, 20 Jul 2010 16:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 680zG2r9yeUS for ; Tue, 20 Jul 2010 16:36:09 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id AD7D33A68DB for ; Tue, 20 Jul 2010 16:36:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6KNaIgn072073; Tue, 20 Jul 2010 19:36:18 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 14:20:42 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> Date: Tue, 20 Jul 2010 19:36:18 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 23:36:16 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > John, > > The point is that from ISCD you can not figure out how *many* LSPs > matching the ISCD you can accommodate on the link. Such information is > important in case of con-current routing (e.g. restoration after link > failure). > > Igor Igor, Sergio, RFC 4203 (in 1. Introduction) The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: [OSPF-TE] above is RFC 3630. RFC 3630 (in 2.4.2. Link TLV) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) If you read on you find: The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). and The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. [...] So the totals per link and per priority level are already there in the base spec before the RFC 4203 *extensions* to RFC 3630 were added. That is how you figure out how many ODU0 you can add to your existing ODU2, and so on. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows everything about everything. Myself (all too obviously sometimes) included.] Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > >From RFC 4202: > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > Bandwidth are enumerated in [GMPLS-SIG]. > > On an interface having Standard SDH multiplexing, an LSP at priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. > > On an interface having Arbitrary SDH multiplexing, an LSP at priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > >From RFC 4201: > > 3.10. Maximum LSP Bandwidth > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP Bandwidth > at priority p of all of its component links. > > > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > Snipped.... > > > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > > > > JD: As the person to whom I believe you are referring, I would suggest > > that you actually read RFC 4202 and 4206. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Wed Jul 21 00:49:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B478E3A6B59 for ; Wed, 21 Jul 2010 00:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKSglki10XCY for ; Wed, 21 Jul 2010 00:49:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6AAD53A63D3 for ; Wed, 21 Jul 2010 00:49:05 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-03-4c46a67f22aa Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FA.D4.06895.F76A64C4; Wed, 21 Jul 2010 09:49:20 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jul 2010 09:49:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 09:49:16 +0200 Message-ID: In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAWbSJA References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> From: "Daniele Ceccarelli" To: "Igor Bryskin" , "John E Drake" , , "Snigdho Bardalai" X-OriginalArrivalTime: 21 Jul 2010 07:49:19.0410 (UTC) FILETIME=[39C6B920:01CB28A9] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 07:49:09 -0000 Igor, In other words it could be possible to define 3 Switching Cap (LO, HO = and SHO) and put what we defined in the encoding draft into the = Switching Capability-specific information of the ISCD. Something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = -----Switching Capability-specific information |0|1|2|3|4|5|6|7| T | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I still don't understand why we need partitioning the network in three = layers while just Sublamba and Full lambda distinction is enough = (distinction supported advertising different signal types for full = lambdas and sublambdas. Personally i still prefer advertising these pieces of information as a = separate sub-TLV (called OTN-ISCD subTLV in the draft but easily = estensible to TDM-ISCD accordingly to = http://tools.ietf.org/html/draft-ong-gmpls-ason-routing-exper-02 format = proposed by the OIF) but this could be a valid solution too. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: marted=EC 20 luglio 2010 23.02 To: John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt=20 John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved = bandwidth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority = > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? = You do not advertise unreserved bandwidth in the ISCD TLV. In = particular, for TDM, what is advertised is the max and min bandwidth = allowed for a single LSP. It was designed to produce a compact = representation by taking advantage of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but = wasteful. > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done=20 > > > in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli=20 > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang;=20 > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and=20 > > > > a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while=20 > > > > only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same = Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli=20 > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang;=20 > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved = > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, = correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level.=20 > > > > IB>> However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles=20 > > > > IB>> unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang;=20 > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; We also have 16=20 > > > > > > reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16=20 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj=20 > > > > > > LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces=20 > > > > > > AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2=20 > > > > > > can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2=20 > > > > > > with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the=20 > > > > > > path computation is constrained to the OTN_HO_SC topology,=20 > > > > > > B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing=20 > > > > > > the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing=20 > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ;=20 > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ;=20 > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology=20 > > > > > > is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its=20 > > > > > > switching capability field (confusing name as it is) is a=20 > > > > > > good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or=20 > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is=20 > > > > > > it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of=20 > > > > > > clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC,=20 > > > > > > IB>> etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there=20 > > > > > > is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN = hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding=20 > > > > > > type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; = > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as=20 > > > > > > > many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high = order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA=20 > > > > > > can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 = or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not = directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction=20 > > > > > > but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou=20 > > > > > > > Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on=20 > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer=20 > > > > > > > > independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a=20 > > > > > > > > >new TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user=20 > > > > > > > > IB>> possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based=20 > > > > > > > > on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3=20 > > > > > > > > links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container.=20 > > > > > > > > >> For example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this=20 > > > > > > > > >> point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This = > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho From daniele.ceccarelli@ericsson.com Wed Jul 21 01:28:52 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467953A6B3D for ; Wed, 21 Jul 2010 01:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=1.873, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gToFFmX5R2Im for ; Wed, 21 Jul 2010 01:28:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8C5A83A68B3 for ; Wed, 21 Jul 2010 01:28:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-9f-4c46afd16ccd Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B4.78.10125.1DFA64C4; Wed, 21 Jul 2010 10:29:05 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jul 2010 10:29:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 10:29:03 +0200 Message-ID: In-Reply-To: <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZGb5GkrZ3IhaSFms97b6HVlGCAASXfMA References: Your message of "Tue, 20 Jul 2010 14:20:42 EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> From: "Daniele Ceccarelli" To: , "Igor Bryskin" X-OriginalArrivalTime: 21 Jul 2010 08:29:04.0835 (UTC) FILETIME=[C799B130:01CB28AE] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 08:28:52 -0000 Hi Curtis, You're perfectly right, the tools for Maximum Reservable Bandwidth and = Unreserved Bandwidth are already there, but they lack of distinguishing = how such bandiwdth is distributed over the various signal types = supported by the advertised link. Estending both of them plus the ISCD could be a bigger effort and = bandwidth consuming solution than introducing all the required = information into a single sub-TLV. Cheers Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Curtis Villamizar Sent: mercoled=EC 21 luglio 2010 1.36 To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] R: Comment = ondraft-ietf-ccamp-gmpls-g709-framework-01.txt In message = <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical= .com> Igor Bryskin writes: > =20 > John, > =20 > The point is that from ISCD you can not figure out how *many* LSPs=20 > matching the ISCD you can accommodate on the link. Such information is = > important in case of con-current routing (e.g. restoration after link=20 > failure). > =20 > Igor Igor, Sergio, RFC 4203 (in 1. Introduction) The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: [OSPF-TE] above is RFC 3630. RFC 3630 (in 2.4.2. Link TLV) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) If you read on you find: The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). and The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. [...] So the totals per link and per priority level are already there in the = base spec before the RFC 4203 *extensions* to RFC 3630 were added. That is how you figure out how many ODU0 you can add to your existing = ODU2, and so on. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows = everything about everything. Myself (all too obviously sometimes) included.] Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > >From RFC 4202: > =20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority = p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. > =20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. > =20 > Typical values for the Minimum LSP Bandwidth and for the Maximum = LSP > Bandwidth are enumerated in [GMPLS-SIG]. > =20 > On an interface having Standard SDH multiplexing, an LSP at = priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined = by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. > =20 > On an interface having Arbitrary SDH multiplexing, an LSP at = priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the = bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > =20 > >From RFC 4201: > =20 > 3.10. Maximum LSP Bandwidth > =20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP = Bandwidth > at priority p of all of its component links. > =20 > =20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-=20 > > framework-01.txt > >=20 > > Snipped.... > >=20 > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth=20 > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > >=20 > > JD: As the person to whom I believe you are referring, I would=20 > > suggest that you actually read RFC 4202 and 4206. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Wed Jul 21 02:45:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11C83A6B9C for ; Wed, 21 Jul 2010 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnP6T4gQPf7Y for ; Wed, 21 Jul 2010 02:45:25 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 07ADA3A6B7D for ; Wed, 21 Jul 2010 02:44:59 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6L9jCnH016645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Jul 2010 11:45:12 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 21 Jul 2010 11:45:12 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: "curtis@occnc.com" Date: Wed, 21 Jul 2010 11:45:10 +0200 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZF8RGYf4VrCGQkaChb59QnopZgAUr3tA Message-ID: References: Your message of "Tue, 20 Jul 2010 14:20:42 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> In-Reply-To: <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 09:45:27 -0000 Hi Curtis, Thanks for your comment. As pointed out by Daniele you're right but the missing information here is = the real spatial allocation that raised in importance above all in case of = link bundling unless you constrain the capability in 1 component link per T= E-link, that would reduce value of this very important feature for scalabil= ity. About the last part=20 [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows everything about everything. Myself (all too obviously sometimes) included.] I'm completely agree with you. I know all that is not simple and obvious stuff for everyone.=20 My only two cents is just to highlight it is not always possible justify th= at different solution for SDH control plane with respect what defined in RF= C 4202/4203 are deployed, with a bad reading of these RFCs. Best Regards Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: curtis@occnc.com [mailto:curtis@occnc.com]=20 Inviato: mercoled=EC 21 luglio 2010 1.36 A: Igor Bryskin Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardala= i Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01= .txt=20 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > =20 > John, > =20 > The point is that from ISCD you can not figure out how *many* LSPs > matching the ISCD you can accommodate on the link. Such information is > important in case of con-current routing (e.g. restoration after link > failure).=20 > =20 > Igor=20 Igor, Sergio, RFC 4203 (in 1. Introduction) The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: [OSPF-TE] above is RFC 3630. RFC 3630 (in 2.4.2. Link TLV) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) If you read on you find: The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). and The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. [...] So the totals per link and per priority level are already there in the base spec before the RFC 4203 *extensions* to RFC 3630 were added. That is how you figure out how many ODU0 you can add to your existing ODU2, and so on. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows everything about everything. Myself (all too obviously sometimes) included.] Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-= 01.txt > =20 > >From RFC 4202: > =20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. > =20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. > =20 > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > Bandwidth are enumerated in [GMPLS-SIG]. > =20 > On an interface having Standard SDH multiplexing, an LSP at priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. > =20 > On an interface having Arbitrary SDH multiplexing, an LSP at priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > =20 > >From RFC 4201: > =20 > 3.10. Maximum LSP Bandwidth > =20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP Bandwidth > at priority p of all of its component links. > =20 > =20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > >=20 > > Snipped.... > >=20 > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > >=20 > > JD: As the person to whom I believe you are referring, I would suggest > > that you actually read RFC 4202 and 4206. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Lyong@Ciena.com Wed Jul 21 05:20:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECFB3A6950 for ; Wed, 21 Jul 2010 05:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FoNtV1UbkET for ; Wed, 21 Jul 2010 05:20:58 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id D6F623A67ED for ; Wed, 21 Jul 2010 05:20:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 08:21:06 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901C29EBA@mdmxm03.ciena.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZGb5GkrZ3IhaSFms97b6HVlGCAASXfMAAAghs5A= References: Your message of "Tue, 20 Jul 2010 14:20:42EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com><201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> From: "Ong, Lyndon" Importance: normal Priority: normal To: "Daniele Ceccarelli" , , "Igor Bryskin" Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 12:20:59 -0000 I support this, I think this would be very helpful for TDM technology in = general. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Daniele Ceccarelli Sent: Wednesday, July 21, 2010 1:29 AM To: curtis@occnc.com; Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] R: = Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt Hi Curtis, You're perfectly right, the tools for Maximum Reservable Bandwidth and = Unreserved Bandwidth are already there, but they lack of distinguishing = how such bandiwdth is distributed over the various signal types = supported by the advertised link. Estending both of them plus the ISCD could be a bigger effort and = bandwidth consuming solution than introducing all the required = information into a single sub-TLV. Cheers Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Curtis Villamizar Sent: mercoled=C3=AC 21 luglio 2010 1.36 To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] R: Comment = ondraft-ietf-ccamp-gmpls-g709-framework-01.txt In message = <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical= .com> Igor Bryskin writes: > =20 > John, > =20 > The point is that from ISCD you can not figure out how *many* LSPs=20 > matching the ISCD you can accommodate on the link. Such information is = > important in case of con-current routing (e.g. restoration after link=20 > failure). > =20 > Igor Igor, Sergio, RFC 4203 (in 1. Introduction) The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: [OSPF-TE] above is RFC 3630. RFC 3630 (in 2.4.2. Link TLV) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) If you read on you find: The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). and The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. [...] So the totals per link and per priority level are already there in the = base spec before the RFC 4203 *extensions* to RFC 3630 were added. That is how you figure out how many ODU0 you can add to your existing = ODU2, and so on. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows = everything about everything. Myself (all too obviously sometimes) included.] Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > >From RFC 4202: > =20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority = p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. > =20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. > =20 > Typical values for the Minimum LSP Bandwidth and for the Maximum = LSP > Bandwidth are enumerated in [GMPLS-SIG]. > =20 > On an interface having Standard SDH multiplexing, an LSP at = priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined = by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. > =20 > On an interface having Arbitrary SDH multiplexing, an LSP at = priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the = bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > =20 > >From RFC 4201: > =20 > 3.10. Maximum LSP Bandwidth > =20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP = Bandwidth > at priority p of all of its component links. > =20 > =20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-=20 > > framework-01.txt > >=20 > > Snipped.... > >=20 > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth=20 > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > >=20 > > JD: As the person to whom I believe you are referring, I would=20 > > suggest that you actually read RFC 4202 and 4206. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Lyong@Ciena.com Wed Jul 21 05:30:36 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D48D3A69A3 for ; Wed, 21 Jul 2010 05:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHFuScujajfI for ; Wed, 21 Jul 2010 05:30:29 -0700 (PDT) Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 967E63A67B5 for ; Wed, 21 Jul 2010 05:30:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 08:29:43 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAWbSJAAAog3yA= References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT."<201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> From: "Ong, Lyndon" Importance: normal Priority: normal To: "Daniele Ceccarelli" , "Igor Bryskin" , "John E Drake" , , "Snigdho Bardalai" Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 12:30:36 -0000 I support this as well, of course. Whether this is a = technology-specific extension of the ISCD format or a separate sub-TLV = is a detail, however as Daniele points out many of the same = considerations apply to both OTN and SONET/SDH. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Daniele Ceccarelli Sent: Wednesday, July 21, 2010 12:49 AM To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, In other words it could be possible to define 3 Switching Cap (LO, HO = and SHO) and put what we defined in the encoding draft into the = Switching Capability-specific information of the ISCD. Something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = -----Switching Capability-specific information |0|1|2|3|4|5|6|7| T | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I still don't understand why we need partitioning the network in three = layers while just Sublamba and Full lambda distinction is enough = (distinction supported advertising different signal types for full = lambdas and sublambdas. Personally i still prefer advertising these pieces of information as a = separate sub-TLV (called OTN-ISCD subTLV in the draft but easily = estensible to TDM-ISCD accordingly to = http://tools.ietf.org/html/draft-ong-gmpls-ason-routing-exper-02 format = proposed by the OIF) but this could be a valid solution too. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: marted=C3=AC 20 luglio 2010 23.02 To: John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt=20 John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved = bandwidth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on = draft-ietf-ccamp-gmpls-g709-framework-01.txt Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority = > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? = You do not advertise unreserved bandwidth in the ISCD TLV. In = particular, for TDM, what is advertised is the max and min bandwidth = allowed for a single LSP. It was designed to produce a compact = representation by taking advantage of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but = wasteful. > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done=20 > > > in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli=20 > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang;=20 > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and=20 > > > > a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while=20 > > > > only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same = Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli=20 > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang;=20 > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved = > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, = correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level.=20 > > > > IB>> However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles=20 > > > > IB>> unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang;=20 > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; We also have 16=20 > > > > > > reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16=20 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj=20 > > > > > > LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces=20 > > > > > > AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2=20 > > > > > > can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2=20 > > > > > > with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the=20 > > > > > > path computation is constrained to the OTN_HO_SC topology,=20 > > > > > > B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing=20 > > > > > > the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing=20 > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ;=20 > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ;=20 > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology=20 > > > > > > is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its=20 > > > > > > switching capability field (confusing name as it is) is a=20 > > > > > > good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or=20 > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is=20 > > > > > > it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of=20 > > > > > > clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC,=20 > > > > > > IB>> etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there=20 > > > > > > is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > = =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN = hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding=20 > > > > > > type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; = > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as=20 > > > > > > > many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high = order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA=20 > > > > > > can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 = or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not = directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction=20 > > > > > > but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou=20 > > > > > > > Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on=20 > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer=20 > > > > > > > > independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a=20 > > > > > > > > >new TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user=20 > > > > > > > > IB>> possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based=20 > > > > > > > > on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3=20 > > > > > > > > links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container.=20 > > > > > > > > >> For example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this=20 > > > > > > > > >> point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This = > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jul 21 06:15:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8B03A67F4 for ; Wed, 21 Jul 2010 06:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBx8FCMjyVi8 for ; Wed, 21 Jul 2010 06:15:05 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 1E07D3A67F2 for ; Wed, 21 Jul 2010 06:15:04 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LDFFl3024582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 15:15:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 15:15:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 09:15:13 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Wed, 21 Jul 2010 09:15:04 -0400 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZF1vMQS7bro1SIquJeHidp6adgAcGo3Q Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 14:20:42 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> In-Reply-To: <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_05:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 13:15:09 -0000 Curtis, I agree with all you said. The question is that if a single TE LINK TLV con= tains several ISCDs sub-TLVs and a single "Maximum Reservable Bandwidth" su= b-TLV, how the available bandwidth can be partitioned between ISCDs, so tha= t a path computer making use of the TE LINK TLV could figure out how many L= SPs of each type (associated with each ISCD) could be placed on the link. A= gain, this information is not needed when paths are computed for one servic= e at a time, but useful for con-current path computations when several LSPs= are (re-)placed at the same time (e.g. in case of restoration after a fail= ure of a link carrying multiple LSPs). Cheers, Igor P.S. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows everything about everything. Myself (all too obviously sometimes) included.] I never do that. Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Tuesday, July 20, 2010 7:36 PM To: Igor Bryskin Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardala= i Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01= .txt=20 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: > =20 > John, > =20 > The point is that from ISCD you can not figure out how *many* LSPs > matching the ISCD you can accommodate on the link. Such information is > important in case of con-current routing (e.g. restoration after link > failure).=20 > =20 > Igor=20 Igor, Sergio, RFC 4203 (in 1. Introduction) The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: [OSPF-TE] above is RFC 3630. RFC 3630 (in 2.4.2. Link TLV) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) If you read on you find: The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). and The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. [...] So the totals per link and per priority level are already there in the base spec before the RFC 4203 *extensions* to RFC 3630 were added. That is how you figure out how many ODU0 you can add to your existing ODU2, and so on. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows everything about everything. Myself (all too obviously sometimes) included.] Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-= 01.txt > =20 > >From RFC 4202: > =20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. > =20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. > =20 > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > Bandwidth are enumerated in [GMPLS-SIG]. > =20 > On an interface having Standard SDH multiplexing, an LSP at priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. > =20 > On an interface having Arbitrary SDH multiplexing, an LSP at priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > =20 > >From RFC 4201: > =20 > 3.10. Maximum LSP Bandwidth > =20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP Bandwidth > at priority p of all of its component links. > =20 > =20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > >=20 > > Snipped.... > >=20 > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > >=20 > > JD: As the person to whom I believe you are referring, I would suggest > > that you actually read RFC 4202 and 4206. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jul 21 06:34:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2CE3A6359 for ; Wed, 21 Jul 2010 06:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxJWzwMptH-L for ; Wed, 21 Jul 2010 06:34:53 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id E79A13A67B3 for ; Wed, 21 Jul 2010 06:34:52 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LDZ5mO019360 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 15:35:05 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 15:35:05 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 09:35:02 -0400 From: Igor Bryskin To: "Ong, Lyndon" , Daniele Ceccarelli , "curtis@occnc.com" Date: Wed, 21 Jul 2010 09:34:58 -0400 Thread-Topic: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZGb5GkrZ3IhaSFms97b6HVlGCAASXfMAAAghs5AAAoqKsA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762E7@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 14:20:42EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com><201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EBA@mdmxm03.ciena.com> In-Reply-To: <0AFD1B67B949784DA087CDA9F0DD4AD901C29EBA@mdmxm03.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_05:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 13:34:55 -0000 THluZG9uLA0KDQpUaGlzIGlzIG5vdCBURE0gb3IgT1ROIHNwZWNpZmljIHByb2JsZW0uIEkgY2Fu IGJ1aWxkIGhpZXJhcmNoaWNhbCB0b3BvbG9naWVzIHVzaW5nIEV0aGVybmV0IFNUQUcgc3dpdGNo aW5nLiBJZiBhIGxpbmsgY2FuIHBhcnRpY2lwYXRlIGluIHNldmVyYWwgc3VjaCB0b3BvbG9naWVz IGl0IHdpbGwgY29udGFpbiBzZXZlcmFsIElEU0NzIGluIHRoZSBhZHZlcnRpc2luZywgc28gdGhl IHByb2JsZW0gaXMgdGhlIHNhbWU6IGhvdyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCBpcyBwYXJ0 aXRpb25lZCBiZXR3ZWVuIElEU0NzPw0KDQpJZ29yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBPbmcsIEx5bmRvbiBbbWFpbHRvOkx5b25nQENpZW5hLmNvbV0gDQpTZW50OiBX ZWRuZXNkYXksIEp1bHkgMjEsIDIwMTAgODoyMSBBTQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaTsg Y3VydGlzQG9jY25jLmNvbTsgSWdvciBCcnlza2luDQpDYzogY2NhbXBAaWV0Zi5vcmc7IFNuaWdk aG8gQmFyZGFsYWkNClN1YmplY3Q6IFJFOiBbQ0NBTVBdIFI6IENvbW1lbnRvbmRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDEudHh0DQoNCkkgc3VwcG9ydCB0aGlzLCBJIHRo aW5rIHRoaXMgd291bGQgYmUgdmVyeSBoZWxwZnVsIGZvciBURE0gdGVjaG5vbG9neSBpbiBnZW5l cmFsLg0KDQpMeW5kb24NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBj Y2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIERhbmllbGUgQ2VjY2FyZWxsaQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIxLCAy MDEwIDE6MjkgQU0NClRvOiBjdXJ0aXNAb2NjbmMuY29tOyBJZ29yIEJyeXNraW4NCkNjOiBjY2Ft cEBpZXRmLm9yZzsgU25pZ2RobyBCYXJkYWxhaQ0KU3ViamVjdDogUmU6IFtDQ0FNUF0gUjogQ29t bWVudG9uZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0KSGkg Q3VydGlzLA0KDQpZb3UncmUgcGVyZmVjdGx5IHJpZ2h0LCB0aGUgdG9vbHMgZm9yIE1heGltdW0g UmVzZXJ2YWJsZSBCYW5kd2lkdGggYW5kIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGFyZSBhbHJlYWR5 IHRoZXJlLCBidXQgdGhleSBsYWNrIG9mIGRpc3Rpbmd1aXNoaW5nIGhvdyBzdWNoIGJhbmRpd2R0 aCBpcyBkaXN0cmlidXRlZCBvdmVyIHRoZSB2YXJpb3VzIHNpZ25hbCB0eXBlcyBzdXBwb3J0ZWQg YnkgdGhlIGFkdmVydGlzZWQgbGluay4NCkVzdGVuZGluZyBib3RoIG9mIHRoZW0gcGx1cyB0aGUg SVNDRCBjb3VsZCBiZSBhIGJpZ2dlciBlZmZvcnQgYW5kIGJhbmR3aWR0aCBjb25zdW1pbmcgc29s dXRpb24gdGhhbiBpbnRyb2R1Y2luZyBhbGwgdGhlIHJlcXVpcmVkIGluZm9ybWF0aW9uIGludG8g YSBzaW5nbGUgc3ViLVRMVi4NCg0KQ2hlZXJzDQpEYW5pZWxlDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3VydGlzIFZpbGxhbWl6YXINClNlbnQ6IG1l cmNvbGVkw6wgMjEgbHVnbGlvIDIwMTAgMS4zNg0KVG86IElnb3IgQnJ5c2tpbg0KQ2M6IGNjYW1w QGlldGYub3JnOyBTbmlnZGhvIEJhcmRhbGFpDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBSOiBDb21t ZW50IG9uZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0KDQpJ biBtZXNzYWdlIDwwNTJDNjdCNEVENTU4RDQxQkJERUE3Q0E5RkM2RENEQzUzQzBENzYxNkVAYXRs LXNydi1leGdlbi5hdGwuYWR2YW9wdGljYWwuY29tPg0KSWdvciBCcnlza2luIHdyaXRlczoNCj4g IA0KPiBKb2huLA0KPiAgDQo+IFRoZSBwb2ludCBpcyB0aGF0IGZyb20gSVNDRCB5b3UgY2FuIG5v dCBmaWd1cmUgb3V0IGhvdyAqbWFueSogTFNQcyANCj4gbWF0Y2hpbmcgdGhlIElTQ0QgeW91IGNh biBhY2NvbW1vZGF0ZSBvbiB0aGUgbGluay4gU3VjaCBpbmZvcm1hdGlvbiBpcyANCj4gaW1wb3J0 YW50IGluIGNhc2Ugb2YgY29uLWN1cnJlbnQgcm91dGluZyAoZS5nLiByZXN0b3JhdGlvbiBhZnRl ciBsaW5rIA0KPiBmYWlsdXJlKS4NCj4gIA0KPiBJZ29yDQoNCklnb3IsIFNlcmdpbywNCg0KICBS RkMgNDIwMyAoaW4gMS4gIEludHJvZHVjdGlvbikNCg0KICAgVGhlIFRFIExTQSwgd2hpY2ggaXMg YW4gb3BhcXVlIExTQSB3aXRoIGFyZWEgZmxvb2Rpbmcgc2NvcGUNCiAgIFtPU1BGLVRFXSwgaGFz IG9ubHkgb25lIHRvcC1sZXZlbCBUeXBlL0xlbmd0aC9WYWx1ZSAoVExWKSB0cmlwbGV0DQogICBh bmQgaGFzIG9uZSBvciBtb3JlIG5lc3RlZCBzdWItVExWcyBmb3IgZXh0ZW5zaWJpbGl0eS4gIFRo ZQ0KICAgdG9wLWxldmVsIFRMViBjYW4gdGFrZSBvbmUgb2YgdHdvIHZhbHVlcyAoMSkgUm91dGVy IEFkZHJlc3Mgb3IgKDIpDQogICBMaW5rLiAgSW4gdGhpcyBkb2N1bWVudCwgd2UgZW5oYW5jZSB0 aGUgc3ViLVRMVnMgZm9yIHRoZSBMaW5rIFRMVg0KICAgaW4gc3VwcG9ydCBvZiBHTVBMUy4gIFNw ZWNpZmljYWxseSwgd2UgYWRkIHRoZSBmb2xsb3dpbmcgc3ViLVRMVnMNCiAgIHRvIHRoZSBMaW5r IFRMVjoNCg0KW09TUEYtVEVdIGFib3ZlIGlzIFJGQyAzNjMwLg0KDQogIFJGQyAzNjMwIChpbiAy LjQuMi4gIExpbmsgVExWKQ0KDQogICBUaGUgZm9sbG93aW5nIHN1Yi1UTFZzIG9mIHRoZSBMaW5r IFRMViBhcmUgZGVmaW5lZDoNCg0KICAgICAgMSAtIExpbmsgdHlwZSAoMSBvY3RldCkNCiAgICAg IDIgLSBMaW5rIElEICg0IG9jdGV0cykNCiAgICAgIDMgLSBMb2NhbCBpbnRlcmZhY2UgSVAgYWRk cmVzcyAoNCBvY3RldHMpDQogICAgICA0IC0gUmVtb3RlIGludGVyZmFjZSBJUCBhZGRyZXNzICg0 IG9jdGV0cykNCiAgICAgIDUgLSBUcmFmZmljIGVuZ2luZWVyaW5nIG1ldHJpYyAoNCBvY3RldHMp DQogICAgICA2IC0gTWF4aW11bSBiYW5kd2lkdGggKDQgb2N0ZXRzKQ0KICAgICAgNyAtIE1heGlt dW0gcmVzZXJ2YWJsZSBiYW5kd2lkdGggKDQgb2N0ZXRzKQ0KICAgICAgOCAtIFVucmVzZXJ2ZWQg YmFuZHdpZHRoICgzMiBvY3RldHMpDQogICAgICA5IC0gQWRtaW5pc3RyYXRpdmUgZ3JvdXAgKDQg b2N0ZXRzKQ0KDQpJZiB5b3UgcmVhZCBvbiB5b3UgZmluZDoNCg0KICAgVGhlIE1heGltdW0gUmVz ZXJ2YWJsZSBCYW5kd2lkdGggc3ViLVRMViBzcGVjaWZpZXMgdGhlIG1heGltdW0NCiAgIGJhbmR3 aWR0aCB0aGF0IG1heSBiZSByZXNlcnZlZCBvbiB0aGlzIGxpbmssIGluIHRoaXMgZGlyZWN0aW9u LCBpbg0KICAgSUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQuICBOb3RlIHRoYXQgdGhpcyBtYXkg YmUgZ3JlYXRlciB0aGFuIHRoZQ0KICAgbWF4aW11bSBiYW5kd2lkdGggKGluIHdoaWNoIGNhc2Ug dGhlIGxpbmsgbWF5IGJlIG92ZXJzdWJzY3JpYmVkKS4NCg0KYW5kDQoNCiAgIFRoZSBVbnJlc2Vy dmVkIEJhbmR3aWR0aCBzdWItVExWIHNwZWNpZmllcyB0aGUgYW1vdW50IG9mIGJhbmR3aWR0aA0K ICAgbm90IHlldCByZXNlcnZlZCBhdCBlYWNoIG9mIHRoZSBlaWdodCBwcmlvcml0eSBsZXZlbHMg aW4gSUVFRQ0KICAgZmxvYXRpbmcgcG9pbnQgZm9ybWF0LiAgVGhlIHZhbHVlcyBjb3JyZXNwb25k IHRvIHRoZSBiYW5kd2lkdGggdGhhdA0KICAgY2FuIGJlIHJlc2VydmVkIHdpdGggYSBzZXR1cCBw cmlvcml0eSBvZiAwIHRocm91Z2ggNywgYXJyYW5nZWQgaW4NCiAgIGluY3JlYXNpbmcgb3JkZXIg d2l0aCBwcmlvcml0eSAwIG9jY3VycmluZyBhdCB0aGUgc3RhcnQgb2YgdGhlIHN1Yi0NCiAgIFRM ViwgYW5kIHByaW9yaXR5IDcgYXQgdGhlIGVuZCBvZiB0aGUgc3ViLVRMVi4gIFsuLi5dDQoNClNv IHRoZSB0b3RhbHMgcGVyIGxpbmsgYW5kIHBlciBwcmlvcml0eSBsZXZlbCBhcmUgYWxyZWFkeSB0 aGVyZSBpbiB0aGUgYmFzZSBzcGVjIGJlZm9yZSB0aGUgUkZDIDQyMDMgKmV4dGVuc2lvbnMqIHRv IFJGQyAzNjMwIHdlcmUgYWRkZWQuDQoNClRoYXQgaXMgaG93IHlvdSBmaWd1cmUgb3V0IGhvdyBt YW55IE9EVTAgeW91IGNhbiBhZGQgdG8geW91ciBleGlzdGluZyBPRFUyLCBhbmQgc28gb24uDQoN CltCVFctIExldHMgcGxlYXNlIG5vdCB0YWxrIGFib3V0ICJpZ25vcmFuY2UgYW5kIG1pc3VuZGVy c3RhbmRpbmciLg0KVGhpcyBpcyBub3Qgc2ltcGxlIG9idmlvdXMgc3R1ZmYgYW5kIG1heWJlIG5v bmUgb2YgdXMgaW5kaXZpZHVhbGx5IGtub3dzIGV2ZXJ5dGhpbmcgYWJvdXQgZXZlcnl0aGluZy4g IE15c2VsZiAoYWxsIHRvbyBvYnZpb3VzbHkNCnNvbWV0aW1lcykgaW5jbHVkZWQuXQ0KDQpDdXJ0 aXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaG4gRSBEcmFr ZSBbbWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldF0NCj4gU2VudDogVHVlc2RheSwgSnVseSAyMCwg MjAxMCAxOjEzIFBNDQo+IFRvOiBCRUxPVFRJLCBTRVJHSU8gKFNFUkdJTyk7IElnb3IgQnJ5c2tp bg0KPiBDYzogY2NhbXBAaWV0Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWkNCj4gU3ViamVjdDogUkU6 IFtDQ0FNUF0gUjogQ29tbWVudCBvbiANCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZy YW1ld29yay0wMS50eHQNCj4gIA0KPiA+RnJvbSBSRkMgNDIwMjoNCj4gIA0KPiAgICBGb3IgYSBz aW1wbGUgKHVuYnVuZGxlZCkgbGluayB0aGUgTWF4aW11bSBMU1AgQmFuZHdpZHRoIGF0IHByaW9y aXR5IHANCj4gICAgaXMgZGVmaW5lZCBhcyB0aGUgbWF4aW11bSBiYW5kd2lkdGggYW4gTFNQIGF0 IHByaW9yaXR5IHAgY291bGQNCj4gICAgcmVzZXJ2ZS4gIE1heGltdW0gTFNQIEJhbmR3aWR0aCBm b3IgYSBidW5kbGVkIGxpbmsgaXMgZGVmaW5lZCBpbg0KPiAgICBbTElOSy1CVU5ETEVdLg0KPiAg DQo+ICAgIFRoZSBNaW5pbXVtIExTUCBCYW5kd2lkdGggc3BlY2lmaWVzIHRoZSBtaW5pbXVtIGJh bmR3aWR0aCBhbiBMU1ANCj4gICAgY291bGQgcmVzZXJ2ZS4NCj4gIA0KPiAgICBUeXBpY2FsIHZh bHVlcyBmb3IgdGhlIE1pbmltdW0gTFNQIEJhbmR3aWR0aCBhbmQgZm9yIHRoZSBNYXhpbXVtIExT UA0KPiAgICBCYW5kd2lkdGggYXJlIGVudW1lcmF0ZWQgaW4gW0dNUExTLVNJR10uDQo+ICANCj4g ICAgT24gYW4gaW50ZXJmYWNlIGhhdmluZyBTdGFuZGFyZCBTREggbXVsdGlwbGV4aW5nLCBhbiBM U1AgYXQgcHJpb3JpdHkNCj4gICAgcCBjb3VsZCByZXNlcnZlIGFueSBiYW5kd2lkdGggYWxsb3dl ZCBieSB0aGUgYnJhbmNoIG9mIHRoZSBTREgNCj4gICAgaGllcmFyY2h5LCB3aXRoIHRoZSBsZWFm IGFuZCB0aGUgcm9vdCBvZiB0aGUgYnJhbmNoIGJlaW5nIGRlZmluZWQgYnkNCj4gICAgdGhlIE1p bmltdW0gTFNQIEJhbmR3aWR0aCBhbmQgdGhlIE1heGltdW0gTFNQIEJhbmR3aWR0aCBhdCBwcmlv cml0eQ0KPiAgICBwLg0KPiAgDQo+ICAgIE9uIGFuIGludGVyZmFjZSBoYXZpbmcgQXJiaXRyYXJ5 IFNESCBtdWx0aXBsZXhpbmcsIGFuIExTUCBhdCBwcmlvcml0eQ0KPiAgICBwIGNvdWxkIHJlc2Vy dmUgYW55IGJhbmR3aWR0aCBiZXR3ZWVuIHRoZSBNaW5pbXVtIExTUCBCYW5kd2lkdGggYW5kDQo+ ICAgIHRoZSBNYXhpbXVtIExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgcCwgcHJvdmlkZWQgdGhh dCB0aGUgYmFuZHdpZHRoDQo+ICAgIHJlc2VydmVkIGJ5IHRoZSBMU1AgaXMgYSBtdWx0aXBsZSBv ZiB0aGUgTWluaW11bSBMU1AgQmFuZHdpZHRoLg0KPiAgDQo+ID5Gcm9tIFJGQyA0MjAxOg0KPiAg DQo+IDMuMTAuICBNYXhpbXVtIExTUCBCYW5kd2lkdGgNCj4gIA0KPiAgICBUaGUgTWF4aW11bSBM U1AgQmFuZHdpZHRoIHRha2VzIHRoZSBwbGFjZSBvZiB0aGUgTWF4aW11bSBCYW5kd2lkdGguDQo+ ICAgIEZvciBhbiB1bmJ1bmRsZWQgbGluaywgdGhlIE1heGltdW0gQmFuZHdpZHRoIGlzIGRlZmlu ZWQgaW4NCj4gICAgW0dNUExTLVJPVVRJTkddLiAgVGhlIE1heGltdW0gTFNQIEJhbmR3aWR0aCBv ZiBhIGJ1bmRsZWQgbGluayBhdA0KPiAgICBwcmlvcml0eSBwIGlzIGRlZmluZWQgdG8gYmUgdGhl IG1heGltdW0gb2YgdGhlIE1heGltdW0gTFNQIEJhbmR3aWR0aA0KPiAgICBhdCBwcmlvcml0eSBw IG9mIGFsbCBvZiBpdHMgY29tcG9uZW50IGxpbmtzLg0KPiAgDQo+ICANCj4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEpvaG4gRSBEcmFrZQ0KPiA+IFNlbnQ6IFR1ZXNk YXksIEp1bHkgMjAsIDIwMTAgMTA6MDQgQU0NCj4gPiBUbzogJ0JFTE9UVEksIFNFUkdJTyAoU0VS R0lPKSc7IElnb3IgQnJ5c2tpbg0KPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgU25pZ2RobyBCYXJk YWxhaQ0KPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIFI6IENvbW1lbnQgb24gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1nNzA5LSANCj4gPiBmcmFtZXdvcmstMDEudHh0DQo+ID4gDQo+ID4gU25pcHBl ZC4uLi4NCj4gPiANCj4gPiA+DQo+ID4gPiBJIHJlYWxpemVkIGZyb20gc29tZW9uZSBpbiB0aGlz IHRocmVhZCAobm90IGZyb20geW91KSB0aGlzIHdhcyBkdWUNCj4gPiBqdXN0DQo+ID4gPiB0byBp Z25vcmFuY2UgYW5kIG1pc3VuZGVyc3RhbmRpbmcgb2YgUkZDIDQyMDIvNDIwMyBiYW5kd2lkdGgg DQo+ID4gPiBhZHZlcnRpc2VtZW50IGZvciBTREggLiBBbnl3YXkgaXQgaXMgYSBmYWN0IHRoYXQg dGhlIGFsdGVybmF0aXZlDQo+ID4gZm9ybWF0DQo+ID4gPiBpcyB1c2VkIGluIG1hbnkgaW1wbGVt ZW50YXRpb25zICJpbiBmaWVsZCIgZm9yIFNESCBjb250cm9sIHBsYW5lLg0KPiA+ID4NCj4gPiAN Cj4gPiBKRDogIEFzIHRoZSBwZXJzb24gdG8gd2hvbSBJIGJlbGlldmUgeW91IGFyZSByZWZlcnJp bmcsIEkgd291bGQgDQo+ID4gc3VnZ2VzdCB0aGF0IHlvdSBhY3R1YWxseSByZWFkIFJGQyA0MjAy IGFuZCA0MjA2Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxp bmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXANCg0K From Lyong@Ciena.com Wed Jul 21 06:44:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802153A67AF for ; Wed, 21 Jul 2010 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeSchClCvKkk for ; Wed, 21 Jul 2010 06:44:09 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id 05FD93A6359 for ; Wed, 21 Jul 2010 06:44:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 09:43:53 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901C29F16@mdmxm03.ciena.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762E7@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZGb5GkrZ3IhaSFms97b6HVlGCAASXfMAAAghs5AAAoqKsAAAapNg References: Your message of "Tue, 20 Jul 2010 14:20:42EDT."<052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com><201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EBA@mdmxm03.ciena.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762E7@atl-srv-exgen.atl.advaoptical.com> From: "Ong, Lyndon" Importance: normal Priority: normal To: "Igor Bryskin" , "Daniele Ceccarelli" , Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] R: Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 13:44:14 -0000 Hi Igor, Well, I did not say that it was specific to TDM, only that it does occur = in TDM. You point out that hierarchical topologies can be built in = packet as well, which sounds reasonable. I do think that some aspects, like supporting multiple signal types = (i.e., minimum reserveable bandwidth quanta) may be specific to TDM. Cheers, Lyndon -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Wednesday, July 21, 2010 6:35 AM To: Ong, Lyndon; Daniele Ceccarelli; curtis@occnc.com Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] R: = Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt Lyndon, This is not TDM or OTN specific problem. I can build hierarchical = topologies using Ethernet STAG switching. If a link can participate in = several such topologies it will contain several IDSCs in the = advertising, so the problem is the same: how the available bandwidth is = partitioned between IDSCs? Igor -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Wednesday, July 21, 2010 8:21 AM To: Daniele Ceccarelli; curtis@occnc.com; Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] R: = Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt I support this, I think this would be very helpful for TDM technology in = general. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Daniele Ceccarelli Sent: Wednesday, July 21, 2010 1:29 AM To: curtis@occnc.com; Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] R: = Commentondraft-ietf-ccamp-gmpls-g709-framework-01.txt Hi Curtis, You're perfectly right, the tools for Maximum Reservable Bandwidth and = Unreserved Bandwidth are already there, but they lack of distinguishing = how such bandiwdth is distributed over the various signal types = supported by the advertised link. Estending both of them plus the ISCD could be a bigger effort and = bandwidth consuming solution than introducing all the required = information into a single sub-TLV. Cheers Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Curtis Villamizar Sent: mercoled=C3=AC 21 luglio 2010 1.36 To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] R: Comment = ondraft-ietf-ccamp-gmpls-g709-framework-01.txt In message = <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical= .com> Igor Bryskin writes: > =20 > John, > =20 > The point is that from ISCD you can not figure out how *many* LSPs=20 > matching the ISCD you can accommodate on the link. Such information is = > important in case of con-current routing (e.g. restoration after link=20 > failure). > =20 > Igor Igor, Sergio, RFC 4203 (in 1. Introduction) The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: [OSPF-TE] above is RFC 3630. RFC 3630 (in 2.4.2. Link TLV) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) If you read on you find: The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). and The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. [...] So the totals per link and per priority level are already there in the = base spec before the RFC 4203 *extensions* to RFC 3630 were added. That is how you figure out how many ODU0 you can add to your existing = ODU2, and so on. [BTW- Lets please not talk about "ignorance and misunderstanding". This is not simple obvious stuff and maybe none of us individually knows = everything about everything. Myself (all too obviously sometimes) included.] Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 1:13 PM > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] R: Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > >From RFC 4202: > =20 > For a simple (unbundled) link the Maximum LSP Bandwidth at priority = p > is defined as the maximum bandwidth an LSP at priority p could > reserve. Maximum LSP Bandwidth for a bundled link is defined in > [LINK-BUNDLE]. > =20 > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > could reserve. > =20 > Typical values for the Minimum LSP Bandwidth and for the Maximum = LSP > Bandwidth are enumerated in [GMPLS-SIG]. > =20 > On an interface having Standard SDH multiplexing, an LSP at = priority > p could reserve any bandwidth allowed by the branch of the SDH > hierarchy, with the leaf and the root of the branch being defined = by > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > p. > =20 > On an interface having Arbitrary SDH multiplexing, an LSP at = priority > p could reserve any bandwidth between the Minimum LSP Bandwidth and > the Maximum LSP Bandwidth at priority p, provided that the = bandwidth > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > =20 > >From RFC 4201: > =20 > 3.10. Maximum LSP Bandwidth > =20 > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > For an unbundled link, the Maximum Bandwidth is defined in > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > priority p is defined to be the maximum of the Maximum LSP = Bandwidth > at priority p of all of its component links. > =20 > =20 > > -----Original Message----- > > From: John E Drake > > Sent: Tuesday, July 20, 2010 10:04 AM > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-=20 > > framework-01.txt > >=20 > > Snipped.... > >=20 > > > > > > I realized from someone in this thread (not from you) this was due > > just > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth=20 > > > advertisement for SDH . Anyway it is a fact that the alternative > > format > > > is used in many implementations "in field" for SDH control plane. > > > > >=20 > > JD: As the person to whom I believe you are referring, I would=20 > > suggest that you actually read RFC 4202 and 4206. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jul 21 06:51:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1823A6826 for ; Wed, 21 Jul 2010 06:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBQ8oubrognn for ; Wed, 21 Jul 2010 06:51:10 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 29E143A6889 for ; Wed, 21 Jul 2010 06:51:05 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LDpFwS009606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 15:51:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 15:51:14 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 09:51:12 -0400 From: Igor Bryskin To: "Ong, Lyndon" , Daniele Ceccarelli , John E Drake , "curtis@occnc.com" , Snigdho Bardalai Date: Wed, 21 Jul 2010 09:51:05 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAWbSJAAAog3yAAAm+/cA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT."<201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> In-Reply-To: <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_05:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 13:51:21 -0000 V2UgbmVlZCB0byBkaXNjdXNzIHRoaXMgZmFjZSB0byBmYWNlLiBUaGUgYmlnZ2VzdCBkaXNhZ3Jl ZW1lbnRzIHdpdGggRGFuaWVsZSBhcmU6DQoxKSBJIGRvbid0IGJlbGlldmUgdGhhdCBmbGF0IHJv dXRpbmcgbW9kZWwgb2YgYSBtdWx0aS1sYXllciBPVE4gbmV0d29yayBpcyBjb3JyZWN0Lg0KMikg SSB0aGluayBlYWNoIE9UTiByb2xlIGRlZmluZXMgYSBzZXBhcmF0ZSB0b3BvbG9neSBvZiBPVE4g bGlua3MsIGFuZCB0aGVyZSBpcyBhIG5lZWQgdG8gYmUgYWJsZSB0byBjb25zdHJhaW4gdGhlIHJv dXRpbmcgb2YgYSBnaXZlbiBPVE4gY29ubmVjdGlvbiB0byBvbmUgb3IgbW9yZSAoYnV0IG5vdCBu ZWNlc3NhcmlseSBhbGwpIHN1Y2ggdG9wb2xvZ2llczsNCjMpIFRoZXJlIGlzIGFuIGlzc3VlIGlu IHRoZSBjdXJyZW50IGRlZmluaXRpb25zIG9mIEdNUExTIE9TUEYgZXh0ZW5zaW9ucyAoUkZDIDQy MDMpLCB3aGljaCBkb2VzIGFsbG93IHRvIHNwZWNpZnkgbXVsdGlwbGUgSVNDRHMgYnV0IGRvZXMg bm90IGd1aWRlIGFzIHRvIGhvdyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCBvbiB0aGUgbGluayBp cyBwYXJ0aXRpb25lZCBiZXR3ZWVuIElTQ0RzLiBUaGlzIGlzIGEgZ2VuZXJpYyBpc3N1ZSBhbmQg c2hvdWxkIGJlIHJlc29sdmVkIGluIGEgZ2VuZXJpYyB3YXk7DQo0KSBPdGhlciB0aGFuICgzKSB3 ZSBkb24ndCBuZWVkIGFueSBPVE4gb3IgVERNIHNwZWNpZmljIENQIG1hY2hpbmVyeSBmb3IgVEUg YW5kIHJvdXRpbmcgaW4gT1ROIG5ldHdvcmtzLiBVbmxlc3Mgd2Ugc2VlIHN0cm9uZyByZWFzb25z IHRvIHRoZSBjb250cmFyeSB3ZSBzaG91bGQgbm90IGludmVudCBzdWNoIG1hY2hpbmVyeS4NCg0K Q2hlZXJzLA0KSWdvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT25nLCBM eW5kb24gW21haWx0bzpMeW9uZ0BDaWVuYS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjEs IDIwMTAgODozMCBBTQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgSWdvciBCcnlza2luOyBKb2hu IEUgRHJha2U7IGN1cnRpc0BvY2NuYy5jb207IFNuaWdkaG8gQmFyZGFsYWkNCkNjOiBjY2FtcEBp ZXRmLm9yZzsgU25pZ2RobyBCYXJkYWxhaQ0KU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBv biBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dA0KDQpJIHN1cHBv cnQgdGhpcyBhcyB3ZWxsLCBvZiBjb3Vyc2UuICBXaGV0aGVyIHRoaXMgaXMgYSB0ZWNobm9sb2d5 LXNwZWNpZmljIGV4dGVuc2lvbiBvZiB0aGUgSVNDRCBmb3JtYXQgb3IgYSBzZXBhcmF0ZSBzdWIt VExWIGlzIGEgZGV0YWlsLCBob3dldmVyIGFzIERhbmllbGUgcG9pbnRzIG91dCBtYW55IG9mIHRo ZSBzYW1lIGNvbnNpZGVyYXRpb25zIGFwcGx5IHRvIGJvdGggT1ROIGFuZCBTT05FVC9TREguDQoN Ckx5bmRvbg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNjYW1wLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRGFuaWVsZSBDZWNjYXJlbGxpDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjEsIDIwMTAgMTI6 NDkgQU0NClRvOiBJZ29yIEJyeXNraW47IEpvaG4gRSBEcmFrZTsgY3VydGlzQG9jY25jLmNvbTsg U25pZ2RobyBCYXJkYWxhaQ0KQ2M6IGNjYW1wQGlldGYub3JnOyBTbmlnZGhvIEJhcmRhbGFpDQpT dWJqZWN0OiBSZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcw OS1mcmFtZXdvcmstMDEudHh0DQoNCklnb3IsDQoNCkluIG90aGVyIHdvcmRzIGl0IGNvdWxkIGJl IHBvc3NpYmxlIHRvIGRlZmluZSAzIFN3aXRjaGluZyBDYXAgKExPLCBITyBhbmQgU0hPKSBhbmQg cHV0IHdoYXQgd2UgZGVmaW5lZCBpbiB0aGUgZW5jb2RpbmcgZHJhZnQgaW50byB0aGUgU3dpdGNo aW5nIENhcGFiaWxpdHktc3BlY2lmaWMgaW5mb3JtYXRpb24gb2YgdGhlIElTQ0QuDQoNClNvbWV0 aGluZyBsaWtlIHRoaXM6DQoNCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg fCBTd2l0Y2hpbmcgQ2FwIHwgICBFbmNvZGluZyAgICB8ICAgICAgICAgICBSZXNlcnZlZCAgICAg ICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5k d2lkdGggYXQgcHJpb3JpdHkgMCAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAg ICAgICAgICAgICAgICBNYXggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAxICAgICAgICAgICAg ICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRo IGF0IHByaW9yaXR5IDIgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAg ICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMyAgICAgICAgICAgICAgfA0K ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICBNYXggTFNQIEJhbmR3aWR0aCBhdCBw cmlvcml0eSA0ICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAg ICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDUgICAgICAgICAgICAgIHwNCiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3Jp dHkgNiAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICBN YXggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA3ICAgICAgICAgICAgICB8DQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgLS0tLS1Td2l0Y2hpbmcgQ2FwYWJpbGl0eS1zcGVjaWZpYyBpbmZvcm1h dGlvbg0KICAgfDB8MXwyfDN8NHw1fDZ8N3wgIFQgIHwgICAgICAgICB8ICAgICAgICAgIFJlc2Vy dmVkICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAg ICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgIHwgIFNpZ25hbCBUeXBlICB8RnwgICAgICAgICAgICAgICBCYW5kd2lkdGggQCBQMSAgICAg ICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAgICAg ICAgICAgIEJhbmR3aWR0aCBAIFAyICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDMgICAgICAgICAg ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIFNpZ25hbCBUeXBlICB8RnwgICAgICAgICAgICAg ICBCYW5kd2lkdGggQCBQNCAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgU2ln bmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFA1ICAgICAgICAgICAgICAg IHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFu ZHdpZHRoIEAgUDYgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIFNpZ25hbCBU eXBlICB8RnwgICAgICAgICAgICAgICBCYW5kd2lkdGggQCBQNyAgICAgICAgICAgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4NCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBA IFAwICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBTaWduYWwgVHlwZSAgfEZ8 ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDEgICAgICAgICAgICAgICAgfA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgIHwgIFNpZ25hbCBUeXBlICB8RnwgICAgICAgICAgICAgICBCYW5kd2lkdGggQCBQMiAg ICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAg ICAgICAgICAgIEJhbmR3aWR0aCBAIFAzICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDQgICAgICAg ICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIFNpZ25hbCBUeXBlICB8RnwgICAgICAgICAg ICAgICBCYW5kd2lkdGggQCBQNSAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg U2lnbmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFA2ICAgICAgICAgICAg ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAg QmFuZHdpZHRoIEAgUDcgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KSSBzdGlsbCBk b24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIHBhcnRpdGlvbmluZyB0aGUgbmV0d29yayBpbiB0 aHJlZSBsYXllcnMgd2hpbGUganVzdCBTdWJsYW1iYSBhbmQgRnVsbCBsYW1iZGEgZGlzdGluY3Rp b24gaXMgZW5vdWdoIChkaXN0aW5jdGlvbiBzdXBwb3J0ZWQgYWR2ZXJ0aXNpbmcgZGlmZmVyZW50 IHNpZ25hbCB0eXBlcyBmb3IgZnVsbCBsYW1iZGFzIGFuZCBzdWJsYW1iZGFzLg0KDQpQZXJzb25h bGx5IGkgc3RpbGwgcHJlZmVyIGFkdmVydGlzaW5nIHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1hdGlv biBhcyBhIHNlcGFyYXRlIHN1Yi1UTFYgKGNhbGxlZCBPVE4tSVNDRCBzdWJUTFYgaW4gdGhlIGRy YWZ0IGJ1dCBlYXNpbHkgZXN0ZW5zaWJsZSB0byBURE0tSVNDRCBhY2NvcmRpbmdseSB0byBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vbmctZ21wbHMtYXNvbi1yb3V0aW5nLWV4cGVy LTAyIGZvcm1hdCBwcm9wb3NlZCBieSB0aGUgT0lGKSBidXQgdGhpcyBjb3VsZCBiZSBhIHZhbGlk IHNvbHV0aW9uIHRvby4NCg0KQlINCkRhbmllbGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IElnb3IgQnJ5c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0N ClNlbnQ6IG1hcnRlZMOsIDIwIGx1Z2xpbyAyMDEwIDIzLjAyDQpUbzogSm9obiBFIERyYWtlOyBj dXJ0aXNAb2NjbmMuY29tOyBTbmlnZGhvIEJhcmRhbGFpDQpDYzogRGFuaWVsZSBDZWNjYXJlbGxp OyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6 IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1l d29yay0wMS50eHQNCg0KSm9obiwNCg0KRG8geW91IHVuZGVyc3RhbmQgdGhlIHF1b3RlIGZyb20g UkZDNDIwMzoNCjAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg ICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8IFN3aXRjaGluZyBD YXAgfCAgIEVuY29kaW5nICAgIHwgICAgICAgICAgIFJlc2VydmVkICAgICAgICAgICAgfA0KICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICBNYXggTFNQIEJhbmR3aWR0aCBhdCBwcmlv cml0eSAwICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAg IE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDEgICAgICAgICAgICAgIHwNCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkg MiAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICBNYXgg TFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSAzICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDQgICAg ICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBC YW5kd2lkdGggYXQgcHJpb3JpdHkgNSAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg ICAgICAgICAgICAgICAgICBNYXggTFNQIEJhbmR3aWR0aCBhdCBwcmlvcml0eSA2ICAgICAgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdp ZHRoIGF0IHByaW9yaXR5IDcgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAg ICBTd2l0Y2hpbmcgQ2FwYWJpbGl0eS1zcGVjaWZpYyBpbmZvcm1hdGlvbiAgICAgICAgICAgICAg fA0KICAgfCAgICAgICAgICAgICAgICAgICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCllvdSBjYW4gdXNlIHRoZSBsYXN0IGZpZWxk IGZvciBPVE4gc3dpdGNoY2FwIHRvIGFkdmVydGlzZSB1bnJlc29sdmVkIGJhbmR3aWR0aCBhdmFp bGFibGUgZm9yIHRoZSBJU0NEIG9uIHBlciBwcmlvcml0eSBsZXZlbC4NCg0KSWdvcg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBFIERyYWtlIFttYWlsdG86amRyYWtl QGp1bmlwZXIubmV0XQ0KU2VudDogVHVlc2RheSwgSnVseSAyMCwgMjAxMCA0OjM1IFBNDQpUbzog SWdvciBCcnlza2luOyBjdXJ0aXNAb2NjbmMuY29tOyBTbmlnZGhvIEJhcmRhbGFpDQpDYzogRGFu aWVsZSBDZWNjYXJlbGxpOyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgY2NhbXBAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0KU25pcHBlZC4uLg0KDQo+IElEU0Mgc3ViLVRM ViBhbmQgeW91IGNhbiBzcGVjaWZ5IHRoZSB1bnJlc2VydmVkIGJhbmR3aWR0aCBwZXIgcHJpb3Jp dHkNCj4gbGV2ZWwgZm9yIGV2ZXJ5IElTQ0QuDQoNCkpEOiAgSWdvciwgd2hhdCBwYXJ0IG9mIG15 IHF1b3RlIGZyb20gUkZDIDQyMDIgZGlkIHlvdSBub3QgdW5kZXJzdGFuZD8gIFlvdSBkbyBub3Qg YWR2ZXJ0aXNlIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGluIHRoZSBJU0NEIFRMVi4gIEluIHBhcnRp Y3VsYXIsIGZvciBURE0sIHdoYXQgaXMgYWR2ZXJ0aXNlZCBpcyB0aGUgbWF4IGFuZCBtaW4gYmFu ZHdpZHRoIGFsbG93ZWQgZm9yIGEgc2luZ2xlIExTUC4gIEl0IHdhcyBkZXNpZ25lZCB0byBwcm9k dWNlIGEgY29tcGFjdCByZXByZXNlbnRhdGlvbiBieSB0YWtpbmcgYWR2YW50YWdlIG9mIHRoZSBT REgvU09ORVQgaGllcmFyY2h5Lg0KDQpBZHZlcnRpc2luZyBhIHNlcGFyYXRlIElTQ0QgZm9yIGVh Y2ggc3VwcG9ydGVkIHJhdGUgaXMgYWxsb3dlZCBidXQgd2FzdGVmdWwuDQoNCj4NCj4gSWdvcg0K Pg0KPg0KPiA+IE9uIFR1ZSwgSnVsIDIwLCAyMDEwIGF0IDk6MTYgQU0sIElnb3IgQnJ5c2tpbg0K PiA8SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPndybz0NCj4gPiB0ZToNCj4gPg0KPiA+ID4gSm9o biwNCj4gPiA+DQo+ID4gPiBJIHRvdGFsbHkgYWdyZWUgd2l0aCB5b3UuIEl0IGlzIGFic29sdXRl bHkgbm9uIE9UTiBzcGVjaWZpYy4NCj4gSG93ZXZlciBpZiBhDQo+ID4gPiBURSBsaW5rIGFkdmVy dGlzZXMgbW9yZSB0aGFuIG9uZSBJU0NEICh3aXRoIGVhY2ggSVNDRCBjb250YWluaW5nDQo+IG9u bHkgbWF4DQo+ID4gPiBsc3AgYmFuZHdpZHRoIHBlciBwcmlvcml0eSksIGl0IGlzIG5lY2Vzc2Fy eSB0byBpbmRpY2F0ZSBob3cgdGhlDQo+IHRvdGFsIGxpPQ0KPiA+IG5rDQo+ID4gPiB1bnJlc2Vy dmVkIGJhbmR3aWR0aCBpcyBwYXJ0aXRpb25lZCBiZXR3ZWVuIHNldmVyYWwgSVNDRHMuIFdoYXQg SQ0KPiBhbQ0KPiA+ID4gc3VnZ2VzdGluZyBpcyBpbnN0ZWFkIG9mIGFkdmVydGlzaW5nIHRoZSB1 bnJlc2VydmVkIGJhbmR3aWR0aA0KPiBtdWx0aXBsZSB0aT0NCj4gPiBtZXMNCj4gPiA+IChvbmUg cGVyIElTQ0QpLCBpbmRpY2F0ZSBob3cgdGhlIGJhbmR3aWR0aCBpcyBzcGxpdCBiZXR3ZWVuIHRo ZQ0KPiBJU0NEczogZS49DQo+ID4gZw0KPiA+ID4gSVNDRDEgNzUlLCBJU0NEMiAyNSUuDQo+ID4g Pg0KPiA+ID4gSWdvci4NCj4gPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gRnJvbTogSm9obiBFIERyYWtlIFttYWlsdG86amRyYWtlQGp1bmlwZXIubmV0XQ0KPiA+ ID4gIFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjAsIDIwMTAgMTE6NTQgQU0NCj4gPiA+IFRvOiBJZ29y IEJyeXNraW47IERhbmllbGUgQ2VjY2FyZWxsaTsgU25pZ2RobyBCYXJkYWxhaTsgRmF0YWkNCj4g Wmhhbmc7DQo+ID4gPiBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmcN Cj4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24NCj4gPiA+IGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDEudHh0DQo+ID4gPg0KPiA+ID4gSWdvciwNCj4g PiA+DQo+ID4gPiBVbnJlc2VydmVkIGJhbmR3aWR0aCBpcyBub3QgYWR2ZXJ0aXNlZCBpbiB0aGUg VERNIElTQyBUTFYsIHNvIHRoZQ0KPiBpc3N1ZSBvPQ0KPiA+IGYNCj4gPiA+IHBhcnRpdGlvbmlu ZyB1bnJlc2VydmVkIGJhbmR3aWR0aCBhY3Jvc3MgbXVsdGlwbGUgYWR2ZXJ0aXNlZCBURE0NCj4g SVNDIFRMVnM9DQo+ID4gIGlzDQo+ID4gPiBhY3R1YWxseSBhIG5vbi1pc3N1ZS4NCj4gPiA+DQo+ ID4gPiBVbnJlc2VydmVkIGJhbmR3aWR0aCBieSBwcmlvcml0eSBoYXMgYWx3YXlzIGJlZW4gYWR2 ZXJ0aXNlZCB1c2luZw0KPiB0aGUgTVBMPQ0KPiA+IFMNCj4gPiA+IHN1Yi1UTFYuICBNeSBwb2lu dCBoYXMgYmVlbiB0aGF0IHdlIGhhdmUgbmV2ZXIgaGFkIGEgcmVxdWlyZW1lbnQNCj4gKGluY2x1 ZGk9DQo+ID4gbmcNCj4gPiA+IFNESC9TT05FVCkgaW4gdGhlIHBhc3QgdG8gYWR2ZXJ0aXNlIHVu cmVzZXJ2ZWQgYmFuZHdpZHRoIGJ5IHNpZ25hbA0KPiB0eXBlLCA9DQo+ID4gc28NCj4gPiA+IHdo YXQgaXMgc3BlY2lhbCBhYm91dCBPVE4/DQo+ID4gPg0KPiA+ID4gQSBmdXJ0aGVyIHBvaW50IHdv dWxkIGJlIHRoYXQgaWYgd2UgZG8gZGVjaWRlIHRoYXQgaXQgaXMgbmVjZXNzYXJ5DQo+IHRvDQo+ ID4gPiBhZHZlcnRpc2UgdW5yZXNlcnZlZCBiYW5kd2lkdGggYnkgc2lnbmFsIHR5cGUsIGl0IHNo b3VsZCBiZSBkb25lDQo+ID4gPiBpbg0KPiBhDQo+ID4gPiBnZW5lcmFsIHdheSBhbmQgbm90IGlu IGFuIE9UTiBzcGVjaWZpYyBtYW5uZXIuICAoQW5kIGluIGZhY3QsIHRoZQ0KPiBhcmd1bWVuPQ0K PiA+IHRzDQo+ID4gPiB0aGF0IHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGJ5IHNpZ25hbCB0eXBlIG5l ZWRzIHRvIGJlIGFkdmVydGlzZWQsDQo+IHN1Y2ggYXMgPQ0KPiA+IHRoZQ0KPiA+ID4gbGF0ZXN0 IGUtbWFpbCBmcm9tIEN1cnRpcywgYXJlIG5vdCBPVE4gc3BlY2lmaWMuKQ0KPiA+ID4NCj4gPiA+ IFRoYW5rcywNCj4gPiA+DQo+ID4gPiBKb2huDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ID4gPiA+IE9mIElnb3Ig QnJ5c2tpbg0KPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDIwLCAyMDEwIDg6MjEgQU0NCj4g PiA+ID4gVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgU25pZ2RobyBCYXJkYWxhaTsgRmF0YWkgWmhh bmc7DQo+IGN1cnRpc0BvY2NuYy5jb20NCj4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnDQo+ID4g PiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nNzA5LQ0KPiBmcmFtZXdvcmstDQo+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPg0KPiA+ID4gPiBJ dCBpcyBhIHZhbGlkIHBvaW50LCBidXQgdGhlIHN1Z2dlc3RlZCBzb2x1dGlvbiBpcyB3YXkgdG9v DQo+IGV4cGVuc2l2ZS4NCj4gPiA+ID4gQWxsIHlvdSBuZWVkIGlzIGEgd2F5IHRvIHNheSBob3cg dGhlIGFkdmVydGlzZWQgdW5yZXNlcnZlZA0KPiBiYW5kd2lkdGggaXMNCj4gPiA+ID4gcGFydGl0 aW9uZWQgYmV0d2VlbiBJU0NEcyBpbiBjYXNlIHRoZSBURSBsaW5rIGFkdmVydGlzZW1lbnQNCj4g Y29udGFpbnMNCj4gPiA+ID4gc2V2ZXJhbCBvZiB0aGVtLiBPbmUgY2hlYXAgd2F5IG9mIGRvaW5n IHNvIGlzIHRvIGFsbG9jYXRlIDMtNA0KPiBiaXRzIG91dA0KPiA+ID4gPiBvZiB0aGUgSVNDRCBz dWItVExWIHJlc2VydmVkIGJpdHMgdG8gaW5kaWNhdGUgdGhlIGZyYWN0aW9uIG9mDQo+IHRvdGFs DQo+ID4gPiA+IHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGFzc29jaWF0ZWQgd2l0aCB0aGUgSVNDRC4g QW5vdGhlciB3YXkgaXMgdG8NCj4gdXNlDQo+ID4gPiA+IHN3aWN0aGNhcCBzcGVjaWZpYyBleHRl bnNpb24uDQo+ID4gPiA+IEJUVzogdGhpcyBpcyBub3QgYW4gT1ROIHNwZWNpZmljIGlzc3VlLCBy YXRoZXIgbW9yZSBnZW5lcmFsOiBhbnkNCj4gdGltZQ0KPiA+ID4gPiB3aGVuIGEgVEUgbGluayBh ZHZlcnRpc2VzIG1vcmUgdGhhbiBvbmUgSVNDRCAod2hpY2ggaXMgcGVyZmVjdGx5DQo+IE9rDQo+ ID4gPiA+IGFjY29yZGluZyB0byA0MjAzKSB5b3UnbGwgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtLg0K PiA+ID4gPg0KPiA+ID4gPiBJZ29yDQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IERhbmllbGUgQ2VjY2FyZWxsaQ0KPiA+ID4gPiBbbWFp bHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+ID4gPiA+IFNlbnQ6IFR1ZXNk YXksIEp1bHkgMjAsIDIwMTAgMTA6NTcgQU0NCj4gPiA+ID4gVG86IElnb3IgQnJ5c2tpbjsgU25p Z2RobyBCYXJkYWxhaTsgRmF0YWkgWmhhbmc7DQo+ID4gPiA+IGN1cnRpc0BvY2NuYy5jb20NCj4g PiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENv bW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiBmcmFtZXdvcmstDQo+ID4g PiA+IDAxLnR4dA0KPiA+ID4gPg0KPiA+ID4gPiBJZ29yLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGUg bmVlZCBmb3IgdW5yZXNlcnZlZCByZXNvdXJjZXMgYWR2ZXJ0aXNlZCBwZXIgc2lnbmFsIHR5cGUg aXMNCj4gdGhlDQo+ID4gPiA+IGNvbmN1cnJlbnQgcGF0aCBjb21wdXRhdGlvbi4gSSdsbCBhbnN3 ZXIgcXVvdGluZyBhIHNlY3Rpb24gZnJvbQ0KPiB0aGUNCj4gPiA+ID4gaW5mby1tb2RlbCBkcmFm dCwgcGxlYXNlIGhhdmUgYSBsb29rIGluIHBhcnRpY3VsYXIgdG8gdGhlDQo+IGV4YW1wbGU6DQo+ ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ICAgICIgVW5yZXNlcnZlZCByZXNvdXJjZXMgbmVlZCB0 byBiZSBhZHZlcnRpc2VkIHBlciBwcmlvcml0eSBhbmQNCj4gcGVyDQo+ID4gPiA+ICAgIHNpZ25h bCB0eXBlIGluIG9yZGVyIHRvIGFsbG93IHRoZSBjb3JyZWN0IGZ1bmN0aW9uaW5nIG9mIHRoZQ0K PiA+ID4gPiAgICByZXN0b3JhdGlvbiBwcm9jZXNzLiAgW1JGQzQyMDNdIG9ubHkgYWxsb3dzIGFk dmVydGlzaW5nDQo+IHVucmVzZXJ2ZWQNCj4gPiA+ID4gICAgcmVzb3VyY2VzIHBlciBwcmlvcml0 eSwgdGhpcyBsZWFkcyBub3QgdG8ga25vdyBob3cgbWFueSBMU1BzDQo+IG9mIGENCj4gPiA+ID4g ICAgc3BlY2lmaWMgc2lnbmFsIHR5cGUgY2FuIGJlIHJlc3RvcmVkLiAgQXMgZXhhbXBsZSBpdCBp cw0KPiBwb3NzaWJsZSB0bw0KPiA+ID4gPiAgICBjb25zaWRlciB0aGUgc2NlbmFyaW8gZGVwaWN0 ZWQgaW4gdGhlIGZvbGxvd2luZyBmaWd1cmUuDQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICAg ICAgICAgICstLS0tLS0rIGNvbXBvbmVudCBsaW5rIDEgKy0tLS0tLSsNCj4gPiA+ID4gICAgICAg ICAgICAgICAgICAgfCAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgfA0KPiA+ID4gPiAg ICAgICAgICAgICAgICAgICB8ICAgICAgfCBjb21wb25lbnQgbGluayAyIHwgICAgICB8DQo+ID4g PiA+ICAgICAgICAgICAgICAgICAgIHwgIE4xICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgTjIgIHwN Cj4gPiA+ID4gICAgICAgICAgICAgICAgICAgfCAgICAgIHwgY29tcG9uZW50IGxpbmsgMyB8ICAg ICAgfA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICB8ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LSsgICAgICB8DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICstLS0tLS0rICAgICAgICAgICAg ICAgICAgKy0tLSstLSsNCj4gPiA+ID4NCj4gPiA+ID4gICAgU3VwcG9zZSB0byBoYXZlIGEgVEUg bGluayBjb21wcmlzaW5nIDMgT0RVMyBjb21wb25lbnQgbGlua3MNCj4gd2l0aA0KPiA+ID4gPiAg ICAzMlRTcyBhdmFpbGFibGUgb24gdGhlIGZpcnN0IG9uZSwgMjRUU3Mgb24gdGhlIHNlY29uZCwg MjRUU3MNCj4gb24gdGhlDQo+ID4gPiA+ICAgIHRoaXJkIGFuZCBzdXBwb3J0aW5nIE9EVTIgYW5k IE9EVTMgc2lnbmFsIHR5cGVzLiAgVGhlIG5vZGUNCj4gd291bGQNCj4gPiA+ID4gICAgYWR2ZXJ0 aXNlIGEgVEUgbGluayB1bnJlc2VydmVkIGJhbmR3aWR0aCBlcXVhbCB0byA4MCBUU3MgYW5kDQo+ ID4gPiA+IGENCj4gTUFYDQo+ID4gPiA+ICAgIExTUCBiYW5kd2lkdGggZXF1YWwgdG8gMzIgVFNz LiAgSW4gY2FzZSBvZiByZXN0b3JhdGlvbiB0aGUNCj4gbmV0d29yaw0KPiA+ID4gPiAgICBjb3Vs ZCB0cnkgdG8gcmVzdG9yZSAyIE9EVTMgKDY0VFNzKSBpbiBzdWNoIFRFLWxpbmsgd2hpbGUNCj4g PiA+ID4gb25seQ0KPiBhDQo+ID4gPiA+ICAgIHNpbmdsZSBPRFUzIGNhbiBiZSBzZXQgdXAgYW5k IGEgY3JhbmstYmFjayB3b3VsZCBiZQ0KPiBvcmlnaW5hdGVkLiAgSW4NCj4gPiA+ID4gICAgbW9y ZSBjb21wbGV4IG5ldHdvcmsgc2NlbmFyaW9zIHRoZSBudW1iZXIgb2YgY3JhbmstYmFja3MgY2Fu DQo+IGJlIG11Y2gNCj4gPiA+ID4gICAgaGlnaGVyLiINCj4gPiA+ID4NCj4gPiA+ID4gSW4gb3Ro ZXIgd29yZHMsIGFkdmVydGlzaW5nIHRoZSBudW1iZXIgb2YgYXZhaWxibGUgcmVzb3VyY2VzIHBl cg0KPiBzaWduYWwNCj4gPiA+ID4gdHlwZSBkb2VzIG5vdCBhdm9pZCB0aGUgcG9zc2liaWxpdHkg b2YgY3JhbmNrLWJhY2sgYnV0IGRlY3JlYXNlcw0KPiBpdCBhcw0KPiA+ID4gPiBtdWNoIGFzIHBv c3NpYmxlLiBGb3Igc3VyZSBhIGdvb2Qgcm91dGluZyBwcmV2ZW50cyBmcm9tIGNyYW5rLQ0KPiBi YWNrcw0KPiA+ID4gPiBjYXVzZWQgYnkgdGhlIHJlc3RvcmF0aW9uIG9mIExTUCBvcmlnaW5hdGlu ZyBvbiB0aGUgc2FtZSBJbmdyZXNzLg0KPiBUaGUNCj4gPiA+ID4gY3JhbmNrLWJhY2tzIGR1ZSB0 byB0aGUgY29uY3VycmVudCByZXN0b3JhdGlvbiBvZiBMU1BzDQo+IG9yaWdpbmF0aW5nIG9uDQo+ ID4gPiA+IGRpZmZlcmVudCBpbmdyZXNzIG5vZGVzIGNhbm5vdCBiZSBhdm9pZGVkLg0KPiA+ID4g Pg0KPiA+ID4gPiBCUg0KPiA+ID4gPiBEYW5pZWxlDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IElnb3IgQnJ5c2tpbiBb bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NCj4gPiA+ID4gU2VudDogbWFydGVkPUVD IDIwIGx1Z2xpbyAyMDEwIDE2LjE2DQo+ID4gPiA+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IFNu aWdkaG8gQmFyZGFsYWk7IEZhdGFpIFpoYW5nOw0KPiBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiA+ IENjOiBjY2FtcEBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50 IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gZnJhbWV3b3JrLQ0KPiA+ID4gPiAw MS50eHQNCj4gPiA+ID4NCj4gPiA+ID4gSW4gbGluZQ0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4g PiA+ID4gW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0KPiA+ID4gPiBT ZW50OiBUdWVzZGF5LCBKdWx5IDIwLCAyMDEwIDQ6MzIgQU0NCj4gPiA+ID4gVG86IFNuaWdkaG8g QmFyZGFsYWk7IElnb3IgQnJ5c2tpbjsgRmF0YWkgWmhhbmc7DQo+ID4gPiA+IGN1cnRpc0BvY2Nu Yy5jb20NCj4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBb Q0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiBmcmFtZXdv cmstDQo+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPg0KPiA+ID4gPiBJZ29yLCBvbmUgbW9yZSBxdWVz dGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gV2hhdCBhYm91dCB0aGUgdW5yZXNlcnZlZCBiYW5kd2lk dGg/DQo+ID4gPiA+IElmIHlvdSdyZSBhZHZlcnRpc2luZyB0aGUgbWF4IGxzcCBiYW5kd2lkdGgg YnkgMSBJU0NEIHBlciByb2xlDQo+IHBlcg0KPiA+ID4gPiAobXV4Q2FwICYgc2lnbmFsIHR5cGUp IHlvdSBhbHNvIG5lZWQgdG8gYWR2ZXJ0aXNlIHRoZSB1bnJlc2VydmVkDQo+ID4gPiA+IGJhbmR3 aWR0aCB1c2luZyAxIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIHN1Yi1UTFYgcGVyIElTQ0QsIGNvcnJl Y3Q/DQo+IFRoaXMNCj4gPiA+ID4gYWxzbyBpbXBsaWVzIGV4dGVuZGluZyB0aGUgdW5yZXNlcnZl ZCBiYW5kd2lkdGggVExWIHNvIHRvIGNyZWF0ZQ0KPiBhDQo+ID4gPiA+IGNvcnJpc3BvbmRlbmNl IGJldHdlZW4gdGhlIGNvdXBsZXMgKElTQ0QtdW5yZXNlcnZlZCBiYW5kd2lkdGgNCj4gc3ViVExW KS4NCj4gPiA+ID4NCj4gPiA+ID4gSUI+PiBBZ3JlZSB0aGF0IG1heCBsc3AgYmFuZHdpZHRoIHNo b3VsZCBiZSBhZHZlcnRpc2VkIGJ5IDEgSVNDRA0KPiBwZXINCj4gPiA+ID4gSUI+PiByb2xlIHBl ciAobXV4Q2FwICYgc2lnbmFsIHR5cGUpIHBlciBwcmlvcml0eSBsZXZlbC4NCj4gPiA+ID4gSUI+ PiBIb3dldmVyLA0KPiB0b3RhbA0KPiA+ID4gPiBJQj4+IHVucmVzZXJ2ZWQgYmFuZHdpZHRoIElN TyBpcyBPSyB0byBzaGFyZSBiZXR3ZWVuIHJvbGVzDQo+ID4gPiA+IElCPj4gdW5sZXNzDQo+IHlv dQ0KPiA+ID4gPiBJQj4+IHNlZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIHRoZSBjb250cmFyeSAo d2hpY2ggSSBkb24ndCkNCj4gPiA+ID4NCj4gPiA+ID4gSWdvcg0KPiA+ID4gPg0KPiA+ID4gPiBU aGFua3MNCj4gPiA+ID4gRGFuaWVsZQ0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBTbmlnZGhvIEJhcmRhbGFpIFttYWlsdG86U0JhcmRh bGFpQGluZmluZXJhLmNvbV0NCj4gPiA+ID4gU2VudDogbHVuZWQ9RUMgMTkgbHVnbGlvIDIwMTAg MTcuNDgNCj4gPiA+ID4gVG86IElnb3IgQnJ5c2tpbjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBGYXRh aSBaaGFuZzsNCj4gY3VydGlzQG9jY25jLmNvbQ0KPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmcN Cj4gPiA+ID4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLWc3MDktDQo+IGZyYW1ld29yay0NCj4gPiA+ID4gMDEudHh0DQo+ID4gPiA+DQo+ID4g PiA+IFVuZGVyc3Rvb2QuLi4NCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcw0KPiA+ID4gPiBTbmln ZGhvDQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4gPiBGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21d DQo+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDE5LCAyMDEwIDg6NDYgQU0NCj4gPiA+ID4g PiBUbzogU25pZ2RobyBCYXJkYWxhaTsgRGFuaWVsZSBDZWNjYXJlbGxpOyBGYXRhaSBaaGFuZzsN Cj4gPiA+ID4gPiBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3Jn DQo+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLWc3MDktDQo+ID4gPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiAwMS50eHQNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IFtTQ0JdIEFyZSB5b3Ugc2F5aW5nIHRoZSBJU0NEIGFzIGRlZmlu ZWQgdG9kYXkgd2l0aCBtaW5vcg0KPiBleHRlbnNpb25zDQo+ID4gPiA+ID4gKGkuZS4gdG8gZnVy dGhlciBjbGFzc2lmeSB0aGUgaW5mb3JtYXRpb24pIHdpbGwgYmUgc3VmZmljaWVudA0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gVGhhdCdzIGV4YWN0bHkgd2hhdCBJJ3ZlIGJlZW4NCj4gPiA+ID4gPiB0 cnlpbmcgdG8gc2F5IGFsbCBhbG9uZy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENoZWVycywNCj4g PiA+ID4gPiBJZ29yDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gPiA+IEZyb206IFNuaWdkaG8gQmFyZGFsYWkgW21haWx0bzpTQmFyZGFsYWlA aW5maW5lcmEuY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAxOSwgMjAxMCAxMToz MSBBTQ0KPiA+ID4gPiA+IFRvOiBJZ29yIEJyeXNraW47IERhbmllbGUgQ2VjY2FyZWxsaTsgRmF0 YWkgWmhhbmc7DQo+IGN1cnRpc0BvY2NuYy5jb20NCj4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5v cmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4gZnJhbWV3b3JrLQ0KPiA+ID4gPiA+IDAxLnR4dA0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSWdvcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUGxlYXNlIHNl ZSBpbmxpbmUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBSZWdhcmRzDQo+ID4gPiA+ID4gU25pZ2Ro bw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gPiA+ID4gRnJvbTogSWdvciBCcnlza2luIFttYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwu Y29tXQ0KPiA+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDE5LCAyMDEwIDc6NDMgQU0NCj4g PiA+ID4gPiA+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IEZhdGFpIFpoYW5nOyBjdXJ0aXNAb2Nj bmMuY29tDQo+ID4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWkN Cj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4gPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4 dA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IERhbmllbGUsDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gUGxlYXNlLCBzZWUgaW4gbGluZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBDaGVl cnMsDQo+ID4gPiA+ID4gPiBJZ29yDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IERhbmllbGUgQ2VjY2FyZWxsaQ0K PiBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+ID4gPiA+ID4gPiBT ZW50OiBNb25kYXksIEp1bHkgMTksIDIwMTAgMTA6MzEgQU0NCj4gPiA+ID4gPiA+IFRvOiBJZ29y IEJyeXNraW47IEZhdGFpIFpoYW5nOyBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiA+ID4gPiBDYzog Y2NhbXBAaWV0Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWkNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJF OiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4g PiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+IEhpIElnb3IsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSSBkaWRuJ3QgdW5kZXJzdGFu ZCBpZiB5b3UncmUgcHJvcG9zaW5nIHRvIChhKSBzZW5kIGFuIElTQ0QNCj4gcGVyDQo+ID4gPiA+ IHJvbGUNCj4gPiA+ID4gPiA+IChpLmUuIE9UTl9IT19TQywgT1ROX0xPX1NDKSBvciAoYikgYW4g SVNDRCBwZXIgcm9sZSBwZXINCj4gc2lnbmFsDQo+ID4gPiA+IHR5cGUuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gSUI+PiBpbiBJU0NEOg0KPiA+ID4gPiA+ID4gc3dpdGNoQ2FwID0zRCByb2xl Ow0KPiA+ID4gPiA+ID4gZW5jb2RlVHlwZSA9M0QgbXV4Q2FwICYgc2lnbmFsIHR5cGU7IFdlIGFs c28gaGF2ZSAxNg0KPiA+ID4gPiA+ID4gcmVzZXJ2ZWQgYml0cyB3aGljaCBjYW4gdXNlIGZvciBP VE4gc3BlY2lmaWMNCj4gaW5mbw0KPiA+ID4gPiBpbg0KPiA+ID4gPiA+ID4gY2FzZSB3ZSBuZWVk IGl0Lg0KPiA+ID4gPiA+IFtTQ0JdIEkgYW0geWV0IHRvIGNsZWFybHkgdW5kZXJzdGFuZCB3aGF0 IHRoZSByb2xlIG9mICJyb2xlIg0KPiBpcywgYnV0DQo+ID4gPiA+ID4gYWdyZWUgd2l0aCB5b3Vy IG9ic2VydmF0aW9uIG9uIHRoZSBlbmNvZGUtdHlwZSBhbmQgdGhlIDE2DQo+ID4gPiA+ID4gcmVz ZXJ2ZWQtYml0cyB0byBmdXJ0aGVyIGNsYXNzaWZ5IHRoZSBzd2l0Y2hpbmcgaW5mb3JtYXRpb24u DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSW4gY2FzZSAoYSkgeW91J3JlIHN0aWxsIG1pc3Np bmcgYSBsb3Qgb2YgaW5mb3JtYXRpb24uIEZvcg0KPiBlYWNoDQo+ID4gPiA+IHJvbGUNCj4gPiA+ ID4gPiA+IHlvdSB3b3VsZCBhZHZlcnRpc2UganVzdCB0aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGgg YnV0IHlvdQ0KPiB3b3VsZG4ndA0KPiA+ID4gPiA+IGtub3cNCj4gPiA+ID4gPiA+IGlmIHN1Y2gg YmFuZHdpZHRoIGlzIGF2YWlsYWJsZSBmb3IgYSBjZXJ0YWluIHR5cGUgb2YgT0RVag0KPiA+ID4g PiA+ID4gTFNQDQo+IChlLmcuDQo+ID4gPiA+ID4gMTUNCj4gPiA+ID4gPiA+IEdicHMgYXZhaWxh YmxlIG9uIDMgY29tcG9uZW50IGxpbmtzOiB5b3UgYWR2ZXJ0aXNlIDQ1IEdicHMNCj4gPiA+ID4g YXZhaWxhYmxlDQo+ID4gPiA+ID4gPiBidXQgbm8gT0RVMyBjYW4gYmUgc2V0IHVwIG9uIHN1Y2gg VEUgbGluaykuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSW4gY2FzZSAoYikgdGhlIG51bWJl ciBvZiBJU0NEcyB3b3VsZCBjYXVzZSBzZXJpb3VzDQo+IHNjYWxhYmlsaXR5DQo+ID4gPiA+ID4g aXNzdWVzDQo+ID4gPiA+ID4gPiBhbmQgdGhlIHJlcXVpcmVtZW50IG9mIGJlaW5nIGFibGUgdG8g YnVuZGxlIGNvbXBvbmVudCBsaW5rcw0KPiA+ID4gPiB0b2dldGhlcg0KPiA+ID4gPiA+ID4gd291 bGRuJ3QgYmUgc2F0aXNmaWVkLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IElCPj4gRGlzYWdy ZWUuIElTQ0QgaXMgYSByZWxhdGl2ZWx5IHNtYWxsIHN1YlRMViwgc2V2ZXJhbA0KPiBJU0RDcw0K PiA+ID4gPiB3aWxsDQo+ID4gPiA+ID4gPiBwcm92aWRlIGEgbG90IG9mIGZsZXhpYmlsaXR5OiB5 b3UgY2FuIHNwZWNpZnkgZGlmZmVyZW50DQo+IHRoaW5ncw0KPiA+ID4gPiAoZS5nLg0KPiA+ID4g PiA+ID4gYXZhaWxhYmxlIGJhbmR3aWR0aCkgZm9yIHRoZSBzYW1lIGxpbmsgaW4gZGlmZmVyZW50 IHJvbGVzLg0KPiA+ID4gPiA+IFtTQ0JdIEFyZSB5b3Ugc2F5aW5nIHRoZSBJU0NEIGFzIGRlZmlu ZWQgdG9kYXkgd2l0aCBtaW5vcg0KPiBleHRlbnNpb25zDQo+ID4gPiA+ID4gKGkuZS4gdG8gZnVy dGhlciBjbGFzc2lmeSB0aGUgaW5mb3JtYXRpb24pIHdpbGwgYmUgc3VmZmljaWVudD8NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ID4gPiBEYW5pZWxlDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYu b3JnXQ0KPiBPbg0KPiA+ID4gPiA+IEJlaGFsZg0KPiA+ID4gPiA+ID4gT2YgSWdvciBCcnlza2lu DQo+ID4gPiA+ID4gPiBTZW50OiBsdW5lZD1FQyAxOSBsdWdsaW8gMjAxMCAxNS40MA0KPiA+ID4g PiA+ID4gVG86IEZhdGFpIFpoYW5nOyBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiA+ID4gPiBDYzog Y2NhbXBAaWV0Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWkNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4g PiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+IEZhdGFpLA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFBsZWFzZSwgc2VlIG15IHJlc3Bv bnNlcyBvbi1saW5lLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4g PiA+IElnb3INCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNj YW1wLWJvdW5jZXNAaWV0Zi5vcmddDQo+IE9uDQo+ID4gPiA+ID4gQmVoYWxmDQo+ID4gPiA+ID4g PiBPZiBGYXRhaSBaaGFuZw0KPiA+ID4gPiA+ID4gU2VudDogU3VuZGF5LCBKdWx5IDE4LCAyMDEw IDEwOjQ5IFBNDQo+ID4gPiA+ID4gPiBUbzogSWdvciBCcnlza2luOyBjdXJ0aXNAb2NjbmMuY29t DQo+ID4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWkNCj4gPiA+ ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nNzA5LQ0KPiA+ID4gPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4dA0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIElnb3IsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g VGhhbmtzLg0KPiA+ID4gPiA+ID4gSSB1bmRlcnN0YW5kIHdoYXQgeW91IHNhaWQuIFRoZXJlZm9y ZSwgd2UgaGF2ZSBhZGRlZCBzb21lDQo+IHRleHQgdG8NCj4gPiA+ID4gPiA+IGFkZHJlc3MgdGhl IHJlcXVpcm1lbnQgaW4gRldLIGRvY3VtZW50LiBIb3dldmVyLCB3ZSBzdGlsbA0KPiBkb24ndA0K PiA+ID4gPiA+ID4gdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGV4dGVuZCBJU0MgdG8gbWVldCB0aGUg cmVxdWlybWVudC4gVGhlDQo+IHJvbGUNCj4gPiA+ID4gb2YNCj4gPiA+ID4gPiA+IHRoZQ0KPiA+ ID4gPiA+IE9EVQ0KPiA+ID4gPiA+ID4gY2FuIGJlIGdldCBmcm9tIHRoZSByb3V0aW5nIGluZm9y bWF0aW9uIGltcGxpY2l0bHkuIEluIHRoZQ0KPiBbZHJhZnQtDQo+ID4gPiA+ID4gPiBjZWNjYXJl bGxpLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMl0gZHJhZnQsIGEga2luZCBvZiAgIkZ1bGwNCj4g PiA+ID4gTGFtYmRhIg0KPiA+ID4gPiA+IGlzDQo+ID4gPiA+ID4gPiBpbnRyb2R1Y2VkLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IElCPj4gVGhpcyBpcyBwb3NzaWJsZSwgaG93ZXZlcjoNCj4g PiA+ID4gPiA+IGEpIHRoaXMgcmVxdWlyZXMgT1ROIHNwZWNpZmljIGFkdmVydGlzaW5nIGFuZCBw cm9jZXNzaW5nDQo+IHJ1bGVzOw0KPiA+ID4gPiA+ID4gYikgZGlzYWxsb3dzIHRvcG9sb2d5IHNl cGFyYXRpb24gaW4gdGVjaG5vbG9neSBpbmRlcGVuZGVudA0KPiB3YXkNCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBBIHF1aWNrIHF1ZXN0aW9uIG9uIHlvdXIgc3RhdGVtZW50OiAidGhlIHJvbGUg b2YgYW4gT0RVDQo+IGNvbnRhaW5lcg0KPiA+ID4gPiA+IGRvZXMNCj4gPiA+ID4gPiA+IG5vdCBj aGFuZ2UgaG9wLWJ5LWhvcCAoYXMgc29tZSBwZW9wbGUgc2VlbSB0byBiZWxpZXZlKS4gVGhlDQo+ IHJvbGUgaXMNCj4gPiA+ID4gPiA+IG9ubHkgbWVhbmluZ2Z1bCBvbiB0aGUgT0RVIHRlcm1pbmF0 aW5nIG5vZGVzIGFuZCBpcnJlbGV2YW50DQo+IG9uDQo+ID4gPiA+ID4gdHJhbnNpdA0KPiA+ID4g PiA+ID4gbm9kZXMuIEl0IGlzIGl0J3MgcG9zaXRpb24gaW4gdGhlIGhpZXJhcmNoeSAoYnV0IG5v dCByb2xlKQ0KPiB0aGF0IG1heQ0KPiA+ID4gPiA+ID4gY2hhbmdlIGhvcC1ieS1ob3AuICINCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGb3IgZXhhbXBsZSwgQShBSTEpLS0tLShCSTEpQihCSTIp LS0tLShDSTEpQywgIEludGVyZmFjZXMNCj4gPiA+ID4gPiA+IEFJMQ0KPiBhbmQNCj4gPiA+ID4g PiA+IENJMSBjYW4gc3VwcG9ydCBIbyBPRFUyIGFuZCBMbyBPRFUyLCBIb3dldmVyLCBCSTEgYW5k IEJJMg0KPiA+ID4gPiA+ID4gY2FuDQo+IG9ubHkNCj4gPiA+ID4gPiBzdXBwb3J0DQo+ID4gPiA+ ID4gPiBMbyBPRFUyICh0aGUgcm9sZSBpcyBMbyBPVE4gTGV2ZWwpLiBJZiBhIGNvbm5lY3Rpb24g T0RVMg0KPiA+ID4gPiA+ID4gd2l0aA0KPiB0aGUNCj4gPiA+ID4gPiByb2xlDQo+ID4gPiA+ID4g PiBvZiBIbyBPRFUgbGV2ZWwgaXMgcmVxdWVzdGVkLCAgYWNjb3JkaW5nIHRvIHlvdXIgc3RhdGVt ZW50LA0KPiB0aGlzDQo+ID4gPiA+ID4gPiBjb25uZWNpdG9uIHdpbGwgYmUgYWxsb3dlZCB0byBi ZSBjcmVhdGVkLiBIb3dldmVyLCBpdCBzaG91bGQNCj4gbm90IGJlDQo+ID4gPiA+ID4gPiBhbGxv d2VkIGJlY2F1c2UgdGhlIElTQyBpcyBub3QgY29uc2lzdGVudCBhbG9uZyB0aGUgTFNQLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IElCPj4gTm8sIHlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3Qg Y29ycmVjdC4gQTExIGFuZCBDMTEgVEUNCj4gbGluaw0KPiA+ID4gPiBlbmRzDQo+ID4gPiA+ID4g PiB3aWxsIGJlIGFkdmVydGlzZWQgd2l0aCB0d28gSVNDRHM6IE9UTl9IT19TQyBhbmQgT0lOX0xP X1NDLA0KPiB3aGlsZQ0KPiA+ID4gPiA+ID4gQjExIGFuZCBCMTIgLSBvbmx5IHdpdGggYSBzaW5n bGUgSVNDRDogT1ROX0xPX1NDLiBJZiB0aGUNCj4gPiA+ID4gPiA+IHBhdGggY29tcHV0YXRpb24g aXMgY29uc3RyYWluZWQgdG8gdGhlIE9UTl9IT19TQyB0b3BvbG9neSwNCj4gPiA+ID4gPiA+IEIx MSBhbmQNCj4gQjEyDQo+ID4gPiA+IFRFDQo+ID4gPiA+ID4gPiBsaW5rcyB3aWxsDQo+ID4gPiA+ ID4gYmUNCj4gPiA+ID4gPiA+IGRpc2FsbG93ZWQsIGFuZCB0aGUgcmVzdWx0aW5nIHBhdGggKGlm IGFueSkgd2lsbCBub3QgZ28NCj4gdGhyb3VnaCBCMTENCj4gPiA+ID4gPiBhbmQNCj4gPiA+ID4g PiA+IEIxMi4gSWYgb25lIGNpcmN1bXZlbnRzIHRoZSBwYXRoIGNvbXB1dGF0aW9uIGJ5IHByb3Zp ZGluZw0KPiA+ID4gPiA+ID4gdGhlDQo+IGZ1bGx5DQo+ID4gPiA+ID4gPiBleHBsaWNpdCBwYXRo LCB0aGUgc2lnbmFsaW5nIHNob3VsZCBmYWlsIG9uIG5vZGUgQiBmb3IgdGhlDQo+IHNhbWUNCj4g PiA+ID4gPiByZWFzb246DQo+ID4gPiA+ID4gPiBpbmNvbnNpc3RlbmN5IG9mIHJlcXVpcmVkIChz aWduYWxlZCkgYW5kIHN1cHBvcnRlZCAoYnkgbG9jYWwNCj4gPiA+ID4gPiA+IGludGVyZmFjZXMp IHN3aXRjaGNhcC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBQbGVhc2Ugc2VlIHRoZSB0ZXh0 IGZyb20gUkZDMzQ3MzogICAiTm9kZXMgTVVTVCB2ZXJpZnkgdGhhdA0KPiB0aGUNCj4gPiA+ID4g dHlwZQ0KPiA+ID4gPiA+ID4gaW5kaWNhdGVkIGluIHRoZSBTd2l0Y2hpbmcgVHlwZSAgcGFyYW1l dGVyIGlzIHN1cHBvcnRlZCBvbg0KPiB0aGUNCj4gPiA+ID4gPiA+IGNvcnJlc3BvbmRpbmcgaW5j b21pbmcgaW50ZXJmYWNlLiAgSWYgIHRoZSB0eXBlIGNhbm5vdCBiZQ0KPiA+ID4gPiBzdXBwb3J0 ZWQsDQo+ID4gPiA+ID4gPiB0aGUgbm9kZSBNVVNUIGdlbmVyYXRlIGEgUGF0aEVyciBtZXNzYWdl IHdpdGggYSAiUm91dGluZw0KPiA+ID4gPiA+ID4gcHJvYmxlbS9Td2l0Y2hpbmcgVHlwZSIgaW5k aWNhdGlvbi4iDQo+ID4gPiA+ID4gPiBJQj4+IEluZGVlZA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEJlc3QgUmVnYXJkcw0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEZhdGFpDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogIklnb3IgQnJ5 c2tpbiIgPElCcnlza2luQGFkdmFvcHRpY2FsLmNvbT4NCj4gPiA+ID4gPiA+IFRvOiAiRmF0YWkg WmhhbmciIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+Ow0KPiA+ID4gPiA+ID4gPGN1cnRpc0BvY2Nu Yy5jb20+DQo+ID4gPiA+ID4gPiBDYzogIkpvaG4gRSBEcmFrZSIgPGpkcmFrZUBqdW5pcGVyLm5l dD47ICJTbmlnZGhvIEJhcmRhbGFpIg0KPiA+ID4gPiA+ID4gPFNCYXJkYWxhaUBpbmZpbmVyYS5j b20+OyAiTG91IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+Ow0KPiA+ID4gPiA+ID4gPGNjYW1w QGlldGYub3JnPjsgPGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4gPiA+IGZy YW1ld29ya0B0b29scy5pZXRmLm9yZz4NCj4gPiA+ID4gPiA+IFNlbnQ6IEZyaWRheSwgSnVseSAx NiwgMjAxMCAxMjozNCBBTQ0KPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVu dCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiA+ID4gZnJhbWV3b3JrLQ0K PiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IEZhdGFpLA0KPiA+ID4gPiA+ID4gUGxlYXNlLCBzZWUgbXkgYW5zd2VycyBpbiBsaW5lLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ ID4gPiBGcm9tOiBGYXRhaSBaaGFuZyBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NCj4g PiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNCwgMjAxMCA5OjUyIFBNDQo+ID4gPiA+ ID4gPiBUbzogSWdvciBCcnlza2luOyBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiA+ID4gPiBDYzog Sm9obiBFIERyYWtlOyBTbmlnZGhvIEJhcmRhbGFpOyBMb3UgQmVyZ2VyOw0KPiBjY2FtcEBpZXRm Lm9yZzsNCj4gPiA+ID4gPiBkcmFmdC0NCj4gPiA+ID4gPiA+IGlldGYtY2NhbXAtZ21wbHMtZzcw OS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NB TVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4gPiA+IGZy YW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhp IElnb3IgYW5kIGFsbCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGFua3MgZm9yIGFsbCB5 b3VyIGNvbW1lbnRzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEkgdGhpbmsgcm9sZSBkb2Vz IG5vdCBlcXVhbCBzd2l0Y2hpbmcgY2FwYWJpbGl0eS4gVGhlDQo+IG9wZXJhdG9ycyBjYW4NCj4g PiA+ID4gPiA+IGRlZmluZSBkaWZmZXJlbnQgcm9sZXMgZGVwZW5kaW5nIG9uIHRoZWlyIHBvbGlj eSBhbmQgYWNoaWV2ZQ0KPiB0aGUNCj4gPiA+ID4gPiA+IHJvbGUgdGhyb3VnaCBkaWZmZXJlbnQg bWV0aG9kcy4gSG93ZXZlciwgZm9yIE9UTiBuZXR3b3JrcywNCj4gdGhlDQo+ID4gPiA+ID4gPiBj b250YWluZXJzIChlLmcuLCBPRFVrKSBhbGwgaGF2ZSB0aGUgc2FtZSBzd2l0Y2hpbmcNCj4gY2Fw YWJsaWxpdHkNCj4gPiA+ID4gPiA+IChpLmUuLCBURE0NCj4gPiA+ID4gPiA+IHN3aXRjaGluZykg YW5kIEkgdGhpbmsgd2Ugc2hvdWxkIHJlZmxlY3QgdGhlIG5hdHVyYWwNCj4gPiA+ID4gY2hhcmFj dGVyaXN0aWNzDQo+ID4gPiA+ID4gb2YNCj4gPiA+ID4gPiA+IGxpbmtzIGluIHRoZSByb3V0aW5n LiBJbiBhZGRpdGlvbiwgaWYgd2UgZXh0ZW5kIHRoZSBJU0MsIGl0DQo+IHdpbGwNCj4gPiA+ID4g PiA+IG1ha2UgdGhlIGVuY29kaW5nIHR5cGUgbG9zZSBpdHMnIG93biBtZWFuaW5nKGllLiwgSVND DQo+IG92ZXJyaWRlcw0KPiA+ID4gPiA+ID4gZW5jb2RpbmcgdHlwZSkuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gSUI+PiBXaGVuIGEgR01QTFMgQ1AgaW5zdGFuY2UgY29udHJvbHMgc2V2ZXJh bCBsYXllcnMsIGl0DQo+IHZpZXdzIHRoZQ0KPiA+ID4gPiA+ID4gbmV0d29yayBhcyBhIHN0YWNr IG9mIHRvcG9sb2dpZXMuIFdoZXRoZXIgYSBnaXZlbiB0b3BvbG9neQ0KPiA+ID4gPiA+ID4gaXMN Cj4gcmVhbA0KPiA+ID4gPiA+ID4gb3IgdmlydHVhbCBpcyBvZiBubyBpbXBvcnRhbmNlLg0KPiA+ ID4gPiA+ID4gVGhlIEdNUExTIElTQ0QgbGluayBzdWItdGx2IGFuZCwgaW4gcGFydGljdWxhciwg aXRzDQo+ID4gPiA+ID4gPiBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBmaWVsZCAoY29uZnVzaW5nIG5h bWUgYXMgaXQgaXMpIGlzIGENCj4gPiA+ID4gPiA+IGdvb2Qgd2F5IHRvDQo+ID4gPiA+IGRlc2Ny aWJlDQo+ID4gPiA+ID4gYQ0KPiA+ID4gPiA+ID4gbGF5ZXIgaW4gdGVjaG5vbG9neSBpbmRlcGVu ZGVudCB3YXksIHNvIHRoYXQsIHNheSwgTVBMUy1UUC0NCj4gPk9UTl9MTy0NCj4gPiA+ID4gPiA+ ID5PVE5fSE8tPk9UTl9TSE8tPldETSBsYXllciBzdGFjayBjb3VsZCBiZSBwZXJjZWl2ZWQgYXMg YQ0KPiBzdGFjayBvZg0KPiA+ID4gPiA+ID4gdG9wb2xvZ2llcyB0aGF0IGNvdWxkIGJlIGVhc2ls eSBzZXBhcmF0ZWQgaW4gdGVjaG5vbG9neQ0KPiBpbmRlcGVuZGVudA0KPiA+ID4gPiA+IHdheQ0K PiA+ID4gPiA+ID4gc2hvdWxkIHBhdGggY29tcHV0YXRpb24gYmUgY29uc3RyYWluZWQgdG8gcGFy dGljdWxhciBvbmUgb3INCj4gPiA+ID4gPiA+IHN1Yi1zdGFjayBvZiB0aGVtLg0KPiA+ID4gPiA+ ID4gSSB0aGluayBhIGdvb2Qgd2F5IHRvIGlkZW50aWZ5IGFuIE9UTiAodmlydHVhbCkgdG9wb2xv Z3kgaXMNCj4gdmlhDQo+ID4gPiA+ID4gPiAoaW5mcmFzdHJ1Y3R1cmUpIE9EVSBjb250YWluZXIg cm9sZSBvZiBPRFVzIGNvbXByaXNpbmcgdGhlDQo+ID4gPiA+IHRvcG9sb2d5Lg0KPiA+ID4gPiA+ ID4gQlRXIElNTyB0aGUgcm9sZSBvZiBhbiBPRFUgY29udGFpbmVyIGRvZXMgbm90IGNoYW5nZSBo b3AtYnktDQo+IGhvcCAoYXMNCj4gPiA+ID4gPiA+IHNvbWUgcGVvcGxlIHNlZW0gdG8gYmVsaWV2 ZSkuIFRoZSByb2xlIGlzIG9ubHkgbWVhbmluZ2Z1bCBvbg0KPiB0aGUNCj4gPiA+ID4gT0RVDQo+ ID4gPiA+ID4gPiB0ZXJtaW5hdGluZyBub2RlcyBhbmQgaXJyZWxldmFudCBvbiB0cmFuc2l0IG5v ZGVzLiBJdCBpcw0KPiA+ID4gPiA+ID4gaXQncw0KPiA+ID4gPiA+IHBvc2l0aW9uDQo+ID4gPiA+ ID4gPiBpbiB0aGUgaGllcmFyY2h5IChidXQgbm90IHJvbGUpIHRoYXQgbWF5IGNoYW5nZSBob3At YnktaG9wLg0KPiBPRFUncw0KPiA+ID4gPiA+IHJvbGUNCj4gPiA+ID4gPiA+IGlzIHRoZSBsZXZl bCBvZiB0b3BvbG9neSBpdCBpcyBwcm92aXNpb25lZCBmb3IgYW5kIGl0IGlzIHRoZQ0KPiBzYW1l DQo+ID4gPiA+ID4gPiBmb3IgYWxsIE9EVXMgdGhhdCBjb21wcmlzZSB0aGUgdG9wb2xvZ3kuIEZv ciwgZXhhbXBsZSBhIHVzZXINCj4gbWF5DQo+ID4gPiA+ID4gcHJvdmlzaW9uDQo+ID4gPiA+ID4g PiBhIExPIHRvcG9sb2d5IGFuZCBjb25zdHJhaW4gT0RVcyBoZSBzZWxscyB0byBhIHNldCBvZg0K PiA+ID4gPiA+ID4gY2xpZW50cw0KPiB0bw0KPiA+ID4gPiB1c2UNCj4gPiA+ID4gPiA+IHRoZSB0 b3BvbG9neSByYXRoZXIgdGhhbiBhbnkgcmVzb3VyY2VzIGF2YWlsYWJsZSBvbiBPVE4NCj4gbmV0 d29yay4NCj4gPiA+ID4gPiA+IFRoZSBib3R0b20gbGluZTogY29udGFpbmVyJ3Mgcm9sZSBpcyB0 aGUgc2FtZSBhcyB0aGUgcm9sZSBvZg0KPiA+ID4gPiB2aXJ0dWFsDQo+ID4gPiA+ID4gPiB0b3Bv bG9neSB0aGUgY29udGFpbmVyIGlzIGEgcGFydCBvZiBhbmQgY291bGQgYmUgYWR2ZXJ0aXNlZA0K PiBhcyB0aGUNCj4gPiA+ID4gPiA+IGNvcnJlc3BvbmRpbmcgbGluayBzd2l0Y2hjYXAuDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gQWNjb3JkaW5nIHRvIHRoZSBwb2ludCAzLCBJIGRvbid0IGtu b3cgaG93IHRvIGFkdmVydGlzZSB0aGUNCj4gcm9sZXMNCj4gPiA+ID4gPiA+IGFuZCBtdXhpbmcg Y2FwYWJpbGl0aWVzIHdpdGggdGhlIElTQ0Qgb2YgUkZDNDIwMiwgY291bGQgeW91DQo+ID4gPiA+ IGNsYXJpZnk/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSUI+PiBzd2l0Y2hjYXAgPTNEIE9E VSByb2xlIChlLmcuIExPX09UTl9TQywgSE9fT1ROX1NDLA0KPiA+ID4gPiA+ID4gSUI+PiBldGMu KQ0KPiA+ID4gPiA+ID4gICAgICBlbmNvZGluZyB0eXBlID0zRCBtdXguIGNhcGFiaWxpdGllcyBj b2RlDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSW4gYWRkaXRpb24sIGNvdWxkIHlvdSBjbGFy aWZ5IG15IHF1ZXN0aW9ucyBpbiBhbm90aGVyIGVtYWlsDQo+ID4gPiA+IChjb3BpZWQNCj4gPiA+ ID4gPiBhcw0KPiA+ID4gPiA+ID4gZm9sbG93cyk6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ ID4gPiA+DQo+ID0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj4gPg0KPiA9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9DQo+IDMNCj4gRD0z RD0NCj4gPiA9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9M0Q9M0QNCj4gPiA+ID4gPiA9M0QNCj4gPiA+ID4gPiA+DQo+ID0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0NCj4gPiA9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0QNCj4gPiA+ID4gPiA+IEZvciAgTG8gT0RVLCBI byBPRFUsIFNITyBPRFUsIHRoZXkgYXJlIHJlbGF0aXZlIHRvIGVhY2gNCj4gb3RoZXIuDQo+ID4g PiA+ID4gPiBJQj4+IEkgZGlzYWdyZWUuIFlvdSBkZWZpbmUgcm9sZSA9M0Q9M0QgcG9zaXRpb24g aW4gdGhlDQo+IGhpZXJhcmNoeSwNCj4gPiA+ID4gd2hpY2gNCj4gPiA+ID4gPiBpcw0KPiA+ID4g PiA+ID4gYSBtaXN0YWtlIElNTy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGb3IgZXhhbXBs ZSwgT0RVMS0+T0RVMi0+T0RVMy0+T0RVNCwgaG93IHRvIHJlZ2FyZCBPRFUyIG9yDQo+IE9EVTMg YXMNCj4gPiA+ID4gPiA+IEhvIE9UTiBMZXZlbCBvciBMbyBPVE4gTGV2ZWw/IEFub3RoZXIgZXhh bXBsZSBpcywgaWYgdGhlcmUNCj4gPiA+ID4gPiA+IGlzDQo+IGENCj4gPiA+ID4gT1RVMw0KPiA+ ID4gPiA+IGxpbmsNCj4gPiA+ID4gPiA+IHN1cHBvcnRpbmcgT0RVMiBzd2l0Y2hpbmcsIHdoaWNo IGNhbiBiZSB1c2VkIGFzIExvIE9EVTINCj4gKHNlcnZpY2UNCj4gPiA+ID4gPiA+IG92ZXINCj4g PiA+ID4gPiA+IE9EVTIgZGlyZWN0bHkpIGFuZCBIbyBPRFUyIChPRFUxIGlzIG92ZXIgdGhpcyBP RFUyKSwgaW4gdGhpcw0KPiBjYXNlLA0KPiA+ID4gPiA+IGhvdw0KPiA+ID4gPiA+ID4gdG8gZGlm ZmVyZW50aWF0ZSBpZiB0aGlzIE9EVTIgaXMgTG8gT1ROIExldmVsIG9yIEhvIE9UTg0KPiBMZXZl bD8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJQj4+IEFzIEkgbWVudGlvbmVkIGVhcmxpZXIs IE9EVSByb2xlIGlzIG9ubHkgaW1wb3J0YW50IG9uDQo+IHRoZSBPRFUNCj4gPiA+ID4gPiA+IHRl cm1pbmF0aW5nIG5vZGVzIChpLmUuIG9uIGVpdGhlciBzaWRlIG9mIGNvcnJlc3BvbmRpbmcNCj4g bGluaykuIFdoYXQNCj4gPiA+ID4gPiA+IGhhcHBlbnMgb24gdGhlIE9EVSB0cmFuc2l0IG5vZGVz IGFuZCBpdHMgcGxhY2UgaW4gdGhlDQo+IGhpZXJhcmNoeSBvbg0KPiA+ID4gPiA+IHRoZQ0KPiA+ ID4gPiA+ID4gdHJhbnNpdCBub2RlcyBhcmUgb2Ygbm8gaW1wb3J0YW5jZS4gTXkgTE8gY29udGFp bmVyIGNhbiBiZQ0KPiBjYXJyaWVkDQo+ID4gPiA+ID4gPiBieSBzb21lYm9keSBlbHNlJ3MgTE8g Y29udGFpbmVyIGFuZCBjYW4gY2FycnkgbXkgY2xpZW50J3MgTE8NCj4gPiA+ID4gY29udGFpbmVy Lg0KPiA+ID4gPiA+IFRvDQo+ID4gPiA+ID4gPiBzb21lIGV4dGVudCBpdCBpcyBzaW1pbGFyIHRv IE1QTFMgTFNQIHJvbGU6IExTUCBhbHdheXMgaGFzIGENCj4gcm9sZQ0KPiA+ID4gPiA+IChlLmcu DQo+ID4gPiA+ID4gPiBQVyBMU1Agb3IgVEUtIExTUCkgYW5kIGl0IGNvdWxkIGJlIGFueXdoZXJl IGluIE1QTFMgc3RhY2sNCj4gYWxvbmcgaXRzDQo+ID4gPiA+ID4gPiBwYXRoLg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiA+IElnb3INCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj4gPg0KPiA9 M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9DQo+IDMNCj4gRD0zRD0NCj4gPiA9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0QNCj4gPiA+ID4gPiA9M0QN Cj4gPiA+ID4gPiA+DQo+ID0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj4gPiA9M0Q9M0Q9M0Q9M0Q9M0Q9M0QNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoYW5rcw0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEZhdGFpDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogIklnb3IgQnJ5c2tp biIgPElCcnlza2luQGFkdmFvcHRpY2FsLmNvbT4NCj4gPiA+ID4gPiA+IFRvOiA8Y3VydGlzQG9j Y25jLmNvbT4NCj4gPiA+ID4gPiA+IENjOiAiSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIu bmV0PjsgIlNuaWdkaG8gQmFyZGFsYWkiDQo+ID4gPiA+ID4gPiA8U0JhcmRhbGFpQGluZmluZXJh LmNvbT47ICJGYXRhaSBaaGFuZyINCj4gPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT47DQo+ID4gPiA+ ID4gPiAiTG91IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+OyA8Y2NhbXBAaWV0Zi5vcmc+Ow0K PiA+ID4gPiA+ID4gPGRyYWZ0LWlldGYtY2NhbXAtDQo+ID4gPiA+ID4gZ21wbHMtDQo+ID4gPiA+ ID4gPiBnNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4NCj4gPiA+ID4gPiA+IFNlbnQ6IFdl ZG5lc2RheSwgSnVseSAxNCwgMjAxMCAxMDozNiBQTQ0KPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6 IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiA+ ID4gZnJhbWV3b3JrLQ0KPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IEN1cnRpcywNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGFua3Mg Zm9yIHlvdXIgY29tbWVudC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJIGFncmVlIHRoYXQg dGhlcmUgc2hvdWxkIGJlIG11bHRpcGxlIE9UTiBzcGVjaWZpYyBlbmNvZGluZw0KPiB0eXBlcw0K PiA+ID4gPiA+ID4gaW50cm9kdWNlZC4gQnV0IElNTyB0aGV5IHNob3VsZCBpbmRpY2F0ZSB0aGUg bGluaydzIG11eA0KPiA+ID4gPiBjYXBhYmlsaXRpZXMNCj4gPiA+ID4gPiA+IHJhdGhlciB0aGFu IHRoZSBsaW5rJ3Mgcm9sZSAoaS5lLiBsZXZlbCBpbiB0aGUgT1ROIGhpZXJhcmNoeToNCj4gTE8s DQo+ID4gPiA+ID4gPiBITywgU0hPLCBldGMuKS4gVGhlIGxpbmsncyByb2xlIG9yIHJvbGVzIElN TyBzaG91bGQgYmUNCj4gaW5kaWNhdGVkDQo+ID4gPiA+ID4gPiB3aXRoIGEgc2VwYXJhdGUgc3dp dGNoY2Fwcy4gSSBjYW4gZ2l2ZSB5b3Ugc2V2ZXJhbCByZWFzb25zOg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IDEuIExpbmtzIHdpdGggdGhlIHNhbWUgbXV4IGNhcGFiaWxpdGllcyBtYXkgaGF2 ZSBkaWZmZXJlbnQNCj4gcm9sZXM7DQo+ID4gPiA+IDIuDQo+ID4gPiA+ID4gPiBMaW5rIG1heSBh ZHZlcnRpc2Ugc2V2ZXJhbCByb2xlcyAoZS5nLiBITyBhbmQgU0hPKSB3aXRoDQo+IGRpZmZlcmVu dA0KPiA+ID4gPiA+ID4gbXV4LmNhcGFiaWxpdGllcyBwZXIgcm9sZTsgMy4gTGluaydzIHJvbGUg YW5kIG11eC4NCj4gY2FwYWJpbGl0aWVzIGNhbg0KPiA+ID4gPiA+IGJlDQo+ID4gPiA+ID4gPiBh ZHZlcnRpc2VkIHdpdGggSVNDRHMgYXMgZGVmaW5lZCBpbiBSRkM0MjAyIChubyBPVE4tc3R5bGUN Cj4gSVNDRCBpcw0KPiA+ID4gPiA+ID4gcmVxdWlyZWQpOyA0LiBUaGUgY29tYmluYXRpb24gb2Yg c3dpY3RoY2FwcyBhbmQgZW5jb2RpbmcNCj4gPiA+ID4gPiA+IHR5cGUNCj4gd2lsbA0KPiA+ID4g PiA+IGxvb2sNCj4gPiA+ID4gPiA+IHRvIENQIGFzIGEgc2VwYXJhdGUgbGF5ZXIsIHdoaWNoIGlz IGV4YWN0bHkgaG93IElUVSBtb2RlbHMNCj4gT1RODQo+ID4gPiA+ID4gPiBoaWVyYXJjaGllcyBp biBhbGwgYXNwZWN0cyBidXQgcm91dGluZyAoIT8pIDUuIElmIHRoZQ0KPiBvcGVyYXRvcg0KPiA+ ID4gPiB3b3VsZA0KPiA+ID4gPiA+ID4gd2FudCB0byBjb25zdHJhaW4gdGhlIHJvdXRpbmcgb2Yg T1ROIGNvbm5lY3Rpb25zIHRvIHByZS0NCj4gY29uZmlndXJlZA0KPiA+ID4gPiA+ID4gdG9wb2xv Z3kgd2l0aCBhIHNwZWNpZmljIHJvbGUgKGUuZy4gY29uc3RyYWluIGFsbCBPRFVzIGl0DQo+IHNl bGxzIHRvDQo+ID4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiBjbGllbnRzIHRvIG9uZSBvciBtb3Jl IHByZS1jb25maWd1cmVkIExPIHRvcG9sb2dpZXMpLCB0aGlzDQo+IHdvdWxkIGJlDQo+ID4gPiA+ ID4gPiBwb3NzaWJsZSB0byBkbyBpbiBhIHRlY2hub2xvZ3kgaW5kZXBlbmRlbnQgd2F5LiBTdXBw b3NlIGFuDQo+IGluc3RhbmNlDQo+ID4gPiA+ID4gb2YNCj4gPiA+ID4gPiA+IEdNUExTIENQIG1h bmFnZXMgV0RNIGFuZCBPVE4gTkVzLiBUaGVuIHNlcGFyYXRpb24gb2YgTE8gZnJvbQ0KPiBITyBP VE4NCj4gPiA+ID4gPiA+IGxpbmtzIHdpbGwgYmUgbm8gZGlmZmVyZW50IGZyb20gdGhlIHNlcGFy YXRpb24gb2YgV0RNIGxpbmtzDQo+IGZyb20NCj4gPiA+ID4gPiBPVFVzLg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiA+IElnb3INCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogY3Vy dGlzQG9jY25jLmNvbSBbbWFpbHRvOmN1cnRpc0BvY2NuYy5jb21dDQo+ID4gPiA+ID4gPiBTZW50 OiBUdWVzZGF5LCBKdWx5IDEzLCAyMDEwIDY6MjQgUE0NCj4gPiA+ID4gPiA+IFRvOiBJZ29yIEJy eXNraW4NCj4gPiA+ID4gPiA+IENjOiBKb2huIEUgRHJha2U7IFNuaWdkaG8gQmFyZGFsYWk7IEZh dGFpIFpoYW5nOyBMb3UgQmVyZ2VyOw0KPiA+ID4gPiA+ID4gY2NhbXBAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4gZnJhbWV3b3JrQHRvb2xzLmlldGYub3Jn DQo+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4gPiBmcmFtZXdvcmstDQo+ID4gPiA+ID4gPiAwMS50 eHQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSW4gbWVzc2FnZSA8MDUy QzY3QjRFRDU1OEQ0MUJCREVBN0NBOUZDNkRDREM1M0MwRDFFMUZFQGF0bC0NCj4gc3J2LQ0KPiA+ ID4gPiA+ID4gZXhnZW4uYXRsLmFkdmFvcHRpY2FsLmNvbT4NCj4gPiA+ID4gPiA+IElnb3IgQnJ5 c2tpbiB3cml0ZXM6DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEkgdGhpbmsgT1ROIGxp bmtzIHJlcXVpcmUgbW9yZSB0aGFuIG9uZSBzd2l0Y2hjYXBzOiBhcw0KPiA+ID4gPiA+ID4gPiBt YW55DQo+IGFzDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gZGVwdGggb2YgdGhlIGRlZXBlc3Qg cG9zc2libGUgT1ROIERQIGhpZXJhcmNoeSwgZm9yIGV4YW1wbGU6DQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+IHR5cGVkZWYgZW51bQ0KPiA+ID4gPiA+ID4gPiB7DQo+ID4gPiA+ID4gPiA+ ICAgIExTUFN3aXRjaFR5cGVfVW5rbm93biA9M0QwICAgICAgICAgICAgLyogVW5rbm93biAqLw0K PiA+ID4gPiA+ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfUFNDXzEgPTNEMSAgICAgICAgICAgIC8q IFBTQy0xICovDQo+ID4gPiA+ID4gPiA+ICAgICwgTFNQU3dpdGNoVHlwZV9QU0NfMiA9M0QyICAg ICAgICAgICAgLyogUFNDLTIgKi8NCj4gPiA+ID4gPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX1BT Q18zID0zRDMgICAgICAgICAgICAvKiBQU0MtMyAqLw0KPiA+ID4gPiA+ID4gPiAgICAsIExTUFN3 aXRjaFR5cGVfUFNDXzQgPTNENCAgICAgICAgICAgIC8qIFBTQy00ICovDQo+ID4gPiA+ID4gPiA+ ICAgICwgTFNQU3dpdGNoVHlwZV9MMlNDICA9M0Q1MCAgICAgICAgICAgLyogTDJTQyAqLw0KPiA+ ID4gPiA+ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfVERNICAgPTNEMTAwICAgICAgICAgIC8qIFRE TSAqLw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAvKioqKiovDQo+ID4gPiA+ID4gPiA+ ICAgICwgTFNQU3dpdGNoVHlwZV9PVE5fTE89M0QxMjQgICAvKiBPVE4gbG93IG9yZGVyICovDQo+ ID4gPiA+ID4gPiA+ICAgICwgTFNQU3dpdGNoVHlwZV9PVE5fSE89M0QxMjUgICAvKiBPVE4gaGln aCBvcmRlciAqLw0KPiA+ID4gPiA+ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfT1ROX1NITz0zRDEy NiAgLyogT1ROIHN1cGVyIGhpZ2ggb3JkZXINCj4gKi8NCj4gPiA+ID4gLyoqKioqLw0KPiA+ID4g PiA+ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfTFNDICAgPTNEMTUwICAgICAgICAgIC8qIExTQyAq Lw0KPiA+ID4gPiA+ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfRlNDICAgPTNEMjAwICAgICAgICAg IC8qIEZTQyAqLw0KPiA+ID4gPiA+ID4gPiB9ZV9MU1BTd2l0Y2hUeXBlOw0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJdCB3b3VsZCBiZSBiZXR0ZXIgSU1ITyB0byBrZWVw IHRoZSBTd2l0Y2ggVHlwZSBhcyBURE0gYW5kDQo+IG1ha2UgdGhlDQo+ID4gPiA+ID4gPiBFbmNv ZGluZyBUeXBlIE9UTl9MTywgT1ROX0hPIG9yIE9UTl9TSE8uDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gVGhpcyB3b3VsZCByZXBsYWNlIHRoZSAyMDAwNiBPVE4gRW5jb2RpbmcgVHlwZSBmb3Ig Ry43MDkNCj4gRGlnaXRhbA0KPiA+ID4gPiA+ID4gUGF0aCBsYXllciBhbmQgRy43MDkgT3B0aWNh bCBDaGFubmVsIGxheWVyIGZvciAyMDA5IE9UTiwNCj4gd2hpY2ggaGFkDQo+ID4gPiA+ID4gPiBp biB0dXJuIHJlcGxhY2VkIHRoZSBFbmNvZGluZyBUeXBlIG9mICJEaWdpdGFsIFdyYXBwZXIiIGEN Cj4gbG9uZyB0aW1lDQo+ID4gPiA+IGFnby4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBSZXBs YWNpbmcgdGhlIEVuY29kaW5nIFR5cGUgd291bGQgaW5zdXJlIHRoYXQgYW55IExTUiB0aGF0DQo+ IGRpZCBub3QNCj4gPiA+ID4gPiA+IHVuZGVyc3RhbmQgd2hhdCB0aGUgVFMgdHlwZSBtZWFudCBk aWQgbm90IHRyeSB0byBtdWx0aXBsZXgNCj4gaXRzIExPDQo+ID4gPiA+ID4gPiBPRFUgYXQgVFMg Z3JhbnVsYXJpdHkgMi41IG9udG8gYSBITyBPRFUgdGhhdCBoYWQgYWxyYWVkeQ0KPiBjb21taXRl ZA0KPiA+ID4gPiB0bw0KPiA+ID4gPiA+IHVzaW5nDQo+ID4gPiA+ID4gPiBhIDEuMjUgVFMgZ3Jh bnVsYXJpdHkgZm9yIGFub3RoZXIgTE8gT0RVLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEl0 IGNvdWxkIGFsc28gYmUgc3RhdGVkIHRoYXQgaWYgYW4gTFNSIGFkdmVydGlzZXMgT1ROX0xPLA0K PiBPVE5fSE8gb3INCj4gPiA+ID4gPiA+IE9UTl9TSE8gRkEsIGFuZCBhbHNvIGFkdmVydGlzZXMg Ry43MDkgRGlnaXRhbCBQYXRoIEZBLCB0aGVuDQo+IHRoZQ0KPiA+ID4gPiA+IGxhdHRlcg0KPiA+ ID4gPiA+ID4gaXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgYW5kIHNob3VsZCBiZSBpZ25v cmVkIGlmDQo+IE9UTl9MTywNCj4gPiA+ID4gPiA+IE9UTl9ITyBvciBPVE5fU0hPIGlzIHVuZGVy c3Rvb2QuICBJZiB0aGUgTFNSIGNvbW1pdHMgdG8gMS4yNQ0KPiBUUw0KPiA+ID4gPiA+ID4gZ3Jh bnVsYXJpdHksIHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgRy43MDkgRGlnaXRhbCBQYXRoIEZBDQo+ ID4gPiA+ID4gPiBjYW4NCj4gYmUNCj4gPiA+ID4gd2l0aGRyYXduLg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IFRoZSBFbmNvZGluZyB0eXBlIHdvdWxkIGJlIHRoZSBsb3dlciBlbmNvZGluZyBh dCBlYWNoIGVuZCBvZg0KPiB0aGUNCj4gPiA+ID4gTFNQDQo+ID4gPiA+ID4gPiByZWdhcmRsZXNz IG9mIHdoYXQgZ29lcyBvbiBpbiB0aGUgbWlkZGxlIHNpbmNlIHRoYXQNCj4gZGV0ZXJtaW5lcyB3 aGF0DQo+ID4gPiA+ID4gY2FuDQo+ID4gPiA+ID4gPiBiZSB3cmFwcGVkIGluc2lkZSBpdC4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGb3IgZXhhbXBsZToNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBPVFUzDQo+ID4gPiA+ID4gPiAgICAgICAgICAg ICAgIE9UVTIgICAgICBPRFVrPTNEMyAtLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gICAgT1RV MSAgICAgICBPRFVrPTNEMiAtLSBPRFVqPTNEMg0KPiA+ID4gPiA+ID4gICAgT0RVaz0zRDEgLS0t IE9EVWo9M0QxIC0tDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhpcyBpcyBPSyBhbmQgdGhl IG91dGVyIE9EVWs9M0QxIGNvdWxkIGhvbGQgYSBPRFVqPTNEMCBvcg0KPiBPRFVqPTNEZj0NCj4g PiBsZXgNCj4gPiA+ID4gPiA+IGV2ZW4gdGhvdWdoIHRoZSBPRFVrPTNEMiBhdCB0aGUgbmV4dCBo b3AgY291bGQgbm90IGRpcmVjdGx5DQo+IGNvbnRhaW4NCj4gPiA+ID4gYW4gT0RVMC4NCj4gPiA+ ID4gPiA+IElmIHRoZSBTSE8gRW5jb2RpbmcgVHlwZSBpcyB1c2VkLCB0aGVuIGl0IGluZGljYXRl cyB0aGF0IHR3bw0KPiBsZXZlbHMNCj4gPiA+ID4gPiBvZg0KPiA+ID4gPiA+ID4gbXVsdGlwbGV4 aW5nIGNvdWxkIGJlIHN1cHBvcnRlZCBhdCB0aGF0IHN3aXRjaC9MU1IuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gVGhlIG5vbWluYWwgYnl0ZXMvc2VjIHJhdGVzIGNhbiBzdGlsbCBiZSBwcm92 aWRlZC4gIFJGQyA0MzI4DQo+IFN3aXRjaA0KPiA+ID4gPiA+ID4gVHlwZXMgY3VycmVudGx5IGRv bid0IGluY2x1ZGUgYW4gT0RVaiBvciBPRFVrIGRpc3RpbmN0aW9uDQo+ID4gPiA+ID4gPiBidXQN Cj4gaWYNCj4gPiA+ID4gPiA+IEVuY29kaW5nIFR5cGUgaW5kaWNhdGVkIExPIG9yIEhPLCB0aGF0 IG1heSBub3QgYmUgbmVlZGVkLg0KPiBBbG9uZw0KPiA+ID4gPiA+ID4gd2l0aCB0aGUgbmV3IEVu Y29kaW5nIFR5cGUgbmV3IFNpZ25hbCBUeXBlcyBmb3IgT0RVMCwgT0RVNCwNCj4gYW5kDQo+ID4g PiA+ID4gPiBPRFUtZmxleCwgYW5kIE9EVTJlLCBjYW4gYmUgYWRkZWQuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gYnR3IC0gdGhlIDEuMjUgb3IgMi41IFRTIHR5cGUgaXMgYSB2YWx1YWJsZSBh ZGRpdGlvbiBidXQgSSdtDQo+IG5vdA0KPiA+ID4gPiA+IGNsZWFyDQo+ID4gPiA+ID4gPiBob3cg aW4gYW4gRkEgaXQgY2FuIGJlIGluZGljYXRlZCB0aGF0IGVpdGhlciB0eXBlIGlzDQo+IGN1cnJl bnRseQ0KPiA+ID4gPiA+ID4gYXZhaWxhYmxlIChORSBjYXBhYmxlIG9mIGJvdGggYW5kIGhhc24n dCBjb21taXR0ZWQgdG8gZWl0aGVyDQo+IG9uZQ0KPiA+ID4gPiA+IHlldCkuDQo+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gQlRXLSBNYXliZSBJJ20gbWlzc2luZyBzb21ldGhpbmcgYnV0IHRoZSBu dW1iZXIgb2YgbWVzc2FnZXMNCj4gb24gdGhpcw0KPiA+ID4gPiA+ID4gd291bGQgaW5kaWNhdGUg YSBodWdlIGNvbnRyb3ZlcnN5IGFuZCBJJ20gbm90IGdldHRpbmcgaXQNCj4gKG90aGVyDQo+ID4g PiA+IHRoYW4NCj4gPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiBzdHJvbmcgcHJlZmVyZW5jZSB0byBy ZWx5IG9uIGJ5dGVzL3NlYyBvciBvbiBlbnVtZXJhdGVkIHR5cGUNCj4gPiA+ID4gZmllbGRzKS4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBkcmFmdC1iY2NnLWNjYW1wLW90bi1nNzA5LWluZm8t bW9kZWwtMDEgaXMgbmljZSB3b3JrLiAgSSdtDQo+IG5vdCBzdXJlDQo+ID4gPiA+ID4gaWYNCj4g PiA+ID4gPiA+IHRoZSBpbnRlbnQgaXMgdG8gbWVyZ2Ugd2l0aCBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLWc3MDktDQo+IGZyYW1ld29yaywNCj4gPiA+ID4gPiA+IG9yIG90aGVyIGludGVudC4gIENv dWxkIHNvbWVvbmUgKGVpdGhlciBkcmFmdCkgY29uY2lzZWx5DQo+IHN1bW1hcml6ZQ0KPiA+ID4g PiA+ID4gdGhlIG11bHRpcGxleGluZyByZXN0cmljdGlvbnMgaW4gb25lIHBsYWNlLCBpbmNsdWRp bmcNCj4gcmVzdHJpY3Rpb25zDQo+ID4gPiA+ID4gPiBvbiBudW1iZXIgb2YgbXVsdGlwbGV4aW5n IGxheWVycyBhdCBvbmUgTFNSLiAgVGhhdCBtaWdodA0KPiBoZWxwLg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IEN1cnRpcw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+IEZyb206IEpvaG4gRSBE cmFrZSBbbWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldF0NCj4gPiA+ID4gPiA+ID4gU2VudDogVGh1 cnNkYXksIEp1bHkgMDgsIDIwMTAgMTo1OSBQTQ0KPiA+ID4gPiA+ID4gPiBUbzogSWdvciBCcnlz a2luOyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91DQo+ID4gPiA+ID4gPiA+IEJl cmdlcg0KPiA+ID4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7DQo+ID4gPiA+ID4gPiA+IGRy YWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+ ID4gPiA+ID4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBvbg0KPiA+ID4gPiA+ID4gPiBk cmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dA0KPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiBXaGF0IGRvIHlvdSBtZWFuIGJ5ICJkaWZmZXJlbnQgc3dpdGNoY2Fw cyI/DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gPiA+ID4gPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86Y2NhbXAtDQo+IGJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+ID4gPiA+ID4gQmVoYWxm IE9mIElnb3IgQnJ5c2tpbg0KPiA+ID4gPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4 LCAyMDEwIDEwOjUzIEFNDQo+ID4gPiA+ID4gPiA+ID4gVG86IFNuaWdkaG8gQmFyZGFsYWk7IEZh dGFpIFpoYW5nOyBMb3UgQmVyZ2VyDQo+ID4gPiA+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3Jn Ow0KPiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtA dG9vbHMuaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21t ZW50IG9uDQo+ID4gPiA+ID4gPiA+ID4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1l d29yay0NCj4gPiA+ID4gPiA+ID4gPiAwMS50eHQNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+IFNuaWdkaG8sDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiA+ID1EOCAgSSB0aGluayB3ZSBuZWVkIHRvIHNvcnQgb3V0IHRoZSBpc3N1ZXMgd2l0aCB0aGUN Cj4gZnJhbWV3b3JrDQo+ID4gPiA+ID4gPiA+ID4gZG9jdW1lbnQgYmVmb3JlIHdlIGNhbiBlbWJh cmsgb24gYW55IHByb3Bvc2FscyB0byB0aGUNCj4gcHJvYmxlbS4NCj4gPiA+ID4gSQ0KPiA+ID4g PiA+IGFtDQo+ID4gPiA+ID4gPiA+ID4gc3RpbGwgbm90IGNsZWFyIHdoeSBkbyB3ZSBoYXZlIHRv IGRldmlhdGUgZnJvbSB0aGUNCj4gZ2VuZXJhbA0KPiA+ID4gPiA+IGFwcHJvYWNoDQo+ID4gPiA+ ID4gPiA+ID4gdGhhdCBoYXMgYmVlbiBlc3RhYmxpc2hlZCBpbiBSRkMgNDIwMi4NCj4gPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g PiBJQj4+IEFncmVlIGFic29sdXRlbHkuIEdNUExTIGlzIGluaGVyZW50bHkgbXVsdGktbGF5ZXIN Cj4gY29udHJvbA0KPiA+ID4gPiA+ID4gPiA+IElCPj4gcGxhbmUsIGFuZA0KPiA+ID4gPiA+ID4g PiA+IGl0IGlzIGhpZ2hseSBkZXNpcmFibGUgdG8gYWRoZXJlIHRvIHRoZSBsYXllcg0KPiA+ID4g PiA+ID4gPiA+IGluZGVwZW5kZW50DQo+ID4gPiA+ID4gcGFyYWRpZ20NCj4gPiA+ID4gPiA+ID4g PiBvZiBhZHZlcnRpc2luZyBvZiBURSBsaW5rcywgYW5kIHRoZXJlIGlzIG5vIHJlYXNvbiB0bw0K PiBpbnZlbnQgYW4NCj4gPiA+ID4gPiBPVE4NCj4gPiA+ID4gPiA+ID4gPiBzcGVjaWZpYyBJU0NE LiBUaGUgY29tYmluYXRpb24gb2YgU3dpdGNoaW5nIENhcGFiaWxpdHkNCj4gYW5kDQo+ID4gPiA+ ID4gRW5jb2RpbmcNCj4gPiA+ID4gPiA+ID4gPiB0eXBlIG9mIFJGQzQyMDIgSVNDRCBhbGxvd3Mg Zm9yIHNwZWNpZnlpbmcgYm90aA0KPiBtdWx0aXBsZXhpbmcNCj4gPiA+ID4gPiA+ID4gPiBjYXBh YmlsaXRpZXMgYW5kIE9UTiBsYXllciAoTE8sIEhPLCBTSE8pIG9mIGFuIE9UTiBsaW5rLA0KPiBh bmQsDQo+ID4gPiA+IGlmDQo+ID4gPiA+ID4gPiA+ID4gdGhpcyBub3Qgc3VmZmljaWVudCwgeW91 IGhhdmUgYW5vdGhlciByZXNlcnZlZCAxNiBiaXRzLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID5BZGRpdGlvbmFsbHks IEkgZG8gbm90IHNlZSBhbnkgcmVhc29uIHRvIGFkdmVydGlzZSBhDQo+ID4gPiA+ID4gPiA+ID4g Pm5ldyBURS1saW5rDQo+ID4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4gPiA+IHJlcHJlc2VudCA+ dGhlIGxvdy1vcmRlciBPRFVqIGJhbmR3aWR0aCB3aXRoaW4gdGhlIGhpZ2gtDQo+IG9yZGVyDQo+ ID4gPiA+ID4gPiBjb250YWluZXJzLg0KPiA+ID4gPiA+ID4gPiA+IFRoaXMgaXMgc2ltcGx5ID5i bG93aW5nIHVwIHRoZSBzb2x1dGlvbiB0byBhIHZlcnkgc2ltcGxlDQo+ID4gPiA+IHByb2JsZW0u DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4gSUI+PiBIZXJlIEkgZGlzYWdyZWUuIEluIG9yZGVyIHRvIGdpdmUgYSB1c2Vy DQo+ID4gPiA+ID4gPiA+ID4gSUI+PiBwb3NzaWJpbGl0eQ0KPiB0bw0KPiA+ID4gPiA+IGNyZWF0 ZQ0KPiA+ID4gPiA+ID4gPiA+IElCPj4gT1RODQo+ID4gPiA+ID4gPiA+ID4gaGllcmFyY2hpZXMg YW5kIGNvbnN0cmFpbiBMTyBjb25uZWN0aW9ucyB0byBITw0KPiBjb250YWluZXJzLCBvbmUNCj4g PiA+ID4gPiA+IG5lZWRzDQo+ID4gPiA+ID4gPiA+ID4gdG8gYWR2ZXJ0aXNlIE9UTiBsaW5rcyB3 aXRoIGRpZmZlcmVudCBzd2l0Y2hjYXBzLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiA+IElnb3INCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBSZWdhcmRzDQo+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBTbmlnZGhvDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogRmF0YWkgWmhh bmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gPiA+ID4gU2VudDog V2VkbmVzZGF5LCBKdWx5IDA3LCAyMDEwIDY6MzMgUE0NCj4gPiA+ID4gPiA+ID4gPiBUbzogU25p Z2RobyBCYXJkYWxhaTsgTG91IEJlcmdlcg0KPiA+ID4gPiA+ID4gPiA+IENjOiBjY2FtcEBpZXRm Lm9yZzsNCj4gPiA+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3 b3JrQHRvb2xzLmlldGYub3JnDQo+ID4gPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0g Q29tbWVudCBvbg0KPiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1m cmFtZXdvcmstDQo+ID4gPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gSGkgU25pZ2RobyBh bmQgTG91LA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+IFllcywgd2UgaGF2ZSBsb3RzIG9mIG9mZi1saW5lIGRpc2N1c3Np b25zIGFtb25nIGF1dGhvcnMNCj4gYW5kDQo+ID4gPiA+ID4gPiA+ID4gb3RoZXIgaW50ZXJlc3Rl ZCBleHBlcnRzLCBhbmQgd2UgdGhpbmsgdGhlIHByb3Bvc2FsDQo+IGRlc2NyaWJlZA0KPiA+ID4g PiBpbg0KPiA+ID4gPiA+ICJkcmFmdC0NCj4gPiA+ID4gPiA+ID4gPiBjZWNjYXJlbGxpLWNjYW1w LWdtcGxzLW9zcGYtZzcwOSIgW09TUEYtRW5jb2RpbmddIGRyYWZ0DQo+IGlzIG1vcmUNCj4gPiA+ ID4gPiA+ID4gPiBmZWFzaWJsZSBmb3IgT1ROIG5ldHdvcmtzLg0KPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFRoZSBmcmFt ZXdvcmsgZHJhZnQganVzdCB0ZWxscyB5b3Ugd2hhdCBpbmZvcm1hdGlvbg0KPiBuZWVkZWQgZm9y DQo+ID4gPiA+ID4gPiA+ID4gY29udHJvbCBwbGFuZSwgbm8gbWF0dGVyIGhvdyB5b3UgZW5jb2Rl IHRoZSByb3V0aW5nDQo+ID4gPiA+IGluZm9ybWF0aW9uLg0KPiA+ID4gPiA+ID4gRm9yDQo+ID4g PiA+ID4gPiA+ID4gVERNIG5ldHdvcmtzLCB5b3Uga25vdyB0aGUgcmVzb3VyY2UgaXMgYWxsb2Nh dGVkIGJhc2VkDQo+ID4gPiA+ID4gPiA+ID4gb24NCj4gVFMsDQo+ID4gPiA+IHNvDQo+ID4gPiA+ ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gPiBhdmFpbGFibGUgVFMgc2hvdWxkIGJlIGdldCBvciBp bmR1Y2VkIGJlZm9yZSBjcmVhdGluZw0KPiBjcm9zcy0NCj4gPiA+ID4gPiA+IGNvbm5lY3QuDQo+ ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4gSWYgeW91IGFyZSB0cnlpbmcgdG8gZmluZCBob3cgdG8gZW5jb2RlIHRoZSByb3V0 aW5nDQo+ID4gPiA+IGluZm9ybWF0aW9uLA0KPiA+ID4gPiA+IEkNCj4gPiA+ID4gPiA+ID4gPiB0 aGluayB5b3UgbmVlZCBnbyB0byB0aGUgcm91dGluZyBkcmFmdHMgKGluZm8gbW9kZWwgYW5kDQo+ ID4gPiA+ID4gZW5jb2RpbmcpLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IElmIHlvdSBsb29rIGF0IHRoZSByb3V0aW5n IGRyYWZ0cyAoaW5mbyBtb2RlbCBhbmQNCj4gZW5jb2RpbmcpLA0KPiA+ID4gPiB5b3UNCj4gPiA+ ID4gPiA+ID4gPiB3aWxsIGZpbmQgdGhhdCBvbmUgb2YgeW91ciBzdWdnZXN0aW9ucyBpcyBhZG9w dGVkIChpLmUuLA0KPiBzaW1wbHkNCj4gPiA+ID4gPiA+ID4gPiBhZHZlcnRpemUgdGhlIGF2YWls YWJsZSBudW1iZXIgb2YgT0RVMCwgT0RVMSwgT0RVMiwgLi4uLA0KPiBPRFU0DQo+ID4gPiA+ID4g PiBjb250YWluZXIgaW5zdGFuY2VzKS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBPbmUgbW9yZSB0aGluZyBmb3IgeW91 ciBmaXJzdCBjb21tZW50Og0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gSWYgeW91 IGNyZWF0ZSBhbiBPRFUyIExTUCAodXN1YWxseSBvdmVyIG11bHRpIE9UVTMNCj4gPiA+ID4gPiA+ ID4gPiBsaW5rcykNCj4gYXMgRkENCj4gPiA+ID4gPiBmb3INCj4gPiA+ID4gPiA+ID4gPiBPRFUx LCB5b3UgaGF2ZSB0byBhZHZlcnRpc2UgYSBuZXcgVEUgbGluayBvciBwdXQgdGhpcyBGQQ0KPiBh cyBhDQo+ID4gPiA+ID4gPiA+ID4gY29tcG9uZW50IGxpbmsgb2YgYW4gZXhpc3RpbmcgVEUgbGlu ayAobGlrZSBSRkM0MjA2YmlzKS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBCZXN0IFJlZ2FyZHMNCj4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+IEZhdGFpDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEZyb206ICJTbmlnZGhvIEJhcmRhbGFpIiA8U0JhcmRhbGFp QGluZmluZXJhLmNvbQ0KPiA+ID4gPiA+ID4gPiA+IDxtYWlsdG86U0JhcmRhbGFpQGluZmluZXJh LmNvbT4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gVG86ICJMb3UgQmVyZ2Vy IiA8bGJlcmdlckBsYWJuLm5ldA0KPiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+ID4NCj4gPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IENjOiA8Y2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4gPjsNCj4gPiA+ID4gPiA+ID4gPiA8ZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy0gZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiA8bWFpbHRv OmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4gPiA+ID4gPiBmcmFtZXdvcmtA dG9vbHMuaWV0Zi5vcmc+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFNlbnQ6 IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCAxMTo0MyBQTQ0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbg0KPiA+ID4gPiA+ID4g PiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstDQo+ID4gPiA+ID4gPiA+ ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBIaSBMb3UNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4gPiBUaGFua3MsIEkgYWxzbyB3b3VsZCBsaWtlIHRvIGhlYXIgYWJvdXQgdGhlIHNh bWUuDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gU25pZ2Robw0KPiA+ID4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiA+ID4gPiA+ID4gPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJu Lm5ldF0NCj4gPiA+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCA4 OjM3IEFNDQo+ID4gPiA+ID4gPiA+ID4gPiBUbzogU25pZ2RobyBCYXJkYWxhaQ0KPiA+ID4gPiA+ ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IDsNCj4g PiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtDQo+ID4gPiA+ID4gPiA+ID4g ZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcgPG1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLQ0K PiBnbXBscy0NCj4gPiA+ID4gPiBnNzA5LQ0KPiA+ID4gPiA+ID4gPiA+IGZyYW1ld29ya0B0b29s cy5pZXRmLm9yZz4NCj4gPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1l bnQgb24NCj4gPiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFt ZXdvcmstDQo+ID4gPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+ID4gU25pZ2RobywNCj4gPiA+ID4gPiA+ID4gPiA+IEkgYmVsaWV2ZSB0aGVyZSBo YXMgYmVlbiBzb21lIG9mZi1saW5lIGRpc2N1c3Npb24gb24NCj4gaG93IHRvDQo+ID4gPiA+ID4g PiBiZXR0ZXINCj4gPiA+ID4gPiA+ID4gPiA+IGFsaWduIHRoZSB3b3JrIHdpdGggNDIwMi4gIFVz ZSBvZiBjb21tb24gYXBwcm9hY2hlcyBpcw0KPiBvZg0KPiA+ID4gPiA+IGNvdXJzZQ0KPiA+ID4g PiA+ID4gPiA+ID4gb25lIG9mIHRoZSBtYWluIG9iamVjdGl2ZXMgb2YgKkMqQ0FNUC4gIEkgbG9v ayBmb3J3YXJkDQo+IHRvDQo+ID4gPiA+ID4gaGVhcmluZw0KPiA+ID4gPiA+ID4gPiA+ID4gZnJv bSB0aGUgZHJhZnQgYW5kIGRpc2N1c3Npb24gY29udHJpYnV0b3JzIG9uIHRoZXJlDQo+IHByb2dy ZXNzDQo+ID4gPiA+ID4gPiA+ID4gPiBvbg0KPiA+ID4gPiA+ID4gdGhpcyBwb2ludC4NCj4gPiA+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBMb3UNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4gPiBPbiA3LzYvMjAxMCAzOjU5IFBNLCBTbmlnZGhvIEJhcmRhbGFpIHdy b3RlOg0KPiA+ID4gPiA+ID4gPiA+ID4+IEhlbGxvLA0KPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4g PiA+ID4gPiA+ID4gPj4gSSBoYXZlIGEgY29tbWVudCBhbmQgYSBxdWVzdGlvbiBvbiBTZWN0aW9u IDMuMS4yLjEuDQo+IFRoaXMNCj4gPiA+ID4gPiBzZWN0aW9uDQo+ID4gPiA+ID4gPiA+ID4gPj4g ZGVzY3JpYmVzIHRoZSBsaW5rLXBhcmFtZXRlcnMgdGhhdCBhcmUgcmVxdWlyZWQgZm9yDQo+IE9U Tg0KPiA+ID4gPiA+IHNlcnZpY2UNCj4gPiA+ID4gPiA+ID4gPiA+PiByb3V0aW5nIHB1cnBvc2Vz Lg0KPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPj4gTXkgY29tbWVudCBpcyBo b3cgYXJlIHdlIGdvaW5nIHRvIGFkdmVydGlzZSB0aGUgbG93LQ0KPiBvcmRlcg0KPiA+ID4gPiA+ ID4gPiA+ID4+IE9EVWogYXZhaWxhYmlsaXR5IHdpdGhpbiBhIGhpZ2hlci1vcmRlciBjb250YWlu ZXIuDQo+ID4gPiA+ID4gPiA+ID4gPj4gRm9yIGV4YW1wbGUsIGNvbnNpZGVyIGFuDQo+ID4gPiA+ ID4gPiA+ID4gPj4gT1RVMyBsaW5rIHdoaWNoIGhhcyAxNiB0aW1lLXNsb3RzIG9mIDIuNUcgZ3Jh bnVsYXJpdHkNCj4gYW5kDQo+ID4gPiA+ID4gPiA+ID4gPj4gdGhlbg0KPiA+ID4gPiA+ID4gd2UN Cj4gPiA+ID4gPiA+ID4gPiA+PiBlc3RhYmxpc2ggYW4gT0RVMiBzZXJ2aWNlIG92ZXIgdGhlIGxp bmsuIEF0IHRoaXMNCj4gPiA+ID4gPiA+ID4gPiA+PiBwb2ludA0KPiBpbg0KPiA+ID4gPiA+ID4g PiA+ID4+IHRpbWUgdGhlIE9UVTMgbGluayBoYXMgMTIgdGltZS1zbG90cyBhdmFpbGFibGUgZm9y DQo+IE9EVTINCj4gPiA+ID4gPiA+ID4gPiA+PiBzZXJ2aWNlcw0KPiA+ID4gPiA+IGFuZA0KPiA+ ID4gPiA+ID4gPiA+ID4+IHVwIHRvIDEyKzQgdGltZS1zbG90cyBhdmFpbGFibGUgZm9yIE9EVTEg c2VydmljZXMgKDQNCj4gT0RVMXMNCj4gPiA+ID4gPiA+ID4gPiA+PiBhcmUgY29udGFpbmVkIG92 ZXIgdGhlIE9EVTIpLiBTbyBpdCBpcyBvYnZpb3VzIGZyb20NCj4gdGhpcw0KPiA+ID4gPiA+ID4g PiA+ID4+IGV4YW1wbGUNCj4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+ID4gPiA+PiB0aGUg bnVtYmVyIG9mIHRpbWUtc2xvdHMgYXZhaWxhYmxlIGlzIGRpZmZlcmVudCBiYXNlZA0KPiBvbiB0 aGUNCj4gPiA+ID4gPiA+IHNpZ25hbC10eXBlIChpLmUuIE9EVTEgYW5kIE9EVTIpLg0KPiA+ID4g PiA+ID4gPiA+ID4+IEhvdyBkbyB3ZSBhZGRyZXNzIHRoaXMgaXNzdWUgYmFzZWQgb24gdGhlIGFw cHJvYWNoDQo+IHNwZWNpZmllZA0KPiA+ID4gPiA+IGluDQo+ID4gPiA+ID4gPiA+ID4gPj4gdGhl DQo+ID4gPiA+ID4gPiA+ID4gZHJhZnQ/DQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ ID4gPiA+PiBNeSBvdGhlciBxdWVzdGlvbiBpcyB3aHkgbm90IHNpbXBseSBhZHZlcnRpemUgdGhl DQo+IGF2YWlsYWJsZQ0KPiA+ID4gPiA+ID4gPiA+ID4+IG51bWJlciBvZiBPRFUwLCBPRFUxLCBP RFUyLCAuLi4sIE9EVTQgY29udGFpbmVyDQo+IGluc3RhbmNlcyBvcg0KPiA+ID4gPiA+IHRoZQ0K PiA+ID4gPiA+ID4gPiA+ID4+IGVxdWl2YWxlbnQgYmFuZHdpZHRoIGluIGJ5dGVzL3NlYyB3aXRo aW4gYSBsaW5rPyBUaGlzDQo+ID4gPiA+ID4gPiA+ID4gPj4gYXBwcm9hY2ggc2VlbXMgdG8gYmUg bW9yZSBpbi1saW5lIHdpdGggdGhlIGdlbmVyYWwNCj4gYXBwcm9hY2gNCj4gPiA+ID4gPiA+ID4g PiA+PiBvdXRsaW5lZCBpbiBSRkMtNDIwMi4gUmVmZXIgdG8NCj4gPiA+ID4gPiA+ID4gPiBzZWN0 aW9uDQo+ID4gPiA+ID4gPiA+ID4gPj4gMy40IGluIFJGQyA0MjAyIGZvciBhbiBleGFtcGxlIHRo YXQgc2hvd3MgbXVsdGlwbGUNCj4gSVNDRHMNCj4gPiA+ID4gPiA+ID4gPiA+PiBiZWluZyBhZHZl cnRpc2VkIHBlciBWQyByYXRlIGZvciBhbiBTREggbGluay4gVGhlDQo+IGFkZGl0aW9uYWwNCj4g PiA+ID4gPiA+ID4gPiA+PiBiZW5lZml0DQo+ID4gPiA+ID4gPiBpcw0KPiA+ID4gPiA+ID4gPiA+ ID4+IHRoYXQgdGhlIGFkdmVydGlzZW1lbnQgaXMgVFMgc2l6ZSBpbmRlcGVuZGVudCBhbmQNCj4g aGVuY2Ugd2lsbA0KPiA+ID4gPiA+ID4gPiA+ID4+IHNpbXBsaWZ5IHRoZSBpbXBsZW1lbnRhdGlv bi4NCj4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IFJlZ2FyZHMNCj4gPiA+ ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IFNuaWdkaG8NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkND QU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w DQoNCg== From jdrake@juniper.net Wed Jul 21 07:46:20 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A943A6BC6 for ; Wed, 21 Jul 2010 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm+Jg+4qxetE for ; Wed, 21 Jul 2010 07:46:16 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 2C2903A6BB7 for ; Wed, 21 Jul 2010 07:46:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTEcIQIlTNSn3fFMLqH71YSLGHBG7vBKL@postini.com; Wed, 21 Jul 2010 07:46:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 21 Jul 2010 07:42:46 -0700 From: John E Drake To: Igor Bryskin , "Ong, Lyndon" , Daniele Ceccarelli , "curtis@occnc.com" , Snigdho Bardalai Date: Wed, 21 Jul 2010 07:42:43 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAWbSJAAAog3yAAAm+/cAACMuqw Message-ID: <5E893DB832F57341992548CDBB33316398448E10B3@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT."<201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 14:46:20 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWdvciBCcnlza2luIFtt YWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg MjEsIDIwMTAgNjo1MSBBTQ0KPiBUbzogT25nLCBMeW5kb247IERhbmllbGUgQ2VjY2FyZWxsaTsg Sm9obiBFIERyYWtlOyBjdXJ0aXNAb2NjbmMuY29tOw0KPiBTbmlnZGhvIEJhcmRhbGFpDQo+IENj OiBjY2FtcEBpZXRmLm9yZzsgU25pZ2RobyBCYXJkYWxhaQ0KPiBTdWJqZWN0OiBSRTogW0NDQU1Q XSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstDQo+IDAx LnR4dA0KPg0KPiBXZSBuZWVkIHRvIGRpc2N1c3MgdGhpcyBmYWNlIHRvIGZhY2UuIFRoZSBiaWdn ZXN0IGRpc2FncmVlbWVudHMgd2l0aA0KPiBEYW5pZWxlIGFyZToNCj4gMSkgSSBkb24ndCBiZWxp ZXZlIHRoYXQgZmxhdCByb3V0aW5nIG1vZGVsIG9mIGEgbXVsdGktbGF5ZXIgT1ROIG5ldHdvcmsN Cj4gaXMgY29ycmVjdC4NCg0KSkQ6ICBEaXNhZ3JlZQ0KDQo+IDIpIEkgdGhpbmsgZWFjaCBPVE4g cm9sZSBkZWZpbmVzIGEgc2VwYXJhdGUgdG9wb2xvZ3kgb2YgT1ROIGxpbmtzLCBhbmQNCj4gdGhl cmUgaXMgYSBuZWVkIHRvIGJlIGFibGUgdG8gY29uc3RyYWluIHRoZSByb3V0aW5nIG9mIGEgZ2l2 ZW4gT1RODQo+IGNvbm5lY3Rpb24gdG8gb25lIG9yIG1vcmUgKGJ1dCBub3QgbmVjZXNzYXJpbHkg YWxsKSBzdWNoIHRvcG9sb2dpZXM7DQoNCkpEOiAgRGlzYWdyZWUNCg0KPiAzKSBUaGVyZSBpcyBh biBpc3N1ZSBpbiB0aGUgY3VycmVudCBkZWZpbml0aW9ucyBvZiBHTVBMUyBPU1BGDQo+IGV4dGVu c2lvbnMgKFJGQyA0MjAzKSwgd2hpY2ggZG9lcyBhbGxvdyB0byBzcGVjaWZ5IG11bHRpcGxlIElT Q0RzIGJ1dA0KPiBkb2VzIG5vdCBndWlkZSBhcyB0byBob3cgdGhlIGF2YWlsYWJsZSBiYW5kd2lk dGggb24gdGhlIGxpbmsgaXMNCj4gcGFydGl0aW9uZWQgYmV0d2VlbiBJU0NEcy4gVGhpcyBpcyBh IGdlbmVyaWMgaXNzdWUgYW5kIHNob3VsZCBiZQ0KPiByZXNvbHZlZCBpbiBhIGdlbmVyaWMgd2F5 Ow0KDQpKRDogIFBhcnRpdGlvbmluZyBpcyB0aGUgd3JvbmcgbW9kZWwuICBJZiB3ZSBnbyB0aGlz IHJvdXRlIHdlIHNob3VsZCBhZHZlcnRpc2UgYSBzZXBhcmF0ZSBiYW5kd2lkdGggZm9yIGVhY2gu ICBUaGlzIGlzIHRoZSBtb3N0IGZsZXhpYmxlIGFuZCBnZW5lcmFsIG1vZGVsLg0KDQo+IDQpIE90 aGVyIHRoYW4gKDMpIHdlIGRvbid0IG5lZWQgYW55IE9UTiBvciBURE0gc3BlY2lmaWMgQ1AgbWFj aGluZXJ5DQo+IGZvciBURSBhbmQgcm91dGluZyBpbiBPVE4gbmV0d29ya3MuIFVubGVzcyB3ZSBz ZWUgc3Ryb25nIHJlYXNvbnMgdG8gdGhlDQo+IGNvbnRyYXJ5IHdlIHNob3VsZCBub3QgaW52ZW50 IHN1Y2ggbWFjaGluZXJ5Lg0KDQpKRDogIEFncmVlDQoNCj4NCj4gQ2hlZXJzLA0KPiBJZ29yDQo+ DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9uZywgTHluZG9uIFttYWls dG86THlvbmdAQ2llbmEuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjEsIDIwMTAgODoz MCBBTQ0KPiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBJZ29yIEJyeXNraW47IEpvaG4gRSBEcmFr ZTsgY3VydGlzQG9jY25jLmNvbTsNCj4gU25pZ2RobyBCYXJkYWxhaQ0KPiBDYzogY2NhbXBAaWV0 Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWkNCj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCBv biBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLQ0KPiAwMS50eHQNCj4NCj4g SSBzdXBwb3J0IHRoaXMgYXMgd2VsbCwgb2YgY291cnNlLiAgV2hldGhlciB0aGlzIGlzIGEgdGVj aG5vbG9neS0NCj4gc3BlY2lmaWMgZXh0ZW5zaW9uIG9mIHRoZSBJU0NEIGZvcm1hdCBvciBhIHNl cGFyYXRlIHN1Yi1UTFYgaXMgYQ0KPiBkZXRhaWwsIGhvd2V2ZXIgYXMgRGFuaWVsZSBwb2ludHMg b3V0IG1hbnkgb2YgdGhlIHNhbWUgY29uc2lkZXJhdGlvbnMNCj4gYXBwbHkgdG8gYm90aCBPVE4g YW5kIFNPTkVUL1NESC4NCj4NCj4gTHluZG9uDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgRGFuaWVsZSBDZWNjYXJlbGxpDQo+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAyMSwgMjAxMCAxMjo0OSBBTQ0KPiBUbzogSWdvciBCcnlza2lu OyBKb2huIEUgRHJha2U7IGN1cnRpc0BvY2NuYy5jb207IFNuaWdkaG8gQmFyZGFsYWkNCj4gQ2M6 IGNjYW1wQGlldGYub3JnOyBTbmlnZGhvIEJhcmRhbGFpDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBd IENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0NCj4gMDEu dHh0DQo+DQo+IElnb3IsDQo+DQo+IEluIG90aGVyIHdvcmRzIGl0IGNvdWxkIGJlIHBvc3NpYmxl IHRvIGRlZmluZSAzIFN3aXRjaGluZyBDYXAgKExPLCBITw0KPiBhbmQgU0hPKSBhbmQgcHV0IHdo YXQgd2UgZGVmaW5lZCBpbiB0aGUgZW5jb2RpbmcgZHJhZnQgaW50byB0aGUNCj4gU3dpdGNoaW5n IENhcGFiaWxpdHktc3BlY2lmaWMgaW5mb3JtYXRpb24gb2YgdGhlIElTQ0QuDQo+DQo+IFNvbWV0 aGluZyBsaWtlIHRoaXM6DQo+DQo+ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gICAgfCBTd2l0Y2hpbmcgQ2FwIHwgICBFbmNvZGluZyAgICB8ICAgICAgICAgICBSZXNl cnZlZCAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICAg IE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDAgICAgICAgICAgICAgIHwNCj4gICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9y aXR5IDEgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAg ICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDIgICAgICAgICAgICAgIHwNCj4gICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHBy aW9yaXR5IDMgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAg ICAgICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDQgICAgICAgICAgICAgIHwNCj4g ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0 IHByaW9yaXR5IDUgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAg ICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IDYgICAgICAgICAgICAgIHwN Cj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRo IGF0IHByaW9yaXR5IDcgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsgLS0NCj4gLS0tU3dpdGNoaW5nIENhcGFiaWxpdHktc3BlY2lmaWMgaW5mb3JtYXRpb24NCj4g ICAgfDB8MXwyfDN8NHw1fDZ8N3wgIFQgIHwgICAgICAgICB8ICAgICAgICAgIFJlc2VydmVkICAg ICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAg ICAgICAgICAgIEJhbmR3aWR0aCBAIFAwICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFAxICAg ICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAg ICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFAyICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFAz ICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgU2lnbmFsIFR5cGUgIHxG fCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFA0ICAgICAgICAgICAgICAgIHwNCj4gICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCj4gICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBA IFA1ICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgU2lnbmFsIFR5cGUg IHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0aCBAIFA2ICAgICAgICAgICAgICAgIHwNCj4gICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgfCAgU2lnbmFsIFR5cGUgIHxGfCAgICAgICAgICAgICAgIEJhbmR3aWR0 aCBAIFA3ICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g ICAgLi4uICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4uLg0KPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICBTaWdu YWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDAgICAgICAgICAgICAgICAg fA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPiAgICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAg QmFuZHdpZHRoIEAgUDEgICAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICBT aWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDIgICAgICAgICAgICAg ICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAg ICAgQmFuZHdpZHRoIEAgUDMgICAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8 ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDQgICAgICAgICAg ICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAg ICAgICAgQmFuZHdpZHRoIEAgUDUgICAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAg ICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAgICAgICAgICAgQmFuZHdpZHRoIEAgUDYgICAgICAg ICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICBTaWduYWwgVHlwZSAgfEZ8ICAgICAg ICAgICAgICAgQmFuZHdpZHRoIEAgUDcgICAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K Pg0KPiBJIHN0aWxsIGRvbid0IHVuZGVyc3RhbmQgd2h5IHdlIG5lZWQgcGFydGl0aW9uaW5nIHRo ZSBuZXR3b3JrIGluIHRocmVlDQo+IGxheWVycyB3aGlsZSBqdXN0IFN1YmxhbWJhIGFuZCBGdWxs IGxhbWJkYSBkaXN0aW5jdGlvbiBpcyBlbm91Z2gNCj4gKGRpc3RpbmN0aW9uIHN1cHBvcnRlZCBh ZHZlcnRpc2luZyBkaWZmZXJlbnQgc2lnbmFsIHR5cGVzIGZvciBmdWxsDQo+IGxhbWJkYXMgYW5k IHN1YmxhbWJkYXMuDQo+DQo+IFBlcnNvbmFsbHkgaSBzdGlsbCBwcmVmZXIgYWR2ZXJ0aXNpbmcg dGhlc2UgcGllY2VzIG9mIGluZm9ybWF0aW9uIGFzIGENCj4gc2VwYXJhdGUgc3ViLVRMViAoY2Fs bGVkIE9UTi1JU0NEIHN1YlRMViBpbiB0aGUgZHJhZnQgYnV0IGVhc2lseQ0KPiBlc3RlbnNpYmxl IHRvIFRETS1JU0NEIGFjY29yZGluZ2x5IHRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LQ0KPiBvbmctZ21wbHMtYXNvbi1yb3V0aW5nLWV4cGVyLTAyIGZvcm1hdCBwcm9wb3NlZCBi eSB0aGUgT0lGKSBidXQgdGhpcw0KPiBjb3VsZCBiZSBhIHZhbGlkIHNvbHV0aW9uIHRvby4NCj4N Cj4gQlINCj4gRGFuaWVsZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQo+IFNlbnQ6 IG1hcnRlZMOsIDIwIGx1Z2xpbyAyMDEwIDIzLjAyDQo+IFRvOiBKb2huIEUgRHJha2U7IGN1cnRp c0BvY2NuYy5jb207IFNuaWdkaG8gQmFyZGFsYWkNCj4gQ2M6IERhbmllbGUgQ2VjY2FyZWxsaTsg U25pZ2RobyBCYXJkYWxhaTsgRmF0YWkgWmhhbmc7IGNjYW1wQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1l d29yay0NCj4gMDEudHh0DQo+DQo+IEpvaG4sDQo+DQo+IERvIHlvdSB1bmRlcnN0YW5kIHRoZSBx dW90ZSBmcm9tIFJGQzQyMDM6DQo+IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K PiAgICB8IFN3aXRjaGluZyBDYXAgfCAgIEVuY29kaW5nICAgIHwgICAgICAgICAgIFJlc2VydmVk ICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICAgICAgICAgICAgICAgICAgTWF4 IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMCAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiAgICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkg MSAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICAgICAgICAgICAgICAgICAg TWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgMiAgICAgICAgICAgICAgfA0KPiAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KPiAgICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3Jp dHkgMyAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICAgICAgICAgICAgICAg ICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNCAgICAgICAgICAgICAgfA0KPiAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KPiAgICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJp b3JpdHkgNSAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICAgICAgICAgICAg ICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgNiAgICAgICAgICAgICAgfA0KPiAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiAgICB8ICAgICAgICAgICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGggYXQg cHJpb3JpdHkgNyAgICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICB8ICAgICAgICBT d2l0Y2hpbmcgQ2FwYWJpbGl0eS1zcGVjaWZpYyBpbmZvcm1hdGlvbiAgICAgICAgICAgICAgfA0K PiAgICB8ICAgICAgICAgICAgICAgICAgKHZhcmlhYmxlKSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPg0KPiBZb3UgY2FuIHVzZSB0aGUgbGFzdCBm aWVsZCBmb3IgT1ROIHN3aXRjaGNhcCB0byBhZHZlcnRpc2UgdW5yZXNvbHZlZA0KPiBiYW5kd2lk dGggYXZhaWxhYmxlIGZvciB0aGUgSVNDRCBvbiBwZXIgcHJpb3JpdHkgbGV2ZWwuDQo+DQo+IEln b3INCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9obiBFIERyYWtl IFttYWlsdG86amRyYWtlQGp1bmlwZXIubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDIwLCAy MDEwIDQ6MzUgUE0NCj4gVG86IElnb3IgQnJ5c2tpbjsgY3VydGlzQG9jY25jLmNvbTsgU25pZ2Ro byBCYXJkYWxhaQ0KPiBDYzogRGFuaWVsZSBDZWNjYXJlbGxpOyBTbmlnZGhvIEJhcmRhbGFpOyBG YXRhaSBaaGFuZzsgY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVu dCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLQ0KPiAwMS50eHQNCj4N Cj4gU25pcHBlZC4uLg0KPg0KPiA+IElEU0Mgc3ViLVRMViBhbmQgeW91IGNhbiBzcGVjaWZ5IHRo ZSB1bnJlc2VydmVkIGJhbmR3aWR0aCBwZXINCj4gcHJpb3JpdHkNCj4gPiBsZXZlbCBmb3IgZXZl cnkgSVNDRC4NCj4NCj4gSkQ6ICBJZ29yLCB3aGF0IHBhcnQgb2YgbXkgcXVvdGUgZnJvbSBSRkMg NDIwMiBkaWQgeW91IG5vdCB1bmRlcnN0YW5kPw0KPiBZb3UgZG8gbm90IGFkdmVydGlzZSB1bnJl c2VydmVkIGJhbmR3aWR0aCBpbiB0aGUgSVNDRCBUTFYuICBJbg0KPiBwYXJ0aWN1bGFyLCBmb3Ig VERNLCB3aGF0IGlzIGFkdmVydGlzZWQgaXMgdGhlIG1heCBhbmQgbWluIGJhbmR3aWR0aA0KPiBh bGxvd2VkIGZvciBhIHNpbmdsZSBMU1AuICBJdCB3YXMgZGVzaWduZWQgdG8gcHJvZHVjZSBhIGNv bXBhY3QNCj4gcmVwcmVzZW50YXRpb24gYnkgdGFraW5nIGFkdmFudGFnZSBvZiB0aGUgU0RIL1NP TkVUIGhpZXJhcmNoeS4NCj4NCj4gQWR2ZXJ0aXNpbmcgYSBzZXBhcmF0ZSBJU0NEIGZvciBlYWNo IHN1cHBvcnRlZCByYXRlIGlzIGFsbG93ZWQgYnV0DQo+IHdhc3RlZnVsLg0KPg0KPiA+DQo+ID4g SWdvcg0KPiA+DQo+ID4NCj4gPiA+IE9uIFR1ZSwgSnVsIDIwLCAyMDEwIGF0IDk6MTYgQU0sIEln b3IgQnJ5c2tpbg0KPiA+IDxJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20+d3JvPQ0KPiA+ID4gdGU6 DQo+ID4gPg0KPiA+ID4gPiBKb2huLA0KPiA+ID4gPg0KPiA+ID4gPiBJIHRvdGFsbHkgYWdyZWUg d2l0aCB5b3UuIEl0IGlzIGFic29sdXRlbHkgbm9uIE9UTiBzcGVjaWZpYy4NCj4gPiBIb3dldmVy IGlmIGENCj4gPiA+ID4gVEUgbGluayBhZHZlcnRpc2VzIG1vcmUgdGhhbiBvbmUgSVNDRCAod2l0 aCBlYWNoIElTQ0QgY29udGFpbmluZw0KPiA+IG9ubHkgbWF4DQo+ID4gPiA+IGxzcCBiYW5kd2lk dGggcGVyIHByaW9yaXR5KSwgaXQgaXMgbmVjZXNzYXJ5IHRvIGluZGljYXRlIGhvdyB0aGUNCj4g PiB0b3RhbCBsaT0NCj4gPiA+IG5rDQo+ID4gPiA+IHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGlzIHBh cnRpdGlvbmVkIGJldHdlZW4gc2V2ZXJhbCBJU0NEcy4gV2hhdCBJDQo+ID4gYW0NCj4gPiA+ID4g c3VnZ2VzdGluZyBpcyBpbnN0ZWFkIG9mIGFkdmVydGlzaW5nIHRoZSB1bnJlc2VydmVkIGJhbmR3 aWR0aA0KPiA+IG11bHRpcGxlIHRpPQ0KPiA+ID4gbWVzDQo+ID4gPiA+IChvbmUgcGVyIElTQ0Qp LCBpbmRpY2F0ZSBob3cgdGhlIGJhbmR3aWR0aCBpcyBzcGxpdCBiZXR3ZWVuIHRoZQ0KPiA+IElT Q0RzOiBlLj0NCj4gPiA+IGcNCj4gPiA+ID4gSVNDRDEgNzUlLCBJU0NEMiAyNSUuDQo+ID4gPiA+ DQo+ID4gPiA+IElnb3IuDQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiA+IEZyb206IEpvaG4gRSBEcmFrZSBbbWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5l dF0NCj4gPiA+ID4gIFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjAsIDIwMTAgMTE6NTQgQU0NCj4gPiA+ ID4gVG86IElnb3IgQnJ5c2tpbjsgRGFuaWVsZSBDZWNjYXJlbGxpOyBTbmlnZGhvIEJhcmRhbGFp OyBGYXRhaQ0KPiA+IFpoYW5nOw0KPiA+ID4gPiBjdXJ0aXNAb2NjbmMuY29tDQo+ID4gPiA+IENj OiBjY2FtcEBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9u DQo+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDEudHh0DQo+ ID4gPiA+DQo+ID4gPiA+IElnb3IsDQo+ID4gPiA+DQo+ID4gPiA+IFVucmVzZXJ2ZWQgYmFuZHdp ZHRoIGlzIG5vdCBhZHZlcnRpc2VkIGluIHRoZSBURE0gSVNDIFRMViwgc28gdGhlDQo+ID4gaXNz dWUgbz0NCj4gPiA+IGYNCj4gPiA+ID4gcGFydGl0aW9uaW5nIHVucmVzZXJ2ZWQgYmFuZHdpZHRo IGFjcm9zcyBtdWx0aXBsZSBhZHZlcnRpc2VkIFRETQ0KPiA+IElTQyBUTFZzPQ0KPiA+ID4gIGlz DQo+ID4gPiA+IGFjdHVhbGx5IGEgbm9uLWlzc3VlLg0KPiA+ID4gPg0KPiA+ID4gPiBVbnJlc2Vy dmVkIGJhbmR3aWR0aCBieSBwcmlvcml0eSBoYXMgYWx3YXlzIGJlZW4gYWR2ZXJ0aXNlZCB1c2lu Zw0KPiA+IHRoZSBNUEw9DQo+ID4gPiBTDQo+ID4gPiA+IHN1Yi1UTFYuICBNeSBwb2ludCBoYXMg YmVlbiB0aGF0IHdlIGhhdmUgbmV2ZXIgaGFkIGEgcmVxdWlyZW1lbnQNCj4gPiAoaW5jbHVkaT0N Cj4gPiA+IG5nDQo+ID4gPiA+IFNESC9TT05FVCkgaW4gdGhlIHBhc3QgdG8gYWR2ZXJ0aXNlIHVu cmVzZXJ2ZWQgYmFuZHdpZHRoIGJ5DQo+IHNpZ25hbA0KPiA+IHR5cGUsID0NCj4gPiA+IHNvDQo+ ID4gPiA+IHdoYXQgaXMgc3BlY2lhbCBhYm91dCBPVE4/DQo+ID4gPiA+DQo+ID4gPiA+IEEgZnVy dGhlciBwb2ludCB3b3VsZCBiZSB0aGF0IGlmIHdlIGRvIGRlY2lkZSB0aGF0IGl0IGlzDQo+IG5l Y2Vzc2FyeQ0KPiA+IHRvDQo+ID4gPiA+IGFkdmVydGlzZSB1bnJlc2VydmVkIGJhbmR3aWR0aCBi eSBzaWduYWwgdHlwZSwgaXQgc2hvdWxkIGJlIGRvbmUNCj4gPiA+ID4gaW4NCj4gPiBhDQo+ID4g PiA+IGdlbmVyYWwgd2F5IGFuZCBub3QgaW4gYW4gT1ROIHNwZWNpZmljIG1hbm5lci4gIChBbmQg aW4gZmFjdCwgdGhlDQo+ID4gYXJndW1lbj0NCj4gPiA+IHRzDQo+ID4gPiA+IHRoYXQgdW5yZXNl cnZlZCBiYW5kd2lkdGggYnkgc2lnbmFsIHR5cGUgbmVlZHMgdG8gYmUgYWR2ZXJ0aXNlZCwNCj4g PiBzdWNoIGFzID0NCj4gPiA+IHRoZQ0KPiA+ID4gPiBsYXRlc3QgZS1tYWlsIGZyb20gQ3VydGlz LCBhcmUgbm90IE9UTiBzcGVjaWZpYy4pDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcywNCj4gPiA+ ID4NCj4gPiA+ID4gSm9obg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNj YW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmDQo+ID4gPiA+ID4gT2YgSWdvciBC cnlza2luDQo+ID4gPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAyMCwgMjAxMCA4OjIxIEFNDQo+ ID4gPiA+ID4gVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgU25pZ2RobyBCYXJkYWxhaTsgRmF0YWkg Wmhhbmc7DQo+ID4gY3VydGlzQG9jY25jLmNvbQ0KPiA+ID4gPiA+IENjOiBjY2FtcEBpZXRmLm9y Zw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1nNzA5LQ0KPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiAwMS50eHQNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEl0IGlzIGEgdmFsaWQgcG9pbnQsIGJ1dCB0aGUgc3VnZ2VzdGVkIHNv bHV0aW9uIGlzIHdheSB0b28NCj4gPiBleHBlbnNpdmUuDQo+ID4gPiA+ID4gQWxsIHlvdSBuZWVk IGlzIGEgd2F5IHRvIHNheSBob3cgdGhlIGFkdmVydGlzZWQgdW5yZXNlcnZlZA0KPiA+IGJhbmR3 aWR0aCBpcw0KPiA+ID4gPiA+IHBhcnRpdGlvbmVkIGJldHdlZW4gSVNDRHMgaW4gY2FzZSB0aGUg VEUgbGluayBhZHZlcnRpc2VtZW50DQo+ID4gY29udGFpbnMNCj4gPiA+ID4gPiBzZXZlcmFsIG9m IHRoZW0uIE9uZSBjaGVhcCB3YXkgb2YgZG9pbmcgc28gaXMgdG8gYWxsb2NhdGUgMy00DQo+ID4g Yml0cyBvdXQNCj4gPiA+ID4gPiBvZiB0aGUgSVNDRCBzdWItVExWIHJlc2VydmVkIGJpdHMgdG8g aW5kaWNhdGUgdGhlIGZyYWN0aW9uIG9mDQo+ID4gdG90YWwNCj4gPiA+ID4gPiB1bnJlc2VydmVk IGJhbmR3aWR0aCBhc3NvY2lhdGVkIHdpdGggdGhlIElTQ0QuIEFub3RoZXIgd2F5IGlzDQo+IHRv DQo+ID4gdXNlDQo+ID4gPiA+ID4gc3dpY3RoY2FwIHNwZWNpZmljIGV4dGVuc2lvbi4NCj4gPiA+ ID4gPiBCVFc6IHRoaXMgaXMgbm90IGFuIE9UTiBzcGVjaWZpYyBpc3N1ZSwgcmF0aGVyIG1vcmUg Z2VuZXJhbDoNCj4gYW55DQo+ID4gdGltZQ0KPiA+ID4gPiA+IHdoZW4gYSBURSBsaW5rIGFkdmVy dGlzZXMgbW9yZSB0aGFuIG9uZSBJU0NEICh3aGljaCBpcw0KPiBwZXJmZWN0bHkNCj4gPiBPaw0K PiA+ID4gPiA+IGFjY29yZGluZyB0byA0MjAzKSB5b3UnbGwgaGF2ZSB0aGUgc2FtZSBwcm9ibGVt Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSWdvcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkN Cj4gPiA+ID4gPiBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+ID4g PiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAyMCwgMjAxMCAxMDo1NyBBTQ0KPiA+ID4gPiA+IFRv OiBJZ29yIEJyeXNraW47IFNuaWdkaG8gQmFyZGFsYWk7IEZhdGFpIFpoYW5nOw0KPiA+ID4gPiA+ IGN1cnRpc0BvY2NuYy5jb20NCj4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4gPiA+ID4g PiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt ZzcwOS0NCj4gPiBmcmFtZXdvcmstDQo+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBJZ29yLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIG5lZWQgZm9yIHVucmVzZXJ2ZWQg cmVzb3VyY2VzIGFkdmVydGlzZWQgcGVyIHNpZ25hbCB0eXBlIGlzDQo+ID4gdGhlDQo+ID4gPiA+ ID4gY29uY3VycmVudCBwYXRoIGNvbXB1dGF0aW9uLiBJJ2xsIGFuc3dlciBxdW90aW5nIGEgc2Vj dGlvbiBmcm9tDQo+ID4gdGhlDQo+ID4gPiA+ID4gaW5mby1tb2RlbCBkcmFmdCwgcGxlYXNlIGhh dmUgYSBsb29rIGluIHBhcnRpY3VsYXIgdG8gdGhlDQo+ID4gZXhhbXBsZToNCj4gPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgIiBVbnJlc2VydmVkIHJlc291cmNlcyBuZWVkIHRvIGJl IGFkdmVydGlzZWQgcGVyIHByaW9yaXR5DQo+IGFuZA0KPiA+IHBlcg0KPiA+ID4gPiA+ICAgIHNp Z25hbCB0eXBlIGluIG9yZGVyIHRvIGFsbG93IHRoZSBjb3JyZWN0IGZ1bmN0aW9uaW5nIG9mIHRo ZQ0KPiA+ID4gPiA+ICAgIHJlc3RvcmF0aW9uIHByb2Nlc3MuICBbUkZDNDIwM10gb25seSBhbGxv d3MgYWR2ZXJ0aXNpbmcNCj4gPiB1bnJlc2VydmVkDQo+ID4gPiA+ID4gICAgcmVzb3VyY2VzIHBl ciBwcmlvcml0eSwgdGhpcyBsZWFkcyBub3QgdG8ga25vdyBob3cgbWFueSBMU1BzDQo+ID4gb2Yg YQ0KPiA+ID4gPiA+ICAgIHNwZWNpZmljIHNpZ25hbCB0eXBlIGNhbiBiZSByZXN0b3JlZC4gIEFz IGV4YW1wbGUgaXQgaXMNCj4gPiBwb3NzaWJsZSB0bw0KPiA+ID4gPiA+ICAgIGNvbnNpZGVyIHRo ZSBzY2VuYXJpbyBkZXBpY3RlZCBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICstLS0tLS0rIGNvbXBvbmVudCBsaW5rIDEgKy0t LS0tLSsNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICB8ICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLSsgICAgICB8DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgfCAgICAgIHwgY29tcG9u ZW50IGxpbmsgMiB8ICAgICAgfA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIHwgIE4xICAr LS0tLS0tLS0tLS0tLS0tLS0tKyAgTjIgIHwNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICB8 ICAgICAgfCBjb21wb25lbnQgbGluayAzIHwgICAgICB8DQo+ID4gPiA+ID4gICAgICAgICAgICAg ICAgICAgfCAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgfA0KPiA+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICstLS0tLS0rICAgICAgICAgICAgICAgICAgKy0tLSstLSsNCj4gPiA+ID4g Pg0KPiA+ID4gPiA+ICAgIFN1cHBvc2UgdG8gaGF2ZSBhIFRFIGxpbmsgY29tcHJpc2luZyAzIE9E VTMgY29tcG9uZW50IGxpbmtzDQo+ID4gd2l0aA0KPiA+ID4gPiA+ICAgIDMyVFNzIGF2YWlsYWJs ZSBvbiB0aGUgZmlyc3Qgb25lLCAyNFRTcyBvbiB0aGUgc2Vjb25kLCAyNFRTcw0KPiA+IG9uIHRo ZQ0KPiA+ID4gPiA+ICAgIHRoaXJkIGFuZCBzdXBwb3J0aW5nIE9EVTIgYW5kIE9EVTMgc2lnbmFs IHR5cGVzLiAgVGhlIG5vZGUNCj4gPiB3b3VsZA0KPiA+ID4gPiA+ICAgIGFkdmVydGlzZSBhIFRF IGxpbmsgdW5yZXNlcnZlZCBiYW5kd2lkdGggZXF1YWwgdG8gODAgVFNzIGFuZA0KPiA+ID4gPiA+ IGENCj4gPiBNQVgNCj4gPiA+ID4gPiAgICBMU1AgYmFuZHdpZHRoIGVxdWFsIHRvIDMyIFRTcy4g IEluIGNhc2Ugb2YgcmVzdG9yYXRpb24gdGhlDQo+ID4gbmV0d29yaw0KPiA+ID4gPiA+ICAgIGNv dWxkIHRyeSB0byByZXN0b3JlIDIgT0RVMyAoNjRUU3MpIGluIHN1Y2ggVEUtbGluayB3aGlsZQ0K PiA+ID4gPiA+IG9ubHkNCj4gPiBhDQo+ID4gPiA+ID4gICAgc2luZ2xlIE9EVTMgY2FuIGJlIHNl dCB1cCBhbmQgYSBjcmFuay1iYWNrIHdvdWxkIGJlDQo+ID4gb3JpZ2luYXRlZC4gIEluDQo+ID4g PiA+ID4gICAgbW9yZSBjb21wbGV4IG5ldHdvcmsgc2NlbmFyaW9zIHRoZSBudW1iZXIgb2YgY3Jh bmstYmFja3MgY2FuDQo+ID4gYmUgbXVjaA0KPiA+ID4gPiA+ICAgIGhpZ2hlci4iDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBJbiBvdGhlciB3b3JkcywgYWR2ZXJ0aXNpbmcgdGhlIG51bWJlciBvZiBh dmFpbGJsZSByZXNvdXJjZXMNCj4gcGVyDQo+ID4gc2lnbmFsDQo+ID4gPiA+ID4gdHlwZSBkb2Vz IG5vdCBhdm9pZCB0aGUgcG9zc2liaWxpdHkgb2YgY3JhbmNrLWJhY2sgYnV0DQo+IGRlY3JlYXNl cw0KPiA+IGl0IGFzDQo+ID4gPiA+ID4gbXVjaCBhcyBwb3NzaWJsZS4gRm9yIHN1cmUgYSBnb29k IHJvdXRpbmcgcHJldmVudHMgZnJvbSBjcmFuay0NCj4gPiBiYWNrcw0KPiA+ID4gPiA+IGNhdXNl ZCBieSB0aGUgcmVzdG9yYXRpb24gb2YgTFNQIG9yaWdpbmF0aW5nIG9uIHRoZSBzYW1lDQo+IElu Z3Jlc3MuDQo+ID4gVGhlDQo+ID4gPiA+ID4gY3JhbmNrLWJhY2tzIGR1ZSB0byB0aGUgY29uY3Vy cmVudCByZXN0b3JhdGlvbiBvZiBMU1BzDQo+ID4gb3JpZ2luYXRpbmcgb24NCj4gPiA+ID4gPiBk aWZmZXJlbnQgaW5ncmVzcyBub2RlcyBjYW5ub3QgYmUgYXZvaWRlZC4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IEJSDQo+ID4gPiA+ID4gRGFuaWVsZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IElnb3IgQnJ5 c2tpbiBbbWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbV0NCj4gPiA+ID4gPiBTZW50OiBt YXJ0ZWQ9RUMgMjAgbHVnbGlvIDIwMTAgMTYuMTYNCj4gPiA+ID4gPiBUbzogRGFuaWVsZSBDZWNj YXJlbGxpOyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsNCj4gPiBjdXJ0aXNAb2NjbmMu Y29tDQo+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUkU6 IFtDQ0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gZnJh bWV3b3JrLQ0KPiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSW4gbGluZQ0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4gPiA+ID4gPiBbbWFpbHRvOmRhbmllbGUuY2Vj Y2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+ID4gPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAyMCwg MjAxMCA0OjMyIEFNDQo+ID4gPiA+ID4gVG86IFNuaWdkaG8gQmFyZGFsYWk7IElnb3IgQnJ5c2tp bjsgRmF0YWkgWmhhbmc7DQo+ID4gPiA+ID4gY3VydGlzQG9jY25jLmNvbQ0KPiA+ID4gPiA+IENj OiBjY2FtcEBpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQg b24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+IGZyYW1ld29yay0NCj4gPiA+ID4g PiAwMS50eHQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IElnb3IsIG9uZSBtb3JlIHF1ZXN0aW9uLg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gV2hhdCBhYm91dCB0aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGg/ DQo+ID4gPiA+ID4gSWYgeW91J3JlIGFkdmVydGlzaW5nIHRoZSBtYXggbHNwIGJhbmR3aWR0aCBi eSAxIElTQ0QgcGVyIHJvbGUNCj4gPiBwZXINCj4gPiA+ID4gPiAobXV4Q2FwICYgc2lnbmFsIHR5 cGUpIHlvdSBhbHNvIG5lZWQgdG8gYWR2ZXJ0aXNlIHRoZQ0KPiB1bnJlc2VydmVkDQo+ID4gPiA+ ID4gYmFuZHdpZHRoIHVzaW5nIDEgdW5yZXNlcnZlZCBiYW5kd2lkdGggc3ViLVRMViBwZXIgSVND RCwNCj4gY29ycmVjdD8NCj4gPiBUaGlzDQo+ID4gPiA+ID4gYWxzbyBpbXBsaWVzIGV4dGVuZGlu ZyB0aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGggVExWIHNvIHRvDQo+IGNyZWF0ZQ0KPiA+IGENCj4g PiA+ID4gPiBjb3JyaXNwb25kZW5jZSBiZXR3ZWVuIHRoZSBjb3VwbGVzIChJU0NELXVucmVzZXJ2 ZWQgYmFuZHdpZHRoDQo+ID4gc3ViVExWKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IElCPj4gQWdy ZWUgdGhhdCBtYXggbHNwIGJhbmR3aWR0aCBzaG91bGQgYmUgYWR2ZXJ0aXNlZCBieSAxDQo+IElT Q0QNCj4gPiBwZXINCj4gPiA+ID4gPiBJQj4+IHJvbGUgcGVyIChtdXhDYXAgJiBzaWduYWwgdHlw ZSkgcGVyIHByaW9yaXR5IGxldmVsLg0KPiA+ID4gPiA+IElCPj4gSG93ZXZlciwNCj4gPiB0b3Rh bA0KPiA+ID4gPiA+IElCPj4gdW5yZXNlcnZlZCBiYW5kd2lkdGggSU1PIGlzIE9LIHRvIHNoYXJl IGJldHdlZW4gcm9sZXMNCj4gPiA+ID4gPiBJQj4+IHVubGVzcw0KPiA+IHlvdQ0KPiA+ID4gPiA+ IElCPj4gc2VlIGEgY29tcGVsbGluZyByZWFzb24gdG8gdGhlIGNvbnRyYXJ5ICh3aGljaCBJIGRv bid0KQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSWdvcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhh bmtzDQo+ID4gPiA+ID4gRGFuaWVsZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBTbmlnZGhvIEJhcmRhbGFpIFttYWlsdG86 U0JhcmRhbGFpQGluZmluZXJhLmNvbV0NCj4gPiA+ID4gPiBTZW50OiBsdW5lZD1FQyAxOSBsdWds aW8gMjAxMCAxNy40OA0KPiA+ID4gPiA+IFRvOiBJZ29yIEJyeXNraW47IERhbmllbGUgQ2VjY2Fy ZWxsaTsgRmF0YWkgWmhhbmc7DQo+ID4gY3VydGlzQG9jY25jLmNvbQ0KPiA+ID4gPiA+IENjOiBj Y2FtcEBpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24g ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiAw MS50eHQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFVuZGVyc3Rvb2QuLi4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFJlZ2FyZHMNCj4gPiA+ID4gPiBTbmlnZGhvDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBJZ29yIEJyeXNr aW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQo+ID4gPiA+ID4gPiBTZW50OiBN b25kYXksIEp1bHkgMTksIDIwMTAgODo0NiBBTQ0KPiA+ID4gPiA+ID4gVG86IFNuaWdkaG8gQmFy ZGFsYWk7IERhbmllbGUgQ2VjY2FyZWxsaTsgRmF0YWkgWmhhbmc7DQo+ID4gPiA+ID4gPiBjdXJ0 aXNAb2NjbmMuY29tDQo+ID4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1n NzA5LQ0KPiA+ID4gPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IFtTQ0JdIEFyZSB5b3Ugc2F5aW5nIHRoZSBJU0NEIGFzIGRlZmluZWQg dG9kYXkgd2l0aCBtaW5vcg0KPiA+IGV4dGVuc2lvbnMNCj4gPiA+ID4gPiA+IChpLmUuIHRvIGZ1 cnRoZXIgY2xhc3NpZnkgdGhlIGluZm9ybWF0aW9uKSB3aWxsIGJlIHN1ZmZpY2llbnQNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGF0J3MgZXhhY3RseSB3aGF0IEkndmUgYmVlbg0KPiA+ID4g PiA+ID4gdHJ5aW5nIHRvIHNheSBhbGwgYWxvbmcuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g Q2hlZXJzLA0KPiA+ID4gPiA+ID4gSWdvcg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBTbmlnZGhvIEJhcmRhbGFp IFttYWlsdG86U0JhcmRhbGFpQGluZmluZXJhLmNvbV0NCj4gPiA+ID4gPiA+IFNlbnQ6IE1vbmRh eSwgSnVseSAxOSwgMjAxMCAxMTozMSBBTQ0KPiA+ID4gPiA+ID4gVG86IElnb3IgQnJ5c2tpbjsg RGFuaWVsZSBDZWNjYXJlbGxpOyBGYXRhaSBaaGFuZzsNCj4gPiBjdXJ0aXNAb2NjbmMuY29tDQo+ ID4gPiA+ID4gPiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJFOiBb Q0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LQ0KPiA+ID4gPiA+ IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IElnb3INCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBSZWdhcmRzDQo+ID4gPiA+ID4gPiBTbmlnZGhvDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ ID4gPiBGcm9tOiBJZ29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21d DQo+ID4gPiA+ID4gPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAxOSwgMjAxMCA3OjQzIEFNDQo+ID4g PiA+ID4gPiA+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGk7IEZhdGFpIFpoYW5nOyBjdXJ0aXNAb2Nj bmMuY29tDQo+ID4gPiA+ID4gPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgU25pZ2RobyBCYXJkYWxh aQ0KPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWll dGYtY2NhbXAtZ21wbHMtDQo+IGc3MDktDQo+ID4gPiA+ID4gPiBmcmFtZXdvcmstDQo+ID4gPiA+ ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBEYW5pZWxlLA0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBQbGVhc2UsIHNlZSBpbiBsaW5lLg0KPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ID4gPiA+IElnb3INCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiA+ID4gRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpDQo+ID4gW21haWx0bzpkYW5pZWxlLmNlY2Nh cmVsbGlAZXJpY3Nzb24uY29tXQ0KPiA+ID4gPiA+ID4gPiBTZW50OiBNb25kYXksIEp1bHkgMTks IDIwMTAgMTA6MzEgQU0NCj4gPiA+ID4gPiA+ID4gVG86IElnb3IgQnJ5c2tpbjsgRmF0YWkgWmhh bmc7IGN1cnRpc0BvY2NuYy5jb20NCj4gPiA+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnOyBT bmlnZGhvIEJhcmRhbGFpDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIENvbW1l bnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy0NCj4gZzcwOS0NCj4gPiA+ID4gPiA+IGZyYW1l d29yay0NCj4gPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ IEhpIElnb3IsDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEkgZGlkbid0IHVuZGVyc3Rh bmQgaWYgeW91J3JlIHByb3Bvc2luZyB0byAoYSkgc2VuZCBhbiBJU0NEDQo+ID4gcGVyDQo+ID4g PiA+ID4gcm9sZQ0KPiA+ID4gPiA+ID4gPiAoaS5lLiBPVE5fSE9fU0MsIE9UTl9MT19TQykgb3Ig KGIpIGFuIElTQ0QgcGVyIHJvbGUgcGVyDQo+ID4gc2lnbmFsDQo+ID4gPiA+ID4gdHlwZS4NCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSUI+PiBpbiBJU0NEOg0KPiA+ID4gPiA+ID4gPiBz d2l0Y2hDYXAgPTNEIHJvbGU7DQo+ID4gPiA+ID4gPiA+IGVuY29kZVR5cGUgPTNEIG11eENhcCAm IHNpZ25hbCB0eXBlOyBXZSBhbHNvIGhhdmUgMTYNCj4gPiA+ID4gPiA+ID4gcmVzZXJ2ZWQgYml0 cyB3aGljaCBjYW4gdXNlIGZvciBPVE4gc3BlY2lmaWMNCj4gPiBpbmZvDQo+ID4gPiA+ID4gaW4N Cj4gPiA+ID4gPiA+ID4gY2FzZSB3ZSBuZWVkIGl0Lg0KPiA+ID4gPiA+ID4gW1NDQl0gSSBhbSB5 ZXQgdG8gY2xlYXJseSB1bmRlcnN0YW5kIHdoYXQgdGhlIHJvbGUgb2YgInJvbGUiDQo+ID4gaXMs IGJ1dA0KPiA+ID4gPiA+ID4gYWdyZWUgd2l0aCB5b3VyIG9ic2VydmF0aW9uIG9uIHRoZSBlbmNv ZGUtdHlwZSBhbmQgdGhlIDE2DQo+ID4gPiA+ID4gPiByZXNlcnZlZC1iaXRzIHRvIGZ1cnRoZXIg Y2xhc3NpZnkgdGhlIHN3aXRjaGluZyBpbmZvcm1hdGlvbi4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gSW4gY2FzZSAoYSkgeW91J3JlIHN0aWxsIG1pc3NpbmcgYSBsb3Qgb2YgaW5mb3Jt YXRpb24uIEZvcg0KPiA+IGVhY2gNCj4gPiA+ID4gPiByb2xlDQo+ID4gPiA+ID4gPiA+IHlvdSB3 b3VsZCBhZHZlcnRpc2UganVzdCB0aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGggYnV0IHlvdQ0KPiA+ IHdvdWxkbid0DQo+ID4gPiA+ID4gPiBrbm93DQo+ID4gPiA+ID4gPiA+IGlmIHN1Y2ggYmFuZHdp ZHRoIGlzIGF2YWlsYWJsZSBmb3IgYSBjZXJ0YWluIHR5cGUgb2YgT0RVag0KPiA+ID4gPiA+ID4g PiBMU1ANCj4gPiAoZS5nLg0KPiA+ID4gPiA+ID4gMTUNCj4gPiA+ID4gPiA+ID4gR2JwcyBhdmFp bGFibGUgb24gMyBjb21wb25lbnQgbGlua3M6IHlvdSBhZHZlcnRpc2UgNDUgR2Jwcw0KPiA+ID4g PiA+IGF2YWlsYWJsZQ0KPiA+ID4gPiA+ID4gPiBidXQgbm8gT0RVMyBjYW4gYmUgc2V0IHVwIG9u IHN1Y2ggVEUgbGluaykuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEluIGNhc2UgKGIp IHRoZSBudW1iZXIgb2YgSVNDRHMgd291bGQgY2F1c2Ugc2VyaW91cw0KPiA+IHNjYWxhYmlsaXR5 DQo+ID4gPiA+ID4gPiBpc3N1ZXMNCj4gPiA+ID4gPiA+ID4gYW5kIHRoZSByZXF1aXJlbWVudCBv ZiBiZWluZyBhYmxlIHRvIGJ1bmRsZSBjb21wb25lbnQgbGlua3MNCj4gPiA+ID4gPiB0b2dldGhl cg0KPiA+ID4gPiA+ID4gPiB3b3VsZG4ndCBiZSBzYXRpc2ZpZWQuDQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+IElCPj4gRGlzYWdyZWUuIElTQ0QgaXMgYSByZWxhdGl2ZWx5IHNtYWxsIHN1 YlRMViwgc2V2ZXJhbA0KPiA+IElTRENzDQo+ID4gPiA+ID4gd2lsbA0KPiA+ID4gPiA+ID4gPiBw cm92aWRlIGEgbG90IG9mIGZsZXhpYmlsaXR5OiB5b3UgY2FuIHNwZWNpZnkgZGlmZmVyZW50DQo+ ID4gdGhpbmdzDQo+ID4gPiA+ID4gKGUuZy4NCj4gPiA+ID4gPiA+ID4gYXZhaWxhYmxlIGJhbmR3 aWR0aCkgZm9yIHRoZSBzYW1lIGxpbmsgaW4gZGlmZmVyZW50IHJvbGVzLg0KPiA+ID4gPiA+ID4g W1NDQl0gQXJlIHlvdSBzYXlpbmcgdGhlIElTQ0QgYXMgZGVmaW5lZCB0b2RheSB3aXRoIG1pbm9y DQo+ID4gZXh0ZW5zaW9ucw0KPiA+ID4gPiA+ID4gKGkuZS4gdG8gZnVydGhlciBjbGFzc2lmeSB0 aGUgaW5mb3JtYXRpb24pIHdpbGwgYmUNCj4gc3VmZmljaWVudD8NCj4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiBEYW5pZWxlDQo+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC0NCj4gYm91bmNlc0Bp ZXRmLm9yZ10NCj4gPiBPbg0KPiA+ID4gPiA+ID4gQmVoYWxmDQo+ID4gPiA+ID4gPiA+IE9mIEln b3IgQnJ5c2tpbg0KPiA+ID4gPiA+ID4gPiBTZW50OiBsdW5lZD1FQyAxOSBsdWdsaW8gMjAxMCAx NS40MA0KPiA+ID4gPiA+ID4gPiBUbzogRmF0YWkgWmhhbmc7IGN1cnRpc0BvY2NuYy5jb20NCj4g PiA+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnOyBTbmlnZGhvIEJhcmRhbGFpDQo+ID4gPiA+ ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy0NCj4gZzcwOS0NCj4gPiA+ID4gPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+ID4gMDEu dHh0DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEZhdGFpLA0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiBQbGVhc2UsIHNlZSBteSByZXNwb25zZXMgb24tbGluZS4NCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiBJZ29yDQo+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ ID4gPiA+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC0NCj4gYm91 bmNlc0BpZXRmLm9yZ10NCj4gPiBPbg0KPiA+ID4gPiA+ID4gQmVoYWxmDQo+ID4gPiA+ID4gPiA+ IE9mIEZhdGFpIFpoYW5nDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFN1bmRheSwgSnVseSAxOCwgMjAx MCAxMDo0OSBQTQ0KPiA+ID4gPiA+ID4gPiBUbzogSWdvciBCcnlza2luOyBjdXJ0aXNAb2NjbmMu Y29tDQo+ID4gPiA+ID4gPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgU25pZ2RobyBCYXJkYWxhaQ0K PiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21tZW50IG9uIGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtDQo+IGc3MDktDQo+ID4gPiA+ID4gPiBmcmFtZXdvcmstDQo+ID4gPiA+ID4g PiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBIaSBJZ29yLA0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGFua3MuDQo+ID4gPiA+ID4gPiA+IEkgdW5kZXJzdGFu ZCB3aGF0IHlvdSBzYWlkLiBUaGVyZWZvcmUsIHdlIGhhdmUgYWRkZWQgc29tZQ0KPiA+IHRleHQg dG8NCj4gPiA+ID4gPiA+ID4gYWRkcmVzcyB0aGUgcmVxdWlybWVudCBpbiBGV0sgZG9jdW1lbnQu IEhvd2V2ZXIsIHdlIHN0aWxsDQo+ID4gZG9uJ3QNCj4gPiA+ID4gPiA+ID4gdGhpbmsgdGhhdCB3 ZSBuZWVkIHRvIGV4dGVuZCBJU0MgdG8gbWVldCB0aGUgcmVxdWlybWVudC4NCj4gVGhlDQo+ID4g cm9sZQ0KPiA+ID4gPiA+IG9mDQo+ID4gPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gT0RVDQo+ ID4gPiA+ID4gPiA+IGNhbiBiZSBnZXQgZnJvbSB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBpbXBs aWNpdGx5LiBJbiB0aGUNCj4gPiBbZHJhZnQtDQo+ID4gPiA+ID4gPiA+IGNlY2NhcmVsbGktY2Nh bXAtZ21wbHMtb3NwZi1nNzA5LTAyXSBkcmFmdCwgYSBraW5kIG9mDQo+ICJGdWxsDQo+ID4gPiA+ ID4gTGFtYmRhIg0KPiA+ID4gPiA+ID4gaXMNCj4gPiA+ID4gPiA+ID4gaW50cm9kdWNlZC4NCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSUI+PiBUaGlzIGlzIHBvc3NpYmxlLCBob3dldmVy Og0KPiA+ID4gPiA+ID4gPiBhKSB0aGlzIHJlcXVpcmVzIE9UTiBzcGVjaWZpYyBhZHZlcnRpc2lu ZyBhbmQgcHJvY2Vzc2luZw0KPiA+IHJ1bGVzOw0KPiA+ID4gPiA+ID4gPiBiKSBkaXNhbGxvd3Mg dG9wb2xvZ3kgc2VwYXJhdGlvbiBpbiB0ZWNobm9sb2d5IGluZGVwZW5kZW50DQo+ID4gd2F5DQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEEgcXVpY2sgcXVlc3Rpb24gb24geW91ciBzdGF0 ZW1lbnQ6ICJ0aGUgcm9sZSBvZiBhbiBPRFUNCj4gPiBjb250YWluZXINCj4gPiA+ID4gPiA+IGRv ZXMNCj4gPiA+ID4gPiA+ID4gbm90IGNoYW5nZSBob3AtYnktaG9wIChhcyBzb21lIHBlb3BsZSBz ZWVtIHRvIGJlbGlldmUpLiBUaGUNCj4gPiByb2xlIGlzDQo+ID4gPiA+ID4gPiA+IG9ubHkgbWVh bmluZ2Z1bCBvbiB0aGUgT0RVIHRlcm1pbmF0aW5nIG5vZGVzIGFuZCBpcnJlbGV2YW50DQo+ID4g b24NCj4gPiA+ID4gPiA+IHRyYW5zaXQNCj4gPiA+ID4gPiA+ID4gbm9kZXMuIEl0IGlzIGl0J3Mg cG9zaXRpb24gaW4gdGhlIGhpZXJhcmNoeSAoYnV0IG5vdCByb2xlKQ0KPiA+IHRoYXQgbWF5DQo+ ID4gPiA+ID4gPiA+IGNoYW5nZSBob3AtYnktaG9wLiAiDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+IEZvciBleGFtcGxlLCBBKEFJMSktLS0tKEJJMSlCKEJJMiktLS0tKENJMSlDLCAgSW50 ZXJmYWNlcw0KPiA+ID4gPiA+ID4gPiBBSTENCj4gPiBhbmQNCj4gPiA+ID4gPiA+ID4gQ0kxIGNh biBzdXBwb3J0IEhvIE9EVTIgYW5kIExvIE9EVTIsIEhvd2V2ZXIsIEJJMSBhbmQgQkkyDQo+ID4g PiA+ID4gPiA+IGNhbg0KPiA+IG9ubHkNCj4gPiA+ID4gPiA+IHN1cHBvcnQNCj4gPiA+ID4gPiA+ ID4gTG8gT0RVMiAodGhlIHJvbGUgaXMgTG8gT1ROIExldmVsKS4gSWYgYSBjb25uZWN0aW9uIE9E VTINCj4gPiA+ID4gPiA+ID4gd2l0aA0KPiA+IHRoZQ0KPiA+ID4gPiA+ID4gcm9sZQ0KPiA+ID4g PiA+ID4gPiBvZiBIbyBPRFUgbGV2ZWwgaXMgcmVxdWVzdGVkLCAgYWNjb3JkaW5nIHRvIHlvdXIg c3RhdGVtZW50LA0KPiA+IHRoaXMNCj4gPiA+ID4gPiA+ID4gY29ubmVjaXRvbiB3aWxsIGJlIGFs bG93ZWQgdG8gYmUgY3JlYXRlZC4gSG93ZXZlciwgaXQNCj4gc2hvdWxkDQo+ID4gbm90IGJlDQo+ ID4gPiA+ID4gPiA+IGFsbG93ZWQgYmVjYXVzZSB0aGUgSVNDIGlzIG5vdCBjb25zaXN0ZW50IGFs b25nIHRoZSBMU1AuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IElCPj4gTm8sIHlvdXIg dW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gQTExIGFuZCBDMTEgVEUNCj4gPiBsaW5rDQo+ ID4gPiA+ID4gZW5kcw0KPiA+ID4gPiA+ID4gPiB3aWxsIGJlIGFkdmVydGlzZWQgd2l0aCB0d28g SVNDRHM6IE9UTl9IT19TQyBhbmQgT0lOX0xPX1NDLA0KPiA+IHdoaWxlDQo+ID4gPiA+ID4gPiA+ IEIxMSBhbmQgQjEyIC0gb25seSB3aXRoIGEgc2luZ2xlIElTQ0Q6IE9UTl9MT19TQy4gSWYgdGhl DQo+ID4gPiA+ID4gPiA+IHBhdGggY29tcHV0YXRpb24gaXMgY29uc3RyYWluZWQgdG8gdGhlIE9U Tl9IT19TQyB0b3BvbG9neSwNCj4gPiA+ID4gPiA+ID4gQjExIGFuZA0KPiA+IEIxMg0KPiA+ID4g PiA+IFRFDQo+ID4gPiA+ID4gPiA+IGxpbmtzIHdpbGwNCj4gPiA+ID4gPiA+IGJlDQo+ID4gPiA+ ID4gPiA+IGRpc2FsbG93ZWQsIGFuZCB0aGUgcmVzdWx0aW5nIHBhdGggKGlmIGFueSkgd2lsbCBu b3QgZ28NCj4gPiB0aHJvdWdoIEIxMQ0KPiA+ID4gPiA+ID4gYW5kDQo+ID4gPiA+ID4gPiA+IEIx Mi4gSWYgb25lIGNpcmN1bXZlbnRzIHRoZSBwYXRoIGNvbXB1dGF0aW9uIGJ5IHByb3ZpZGluZw0K PiA+ID4gPiA+ID4gPiB0aGUNCj4gPiBmdWxseQ0KPiA+ID4gPiA+ID4gPiBleHBsaWNpdCBwYXRo LCB0aGUgc2lnbmFsaW5nIHNob3VsZCBmYWlsIG9uIG5vZGUgQiBmb3IgdGhlDQo+ID4gc2FtZQ0K PiA+ID4gPiA+ID4gcmVhc29uOg0KPiA+ID4gPiA+ID4gPiBpbmNvbnNpc3RlbmN5IG9mIHJlcXVp cmVkIChzaWduYWxlZCkgYW5kIHN1cHBvcnRlZCAoYnkNCj4gbG9jYWwNCj4gPiA+ID4gPiA+ID4g aW50ZXJmYWNlcykgc3dpdGNoY2FwLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBQbGVh c2Ugc2VlIHRoZSB0ZXh0IGZyb20gUkZDMzQ3MzogICAiTm9kZXMgTVVTVCB2ZXJpZnkgdGhhdA0K PiA+IHRoZQ0KPiA+ID4gPiA+IHR5cGUNCj4gPiA+ID4gPiA+ID4gaW5kaWNhdGVkIGluIHRoZSBT d2l0Y2hpbmcgVHlwZSAgcGFyYW1ldGVyIGlzIHN1cHBvcnRlZCBvbg0KPiA+IHRoZQ0KPiA+ID4g PiA+ID4gPiBjb3JyZXNwb25kaW5nIGluY29taW5nIGludGVyZmFjZS4gIElmICB0aGUgdHlwZSBj YW5ub3QgYmUNCj4gPiA+ID4gPiBzdXBwb3J0ZWQsDQo+ID4gPiA+ID4gPiA+IHRoZSBub2RlIE1V U1QgZ2VuZXJhdGUgYSBQYXRoRXJyIG1lc3NhZ2Ugd2l0aCBhICJSb3V0aW5nDQo+ID4gPiA+ID4g PiA+IHByb2JsZW0vU3dpdGNoaW5nIFR5cGUiIGluZGljYXRpb24uIg0KPiA+ID4gPiA+ID4gPiBJ Qj4+IEluZGVlZA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBCZXN0IFJlZ2FyZHMNCj4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gRmF0YWkNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiAiSWdvciBCcnlza2lu IiA8SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPg0KPiA+ID4gPiA+ID4gPiBUbzogIkZhdGFpIFpo YW5nIiA8emhhbmdmYXRhaUBodWF3ZWkuY29tPjsNCj4gPiA+ID4gPiA+ID4gPGN1cnRpc0BvY2Nu Yy5jb20+DQo+ID4gPiA+ID4gPiA+IENjOiAiSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIu bmV0PjsgIlNuaWdkaG8gQmFyZGFsYWkiDQo+ID4gPiA+ID4gPiA+IDxTQmFyZGFsYWlAaW5maW5l cmEuY29tPjsgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PjsNCj4gPiA+ID4gPiA+ID4g PGNjYW1wQGlldGYub3JnPjsgPGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4g PiA+ID4gZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPg0KPiA+ID4gPiA+ID4gPiBTZW50OiBGcmlk YXksIEp1bHkgMTYsIDIwMTAgMTI6MzQgQU0NCj4gPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtD Q0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLQ0KPiBnNzA5LQ0KPiA+ID4g PiA+ID4gZnJhbWV3b3JrLQ0KPiA+ID4gPiA+ID4gPiAwMS50eHQNCj4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gRmF0YWksDQo+ID4gPiA+ID4gPiA+IFBsZWFzZSwg c2VlIG15IGFuc3dlcnMgaW4gbGluZS4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gRnJvbTogRmF0YWkgWmhhbmcg W21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5l c2RheSwgSnVseSAxNCwgMjAxMCA5OjUyIFBNDQo+ID4gPiA+ID4gPiA+IFRvOiBJZ29yIEJyeXNr aW47IGN1cnRpc0BvY2NuYy5jb20NCj4gPiA+ID4gPiA+ID4gQ2M6IEpvaG4gRSBEcmFrZTsgU25p Z2RobyBCYXJkYWxhaTsgTG91IEJlcmdlcjsNCj4gPiBjY2FtcEBpZXRmLm9yZzsNCj4gPiA+ID4g PiA+IGRyYWZ0LQ0KPiA+ID4gPiA+ID4gPiBpZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3Jr QHRvb2xzLmlldGYub3JnDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1l bnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy0NCj4gZzcwOS0NCj4gPiA+ID4gPiA+IGZyYW1l d29yay0NCj4gPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ IEhpIElnb3IgYW5kIGFsbCwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gVGhhbmtzIGZv ciBhbGwgeW91ciBjb21tZW50cy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSSB0aGlu ayByb2xlIGRvZXMgbm90IGVxdWFsIHN3aXRjaGluZyBjYXBhYmlsaXR5LiBUaGUNCj4gPiBvcGVy YXRvcnMgY2FuDQo+ID4gPiA+ID4gPiA+IGRlZmluZSBkaWZmZXJlbnQgcm9sZXMgZGVwZW5kaW5n IG9uIHRoZWlyIHBvbGljeSBhbmQNCj4gYWNoaWV2ZQ0KPiA+IHRoZQ0KPiA+ID4gPiA+ID4gPiBy b2xlIHRocm91Z2ggZGlmZmVyZW50IG1ldGhvZHMuIEhvd2V2ZXIsIGZvciBPVE4gbmV0d29ya3Ms DQo+ID4gdGhlDQo+ID4gPiA+ID4gPiA+IGNvbnRhaW5lcnMgKGUuZy4sIE9EVWspIGFsbCBoYXZl IHRoZSBzYW1lIHN3aXRjaGluZw0KPiA+IGNhcGFibGlsaXR5DQo+ID4gPiA+ID4gPiA+IChpLmUu LCBURE0NCj4gPiA+ID4gPiA+ID4gc3dpdGNoaW5nKSBhbmQgSSB0aGluayB3ZSBzaG91bGQgcmVm bGVjdCB0aGUgbmF0dXJhbA0KPiA+ID4gPiA+IGNoYXJhY3RlcmlzdGljcw0KPiA+ID4gPiA+ID4g b2YNCj4gPiA+ID4gPiA+ID4gbGlua3MgaW4gdGhlIHJvdXRpbmcuIEluIGFkZGl0aW9uLCBpZiB3 ZSBleHRlbmQgdGhlIElTQywgaXQNCj4gPiB3aWxsDQo+ID4gPiA+ID4gPiA+IG1ha2UgdGhlIGVu Y29kaW5nIHR5cGUgbG9zZSBpdHMnIG93biBtZWFuaW5nKGllLiwgSVNDDQo+ID4gb3ZlcnJpZGVz DQo+ID4gPiA+ID4gPiA+IGVuY29kaW5nIHR5cGUpLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiBJQj4+IFdoZW4gYSBHTVBMUyBDUCBpbnN0YW5jZSBjb250cm9scyBzZXZlcmFsIGxheWVy cywgaXQNCj4gPiB2aWV3cyB0aGUNCj4gPiA+ID4gPiA+ID4gbmV0d29yayBhcyBhIHN0YWNrIG9m IHRvcG9sb2dpZXMuIFdoZXRoZXIgYSBnaXZlbiB0b3BvbG9neQ0KPiA+ID4gPiA+ID4gPiBpcw0K PiA+IHJlYWwNCj4gPiA+ID4gPiA+ID4gb3IgdmlydHVhbCBpcyBvZiBubyBpbXBvcnRhbmNlLg0K PiA+ID4gPiA+ID4gPiBUaGUgR01QTFMgSVNDRCBsaW5rIHN1Yi10bHYgYW5kLCBpbiBwYXJ0aWN1 bGFyLCBpdHMNCj4gPiA+ID4gPiA+ID4gc3dpdGNoaW5nIGNhcGFiaWxpdHkgZmllbGQgKGNvbmZ1 c2luZyBuYW1lIGFzIGl0IGlzKSBpcyBhDQo+ID4gPiA+ID4gPiA+IGdvb2Qgd2F5IHRvDQo+ID4g PiA+ID4gZGVzY3JpYmUNCj4gPiA+ID4gPiA+IGENCj4gPiA+ID4gPiA+ID4gbGF5ZXIgaW4gdGVj aG5vbG9neSBpbmRlcGVuZGVudCB3YXksIHNvIHRoYXQsIHNheSwgTVBMUy1UUC0NCj4gPiA+T1RO X0xPLQ0KPiA+ID4gPiA+ID4gPiA+T1ROX0hPLT5PVE5fU0hPLT5XRE0gbGF5ZXIgc3RhY2sgY291 bGQgYmUgcGVyY2VpdmVkIGFzIGENCj4gPiBzdGFjayBvZg0KPiA+ID4gPiA+ID4gPiB0b3BvbG9n aWVzIHRoYXQgY291bGQgYmUgZWFzaWx5IHNlcGFyYXRlZCBpbiB0ZWNobm9sb2d5DQo+ID4gaW5k ZXBlbmRlbnQNCj4gPiA+ID4gPiA+IHdheQ0KPiA+ID4gPiA+ID4gPiBzaG91bGQgcGF0aCBjb21w dXRhdGlvbiBiZSBjb25zdHJhaW5lZCB0byBwYXJ0aWN1bGFyIG9uZSBvcg0KPiA+ID4gPiA+ID4g PiBzdWItc3RhY2sgb2YgdGhlbS4NCj4gPiA+ID4gPiA+ID4gSSB0aGluayBhIGdvb2Qgd2F5IHRv IGlkZW50aWZ5IGFuIE9UTiAodmlydHVhbCkgdG9wb2xvZ3kgaXMNCj4gPiB2aWENCj4gPiA+ID4g PiA+ID4gKGluZnJhc3RydWN0dXJlKSBPRFUgY29udGFpbmVyIHJvbGUgb2YgT0RVcyBjb21wcmlz aW5nIHRoZQ0KPiA+ID4gPiA+IHRvcG9sb2d5Lg0KPiA+ID4gPiA+ID4gPiBCVFcgSU1PIHRoZSBy b2xlIG9mIGFuIE9EVSBjb250YWluZXIgZG9lcyBub3QgY2hhbmdlIGhvcC0NCj4gYnktDQo+ID4g aG9wIChhcw0KPiA+ID4gPiA+ID4gPiBzb21lIHBlb3BsZSBzZWVtIHRvIGJlbGlldmUpLiBUaGUg cm9sZSBpcyBvbmx5IG1lYW5pbmdmdWwNCj4gb24NCj4gPiB0aGUNCj4gPiA+ID4gPiBPRFUNCj4g PiA+ID4gPiA+ID4gdGVybWluYXRpbmcgbm9kZXMgYW5kIGlycmVsZXZhbnQgb24gdHJhbnNpdCBu b2Rlcy4gSXQgaXMNCj4gPiA+ID4gPiA+ID4gaXQncw0KPiA+ID4gPiA+ID4gcG9zaXRpb24NCj4g PiA+ID4gPiA+ID4gaW4gdGhlIGhpZXJhcmNoeSAoYnV0IG5vdCByb2xlKSB0aGF0IG1heSBjaGFu Z2UgaG9wLWJ5LWhvcC4NCj4gPiBPRFUncw0KPiA+ID4gPiA+ID4gcm9sZQ0KPiA+ID4gPiA+ID4g PiBpcyB0aGUgbGV2ZWwgb2YgdG9wb2xvZ3kgaXQgaXMgcHJvdmlzaW9uZWQgZm9yIGFuZCBpdCBp cw0KPiB0aGUNCj4gPiBzYW1lDQo+ID4gPiA+ID4gPiA+IGZvciBhbGwgT0RVcyB0aGF0IGNvbXBy aXNlIHRoZSB0b3BvbG9neS4gRm9yLCBleGFtcGxlIGENCj4gdXNlcg0KPiA+IG1heQ0KPiA+ID4g PiA+ID4gcHJvdmlzaW9uDQo+ID4gPiA+ID4gPiA+IGEgTE8gdG9wb2xvZ3kgYW5kIGNvbnN0cmFp biBPRFVzIGhlIHNlbGxzIHRvIGEgc2V0IG9mDQo+ID4gPiA+ID4gPiA+IGNsaWVudHMNCj4gPiB0 bw0KPiA+ID4gPiA+IHVzZQ0KPiA+ID4gPiA+ID4gPiB0aGUgdG9wb2xvZ3kgcmF0aGVyIHRoYW4g YW55IHJlc291cmNlcyBhdmFpbGFibGUgb24gT1RODQo+ID4gbmV0d29yay4NCj4gPiA+ID4gPiA+ ID4gVGhlIGJvdHRvbSBsaW5lOiBjb250YWluZXIncyByb2xlIGlzIHRoZSBzYW1lIGFzIHRoZSBy b2xlDQo+IG9mDQo+ID4gPiA+ID4gdmlydHVhbA0KPiA+ID4gPiA+ID4gPiB0b3BvbG9neSB0aGUg Y29udGFpbmVyIGlzIGEgcGFydCBvZiBhbmQgY291bGQgYmUgYWR2ZXJ0aXNlZA0KPiA+IGFzIHRo ZQ0KPiA+ID4gPiA+ID4gPiBjb3JyZXNwb25kaW5nIGxpbmsgc3dpdGNoY2FwLg0KPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiBBY2NvcmRpbmcgdG8gdGhlIHBvaW50IDMsIEkgZG9uJ3Qga25v dyBob3cgdG8gYWR2ZXJ0aXNlIHRoZQ0KPiA+IHJvbGVzDQo+ID4gPiA+ID4gPiA+IGFuZCBtdXhp bmcgY2FwYWJpbGl0aWVzIHdpdGggdGhlIElTQ0Qgb2YgUkZDNDIwMiwgY291bGQgeW91DQo+ID4g PiA+ID4gY2xhcmlmeT8NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSUI+PiBzd2l0Y2hj YXAgPTNEIE9EVSByb2xlIChlLmcuIExPX09UTl9TQywgSE9fT1ROX1NDLA0KPiA+ID4gPiA+ID4g PiBJQj4+IGV0Yy4pDQo+ID4gPiA+ID4gPiA+ICAgICAgZW5jb2RpbmcgdHlwZSA9M0QgbXV4LiBj YXBhYmlsaXRpZXMgY29kZQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJbiBhZGRpdGlv biwgY291bGQgeW91IGNsYXJpZnkgbXkgcXVlc3Rpb25zIGluIGFub3RoZXINCj4gZW1haWwNCj4g PiA+ID4gPiAoY29waWVkDQo+ID4gPiA+ID4gPiBhcw0KPiA+ID4gPiA+ID4gPiBmb2xsb3dzKToN Cj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPg0KPiA9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9 M0Q9DQo+ID4gPg0KPiA+DQo+ID0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj4gPiAzDQo+ID4gRD0zRD0NCj4gPiA+ ID0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRA0KPiA+ID4gPiA+ID4gPTNEDQo+ID4gPiA+ID4gPiA+DQo+ID4gPTNEPTNEPTNE PTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNE PQ0KPiA+ID4gPTNEPTNEPTNEPTNEPTNEPTNEPTNEDQo+ID4gPiA+ID4gPiA+IEZvciAgTG8gT0RV LCBIbyBPRFUsIFNITyBPRFUsIHRoZXkgYXJlIHJlbGF0aXZlIHRvIGVhY2gNCj4gPiBvdGhlci4N Cj4gPiA+ID4gPiA+ID4gSUI+PiBJIGRpc2FncmVlLiBZb3UgZGVmaW5lIHJvbGUgPTNEPTNEIHBv c2l0aW9uIGluIHRoZQ0KPiA+IGhpZXJhcmNoeSwNCj4gPiA+ID4gPiB3aGljaA0KPiA+ID4gPiA+ ID4gaXMNCj4gPiA+ID4gPiA+ID4gYSBtaXN0YWtlIElNTy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gRm9yIGV4YW1wbGUsIE9EVTEtPk9EVTItPk9EVTMtPk9EVTQsIGhvdyB0byByZWdh cmQgT0RVMiBvcg0KPiA+IE9EVTMgYXMNCj4gPiA+ID4gPiA+ID4gSG8gT1ROIExldmVsIG9yIExv IE9UTiBMZXZlbD8gQW5vdGhlciBleGFtcGxlIGlzLCBpZiB0aGVyZQ0KPiA+ID4gPiA+ID4gPiBp cw0KPiA+IGENCj4gPiA+ID4gPiBPVFUzDQo+ID4gPiA+ID4gPiBsaW5rDQo+ID4gPiA+ID4gPiA+ IHN1cHBvcnRpbmcgT0RVMiBzd2l0Y2hpbmcsIHdoaWNoIGNhbiBiZSB1c2VkIGFzIExvIE9EVTIN Cj4gPiAoc2VydmljZQ0KPiA+ID4gPiA+ID4gPiBvdmVyDQo+ID4gPiA+ID4gPiA+IE9EVTIgZGly ZWN0bHkpIGFuZCBIbyBPRFUyIChPRFUxIGlzIG92ZXIgdGhpcyBPRFUyKSwgaW4NCj4gdGhpcw0K PiA+IGNhc2UsDQo+ID4gPiA+ID4gPiBob3cNCj4gPiA+ID4gPiA+ID4gdG8gZGlmZmVyZW50aWF0 ZSBpZiB0aGlzIE9EVTIgaXMgTG8gT1ROIExldmVsIG9yIEhvIE9UTg0KPiA+IExldmVsPw0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJQj4+IEFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIE9E VSByb2xlIGlzIG9ubHkgaW1wb3J0YW50IG9uDQo+ID4gdGhlIE9EVQ0KPiA+ID4gPiA+ID4gPiB0 ZXJtaW5hdGluZyBub2RlcyAoaS5lLiBvbiBlaXRoZXIgc2lkZSBvZiBjb3JyZXNwb25kaW5nDQo+ ID4gbGluaykuIFdoYXQNCj4gPiA+ID4gPiA+ID4gaGFwcGVucyBvbiB0aGUgT0RVIHRyYW5zaXQg bm9kZXMgYW5kIGl0cyBwbGFjZSBpbiB0aGUNCj4gPiBoaWVyYXJjaHkgb24NCj4gPiA+ID4gPiA+ IHRoZQ0KPiA+ID4gPiA+ID4gPiB0cmFuc2l0IG5vZGVzIGFyZSBvZiBubyBpbXBvcnRhbmNlLiBN eSBMTyBjb250YWluZXIgY2FuIGJlDQo+ID4gY2FycmllZA0KPiA+ID4gPiA+ID4gPiBieSBzb21l Ym9keSBlbHNlJ3MgTE8gY29udGFpbmVyIGFuZCBjYW4gY2FycnkgbXkgY2xpZW50J3MNCj4gTE8N Cj4gPiA+ID4gPiBjb250YWluZXIuDQo+ID4gPiA+ID4gPiBUbw0KPiA+ID4gPiA+ID4gPiBzb21l IGV4dGVudCBpdCBpcyBzaW1pbGFyIHRvIE1QTFMgTFNQIHJvbGU6IExTUCBhbHdheXMgaGFzDQo+ IGENCj4gPiByb2xlDQo+ID4gPiA+ID4gPiAoZS5nLg0KPiA+ID4gPiA+ID4gPiBQVyBMU1Agb3Ig VEUtIExTUCkgYW5kIGl0IGNvdWxkIGJlIGFueXdoZXJlIGluIE1QTFMgc3RhY2sNCj4gPiBhbG9u ZyBpdHMNCj4gPiA+ID4gPiA+ID4gcGF0aC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g Q2hlZXJzLA0KPiA+ID4gPiA+ID4gPiBJZ29yDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4NCj4gPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNE PTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPQ0KPiA+ID4NCj4g Pg0KPiA9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9DQo+ID4gMw0KPiA+IEQ9M0Q9DQo+ID4gPiA9M0Q9M0Q9M0Q9M0Q9 M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0Q9M0QNCj4g PiA+ID4gPiA+ID0zRA0KPiA+ID4gPiA+ID4gPg0KPiA+ID0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj4gPiA+ID0zRD0z RD0zRD0zRD0zRD0zRA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiBUaGFua3MNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gRmF0 YWkNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiAiSWdvciBCcnlza2luIiA8SUJyeXNraW5AYWR2YW9w dGljYWwuY29tPg0KPiA+ID4gPiA+ID4gPiBUbzogPGN1cnRpc0BvY2NuYy5jb20+DQo+ID4gPiA+ ID4gPiA+IENjOiAiSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIubmV0PjsgIlNuaWdkaG8g QmFyZGFsYWkiDQo+ID4gPiA+ID4gPiA+IDxTQmFyZGFsYWlAaW5maW5lcmEuY29tPjsgIkZhdGFp IFpoYW5nIg0KPiA+IDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+Ow0KPiA+ID4gPiA+ID4gPiAiTG91 IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+OyA8Y2NhbXBAaWV0Zi5vcmc+Ow0KPiA+ID4gPiA+ ID4gPiA8ZHJhZnQtaWV0Zi1jY2FtcC0NCj4gPiA+ID4gPiA+IGdtcGxzLQ0KPiA+ID4gPiA+ID4g PiBnNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4NCj4gPiA+ID4gPiA+ID4gU2VudDogV2Vk bmVzZGF5LCBKdWx5IDE0LCAyMDEwIDEwOjM2IFBNDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJF OiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy0NCj4gZzcwOS0NCj4g PiA+ID4gPiA+IGZyYW1ld29yay0NCj4gPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEN1cnRpcywNCj4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnQuDQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+IEkgYWdyZWUgdGhhdCB0aGVyZSBzaG91bGQgYmUgbXVsdGlwbGUgT1ROIHNwZWNp ZmljIGVuY29kaW5nDQo+ID4gdHlwZXMNCj4gPiA+ID4gPiA+ID4gaW50cm9kdWNlZC4gQnV0IElN TyB0aGV5IHNob3VsZCBpbmRpY2F0ZSB0aGUgbGluaydzIG11eA0KPiA+ID4gPiA+IGNhcGFiaWxp dGllcw0KPiA+ID4gPiA+ID4gPiByYXRoZXIgdGhhbiB0aGUgbGluaydzIHJvbGUgKGkuZS4gbGV2 ZWwgaW4gdGhlIE9UTg0KPiBoaWVyYXJjaHk6DQo+ID4gTE8sDQo+ID4gPiA+ID4gPiA+IEhPLCBT SE8sIGV0Yy4pLiBUaGUgbGluaydzIHJvbGUgb3Igcm9sZXMgSU1PIHNob3VsZCBiZQ0KPiA+IGlu ZGljYXRlZA0KPiA+ID4gPiA+ID4gPiB3aXRoIGEgc2VwYXJhdGUgc3dpdGNoY2Fwcy4gSSBjYW4g Z2l2ZSB5b3Ugc2V2ZXJhbCByZWFzb25zOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAx LiBMaW5rcyB3aXRoIHRoZSBzYW1lIG11eCBjYXBhYmlsaXRpZXMgbWF5IGhhdmUgZGlmZmVyZW50 DQo+ID4gcm9sZXM7DQo+ID4gPiA+ID4gMi4NCj4gPiA+ID4gPiA+ID4gTGluayBtYXkgYWR2ZXJ0 aXNlIHNldmVyYWwgcm9sZXMgKGUuZy4gSE8gYW5kIFNITykgd2l0aA0KPiA+IGRpZmZlcmVudA0K PiA+ID4gPiA+ID4gPiBtdXguY2FwYWJpbGl0aWVzIHBlciByb2xlOyAzLiBMaW5rJ3Mgcm9sZSBh bmQgbXV4Lg0KPiA+IGNhcGFiaWxpdGllcyBjYW4NCj4gPiA+ID4gPiA+IGJlDQo+ID4gPiA+ID4g PiA+IGFkdmVydGlzZWQgd2l0aCBJU0NEcyBhcyBkZWZpbmVkIGluIFJGQzQyMDIgKG5vIE9UTi1z dHlsZQ0KPiA+IElTQ0QgaXMNCj4gPiA+ID4gPiA+ID4gcmVxdWlyZWQpOyA0LiBUaGUgY29tYmlu YXRpb24gb2Ygc3dpY3RoY2FwcyBhbmQgZW5jb2RpbmcNCj4gPiA+ID4gPiA+ID4gdHlwZQ0KPiA+ IHdpbGwNCj4gPiA+ID4gPiA+IGxvb2sNCj4gPiA+ID4gPiA+ID4gdG8gQ1AgYXMgYSBzZXBhcmF0 ZSBsYXllciwgd2hpY2ggaXMgZXhhY3RseSBob3cgSVRVIG1vZGVscw0KPiA+IE9UTg0KPiA+ID4g PiA+ID4gPiBoaWVyYXJjaGllcyBpbiBhbGwgYXNwZWN0cyBidXQgcm91dGluZyAoIT8pIDUuIElm IHRoZQ0KPiA+IG9wZXJhdG9yDQo+ID4gPiA+ID4gd291bGQNCj4gPiA+ID4gPiA+ID4gd2FudCB0 byBjb25zdHJhaW4gdGhlIHJvdXRpbmcgb2YgT1ROIGNvbm5lY3Rpb25zIHRvIHByZS0NCj4gPiBj b25maWd1cmVkDQo+ID4gPiA+ID4gPiA+IHRvcG9sb2d5IHdpdGggYSBzcGVjaWZpYyByb2xlIChl LmcuIGNvbnN0cmFpbiBhbGwgT0RVcyBpdA0KPiA+IHNlbGxzIHRvDQo+ID4gPiA+ID4gPiB0aGUN Cj4gPiA+ID4gPiA+ID4gY2xpZW50cyB0byBvbmUgb3IgbW9yZSBwcmUtY29uZmlndXJlZCBMTyB0 b3BvbG9naWVzKSwgdGhpcw0KPiA+IHdvdWxkIGJlDQo+ID4gPiA+ID4gPiA+IHBvc3NpYmxlIHRv IGRvIGluIGEgdGVjaG5vbG9neSBpbmRlcGVuZGVudCB3YXkuIFN1cHBvc2UgYW4NCj4gPiBpbnN0 YW5jZQ0KPiA+ID4gPiA+ID4gb2YNCj4gPiA+ID4gPiA+ID4gR01QTFMgQ1AgbWFuYWdlcyBXRE0g YW5kIE9UTiBORXMuIFRoZW4gc2VwYXJhdGlvbiBvZiBMTw0KPiBmcm9tDQo+ID4gSE8gT1RODQo+ ID4gPiA+ID4gPiA+IGxpbmtzIHdpbGwgYmUgbm8gZGlmZmVyZW50IGZyb20gdGhlIHNlcGFyYXRp b24gb2YgV0RNIGxpbmtzDQo+ID4gZnJvbQ0KPiA+ID4gPiA+ID4gT1RVcy4NCj4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiBJZ29yDQo+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4g PiA+IEZyb206IGN1cnRpc0BvY2NuYy5jb20gW21haWx0bzpjdXJ0aXNAb2NjbmMuY29tXQ0KPiA+ ID4gPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDEzLCAyMDEwIDY6MjQgUE0NCj4gPiA+ID4g PiA+ID4gVG86IElnb3IgQnJ5c2tpbg0KPiA+ID4gPiA+ID4gPiBDYzogSm9obiBFIERyYWtlOyBT bmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91DQo+IEJlcmdlcjsNCj4gPiA+ID4gPiA+ ID4gY2NhbXBAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS0NCj4gPiA+ID4g PiBmcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtD Q0FNUF0gQ29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLQ0KPiBnNzA5LQ0KPiA+ID4g PiA+ID4gZnJhbWV3b3JrLQ0KPiA+ID4gPiA+ID4gPiAwMS50eHQNCj4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSW4gbWVzc2FnZSA8MDUyQzY3QjRFRDU1OEQ0MUJC REVBN0NBOUZDNkRDREM1M0MwRDFFMUZFQGF0bC0NCj4gPiBzcnYtDQo+ID4gPiA+ID4gPiA+IGV4 Z2VuLmF0bC5hZHZhb3B0aWNhbC5jb20+DQo+ID4gPiA+ID4gPiA+IElnb3IgQnJ5c2tpbiB3cml0 ZXM6DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBJIHRoaW5rIE9UTiBsaW5rcyBy ZXF1aXJlIG1vcmUgdGhhbiBvbmUgc3dpdGNoY2FwczogYXMNCj4gPiA+ID4gPiA+ID4gPiBtYW55 DQo+ID4gYXMNCj4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gZGVwdGggb2YgdGhlIGRlZXBl c3QgcG9zc2libGUgT1ROIERQIGhpZXJhcmNoeSwgZm9yDQo+IGV4YW1wbGU6DQo+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiB0eXBlZGVmIGVudW0NCj4gPiA+ID4gPiA+ID4gPiB7DQo+ ID4gPiA+ID4gPiA+ID4gICAgTFNQU3dpdGNoVHlwZV9Vbmtub3duID0zRDAgICAgICAgICAgICAv KiBVbmtub3duICovDQo+ID4gPiA+ID4gPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX1BTQ18xID0z RDEgICAgICAgICAgICAvKiBQU0MtMSAqLw0KPiA+ID4gPiA+ID4gPiA+ICAgICwgTFNQU3dpdGNo VHlwZV9QU0NfMiA9M0QyICAgICAgICAgICAgLyogUFNDLTIgKi8NCj4gPiA+ID4gPiA+ID4gPiAg ICAsIExTUFN3aXRjaFR5cGVfUFNDXzMgPTNEMyAgICAgICAgICAgIC8qIFBTQy0zICovDQo+ID4g PiA+ID4gPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX1BTQ180ID0zRDQgICAgICAgICAgICAvKiBQ U0MtNCAqLw0KPiA+ID4gPiA+ID4gPiA+ICAgICwgTFNQU3dpdGNoVHlwZV9MMlNDICA9M0Q1MCAg ICAgICAgICAgLyogTDJTQyAqLw0KPiA+ID4gPiA+ID4gPiA+ICAgICwgTFNQU3dpdGNoVHlwZV9U RE0gICA9M0QxMDAgICAgICAgICAgLyogVERNICovDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gPiAvKioqKiovDQo+ID4gPiA+ID4gPiA+ID4gICAgLCBMU1BTd2l0Y2hUeXBlX09UTl9M Tz0zRDEyNCAgIC8qIE9UTiBsb3cgb3JkZXIgKi8NCj4gPiA+ID4gPiA+ID4gPiAgICAsIExTUFN3 aXRjaFR5cGVfT1ROX0hPPTNEMTI1ICAgLyogT1ROIGhpZ2ggb3JkZXIgKi8NCj4gPiA+ID4gPiA+ ID4gPiAgICAsIExTUFN3aXRjaFR5cGVfT1ROX1NITz0zRDEyNiAgLyogT1ROIHN1cGVyIGhpZ2gg b3JkZXINCj4gPiAqLw0KPiA+ID4gPiA+IC8qKioqKi8NCj4gPiA+ID4gPiA+ID4gPiAgICAsIExT UFN3aXRjaFR5cGVfTFNDICAgPTNEMTUwICAgICAgICAgIC8qIExTQyAqLw0KPiA+ID4gPiA+ID4g PiA+ICAgICwgTFNQU3dpdGNoVHlwZV9GU0MgICA9M0QyMDAgICAgICAgICAgLyogRlNDICovDQo+ ID4gPiA+ID4gPiA+ID4gfWVfTFNQU3dpdGNoVHlwZTsNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gSXQgd291bGQgYmUgYmV0dGVyIElNSE8gdG8ga2VlcCB0aGUg U3dpdGNoIFR5cGUgYXMgVERNIGFuZA0KPiA+IG1ha2UgdGhlDQo+ID4gPiA+ID4gPiA+IEVuY29k aW5nIFR5cGUgT1ROX0xPLCBPVE5fSE8gb3IgT1ROX1NITy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gVGhpcyB3b3VsZCByZXBsYWNlIHRoZSAyMDAwNiBPVE4gRW5jb2RpbmcgVHlwZSBm b3IgRy43MDkNCj4gPiBEaWdpdGFsDQo+ID4gPiA+ID4gPiA+IFBhdGggbGF5ZXIgYW5kIEcuNzA5 IE9wdGljYWwgQ2hhbm5lbCBsYXllciBmb3IgMjAwOSBPVE4sDQo+ID4gd2hpY2ggaGFkDQo+ID4g PiA+ID4gPiA+IGluIHR1cm4gcmVwbGFjZWQgdGhlIEVuY29kaW5nIFR5cGUgb2YgIkRpZ2l0YWwg V3JhcHBlciIgYQ0KPiA+IGxvbmcgdGltZQ0KPiA+ID4gPiA+IGFnby4NCj4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gUmVwbGFjaW5nIHRoZSBFbmNvZGluZyBUeXBlIHdvdWxkIGluc3VyZSB0 aGF0IGFueSBMU1IgdGhhdA0KPiA+IGRpZCBub3QNCj4gPiA+ID4gPiA+ID4gdW5kZXJzdGFuZCB3 aGF0IHRoZSBUUyB0eXBlIG1lYW50IGRpZCBub3QgdHJ5IHRvIG11bHRpcGxleA0KPiA+IGl0cyBM Tw0KPiA+ID4gPiA+ID4gPiBPRFUgYXQgVFMgZ3JhbnVsYXJpdHkgMi41IG9udG8gYSBITyBPRFUg dGhhdCBoYWQgYWxyYWVkeQ0KPiA+IGNvbW1pdGVkDQo+ID4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+ IHVzaW5nDQo+ID4gPiA+ID4gPiA+IGEgMS4yNSBUUyBncmFudWxhcml0eSBmb3IgYW5vdGhlciBM TyBPRFUuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEl0IGNvdWxkIGFsc28gYmUgc3Rh dGVkIHRoYXQgaWYgYW4gTFNSIGFkdmVydGlzZXMgT1ROX0xPLA0KPiA+IE9UTl9ITyBvcg0KPiA+ ID4gPiA+ID4gPiBPVE5fU0hPIEZBLCBhbmQgYWxzbyBhZHZlcnRpc2VzIEcuNzA5IERpZ2l0YWwg UGF0aCBGQSwgdGhlbg0KPiA+IHRoZQ0KPiA+ID4gPiA+ID4gbGF0dGVyDQo+ID4gPiA+ID4gPiA+ IGlzIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFuZCBzaG91bGQgYmUgaWdub3JlZCBpZg0K PiA+IE9UTl9MTywNCj4gPiA+ID4gPiA+ID4gT1ROX0hPIG9yIE9UTl9TSE8gaXMgdW5kZXJzdG9v ZC4gIElmIHRoZSBMU1IgY29tbWl0cyB0bw0KPiAxLjI1DQo+ID4gVFMNCj4gPiA+ID4gPiA+ID4g Z3JhbnVsYXJpdHksIHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgRy43MDkgRGlnaXRhbCBQYXRoIEZB DQo+ID4gPiA+ID4gPiA+IGNhbg0KPiA+IGJlDQo+ID4gPiA+ID4gd2l0aGRyYXduLg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGUgRW5jb2RpbmcgdHlwZSB3b3VsZCBiZSB0aGUgbG93 ZXIgZW5jb2RpbmcgYXQgZWFjaCBlbmQNCj4gb2YNCj4gPiB0aGUNCj4gPiA+ID4gPiBMU1ANCj4g PiA+ID4gPiA+ID4gcmVnYXJkbGVzcyBvZiB3aGF0IGdvZXMgb24gaW4gdGhlIG1pZGRsZSBzaW5j ZSB0aGF0DQo+ID4gZGV0ZXJtaW5lcyB3aGF0DQo+ID4gPiA+ID4gPiBjYW4NCj4gPiA+ID4gPiA+ ID4gYmUgd3JhcHBlZCBpbnNpZGUgaXQuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEZv ciBleGFtcGxlOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgICAgICBPVFUzDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgT1RVMiAgICAgIE9EVWs9 M0QzIC0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiA+ICAgIE9UVTEgICAgICAgT0RVaz0zRDIg LS0gT0RVaj0zRDINCj4gPiA+ID4gPiA+ID4gICAgT0RVaz0zRDEgLS0tIE9EVWo9M0QxIC0tDQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoaXMgaXMgT0sgYW5kIHRoZSBvdXRlciBPRFVr PTNEMSBjb3VsZCBob2xkIGEgT0RVaj0zRDAgb3INCj4gPiBPRFVqPTNEZj0NCj4gPiA+IGxleA0K PiA+ID4gPiA+ID4gPiBldmVuIHRob3VnaCB0aGUgT0RVaz0zRDIgYXQgdGhlIG5leHQgaG9wIGNv dWxkIG5vdCBkaXJlY3RseQ0KPiA+IGNvbnRhaW4NCj4gPiA+ID4gPiBhbiBPRFUwLg0KPiA+ID4g PiA+ID4gPiBJZiB0aGUgU0hPIEVuY29kaW5nIFR5cGUgaXMgdXNlZCwgdGhlbiBpdCBpbmRpY2F0 ZXMgdGhhdA0KPiB0d28NCj4gPiBsZXZlbHMNCj4gPiA+ID4gPiA+IG9mDQo+ID4gPiA+ID4gPiA+ IG11bHRpcGxleGluZyBjb3VsZCBiZSBzdXBwb3J0ZWQgYXQgdGhhdCBzd2l0Y2gvTFNSLg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGUgbm9taW5hbCBieXRlcy9zZWMgcmF0ZXMgY2Fu IHN0aWxsIGJlIHByb3ZpZGVkLiAgUkZDDQo+IDQzMjgNCj4gPiBTd2l0Y2gNCj4gPiA+ID4gPiA+ ID4gVHlwZXMgY3VycmVudGx5IGRvbid0IGluY2x1ZGUgYW4gT0RVaiBvciBPRFVrIGRpc3RpbmN0 aW9uDQo+ID4gPiA+ID4gPiA+IGJ1dA0KPiA+IGlmDQo+ID4gPiA+ID4gPiA+IEVuY29kaW5nIFR5 cGUgaW5kaWNhdGVkIExPIG9yIEhPLCB0aGF0IG1heSBub3QgYmUgbmVlZGVkLg0KPiA+IEFsb25n DQo+ID4gPiA+ID4gPiA+IHdpdGggdGhlIG5ldyBFbmNvZGluZyBUeXBlIG5ldyBTaWduYWwgVHlw ZXMgZm9yIE9EVTAsIE9EVTQsDQo+ID4gYW5kDQo+ID4gPiA+ID4gPiA+IE9EVS1mbGV4LCBhbmQg T0RVMmUsIGNhbiBiZSBhZGRlZC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gYnR3IC0g dGhlIDEuMjUgb3IgMi41IFRTIHR5cGUgaXMgYSB2YWx1YWJsZSBhZGRpdGlvbiBidXQNCj4gSSdt DQo+ID4gbm90DQo+ID4gPiA+ID4gPiBjbGVhcg0KPiA+ID4gPiA+ID4gPiBob3cgaW4gYW4gRkEg aXQgY2FuIGJlIGluZGljYXRlZCB0aGF0IGVpdGhlciB0eXBlIGlzDQo+ID4gY3VycmVudGx5DQo+ ID4gPiA+ID4gPiA+IGF2YWlsYWJsZSAoTkUgY2FwYWJsZSBvZiBib3RoIGFuZCBoYXNuJ3QgY29t bWl0dGVkIHRvDQo+IGVpdGhlcg0KPiA+IG9uZQ0KPiA+ID4gPiA+ID4geWV0KS4NCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gQlRXLSBNYXliZSBJJ20gbWlzc2luZyBzb21ldGhpbmcgYnV0 IHRoZSBudW1iZXIgb2YgbWVzc2FnZXMNCj4gPiBvbiB0aGlzDQo+ID4gPiA+ID4gPiA+IHdvdWxk IGluZGljYXRlIGEgaHVnZSBjb250cm92ZXJzeSBhbmQgSSdtIG5vdCBnZXR0aW5nIGl0DQo+ID4g KG90aGVyDQo+ID4gPiA+ID4gdGhhbg0KPiA+ID4gPiA+ID4gYQ0KPiA+ID4gPiA+ID4gPiBzdHJv bmcgcHJlZmVyZW5jZSB0byByZWx5IG9uIGJ5dGVzL3NlYyBvciBvbiBlbnVtZXJhdGVkDQo+IHR5 cGUNCj4gPiA+ID4gPiBmaWVsZHMpLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBkcmFm dC1iY2NnLWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWwtMDEgaXMgbmljZSB3b3JrLiAgSSdtDQo+ ID4gbm90IHN1cmUNCj4gPiA+ID4gPiA+IGlmDQo+ID4gPiA+ID4gPiA+IHRoZSBpbnRlbnQgaXMg dG8gbWVyZ2Ugd2l0aCBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gZnJhbWV3b3Jr LA0KPiA+ID4gPiA+ID4gPiBvciBvdGhlciBpbnRlbnQuICBDb3VsZCBzb21lb25lIChlaXRoZXIg ZHJhZnQpIGNvbmNpc2VseQ0KPiA+IHN1bW1hcml6ZQ0KPiA+ID4gPiA+ID4gPiB0aGUgbXVsdGlw bGV4aW5nIHJlc3RyaWN0aW9ucyBpbiBvbmUgcGxhY2UsIGluY2x1ZGluZw0KPiA+IHJlc3RyaWN0 aW9ucw0KPiA+ID4gPiA+ID4gPiBvbiBudW1iZXIgb2YgbXVsdGlwbGV4aW5nIGxheWVycyBhdCBv bmUgTFNSLiAgVGhhdCBtaWdodA0KPiA+IGhlbHAuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiA+IEN1cnRpcw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogSm9obiBF IERyYWtlIFttYWlsdG86amRyYWtlQGp1bmlwZXIubmV0XQ0KPiA+ID4gPiA+ID4gPiA+IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDE6NTkgUE0NCj4gPiA+ID4gPiA+ID4gPiBUbzogSWdv ciBCcnlza2luOyBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91DQo+ID4gPiA+ID4g PiA+ID4gQmVyZ2VyDQo+ID4gPiA+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnOw0KPiA+ID4g PiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0 Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSRTogW0NDQU1QXSBDb21tZW50IG9uDQo+ ID4gPiA+ID4gPiA+ID4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50 eHQNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFdoYXQgZG8geW91IG1lYW4gYnkg ImRpZmZlcmVudCBzd2l0Y2hjYXBzIj8NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gPiA+IEZyb206IGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC0NCj4gPiBib3VuY2VzQGlldGYub3Jn XSBPbg0KPiA+ID4gPiA+ID4gPiA+ID4gQmVoYWxmIE9mIElnb3IgQnJ5c2tpbg0KPiA+ID4gPiA+ ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgMTA6NTMgQU0NCj4gPiA+ID4g PiA+ID4gPiA+IFRvOiBTbmlnZGhvIEJhcmRhbGFpOyBGYXRhaSBaaGFuZzsgTG91IEJlcmdlcg0K PiA+ID4gPiA+ID4gPiA+ID4gQ2M6IGNjYW1wQGlldGYub3JnOw0KPiA+ID4gPiA+ID4gPiA+ID4g ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZw0KPiA+ ID4gPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBvbg0KPiA+ID4gPiA+ ID4gPiA+ID4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0NCj4gPiA+ID4g PiA+ID4gPiA+IDAxLnR4dA0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IFNu aWdkaG8sDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiA+ID1EOCAgSSB0aGluayB3ZSBuZWVkIHRvIHNvcnQgb3V0IHRoZSBpc3N1ZXMgd2l0aCB0 aGUNCj4gPiBmcmFtZXdvcmsNCj4gPiA+ID4gPiA+ID4gPiA+IGRvY3VtZW50IGJlZm9yZSB3ZSBj YW4gZW1iYXJrIG9uIGFueSBwcm9wb3NhbHMgdG8gdGhlDQo+ID4gcHJvYmxlbS4NCj4gPiA+ID4g PiBJDQo+ID4gPiA+ID4gPiBhbQ0KPiA+ID4gPiA+ID4gPiA+ID4gc3RpbGwgbm90IGNsZWFyIHdo eSBkbyB3ZSBoYXZlIHRvIGRldmlhdGUgZnJvbSB0aGUNCj4gPiBnZW5lcmFsDQo+ID4gPiA+ID4g PiBhcHByb2FjaA0KPiA+ID4gPiA+ID4gPiA+ID4gdGhhdCBoYXMgYmVlbiBlc3RhYmxpc2hlZCBp biBSRkMgNDIwMi4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IElCPj4gQWdyZWUgYWJzb2x1dGVseS4gR01Q TFMgaXMgaW5oZXJlbnRseSBtdWx0aS1sYXllcg0KPiA+IGNvbnRyb2wNCj4gPiA+ID4gPiA+ID4g PiA+IElCPj4gcGxhbmUsIGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gaXQgaXMgaGlnaGx5IGRlc2ly YWJsZSB0byBhZGhlcmUgdG8gdGhlIGxheWVyDQo+ID4gPiA+ID4gPiA+ID4gPiBpbmRlcGVuZGVu dA0KPiA+ID4gPiA+ID4gcGFyYWRpZ20NCj4gPiA+ID4gPiA+ID4gPiA+IG9mIGFkdmVydGlzaW5n IG9mIFRFIGxpbmtzLCBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvDQo+ID4gaW52ZW50IGFuDQo+ ID4gPiA+ID4gPiBPVE4NCj4gPiA+ID4gPiA+ID4gPiA+IHNwZWNpZmljIElTQ0QuIFRoZSBjb21i aW5hdGlvbiBvZiBTd2l0Y2hpbmcgQ2FwYWJpbGl0eQ0KPiA+IGFuZA0KPiA+ID4gPiA+ID4gRW5j b2RpbmcNCj4gPiA+ID4gPiA+ID4gPiA+IHR5cGUgb2YgUkZDNDIwMiBJU0NEIGFsbG93cyBmb3Ig c3BlY2lmeWluZyBib3RoDQo+ID4gbXVsdGlwbGV4aW5nDQo+ID4gPiA+ID4gPiA+ID4gPiBjYXBh YmlsaXRpZXMgYW5kIE9UTiBsYXllciAoTE8sIEhPLCBTSE8pIG9mIGFuIE9UTg0KPiBsaW5rLA0K PiA+IGFuZCwNCj4gPiA+ID4gPiBpZg0KPiA+ID4gPiA+ID4gPiA+ID4gdGhpcyBub3Qgc3VmZmlj aWVudCwgeW91IGhhdmUgYW5vdGhlciByZXNlcnZlZCAxNiBiaXRzLg0KPiA+ID4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ ID4gPkFkZGl0aW9uYWxseSwgSSBkbyBub3Qgc2VlIGFueSByZWFzb24gdG8gYWR2ZXJ0aXNlIGEN Cj4gPiA+ID4gPiA+ID4gPiA+ID5uZXcgVEUtbGluaw0KPiA+ID4gPiA+ID4gPiB0bw0KPiA+ID4g PiA+ID4gPiA+ID4gcmVwcmVzZW50ID50aGUgbG93LW9yZGVyIE9EVWogYmFuZHdpZHRoIHdpdGhp biB0aGUNCj4gaGlnaC0NCj4gPiBvcmRlcg0KPiA+ID4gPiA+ID4gPiBjb250YWluZXJzLg0KPiA+ ID4gPiA+ID4gPiA+ID4gVGhpcyBpcyBzaW1wbHkgPmJsb3dpbmcgdXAgdGhlIHNvbHV0aW9uIHRv IGEgdmVyeQ0KPiBzaW1wbGUNCj4gPiA+ID4gPiBwcm9ibGVtLg0KPiA+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g SUI+PiBIZXJlIEkgZGlzYWdyZWUuIEluIG9yZGVyIHRvIGdpdmUgYSB1c2VyDQo+ID4gPiA+ID4g PiA+ID4gPiBJQj4+IHBvc3NpYmlsaXR5DQo+ID4gdG8NCj4gPiA+ID4gPiA+IGNyZWF0ZQ0KPiA+ ID4gPiA+ID4gPiA+ID4gSUI+PiBPVE4NCj4gPiA+ID4gPiA+ID4gPiA+IGhpZXJhcmNoaWVzIGFu ZCBjb25zdHJhaW4gTE8gY29ubmVjdGlvbnMgdG8gSE8NCj4gPiBjb250YWluZXJzLCBvbmUNCj4g PiA+ID4gPiA+ID4gbmVlZHMNCj4gPiA+ID4gPiA+ID4gPiA+IHRvIGFkdmVydGlzZSBPVE4gbGlu a3Mgd2l0aCBkaWZmZXJlbnQgc3dpdGNoY2Fwcy4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IENoZWVycywN Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBJZ29yDQo+ID4gPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4gPiBSZWdhcmRzDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gU25pZ2Ro bw0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+ID4gRnJvbTogRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFp QGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDcs IDIwMTAgNjozMyBQTQ0KPiA+ID4gPiA+ID4gPiA+ID4gVG86IFNuaWdkaG8gQmFyZGFsYWk7IExv dSBCZXJnZXINCj4gPiA+ID4gPiA+ID4gPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsNCj4gPiA+ID4g PiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0 Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24N Cj4gPiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmst DQo+ID4gPiA+ID4gPiA+ID4gPiAwMS50eHQNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IEhpIFNuaWdkaG8g YW5kIExvdSwNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IFllcywgd2UgaGF2ZSBsb3RzIG9mIG9mZi1saW5l IGRpc2N1c3Npb25zIGFtb25nIGF1dGhvcnMNCj4gPiBhbmQNCj4gPiA+ID4gPiA+ID4gPiA+IG90 aGVyIGludGVyZXN0ZWQgZXhwZXJ0cywgYW5kIHdlIHRoaW5rIHRoZSBwcm9wb3NhbA0KPiA+IGRl c2NyaWJlZA0KPiA+ID4gPiA+IGluDQo+ID4gPiA+ID4gPiAiZHJhZnQtDQo+ID4gPiA+ID4gPiA+ ID4gPiBjZWNjYXJlbGxpLWNjYW1wLWdtcGxzLW9zcGYtZzcwOSIgW09TUEYtRW5jb2RpbmddIGRy YWZ0DQo+ID4gaXMgbW9yZQ0KPiA+ID4gPiA+ID4gPiA+ID4gZmVhc2libGUgZm9yIE9UTiBuZXR3 b3Jrcy4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IFRoZSBmcmFtZXdvcmsgZHJhZnQganVzdCB0ZWxscyB5 b3Ugd2hhdCBpbmZvcm1hdGlvbg0KPiA+IG5lZWRlZCBmb3INCj4gPiA+ID4gPiA+ID4gPiA+IGNv bnRyb2wgcGxhbmUsIG5vIG1hdHRlciBob3cgeW91IGVuY29kZSB0aGUgcm91dGluZw0KPiA+ID4g PiA+IGluZm9ybWF0aW9uLg0KPiA+ID4gPiA+ID4gPiBGb3INCj4gPiA+ID4gPiA+ID4gPiA+IFRE TSBuZXR3b3JrcywgeW91IGtub3cgdGhlIHJlc291cmNlIGlzIGFsbG9jYXRlZCBiYXNlZA0KPiA+ ID4gPiA+ID4gPiA+ID4gb24NCj4gPiBUUywNCj4gPiA+ID4gPiBzbw0KPiA+ID4gPiA+ID4gPiB0 aGUNCj4gPiA+ID4gPiA+ID4gPiA+IGF2YWlsYWJsZSBUUyBzaG91bGQgYmUgZ2V0IG9yIGluZHVj ZWQgYmVmb3JlIGNyZWF0aW5nDQo+ID4gY3Jvc3MtDQo+ID4gPiA+ID4gPiA+IGNvbm5lY3QuDQo+ ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4gPiBJZiB5b3UgYXJlIHRyeWluZyB0byBmaW5kIGhvdyB0byBlbmNvZGUg dGhlIHJvdXRpbmcNCj4gPiA+ID4gPiBpbmZvcm1hdGlvbiwNCj4gPiA+ID4gPiA+IEkNCj4gPiA+ ID4gPiA+ID4gPiA+IHRoaW5rIHlvdSBuZWVkIGdvIHRvIHRoZSByb3V0aW5nIGRyYWZ0cyAoaW5m byBtb2RlbCBhbmQNCj4gPiA+ID4gPiA+IGVuY29kaW5nKS4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IElm IHlvdSBsb29rIGF0IHRoZSByb3V0aW5nIGRyYWZ0cyAoaW5mbyBtb2RlbCBhbmQNCj4gPiBlbmNv ZGluZyksDQo+ID4gPiA+ID4geW91DQo+ID4gPiA+ID4gPiA+ID4gPiB3aWxsIGZpbmQgdGhhdCBv bmUgb2YgeW91ciBzdWdnZXN0aW9ucyBpcyBhZG9wdGVkDQo+IChpLmUuLA0KPiA+IHNpbXBseQ0K PiA+ID4gPiA+ID4gPiA+ID4gYWR2ZXJ0aXplIHRoZSBhdmFpbGFibGUgbnVtYmVyIG9mIE9EVTAs IE9EVTEsIE9EVTIsDQo+IC4uLiwNCj4gPiBPRFU0DQo+ID4gPiA+ID4gPiA+IGNvbnRhaW5lciBp bnN0YW5jZXMpLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gT25lIG1vcmUgdGhpbmcgZm9yIHlvdXIgZmly c3QgY29tbWVudDoNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBJZiB5b3Ug Y3JlYXRlIGFuIE9EVTIgTFNQICh1c3VhbGx5IG92ZXIgbXVsdGkgT1RVMw0KPiA+ID4gPiA+ID4g PiA+ID4gbGlua3MpDQo+ID4gYXMgRkENCj4gPiA+ID4gPiA+IGZvcg0KPiA+ID4gPiA+ID4gPiA+ ID4gT0RVMSwgeW91IGhhdmUgdG8gYWR2ZXJ0aXNlIGEgbmV3IFRFIGxpbmsgb3IgcHV0IHRoaXMN Cj4gRkENCj4gPiBhcyBhDQo+ID4gPiA+ID4gPiA+ID4gPiBjb21wb25lbnQgbGluayBvZiBhbiBl eGlzdGluZyBURSBsaW5rIChsaWtlDQo+IFJGQzQyMDZiaXMpLg0KPiA+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g QmVzdCBSZWdhcmRzDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gRmF0YWkN Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gPiA+IEZyb206ICJTbmlnZGhvIEJhcmRhbGFpIiA8U0JhcmRhbGFpQGluZmluZXJhLmNv bQ0KPiA+ID4gPiA+ID4gPiA+ID4gPG1haWx0bzpTQmFyZGFsYWlAaW5maW5lcmEuY29tPiA+DQo+ ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gVG86ICJMb3UgQmVyZ2VyIiA8bGJl cmdlckBsYWJuLm5ldA0KPiA+IDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4gPg0KPiA+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IENjOiA8Y2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4gPjsNCj4gPiA+ID4gPiA+ID4gPiA+IDxkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLSBnNzA5LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+ID4gPG1h aWx0bzpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktDQo+ID4gPiA+ID4gPiA+ID4gPiBmcmFt ZXdvcmtAdG9vbHMuaWV0Zi5vcmc+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDcsIDIwMTAgMTE6NDMgUE0NCj4gPiA+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21tZW50IG9u DQo+ID4gPiA+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3Jr LQ0KPiA+ID4gPiA+ID4gPiA+ID4gMDEudHh0DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IEhpIExvdQ0K PiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBUaGFua3MsIEkgYWxzbyB3 b3VsZCBsaWtlIHRvIGhlYXIgYWJvdXQgdGhlIHNhbWUuDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4gPiA+IFNuaWdkaG8NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gPiA+ ID4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+ID4gPiA+ID4g PiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCA4OjM3IEFNDQo+ID4gPiA+ ID4gPiA+ID4gPiA+IFRvOiBTbmlnZGhvIEJhcmRhbGFpDQo+ID4gPiA+ID4gPiA+ID4gPiA+IENj OiBjY2FtcEBpZXRmLm9yZyA8bWFpbHRvOmNjYW1wQGlldGYub3JnPiA7DQo+ID4gPiA+ID4gPiA+ ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtDQo+ID4gPiA+ID4gPiA+ID4gPiBnNzA5LWZy YW1ld29ya0B0b29scy5pZXRmLm9yZyA8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtDQo+ID4gZ21w bHMtDQo+ID4gPiA+ID4gPiBnNzA5LQ0KPiA+ID4gPiA+ID4gPiA+ID4gZnJhbWV3b3JrQHRvb2xz LmlldGYub3JnPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21t ZW50IG9uDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1m cmFtZXdvcmstDQo+ID4gPiA+ID4gPiA+ID4gPiAwMS50eHQNCj4gPiA+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiA+ID4gU25pZ2RobywNCj4gPiA+ID4gPiA+ID4gPiA+ID4gSSBiZWxp ZXZlIHRoZXJlIGhhcyBiZWVuIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBvbg0KPiA+IGhvdyB0 bw0KPiA+ID4gPiA+ID4gPiBiZXR0ZXINCj4gPiA+ID4gPiA+ID4gPiA+ID4gYWxpZ24gdGhlIHdv cmsgd2l0aCA0MjAyLiAgVXNlIG9mIGNvbW1vbiBhcHByb2FjaGVzDQo+IGlzDQo+ID4gb2YNCj4g PiA+ID4gPiA+IGNvdXJzZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiBvbmUgb2YgdGhlIG1haW4gb2Jq ZWN0aXZlcyBvZiAqQypDQU1QLiAgSSBsb29rDQo+IGZvcndhcmQNCj4gPiB0bw0KPiA+ID4gPiA+ ID4gaGVhcmluZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiBmcm9tIHRoZSBkcmFmdCBhbmQgZGlzY3Vz c2lvbiBjb250cmlidXRvcnMgb24gdGhlcmUNCj4gPiBwcm9ncmVzcw0KPiA+ID4gPiA+ID4gPiA+ ID4gPiBvbg0KPiA+ID4gPiA+ID4gPiB0aGlzIHBvaW50Lg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+ID4gPiBMb3UNCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiA+ID4gT24gNy82LzIwMTAgMzo1OSBQTSwgU25pZ2RobyBCYXJkYWxhaSB3cm90ZToNCj4g PiA+ID4gPiA+ID4gPiA+ID4+IEhlbGxvLA0KPiA+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+ID4gPiA+ID4+IEkgaGF2ZSBhIGNvbW1lbnQgYW5kIGEgcXVlc3Rpb24gb24gU2VjdGlvbiAz LjEuMi4xLg0KPiA+IFRoaXMNCj4gPiA+ID4gPiA+IHNlY3Rpb24NCj4gPiA+ID4gPiA+ID4gPiA+ ID4+IGRlc2NyaWJlcyB0aGUgbGluay1wYXJhbWV0ZXJzIHRoYXQgYXJlIHJlcXVpcmVkIGZvcg0K PiA+IE9UTg0KPiA+ID4gPiA+ID4gc2VydmljZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gcm91dGlu ZyBwdXJwb3Nlcy4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBN eSBjb21tZW50IGlzIGhvdyBhcmUgd2UgZ29pbmcgdG8gYWR2ZXJ0aXNlIHRoZSBsb3ctDQo+ID4g b3JkZXINCj4gPiA+ID4gPiA+ID4gPiA+ID4+IE9EVWogYXZhaWxhYmlsaXR5IHdpdGhpbiBhIGhp Z2hlci1vcmRlciBjb250YWluZXIuDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBGb3IgZXhhbXBsZSwg Y29uc2lkZXIgYW4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IE9UVTMgbGluayB3aGljaCBoYXMgMTYg dGltZS1zbG90cyBvZiAyLjVHDQo+IGdyYW51bGFyaXR5DQo+ID4gYW5kDQo+ID4gPiA+ID4gPiA+ ID4gPiA+PiB0aGVuDQo+ID4gPiA+ID4gPiA+IHdlDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBlc3Rh Ymxpc2ggYW4gT0RVMiBzZXJ2aWNlIG92ZXIgdGhlIGxpbmsuIEF0IHRoaXMNCj4gPiA+ID4gPiA+ ID4gPiA+ID4+IHBvaW50DQo+ID4gaW4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IHRpbWUgdGhlIE9U VTMgbGluayBoYXMgMTIgdGltZS1zbG90cyBhdmFpbGFibGUgZm9yDQo+ID4gT0RVMg0KPiA+ID4g PiA+ID4gPiA+ID4gPj4gc2VydmljZXMNCj4gPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4gPiA+ ID4gPj4gdXAgdG8gMTIrNCB0aW1lLXNsb3RzIGF2YWlsYWJsZSBmb3IgT0RVMSBzZXJ2aWNlcyAo NA0KPiA+IE9EVTFzDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBhcmUgY29udGFpbmVkIG92ZXIgdGhl IE9EVTIpLiBTbyBpdCBpcyBvYnZpb3VzIGZyb20NCj4gPiB0aGlzDQo+ID4gPiA+ID4gPiA+ID4g PiA+PiBleGFtcGxlDQo+ID4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IHRo ZSBudW1iZXIgb2YgdGltZS1zbG90cyBhdmFpbGFibGUgaXMgZGlmZmVyZW50DQo+IGJhc2VkDQo+ ID4gb24gdGhlDQo+ID4gPiA+ID4gPiA+IHNpZ25hbC10eXBlIChpLmUuIE9EVTEgYW5kIE9EVTIp Lg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gSG93IGRvIHdlIGFkZHJlc3MgdGhpcyBpc3N1ZSBiYXNl ZCBvbiB0aGUgYXBwcm9hY2gNCj4gPiBzcGVjaWZpZWQNCj4gPiA+ID4gPiA+IGluDQo+ID4gPiA+ ID4gPiA+ID4gPiA+PiB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+IGRyYWZ0Pw0KPiA+ID4gPiA+ID4g PiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IE15IG90aGVyIHF1ZXN0aW9uIGlzIHdoeSBu b3Qgc2ltcGx5IGFkdmVydGl6ZSB0aGUNCj4gPiBhdmFpbGFibGUNCj4gPiA+ID4gPiA+ID4gPiA+ ID4+IG51bWJlciBvZiBPRFUwLCBPRFUxLCBPRFUyLCAuLi4sIE9EVTQgY29udGFpbmVyDQo+ID4g aW5zdGFuY2VzIG9yDQo+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IGVxdWl2 YWxlbnQgYmFuZHdpZHRoIGluIGJ5dGVzL3NlYyB3aXRoaW4gYSBsaW5rPw0KPiBUaGlzDQo+ID4g PiA+ID4gPiA+ID4gPiA+PiBhcHByb2FjaCBzZWVtcyB0byBiZSBtb3JlIGluLWxpbmUgd2l0aCB0 aGUgZ2VuZXJhbA0KPiA+IGFwcHJvYWNoDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBvdXRsaW5lZCBp biBSRkMtNDIwMi4gUmVmZXIgdG8NCj4gPiA+ID4gPiA+ID4gPiA+IHNlY3Rpb24NCj4gPiA+ID4g PiA+ID4gPiA+ID4+IDMuNCBpbiBSRkMgNDIwMiBmb3IgYW4gZXhhbXBsZSB0aGF0IHNob3dzIG11 bHRpcGxlDQo+ID4gSVNDRHMNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IGJlaW5nIGFkdmVydGlzZWQg cGVyIFZDIHJhdGUgZm9yIGFuIFNESCBsaW5rLiBUaGUNCj4gPiBhZGRpdGlvbmFsDQo+ID4gPiA+ ID4gPiA+ID4gPiA+PiBiZW5lZml0DQo+ID4gPiA+ID4gPiA+IGlzDQo+ID4gPiA+ID4gPiA+ID4g PiA+PiB0aGF0IHRoZSBhZHZlcnRpc2VtZW50IGlzIFRTIHNpemUgaW5kZXBlbmRlbnQgYW5kDQo+ ID4gaGVuY2Ugd2lsbA0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gc2ltcGxpZnkgdGhlIGltcGxlbWVu dGF0aW9uLg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IFJlZ2Fy ZHMNCj4gPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBTbmlnZGhvDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1Q IG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg== From sergio.belotti@alcatel-lucent.com Wed Jul 21 07:58:46 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22A93A697B for ; Wed, 21 Jul 2010 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRQBqCVo6rNZ for ; Wed, 21 Jul 2010 07:58:43 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 5B8A63A6774 for ; Wed, 21 Jul 2010 07:58:42 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6LEwdfK032639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Jul 2010 16:58:43 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 21 Jul 2010 16:58:42 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin Date: Wed, 21 Jul 2010 16:58:39 +0200 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAWbSJAAAog3yAAAm+/cAACFVOw Message-ID: References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT."<201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 14:58:46 -0000 Igor, For point 1) and 2) I do not think we are so far. You're proposing a three-layer approach , we are aligned with what ITU is p= roposing but we also have different roles in the network (lambda and sub-la= mbda) and than needs for constrains and policy in the network. The fact to have three switching capability to characterize the different r= oles in the same technology it seems to me a little against the concept of = switching capability itself. You could say that for packet there is already 4 PSC SC defined. But here w= e are in TDM , we have not label stacking capability. For point 3) and 4) , I do not discuss about the generality or not of the i= ssue, but surely you cannot negate that the problem of spatial allocation i= s raised as soon as SDH CP has been implemented . Then the same problem com= e in for OTN , and your intention to cope the issue in a generic way with m= odifications of RFC 4203 is a good intention, but take also into account th= at also our proposed format can be generic as soon as you change the signal= types supported. You're right we need to discuss face to face but my perception is that we c= a be less far than you believe. Cheers Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: mercoled=EC 21 luglio 2010 15.51 A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho= Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t We need to discuss this face to face. The biggest disagreements with Daniel= e are: 1) I don't believe that flat routing model of a multi-layer OTN network is = correct. 2) I think each OTN role defines a separate topology of OTN links, and ther= e is a need to be able to constrain the routing of a given OTN connection t= o one or more (but not necessarily all) such topologies; 3) There is an issue in the current definitions of GMPLS OSPF extensions (R= FC 4203), which does allow to specify multiple ISCDs but does not guide as = to how the available bandwidth on the link is partitioned between ISCDs. Th= is is a generic issue and should be resolved in a generic way; 4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE= and routing in OTN networks. Unless we see strong reasons to the contrary = we should not invent such machinery. Cheers, Igor -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Wednesday, July 21, 2010 8:30 AM To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; Snigd= ho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I support this as well, of course. Whether this is a technology-specific e= xtension of the ISCD format or a separate sub-TLV is a detail, however as D= aniele points out many of the same considerations apply to both OTN and SON= ET/SDH. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, July 21, 2010 12:49 AM To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, In other words it could be possible to define 3 Switching Cap (LO, HO and S= HO) and put what we defined in the encoding draft into the Switching Capabi= lity-specific information of the ISCD. Something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----S= witching Capability-specific information |0|1|2|3|4|5|6|7| T | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I still don't understand why we need partitioning the network in three laye= rs while just Sublamba and Full lambda distinction is enough (distinction s= upported advertising different signal types for full lambdas and sublambdas= . Personally i still prefer advertising these pieces of information as a sepa= rate sub-TLV (called OTN-ISCD subTLV in the draft but easily estensible to = TDM-ISCD accordingly to http://tools.ietf.org/html/draft-ong-gmpls-ason-rou= ting-exper-02 format proposed by the OIF) but this could be a valid solutio= n too. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: marted=EC 20 luglio 2010 23.02 To: John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved bandwi= dth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? You= do not advertise unreserved bandwidth in the ISCD TLV. In particular, for= TDM, what is advertised is the max and min bandwidth allowed for a single = LSP. It was designed to produce a compact representation by taking advanta= ge of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but wasteful= . > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done > > > in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > > > > a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level. > > > > IB>> However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > IB>> unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > path computation is constrained to the OTN_HO_SC topology, > > > > > > B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing > > > > > > the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ; > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology > > > > > > is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > switching capability field (confusing name as it is) is a > > > > > > good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > IB>> etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > > > > > > is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > >new TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > IB>> possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based > > > > > > > > on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > >> For example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > >> point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Wed Jul 21 08:21:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A42B3A68AE for ; Wed, 21 Jul 2010 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWJr+vR--z0e for ; Wed, 21 Jul 2010 08:21:25 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 5BC933A6359 for ; Wed, 21 Jul 2010 08:21:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTEcQgL62+o0SpB8j1hi/E278awKB+a8p@postini.com; Wed, 21 Jul 2010 08:21:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 21 Jul 2010 07:37:13 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" Date: Wed, 21 Jul 2010 07:37:11 -0700 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZF1vMQS7bro1SIquJeHidp6adgAcGo3QAAM83SA= Message-ID: <5E893DB832F57341992548CDBB33316398448E10A1@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 14:20:42 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:21:27 -0000 Igor, The normal case is that the advertised unreserved bandwidth is available to= *all* of the advertised ISCDs. That is why it was designed the way it was= . If we want to advertise unreserved bandwidth by service category, then that= is what we should do, rather than trying to carve up unreserved bandwidth = with percentages. It doesn't fit the normal case and enforces a rigid stru= cture. Thanks, John=20 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Wednesday, July 21, 2010 6:15 AM > To: curtis@occnc.com > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > Curtis, >=20 > I agree with all you said. The question is that if a single TE LINK TLV > contains several ISCDs sub-TLVs and a single "Maximum Reservable > Bandwidth" sub-TLV, how the available bandwidth can be partitioned > between ISCDs, so that a path computer making use of the TE LINK TLV > could figure out how many LSPs of each type (associated with each ISCD) > could be placed on the link. Again, this information is not needed when > paths are computed for one service at a time, but useful for con- > current path computations when several LSPs are (re-)placed at the same > time (e.g. in case of restoration after a failure of a link carrying > multiple LSPs). >=20 > Cheers, > Igor >=20 > P.S. [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] >=20 > I never do that. > Igor >=20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 7:36 PM > To: Igor Bryskin > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > Bardalai > Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 >=20 > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > The point is that from ISCD you can not figure out how *many* LSPs > > matching the ISCD you can accommodate on the link. Such information > is > > important in case of con-current routing (e.g. restoration after link > > failure). > > > > Igor >=20 > Igor, Sergio, >=20 > RFC 4203 (in 1. Introduction) >=20 > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: >=20 > [OSPF-TE] above is RFC 3630. >=20 > RFC 3630 (in 2.4.2. Link TLV) >=20 > The following sub-TLVs of the Link TLV are defined: >=20 > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) >=20 > If you read on you find: >=20 > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). >=20 > and >=20 > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] >=20 > So the totals per link and per priority level are already there in the > base spec before the RFC 4203 *extensions* to RFC 3630 were added. >=20 > That is how you figure out how many ODU0 you can add to your existing > ODU2, and so on. >=20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] >=20 > Curtis >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > >From RFC 4202: > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > priority p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > > > Typical values for the Minimum LSP Bandwidth and for the Maximum > LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > On an interface having Standard SDH multiplexing, an LSP at > priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined > by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > priority > > p. > > > > On an interface having Arbitrary SDH multiplexing, an LSP at > priority > > p could reserve any bandwidth between the Minimum LSP Bandwidth > and > > the Maximum LSP Bandwidth at priority p, provided that the > bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > > > >From RFC 4201: > > > > 3.10. Maximum LSP Bandwidth > > > > The Maximum LSP Bandwidth takes the place of the Maximum > Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP > Bandwidth > > at priority p of all of its component links. > > > > > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > Snipped.... > > > > > > > > > > > I realized from someone in this thread (not from you) this was > due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > > > > > JD: As the person to whom I believe you are referring, I would > suggest > > > that you actually read RFC 4202 and 4206. > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jul 21 08:34:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0F23A67F4 for ; Wed, 21 Jul 2010 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG2nouhkGmJE for ; Wed, 21 Jul 2010 08:33:58 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 56D723A6359 for ; Wed, 21 Jul 2010 08:33:58 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LFY4Ll022533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 17:34:04 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 17:34:04 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 21 Jul 2010 17:34:03 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 11:34:01 -0400 From: Igor Bryskin To: John E Drake , "curtis@occnc.com" Date: Wed, 21 Jul 2010 11:33:51 -0400 Thread-Topic: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoZF1vMQS7bro1SIquJeHidp6adgAcGo3QAAM83SAAAeKIEA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7638E@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 14:20:42 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398448E10A1@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316398448E10A1@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_07:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:34:00 -0000 I agree. All I am saying is that there is a need for a technology independe= nt enhancement to 4203 to address the issue of concurrent path computations= .=20 Igor=20 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Wednesday, July 21, 2010 10:37 AM To: Igor Bryskin; curtis@occnc.com Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01= .txt=20 Igor, The normal case is that the advertised unreserved bandwidth is available to= *all* of the advertised ISCDs. That is why it was designed the way it was= . If we want to advertise unreserved bandwidth by service category, then that= is what we should do, rather than trying to carve up unreserved bandwidth = with percentages. It doesn't fit the normal case and enforces a rigid stru= cture. Thanks, John=20 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Wednesday, July 21, 2010 6:15 AM > To: curtis@occnc.com > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > Bardalai > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > Curtis, >=20 > I agree with all you said. The question is that if a single TE LINK TLV > contains several ISCDs sub-TLVs and a single "Maximum Reservable > Bandwidth" sub-TLV, how the available bandwidth can be partitioned > between ISCDs, so that a path computer making use of the TE LINK TLV > could figure out how many LSPs of each type (associated with each ISCD) > could be placed on the link. Again, this information is not needed when > paths are computed for one service at a time, but useful for con- > current path computations when several LSPs are (re-)placed at the same > time (e.g. in case of restoration after a failure of a link carrying > multiple LSPs). >=20 > Cheers, > Igor >=20 > P.S. [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] >=20 > I never do that. > Igor >=20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 7:36 PM > To: Igor Bryskin > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > Bardalai > Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 >=20 > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > The point is that from ISCD you can not figure out how *many* LSPs > > matching the ISCD you can accommodate on the link. Such information > is > > important in case of con-current routing (e.g. restoration after link > > failure). > > > > Igor >=20 > Igor, Sergio, >=20 > RFC 4203 (in 1. Introduction) >=20 > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: >=20 > [OSPF-TE] above is RFC 3630. >=20 > RFC 3630 (in 2.4.2. Link TLV) >=20 > The following sub-TLVs of the Link TLV are defined: >=20 > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) >=20 > If you read on you find: >=20 > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). >=20 > and >=20 > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] >=20 > So the totals per link and per priority level are already there in the > base spec before the RFC 4203 *extensions* to RFC 3630 were added. >=20 > That is how you figure out how many ODU0 you can add to your existing > ODU2, and so on. >=20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] >=20 > Curtis >=20 >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > >From RFC 4202: > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > priority p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > > > Typical values for the Minimum LSP Bandwidth and for the Maximum > LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > On an interface having Standard SDH multiplexing, an LSP at > priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined > by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > priority > > p. > > > > On an interface having Arbitrary SDH multiplexing, an LSP at > priority > > p could reserve any bandwidth between the Minimum LSP Bandwidth > and > > the Maximum LSP Bandwidth at priority p, provided that the > bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > > > >From RFC 4201: > > > > 3.10. Maximum LSP Bandwidth > > > > The Maximum LSP Bandwidth takes the place of the Maximum > Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP > Bandwidth > > at priority p of all of its component links. > > > > > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > Snipped.... > > > > > > > > > > > I realized from someone in this thread (not from you) this was > due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > > > > > JD: As the person to whom I believe you are referring, I would > suggest > > > that you actually read RFC 4202 and 4206. > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Wed Jul 21 08:40:50 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D173A6974 for ; Wed, 21 Jul 2010 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lv+7oi3VvNo for ; Wed, 21 Jul 2010 08:40:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 472893A6900 for ; Wed, 21 Jul 2010 08:40:46 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LFes5B085212; Wed, 21 Jul 2010 11:40:54 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007211540.o6LFes5B085212@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 15:17:02 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7619B@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 11:40:54 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:40:50 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7619B@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > Curtis, > > > > Curtis, > > > > I agree with your concerns about cranbacks. I never liked solutions > > that rely on crankbacks. But what I was saying is that path > > computation in the described example will be able to figure that the > > path is not feasible, hence the ingress node will know that without > > signaling failure. > > > > Cheers and hope to see you in Maastricht. > > Igor > > > Igor, > > I don't follow that. Are you claiming that the PathErr is > significantly different from crankback? Or did I miss something about > the example? > > IB>> Curtis, I don't follow you either. When did I mention either crankback or pathErr? I was saying that not feasible paths should be failed by path computation. The advertising based solely on 4203 has everything to achieve that. I'm not sure who wrote this since your style of "quoting" does not make it clear. I thought I was responding to a comment from you. > > Please see the text from RFC3473: "Nodes MUST verify that the type > > indicated in the Switching Type parameter is supported on the > > corresponding incoming interface. If the type cannot be > > supported, > > the node MUST generate a PathErr message with a "Routing > > problem/Switching Type" indication." In any case, we are in agreement that crankback should be avoided. > Igor Curtis > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 20, 2010 10:52 AM > > To: Fatai Zhang > > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > > Fatai Zhang writes: > > > > > > Hi Igor, > > > > > > Thanks. > > > > Sorry to jump in but I think I understand Igor's objection (and > > Snigdho's objection, and the reason this thread is going on). > > > > > I understand what you said. Therefore, we have added some text to > > > address the requirment in FWK document. However, we still don't think > > > that we need to extend ISC to meet the requirment. The role of the ODU > > > can be get from the routing information implicitly. In the > > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" is introduced. > > > > > > A quick question on your statement: "the role of an ODU container does > > > not change hop-by-hop (as some people seem to believe). The role is > > > only meaningful on the ODU terminating nodes and irrelevant on transit > > > nodes. It is it's position in the hierarchy (but not role) that may > > > change hop-by-hop. " > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and CI1 > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only support > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the role > > > of Ho ODU level is requested, according to your statement, this > > > conneciton will be allowed to be created. However, it should not be > > > allowed because the ISC is not consistent along the LSP. > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the type > > > indicated in the Switching Type parameter is supported on the > > > corresponding incoming interface. If the type cannot be supported, > > > the node MUST generate a PathErr message with a "Routing > > > problem/Switching Type" indication." > > > > I think the objection, which would be a very valid one, is that the > > ingress has no way to know apriori that a path is infeasible. Each > > crankback delays convergence. Crankback should only occur if another > > ingress has reserved resources before signaling was completed, not > > because inadequate routing information is provided in quiescent state. > > > > Curtis > > > > > > > Best Regards > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: "Fatai Zhang" ; > > > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Lou Berger" ; ; > > > Sent: Friday, July 16, 2010 12:34 AM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > Fatai, > > > Please, see my answers in line. > > > > > > -----Original Message----- > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > To: Igor Bryskin; curtis@occnc.com > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Hi Igor and all, > > > > > > Thanks for all your comments. > > > > > > I think role does not equal switching capability. The operators can define different roles depending on their policy and achieve the role through different methods. However, for OTN networks, the containers (e.g., ODUk) all have the same switching capablility (i.e., TDM switching) and I think we should reflect the natural characteristics of links in the routing. In addition, if we extend the ISC, it will make the encoding type lose its' own meaning(ie., ISC overrides encoding type). > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the network as a stack of topologies. Whether a given topology is real or virtual is of no importance. > > > The GMPLS ISCD link sub-tlv and, in particular, its switching capability field (confusing name as it is) is a good way to describe a layer in technology independent way, so that, say, MPLS-TP->OTN_LO->OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of topologies that could be easily separated in technology independent way should path computation be constrained to particular one or sub-stack of them. > > > I think a good way to identify an OTN (virtual) topology is via (infrastructure) ODU container role of ODUs comprising the topology. BTW IMO the role of an ODU container does not change hop-by-hop (as some people seem to believe). The role is only meaningful on the ODU terminating nodes and irrelevant on transit nodes. It is it's position in the hierarchy (but not role) that may change hop-by-hop. ODU's role is the level of topology it is provisioned for and it is the same for all ODUs that comprise the topology. For, example a user may provision a LO topology and constrain ODUs he sells to a set of clients to use the topology rather than any resources available on OTN network. > > > The bottom line: container's role is the same as the role of virtual topology the container is a part of and could be advertised as the corresponding link switchcap. > > > > > > According to the point 3, I don't know how to advertise the roles and muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > encoding type = mux. capabilities code > > > > > > In addition, could you clarify my questions in another email (copied as follows): > > > ==================================================================================================== > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > IB>> I disagree. You define role == position in the hierarchy, which is a mistake IMO. > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as Ho OTN Level or Lo OTN Level? Another example is, if there is a OTU3 link supporting ODU2 switching, which can be used as Lo ODU2 (service over ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, how to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU terminating nodes (i.e. on either side of corresponding link). What happens on the ODU transit nodes and its place in the hierarchy on the transit nodes are of no importance. My LO container can be carried by somebody else's LO container and can carry my client's LO container. To some extent it is similar to MPLS LSP role: LSP always has a role (e.g. PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its path. > > > > > > Cheers, > > > Igor > > > > > > =================================================================================================== > > > > > > > > > > > > Thanks > > > > > > Fatai > > > > > > ----- Original Message ----- > > > From: "Igor Bryskin" > > > To: > > > Cc: "John E Drake" ; "Snigdho Bardalai" ; "Fatai Zhang" ; "Lou Berger" ; ; > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > Curtis, > > > > > > Thanks for your comment. > > > > > > I agree that there should be multiple OTN specific encoding types introduced. But IMO they should indicate the link's mux capabilities rather than the link's role (i.e. level in the OTN hierarchy: LO, HO, SHO, etc.). The link's role or roles IMO should be indicated with a separate switchcaps. I can give you several reasons: > > > > > > 1. Links with the same mux capabilities may have different roles; > > > 2. Link may advertise several roles (e.g. HO and SHO) with different mux.capabilities per role; > > > 3. Link's role and mux. capabilities can be advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is required); > > > 4. The combination of swicthcaps and encoding type will look to CP as a separate layer, which is exactly how ITU models OTN hierarchies in all aspects but routing (!?) > > > 5. If the operator would want to constrain the routing of OTN connections to pre-configured topology with a specific role (e.g. constrain all ODUs it sells to the clients to one or more pre-configured LO topologies), this would be possible to do in a technology independent way. Suppose an instance of GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN links will be no different from the separation of WDM links from OTUs. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > To: Igor Bryskin > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv-exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > I think OTN links require more than one switchcaps: as many as the depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > typedef enum > > > > { > > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > > > /*****/ > > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > > > /*****/ > > > > , LSPSwitchType_LSC =150 /* LSC */ > > > > , LSPSwitchType_FSC =200 /* FSC */ > > > > }e_LSPSwitchType; > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital Path > > > layer and G.709 Optical Channel layer for 2009 OTN, which had in turn > > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > understand what the TS type meant did not try to multiplex its LO ODU > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to using > > > a 1.25 TS granularity for another LO ODU. > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the latter > > > is for backward compatibility and should be ignored if OTN_LO, OTN_HO > > > or OTN_SHO is understood. If the LSR commits to 1.25 TS granularity, > > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > > > The Encoding type would be the lower encoding at each end of the LSP > > > regardless of what goes on in the middle since that determines what > > > can be wrapped inside it. > > > > > > For example: > > > > > > OTU3 > > > OTU2 ODUk=3 -------------- > > > OTU1 ODUk=2 -- ODUj=2 > > > ODUk=1 --- ODUj=1 -- > > > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex even > > > though the ODUk=2 at the next hop could not directly contain an ODU0. > > > If the SHO Encoding Type is used, then it indicates that two levels of > > > multiplexing could be supported at that switch/LSR. > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > Types currently don't include an ODUj or ODUk distinction but if > > > Encoding Type indicated LO or HO, that may not be needed. Along with > > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU-flex, > > > and ODU2e, can be added. > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not clear > > > how in an FA it can be indicated that either type is currently > > > available (NE capable of both and hasn't committed to either one yet). > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > would indicate a huge controversy and I'm not getting it (other than a > > > strong preference to rely on bytes/sec or on enumerated type fields). > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure if > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, or > > > other intent. Could someone (either draft) concisely summarize the > > > multiplexing restrictions in one place, including restrictions on > > > number of multiplexing layers at one LSR. That might help. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > > > > > Igor Bryskin > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework document > > > > > before we can embark on any proposals to the problem. I am still not clear > > > > > why do we have to deviate from the general approach that has been > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control plane, and > > > > > it is highly desirable to adhere to the layer independent paradigm of > > > > > advertising of TE links, and there is no reason to invent an OTN specific > > > > > ISCD. The combination of Switching Capability and Encoding type of RFC4202 > > > > > ISCD allows for specifying both multiplexing capabilities and OTN layer > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, you have > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE-link to > > > > > represent >the low-order ODUj bandwidth within the high-order containers. > > > > > This is simply >blowing up the solution to a very simple problem. > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to create OTN > > > > > hierarchies and constrain LO connections to HO containers, one needs to > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > To: Snigdho Bardalai; Lou Berger > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and other > > > > > interested experts, and we think the proposal described in "draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more feasible > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for control > > > > > plane, no matter how you encode the routing information. For TDM networks, > > > > > you know the resource is allocated based on TS, so the available TS should > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing information, I think > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), you will find > > > > > that one of your suggestions is adopted (i.e., simply advertize the > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container instances). > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA for ODU1, > > > > > you have to advertise a new TE link or put this FA as a component link of > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > Cc: >; > > > > g709-framework@tools.ietf.org > > > > framework@tools.ietf.org> > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > Snigdho > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > To: Snigdho Bardalai > > > > > > Cc: ccamp@ietf.org ; draft-ietf-ccamp-gmpls- > > > > > g709-framework@tools.ietf.org > > > > framework@tools.ietf.org> > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > > > 01.txt > > > > > > > > > > > > Snigdho, > > > > > > I believe there has been some off-line discussion on how to better > > > > > > align the work with 4202. Use of common approaches is of course one of > > > > > > the main objectives of *C*CAMP. I look forward to hearing from the > > > > > > draft and discussion contributors on there progress on this point. > > > > > > > > > > > > Lou > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > >> Hello, > > > > > >> > > > > > >> I have a comment and a question on Section 3.1.2.1. This section > > > > > >> describes the link-parameters that are required for OTN service routing > > > > > >> purposes. > > > > > >> > > > > > >> My comment is how are we going to advertise the low-order ODUj > > > > > >> availability within a higher-order container. For example, consider an > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and then we > > > > > >> establish an ODU2 service over the link. At this point in time the OTU3 > > > > > >> link has 12 time-slots available for ODU2 services and up to 12+4 > > > > > >> time-slots available for ODU1 services (4 ODU1s are contained over the > > > > > >> ODU2). So it is obvious from this example that the number of time-slots > > > > > >> available is different based on the signal-type (i.e. ODU1 and ODU2). > > > > > >> How do we address this issue based on the approach specified in the > > > > > draft? > > > > > >> > > > > > >> My other question is why not simply advertize the available number of > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent > > > > > >> bandwidth in bytes/sec within a link? This approach seems to be more > > > > > >> in-line with the general approach outlined in RFC-4202. Refer to > > > > > section > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs being > > > > > >> advertised per VC rate for an SDH link. The additional benefit is that > > > > > >> the advertisement is TS size independent and hence will simplify the > > > > > >> implementation. > > > > > >> > > > > > >> Regards > > > > > >> > > > > > >> Snigdho From IBryskin@advaoptical.com Wed Jul 21 09:02:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA4C3A69B7 for ; Wed, 21 Jul 2010 09:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTIzHznba81V for ; Wed, 21 Jul 2010 09:02:44 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 7EA753A67E1 for ; Wed, 21 Jul 2010 09:02:42 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LG2Y1g028958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 18:02:34 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 18:02:34 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 21 Jul 2010 18:02:33 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 12:02:31 -0400 From: Igor Bryskin To: "BELOTTI, SERGIO (SERGIO)" Date: Wed, 21 Jul 2010 12:02:23 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcsoQl4iXRU+o9jgTfubD7V7OVDq3gAAtHuAAAFIarAAANwmsAAWbSJAAAog3yAAAm+/cAACFVOwAAIrqXA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 09:21:53 PDT."<201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com><5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net><052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_07:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 16:02:49 -0000 Hi Sergio, I'd like to run with you the following logic. 1. Suppose an operator after some planning decides to provision an infrastr= ucture ODU and use it as a link. Why would he do so? One reason that I can= think of is because he wants to build a virtual topology for a set of clie= nts (with possibly himself as one from the set). The purpose of this topolo= gy, generally speaking, is: a) To be non-congruent with underlying topology (virtual or OTU/OCh). = For example, to interconnect nodes that do not have a common OTU/OCh link; b) To constrain said set of clients to resources of the topology (rath= er than, for example, to use OTU/OCh links directly). The question is how the operator can constrain the routing of the ODUs for = the clients from the set to the prepared for this purpose virtual topology = within the flat ITU routing model? 2. Would you agree that the only reason why a TE link advertises an attribu= te is to be able to constrain a path computation based on the attribute? Yo= ur definitions of the OTN encoding types, for example, are: " .... o 8 - Lambda (Photonic) o 12 - G.709 ODUk (Digital Path) .... " which will give the operator an ability to route an OTN connection either s= traight over OTUs or over infrastructure ODUs with no regard to the roles a= ssigned to the links. Do you believe this would be flexible enough for the = operator? 3. What is it you can achieve with the suggested OTN routing that can not b= e achieved using multiple 4203 ISCDs? Thanks, Igor -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, July 21, 2010 10:59 AM To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John= E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zha= ng Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, For point 1) and 2) I do not think we are so far. You're proposing a three-layer approach , we are aligned with what ITU is p= roposing but we also have different roles in the network (lambda and sub-la= mbda) and than needs for constrains and policy in the network. The fact to have three switching capability to characterize the different r= oles in the same technology it seems to me a little against the concept of = switching capability itself. You could say that for packet there is already 4 PSC SC defined. But here w= e are in TDM , we have not label stacking capability. For point 3) and 4) , I do not discuss about the generality or not of the i= ssue, but surely you cannot negate that the problem of spatial allocation i= s raised as soon as SDH CP has been implemented . Then the same problem com= e in for OTN , and your intention to cope the issue in a generic way with m= odifications of RFC 4203 is a good intention, but take also into account th= at also our proposed format can be generic as soon as you change the signal= types supported. You're right we need to discuss face to face but my perception is that we c= a be less far than you believe. Cheers Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: mercoled=EC 21 luglio 2010 15.51 A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho= Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t We need to discuss this face to face. The biggest disagreements with Daniel= e are: 1) I don't believe that flat routing model of a multi-layer OTN network is = correct. 2) I think each OTN role defines a separate topology of OTN links, and ther= e is a need to be able to constrain the routing of a given OTN connection t= o one or more (but not necessarily all) such topologies; 3) There is an issue in the current definitions of GMPLS OSPF extensions (R= FC 4203), which does allow to specify multiple ISCDs but does not guide as = to how the available bandwidth on the link is partitioned between ISCDs. Th= is is a generic issue and should be resolved in a generic way; 4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE= and routing in OTN networks. Unless we see strong reasons to the contrary = we should not invent such machinery. Cheers, Igor -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Wednesday, July 21, 2010 8:30 AM To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; Snigd= ho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I support this as well, of course. Whether this is a technology-specific e= xtension of the ISCD format or a separate sub-TLV is a detail, however as D= aniele points out many of the same considerations apply to both OTN and SON= ET/SDH. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, July 21, 2010 12:49 AM To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, In other words it could be possible to define 3 Switching Cap (LO, HO and S= HO) and put what we defined in the encoding draft into the Switching Capabi= lity-specific information of the ISCD. Something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----S= witching Capability-specific information |0|1|2|3|4|5|6|7| T | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I still don't understand why we need partitioning the network in three laye= rs while just Sublamba and Full lambda distinction is enough (distinction s= upported advertising different signal types for full lambdas and sublambdas= . Personally i still prefer advertising these pieces of information as a sepa= rate sub-TLV (called OTN-ISCD subTLV in the draft but easily estensible to = TDM-ISCD accordingly to http://tools.ietf.org/html/draft-ong-gmpls-ason-rou= ting-exper-02 format proposed by the OIF) but this could be a valid solutio= n too. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: marted=EC 20 luglio 2010 23.02 To: John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved bandwi= dth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? You= do not advertise unreserved bandwidth in the ISCD TLV. In particular, for= TDM, what is advertised is the max and min bandwidth allowed for a single = LSP. It was designed to produce a compact representation by taking advanta= ge of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but wasteful= . > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done > > > in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > > > > a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level. > > > > IB>> However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > IB>> unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > path computation is constrained to the OTN_HO_SC topology, > > > > > > B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing > > > > > > the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ; > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology > > > > > > is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > switching capability field (confusing name as it is) is a > > > > > > good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > IB>> etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > > > > > > is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > >new TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > IB>> possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based > > > > > > > > on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > >> For example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > >> point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Wed Jul 21 09:21:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD633A68D7 for ; Wed, 21 Jul 2010 09:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8NVesBVgSkq for ; Wed, 21 Jul 2010 09:21:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id D39B83A69A5 for ; Wed, 21 Jul 2010 09:21:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LGLhp5085666; Wed, 21 Jul 2010 12:21:43 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007211621.o6LGLhp5085666@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 15:44:11 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 12:21:43 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 16:21:34 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761B3@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > Curtis, > > When a link advertises two ISCDs it means that it is immediately ready > to accept an LSP of any type. Hence the TDM+PSC-4 advertisement > (albeit allowed) does not make any practical sense to me. You need, > first, create a TDM LSP, advertise it as an FA and use FA as a link > (which is likely to be a different link, because, for example, it will > have a different remote end) for PSC-4 LSP. However, if an OTN link > advertises two IDSCc - OTN_LO and OTN_HO - it is quite a different > ball game. It will mean that the link could participate in the two > topologies immediately. > > Igor TDM+LSR is the title of one of the examples in RFC 4202. In RFC 4202 the set of ICSD is: Interface Switching Capability Descriptor: Interface Switching Capability = TDM [Standard SDH] Encoding = SDH Min LSP Bandwidth = VC-3 Max LSP Bandwidth[p] = STM-64, for all p Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 10 Gbps, for all p Does RFC 4202 make sense? If so, I changed from PSC-1 as listed in RFC 4202 to PSC-4 and changed the description of it from TDM+LSR to TDM+PSC-4. If is still an FA and an FA in this case implies that a STM-64 exists and at each termination point PSC LSP can be created as well as TDM LSP. Given that please reread and see if the rest of the example I gave makes any sense. It is the same as your OTN_HO+OTN_LO example and given as an illustration using something familiar (PSC and TDM have been deployed for a while now and *should* be familiar to someone). BTW - I see exactly what you are doing by defining OTN_LO, OTN_HO, and OTN_SHO but I'm not certain that all constraints of OTN are covered. Maybe they are. RFC 3630 gives the means to indicate how many connections can be made in the base Link TLV. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 3:29 PM > To: Igor Bryskin > Cc: John E Drake; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com; ccamp@ietf.org > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D760FF@atl-srv-exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > I totally agree with you. It is absolutely non OTN specific. However > > if a TE link advertises more than one ISCD (with each ISCD containing > > only max lsp bandwidth per priority), it is necessary to indicate how > > the total link unreserved bandwidth is partitioned between several > > ISCDs. What I am suggesting is instead of advertising the unreserved > > bandwidth multiple times (one per ISCD), indicate how the bandwidth is > > split between the ISCDs: e.g ISCD1 75%, ISCD2 25%. > > > > Igor. > > > Igor, > > If there are two ISCs and nothing reserved, then there is one FA. One > ISC is always lower in the hierarchy than the other. Consider the > TDM+LSR example in RFC4202 and assume the exact advertisement is > TDM+PSC-4. If a 1Gb/s PSC-3 LSP from far away is created on a STM64 > and uses an STM16 worth of bandwidth, then the original FA has 75% > reservable and there is a new PSC-4 only FA with 2.5G and 1.5G > reservable. The new PSC-4 FA can take more PSC-3 but not more TDM. > The original TDM+PSC-4 FA can take 7.5G of TDM or PSC capacity. The > far away LSR would advertise a PSC-3 FA. > > The same should apply to the above example if an STM16 was added from > a far away LSR. A new FA would be created at STM16 advertised by the > new TDM LSP ingress. The old FA would now have 75% remaining for > either TDM or PSC-4. > > Of course with 75% remaining it may not be possible to create a 5 Gb/s > PSC LSP if it is not possible to link bundle two PSC-4 each over a > STM16, but that brings us into the realm of discussing multipath (or > pointing out that maxlsp can be set to 2.5G and avoid it). > > BTW- I am wondering what TDM capable LSR in the field actually do if > this is not what they do. > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 11:54 AM > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > Cc: ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > Igor, > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the issue of partitioning unreserved bandwidth across multiple advertised TDM ISC TLVs is actually a non-issue. > > > > Unreserved bandwidth by priority has always been advertised using the MPLS sub-TLV. My point has been that we have never had a requirement (including SDH/SONET) in the past to advertise unreserved bandwidth by signal type, so what is special about OTN? > > > > > A further point would be that if we do decide that it is necessary to advertise unreserved bandwidth by signal type, it should be done in a general way and not in an OTN specific manner. (And in fact, the arguments that unreserved bandwidth by signal type needs to be advertised, such as the latest e-mail from Curtis, are not OTN specific.) > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > > Of Igor Bryskin > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > It is a valid point, but the suggested solution is way too expensive. > > > All you need is a way to say how the advertised unreserved bandwidth is > > > partitioned between ISCDs in case the TE link advertisement contains > > > several of them. One cheap way of doing so is to allocate 3-4 bits out > > > of the ISCD sub-TLV reserved bits to indicate the fraction of total > > > unreserved bandwidth associated with the ISCD. Another way is to use > > > swicthcap specific extension. > > > BTW: this is not an OTN specific issue, rather more general: any time > > > when a TE link advertises more than one ISCD (which is perfectly Ok > > > according to 4203) you'll have the same problem. > > > > > > Igor > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Igor, > > > > > > The need for unreserved resources advertised per signal type is the > > > concurrent path computation. I'll answer quoting a section from the > > > info-model draft, please have a look in particular to the example: > > > > > > > > > " Unreserved resources need to be advertised per priority and per > > > signal type in order to allow the correct functioning of the > > > restoration process. [RFC4203] only allows advertising unreserved > > > resources per priority, this leads not to know how many LSPs of a > > > specific signal type can be restored. As example it is possible to > > > consider the scenario depicted in the following figure. > > > > > > +------+ component link 1 +------+ > > > | +------------------+ | > > > | | component link 2 | | > > > | N1 +------------------+ N2 | > > > | | component link 3 | | > > > | +------------------+ | > > > +------+ +---+--+ > > > > > > Suppose to have a TE link comprising 3 ODU3 component links with > > > 32TSs available on the first one, 24TSs on the second, 24TSs on the > > > third and supporting ODU2 and ODU3 signal types. The node would > > > advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX > > > LSP bandwidth equal to 32 TSs. In case of restoration the network > > > could try to restore 2 ODU3 (64TSs) in such TE-link while only a > > > single ODU3 can be set up and a crank-back would be originated. In > > > more complex network scenarios the number of crank-backs can be much > > > higher." > > > > > > In other words, advertising the number of availble resources per signal > > > type does not avoid the possibility of cranck-back but decreases it as > > > much as possible. For sure a good routing prevents from crank-backs > > > caused by the restoration of LSP originating on the same Ingress. The > > > cranck-backs due to the concurrent restoration of LSPs originating on > > > different ingress nodes cannot be avoided. > > > > > > BR > > > Daniele > > > > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: martedì 20 luglio 2010 16.16 > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > In line > > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Igor, one more question. > > > > > > What about the unreserved bandwidth? > > > If you're advertising the max lsp bandwidth by 1 ISCD per role per > > > (muxCap & signal type) you also need to advertise the unreserved > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? This > > > also implies extending the unreserved bandwidth TLV so to create a > > > corrispondence between the couples (ISCD-unreserved bandwidth subTLV). > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD per > > > IB>> role per (muxCap & signal type) per priority level. However, total > > > IB>> unreserved bandwidth IMO is OK to share between roles unless you > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > Igor > > > > > > Thanks > > > Daniele > > > > > > -----Original Message----- > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > Sent: lunedì 19 luglio 2010 17.48 > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > > 01.txt > > > > > > Understood... > > > > > > Regards > > > Snigdho > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > That's exactly what I've been > > > > trying to say all along. > > > > > > > > Cheers, > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > 01.txt > > > > > > > > Igor > > > > > > > > Please see inline. > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Daniele, > > > > > > > > > > Please, see in line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD per > > > role > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per signal > > > type. > > > > > > > > > > IB>> in ISCD: > > > > > switchCap = role; > > > > > encodeType = muxCap & signal type; > > > > > We also have 16 reserved bits which can use for OTN specific info > > > in > > > > > case we need it. > > > > [SCB] I am yet to clearly understand what the role of "role" is, but > > > > agree with your observation on the encode-type and the 16 > > > > reserved-bits to further classify the switching information. > > > > > > > > > > In case (a) you're still missing a lot of information. For each > > > role > > > > > you would advertise just the unreserved bandwidth but you wouldn't > > > > know > > > > > if such bandwidth is available for a certain type of ODUj LSP (e.g. > > > > 15 > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > available > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > In case (b) the number of ISCDs would cause serious scalability > > > > issues > > > > > and the requirement of being able to bundle component links > > > together > > > > > wouldn't be satisfied. > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several ISDCs > > > will > > > > > provide a lot of flexibility: you can specify different things > > > (e.g. > > > > > available bandwidth) for the same link in different roles. > > > > [SCB] Are you saying the ISCD as defined today with minor extensions > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > Cheers, > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: lunedì 19 luglio 2010 15.40 > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Fatai, > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf > > > > > Of Fatai Zhang > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > I understand what you said. Therefore, we have added some text to > > > > > address the requirment in FWK document. However, we still don't > > > > > think that we need to extend ISC to meet the requirment. The role > > > of > > > > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the [draft- > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > Lambda" > > > > is > > > > > introduced. > > > > > > > > > > IB>> This is possible, however: > > > > > a) this requires OTN specific advertising and processing rules; > > > > > b) disallows topology separation in technology independent way > > > > > > > > > > A quick question on your statement: "the role of an ODU container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The role is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > > role > > > > > of Ho ODU level is requested, according to your statement, this > > > > > conneciton will be allowed to be created. However, it should not be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE link > > > ends > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, while > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the path > > > > > computation is constrained to the OTN_HO_SC topology, B11 and B12 > > > TE > > > > > links will > > > > be > > > > > disallowed, and the resulting path (if any) will not go through B11 > > > > and > > > > > B12. If one circumvents the path computation by providing the fully > > > > > explicit path, the signaling should fail on node B for the same > > > > reason: > > > > > inconsistency of required (signaled) and supported (by local > > > > > interfaces) switchcap. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft- > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators can > > > > > define different roles depending on their policy and achieve the > > > > > role through different methods. However, for OTN networks, the > > > > > containers (e.g., ODUk) all have the same switching capablility > > > > > (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics > > > > of > > > > > links in the routing. In addition, if we extend the ISC, it will > > > > > make the encoding type lose its' own meaning(ie., ISC overrides > > > > > encoding type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views the > > > > > network as a stack of topologies. Whether a given topology is real > > > > > or virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe > > > > a > > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > > > topologies that could be easily separated in technology independent > > > > way > > > > > should path computation be constrained to particular one or > > > > > sub-stack of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > > > some people seem to believe). The role is only meaningful on the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > > > role > > > > > is the level of topology it is provisioned for and it is the same > > > > > for all ODUs that comprise the topology. For, example a user may > > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients to > > > use > > > > > the topology rather than any resources available on OTN network. > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as the > > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the roles > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > clarify? > > > > > > > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type = mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > as > > > > > follows): > > > > > > > > > > > > ====================================================================== > > > > = > > > > > ============================= > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role == position in the hierarchy, > > > which > > > > is > > > > > a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 as > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there is a > > > OTU3 > > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the ODU > > > > > terminating nodes (i.e. on either side of corresponding link). What > > > > > happens on the ODU transit nodes and its place in the hierarchy on > > > > the > > > > > transit nodes are of no importance. My LO container can be carried > > > > > by somebody else's LO container and can carry my client's LO > > > container. > > > > To > > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > > ====================================================================== > > > > = > > > > > ============================ > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" ; > > > > > "Lou Berger" ; ; > > > > > > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > > > > HO, SHO, etc.). The link's role or roles IMO should be indicated > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > > 2. > > > > > Link may advertise several roles (e.g. HO and SHO) with different > > > > > mux.capabilities per role; 3. Link's role and mux. capabilities can > > > > be > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style ISCD is > > > > > required); 4. The combination of swicthcaps and encoding type will > > > > look > > > > > to CP as a separate layer, which is exactly how ITU models OTN > > > > > hierarchies in all aspects but routing (!?) 5. If the operator > > > would > > > > > want to constrain the routing of OTN connections to pre-configured > > > > > topology with a specific role (e.g. constrain all ODUs it sells to > > > > the > > > > > clients to one or more pre-configured LO topologies), this would be > > > > > possible to do in a technology independent way. Suppose an instance > > > > of > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from HO OTN > > > > > links will be no different from the separation of WDM links from > > > > OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > > /*****/ > > > > > > , LSPSwitchType_LSC =150 /* LSC */ > > > > > > , LSPSwitchType_FSC =200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, which had > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a long time > > > ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did not > > > > > understand what the TS type meant did not try to multiplex its LO > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy commited > > > to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > > > granularity, then the corresponding G.709 Digital Path FA can be > > > withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of the > > > LSP > > > > > regardless of what goes on in the middle since that determines what > > > > can > > > > > be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3 -------------- > > > > > OTU1 ODUk=2 -- ODUj=2 > > > > > ODUk=1 --- ODUj=1 -- > > > > > > > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex > > > > > even though the ODUk=2 at the next hop could not directly contain > > > an ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 Switch > > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, and > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on this > > > > > would indicate a huge controversy and I'm not getting it (other > > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-framework, > > > > > or other intent. Could someone (either draft) concisely summarize > > > > > the multiplexing restrictions in one place, including restrictions > > > > > on number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > > > > Behalf Of Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework > > > > > > > document before we can embark on any proposals to the problem. > > > I > > > > am > > > > > > > still not clear why do we have to deviate from the general > > > > approach > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer control > > > > > > > IB>> plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm > > > > > > > of advertising of TE links, and there is no reason to invent an > > > > OTN > > > > > > > specific ISCD. The combination of Switching Capability and > > > > Encoding > > > > > > > type of RFC4202 ISCD allows for specifying both multiplexing > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, and, > > > if > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > > > > > > > >TE-link > > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > > create > > > > > > > IB>> OTN > > > > > > > hierarchies and constrain LO connections to HO containers, one > > > > > needs > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > > > > > > other interested experts, and we think the proposal described > > > in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is more > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed for > > > > > > > control plane, no matter how you encode the routing > > > information. > > > > > For > > > > > > > TDM networks, you know the resource is allocated based on TS, > > > so > > > > > the > > > > > > > available TS should be get or induced before creating cross- > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > I > > > > > > > think you need go to the routing drafts (info model and > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > > you > > > > > > > will find that one of your suggestions is adopted (i.e., simply > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., ODU4 > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as FA > > > > for > > > > > > > ODU1, you have to advertise a new TE link or put this FA as a > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > g709-framework@tools.ietf.org > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how to > > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course > > > > > > > > one of the main objectives of *C*CAMP. I look forward to > > > > hearing > > > > > > > > from the draft and discussion contributors on there progress > > > > > > > > on > > > > > this point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service > > > > > > > >> routing purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low-order > > > > > > > >> ODUj availability within a higher-order container. For > > > > > > > >> example, consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > > > > > > >> then > > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point in > > > > > > > >> time the OTU3 link has 12 time-slots available for ODU2 > > > > > > > >> services > > > > and > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 ODU1s > > > > > > > >> are contained over the ODU2). So it is obvious from this > > > > > > > >> example > > > > > that > > > > > > > >> the number of time-slots available is different based on the > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > >> How do we address this issue based on the approach specified > > > > in > > > > > > > >> the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the available > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container instances or > > > > the > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > >> approach seems to be more in-line with the general approach > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > > > > > > >> being advertised per VC rate for an SDH link. The additional > > > > > > > >> benefit > > > > > is > > > > > > > >> that the advertisement is TS size independent and hence will > > > > > > > >> simplify the implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho From curtis@occnc.com Wed Jul 21 09:45:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BE73A6866 for ; Wed, 21 Jul 2010 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSE7wics0SzG for ; Wed, 21 Jul 2010 09:45:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id A14333A6784 for ; Wed, 21 Jul 2010 09:45:41 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LGjdfk086000; Wed, 21 Jul 2010 12:45:39 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007211645.o6LGjdfk086000@harbor.orleans.occnc.com> To: John E Drake From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 13:17:32 PDT." <5E893DB832F57341992548CDBB333163984487CA7D@EMBX01-HQ.jnpr.net> Date: Wed, 21 Jul 2010 12:45:39 -0400 Sender: curtis@occnc.com Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 16:45:44 -0000 In message <5E893DB832F57341992548CDBB333163984487CA7D@EMBX01-HQ.jnpr.net> John E Drake writes: > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, July 20, 2010 12:40 PM > > To: John E Drake > > Cc: curtis@occnc.com; Fatai Zhang; Igor Bryskin; Snigdho Bardalai; Lou > > Berger; ccamp@ietf.org > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > > > In message <5E893DB832F57341992548CDBB333163984487C3BC@EMBX01- > > HQ.jnpr.net> > > John E Drake writes: > > > > > > Curtis, > > > > > > Unless you are proposing to issue a new advertisement every time an > > > LSP is activated or deactivated, which has issues of its own, you > > will > > > be dealing with thresholding so what is being advertised is only an > > > approximation (e.g., advertise 5 ODUj if the unreserved bandwidth is > > > between 0 ODUj and 10 ODUj), so you will never know with certainty > > > whether a given LSP can be activated until you try to activate it. > > > > > > Thanks, > > > > > > John > > > > > > John, > > > > When you create a new LSP you must deduct from the existing FA and > > create an FA for the new LSP. The endpoints of the new LSP may not be > > the same as the endpoints of the old FA, more likely it is just a hop > > along the way. > > > > Curtis > > JD: I agree with what you wrote, above, but I am not sure what it has > to do with my e-mail. Apparently I am a master at irrelevant comments. :-) > The question we have been discussing is whether an intermediate node > should be advertising the total unreserved bandwidth or unreserved > bandwidth by service category for each of its links. I thought your > e-mail indicated support for the latter position. Let me summarize: RFC 4203: Max Bandwidth is the total BW irrespective of what is reserved. Max LSP is the biggest LSP that can be created. Min LSP if provided is the smallest LSP and an LSP must be an integer multiple of min LSP. RFC 3630: Link TLV Unreserved Bandwidth has the remaining unreserved bandwidth per priority type. RFC 4203 extends RFC 3630 and therefore the is no "unreserved bandwidth" specified in RFC 4203. In RFC 4202: [...] This document enhances the routing extensions [ISIS-TE], [OSPF-TE] required to support MPLS Traffic Engineering (TE). [ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say how to associate TE properties to regular (packet-switched) links. This document extends the set of TE properties, and also says how to associate TE properties with non-packet-switched links such as links between Optical Cross-Connects (OXCs). [LSP-HIER] says how to associate TE properties with links formed by Label Switched Paths. Note [OSPF-TE] == RFC 3630, [ISIS-TE] == RFC 3784. In RFC 4203: In this section, we define the enhancements to the Traffic Engineering (TE) properties of GMPLS TE links that can be announced in OSPF TE LSAs. The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: Sub-TLV Type Length Name 11 8 Link Local/Remote Identifiers 14 4 Link Protection Type 15 variable Interface Switching Capability Descriptor 16 variable Shared Risk Link Group Note that none of the Link TLV sub-TLVs in RFC 3630 are obsoleted or superceded. > What I was trying to point out was that unless an intermediate node > issues a new advertisement every it activates or deactivates an LSP > across its links, the state of its links in its last advertisement may > be very different from its current state, and that hence an ingress > node does not have a reliable indication of that state. Yes. reservable bw must be updated. > The example I used was that what was advertised for a given link was 5 > ODUj, even though the current unreserved bandwidth for ODUj is > anywhere in the range 0 ODUj to 10 ODUj. The reservable bandwidth would indicate that half of the capacity was still available. The min LSP bw indicates which ODUj you are dealing with. > I.e., advertising unreserved bandwidth by service category gives a > false sense of security wrt the distributed awareness of the current > state of the network. The reservable bandwidth is in bytes/sec which we both agree on. That way any nominal multiple of min LSP could be used. A slight sticky point is that ODU payloads are not exact integer multiples due to OH which is why I stated nominal multiples. Curtis > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Tuesday, July 20, 2010 7:52 AM > > > > To: Fatai Zhang > > > > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho Bardalai; > > Lou > > > > Berger; ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > 01.txt > > > > > > > > > > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > > > > Fatai Zhang writes: > > > > > > > > > > Hi Igor, > > > > > > > > > > Thanks. > > > > > > > > Sorry to jump in but I think I understand Igor's objection (and > > > > Snigdho's objection, and the reason this thread is going on). > > > > > > > > > I understand what you said. Therefore, we have added some text to > > > > > address the requirment in FWK document. However, we still don't > > think > > > > > that we need to extend ISC to meet the requirment. The role of > > the > > > > ODU > > > > > can be get from the routing information implicitly. In the > > > > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > "Full > > > > > Lambda" is introduced. > > > > > > > > > > A quick question on your statement: "the role of an ODU container > > > > does > > > > > not change hop-by-hop (as some people seem to believe). The role > > is > > > > > only meaningful on the ODU terminating nodes and irrelevant on > > > > transit > > > > > nodes. It is it's position in the hierarchy (but not role) that > > may > > > > > change hop-by-hop. " > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 and > > CI1 > > > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can only > > > > support > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with the > > > > role > > > > > of Ho ODU level is requested, according to your statement, this > > > > > conneciton will be allowed to be created. However, it should not > > be > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > type > > > > > indicated in the Switching Type parameter is supported on the > > > > > corresponding incoming interface. If the type cannot be > > supported, > > > > > the node MUST generate a PathErr message with a "Routing > > > > > problem/Switching Type" indication." > > > > > > > > I think the objection, which would be a very valid one, is that the > > > > ingress has no way to know apriori that a path is infeasible. Each > > > > crankback delays convergence. Crankback should only occur if > > another > > > > ingress has reserved resources before signaling was completed, not > > > > because inadequate routing information is provided in quiescent > > state. > > > > > > > > Curtis > > > > > > > > > > > > > Best Regards > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: "Fatai Zhang" ; > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Lou Berger" ; > > > > ; > > > framework@tools.ietf.org> > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > > > > > > > > Fatai, > > > > > Please, see my answers in line. > > > > > > > > > > -----Original Message----- > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; ccamp@ietf.org; > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > > > Hi Igor and all, > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > I think role does not equal switching capability. The operators > > can > > > > define different roles depending on their policy and achieve the > > role > > > > through different methods. However, for OTN networks, the > > containers > > > > (e.g., ODUk) all have the same switching capablility (i.e., TDM > > > > switching) and I think we should reflect the natural > > characteristics of > > > > links in the routing. In addition, if we extend the ISC, it will > > make > > > > the encoding type lose its' own meaning(ie., ISC overrides encoding > > > > type). > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it views > > the > > > > network as a stack of topologies. Whether a given topology is real > > or > > > > virtual is of no importance. > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > capability field (confusing name as it is) is a good way to > > describe a > > > > layer in technology independent way, so that, say, MPLS-TP->OTN_LO- > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack of > > > > topologies that could be easily separated in technology independent > > way > > > > should path computation be constrained to particular one or sub- > > stack > > > > of them. > > > > > I think a good way to identify an OTN (virtual) topology is via > > > > (infrastructure) ODU container role of ODUs comprising the > > topology. > > > > BTW IMO the role of an ODU container does not change hop-by-hop (as > > > > some people seem to believe). The role is only meaningful on the > > ODU > > > > terminating nodes and irrelevant on transit nodes. It is it's > > position > > > > in the hierarchy (but not role) that may change hop-by-hop. ODU's > > role > > > > is the level of topology it is provisioned for and it is the same > > for > > > > all ODUs that comprise the topology. For, example a user may > > provision > > > > a LO topology and constrain ODUs he sells to a set of clients to > > use > > > > the topology rather than any resources available on OTN network. > > > > > The bottom line: container's role is the same as the role of > > virtual > > > > topology the container is a part of and could be advertised as the > > > > corresponding link switchcap. > > > > > > > > > > According to the point 3, I don't know how to advertise the roles > > and > > > > muxing capabilities with the ISCD of RFC4202, could you clarify? > > > > > > > > > > IB>> switchcap = ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > encoding type = mux. capabilities code > > > > > > > > > > In addition, could you clarify my questions in another email > > (copied > > > > as follows): > > > > > > > > > > > ======================================================================= > > > > ============================= > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each other. > > > > > IB>> I disagree. You define role == position in the hierarchy, > > which > > > > is a mistake IMO. > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or ODU3 > > as Ho > > > > OTN Level or Lo OTN Level? Another example is, if there is a OTU3 > > link > > > > supporting ODU2 switching, which can be used as Lo ODU2 (service > > over > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this case, > > how > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on the > > ODU > > > > terminating nodes (i.e. on either side of corresponding link). What > > > > happens on the ODU transit nodes and its place in the hierarchy on > > the > > > > transit nodes are of no importance. My LO container can be carried > > by > > > > somebody else's LO container and can carry my client's LO > > container. To > > > > some extent it is similar to MPLS LSP role: LSP always has a role > > (e.g. > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along its > > > > path. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > > > > > > > ======================================================================= > > > > ============================ > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Fatai > > > > > > > > > > ----- Original Message ----- > > > > > From: "Igor Bryskin" > > > > > To: > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > ; "Fatai Zhang" ; > > "Lou > > > > Berger" ; ; > gmpls- > > > > g709-framework@tools.ietf.org> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > Thanks for your comment. > > > > > > > > > > I agree that there should be multiple OTN specific encoding types > > > > introduced. But IMO they should indicate the link's mux > > capabilities > > > > rather than the link's role (i.e. level in the OTN hierarchy: LO, > > HO, > > > > SHO, etc.). The link's role or roles IMO should be indicated with a > > > > separate switchcaps. I can give you several reasons: > > > > > > > > > > 1. Links with the same mux capabilities may have different roles; > > > > > 2. Link may advertise several roles (e.g. HO and SHO) with > > different > > > > mux.capabilities per role; > > > > > 3. Link's role and mux. capabilities can be advertised with ISCDs > > as > > > > defined in RFC4202 (no OTN-style ISCD is required); > > > > > 4. The combination of swicthcaps and encoding type will look to > > CP as > > > > a separate layer, which is exactly how ITU models OTN hierarchies > > in > > > > all aspects but routing (!?) > > > > > 5. If the operator would want to constrain the routing of OTN > > > > connections to pre-configured topology with a specific role (e.g. > > > > constrain all ODUs it sells to the clients to one or more pre- > > > > configured LO topologies), this would be possible to do in a > > technology > > > > independent way. Suppose an instance of GMPLS CP manages WDM and > > OTN > > > > NEs. Then separation of LO from HO OTN links will be no different > > from > > > > the separation of WDM links from OTUs. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > To: Igor Bryskin > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > framework@tools.ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many as > > the > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > typedef enum > > > > > > { > > > > > > LSPSwitchType_Unknown =0 /* Unknown */ > > > > > > , LSPSwitchType_PSC_1 =1 /* PSC-1 */ > > > > > > , LSPSwitchType_PSC_2 =2 /* PSC-2 */ > > > > > > , LSPSwitchType_PSC_3 =3 /* PSC-3 */ > > > > > > , LSPSwitchType_PSC_4 =4 /* PSC-4 */ > > > > > > , LSPSwitchType_L2SC =50 /* L2SC */ > > > > > > , LSPSwitchType_TDM =100 /* TDM */ > > > > > > > > > > > > /*****/ > > > > > > , LSPSwitchType_OTN_LO=124 /* OTN low order */ > > > > > > , LSPSwitchType_OTN_HO=125 /* OTN high order */ > > > > > > , LSPSwitchType_OTN_SHO=126 /* OTN super high order */ > > > > > > /*****/ > > > > > > , LSPSwitchType_LSC =150 /* LSC */ > > > > > > , LSPSwitchType_FSC =200 /* FSC */ > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and make > > the > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 Digital > > Path > > > > > layer and G.709 Optical Channel layer for 2009 OTN, which had in > > turn > > > > > replaced the Encoding Type of "Digital Wrapper" a long time ago. > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that did > > not > > > > > understand what the TS type meant did not try to multiplex its LO > > ODU > > > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited to > > > > using > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, OTN_HO > > or > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then the > > > > latter > > > > > is for backward compatibility and should be ignored if OTN_LO, > > OTN_HO > > > > > or OTN_SHO is understood. If the LSR commits to 1.25 TS > > granularity, > > > > > then the corresponding G.709 Digital Path FA can be withdrawn. > > > > > > > > > > The Encoding type would be the lower encoding at each end of the > > LSP > > > > > regardless of what goes on in the middle since that determines > > what > > > > > can be wrapped inside it. > > > > > > > > > > For example: > > > > > > > > > > OTU3 > > > > > OTU2 ODUk=3 -------------- > > > > > OTU1 ODUk=2 -- ODUj=2 > > > > > ODUk=1 --- ODUj=1 -- > > > > > > > > > > This is OK and the outer ODUk=1 could hold a ODUj=0 or ODUj=flex > > even > > > > > though the ODUk=2 at the next hop could not directly contain an > > ODU0. > > > > > If the SHO Encoding Type is used, then it indicates that two > > levels > > > > of > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > > Switch > > > > > Types currently don't include an ODUj or ODUk distinction but if > > > > > Encoding Type indicated LO or HO, that may not be needed. Along > > with > > > > > the new Encoding Type new Signal Types for ODU0, ODU4, and ODU- > > flex, > > > > > and ODU2e, can be added. > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm not > > > > clear > > > > > how in an FA it can be indicated that either type is currently > > > > > available (NE capable of both and hasn't committed to either one > > > > yet). > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages on > > this > > > > > would indicate a huge controversy and I'm not getting it (other > > than > > > > a > > > > > strong preference to rely on bytes/sec or on enumerated type > > fields). > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm not > > sure > > > > if > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, or > > > > > other intent. Could someone (either draft) concisely summarize > > the > > > > > multiplexing restrictions in one place, including restrictions on > > > > > number of multiplexing layers at one LSR. That might help. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > > On > > > > Behalf Of > > > > > > > Igor Bryskin > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ø I think we need to sort out the issues with the framework > > > > document > > > > > > > before we can embark on any proposals to the problem. I am > > still > > > > not clear > > > > > > > why do we have to deviate from the general approach that has > > been > > > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > plane, and > > > > > > > it is highly desirable to adhere to the layer independent > > > > paradigm of > > > > > > > advertising of TE links, and there is no reason to invent an > > OTN > > > > specific > > > > > > > ISCD. The combination of Switching Capability and Encoding > > type > > > > of RFC4202 > > > > > > > ISCD allows for specifying both multiplexing capabilities and > > OTN > > > > layer > > > > > > > (LO, HO, SHO) of an OTN link, and, if this not sufficient, > > you > > > > have > > > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new TE- > > link > > > > to > > > > > > > represent >the low-order ODUj bandwidth within the high-order > > > > containers. > > > > > > > This is simply >blowing up the solution to a very simple > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility to > > > > create OTN > > > > > > > hierarchies and constrain LO connections to HO containers, > > one > > > > needs to > > > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors and > > other > > > > > > > interested experts, and we think the proposal described in > > > > "draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft is > > more > > > > feasible > > > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information needed > > for > > > > control > > > > > > > plane, no matter how you encode the routing information. For > > TDM > > > > networks, > > > > > > > you know the resource is allocated based on TS, so the > > available > > > > TS should > > > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > information, > > > > I think > > > > > > > you need go to the routing drafts (info model and encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and encoding), > > you > > > > will find > > > > > > > that one of your suggestions is adopted (i.e., simply > > advertize > > > > the > > > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > > instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) as > > FA > > > > for ODU1, > > > > > > > you have to advertise a new TE link or put this FA as a > > component > > > > link of > > > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > ccamp- > > > > gmpls- > > > > > > > g709-framework@tools.ietf.org > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > To: Snigdho Bardalai > > > > > > > > Cc: ccamp@ietf.org ; draft-ietf- > > ccamp- > > > > gmpls- > > > > > > > g709-framework@tools.ietf.org > > > g709- > > > > > > > framework@tools.ietf.org> > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > I believe there has been some off-line discussion on how to > > > > better > > > > > > > > align the work with 4202. Use of common approaches is of > > > > course one of > > > > > > > > the main objectives of *C*CAMP. I look forward to hearing > > from > > > > the > > > > > > > > draft and discussion contributors on there progress on this > > > > point. > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > >> Hello, > > > > > > > >> > > > > > > > >> I have a comment and a question on Section 3.1.2.1. This > > > > section > > > > > > > >> describes the link-parameters that are required for OTN > > > > service routing > > > > > > > >> purposes. > > > > > > > >> > > > > > > > >> My comment is how are we going to advertise the low-order > > ODUj > > > > > > > >> availability within a higher-order container. For example, > > > > consider an > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity and > > then > > > > we > > > > > > > >> establish an ODU2 service over the link. At this point in > > time > > > > the OTU3 > > > > > > > >> link has 12 time-slots available for ODU2 services and up > > to > > > > 12+4 > > > > > > > >> time-slots available for ODU1 services (4 ODU1s are > > contained > > > > over the > > > > > > > >> ODU2). So it is obvious from this example that the number > > of > > > > time-slots > > > > > > > >> available is different based on the signal-type (i.e. ODU1 > > and > > > > ODU2). > > > > > > > >> How do we address this issue based on the approach > > specified > > > > in the > > > > > > > draft? > > > > > > > >> > > > > > > > >> My other question is why not simply advertize the > > available > > > > number of > > > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > > equivalent > > > > > > > >> bandwidth in bytes/sec within a link? This approach seems > > to > > > > be more > > > > > > > >> in-line with the general approach outlined in RFC-4202. > > Refer > > > > to > > > > > > > section > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple ISCDs > > being > > > > > > > >> advertised per VC rate for an SDH link. The additional > > benefit > > > > is that > > > > > > > >> the advertisement is TS size independent and hence will > > > > simplify the > > > > > > > >> implementation. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Snigdho From curtis@occnc.com Wed Jul 21 10:51:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2633A3A685A for ; Wed, 21 Jul 2010 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sBO90vcR+rH for ; Wed, 21 Jul 2010 10:51:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id D1D3F3A67BD for ; Wed, 21 Jul 2010 10:51:19 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LHpKXI086686; Wed, 21 Jul 2010 13:51:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007211751.o6LHpKXI086686@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 16:26:04 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 13:51:20 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Preemption (was draft-ietf-ccamp-gmpls-g709-framework-01.txt) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:51:21 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > Curtis, > Igor, > > > > Would you not need percentage per priority per signal-type? > > > > Regards > > Snigdho > > > You would if you wanted to be able to preempt LSPs, therefore you do. > I take it that was a rhetorical question for which you knew the answer > already but I fell for it and answered. :-) > > Curtis > > IB>> The question is not rhetorical. Keep in mind that this > information is only needed for concurrent path computations performed > on the same node. For example, a link has failed and *all* LSPs going > through the link are originated on the same NE, and the NE is trying > to reroute all of them concurrently. I don't think you will want to > preempt other connections knowing that it may not help, because at the > same time other NEs (terminating other LSPs going over the failed > link) may do the same thing. If you use preemption in this case your > restoration will do more harm than good. > > In all other case the info does not help much. I think it is Ok to say > that ISDCs share the common pool in, say, 60% to 40% ratio and > extrapolate the ratio for all priority levels. I say it is overkill to > partition the unreserved bandwidth pool on per priority > level. However, if you insist on such partitioning then 4203 allows > you to expand the IDSC sub-TLV and you can specify the unreserved > bandwidth per priority level for every ISCD. > > Igor OK ... so if priority 0-7 in RFC 3630 Link TLV unreserve BW and in RFC 4203 are not for preemption, what exactly are they for? If a priority 4 OTN_HO contains one smaller priority 5 OTN_LO how are the reservable bandwidth per priority in the Link TLV expressed? If a priority 4 OTN_LO won't fit, does the priority 5 OTN_LO block it, or does it get preempted? I think you need two FA in this case and priority would drive preemption, but I'd be willing to read why it should be otherwise. As I understand it, the FA for a priority N LSP should have BW for priority zero to N-1 set to zero. This is because you can't put a priority 1 LSP into a priority 3 LSP, otherwise the priority 1 LSP could effectively get preempted by a priority 2 LSP. This means that the examples above need two FA or need percentage per priority per signal-type as Snigdho pointed out. If OTN_LO OTN_HO, and OTN_SHO are ISCs, rather than use TDM as the ISC, then you need Max LSP Bandwidth per priority level for each of OTN_LO OTN_HO, and OTN_SHO plus the Switching Capability-specific information given in the ISCD must be given individually for each. OTOH, if just OTN is the ISC, then OTN_LO OTN_HO, and OTN_SHO can be part of the Switching Capability-specific information in the ISCD. This to me makes more sense. Really the issue is how to express the OTN specific constraints and IMHO that should be in the "Switching Capability-specific information". It is also architecturally cleaner to provide only Sub-TLVs in the Switching Capability-specific information and to define only one new ISC. Curtis > [...trimmed...] From curtis@occnc.com Wed Jul 21 11:08:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF183A6974 for ; Wed, 21 Jul 2010 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA-Srm1+n1xJ for ; Wed, 21 Jul 2010 11:08:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 4D1653A68EA for ; Wed, 21 Jul 2010 11:08:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LI8RCV086918; Wed, 21 Jul 2010 14:08:27 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007211808.o6LI8RCV086918@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Jul 2010 16:54:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761ED@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 14:08:27 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:08:12 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761ED@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > IB>> It is possible from the RFC4203 point of view. What I am saying > is that it is not practical to advertise for the same link both TDM > and PSC ISCDs. It is only possible when: > a) TDM topology and PSC topology are congruent (at least partially); > b) TDM topology and PSC topology share the same address space; > c) TDM and PSC share the same routing instance. > > Igor That is essentially the peer model, which is in fact possible. Curtis From zhangfatai@huawei.com Wed Jul 21 11:14:22 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EE13A69E2 for ; Wed, 21 Jul 2010 11:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+u8XaCNJ1Pu for ; Wed, 21 Jul 2010 11:14:20 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id D31033A69B7 for ; Wed, 21 Jul 2010 11:14:20 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5X00E176OD17@usaga03-in.huawei.com> for ccamp@ietf.org; Wed, 21 Jul 2010 13:14:37 -0500 (CDT) Received: from zhang (5356F00D.cable.casema.nl [83.86.240.13]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5X00B3T6OBKA@usaga03-in.huawei.com> for ccamp@ietf.org; Wed, 21 Jul 2010 13:14:37 -0500 (CDT) Date: Thu, 22 Jul 2010 02:14:42 +0800 From: Fatai Zhang To: John E Drake , Igor Bryskin , curtis@occnc.com Message-id: <02f301cb2900$983fd4d0$6801a8c0@zhang> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: "Your message of Tue, 20 Jul 2010 14:20:42 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> <201007202336.o6KNaIgn072073@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB33316398448E10A1@EMBX01-HQ.jnpr.net> Cc: ccamp@ietf.org, Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:14:22 -0000 Hi John, snipped.... If we want to advertise unreserved bandwidth by service category, then that is what we should do, rather than trying to carve up unreserved bandwidth with percentages. It doesn't fit the normal case and enforces a rigid structure. [Fatai] Yes, agree. The solution for the issue is based on the assumption (i.e., extending ISC types). Thanks Fatai Zhang Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28973234 Fax: +86-755-28972935 ----- Original Message ----- From: "John E Drake" To: "Igor Bryskin" ; Cc: ; "Snigdho Bardalai" Sent: Wednesday, July 21, 2010 10:37 PM Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > Igor, > > The normal case is that the advertised unreserved bandwidth is available to *all* of the advertised ISCDs. That is why it was designed the way it was. > > If we want to advertise unreserved bandwidth by service category, then that is what we should do, rather than trying to carve up unreserved bandwidth with percentages. It doesn't fit the normal case and enforces a rigid structure. > > Thanks, > > John > From IBryskin@advaoptical.com Wed Jul 21 11:28:50 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF8D3A6A08 for ; Wed, 21 Jul 2010 11:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4ut5jDJOKeu for ; Wed, 21 Jul 2010 11:28:49 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 312783A691A for ; Wed, 21 Jul 2010 11:28:49 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LIT2DI032706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 20:29:02 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 20:29:02 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 21 Jul 2010 20:29:02 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 14:28:59 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Wed, 21 Jul 2010 14:28:41 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acso/7wWlwlhoZWDRJavMbu8I7yc6QAAad2w Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7642A@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Tue, 20 Jul 2010 16:54:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761ED@atl-srv-exgen.atl.advaoptical.com> <201007211808.o6LI8RCV086918@harbor.orleans.occnc.com> In-Reply-To: <201007211808.o6LI8RCV086918@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_08:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:28:50 -0000 Curtis, > IB>> It is possible from the RFC4203 point of view. What I am saying > is that it is not practical to advertise for the same link both TDM > and PSC ISCDs. It is only possible when: > a) TDM topology and PSC topology are congruent (at least partially); > b) TDM topology and PSC topology share the same address space; > c) TDM and PSC share the same routing instance. > =20 > Igor That is essentially the peer model, which is in fact possible. IB>> That's what people thought when they were 10 years younger :=3D) I would like to talk to somebody who has ever seen such configuration outsi= de of an interop demo. Igor Curtis =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Wed Jul 21 12:44:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114113A6AF3 for ; Wed, 21 Jul 2010 12:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUq4a5bXAWdU for ; Wed, 21 Jul 2010 12:44:20 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id DFFA63A68C6 for ; Wed, 21 Jul 2010 12:44:19 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5X004EIAUB87@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 21 Jul 2010 12:44:36 -0700 (PDT) Received: from zhang (5356F00D.cable.casema.nl [83.86.240.13]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5X00CKCAU826@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 21 Jul 2010 12:44:35 -0700 (PDT) Date: Thu, 22 Jul 2010 03:44:39 +0800 From: Fatai Zhang To: Igor Bryskin , "BELOTTI, SERGIO (SERGIO)" Message-id: <03ae01cb290d$29ae17e0$6801a8c0@zhang> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: "Your message of Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> Cc: "Varma, Eve L \(Eve\)" , ccamp@ietf.org, Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:44:21 -0000 SGkgSWdvciwNCg0KVGhhbmtzIHZlcnkgbXVjaC4gSSBzdXBwb3J0IHlvdXIgc3VnZ2VzdGlvbnMu DQoNCkkgd291bGQgbGlrZSB0byBwdXQgYSBmZXcgaXRlbXMgZm9sbG93aW5nIHlvdXIgaXRlbXMg dG8gYmUgZGlzY3Vzc2VkLg0KDQooNSkgRGlzY3VzcyBvciBjbGFyaWZ5IHRoZSBvcmlnaW5hbCBt ZWFuaW5nIG9mIFN3aXRoY2luZyBDYXBhYmlsaXR5IHRvIHNlZSBpZiBzd2l0Y2hpbmcgY2FwYWJp bGl0eSBpcyBlcXVhbCB0byByb2xlLg0KKDYpIERpc2N1c3MgaWYgdGhyZWUgbGF5ZXJzIG9yIHJv bGVzIGFyZSBjb21wZXRlbnQgZm9yIG1vcmUgdGhhbiB0aHJlZSBsYXllcnMgbmV0d29ya3MgKGF0 IGxlYXN0IDUgbGF5ZXJzIChPRFVqKGo9MC9mbGV4LCAxLDIsMyw0Li4uKSkuIFdlIGtub3cgdGhl IGhpZ2hlciBsYXllciBPRFVrIGNhbiBwcm92aWRlIHZpcnR1YWwgdG9wb2xvZ3kgZm9yIHRoZSBs b3dlciBsYXllciBPRFVqIChqPGspLiBJbiBhZGR0aW9uLCBkbyB5b3UgdGhpbmsgaWYgaXQgaXMg c2VtaS1mbGF0IHJvdXRpbmcgbW9kZWwgZm9yIHlvdXIgcHJvcG9zYWw/IA0KKDcpIERpc2N1c3Mg d2hhdCBzaG91bGQgYmUgZXh0ZW5kZWQgdG8gUkZDNDIwMyB0byBjYXJyeSBhY2N1cmF0ZSByb3V0 aW5nIGluZm9ybWFpdG9uLiBJZiBpdCBuZWVkcyBtYWpvciBjaGFuZ2VzIG9uIElTQ0QgZXZlbiB0 aG91Z2ggaXQgbG9va3MgbGlrZSB0aGUgb3JpZ2luYWwgSVNDRCBvZiBSRkM0MjAzLCB3aHkgd2Ug Y2FuIG5vdCB0YWtlIGEgc3RlcCBmb3J3YXJkIHRvIG1ha2UgaXQgbW9yZSByZWFzb25hYmxlLg0K DQoNClRoYW5rcw0KRmF0YWkgWmhhbmcNCg0KIA0KDQpBZHZhbmNlZCBUZWNobm9sb2d5IERlcGFy dG1lbnQNCldpcmVsaW5lIE5ldHdvcmtpbmcgQnVzaW5lc3MgVW5pdA0KSHVhd2VpIFRlY2hub2xv Z2llcyBDby4sIExURC4NCkh1YXdlaSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZywNClNoZW56aGVu IDUxODEyOSBQLlIuQ2hpbmENClRlbDogKzg2LTc1NS0yODk3MzIzNA0KRmF4OiArODYtNzU1LTI4 OTcyOTM1DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSWdvciBCcnlz a2luIiA8SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPg0KVG86ICJCRUxPVFRJLCBTRVJHSU8gKFNF UkdJTykiIDxzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb20+DQpDYzogPGNjYW1wQGll dGYub3JnPjsgIlNuaWdkaG8gQmFyZGFsYWkiIDxTQmFyZGFsYWlAaW5maW5lcmEuY29tPjsgIk9u ZywgTHluZG9uIiA8THlvbmdAQ2llbmEuY29tPjsgIkRhbmllbGUgQ2VjY2FyZWxsaSIgPGRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+OyAiSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlw ZXIubmV0PjsgPGN1cnRpc0BvY2NuYy5jb20+OyAiU25pZ2RobyBCYXJkYWxhaSIgPHNiYXJkYWxh aTFAZ21haWwuY29tPjsgIlZhcm1hLCBFdmUgTCAoRXZlKSIgPGV2ZS52YXJtYUBhbGNhdGVsLWx1 Y2VudC5jb20+OyAiRmF0YWkgWmhhbmciIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+DQpTZW50OiBU aHVyc2RheSwgSnVseSAyMiwgMjAxMCAxMjowMiBBTQ0KU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29t bWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dA0KDQoN CkhpIFNlcmdpbywNCg0KSSdkIGxpa2UgdG8gcnVuIHdpdGggeW91IHRoZSBmb2xsb3dpbmcgbG9n aWMuDQoNCjEuIFN1cHBvc2UgYW4gb3BlcmF0b3IgYWZ0ZXIgc29tZSBwbGFubmluZyBkZWNpZGVz IHRvIHByb3Zpc2lvbiBhbiBpbmZyYXN0cnVjdHVyZSBPRFUgYW5kIHVzZSBpdCBhcyBhIGxpbmsu IFdoeSB3b3VsZCBoZSBkbyBzbz8gIE9uZSByZWFzb24gdGhhdCBJIGNhbiB0aGluayBvZiBpcyBi ZWNhdXNlIGhlIHdhbnRzIHRvIGJ1aWxkIGEgdmlydHVhbCB0b3BvbG9neSBmb3IgYSBzZXQgb2Yg Y2xpZW50cyAod2l0aCBwb3NzaWJseSBoaW1zZWxmIGFzIG9uZSBmcm9tIHRoZSBzZXQpLiBUaGUg cHVycG9zZSBvZiB0aGlzIHRvcG9sb2d5LCBnZW5lcmFsbHkgc3BlYWtpbmcsICBpczoNCmEpICAg ICAgVG8gYmUgbm9uLWNvbmdydWVudCB3aXRoIHVuZGVybHlpbmcgdG9wb2xvZ3kgKHZpcnR1YWwg b3IgT1RVL09DaCkuIEZvciBleGFtcGxlLCB0byBpbnRlcmNvbm5lY3Qgbm9kZXMgdGhhdCBkbyBu b3QgaGF2ZSBhIGNvbW1vbiBPVFUvT0NoIGxpbms7DQpiKSAgICAgIFRvIGNvbnN0cmFpbiBzYWlk IHNldCBvZiBjbGllbnRzIHRvIHJlc291cmNlcyBvZiB0aGUgdG9wb2xvZ3kgKHJhdGhlciB0aGFu LCBmb3IgZXhhbXBsZSwgdG8gdXNlIE9UVS9PQ2ggbGlua3MgZGlyZWN0bHkpLg0KVGhlIHF1ZXN0 aW9uIGlzIGhvdyB0aGUgb3BlcmF0b3IgY2FuIGNvbnN0cmFpbiB0aGUgcm91dGluZyBvZiB0aGUg T0RVcyBmb3IgdGhlIGNsaWVudHMgZnJvbSB0aGUgc2V0IHRvIHRoZSBwcmVwYXJlZCBmb3IgdGhp cyBwdXJwb3NlIHZpcnR1YWwgdG9wb2xvZ3kgd2l0aGluIHRoZSBmbGF0IElUVSByb3V0aW5nIG1v ZGVsPw0KDQoyLiBXb3VsZCB5b3UgYWdyZWUgdGhhdCB0aGUgb25seSByZWFzb24gd2h5IGEgVEUg bGluayBhZHZlcnRpc2VzIGFuIGF0dHJpYnV0ZSBpcyB0byBiZSBhYmxlIHRvIGNvbnN0cmFpbiBh IHBhdGggY29tcHV0YXRpb24gYmFzZWQgb24gdGhlIGF0dHJpYnV0ZT8gWW91ciBkZWZpbml0aW9u cyBvZiB0aGUgT1ROIGVuY29kaW5nIHR5cGVzLCBmb3IgZXhhbXBsZSwgYXJlOg0KIiAgICAgLi4u Lg0KICAgICAgbyA4IC0gTGFtYmRhIChQaG90b25pYykNCiAgICAgIG8gMTIgLSBHLjcwOSBPRFVr IChEaWdpdGFsIFBhdGgpDQogICAgICAuLi4uDQoiDQoNCndoaWNoIHdpbGwgZ2l2ZSB0aGUgb3Bl cmF0b3IgYW4gYWJpbGl0eSB0byByb3V0ZSBhbiBPVE4gY29ubmVjdGlvbiBlaXRoZXIgc3RyYWln aHQgb3ZlciBPVFVzIG9yIG92ZXIgaW5mcmFzdHJ1Y3R1cmUgT0RVcyB3aXRoIG5vIHJlZ2FyZCB0 byB0aGUgcm9sZXMgYXNzaWduZWQgdG8gdGhlIGxpbmtzLiBEbyB5b3UgYmVsaWV2ZSB0aGlzIHdv dWxkIGJlIGZsZXhpYmxlIGVub3VnaCBmb3IgdGhlIG9wZXJhdG9yPw0KDQozLiBXaGF0IGlzIGl0 IHlvdSBjYW4gYWNoaWV2ZSB3aXRoIHRoZSBzdWdnZXN0ZWQgT1ROIHJvdXRpbmcgdGhhdCBjYW4g bm90IGJlIGFjaGlldmVkIHVzaW5nIG11bHRpcGxlIDQyMDMgSVNDRHM/DQoNClRoYW5rcywNCkln b3INCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQkVMT1RUSSwgU0VSR0lP IChTRVJHSU8pIFttYWlsdG86c2VyZ2lvLmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuY29tXQ0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDIxLCAyMDEwIDEwOjU5IEFNDQpUbzogSWdvciBCcnlza2luDQpD YzogY2NhbXBAaWV0Zi5vcmc7IFNuaWdkaG8gQmFyZGFsYWk7IE9uZywgTHluZG9uOyBEYW5pZWxl IENlY2NhcmVsbGk7IEpvaG4gRSBEcmFrZTsgY3VydGlzQG9jY25jLmNvbTsgU25pZ2RobyBCYXJk YWxhaTsgVmFybWEsIEV2ZSBMIChFdmUpOyBGYXRhaSBaaGFuZw0KU3ViamVjdDogUjogW0NDQU1Q XSBDb21tZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDEudHh0 DQoNCklnb3IsDQoNCkZvciBwb2ludCAxKSBhbmQgMikgSSBkbyBub3QgdGhpbmsgd2UgYXJlIHNv IGZhci4NCllvdSdyZSBwcm9wb3NpbmcgYSB0aHJlZS1sYXllciBhcHByb2FjaCAsIHdlIGFyZSBh bGlnbmVkIHdpdGggd2hhdCBJVFUgaXMgcHJvcG9zaW5nIGJ1dCB3ZSBhbHNvIGhhdmUgZGlmZmVy ZW50IHJvbGVzIGluIHRoZSBuZXR3b3JrIChsYW1iZGEgYW5kIHN1Yi1sYW1iZGEpIGFuZCB0aGFu IG5lZWRzIGZvciBjb25zdHJhaW5zIGFuZCBwb2xpY3kgaW4gdGhlIG5ldHdvcmsuDQpUaGUgZmFj dCB0byBoYXZlIHRocmVlIHN3aXRjaGluZyBjYXBhYmlsaXR5IHRvIGNoYXJhY3Rlcml6ZSB0aGUg ZGlmZmVyZW50IHJvbGVzIGluIHRoZSBzYW1lIHRlY2hub2xvZ3kgaXQgc2VlbXMgdG8gbWUgYSBs aXR0bGUgYWdhaW5zdCB0aGUgY29uY2VwdCBvZiBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBpdHNlbGYu DQpZb3UgY291bGQgc2F5IHRoYXQgZm9yIHBhY2tldCB0aGVyZSBpcyBhbHJlYWR5IDQgUFNDIFND IGRlZmluZWQuIEJ1dCBoZXJlIHdlIGFyZSBpbiBURE0gLCB3ZSBoYXZlIG5vdCBsYWJlbCBzdGFj a2luZyBjYXBhYmlsaXR5Lg0KDQpGb3IgcG9pbnQgMykgYW5kIDQpICwgSSBkbyBub3QgZGlzY3Vz cyBhYm91dCB0aGUgZ2VuZXJhbGl0eSBvciBub3Qgb2YgdGhlIGlzc3VlLCBidXQgc3VyZWx5IHlv dSBjYW5ub3QgbmVnYXRlIHRoYXQgdGhlIHByb2JsZW0gb2Ygc3BhdGlhbCBhbGxvY2F0aW9uIGlz IHJhaXNlZCBhcyBzb29uIGFzIFNESCBDUCBoYXMgYmVlbiBpbXBsZW1lbnRlZCAuIFRoZW4gdGhl IHNhbWUgcHJvYmxlbSBjb21lIGluIGZvciBPVE4gLCBhbmQgeW91ciBpbnRlbnRpb24gdG8gY29w ZSB0aGUgaXNzdWUgaW4gYSBnZW5lcmljIHdheSB3aXRoIG1vZGlmaWNhdGlvbnMgb2YgUkZDIDQy MDMgaXMgYSBnb29kIGludGVudGlvbiwgYnV0IHRha2UgYWxzbyBpbnRvIGFjY291bnQgdGhhdCBh bHNvIG91ciBwcm9wb3NlZCBmb3JtYXQgY2FuIGJlIGdlbmVyaWMgYXMgc29vbiBhcyB5b3UgY2hh bmdlIHRoZSBzaWduYWwgdHlwZXMgc3VwcG9ydGVkLg0KDQpZb3UncmUgcmlnaHQgd2UgbmVlZCB0 byBkaXNjdXNzIGZhY2UgdG8gZmFjZSBidXQgbXkgcGVyY2VwdGlvbiBpcyB0aGF0IHdlIGNhIGJl IGxlc3MgZmFyIHRoYW4geW91IGJlbGlldmUuDQoNCkNoZWVycw0KDQpTZXJnaW8NCg0KU2VyZ2lv IEJlbG90dGkNCg0KU3lzdGVtIEFyY2hpdGVjdHVyZQ0KT3B0aWNzIERpdmlzaW9uLVRlcnJlc3Ry aWFsIE9wdGljcyBVbml0DQpBTENBVEVMLUxVQ0VOVA0KDQorMzkgMDM5IDY4NjMwMzMNCiszOSAw MzkgNjg2MzU5MA0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogY2NhbXAt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250 byBkaSBJZ29yIEJyeXNraW4NCkludmlhdG86IG1lcmNvbGVk7CAyMSBsdWdsaW8gMjAxMCAxNS41 MQ0KQTogT25nLCBMeW5kb247IERhbmllbGUgQ2VjY2FyZWxsaTsgSm9obiBFIERyYWtlOyBjdXJ0 aXNAb2NjbmMuY29tOyBTbmlnZGhvIEJhcmRhbGFpDQpDYzogY2NhbXBAaWV0Zi5vcmc7IFNuaWdk aG8gQmFyZGFsYWkNCk9nZ2V0dG86IFJlOiBbQ0NBTVBdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQNCg0KV2UgbmVlZCB0byBkaXNjdXNzIHRo aXMgZmFjZSB0byBmYWNlLiBUaGUgYmlnZ2VzdCBkaXNhZ3JlZW1lbnRzIHdpdGggRGFuaWVsZSBh cmU6DQoxKSBJIGRvbid0IGJlbGlldmUgdGhhdCBmbGF0IHJvdXRpbmcgbW9kZWwgb2YgYSBtdWx0 aS1sYXllciBPVE4gbmV0d29yayBpcyBjb3JyZWN0Lg0KMikgSSB0aGluayBlYWNoIE9UTiByb2xl IGRlZmluZXMgYSBzZXBhcmF0ZSB0b3BvbG9neSBvZiBPVE4gbGlua3MsIGFuZCB0aGVyZSBpcyBh IG5lZWQgdG8gYmUgYWJsZSB0byBjb25zdHJhaW4gdGhlIHJvdXRpbmcgb2YgYSBnaXZlbiBPVE4g Y29ubmVjdGlvbiB0byBvbmUgb3IgbW9yZSAoYnV0IG5vdCBuZWNlc3NhcmlseSBhbGwpIHN1Y2gg dG9wb2xvZ2llczsNCjMpIFRoZXJlIGlzIGFuIGlzc3VlIGluIHRoZSBjdXJyZW50IGRlZmluaXRp b25zIG9mIEdNUExTIE9TUEYgZXh0ZW5zaW9ucyAoUkZDIDQyMDMpLCB3aGljaCBkb2VzIGFsbG93 IHRvIHNwZWNpZnkgbXVsdGlwbGUgSVNDRHMgYnV0IGRvZXMgbm90IGd1aWRlIGFzIHRvIGhvdyB0 aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCBvbiB0aGUgbGluayBpcyBwYXJ0aXRpb25lZCBiZXR3ZWVu IElTQ0RzLiBUaGlzIGlzIGEgZ2VuZXJpYyBpc3N1ZSBhbmQgc2hvdWxkIGJlIHJlc29sdmVkIGlu IGEgZ2VuZXJpYyB3YXk7DQo0KSBPdGhlciB0aGFuICgzKSB3ZSBkb24ndCBuZWVkIGFueSBPVE4g b3IgVERNIHNwZWNpZmljIENQIG1hY2hpbmVyeSBmb3IgVEUgYW5kIHJvdXRpbmcgaW4gT1ROIG5l dHdvcmtzLiBVbmxlc3Mgd2Ugc2VlIHN0cm9uZyByZWFzb25zIHRvIHRoZSBjb250cmFyeSB3ZSBz aG91bGQgbm90IGludmVudCBzdWNoIG1hY2hpbmVyeS4NCg0KQ2hlZXJzLA0KSWdvcg0KDQo= From curtis@occnc.com Wed Jul 21 12:59:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838443A67DB for ; Wed, 21 Jul 2010 12:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK-VT3xHZ8sz for ; Wed, 21 Jul 2010 12:59:55 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 16CF83A67A1 for ; Wed, 21 Jul 2010 12:59:54 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LK01OT088290; Wed, 21 Jul 2010 16:00:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007212000.o6LK01OT088290@harbor.orleans.occnc.com> To: "Daniele Ceccarelli" From: Curtis Villamizar In-reply-to: Your message of "Wed, 21 Jul 2010 10:29:03 +0200." Date: Wed, 21 Jul 2010 16:00:00 -0400 Sender: curtis@occnc.com Cc: Snigdho Bardalai , ccamp@ietf.org, Igor Bryskin Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:59:56 -0000 In message "Daniele Ceccarelli" writes: > > Hi Curtis, > > You're perfectly right, the tools for Maximum Reservable Bandwidth and > Unreserved Bandwidth are already there, but they lack of > distinguishing how such bandiwdth is distributed over the various > signal types supported by the advertised link. Estending both of them > plus the ISCD could be a bigger effort and bandwidth consuming > solution than introducing all the required information into a single > sub-TLV. > > Cheers > Daniele Daniele, The only situation in which a new LSP was set up and a new FA was not needed would be the case where the endpoints exactly the same. If a ODU1 is set up inside an ODU3, the remaining reservable BW is (nominal) ODU3-ODU1. Since it is not possible to create 3.75 ODU2, only 3 ODU2, there is no issue. The new FA would be max-bandwidth of ODU1 and may be max-lsp-bw of either ODU0 or ODU1 depending on whether a HO ODU1 LSP was created. For the odd case where the new ODU1 LSP has the same end points as the old ODU3 LSP, creating an additional FA that might otherwise not be needed is not a big deal. Curtis > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Curtis Villamizar > Sent: mercoledì 21 luglio 2010 1.36 > To: Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > The point is that from ISCD you can not figure out how *many* LSPs > > matching the ISCD you can accommodate on the link. Such information is > > important in case of con-current routing (e.g. restoration after link > > failure). > > > > Igor > > Igor, Sergio, > > RFC 4203 (in 1. Introduction) > > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: > > [OSPF-TE] above is RFC 3630. > > RFC 3630 (in 2.4.2. Link TLV) > > The following sub-TLVs of the Link TLV are defined: > > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) > > If you read on you find: > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > > and > > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] > > So the totals per link and per priority level are already there in the base spec before the RFC 4203 *extensions* to RFC 3630 were added. > > That is how you figure out how many ODU0 you can add to your existing ODU2, and so on. > > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually knows everything about everything. Myself (all too obviously > sometimes) included.] > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > >From RFC 4202: > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > On an interface having Standard SDH multiplexing, an LSP at priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > > p. > > > > On an interface having Arbitrary SDH multiplexing, an LSP at priority > > p could reserve any bandwidth between the Minimum LSP Bandwidth and > > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > > > >From RFC 4201: > > > > 3.10. Maximum LSP Bandwidth > > > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP Bandwidth > > at priority p of all of its component links. > > > > > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > Snipped.... > > > > > > > > > > > I realized from someone in this thread (not from you) this was due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > > > > > JD: As the person to whom I believe you are referring, I would > > > suggest that you actually read RFC 4202 and 4206. From IBryskin@advaoptical.com Wed Jul 21 13:01:46 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0727F3A67DB for ; Wed, 21 Jul 2010 13:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ4txSlrEpGl for ; Wed, 21 Jul 2010 13:01:44 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 4D9343A67A1 for ; Wed, 21 Jul 2010 13:01:44 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LK1exq028840 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 22:01:40 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 22:01:40 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 16:01:38 -0400 From: Igor Bryskin To: Fatai Zhang , "BELOTTI, SERGIO (SERGIO)" Date: Wed, 21 Jul 2010 16:01:33 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspDSjfiP/t9apER/uYyeVzB3vBzwAACVUA Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76483@atl-srv-exgen.atl.advaoptical.com> References: "Your message of Tue, 20 Jul 2010 09:21:53 PDT." <201007201932.o6KJWZ1u066615@harbor.orleans.occnc.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761CF@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163984487CB18@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D761EF@atl-srv-exgen.atl.advaoptical.com> <0AFD1B67B949784DA087CDA9F0DD4AD901C29EC2@mdmxm03.ciena.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762F5@atl-srv-exgen.atl.advaoptical.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <03ae01cb290d$29ae17e0$6801a8c0@zhang> In-Reply-To: <03ae01cb290d$29ae17e0$6801a8c0@zhang> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_08:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:01:46 -0000 Fatai, Please see in line. -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Sent: Wednesday, July 21, 2010 3:45 PM To: Igor Bryskin; BELOTTI, SERGIO (SERGIO) Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John= E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve) Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Igor, Thanks very much. I support your suggestions. IB>> Excellent, thanks I would like to put a few items following your items to be discussed. (5) Discuss or clarify the original meaning of Swithcing Capability to see = if switching capability is equal to role. IB>> instance of GMPLS managing multiple layers views network as a stack of= topologies with distinct swicthcap (which is the topology ID). My suggesti= on for the OTN is to associate each virtual topology with the role, hence f= or OTN swicthcap =3D role=20 (6) Discuss if three layers or roles are competent for more than three laye= rs networks (at least 5 layers (ODUj(j=3D0/flex, 1,2,3,4...)). We know the = higher layer ODUk can provide virtual topology for the lower layer ODUj (j<= k). IB>> It should be 5, of course; 3 was an example In addtion, do you think if it is semi-flat routing model for your proposa= l?=20 IB>> If I understand you correctly, by semi-flat you mean some TE links adv= ertise more than 1 role. In this case, yes (7) Discuss what should be extended to RFC4203 to carry accurate routing in= formaiton. If it needs major changes on ISCD even though it looks like the = original ISCD of RFC4203, why we can not take a step forward to make it mor= e reasonable. IB>> Exactly, it should be a generic minor enhancement specific neither to = OTN nor TDM. Igor Thanks Fatai Zhang =20 Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28973234 Fax: +86-755-28972935 ----- Original Message -----=20 From: "Igor Bryskin" To: "BELOTTI, SERGIO (SERGIO)" Cc: ; "Snigdho Bardalai" ; "Ong, Ly= ndon" ; "Daniele Ceccarelli" ; "John E Drake" ; ; "Snigdho Bar= dalai" ; "Varma, Eve L (Eve)" ; "Fatai Zhang" Sent: Thursday, July 22, 2010 12:02 AM Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Hi Sergio, I'd like to run with you the following logic. 1. Suppose an operator after some planning decides to provision an infrastr= ucture ODU and use it as a link. Why would he do so? One reason that I can= think of is because he wants to build a virtual topology for a set of clie= nts (with possibly himself as one from the set). The purpose of this topolo= gy, generally speaking, is: a) To be non-congruent with underlying topology (virtual or OTU/OCh). = For example, to interconnect nodes that do not have a common OTU/OCh link; b) To constrain said set of clients to resources of the topology (rath= er than, for example, to use OTU/OCh links directly). The question is how the operator can constrain the routing of the ODUs for = the clients from the set to the prepared for this purpose virtual topology = within the flat ITU routing model? 2. Would you agree that the only reason why a TE link advertises an attribu= te is to be able to constrain a path computation based on the attribute? Yo= ur definitions of the OTN encoding types, for example, are: " .... o 8 - Lambda (Photonic) o 12 - G.709 ODUk (Digital Path) .... " which will give the operator an ability to route an OTN connection either s= traight over OTUs or over infrastructure ODUs with no regard to the roles a= ssigned to the links. Do you believe this would be flexible enough for the = operator? 3. What is it you can achieve with the suggested OTN routing that can not b= e achieved using multiple 4203 ISCDs? Thanks, Igor -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, July 21, 2010 10:59 AM To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John= E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zha= ng Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, For point 1) and 2) I do not think we are so far. You're proposing a three-layer approach , we are aligned with what ITU is p= roposing but we also have different roles in the network (lambda and sub-la= mbda) and than needs for constrains and policy in the network. The fact to have three switching capability to characterize the different r= oles in the same technology it seems to me a little against the concept of = switching capability itself. You could say that for packet there is already 4 PSC SC defined. But here w= e are in TDM , we have not label stacking capability. For point 3) and 4) , I do not discuss about the generality or not of the i= ssue, but surely you cannot negate that the problem of spatial allocation i= s raised as soon as SDH CP has been implemented . Then the same problem com= e in for OTN , and your intention to cope the issue in a generic way with m= odifications of RFC 4203 is a good intention, but take also into account th= at also our proposed format can be generic as soon as you change the signal= types supported. You're right we need to discuss face to face but my perception is that we c= a be less far than you believe. Cheers Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: mercoled=EC 21 luglio 2010 15.51 A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho= Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t We need to discuss this face to face. The biggest disagreements with Daniel= e are: 1) I don't believe that flat routing model of a multi-layer OTN network is = correct. 2) I think each OTN role defines a separate topology of OTN links, and ther= e is a need to be able to constrain the routing of a given OTN connection t= o one or more (but not necessarily all) such topologies; 3) There is an issue in the current definitions of GMPLS OSPF extensions (R= FC 4203), which does allow to specify multiple ISCDs but does not guide as = to how the available bandwidth on the link is partitioned between ISCDs. Th= is is a generic issue and should be resolved in a generic way; 4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE= and routing in OTN networks. Unless we see strong reasons to the contrary = we should not invent such machinery. Cheers, Igor From IBryskin@advaoptical.com Wed Jul 21 13:04:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624803A6B29 for ; Wed, 21 Jul 2010 13:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n3mEKaBmbmE for ; Wed, 21 Jul 2010 13:04:35 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 1FE3D3A6B1F for ; Wed, 21 Jul 2010 13:04:34 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6LK4obV031344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 21 Jul 2010 22:04:50 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 22:04:49 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Wed, 21 Jul 2010 16:04:35 -0400 From: Igor Bryskin To: "curtis@occnc.com" , Daniele Ceccarelli Date: Wed, 21 Jul 2010 16:04:31 -0400 Thread-Topic: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspD1KSp6jRD2OXRs6CCvAzUE75AAAAD4rQ Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D76485@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Wed, 21 Jul 2010 10:29:03 +0200." <201007212000.o6LK01OT088290@harbor.orleans.occnc.com> In-Reply-To: <201007212000.o6LK01OT088290@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-21_08:2010-07-21, 2010-07-21, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:04:37 -0000 Curtis, Could not agree more :=3D) Igor -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Wednesday, July 21, 2010 4:00 PM To: Daniele Ceccarelli Cc: curtis@occnc.com; Igor Bryskin; ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-01.= txt=20 In message "Daniele Ceccarelli" writes: > =20 > Hi Curtis, > =20 > You're perfectly right, the tools for Maximum Reservable Bandwidth and > Unreserved Bandwidth are already there, but they lack of > distinguishing how such bandiwdth is distributed over the various > signal types supported by the advertised link. Estending both of them > plus the ISCD could be a bigger effort and bandwidth consuming > solution than introducing all the required information into a single > sub-TLV. > =20 > Cheers > Daniele Daniele, The only situation in which a new LSP was set up and a new FA was not needed would be the case where the endpoints exactly the same. If a ODU1 is set up inside an ODU3, the remaining reservable BW is (nominal) ODU3-ODU1. Since it is not possible to create 3.75 ODU2, only 3 ODU2, there is no issue. The new FA would be max-bandwidth of ODU1 and may be max-lsp-bw of either ODU0 or ODU1 depending on whether a HO ODU1 LSP was created. For the odd case where the new ODU1 LSP has the same end points as the old ODU3 LSP, creating an additional FA that might otherwise not be needed is not a big deal. Curtis > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Curtis Villamizar > Sent: mercoled=EC 21 luglio 2010 1.36 > To: Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] R: Comment ondraft-ietf-ccamp-gmpls-g709-framework-0= 1.txt > =20 > =20 > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.= advaoptical.com> > Igor Bryskin writes: > > =20 > > John, > > =20 > > The point is that from ISCD you can not figure out how *many* LSPs=20 > > matching the ISCD you can accommodate on the link. Such information is= =20 > > important in case of con-current routing (e.g. restoration after link=20 > > failure). > > =20 > > Igor > =20 > Igor, Sergio, > =20 > RFC 4203 (in 1. Introduction) > =20 > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: > =20 > [OSPF-TE] above is RFC 3630. > =20 > RFC 3630 (in 2.4.2. Link TLV) > =20 > The following sub-TLVs of the Link TLV are defined: > =20 > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) > =20 > If you read on you find: > =20 > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > =20 > and > =20 > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] > =20 > So the totals per link and per priority level are already there in the ba= se spec before the RFC 4203 *extensions* to RFC 3630 were added. > =20 > That is how you figure out how many ODU0 you can add to your existing ODU= 2, and so on. > =20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually knows = everything about everything. Myself (all too obviously > sometimes) included.] > =20 > Curtis > =20 > =20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on=20 > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > =20 > > >From RFC 4202: > > =20 > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority = p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > =20 > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > =20 > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > =20 > > On an interface having Standard SDH multiplexing, an LSP at priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > > p. > > =20 > > On an interface having Arbitrary SDH multiplexing, an LSP at priorit= y > > p could reserve any bandwidth between the Minimum LSP Bandwidth and > > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > =20 > > >From RFC 4201: > > =20 > > 3.10. Maximum LSP Bandwidth > > =20 > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP Bandwidth > > at priority p of all of its component links. > > =20 > > =20 > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-=20 > > > framework-01.txt > > >=20 > > > Snipped.... > > >=20 > > > > > > > > I realized from someone in this thread (not from you) this was due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth=20 > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > >=20 > > > JD: As the person to whom I believe you are referring, I would=20 > > > suggest that you actually read RFC 4202 and 4206. From curtis@occnc.com Wed Jul 21 13:24:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636AD3A67D3 for ; Wed, 21 Jul 2010 13:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPa31h-pOP3Z for ; Wed, 21 Jul 2010 13:24:36 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id A63223A6B1F for ; Wed, 21 Jul 2010 13:24:35 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LKOpGZ088530; Wed, 21 Jul 2010 16:24:51 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> To: "BELOTTI, SERGIO (SERGIO)" From: Curtis Villamizar In-reply-to: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." Date: Wed, 21 Jul 2010 16:24:51 -0400 Sender: curtis@occnc.com Cc: Snigdho Bardalai , "ccamp@ietf.org" , Igor Bryskin Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:24:37 -0000 In message "BELOTTI, SERGIO (SERGIO)" writes: > > Hi Curtis, > > Thanks for your comment. > As pointed out by Daniele you're right but the missing information > here is the real spatial allocation that raised in importance above > all in case of link bundling unless you constrain the capability in 1 > component link per TE-link, that would reduce value of this very > important feature for scalability. Maybe I'm missing something (again). If so, please point out what I missed. In link bundling the min LSP BW is the smallest LSP or TDM container supported. Any multiple of the min LSP is allowed. The max LSP BW is the largest LSP that can be accommodated (per priority). The max reservable BW (not max LSP bw) is the total size of the bundle, ignoring any reservations, and the reservable BW (in the Link TLV in RFC 3630) indicates how much capacity is still left. For bundles as per RFC 4201: 3.10. Maximum LSP Bandwidth The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. For an unbundled link, the Maximum Bandwidth is defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p is defined to be the maximum of the Maximum LSP Bandwidth at priority p of all of its component links. The details of how Maximum LSP Bandwidth is carried in IS-IS is given in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried in OSPF is given in [GMPLS-OSPF]. This is consistent with RFC 4203 "Max LSP Bandwidth at priority N" being reported in the ISCD. 3.8. Unreserved Bandwidth The unreserved bandwidth of a bundled link at priority p is the sum of the unreserved bandwidths at priority p of all the component links associated with the bundled link. This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined in RFC 3630. That seems to me to completely cover link bundling with no constraints on its capability and no need for one TE-link (FA) per compoent link. > About the last part > > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] > > I'm completely agree with you. > I know all that is not simple and obvious stuff for everyone. > My only two cents is just to highlight it is not always possible > justify that different solution for SDH control plane with respect > what defined in RFC 4202/4203 are deployed, with a bad reading of > these RFCs. We are defining new OTN functionality so software will need to change. If prior SONET implementations didn't get it right that is no reason to not get it right in defining the OTN extensions. > Best Regards > > Sergio Curtis > Sergio Belotti > > System Architecture > Optics Division-Terrestrial Optics Unit > ALCATEL-LUCENT > > +39 039 6863033 > +39 039 6863590 > > > -----Messaggio originale----- > Da: curtis@occnc.com [mailto:curtis@occnc.com] > Inviato: mercoledì 21 luglio 2010 1.36 > A: Igor Bryskin > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > The point is that from ISCD you can not figure out how *many* LSPs > > matching the ISCD you can accommodate on the link. Such information is > > important in case of con-current routing (e.g. restoration after link > > failure). > > > > Igor > > Igor, Sergio, > > RFC 4203 (in 1. Introduction) > > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: > > [OSPF-TE] above is RFC 3630. > > RFC 3630 (in 2.4.2. Link TLV) > > The following sub-TLVs of the Link TLV are defined: > > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) > > If you read on you find: > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > > and > > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] > > So the totals per link and per priority level are already there in the > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > > That is how you figure out how many ODU0 you can add to your existing > ODU2, and so on. > > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > >From RFC 4202: > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > On an interface having Standard SDH multiplexing, an LSP at priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > > p. > > > > On an interface having Arbitrary SDH multiplexing, an LSP at priority > > p could reserve any bandwidth between the Minimum LSP Bandwidth and > > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > > > >From RFC 4201: > > > > 3.10. Maximum LSP Bandwidth > > > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP Bandwidth > > at priority p of all of its component links. > > > > > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > Snipped.... > > > > > > > > > > > I realized from someone in this thread (not from you) this was due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > > > > > JD: As the person to whom I believe you are referring, I would suggest > > > that you actually read RFC 4202 and 4206. From curtis@occnc.com Wed Jul 21 14:02:23 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE693A6B8B for ; Wed, 21 Jul 2010 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwFbKYCZEX7p for ; Wed, 21 Jul 2010 14:02:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id E23E63A6BB2 for ; Wed, 21 Jul 2010 14:02:19 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LL2UqO088974; Wed, 21 Jul 2010 17:02:30 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007212102.o6LL2UqO088974@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Wed, 21 Jul 2010 09:15:04 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 17:02:30 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 21:02:23 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D762C3@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > Curtis, > > I agree with all you said. The question is that if a single TE LINK > TLV contains several ISCDs sub-TLVs and a single "Maximum Reservable > Bandwidth" sub-TLV, how the available bandwidth can be partitioned > between ISCDs, so that a path computer making use of the TE LINK TLV > could figure out how many LSPs of each type (associated with each > ISCD) could be placed on the link. Again, this information is not > needed when paths are computed for one service at a time, but useful > for con-current path computations when several LSPs are (re-)placed at > the same time (e.g. in case of restoration after a failure of a link > carrying multiple LSPs). I've been trying to point out that this is not an issue. The case where an LSP is inside another LSP with identical endpoints on both layers is rare and it is questionable what purpose that serves. In that case an additional FA is needed for the newer contained LSP. The more common case is where one or more of the end point of the contained LSP extended beyond the endpoints of the containing LSP. In that case you always need another FA since the end points differ. The bandwidth for all containers is reduced by the same amount. The inability to create a fractional ODUj allows the fractional part of the unreserved bandwidth to do no harm. There is no constraint that unreserved bandwidth must be a multiple of the min-lsp-bw of any of the ISCDs. > Cheers, > Igor > > P.S. [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] > > I never do that. > Igor Yes. I agree. You don't. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, July 20, 2010 7:36 PM > To: Igor Bryskin > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaoptical.com> > Igor Bryskin writes: > > > > John, > > > > The point is that from ISCD you can not figure out how *many* LSPs > > matching the ISCD you can accommodate on the link. Such information is > > important in case of con-current routing (e.g. restoration after link > > failure). > > > > Igor > > Igor, Sergio, > > RFC 4203 (in 1. Introduction) > > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: > > [OSPF-TE] above is RFC 3630. > > RFC 3630 (in 2.4.2. Link TLV) > > The following sub-TLVs of the Link TLV are defined: > > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) > > If you read on you find: > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > > and > > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] > > So the totals per link and per priority level are already there in the > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > > That is how you figure out how many ODU0 you can add to your existing > ODU2, and so on. > > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] > > Curtis > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > >From RFC 4202: > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > On an interface having Standard SDH multiplexing, an LSP at priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > > p. > > > > On an interface having Arbitrary SDH multiplexing, an LSP at priority > > p could reserve any bandwidth between the Minimum LSP Bandwidth and > > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > > > >From RFC 4201: > > > > 3.10. Maximum LSP Bandwidth > > > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP Bandwidth > > at priority p of all of its component links. > > > > > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > Snipped.... > > > > > > > > > > > I realized from someone in this thread (not from you) this was due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > > > > > JD: As the person to whom I believe you are referring, I would suggest > > > that you actually read RFC 4202 and 4206. From curtis@occnc.com Wed Jul 21 14:38:02 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E8A3A6BC9 for ; Wed, 21 Jul 2010 14:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+OZjZX8b95r for ; Wed, 21 Jul 2010 14:37:58 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id B83573A6B50 for ; Wed, 21 Jul 2010 14:37:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LLbjZr090069; Wed, 21 Jul 2010 17:37:45 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 17:37:45 -0400 Sender: curtis@occnc.com Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 21:38:02 -0000 Igor, A current solution would be to use ML/MT extensions. A GMPLS E-NNI could also solve this problem if designed to isolate clients and resources in this manner. No hacking of RFC 4203 is needed. No (new) warts need to be added. Curtis In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: Hi Sergio, I'd like to run with you the following logic. 1. Suppose an operator after some planning decides to provision an infrastructure ODU and use it as a link. Why would he do so? One reason that I can think of is because he wants to build a virtual topology for a set of clients (with possibly himself as one from the set). The purpose of this topology, generally speaking, is: a) To be non-congruent with underlying topology (virtual or OTU/OCh). For example, to interconnect nodes that do not have a common OTU/OCh link; b) To constrain said set of clients to resources of the topology (rather than, for example, to use OTU/OCh links directly). The question is how the operator can constrain the routing of the ODUs for the clients from the set to the prepared for this purpose virtual topology within the flat ITU routing model? 2. Would you agree that the only reason why a TE link advertises an attribute is to be able to constrain a path computation based on the attribute? Your definitions of the OTN encoding types, for example, are: " .... o 8 - Lambda (Photonic) o 12 - G.709 ODUk (Digital Path) .... " which will give the operator an ability to route an OTN connection either straight over OTUs or over infrastructure ODUs with no regard to the roles assigned to the links. Do you believe this would be flexible enough for the operator? 3. What is it you can achieve with the suggested OTN routing that can not be achieved using multiple 4203 ISCDs? Thanks, Igor -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, July 21, 2010 10:59 AM To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, For point 1) and 2) I do not think we are so far. You're proposing a three-layer approach , we are aligned with what ITU is proposing but we also have different roles in the network (lambda and sub-lambda) and than needs for constrains and policy in the network. The fact to have three switching capability to characterize the different roles in the same technology it seems to me a little against the concept of switching capability itself. You could say that for packet there is already 4 PSC SC defined. But here we are in TDM , we have not label stacking capability. For point 3) and 4) , I do not discuss about the generality or not of the issue, but surely you cannot negate that the problem of spatial allocation is raised as soon as SDH CP has been implemented . Then the same problem come in for OTN , and your intention to cope the issue in a generic way with modifications of RFC 4203 is a good intention, but take also into account that also our proposed format can be generic as soon as you change the signal types supported. You're right we need to discuss face to face but my perception is that we ca be less far than you believe. Cheers Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igor Bryskin Inviato: mercoledì 21 luglio 2010 15.51 A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt We need to discuss this face to face. The biggest disagreements with Daniele are: 1) I don't believe that flat routing model of a multi-layer OTN network is correct. 2) I think each OTN role defines a separate topology of OTN links, and there is a need to be able to constrain the routing of a given OTN connection to one or more (but not necessarily all) such topologies; 3) There is an issue in the current definitions of GMPLS OSPF extensions (RFC 4203), which does allow to specify multiple ISCDs but does not guide as to how the available bandwidth on the link is partitioned between ISCDs. This is a generic issue and should be resolved in a generic way; 4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE and routing in OTN networks. Unless we see strong reasons to the contrary we should not invent such machinery. Cheers, Igor -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Wednesday, July 21, 2010 8:30 AM To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt I support this as well, of course. Whether this is a technology-specific extension of the ISCD format or a separate sub-TLV is a detail, however as Daniele points out many of the same considerations apply to both OTN and SONET/SDH. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, July 21, 2010 12:49 AM To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, In other words it could be possible to define 3 Switching Cap (LO, HO and SHO) and put what we defined in the encoding draft into the Switching Capability-specific information of the ISCD. Something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----Switching Capability-specific information |0|1|2|3|4|5|6|7| T | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I still don't understand why we need partitioning the network in three layers while just Sublamba and Full lambda distinction is enough (distinction supported advertising different signal types for full lambdas and sublambdas. Personally i still prefer advertising these pieces of information as a separate sub-TLV (called OTN-ISCD subTLV in the draft but easily estensible to TDM-ISCD accordingly to http://tools.ietf.org/html/draft-ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this could be a valid solution too. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: martedì 20 luglio 2010 23.02 To: John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved bandwidth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? You do not advertise unreserved bandwidth in the ISCD TLV. In particular, for TDM, what is advertised is the max and min bandwidth allowed for a single LSP. It was designed to produce a compact representation by taking advantage of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but wasteful. > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro= > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li= > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti= > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.= > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o= > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs= > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL= > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi= > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, = > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done > > > in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen= > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as = > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > > > > a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=EC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level. > > > > IB>> However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > IB>> unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=EC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D role; > > > > > > encodeType =3D muxCap & signal type; We also have 16 > > > > > > reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=EC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > path computation is constrained to the OTN_HO_SC topology, > > > > > > B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing > > > > > > the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ; > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology > > > > > > is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > switching capability field (confusing name as it is) is a > > > > > > good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > IB>> etc.) > > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > 3 > D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D=3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D=3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > > > > > > is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > 3 > D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3 -------------- > > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or > ODUj=3Df= > > lex > > > > > > even though the ODUk=3D2 at the next hop could not directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > >new TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > IB>> possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based > > > > > > > > on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > >> For example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > >> point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Wed Jul 21 14:55:43 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B603A6BDA for ; Wed, 21 Jul 2010 14:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUVDafwIFJ6u for ; Wed, 21 Jul 2010 14:55:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 5D9FE3A6B7D for ; Wed, 21 Jul 2010 14:55:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6LLtukW090353; Wed, 21 Jul 2010 17:55:56 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007212155.o6LLtukW090353@harbor.orleans.occnc.com> To: Igor Bryskin From: Curtis Villamizar In-reply-to: Your message of "Wed, 21 Jul 2010 14:28:41 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7642A@atl-srv-exgen.atl.advaoptical.com> Date: Wed, 21 Jul 2010 17:55:56 -0400 Sender: curtis@occnc.com Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 21:55:43 -0000 In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7642A@atl-srv-exgen.atl.advaoptical.com> Igor Bryskin writes: > > Curtis, > > > IB>> It is possible from the RFC4203 point of view. What I am saying > > is that it is not practical to advertise for the same link both TDM > > and PSC ISCDs. It is only possible when: > > a) TDM topology and PSC topology are congruent (at least partially); > > b) TDM topology and PSC topology share the same address space; > > c) TDM and PSC share the same routing instance. > > > > Igor > > > That is essentially the peer model, which is in fact possible. > > IB>> That's what people thought when they were 10 years younger :=) > I would like to talk to somebody who has ever seen such configuration > outside of an interop demo. > > Igor The same could be said of almost any two ISC types in the GMPLS hierarchy, not just PSC and TDM. We could also go off on the topic of interoperability among GMPLS implementations. Of the limited deployment of GMPLS that is not PSC, there is very little deployment that is mixed vendor. In any case, this was based on the example given in RFC 4202. If it is nothing more than an acedemic example, that is irrelevant to the discussion of how RFC 3630, 4201, 4202, 4203 were intended to work. Curtis From IBryskin@advaoptical.com Thu Jul 22 05:51:04 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9CF3A657C for ; Thu, 22 Jul 2010 05:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6K--myLHRgx for ; Thu, 22 Jul 2010 05:51:01 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 1FDDC3A67B5 for ; Thu, 22 Jul 2010 05:51:00 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6MCpBuF001321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 22 Jul 2010 14:51:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Jul 2010 14:51:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 22 Jul 2010 08:51:09 -0400 From: Igor Bryskin To: "curtis@occnc.com" , "BELOTTI, SERGIO (SERGIO)" Date: Thu, 22 Jul 2010 08:50:57 -0400 Thread-Topic: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspEsqpJ8NTxF2xSxmlLsAWGH81FgAiE+aw Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD67A2@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> In-Reply-To: <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-22_03:2010-07-22, 2010-07-22, 1970-01-01 signatures=0 Cc: "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:51:04 -0000 Curtis, Please, see my comments in line. Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Wednesday, July 21, 2010 4:25 PM To: BELOTTI, SERGIO (SERGIO) Cc: Snigdho Bardalai; ccamp@ietf.org; Igor Bryskin Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework= -01.txt In message "BELOTTI, SERGIO (SERGIO)" writes: > =20 > Hi Curtis, > =20 > Thanks for your comment. > As pointed out by Daniele you're right but the missing information=20 > here is the real spatial allocation that raised in importance above=20 > all in case of link bundling unless you constrain the capability in 1=20 > component link per TE-link, that would reduce value of this very=20 > important feature for scalability. Maybe I'm missing something (again). If so, please point out what I missed= . In link bundling the min LSP BW is the smallest LSP or TDM container suppor= ted. Any multiple of the min LSP is allowed. The max LSP BW is the larges= t LSP that can be accommodated (per priority). The max reservable BW (not = max LSP bw) is the total size of the bundle, ignoring any reservations, and= the reservable BW (in the Link TLV in RFC 3630) indicates how much capacit= y is still left. For bundles as per RFC 4201: 3.10. Maximum LSP Bandwidth The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. For an unbundled link, the Maximum Bandwidth is defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p is defined to be the maximum of the Maximum LSP Bandwidth at priority p of all of its component links. The details of how Maximum LSP Bandwidth is carried in IS-IS is given in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried in OSPF is given in [GMPLS-OSPF]. This is consistent with RFC 4203 "Max LSP Bandwidth at priority N" being reported in the ISCD. 3.8. Unreserved Bandwidth The unreserved bandwidth of a bundled link at priority p is the sum of the unreserved bandwidths at priority p of all the component links associated with the bundled link. This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined in RF= C 3630. That seems to me to completely cover link bundling with no constraints on i= ts capability and no need for one TE-link (FA) per compoent link. IB>> Correct as long as components share the same termination points. Gener= ally speaking, when an infrastructure ODU is provisioned, it has more than = 1 hope, hehence needs to be advertised as a separate FA TE link. > About the last part > =20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually=20 > knows everything about everything. Myself (all too obviously > sometimes) included.] > =20 > I'm completely agree with you. > I know all that is not simple and obvious stuff for everyone.=20 > My only two cents is just to highlight it is not always possible=20 > justify that different solution for SDH control plane with respect=20 > what defined in RFC 4202/4203 are deployed, with a bad reading of=20 > these RFCs. We are defining new OTN functionality so software will need to change. If = prior SONET implementations didn't get it right that is no reason to not ge= t it right in defining the OTN extensions. IB>> agreed 100%. Also, CP architecture and protocols are the center part o= f IETF CCAMP charter, and we have all rights questioning ITU solutions wrt = CP. Igor=20 > Best Regards > =20 > Sergio Curtis > Sergio Belotti > =20 > System Architecture > Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT > =20 > +39 039 6863033 > +39 039 6863590 > =20 > =20 > -----Messaggio originale----- > Da: curtis@occnc.com [mailto:curtis@occnc.com] > Inviato: mercoled=EC 21 luglio 2010 1.36 > A: Igor Bryskin > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho=20 > Bardalai > Oggetto: Re: [CCAMP] R: Comment on=20 > draft-ietf-ccamp-gmpls-g709-framework-01.txt > =20 > =20 > In message=20 > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.advaopti > cal.com> > Igor Bryskin writes: > > =20 > > John, > > =20 > > The point is that from ISCD you can not figure out how *many* LSPs=20 > > matching the ISCD you can accommodate on the link. Such information=20 > > is important in case of con-current routing (e.g. restoration after=20 > > link failure). > > =20 > > Igor > =20 > Igor, Sergio, > =20 > RFC 4203 (in 1. Introduction) > =20 > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: > =20 > [OSPF-TE] above is RFC 3630. > =20 > RFC 3630 (in 2.4.2. Link TLV) > =20 > The following sub-TLVs of the Link TLV are defined: > =20 > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) > =20 > If you read on you find: > =20 > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > =20 > and > =20 > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] > =20 > So the totals per link and per priority level are already there in the=20 > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > =20 > That is how you figure out how many ODU0 you can add to your existing=20 > ODU2, and so on. > =20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually=20 > knows everything about everything. Myself (all too obviously > sometimes) included.] > =20 > Curtis > =20 > =20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on=20 > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > =20 > > >From RFC 4202: > > =20 > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority = p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > =20 > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > =20 > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > =20 > > On an interface having Standard SDH multiplexing, an LSP at priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > > p. > > =20 > > On an interface having Arbitrary SDH multiplexing, an LSP at priorit= y > > p could reserve any bandwidth between the Minimum LSP Bandwidth and > > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > =20 > > >From RFC 4201: > > =20 > > 3.10. Maximum LSP Bandwidth > > =20 > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP Bandwidth > > at priority p of all of its component links. > > =20 > > =20 > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-=20 > > > framework-01.txt > > >=20 > > > Snipped.... > > >=20 > > > > > > > > I realized from someone in this thread (not from you) this was=20 > > > > due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth=20 > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > >=20 > > > JD: As the person to whom I believe you are referring, I would=20 > > > suggest that you actually read RFC 4202 and 4206. From IBryskin@advaoptical.com Thu Jul 22 06:24:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991553A687B for ; Thu, 22 Jul 2010 06:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwJGdxzC8W8X for ; Thu, 22 Jul 2010 06:24:26 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 624493A69FE for ; Thu, 22 Jul 2010 06:24:25 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6MDOWgY015415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 22 Jul 2010 15:24:32 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Jul 2010 15:24:32 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 22 Jul 2010 09:24:29 -0400 From: Igor Bryskin To: "curtis@occnc.com" Date: Thu, 22 Jul 2010 09:24:22 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ6O/b+4FluKSayjbP+dwRteRAAg2f6g Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD67D7@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> In-Reply-To: <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-22_03:2010-07-22, 2010-07-22, 1970-01-01 signatures=0 Cc: "Ong, Lyndon" , "ccamp@ietf.org" , Snigdho Bardalai , "Varma, Eve L \(Eve\)" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 13:24:30 -0000 Curtis, The same OTN TE link can play several roles (e.g. LO ODU2 and HO ODU2). Alt= hough, the two roles will share the same physical resources, operator may h= ave a policy saying that the resources are divided between the roles (e.g. = 50%-50% or 75%-25%). Therefore, I believe some enhancement to 4203 will be = needed. Otherwise, I agree. Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Wednesday, July 21, 2010 5:38 PM To: Igor Bryskin Cc: Varma, Eve L (Eve); ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, A current solution would be to use ML/MT extensions. A GMPLS E-NNI could also solve this problem if designed to isolate clients and resources in this manner. No hacking of RFC 4203 is needed. No (new) warts need to be added. Curtis In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.ad= vaoptical.com> Igor Bryskin writes: Hi Sergio, I'd like to run with you the following logic. 1. Suppose an operator after some planning decides to provision an infrastr= ucture ODU and use it as a link. Why would he do so? One reason that I can= think of is because he wants to build a virtual topology for a set of clie= nts (with possibly himself as one from the set). The purpose of this topolo= gy, generally speaking, is: a) To be non-congruent with underlying topology (virtual or OTU/OCh). = For example, to interconnect nodes that do not have a common OTU/OCh link; b) To constrain said set of clients to resources of the topology (rath= er than, for example, to use OTU/OCh links directly). The question is how the operator can constrain the routing of the ODUs for = the clients from the set to the prepared for this purpose virtual topology = within the flat ITU routing model? 2. Would you agree that the only reason why a TE link advertises an attribu= te is to be able to constrain a path computation based on the attribute? Yo= ur definitions of the OTN encoding types, for example, are: " .... o 8 - Lambda (Photonic) o 12 - G.709 ODUk (Digital Path) .... " which will give the operator an ability to route an OTN connection either s= traight over OTUs or over infrastructure ODUs with no regard to the roles a= ssigned to the links. Do you believe this would be flexible enough for the = operator? 3. What is it you can achieve with the suggested OTN routing that can not b= e achieved using multiple 4203 ISCDs? Thanks, Igor -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: Wednesday, July 21, 2010 10:59 AM To: Igor Bryskin Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; John= E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zha= ng Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Igor, For point 1) and 2) I do not think we are so far. You're proposing a three-layer approach , we are aligned with what ITU is p= roposing but we also have different roles in the network (lambda and sub-la= mbda) and than needs for constrains and policy in the network. The fact to have three switching capability to characterize the different r= oles in the same technology it seems to me a little against the concept of = switching capability itself. You could say that for packet there is already 4 PSC SC defined. But here w= e are in TDM , we have not label stacking capability. For point 3) and 4) , I do not discuss about the generality or not of the i= ssue, but surely you cannot negate that the problem of spatial allocation i= s raised as soon as SDH CP has been implemented . Then the same problem com= e in for OTN , and your intention to cope the issue in a generic way with m= odifications of RFC 4203 is a good intention, but take also into account th= at also our proposed format can be generic as soon as you change the signal= types supported. You're right we need to discuss face to face but my perception is that we c= a be less far than you believe. Cheers Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Igo= r Bryskin Inviato: mercoled=EC 21 luglio 2010 15.51 A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho= Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t We need to discuss this face to face. The biggest disagreements with Daniel= e are: 1) I don't believe that flat routing model of a multi-layer OTN network is = correct. 2) I think each OTN role defines a separate topology of OTN links, and ther= e is a need to be able to constrain the routing of a given OTN connection t= o one or more (but not necessarily all) such topologies; 3) There is an issue in the current definitions of GMPLS OSPF extensions (R= FC 4203), which does allow to specify multiple ISCDs but does not guide as = to how the available bandwidth on the link is partitioned between ISCDs. Th= is is a generic issue and should be resolved in a generic way; 4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE= and routing in OTN networks. Unless we see strong reasons to the contrary = we should not invent such machinery. Cheers, Igor -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Wednesday, July 21, 2010 8:30 AM To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; Snigd= ho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t I support this as well, of course. Whether this is a technology-specific e= xtension of the ISCD format or a separate sub-TLV is a detail, however as D= aniele points out many of the same considerations apply to both OTN and SON= ET/SDH. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, July 21, 2010 12:49 AM To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: ccamp@ietf.org; Snigdho Bardalai Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, In other words it could be possible to define 3 Switching Cap (LO, HO and S= HO) and put what we defined in the encoding draft into the Switching Capabi= lity-specific information of the ISCD. Something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----S= witching Capability-specific information |0|1|2|3|4|5|6|7| T | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type |F| Bandwidth @ P7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I still don't understand why we need partitioning the network in three laye= rs while just Sublamba and Full lambda distinction is enough (distinction s= upported advertising different signal types for full lambdas and sublambdas= . Personally i still prefer advertising these pieces of information as a sepa= rate sub-TLV (called OTN-ISCD subTLV in the draft but easily estensible to = TDM-ISCD accordingly to http://tools.ietf.org/html/draft-ong-gmpls-ason-rou= ting-exper-02 format proposed by the OIF) but this could be a valid solutio= n too. BR Daniele -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: marted=EC 20 luglio 2010 23.02 To: John E Drake; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t John, Do you understand the quote from RFC4203: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You can use the last field for OTN switchcap to advertise unresolved bandwi= dth available for the ISCD on per priority level. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Tuesday, July 20, 2010 4:35 PM To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Snipped... > IDSC sub-TLV and you can specify the unreserved bandwidth per priority > level for every ISCD. JD: Igor, what part of my quote from RFC 4202 did you not understand? You= do not advertise unreserved bandwidth in the ISCD TLV. In particular, for= TDM, what is advertised is the max and min bandwidth allowed for a single = LSP. It was designed to produce a compact representation by taking advanta= ge of the SDH/SONET hierarchy. Advertising a separate ISCD for each supported rate is allowed but wasteful= . > > Igor > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > wro=3D > > te: > > > > > John, > > > > > > I totally agree with you. It is absolutely non OTN specific. > However if a > > > TE link advertises more than one ISCD (with each ISCD containing > only max > > > lsp bandwidth per priority), it is necessary to indicate how the > total li=3D > > nk > > > unreserved bandwidth is partitioned between several ISCDs. What I > am > > > suggesting is instead of advertising the unreserved bandwidth > multiple ti=3D > > mes > > > (one per ISCD), indicate how the bandwidth is split between the > ISCDs: e.=3D > > g > > > ISCD1 75%, ISCD2 25%. > > > > > > Igor. > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > Zhang; > > > curtis@occnc.com > > > Cc: ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > Igor, > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > issue o=3D > > f > > > partitioning unreserved bandwidth across multiple advertised TDM > ISC TLVs=3D > > is > > > actually a non-issue. > > > > > > Unreserved bandwidth by priority has always been advertised using > the MPL=3D > > S > > > sub-TLV. My point has been that we have never had a requirement > (includi=3D > > ng > > > SDH/SONET) in the past to advertise unreserved bandwidth by signal > type, =3D > > so > > > what is special about OTN? > > > > > > A further point would be that if we do decide that it is necessary > to > > > advertise unreserved bandwidth by signal type, it should be done > > > in > a > > > general way and not in an OTN specific manner. (And in fact, the > argumen=3D > > ts > > > that unreserved bandwidth by signal type needs to be advertised, > such as =3D > > the > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > > Of Igor Bryskin > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > It is a valid point, but the suggested solution is way too > expensive. > > > > All you need is a way to say how the advertised unreserved > bandwidth is > > > > partitioned between ISCDs in case the TE link advertisement > contains > > > > several of them. One cheap way of doing so is to allocate 3-4 > bits out > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > total > > > > unreserved bandwidth associated with the ISCD. Another way is to > use > > > > swicthcap specific extension. > > > > BTW: this is not an OTN specific issue, rather more general: any > time > > > > when a TE link advertises more than one ISCD (which is perfectly > Ok > > > > according to 4203) you'll have the same problem. > > > > > > > > Igor > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, > > > > > > > > The need for unreserved resources advertised per signal type is > the > > > > concurrent path computation. I'll answer quoting a section from > the > > > > info-model draft, please have a look in particular to the > example: > > > > > > > > > > > > " Unreserved resources need to be advertised per priority and > per > > > > signal type in order to allow the correct functioning of the > > > > restoration process. [RFC4203] only allows advertising > unreserved > > > > resources per priority, this leads not to know how many LSPs > of a > > > > specific signal type can be restored. As example it is > possible to > > > > consider the scenario depicted in the following figure. > > > > > > > > +------+ component link 1 +------+ > > > > | +------------------+ | > > > > | | component link 2 | | > > > > | N1 +------------------+ N2 | > > > > | | component link 3 | | > > > > | +------------------+ | > > > > +------+ +---+--+ > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > with > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > on the > > > > third and supporting ODU2 and ODU3 signal types. The node > would > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > > > > a > MAX > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > network > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > only > a > > > > single ODU3 can be set up and a crank-back would be > originated. In > > > > more complex network scenarios the number of crank-backs can > be much > > > > higher." > > > > > > > > In other words, advertising the number of availble resources per > signal > > > > type does not avoid the possibility of cranck-back but decreases > it as > > > > much as possible. For sure a good routing prevents from crank- > backs > > > > caused by the restoration of LSP originating on the same Ingress. > The > > > > cranck-backs due to the concurrent restoration of LSPs > originating on > > > > different ingress nodes cannot be avoided. > > > > > > > > BR > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > In line > > > > > > > > -----Original Message----- > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Igor, one more question. > > > > > > > > What about the unreserved bandwidth? > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > per > > > > (muxCap & signal type) you also need to advertise the unreserved > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct? > This > > > > also implies extending the unreserved bandwidth TLV so to create > a > > > > corrispondence between the couples (ISCD-unreserved bandwidth > subTLV). > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD > per > > > > IB>> role per (muxCap & signal type) per priority level. > > > > IB>> However, > total > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > IB>> unless > you > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > Igor > > > > > > > > Thanks > > > > Daniele > > > > > > > > -----Original Message----- > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > > 01.txt > > > > > > > > Understood... > > > > > > > > Regards > > > > Snigdho > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > That's exactly what I've been > > > > > trying to say all along. > > > > > > > > > > Cheers, > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework- > > > > > 01.txt > > > > > > > > > > Igor > > > > > > > > > > Please see inline. > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Daniele, > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > per > > > > role > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > signal > > > > type. > > > > > > > > > > > > IB>> in ISCD: > > > > > > switchCap =3D3D role; > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > reserved bits which can use for OTN specific > info > > > > in > > > > > > case we need it. > > > > > [SCB] I am yet to clearly understand what the role of "role" > is, but > > > > > agree with your observation on the encode-type and the 16 > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > each > > > > role > > > > > > you would advertise just the unreserved bandwidth but you > wouldn't > > > > > know > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > LSP > (e.g. > > > > > 15 > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > available > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > scalability > > > > > issues > > > > > > and the requirement of being able to bundle component links > > > > together > > > > > > wouldn't be satisfied. > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > ISDCs > > > > will > > > > > > provide a lot of flexibility: you can specify different > things > > > > (e.g. > > > > > > available bandwidth) for the same link in different roles. > > > > > [SCB] Are you saying the ISCD as defined today with minor > extensions > > > > > (i.e. to further classify the information) will be sufficient? > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Fatai, > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of Fatai Zhang > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > > > > think that we need to extend ISC to meet the requirment. The > role > > > > of > > > > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > [draft- > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of "Full > > > > Lambda" > > > > > is > > > > > > introduced. > > > > > > > > > > > > IB>> This is possible, however: > > > > > > a) this requires OTN specific advertising and processing > rules; > > > > > > b) disallows topology separation in technology independent > way > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > AI1 > and > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > link > > > > ends > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > while > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > path computation is constrained to the OTN_HO_SC topology, > > > > > > B11 and > B12 > > > > TE > > > > > > links will > > > > > be > > > > > > disallowed, and the resulting path (if any) will not go > through B11 > > > > > and > > > > > > B12. If one circumvents the path computation by providing > > > > > > the > fully > > > > > > explicit path, the signaling should fail on node B for the > same > > > > > reason: > > > > > > inconsistency of required (signaled) and supported (by local > > > > > > interfaces) switchcap. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > the > > > > type > > > > > > indicated in the Switching Type parameter is supported on > the > > > > > > corresponding incoming interface. If the type cannot be > > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Lou Berger" ; > > > > > > ; > > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft- > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators can > > > > > > define different roles depending on their policy and achieve > the > > > > > > role through different methods. However, for OTN networks, > the > > > > > > containers (e.g., ODUk) all have the same switching > capablility > > > > > > (i.e., TDM > > > > > > switching) and I think we should reflect the natural > > > > characteristics > > > > > of > > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > > > > make the encoding type lose its' own meaning(ie., ISC > overrides > > > > > > encoding type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views the > > > > > > network as a stack of topologies. Whether a given topology > > > > > > is > real > > > > > > or virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > switching capability field (confusing name as it is) is a > > > > > > good way to > > > > describe > > > > > a > > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > stack of > > > > > > topologies that could be easily separated in technology > independent > > > > > way > > > > > > should path computation be constrained to particular one or > > > > > > sub-stack of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > topology. > > > > > > BTW IMO the role of an ODU container does not change hop-by- > hop (as > > > > > > some people seem to believe). The role is only meaningful on > the > > > > ODU > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > it's > > > > > position > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > > > role > > > > > > is the level of topology it is provisioned for and it is the > same > > > > > > for all ODUs that comprise the topology. For, example a user > may > > > > > provision > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > clients > to > > > > use > > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > > virtual > > > > > > topology the container is a part of and could be advertised > as the > > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > clarify? > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > IB>> etc.) > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > > (copied > > > > > as > > > > > > follows): > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > hierarchy, > > > > which > > > > > is > > > > > > a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 as > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > > > > > > is > a > > > > OTU3 > > > > > link > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > > > > over > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > > > how > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the ODU > > > > > > terminating nodes (i.e. on either side of corresponding > link). What > > > > > > happens on the ODU transit nodes and its place in the > hierarchy on > > > > > the > > > > > > transit nodes are of no importance. My LO container can be > carried > > > > > > by somebody else's LO container and can carry my client's LO > > > > container. > > > > > To > > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > > > (e.g. > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > along its > > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > 3 > D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > =3D3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > ; "Fatai Zhang" > ; > > > > > > "Lou Berger" ; ; > > > > > > > > > > gmpls- > > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > > introduced. But IMO they should indicate the link's mux > > > > capabilities > > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > indicated > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > 2. > > > > > > Link may advertise several roles (e.g. HO and SHO) with > different > > > > > > mux.capabilities per role; 3. Link's role and mux. > capabilities can > > > > > be > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > ISCD is > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > type > will > > > > > look > > > > > > to CP as a separate layer, which is exactly how ITU models > OTN > > > > > > hierarchies in all aspects but routing (!?) 5. If the > operator > > > > would > > > > > > want to constrain the routing of OTN connections to pre- > configured > > > > > > topology with a specific role (e.g. constrain all ODUs it > sells to > > > > > the > > > > > > clients to one or more pre-configured LO topologies), this > would be > > > > > > possible to do in a technology independent way. Suppose an > instance > > > > > of > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from > HO OTN > > > > > > links will be no different from the separation of WDM links > from > > > > > OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > many > as > > > > the > > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > */ > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > which had > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > long time > > > > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > commited > > > > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to 1.25 > TS > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > can > be > > > > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > > LSP > > > > > > regardless of what goes on in the middle since that > determines what > > > > > can > > > > > > be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 or > ODUj=3D3Df=3D > > lex > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > contain > > > > an ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > and > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > framework, > > > > > > or other intent. Could someone (either draft) concisely > summarize > > > > > > the multiplexing restrictions in one place, including > restrictions > > > > > > on number of multiplexing layers at one LSR. That might > help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > Berger > > > > > > > Cc: ccamp@ietf.org; > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] On > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > framework > > > > > > > > document before we can embark on any proposals to the > problem. > > > > I > > > > > am > > > > > > > > still not clear why do we have to deviate from the > general > > > > > approach > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > control > > > > > > > > IB>> plane, and > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > independent > > > > > paradigm > > > > > > > > of advertising of TE links, and there is no reason to > invent an > > > > > OTN > > > > > > > > specific ISCD. The combination of Switching Capability > and > > > > > Encoding > > > > > > > > type of RFC4202 ISCD allows for specifying both > multiplexing > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link, > and, > > > > if > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > >new TE-link > > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > IB>> possibility > to > > > > > create > > > > > > > > IB>> OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, one > > > > > > needs > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > > > > > > other interested experts, and we think the proposal > described > > > > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is more > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed for > > > > > > > > control plane, no matter how you encode the routing > > > > information. > > > > > > For > > > > > > > > TDM networks, you know the resource is allocated based > > > > > > > > on > TS, > > > > so > > > > > > the > > > > > > > > available TS should be get or induced before creating > cross- > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > information, > > > > > I > > > > > > > > think you need go to the routing drafts (info model and > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > > you > > > > > > > > will find that one of your suggestions is adopted (i.e., > simply > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ..., > ODU4 > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > links) > as FA > > > > > for > > > > > > > > ODU1, you have to advertise a new TE link or put this FA > as a > > > > > > > > component link of an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course > > > > > > > > > one of the main objectives of *C*CAMP. I look forward > to > > > > > hearing > > > > > > > > > from the draft and discussion contributors on there > progress > > > > > > > > > on > > > > > > this point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service > > > > > > > > >> routing purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > >> For example, consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > > > > > > >> then > > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > >> point > in > > > > > > > > >> time the OTU3 link has 12 time-slots available for > ODU2 > > > > > > > > >> services > > > > > and > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > ODU1s > > > > > > > > >> are contained over the ODU2). So it is obvious from > this > > > > > > > > >> example > > > > > > that > > > > > > > > >> the number of time-slots available is different based > on the > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > >> How do we address this issue based on the approach > specified > > > > > in > > > > > > > > >> the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > available > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > instances or > > > > > the > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This > > > > > > > > >> approach seems to be more in-line with the general > approach > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > > > > > > >> being advertised per VC rate for an SDH link. The > additional > > > > > > > > >> benefit > > > > > > is > > > > > > > > >> that the advertisement is TS size independent and > hence will > > > > > > > > >> simplify the implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Thu Jul 22 06:29:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D913A6B13 for ; Thu, 22 Jul 2010 06:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.153 X-Spam-Level: X-Spam-Status: No, score=-4.153 tagged_above=-999 required=5 tests=[AWL=2.096, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VLFs1NLj5nb for ; Thu, 22 Jul 2010 06:29:44 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A0A3E3A67B8 for ; Thu, 22 Jul 2010 06:29:42 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6MDTvCw030004 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Jul 2010 15:29:57 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 22 Jul 2010 15:29:57 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: "curtis@occnc.com" Date: Thu, 22 Jul 2010 15:29:55 +0200 Thread-Topic: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspEslx7yrt32Q5R6yxv2nXzSeAHQAjA+Cg Message-ID: References: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> In-Reply-To: <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "Varma, Eve L \(Eve\)" , Snigdho Bardalai , "ccamp@ietf.org" , Igor Bryskin Subject: [CCAMP] R: R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 13:29:45 -0000 Hi Curtis, 3.8. Unreserved Bandwidth The unreserved bandwidth of a bundled link at priority p is the sum of the unreserved bandwidths at priority p of all the component links associated with the bundled link. This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined in RFC 3630. That seems to me to completely cover link bundling with no constraints on its capability and no need for one TE-link (FA) per compoent link. SB> You cannot deduce form this advertisement how many LSP (ODU connections= ) of MAX LSP BW you can setup since you have not the information on how the= unreserved BW is allocate on the different component link and you can have= the impression to be able to setup a number of connection that instead is = not possible due to fragmentation of the usage of the BW in the different c= omponent link.=20 If the TE is per- component link this obviously not happen losing the scala= bility of bundling construct. You told me you have read the info draft for G.709, there is an example for= that. > About the last part=20 > =20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] > =20 > I'm completely agree with you. > I know all that is not simple and obvious stuff for everyone.=20 > My only two cents is just to highlight it is not always possible > justify that different solution for SDH control plane with respect > what defined in RFC 4202/4203 are deployed, with a bad reading of > these RFCs. We are defining new OTN functionality so software will need to change.=20 SB> Surely, possibly taking into account previous TDM experience. If prior SONET implementations didn't get it right that is no reason to not get it right in defining the OTN extensions. SB> Probably you misunderstood the sense of my wording: it is not the imple= mentation that did not right but the implementation of CP SDH will try to o= vercome lack in the reference standard document. I agree with you trying to avoid this can happen also for OTN. Best regards sergio > Best Regards > =20 > Sergio Curtis > Sergio Belotti > =20 > System Architecture > Optics Division-Terrestrial Optics Unit > ALCATEL-LUCENT > =20 > +39 039 6863033 > +39 039 6863590 > =20 > =20 > -----Messaggio originale----- > Da: curtis@occnc.com [mailto:curtis@occnc.com]=20 > Inviato: mercoled=EC 21 luglio 2010 1.36 > A: Igor Bryskin > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Barda= lai > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-= 01.txt=20 > =20 > =20 > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv-exgen.atl.= advaoptical.com> > Igor Bryskin writes: > > =20 > > John, > > =20 > > The point is that from ISCD you can not figure out how *many* LSPs > > matching the ISCD you can accommodate on the link. Such information is > > important in case of con-current routing (e.g. restoration after link > > failure).=20 > > =20 > > Igor=20 > =20 > Igor, Sergio, > =20 > RFC 4203 (in 1. Introduction) > =20 > The TE LSA, which is an opaque LSA with area flooding scope > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > and has one or more nested sub-TLVs for extensibility. The > top-level TLV can take one of two values (1) Router Address or (2) > Link. In this document, we enhance the sub-TLVs for the Link TLV > in support of GMPLS. Specifically, we add the following sub-TLVs > to the Link TLV: > =20 > [OSPF-TE] above is RFC 3630. > =20 > RFC 3630 (in 2.4.2. Link TLV) > =20 > The following sub-TLVs of the Link TLV are defined: > =20 > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Administrative group (4 octets) > =20 > If you read on you find: > =20 > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > =20 > and > =20 > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > not yet reserved at each of the eight priority levels in IEEE > floating point format. The values correspond to the bandwidth that > can be reserved with a setup priority of 0 through 7, arranged in > increasing order with priority 0 occurring at the start of the sub- > TLV, and priority 7 at the end of the sub-TLV. [...] > =20 > So the totals per link and per priority level are already there in the > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > =20 > That is how you figure out how many ODU0 you can add to your existing > ODU2, and so on. > =20 > [BTW- Lets please not talk about "ignorance and misunderstanding". > This is not simple obvious stuff and maybe none of us individually > knows everything about everything. Myself (all too obviously > sometimes) included.] > =20 > Curtis > =20 > =20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net]=20 > > Sent: Tuesday, July 20, 2010 1:13 PM > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framewor= k-01.txt > > =20 > > >From RFC 4202: > > =20 > > For a simple (unbundled) link the Maximum LSP Bandwidth at priority = p > > is defined as the maximum bandwidth an LSP at priority p could > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > [LINK-BUNDLE]. > > =20 > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > could reserve. > > =20 > > Typical values for the Minimum LSP Bandwidth and for the Maximum LSP > > Bandwidth are enumerated in [GMPLS-SIG]. > > =20 > > On an interface having Standard SDH multiplexing, an LSP at priority > > p could reserve any bandwidth allowed by the branch of the SDH > > hierarchy, with the leaf and the root of the branch being defined by > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority > > p. > > =20 > > On an interface having Arbitrary SDH multiplexing, an LSP at priorit= y > > p could reserve any bandwidth between the Minimum LSP Bandwidth and > > the Maximum LSP Bandwidth at priority p, provided that the bandwidth > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > =20 > > >From RFC 4201: > > =20 > > 3.10. Maximum LSP Bandwidth > > =20 > > The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. > > For an unbundled link, the Maximum Bandwidth is defined in > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > priority p is defined to be the maximum of the Maximum LSP Bandwidth > > at priority p of all of its component links. > > =20 > > =20 > > > -----Original Message----- > > > From: John E Drake > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > >=20 > > > Snipped.... > > >=20 > > > > > > > > I realized from someone in this thread (not from you) this was due > > > just > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > advertisement for SDH . Anyway it is a fact that the alternative > > > format > > > > is used in many implementations "in field" for SDH control plane. > > > > > > >=20 > > > JD: As the person to whom I believe you are referring, I would sugge= st > > > that you actually read RFC 4202 and 4206. From jdrake@juniper.net Thu Jul 22 08:10:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0143A6B9D for ; Thu, 22 Jul 2010 08:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe3004aOG11F for ; Thu, 22 Jul 2010 08:10:44 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id EB7013A6BB0 for ; Thu, 22 Jul 2010 08:10:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTEhfe1YX4md1nVRjrMb/HvRoqCIfZhVF@postini.com; Thu, 22 Jul 2010 08:11:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 22 Jul 2010 08:07:18 -0700 From: John E Drake To: "curtis@occnc.com" Date: Thu, 22 Jul 2010 08:07:16 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: Acso9DW8/CPBVJ3SQYC3GDI0R30oDwAt+v6A Message-ID: <5E893DB832F57341992548CDBB33316398449D9F44@EMBX01-HQ.jnpr.net> References: Your message of "Tue, 20 Jul 2010 13:17:32 PDT." <5E893DB832F57341992548CDBB333163984487CA7D@EMBX01-HQ.jnpr.net> <201007211645.o6LGjdfk086000@harbor.orleans.occnc.com> In-Reply-To: <201007211645.o6LGjdfk086000@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai , Lou Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:10:51 -0000 Snipped... > > The question we have been discussing is whether an intermediate node > > should be advertising the total unreserved bandwidth or unreserved > > bandwidth by service category for each of its links. I thought your > > e-mail indicated support for the latter position. > > Let me summarize: > > RFC 4203: > > Max Bandwidth is the total BW irrespective of what is reserved. JD: I didn't see that in 4203. As I explained to Igor, it is probably bet= ter to use 4202 rather than 4203 as it contains the explanation of the fiel= ds. > > Max LSP is the biggest LSP that can be created. > > Min LSP if provided is the smallest LSP and an LSP must be an > integer multiple of min LSP. JD: For PSC I don't think there is any relationship other than >=3D between= max and min. For TDM standard SDH/SONET, max and min describe a branch of= the SDH/SONET hierarchy and an LSP of any rate defined on that branch may = be established. For TDM arbitrary SDH/SONET, an LSP of rate N * min up to= a value of max may be established. > > RFC 3630: > > Link TLV Unreserved Bandwidth has the remaining unreserved > bandwidth per priority type. > > RFC 4203 extends RFC 3630 and therefore the is no "unreserved > bandwidth" specified in RFC 4203. > > In RFC 4202: > > [...] This document enhances the routing extensions [ISIS-TE], > [OSPF-TE] required to support MPLS Traffic Engineering (TE). > > [ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say > how to associate TE properties to regular (packet-switched) links. > This document extends the set of TE properties, and also says how to > associate TE properties with non-packet-switched links such as links > between Optical Cross-Connects (OXCs). [LSP-HIER] says how to > associate TE properties with links formed by Label Switched Paths. > > Note [OSPF-TE] =3D=3D RFC 3630, [ISIS-TE] =3D=3D RFC 3784. > > In RFC 4203: > > In this section, we define the enhancements to the Traffic > Engineering (TE) properties of GMPLS TE links that can be announced > in OSPF TE LSAs. The TE LSA, which is an opaque LSA with area > flooding scope [OSPF-TE], has only one top-level Type/Length/Value > (TLV) triplet and has one or more nested sub-TLVs for > extensibility. The top-level TLV can take one of two values (1) > Router Address or (2) Link. In this document, we enhance the > sub-TLVs for the Link TLV in support of GMPLS. Specifically, we > add the following sub-TLVs to the Link TLV: > > Sub-TLV Type Length Name > 11 8 Link Local/Remote Identifiers > 14 4 Link Protection Type > 15 variable Interface Switching Capability > Descriptor > 16 variable Shared Risk Link Group > > Note that none of the Link TLV sub-TLVs in RFC 3630 are obsoleted or > superceded. > > > What I was trying to point out was that unless an intermediate node > > issues a new advertisement every it activates or deactivates an LSP > > across its links, the state of its links in its last advertisement > may > > be very different from its current state, and that hence an ingress > > node does not have a reliable indication of that state. > > Yes. reservable bw must be updated. JD: Unreserved? > > > The example I used was that what was advertised for a given link was > 5 > > ODUj, even though the current unreserved bandwidth for ODUj is > > anywhere in the range 0 ODUj to 10 ODUj. > > The reservable bandwidth would indicate that half of the capacity was > still available. The min LSP bw indicates which ODUj you are dealing > with. JD: Right, but my point was that the actual unreserved bandwidth could act= ually be less than 5 ODUj, so the establishment of a 5 ODUj LSP would fail = even though it was in conformance with what was advertised. > > > I.e., advertising unreserved bandwidth by service category gives a > > false sense of security wrt the distributed awareness of the current > > state of the network. > > The reservable bandwidth is in bytes/sec which we both agree on. That > way any nominal multiple of min LSP could be used. A slight sticky > point is that ODU payloads are not exact integer multiples due to OH > which is why I stated nominal multiples. JD: According to Snigdho what is actually allowed is exact integer multipl= es. I.e., it would be possible to establish 84 ODU0 LSPs on an ODU4, but o= nly 80 are actually allowed. > > Curtis > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Tuesday, July 20, 2010 7:52 AM > > > > > To: Fatai Zhang > > > > > Cc: Igor Bryskin; curtis@occnc.com; John E Drake; Snigdho > Bardalai; > > > Lou > > > > > Berger; ccamp@ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > 01.txt > > > > > > > > > > > > > > > In message <0bd901cb26ec$e8329ec0$514c460a@china.huawei.com> > > > > > Fatai Zhang writes: > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > Thanks. > > > > > > > > > > Sorry to jump in but I think I understand Igor's objection (and > > > > > Snigdho's objection, and the reason this thread is going on). > > > > > > > > > > > I understand what you said. Therefore, we have added some > text to > > > > > > address the requirment in FWK document. However, we still > don't > > > think > > > > > > that we need to extend ISC to meet the requirment. The role > of > > > the > > > > > ODU > > > > > > can be get from the routing information implicitly. In the > > > > > > [draft-ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > > "Full > > > > > > Lambda" is introduced. > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > container > > > > > does > > > > > > not change hop-by-hop (as some people seem to believe). The > role > > > is > > > > > > only meaningful on the ODU terminating nodes and irrelevant > on > > > > > transit > > > > > > nodes. It is it's position in the hierarchy (but not role) > that > > > may > > > > > > change hop-by-hop. " > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces AI1 > and > > > CI1 > > > > > > can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 can > only > > > > > support > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 with > the > > > > > role > > > > > > of Ho ODU level is requested, according to your statement, > this > > > > > > conneciton will be allowed to be created. However, it should > not > > > be > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that the > > > type > > > > > > indicated in the Switching Type parameter is supported on the > > > > > > corresponding incoming interface. If the type cannot be > > > supported, > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > problem/Switching Type" indication." > > > > > > > > > > I think the objection, which would be a very valid one, is that > the > > > > > ingress has no way to know apriori that a path is infeasible. > Each > > > > > crankback delays convergence. Crankback should only occur if > > > another > > > > > ingress has reserved resources before signaling was completed, > not > > > > > because inadequate routing information is provided in quiescent > > > state. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: "Fatai Zhang" ; > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Lou Berger" ; > > > > > ; > > > > framework@tools.ietf.org> > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework-01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > Please, see my answers in line. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > ccamp@ietf.org; > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework-01.txt > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > I think role does not equal switching capability. The > operators > > > can > > > > > define different roles depending on their policy and achieve > the > > > role > > > > > through different methods. However, for OTN networks, the > > > containers > > > > > (e.g., ODUk) all have the same switching capablility (i.e., TDM > > > > > switching) and I think we should reflect the natural > > > characteristics of > > > > > links in the routing. In addition, if we extend the ISC, it > will > > > make > > > > > the encoding type lose its' own meaning(ie., ISC overrides > encoding > > > > > type). > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > views > > > the > > > > > network as a stack of topologies. Whether a given topology is > real > > > or > > > > > virtual is of no importance. > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its switching > > > > > capability field (confusing name as it is) is a good way to > > > describe a > > > > > layer in technology independent way, so that, say, MPLS-TP- > >OTN_LO- > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a stack > of > > > > > topologies that could be easily separated in technology > independent > > > way > > > > > should path computation be constrained to particular one or > sub- > > > stack > > > > > of them. > > > > > > I think a good way to identify an OTN (virtual) topology is > via > > > > > (infrastructure) ODU container role of ODUs comprising the > > > topology. > > > > > BTW IMO the role of an ODU container does not change hop-by-hop > (as > > > > > some people seem to believe). The role is only meaningful on > the > > > ODU > > > > > terminating nodes and irrelevant on transit nodes. It is it's > > > position > > > > > in the hierarchy (but not role) that may change hop-by-hop. > ODU's > > > role > > > > > is the level of topology it is provisioned for and it is the > same > > > for > > > > > all ODUs that comprise the topology. For, example a user may > > > provision > > > > > a LO topology and constrain ODUs he sells to a set of clients > to > > > use > > > > > the topology rather than any resources available on OTN > network. > > > > > > The bottom line: container's role is the same as the role of > > > virtual > > > > > topology the container is a part of and could be advertised as > the > > > > > corresponding link switchcap. > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > roles > > > and > > > > > muxing capabilities with the ISCD of RFC4202, could you > clarify? > > > > > > > > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, etc.) > > > > > > encoding type =3D mux. capabilities code > > > > > > > > > > > > In addition, could you clarify my questions in another email > > > (copied > > > > > as follows): > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > other. > > > > > > IB>> I disagree. You define role =3D=3D position in the > hierarchy, > > > which > > > > > is a mistake IMO. > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > ODU3 > > > as Ho > > > > > OTN Level or Lo OTN Level? Another example is, if there is a > OTU3 > > > link > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > (service > > > over > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this > case, > > > how > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN Level? > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > the > > > ODU > > > > > terminating nodes (i.e. on either side of corresponding link). > What > > > > > happens on the ODU transit nodes and its place in the hierarchy > on > > > the > > > > > transit nodes are of no importance. My LO container can be > carried > > > by > > > > > somebody else's LO container and can carry my client's LO > > > container. To > > > > > some extent it is similar to MPLS LSP role: LSP always has a > role > > > (e.g. > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack along > its > > > > > path. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > =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=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=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Fatai > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Igor Bryskin" > > > > > > To: > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > ; "Fatai Zhang" > ; > > > "Lou > > > > > Berger" ; ; ccamp- > > > gmpls- > > > > > g709-framework@tools.ietf.org> > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework-01.txt > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > types > > > > > introduced. But IMO they should indicate the link's mux > > > capabilities > > > > > rather than the link's role (i.e. level in the OTN hierarchy: > LO, > > > HO, > > > > > SHO, etc.). The link's role or roles IMO should be indicated > with a > > > > > separate switchcaps. I can give you several reasons: > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > roles; > > > > > > 2. Link may advertise several roles (e.g. HO and SHO) with > > > different > > > > > mux.capabilities per role; > > > > > > 3. Link's role and mux. capabilities can be advertised with > ISCDs > > > as > > > > > defined in RFC4202 (no OTN-style ISCD is required); > > > > > > 4. The combination of swicthcaps and encoding type will look > to > > > CP as > > > > > a separate layer, which is exactly how ITU models OTN > hierarchies > > > in > > > > > all aspects but routing (!?) > > > > > > 5. If the operator would want to constrain the routing of OTN > > > > > connections to pre-configured topology with a specific role > (e.g. > > > > > constrain all ODUs it sells to the clients to one or more pre- > > > > > configured LO topologies), this would be possible to do in a > > > technology > > > > > independent way. Suppose an instance of GMPLS CP manages WDM > and > > > OTN > > > > > NEs. Then separation of LO from HO OTN links will be no > different > > > from > > > > > the separation of WDM links from OTUs. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > To: Igor Bryskin > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger; > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > framework@tools.ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework-01.txt > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > srv- > > > > > exgen.atl.advaoptical.com> > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as many > as > > > the > > > > > depth of the deepest possible OTN DP hierarchy, for example: > > > > > > > > > > > > > > typedef enum > > > > > > > { > > > > > > > LSPSwitchType_Unknown =3D0 /* Unknown */ > > > > > > > , LSPSwitchType_PSC_1 =3D1 /* PSC-1 */ > > > > > > > , LSPSwitchType_PSC_2 =3D2 /* PSC-2 */ > > > > > > > , LSPSwitchType_PSC_3 =3D3 /* PSC-3 */ > > > > > > > , LSPSwitchType_PSC_4 =3D4 /* PSC-4 */ > > > > > > > , LSPSwitchType_L2SC =3D50 /* L2SC */ > > > > > > > , LSPSwitchType_TDM =3D100 /* TDM */ > > > > > > > > > > > > > > /*****/ > > > > > > > , LSPSwitchType_OTN_LO=3D124 /* OTN low order */ > > > > > > > , LSPSwitchType_OTN_HO=3D125 /* OTN high order */ > > > > > > > , LSPSwitchType_OTN_SHO=3D126 /* OTN super high order */ > > > > > > > /*****/ > > > > > > > , LSPSwitchType_LSC =3D150 /* LSC */ > > > > > > > , LSPSwitchType_FSC =3D200 /* FSC */ > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > make > > > the > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > Digital > > > Path > > > > > > layer and G.709 Optical Channel layer for 2009 OTN, which had > in > > > turn > > > > > > replaced the Encoding Type of "Digital Wrapper" a long time > ago. > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > did > > > not > > > > > > understand what the TS type meant did not try to multiplex > its LO > > > ODU > > > > > > at TS granularity 2.5 onto a HO ODU that had alraedy commited > to > > > > > using > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > OTN_HO > > > or > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > the > > > > > latter > > > > > > is for backward compatibility and should be ignored if > OTN_LO, > > > OTN_HO > > > > > > or OTN_SHO is understood. If the LSR commits to 1.25 TS > > > granularity, > > > > > > then the corresponding G.709 Digital Path FA can be > withdrawn. > > > > > > > > > > > > The Encoding type would be the lower encoding at each end of > the > > > LSP > > > > > > regardless of what goes on in the middle since that > determines > > > what > > > > > > can be wrapped inside it. > > > > > > > > > > > > For example: > > > > > > > > > > > > OTU3 > > > > > > OTU2 ODUk=3D3 -------------- > > > > > > OTU1 ODUk=3D2 -- ODUj=3D2 > > > > > > ODUk=3D1 --- ODUj=3D1 -- > > > > > > > > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or > ODUj=3Dflex > > > even > > > > > > though the ODUk=3D2 at the next hop could not directly contain > an > > > ODU0. > > > > > > If the SHO Encoding Type is used, then it indicates that two > > > levels > > > > > of > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC 4328 > > > Switch > > > > > > Types currently don't include an ODUj or ODUk distinction but > if > > > > > > Encoding Type indicated LO or HO, that may not be needed. > Along > > > with > > > > > > the new Encoding Type new Signal Types for ODU0, ODU4, and > ODU- > > > flex, > > > > > > and ODU2e, can be added. > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm > not > > > > > clear > > > > > > how in an FA it can be indicated that either type is > currently > > > > > > available (NE capable of both and hasn't committed to either > one > > > > > yet). > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > on > > > this > > > > > > would indicate a huge controversy and I'm not getting it > (other > > > than > > > > > a > > > > > > strong preference to rely on bytes/sec or on enumerated type > > > fields). > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > not > > > sure > > > > > if > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > > framework, or > > > > > > other intent. Could someone (either draft) concisely > summarize > > > the > > > > > > multiplexing restrictions in one place, including > restrictions on > > > > > > number of multiplexing layers at one LSR. That might help. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > framework-01.txt > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > > On > > > > > Behalf Of > > > > > > > > Igor Bryskin > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D8 I think we need to sort out the issues with the > framework > > > > > document > > > > > > > > before we can embark on any proposals to the problem. I > am > > > still > > > > > not clear > > > > > > > > why do we have to deviate from the general approach that > has > > > been > > > > > > > > established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > > control > > > > > plane, and > > > > > > > > it is highly desirable to adhere to the layer independent > > > > > paradigm of > > > > > > > > advertising of TE links, and there is no reason to invent > an > > > OTN > > > > > specific > > > > > > > > ISCD. The combination of Switching Capability and > Encoding > > > type > > > > > of RFC4202 > > > > > > > > ISCD allows for specifying both multiplexing capabilities > and > > > OTN > > > > > layer > > > > > > > > (LO, HO, SHO) of an OTN link, and, if this not > sufficient, > > > you > > > > > have > > > > > > > > another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a new > TE- > > > link > > > > > to > > > > > > > > represent >the low-order ODUj bandwidth within the high- > order > > > > > containers. > > > > > > > > This is simply >blowing up the solution to a very simple > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user possibility > to > > > > > create OTN > > > > > > > > hierarchies and constrain LO connections to HO > containers, > > > one > > > > > needs to > > > > > > > > advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > and > > > other > > > > > > > > interested experts, and we think the proposal described > in > > > > > "draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > is > > > more > > > > > feasible > > > > > > > > for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > needed > > > for > > > > > control > > > > > > > > plane, no matter how you encode the routing information. > For > > > TDM > > > > > networks, > > > > > > > > you know the resource is allocated based on TS, so the > > > available > > > > > TS should > > > > > > > > be get or induced before creating cross-connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > information, > > > > > I think > > > > > > > > you need go to the routing drafts (info model and > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > encoding), > > > you > > > > > will find > > > > > > > > that one of your suggestions is adopted (i.e., simply > > > advertize > > > > > the > > > > > > > > available number of ODU0, ODU1, ODU2, ..., ODU4 container > > > > > instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 links) > as > > > FA > > > > > for ODU1, > > > > > > > > you have to advertise a new TE link or put this FA as a > > > component > > > > > link of > > > > > > > > an existing TE link (like RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > Cc: >; ietf- > > > ccamp- > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > Cc: ccamp@ietf.org ; draft- > ietf- > > > ccamp- > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org gmpls- > > > > > g709- > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > I believe there has been some off-line discussion on > how to > > > > > better > > > > > > > > > align the work with 4202. Use of common approaches is > of > > > > > course one of > > > > > > > > > the main objectives of *C*CAMP. I look forward to > hearing > > > from > > > > > the > > > > > > > > > draft and discussion contributors on there progress on > this > > > > > point. > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > >> Hello, > > > > > > > > >> > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > This > > > > > section > > > > > > > > >> describes the link-parameters that are required for > OTN > > > > > service routing > > > > > > > > >> purposes. > > > > > > > > >> > > > > > > > > >> My comment is how are we going to advertise the low- > order > > > ODUj > > > > > > > > >> availability within a higher-order container. For > example, > > > > > consider an > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity > and > > > then > > > > > we > > > > > > > > >> establish an ODU2 service over the link. At this point > in > > > time > > > > > the OTU3 > > > > > > > > >> link has 12 time-slots available for ODU2 services and > up > > > to > > > > > 12+4 > > > > > > > > >> time-slots available for ODU1 services (4 ODU1s are > > > contained > > > > > over the > > > > > > > > >> ODU2). So it is obvious from this example that the > number > > > of > > > > > time-slots > > > > > > > > >> available is different based on the signal-type (i.e. > ODU1 > > > and > > > > > ODU2). > > > > > > > > >> How do we address this issue based on the approach > > > specified > > > > > in the > > > > > > > > draft? > > > > > > > > >> > > > > > > > > >> My other question is why not simply advertize the > > > available > > > > > number of > > > > > > > > >> ODU0, ODU1, ODU2, ..., ODU4 container instances or the > > > > > equivalent > > > > > > > > >> bandwidth in bytes/sec within a link? This approach > seems > > > to > > > > > be more > > > > > > > > >> in-line with the general approach outlined in RFC- > 4202. > > > Refer > > > > > to > > > > > > > > section > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > ISCDs > > > being > > > > > > > > >> advertised per VC rate for an SDH link. The additional > > > benefit > > > > > is that > > > > > > > > >> the advertisement is TS size independent and hence > will > > > > > simplify the > > > > > > > > >> implementation. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Snigdho From jdrake@juniper.net Thu Jul 22 08:32:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FADF3A6BE6 for ; Thu, 22 Jul 2010 08:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuHg3mHw+0yR for ; Thu, 22 Jul 2010 08:32:16 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id BBB6A3A6BD3 for ; Thu, 22 Jul 2010 08:32:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTEhkh1JigHw52uM013qqXz7Qs8s4i7eG@postini.com; Thu, 22 Jul 2010 08:32:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 22 Jul 2010 08:23:39 -0700 From: John E Drake To: "curtis@occnc.com" , "BELOTTI, SERGIO (SERGIO)" Date: Thu, 22 Jul 2010 08:23:37 -0700 Thread-Topic: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspEs4rfpzXbzHMSoS+YSwEHFKz6wAnrF6Q Message-ID: <5E893DB832F57341992548CDBB33316398449D9FB0@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> In-Reply-To: <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:32:29 -0000 Curtis, As I said last week, I think the existing RFC 4202/4203 design works just f= ine for unbundled links. For bundled links, due to bin packing, it is asserted that if one advertise= d unreserved bandwidth by what I have been calling service type (which in t= he OTN case equates to ODUj client rate), one can get a more accurate under= standing of the state of the bundled link wrt the number of LSPs that could= be established at each of the ODUj client rates available at the time of a= dvertisement. So, I think there are two questions. 1) Do we want to advertise unreserved= bandwidth by service type, and if so, do we want to advertise it for all l= inks or only for bundled links? Thanks, John =20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, July 21, 2010 1:25 PM > To: BELOTTI, SERGIO (SERGIO) > Cc: curtis@occnc.com; Daniele Ceccarelli; ccamp@ietf.org; Snigdho > Bardalai; Igor Bryskin; John E Drake > Subject: Re: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 >=20 > In message m.alcatel-lucent.com> > "BELOTTI, SERGIO (SERGIO)" writes: > > > > Hi Curtis, > > > > Thanks for your comment. > > As pointed out by Daniele you're right but the missing information > > here is the real spatial allocation that raised in importance above > > all in case of link bundling unless you constrain the capability in 1 > > component link per TE-link, that would reduce value of this very > > important feature for scalability. >=20 >=20 > Maybe I'm missing something (again). If so, please point out what I > missed. >=20 > In link bundling the min LSP BW is the smallest LSP or TDM container > supported. Any multiple of the min LSP is allowed. The max LSP BW is > the largest LSP that can be accommodated (per priority). The max > reservable BW (not max LSP bw) is the total size of the bundle, > ignoring any reservations, and the reservable BW (in the Link TLV in > RFC 3630) indicates how much capacity is still left. >=20 > For bundles as per RFC 4201: >=20 > 3.10. Maximum LSP Bandwidth >=20 > The Maximum LSP Bandwidth takes the place of the Maximum > Bandwidth. For an unbundled link, the Maximum Bandwidth is > defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a > bundled link at priority p is defined to be the maximum of the > Maximum LSP Bandwidth at priority p of all of its component links. > The details of how Maximum LSP Bandwidth is carried in IS-IS is > given in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth > is carried in OSPF is given in [GMPLS-OSPF]. >=20 > This is consistent with RFC 4203 "Max LSP Bandwidth at priority N" > being reported in the ISCD. >=20 > 3.8. Unreserved Bandwidth >=20 > The unreserved bandwidth of a bundled link at priority p is the > sum of the unreserved bandwidths at priority p of all the > component links associated with the bundled link. >=20 > This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined > in RFC 3630. >=20 > That seems to me to completely cover link bundling with no constraints > on its capability and no need for one TE-link (FA) per compoent link. >=20 >=20 > > About the last part > > > > [BTW- Lets please not talk about "ignorance and misunderstanding". > > This is not simple obvious stuff and maybe none of us individually > > knows everything about everything. Myself (all too obviously > > sometimes) included.] > > > > I'm completely agree with you. > > I know all that is not simple and obvious stuff for everyone. > > My only two cents is just to highlight it is not always possible > > justify that different solution for SDH control plane with respect > > what defined in RFC 4202/4203 are deployed, with a bad reading of > > these RFCs. >=20 >=20 > We are defining new OTN functionality so software will need to > change. If prior SONET implementations didn't get it right that is no > reason to not get it right in defining the OTN extensions. >=20 >=20 > > Best Regards > > > > Sergio >=20 >=20 > Curtis >=20 >=20 > > Sergio Belotti > > > > System Architecture > > Optics Division-Terrestrial Optics Unit > > ALCATEL-LUCENT > > > > +39 039 6863033 > > +39 039 6863590 > > > > > > -----Messaggio originale----- > > Da: curtis@occnc.com [mailto:curtis@occnc.com] > > Inviato: mercoled=EC 21 luglio 2010 1.36 > > A: Igor Bryskin > > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > Bardalai > > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > > > John, > > > > > > The point is that from ISCD you can not figure out how *many* LSPs > > > matching the ISCD you can accommodate on the link. Such information > is > > > important in case of con-current routing (e.g. restoration after > link > > > failure). > > > > > > Igor > > > > Igor, Sergio, > > > > RFC 4203 (in 1. Introduction) > > > > The TE LSA, which is an opaque LSA with area flooding scope > > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet > > and has one or more nested sub-TLVs for extensibility. The > > top-level TLV can take one of two values (1) Router Address or (2) > > Link. In this document, we enhance the sub-TLVs for the Link TLV > > in support of GMPLS. Specifically, we add the following sub-TLVs > > to the Link TLV: > > > > [OSPF-TE] above is RFC 3630. > > > > RFC 3630 (in 2.4.2. Link TLV) > > > > The following sub-TLVs of the Link TLV are defined: > > > > 1 - Link type (1 octet) > > 2 - Link ID (4 octets) > > 3 - Local interface IP address (4 octets) > > 4 - Remote interface IP address (4 octets) > > 5 - Traffic engineering metric (4 octets) > > 6 - Maximum bandwidth (4 octets) > > 7 - Maximum reservable bandwidth (4 octets) > > 8 - Unreserved bandwidth (32 octets) > > 9 - Administrative group (4 octets) > > > > If you read on you find: > > > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > > bandwidth that may be reserved on this link, in this direction, in > > IEEE floating point format. Note that this may be greater than > the > > maximum bandwidth (in which case the link may be oversubscribed). > > > > and > > > > The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth > > not yet reserved at each of the eight priority levels in IEEE > > floating point format. The values correspond to the bandwidth > that > > can be reserved with a setup priority of 0 through 7, arranged in > > increasing order with priority 0 occurring at the start of the > sub- > > TLV, and priority 7 at the end of the sub-TLV. [...] > > > > So the totals per link and per priority level are already there in > the > > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > > > > That is how you figure out how many ODU0 you can add to your existing > > ODU2, and so on. > > > > [BTW- Lets please not talk about "ignorance and misunderstanding". > > This is not simple obvious stuff and maybe none of us individually > > knows everything about everything. Myself (all too obviously > > sometimes) included.] > > > > Curtis > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 1:13 PM > > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt > > > > > > >From RFC 4202: > > > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > priority p > > > is defined as the maximum bandwidth an LSP at priority p could > > > reserve. Maximum LSP Bandwidth for a bundled link is defined in > > > [LINK-BUNDLE]. > > > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP > > > could reserve. > > > > > > Typical values for the Minimum LSP Bandwidth and for the Maximum > LSP > > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > > > On an interface having Standard SDH multiplexing, an LSP at > priority > > > p could reserve any bandwidth allowed by the branch of the SDH > > > hierarchy, with the leaf and the root of the branch being > defined by > > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > priority > > > p. > > > > > > On an interface having Arbitrary SDH multiplexing, an LSP at > priority > > > p could reserve any bandwidth between the Minimum LSP Bandwidth > and > > > the Maximum LSP Bandwidth at priority p, provided that the > bandwidth > > > reserved by the LSP is a multiple of the Minimum LSP Bandwidth. > > > > > > >From RFC 4201: > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > Bandwidth. > > > For an unbundled link, the Maximum Bandwidth is defined in > > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at > > > priority p is defined to be the maximum of the Maximum LSP > Bandwidth > > > at priority p of all of its component links. > > > > > > > > > > -----Original Message----- > > > > From: John E Drake > > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > Snipped.... > > > > > > > > > > > > > > I realized from someone in this thread (not from you) this was > due > > > > just > > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > > advertisement for SDH . Anyway it is a fact that the > alternative > > > > format > > > > > is used in many implementations "in field" for SDH control > plane. > > > > > > > > > > > > > JD: As the person to whom I believe you are referring, I would > suggest > > > > that you actually read RFC 4202 and 4206. From jdrake@juniper.net Thu Jul 22 09:29:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F523A6B20 for ; Thu, 22 Jul 2010 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.303 X-Spam-Level: X-Spam-Status: No, score=-5.303 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR3UdCXxYGfZ for ; Thu, 22 Jul 2010 09:29:25 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 1BA1A3A6B3C for ; Thu, 22 Jul 2010 09:29:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTEhx5vs5tGPmbbT02YCOdcMRz4KozFKV@postini.com; Thu, 22 Jul 2010 09:29:42 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 22 Jul 2010 09:19:27 -0700 From: John E Drake To: "curtis@occnc.com" , Igor Bryskin Date: Thu, 22 Jul 2010 09:19:22 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ5fxRxCX072TIeobRA5d6U+SgAm3o3g Message-ID: <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> In-Reply-To: <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 16:29:30 -0000 Igor, There is no reason to define multiple ISCD values for OTN networks in order= to constrain the path of a given LSP to only certain links. The right way= to do this is link colors (nee Administrative Groups, defined in RFC 3630)= , which is what it was designed to do. I know this is a radical thought but why don't we use ISCD for what it was = designed to do? Thanks, John > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, July 21, 2010 2:38 PM > To: Igor Bryskin > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho > Bardalai; Varma, Eve L (Eve); Fatai Zhang > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > Igor, > > A current solution would be to use ML/MT extensions. A GMPLS E-NNI > could also solve this problem if designed to isolate clients and > resources in this manner. > > No hacking of RFC 4203 is needed. No (new) warts need to be added. > > Curtis > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > Hi Sergio, > > I'd like to run with you the following logic. > > 1. Suppose an operator after some planning decides to provision an > infrastructure ODU and use it as a link. Why would he do so? One > reason that I can think of is because he wants to build a virtual > topology for a set of clients (with possibly himself as one from the > set). The purpose of this topology, generally speaking, is: > a) To be non-congruent with underlying topology (virtual or > OTU/OCh). For example, to interconnect nodes that do not have a common > OTU/OCh link; > b) To constrain said set of clients to resources of the topology > (rather than, for example, to use OTU/OCh links directly). > The question is how the operator can constrain the routing of the ODUs > for the clients from the set to the prepared for this purpose virtual > topology within the flat ITU routing model? > > 2. Would you agree that the only reason why a TE link advertises an > attribute is to be able to constrain a path computation based on the > attribute? Your definitions of the OTN encoding types, for example, > are: > " .... > o 8 - Lambda (Photonic) > o 12 - G.709 ODUk (Digital Path) > .... > " > > which will give the operator an ability to route an OTN connection > either straight over OTUs or over infrastructure ODUs with no regard to > the roles assigned to the links. Do you believe this would be flexible > enough for the operator? > > 3. What is it you can achieve with the suggested OTN routing that can > not be achieved using multiple 4203 ISCDs? > > Thanks, > Igor > > > -----Original Message----- > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > lucent.com] > Sent: Wednesday, July 21, 2010 10:59 AM > To: Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; > John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); > Fatai Zhang > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > For point 1) and 2) I do not think we are so far. > You're proposing a three-layer approach , we are aligned with what ITU > is proposing but we also have different roles in the network (lambda > and sub-lambda) and than needs for constrains and policy in the > network. > The fact to have three switching capability to characterize the > different roles in the same technology it seems to me a little against > the concept of switching capability itself. > You could say that for packet there is already 4 PSC SC defined. But > here we are in TDM , we have not label stacking capability. > > For point 3) and 4) , I do not discuss about the generality or not of > the issue, but surely you cannot negate that the problem of spatial > allocation is raised as soon as SDH CP has been implemented . Then the > same problem come in for OTN , and your intention to cope the issue in > a generic way with modifications of RFC 4203 is a good intention, but > take also into account that also our proposed format can be generic as > soon as you change the signal types supported. > > You're right we need to discuss face to face but my perception is that > we ca be less far than you believe. > > Cheers > > Sergio > > Sergio Belotti > > System Architecture > Optics Division-Terrestrial Optics Unit > ALCATEL-LUCENT > > +39 039 6863033 > +39 039 6863590 > > > -----Messaggio originale----- > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di > Igor Bryskin > Inviato: mercoled=EC 21 luglio 2010 15.51 > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; > Snigdho Bardalai > Cc: ccamp@ietf.org; Snigdho Bardalai > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > We need to discuss this face to face. The biggest disagreements with > Daniele are: > 1) I don't believe that flat routing model of a multi-layer OTN network > is correct. > 2) I think each OTN role defines a separate topology of OTN links, and > there is a need to be able to constrain the routing of a given OTN > connection to one or more (but not necessarily all) such topologies; > 3) There is an issue in the current definitions of GMPLS OSPF > extensions (RFC 4203), which does allow to specify multiple ISCDs but > does not guide as to how the available bandwidth on the link is > partitioned between ISCDs. This is a generic issue and should be > resolved in a generic way; > 4) Other than (3) we don't need any OTN or TDM specific CP machinery > for TE and routing in OTN networks. Unless we see strong reasons to the > contrary we should not invent such machinery. > > Cheers, > Igor > > -----Original Message----- > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > Sent: Wednesday, July 21, 2010 8:30 AM > To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; > Snigdho Bardalai > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > I support this as well, of course. Whether this is a technology- > specific extension of the ISCD format or a separate sub-TLV is a > detail, however as Daniele points out many of the same considerations > apply to both OTN and SONET/SDH. > > Lyndon > > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Wednesday, July 21, 2010 12:49 AM > To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > In other words it could be possible to define 3 Switching Cap (LO, HO > and SHO) and put what we defined in the encoding draft into the > Switching Capability-specific information of the ISCD. > > Something like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Cap | Encoding | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- > ---Switching Capability-specific information > |0|1|2|3|4|5|6|7| T | | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ... ... ... > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I still don't understand why we need partitioning the network in three > layers while just Sublamba and Full lambda distinction is enough > (distinction supported advertising different signal types for full > lambdas and sublambdas. > > Personally i still prefer advertising these pieces of information as a > separate sub-TLV (called OTN-ISCD subTLV in the draft but easily > estensible to TDM-ISCD accordingly to http://tools.ietf.org/html/draft- > ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this > could be a valid solution too. > > BR > Daniele > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: marted=EC 20 luglio 2010 23.02 > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > Do you understand the quote from RFC4203: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Cap | Encoding | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Capability-specific information | > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > You can use the last field for OTN switchcap to advertise unresolved > bandwidth available for the ISCD on per priority level. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 4:35 PM > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Snipped... > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > priority > > level for every ISCD. > > JD: Igor, what part of my quote from RFC 4202 did you not understand? > You do not advertise unreserved bandwidth in the ISCD TLV. In > particular, for TDM, what is advertised is the max and min bandwidth > allowed for a single LSP. It was designed to produce a compact > representation by taking advantage of the SDH/SONET hierarchy. > > Advertising a separate ISCD for each supported rate is allowed but > wasteful. > > > > > Igor > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > wro=3D > > > te: > > > > > > > John, > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > However if a > > > > TE link advertises more than one ISCD (with each ISCD containing > > only max > > > > lsp bandwidth per priority), it is necessary to indicate how the > > total li=3D > > > nk > > > > unreserved bandwidth is partitioned between several ISCDs. What I > > am > > > > suggesting is instead of advertising the unreserved bandwidth > > multiple ti=3D > > > mes > > > > (one per ISCD), indicate how the bandwidth is split between the > > ISCDs: e.=3D > > > g > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > Igor. > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > Igor, > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > > issue o=3D > > > f > > > > partitioning unreserved bandwidth across multiple advertised TDM > > ISC TLVs=3D > > > is > > > > actually a non-issue. > > > > > > > > Unreserved bandwidth by priority has always been advertised using > > the MPL=3D > > > S > > > > sub-TLV. My point has been that we have never had a requirement > > (includi=3D > > > ng > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > signal > > type, =3D > > > so > > > > what is special about OTN? > > > > > > > > A further point would be that if we do decide that it is > necessary > > to > > > > advertise unreserved bandwidth by signal type, it should be done > > > > in > > a > > > > general way and not in an OTN specific manner. (And in fact, the > > argumen=3D > > > ts > > > > that unreserved bandwidth by signal type needs to be advertised, > > such as =3D > > > the > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > It is a valid point, but the suggested solution is way too > > expensive. > > > > > All you need is a way to say how the advertised unreserved > > bandwidth is > > > > > partitioned between ISCDs in case the TE link advertisement > > contains > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > bits out > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > total > > > > > unreserved bandwidth associated with the ISCD. Another way is > to > > use > > > > > swicthcap specific extension. > > > > > BTW: this is not an OTN specific issue, rather more general: > any > > time > > > > > when a TE link advertises more than one ISCD (which is > perfectly > > Ok > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, > > > > > > > > > > The need for unreserved resources advertised per signal type is > > the > > > > > concurrent path computation. I'll answer quoting a section from > > the > > > > > info-model draft, please have a look in particular to the > > example: > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > and > > per > > > > > signal type in order to allow the correct functioning of the > > > > > restoration process. [RFC4203] only allows advertising > > unreserved > > > > > resources per priority, this leads not to know how many LSPs > > of a > > > > > specific signal type can be restored. As example it is > > possible to > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > +------+ component link 1 +------+ > > > > > | +------------------+ | > > > > > | | component link 2 | | > > > > > | N1 +------------------+ N2 | > > > > > | | component link 3 | | > > > > > | +------------------+ | > > > > > +------+ +---+--+ > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > > with > > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > > on the > > > > > third and supporting ODU2 and ODU3 signal types. The node > > would > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > > > > > a > > MAX > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > network > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > > only > > a > > > > > single ODU3 can be set up and a crank-back would be > > originated. In > > > > > more complex network scenarios the number of crank-backs can > > be much > > > > > higher." > > > > > > > > > > In other words, advertising the number of availble resources > per > > signal > > > > > type does not avoid the possibility of cranck-back but > decreases > > it as > > > > > much as possible. For sure a good routing prevents from crank- > > backs > > > > > caused by the restoration of LSP originating on the same > Ingress. > > The > > > > > cranck-backs due to the concurrent restoration of LSPs > > originating on > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > BR > > > > > Daniele > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > In line > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, one more question. > > > > > > > > > > What about the unreserved bandwidth? > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > > per > > > > > (muxCap & signal type) you also need to advertise the > unreserved > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > correct? > > This > > > > > also implies extending the unreserved bandwidth TLV so to > create > > a > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > subTLV). > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > ISCD > > per > > > > > IB>> role per (muxCap & signal type) per priority level. > > > > > IB>> However, > > total > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > > IB>> unless > > you > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > Igor > > > > > > > > > > Thanks > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Understood... > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > > > That's exactly what I've been > > > > > > trying to say all along. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > > per > > > > > role > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > signal > > > > > type. > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > switchCap =3D3D role; > > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > > reserved bits which can use for OTN specific > > info > > > > > in > > > > > > > case we need it. > > > > > > [SCB] I am yet to clearly understand what the role of "role" > > is, but > > > > > > agree with your observation on the encode-type and the 16 > > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > > each > > > > > role > > > > > > > you would advertise just the unreserved bandwidth but you > > wouldn't > > > > > > know > > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > > LSP > > (e.g. > > > > > > 15 > > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > > available > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > scalability > > > > > > issues > > > > > > > and the requirement of being able to bundle component links > > > > > together > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > ISDCs > > > > > will > > > > > > > provide a lot of flexibility: you can specify different > > things > > > > > (e.g. > > > > > > > available bandwidth) for the same link in different roles. > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be > sufficient? > > > > > > > > > > > > > > Cheers, > > > > > > > Daniele > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Igor Bryskin > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Fatai Zhang > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > Thanks. > > > > > > > I understand what you said. Therefore, we have added some > > text to > > > > > > > address the requirment in FWK document. However, we still > > don't > > > > > > > think that we need to extend ISC to meet the requirment. > The > > role > > > > > of > > > > > > > the > > > > > > ODU > > > > > > > can be get from the routing information implicitly. In the > > [draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > "Full > > > > > Lambda" > > > > > > is > > > > > > > introduced. > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > a) this requires OTN specific advertising and processing > > rules; > > > > > > > b) disallows topology separation in technology independent > > way > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > container > > > > > > does > > > > > > > not change hop-by-hop (as some people seem to believe). The > > role is > > > > > > > only meaningful on the ODU terminating nodes and irrelevant > > on > > > > > > transit > > > > > > > nodes. It is it's position in the hierarchy (but not role) > > that may > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > > AI1 > > and > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > > can > > only > > > > > > support > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > > with > > the > > > > > > role > > > > > > > of Ho ODU level is requested, according to your statement, > > this > > > > > > > conneciton will be allowed to be created. However, it > should > > not be > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > > link > > > > > ends > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > > while > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > > path computation is constrained to the OTN_HO_SC topology, > > > > > > > B11 and > > B12 > > > > > TE > > > > > > > links will > > > > > > be > > > > > > > disallowed, and the resulting path (if any) will not go > > through B11 > > > > > > and > > > > > > > B12. If one circumvents the path computation by providing > > > > > > > the > > fully > > > > > > > explicit path, the signaling should fail on node B for the > > same > > > > > > reason: > > > > > > > inconsistency of required (signaled) and supported (by > local > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > > the > > > > > type > > > > > > > indicated in the Switching Type parameter is supported on > > the > > > > > > > corresponding incoming interface. If the type cannot be > > > > > supported, > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > problem/Switching Type" indication." > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Lou Berger" ; > > > > > > > ; > > > > > > framework@tools.ietf.org> > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > ccamp@ietf.org; > > > > > > draft- > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > I think role does not equal switching capability. The > > operators can > > > > > > > define different roles depending on their policy and > achieve > > the > > > > > > > role through different methods. However, for OTN networks, > > the > > > > > > > containers (e.g., ODUk) all have the same switching > > capablility > > > > > > > (i.e., TDM > > > > > > > switching) and I think we should reflect the natural > > > > > characteristics > > > > > > of > > > > > > > links in the routing. In addition, if we extend the ISC, it > > will > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > overrides > > > > > > > encoding type). > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > views the > > > > > > > network as a stack of topologies. Whether a given topology > > > > > > > is > > real > > > > > > > or virtual is of no importance. > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > > switching capability field (confusing name as it is) is a > > > > > > > good way to > > > > > describe > > > > > > a > > > > > > > layer in technology independent way, so that, say, MPLS-TP- > > >OTN_LO- > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > stack of > > > > > > > topologies that could be easily separated in technology > > independent > > > > > > way > > > > > > > should path computation be constrained to particular one or > > > > > > > sub-stack of them. > > > > > > > I think a good way to identify an OTN (virtual) topology is > > via > > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > > topology. > > > > > > > BTW IMO the role of an ODU container does not change hop- > by- > > hop (as > > > > > > > some people seem to believe). The role is only meaningful > on > > the > > > > > ODU > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > > it's > > > > > > position > > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > > ODU's > > > > > > role > > > > > > > is the level of topology it is provisioned for and it is > the > > same > > > > > > > for all ODUs that comprise the topology. For, example a > user > > may > > > > > > provision > > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > > clients > > to > > > > > use > > > > > > > the topology rather than any resources available on OTN > > network. > > > > > > > The bottom line: container's role is the same as the role > of > > > > > virtual > > > > > > > topology the container is a part of and could be advertised > > as the > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > > roles > > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > > clarify? > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > > IB>> etc.) > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > In addition, could you clarify my questions in another > email > > > > > (copied > > > > > > as > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > 3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > other. > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > hierarchy, > > > > > which > > > > > > is > > > > > > > a mistake IMO. > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > > ODU3 as > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > > > > > > > is > > a > > > > > OTU3 > > > > > > link > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > (service > > > > > > > over > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > this > > case, > > > > > > how > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > Level? > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > > the ODU > > > > > > > terminating nodes (i.e. on either side of corresponding > > link). What > > > > > > > happens on the ODU transit nodes and its place in the > > hierarchy on > > > > > > the > > > > > > > transit nodes are of no importance. My LO container can be > > carried > > > > > > > by somebody else's LO container and can carry my client's > LO > > > > > container. > > > > > > To > > > > > > > some extent it is similar to MPLS LSP role: LSP always has > a > > role > > > > > > (e.g. > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > along its > > > > > > > path. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > 3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Fatai Zhang" > > ; > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > gmpls- > > > > > > > g709-framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > > types > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > capabilities > > > > > > > rather than the link's role (i.e. level in the OTN > hierarchy: > > LO, > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > indicated > > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > > roles; > > > > > 2. > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > different > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > capabilities can > > > > > > be > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > ISCD is > > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > > type > > will > > > > > > look > > > > > > > to CP as a separate layer, which is exactly how ITU models > > OTN > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > operator > > > > > would > > > > > > > want to constrain the routing of OTN connections to pre- > > configured > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > sells to > > > > > > the > > > > > > > clients to one or more pre-configured LO topologies), this > > would be > > > > > > > possible to do in a technology independent way. Suppose an > > instance > > > > > > of > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > from > > HO OTN > > > > > > > links will be no different from the separation of WDM links > > from > > > > > > OTUs. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > To: Igor Bryskin > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger; > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > srv- > > > > > > > exgen.atl.advaoptical.com> > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > > many > > as > > > > > the > > > > > > > depth of the deepest possible OTN DP hierarchy, for > example: > > > > > > > > > > > > > > > > typedef enum > > > > > > > > { > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > /*****/ > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > > */ > > > > > /*****/ > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > > make the > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > Digital > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > which had > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > long time > > > > > ago. > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > > did not > > > > > > > understand what the TS type meant did not try to multiplex > > its LO > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > commited > > > > > to > > > > > > using > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > OTN_HO or > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > > the > > > > > > latter > > > > > > > is for backward compatibility and should be ignored if > > OTN_LO, > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > 1.25 > > TS > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > > can > > be > > > > > withdrawn. > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > of > > the > > > > > LSP > > > > > > > regardless of what goes on in the middle since that > > determines what > > > > > > can > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > OTU3 > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 o= r > > ODUj=3D3Df=3D > > > lex > > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > > contain > > > > > an ODU0. > > > > > > > If the SHO Encoding Type is used, then it indicates that > two > > levels > > > > > > of > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > 4328 > > Switch > > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > > but > > if > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > Along > > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > > and > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > I'm > > not > > > > > > clear > > > > > > > how in an FA it can be indicated that either type is > > currently > > > > > > > available (NE capable of both and hasn't committed to > either > > one > > > > > > yet). > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > > on this > > > > > > > would indicate a huge controversy and I'm not getting it > > (other > > > > > than > > > > > > a > > > > > > > strong preference to rely on bytes/sec or on enumerated > type > > > > > fields). > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > > not sure > > > > > > if > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, > > > > > > > or other intent. Could someone (either draft) concisely > > summarize > > > > > > > the multiplexing restrictions in one place, including > > restrictions > > > > > > > on number of multiplexing layers at one LSR. That might > > help. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > > Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] On > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > framework > > > > > > > > > document before we can embark on any proposals to the > > problem. > > > > > I > > > > > > am > > > > > > > > > still not clear why do we have to deviate from the > > general > > > > > > approach > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > > > > > > IB>> plane, and > > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > > independent > > > > > > paradigm > > > > > > > > > of advertising of TE links, and there is no reason to > > invent an > > > > > > OTN > > > > > > > > > specific ISCD. The combination of Switching Capability > > and > > > > > > Encoding > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > multiplexing > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > link, > > and, > > > > > if > > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > > >new TE-link > > > > > > > to > > > > > > > > > represent >the low-order ODUj bandwidth within the > high- > > order > > > > > > > containers. > > > > > > > > > This is simply >blowing up the solution to a very > simple > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > > IB>> possibility > > to > > > > > > create > > > > > > > > > IB>> OTN > > > > > > > > > hierarchies and constrain LO connections to HO > > containers, one > > > > > > > needs > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > > and > > > > > > > > > other interested experts, and we think the proposal > > described > > > > > in > > > > > > "draft- > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > > is more > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > needed for > > > > > > > > > control plane, no matter how you encode the routing > > > > > information. > > > > > > > For > > > > > > > > > TDM networks, you know the resource is allocated based > > > > > > > > > on > > TS, > > > > > so > > > > > > > the > > > > > > > > > available TS should be get or induced before creating > > cross- > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > information, > > > > > > I > > > > > > > > > think you need go to the routing drafts (info model and > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > encoding), > > > > > you > > > > > > > > > will find that one of your suggestions is adopted > (i.e., > > simply > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > ..., > > ODU4 > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > > links) > > as FA > > > > > > for > > > > > > > > > ODU1, you have to advertise a new TE link or put this > FA > > as a > > > > > > > > > component link of an existing TE link (like > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > g709-framework@tools.ietf.org > gmpls- > > > > > > g709- > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > I believe there has been some off-line discussion on > > how to > > > > > > > better > > > > > > > > > > align the work with 4202. Use of common approaches > is > > of > > > > > > course > > > > > > > > > > one of the main objectives of *C*CAMP. I look > forward > > to > > > > > > hearing > > > > > > > > > > from the draft and discussion contributors on there > > progress > > > > > > > > > > on > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > >> Hello, > > > > > > > > > >> > > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > > This > > > > > > section > > > > > > > > > >> describes the link-parameters that are required for > > OTN > > > > > > service > > > > > > > > > >> routing purposes. > > > > > > > > > >> > > > > > > > > > >> My comment is how are we going to advertise the low- > > order > > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > > >> For example, consider an > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > granularity > > and > > > > > > > > > >> then > > > > > > > we > > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > > >> point > > in > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > ODU2 > > > > > > > > > >> services > > > > > > and > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > > ODU1s > > > > > > > > > >> are contained over the ODU2). So it is obvious from > > this > > > > > > > > > >> example > > > > > > > that > > > > > > > > > >> the number of time-slots available is different > based > > on the > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > >> How do we address this issue based on the approach > > specified > > > > > > in > > > > > > > > > >> the > > > > > > > > > draft? > > > > > > > > > >> > > > > > > > > > >> My other question is why not simply advertize the > > available > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances or > > > > > > the > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > This > > > > > > > > > >> approach seems to be more in-line with the general > > approach > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > section > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > ISCDs > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > additional > > > > > > > > > >> benefit > > > > > > > is > > > > > > > > > >> that the advertisement is TS size independent and > > hence will > > > > > > > > > >> simplify the implementation. > > > > > > > > > >> > > > > > > > > > >> Regards > > > > > > > > > >> > > > > > > > > > >> Snigdho > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From IBryskin@advaoptical.com Thu Jul 22 10:13:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9BD93A6842 for ; Thu, 22 Jul 2010 10:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXZrbJsvcgGH for ; Thu, 22 Jul 2010 10:13:12 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 5A90D3A676A for ; Thu, 22 Jul 2010 10:13:11 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6MHD0oD006236 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 22 Jul 2010 19:13:00 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Jul 2010 19:13:00 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 22 Jul 2010 13:12:57 -0400 From: Igor Bryskin To: John E Drake , "curtis@occnc.com" Date: Thu, 22 Jul 2010 13:12:37 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ5fxRxCX072TIeobRA5d6U+SgAm3o3gAADpouA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-22_06:2010-07-22, 2010-07-22, 1970-01-01 signatures=0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 17:13:17 -0000 John, One reason is that ISCD allows for advertising of available LSP bandwidth p= er priority level, which could change for the same OTN link depending on ro= le. Coloring won't allow to do so. Also, ISCD encoding type allows for enco= ding the signal type, mux. capabilities, etc. without introduction of OTN s= pecific sub-TLVs. We want to help operator to provision topologies, ID the= m and provide a simple way to constrain a given LSP to be routed within a t= opology. ISCD gives you a simple way to do so in a technology independent = way, so that constraining LSP to belong, say, OTN_LO or OTN_HO topology wil= l not be different from constraining LSP to belong to, say, ETH_EVPL layer. Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 22, 2010 12:19 PM To: curtis@occnc.com; Igor Bryskin Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon= ; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, There is no reason to define multiple ISCD values for OTN networks in order= to constrain the path of a given LSP to only certain links. The right way= to do this is link colors (nee Administrative Groups, defined in RFC 3630)= , which is what it was designed to do. I know this is a radical thought but why don't we use ISCD for what it was = designed to do? Thanks, John > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, July 21, 2010 2:38 PM > To: Igor Bryskin > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho > Bardalai; Varma, Eve L (Eve); Fatai Zhang > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > > Igor, > > A current solution would be to use ML/MT extensions. A GMPLS E-NNI > could also solve this problem if designed to isolate clients and > resources in this manner. > > No hacking of RFC 4203 is needed. No (new) warts need to be added. > > Curtis > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv- > exgen.atl.advaoptical.com> > Igor Bryskin writes: > > Hi Sergio, > > I'd like to run with you the following logic. > > 1. Suppose an operator after some planning decides to provision an > infrastructure ODU and use it as a link. Why would he do so? One > reason that I can think of is because he wants to build a virtual > topology for a set of clients (with possibly himself as one from the > set). The purpose of this topology, generally speaking, is: > a) To be non-congruent with underlying topology (virtual or > OTU/OCh). For example, to interconnect nodes that do not have a common > OTU/OCh link; > b) To constrain said set of clients to resources of the topology > (rather than, for example, to use OTU/OCh links directly). > The question is how the operator can constrain the routing of the ODUs > for the clients from the set to the prepared for this purpose virtual > topology within the flat ITU routing model? > > 2. Would you agree that the only reason why a TE link advertises an > attribute is to be able to constrain a path computation based on the > attribute? Your definitions of the OTN encoding types, for example, > are: > " .... > o 8 - Lambda (Photonic) > o 12 - G.709 ODUk (Digital Path) > .... > " > > which will give the operator an ability to route an OTN connection > either straight over OTUs or over infrastructure ODUs with no regard to > the roles assigned to the links. Do you believe this would be flexible > enough for the operator? > > 3. What is it you can achieve with the suggested OTN routing that can > not be achieved using multiple 4203 ISCDs? > > Thanks, > Igor > > > -----Original Message----- > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > lucent.com] > Sent: Wednesday, July 21, 2010 10:59 AM > To: Igor Bryskin > Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele Ceccarelli; > John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); > Fatai Zhang > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > For point 1) and 2) I do not think we are so far. > You're proposing a three-layer approach , we are aligned with what ITU > is proposing but we also have different roles in the network (lambda > and sub-lambda) and than needs for constrains and policy in the > network. > The fact to have three switching capability to characterize the > different roles in the same technology it seems to me a little against > the concept of switching capability itself. > You could say that for packet there is already 4 PSC SC defined. But > here we are in TDM , we have not label stacking capability. > > For point 3) and 4) , I do not discuss about the generality or not of > the issue, but surely you cannot negate that the problem of spatial > allocation is raised as soon as SDH CP has been implemented . Then the > same problem come in for OTN , and your intention to cope the issue in > a generic way with modifications of RFC 4203 is a good intention, but > take also into account that also our proposed format can be generic as > soon as you change the signal types supported. > > You're right we need to discuss face to face but my perception is that > we ca be less far than you believe. > > Cheers > > Sergio > > Sergio Belotti > > System Architecture > Optics Division-Terrestrial Optics Unit > ALCATEL-LUCENT > > +39 039 6863033 > +39 039 6863590 > > > -----Messaggio originale----- > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di > Igor Bryskin > Inviato: mercoled=EC 21 luglio 2010 15.51 > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; > Snigdho Bardalai > Cc: ccamp@ietf.org; Snigdho Bardalai > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > We need to discuss this face to face. The biggest disagreements with > Daniele are: > 1) I don't believe that flat routing model of a multi-layer OTN network > is correct. > 2) I think each OTN role defines a separate topology of OTN links, and > there is a need to be able to constrain the routing of a given OTN > connection to one or more (but not necessarily all) such topologies; > 3) There is an issue in the current definitions of GMPLS OSPF > extensions (RFC 4203), which does allow to specify multiple ISCDs but > does not guide as to how the available bandwidth on the link is > partitioned between ISCDs. This is a generic issue and should be > resolved in a generic way; > 4) Other than (3) we don't need any OTN or TDM specific CP machinery > for TE and routing in OTN networks. Unless we see strong reasons to the > contrary we should not invent such machinery. > > Cheers, > Igor > > -----Original Message----- > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > Sent: Wednesday, July 21, 2010 8:30 AM > To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; > Snigdho Bardalai > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > I support this as well, of course. Whether this is a technology- > specific extension of the ISCD format or a separate sub-TLV is a > detail, however as Daniele points out many of the same considerations > apply to both OTN and SONET/SDH. > > Lyndon > > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Wednesday, July 21, 2010 12:49 AM > To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: ccamp@ietf.org; Snigdho Bardalai > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > In other words it could be possible to define 3 Switching Cap (LO, HO > and SHO) and put what we defined in the encoding draft into the > Switching Capability-specific information of the ISCD. > > Something like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Cap | Encoding | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- > ---Switching Capability-specific information > |0|1|2|3|4|5|6|7| T | | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ... ... ... > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type |F| Bandwidth @ P7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I still don't understand why we need partitioning the network in three > layers while just Sublamba and Full lambda distinction is enough > (distinction supported advertising different signal types for full > lambdas and sublambdas. > > Personally i still prefer advertising these pieces of information as a > separate sub-TLV (called OTN-ISCD subTLV in the draft but easily > estensible to TDM-ISCD accordingly to http://tools.ietf.org/html/draft- > ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this > could be a valid solution too. > > BR > Daniele > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: marted=EC 20 luglio 2010 23.02 > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > Do you understand the quote from RFC4203: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Cap | Encoding | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Switching Capability-specific information | > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > You can use the last field for OTN switchcap to advertise unresolved > bandwidth available for the ISCD on per priority level. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Tuesday, July 20, 2010 4:35 PM > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Snipped... > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > priority > > level for every ISCD. > > JD: Igor, what part of my quote from RFC 4202 did you not understand? > You do not advertise unreserved bandwidth in the ISCD TLV. In > particular, for TDM, what is advertised is the max and min bandwidth > allowed for a single LSP. It was designed to produce a compact > representation by taking advantage of the SDH/SONET hierarchy. > > Advertising a separate ISCD for each supported rate is allowed but > wasteful. > > > > > Igor > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > wro=3D > > > te: > > > > > > > John, > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > However if a > > > > TE link advertises more than one ISCD (with each ISCD containing > > only max > > > > lsp bandwidth per priority), it is necessary to indicate how the > > total li=3D > > > nk > > > > unreserved bandwidth is partitioned between several ISCDs. What I > > am > > > > suggesting is instead of advertising the unreserved bandwidth > > multiple ti=3D > > > mes > > > > (one per ISCD), indicate how the bandwidth is split between the > > ISCDs: e.=3D > > > g > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > Igor. > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > Zhang; > > > > curtis@occnc.com > > > > Cc: ccamp@ietf.org > > > > Subject: RE: [CCAMP] Comment on > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > Igor, > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the > > issue o=3D > > > f > > > > partitioning unreserved bandwidth across multiple advertised TDM > > ISC TLVs=3D > > > is > > > > actually a non-issue. > > > > > > > > Unreserved bandwidth by priority has always been advertised using > > the MPL=3D > > > S > > > > sub-TLV. My point has been that we have never had a requirement > > (includi=3D > > > ng > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > signal > > type, =3D > > > so > > > > what is special about OTN? > > > > > > > > A further point would be that if we do decide that it is > necessary > > to > > > > advertise unreserved bandwidth by signal type, it should be done > > > > in > > a > > > > general way and not in an OTN specific manner. (And in fact, the > > argumen=3D > > > ts > > > > that unreserved bandwidth by signal type needs to be advertised, > > such as =3D > > > the > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > > > Of Igor Bryskin > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > It is a valid point, but the suggested solution is way too > > expensive. > > > > > All you need is a way to say how the advertised unreserved > > bandwidth is > > > > > partitioned between ISCDs in case the TE link advertisement > > contains > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > bits out > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > total > > > > > unreserved bandwidth associated with the ISCD. Another way is > to > > use > > > > > swicthcap specific extension. > > > > > BTW: this is not an OTN specific issue, rather more general: > any > > time > > > > > when a TE link advertises more than one ISCD (which is > perfectly > > Ok > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > Igor > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, > > > > > > > > > > The need for unreserved resources advertised per signal type is > > the > > > > > concurrent path computation. I'll answer quoting a section from > > the > > > > > info-model draft, please have a look in particular to the > > example: > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > and > > per > > > > > signal type in order to allow the correct functioning of the > > > > > restoration process. [RFC4203] only allows advertising > > unreserved > > > > > resources per priority, this leads not to know how many LSPs > > of a > > > > > specific signal type can be restored. As example it is > > possible to > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > +------+ component link 1 +------+ > > > > > | +------------------+ | > > > > > | | component link 2 | | > > > > > | N1 +------------------+ N2 | > > > > > | | component link 3 | | > > > > > | +------------------+ | > > > > > +------+ +---+--+ > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component links > > with > > > > > 32TSs available on the first one, 24TSs on the second, 24TSs > > on the > > > > > third and supporting ODU2 and ODU3 signal types. The node > > would > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs and > > > > > a > > MAX > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > network > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > > only > > a > > > > > single ODU3 can be set up and a crank-back would be > > originated. In > > > > > more complex network scenarios the number of crank-backs can > > be much > > > > > higher." > > > > > > > > > > In other words, advertising the number of availble resources > per > > signal > > > > > type does not avoid the possibility of cranck-back but > decreases > > it as > > > > > much as possible. For sure a good routing prevents from crank- > > backs > > > > > caused by the restoration of LSP originating on the same > Ingress. > > The > > > > > cranck-backs due to the concurrent restoration of LSPs > > originating on > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > BR > > > > > Daniele > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > In line > > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Igor, one more question. > > > > > > > > > > What about the unreserved bandwidth? > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per role > > per > > > > > (muxCap & signal type) you also need to advertise the > unreserved > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > correct? > > This > > > > > also implies extending the unreserved bandwidth TLV so to > create > > a > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > subTLV). > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > ISCD > > per > > > > > IB>> role per (muxCap & signal type) per priority level. > > > > > IB>> However, > > total > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > > IB>> unless > > you > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > Igor > > > > > > > > > > Thanks > > > > > Daniele > > > > > > > > > > -----Original Message----- > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > > > 01.txt > > > > > > > > > > Understood... > > > > > > > > > > Regards > > > > > Snigdho > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be sufficient > > > > > > > > > > > > That's exactly what I've been > > > > > > trying to say all along. > > > > > > > > > > > > Cheers, > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daniele Ceccarelli > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an ISCD > > per > > > > > role > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > signal > > > > > type. > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > switchCap =3D3D role; > > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > > reserved bits which can use for OTN specific > > info > > > > > in > > > > > > > case we need it. > > > > > > [SCB] I am yet to clearly understand what the role of "role" > > is, but > > > > > > agree with your observation on the encode-type and the 16 > > > > > > reserved-bits to further classify the switching information. > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. For > > each > > > > > role > > > > > > > you would advertise just the unreserved bandwidth but you > > wouldn't > > > > > > know > > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > > LSP > > (e.g. > > > > > > 15 > > > > > > > Gbps available on 3 component links: you advertise 45 Gbps > > > > > available > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > scalability > > > > > > issues > > > > > > > and the requirement of being able to bundle component links > > > > > together > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > ISDCs > > > > > will > > > > > > > provide a lot of flexibility: you can specify different > > things > > > > > (e.g. > > > > > > > available bandwidth) for the same link in different roles. > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > extensions > > > > > > (i.e. to further classify the information) will be > sufficient? > > > > > > > > > > > > > > Cheers, > > > > > > > Daniele > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Igor Bryskin > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > > > Behalf > > > > > > > Of Fatai Zhang > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > Thanks. > > > > > > > I understand what you said. Therefore, we have added some > > text to > > > > > > > address the requirment in FWK document. However, we still > > don't > > > > > > > think that we need to extend ISC to meet the requirment. > The > > role > > > > > of > > > > > > > the > > > > > > ODU > > > > > > > can be get from the routing information implicitly. In the > > [draft- > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > "Full > > > > > Lambda" > > > > > > is > > > > > > > introduced. > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > a) this requires OTN specific advertising and processing > > rules; > > > > > > > b) disallows topology separation in technology independent > > way > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > container > > > > > > does > > > > > > > not change hop-by-hop (as some people seem to believe). The > > role is > > > > > > > only meaningful on the ODU terminating nodes and irrelevant > > on > > > > > > transit > > > > > > > nodes. It is it's position in the hierarchy (but not role) > > that may > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > > AI1 > > and > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > > can > > only > > > > > > support > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > > with > > the > > > > > > role > > > > > > > of Ho ODU level is requested, according to your statement, > > this > > > > > > > conneciton will be allowed to be created. However, it > should > > not be > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 TE > > link > > > > > ends > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC, > > while > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > > path computation is constrained to the OTN_HO_SC topology, > > > > > > > B11 and > > B12 > > > > > TE > > > > > > > links will > > > > > > be > > > > > > > disallowed, and the resulting path (if any) will not go > > through B11 > > > > > > and > > > > > > > B12. If one circumvents the path computation by providing > > > > > > > the > > fully > > > > > > > explicit path, the signaling should fail on node B for the > > same > > > > > > reason: > > > > > > > inconsistency of required (signaled) and supported (by > local > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify that > > the > > > > > type > > > > > > > indicated in the Switching Type parameter is supported on > > the > > > > > > > corresponding incoming interface. If the type cannot be > > > > > supported, > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > problem/Switching Type" indication." > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Lou Berger" ; > > > > > > > ; > > > > > > framework@tools.ietf.org> > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > ccamp@ietf.org; > > > > > > draft- > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > I think role does not equal switching capability. The > > operators can > > > > > > > define different roles depending on their policy and > achieve > > the > > > > > > > role through different methods. However, for OTN networks, > > the > > > > > > > containers (e.g., ODUk) all have the same switching > > capablility > > > > > > > (i.e., TDM > > > > > > > switching) and I think we should reflect the natural > > > > > characteristics > > > > > > of > > > > > > > links in the routing. In addition, if we extend the ISC, it > > will > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > overrides > > > > > > > encoding type). > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > views the > > > > > > > network as a stack of topologies. Whether a given topology > > > > > > > is > > real > > > > > > > or virtual is of no importance. > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > > switching capability field (confusing name as it is) is a > > > > > > > good way to > > > > > describe > > > > > > a > > > > > > > layer in technology independent way, so that, say, MPLS-TP- > > >OTN_LO- > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > stack of > > > > > > > topologies that could be easily separated in technology > > independent > > > > > > way > > > > > > > should path computation be constrained to particular one or > > > > > > > sub-stack of them. > > > > > > > I think a good way to identify an OTN (virtual) topology is > > via > > > > > > > (infrastructure) ODU container role of ODUs comprising the > > > > > topology. > > > > > > > BTW IMO the role of an ODU container does not change hop- > by- > > hop (as > > > > > > > some people seem to believe). The role is only meaningful > on > > the > > > > > ODU > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > > it's > > > > > > position > > > > > > > in the hierarchy (but not role) that may change hop-by-hop. > > ODU's > > > > > > role > > > > > > > is the level of topology it is provisioned for and it is > the > > same > > > > > > > for all ODUs that comprise the topology. For, example a > user > > may > > > > > > provision > > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > > clients > > to > > > > > use > > > > > > > the topology rather than any resources available on OTN > > network. > > > > > > > The bottom line: container's role is the same as the role > of > > > > > virtual > > > > > > > topology the container is a part of and could be advertised > > as the > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise the > > roles > > > > > > > and muxing capabilities with the ISCD of RFC4202, could you > > > > > clarify? > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > > IB>> etc.) > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > In addition, could you clarify my questions in another > email > > > > > (copied > > > > > > as > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > 3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > other. > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > hierarchy, > > > > > which > > > > > > is > > > > > > > a mistake IMO. > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or > > ODU3 as > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there > > > > > > > is > > a > > > > > OTU3 > > > > > > link > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > (service > > > > > > > over > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > this > > case, > > > > > > how > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > Level? > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important on > > the ODU > > > > > > > terminating nodes (i.e. on either side of corresponding > > link). What > > > > > > > happens on the ODU transit nodes and its place in the > > hierarchy on > > > > > > the > > > > > > > transit nodes are of no importance. My LO container can be > > carried > > > > > > > by somebody else's LO container and can carry my client's > LO > > > > > container. > > > > > > To > > > > > > > some extent it is similar to MPLS LSP role: LSP always has > a > > role > > > > > > (e.g. > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > along its > > > > > > > path. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > 3 > > D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > =3D3D > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Igor Bryskin" > > > > > > > To: > > > > > > > Cc: "John E Drake" ; "Snigdho Bardalai" > > > > > > > ; "Fatai Zhang" > > ; > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > gmpls- > > > > > > > g709-framework@tools.ietf.org> > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > I agree that there should be multiple OTN specific encoding > > types > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > capabilities > > > > > > > rather than the link's role (i.e. level in the OTN > hierarchy: > > LO, > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > indicated > > > > > > > with a separate switchcaps. I can give you several reasons: > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have different > > roles; > > > > > 2. > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > different > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > capabilities can > > > > > > be > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > ISCD is > > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > > type > > will > > > > > > look > > > > > > > to CP as a separate layer, which is exactly how ITU models > > OTN > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > operator > > > > > would > > > > > > > want to constrain the routing of OTN connections to pre- > > configured > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > sells to > > > > > > the > > > > > > > clients to one or more pre-configured LO topologies), this > > would be > > > > > > > possible to do in a technology independent way. Suppose an > > instance > > > > > > of > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > from > > HO OTN > > > > > > > links will be no different from the separation of WDM links > > from > > > > > > OTUs. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > To: Igor Bryskin > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > Berger; > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > framework@tools.ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > srv- > > > > > > > exgen.atl.advaoptical.com> > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > > many > > as > > > > > the > > > > > > > depth of the deepest possible OTN DP hierarchy, for > example: > > > > > > > > > > > > > > > > typedef enum > > > > > > > > { > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > /*****/ > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high order > > */ > > > > > /*****/ > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM and > > make the > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > Digital > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > which had > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > long time > > > > > ago. > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR that > > did not > > > > > > > understand what the TS type meant did not try to multiplex > > its LO > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > commited > > > > > to > > > > > > using > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > OTN_HO or > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then > > the > > > > > > latter > > > > > > > is for backward compatibility and should be ignored if > > OTN_LO, > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > 1.25 > > TS > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > > can > > be > > > > > withdrawn. > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > of > > the > > > > > LSP > > > > > > > regardless of what goes on in the middle since that > > determines what > > > > > > can > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > OTU3 > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 o= r > > ODUj=3D3Df=3D > > > lex > > > > > > > even though the ODUk=3D3D2 at the next hop could not directly > > contain > > > > > an ODU0. > > > > > > > If the SHO Encoding Type is used, then it indicates that > two > > levels > > > > > > of > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > 4328 > > Switch > > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > > but > > if > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > Along > > > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4, > > and > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > I'm > > not > > > > > > clear > > > > > > > how in an FA it can be indicated that either type is > > currently > > > > > > > available (NE capable of both and hasn't committed to > either > > one > > > > > > yet). > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of messages > > on this > > > > > > > would indicate a huge controversy and I'm not getting it > > (other > > > > > than > > > > > > a > > > > > > > strong preference to rely on bytes/sec or on enumerated > type > > > > > fields). > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. I'm > > not sure > > > > > > if > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > framework, > > > > > > > or other intent. Could someone (either draft) concisely > > summarize > > > > > > > the multiplexing restrictions in one place, including > > restrictions > > > > > > > on number of multiplexing layers at one LSR. That might > > help. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > > Berger > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] On > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > framework > > > > > > > > > document before we can embark on any proposals to the > > problem. > > > > > I > > > > > > am > > > > > > > > > still not clear why do we have to deviate from the > > general > > > > > > approach > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer > > control > > > > > > > > > IB>> plane, and > > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > > independent > > > > > > paradigm > > > > > > > > > of advertising of TE links, and there is no reason to > > invent an > > > > > > OTN > > > > > > > > > specific ISCD. The combination of Switching Capability > > and > > > > > > Encoding > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > multiplexing > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > link, > > and, > > > > > if > > > > > > > > > this not sufficient, you have another reserved 16 bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > > >new TE-link > > > > > > > to > > > > > > > > > represent >the low-order ODUj bandwidth within the > high- > > order > > > > > > > containers. > > > > > > > > > This is simply >blowing up the solution to a very > simple > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > > IB>> possibility > > to > > > > > > create > > > > > > > > > IB>> OTN > > > > > > > > > hierarchies and constrain LO connections to HO > > containers, one > > > > > > > needs > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among authors > > and > > > > > > > > > other interested experts, and we think the proposal > > described > > > > > in > > > > > > "draft- > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft > > is more > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > needed for > > > > > > > > > control plane, no matter how you encode the routing > > > > > information. > > > > > > > For > > > > > > > > > TDM networks, you know the resource is allocated based > > > > > > > > > on > > TS, > > > > > so > > > > > > > the > > > > > > > > > available TS should be get or induced before creating > > cross- > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > information, > > > > > > I > > > > > > > > > think you need go to the routing drafts (info model and > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > encoding), > > > > > you > > > > > > > > > will find that one of your suggestions is adopted > (i.e., > > simply > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > ..., > > ODU4 > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > > links) > > as FA > > > > > > for > > > > > > > > > ODU1, you have to advertise a new TE link or put this > FA > > as a > > > > > > > > > component link of an existing TE link (like > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > g709-framework@tools.ietf.org > gmpls- > > > > > > g709- > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > I believe there has been some off-line discussion on > > how to > > > > > > > better > > > > > > > > > > align the work with 4202. Use of common approaches > is > > of > > > > > > course > > > > > > > > > > one of the main objectives of *C*CAMP. I look > forward > > to > > > > > > hearing > > > > > > > > > > from the draft and discussion contributors on there > > progress > > > > > > > > > > on > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > >> Hello, > > > > > > > > > >> > > > > > > > > > >> I have a comment and a question on Section 3.1.2.1. > > This > > > > > > section > > > > > > > > > >> describes the link-parameters that are required for > > OTN > > > > > > service > > > > > > > > > >> routing purposes. > > > > > > > > > >> > > > > > > > > > >> My comment is how are we going to advertise the low- > > order > > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > > >> For example, consider an > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > granularity > > and > > > > > > > > > >> then > > > > > > > we > > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > > >> point > > in > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > ODU2 > > > > > > > > > >> services > > > > > > and > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4 > > ODU1s > > > > > > > > > >> are contained over the ODU2). So it is obvious from > > this > > > > > > > > > >> example > > > > > > > that > > > > > > > > > >> the number of time-slots available is different > based > > on the > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > >> How do we address this issue based on the approach > > specified > > > > > > in > > > > > > > > > >> the > > > > > > > > > draft? > > > > > > > > > >> > > > > > > > > > >> My other question is why not simply advertize the > > available > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > instances or > > > > > > the > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > This > > > > > > > > > >> approach seems to be more in-line with the general > > approach > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > section > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > ISCDs > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > additional > > > > > > > > > >> benefit > > > > > > > is > > > > > > > > > >> that the advertisement is TS size independent and > > hence will > > > > > > > > > >> simplify the implementation. > > > > > > > > > >> > > > > > > > > > >> Regards > > > > > > > > > >> > > > > > > > > > >> Snigdho > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From jdrake@juniper.net Thu Jul 22 10:24:02 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2A03A6842 for ; Thu, 22 Jul 2010 10:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7muC87wgYz3I for ; Thu, 22 Jul 2010 10:24:00 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 3C6E43A676A for ; Thu, 22 Jul 2010 10:23:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTEh+uU9qACqeCX4qFmPow1Z5iPEmYi5O@postini.com; Thu, 22 Jul 2010 10:24:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 22 Jul 2010 10:21:04 -0700 From: John E Drake To: John E Drake , "curtis@occnc.com" , "BELOTTI, SERGIO (SERGIO)" Date: Thu, 22 Jul 2010 10:21:01 -0700 Thread-Topic: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspEs4rfpzXbzHMSoS+YSwEHFKz6wAnrF6QAAQYHrA= Message-ID: <5E893DB832F57341992548CDBB3331639844B32D16@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Igor Bryskin , "ccamp@ietf.org" , Snigdho Bardalai Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 17:24:02 -0000 Hi, I have a suggestion. Why don't we allow a node to optionally advertise the unreserved bandwidth = for each of the component links in a bundle? This is a general, non-OTN, s= olution to this specific problem and it is backwards compatible. Thanks, John=20 > -----Original Message----- > From: John E Drake > Sent: Thursday, July 22, 2010 8:24 AM > To: 'curtis@occnc.com'; BELOTTI, SERGIO (SERGIO) > Cc: Daniele Ceccarelli; ccamp@ietf.org; Snigdho Bardalai; Igor Bryskin > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > Curtis, >=20 > As I said last week, I think the existing RFC 4202/4203 design works > just fine for unbundled links. >=20 > For bundled links, due to bin packing, it is asserted that if one > advertised unreserved bandwidth by what I have been calling service > type (which in the OTN case equates to ODUj client rate), one can get a > more accurate understanding of the state of the bundled link wrt the > number of LSPs that could be established at each of the ODUj client > rates available at the time of advertisement. >=20 > So, I think there are two questions. 1) Do we want to advertise > unreserved bandwidth by service type, and if so, do we want to > advertise it for all links or only for bundled links? >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, July 21, 2010 1:25 PM > > To: BELOTTI, SERGIO (SERGIO) > > Cc: curtis@occnc.com; Daniele Ceccarelli; ccamp@ietf.org; Snigdho > > Bardalai; Igor Bryskin; John E Drake > > Subject: Re: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > In message > > m.alcatel-lucent.com> > > "BELOTTI, SERGIO (SERGIO)" writes: > > > > > > Hi Curtis, > > > > > > Thanks for your comment. > > > As pointed out by Daniele you're right but the missing information > > > here is the real spatial allocation that raised in importance above > > > all in case of link bundling unless you constrain the capability in > 1 > > > component link per TE-link, that would reduce value of this very > > > important feature for scalability. > > > > > > Maybe I'm missing something (again). If so, please point out what I > > missed. > > > > In link bundling the min LSP BW is the smallest LSP or TDM container > > supported. Any multiple of the min LSP is allowed. The max LSP BW > is > > the largest LSP that can be accommodated (per priority). The max > > reservable BW (not max LSP bw) is the total size of the bundle, > > ignoring any reservations, and the reservable BW (in the Link TLV in > > RFC 3630) indicates how much capacity is still left. > > > > For bundles as per RFC 4201: > > > > 3.10. Maximum LSP Bandwidth > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > Bandwidth. For an unbundled link, the Maximum Bandwidth is > > defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a > > bundled link at priority p is defined to be the maximum of the > > Maximum LSP Bandwidth at priority p of all of its component > links. > > The details of how Maximum LSP Bandwidth is carried in IS-IS is > > given in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth > > is carried in OSPF is given in [GMPLS-OSPF]. > > > > This is consistent with RFC 4203 "Max LSP Bandwidth at priority N" > > being reported in the ISCD. > > > > 3.8. Unreserved Bandwidth > > > > The unreserved bandwidth of a bundled link at priority p is the > > sum of the unreserved bandwidths at priority p of all the > > component links associated with the bundled link. > > > > This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined > > in RFC 3630. > > > > That seems to me to completely cover link bundling with no > constraints > > on its capability and no need for one TE-link (FA) per compoent link. > > > > > > > About the last part > > > > > > [BTW- Lets please not talk about "ignorance and misunderstanding". > > > This is not simple obvious stuff and maybe none of us individually > > > knows everything about everything. Myself (all too obviously > > > sometimes) included.] > > > > > > I'm completely agree with you. > > > I know all that is not simple and obvious stuff for everyone. > > > My only two cents is just to highlight it is not always possible > > > justify that different solution for SDH control plane with respect > > > what defined in RFC 4202/4203 are deployed, with a bad reading of > > > these RFCs. > > > > > > We are defining new OTN functionality so software will need to > > change. If prior SONET implementations didn't get it right that is > no > > reason to not get it right in defining the OTN extensions. > > > > > > > Best Regards > > > > > > Sergio > > > > > > Curtis > > > > > > > Sergio Belotti > > > > > > System Architecture > > > Optics Division-Terrestrial Optics Unit > > > ALCATEL-LUCENT > > > > > > +39 039 6863033 > > > +39 039 6863590 > > > > > > > > > -----Messaggio originale----- > > > Da: curtis@occnc.com [mailto:curtis@occnc.com] > > > Inviato: mercoled=EC 21 luglio 2010 1.36 > > > A: Igor Bryskin > > > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > > Bardalai > > > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > > > John, > > > > > > > > The point is that from ISCD you can not figure out how *many* > LSPs > > > > matching the ISCD you can accommodate on the link. Such > information > > is > > > > important in case of con-current routing (e.g. restoration after > > link > > > > failure). > > > > > > > > Igor > > > > > > Igor, Sergio, > > > > > > RFC 4203 (in 1. Introduction) > > > > > > The TE LSA, which is an opaque LSA with area flooding scope > > > [OSPF-TE], has only one top-level Type/Length/Value (TLV) > triplet > > > and has one or more nested sub-TLVs for extensibility. The > > > top-level TLV can take one of two values (1) Router Address or > (2) > > > Link. In this document, we enhance the sub-TLVs for the Link > TLV > > > in support of GMPLS. Specifically, we add the following sub- > TLVs > > > to the Link TLV: > > > > > > [OSPF-TE] above is RFC 3630. > > > > > > RFC 3630 (in 2.4.2. Link TLV) > > > > > > The following sub-TLVs of the Link TLV are defined: > > > > > > 1 - Link type (1 octet) > > > 2 - Link ID (4 octets) > > > 3 - Local interface IP address (4 octets) > > > 4 - Remote interface IP address (4 octets) > > > 5 - Traffic engineering metric (4 octets) > > > 6 - Maximum bandwidth (4 octets) > > > 7 - Maximum reservable bandwidth (4 octets) > > > 8 - Unreserved bandwidth (32 octets) > > > 9 - Administrative group (4 octets) > > > > > > If you read on you find: > > > > > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > > > bandwidth that may be reserved on this link, in this direction, > in > > > IEEE floating point format. Note that this may be greater than > > the > > > maximum bandwidth (in which case the link may be > oversubscribed). > > > > > > and > > > > > > The Unreserved Bandwidth sub-TLV specifies the amount of > bandwidth > > > not yet reserved at each of the eight priority levels in IEEE > > > floating point format. The values correspond to the bandwidth > > that > > > can be reserved with a setup priority of 0 through 7, arranged > in > > > increasing order with priority 0 occurring at the start of the > > sub- > > > TLV, and priority 7 at the end of the sub-TLV. [...] > > > > > > So the totals per link and per priority level are already there in > > the > > > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > > > > > > That is how you figure out how many ODU0 you can add to your > existing > > > ODU2, and so on. > > > > > > [BTW- Lets please not talk about "ignorance and misunderstanding". > > > This is not simple obvious stuff and maybe none of us individually > > > knows everything about everything. Myself (all too obviously > > > sometimes) included.] > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > Sent: Tuesday, July 20, 2010 1:13 PM > > > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > > > > > >From RFC 4202: > > > > > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > > priority p > > > > is defined as the maximum bandwidth an LSP at priority p could > > > > reserve. Maximum LSP Bandwidth for a bundled link is defined > in > > > > [LINK-BUNDLE]. > > > > > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an > LSP > > > > could reserve. > > > > > > > > Typical values for the Minimum LSP Bandwidth and for the > Maximum > > LSP > > > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > > > > > On an interface having Standard SDH multiplexing, an LSP at > > priority > > > > p could reserve any bandwidth allowed by the branch of the SDH > > > > hierarchy, with the leaf and the root of the branch being > > defined by > > > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > > priority > > > > p. > > > > > > > > On an interface having Arbitrary SDH multiplexing, an LSP at > > priority > > > > p could reserve any bandwidth between the Minimum LSP > Bandwidth > > and > > > > the Maximum LSP Bandwidth at priority p, provided that the > > bandwidth > > > > reserved by the LSP is a multiple of the Minimum LSP > Bandwidth. > > > > > > > > >From RFC 4201: > > > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > Bandwidth. > > > > For an unbundled link, the Maximum Bandwidth is defined in > > > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link > at > > > > priority p is defined to be the maximum of the Maximum LSP > > Bandwidth > > > > at priority p of all of its component links. > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake > > > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > > > framework-01.txt > > > > > > > > > > Snipped.... > > > > > > > > > > > > > > > > > I realized from someone in this thread (not from you) this > was > > due > > > > > just > > > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > > > advertisement for SDH . Anyway it is a fact that the > > alternative > > > > > format > > > > > > is used in many implementations "in field" for SDH control > > plane. > > > > > > > > > > > > > > > > JD: As the person to whom I believe you are referring, I would > > suggest > > > > > that you actually read RFC 4202 and 4206. From SBardalai@infinera.com Thu Jul 22 10:27:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052BF3A684A for ; Thu, 22 Jul 2010 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yMSoMDnFA06 for ; Thu, 22 Jul 2010 10:27:08 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 1FD9F3A67C3 for ; Thu, 22 Jul 2010 10:27:08 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Thu, 22 Jul 2010 10:27:04 -0700 From: Snigdho Bardalai To: John E Drake , "curtis@occnc.com" , "BELOTTI, SERGIO (SERGIO)" Date: Thu, 22 Jul 2010 10:27:34 -0700 Thread-Topic: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspEs4rfpzXbzHMSoS+YSwEHFKz6wAnrF6QAAQYHrAAADnzAA== Message-ID: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE78AF@SV-EXDB1.infinera.com> References: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32D16@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639844B32D16@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Igor Bryskin Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 17:27:10 -0000 John That is an alternative but because the size of the LSA grows with number of= components you could potentially have to limit the size of a bundle or be = ready to grow the LSA (in theory there is no limit) Regards Snigdho > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 22, 2010 10:21 AM > To: John E Drake; curtis@occnc.com; BELOTTI, SERGIO (SERGIO) > Cc: Daniele Ceccarelli; ccamp@ietf.org; Snigdho Bardalai; Igor Bryskin > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > Hi, >=20 > I have a suggestion. >=20 > Why don't we allow a node to optionally advertise the unreserved > bandwidth for each of the component links in a bundle? This is a > general, non-OTN, solution to this specific problem and it is backwards > compatible. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: John E Drake > > Sent: Thursday, July 22, 2010 8:24 AM > > To: 'curtis@occnc.com'; BELOTTI, SERGIO (SERGIO) > > Cc: Daniele Ceccarelli; ccamp@ietf.org; Snigdho Bardalai; Igor > Bryskin > > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > Curtis, > > > > As I said last week, I think the existing RFC 4202/4203 design works > > just fine for unbundled links. > > > > For bundled links, due to bin packing, it is asserted that if one > > advertised unreserved bandwidth by what I have been calling service > > type (which in the OTN case equates to ODUj client rate), one can get > a > > more accurate understanding of the state of the bundled link wrt the > > number of LSPs that could be established at each of the ODUj client > > rates available at the time of advertisement. > > > > So, I think there are two questions. 1) Do we want to advertise > > unreserved bandwidth by service type, and if so, do we want to > > advertise it for all links or only for bundled links? > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, July 21, 2010 1:25 PM > > > To: BELOTTI, SERGIO (SERGIO) > > > Cc: curtis@occnc.com; Daniele Ceccarelli; ccamp@ietf.org; Snigdho > > > Bardalai; Igor Bryskin; John E Drake > > > Subject: Re: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > In message > > > > m.alcatel-lucent.com> > > > "BELOTTI, SERGIO (SERGIO)" writes: > > > > > > > > Hi Curtis, > > > > > > > > Thanks for your comment. > > > > As pointed out by Daniele you're right but the missing > information > > > > here is the real spatial allocation that raised in importance > above > > > > all in case of link bundling unless you constrain the capability > in > > 1 > > > > component link per TE-link, that would reduce value of this very > > > > important feature for scalability. > > > > > > > > > Maybe I'm missing something (again). If so, please point out what > I > > > missed. > > > > > > In link bundling the min LSP BW is the smallest LSP or TDM > container > > > supported. Any multiple of the min LSP is allowed. The max LSP BW > > is > > > the largest LSP that can be accommodated (per priority). The max > > > reservable BW (not max LSP bw) is the total size of the bundle, > > > ignoring any reservations, and the reservable BW (in the Link TLV > in > > > RFC 3630) indicates how much capacity is still left. > > > > > > For bundles as per RFC 4201: > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > > Bandwidth. For an unbundled link, the Maximum Bandwidth is > > > defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a > > > bundled link at priority p is defined to be the maximum of the > > > Maximum LSP Bandwidth at priority p of all of its component > > links. > > > The details of how Maximum LSP Bandwidth is carried in IS-IS is > > > given in [GMPLS-ISIS]. The details of how Maximum LSP > Bandwidth > > > is carried in OSPF is given in [GMPLS-OSPF]. > > > > > > This is consistent with RFC 4203 "Max LSP Bandwidth at priority N" > > > being reported in the ISCD. > > > > > > 3.8. Unreserved Bandwidth > > > > > > The unreserved bandwidth of a bundled link at priority p is the > > > sum of the unreserved bandwidths at priority p of all the > > > component links associated with the bundled link. > > > > > > This goes in the Link TLV in the Unreserved Bandwidth sub-TLV > defined > > > in RFC 3630. > > > > > > That seems to me to completely cover link bundling with no > > constraints > > > on its capability and no need for one TE-link (FA) per compoent > link. > > > > > > > > > > About the last part > > > > > > > > [BTW- Lets please not talk about "ignorance and > misunderstanding". > > > > This is not simple obvious stuff and maybe none of us > individually > > > > knows everything about everything. Myself (all too obviously > > > > sometimes) included.] > > > > > > > > I'm completely agree with you. > > > > I know all that is not simple and obvious stuff for everyone. > > > > My only two cents is just to highlight it is not always possible > > > > justify that different solution for SDH control plane with > respect > > > > what defined in RFC 4202/4203 are deployed, with a bad reading of > > > > these RFCs. > > > > > > > > > We are defining new OTN functionality so software will need to > > > change. If prior SONET implementations didn't get it right that is > > no > > > reason to not get it right in defining the OTN extensions. > > > > > > > > > > Best Regards > > > > > > > > Sergio > > > > > > > > > Curtis > > > > > > > > > > Sergio Belotti > > > > > > > > System Architecture > > > > Optics Division-Terrestrial Optics Unit > > > > ALCATEL-LUCENT > > > > > > > > +39 039 6863033 > > > > +39 039 6863590 > > > > > > > > > > > > -----Messaggio originale----- > > > > Da: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Inviato: mercoled=EC 21 luglio 2010 1.36 > > > > A: Igor Bryskin > > > > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; > Snigdho > > > Bardalai > > > > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > John, > > > > > > > > > > The point is that from ISCD you can not figure out how *many* > > LSPs > > > > > matching the ISCD you can accommodate on the link. Such > > information > > > is > > > > > important in case of con-current routing (e.g. restoration > after > > > link > > > > > failure). > > > > > > > > > > Igor > > > > > > > > Igor, Sergio, > > > > > > > > RFC 4203 (in 1. Introduction) > > > > > > > > The TE LSA, which is an opaque LSA with area flooding scope > > > > [OSPF-TE], has only one top-level Type/Length/Value (TLV) > > triplet > > > > and has one or more nested sub-TLVs for extensibility. The > > > > top-level TLV can take one of two values (1) Router Address or > > (2) > > > > Link. In this document, we enhance the sub-TLVs for the Link > > TLV > > > > in support of GMPLS. Specifically, we add the following sub- > > TLVs > > > > to the Link TLV: > > > > > > > > [OSPF-TE] above is RFC 3630. > > > > > > > > RFC 3630 (in 2.4.2. Link TLV) > > > > > > > > The following sub-TLVs of the Link TLV are defined: > > > > > > > > 1 - Link type (1 octet) > > > > 2 - Link ID (4 octets) > > > > 3 - Local interface IP address (4 octets) > > > > 4 - Remote interface IP address (4 octets) > > > > 5 - Traffic engineering metric (4 octets) > > > > 6 - Maximum bandwidth (4 octets) > > > > 7 - Maximum reservable bandwidth (4 octets) > > > > 8 - Unreserved bandwidth (32 octets) > > > > 9 - Administrative group (4 octets) > > > > > > > > If you read on you find: > > > > > > > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > > > > bandwidth that may be reserved on this link, in this > direction, > > in > > > > IEEE floating point format. Note that this may be greater > than > > > the > > > > maximum bandwidth (in which case the link may be > > oversubscribed). > > > > > > > > and > > > > > > > > The Unreserved Bandwidth sub-TLV specifies the amount of > > bandwidth > > > > not yet reserved at each of the eight priority levels in IEEE > > > > floating point format. The values correspond to the bandwidth > > > that > > > > can be reserved with a setup priority of 0 through 7, arranged > > in > > > > increasing order with priority 0 occurring at the start of the > > > sub- > > > > TLV, and priority 7 at the end of the sub-TLV. [...] > > > > > > > > So the totals per link and per priority level are already there > in > > > the > > > > base spec before the RFC 4203 *extensions* to RFC 3630 were > added. > > > > > > > > That is how you figure out how many ODU0 you can add to your > > existing > > > > ODU2, and so on. > > > > > > > > [BTW- Lets please not talk about "ignorance and > misunderstanding". > > > > This is not simple obvious stuff and maybe none of us > individually > > > > knows everything about everything. Myself (all too obviously > > > > sometimes) included.] > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 1:13 PM > > > > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > >From RFC 4202: > > > > > > > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > > > priority p > > > > > is defined as the maximum bandwidth an LSP at priority p > could > > > > > reserve. Maximum LSP Bandwidth for a bundled link is > defined > > in > > > > > [LINK-BUNDLE]. > > > > > > > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an > > LSP > > > > > could reserve. > > > > > > > > > > Typical values for the Minimum LSP Bandwidth and for the > > Maximum > > > LSP > > > > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > > > > > > > On an interface having Standard SDH multiplexing, an LSP at > > > priority > > > > > p could reserve any bandwidth allowed by the branch of the > SDH > > > > > hierarchy, with the leaf and the root of the branch being > > > defined by > > > > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > > > priority > > > > > p. > > > > > > > > > > On an interface having Arbitrary SDH multiplexing, an LSP at > > > priority > > > > > p could reserve any bandwidth between the Minimum LSP > > Bandwidth > > > and > > > > > the Maximum LSP Bandwidth at priority p, provided that the > > > bandwidth > > > > > reserved by the LSP is a multiple of the Minimum LSP > > Bandwidth. > > > > > > > > > > >From RFC 4201: > > > > > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > > Bandwidth. > > > > > For an unbundled link, the Maximum Bandwidth is defined in > > > > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled > link > > at > > > > > priority p is defined to be the maximum of the Maximum LSP > > > Bandwidth > > > > > at priority p of all of its component links. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake > > > > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework-01.txt > > > > > > > > > > > > Snipped.... > > > > > > > > > > > > > > > > > > > > I realized from someone in this thread (not from you) this > > was > > > due > > > > > > just > > > > > > > to ignorance and misunderstanding of RFC 4202/4203 > bandwidth > > > > > > > advertisement for SDH . Anyway it is a fact that the > > > alternative > > > > > > format > > > > > > > is used in many implementations "in field" for SDH control > > > plane. > > > > > > > > > > > > > > > > > > > JD: As the person to whom I believe you are referring, I > would > > > suggest > > > > > > that you actually read RFC 4202 and 4206. From jdrake@juniper.net Thu Jul 22 10:34:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC793A6896 for ; Thu, 22 Jul 2010 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g63Ch1B6ykam for ; Thu, 22 Jul 2010 10:33:58 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id B89FA3A676A for ; Thu, 22 Jul 2010 10:33:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTEiA7mYDV+c4x5P2VGTBEfhfxM+Od0hx@postini.com; Thu, 22 Jul 2010 10:33:55 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Jul 2010 10:30:44 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" Date: Thu, 22 Jul 2010 10:30:42 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ5fxRxCX072TIeobRA5d6U+SgAm3o3gAADpouAAAY2NUA== Message-ID: <5E893DB832F57341992548CDBB3331639844B32D6C@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 17:34:03 -0000 Igor, This sounds like arm waving to me. To put things in perspective, let's rem= ember that you are the only person that is claiming that an operator wants = any of this. I have seen nothing to date in I-Ds pertaining to OTN that ha= s said any of this is needed. It is also completely contrary to the ITU mo= deling work for OTN, which uses a single flat network. (Of which you were,= until recently, completely unaware.) As a general rule, what should be advertised in the TE database is the type= of client signals that can be placed on a given link and not its server ch= aracteristics, which are more or less totally irrelevant. John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 22, 2010 10:13 AM > To: John E Drake; curtis@occnc.com > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > One reason is that ISCD allows for advertising of available LSP > bandwidth per priority level, which could change for the same OTN link > depending on role. Coloring won't allow to do so. Also, ISCD encoding > type allows for encoding the signal type, mux. capabilities, etc. > without introduction of OTN specific sub-TLVs. We want to help operator > to provision topologies, ID them and provide a simple way to constrain > a given LSP to be routed within a topology. ISCD gives you a simple > way to do so in a technology independent way, so that constraining LSP > to belong, say, OTN_LO or OTN_HO topology will not be different from > constraining LSP to belong to, say, ETH_EVPL layer. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 22, 2010 12:19 PM > To: curtis@occnc.com; Igor Bryskin > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > There is no reason to define multiple ISCD values for OTN networks in > order to constrain the path of a given LSP to only certain links. The > right way to do this is link colors (nee Administrative Groups, defined > in RFC 3630), which is what it was designed to do. > > I know this is a radical thought but why don't we use ISCD for what it > was designed to do? > > Thanks, > > John > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, July 21, 2010 2:38 PM > > To: Igor Bryskin > > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > > Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho > > Bardalai; Varma, Eve L (Eve); Fatai Zhang > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Igor, > > > > A current solution would be to use ML/MT extensions. A GMPLS E-NNI > > could also solve this problem if designed to isolate clients and > > resources in this manner. > > > > No hacking of RFC 4203 is needed. No (new) warts need to be added. > > > > Curtis > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > Hi Sergio, > > > > I'd like to run with you the following logic. > > > > 1. Suppose an operator after some planning decides to provision an > > infrastructure ODU and use it as a link. Why would he do so? One > > reason that I can think of is because he wants to build a virtual > > topology for a set of clients (with possibly himself as one from the > > set). The purpose of this topology, generally speaking, is: > > a) To be non-congruent with underlying topology (virtual or > > OTU/OCh). For example, to interconnect nodes that do not have a > common > > OTU/OCh link; > > b) To constrain said set of clients to resources of the topology > > (rather than, for example, to use OTU/OCh links directly). > > The question is how the operator can constrain the routing of the > ODUs > > for the clients from the set to the prepared for this purpose virtual > > topology within the flat ITU routing model? > > > > 2. Would you agree that the only reason why a TE link advertises an > > attribute is to be able to constrain a path computation based on the > > attribute? Your definitions of the OTN encoding types, for example, > > are: > > " .... > > o 8 - Lambda (Photonic) > > o 12 - G.709 ODUk (Digital Path) > > .... > > " > > > > which will give the operator an ability to route an OTN connection > > either straight over OTUs or over infrastructure ODUs with no regard > to > > the roles assigned to the links. Do you believe this would be > flexible > > enough for the operator? > > > > 3. What is it you can achieve with the suggested OTN routing that can > > not be achieved using multiple 4203 ISCDs? > > > > Thanks, > > Igor > > > > > > -----Original Message----- > > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > > lucent.com] > > Sent: Wednesday, July 21, 2010 10:59 AM > > To: Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele > Ceccarelli; > > John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); > > Fatai Zhang > > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > For point 1) and 2) I do not think we are so far. > > You're proposing a three-layer approach , we are aligned with what > ITU > > is proposing but we also have different roles in the network (lambda > > and sub-lambda) and than needs for constrains and policy in the > > network. > > The fact to have three switching capability to characterize the > > different roles in the same technology it seems to me a little > against > > the concept of switching capability itself. > > You could say that for packet there is already 4 PSC SC defined. But > > here we are in TDM , we have not label stacking capability. > > > > For point 3) and 4) , I do not discuss about the generality or not of > > the issue, but surely you cannot negate that the problem of spatial > > allocation is raised as soon as SDH CP has been implemented . Then > the > > same problem come in for OTN , and your intention to cope the issue > in > > a generic way with modifications of RFC 4203 is a good intention, but > > take also into account that also our proposed format can be generic > as > > soon as you change the signal types supported. > > > > You're right we need to discuss face to face but my perception is > that > > we ca be less far than you believe. > > > > Cheers > > > > Sergio > > > > Sergio Belotti > > > > System Architecture > > Optics Division-Terrestrial Optics Unit > > ALCATEL-LUCENT > > > > +39 039 6863033 > > +39 039 6863590 > > > > > > -----Messaggio originale----- > > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto > di > > Igor Bryskin > > Inviato: mercoled=EC 21 luglio 2010 15.51 > > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; > > Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > We need to discuss this face to face. The biggest disagreements with > > Daniele are: > > 1) I don't believe that flat routing model of a multi-layer OTN > network > > is correct. > > 2) I think each OTN role defines a separate topology of OTN links, > and > > there is a need to be able to constrain the routing of a given OTN > > connection to one or more (but not necessarily all) such topologies; > > 3) There is an issue in the current definitions of GMPLS OSPF > > extensions (RFC 4203), which does allow to specify multiple ISCDs but > > does not guide as to how the available bandwidth on the link is > > partitioned between ISCDs. This is a generic issue and should be > > resolved in a generic way; > > 4) Other than (3) we don't need any OTN or TDM specific CP machinery > > for TE and routing in OTN networks. Unless we see strong reasons to > the > > contrary we should not invent such machinery. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > Sent: Wednesday, July 21, 2010 8:30 AM > > To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; > > Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > I support this as well, of course. Whether this is a technology- > > specific extension of the ISCD format or a separate sub-TLV is a > > detail, however as Daniele points out many of the same considerations > > apply to both OTN and SONET/SDH. > > > > Lyndon > > > > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Daniele Ceccarelli > > Sent: Wednesday, July 21, 2010 12:49 AM > > To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > In other words it could be possible to define 3 Switching Cap (LO, HO > > and SHO) and put what we defined in the encoding draft into the > > Switching Capability-specific information of the ISCD. > > > > Something like this: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -- > > ---Switching Capability-specific information > > |0|1|2|3|4|5|6|7| T | | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ... ... > ... > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I still don't understand why we need partitioning the network in > three > > layers while just Sublamba and Full lambda distinction is enough > > (distinction supported advertising different signal types for full > > lambdas and sublambdas. > > > > Personally i still prefer advertising these pieces of information as > a > > separate sub-TLV (called OTN-ISCD subTLV in the draft but easily > > estensible to TDM-ISCD accordingly to > http://tools.ietf.org/html/draft- > > ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this > > could be a valid solution too. > > > > BR > > Daniele > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 23.02 > > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > Do you understand the quote from RFC4203: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Capability-specific information | > > | (variable) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > You can use the last field for OTN switchcap to advertise unresolved > > bandwidth available for the ISCD on per priority level. > > > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 4:35 PM > > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snipped... > > > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > > priority > > > level for every ISCD. > > > > JD: Igor, what part of my quote from RFC 4202 did you not > understand? > > You do not advertise unreserved bandwidth in the ISCD TLV. In > > particular, for TDM, what is advertised is the max and min bandwidth > > allowed for a single LSP. It was designed to produce a compact > > representation by taking advantage of the SDH/SONET hierarchy. > > > > Advertising a separate ISCD for each supported rate is allowed but > > wasteful. > > > > > > > > Igor > > > > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > > wro=3D > > > > te: > > > > > > > > > John, > > > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > > However if a > > > > > TE link advertises more than one ISCD (with each ISCD > containing > > > only max > > > > > lsp bandwidth per priority), it is necessary to indicate how > the > > > total li=3D > > > > nk > > > > > unreserved bandwidth is partitioned between several ISCDs. What > I > > > am > > > > > suggesting is instead of advertising the unreserved bandwidth > > > multiple ti=3D > > > > mes > > > > > (one per ISCD), indicate how the bandwidth is split between the > > > ISCDs: e.=3D > > > > g > > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > > > Igor. > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > > Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > Igor, > > > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so > the > > > issue o=3D > > > > f > > > > > partitioning unreserved bandwidth across multiple advertised > TDM > > > ISC TLVs=3D > > > > is > > > > > actually a non-issue. > > > > > > > > > > Unreserved bandwidth by priority has always been advertised > using > > > the MPL=3D > > > > S > > > > > sub-TLV. My point has been that we have never had a > requirement > > > (includi=3D > > > > ng > > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > > signal > > > type, =3D > > > > so > > > > > what is special about OTN? > > > > > > > > > > A further point would be that if we do decide that it is > > necessary > > > to > > > > > advertise unreserved bandwidth by signal type, it should be > done > > > > > in > > > a > > > > > general way and not in an OTN specific manner. (And in fact, > the > > > argumen=3D > > > > ts > > > > > that unreserved bandwidth by signal type needs to be > advertised, > > > such as =3D > > > > the > > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > It is a valid point, but the suggested solution is way too > > > expensive. > > > > > > All you need is a way to say how the advertised unreserved > > > bandwidth is > > > > > > partitioned between ISCDs in case the TE link advertisement > > > contains > > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > > bits out > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > > total > > > > > > unreserved bandwidth associated with the ISCD. Another way is > > to > > > use > > > > > > swicthcap specific extension. > > > > > > BTW: this is not an OTN specific issue, rather more general: > > any > > > time > > > > > > when a TE link advertises more than one ISCD (which is > > perfectly > > > Ok > > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, > > > > > > > > > > > > The need for unreserved resources advertised per signal type > is > > > the > > > > > > concurrent path computation. I'll answer quoting a section > from > > > the > > > > > > info-model draft, please have a look in particular to the > > > example: > > > > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > > and > > > per > > > > > > signal type in order to allow the correct functioning of > the > > > > > > restoration process. [RFC4203] only allows advertising > > > unreserved > > > > > > resources per priority, this leads not to know how many > LSPs > > > of a > > > > > > specific signal type can be restored. As example it is > > > possible to > > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > > > +------+ component link 1 +------+ > > > > > > | +------------------+ | > > > > > > | | component link 2 | | > > > > > > | N1 +------------------+ N2 | > > > > > > | | component link 3 | | > > > > > > | +------------------+ | > > > > > > +------+ +---+--+ > > > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component > links > > > with > > > > > > 32TSs available on the first one, 24TSs on the second, > 24TSs > > > on the > > > > > > third and supporting ODU2 and ODU3 signal types. The node > > > would > > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs > and > > > > > > a > > > MAX > > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > > network > > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > > > only > > > a > > > > > > single ODU3 can be set up and a crank-back would be > > > originated. In > > > > > > more complex network scenarios the number of crank-backs > can > > > be much > > > > > > higher." > > > > > > > > > > > > In other words, advertising the number of availble resources > > per > > > signal > > > > > > type does not avoid the possibility of cranck-back but > > decreases > > > it as > > > > > > much as possible. For sure a good routing prevents from > crank- > > > backs > > > > > > caused by the restoration of LSP originating on the same > > Ingress. > > > The > > > > > > cranck-backs due to the concurrent restoration of LSPs > > > originating on > > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > > > BR > > > > > > Daniele > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > In line > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, one more question. > > > > > > > > > > > > What about the unreserved bandwidth? > > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per > role > > > per > > > > > > (muxCap & signal type) you also need to advertise the > > unreserved > > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > > correct? > > > This > > > > > > also implies extending the unreserved bandwidth TLV so to > > create > > > a > > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > > subTLV). > > > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > > ISCD > > > per > > > > > > IB>> role per (muxCap & signal type) per priority level. > > > > > > IB>> However, > > > total > > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > > > IB>> unless > > > you > > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > > > Igor > > > > > > > > > > > > Thanks > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Understood... > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > sufficient > > > > > > > > > > > > > > That's exactly what I've been > > > > > > > trying to say all along. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Regards > > > > > > > Snigdho > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Daniele Ceccarelli > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an > ISCD > > > per > > > > > > role > > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > > signal > > > > > > type. > > > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > > switchCap =3D3D role; > > > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > > > reserved bits which can use for OTN specific > > > info > > > > > > in > > > > > > > > case we need it. > > > > > > > [SCB] I am yet to clearly understand what the role of > "role" > > > is, but > > > > > > > agree with your observation on the encode-type and the 16 > > > > > > > reserved-bits to further classify the switching > information. > > > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. > For > > > each > > > > > > role > > > > > > > > you would advertise just the unreserved bandwidth but you > > > wouldn't > > > > > > > know > > > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > > > LSP > > > (e.g. > > > > > > > 15 > > > > > > > > Gbps available on 3 component links: you advertise 45 > Gbps > > > > > > available > > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > > scalability > > > > > > > issues > > > > > > > > and the requirement of being able to bundle component > links > > > > > > together > > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > > ISDCs > > > > > > will > > > > > > > > provide a lot of flexibility: you can specify different > > > things > > > > > > (e.g. > > > > > > > > available bandwidth) for the same link in different > roles. > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > > sufficient? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Daniele > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Igor Bryskin > > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Fatai Zhang > > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > Thanks. > > > > > > > > I understand what you said. Therefore, we have added some > > > text to > > > > > > > > address the requirment in FWK document. However, we still > > > don't > > > > > > > > think that we need to extend ISC to meet the requirment. > > The > > > role > > > > > > of > > > > > > > > the > > > > > > > ODU > > > > > > > > can be get from the routing information implicitly. In > the > > > [draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > "Full > > > > > > Lambda" > > > > > > > is > > > > > > > > introduced. > > > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > > a) this requires OTN specific advertising and processing > > > rules; > > > > > > > > b) disallows topology separation in technology > independent > > > way > > > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > > container > > > > > > > does > > > > > > > > not change hop-by-hop (as some people seem to believe). > The > > > role is > > > > > > > > only meaningful on the ODU terminating nodes and > irrelevant > > > on > > > > > > > transit > > > > > > > > nodes. It is it's position in the hierarchy (but not > role) > > > that may > > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > > > AI1 > > > and > > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > > > can > > > only > > > > > > > support > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > > > with > > > the > > > > > > > role > > > > > > > > of Ho ODU level is requested, according to your > statement, > > > this > > > > > > > > conneciton will be allowed to be created. However, it > > should > > > not be > > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 > TE > > > link > > > > > > ends > > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and > OIN_LO_SC, > > > while > > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > > > path computation is constrained to the OTN_HO_SC > topology, > > > > > > > > B11 and > > > B12 > > > > > > TE > > > > > > > > links will > > > > > > > be > > > > > > > > disallowed, and the resulting path (if any) will not go > > > through B11 > > > > > > > and > > > > > > > > B12. If one circumvents the path computation by providing > > > > > > > > the > > > fully > > > > > > > > explicit path, the signaling should fail on node B for > the > > > same > > > > > > > reason: > > > > > > > > inconsistency of required (signaled) and supported (by > > local > > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify > that > > > the > > > > > > type > > > > > > > > indicated in the Switching Type parameter is supported > on > > > the > > > > > > > > corresponding incoming interface. If the type cannot be > > > > > > supported, > > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > > problem/Switching Type" indication." > > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Lou Berger" > ; > > > > > > > > ; > > > > > > > framework@tools.ietf.org> > > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > > ccamp@ietf.org; > > > > > > > draft- > > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > > > I think role does not equal switching capability. The > > > operators can > > > > > > > > define different roles depending on their policy and > > achieve > > > the > > > > > > > > role through different methods. However, for OTN > networks, > > > the > > > > > > > > containers (e.g., ODUk) all have the same switching > > > capablility > > > > > > > > (i.e., TDM > > > > > > > > switching) and I think we should reflect the natural > > > > > > characteristics > > > > > > > of > > > > > > > > links in the routing. In addition, if we extend the ISC, > it > > > will > > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > > overrides > > > > > > > > encoding type). > > > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > > views the > > > > > > > > network as a stack of topologies. Whether a given > topology > > > > > > > > is > > > real > > > > > > > > or virtual is of no importance. > > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > > > switching capability field (confusing name as it is) is a > > > > > > > > good way to > > > > > > describe > > > > > > > a > > > > > > > > layer in technology independent way, so that, say, MPLS- > TP- > > > >OTN_LO- > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > > stack of > > > > > > > > topologies that could be easily separated in technology > > > independent > > > > > > > way > > > > > > > > should path computation be constrained to particular one > or > > > > > > > > sub-stack of them. > > > > > > > > I think a good way to identify an OTN (virtual) topology > is > > > via > > > > > > > > (infrastructure) ODU container role of ODUs comprising > the > > > > > > topology. > > > > > > > > BTW IMO the role of an ODU container does not change hop- > > by- > > > hop (as > > > > > > > > some people seem to believe). The role is only meaningful > > on > > > the > > > > > > ODU > > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > > > it's > > > > > > > position > > > > > > > > in the hierarchy (but not role) that may change hop-by- > hop. > > > ODU's > > > > > > > role > > > > > > > > is the level of topology it is provisioned for and it is > > the > > > same > > > > > > > > for all ODUs that comprise the topology. For, example a > > user > > > may > > > > > > > provision > > > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > > > clients > > > to > > > > > > use > > > > > > > > the topology rather than any resources available on OTN > > > network. > > > > > > > > The bottom line: container's role is the same as the role > > of > > > > > > virtual > > > > > > > > topology the container is a part of and could be > advertised > > > as the > > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise > the > > > roles > > > > > > > > and muxing capabilities with the ISCD of RFC4202, could > you > > > > > > clarify? > > > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > > > IB>> etc.) > > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > > > In addition, could you clarify my questions in another > > email > > > > > > (copied > > > > > > > as > > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > 3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > > other. > > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > > hierarchy, > > > > > > which > > > > > > > is > > > > > > > > a mistake IMO. > > > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 > or > > > ODU3 as > > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if > there > > > > > > > > is > > > a > > > > > > OTU3 > > > > > > > link > > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > > (service > > > > > > > > over > > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > > this > > > case, > > > > > > > how > > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > > Level? > > > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important > on > > > the ODU > > > > > > > > terminating nodes (i.e. on either side of corresponding > > > link). What > > > > > > > > happens on the ODU transit nodes and its place in the > > > hierarchy on > > > > > > > the > > > > > > > > transit nodes are of no importance. My LO container can > be > > > carried > > > > > > > > by somebody else's LO container and can carry my client's > > LO > > > > > > container. > > > > > > > To > > > > > > > > some extent it is similar to MPLS LSP role: LSP always > has > > a > > > role > > > > > > > (e.g. > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > > along its > > > > > > > > path. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > 3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Fatai Zhang" > > > ; > > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org> > > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > > > I agree that there should be multiple OTN specific > encoding > > > types > > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > > capabilities > > > > > > > > rather than the link's role (i.e. level in the OTN > > hierarchy: > > > LO, > > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > > indicated > > > > > > > > with a separate switchcaps. I can give you several > reasons: > > > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have > different > > > roles; > > > > > > 2. > > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > > different > > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > > capabilities can > > > > > > > be > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > > ISCD is > > > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > > > type > > > will > > > > > > > look > > > > > > > > to CP as a separate layer, which is exactly how ITU > models > > > OTN > > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > > operator > > > > > > would > > > > > > > > want to constrain the routing of OTN connections to pre- > > > configured > > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > > sells to > > > > > > > the > > > > > > > > clients to one or more pre-configured LO topologies), > this > > > would be > > > > > > > > possible to do in a technology independent way. Suppose > an > > > instance > > > > > > > of > > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > > from > > > HO OTN > > > > > > > > links will be no different from the separation of WDM > links > > > from > > > > > > > OTUs. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > > To: Igor Bryskin > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger; > > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > In message > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > > srv- > > > > > > > > exgen.atl.advaoptical.com> > > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > > > many > > > as > > > > > > the > > > > > > > > depth of the deepest possible OTN DP hierarchy, for > > example: > > > > > > > > > > > > > > > > > > typedef enum > > > > > > > > > { > > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high > order > > > */ > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM > and > > > make the > > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > > Digital > > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > > which had > > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > > long time > > > > > > ago. > > > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR > that > > > did not > > > > > > > > understand what the TS type meant did not try to > multiplex > > > its LO > > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > > commited > > > > > > to > > > > > > > using > > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > > OTN_HO or > > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, > then > > > the > > > > > > > latter > > > > > > > > is for backward compatibility and should be ignored if > > > OTN_LO, > > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > > 1.25 > > > TS > > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > > > can > > > be > > > > > > withdrawn. > > > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > > of > > > the > > > > > > LSP > > > > > > > > regardless of what goes on in the middle since that > > > determines what > > > > > > > can > > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > OTU3 > > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 > or > > > ODUj=3D3Df=3D > > > > lex > > > > > > > > even though the ODUk=3D3D2 at the next hop could not > directly > > > contain > > > > > > an ODU0. > > > > > > > > If the SHO Encoding Type is used, then it indicates that > > two > > > levels > > > > > > > of > > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > > 4328 > > > Switch > > > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > > > but > > > if > > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > > Along > > > > > > > > with the new Encoding Type new Signal Types for ODU0, > ODU4, > > > and > > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > > I'm > > > not > > > > > > > clear > > > > > > > > how in an FA it can be indicated that either type is > > > currently > > > > > > > > available (NE capable of both and hasn't committed to > > either > > > one > > > > > > > yet). > > > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of > messages > > > on this > > > > > > > > would indicate a huge controversy and I'm not getting it > > > (other > > > > > > than > > > > > > > a > > > > > > > > strong preference to rely on bytes/sec or on enumerated > > type > > > > > > fields). > > > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. > I'm > > > not sure > > > > > > > if > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > > framework, > > > > > > > > or other intent. Could someone (either draft) concisely > > > summarize > > > > > > > > the multiplexing restrictions in one place, including > > > restrictions > > > > > > > > on number of multiplexing layers at one LSR. That might > > > help. > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > > > Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] On > > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > > framework > > > > > > > > > > document before we can embark on any proposals to the > > > problem. > > > > > > I > > > > > > > am > > > > > > > > > > still not clear why do we have to deviate from the > > > general > > > > > > > approach > > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi- > layer > > > control > > > > > > > > > > IB>> plane, and > > > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > > > independent > > > > > > > paradigm > > > > > > > > > > of advertising of TE links, and there is no reason to > > > invent an > > > > > > > OTN > > > > > > > > > > specific ISCD. The combination of Switching > Capability > > > and > > > > > > > Encoding > > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > > multiplexing > > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > > link, > > > and, > > > > > > if > > > > > > > > > > this not sufficient, you have another reserved 16 > bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > > > >new TE-link > > > > > > > > to > > > > > > > > > > represent >the low-order ODUj bandwidth within the > > high- > > > order > > > > > > > > containers. > > > > > > > > > > This is simply >blowing up the solution to a very > > simple > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > > > IB>> possibility > > > to > > > > > > > create > > > > > > > > > > IB>> OTN > > > > > > > > > > hierarchies and constrain LO connections to HO > > > containers, one > > > > > > > > needs > > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among > authors > > > and > > > > > > > > > > other interested experts, and we think the proposal > > > described > > > > > > in > > > > > > > "draft- > > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] > draft > > > is more > > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > > needed for > > > > > > > > > > control plane, no matter how you encode the routing > > > > > > information. > > > > > > > > For > > > > > > > > > > TDM networks, you know the resource is allocated > based > > > > > > > > > > on > > > TS, > > > > > > so > > > > > > > > the > > > > > > > > > > available TS should be get or induced before creating > > > cross- > > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > > information, > > > > > > > I > > > > > > > > > > think you need go to the routing drafts (info model > and > > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > > encoding), > > > > > > you > > > > > > > > > > will find that one of your suggestions is adopted > > (i.e., > > > simply > > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > > ..., > > > ODU4 > > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > > > links) > > > as FA > > > > > > > for > > > > > > > > > > ODU1, you have to advertise a new TE link or put this > > FA > > > as a > > > > > > > > > > component link of an existing TE link (like > > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > > g709-framework@tools.ietf.org ccamp- > > > gmpls- > > > > > > > g709- > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > I believe there has been some off-line discussion > on > > > how to > > > > > > > > better > > > > > > > > > > > align the work with 4202. Use of common approaches > > is > > > of > > > > > > > course > > > > > > > > > > > one of the main objectives of *C*CAMP. I look > > forward > > > to > > > > > > > hearing > > > > > > > > > > > from the draft and discussion contributors on there > > > progress > > > > > > > > > > > on > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > > >> Hello, > > > > > > > > > > >> > > > > > > > > > > >> I have a comment and a question on Section > 3.1.2.1. > > > This > > > > > > > section > > > > > > > > > > >> describes the link-parameters that are required > for > > > OTN > > > > > > > service > > > > > > > > > > >> routing purposes. > > > > > > > > > > >> > > > > > > > > > > >> My comment is how are we going to advertise the > low- > > > order > > > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > > > >> For example, consider an > > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > > granularity > > > and > > > > > > > > > > >> then > > > > > > > > we > > > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > > > >> point > > > in > > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > > ODU2 > > > > > > > > > > >> services > > > > > > > and > > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services > (4 > > > ODU1s > > > > > > > > > > >> are contained over the ODU2). So it is obvious > from > > > this > > > > > > > > > > >> example > > > > > > > > that > > > > > > > > > > >> the number of time-slots available is different > > based > > > on the > > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > > >> How do we address this issue based on the approach > > > specified > > > > > > > in > > > > > > > > > > >> the > > > > > > > > > > draft? > > > > > > > > > > >> > > > > > > > > > > >> My other question is why not simply advertize the > > > available > > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances or > > > > > > > the > > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > > This > > > > > > > > > > >> approach seems to be more in-line with the general > > > approach > > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > > section > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > > ISCDs > > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > > additional > > > > > > > > > > >> benefit > > > > > > > > is > > > > > > > > > > >> that the advertisement is TS size independent and > > > hence will > > > > > > > > > > >> simplify the implementation. > > > > > > > > > > >> > > > > > > > > > > >> Regards > > > > > > > > > > >> > > > > > > > > > > >> Snigdho > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > From jdrake@juniper.net Thu Jul 22 10:37:50 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DF73A6887 for ; Thu, 22 Jul 2010 10:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpW7dccHP-BZ for ; Thu, 22 Jul 2010 10:37:35 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7ABD83A68DE for ; Thu, 22 Jul 2010 10:37:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTEiB2TvKaMLEAlOokiAyR8blqgt0VKK3@postini.com; Thu, 22 Jul 2010 10:37:45 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Jul 2010 10:34:36 -0700 From: John E Drake To: Snigdho Bardalai , "curtis@occnc.com" , "BELOTTI, SERGIO (SERGIO)" Date: Thu, 22 Jul 2010 10:34:35 -0700 Thread-Topic: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspEs4rfpzXbzHMSoS+YSwEHFKz6wAnrF6QAAQYHrAAADnzAAAAP8Aw Message-ID: <5E893DB832F57341992548CDBB3331639844B32DA5@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 11:45:10 +0200." <201007212024.o6LKOpGZ088530@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32D16@EMBX01-HQ.jnpr.net> <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE78AF@SV-EXDB1.infinera.com> In-Reply-To: <0DEA331C14C86B4CB8A3A2470AA14B0EA0FDCE78AF@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Igor Bryskin Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 17:37:51 -0000 Snigdho, I am sure there will be some details to work out, but it solves the specifi= c problem at hand in a general way that is consistent with the way MPLS/GMP= LS works. It is just adding detail in a specific case where more detail ma= y be useful. Thanks, John > -----Original Message----- > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > Sent: Thursday, July 22, 2010 10:28 AM > To: John E Drake; curtis@occnc.com; BELOTTI, SERGIO (SERGIO) > Cc: Daniele Ceccarelli; ccamp@ietf.org; Igor Bryskin > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > framework-01.txt >=20 > John >=20 > That is an alternative but because the size of the LSA grows with > number of components you could potentially have to limit the size of a > bundle or be ready to grow the LSA (in theory there is no limit) >=20 > Regards > Snigdho >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 22, 2010 10:21 AM > > To: John E Drake; curtis@occnc.com; BELOTTI, SERGIO (SERGIO) > > Cc: Daniele Ceccarelli; ccamp@ietf.org; Snigdho Bardalai; Igor > Bryskin > > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > Hi, > > > > I have a suggestion. > > > > Why don't we allow a node to optionally advertise the unreserved > > bandwidth for each of the component links in a bundle? This is a > > general, non-OTN, solution to this specific problem and it is > backwards > > compatible. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: John E Drake > > > Sent: Thursday, July 22, 2010 8:24 AM > > > To: 'curtis@occnc.com'; BELOTTI, SERGIO (SERGIO) > > > Cc: Daniele Ceccarelli; ccamp@ietf.org; Snigdho Bardalai; Igor > > Bryskin > > > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > Curtis, > > > > > > As I said last week, I think the existing RFC 4202/4203 design > works > > > just fine for unbundled links. > > > > > > For bundled links, due to bin packing, it is asserted that if one > > > advertised unreserved bandwidth by what I have been calling service > > > type (which in the OTN case equates to ODUj client rate), one can > get > > a > > > more accurate understanding of the state of the bundled link wrt > the > > > number of LSPs that could be established at each of the ODUj client > > > rates available at the time of advertisement. > > > > > > So, I think there are two questions. 1) Do we want to advertise > > > unreserved bandwidth by service type, and if so, do we want to > > > advertise it for all links or only for bundled links? > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, July 21, 2010 1:25 PM > > > > To: BELOTTI, SERGIO (SERGIO) > > > > Cc: curtis@occnc.com; Daniele Ceccarelli; ccamp@ietf.org; Snigdho > > > > Bardalai; Igor Bryskin; John E Drake > > > > Subject: Re: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework-01.txt > > > > > > > > > > > > In message > > > > > > m.alcatel-lucent.com> > > > > "BELOTTI, SERGIO (SERGIO)" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > Thanks for your comment. > > > > > As pointed out by Daniele you're right but the missing > > information > > > > > here is the real spatial allocation that raised in importance > > above > > > > > all in case of link bundling unless you constrain the > capability > > in > > > 1 > > > > > component link per TE-link, that would reduce value of this > very > > > > > important feature for scalability. > > > > > > > > > > > > Maybe I'm missing something (again). If so, please point out > what > > I > > > > missed. > > > > > > > > In link bundling the min LSP BW is the smallest LSP or TDM > > container > > > > supported. Any multiple of the min LSP is allowed. The max LSP > BW > > > is > > > > the largest LSP that can be accommodated (per priority). The max > > > > reservable BW (not max LSP bw) is the total size of the bundle, > > > > ignoring any reservations, and the reservable BW (in the Link TLV > > in > > > > RFC 3630) indicates how much capacity is still left. > > > > > > > > For bundles as per RFC 4201: > > > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > > > Bandwidth. For an unbundled link, the Maximum Bandwidth is > > > > defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a > > > > bundled link at priority p is defined to be the maximum of > the > > > > Maximum LSP Bandwidth at priority p of all of its component > > > links. > > > > The details of how Maximum LSP Bandwidth is carried in IS-IS > is > > > > given in [GMPLS-ISIS]. The details of how Maximum LSP > > Bandwidth > > > > is carried in OSPF is given in [GMPLS-OSPF]. > > > > > > > > This is consistent with RFC 4203 "Max LSP Bandwidth at priority > N" > > > > being reported in the ISCD. > > > > > > > > 3.8. Unreserved Bandwidth > > > > > > > > The unreserved bandwidth of a bundled link at priority p is > the > > > > sum of the unreserved bandwidths at priority p of all the > > > > component links associated with the bundled link. > > > > > > > > This goes in the Link TLV in the Unreserved Bandwidth sub-TLV > > defined > > > > in RFC 3630. > > > > > > > > That seems to me to completely cover link bundling with no > > > constraints > > > > on its capability and no need for one TE-link (FA) per compoent > > link. > > > > > > > > > > > > > About the last part > > > > > > > > > > [BTW- Lets please not talk about "ignorance and > > misunderstanding". > > > > > This is not simple obvious stuff and maybe none of us > > individually > > > > > knows everything about everything. Myself (all too obviously > > > > > sometimes) included.] > > > > > > > > > > I'm completely agree with you. > > > > > I know all that is not simple and obvious stuff for everyone. > > > > > My only two cents is just to highlight it is not always > possible > > > > > justify that different solution for SDH control plane with > > respect > > > > > what defined in RFC 4202/4203 are deployed, with a bad reading > of > > > > > these RFCs. > > > > > > > > > > > > We are defining new OTN functionality so software will need to > > > > change. If prior SONET implementations didn't get it right that > is > > > no > > > > reason to not get it right in defining the OTN extensions. > > > > > > > > > > > > > Best Regards > > > > > > > > > > Sergio > > > > > > > > > > > > Curtis > > > > > > > > > > > > > Sergio Belotti > > > > > > > > > > System Architecture > > > > > Optics Division-Terrestrial Optics Unit > > > > > ALCATEL-LUCENT > > > > > > > > > > +39 039 6863033 > > > > > +39 039 6863590 > > > > > > > > > > > > > > > -----Messaggio originale----- > > > > > Da: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Inviato: mercoled=EC 21 luglio 2010 1.36 > > > > > A: Igor Bryskin > > > > > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; > > Snigdho > > > > Bardalai > > > > > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > > framework-01.txt > > > > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > > > > exgen.atl.advaoptical.com> > > > > > Igor Bryskin writes: > > > > > > > > > > > > John, > > > > > > > > > > > > The point is that from ISCD you can not figure out how *many* > > > LSPs > > > > > > matching the ISCD you can accommodate on the link. Such > > > information > > > > is > > > > > > important in case of con-current routing (e.g. restoration > > after > > > > link > > > > > > failure). > > > > > > > > > > > > Igor > > > > > > > > > > Igor, Sergio, > > > > > > > > > > RFC 4203 (in 1. Introduction) > > > > > > > > > > The TE LSA, which is an opaque LSA with area flooding scope > > > > > [OSPF-TE], has only one top-level Type/Length/Value (TLV) > > > triplet > > > > > and has one or more nested sub-TLVs for extensibility. The > > > > > top-level TLV can take one of two values (1) Router Address > or > > > (2) > > > > > Link. In this document, we enhance the sub-TLVs for the > Link > > > TLV > > > > > in support of GMPLS. Specifically, we add the following > sub- > > > TLVs > > > > > to the Link TLV: > > > > > > > > > > [OSPF-TE] above is RFC 3630. > > > > > > > > > > RFC 3630 (in 2.4.2. Link TLV) > > > > > > > > > > The following sub-TLVs of the Link TLV are defined: > > > > > > > > > > 1 - Link type (1 octet) > > > > > 2 - Link ID (4 octets) > > > > > 3 - Local interface IP address (4 octets) > > > > > 4 - Remote interface IP address (4 octets) > > > > > 5 - Traffic engineering metric (4 octets) > > > > > 6 - Maximum bandwidth (4 octets) > > > > > 7 - Maximum reservable bandwidth (4 octets) > > > > > 8 - Unreserved bandwidth (32 octets) > > > > > 9 - Administrative group (4 octets) > > > > > > > > > > If you read on you find: > > > > > > > > > > The Maximum Reservable Bandwidth sub-TLV specifies the > maximum > > > > > bandwidth that may be reserved on this link, in this > > direction, > > > in > > > > > IEEE floating point format. Note that this may be greater > > than > > > > the > > > > > maximum bandwidth (in which case the link may be > > > oversubscribed). > > > > > > > > > > and > > > > > > > > > > The Unreserved Bandwidth sub-TLV specifies the amount of > > > bandwidth > > > > > not yet reserved at each of the eight priority levels in > IEEE > > > > > floating point format. The values correspond to the > bandwidth > > > > that > > > > > can be reserved with a setup priority of 0 through 7, > arranged > > > in > > > > > increasing order with priority 0 occurring at the start of > the > > > > sub- > > > > > TLV, and priority 7 at the end of the sub-TLV. [...] > > > > > > > > > > So the totals per link and per priority level are already there > > in > > > > the > > > > > base spec before the RFC 4203 *extensions* to RFC 3630 were > > added. > > > > > > > > > > That is how you figure out how many ODU0 you can add to your > > > existing > > > > > ODU2, and so on. > > > > > > > > > > [BTW- Lets please not talk about "ignorance and > > misunderstanding". > > > > > This is not simple obvious stuff and maybe none of us > > individually > > > > > knows everything about everything. Myself (all too obviously > > > > > sometimes) included.] > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Tuesday, July 20, 2010 1:13 PM > > > > > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework-01.txt > > > > > > > > > > > > >From RFC 4202: > > > > > > > > > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > > > > priority p > > > > > > is defined as the maximum bandwidth an LSP at priority p > > could > > > > > > reserve. Maximum LSP Bandwidth for a bundled link is > > defined > > > in > > > > > > [LINK-BUNDLE]. > > > > > > > > > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth > an > > > LSP > > > > > > could reserve. > > > > > > > > > > > > Typical values for the Minimum LSP Bandwidth and for the > > > Maximum > > > > LSP > > > > > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > > > > > > > > > On an interface having Standard SDH multiplexing, an LSP > at > > > > priority > > > > > > p could reserve any bandwidth allowed by the branch of the > > SDH > > > > > > hierarchy, with the leaf and the root of the branch being > > > > defined by > > > > > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > > > > priority > > > > > > p. > > > > > > > > > > > > On an interface having Arbitrary SDH multiplexing, an LSP > at > > > > priority > > > > > > p could reserve any bandwidth between the Minimum LSP > > > Bandwidth > > > > and > > > > > > the Maximum LSP Bandwidth at priority p, provided that the > > > > bandwidth > > > > > > reserved by the LSP is a multiple of the Minimum LSP > > > Bandwidth. > > > > > > > > > > > > >From RFC 4201: > > > > > > > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > > > Bandwidth. > > > > > > For an unbundled link, the Maximum Bandwidth is defined in > > > > > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled > > link > > > at > > > > > > priority p is defined to be the maximum of the Maximum LSP > > > > Bandwidth > > > > > > at priority p of all of its component links. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: John E Drake > > > > > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > > > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework-01.txt > > > > > > > > > > > > > > Snipped.... > > > > > > > > > > > > > > > > > > > > > > > I realized from someone in this thread (not from you) > this > > > was > > > > due > > > > > > > just > > > > > > > > to ignorance and misunderstanding of RFC 4202/4203 > > bandwidth > > > > > > > > advertisement for SDH . Anyway it is a fact that the > > > > alternative > > > > > > > format > > > > > > > > is used in many implementations "in field" for SDH > control > > > > plane. > > > > > > > > > > > > > > > > > > > > > > JD: As the person to whom I believe you are referring, I > > would > > > > suggest > > > > > > > that you actually read RFC 4202 and 4206. From IBryskin@advaoptical.com Thu Jul 22 11:12:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0703A6872 for ; Thu, 22 Jul 2010 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkbVMdO1xFrG for ; Thu, 22 Jul 2010 11:12:30 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 88D183A67AF for ; Thu, 22 Jul 2010 11:12:28 -0700 (PDT) Received: from muc-srv-exhub.advaoptical.com ([172.20.1.44]) by muc-vsrv-fsmail.advaoptical.com (8.14.3/8.14.3) with ESMTP id o6MICUpU023615 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 22 Jul 2010 20:12:30 +0200 Received: from MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Jul 2010 20:12:30 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.0.702.0; Thu, 22 Jul 2010 20:12:29 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 22 Jul 2010 14:12:26 -0400 From: Igor Bryskin To: John E Drake , "curtis@occnc.com" Date: Thu, 22 Jul 2010 14:12:22 -0400 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ5fxRxCX072TIeobRA5d6U+SgAm3o3gAADpouAAAY2NUAABJTKg Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD6917@atl-srv-exgen.atl.advaoptical.com> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639844B32D6C@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639844B32D6C@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-22_06:2010-07-22, 2010-07-22, 1970-01-01 signatures=0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 18:12:35 -0000 John, Things like in your last email you have said already several times in this = discussion alone. I noticed that you do that every time when you run out of= technical arguments (which in your case haven't changed a bit in 10 years = since early GMPLS years). Outside of technical arguments I do not care what you say. So why don't you= stop wasting your time and wait for several days until the f2f meeting wit= h the authors of the OTN work and CCAMP WG chair? You see, we have started = this discussion long time before you joined it, and the fact that it is sti= ll alive tells me that some people do care and get things which you may not= . Cheers, Igor -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, July 22, 2010 1:31 PM To: Igor Bryskin; curtis@occnc.com Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon= ; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai Zhang Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.tx= t Igor, This sounds like arm waving to me. To put things in perspective, let's rem= ember that you are the only person that is claiming that an operator wants = any of this. I have seen nothing to date in I-Ds pertaining to OTN that ha= s said any of this is needed. It is also completely contrary to the ITU mo= deling work for OTN, which uses a single flat network. (Of which you were,= until recently, completely unaware.) As a general rule, what should be advertised in the TE database is the type= of client signals that can be placed on a given link and not its server ch= aracteristics, which are more or less totally irrelevant. John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 22, 2010 10:13 AM > To: John E Drake; curtis@occnc.com > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > One reason is that ISCD allows for advertising of available LSP > bandwidth per priority level, which could change for the same OTN link > depending on role. Coloring won't allow to do so. Also, ISCD encoding > type allows for encoding the signal type, mux. capabilities, etc. > without introduction of OTN specific sub-TLVs. We want to help operator > to provision topologies, ID them and provide a simple way to constrain > a given LSP to be routed within a topology. ISCD gives you a simple > way to do so in a technology independent way, so that constraining LSP > to belong, say, OTN_LO or OTN_HO topology will not be different from > constraining LSP to belong to, say, ETH_EVPL layer. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 22, 2010 12:19 PM > To: curtis@occnc.com; Igor Bryskin > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > There is no reason to define multiple ISCD values for OTN networks in > order to constrain the path of a given LSP to only certain links. The > right way to do this is link colors (nee Administrative Groups, defined > in RFC 3630), which is what it was designed to do. > > I know this is a radical thought but why don't we use ISCD for what it > was designed to do? > > Thanks, > > John > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, July 21, 2010 2:38 PM > > To: Igor Bryskin > > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > > Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho > > Bardalai; Varma, Eve L (Eve); Fatai Zhang > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Igor, > > > > A current solution would be to use ML/MT extensions. A GMPLS E-NNI > > could also solve this problem if designed to isolate clients and > > resources in this manner. > > > > No hacking of RFC 4203 is needed. No (new) warts need to be added. > > > > Curtis > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > Hi Sergio, > > > > I'd like to run with you the following logic. > > > > 1. Suppose an operator after some planning decides to provision an > > infrastructure ODU and use it as a link. Why would he do so? One > > reason that I can think of is because he wants to build a virtual > > topology for a set of clients (with possibly himself as one from the > > set). The purpose of this topology, generally speaking, is: > > a) To be non-congruent with underlying topology (virtual or > > OTU/OCh). For example, to interconnect nodes that do not have a > common > > OTU/OCh link; > > b) To constrain said set of clients to resources of the topology > > (rather than, for example, to use OTU/OCh links directly). > > The question is how the operator can constrain the routing of the > ODUs > > for the clients from the set to the prepared for this purpose virtual > > topology within the flat ITU routing model? > > > > 2. Would you agree that the only reason why a TE link advertises an > > attribute is to be able to constrain a path computation based on the > > attribute? Your definitions of the OTN encoding types, for example, > > are: > > " .... > > o 8 - Lambda (Photonic) > > o 12 - G.709 ODUk (Digital Path) > > .... > > " > > > > which will give the operator an ability to route an OTN connection > > either straight over OTUs or over infrastructure ODUs with no regard > to > > the roles assigned to the links. Do you believe this would be > flexible > > enough for the operator? > > > > 3. What is it you can achieve with the suggested OTN routing that can > > not be achieved using multiple 4203 ISCDs? > > > > Thanks, > > Igor > > > > > > -----Original Message----- > > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > > lucent.com] > > Sent: Wednesday, July 21, 2010 10:59 AM > > To: Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele > Ceccarelli; > > John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); > > Fatai Zhang > > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > For point 1) and 2) I do not think we are so far. > > You're proposing a three-layer approach , we are aligned with what > ITU > > is proposing but we also have different roles in the network (lambda > > and sub-lambda) and than needs for constrains and policy in the > > network. > > The fact to have three switching capability to characterize the > > different roles in the same technology it seems to me a little > against > > the concept of switching capability itself. > > You could say that for packet there is already 4 PSC SC defined. But > > here we are in TDM , we have not label stacking capability. > > > > For point 3) and 4) , I do not discuss about the generality or not of > > the issue, but surely you cannot negate that the problem of spatial > > allocation is raised as soon as SDH CP has been implemented . Then > the > > same problem come in for OTN , and your intention to cope the issue > in > > a generic way with modifications of RFC 4203 is a good intention, but > > take also into account that also our proposed format can be generic > as > > soon as you change the signal types supported. > > > > You're right we need to discuss face to face but my perception is > that > > we ca be less far than you believe. > > > > Cheers > > > > Sergio > > > > Sergio Belotti > > > > System Architecture > > Optics Division-Terrestrial Optics Unit > > ALCATEL-LUCENT > > > > +39 039 6863033 > > +39 039 6863590 > > > > > > -----Messaggio originale----- > > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto > di > > Igor Bryskin > > Inviato: mercoled=EC 21 luglio 2010 15.51 > > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; > > Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > We need to discuss this face to face. The biggest disagreements with > > Daniele are: > > 1) I don't believe that flat routing model of a multi-layer OTN > network > > is correct. > > 2) I think each OTN role defines a separate topology of OTN links, > and > > there is a need to be able to constrain the routing of a given OTN > > connection to one or more (but not necessarily all) such topologies; > > 3) There is an issue in the current definitions of GMPLS OSPF > > extensions (RFC 4203), which does allow to specify multiple ISCDs but > > does not guide as to how the available bandwidth on the link is > > partitioned between ISCDs. This is a generic issue and should be > > resolved in a generic way; > > 4) Other than (3) we don't need any OTN or TDM specific CP machinery > > for TE and routing in OTN networks. Unless we see strong reasons to > the > > contrary we should not invent such machinery. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > Sent: Wednesday, July 21, 2010 8:30 AM > > To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; > > Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > I support this as well, of course. Whether this is a technology- > > specific extension of the ISCD format or a separate sub-TLV is a > > detail, however as Daniele points out many of the same considerations > > apply to both OTN and SONET/SDH. > > > > Lyndon > > > > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Daniele Ceccarelli > > Sent: Wednesday, July 21, 2010 12:49 AM > > To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > In other words it could be possible to define 3 Switching Cap (LO, HO > > and SHO) and put what we defined in the encoding draft into the > > Switching Capability-specific information of the ISCD. > > > > Something like this: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -- > > ---Switching Capability-specific information > > |0|1|2|3|4|5|6|7| T | | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ... ... > ... > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I still don't understand why we need partitioning the network in > three > > layers while just Sublamba and Full lambda distinction is enough > > (distinction supported advertising different signal types for full > > lambdas and sublambdas. > > > > Personally i still prefer advertising these pieces of information as > a > > separate sub-TLV (called OTN-ISCD subTLV in the draft but easily > > estensible to TDM-ISCD accordingly to > http://tools.ietf.org/html/draft- > > ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this > > could be a valid solution too. > > > > BR > > Daniele > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 23.02 > > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > Do you understand the quote from RFC4203: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Capability-specific information | > > | (variable) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > You can use the last field for OTN switchcap to advertise unresolved > > bandwidth available for the ISCD on per priority level. > > > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 4:35 PM > > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snipped... > > > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > > priority > > > level for every ISCD. > > > > JD: Igor, what part of my quote from RFC 4202 did you not > understand? > > You do not advertise unreserved bandwidth in the ISCD TLV. In > > particular, for TDM, what is advertised is the max and min bandwidth > > allowed for a single LSP. It was designed to produce a compact > > representation by taking advantage of the SDH/SONET hierarchy. > > > > Advertising a separate ISCD for each supported rate is allowed but > > wasteful. > > > > > > > > Igor > > > > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > > wro=3D > > > > te: > > > > > > > > > John, > > > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > > However if a > > > > > TE link advertises more than one ISCD (with each ISCD > containing > > > only max > > > > > lsp bandwidth per priority), it is necessary to indicate how > the > > > total li=3D > > > > nk > > > > > unreserved bandwidth is partitioned between several ISCDs. What > I > > > am > > > > > suggesting is instead of advertising the unreserved bandwidth > > > multiple ti=3D > > > > mes > > > > > (one per ISCD), indicate how the bandwidth is split between the > > > ISCDs: e.=3D > > > > g > > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > > > Igor. > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > > Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > Igor, > > > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so > the > > > issue o=3D > > > > f > > > > > partitioning unreserved bandwidth across multiple advertised > TDM > > > ISC TLVs=3D > > > > is > > > > > actually a non-issue. > > > > > > > > > > Unreserved bandwidth by priority has always been advertised > using > > > the MPL=3D > > > > S > > > > > sub-TLV. My point has been that we have never had a > requirement > > > (includi=3D > > > > ng > > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > > signal > > > type, =3D > > > > so > > > > > what is special about OTN? > > > > > > > > > > A further point would be that if we do decide that it is > > necessary > > > to > > > > > advertise unreserved bandwidth by signal type, it should be > done > > > > > in > > > a > > > > > general way and not in an OTN specific manner. (And in fact, > the > > > argumen=3D > > > > ts > > > > > that unreserved bandwidth by signal type needs to be > advertised, > > > such as =3D > > > > the > > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > It is a valid point, but the suggested solution is way too > > > expensive. > > > > > > All you need is a way to say how the advertised unreserved > > > bandwidth is > > > > > > partitioned between ISCDs in case the TE link advertisement > > > contains > > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > > bits out > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > > total > > > > > > unreserved bandwidth associated with the ISCD. Another way is > > to > > > use > > > > > > swicthcap specific extension. > > > > > > BTW: this is not an OTN specific issue, rather more general: > > any > > > time > > > > > > when a TE link advertises more than one ISCD (which is > > perfectly > > > Ok > > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, > > > > > > > > > > > > The need for unreserved resources advertised per signal type > is > > > the > > > > > > concurrent path computation. I'll answer quoting a section > from > > > the > > > > > > info-model draft, please have a look in particular to the > > > example: > > > > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > > and > > > per > > > > > > signal type in order to allow the correct functioning of > the > > > > > > restoration process. [RFC4203] only allows advertising > > > unreserved > > > > > > resources per priority, this leads not to know how many > LSPs > > > of a > > > > > > specific signal type can be restored. As example it is > > > possible to > > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > > > +------+ component link 1 +------+ > > > > > > | +------------------+ | > > > > > > | | component link 2 | | > > > > > > | N1 +------------------+ N2 | > > > > > > | | component link 3 | | > > > > > > | +------------------+ | > > > > > > +------+ +---+--+ > > > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component > links > > > with > > > > > > 32TSs available on the first one, 24TSs on the second, > 24TSs > > > on the > > > > > > third and supporting ODU2 and ODU3 signal types. The node > > > would > > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs > and > > > > > > a > > > MAX > > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > > network > > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > > > only > > > a > > > > > > single ODU3 can be set up and a crank-back would be > > > originated. In > > > > > > more complex network scenarios the number of crank-backs > can > > > be much > > > > > > higher." > > > > > > > > > > > > In other words, advertising the number of availble resources > > per > > > signal > > > > > > type does not avoid the possibility of cranck-back but > > decreases > > > it as > > > > > > much as possible. For sure a good routing prevents from > crank- > > > backs > > > > > > caused by the restoration of LSP originating on the same > > Ingress. > > > The > > > > > > cranck-backs due to the concurrent restoration of LSPs > > > originating on > > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > > > BR > > > > > > Daniele > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > In line > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, one more question. > > > > > > > > > > > > What about the unreserved bandwidth? > > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per > role > > > per > > > > > > (muxCap & signal type) you also need to advertise the > > unreserved > > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > > correct? > > > This > > > > > > also implies extending the unreserved bandwidth TLV so to > > create > > > a > > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > > subTLV). > > > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > > ISCD > > > per > > > > > > IB>> role per (muxCap & signal type) per priority level. > > > > > > IB>> However, > > > total > > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > > > IB>> unless > > > you > > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > > > Igor > > > > > > > > > > > > Thanks > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Understood... > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > sufficient > > > > > > > > > > > > > > That's exactly what I've been > > > > > > > trying to say all along. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Regards > > > > > > > Snigdho > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Daniele Ceccarelli > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an > ISCD > > > per > > > > > > role > > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > > signal > > > > > > type. > > > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > > switchCap =3D3D role; > > > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > > > reserved bits which can use for OTN specific > > > info > > > > > > in > > > > > > > > case we need it. > > > > > > > [SCB] I am yet to clearly understand what the role of > "role" > > > is, but > > > > > > > agree with your observation on the encode-type and the 16 > > > > > > > reserved-bits to further classify the switching > information. > > > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. > For > > > each > > > > > > role > > > > > > > > you would advertise just the unreserved bandwidth but you > > > wouldn't > > > > > > > know > > > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > > > LSP > > > (e.g. > > > > > > > 15 > > > > > > > > Gbps available on 3 component links: you advertise 45 > Gbps > > > > > > available > > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > > scalability > > > > > > > issues > > > > > > > > and the requirement of being able to bundle component > links > > > > > > together > > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > > ISDCs > > > > > > will > > > > > > > > provide a lot of flexibility: you can specify different > > > things > > > > > > (e.g. > > > > > > > > available bandwidth) for the same link in different > roles. > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > > sufficient? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Daniele > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Igor Bryskin > > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Fatai Zhang > > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > Thanks. > > > > > > > > I understand what you said. Therefore, we have added some > > > text to > > > > > > > > address the requirment in FWK document. However, we still > > > don't > > > > > > > > think that we need to extend ISC to meet the requirment. > > The > > > role > > > > > > of > > > > > > > > the > > > > > > > ODU > > > > > > > > can be get from the routing information implicitly. In > the > > > [draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > "Full > > > > > > Lambda" > > > > > > > is > > > > > > > > introduced. > > > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > > a) this requires OTN specific advertising and processing > > > rules; > > > > > > > > b) disallows topology separation in technology > independent > > > way > > > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > > container > > > > > > > does > > > > > > > > not change hop-by-hop (as some people seem to believe). > The > > > role is > > > > > > > > only meaningful on the ODU terminating nodes and > irrelevant > > > on > > > > > > > transit > > > > > > > > nodes. It is it's position in the hierarchy (but not > role) > > > that may > > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > > > AI1 > > > and > > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > > > can > > > only > > > > > > > support > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > > > with > > > the > > > > > > > role > > > > > > > > of Ho ODU level is requested, according to your > statement, > > > this > > > > > > > > conneciton will be allowed to be created. However, it > > should > > > not be > > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 > TE > > > link > > > > > > ends > > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and > OIN_LO_SC, > > > while > > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > > > path computation is constrained to the OTN_HO_SC > topology, > > > > > > > > B11 and > > > B12 > > > > > > TE > > > > > > > > links will > > > > > > > be > > > > > > > > disallowed, and the resulting path (if any) will not go > > > through B11 > > > > > > > and > > > > > > > > B12. If one circumvents the path computation by providing > > > > > > > > the > > > fully > > > > > > > > explicit path, the signaling should fail on node B for > the > > > same > > > > > > > reason: > > > > > > > > inconsistency of required (signaled) and supported (by > > local > > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify > that > > > the > > > > > > type > > > > > > > > indicated in the Switching Type parameter is supported > on > > > the > > > > > > > > corresponding incoming interface. If the type cannot be > > > > > > supported, > > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > > problem/Switching Type" indication." > > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Lou Berger" > ; > > > > > > > > ; > > > > > > > framework@tools.ietf.org> > > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > > ccamp@ietf.org; > > > > > > > draft- > > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > > > I think role does not equal switching capability. The > > > operators can > > > > > > > > define different roles depending on their policy and > > achieve > > > the > > > > > > > > role through different methods. However, for OTN > networks, > > > the > > > > > > > > containers (e.g., ODUk) all have the same switching > > > capablility > > > > > > > > (i.e., TDM > > > > > > > > switching) and I think we should reflect the natural > > > > > > characteristics > > > > > > > of > > > > > > > > links in the routing. In addition, if we extend the ISC, > it > > > will > > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > > overrides > > > > > > > > encoding type). > > > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > > views the > > > > > > > > network as a stack of topologies. Whether a given > topology > > > > > > > > is > > > real > > > > > > > > or virtual is of no importance. > > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > > > switching capability field (confusing name as it is) is a > > > > > > > > good way to > > > > > > describe > > > > > > > a > > > > > > > > layer in technology independent way, so that, say, MPLS- > TP- > > > >OTN_LO- > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > > stack of > > > > > > > > topologies that could be easily separated in technology > > > independent > > > > > > > way > > > > > > > > should path computation be constrained to particular one > or > > > > > > > > sub-stack of them. > > > > > > > > I think a good way to identify an OTN (virtual) topology > is > > > via > > > > > > > > (infrastructure) ODU container role of ODUs comprising > the > > > > > > topology. > > > > > > > > BTW IMO the role of an ODU container does not change hop- > > by- > > > hop (as > > > > > > > > some people seem to believe). The role is only meaningful > > on > > > the > > > > > > ODU > > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > > > it's > > > > > > > position > > > > > > > > in the hierarchy (but not role) that may change hop-by- > hop. > > > ODU's > > > > > > > role > > > > > > > > is the level of topology it is provisioned for and it is > > the > > > same > > > > > > > > for all ODUs that comprise the topology. For, example a > > user > > > may > > > > > > > provision > > > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > > > clients > > > to > > > > > > use > > > > > > > > the topology rather than any resources available on OTN > > > network. > > > > > > > > The bottom line: container's role is the same as the role > > of > > > > > > virtual > > > > > > > > topology the container is a part of and could be > advertised > > > as the > > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise > the > > > roles > > > > > > > > and muxing capabilities with the ISCD of RFC4202, could > you > > > > > > clarify? > > > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > > > IB>> etc.) > > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > > > In addition, could you clarify my questions in another > > email > > > > > > (copied > > > > > > > as > > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > 3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > > other. > > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > > hierarchy, > > > > > > which > > > > > > > is > > > > > > > > a mistake IMO. > > > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 > or > > > ODU3 as > > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if > there > > > > > > > > is > > > a > > > > > > OTU3 > > > > > > > link > > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > > (service > > > > > > > > over > > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > > this > > > case, > > > > > > > how > > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > > Level? > > > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important > on > > > the ODU > > > > > > > > terminating nodes (i.e. on either side of corresponding > > > link). What > > > > > > > > happens on the ODU transit nodes and its place in the > > > hierarchy on > > > > > > > the > > > > > > > > transit nodes are of no importance. My LO container can > be > > > carried > > > > > > > > by somebody else's LO container and can carry my client's > > LO > > > > > > container. > > > > > > > To > > > > > > > > some extent it is similar to MPLS LSP role: LSP always > has > > a > > > role > > > > > > > (e.g. > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > > along its > > > > > > > > path. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > 3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Fatai Zhang" > > > ; > > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org> > > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > > > I agree that there should be multiple OTN specific > encoding > > > types > > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > > capabilities > > > > > > > > rather than the link's role (i.e. level in the OTN > > hierarchy: > > > LO, > > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > > indicated > > > > > > > > with a separate switchcaps. I can give you several > reasons: > > > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have > different > > > roles; > > > > > > 2. > > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > > different > > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > > capabilities can > > > > > > > be > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > > ISCD is > > > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > > > type > > > will > > > > > > > look > > > > > > > > to CP as a separate layer, which is exactly how ITU > models > > > OTN > > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > > operator > > > > > > would > > > > > > > > want to constrain the routing of OTN connections to pre- > > > configured > > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > > sells to > > > > > > > the > > > > > > > > clients to one or more pre-configured LO topologies), > this > > > would be > > > > > > > > possible to do in a technology independent way. Suppose > an > > > instance > > > > > > > of > > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > > from > > > HO OTN > > > > > > > > links will be no different from the separation of WDM > links > > > from > > > > > > > OTUs. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > > To: Igor Bryskin > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger; > > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > In message > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > > srv- > > > > > > > > exgen.atl.advaoptical.com> > > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > > > many > > > as > > > > > > the > > > > > > > > depth of the deepest possible OTN DP hierarchy, for > > example: > > > > > > > > > > > > > > > > > > typedef enum > > > > > > > > > { > > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high > order > > > */ > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM > and > > > make the > > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > > Digital > > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > > which had > > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > > long time > > > > > > ago. > > > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR > that > > > did not > > > > > > > > understand what the TS type meant did not try to > multiplex > > > its LO > > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > > commited > > > > > > to > > > > > > > using > > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > > OTN_HO or > > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, > then > > > the > > > > > > > latter > > > > > > > > is for backward compatibility and should be ignored if > > > OTN_LO, > > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > > 1.25 > > > TS > > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > > > can > > > be > > > > > > withdrawn. > > > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > > of > > > the > > > > > > LSP > > > > > > > > regardless of what goes on in the middle since that > > > determines what > > > > > > > can > > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > OTU3 > > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 > or > > > ODUj=3D3Df=3D > > > > lex > > > > > > > > even though the ODUk=3D3D2 at the next hop could not > directly > > > contain > > > > > > an ODU0. > > > > > > > > If the SHO Encoding Type is used, then it indicates that > > two > > > levels > > > > > > > of > > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > > 4328 > > > Switch > > > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > > > but > > > if > > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > > Along > > > > > > > > with the new Encoding Type new Signal Types for ODU0, > ODU4, > > > and > > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > > I'm > > > not > > > > > > > clear > > > > > > > > how in an FA it can be indicated that either type is > > > currently > > > > > > > > available (NE capable of both and hasn't committed to > > either > > > one > > > > > > > yet). > > > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of > messages > > > on this > > > > > > > > would indicate a huge controversy and I'm not getting it > > > (other > > > > > > than > > > > > > > a > > > > > > > > strong preference to rely on bytes/sec or on enumerated > > type > > > > > > fields). > > > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. > I'm > > > not sure > > > > > > > if > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > > framework, > > > > > > > > or other intent. Could someone (either draft) concisely > > > summarize > > > > > > > > the multiplexing restrictions in one place, including > > > restrictions > > > > > > > > on number of multiplexing layers at one LSR. That might > > > help. > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > > > Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] On > > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > > framework > > > > > > > > > > document before we can embark on any proposals to the > > > problem. > > > > > > I > > > > > > > am > > > > > > > > > > still not clear why do we have to deviate from the > > > general > > > > > > > approach > > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi- > layer > > > control > > > > > > > > > > IB>> plane, and > > > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > > > independent > > > > > > > paradigm > > > > > > > > > > of advertising of TE links, and there is no reason to > > > invent an > > > > > > > OTN > > > > > > > > > > specific ISCD. The combination of Switching > Capability > > > and > > > > > > > Encoding > > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > > multiplexing > > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > > link, > > > and, > > > > > > if > > > > > > > > > > this not sufficient, you have another reserved 16 > bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > > > >new TE-link > > > > > > > > to > > > > > > > > > > represent >the low-order ODUj bandwidth within the > > high- > > > order > > > > > > > > containers. > > > > > > > > > > This is simply >blowing up the solution to a very > > simple > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > > > IB>> possibility > > > to > > > > > > > create > > > > > > > > > > IB>> OTN > > > > > > > > > > hierarchies and constrain LO connections to HO > > > containers, one > > > > > > > > needs > > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among > authors > > > and > > > > > > > > > > other interested experts, and we think the proposal > > > described > > > > > > in > > > > > > > "draft- > > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] > draft > > > is more > > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > > needed for > > > > > > > > > > control plane, no matter how you encode the routing > > > > > > information. > > > > > > > > For > > > > > > > > > > TDM networks, you know the resource is allocated > based > > > > > > > > > > on > > > TS, > > > > > > so > > > > > > > > the > > > > > > > > > > available TS should be get or induced before creating > > > cross- > > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > > information, > > > > > > > I > > > > > > > > > > think you need go to the routing drafts (info model > and > > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > > encoding), > > > > > > you > > > > > > > > > > will find that one of your suggestions is adopted > > (i.e., > > > simply > > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > > ..., > > > ODU4 > > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > > > links) > > > as FA > > > > > > > for > > > > > > > > > > ODU1, you have to advertise a new TE link or put this > > FA > > > as a > > > > > > > > > > component link of an existing TE link (like > > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > > g709-framework@tools.ietf.org ccamp- > > > gmpls- > > > > > > > g709- > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > I believe there has been some off-line discussion > on > > > how to > > > > > > > > better > > > > > > > > > > > align the work with 4202. Use of common approaches > > is > > > of > > > > > > > course > > > > > > > > > > > one of the main objectives of *C*CAMP. I look > > forward > > > to > > > > > > > hearing > > > > > > > > > > > from the draft and discussion contributors on there > > > progress > > > > > > > > > > > on > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > > >> Hello, > > > > > > > > > > >> > > > > > > > > > > >> I have a comment and a question on Section > 3.1.2.1. > > > This > > > > > > > section > > > > > > > > > > >> describes the link-parameters that are required > for > > > OTN > > > > > > > service > > > > > > > > > > >> routing purposes. > > > > > > > > > > >> > > > > > > > > > > >> My comment is how are we going to advertise the > low- > > > order > > > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > > > >> For example, consider an > > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > > granularity > > > and > > > > > > > > > > >> then > > > > > > > > we > > > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > > > >> point > > > in > > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > > ODU2 > > > > > > > > > > >> services > > > > > > > and > > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services > (4 > > > ODU1s > > > > > > > > > > >> are contained over the ODU2). So it is obvious > from > > > this > > > > > > > > > > >> example > > > > > > > > that > > > > > > > > > > >> the number of time-slots available is different > > based > > > on the > > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > > >> How do we address this issue based on the approach > > > specified > > > > > > > in > > > > > > > > > > >> the > > > > > > > > > > draft? > > > > > > > > > > >> > > > > > > > > > > >> My other question is why not simply advertize the > > > available > > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances or > > > > > > > the > > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > > This > > > > > > > > > > >> approach seems to be more in-line with the general > > > approach > > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > > section > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > > ISCDs > > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > > additional > > > > > > > > > > >> benefit > > > > > > > > is > > > > > > > > > > >> that the advertisement is TS size independent and > > > hence will > > > > > > > > > > >> simplify the implementation. > > > > > > > > > > >> > > > > > > > > > > >> Regards > > > > > > > > > > >> > > > > > > > > > > >> Snigdho > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > From jdrake@juniper.net Thu Jul 22 11:46:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A2B3A67AF for ; Thu, 22 Jul 2010 11:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7JFDH-5hI9X for ; Thu, 22 Jul 2010 11:46:44 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 208A03A6842 for ; Thu, 22 Jul 2010 11:46:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTEiSG25w0Ef4hGJWu2e4TTy0wTg/55An@postini.com; Thu, 22 Jul 2010 11:47:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 22 Jul 2010 11:44:57 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" Date: Thu, 22 Jul 2010 11:44:56 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ5fxRxCX072TIeobRA5d6U+SgAm3o3gAADpouAAAY2NUAABJTKgAADHJUA= Message-ID: <5E893DB832F57341992548CDBB3331639844B33077@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> <5E893DB832F57341992548CDBB3331639844B32D6C@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD6917@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD6917@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 18:46:49 -0000 Igor, Since when do questions about the legitimacy of requirements become non-tec= hnical arguments? Do you have any documentation that substantiates your assertions regarding = what carriers what need in order to deploy OTN networks? I haven't seen an= ything to date to support you, and as I said the OTU, which should have a p= retty good understanding of OTN and carrier requirements, is going in a tec= hnical direction completely opposite to yours. You are right that I have r= aised these points more than once. What you failed to mention is that you have never answered them. Regarding your comment about technical arguments, you have not actually mad= e a detailed technical proposal yourself. To date your technical proposal = amounts to "let's use multiple switching capabilities as it is a perfect so= lution". To what problem has also never crisply been answered. I would reiterate that arm waving seems to characterize your activities to = date on all of these points. It might be useful for you to try to put together a detailed technical prop= osal, along with a description of the problem or problems it solves, an exp= lanation of why it is so much better than other proposals ('practically per= fect' doesn't count), and some justification that this problem or problems = are of interest to anyone other than yourself. I also noticed that you didn't respond to my last paragraph. John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 22, 2010 11:12 AM > To: John E Drake; curtis@occnc.com > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > Things like in your last email you have said already several times in > this discussion alone. I noticed that you do that every time when you > run out of technical arguments (which in your case haven't changed a > bit in 10 years since early GMPLS years). > Outside of technical arguments I do not care what you say. So why don't > you stop wasting your time and wait for several days until the f2f > meeting with the authors of the OTN work and CCAMP WG chair? You see, > we have started this discussion long time before you joined it, and the > fact that it is still alive tells me that some people do care and get > things which you may not. > > Cheers, > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 22, 2010 1:31 PM > To: Igor Bryskin; curtis@occnc.com > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > This sounds like arm waving to me. To put things in perspective, let's > remember that you are the only person that is claiming that an operator > wants any of this. I have seen nothing to date in I-Ds pertaining to > OTN that has said any of this is needed. It is also completely > contrary to the ITU modeling work for OTN, which uses a single flat > network. (Of which you were, until recently, completely unaware.) > > As a general rule, what should be advertised in the TE database is the > type of client signals that can be placed on a given link and not its > server characteristics, which are more or less totally irrelevant. > > John > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: Thursday, July 22, 2010 10:13 AM > > To: John E Drake; curtis@occnc.com > > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); > Fatai > > Zhang > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > One reason is that ISCD allows for advertising of available LSP > > bandwidth per priority level, which could change for the same OTN > link > > depending on role. Coloring won't allow to do so. Also, ISCD encoding > > type allows for encoding the signal type, mux. capabilities, etc. > > without introduction of OTN specific sub-TLVs. We want to help > operator > > to provision topologies, ID them and provide a simple way to > constrain > > a given LSP to be routed within a topology. ISCD gives you a simple > > way to do so in a technology independent way, so that constraining > LSP > > to belong, say, OTN_LO or OTN_HO topology will not be different from > > constraining LSP to belong to, say, ETH_EVPL layer. > > > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, July 22, 2010 12:19 PM > > To: curtis@occnc.com; Igor Bryskin > > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); > Fatai > > Zhang > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > There is no reason to define multiple ISCD values for OTN networks in > > order to constrain the path of a given LSP to only certain links. > The > > right way to do this is link colors (nee Administrative Groups, > defined > > in RFC 3630), which is what it was designed to do. > > > > I know this is a radical thought but why don't we use ISCD for what > it > > was designed to do? > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, July 21, 2010 2:38 PM > > > To: Igor Bryskin > > > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; > Ong, > > > Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho > > > Bardalai; Varma, Eve L (Eve); Fatai Zhang > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > > > > Igor, > > > > > > A current solution would be to use ML/MT extensions. A GMPLS E-NNI > > > could also solve this problem if designed to isolate clients and > > > resources in this manner. > > > > > > No hacking of RFC 4203 is needed. No (new) warts need to be added. > > > > > > Curtis > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv- > > > exgen.atl.advaoptical.com> > > > Igor Bryskin writes: > > > > > > Hi Sergio, > > > > > > I'd like to run with you the following logic. > > > > > > 1. Suppose an operator after some planning decides to provision an > > > infrastructure ODU and use it as a link. Why would he do so? One > > > reason that I can think of is because he wants to build a virtual > > > topology for a set of clients (with possibly himself as one from > the > > > set). The purpose of this topology, generally speaking, is: > > > a) To be non-congruent with underlying topology (virtual or > > > OTU/OCh). For example, to interconnect nodes that do not have a > > common > > > OTU/OCh link; > > > b) To constrain said set of clients to resources of the > topology > > > (rather than, for example, to use OTU/OCh links directly). > > > The question is how the operator can constrain the routing of the > > ODUs > > > for the clients from the set to the prepared for this purpose > virtual > > > topology within the flat ITU routing model? > > > > > > 2. Would you agree that the only reason why a TE link advertises an > > > attribute is to be able to constrain a path computation based on > the > > > attribute? Your definitions of the OTN encoding types, for example, > > > are: > > > " .... > > > o 8 - Lambda (Photonic) > > > o 12 - G.709 ODUk (Digital Path) > > > .... > > > " > > > > > > which will give the operator an ability to route an OTN connection > > > either straight over OTUs or over infrastructure ODUs with no > regard > > to > > > the roles assigned to the links. Do you believe this would be > > flexible > > > enough for the operator? > > > > > > 3. What is it you can achieve with the suggested OTN routing that > can > > > not be achieved using multiple 4203 ISCDs? > > > > > > Thanks, > > > Igor > > > > > > > > > -----Original Message----- > > > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > > > lucent.com] > > > Sent: Wednesday, July 21, 2010 10:59 AM > > > To: Igor Bryskin > > > Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele > > Ceccarelli; > > > John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L > (Eve); > > > Fatai Zhang > > > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > > 01.txt > > > > > > Igor, > > > > > > For point 1) and 2) I do not think we are so far. > > > You're proposing a three-layer approach , we are aligned with what > > ITU > > > is proposing but we also have different roles in the network > (lambda > > > and sub-lambda) and than needs for constrains and policy in the > > > network. > > > The fact to have three switching capability to characterize the > > > different roles in the same technology it seems to me a little > > against > > > the concept of switching capability itself. > > > You could say that for packet there is already 4 PSC SC defined. > But > > > here we are in TDM , we have not label stacking capability. > > > > > > For point 3) and 4) , I do not discuss about the generality or not > of > > > the issue, but surely you cannot negate that the problem of spatial > > > allocation is raised as soon as SDH CP has been implemented . Then > > the > > > same problem come in for OTN , and your intention to cope the issue > > in > > > a generic way with modifications of RFC 4203 is a good intention, > but > > > take also into account that also our proposed format can be generic > > as > > > soon as you change the signal types supported. > > > > > > You're right we need to discuss face to face but my perception is > > that > > > we ca be less far than you believe. > > > > > > Cheers > > > > > > Sergio > > > > > > Sergio Belotti > > > > > > System Architecture > > > Optics Division-Terrestrial Optics Unit > > > ALCATEL-LUCENT > > > > > > +39 039 6863033 > > > +39 039 6863590 > > > > > > > > > -----Messaggio originale----- > > > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per > conto > > di > > > Igor Bryskin > > > Inviato: mercoled=EC 21 luglio 2010 15.51 > > > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; > > > Snigdho Bardalai > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > We need to discuss this face to face. The biggest disagreements > with > > > Daniele are: > > > 1) I don't believe that flat routing model of a multi-layer OTN > > network > > > is correct. > > > 2) I think each OTN role defines a separate topology of OTN links, > > and > > > there is a need to be able to constrain the routing of a given OTN > > > connection to one or more (but not necessarily all) such > topologies; > > > 3) There is an issue in the current definitions of GMPLS OSPF > > > extensions (RFC 4203), which does allow to specify multiple ISCDs > but > > > does not guide as to how the available bandwidth on the link is > > > partitioned between ISCDs. This is a generic issue and should be > > > resolved in a generic way; > > > 4) Other than (3) we don't need any OTN or TDM specific CP > machinery > > > for TE and routing in OTN networks. Unless we see strong reasons to > > the > > > contrary we should not invent such machinery. > > > > > > Cheers, > > > Igor > > > > > > -----Original Message----- > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > Sent: Wednesday, July 21, 2010 8:30 AM > > > To: Daniele Ceccarelli; Igor Bryskin; John E Drake; > curtis@occnc.com; > > > Snigdho Bardalai > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > I support this as well, of course. Whether this is a technology- > > > specific extension of the ISCD format or a separate sub-TLV is a > > > detail, however as Daniele points out many of the same > considerations > > > apply to both OTN and SONET/SDH. > > > > > > Lyndon > > > > > > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of Daniele Ceccarelli > > > Sent: Wednesday, July 21, 2010 12:49 AM > > > To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Igor, > > > > > > In other words it could be possible to define 3 Switching Cap (LO, > HO > > > and SHO) and put what we defined in the encoding draft into the > > > Switching Capability-specific information of the ISCD. > > > > > > Something like this: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Switching Cap | Encoding | Reserved > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 0 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 1 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 2 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 3 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 4 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 5 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 6 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 7 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > -- > > > ---Switching Capability-specific information > > > |0|1|2|3|4|5|6|7| T | | Reserved > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P0 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P1 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P2 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P3 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P4 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P5 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P6 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P7 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | > | > > > ... ... > > ... > > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P0 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P1 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P2 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P3 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P4 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P5 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P6 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Signal Type |F| Bandwidth @ P7 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > > > > I still don't understand why we need partitioning the network in > > three > > > layers while just Sublamba and Full lambda distinction is enough > > > (distinction supported advertising different signal types for full > > > lambdas and sublambdas. > > > > > > Personally i still prefer advertising these pieces of information > as > > a > > > separate sub-TLV (called OTN-ISCD subTLV in the draft but easily > > > estensible to TDM-ISCD accordingly to > > http://tools.ietf.org/html/draft- > > > ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but > this > > > could be a valid solution too. > > > > > > BR > > > Daniele > > > > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: marted=EC 20 luglio 2010 23.02 > > > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > John, > > > > > > Do you understand the quote from RFC4203: > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Switching Cap | Encoding | Reserved > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 0 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 1 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 2 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 3 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 4 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 5 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 6 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Max LSP Bandwidth at priority 7 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > | Switching Capability-specific information > | > > > | (variable) > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > > > > > > You can use the last field for OTN switchcap to advertise > unresolved > > > bandwidth available for the ISCD on per priority level. > > > > > > Igor > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Tuesday, July 20, 2010 4:35 PM > > > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > ccamp@ietf.org > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > framework- > > > 01.txt > > > > > > Snipped... > > > > > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > > > priority > > > > level for every ISCD. > > > > > > JD: Igor, what part of my quote from RFC 4202 did you not > > understand? > > > You do not advertise unreserved bandwidth in the ISCD TLV. In > > > particular, for TDM, what is advertised is the max and min > bandwidth > > > allowed for a single LSP. It was designed to produce a compact > > > representation by taking advantage of the SDH/SONET hierarchy. > > > > > > Advertising a separate ISCD for each supported rate is allowed but > > > wasteful. > > > > > > > > > > > Igor > > > > > > > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > > > wro=3D > > > > > te: > > > > > > > > > > > John, > > > > > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > > > However if a > > > > > > TE link advertises more than one ISCD (with each ISCD > > containing > > > > only max > > > > > > lsp bandwidth per priority), it is necessary to indicate how > > the > > > > total li=3D > > > > > nk > > > > > > unreserved bandwidth is partitioned between several ISCDs. > What > > I > > > > am > > > > > > suggesting is instead of advertising the unreserved bandwidth > > > > multiple ti=3D > > > > > mes > > > > > > (one per ISCD), indicate how the bandwidth is split between > the > > > > ISCDs: e.=3D > > > > > g > > > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > > > > > Igor. > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > > > Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > Igor, > > > > > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so > > the > > > > issue o=3D > > > > > f > > > > > > partitioning unreserved bandwidth across multiple advertised > > TDM > > > > ISC TLVs=3D > > > > > is > > > > > > actually a non-issue. > > > > > > > > > > > > Unreserved bandwidth by priority has always been advertised > > using > > > > the MPL=3D > > > > > S > > > > > > sub-TLV. My point has been that we have never had a > > requirement > > > > (includi=3D > > > > > ng > > > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > > > signal > > > > type, =3D > > > > > so > > > > > > what is special about OTN? > > > > > > > > > > > > A further point would be that if we do decide that it is > > > necessary > > > > to > > > > > > advertise unreserved bandwidth by signal type, it should be > > done > > > > > > in > > > > a > > > > > > general way and not in an OTN specific manner. (And in fact, > > the > > > > argumen=3D > > > > > ts > > > > > > that unreserved bandwidth by signal type needs to be > > advertised, > > > > such as =3D > > > > > the > > > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > bounces@ietf.org] > > On > > > > Behalf > > > > > > > Of Igor Bryskin > > > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > It is a valid point, but the suggested solution is way too > > > > expensive. > > > > > > > All you need is a way to say how the advertised unreserved > > > > bandwidth is > > > > > > > partitioned between ISCDs in case the TE link advertisement > > > > contains > > > > > > > several of them. One cheap way of doing so is to allocate > 3-4 > > > > bits out > > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction > of > > > > total > > > > > > > unreserved bandwidth associated with the ISCD. Another way > is > > > to > > > > use > > > > > > > swicthcap specific extension. > > > > > > > BTW: this is not an OTN specific issue, rather more > general: > > > any > > > > time > > > > > > > when a TE link advertises more than one ISCD (which is > > > perfectly > > > > Ok > > > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daniele Ceccarelli > > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor, > > > > > > > > > > > > > > The need for unreserved resources advertised per signal > type > > is > > > > the > > > > > > > concurrent path computation. I'll answer quoting a section > > from > > > > the > > > > > > > info-model draft, please have a look in particular to the > > > > example: > > > > > > > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per > priority > > > and > > > > per > > > > > > > signal type in order to allow the correct functioning of > > the > > > > > > > restoration process. [RFC4203] only allows advertising > > > > unreserved > > > > > > > resources per priority, this leads not to know how many > > LSPs > > > > of a > > > > > > > specific signal type can be restored. As example it is > > > > possible to > > > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > > > > > +------+ component link 1 +------+ > > > > > > > | +------------------+ | > > > > > > > | | component link 2 | | > > > > > > > | N1 +------------------+ N2 | > > > > > > > | | component link 3 | | > > > > > > > | +------------------+ | > > > > > > > +------+ +---+--+ > > > > > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component > > links > > > > with > > > > > > > 32TSs available on the first one, 24TSs on the second, > > 24TSs > > > > on the > > > > > > > third and supporting ODU2 and ODU3 signal types. The > node > > > > would > > > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs > > and > > > > > > > a > > > > MAX > > > > > > > LSP bandwidth equal to 32 TSs. In case of restoration > the > > > > network > > > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link > while > > > > > > > only > > > > a > > > > > > > single ODU3 can be set up and a crank-back would be > > > > originated. In > > > > > > > more complex network scenarios the number of crank-backs > > can > > > > be much > > > > > > > higher." > > > > > > > > > > > > > > In other words, advertising the number of availble > resources > > > per > > > > signal > > > > > > > type does not avoid the possibility of cranck-back but > > > decreases > > > > it as > > > > > > > much as possible. For sure a good routing prevents from > > crank- > > > > backs > > > > > > > caused by the restoration of LSP originating on the same > > > Ingress. > > > > The > > > > > > > cranck-backs due to the concurrent restoration of LSPs > > > > originating on > > > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > > > > > BR > > > > > > > Daniele > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > In line > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daniele Ceccarelli > > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor, one more question. > > > > > > > > > > > > > > What about the unreserved bandwidth? > > > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per > > role > > > > per > > > > > > > (muxCap & signal type) you also need to advertise the > > > unreserved > > > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > > > correct? > > > > This > > > > > > > also implies extending the unreserved bandwidth TLV so to > > > create > > > > a > > > > > > > corrispondence between the couples (ISCD-unreserved > bandwidth > > > > subTLV). > > > > > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > > > ISCD > > > > per > > > > > > > IB>> role per (muxCap & signal type) per priority level. > > > > > > > IB>> However, > > > > total > > > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > > > > IB>> unless > > > > you > > > > > > > IB>> see a compelling reason to the contrary (which I > don't) > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > Thanks > > > > > > > Daniele > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Understood... > > > > > > > > > > > > > > Regards > > > > > > > Snigdho > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > > > curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > > extensions > > > > > > > > (i.e. to further classify the information) will be > > sufficient > > > > > > > > > > > > > > > > That's exactly what I've been > > > > > > > > trying to say all along. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > > curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > Regards > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Daniele Ceccarelli > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an > > ISCD > > > > per > > > > > > > role > > > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > > > signal > > > > > > > type. > > > > > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > > > switchCap =3D3D role; > > > > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > > > > reserved bits which can use for OTN specific > > > > info > > > > > > > in > > > > > > > > > case we need it. > > > > > > > > [SCB] I am yet to clearly understand what the role of > > "role" > > > > is, but > > > > > > > > agree with your observation on the encode-type and the 16 > > > > > > > > reserved-bits to further classify the switching > > information. > > > > > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. > > For > > > > each > > > > > > > role > > > > > > > > > you would advertise just the unreserved bandwidth but > you > > > > wouldn't > > > > > > > > know > > > > > > > > > if such bandwidth is available for a certain type of > ODUj > > > > > > > > > LSP > > > > (e.g. > > > > > > > > 15 > > > > > > > > > Gbps available on 3 component links: you advertise 45 > > Gbps > > > > > > > available > > > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > > > scalability > > > > > > > > issues > > > > > > > > > and the requirement of being able to bundle component > > links > > > > > > > together > > > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, > several > > > > ISDCs > > > > > > > will > > > > > > > > > provide a lot of flexibility: you can specify different > > > > things > > > > > > > (e.g. > > > > > > > > > available bandwidth) for the same link in different > > roles. > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > > extensions > > > > > > > > (i.e. to further classify the information) will be > > > sufficient? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Daniele > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] > > > > On > > > > > > > > Behalf > > > > > > > > > Of Igor Bryskin > > > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] > > > > On > > > > > > > > Behalf > > > > > > > > > Of Fatai Zhang > > > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > I understand what you said. Therefore, we have added > some > > > > text to > > > > > > > > > address the requirment in FWK document. However, we > still > > > > don't > > > > > > > > > think that we need to extend ISC to meet the > requirment. > > > The > > > > role > > > > > > > of > > > > > > > > > the > > > > > > > > ODU > > > > > > > > > can be get from the routing information implicitly. In > > the > > > > [draft- > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > > "Full > > > > > > > Lambda" > > > > > > > > is > > > > > > > > > introduced. > > > > > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > > > a) this requires OTN specific advertising and > processing > > > > rules; > > > > > > > > > b) disallows topology separation in technology > > independent > > > > way > > > > > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > > > container > > > > > > > > does > > > > > > > > > not change hop-by-hop (as some people seem to believe). > > The > > > > role is > > > > > > > > > only meaningful on the ODU terminating nodes and > > irrelevant > > > > on > > > > > > > > transit > > > > > > > > > nodes. It is it's position in the hierarchy (but not > > role) > > > > that may > > > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, > Interfaces > > > > > > > > > AI1 > > > > and > > > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and > BI2 > > > > > > > > > can > > > > only > > > > > > > > support > > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection > ODU2 > > > > > > > > > with > > > > the > > > > > > > > role > > > > > > > > > of Ho ODU level is requested, according to your > > statement, > > > > this > > > > > > > > > conneciton will be allowed to be created. However, it > > > should > > > > not be > > > > > > > > > allowed because the ISC is not consistent along the > LSP. > > > > > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 > > TE > > > > link > > > > > > > ends > > > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and > > OIN_LO_SC, > > > > while > > > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If > the > > > > > > > > > path computation is constrained to the OTN_HO_SC > > topology, > > > > > > > > > B11 and > > > > B12 > > > > > > > TE > > > > > > > > > links will > > > > > > > > be > > > > > > > > > disallowed, and the resulting path (if any) will not go > > > > through B11 > > > > > > > > and > > > > > > > > > B12. If one circumvents the path computation by > providing > > > > > > > > > the > > > > fully > > > > > > > > > explicit path, the signaling should fail on node B for > > the > > > > same > > > > > > > > reason: > > > > > > > > > inconsistency of required (signaled) and supported (by > > > local > > > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify > > that > > > > the > > > > > > > type > > > > > > > > > indicated in the Switching Type parameter is supported > > on > > > > the > > > > > > > > > corresponding incoming interface. If the type cannot > be > > > > > > > supported, > > > > > > > > > the node MUST generate a PathErr message with a > "Routing > > > > > > > > > problem/Switching Type" indication." > > > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Igor Bryskin" > > > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho > > Bardalai" > > > > > > > > > ; "Lou Berger" > > ; > > > > > > > > > ; > > > > > > > > framework@tools.ietf.org> > > > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > > > ccamp@ietf.org; > > > > > > > > draft- > > > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > > > > > I think role does not equal switching capability. The > > > > operators can > > > > > > > > > define different roles depending on their policy and > > > achieve > > > > the > > > > > > > > > role through different methods. However, for OTN > > networks, > > > > the > > > > > > > > > containers (e.g., ODUk) all have the same switching > > > > capablility > > > > > > > > > (i.e., TDM > > > > > > > > > switching) and I think we should reflect the natural > > > > > > > characteristics > > > > > > > > of > > > > > > > > > links in the routing. In addition, if we extend the > ISC, > > it > > > > will > > > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > > > overrides > > > > > > > > > encoding type). > > > > > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, > it > > > > views the > > > > > > > > > network as a stack of topologies. Whether a given > > topology > > > > > > > > > is > > > > real > > > > > > > > > or virtual is of no importance. > > > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > > > > switching capability field (confusing name as it is) is > a > > > > > > > > > good way to > > > > > > > describe > > > > > > > > a > > > > > > > > > layer in technology independent way, so that, say, > MPLS- > > TP- > > > > >OTN_LO- > > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as > a > > > > stack of > > > > > > > > > topologies that could be easily separated in technology > > > > independent > > > > > > > > way > > > > > > > > > should path computation be constrained to particular > one > > or > > > > > > > > > sub-stack of them. > > > > > > > > > I think a good way to identify an OTN (virtual) > topology > > is > > > > via > > > > > > > > > (infrastructure) ODU container role of ODUs comprising > > the > > > > > > > topology. > > > > > > > > > BTW IMO the role of an ODU container does not change > hop- > > > by- > > > > hop (as > > > > > > > > > some people seem to believe). The role is only > meaningful > > > on > > > > the > > > > > > > ODU > > > > > > > > > terminating nodes and irrelevant on transit nodes. It > is > > > > > > > > > it's > > > > > > > > position > > > > > > > > > in the hierarchy (but not role) that may change hop-by- > > hop. > > > > ODU's > > > > > > > > role > > > > > > > > > is the level of topology it is provisioned for and it > is > > > the > > > > same > > > > > > > > > for all ODUs that comprise the topology. For, example a > > > user > > > > may > > > > > > > > provision > > > > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > > > > clients > > > > to > > > > > > > use > > > > > > > > > the topology rather than any resources available on OTN > > > > network. > > > > > > > > > The bottom line: container's role is the same as the > role > > > of > > > > > > > virtual > > > > > > > > > topology the container is a part of and could be > > advertised > > > > as the > > > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise > > the > > > > roles > > > > > > > > > and muxing capabilities with the ISCD of RFC4202, could > > you > > > > > > > clarify? > > > > > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > > > > IB>> etc.) > > > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > > > > > In addition, could you clarify my questions in another > > > email > > > > > > > (copied > > > > > > > > as > > > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > 3 > > > > D=3D3D=3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > =3D3D > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > > > other. > > > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in t= he > > > > hierarchy, > > > > > > > which > > > > > > > > is > > > > > > > > > a mistake IMO. > > > > > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 > > or > > > > ODU3 as > > > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if > > there > > > > > > > > > is > > > > a > > > > > > > OTU3 > > > > > > > > link > > > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > > > (service > > > > > > > > > over > > > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > > > this > > > > case, > > > > > > > > how > > > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > > > Level? > > > > > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important > > on > > > > the ODU > > > > > > > > > terminating nodes (i.e. on either side of corresponding > > > > link). What > > > > > > > > > happens on the ODU transit nodes and its place in the > > > > hierarchy on > > > > > > > > the > > > > > > > > > transit nodes are of no importance. My LO container can > > be > > > > carried > > > > > > > > > by somebody else's LO container and can carry my > client's > > > LO > > > > > > > container. > > > > > > > > To > > > > > > > > > some extent it is similar to MPLS LSP role: LSP always > > has > > > a > > > > role > > > > > > > > (e.g. > > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS > stack > > > > along its > > > > > > > > > path. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > 3 > > > > D=3D3D=3D > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > =3D3D > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Igor Bryskin" > > > > > > > > > To: > > > > > > > > > Cc: "John E Drake" ; "Snigdho > > Bardalai" > > > > > > > > > ; "Fatai Zhang" > > > > ; > > > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > > > > > gmpls- > > > > > > > > > g709-framework@tools.ietf.org> > > > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > > > > > I agree that there should be multiple OTN specific > > encoding > > > > types > > > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > > > capabilities > > > > > > > > > rather than the link's role (i.e. level in the OTN > > > hierarchy: > > > > LO, > > > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > > > indicated > > > > > > > > > with a separate switchcaps. I can give you several > > reasons: > > > > > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have > > different > > > > roles; > > > > > > > 2. > > > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > > > different > > > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > > > capabilities can > > > > > > > > be > > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN- > style > > > > ISCD is > > > > > > > > > required); 4. The combination of swicthcaps and > encoding > > > > > > > > > type > > > > will > > > > > > > > look > > > > > > > > > to CP as a separate layer, which is exactly how ITU > > models > > > > OTN > > > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > > > operator > > > > > > > would > > > > > > > > > want to constrain the routing of OTN connections to > pre- > > > > configured > > > > > > > > > topology with a specific role (e.g. constrain all ODUs > it > > > > sells to > > > > > > > > the > > > > > > > > > clients to one or more pre-configured LO topologies), > > this > > > > would be > > > > > > > > > possible to do in a technology independent way. Suppose > > an > > > > instance > > > > > > > > of > > > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > > > from > > > > HO OTN > > > > > > > > > links will be no different from the separation of WDM > > links > > > > from > > > > > > > > OTUs. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > > > To: Igor Bryskin > > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > > Berger; > > > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > > > framework@tools.ietf.org > > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > > g709- > > > > > > > > framework- > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > In message > > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > > > srv- > > > > > > > > > exgen.atl.advaoptical.com> > > > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: > as > > > > > > > > > > many > > > > as > > > > > > > the > > > > > > > > > depth of the deepest possible OTN DP hierarchy, for > > > example: > > > > > > > > > > > > > > > > > > > > typedef enum > > > > > > > > > > { > > > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown > */ > > > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > > > > > /*****/ > > > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order > */ > > > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high > > order > > > > */ > > > > > > > /*****/ > > > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM > > and > > > > make the > > > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for > G.709 > > > > Digital > > > > > > > > > Path layer and G.709 Optical Channel layer for 2009 > OTN, > > > > which had > > > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" > a > > > > long time > > > > > > > ago. > > > > > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR > > that > > > > did not > > > > > > > > > understand what the TS type meant did not try to > > multiplex > > > > its LO > > > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had > alraedy > > > > commited > > > > > > > to > > > > > > > > using > > > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > > > > > It could also be stated that if an LSR advertises > OTN_LO, > > > > OTN_HO or > > > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, > > then > > > > the > > > > > > > > latter > > > > > > > > > is for backward compatibility and should be ignored if > > > > OTN_LO, > > > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > > > 1.25 > > > > TS > > > > > > > > > granularity, then the corresponding G.709 Digital Path > FA > > > > > > > > > can > > > > be > > > > > > > withdrawn. > > > > > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each > end > > > of > > > > the > > > > > > > LSP > > > > > > > > > regardless of what goes on in the middle since that > > > > determines what > > > > > > > > can > > > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > > > OTU3 > > > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3= D0 > > or > > > > ODUj=3D3Df=3D > > > > > lex > > > > > > > > > even though the ODUk=3D3D2 at the next hop could not > > directly > > > > contain > > > > > > > an ODU0. > > > > > > > > > If the SHO Encoding Type is used, then it indicates > that > > > two > > > > levels > > > > > > > > of > > > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > > > 4328 > > > > Switch > > > > > > > > > Types currently don't include an ODUj or ODUk > distinction > > > > > > > > > but > > > > if > > > > > > > > > Encoding Type indicated LO or HO, that may not be > needed. > > > > Along > > > > > > > > > with the new Encoding Type new Signal Types for ODU0, > > ODU4, > > > > and > > > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition > but > > > I'm > > > > not > > > > > > > > clear > > > > > > > > > how in an FA it can be indicated that either type is > > > > currently > > > > > > > > > available (NE capable of both and hasn't committed to > > > either > > > > one > > > > > > > > yet). > > > > > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of > > messages > > > > on this > > > > > > > > > would indicate a huge controversy and I'm not getting > it > > > > (other > > > > > > > than > > > > > > > > a > > > > > > > > > strong preference to rely on bytes/sec or on enumerated > > > type > > > > > > > fields). > > > > > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. > > I'm > > > > not sure > > > > > > > > if > > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls- > g709- > > > > framework, > > > > > > > > > or other intent. Could someone (either draft) > concisely > > > > summarize > > > > > > > > > the multiplexing restrictions in one place, including > > > > restrictions > > > > > > > > > on number of multiplexing layers at one LSR. That > might > > > > help. > > > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > > > > Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > > bounces@ietf.org] On > > > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with > the > > > > framework > > > > > > > > > > > document before we can embark on any proposals to > the > > > > problem. > > > > > > > I > > > > > > > > am > > > > > > > > > > > still not clear why do we have to deviate from the > > > > general > > > > > > > > approach > > > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi- > > layer > > > > control > > > > > > > > > > > IB>> plane, and > > > > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > > > > independent > > > > > > > > paradigm > > > > > > > > > > > of advertising of TE links, and there is no reason > to > > > > invent an > > > > > > > > OTN > > > > > > > > > > > specific ISCD. The combination of Switching > > Capability > > > > and > > > > > > > > Encoding > > > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > > > multiplexing > > > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > > > link, > > > > and, > > > > > > > if > > > > > > > > > > > this not sufficient, you have another reserved 16 > > bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise > a > > > > > > > > > > > >new TE-link > > > > > > > > > to > > > > > > > > > > > represent >the low-order ODUj bandwidth within the > > > high- > > > > order > > > > > > > > > containers. > > > > > > > > > > > This is simply >blowing up the solution to a very > > > simple > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > > > > IB>> possibility > > > > to > > > > > > > > create > > > > > > > > > > > IB>> OTN > > > > > > > > > > > hierarchies and constrain LO connections to HO > > > > containers, one > > > > > > > > > needs > > > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709- > framework@tools.ietf.org > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among > > authors > > > > and > > > > > > > > > > > other interested experts, and we think the proposal > > > > described > > > > > > > in > > > > > > > > "draft- > > > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] > > draft > > > > is more > > > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > > > needed for > > > > > > > > > > > control plane, no matter how you encode the routing > > > > > > > information. > > > > > > > > > For > > > > > > > > > > > TDM networks, you know the resource is allocated > > based > > > > > > > > > > > on > > > > TS, > > > > > > > so > > > > > > > > > the > > > > > > > > > > > available TS should be get or induced before > creating > > > > cross- > > > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > > > information, > > > > > > > > I > > > > > > > > > > > think you need go to the routing drafts (info model > > and > > > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > > > encoding), > > > > > > > you > > > > > > > > > > > will find that one of your suggestions is adopted > > > (i.e., > > > > simply > > > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > > > ..., > > > > ODU4 > > > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > > > > links) > > > > as FA > > > > > > > > for > > > > > > > > > > > ODU1, you have to advertise a new TE link or put > this > > > FA > > > > as a > > > > > > > > > > > component link of an existing TE link (like > > > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > > > framework@tools.ietf.org > > > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > > > g709-framework@tools.ietf.org > ccamp- > > > > gmpls- > > > > > > > > g709- > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > I believe there has been some off-line discussion > > on > > > > how to > > > > > > > > > better > > > > > > > > > > > > align the work with 4202. Use of common > approaches > > > is > > > > of > > > > > > > > course > > > > > > > > > > > > one of the main objectives of *C*CAMP. I look > > > forward > > > > to > > > > > > > > hearing > > > > > > > > > > > > from the draft and discussion contributors on > there > > > > progress > > > > > > > > > > > > on > > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > > > >> Hello, > > > > > > > > > > > >> > > > > > > > > > > > >> I have a comment and a question on Section > > 3.1.2.1. > > > > This > > > > > > > > section > > > > > > > > > > > >> describes the link-parameters that are required > > for > > > > OTN > > > > > > > > service > > > > > > > > > > > >> routing purposes. > > > > > > > > > > > >> > > > > > > > > > > > >> My comment is how are we going to advertise the > > low- > > > > order > > > > > > > > > > > >> ODUj availability within a higher-order > container. > > > > > > > > > > > >> For example, consider an > > > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > > > granularity > > > > and > > > > > > > > > > > >> then > > > > > > > > > we > > > > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > > > > >> point > > > > in > > > > > > > > > > > >> time the OTU3 link has 12 time-slots available > for > > > > ODU2 > > > > > > > > > > > >> services > > > > > > > > and > > > > > > > > > > > >> up to 12+4 time-slots available for ODU1 > services > > (4 > > > > ODU1s > > > > > > > > > > > >> are contained over the ODU2). So it is obvious > > from > > > > this > > > > > > > > > > > >> example > > > > > > > > > that > > > > > > > > > > > >> the number of time-slots available is different > > > based > > > > on the > > > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > > > >> How do we address this issue based on the > approach > > > > specified > > > > > > > > in > > > > > > > > > > > >> the > > > > > > > > > > > draft? > > > > > > > > > > > >> > > > > > > > > > > > >> My other question is why not simply advertize > the > > > > available > > > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > > > instances or > > > > > > > > the > > > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > > > This > > > > > > > > > > > >> approach seems to be more in-line with the > general > > > > approach > > > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > > > section > > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows > multiple > > > > ISCDs > > > > > > > > > > > >> being advertised per VC rate for an SDH link. > The > > > > additional > > > > > > > > > > > >> benefit > > > > > > > > > is > > > > > > > > > > > >> that the advertisement is TS size independent > and > > > > hence will > > > > > > > > > > > >> simplify the implementation. > > > > > > > > > > > >> > > > > > > > > > > > >> Regards > > > > > > > > > > > >> > > > > > > > > > > > >> Snigdho > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > From jdrake@juniper.net Thu Jul 22 12:22:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C55D3A68A9 for ; Thu, 22 Jul 2010 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.284 X-Spam-Level: X-Spam-Status: No, score=-5.284 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-IkswbMrexF for ; Thu, 22 Jul 2010 12:21:56 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 0DD2E3A6856 for ; Thu, 22 Jul 2010 12:21:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTEiaW2FaJN98TAAkvSanfvhmiaDNo9H1@postini.com; Thu, 22 Jul 2010 12:22:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Jul 2010 12:20:08 -0700 From: John E Drake To: Igor Bryskin , "curtis@occnc.com" Date: Thu, 22 Jul 2010 12:20:06 -0700 Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt Thread-Index: AcspHQ5fxRxCX072TIeobRA5d6U+SgAm3o3gAADpouAABXujEA== Message-ID: <5E893DB832F57341992548CDBB3331639844B331C1@EMBX01-HQ.jnpr.net> References: Your message of "Wed, 21 Jul 2010 12:02:23 EDT." <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-exgen.atl.advaoptical.com> <201007212137.o6LLbjZr090069@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB3331639844B32B3E@EMBX01-HQ.jnpr.net> <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0DD68E9@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Varma, Eve L \(Eve\)" , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 19:22:01 -0000 Igor, I have a quick technical question. Functionally, in what way is a separate= ISCD value for each ODU container rate, which is what I think you are prop= osing, any different than a single ISCD value with link colors used to repr= esent the ODU container rate? John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Thursday, July 22, 2010 10:13 AM > To: John E Drake; curtis@occnc.com > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > John, > > One reason is that ISCD allows for advertising of available LSP > bandwidth per priority level, which could change for the same OTN link > depending on role. Coloring won't allow to do so. Also, ISCD encoding > type allows for encoding the signal type, mux. capabilities, etc. > without introduction of OTN specific sub-TLVs. We want to help operator > to provision topologies, ID them and provide a simple way to constrain > a given LSP to be routed within a topology. ISCD gives you a simple > way to do so in a technology independent way, so that constraining LSP > to belong, say, OTN_LO or OTN_HO topology will not be different from > constraining LSP to belong to, say, ETH_EVPL layer. > > Igor > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 22, 2010 12:19 PM > To: curtis@occnc.com; Igor Bryskin > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai > Zhang > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > 01.txt > > Igor, > > There is no reason to define multiple ISCD values for OTN networks in > order to constrain the path of a given LSP to only certain links. The > right way to do this is link colors (nee Administrative Groups, defined > in RFC 3630), which is what it was designed to do. > > I know this is a radical thought but why don't we use ISCD for what it > was designed to do? > > Thanks, > > John > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, July 21, 2010 2:38 PM > > To: Igor Bryskin > > Cc: BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho Bardalai; Ong, > > Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; Snigdho > > Bardalai; Varma, Eve L (Eve); Fatai Zhang > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > > > Igor, > > > > A current solution would be to use ML/MT extensions. A GMPLS E-NNI > > could also solve this problem if designed to isolate clients and > > resources in this manner. > > > > No hacking of RFC 4203 is needed. No (new) warts need to be added. > > > > Curtis > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv- > > exgen.atl.advaoptical.com> > > Igor Bryskin writes: > > > > Hi Sergio, > > > > I'd like to run with you the following logic. > > > > 1. Suppose an operator after some planning decides to provision an > > infrastructure ODU and use it as a link. Why would he do so? One > > reason that I can think of is because he wants to build a virtual > > topology for a set of clients (with possibly himself as one from the > > set). The purpose of this topology, generally speaking, is: > > a) To be non-congruent with underlying topology (virtual or > > OTU/OCh). For example, to interconnect nodes that do not have a > common > > OTU/OCh link; > > b) To constrain said set of clients to resources of the topology > > (rather than, for example, to use OTU/OCh links directly). > > The question is how the operator can constrain the routing of the > ODUs > > for the clients from the set to the prepared for this purpose virtual > > topology within the flat ITU routing model? > > > > 2. Would you agree that the only reason why a TE link advertises an > > attribute is to be able to constrain a path computation based on the > > attribute? Your definitions of the OTN encoding types, for example, > > are: > > " .... > > o 8 - Lambda (Photonic) > > o 12 - G.709 ODUk (Digital Path) > > .... > > " > > > > which will give the operator an ability to route an OTN connection > > either straight over OTUs or over infrastructure ODUs with no regard > to > > the roles assigned to the links. Do you believe this would be > flexible > > enough for the operator? > > > > 3. What is it you can achieve with the suggested OTN routing that can > > not be achieved using multiple 4203 ISCDs? > > > > Thanks, > > Igor > > > > > > -----Original Message----- > > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > > lucent.com] > > Sent: Wednesday, July 21, 2010 10:59 AM > > To: Igor Bryskin > > Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Daniele > Ceccarelli; > > John E Drake; curtis@occnc.com; Snigdho Bardalai; Varma, Eve L (Eve); > > Fatai Zhang > > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework- > > 01.txt > > > > Igor, > > > > For point 1) and 2) I do not think we are so far. > > You're proposing a three-layer approach , we are aligned with what > ITU > > is proposing but we also have different roles in the network (lambda > > and sub-lambda) and than needs for constrains and policy in the > > network. > > The fact to have three switching capability to characterize the > > different roles in the same technology it seems to me a little > against > > the concept of switching capability itself. > > You could say that for packet there is already 4 PSC SC defined. But > > here we are in TDM , we have not label stacking capability. > > > > For point 3) and 4) , I do not discuss about the generality or not of > > the issue, but surely you cannot negate that the problem of spatial > > allocation is raised as soon as SDH CP has been implemented . Then > the > > same problem come in for OTN , and your intention to cope the issue > in > > a generic way with modifications of RFC 4203 is a good intention, but > > take also into account that also our proposed format can be generic > as > > soon as you change the signal types supported. > > > > You're right we need to discuss face to face but my perception is > that > > we ca be less far than you believe. > > > > Cheers > > > > Sergio > > > > Sergio Belotti > > > > System Architecture > > Optics Division-Terrestrial Optics Unit > > ALCATEL-LUCENT > > > > +39 039 6863033 > > +39 039 6863590 > > > > > > -----Messaggio originale----- > > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto > di > > Igor Bryskin > > Inviato: mercoled=EC 21 luglio 2010 15.51 > > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; curtis@occnc.com; > > Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > We need to discuss this face to face. The biggest disagreements with > > Daniele are: > > 1) I don't believe that flat routing model of a multi-layer OTN > network > > is correct. > > 2) I think each OTN role defines a separate topology of OTN links, > and > > there is a need to be able to constrain the routing of a given OTN > > connection to one or more (but not necessarily all) such topologies; > > 3) There is an issue in the current definitions of GMPLS OSPF > > extensions (RFC 4203), which does allow to specify multiple ISCDs but > > does not guide as to how the available bandwidth on the link is > > partitioned between ISCDs. This is a generic issue and should be > > resolved in a generic way; > > 4) Other than (3) we don't need any OTN or TDM specific CP machinery > > for TE and routing in OTN networks. Unless we see strong reasons to > the > > contrary we should not invent such machinery. > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > Sent: Wednesday, July 21, 2010 8:30 AM > > To: Daniele Ceccarelli; Igor Bryskin; John E Drake; curtis@occnc.com; > > Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > I support this as well, of course. Whether this is a technology- > > specific extension of the ISCD format or a separate sub-TLV is a > > detail, however as Daniele points out many of the same considerations > > apply to both OTN and SONET/SDH. > > > > Lyndon > > > > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Daniele Ceccarelli > > Sent: Wednesday, July 21, 2010 12:49 AM > > To: Igor Bryskin; John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: ccamp@ietf.org; Snigdho Bardalai > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Igor, > > > > In other words it could be possible to define 3 Switching Cap (LO, HO > > and SHO) and put what we defined in the encoding draft into the > > Switching Capability-specific information of the ISCD. > > > > Something like this: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -- > > ---Switching Capability-specific information > > |0|1|2|3|4|5|6|7| T | | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ... ... > ... > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Signal Type |F| Bandwidth @ P7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I still don't understand why we need partitioning the network in > three > > layers while just Sublamba and Full lambda distinction is enough > > (distinction supported advertising different signal types for full > > lambdas and sublambdas. > > > > Personally i still prefer advertising these pieces of information as > a > > separate sub-TLV (called OTN-ISCD subTLV in the draft but easily > > estensible to TDM-ISCD accordingly to > http://tools.ietf.org/html/draft- > > ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this > > could be a valid solution too. > > > > BR > > Daniele > > > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: marted=EC 20 luglio 2010 23.02 > > To: John E Drake; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > John, > > > > Do you understand the quote from RFC4203: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Cap | Encoding | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 2 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 3 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 5 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 6 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max LSP Bandwidth at priority 7 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Switching Capability-specific information | > > | (variable) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > You can use the last field for OTN switchcap to advertise unresolved > > bandwidth available for the ISCD on per priority level. > > > > Igor > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Tuesday, July 20, 2010 4:35 PM > > To: Igor Bryskin; curtis@occnc.com; Snigdho Bardalai > > Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; ccamp@ietf.org > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > framework- > > 01.txt > > > > Snipped... > > > > > IDSC sub-TLV and you can specify the unreserved bandwidth per > > priority > > > level for every ISCD. > > > > JD: Igor, what part of my quote from RFC 4202 did you not > understand? > > You do not advertise unreserved bandwidth in the ISCD TLV. In > > particular, for TDM, what is advertised is the max and min bandwidth > > allowed for a single LSP. It was designed to produce a compact > > representation by taking advantage of the SDH/SONET hierarchy. > > > > Advertising a separate ISCD for each supported rate is allowed but > > wasteful. > > > > > > > > Igor > > > > > > > > > > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin > > > wro=3D > > > > te: > > > > > > > > > John, > > > > > > > > > > I totally agree with you. It is absolutely non OTN specific. > > > However if a > > > > > TE link advertises more than one ISCD (with each ISCD > containing > > > only max > > > > > lsp bandwidth per priority), it is necessary to indicate how > the > > > total li=3D > > > > nk > > > > > unreserved bandwidth is partitioned between several ISCDs. What > I > > > am > > > > > suggesting is instead of advertising the unreserved bandwidth > > > multiple ti=3D > > > > mes > > > > > (one per ISCD), indicate how the bandwidth is split between the > > > ISCDs: e.=3D > > > > g > > > > > ISCD1 75%, ISCD2 25%. > > > > > > > > > > Igor. > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 11:54 AM > > > > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai > > > Zhang; > > > > > curtis@occnc.com > > > > > Cc: ccamp@ietf.org > > > > > Subject: RE: [CCAMP] Comment on > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > Igor, > > > > > > > > > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so > the > > > issue o=3D > > > > f > > > > > partitioning unreserved bandwidth across multiple advertised > TDM > > > ISC TLVs=3D > > > > is > > > > > actually a non-issue. > > > > > > > > > > Unreserved bandwidth by priority has always been advertised > using > > > the MPL=3D > > > > S > > > > > sub-TLV. My point has been that we have never had a > requirement > > > (includi=3D > > > > ng > > > > > SDH/SONET) in the past to advertise unreserved bandwidth by > > signal > > > type, =3D > > > > so > > > > > what is special about OTN? > > > > > > > > > > A further point would be that if we do decide that it is > > necessary > > > to > > > > > advertise unreserved bandwidth by signal type, it should be > done > > > > > in > > > a > > > > > general way and not in an OTN specific manner. (And in fact, > the > > > argumen=3D > > > > ts > > > > > that unreserved bandwidth by signal type needs to be > advertised, > > > such as =3D > > > > the > > > > > latest e-mail from Curtis, are not OTN specific.) > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > > > Behalf > > > > > > Of Igor Bryskin > > > > > > Sent: Tuesday, July 20, 2010 8:21 AM > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > It is a valid point, but the suggested solution is way too > > > expensive. > > > > > > All you need is a way to say how the advertised unreserved > > > bandwidth is > > > > > > partitioned between ISCDs in case the TE link advertisement > > > contains > > > > > > several of them. One cheap way of doing so is to allocate 3-4 > > > bits out > > > > > > of the ISCD sub-TLV reserved bits to indicate the fraction of > > > total > > > > > > unreserved bandwidth associated with the ISCD. Another way is > > to > > > use > > > > > > swicthcap specific extension. > > > > > > BTW: this is not an OTN specific issue, rather more general: > > any > > > time > > > > > > when a TE link advertises more than one ISCD (which is > > perfectly > > > Ok > > > > > > according to 4203) you'll have the same problem. > > > > > > > > > > > > Igor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 10:57 AM > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, > > > > > > > > > > > > The need for unreserved resources advertised per signal type > is > > > the > > > > > > concurrent path computation. I'll answer quoting a section > from > > > the > > > > > > info-model draft, please have a look in particular to the > > > example: > > > > > > > > > > > > > > > > > > " Unreserved resources need to be advertised per priority > > and > > > per > > > > > > signal type in order to allow the correct functioning of > the > > > > > > restoration process. [RFC4203] only allows advertising > > > unreserved > > > > > > resources per priority, this leads not to know how many > LSPs > > > of a > > > > > > specific signal type can be restored. As example it is > > > possible to > > > > > > consider the scenario depicted in the following figure. > > > > > > > > > > > > +------+ component link 1 +------+ > > > > > > | +------------------+ | > > > > > > | | component link 2 | | > > > > > > | N1 +------------------+ N2 | > > > > > > | | component link 3 | | > > > > > > | +------------------+ | > > > > > > +------+ +---+--+ > > > > > > > > > > > > Suppose to have a TE link comprising 3 ODU3 component > links > > > with > > > > > > 32TSs available on the first one, 24TSs on the second, > 24TSs > > > on the > > > > > > third and supporting ODU2 and ODU3 signal types. The node > > > would > > > > > > advertise a TE link unreserved bandwidth equal to 80 TSs > and > > > > > > a > > > MAX > > > > > > LSP bandwidth equal to 32 TSs. In case of restoration the > > > network > > > > > > could try to restore 2 ODU3 (64TSs) in such TE-link while > > > > > > only > > > a > > > > > > single ODU3 can be set up and a crank-back would be > > > originated. In > > > > > > more complex network scenarios the number of crank-backs > can > > > be much > > > > > > higher." > > > > > > > > > > > > In other words, advertising the number of availble resources > > per > > > signal > > > > > > type does not avoid the possibility of cranck-back but > > decreases > > > it as > > > > > > much as possible. For sure a good routing prevents from > crank- > > > backs > > > > > > caused by the restoration of LSP originating on the same > > Ingress. > > > The > > > > > > cranck-backs due to the concurrent restoration of LSPs > > > originating on > > > > > > different ingress nodes cannot be avoided. > > > > > > > > > > > > BR > > > > > > Daniele > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > Sent: marted=3DEC 20 luglio 2010 16.16 > > > > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > In line > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniele Ceccarelli > > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > Sent: Tuesday, July 20, 2010 4:32 AM > > > > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang; > > > > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Igor, one more question. > > > > > > > > > > > > What about the unreserved bandwidth? > > > > > > If you're advertising the max lsp bandwidth by 1 ISCD per > role > > > per > > > > > > (muxCap & signal type) you also need to advertise the > > unreserved > > > > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, > > correct? > > > This > > > > > > also implies extending the unreserved bandwidth TLV so to > > create > > > a > > > > > > corrispondence between the couples (ISCD-unreserved bandwidth > > > subTLV). > > > > > > > > > > > > IB>> Agree that max lsp bandwidth should be advertised by 1 > > ISCD > > > per > > > > > > IB>> role per (muxCap & signal type) per priority level. > > > > > > IB>> However, > > > total > > > > > > IB>> unreserved bandwidth IMO is OK to share between roles > > > > > > IB>> unless > > > you > > > > > > IB>> see a compelling reason to the contrary (which I don't) > > > > > > > > > > > > Igor > > > > > > > > > > > > Thanks > > > > > > Daniele > > > > > > > > > > > > -----Original Message----- > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > Sent: luned=3DEC 19 luglio 2010 17.48 > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > Cc: ccamp@ietf.org > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709- > > > framework- > > > > > > 01.txt > > > > > > > > > > > > Understood... > > > > > > > > > > > > Regards > > > > > > Snigdho > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > Sent: Monday, July 19, 2010 8:46 AM > > > > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang; > > > > > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > sufficient > > > > > > > > > > > > > > That's exactly what I've been > > > > > > > trying to say all along. > > > > > > > > > > > > > > Cheers, > > > > > > > Igor > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > > > > > > > Sent: Monday, July 19, 2010 11:31 AM > > > > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang; > > > curtis@occnc.com > > > > > > > Cc: ccamp@ietf.org > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > g709- > > > > > > framework- > > > > > > > 01.txt > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Regards > > > > > > > Snigdho > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > > > > > Sent: Monday, July 19, 2010 7:43 AM > > > > > > > > To: Daniele Ceccarelli; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Daniele, > > > > > > > > > > > > > > > > Please, see in line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Daniele Ceccarelli > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > > > > Sent: Monday, July 19, 2010 10:31 AM > > > > > > > > To: Igor Bryskin; Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > I didn't understand if you're proposing to (a) send an > ISCD > > > per > > > > > > role > > > > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per > > > signal > > > > > > type. > > > > > > > > > > > > > > > > IB>> in ISCD: > > > > > > > > switchCap =3D3D role; > > > > > > > > encodeType =3D3D muxCap & signal type; We also have 16 > > > > > > > > reserved bits which can use for OTN specific > > > info > > > > > > in > > > > > > > > case we need it. > > > > > > > [SCB] I am yet to clearly understand what the role of > "role" > > > is, but > > > > > > > agree with your observation on the encode-type and the 16 > > > > > > > reserved-bits to further classify the switching > information. > > > > > > > > > > > > > > > > In case (a) you're still missing a lot of information. > For > > > each > > > > > > role > > > > > > > > you would advertise just the unreserved bandwidth but you > > > wouldn't > > > > > > > know > > > > > > > > if such bandwidth is available for a certain type of ODUj > > > > > > > > LSP > > > (e.g. > > > > > > > 15 > > > > > > > > Gbps available on 3 component links: you advertise 45 > Gbps > > > > > > available > > > > > > > > but no ODU3 can be set up on such TE link). > > > > > > > > > > > > > > > > In case (b) the number of ISCDs would cause serious > > > scalability > > > > > > > issues > > > > > > > > and the requirement of being able to bundle component > links > > > > > > together > > > > > > > > wouldn't be satisfied. > > > > > > > > > > > > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several > > > ISDCs > > > > > > will > > > > > > > > provide a lot of flexibility: you can specify different > > > things > > > > > > (e.g. > > > > > > > > available bandwidth) for the same link in different > roles. > > > > > > > [SCB] Are you saying the ISCD as defined today with minor > > > extensions > > > > > > > (i.e. to further classify the information) will be > > sufficient? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Daniele > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Igor Bryskin > > > > > > > > Sent: luned=3DEC 19 luglio 2010 15.40 > > > > > > > > To: Fatai Zhang; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Fatai, > > > > > > > > > > > > > > > > Please, see my responses on-line. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > bounces@ietf.org] > > > On > > > > > > > Behalf > > > > > > > > Of Fatai Zhang > > > > > > > > Sent: Sunday, July 18, 2010 10:49 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor, > > > > > > > > > > > > > > > > Thanks. > > > > > > > > I understand what you said. Therefore, we have added some > > > text to > > > > > > > > address the requirment in FWK document. However, we still > > > don't > > > > > > > > think that we need to extend ISC to meet the requirment. > > The > > > role > > > > > > of > > > > > > > > the > > > > > > > ODU > > > > > > > > can be get from the routing information implicitly. In > the > > > [draft- > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of > > "Full > > > > > > Lambda" > > > > > > > is > > > > > > > > introduced. > > > > > > > > > > > > > > > > IB>> This is possible, however: > > > > > > > > a) this requires OTN specific advertising and processing > > > rules; > > > > > > > > b) disallows topology separation in technology > independent > > > way > > > > > > > > > > > > > > > > A quick question on your statement: "the role of an ODU > > > container > > > > > > > does > > > > > > > > not change hop-by-hop (as some people seem to believe). > The > > > role is > > > > > > > > only meaningful on the ODU terminating nodes and > irrelevant > > > on > > > > > > > transit > > > > > > > > nodes. It is it's position in the hierarchy (but not > role) > > > that may > > > > > > > > change hop-by-hop. " > > > > > > > > > > > > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C, Interfaces > > > > > > > > AI1 > > > and > > > > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2 > > > > > > > > can > > > only > > > > > > > support > > > > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2 > > > > > > > > with > > > the > > > > > > > role > > > > > > > > of Ho ODU level is requested, according to your > statement, > > > this > > > > > > > > conneciton will be allowed to be created. However, it > > should > > > not be > > > > > > > > allowed because the ISC is not consistent along the LSP. > > > > > > > > > > > > > > > > IB>> No, your understanding is not correct. A11 and C11 > TE > > > link > > > > > > ends > > > > > > > > will be advertised with two ISCDs: OTN_HO_SC and > OIN_LO_SC, > > > while > > > > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the > > > > > > > > path computation is constrained to the OTN_HO_SC > topology, > > > > > > > > B11 and > > > B12 > > > > > > TE > > > > > > > > links will > > > > > > > be > > > > > > > > disallowed, and the resulting path (if any) will not go > > > through B11 > > > > > > > and > > > > > > > > B12. If one circumvents the path computation by providing > > > > > > > > the > > > fully > > > > > > > > explicit path, the signaling should fail on node B for > the > > > same > > > > > > > reason: > > > > > > > > inconsistency of required (signaled) and supported (by > > local > > > > > > > > interfaces) switchcap. > > > > > > > > > > > > > > > > Please see the text from RFC3473: "Nodes MUST verify > that > > > the > > > > > > type > > > > > > > > indicated in the Switching Type parameter is supported > on > > > the > > > > > > > > corresponding incoming interface. If the type cannot be > > > > > > supported, > > > > > > > > the node MUST generate a PathErr message with a "Routing > > > > > > > > problem/Switching Type" indication." > > > > > > > > IB>> Indeed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: "Fatai Zhang" ; > > > > > > > > > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Lou Berger" > ; > > > > > > > > ; > > > > > > > framework@tools.ietf.org> > > > > > > > > Sent: Friday, July 16, 2010 12:34 AM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Fatai, > > > > > > > > Please, see my answers in line. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > Sent: Wednesday, July 14, 2010 9:52 PM > > > > > > > > To: Igor Bryskin; curtis@occnc.com > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger; > > > ccamp@ietf.org; > > > > > > > draft- > > > > > > > > ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > Hi Igor and all, > > > > > > > > > > > > > > > > Thanks for all your comments. > > > > > > > > > > > > > > > > I think role does not equal switching capability. The > > > operators can > > > > > > > > define different roles depending on their policy and > > achieve > > > the > > > > > > > > role through different methods. However, for OTN > networks, > > > the > > > > > > > > containers (e.g., ODUk) all have the same switching > > > capablility > > > > > > > > (i.e., TDM > > > > > > > > switching) and I think we should reflect the natural > > > > > > characteristics > > > > > > > of > > > > > > > > links in the routing. In addition, if we extend the ISC, > it > > > will > > > > > > > > make the encoding type lose its' own meaning(ie., ISC > > > overrides > > > > > > > > encoding type). > > > > > > > > > > > > > > > > IB>> When a GMPLS CP instance controls several layers, it > > > views the > > > > > > > > network as a stack of topologies. Whether a given > topology > > > > > > > > is > > > real > > > > > > > > or virtual is of no importance. > > > > > > > > The GMPLS ISCD link sub-tlv and, in particular, its > > > > > > > > switching capability field (confusing name as it is) is a > > > > > > > > good way to > > > > > > describe > > > > > > > a > > > > > > > > layer in technology independent way, so that, say, MPLS- > TP- > > > >OTN_LO- > > > > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a > > > stack of > > > > > > > > topologies that could be easily separated in technology > > > independent > > > > > > > way > > > > > > > > should path computation be constrained to particular one > or > > > > > > > > sub-stack of them. > > > > > > > > I think a good way to identify an OTN (virtual) topology > is > > > via > > > > > > > > (infrastructure) ODU container role of ODUs comprising > the > > > > > > topology. > > > > > > > > BTW IMO the role of an ODU container does not change hop- > > by- > > > hop (as > > > > > > > > some people seem to believe). The role is only meaningful > > on > > > the > > > > > > ODU > > > > > > > > terminating nodes and irrelevant on transit nodes. It is > > > > > > > > it's > > > > > > > position > > > > > > > > in the hierarchy (but not role) that may change hop-by- > hop. > > > ODU's > > > > > > > role > > > > > > > > is the level of topology it is provisioned for and it is > > the > > > same > > > > > > > > for all ODUs that comprise the topology. For, example a > > user > > > may > > > > > > > provision > > > > > > > > a LO topology and constrain ODUs he sells to a set of > > > > > > > > clients > > > to > > > > > > use > > > > > > > > the topology rather than any resources available on OTN > > > network. > > > > > > > > The bottom line: container's role is the same as the role > > of > > > > > > virtual > > > > > > > > topology the container is a part of and could be > advertised > > > as the > > > > > > > > corresponding link switchcap. > > > > > > > > > > > > > > > > According to the point 3, I don't know how to advertise > the > > > roles > > > > > > > > and muxing capabilities with the ISCD of RFC4202, could > you > > > > > > clarify? > > > > > > > > > > > > > > > > IB>> switchcap =3D3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC, > > > > > > > > IB>> etc.) > > > > > > > > encoding type =3D3D mux. capabilities code > > > > > > > > > > > > > > > > In addition, could you clarify my questions in another > > email > > > > > > (copied > > > > > > > as > > > > > > > > follows): > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > 3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > For Lo ODU, Ho ODU, SHO ODU, they are relative to each > > > other. > > > > > > > > IB>> I disagree. You define role =3D3D=3D3D position in the > > > hierarchy, > > > > > > which > > > > > > > is > > > > > > > > a mistake IMO. > > > > > > > > > > > > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 > or > > > ODU3 as > > > > > > > > Ho OTN Level or Lo OTN Level? Another example is, if > there > > > > > > > > is > > > a > > > > > > OTU3 > > > > > > > link > > > > > > > > supporting ODU2 switching, which can be used as Lo ODU2 > > > (service > > > > > > > > over > > > > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in > > this > > > case, > > > > > > > how > > > > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN > > > Level? > > > > > > > > > > > > > > > > IB>> As I mentioned earlier, ODU role is only important > on > > > the ODU > > > > > > > > terminating nodes (i.e. on either side of corresponding > > > link). What > > > > > > > > happens on the ODU transit nodes and its place in the > > > hierarchy on > > > > > > > the > > > > > > > > transit nodes are of no importance. My LO container can > be > > > carried > > > > > > > > by somebody else's LO container and can carry my client's > > LO > > > > > > container. > > > > > > > To > > > > > > > > some extent it is similar to MPLS LSP role: LSP always > has > > a > > > role > > > > > > > (e.g. > > > > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack > > > along its > > > > > > > > path. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > 3 > > > D=3D3D=3D > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D= 3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > =3D3D > > > > > > > > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3= D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D > > > > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Igor Bryskin" > > > > > > > > To: > > > > > > > > Cc: "John E Drake" ; "Snigdho > Bardalai" > > > > > > > > ; "Fatai Zhang" > > > ; > > > > > > > > "Lou Berger" ; ; > > > > > > > > > > > > > > gmpls- > > > > > > > > g709-framework@tools.ietf.org> > > > > > > > > Sent: Wednesday, July 14, 2010 10:36 PM > > > > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > Curtis, > > > > > > > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > > > > > > I agree that there should be multiple OTN specific > encoding > > > types > > > > > > > > introduced. But IMO they should indicate the link's mux > > > > > > capabilities > > > > > > > > rather than the link's role (i.e. level in the OTN > > hierarchy: > > > LO, > > > > > > > > HO, SHO, etc.). The link's role or roles IMO should be > > > indicated > > > > > > > > with a separate switchcaps. I can give you several > reasons: > > > > > > > > > > > > > > > > 1. Links with the same mux capabilities may have > different > > > roles; > > > > > > 2. > > > > > > > > Link may advertise several roles (e.g. HO and SHO) with > > > different > > > > > > > > mux.capabilities per role; 3. Link's role and mux. > > > capabilities can > > > > > > > be > > > > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style > > > ISCD is > > > > > > > > required); 4. The combination of swicthcaps and encoding > > > > > > > > type > > > will > > > > > > > look > > > > > > > > to CP as a separate layer, which is exactly how ITU > models > > > OTN > > > > > > > > hierarchies in all aspects but routing (!?) 5. If the > > > operator > > > > > > would > > > > > > > > want to constrain the routing of OTN connections to pre- > > > configured > > > > > > > > topology with a specific role (e.g. constrain all ODUs it > > > sells to > > > > > > > the > > > > > > > > clients to one or more pre-configured LO topologies), > this > > > would be > > > > > > > > possible to do in a technology independent way. Suppose > an > > > instance > > > > > > > of > > > > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO > > from > > > HO OTN > > > > > > > > links will be no different from the separation of WDM > links > > > from > > > > > > > OTUs. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > > Sent: Tuesday, July 13, 2010 6:24 PM > > > > > > > > To: Igor Bryskin > > > > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou > > Berger; > > > > > > > > ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > > > > > > framework@tools.ietf.org > > > > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls- > > g709- > > > > > > > framework- > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > In message > <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl- > > > srv- > > > > > > > > exgen.atl.advaoptical.com> > > > > > > > > Igor Bryskin writes: > > > > > > > > > > > > > > > > > > I think OTN links require more than one switchcaps: as > > > > > > > > > many > > > as > > > > > > the > > > > > > > > depth of the deepest possible OTN DP hierarchy, for > > example: > > > > > > > > > > > > > > > > > > typedef enum > > > > > > > > > { > > > > > > > > > LSPSwitchType_Unknown =3D3D0 /* Unknown */ > > > > > > > > > , LSPSwitchType_PSC_1 =3D3D1 /* PSC-1 */ > > > > > > > > > , LSPSwitchType_PSC_2 =3D3D2 /* PSC-2 */ > > > > > > > > > , LSPSwitchType_PSC_3 =3D3D3 /* PSC-3 */ > > > > > > > > > , LSPSwitchType_PSC_4 =3D3D4 /* PSC-4 */ > > > > > > > > > , LSPSwitchType_L2SC =3D3D50 /* L2SC */ > > > > > > > > > , LSPSwitchType_TDM =3D3D100 /* TDM */ > > > > > > > > > > > > > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_OTN_LO=3D3D124 /* OTN low order */ > > > > > > > > > , LSPSwitchType_OTN_HO=3D3D125 /* OTN high order */ > > > > > > > > > , LSPSwitchType_OTN_SHO=3D3D126 /* OTN super high > order > > > */ > > > > > > /*****/ > > > > > > > > > , LSPSwitchType_LSC =3D3D150 /* LSC */ > > > > > > > > > , LSPSwitchType_FSC =3D3D200 /* FSC */ > > > > > > > > > }e_LSPSwitchType; > > > > > > > > > > > > > > > > > > > > > > > > It would be better IMHO to keep the Switch Type as TDM > and > > > make the > > > > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO. > > > > > > > > > > > > > > > > This would replace the 20006 OTN Encoding Type for G.709 > > > Digital > > > > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN, > > > which had > > > > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a > > > long time > > > > > > ago. > > > > > > > > > > > > > > > > Replacing the Encoding Type would insure that any LSR > that > > > did not > > > > > > > > understand what the TS type meant did not try to > multiplex > > > its LO > > > > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy > > > commited > > > > > > to > > > > > > > using > > > > > > > > a 1.25 TS granularity for another LO ODU. > > > > > > > > > > > > > > > > It could also be stated that if an LSR advertises OTN_LO, > > > OTN_HO or > > > > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, > then > > > the > > > > > > > latter > > > > > > > > is for backward compatibility and should be ignored if > > > OTN_LO, > > > > > > > > OTN_HO or OTN_SHO is understood. If the LSR commits to > > 1.25 > > > TS > > > > > > > > granularity, then the corresponding G.709 Digital Path FA > > > > > > > > can > > > be > > > > > > withdrawn. > > > > > > > > > > > > > > > > The Encoding type would be the lower encoding at each end > > of > > > the > > > > > > LSP > > > > > > > > regardless of what goes on in the middle since that > > > determines what > > > > > > > can > > > > > > > > be wrapped inside it. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > OTU3 > > > > > > > > OTU2 ODUk=3D3D3 -------------- > > > > > > > > OTU1 ODUk=3D3D2 -- ODUj=3D3D2 > > > > > > > > ODUk=3D3D1 --- ODUj=3D3D1 -- > > > > > > > > > > > > > > > > This is OK and the outer ODUk=3D3D1 could hold a ODUj=3D3D0 > or > > > ODUj=3D3Df=3D > > > > lex > > > > > > > > even though the ODUk=3D3D2 at the next hop could not > directly > > > contain > > > > > > an ODU0. > > > > > > > > If the SHO Encoding Type is used, then it indicates that > > two > > > levels > > > > > > > of > > > > > > > > multiplexing could be supported at that switch/LSR. > > > > > > > > > > > > > > > > The nominal bytes/sec rates can still be provided. RFC > > 4328 > > > Switch > > > > > > > > Types currently don't include an ODUj or ODUk distinction > > > > > > > > but > > > if > > > > > > > > Encoding Type indicated LO or HO, that may not be needed. > > > Along > > > > > > > > with the new Encoding Type new Signal Types for ODU0, > ODU4, > > > and > > > > > > > > ODU-flex, and ODU2e, can be added. > > > > > > > > > > > > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but > > I'm > > > not > > > > > > > clear > > > > > > > > how in an FA it can be indicated that either type is > > > currently > > > > > > > > available (NE capable of both and hasn't committed to > > either > > > one > > > > > > > yet). > > > > > > > > > > > > > > > > BTW- Maybe I'm missing something but the number of > messages > > > on this > > > > > > > > would indicate a huge controversy and I'm not getting it > > > (other > > > > > > than > > > > > > > a > > > > > > > > strong preference to rely on bytes/sec or on enumerated > > type > > > > > > fields). > > > > > > > > > > > > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work. > I'm > > > not sure > > > > > > > if > > > > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709- > > > framework, > > > > > > > > or other intent. Could someone (either draft) concisely > > > summarize > > > > > > > > the multiplexing restrictions in one place, including > > > restrictions > > > > > > > > on number of multiplexing layers at one LSR. That might > > > help. > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > > > > > Sent: Thursday, July 08, 2010 1:59 PM > > > > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou > > > > > > > > > Berger > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > Subject: RE: [CCAMP] Comment on > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt > > > > > > > > > > > > > > > > > > What do you mean by "different switchcaps"? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ccamp-bounces@ietf.org [mailto:ccamp- > > > bounces@ietf.org] On > > > > > > > > > > Behalf Of Igor Bryskin > > > > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM > > > > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =3DD8 I think we need to sort out the issues with the > > > framework > > > > > > > > > > document before we can embark on any proposals to the > > > problem. > > > > > > I > > > > > > > am > > > > > > > > > > still not clear why do we have to deviate from the > > > general > > > > > > > approach > > > > > > > > > > that has been established in RFC 4202. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi- > layer > > > control > > > > > > > > > > IB>> plane, and > > > > > > > > > > it is highly desirable to adhere to the layer > > > > > > > > > > independent > > > > > > > paradigm > > > > > > > > > > of advertising of TE links, and there is no reason to > > > invent an > > > > > > > OTN > > > > > > > > > > specific ISCD. The combination of Switching > Capability > > > and > > > > > > > Encoding > > > > > > > > > > type of RFC4202 ISCD allows for specifying both > > > multiplexing > > > > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN > > link, > > > and, > > > > > > if > > > > > > > > > > this not sufficient, you have another reserved 16 > bits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Additionally, I do not see any reason to advertise a > > > > > > > > > > >new TE-link > > > > > > > > to > > > > > > > > > > represent >the low-order ODUj bandwidth within the > > high- > > > order > > > > > > > > containers. > > > > > > > > > > This is simply >blowing up the solution to a very > > simple > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IB>> Here I disagree. In order to give a user > > > > > > > > > > IB>> possibility > > > to > > > > > > > create > > > > > > > > > > IB>> OTN > > > > > > > > > > hierarchies and constrain LO connections to HO > > > containers, one > > > > > > > > needs > > > > > > > > > > to advertise OTN links with different switchcaps. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > > > > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM > > > > > > > > > > To: Snigdho Bardalai; Lou Berger > > > > > > > > > > Cc: ccamp@ietf.org; > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Snigdho and Lou, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, we have lots of off-line discussions among > authors > > > and > > > > > > > > > > other interested experts, and we think the proposal > > > described > > > > > > in > > > > > > > "draft- > > > > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] > draft > > > is more > > > > > > > > > > feasible for OTN networks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The framework draft just tells you what information > > > needed for > > > > > > > > > > control plane, no matter how you encode the routing > > > > > > information. > > > > > > > > For > > > > > > > > > > TDM networks, you know the resource is allocated > based > > > > > > > > > > on > > > TS, > > > > > > so > > > > > > > > the > > > > > > > > > > available TS should be get or induced before creating > > > cross- > > > > > > > > connect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are trying to find how to encode the routing > > > > > > information, > > > > > > > I > > > > > > > > > > think you need go to the routing drafts (info model > and > > > > > > > encoding). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you look at the routing drafts (info model and > > > encoding), > > > > > > you > > > > > > > > > > will find that one of your suggestions is adopted > > (i.e., > > > simply > > > > > > > > > > advertize the available number of ODU0, ODU1, ODU2, > > ..., > > > ODU4 > > > > > > > > container instances). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One more thing for your first comment: > > > > > > > > > > > > > > > > > > > > If you create an ODU2 LSP (usually over multi OTU3 > > > > > > > > > > links) > > > as FA > > > > > > > for > > > > > > > > > > ODU1, you have to advertise a new TE link or put this > > FA > > > as a > > > > > > > > > > component link of an existing TE link (like > > RFC4206bis). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > > > > Fatai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > From: "Snigdho Bardalai" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Lou Berger" > > > > > > > > > > > > > > > > > > > > > > > Cc: >; > > > > > > > > > > framework@tools.ietf.org > > > > > > > > > > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > > > > > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM > > > > > > > > > > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Lou > > > > > > > > > > > > > > > > > > > > > > Thanks, I also would like to hear about the same. > > > > > > > > > > > > > > > > > > > > > > Snigdho > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM > > > > > > > > > > > To: Snigdho Bardalai > > > > > > > > > > > Cc: ccamp@ietf.org ; > > > > > > > > > > > draft-ietf-ccamp-gmpls- > > > > > > > > > > g709-framework@tools.ietf.org ccamp- > > > gmpls- > > > > > > > g709- > > > > > > > > > > framework@tools.ietf.org> > > > > > > > > > > > Subject: Re: [CCAMP] Comment on > > > > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework- > > > > > > > > > > 01.txt > > > > > > > > > > > > > > > > > > > > > > Snigdho, > > > > > > > > > > > I believe there has been some off-line discussion > on > > > how to > > > > > > > > better > > > > > > > > > > > align the work with 4202. Use of common approaches > > is > > > of > > > > > > > course > > > > > > > > > > > one of the main objectives of *C*CAMP. I look > > forward > > > to > > > > > > > hearing > > > > > > > > > > > from the draft and discussion contributors on there > > > progress > > > > > > > > > > > on > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote: > > > > > > > > > > >> Hello, > > > > > > > > > > >> > > > > > > > > > > >> I have a comment and a question on Section > 3.1.2.1. > > > This > > > > > > > section > > > > > > > > > > >> describes the link-parameters that are required > for > > > OTN > > > > > > > service > > > > > > > > > > >> routing purposes. > > > > > > > > > > >> > > > > > > > > > > >> My comment is how are we going to advertise the > low- > > > order > > > > > > > > > > >> ODUj availability within a higher-order container. > > > > > > > > > > >> For example, consider an > > > > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G > > granularity > > > and > > > > > > > > > > >> then > > > > > > > > we > > > > > > > > > > >> establish an ODU2 service over the link. At this > > > > > > > > > > >> point > > > in > > > > > > > > > > >> time the OTU3 link has 12 time-slots available for > > > ODU2 > > > > > > > > > > >> services > > > > > > > and > > > > > > > > > > >> up to 12+4 time-slots available for ODU1 services > (4 > > > ODU1s > > > > > > > > > > >> are contained over the ODU2). So it is obvious > from > > > this > > > > > > > > > > >> example > > > > > > > > that > > > > > > > > > > >> the number of time-slots available is different > > based > > > on the > > > > > > > > signal-type (i.e. ODU1 and ODU2). > > > > > > > > > > >> How do we address this issue based on the approach > > > specified > > > > > > > in > > > > > > > > > > >> the > > > > > > > > > > draft? > > > > > > > > > > >> > > > > > > > > > > >> My other question is why not simply advertize the > > > available > > > > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container > > > instances or > > > > > > > the > > > > > > > > > > >> equivalent bandwidth in bytes/sec within a link? > > This > > > > > > > > > > >> approach seems to be more in-line with the general > > > approach > > > > > > > > > > >> outlined in RFC-4202. Refer to > > > > > > > > > > section > > > > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple > > > ISCDs > > > > > > > > > > >> being advertised per VC rate for an SDH link. The > > > additional > > > > > > > > > > >> benefit > > > > > > > > is > > > > > > > > > > >> that the advertisement is TS size independent and > > > hence will > > > > > > > > > > >> simplify the implementation. > > > > > > > > > > >> > > > > > > > > > > >> Regards > > > > > > > > > > >> > > > > > > > > > > >> Snigdho > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > From wwwrun@core3.amsl.com Fri Jul 23 14:31:30 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 22BA83A68D3; Fri, 23 Jul 2010 14:30:47 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net, dbrungard@att.com, andrew.g.malis@verizon.com, matthew.bocci@alcatel-lucent.com, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100723213112.22BA83A68D3@core3.amsl.com> Date: Fri, 23 Jul 2010 14:30:48 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, pwe3@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, rcallon@juniper.net, paf@cisco.com Subject: [CCAMP] New Liaison Statement, "LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02]" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 21:31:31 -0000 Title: LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] Submission Date: 2010-07-23 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=938 Please reply by 2010-08-16 From: Greg Jones(ITU-T SG 15) To: IETF MPLS, CCAMP and PWE3 WGs(lberger@labn.net,dbrungard@att.com,andrew.g.malis@verizon.com,matthew.bocci@alcatel-lucent.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org pwe3@ietf.org ccamp@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Kam.Lam@alcatel-lucent.com Purpose: For action Body: Attachment(s): LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1087.pdf) LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1088.pdf) From yabin.ye@huawei.com Mon Jul 26 03:26:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2493A6836 for ; Mon, 26 Jul 2010 03:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF4dFwK+MzYy for ; Mon, 26 Jul 2010 03:26:29 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 49A493A68C3 for ; Mon, 26 Jul 2010 03:26:18 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6500JWVUC9I1@lhrga02-in.huawei.com> for ccamp@ietf.org; Mon, 26 Jul 2010 11:26:35 +0100 (BST) Received: from YabinYe ([10.200.70.97]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L65008M7UBQ26@lhrga02-in.huawei.com> for ccamp@ietf.org; Mon, 26 Jul 2010 11:26:33 +0100 (BST) Date: Mon, 26 Jul 2010 12:26:16 +0200 From: Yabin Ye To: ccamp@ietf.org Message-id: <004701cb2cac$ff8674f0$6146c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_TI1Wen4c5+YJ8EMNrECadA)" Thread-index: AcssrPpr34mootmuSiSaWyRRawN7/g== Cc: 'Siamak Azodolmolky' , itom@ait.edu.gr, =?gb2312?B?J01pY2ioqGxlIFdpbG1ldCc=?= Subject: [CCAMP] Ask for comments X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:26:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TI1Wen4c5+YJ8EMNrECadA) Content-type: multipart/alternative; boundary="Boundary_(ID_iOfq3LwWVhcwfoWZ9qv83Q)" --Boundary_(ID_iOfq3LwWVhcwfoWZ9qv83Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Dear All, =20 We have submitted a draft entitled =A1=B0OSPF Extensions in Support of Impairment Aware Routing and Wavelength Assignment in Wavelength = Switched Optical Networks (WSONs)=A1=B1.=20 =20 http://tools.ietf.org/html/draft-agraz-ccamp-wson-impairment-ospf-00 =20 This document suggests to extend the OSPF-TE protocols by including the physical impairments in order to support Generalized Multi-Protocol = Label Switching (GMPLS) and Path Computation Element (PCE) control of Impairment Aware Routing and Wavelength Assignment in Wavelength = Switched Optical Networks (WSONs). =20 Due to urgent issues, we are not able to attend the meeting. Attached = please find the presentation, and kindly let us know if you have any comments. =20 Background: This draft is the output of EU FP7 funded DICONET project. = More details of this project can be found at = http://www.diconet.eu/homepage.asp =20 Thanks and regards, =20 Yabin Ye =20 =20 =20 ********************************************************* Yabin Ye =D2=B6=D1=C7=B1=F3 European Research Center Huawei Technologies Riesstr. 25 80992 Munich Germany Tel: +49 89 158 834 4078 Cell: +49 162 2047570 Fax: +49 89 158 834 4447 E-mail: yabin.ye@huawei.com www.huawei.com ********************************************************* =20 --Boundary_(ID_iOfq3LwWVhcwfoWZ9qv83Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Dear All,

 

We have submitted a draft entitled =A1=B0OSPF = Extensions in Support of Impairment Aware Routing and Wavelength Assignment in = Wavelength Switched Optical Networks (WSONs)=A1=B1.

 

http://tools.ietf.org/html/draft-agraz-ccamp-wson-impairment-ospf-00=

 

This document suggests to extend the OSPF-TE = protocols by including the physical impairments in order to support Generalized = Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) =    control of Impairment Aware Routing and Wavelength Assignment in Wavelength = Switched Optical Networks (WSONs).

 

Due to urgent issues, we are not able to attend the = meeting. Attached please find the presentation, and kindly let us know if you = have any comments.

 

Background: This draft is the output of EU FP7 funded = DICONET project. More details of this project can be found at http://www.diconet.eu/homepag= e.asp

 

Thanks and regards,

 

Yabin Ye  

 

 

*****************= ****************************************

Yabin Ye = =D2=B6=D1=C7=B1=F3

European Research = Center

Huawei = Technologies

Riesstr. = 25

80992 Munich

Germany
Tel: +49 89 158 834 4078

Cell: +49 162 = 2047570
Fax: +49 89 158 834 4447
E-mail: yabin.ye@huawei.com
www.huawei.com

*****************= ****************************************

 

--Boundary_(ID_iOfq3LwWVhcwfoWZ9qv83Q)-- --Boundary_(ID_TI1Wen4c5+YJ8EMNrECadA) Content-type: application/vnd.ms-powerpoint; name="WSON impairment ospf V1.ppt" Content-transfer-encoding: base64 Content-disposition: attachment; filename="WSON impairment ospf V1.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAOAAAAagQAAAAAAAAA EAAA7AYAAAEAAAD+////AAAAAIAEAACBBAAAggQAAIMEAACEBAAAhQQAAIYEAACHBAAAiAQAAIkE AAAABQAAfwUAAHoGAACKBAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A bh7wyyoAAAWLNR+9x/hapvOnUBtimEv/iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVU AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9z b2Z0IE9mZmljZX/tNXEAACo6SURBVHhe7X0H3BXVnfaZW94GCEQMMbQVE4NREywpZjVKzIprJMSO omChvDRFbDExjCNRNxZEUXgpFggoELuxxHz2RJJoghpb4upGg6uoCAi87d478z3PKXPPnTu3ASLZ nwfnnXbq/zn/es5cU57niR0tTXdd592v7T+oTjTs4zemByXSqd2d+vSuH6aDYcsOPLCjlv5O/2aP uo9fXn+fk0q+m0wn3vBF4jWREi/MfK/j9Vrq2V55U9uroWramTRn+VC/Ljnt4y8fcHhXPy066xIi 4ThCpBJCOAnRK5m8HvWMr6Yuk+fjv228LlGXGiqSCeEnUF8qKerTKfHj/vV+Ngge8B0xa+bbGx+r pc5PMu8OAciEGUv3C7rk7ko3NgzoAOE7nEAQB0EcQEh5g3N9um7ciJUrz6qWS6b36FGXqWtv7ghQ F8o76YQIUH8763OAjhDDGtKpYdMGOG+kcrnjrly9+flPktjV1P2pA9Lszvuvhob6C9udFIAgCIob wBrqLImHA88zIhBf6Nb9LOS6qprBbUpsPDsh0kIACIgs1IHhEgaCIxEXoiPwAVR697qGhlXT+qYu n7l6w0+rqfuTyvOpAjLBXXhf0kkMa5O01wCQYBIUxRUExkmAmPgvwG0umZhSLSBOIj3FBxBOkuVx pHFNkA3XsckA7JPzRRuOusb0T87r333Q1W9vOPaTInilej81QJrd+bding7LSq7QXABRpThCPeO/ 8F5eJ0SXdKrftNdeGzhz0KA3yw1uWq/kwKam+n6tfk4BAD0kgZGcwkOX9skxOeFkcyKTyYlUOn3M uf27L7zm7Q1jKhHvk3j/qQAy3l14cr1IjO6ACJLUlyIpT3wjTiQwociSN5jJOeHX1Y3EzYxyBPFF 6pS2bAYA1CkwUhgqwZBnIw5RQ44couomt2QBSkNd+sxpfbs9MnP1xhWfBNHL1bndAZnuLq17XwRL C21XCxgDQAiEBoWjAN0g8ckox1QCBNbZMbSqlBoyIpBii1ZbWusQToScFIWCoiuZEg5EV3snOEaI ZdN7rL370vU7A9Xtl7Y7IGtE6zVKneokGYNPtLiKG7ssoEUZTo2p9OBKJGqqr/t6G+BTusjoI5SC YpeWG7mFidwhwcBB8Sa5VZ6czQ39rhai9exKbW3L99sdEMzNyVkpqiJJWz0lBydlvtQqkDKBmPbO W0Nm9hnweFz+83okD8uSuNKyVVjLglJxaODJPfgXgCOUjc1XWmzqIshCi+7/LiAT3JtPiCU4CSaP GKAMQX2ViVk6JbFTQ/AgFpBswhniQ0k7dYbQnP0sjj8+TTWCoKcFdYiPe75TnQhBpI0xrVf9iJkf diwrOVG28YvtyiFQmT/IqqmaTxg0yKyf8kYTRWbThDS5Ja34DPmD4KBStEj44iASmTSmog5wOAQR brmAURDQgiMIcg4os1fgNeuVHAOQAlxns9BYfm443vxfBSTxDQiJYjpKDDhLrUlKjjAAkGjhoTgp cJxvlwIk8P1vOxQ/BCFHX4YH0dHiyYeLGYozAwjyZrOKW8hOkmtg0WWD/bcxE5Stbos55BR3Ufdu ItM81xvzi2o7DDB2K8obJTb5hRwgAdGghGDlgemWTDZOb32p8dKmvdvsOqfU13ftlhb1G3PgRYAQ wIqi00lLSjEd6qBCJycw8SFMXck5OEQW7eMgtyhO8ftUOz7mm/L0sz8Wor1l9sEHr6+lnMm7RYB8 03VTO4m+L0JB9x/vzn9lnjfu/moarxdOg/I9IklPSjkrjayXwFBk8MzJzXda3uNMPZJb122waBIr 7drS2Y2DOzsalf4m0ZMABYSWClxzokPCS0WuLSw0wLYERBSBEQCTB8VXMgiaqhkb80z4459/WJ9K XJFpT0wesXTp7stGjqwpMs06tgiQ/UTfP6DL/TGnENFw7hvrtvRf4DX/s1LH9ZwszEYiSWLrt/Ks ZyhzGoUbAqPlewYESyT2Ro4CQJB970wGdIBXHiA+5iAfqyMYjoq9oBzaoCMq69d6Suoccog6jC7x M7lOGbepkKY8+2z/hJO8t41tZ/0+u/To8xyK7FOpXPR9zYCMdefNx9AgV5U2oC6sE6nf49S/UuOQ 3K3IUzzjOJOlcqXiRZcoMhATlDOWPSQo0hrCe6kbfJGjmKlLDIq2mQiyg3IZEhA84YCwMnKsOCGg hQUwVNwsb4FJzpGcoTgkYFshMLmPqgEkkaz7fa4N2GlR6/u5vSfe+Ztlc44dOqISXez3NQFypjt/ eINIjG2XVhFHoQaFIfRrdheuaPHGxJu1+RbJRV8p6iBnMIgA+mmiI0wO4jgUNxRbmNmcvQ4IKp9T N+AdiLZHtC6/E88IpmXMBT70CddUwB3KMycwuqQUl1oUUnQRFE4EcglByeXeqkTQs1a9eEcu5/dV eoegqn7X+8GJ45f++sF5I49aXKkO875qQKa4i7q1C3E3wYgmPqkX4vix7vxTF3jjflmm8ZdiATED kaYpFS5R1jpDKlpGaNVA5Tt5jVYT/sCivmRzuxunHpaYMpEBhuQOeuN0wYl86IgqEajYXRPTcAut rkC8GoIXM7BJz780qs5xjm0ngLDKlOmsgGmHHqrLZhdd0LLowSubR39YDShVA9Iu2n+lmT+2Xipr BAwXT3FbnphdQp9gjq9Mi+DYWF2iiZFXqiQmxZdSzJJYlP1UtlTyDHkkxIBoZ5xsdgD9Gul7kMgE Q+oOxrXwgGF8E9CUhfM6RPkuWp+BwAkQ1/ezz4m6eL0+5aWX+mNRc1F7B8JdYf8JBo0C1ecs6mkL Gu9GQwdvM0BOdxceCmIPjeMOuxEuIEGfPIFnu8c3nn0Y76+OrYcmJsWRnF1KqSuxxfAGSAhgpAlr uAXgNAinS7SdxsCpb6WoCR1CroWoNZCAfgiBJJfogpLfjekdgqFEVx2CkmvbO57AoGJTKnCeaO/M wHAwBoGy6EIHk5MJ40hm/YPGX7XoqHnnj/51JVCq4pCkyCxo15ZGXnOoqqP3YNyBE92Fc+Z4YyZG G4cl9jLMZKjlmMAVxYaW3XINPctQOWYaF0wS4AoAQ7AkKBkQF+dUOhCYpV1m7733ZrY15Z13eiQa oUBkiERZRlInMOTOUAp1BwON1IC2lRUCoj11aUTkRGvO9xd07/1yHBEnv/DivJwf7EYTWoJAI0Ma Auyz8mukTsF1BzgmmQ3mop6tB+R0t2Uo/I0vwX4oCHooIKJwKBEPBp8wFkp+gTeG3FKQYIjeiTzH xc4UcgHDFdLK4cCUiSr9BnIGiUhlzAWmjCNyqQwx/AKevMH6stlsbxqpBWKITiAJjNkuQZAK3db4 UQ7RCh4Vp4R/Z1w/oTe+15hIjmvLoDHpVBrdo8Qdx6AmlwKHjmYqm+uLyfhD+Gz3leOSihyC7l9I 7yaO+KUqbpP+iXhohLu0+zJvpCSRSbB3bsccPi424mvMTfoOnMk8owO0ihxtHSlTFmKCYSmsW6SC oJcBJJXJ7CKj6ZwoaMSRsSvqIB0+kWv1tkLXvTIRASOycMYkFB2ZzO3RMU5fubJuQ2PXB9raFRiK OzAaySE8ExReow+8Zvt4n6GTKZzzUN+WA4LwSEOjcIZsDoN/qnvFfBELTUNP0Xov3vyn/XaeN+au Se7C0pOE8jilxJIkpOQMBQxntoqQ80yxkxB4s3NYmd+5s+QQbV0FXCkkRzCepUWV4jKiprmEml9a Gdpk1SYw6Tm7Tz8q44L0UUOX+0HgBuU8onWCof2XkCs0ODKPEWWoD7Q8eLo7q/FSb2pBuMduoCyH JEXb8aaknHV6PcJUYMQWrRZLCISAYZYdweVagHCb3SjmD+3yUbGokCCdJgZlxBQVMkDSq4gEQ3II /tQ7TvewnnbRw4fekXErWmj0B/RGCbnThL004spWY+QQGhGsSJrbKBeIRdH+Tfjz8yOh3w/v7CQI AAMcKvUF7hV3aF1CzjBAyLOsWdASbRVdj8ZlAT2qBgSzZgjD5ZyciuBV8oZuoRP5UXYpOO2BJd7o DabhnMjO6ipSoyjaYpNUjmiRxISuwA3jHnJPlYN1DNMTLudm0xYgfnangPnJSRQ/0DXKPKalxUCP srAKdIisTPdDr400gas2+/5Mu2/TX3qp+/qcv6STHMH+hSJKgRIQHIpYwx3Mx2c8dNI9P2QrAGEs Rq1WRJV4JWvLvOe5m+igdRHa4bC2VjW7C/4bz74UCwgLdVBXEADOBhKSOWFYMz5lTQ9YU11NHX5b RzeuiwfYxODIsDs5TXnnElwZTjH16Tq1UyjXRXQMDWD8bfZeX33R7tu6jzse9KV/QcJTYVMcaaUt wSAw6jk5RnILOScy53DL+FvJVFZkAYjeZv3CrrdYPJXnHJDwIOzBOg2h+ltNTxyR/HlC5G7Nz59I H6XowsC0zpAYaGBkayCgXERMW9HYbK5JeckQcVJUKTAKzN0QXNvSyoNBuDv94DK7N5OeXnlGSiS/ 00mrSSpypajlteQWpUvk0WFxBvsSSWj181sMCHUdrXnFI2YA1Ystk5PbNgDsLQi/3DXbG/0xOzTX O2MRuKQFlw0lO8gZx6VWs0eLGbVFJD1x3CZ8PyzvtHc2BPQ5YF3lHUi0TIXO0IkeQ7jNSDesuEPV 3RkEbTcesG8Y/pny9NPdEQO7qZNRXOqW0N8gh5AjMDqpS5ROCeRZi65ylC/xriyHYCiMv/QzZaNK 3BZL5KSocrfbZN6s6LwHp+/l6wtmQMpfJo2cUomDRkkZPqdFFE46HYNKceOVpmenXyfDFvTuJQgg FPUIZ4TZDaktNVWCkOo60QAjK7kgd2lBV9rFPT5XGKmYQ5HFRSylyKWo0vpDgtVeqDeiw0It68oN t4LICl6F4tyXc4tk4VkPXQ+muOpyugVW15BJ7vzjbvTG3cGScJIun+AuKBAPsZ3lQJV3oeJTEhT8 YVzK1y45H2U6U4E0cbl9lLKO15i1Wn+oARizV7dETPQGCkqYGw/9zn+ZPkx4+PETUkHiUPgjyrnU Tl7ojRu9gfdSgUNc2Uo8biwQpq9uMSAo+BTGcLIBoZxyN9xT6M8XNk2rC++X4vuPuy/1PKk+APhl 6ORPi6VtpNvklAADN8u7JFCaJqrZYIX8DPLJ8IgOscsQjPZFDBhGh9gSmNyHvqG2cDckHMDU2s7c ko6sWuNQoXgVUpHKOzRrLZ0hJ07pRPGP71Oe2gpAOpc1iIaWVmW+SnLmCVdaQJXjElRRt0b0pYyW QPcW/5z+gehb3Y5zEoKgyF0kaIVrJVk6HHrKtOMdQZBmLvUIlTqKSA7hXOA7eRGJAymx1eu5p1xx +Hdl1g//d8NiyK+0NJ8NEKS3FFU6LEInVoosTATta5QjNoKholNsWr7FgCzxpm4Y5c55DMPXct/m gzzZo7okjktskJqEc9IUd+F1s70xfwSn+Nh4PQPk+1lFLuFIKFdIeIKRg4mbDpR5z0TRwkUornsQ CJq70jPnrne8lyuFEUDy3OGiL7ILE5Y/eGCDL06Se4P5xAQL7cUr6QRqa6usEsyTHxP7kbne1E1b DAgLgsUubBTBs1ickpPL1iWl1Xh5BU+HEHXdier6so0Wb9x0gPITUKvy4jULkEj0UxiIzEI+mdQG AhKMJBW7MXsJCH0aDYhxDguoEmTmnjwsVOaJjswdbQQhXDrWCp3BT2nyaiCq4ArTDCYhvChxfjkw +K5icHGJ1/zcSPfGu/Ex2NGqMkVsBUwpLolv1uYS0KfPBHf+RXO9cVfoOXs+ns2scrKpBuQaijTD ZPLbM75DfPT6h3QITewq3F2vvXVdBrwjMkHuXFPH+PnLL0Zs4ovhgpMWWWppFyOQIkuJuFrSZuEv gxFT4GzGla8ICAu9LvY7YU+xai3m405Gl2iDUQJke87meSkz2IDCaZ0WicuxY6UFnvs6AHMtLK7p eNyjloGi7TCa7LRnMlKH8DsQnKRDaA7De2ZXvW4E/Vg7b8KJs3l7wRXLe3Z09Wd00ryVq4fkDBoO mitiHL1q+oqmP3pMvMNPKCqmFELkdXuIv2eM/Iwr8SfvwOwe7gvfwurEq1EtYuJbtveeryNedBlQ uMIID3gJ8v9AlQnGAaQVfF5twiShNFUpK9qkvOeaOf0NqeA1R9C5NGBIr5/7ABKizcmOMcU3pjtu C1o5+wkC66PYqp0b7L6jGX40961XoSvLjWkKosA9Rc8gtVq8ffQHokvLEPeqcY975/+qVCGIrtdO cW/YNy2Sz6LmFOaP5AwFRF6zFCp4TWY1/oJk8sHyOBJhle8irPIUuORXk9wF3AhRNt5jKmKdmH1W KNvHNUmAFzKEotWL1h8SZgsUrKqsmvfT0+/hY/ThkIaUcwQ/bathPpSdN5jA0DqJ/TE2xu1KJixc TQxE11nviLbTSNjvdQq/R6NIrvgP95o360Ry9APe1N/FlV7iTX4eoOxZL5KrwNQyqJcHoLToUlZ+ PChU8KDXUryWEQHsuDq1SaRW0dSulKRPZwGCwbdTrxWVNADJCtVbrE0IbNwYlQc3WNpWg5Iu1ze2 gPWxjdgmMRhgvFkqL1ZVf1QngnmgwOe1tBiCpaBgMMnVgaEhsDYQy5ZPH+nOegaqDsCcX4QsQPnv U9yWgQ2wvOASDSCZyR8mCFlKn5RyGNl5zPK+mKFT0PnZc73m5xHjoicfv8xrjU7rK7merpK/WW4Z rYQk3mMi3NbiTSY3CqzZnE0jo4piFbMornX+0SSyB1zpNa+NK4BNI99IC/+XdSLxFfvzLPR7MADx d+MgOLMohlolMOI7XUXd68Pd65ZnRevkB7yLGNMKE8TXB67r7vY/ojd2kTiH5+3OcuZu6Xd0JND+ ddgzPPdPnpdNi82n+6LLceX9XhlMZ8mNVtc2xuuyQrIwT0pslroDUYPU+6LvrEptVUQCGeSyr/Af muuNPTIuP7ZI9e0QiUVNIvG9NmkG56eO1s0DuL62M37jgP6G/Mszl3I2KY45satoOvFY9/or9xJr fwbFH1o0+EmOYLEQQ0e5Ledga/NM88IYxOxQsT4p57kIZz/R7/o/CTFxNpwnsPOFYOdflCMULb6M 8D82g8dE+pjrgux/qaTCF85UtCF1z/ui32xlEW5dwkZyiEBx9nxv3PXRmrjJsFN0XpsWqTMZPoou zKm25W6ynckhWLEmh3D9Dd6GkumSWyiK2GsM9ILXxS5nneDOOXeFN3GO3eBir/laiLAHIcIeRw27 msrjRZdpWM1jezazHICdAGtjBoj1LnasXDnRXXAWHpcUJZI/RHaD6Q8m04ZKniX6+A+IxutYBiZ3 n0aRai65wF0FRqoPzv92iuyQeV7z36NFoLB/AroiEiES3JsQTYZeijJOIgVUsILt1xEOAiC/cqVq ZTOabJxxHSLXgF2HN57k3nAxKjljmTf5YVM5RNjfcP3F0915N8OrP91shCsHSpyiVx58l4WoS5rB gcgdD4I9U2qpV0eo1pl+ZEV2fX0ZX5eKHHGL401+mNwLSy4jVwEG64PxcRMADk1nUwxAnAgdMRfL Yz1jP8GQ41OjzP8Vbfxiew24pB9MQMkhBEOjLvdYKd2iSEuZByLs2igSDwGYv8CLOHmZAkOmW7zx Z2Af182wMO4Gh/VSIkvBGie+4kDRZvC+GOQqKPiVGNgK1BG7iZuApER7CAhWqj7SIMWSEzP0lwu8 sc/xJUTi/iDoEdVYc9HKFH3EB9B9w+d5Yws+h2C9SeHfBn9qDxXdLk6FmiNvZUN0vgcOEbSk+lF7 4BMYNJSUMlgBY671ThlN4Ha8gyWxX5PwXxvpzrkdimryHV7zRwqU5t9BUX7+n2LXudjnOV6ZtcWg MG/xSj0+QlagL8DrA5int+hy6gei9Tj0s4jWrLen+L5lybSvTShrvCihB5kviNWnmxewcua3FgjN 2GJFDyFWqQPmYE1nkv3yAndW7w2iy02IWf2A9dYKhgIp8To55DncDFEgGCCU1QXO0RCohVxZRCt+ 3iM+Q546qZvwT0JU2P03sWYGPX7t9TeDW65HnfdDNAw0ytlwCuvSloWs1w7mw1rZ/0x34eE3eWMe uRQb7bCr/jR8BrE46sFz0Fd7e4d6H7pn8zkxe75gCYKI/kizBgMzF7sxE/uVEiVx0DDmBQPojazI HdUCJ9nkwQ8hpN8TrZdnRNfzSL9yHBcjovTYVW2g91/gGIpHIGLOp+mpOIREV6KLSXGJUviqEGew 8syNxc/YBSwyD1wxFVbXeCh66fGDW17Bafcz3TlnpURqJsN+BghVd16UmaAln5NQ6BONB7krhZ84 wIOHNyvkh57GGIBlV/TJWJxOACGfRB1hFAKTbU4t35phgnD7wjSIpxtssDhR1gnnBgyqS2Ug8iO3 BZm55qTJiMTDqZc97//t7bohUor4/CYvFXIJwTCgKA2jdIv8AQqcSWUCCrHXE+bfilHu3Fcwo47X gIibvInXw3q6tVU0LQBLn2CIZusVRei8jQYi7I6ZfDQ22d2t2qsbjp80W0NHygwCfXjfJpC+/gDn Xcxz9q1T5I4295Dxx6DugaVEil2fUto+PonePA7rGKG/A+vsgCQiG6DQbpXqKaUvotoF/ot/kzf+ SRntxcsWkLaZ10Z/kC+y2tKiTLA5hfyhFL7hI059ZSarfcDiq9hw/TKAWeaLpgnYJLce4oT+womn uzdg+096BSyQQRRBxSJM9Yh+DYhJ81QCgt0q7wOgaViSmmlWpNDee1FAUN8atC8B4eDQxkRGk00+ lJ9VsNk4BlHOVnDpK7DajocpSy6XCUD0gvSAnkj9kBxRLghaCghN74JWNQ24O17ZiBjYT6Gsmk1H yQ20upSNpHSL4hDKURbivS4pRZmq0oBCoNR+YGdEg2g9EWLsQoixq1jiFm/yX3HaE5/HjcBMvRHW 2OdMGNSIMOZjm6in31j35uMWeGfoTRFjEKJfeAbak8FH1P9uMT0DPHPke/TqOaxByIEyAdAREK2w KOOtH44Ek2AtnM0JKFcQaAVnTUe8z+OE21rxZPqjeiG/cxEbRJtcxpaAIDT80V6uez06dBYz8TAA KFhUUnqEmiYpQVGENJHeQlBUbvovDvYaBleeAY8eOU6GGHuCpW7yxvHXEZZBDl8MfXGJXusL22Jt JFxSZK/FpQSECbP2SPgmb1PPIE8RIOYZBwYxN8yU4xn9ucqOHdnv0AdsZwjcOdgJYz8HEEcgYrAY o9ylnN4phNhW36q26BRQskE9BcCzuFzO63CBCrrk7K+57qnI0lORGT8tod1D45uoqvMLuZVAIY8Q FEYCMOPhvziPj3bnPYqPvEaiA2tYG5Ttz6e7i659V3RcA/0zPu9Uqu4y8AhRcTTEjhRd/Pwavsl5 mOlXZ4X/jk08XqPF1XBgaZpOvskbHYo06g7otb5R7mDIA9FucFHrefO8qfxKWCbEnb4Ic345rLuD SgERB0KU+MVAqBzqn+JITNJzTLsFK4aYPUPgXD1vZhFByWhtYYBQPgWrUpxBMaVSMaeoOZC3pRSx g8OaRON7p7lzvVu9CZew5KXeaEZsmxHzcbGDYS6Cb0cbsaA+FEpQ3ElAmCBOroHVNRpGdxGHQKSu waCeBQfeaPLzHOUOrnHDFL4DH+FNaoF+svOOdRdckRCpH6soeCmymxJRbaGexwlFwxWGN/ChLCIH Wb2BRJUrAASi6wWIrhHIuMzWJ0pk0aaiNW7M4Tyn6D1NEVDyvKQWslRgkaUY6sfZHee2NMPQPgnE e5wtQHGTa46BntgNuReCaIiK8rtFB6ZzC/yS5kcMGbqI3KH4fdH8jhP9okNsWtwkei6yCUy/A5ww kMQlENz9AdE3Dv7EW5F8h2Mb5FJU2stwary2iQehNBDqjeEK0pP7X8GOJ2I5o2CdvWhNHaJr+T6u 24SO3WxAgWhAceNv5x3mZER8GUXPBunRsAPKr1FXZvHIbLgDB/ZGUPKx0xCcTIt1+KT6IuntI2zy PzgdBotsn6Soa0Ed34GCp2wPAcFag8wbTRCF66PP0C4248mp9DSAGA/LqWD3IEQirLLEbVjS/X78 h62VuKQUR+SBMGCxJnIGfLczFnnNK6J9jd3k8FfPu2Ww666GfHvIOHPUJ3HNqjmfF18KFBU9lnwg mdfcGxNBWlAyJ8MwSEcG4nMfwrOfAnkaihptkf07CLYvQFwIkbaT2awdB0bcM65Vd4ombJXu+NoC ZeEVJBgV52CVdCZ1i+5LUTXxXBIPgiG84QgbCNYDgvvwbY5c7E38TVx/S+46ed7zfrun6/YDKA8j 09eUJ2/cQlOV4gVyipKLkLz4a2IZ9lqiUfCG16ifFFwmcOnzy48bwC1TYFz/J8Agl8jE70lw2r9a EOx8et3jwGhZiMUvYTwPY3y7G3+omvpLgaMIr97mz6pGDQRdiRexreKIxVheKNVW2W1A0Cks+HWI sJNA+lnoPNZ+SUrTkPFS5CqjbpqaRq2qmLUVo9hZjiCoUoV/CS0Jg/NXGkTqTXDL5eCW6raYVkNJ K88Yd96V8IFkuKhICVn5yhHfZDMQ5GFQAJiy3JoPMfgeHO6pi7yJZbeRss6q9mVBhPFr1Nuh8L8P gk7AzD8SZ+glcgOrUM3nOYXRYCWU1PJs3hBQ2kSBpSDMXxuPR+9s/Al8F5rh4Jbm2G/Fa8SBO0v2 QYsQw06f0L6ttRLZ5/yUtEHjeDnhVDAzwCYHcS8+3J632Jscu2kkrumqADEFGffCNQ+xH9bUQeZv 1Ynsl+G+9cJ8R3/8BrpyyvdQ8TDVSbOmQq0itQtMe6XkVUyM5rMaKM6wuvljraocrr+JP9sEEPgb +EU7B5PLuLpbgIYU29SPHLDTyZrYV/QdX0UmN6Lzb7SJ1j/AuCgK61TTWk2A2BX+xfMo40M5X01j n3YemNc3f9p9qNT+FgNSqeJa3/P/GfJn0bPxi6KtYZ1obEK4vgs61zhQfPBCuV2VtbTDNrBE8FXU u7lBtFNqtfYU69pRfzlVUksTW523KkCg1L+MWE8D2BFBXOnTNIFNu1CP4Mxn8kAEF4RMdEFouhEu JAjq4DrRCC2Bs8P8eJ7A2ekCVmeeJhakFvkHArQM0WbFTvinEoTDGoDEHylbv9UjRQXvil17Qr4/ jbH09OVWOX5f1igmufNk9TQq+PEaeoSld7mpFP+fAGcT+gHw/DaIpU0oQyC5L2IT9F8rhBc25zEP n/twLxKbUUEbNl+0QUC3wu/BgbVy0dCOVdV/VBpHVYCgsemo6JS8+lbKy1hNbITXdCCNhaG0g/JG 6N8r/aB8eqXUlVHMRQasQct+Ko/ekd40An0ty70pEyoNoJb3MJ/pTH5utNuyGNHtU/O7TQrsKQwz 6IF8PLQCN2o8v9yQt664emS0klq0YyzN2JjgdAn8ZpH5JU6jKvW3KkCgzE8FlwxHJ7qVq9AGRSs6 CQNVPFU4u63UurG0lKOoXEe1nIjBrIWFMuwOb2rB5oFKA6nlPTzkUaPdObfC9L0HXC/HFGfi2s8K PYx8/jjfg9NSTUz1D+Ndf5d3dkUw2I+qANGDHQqb+plKizvMSwdS7euio2hMW+U4cu2Rf80qvXIQ yRWITInc7e+IDaO4e7EWAm9JXvgEj52CzRiO6L0Mca7h0ZCJsZ5M3cWGrm385v3yvIRQYDCajCXk w6vtY9WAwBdZCc/9QsRhflENtdgZmr48Exi1eKXEljKDoWnkvXy3FkL7mN94056qtuPbIt8Sz+N2 gB9hAW0o+rQC4zLqS3NMnkfy5M87frZHbnME+8axUlhtFP552Lz+bLX9rRoQVgjP/Uqsvw/C7D69 2r2wiluUJslzjdIp/D4DImPugWLTpG1lSVU7cDsfVjN/g+9kesF2WADdMtreKJHnjLiQSKHAYl4j rigBENW45QHvnGtq6VNNgLDilzzvDHjs+H+oiTOr4RQjn8ktavuEElzgmlc7ROfwJ72fvf54LT3+ hPLid724DHTaKe6sqxF9uA+E2S26GTrqoxuuUByRf0sw4Pkuesg7B8vNtaWaAWH1UPJjAMpfIb4q bhiwu6PmU24D1tun/NW7mFbHDpfgYb+ETg08xr1+HEzka2A5drX3lJk1DTPRDI8YQBi7wnrLRb/1 zg1/gKCWQW4RIBqU66BTHoDtdD86gR0kpZNaExH8RvYy6KLKv9xQywg+obx3eWfNx/huGiR6uDA6 LoQ0wP7nQrFlW1MkJAyeNyGch/3WOz/cqVJr97YYEDYEncJtqHvCJKYVcR7EGIOP/O1PmVg5vKW/ A4gbsMP5Rn6TXmsHP838GF8OK1nTR7jujFbRcyq44ewmEfRRk49KW4kqrIA+Dk665lHvwge2tr9b BYhpHLOeK3lyNQ+zajdUSqe7A7H7v72nLBlx6db29FMsv8zziAHX9a86zL3icwgy7JUSmTS45p1H vfPDzebboovbBBC7I5hV/3JBx1oI+ahaZn66ljK15N3mgNTS+Gd5iynwGSA72Kz4DJDPANnBKLCD deczDvkMkB2MAjtYd1L4AYBvoE9mO+IGfH8efq4V7SvyctPdfjiMg/cu8r/NfHjXB6e+ugzrW4V3 +R+GiVSG/NwrZepZh7xFnxSbIsjLNYu9cJhYX1F+5OHnf4OtOjehzpKbI5Cf44AvG6bVyF+0edvq wwG4Nl9d+8gbG8HVNNoNebuXwNpB2T9Y9X4d1+Evq1JkcSHINPQorr9fZtKQ4M9Y72fi+lx9Pwbn S6x3XHot5zTZ9fwaeQs+HYj0YRbuo4G6gq0jGGQbiGHXySpit5cgH8f950gbT+L+0Lix6wlhA0CP /Cg7L/Kcj/vJOPqXoZ95ZffrTjzc3bxgxxi0DZGvUFk09GFH4aPvagmTlMyrZ1xR1JQEAAjyIyAr zcf1OHOPPEchD8GOph/GPDsE+Tl74xYPT4zkD3evoMyuePcXHF+oAoi4LAUrGf8KSv3iEgO9BM+j gLTYgOB6JI44QEpxIwnPD4miqeA7eYB2l5XhBVyH3zTq57/DmRu64xZYzeSPHda/AiAXWT0nABQN TE2YnaNBnPDTA1yvwrMPLAKRwCfFjPxHJUAeUQKQ/7Dy32Ou0dbPImDwc4rB6McWbZJjvTs0IBgw ZbKZURkM9AI84+ymfmJiKL/gWxDck0tIKCYH+Q9HufAzBtxTxvewCLwQ19R/TMOt5/KSYi/y7Fbr nv2z0/FbAwYrigJSSe5Xu3IbHdeW3ntWQRoQTD/HsURf9wHBfgAi2GFvfuRpAGG2U3CEgESIvk7n NYAQgCNQ38NWu1Fxda8Gipbf5618tLy2OugYBQQ/WeXS2sh/lVNISpq92yWhH8ehIYS6wyT1BQa9 FO+oVLk4ZwAKAcH7d/Ge34FgY7VMJ+Owt+DYXHAvZzTyf4g8vaz8pQChRWTSVyOEyKAeliurI/A+ hTaHlCJiFJCeyPjd7ULxyo2QE0x6BINYa91fiWuj7PFtkXsA3j9nvafYMh/+JPH+ELznRGM6zMp3 v77m7v4p+pp6RAKofRV7EhrO5OudI0NgvqGVh1U+xw6pQ0AIToqvWF2PLvvOsABhNoJ3hJWfesH+ 6PNU3D+Jev89Qg5jgdmApJHvQABI/4zghAnP7rFut2YLfUlUooA8gZy00Y04iBakQqTN/UknEtxO d4BIthilr8BVPONpD8X7ASDYWyyEcyfuqTfMBjWav9QTtrh6hfl0/pXIT3/M0INiLgrIHZE+UczZ aTVuBuDgduUtTlFAaMlwu21sQqfDjWQxGfJbZdVLW/4XZEc9UTkbGgt49yVkjorNqJ0f1z9yCTnB JO6gNoA0oF6GKGxA7otU8ivcGxN5JPLT3O5n5Ylacy9GyvcF7WgUbdpiNFBwW4qs6A/BHIz6/1ii c4dGntsxpC3dlYKdoW4ziLKZddN5w73dzFTc7GE9MPrDPOLnZgYQ6tJr7cJRjx/3DNXQ+dvT5MP9 jyJirWZstiUgv4+0fhk6uAIdlMFHq9NdcE2laydpLiI/CWGbmbejPMVHbEL+sXjBcIlJ3EthYmt8 thiHsbBOixC4IO6Fdu6NABiawihX9PmyrovmtS3K7uakwLPbykmaUuPh820GCDrwhjaZD9ENUg+9 hWd/wplRV4olRkFtK4dZGTE2A74k0tmry3Ue5RagfhuQaRFAKLZsk9dU91iJen+L57ZXbrLFbupD +3ei/buR6WirPk62lgi4Bc2hXEmDYJsBwhbR0KHoCEWB7d3yG0EecYlAHcQXKMdOnmVlehP1VWNA kACclTKhnh+jnNw1iPMzuN+Ay2goPKo/THGKrSJAouLKHgjeHYM2uH+Xk2GrEwHhOoSxqmgplEu0 bCiCjAJn3KggoYPD0MHBeDgRx7dx/BsO810Jvz6ivmDoexHy2g4YI7qv46BipEVV7VauXyDvkVaf KPLsbZx8P9rqJNdNpLcdk8ipVDzsp0m2lx9bCOM4F2Om48oxc/L1xsF24pK9BsP33DYVRpj/Px5B Tz6OfrqaAAAAAElFTkSuQmCCoEYd8Ea2AADY8+MEAuku2OPtcJjJPSIV///Y/+AAEEpGSUYAAQIB AJYAlgAA/+ED10V4aWYAAE1NACoAAAAIAAcBEgADAAAAAQABAAABGgAFAAAAAQAAAGIBGwAFAAAA AQAAAGoBKAADAAAAAQACAAABMQACAAAAHgAAAHIBMgACAAAAFAAAAJCHaQAEAAAAAQAAAKQAAADQ ABbjYAAAJxAAFuNgAAAnEEFkb2JlIFBob3Rvc2hvcCBDUzIgTWFjaW50b3NoADIwMDY6MDk6MDcg MTc6MjU6MzMAAAOgAQADAAAAAf//AACgAgAEAAAAAQAABdygAwAEAAAAAQAAAJkAAAAAAAAABgED AAMAAAABAAYAAAEaAAUAAAABAAABHgEbAAUAAAABAAABJgEoAAMAAAABAAIAAAIBAAQAAAABAAAB LgICAAQAAAABAAACoQAAAAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABAAoAMB IgACEQEDEQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APSSmKkQokJKYlRKmQokIqYFMVIhMQUlMColTIKiQUlMSolSIPgmIPgkpgUykQfBNB8E lLJJ4PglB8ElLQToNSdB8SodQuNmR6YP6Ogem0eY+m7/ADvaj0+1xtIltLTYf7I9o/zlngO7yT3P mgpSSUHwKUHwKSlJJQfApQfApKf/2f/tJrxQaG90b3Nob3AgMy4wADhCSU0EBAAAAAAABxwCAAAC AAIAOEJJTQQlAAAAAAAQRgzyiSa4VtqwnAGhsKeQdzhCSU0D6gAAAAAdpjw/eG1sIHZlcnNpb249 IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+CjwhRE9DVFlQRSBwbGlzdCBQVUJMSUMgIi0vL0FwcGxl IENvbXB1dGVyLy9EVEQgUExJU1QgMS4wLy9FTiIgImh0dHA6Ly93d3cuYXBwbGUuY29tL0RURHMv UHJvcGVydHlMaXN0LTEuMC5kdGQiPgo8cGxpc3QgdmVyc2lvbj0iMS4wIj4KPGRpY3Q+Cgk8a2V5 PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNSG9yaXpvbnRhbFJlczwva2V5PgoJPGRpY3Q+ CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8c3RyaW5nPmNv bS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50 aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxrZXk+Y29tLmFw cGxlLnByaW50LlBhZ2VGb3JtYXQuUE1Ib3Jpem9udGFsUmVzPC9rZXk+CgkJCQk8cmVhbD43Mjwv cmVhbD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jbGllbnQ8L2tleT4KCQkJCTxz dHJpbmc+Y29tLmFwcGxlLnByaW50aW5nbWFuYWdlcjwvc3RyaW5nPgoJCQkJPGtleT5jb20uYXBw bGUucHJpbnQudGlja2V0Lm1vZERhdGU8L2tleT4KCQkJCTxkYXRlPjIwMDYtMDktMDdUMDk6MjQ6 NDVaPC9kYXRlPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5 PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJyYXk+Cgk8L2RpY3Q+ Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNT3JpZW50YXRpb248L2tleT4KCTxk aWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJPHN0cmlu Zz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRpY3Q+CgkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNT3JpZW50YXRpb248L2tleT4KCQkJCTxpbnRlZ2Vy PjE8L2ludGVnZXI+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY2xpZW50PC9rZXk+ CgkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8L3N0cmluZz4KCQkJCTxrZXk+ Y29tLmFwcGxlLnByaW50LnRpY2tldC5tb2REYXRlPC9rZXk+CgkJCQk8ZGF0ZT4yMDA2LTA5LTA3 VDA5OjI0OjQ1WjwvZGF0ZT4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZs YWc8L2tleT4KCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8L2FycmF5PgoJ PC9kaWN0PgoJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTVNjYWxpbmc8L2tleT4K CTxkaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJPHN0 cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJPGtleT5jb20uYXBwbGUu cHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRpY3Q+CgkJCQk8a2V5 PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNU2NhbGluZzwva2V5PgoJCQkJPHJlYWw+MTwv cmVhbD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jbGllbnQ8L2tleT4KCQkJCTxz dHJpbmc+Y29tLmFwcGxlLnByaW50aW5nbWFuYWdlcjwvc3RyaW5nPgoJCQkJPGtleT5jb20uYXBw bGUucHJpbnQudGlja2V0Lm1vZERhdGU8L2tleT4KCQkJCTxkYXRlPjIwMDYtMDktMDdUMDk6MjQ6 NDVaPC9kYXRlPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5 PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJyYXk+Cgk8L2RpY3Q+ Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxSZXM8L2tleT4KCTxk aWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJPHN0cmlu Zz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRpY3Q+CgkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxSZXM8L2tleT4KCQkJCTxyZWFsPjcy PC9yZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNsaWVudDwva2V5PgoJCQkJ PHN0cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCQk8a2V5PmNvbS5h cHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJPGRhdGU+MjAwNi0wOS0wN1QwOToy NDo0NVo8L2RhdGU+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9r ZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQk8L2RpY3Q+CgkJPC9hcnJheT4KCTwvZGlj dD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1WZXJ0aWNhbFNjYWxpbmc8L2tl eT4KCTxkaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJ PHN0cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJPGtleT5jb20uYXBw bGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRpY3Q+CgkJCQk8 a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxTY2FsaW5nPC9rZXk+CgkJ CQk8cmVhbD4xPC9yZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNsaWVudDwv a2V5PgoJCQkJPHN0cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCQk8 a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJCQkJPGRhdGU+MjAwNi0w OS0wN1QwOToyNDo0NVo8L2RhdGU+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3Rh dGVGbGFnPC9rZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQk8L2RpY3Q+CgkJPC9hcnJh eT4KCTwvZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LnN1YlRpY2tldC5wYXBlcl9pbmZvX3Rp Y2tldDwva2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTUFk anVzdGVkUGFnZVJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlj a2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9z dHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJ PGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5Q TUFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQkJCQk8YXJyYXk+CgkJCQkJCTxyZWFsPjAuMDwvcmVh bD4KCQkJCQkJPHJlYWw+MC4wPC9yZWFsPgoJCQkJCQk8cmVhbD43ODM8L3JlYWw+CgkJCQkJCTxy ZWFsPjU1OTwvcmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRp Y2tldC5jbGllbnQ8L2tleT4KCQkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGluZ21hbmFnZXI8 L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0ZTwva2V5PgoJ CQkJCTxkYXRlPjIwMDYtMDktMDdUMDk6MjQ6NDVaPC9kYXRlPgoJCQkJCTxrZXk+Y29tLmFwcGxl LnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJ CQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5Q YWdlRm9ybWF0LlBNQWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20u YXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUucHJp bnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVt QXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5jb20uYXBwbGUucHJp bnQuUGFnZUZvcm1hdC5QTUFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJCQkJPGFycmF5PgoJCQkJ CQk8cmVhbD4tMTg8L3JlYWw+CgkJCQkJCTxyZWFsPi0xODwvcmVhbD4KCQkJCQkJPHJlYWw+ODI0 PC9yZWFsPgoJCQkJCQk8cmVhbD41Nzc8L3JlYWw+CgkJCQkJPC9hcnJheT4KCQkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC50aWNrZXQuY2xpZW50PC9rZXk+CgkJCQkJPHN0cmluZz5jb20uYXBwbGUu cHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0 Lm1vZERhdGU8L2tleT4KCQkJCQk8ZGF0ZT4yMDA2LTA5LTA3VDA5OjI0OjQ1WjwvZGF0ZT4KCQkJ CQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVn ZXI+MDwvaW50ZWdlcj4KCQkJCTwvZGljdD4KCQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5j b20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLlBNUGFwZXJOYW1lPC9rZXk+CgkJPGRpY3Q+CgkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFw cGxlLnByaW50LnBtLlBvc3RTY3JpcHQ8L3N0cmluZz4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQu dGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNv bS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1QYXBlck5hbWU8L2tleT4KCQkJCQk8c3RyaW5nPmlz by1hNDwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jbGllbnQ8L2tl eT4KCQkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludC5wbS5Qb3N0U2NyaXB0PC9zdHJpbmc+CgkJ CQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lm1vZERhdGU8L2tleT4KCQkJCQk8ZGF0ZT4y MDAzLTA3LTAxVDE3OjQ5OjM2WjwvZGF0ZT4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNr ZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+MTwvaW50ZWdlcj4KCQkJCTwvZGljdD4K CQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLlBN VW5hZGp1c3RlZFBhZ2VSZWN0PC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50 LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLnByaW50LnBtLlBvc3RT Y3JpcHQ8L3N0cmluZz4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwv a2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBl ckluZm8uUE1VbmFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQkJCQk8YXJyYXk+CgkJCQkJCTxyZWFs PjAuMDwvcmVhbD4KCQkJCQkJPHJlYWw+MC4wPC9yZWFsPgoJCQkJCQk8cmVhbD43ODM8L3JlYWw+ CgkJCQkJCTxyZWFsPjU1OTwvcmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxl LnByaW50LnRpY2tldC5jbGllbnQ8L2tleT4KCQkJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludGlu Z21hbmFnZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQubW9kRGF0 ZTwva2V5PgoJCQkJCTxkYXRlPjIwMDYtMDktMDdUMDk6MjQ6NDVaPC9kYXRlPgoJCQkJCTxrZXk+ Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9p bnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBs ZS5wcmludC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJPGRpY3Q+CgkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29t LmFwcGxlLnByaW50LnBtLlBvc3RTY3JpcHQ8L3N0cmluZz4KCQkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5 PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJ CQkJPGFycmF5PgoJCQkJCQk8cmVhbD4tMTg8L3JlYWw+CgkJCQkJCTxyZWFsPi0xODwvcmVhbD4K CQkJCQkJPHJlYWw+ODI0PC9yZWFsPgoJCQkJCQk8cmVhbD41Nzc8L3JlYWw+CgkJCQkJPC9hcnJh eT4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY2xpZW50PC9rZXk+CgkJCQkJPHN0 cmluZz5jb20uYXBwbGUucHJpbnRpbmdtYW5hZ2VyPC9zdHJpbmc+CgkJCQkJPGtleT5jb20uYXBw bGUucHJpbnQudGlja2V0Lm1vZERhdGU8L2tleT4KCQkJCQk8ZGF0ZT4yMDA2LTA5LTA3VDA5OjI0 OjQ1WjwvZGF0ZT4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9r ZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJCTwvZGljdD4KCQkJPC9hcnJheT4KCQk8 L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLnBwZC5QTVBhcGVyTmFtZTwv a2V5PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5 PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5wcmludC5wbS5Qb3N0U2NyaXB0PC9zdHJpbmc+CgkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJ PGRpY3Q+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLnBwZC5QTVBhcGVyTmFt ZTwva2V5PgoJCQkJCTxzdHJpbmc+QTQ8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmlu dC50aWNrZXQuY2xpZW50PC9rZXk+CgkJCQkJPHN0cmluZz5jb20uYXBwbGUucHJpbnQucG0uUG9z dFNjcmlwdDwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5tb2REYXRl PC9rZXk+CgkJCQkJPGRhdGU+MjAwMy0wNy0wMVQxNzo0OTozNlo8L2RhdGU+CgkJCQkJPGtleT5j b20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5PgoJCQkJCTxpbnRlZ2VyPjE8L2lu dGVnZXI+CgkJCQk8L2RpY3Q+CgkJCTwvYXJyYXk+CgkJPC9kaWN0PgoJCTxrZXk+Y29tLmFwcGxl LnByaW50LnRpY2tldC5BUElWZXJzaW9uPC9rZXk+CgkJPHN0cmluZz4wMC4yMDwvc3RyaW5nPgoJ CTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5wcml2YXRlTG9jazwva2V5PgoJCTxmYWxzZS8+ CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnR5cGU8L2tleT4KCQk8c3RyaW5nPmNvbS5h cHBsZS5wcmludC5QYXBlckluZm9UaWNrZXQ8L3N0cmluZz4KCTwvZGljdD4KCTxrZXk+Y29tLmFw cGxlLnByaW50LnRpY2tldC5BUElWZXJzaW9uPC9rZXk+Cgk8c3RyaW5nPjAwLjIwPC9zdHJpbmc+ Cgk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQucHJpdmF0ZUxvY2s8L2tleT4KCTxmYWxzZS8+ Cgk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQudHlwZTwva2V5PgoJPHN0cmluZz5jb20uYXBw bGUucHJpbnQuUGFnZUZvcm1hdFRpY2tldDwvc3RyaW5nPgo8L2RpY3Q+CjwvcGxpc3Q+CjhCSU0D 6QAAAAAAeAADAAAASABIAAAAAAMPAi//7v/uAzgCQQNnBXsD4AACAAAASABIAAAAAALYAigAAQAA AGQAAAABAAMDAwAAAAF//wABAAEAAAAAAAAAAAAAAABoCAAZAZAAAAAAACAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADhCSU0D7QAAAAAAEACWAAAAAQACAJYAAAABAAI4QklNBCYAAAAAAA4AAAAA AAAAAAAAP4AAADhCSU0EDQAAAAAABAAAAB44QklNBBkAAAAAAAQAAAAeOEJJTQPzAAAAAAAJAAAA AAAAAAABADhCSU0ECgAAAAAAAQAAOEJJTScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAv ZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAA AQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA/////////////////////////////wPoAAAAAP// //////////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//// /////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQe AAAAAAAEAAAAADhCSU0EGgAAAAADNwAAAAYAAAAAAAAAAAAAAJkAAAXcAAAAAQA1AAAAAQAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAXcAAAAmQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3Qx AAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAmQAAAABS Z2h0bG9uZwAABdwAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdz bGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNl T3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcg AAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRs b25nAAAAAAAAAABCdG9tbG9uZwAAAJkAAAAAUmdodGxvbmcAAAXcAAAAA3VybFRFWFQAAAABAAAA AAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAA AA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25l bnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNs aWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29s b3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAA AAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAA AAAMAAAAAT/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAABOEJJTQQMAAAAAAK9 AAAAAQAAAKAAAAAQAAAB4AAAHgAAAAKhABgAAf/Y/+AAEEpGSUYAAQIAAEgASAAA/+0ADEFkb2Jl X0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwM DAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEM DAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAQAKADASIAAhEB AxEB/90ABAAK/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAA AAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMk FVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk 9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIE QVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLy s4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEA PwD0kpipEKJCSmJUSpkKJCKmBTFSITEFJTAqJUyCokFJTEqJUiD4JiD4JKYFMpEHwTQfBJSySeD4 JQfBJS0E6DUnQfEqHULjZkemD+joHptHmPpu/wA72o9PtcbSJbS02H+yPaP85Z4Du8k9z5oKUklB 8ClB8CkpSSUHwKUHwKSn/9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABv AHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAA AQA4QklNBAYAAAAAAAcACAAAAAEBAP/hOSRodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/ eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4Onht cG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS4xLTExMSI+CiAgIDxy ZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4 LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHht bG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+CiAgICAgICAgIDxkYzpm b3JtYXQ+aW1hZ2UvanBlZzwvZGM6Zm9ybWF0PgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAg ICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwPSJo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5B ZG9iZSBQaG90b3Nob3AgQ1MyIE1hY2ludG9zaDwveGFwOkNyZWF0b3JUb29sPgogICAgICAgICA8 eGFwOkNyZWF0ZURhdGU+MjAwNi0wOS0wN1QxNzoyMjozOCswODowMDwveGFwOkNyZWF0ZURhdGU+ CiAgICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA2LTA5LTA3VDE3OjI1OjMzKzA4OjAwPC94YXA6 TW9kaWZ5RGF0ZT4KICAgICAgICAgPHhhcDpNZXRhZGF0YURhdGU+MjAwNi0wOS0wN1QxNzoyNToz MyswODowMDwveGFwOk1ldGFkYXRhRGF0ZT4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAg IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcE1NPSJo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIj4KICAgICAgICAgPHhhcE1NOkRvY3VtZW50 SUQ+dXVpZDpCNjZBODlGRTQwMjcxMURCQjFEMUNEMzFFOEVFMzE5ODwveGFwTU06RG9jdW1lbnRJ RD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVpZDoxODEzQUYwODQwMjgxMURCQjkwMjkx MjI1NDZGNDhDNzwveGFwTU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAg ICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBob3Rv c2hvcD0iaHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyI+CiAgICAgICAgIDxwaG90 b3Nob3A6Q29sb3JNb2RlPjM8L3Bob3Rvc2hvcDpDb2xvck1vZGU+CiAgICAgICAgIDxwaG90b3No b3A6SGlzdG9yeS8+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp0aWZmPSJodHRwOi8vbnMuYWRvYmUu Y29tL3RpZmYvMS4wLyI+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8L3RpZmY6T3JpZW50 YXRpb24+CiAgICAgICAgIDx0aWZmOlhSZXNvbHV0aW9uPjE1MDAwMDAvMTAwMDA8L3RpZmY6WFJl c29sdXRpb24+CiAgICAgICAgIDx0aWZmOllSZXNvbHV0aW9uPjE1MDAwMDAvMTAwMDA8L3RpZmY6 WVJlc29sdXRpb24+CiAgICAgICAgIDx0aWZmOlJlc29sdXRpb25Vbml0PjI8L3RpZmY6UmVzb2x1 dGlvblVuaXQ+CiAgICAgICAgIDx0aWZmOk5hdGl2ZURpZ2VzdD4yNTYsMjU3LDI1OCwyNTksMjYy LDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgyLDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYs MjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQzMjtBOUEyQTYyMDI5MjgyQzk0QzFENjM0QzA2NzAxMEI2 OTwvdGlmZjpOYXRpdmVEaWdlc3Q+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpleGlmPSJodHRwOi8v bnMuYWRvYmUuY29tL2V4aWYvMS4wLyI+CiAgICAgICAgIDxleGlmOlBpeGVsWERpbWVuc2lvbj4x NTAwPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9u PjE1MzwvZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOkNvbG9yU3BhY2U+LTE8 L2V4aWY6Q29sb3JTcGFjZT4KICAgICAgICAgPGV4aWY6TmF0aXZlRGlnZXN0PjM2ODY0LDQwOTYw LDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMz NDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3Mzgw LDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQx NDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1 LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQxOTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQx OTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwxMCwxMSwxMiwxMywxNCwxNSwxNiwxNywx OCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDs3NDYyMzFCNTI2RUYxODA5NzBERkY1NTBCMTBE RTE1RTwvZXhpZjpOYXRpdmVEaWdlc3Q+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3Jk ZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3 Ij8+/+4ADkFkb2JlAGRAAAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQIBAQEB AQECAgICAgICAgICAgICAgMDAwMDAwMDAwMDAwMDAwEBAQEBAQECAQECAwICAgMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAmQXcAwERAAIRAQMR Af/dAAQAvP/EAaIAAAAGAgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAA BgUEAwcCCAEJAAoLEAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMX UnGBGGKRJUOhsfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+Mp OGbzdSo5OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU 1dbX2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SF o7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo +DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3c2Fif8AHn3cfAevefXX t3rXXBxcX/p/xPv3XusXv3Xuve/de64n2y/xdb697r17r3v3XusJFrj3cfAevefXvbvWusbj6H/Y e/de6x+/de697917r3v3Xuve/de697917rARYke/de669+691icc3/r9f9f37r3XD37r3XvfuvdY GFiR7917rr37r3Xvfuvde9+691737r3WJxY3/r7917rh7917r3v3XusBFiR7917rr37r3Xvfuvde 9+691737r3XBxcX/AKf717917rF7917roi4t7917rB7917r3v3XuuLi6/wCtz7917rD7917r3v3X uve/de697917roi4I9+691g9+691737r3XBxcX/p/wAT7917rF7917r3v3Xuve/de697917riwuD /hz/ALb37r3WH37r3XvfuvdY3H0P+w9+691j9+691737r3WFxZv9fn37r3XH37r3Xvfuvde9+691 737r3WJxzf8Ar9f9f37r3XD37r3XvfuvdYGFiR7917rr37r3XRFwR7917rB7917r3v3Xuve/de69 7917r3v3XusBFiR7917rr37r3XRFwR7917rB7917r3v3Xuve/de697917roi4I9+691g9+691737 r3XFhdf9bn37r3WH37r3XvfuvdYCLEj37r3XXv3Xuve/de697917r3v3XuuDi4v/AE/4n37r3WL3 7r3XvfuvdR/fuvde9+691737r3Xvfuvde9+691jcfQ/7D37r3WP37r3Xvfuvde9+691737r3Xvfu vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Qk9P0v3nZO1IrX0V09TY6f8AlBoJ q0H1H8eO/wDXjjm3to/AOt+fVivunXuve/de66JABJNgOST9APfuvdVC/IrtRuzd91Ax9R5NrbaM +K2+qE+Kr0yWyGZsfzUug8Z4/aSK4Dar+6qzU6AL37q3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//Q3dmHF/6f8T7snxde6x+3utde 9+691H9+691737r3XX49tH4B1vz6690691737r3XBx9D/sPdk+Lr3XD291rroi4I9+691g9+6917 37r3Xvfuvde9+691737r3WJxzf8Ar9f9f37r3XD37r3XFhdT/hz7917rD7917r3v3Xusbj6H/YH/ AIj37r3WP37r3Xvfuvde9+691737r3XBxcX/AKf74+/de6xe/de697917rE4+h/2Hv3XuuHv3Xuv e/de697917r3v3XuuiLgj37r3WD37r3XvfuvdYnHN/6/8R7917rh7917r3v3XusBFiR7917rr37r 3Xvfuvde9+691737r3WFhY/6/Pv3XuuPv3Xuve/de6j+/de697917r3v3Xuve/de697917rARYke /de669+6910RcEe/de6we/de697917rg44v/AE/4n37r3WL37r3Xvfuvde9+691737r3XFhdT/hz 7917rD7917r3v3Xusbj6H/YH/iPfuvdY/fuvde9+691hcWP+v/vj7917rj7917r3v3Xuve/de697 917rE45v/X/iPfuvdcPfuvde9+691gYWJ9+69117917r3v3Xuve/de697917rE4sb/19+691w9+6 91737r3WAixI9+69117917rG4+h/2Hv3Xusfv3Xuve/de697917r3v3Xuve/de6j+/de697917rE 45v/AF9+691w9+691737r3Xvfuvde9+6910RcEe/de6we/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de69 7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3 Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6HD4+UZqexIp7X/AIdhspWMf6BxHQXP/U+3 +x9tyeXXh0e7231vr3v3Xuiw/Kbs3+4+wpMDjakR7i3otRi6fxt+9R4UJpzNeAP0kq600Z4N5Cym 8Zt7rRNBXqqX37rfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+ 691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3 Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9 +691737r3Xvfuvde9+691737r3X/0d3j37r3WH2o611737r3WJxzf+v/ABHv3XuuHv3Xuve/de64 +0/W+ve/de66IuLe9g0NevdYvb/Wuve/de6wuLH/AF+ffuvdcffuvde9+691737r3XvfuvdcWF1P +HPv3XusPv3Xuve/de6wEWJHv3XuuvfuvddEXBHv3XusHv3Xuve/de697917r3v3Xuve/de6wEWN vfuvdde/de64sLj/AHr37r3WH37r3Xvfuvde9+691737r3XvfuvdYnFjf+vv3XuuHv3XuuDi4/1u f+K+/de6xe/de697917rG4+h/wBh7917rH7917r3v3Xuve/de697917rg44v/T37r3WL37r3Xvfu vdYnHN/6/wDEe/de64e/de697917r3v3Xuve/de6xuPof9h7917rH7917r3v3XusLizf6/Pv3Xuu Pv3Xuve/de6jkWNvfuvde9+691737r3Xvfuvde9+691gIsSPfuvdde/de66IuCPfuvdYPfuvde9+ 691wcXH+t/vX59+691i9+691737r3Xvfuvde9+691xYXH+9e/de6w+/de697917rG/0B/wAffuvd Y/fuvde9+691737r3XvfuvdcHFx/rc/8V9+691i9+691737r3WJx9D/sPfuvdcPfuvddMLgj37r3 WD37r3Xvfuvde9+691737r3XvfuvdYnHN/6+/de64e/de64sLr/rc+/de6w+/de697917r3v3Xuv e/de697917rC4s3+vz7917rj7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de69 7917r3v3Xuve/de6NB8ZqAyZLdWUK8U1DjqFGNzc1tRJUSKp+nH263/IuPbL/F1vo33uvXuuDusa s7sqIis7u7BUVFGpmZm4AA5JP09+691TF3b2JJ2Z2FmdwRyO2Ihf+E7dibUBHg8fIy00oRuVNQ7S VTqeQ0hX6Ae/dUrVqdBP791fr3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r/0t3j37r3WNhzf+v/ABHtyPz60euPtzr3XFhdf9bn 37r3WH37r3XvfuvdcT7Zf4ut9e91691737r3WJhYn/Hn3cfAevefXXt3rXXBxcX/AKf8T7917rF7 917r3v3Xuve/de697917r3v3XusBFiR7917rr37r3WNx9D/sPfuvdY/fuvde9+691hcWb/X59+69 1x9+691737r3Xvfuvde9+691icc3/r/xHv3XuuHv3Xuve/de6wMLH/ev9b37r3XXv3Xuve/de697 917r3v3XuuDi4/1uf+K+/de6xe/de697917rARYke/de669+6910wuCPfuvdYPfuvde9+691737r 3XvfuvddEXBHv3XusHv3Xuve/de64sLr/rc+/de6w+/de697917r3v3Xuve/de66IuLf7b/X9+69 1g9+691737r3XBxcX/p/xPv3XusXv3Xuve/de6xOOb/1/wCI9+691w9+691737r3Xvfuvde9+691 jcfQ/wCw9+691j9+691737r3WFxZv9fn37r3XH37r3XvfuvdRyLG3v3Xuve/de697917r3v3Xuve /de6wMLH/ev9b37r3XXv3XuuiLgj37r3WD37r3Xvfuvde9+691737r3XvfuvdYCLEj37r3XXv3Xu umFwR7917rB7917r3v3XusDCxPv3Xuuvfuvde9+691737r3XvfuvdcWF1/1uffuvdYffuvde9+69 1gIsSPfuvdde/de697917r3v3Xuve/de64OLi/8AT/iffuvdYvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6 91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3R2/jhjjTbLyNe62fJ52oKNe+qmo6WKCP/bS +b2weJ630YP3rr3RZ/lP2D/czraoxFHOYs3vR5cHS+Nws0WLCB87VgfUr4WFNcWIadWH09+60TQV 6qf9+631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3X/9Pd49+691xYXH+tz/th7917rH7Uda697917rARYke/de669+691 17aY6lr1vrr3Tr3XvfuvdcWHF/6f8T7snxde6x+3utde9+691H9+691737r3Xvfuvde9+691737r 3WNx9D/sPfuvdY/fuvddEXBHv3XusHv3Xuve/de64OOL/wBP+J9+691i9+691737r3Xvfuvde9+6 91xYXU/4c+/de6w+/de697917rG4+h/2B/4j37r3WP37r3Xvfuvde9+691737r3XvfuvdYCLEj37 r3XXv3XusTjm/wDX/iPfuvdcPfuvde9+691gYWJ9+69117917r3v3Xuve/de697917rE4sb/ANff uvdcPfuvde9+691gIsSPfuvdde/de697917r3v3Xuve/de6wsLE/48+/de64+/de66IuLe/de6we /de697917ri4uv8Arc+/de6w+/de697917r3v3Xuve/de66IuCPfuvdYPfuvde9+691wcXF/6f8A E+/de6xe/de697917rE45v8A1/4j37r3XD37r3Xvfuvde9+691737r3WNx9D/sPfuvdY/fuvde9+ 691hcWP+v/vj7917rj7917r3v3Xuve/de697917rE45v/X/iPfuvdcPfuvde9+691gYWJ9+69117 917rG4+h/wBh7917rH7917r3v3Xuve/de697917r3v3XusBFiR7917rr37r3WJx9D/sPfuvdcPfu vde9+691737r3XvfuvddEXFvfuvdYPfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917 37r3Xvfuvde9+691737r3VjnVWL/AIR17tSkKaHlxceQkBFm8mVkbKNrvzcea1jyLW/HtP1voQvf uvdVDfJbf39+e0MslLO0uG2tfbeL0sDFI9DKf4pVqFJVvLVGQK4/VGkf9Bb3n1Q/GOgA9+6v1737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3X//U3ePfuvde9+691hI5t/T258fyp1rh172517rG4+h/2Hv3Xusfv3Xuve/de64+ 0/W+ve/de697917rD7Uda697917rE45v/X37r3XD37r3Xvfuvde9+691737r3XRFwR7917rB7917 r3v3XusLizf6/Pv3XuuPv3Xuve/de6jkWNvfuvde9+691737r3Xvfuvde9+691gIsSPfuvdde/de 66IuCPfuvdYPfuvde9+691737r3Xvfuvde9+691icc3/AK/8R7917rh7917riwup/wBv/tvfuvdY ffuvde9+691jcfQ/7D37r3WP37r3Xvfuvde9+691737r3XBxcf63P/FffuvdYvfuvde9+691icfQ /wCw9+691w9+691737r3Xvfuvde9+691wccX/p/xPv3XusXv3Xuve/de6xOOb/19+691w9+69173 7r3WAixI9+69117917r3v3Xuve/de697917rC4s3+vz7917rj7917r3v3Xuo/v3Xuve/de64sLg/ 4c/7b37r3WH37r3Xvfuvde9+691737r3XRFwR7917rB7917r3v3XuuDji/8AT/iffuvdYvfuvde9 +691737r3XvfuvdcWF1P+3/23v3XusPv3Xuve/de6xuPof8AYe/de6x+/de66IuCPfuvdYPfuvde 9+691737r3Xvfuvde9+691icfQ/7D37r3XD37r3XTC4I9+691g9+691737r3Xvfuvde9+691737r 3WJxzf8Ar/xHv3XuuHv3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xup+ LoJcrk8di6e/nyVdSUEIAuTLV1C08Yt+fUw9+691aTTwRUtPBSwLohp4YoIU/wBTFCgjjX/YAAe0 /W+gx7n3yOvOuNy7jilEWSFIcdhL31HM5L/JaJ0U8Hw6mqGHF1jb37r3VLRLFizEkkkkk3JJ5JJP P19+69137917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de69 7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3 Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6 97917r3v3Xuve/de697917r3v3Xuv//V3ePfuvde9+691jcfQ/7D3ZPi691x9vda66YXBHv3XusH v3Xuve/de64n2y/xdb697r17r3v3XusTi3P9fdx8B6959de3etdcWF1/1uffuvdYffuvde9+6917 37r3Xvfuvde9+691hcWb/X59+691x9+691wcXF/6f8T7917rF7917r3v3XusTjm/9f8AiPfuvdcP fuvde9+691737r3XvfuvdY3H0P8AsPfuvdY/fuvde9+691hcWb/X59+691x9+691737r3Xvfuvde 9+691xYXU/7f/be/de6w+/de697917rARYke/de669+6910RcEe/de6we/de697917r3v3Xuve/d e697917rARYke/de669+6910wuCPfuvdYPfuvde9+691737r3XvfuvddEXBHv3XusHv3Xuve/de6 4sLr/rc+/de6w+/de697917rG4+h/wBgf+I9+691j9+691737r3Xvfuvde9+691wcXF/6f717917 rF7917r3v3XusTjm/wDX/iPfuvdcPfuvde9+691gIsSPfuvdde/de697917r3v3Xuve/de6wuLH/ AF+ffuvdcffuvde9+691HIsbe/de697917r3v3Xuve/de697917rARYke/de669+6910RcEe/de6 we/de697917rC4s3+vz7917rj7917r3v3Xuve/de697917rphcEe/de6we/de697917rAwsSPfuv dde/de697917r3v3Xuve/de64OLj/W5/4r7917rF7917r3v3Xuve/de697917r3v3Xuve/de6979 17r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xu ve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697 917r3v3Xuve/de697917oWOksP8AxfsbB6k1wYsVWYn/ANo+zgIpX/2FQ8Pto/AOt+fVg3unXuq5 /mjvf73Obd2BSzEwYWnOfy6KwKNk8ghgxkUi24eCm8kg/qKj37qrfD0R/wB+6t1737r3Xvfuvde9 +691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvdf//W3ePfuvde9+6910wuCPfuvdYvajrXXvfuvdYGFiffuvdde/de697917rj7T9b6979 17riwuP9bn/bD37r3WP2o611737r3WAixI9+69117917r3v3Xuve/de697917rg4uL/0/wCJ9+69 1i9+6910RcW9+691g9+691737r3XFxdf9bn37r3WH37r3Xvfuvde9+691737r3XRFwR7917rB791 7r3v3XuuDi4v/T/iffuvdYvfuvde9+691737r3Xvfuvde9+691gIsSPfuvdde/de6xuPof8AYe/d e6x+/de697917rC4sf8AX/3x9+691x9+691737r3Xvfuvde9+691icc3/r9f9f37r3XD37r3Xvfu vdYGFiR/tvfuvdde/de697917r3v3Xuve/de6xOLG/8AX37r3XD37r3XvfuvdYCLEj37r3XXv3Xu uiLgj37r3WD37r3Xvfuvde9+691737r3XRFxb37r3WD37r3XvfuvdcXF1/1uffuvdYffuvde9+69 1jcfQ/7D37r3WP37r3Xvfuvde9+691737r3XBxcX/p/xPv3XusXv3Xuve/de6xOOb/1/4j37r3XD 37r3Xvfuvde9+691737r3WNx9D/sPfuvdY/fuvde9+691hcWb/X59+691x9+691wccX/AKf8T791 7rF7917r3v3Xuve/de697917r3v3XusDCxI9+69117917rG4+h/2B/4j37r3WP37r3Xvfuvde9+6 91737r3XvfuvdYCLEj37r3XXv3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de 697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917o1 /wAZsKf9/NuKReCaTC0r/wCIH31ev+80x9sv8XW+jT1VTT0NLU1tXKkFLR081VUzvwkNPTxmWaVy PwqqSf8AAe69e6o837uqo3vvPcu66gvqzeWqquBHtqgoQ/hxtISLX8NOkUQP5C+/efVD8Y6SXv3V +ve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de69 7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3 Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6 97917r3v3Xuve/de697917r/193j37r3Xvfuvde9+691hIsSP6H3dRqWnXuve3etdY3H0P8AsPfu vdY/fuvde9+691x9p+t9e9+691737r3WIixt7Uda669+691icfQ/7D37r3XD37r3Xvfuvde9+691 737r3XRFxY+/de6we/de697917rE45v/AF/4j37r3XD37r3XvfuvdYCLEj37r3XXv3Xuve/de697 917r3v3XusLizf6/Pv3XuuPv3Xuve/de6j+/de697917r3v3Xuve/de697917rG4+h/2Hv3Xusfv 3XuuiLgj37r3WD37r3XvfuvdcHHF/wCn/E+/de6xe/de697917r3v3Xuve/de64sLqf8OffuvdYf fuvde9+691jcfQ/7A/8AEe/de6x+/de697917r3v3Xuve/de64OLi/8AT/fH37r3WL37r3Xvfuvd YnH0P+w9+691w9+691737r3WBhYn37r3XXv3Xuve/de697917r3v3XusTjm/9f8AiPfuvdcPfuvd e9+691gIsSPfuvdde/de66IuCPfuvdYPfuvde9+691737r3Xvfuvde9+691H9+691737r3XFhcH/ AA5/23v3XusPv3Xuve/de697917r3v3XuuiLgj37r3WD37r3XvfuvdcHHF/6e/de6xe/de697917 qORY2Pv3Xuve/de697917r3v3Xuve/de6xuPof8AYH/iPfuvdY/fuvddEXBHv3XusHv3Xuve/de6 97917r3v3Xuve/de6xOOb/1/4j37r3XD37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691YZ01g/wCBde4GN00VGTikzVVYW1vkm81MSPwRT+FT/iPx9PafrfSG+Ue8jtPqbMU1PL48 huyWLa9JYnV9vXI0uXfSvJU0kc0RP0Bdb3uAfde6qS9+691737r3Xvfuvde9+691737r3Xvfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691// 0N3j37r3Xvfuvde9+691wcfQ/wCw/wCJ92XJp69e64e3utddEXBHv3XusHv3Xuve/de66/Hto/AO t+fXXunXuve/de6xuPof9h7snxde64+3utddMLgj37r3WD37r3Xvfuvde9+691737r3XvfuvdYnH N/6/8R7917rh7917rg4uP9bn/ivv3XusXv3Xuve/de6xuPof9h7917rH7917r3v3Xuve/de69791 7rg4uL/0/wB69+691i9+691737r3WJxzf+v/ABHv3XuuHv3Xuve/de697917r3v3XuuiLgj37r3W D37r3XvfuvdYXFj/AK/Pv3XuuPv3Xuve/de6jkWNvfuvde9+691737r3Xvfuvde9+691gIsSPfuv dde/de66IuCPfuvdYPfuvde9+691737r3Xvfuvde9+691gIsbe/de669+691xYXH+9e/de6w+/de 697917rG/wBAf8ffuvdY/fuvde9+691737r3XvfuvdcHFx/rc/8AFffuvdYvfuvde9+691jcfQ/7 D37r3WP37r3XvfuvdYWFj/r8+/de64+/de697917r3v3Xuve/de6xOOb/wBffuvdcPfuvde9+691 gIsSPfuvdde/de697917r3v3Xuve/de6wuLN/r8+/de64+/de697917qORY29+691737r3WJxzf+ v/Ee/de64e/de697917r3v3Xuve/de66IuCPfuvdYPfuvde9+691hcWb/X59+691x9+691737r3X vfuvde9+691xYXH+9e/de6w+/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917p32/iZc9 nMRhYdQkymRo6EMvJjWpnWKSX/AIpLE24A9+691aDBBFSwQU0CCOCnhjghjWwWOKJBHGgH+AAA9p +t9Vp/Mzdxym+sLtGCXVTbVxAqauPUbJl88VqXV1H100qUrITyNbAAA3Puqt8PROffurde9+6917 37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3Xvfuvdf//R3ePfuvde9+691737r3XRFxb37r3WL2o611737r3WFxZv9fn37r3X H37r3XvfuvdcfafrfXvfuvddMLj3sGhr17rF7f611737r3WBhYke/de669+691737r3Xvfuvde9+ 691wcXH+tz/xX37r3WL37r3XvfuvdYCLEj37r3XXv3XuuiLgj37r3WD37r3Xvfuvde9+691737r3 XRFwR7917rB7917r3v3XuuLC6/63Pv3XusPv3Xuve/de697917r3v3Xuve/de6wuLN/r8+/de64+ /de64OLi/wDT/iffuvdYvfuvde9+691icc3/AK/8R7917rh7917r3v3Xuve/de697917rG4+h/2H v3Xusfv3Xuve/de6wuLN/r8+/de64+/de697917r3v3Xuve/de6xOOb/ANf+I9+691w9+691737r 3WBhY/71/re/de669+6910RcEe/de6we/de697917r3v3Xuve/de697917rARYke/de669+6910w uCPfuvdYPfuvde9+691wccX/AKf8T7917rF7917r3v3Xuve/de697917riwuv+tz7917rD7917r3 v3Xusbj6H/Ye/de6x+/de697917r3v3Xuve/de64OLi/9P8AiffuvdYvfuvde9+691icc3/r/wAR 7917rh7917ri4uv+tz7917rD7917r3v3Xuve/de697917r3v3XusLizf6/Pv3XuuPv3XuuDi4v8A 0/4n37r3WL37r3Xvfuvde9+691737r3XvfuvdYGFj/vX+t7917rr37r3Xvfuvde9+691737r3Xvf uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv fuvde9+691737r3Q9/HnA/xPe0uXkTVT7ex01QrEXUV1eDQ0ykfS5jM7gn6FeOeQ3J5deHR3Zpoq eGWonkWKCCKSaaV2CpFFEuuSR2P0AAJJ/AHtvrfVHG+tzS7y3lufdMuoDOZqur4UcktDSSTkUNNc 8kRwiOMf63v3n1Q/GOkp791fr3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r/9Ld49+691737r3Xvfuvde9+ 691iYWJ/x593HwHr3n117d611wccX/p7917rF7917r3v3XuuJ9sv8XW+ve69e697917rCRYkf0Pu 6jUtOvde9u9a6xuPof8AYH/iPfuvdY/fuvde9+691737r3Xvfuvde9+691gIsSPfuvdde/de6xOP of8AYe/de64e/de697917rAwsT7917rr37r3Xvfuvde9+691737r3WJxY3/r7917rh7917r3v3Xu sBFiR7917rr37r3Xvfuvde9+691737r3XBxcX/p/xPv3XusXv3Xuve/de6j+/de697917ri4uv8A rc+/de6w+/de697917r3v3Xuve/de66IuCPfuvdYPfuvde9+691wccX/AKf8T7917rF7917r3v3X uve/de697917riwup/w59+691h9+691737r3WNx9D/sPfuvdY/fuvde9+691hcWP+v8A74+/de64 +/de697917r3v3Xuve/de6xOOb/1/wCI9+691w9+691737r3WBhYn37r3XXv3XuuiLgj37r3WD37 r3Xvfuvde9+691737r3XvfuvdYCLEj37r3XXv3XuuiLi3+2/1/fuvdYPfuvde9+691737r3Xvfuv ddEXFvfuvdYPfuvde9+691xcXX/W59+691h9+691737r3WAixI9+69117917r3v3Xuve/de69791 7rg4uL/0/wCJ9+691i9+691737r3Ucixt7917r3v3Xuve/de697917r3v3Xusbj6H/Ye/de6x+/d e697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de6PP8fNvnE7IbKyppqdxVstYCRZvsaMmio1YfW2pZ pF/wce0/W+s3yM3X/dHqHdlVHL4q3L0q7bx9mKu0+cf7Sp8TCxDpSmolUjkFePfuvdU8e/de6979 17r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xu ve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3Xuve/de697917r//093j37r3Xvfuvde9+691737r3XBxwD/T/ifexxHXuuHt /rXXvfuvdRyLG3v3Xuve/de66/Hto/AOt+fXXunXuve/de64OPof9h/xPuy5NPXr3XD291rroi4I 9+691g9+691737r3Xvfuvde9+691737r3WJxzf8Ar/xHv3XuuHv3XuuLC4/3r37r3WH37r3Xvfuv dY3+gP8Aj7917rH7917r3v3Xuve/de697917rg4uP9bn/ivv3XusXv3Xuve/de6xuPof9h7917rH 7917r3v3Xuve/de697917r3v3Xuo/v3Xuve/de6xOOb/ANffuvdcPfuvde9+691gIsSPfuvdde/d e697917r3v3Xuve/de6wuLN/r8+/de64+/de697917qORY2Pv3Xuve/de697917r3v3Xuve/de6w EWJHv3XuuvfuvddEXBHv3XusHv3Xuve/de64OLj/AFv96/Pv3XusXv3Xuve/de697917r3v3XuuL C6n/AG/+29+691h9+691737r3WNx9D/sPfuvdY/fuvde9+691icWN/6+/de64e/de697917r3v3X uve/de6xOPof9h7917rh7917r3v3XusLCxP+PPv3XuuPv3Xuve/de697917r3v3XusTjm/8AX37r 3XD37r3XvfuvdYCLEj37r3XXv3Xusbj6H/YH/iPfuvdY/fuvde9+691737r3Xvfuvde9+691H9+6 91737r3WJxzf+v8AxHv3XuuHv3Xuve/de697917r3v3XuuiLgj37r3WD37r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691Nx1BU5XIUOMo08lVkKunoqZP8AjpPVTCKJTb6eoi5/A9+691Z/iMZBhsVjcTS/ 5jGUNJQQmwUtHSQLArMB+SFuf8fafrfREPm3ue82ytlwy/oSt3PkIdR+rk4rDyWHH4rRzc88W5v7 qrfD0Qj37q3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917 37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf//U3ePfuvde9+691737r3Xvfuvde9+6 91h9qOtde9+691icc3/r/wAR7917rh7917r3v3XuuPtP1vr3v3XuuiLi3v3XusXtR1rr3v3XusLi zf6/Pv3XuuPv3Xuve/de697917r3v3XuuLC6n/b/AO29+691h9+691737r3WBhY/71/re/de669+ 6910RcEe/de6we/de697917r3v3Xuve/de697917rARYke/de669+6910wuCPfuvdYPfuvde9+69 1737r3Xvfuvde9+691icc3/r7917rh7917riwuv+tz7917rD7917r3v3Xusbj6H/AGB/4j37r3WP 37r3Xvfuvde9+691737r3XBxcX/p/wAT7917rF7917r3v3XusTjm/wDX/iPfuvdcPfuvde9+6917 37r3XvfuvdY3H0P+w9+691j9+691737r3WFxZv8AX59+691x9+691737r3Ucixt7917r3v3Xuve/ de697917r3v3XusBFiR7917rr37r3XRFwR7917rB7917r3v3XuuDi4/1v98ffuvdYvfuvde9+691 737r3XvfuvddMLgj37r3WD37r3XvfuvdY3+gP+Pv3Xusfv3Xuve/de697917r3v3XuuLC6/63Pv3 XusPv3Xuve/de6xuPof9gf8AiPfuvdY/fuvddMLgj/bf8R7917rB7917r3v3Xuve/de697917r3v 3XusTjm/9f8AiPfuvdcPfuvdcXF1/wBbn37r3WH37r3Xvfuvde9+691737r3XvfuvdYXFj/r8+/d e64+/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6 97917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v 3Xuve/de697917r3v3Xuve/de697917ocvj/ALdOY3uMpLHqpNuUklczEXQ11SDSUEZ/o3qklU/1 j9tyeXXh0ez231vqnX5F7m/vR3BvCpSXXS4qtTbtIAQUSPBxChqQjD6q1Ss8l/8Aav6e/efVD8Y6 BH37q/Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6 91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Xd49+691737r3Xvfuvde9+691737r3WNhz f+v/ABHtyPz60euPtzr3XFxdf9bn37r3WH37r3XvfuvdcfbLZNfXrfXvdevde9+691iYWJ/x593H wHr3n117d611wcXF/wCn/E+/de6xe/de697917r3v3Xuve/de697917rAwsf96/1vfuvdde/de6x uPof9h7917rH7917r3v3XusLix/1/wDfH37r3XH37r3Xvfuvde9+691737r3WJxzf+v/ABHv3Xuu Hv3Xuve/de6wMLE+/de669+691737r3Xvfuvde9+691xYXX/AFuffuvdYffuvde9+691gIsSPfuv dde/de66IuCPfuvdYPfuvde9+691737r3XvfuvddEXFvfuvdYPfuvde9+691xcXX/W59+691h9+6 91737r3Xvfuvde9+6910RcEe/de6we/de697917rg4uL/wBP+J9+691i9+691737r3WJxzf+v/Ee /de64e/de697917r3v3Xuve/de6xuPof9h7917rH7917r3v3XusLix/1/wDfH37r3XH37r3Xvfuv dYCLEj37r3XXv3Xuve/de697917r3v3XusDCxI9+69117917roi4I9+691g9+691737r3Xvfuvde 9+691737r3WAixI9+69117917roi4I9+691g9+691737r3WBhYn37r3XXv3Xuve/de697917r3v3 XuuLi6/63Pv3XusPv3Xuve/de6wEWJHv3Xuuvfuvde9+691737r3XvfuvdcHFxf+n/E+/de6xe/d e697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917o93QW2/4LshcnNHprNx1L5FyR6xRQ3p8eht+CoeZf8ACT2n630K e5s3Btrbue3FVFft8Hh8llpQx4dcfSPVeMc/ViukAckkAc+/de6opqqmetqamsqZWlqaueapnlb9 Us88hmlkb/FmJJ/1/fuvdYvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691/9bd49+691737r3X vfuvde9+691737r3XFhcf63P+2Hv3XusftR1rr3v3XusBFiR7917rr37r3XX49tH4B1vz6690691 737r3XFhxf8Ap/xPuyfF17rH7e611737r3Uf37r3Xvfuvde9+691737r3XvfuvdY3H0P+w9+691j 9+6910RcEe/de6we/de697917rg44v8A0/4n37r3WL37r3Xvfuvde9+691737r3XFhdT/t/9t791 7rD7917r3v3Xusbj6H/Ye/de6x+/de697917r3v3Xuve/de697917rARYke/de669+691icfQ/7D 37r3XD37r3XvfuvdYWFif8effuvdcffuvde9+691737r3XvfuvdYnHN/6/8AEe/de64e/de69791 7rARYke/de669+691737r3Xvfuvde9+691hcWb/X59+691x9+691737r3Uf37r3XvfuvdcWFwf8A Dn/be/de6w+/de697917r3v3Xuve/de66IuCPfuvdYPfuvde9+691wccX/p7917rF7917r3v3Xus Tjm/9fr/AK/v3XuuHv3Xuve/de697917r3v3Xusbj6H/AGB/4j37r3WP37r3XvfuvdYXFj/r/wC+ Pv3XuuPv3Xuve/de697917r3v3XusTj6H/Ye/de64e/de697917rAwsT7917rr37r3WN/oD/AI+/ de6x+/de697917r3v3Xuve/de697917rARYke/de669+691jcfQ/7D37r3WP37r3Xvfuvde9+691 737r3XvfuvdR/fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3XvfuvdPO3cLUbizuJwdLcTZSvp6QOFv4o5ZLTVDD+kaapG/ wB9+691Z5RUkGPo6SgpUEVLRUsFJTRD6RwU0QhhQf6ygD2n630XT5YbiGC6dy1Gsmio3NksXgIdJ s+hp/wCK1lgPqGgpZI2/wa31I9+691U37917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xu ve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6/ /9fd49+691737r3Xvfuvde9+691737r3XvfuvdYSLEj25H59aPXvbnXusbj6H/YH/iPfuvdY/fuv de9+691x9p+t9e9+691737r3WH2o611737r3WJxzf+v/ABHv3XuuHv3Xuve/de697917r3v3Xuui Lgj37r3WD37r3XvfuvdYXFj/AK/Pv3XuuPv3Xuve/de6jkWNvfuvde9+691737r3Xvfuvde9+691 gIsSPfuvdde/de66IuCPfuvdYPfuvde9+691737r3Xvfuvde9+691icfQ/7D37r3XD37r3XTC4I9 +691g9+691737r3WN/oD/j7917rH7917r3v3Xuve/de697917rg4uP8AW5/4r7917rF7917r3v3X usbj6H/Ye/de6x+/de697917r3v3Xuve/de64OLi/wDT/evfuvdYvfuvde9+691icc3/AK/8R791 7rh7917r3v3XusBFiR7917rr37r3Xvfuvde9+691737r3WFxY/6/Pv3XuuPv3Xuve/de6jkWNvfu vde9+691xYXU/wCHPv3XusPv3Xuve/de697917r3v3XuuiLgj37r3WD37r3XvfuvdcHFxf8Ap/vj 7917rF7917r3v3Xuve/de697917riwuP969+691h9+691737r3WN/oD/AI+/de6x+/de66IuCPfu vdYPfuvde9+691737r3Xvfuvde9+691jcfQ/7D37r3WP37r3XTC4I9+691g9+691737r3Xvfuvde 9+691737r3WJxzf+vv3XuuHv3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3 Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6 97917r3v3Xuve/de697917r3v3Xuve/de697917oynxx2x95ncnumojvDhqf7CgZhx/EMghFQ8bf 1igurD+ko9sv8XW+jle69e6ry+be4fJldj7Ujk0/a0GS3BVxhj6jkKhcdQOynj0/b1Fvz6j791Vv h6Ip791br3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve /de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de69791 7r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6//9Dd49+691737r3Xvfuvde9+6917 37r3XvfuvdY3H0P+w/4n3Zcmnr17rj7e6110RcEe/de6we/de697917rifbL/F1vr3uvXuve/de6 xsOb/wBf+I9uR+fWj1x9ude64uLr/rc+/de6w+/de697917r3v3Xuve/de697917rC4sf9fn37r3 XH37r3XBxcX/AKf8T7917rF7917r3v3XusTjm/8AX/iPfuvdcPfuvde9+691737r3XvfuvdY3H0P +w9+691j9+691737r3WFxZv9fn37r3XH37r3Xvfuvde9+691737r3XFhcf717917rD7917r3v3Xu sDCxI9+69117917roi4I9+691g9+691737r3Xvfuvde9+691737r3WAixI9+69117917rphcEf7b /iPfuvdYPfuvde9+691737r3XvfuvddEXBHv3XusHv3Xuve/de64sLr/AK3Pv3XusPv3Xuve/de6 xuPof9h7917rH7917r3v3Xuve/de697917rg4uL/ANP+J9+691i9+691737r3WJxzf8Ar/xHv3Xu uHv3Xuve/de6wEWJHv3Xuuvfuvde9+691737r3XvfuvdYXFm/wBfn37r3XH37r3XvfuvdYCLG3v3 Xuuvfuvde9+691737r3XvfuvdYGFj/vX+t7917rr37r3XRFwR7917rB7917r3v3XusLix/1/98ff uvdcffuvde9+691737r3XvfuvddMLgj37r3WD37r3XvfuvdYGFiffuvdde/de697917r3v3Xuve/ de64sLr/AK3Pv3XusPv3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917qxvq3a/wDdLZWHxsseiuqIjk8ncWYV9daWSOT/AGqJ NEP/ACB7YJqa9b6EP3rr3VP/AMl9xHcPcm7WWTXTYaak29S83EQxNIkVdHcE/wDKWahrcWvY8+/e fVD8Y6Af37q/Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917 37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//9Hd49+691737r3Xvfuvde9+ 691737r3XvfuvddEXFvewaGvXusXt/rXXvfuvdYGFiffuvdde/de697917rj7T9b697917riwuP9 bn/bD37r3WP2o611737r3WAixI9+69117917r3v3Xuve/de697917rg4uL/0/wCJ9+691i9+6917 37r3Uf37r3XvfuvdcWFwf8Of9t7917rD7917r3v3Xuve/de697917roi4I9+691g9+691737r3XB xxf+n/E+/de6xe/de697917r3v3Xuve/de697917rAwsf96/1vfuvdde/de6xuPof9gf+I9+691j 9+691737r3WFxY/6/wDvj7917rj7917r3v3Xuve/de697917rE45v/X/AIj37r3XD37r3XvfuvdY GFiffuvdde/de697917r3v3Xuve/de6xOLG/9ffuvdcPfuvde9+691gIsSPfuvdde/de66IuLf7b /X9+691g9+691737r3Xvfuvde9+691737r3Uf37r3XvfuvdcXF1/1uffuvdYffuvde9+691jcfQ/ 7D37r3WP37r3Xvfuvde9+691737r3XBxxf8Ap/xPv3XusXv3Xuve/de6xOOb/wBf+I9+691w9+69 1737r3Xvfuvde9+691jcfQ/7D37r3WP37r3XvfuvdYXFj/r/AO+Pv3XuuPv3XuuDi4/1v96/Pv3X usXv3Xuve/de697917r3v3Xuve/de6wMLE+/de669+691jcfQ/7D37r3WP37r3Xvfuvde9+69173 7r3XvfuvdYCLEj37r3XXv3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuv e/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6979 17r3v3Xuve/de697917r3v3XuhK6k2x/evfGHpJYvJQUEn8XyQIuhpKBg6RSD+kspiiI44Y+2j8A 6359WKe6de6jVtXBQUdXXVLaKeipp6uofj0Q08Rmlbn+ign37r3VEOays+dzWXzdWL1WYylflak/ W9RkKt6ub1f8Gc+/de6bvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X/9LeY9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691h9qOtde9+691ik+o/wBj7b/0T/V6de8uuHtzr3Xvfuvd cfafrfXvfuvde9+691h9qOtde9+691xPtl/i63173Xr3Xvfuvde9+691737r3XR+h/1j/vXv3Xus XtR1rr3v3XusL/qP+w/3r37r3XH37r3XvfuvdR/fuvde9+691737r3Xvfuvde9+691x9p+t9e9+6 910fof8AWP8AvXv3XusXtR1rr3v3Xuve/de697917r3v3XusT/X/AGH/ABPv3XuuHv3XuuLfQ/6x /wB69tyeXXh1h9ude697917ro+25PLrw669t9b697917r3v3Xuve/de64P8AQf6//Ee7J8XXuuHt 7rXXvfuvdYn+v+w/4n37r3XD37r3Xvfuvde9+691737r3XB/p/sf+I9+691i9+691737r3XE+2X+ LrfXvdevde9+691h9qOtde9+691737r3Xvfuvde9+691gb9R/wBh/vXtuPz68euvbnXuve/de6j+ /de697917rr8e2j8A6359de6de697917r3v3Xuve/de66P0P+sf969+691i9qOtde9+691wf6f7H /iPfuvdYvfuvde9+691737r3XvfuvdcW+h/1j/vXtuTy68OsPtzr3XvfuvddH23J5deHXXtvrfXR +h/1j/vXv3XusXtR1rr3v3Xuve/de697917r3v3XusT/AF/2H/E+/de64e/de64t9D/rH/evbcnl 14dYfbnXuve/de697917r3v3Xuve/de64n2y/wAXW+ve69e697917r3v3Xuve/de697917r3v3Xu ve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6GjpH/j4sl/2qW/9yo/fuvdGg9+6 90m95f8AHobq/wDDbzn/ALrJffuvdVR+/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/ de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve /de6/9mgRh3w/lYAAG5eXhGNLry22uP8hz+TyGD//9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgG BgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgy PC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjL/wAARCAB5A6MDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAA AAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEI I0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlq c3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL /8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLR ChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn 6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3CysrV7G3ZraEsYlJJjGScVP9gs/+fSD/AL9iiw/5 B9t/1yX+QqxQBX+wWf8Az6Qf9+xUE9laia1AtoQGlIOIxyNjVla3BDqnirStHv4o7nTZbK7uZbWV Q0cskb26oXU8MAJXIU5GcNjKqQeGp5p9JthNLJKYNTvbZGkYs3lxTTxoCx5YhUUbjknGSSSTQBuf YLP/AJ9IP+/Yo+wWf/PpB/37FWKKAK/2Cz/59IP+/YqCCytTNdA20JCygDMY4GxaxtJsorP4h+IP KedvO0+ymbzp3lwxlu8hd5O1eOFXCjsBXQW/+vu/+uo/9AWgA+wWf/PpB/37FH2Cz/59IP8Av2Ks Vn61pn9saYbEzeXG8sTSgruEkayKzxsMjKuqshB4wxyCOCALe2VqljcMttCGETEERjIOKn+wWf8A z6Qf9+xXL6DYWcMWuX2kWkFlos8SR2cNrGI4Z9isWuVUYHzlwmcfMsKMCysuOwoAr/YLP/n0g/79 ij7BZ/8APpB/37FWK5fxV4dTUfMv10ex1m6ESxR22pKskcAG8l4kZcGRiygqXQMEQF125oA2XsrU X0S/ZodpickeWMZyv+Jqf7BZ/wDPpB/37FZ+iPbyado0lneT3tq2ngw3VwSZJkIj2u5IBLEYJyBy elbFAFf7BZ/8+kH/AH7FH2Cz/wCfSD/v2KsV5n4b8S6br3jrR9RXW7S4ur7TL7ZaR3St9njMtu8U RjB+WXy1Zn6ksH5KooUA720srVoWLW0JPmyDmMdA5qf7BZ/8+kH/AH7FFn/qG/66yf8AobVYoAr/ AGCz/wCfSD/v2Kgu7K1WFSttCD5sY4jHQuKxvGmkS6umiqmjQavDb6gZZrW4KCMqbeZFZ9+flDuh OAzAchWIxUmiJpsGlz2lhpNppUttexx3lpaxqqJN+7bIKgBwUaNg2AcEAhSCoANz7BZ/8+kH/fsU fYLP/n0g/wC/YqxRQBX+wWf/AD6Qf9+xUCWVqb6Vfs0O0RIQPLGM5b/AVxWoyQ3PiLXNQ1nRo77T 9CvYXW9kmAeyjSCCfMKAZJVyzyHKll2qPNwEHeJ/yEJv+uUf83oAPsFn/wA+kH/fsUfYLP8A59IP +/YqxVPVtNh1nRr7S7hpFgvbeS3kaMgMFdSpIyCM4PoaAJPsFn/z6Qf9+xUFlZWr2NuzW0JYxKST GMk4rnvB+haPBq2r65pulWNiskr6fAltbpERHBIyOWCj7zSiTkHBRIsgEGuosP8AkH23/XJf5CgA +wWf/PpB/wB+xR9gs/8An0g/79irFcn4utLa51TSftenR61HsnX+x2RHMhOw+eqyEJmPbty5UATk BtxVHAN2eytRNagW0IDSkHEY5Gxqn+wWf/PpB/37FYfhiNYvD+lKk0ciG4mZUjDBbcEynyAGAIEW fKwVUjy8FVxtHSUAV/sFn/z6Qf8AfsUfYLP/AJ9IP+/YqxXnepvNpWoJcz2V22vPrECDUkiJi+wy 3aosfmHC7PLcIYvveZmTaf8AW0AdrBZWpmugbaEhZQBmMcDYtT/YLP8A59IP+/Yot/8AX3f/AF1H /oC0X1lFqFnJazPOkb4yYJ3hcYIPDoQw6djz06UAH2Cz/wCfSD/v2KgvbK1SxuGW2hDCJiCIxkHF clYzzQfB/wAMCGWSIz2+k2ztGxVvLlkgjcBhypKuw3DBGcgggGtCzgh0vWde0ewijttNi0y3uYrW JQscUkjXCuUUcKCIkJUYGctjLMSAdJ9gs/8An0g/79ij7BZ/8+kH/fsVYrl/ENlF/wAJZ4Tvt8/n f2hJDt89/L2/ZLo58vOzdn+LG7HGccUAdB9gs/8An0g/79ioHsrUX0S/ZodpickeWMZyv+JrG8Q2 UX/CWeE77fP539oSQ7fPfy9v2S6OfLzs3Z/ixuxxnHFdA/8AyEIf+uUn80oAPsFn/wA+kH/fsUfY LP8A59IP+/YqxXL+ELKLT9Q8U2sLzvGmqpgzzvM5zZ2x5dyWPXueOnSgDoPsFn/z6Qf9+xUFpZWr QsWtoSfNkHMY6BzXLaR4ds9P17SbfT4oGvtOiLaxq0UISS7kMW0RysOWaQv55BZiDGhYfOjV2Fn/ AKhv+usn/obUAH2Cz/59IP8Av2KPsFn/AM+kH/fsVz/xFsorz4ea/wCa86+Tp9xMvkzvFlhE+A2w jcvPKtlT3BrU13R4dZskingjukhcyiznYCC5YIwVJgVbKbmDdDhlVsHGKAJbuytVhUrbQg+bGOIx 0Lip/sFn/wA+kH/fsVzfhmCG00u+tY4o7WWHU1WaxgULBaMfKISEDjYUKSZGNzSMxVCSi9ZQBX+w Wf8Az6Qf9+xR9gs/+fSD/v2K5+ayig+J2n3SPOZLjSr3eHnd0G2S0A2oSVT32gZ6nJrm/GniXTZN Xls73W7SyTStT0zbaSXSxPLIZ4ZZJWXOWiWJ1x2BEpYHajAA71LK1N9Kv2aHaIkIHljGct/gKn+w Wf8Az6Qf9+xQn/IQm/65R/zepJ4VubeWBzIEkQoxjkZGAIxwykFT7ggjtQBH9gs/+fSD/v2KPsFn /wA+kH/fsVxdlpc118KfEGk2CSTTyvrFtAskpZnY3Fwqgu5ySTj5mPuTWh4ds9K0zWTAvhXTdD1C 4t3lgNpHGWkgDIGV2RRtdWaPcuWX5l2s+DtAN2ysrV7G3ZraEsYlJJjGScVP9gs/+fSD/v2KLD/k H23/AFyX+Qrn/HFlFPp+nXTvOJLfVbDYEndEO68gB3ICFf23A46jBoA6D7BZ/wDPpB/37FQT2VqJ rUC2hAaUg4jHI2NXPeLPtF74h0jR10yDVLW4tLqeSzupRHbs8bwBWlO1iVAkfC7W+dkOBtDrqaLJ Yvo2kR6bDJBaWztaJBIctCYleJoycnJVkK5BIOMgkckA1PsFn/z6Qf8AfsUfYLP/AJ9IP+/YqxXL 6TZRWfxD8QeU87edp9lM3nTvLhjLd5C7ydq8cKuFHYCgDoPsFn/z6Qf9+xUEFlama6BtoSFlAGYx wNi1yUPhDQT46hSLTLRp7B31m4u5YEM8s1xLL5S79uSikTHBwQUgIJwa7S3/ANfd/wDXUf8AoC0A H2Cz/wCfSD/v2KPsFn/z6Qf9+xRfWUWoWclrM86RvjJgneFxgg8OhDDp2PPTpXF2cay/BbQ1eaON BplgzJIGK3AAiPkEKCSJceVgKxPmYCtnaQDrb2ytUsbhltoQwiYgiMZBxU/2Cz/59IP+/Yrk9AtL a2k1/wCyadHosf2eNf7HVEQxkLIfPZYyUzJu25QsCIAC24MidpQBX+wWf/PpB/37FH2Cz/59IP8A v2K5/wAQ2UX/AAlnhO+3z+d/aEkO3z38vb9kujny87N2f4sbscZxxUfiK0WXWRLqmnXepaebdEsI rVGdoLvc+5/lI8t2UxhJiQI9j/PHu+cA3XsrUX0S/ZodpickeWMZyv8Aian+wWf/AD6Qf9+xWP4W vrjU/Dvh2/vJPMurrSo5pn2gbnZIixwOBkk9K6CgCv8AYLP/AJ9IP+/Yo+wWf/PpB/37FcfpHh2z 0/XtJt9Piga+06ItrGrRQhJLuQxbRHKw5ZpC/nkFmIMaFh86NVfQf3Vl4I1lPl1HXdn9p3H8V3vs 5Zvn9cOi7f7i5VdqkqQDsbSytWhYtbQk+bIOYx0Dmp/sFn/z6Qf9+xRZ/wCob/rrJ/6G1Z/iLTLP UrW3bU5oF0y0la5vIblQ0M8YicbZNx27VZlkycgGMH3ABofYLP8A59IP+/YqC7srVYVK20IPmxji MdC4rhtX0SIfCzxS5t59PtHiu7yysIHe2W3jWAogKIV+V9plaNgAGlIZSwJPoF5/qF/66x/+hrQA fYLP/n0g/wC/Yo+wWf8Az6Qf9+xViuH8TeHbO4nvd0UF5r2qyhdNnaEGfTYwkaNJG5yVWI7psgoN 7hQQzgkA7D7BZ/8APpB/37FQJZWpvpV+zQ7REhA8sYzlv8BXLeJvDtncT3u6KC817VZQumztCDPp sYSNGkjc5KrEd02QUG9woIZwT2Cf8hCb/rlH/N6AD7BZ/wDPpB/37FH2Cz/59IP+/YqPVrObUdGv rK3u5LOe4t5Io7mPO6FmUgOMEHIJz1HTqK5ey8PabNrOpR6DbR6Ppq2UtjNcaWiwefcOwBKlQBvg CEBsMA0zrkFHBAOs+wWf/PpB/wB+xUFlZWr2NuzW0JYxKSTGMk4rntE0qz0fxlLBFpdjo/mWkhto NNQLHdxrIgaSUhV/eJmMBSMKJXw77mCdRYf8g+2/65L/ACFAB9gs/wDn0g/79ij7BZ/8+kH/AH7F Y/iTS9Lu5be/10QXGmWkUiNZXFv5ySSu0YjcJzmQbWRQFLHzSB1weffUE8P6PoOh6vqMGiLf/aLm 4Mt0sItoA277JFJnAZTNFECuP3aOV2ELgA7GeytRNagW0IDSkHEY5Gxqn+wWf/PpB/37Fc34Gnhu fAHhB4JY5UFlAhZGDAMsBVhx3DAgjsQRXWUAV/sFn/z6Qf8AfsUfYLP/AJ9IP+/Yrj7jw7Zx61aQ 28UE+vyagb+41RYQLi2tfOaRVZ/vbWVRbAbhlCxAKoyinpmi2Wkag97rfhDTU36xOY9VdIpLjzZr tmt3wFJCHfGobdvViMoFG8AHawWVqZroG2hIWUAZjHA2LU/2Cz/59IP+/Yot/wDX3f8A11H/AKAt V9a0z+2NMNiZvLjeWJpQV3CSNZFZ42GRlXVWQg8YY5BHBALH2Cz/AOfSD/v2KgvbK1SxuGW2hDCJ iCIxkHFcNcImmaLq2peHrP7JpN3d6faWttpoWEXSNOiSzRYKhWkExjD8ZESOHwVI3NDt7HTLLWdL g0e00i8VBd3NrZPvgIkQokkZ2qMEQlSNqncjHBBDMAdJ9gs/+fSD/v2KPsFn/wA+kH/fsVYrk/FG k6a1xPqep6faa1I9vHbabpd1Cr5uAZWIjLBgpkBXc2MKsW5jtX5QDpPsFn/z6Qf9+xUD2VqL6Jfs 0O0xOSPLGM5X/E1xXiHwXps1lpllqaR6rq2o29togvryFXZFjSWSWZC25klZPNIOW+cR54BNdxHB Da3Fpb28UcMEVuyRxxqFVFBQAADgADjFAEn2Cz/59IP+/Yo+wWf/AD6Qf9+xViuH0jw7Z6fr2k2+ nxQNfadEW1jVooQkl3IYtojlYcs0hfzyCzEGNCw+dGoA7D7BZ/8APpB/37FQWllatCxa2hJ82Qcx joHNcN4ZsLOHU9BaG0gtp08zzNbSMKdd2xsvDj5m35887zyY9yeaoMq+gWf+ob/rrJ/6G1AB9gs/ +fSD/v2KPsFn/wA+kH/fsVn+ItMs9StbdtTmgXTLSVrm8huVDQzxiJxtk3HbtVmWTJyAYwfcc3Dp M0Ogl49Pkh0ObU2uJtHhhKlbERlAixAA4Z1Sd4gFYh5EKuxKuAdbd2VqsKlbaEHzYxxGOhcVP9gs /wDn0g/79iuX8L3Xn2usW0VvPbWNnqsUNlbTpsaGExW8gUL1VcyMVQ4KKwXC7dq9hQBX+wWf/PpB /wB+xR9gs/8An0g/79iuP8ZaBZpFeaxPZwTKf3tzqcuHutMhVUBa1G3I2hXk4YFWLOqyE7DX1797 ZeN9Zf5tR0Lf/Zlx/FabLOKb5PTLu27++uFbcoCgA7FLK1N9Kv2aHaIkIHljGct/gKn+wWf/AD6Q f9+xQn/IQm/65R/zei/tft2nXNn9ont/PieLzrd9kke4EbkbswzkHsaAD7BZ/wDPpB/37FH2Cz/5 9IP+/Yrk9M0SxsPFV1YrptpoyXNlKsEOknylu4g6hpZHQIRKm6MKMDZ5rFXfcdmh4GhW28NyQIZC kep6gimSRnYgXkw5ZiSx9yST3oA3LD/kH23/AFyX+QoosP8AkH23/XJf5CigAsP+Qfbf9cl/kKsV x0fhXw7cRrPPoGlyzSAO8j2cbMzHkkkjkk07/hD/AAx/0Lmkf+AMX/xNYusuxzvEJdDf1PSU1Lyp UuZ7O8hyIbu22+ZGGxuX5lZWVsDKsCMhTjcqkEVjb6dFYWtrH5cKSsQCxYklXLMzHJZiSSWJJJJJ JJrA/wCEP8Mf9C5pH/gDF/8AE1kax4V8Oxap4fSPQNLRZb90kVbOMB1+zTtg8cjKg/UD0o9suwLE LsejUVyH/CH+GP8AoXNI/wDAGL/4mj/hD/DH/QuaR/4Axf8AxNL267B9YXY07bw7JbeJZ9bOt6lK 86LG9s6weUY1MhROIg+FMrEHdk8ZJrUt/wDX3f8A11H/AKAtcx/wh/hj/oXNI/8AAGL/AOJrI0fw r4dl1TxAkmgaW6xX6JGrWcZCL9mgbA44GWJ+pPrT9suwfWF2PRqz9b0lNc0efTZbme3jm2hng27s BgSpDqysrY2srAgqSCMGsD/hD/DH/QuaR/4Axf8AxNH/AAh/hj/oXNI/8AYv/iaXt12D6wuxpw6R Pp1vqM9xrepak81uEAuzEFjChz8qxogBO/k4JOF9BW5XnPirwr4dt/B+tzwaBpcU0dhO6SJZxqys I2IIIHBBrX/4Q/wx/wBC5pH/AIAxf/E0/bLsH1hW2OvrH1Dw+l9qJvY9QvrKSWJYLkWjqv2iJSxV SxUsmPMk+aMo3znnIXGR/wAIf4Y/6FzSP/AGL/4mj/hD/DH/AELmkf8AgDF/8TS9uuwfWF2Ojjgh tbi0t7eKOGCK3ZI441CqigoAABwABxirlec3HhXw6vjDTYBoGliF7C7doxZx7WYSW4BIxyQGbH1P rWv/AMIf4Y/6FzSP/AGL/wCJp+2XYPrC7HX1jvoJk8UQ642q3xaGKSGO0xD5Ko4TcP8AV7+WjRvv dR6Eisj/AIQ/wx/0Lmkf+AMX/wATR/wh/hj/AKFzSP8AwBi/+Jpe3XYPrC7HT2f+ob/rrJ/6G1WK 5D/hD/DH/QuaR/4Axf8AxNH/AAh/hj/oXNI/8AYv/iaPbrsH1hdjf1bSU1WKD/SZ7W4tpfOt7mDb vifayEgOrKco7r8yn72RggERxabDplh5cbSSySXEck9xKQZJ5C6gu5AAzgAAAAAAKoCgAYn/AAh/ hj/oXNI/8AYv/iaP+EP8Mf8AQuaR/wCAMX/xNHt12D6wux19Fch/wh/hj/oXNI/8AYv/AImj/hD/ AAx/0Lmkf+AMX/xNHt12D6wuxr33huzvrySZ5J44bjH220jYCG9wAF80EZOAADtI3qAr7lAUaCf8 hCb/AK5R/wA3rmP+EP8ADH/QuaR/4Axf/E1kW/hXw63jDUoDoGlmFLC0dYzZx7VYyXAJAxwSFXP0 HpT9suwfWF2PRqK5D/hD/DH/AELmkf8AgDF/8TR/wh/hj/oXNI/8AYv/AIml7ddg+sLsdHpmmw6V avbwNIyPcT3BLkE7pZWlYcAcbnIHtjr1qSw/5B9t/wBcl/kK5j/hD/DH/QuaR/4Axf8AxNZHhXwr 4duPB+iTz6Bpcs0lhA7yPZxszMY1JJJHJJp+2XYPrC7Ho1Zeq6KNSuLe7hv7vT7y3R40ubURlvLc qXQiRHXBKIc4z8owQCQcT/hD/DH/AELmkf8AgDF/8TR/wh/hj/oXNI/8AYv/AIml7ddg+sLsbdnp sOk29laQtI4FxJI8khBaSRxI7ucADLMzNgAAZwABgVqVyH/CH+GP+hc0j/wBi/8AiaP+EP8ADH/Q uaR/4Axf/E0e3XYPrC7HX1jt4fSXWJL651C+uYGlSdLCZ1NvFKqqqso27uNu4KWKhzvA3AEZH/CH +GP+hc0j/wAAYv8A4mj/AIQ/wx/0Lmkf+AMX/wATR7ddg+sLsdPb/wCvu/8ArqP/AEBaL63lu7OS CG9nspGxieAIXTBB4Dqy89OQevrzXMf8If4Y/wChc0j/AMAYv/iaP+EP8Mf9C5pH/gDF/wDE0e3X YPrC7Gnpnhe20/w1HoM93d6hZxIkcJuSivEiBQgVo1QgqVDBvvA87sgYki0lNN0++le5nvLyaIia 7udvmSBQdq/Kqqqrk4VQBkscbmYnI/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo9uuw fWF2OvrD1rw7JrN/ZXa63qVibJ/MhjtVgKiTY6Fz5kTEkrIy4zjocZ5rM/4Q/wAMf9C5pH/gDF/8 TR/wh/hj/oXNI/8AAGL/AOJo9uuwfWF2NPWvDsms39ldrrepWJsn8yGO1WAqJNjoXPmRMSSsjLjO OhxnmtR/+QhD/wBcpP5pXMf8If4Y/wChc0j/AMAYv/iaP+EP8Mf9C5pH/gDF/wDE0e3XYPrC7HX1 h6L4dk0a/vbttb1K+N6/mTR3SwBTJsRA48uJSCFjVcZx1OM81mf8If4Y/wChc0j/AMAYv/iaP+EP 8Mf9C5pH/gDF/wDE0e3XYPrC7FvSPCUmkPZBfEes3FvaOzi2mMASVmVgTIUiV5CS5YlmOWwxyea3 LP8A1Df9dZP/AENq5j/hD/DH/QuaR/4Axf8AxNH/AAh/hj/oXNI/8AYv/iaPbrsH1hdjb8Q6KPEO jT6W9/d2cFwjRzNaiPdJGylWQ70YAEHqADwMEVHcaCbvTrSCfVb57y0lM0GoYhEyOQyk7RH5Z+R2 TlOhz97DVkf8If4Y/wChc0j/AMAYv/iaP+EP8Mf9C5pH/gDF/wDE0e3XYPrC7G3FpsOmWHlxtJLJ JcRyT3EpBknkLqC7kADOAAAAAAAqgKABqVyH/CH+GP8AoXNI/wDAGL/4mj/hD/DH/QuaR/4Axf8A xNHt12D6wuxp3Ph2S58Swa2Nb1KJ4EaNLZFg8oRsYy6cxF8MYlJO7I5wRUniDQTr8EEJ1W+sY4pU mxaCE73R1kQnzI3+6yA8YzznIrI/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj267B9YX Y6dP+QhN/wBco/5vUk8bTW8sSTSQO6FVljClkJH3huBGR15BHqDXKf8ACH+GP+hc0j/wBi/+Jo/4 Q/wx/wBC5pH/AIAxf/E0e3XYPrC7F/TvCcFno+o6Td6jfalY3/nebFd+UuPNZ2lwYkQjcZGPXjjG Kuaboosbhru5v7vUrwoY1ubsRho4yQSiiNEVQSASQMthckhVAxP+EP8ADH/QuaR/4Axf/E0f8If4 Y/6FzSP/AABi/wDiaPbrsH1hdjp7D/kH23/XJf5Cs/xBoJ1+CCE6rfWMcUqTYtBCd7o6yIT5kb/d ZAeMZ5zkVyPhXwr4duPB+iTz6Bpcs0lhA7yPZxszMY1JJJHJJrX/AOEP8Mf9C5pH/gDF/wDE03WX YHiEuht3mii8t7XN/dxX9sm2PUYhGJ+QA+QUKENgEqU25AIAKqRJFY2+nRWFrax+XCkrEAsWJJVy zMxyWYkkliSSSSSSawP+EP8ADH/QuaR/4Axf/E0f8If4Y/6FzSP/AABi/wDiaXt12D6wux19Ydt4 dktvEs+tnW9SledFje2dYPKMamQonEQfCmViDuyeMk1mf8If4Y/6FzSP/AGL/wCJo/4Q/wAMf9C5 pH/gDF/8TR7ddg+sLsdHHpsMWs3OqK0nn3FvDbupI2hY2kZSOM5zK2eew6d5Lf8A193/ANdR/wCg LXMf8If4Y/6FzSP/AABi/wDiaP8AhD/DH/QuaR/4Axf/ABNHt12D6wux099by3dnJBDez2UjYxPA ELpgg8B1ZeenIPX15rHsvCcFp4Xi0B9Rvrm3t/K+yzTeUJLfyihi27UVTsZFYbg2T97cOKof8If4 Y/6FzSP/AABi/wDiaP8AhD/DH/QuaR/4Axf/ABNHt12D6wuxpw6KNNt9Ru5r+71C8uLcRvc3QjDe WgcogEaIuAXc5xn5jkkAAblch/wh/hj/AKFzSP8AwBi/+Jo/4Q/wx/0Lmkf+AMX/AMTR7ddg+sLs aeteHZNZv7K7XW9SsTZP5kMdqsBUSbHQufMiYklZGXGcdDjPNWNV0ZtUuLeUarqVkkSPHJFaSqiz o5XIbKkg/LgMhVl3NhhmsT/hD/DH/QuaR/4Axf8AxNH/AAh/hj/oXNI/8AYv/iaPbrsH1hdjo44I bW4tLe3ijhgit2SOONQqooKAAAcAAcYq5XIf8If4Y/6FzSP/AABi/wDiaP8AhD/DH/QuaR/4Axf/ ABNHt12D6wuxb0jwlJpD2QXxHrNxb2js4tpjAElZlYEyFIleQkuWJZjlsMcnmrlj4bs7G8jmSSeS G3z9itJGBhssghvKAGRkEgbidikqm1SVOR/wh/hj/oXNI/8AAGL/AOJo/wCEP8Mf9C5pH/gDF/8A E0e3XYPrC7HT2f8AqG/66yf+htVPXNFGuW9tEb+7szb3C3CvbCM7mUHaGWRHVgCQwyOGVWGCBWJ/ wh/hj/oXNI/8AYv/AImj/hD/AAx/0Lmkf+AMX/xNHt12D6wuxbu/CUl9oN/pN14j1mVL92+0TsYN 5jaMRmJR5WxEIGflUHJJzyc6gt5bTTIYJr2e9kWVMzzhA75kB5CKq8dOAOnrzWB/wh/hj/oXNI/8 AYv/AImj/hD/AAx/0Lmkf+AMX/xNHt12D6wux19c3f8AhKS8v9Ru4fEes2Jv0VJVtTANqqm0BHaJ nQDLMAG4Z2YYLGqn/CH+GP8AoXNI/wDAGL/4mj/hD/DH/QuaR/4Axf8AxNHt12D6wuxbv/CUl5f6 jdw+I9ZsTfoqSramAbVVNoCO0TOgGWYANwzswwWNbif8hCb/AK5R/wA3rmP+EP8ADH/QuaR/4Axf /E0f8If4Y/6FzSP/AABi/wDiaPbrsH1hdjp7+1+3adc2f2ie38+J4vOt32SR7gRuRuzDOQexrDtv B8UdvJZ3mr6lf6e9lJY/YZfJhgWJwoICwRx8hV2g5+UE4xmqn/CH+GP+hc0j/wAAYv8A4mj/AIQ/ wx/0Lmkf+AMX/wATR7ddg+sLsbem6KLG4a7ub+71K8KGNbm7EYaOMkEoojRFUEgEkDLYXJIVQLlh /wAg+2/65L/IVzH/AAh/hj/oXNI/8AYv/iaP+EP8Mf8AQuaR/wCAMX/xNHt12D6wuxr6zoJ1e8sb qPVb6wms/MMZthCwJcAFissbjcACAwAIDuM4Y1JDpE8GiHT01vUjOXZ/t7mJ58s5c/eQpjnaBswF wBjArE/4Q/wx/wBC5pH/AIAxf/E0f8If4Y/6FzSP/AGL/wCJo9uuwfWF2NfS9JTQdJ0fSYrme4hs 8QxyT7d+xY2Cg7VUcDA6ducnJrYrkP8AhD/DH/QuaR/4Axf/ABNH/CH+GP8AoXNI/wDAGL/4mj26 7B9YXYtx+EpIb2aeLxHrKRTXv22W3UwBXbeG2M/leYUwqpgv9wBc4GKsQ+F7aG9Mhu7uSzFw13Hp 7lDAk7OZDJwu9jvZnAZmUMQQAVTbmf8ACH+GP+hc0j/wBi/+Jo/4Q/wx/wBC5pH/AIAxf/E0e3XY PrC7HT2/+vu/+uo/9AWq+t6SmuaPPpstzPbxzbQzwbd2AwJUh1ZWVsbWVgQVJBGDWB/wh/hj/oXN I/8AAGL/AOJo/wCEP8Mf9C5pH/gDF/8AE0e3XYPrC7GnB4aGy8TU9W1LVkuUjXbdtGgh2MzK0fko mx9zA7x82VQgjaKki0lNN0++le5nvLyaIia7udvmSBQdq/Kqqqrk4VQBkscbmYnI/wCEP8Mf9C5p H/gDF/8AE0f8If4Y/wChc0j/AMAYv/iaPbrsH1hdjr6w9S8OyX2srqkGt6lYTrbi3C26wOoXcWJH mxOVLHbu2kbtiZztFZn/AAh/hj/oXNI/8AYv/iaP+EP8Mf8AQuaR/wCAMX/xNHt12D6wuxtrocPk 6Kkt1dzvpLh4pppAzzMIXhzIcfMSsjEkY5wfarj/APIQh/65SfzSuY/4Q/wx/wBC5pH/AIAxf/E0 f8If4Y/6FzSP/AGL/wCJo9uuwfWF2Ovrm9I8JSaQ9kF8R6zcW9o7OLaYwBJWZWBMhSJXkJLliWY5 bDHJ5qp/wh/hj/oXNI/8AYv/AImj/hD/AAx/0Lmkf+AMX/xNHt12D6wuxf07wnBp89j/AMTG+uLT Tv8AjwspvK8u1+QxrtKoHbEbMg3s3ByctgjYs/8AUN/11k/9DauY/wCEP8Mf9C5pH/gDF/8AE0f8 If4Y/wChc0j/AMAYv/iaPbrsH1hdjb1zRRrlvbRG/u7M29wtwr2wjO5lB2hlkR1YAkMMjhlVhggV XXw9ONLurR/EWsvPcXCXH20yRCWIrswqBYwgQ+Xyu3B3PnO41mf8If4Y/wChc0j/AMAYv/iaP+EP 8Mf9C5pH/gDF/wDE0e3XYPrC7G3FpsOmWHlxtJLJJcRyT3EpBknkLqC7kADOAAAAAAAqgKABqVyH /CH+GP8AoXNI/wDAGL/4mj/hD/DH/QuaR/4Axf8AxNHt12D6wuxp3Phe2ur+5me7u1tLxxJeWClP IunCKmXypfG1EBUMFYLgqQzbpL7w3Z315JM8k8cNxj7baRsBDe4AC+aCMnAAB2kb1AV9ygKMj/hD /DH/AELmkf8AgDF/8TR/wh/hj/oXNI/8AYv/AImj267B9YXY6dP+QhN/1yj/AJvRf2NvqenXNheR +Za3UTwzJuI3IwIYZHIyCelcx/wh/hj/AKFzSP8AwBi/+Jo/4Q/wx/0Lmkf+AMX/AMTR7ddg+sLs a9roJt/Pmm1W+u7+SJoY76cQ+ZAh5xGqxiMcgMcqdxVd24KoB4f0E6BBPCNVvr6OWV5sXYhGx3dp HI8uNPvM5POccYwKyP8AhD/DH/QuaR/4Axf/ABNH/CH+GP8AoXNI/wDAGL/4mj267B9YXY6ew/5B 9t/1yX+QorK8Ff8AIh+Hf+wZbf8AopaK3Ogfa/8AHpD/ANc1/lXP+M7SKaw0+5ZpxJBqljsCTuqH ddwg7kBCv7bgcdRiugtf+PSH/rmv8qztd0M67DBCdTvbKOKVJsWoi+d0dXQnzEb7rIDxjPOc1xfa PP2ka1Yut/8AIX8N/wDYRf8A9JbitaCNoreON5nmdFCtLIFDOQPvHaAMnrwAPYVk63/yF/Df/YRf /wBJbikhLc2q5rS7SK08e675bTt51hZyt5s7yYYy3WQu4navoowB2Arpaxbfw/Jb+Ip9YOs6hK86 iN7Z1g8oopconEYbCmRiDuyeMk0IF1NqsXRP+Qv4k/7CKf8ApLb1tVi6J/yF/En/AGEU/wDSW3oX UFszTvbSK/tHtpmnWN8ZME7wvwc8OhDDp2PtWT4J/wCRC8O/9gu2/wDRS1rXtvLdWjww3k9nI2MT wBC6854Dqy89OQev41U0HRxoOkQaal9dXcNuqxwtciPciKoVUGxVBAA6kE8nmjoHQr+MP+RJ1/8A 7B1x/wCi2rarF8Yf8iTr/wD2Drj/ANFtW1R0Doc1dWVvrXi69sdRj8+2tLC2nt0JK+VLJJOGkUjB DgRJtcfMvO0jc2b/AIWvbjUfCOi313J5lzc2EE0r4A3O0aknA4HJPSpNQ0WK/uFuFubq0mK+VLJa yBGmiyT5bHBOMk4ZcOuW2su5s3oIIra3jt7eJIoYlCRxxqFVFAwAAOAAO1DegN6GTdf8jtpf/YOv P/RltW1WLdf8jtpf/YOvP/RltW1QxPoeV6FpEUWp2tta6DpGniTVr14NXhIWcLBeMTAFEYwXQMgU P/q1c4wpU9JD42nuNbNrDol1LZC8azM6Q3DOGWQxM3EPlbAwJJ83hQTjd8lX4fCccOjHT/7V1BpB eNexXh8kTwys5dthEYXDFnBBU5WRl+6cVPD4dFveGSHVdQiszO1wbBGjWIuzmRjuCeZguSxG/ByV xt+WqbTLbT3M3/hL7iXX/wCzLa10tpBdeQbabVBFe7A2HkEBTldoaQfP8yYI64qOHxtPca2bWHRL qWyF41mZ0huGcMshiZuIfK2BgST5vCgnG75K0/8AhGi9zuuda1S6tPtX2oWUxiMYcSeagDCMSbVf aQN/RQDkcU+Hw6Le8MkOq6hFZmdrg2CNGsRdnMjHcE8zBcliN+Dkrjb8tL3Re6UbLxB4gu766tf+ Eetc2V5HbXUialldrrG5aPMYLFVkywYJ0G0sSQI/+Ep1b7N5X9j2X9rf2p/Z/wBj/tB9v+r83f5n k4/1f7zGPu8Z3/JWlo/h+TSL68um1nUL03jeZNHcrAFL7UQONkakHbGoxnHXjPNW4tItIdauNVRP 9JniWNuBgY6sOM7mAjDHPIijH8IougujnofG09xrZtYdEupbIXjWZnSG4ZwyyGJm4h8rYGBJPm8K CcbvkqDxNfS6tBaSQaday6da63Zxi8mmIlWZLxI3Mcew8A7k3FlP38Argtuw+HRb3hkh1XUIrMzt cGwRo1iLs5kY7gnmYLksRvwclcbflqDUvCNtqJYJqOoWUJnS7WC1kRY1uFkD+aAynJJGSpyhJLbd 53UXVxpxudDWLa/8jtqn/YOs/wD0Zc1tVi2v/I7ap/2DrP8A9GXNJdSVsy/qlpLf6Re2dvdPaTXE DxR3Med0LMpAcYIOQTnqOnWue0HSdGtNfWaLQoND1WK1kia3gjiWO5jZoy0isg/eKrIAM7WUP8yL vWuh1TT4tX0i9024Z1hvIHt5GjIDBXUqSMgjOD6VUsNDNrfi+utTvdRuUiaGJ7oRL5SMVLgCJEBy UT72cbRjGTkT0BPQ1qxfB/8AyJOgf9g63/8ARa1tVi+D/wDkSdA/7B1v/wCi1o6C6G1RRRSEFFFF ABRRRQBheJf9IbSNLf8A49tRvxDcD+9GkUkxT0KsYgjAggozDvkV5NM0nwet5qmlabBBJd/ZbQW1 uiQxNIZSkbHavGWnwzYJ2qMA4wdrUtPi1Sxa1mZ0BZJEkjIDRujB0cZBGVZVOCCDjkEZFUD4btpL GeG4urq4up2jke+kKedujYPERhQgCMAQoXbnJIJZt1JlJ6Gbe+KdWsFmt5dHsjqEUtoGjXUH8ry7 mVoUYP5OdwdTldmNvIJPy1Rfx7qdvHCZ/D8DSS3TwJFbX+9mEd0lrIRvjQbvMkjKgkAgsSyYAOrc +D1u4ZPP1vVHupJYJGu8QCQrA5kiTAi2bVdi33cknBJHFZuu+CbqS0VtGu3a7W8e4Q3U6xrAslzF cyBCIWyd8I27gcb2zuAAprlKXKa0viWW0tbmK8sUj1SBrdPs8c5eJ/tEnlQsJNoOwvkNldy7W+Vh tLVL3xXqemrNFc6LBJeQS2nmQWt7vDRXErRIUZ40y4dTlW2rjB39hpHw3bSWM8NxdXVxdTtHI99I U87dGweIjChAEYAhQu3OSQSzbqlz4PW7hk8/W9Ue6klgka7xAJCsDmSJMCLZtV2LfdyScEkcUlyi XKMuvFlzpdrqA1PTUW+tVt3WK0nedJBPI0UfzeWHzvVtwCMQMEbidtVF8baiNOluX8OT+ZFdW0LJ maISLNJ5Y8szwx7nDEZUhVwwO/qBrXnheG+1S9vptQvd11FBGIl8sJC0L+ZE6fJncrlm+YsDuIII wBHdeFpL2xNvceINXkkM8M/nkwBh5Tb0UL5XlgB8MSF3HABJUAUe6Huklvq+rTSX1g+m2S6rbRQz rEL5zA8cjOozJ5QYMPKk42Efd55ODwbf6nqnhHS77VUgFzPaxS74pN3mho1O9hsUKxJOVGQOxNW4 NHEPiK71j7ddO9zBHbtbMI/KVULFSMLuzl3PLH759Bh+kaWmjWCWMNxPLbRYWBJdv7iMABY1IAJU AcFtzepNJ2E7WDVNF0zW44ItUsYLyKCXzkjnXem/ay5Kng8M3XPr1ArjNAht/Cnw307X9I0ayM8u l2kmoMZTbho1jLNK21G3Mu9mPy7mGepCqe+njaW3kjSZ4XdSqyxhSyEj7w3AjI68gj2NYyaRcaT4 WttF0+CDVYoYhalNTnEYaDaRhikTBsDC428jqSerT6DT0sUNV8V6nYX96ttosF5Y2d1bWskqXuyZ pJjGNixtGF3DzUPLhSGHzZ3BZ7zxU+madetqFhs1K08jdbW8jTI/nyeXEysE3FSwII2bxtbCt8u6 pfeFtQt/A1noWkXCS3cU8E8t3czsjO6TCaSUFkl+dnBOCCBuPUDB1j4btpLGeG4urq4up2jke+kK edujYPERhQgCMAQoXbnJIJZtx7oe6M8Oa/da19pS70ueykg2kMY5ljkDZ4UzRRMWG05AXADLyckD dqhpunS2PmtPqd7fyyYHmXRQbVGcALGqoOp525ORkkBQL9J+RLtfQKKKKQgooooAKKKKAMXwf/yJ Ogf9g63/APRa1tVi+D/+RJ0D/sHW/wD6LWtqm9xy3CiiikIKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooA4jxH4e0u4utUl8QaYl3Y3y4XVDHG76YnlqhGXyyIGBkDqCFLuWChSzaV5 4mu7TR/Et7/Z0DS6JK48r7UQs0axJNu3bPlbY/3cEZGM45qS88Jx3l1qTNquoR2mpsGvLJPJ8qUe WsTLkxmQBkQA7WB6kEGjVvCNtq41GJtR1C2tdSUi7t7aRFWVjGI95YqXB2qgwGCnaMqQWDVddS7r qZNlqDaDq3iyaPTEXSYNRFzeXCSKhQNawM7JGAS5B3O+SpwcrvYla6G91e+tbt4YfDmqXka4xPBJ bBG4zwHmVuOnIHT8aqL4RtvtVzNNqOoTpeMj3sEkieVdFY0jG9QoABCAsF2h8lW3LhR0NDaBtHA3 Xg/w5feK7CK68PWqjUNOv7i6SaNWlMry25JZwSd4MjgFW+XJ2kCtnwzY2lrr3iyS3tYIZJNUTe0c YUt/osD8kdfmd2+rMe5rTn0cTeIrTWPt10j20Elutsoj8plcqWJyu7OUQ8MPuD1OcybwlM82pyQ+ JtatV1GUyzJB9nXBKKg2sYSy4RFAIOeM5zk0Xv1C91Zs5/V9L09NS8ReHksLVpfEE9nIzCFVYrLv WTHGN6JbTzqx/jboT970GCCK2t47e3iSKGJQkccahVRQMAADgADtVS40i0utasdVmTfc2UU0cGQC F8zZuYZGQ2ExkEcMw5zV+k3cTdzmprG0g+JFhdw2sEdzc6XeefMkYDy7ZLULuYctgcDPSqmq+Np7 HWbyytNEur2KyZUuGihuHdmKLJiMRwuhO11wHkTnrgYY61x4fkuPEUGsDWdQieBTGlsiweUEYoXT mMthjGpJ3ZHOCKLnw6Jr64uINV1Czju2D3UFs0YWZgqoSWKGRCUVVyjLjaCMNk09Oo011M258V6n bNrkraLB9j0WVvtU/wBt5eIRJLmNfL5fY3KttUHADtklTWPF13Y60dLsdPsri582KJILm/ME82/b mSOMRuXiUMSz548uTj5ebc/hOO5s9ftZNV1Dy9bYtPjycxAoIyqfu+AUVU+bccDIIbJObfeGNZOo zy2d3uefYVvmv5bd4XEapve3iQRXDApv+fbuyEOFUU1yjXKXrzUtei8c2GnwW1k2my2s8rFrpg7B XgBcjyjhl8xgFDYbdklcCsqDUbjw9f8AjC5tdIgbTbW/N5dyeeIjj7JA7+WgU734ZjuKAlh8xy23 q7zS0u7+zvluJ7e5tdyh4tp3xsVLxsGBG1iiZIww28EZOc2fwnHc2ev2smq6h5etsWnx5OYgUEZV P3fAKKqfNuOBkENklJoSaOhoqOCNoreON5nmdFCtLIFDOQPvHaAMnrwAPYVJUkBRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBX8Ff8iH4d/7Blt/6KWijwV/yIfh3/sGW3/op aK7z0zjpPDuhzyvNNo2nSSuSzu9qhLE8kkkcmm/8Ix4f/wCgFpn/AICR/wCFao6CivyjEYisq0/f e76vufQwhHlWhlf8Ix4f/wCgFpn/AICR/wCFH/CMeH/+gFpn/gJH/hWrRWP1mt/O/vZXJHsZX/CM eH/+gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FatFH1mt/O/vYckexlf8Ix4f/6AWmf+Akf+FH/CMeH/ APoBaZ/4CR/4Vq0UfWa387+9hyR7GV/wjHh//oBaZ/4CR/4Uf8Ix4f8A+gFpn/gJH/hWrRR9Zrfz v72HJHsZX/CMeH/+gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FatFH1mt/O/vYckexlf8Ix4f/6AWmf+ Akf+FH/CMeH/APoBaZ/4CR/4Vq0UfWa387+9hyR7GV/wjHh//oBaZ/4CR/4Uf8Ix4f8A+gFpn/gJ H/hWrRR9Zrfzv72HJHsZX/CMeH/+gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FatFH1mt/O/vYckexlf 8Ix4f/6AWmf+Akf+FH/CMeH/APoBaZ/4CR/4Vq0UfWa387+9hyR7GV/wjHh//oBaZ/4CR/4Uf8Ix 4f8A+gFpn/gJH/hWrRR9Zrfzv72HJHsZX/CMeH/+gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FatFH1m t/O/vYckexlf8Ix4f/6AWmf+Akf+FH/CMeH/APoBaZ/4CR/4Vq0UfWa387+9hyR7GV/wjHh//oBa Z/4CR/4Uf8Ix4f8A+gFpn/gJH/hWrRR9Zrfzv72HJHsZX/CMeH/+gFpn/gJH/hR/wjHh/wD6AWmf +Akf+FatFH1mt/O/vYckexlf8Ix4f/6AWmf+Akf+FH/CMeH/APoBaZ/4CR/4Vq0UfWa387+9hyR7 GV/wjHh//oBaZ/4CR/4Uf8Ix4f8A+gFpn/gJH/hWrRR9Zrfzv72HJHsZX/CMeH/+gFpn/gJH/hR/ wjHh/wD6AWmf+Akf+FatFH1mt/O/vYckexlf8Ix4f/6AWmf+Akf+FH/CMeH/APoBaZ/4CR/4Vq0U fWa387+9hyR7GV/wjHh//oBaZ/4CR/4Uf8Ix4f8A+gFpn/gJH/hWrRR9Zrfzv72HJHsZX/CMeH/+ gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FatFH1mt/O/vYckexlf8Ix4f/6AWmf+Akf+FH/CMeH/APoB aZ/4CR/4Vq0UfWa387+9hyR7GV/wjHh//oBaZ/4CR/4Uf8Ix4f8A+gFpn/gJH/hWrRR9Zrfzv72H JHsZX/CMeH/+gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FatFH1mt/O/vYckexlf8Ix4f/6AWmf+Akf+ FH/CMeH/APoBaZ/4CR/4Vq0UfWa387+9hyR7GV/wjHh//oBaZ/4CR/4Uf8Ix4f8A+gFpn/gJH/hW rRR9Zrfzv72HJHsZX/CMeH/+gFpn/gJH/hR/wjHh/wD6AWmf+Akf+FZMWgab4osdSn1W0imnuLi5 tlmaNWe3RHaFREWBK8Jv9N7Me+KuX/iC5tW1KaGxilsdLz9rke4KScRrK3loEIb5HGMsuTkcDk9T 9s5ckJtyW+tuy3vrroR7trtaFr/hGPD/AP0AtM/8BI/8KP8AhGPD/wD0AtM/8BI/8KzJvEerrq0l jDpFi4F8bJHe/ddzeR54YgQnA2cdTzxyOaZYeMZr20udROleVplrtkmnNwCwiaJJVYJt5Kq4Lrnj +EyHin7LGWvzPo/iXXbr1FzUtrfga3/CMeH/APoBaZ/4CR/4Uf8ACMeH/wDoBaZ/4CR/4VVv/EFz atqU0NjFLY6Xn7XI9wUk4jWVvLQIQ3yOMZZcnI4HJhn8SahbtrEjaTF9l0mRvtEv2vl4xGsuY12c vtblW2jOAGOSRMY4uSTUn/4F6efmvvG3TXT8DQ/4Rjw//wBALTP/AAEj/wAKP+EY8P8A/QC0z/wE j/wrM1LxbNZ6rdWltpNxdx2jKkzRxTs5Yor4QJEyE7WXG51564GGL5/EmoW7axI2kxfZdJkb7RL9 r5eMRrLmNdnL7W5VtozgBjkkNU8Y0nd66/F6efmhXpdvwND/AIRjw/8A9ALTP/ASP/Cj/hGPD/8A 0AtM/wDASP8AwqrdX+sx+L7Kxht7Q2EtvNIxa4IZgrQgtjyzgrvYBd2GzkkYFb9YzqV4KLc3qr7l qMHfTYyv+EY8P/8AQC0z/wABI/8ACj/hGPD/AP0AtM/8BI/8Kz73SNNl8eabcyafaPO1ncSmVoVL F0e3CNnGcqCQD1GeKyrzTrG0g8Z6tbWdvDqNnM89vdJEqyRuLSKTIYDOCxJI6NuYEEE56KanO1qs tVf8eXv+P4Gbsvsr+lc6X/hGPD//AEAtM/8AASP/AAo/4Rjw/wD9ALTP/ASP/CtWiuP6zW/nf3s1 5I9jK/4Rjw//ANALTP8AwEj/AMKP+EY8P/8AQC0z/wABI/8ACtWij6zW/nf3sOSPYyv+EY8P/wDQ C0z/AMBI/wDCj/hGPD//AEAtM/8AASP/AArVoo+s1v5397Dkj2Mr/hGPD/8A0AtM/wDASP8Awo/4 Rjw//wBALTP/AAEj/wAK1aKPrNb+d/ew5I9jK/4Rjw//ANALTP8AwEj/AMKP+EY8P/8AQC0z/wAB I/8ACtWij6zW/nf3sOSPYyv+EY8P/wDQC0z/AMBI/wDCj/hGPD//AEAtM/8AASP/AArVoo+s1v53 97Dkj2Mr/hGPD/8A0AtM/wDASP8Awo/4Rjw//wBALTP/AAEj/wAK1aKPrNb+d/ew5I9jK/4Rjw// ANALTP8AwEj/AMKP+EY8P/8AQC0z/wABI/8ACtWij6zW/nf3sOSPYyv+EY8P/wDQC0z/AMBI/wDC j/hGPD//AEAtM/8AASP/AArVoo+s1v5397Dkj2Mr/hGPD/8A0AtM/wDASP8Awo/4Rjw//wBALTP/ AAEj/wAK1aKPrNb+d/ew5I9jK/4Rjw//ANALTP8AwEj/AMKP+EY8P/8AQC0z/wABI/8ACtWij6zW /nf3sOSPYyv+EY8P/wDQC0z/AMBI/wDCj/hGPD//AEAtM/8AASP/AArVoo+s1v5397Dkj2Mr/hGP D/8A0AtM/wDASP8Awo/4Rjw//wBALTP/AAEj/wAK1aKPrNb+d/ew5I9jK/4Rjw//ANALTP8AwEj/ AMKP+EY8P/8AQC0z/wABI/8ACtWij6zW/nf3sOSPYyv+EY8P/wDQC0z/AMBI/wDCj/hGPD//AEAt M/8AASP/AArVoo+s1v5397Dkj2Mr/hGPD/8A0AtM/wDASP8Awo/4Rjw//wBALTP/AAEj/wAK1aKP rNb+d/ew5I9jK/4Rjw//ANALTP8AwEj/AMKP+EY8P/8AQC0z/wABI/8ACtWij6zW/nf3sOSPYyv+ EY8P/wDQC0z/AMBI/wDCj/hGPD//AEAtM/8AASP/AArVoo+s1v5397Dkj2Mr/hGPD/8A0AtM/wDA SP8Awo/4Rjw//wBALTP/AAEj/wAK1aKPrNb+d/ew5I9jK/4Rjw//ANALTP8AwEj/AMKP+EY8P/8A QC0z/wABI/8ACtWij6zW/nf3sOSPYyv+EY8P/wDQC0z/AMBI/wDCj/hGPD//AEAtM/8AASP/AArV oo+s1v5397Dkj2Mr/hGPD/8A0AtM/wDASP8Awo/4Rjw//wBALTP/AAEj/wAK1aKPrNb+d/ew5I9j K/4Rjw//ANALTP8AwEj/AMKP+EY8P/8AQC0z/wABI/8ACtWij6zW/nf3sOSPYyv+EY8P/wDQC0z/ AMBI/wDCj/hGPD//AEAtM/8AASP/AArVoo+s1v5397Dkj2Mr/hGPD/8A0AtM/wDASP8Awo/4Rjw/ /wBALTP/AAEj/wAK1aKPrNb+d/ew5I9jK/4Rjw//ANALTP8AwEj/AMKP+EY8P/8AQC0z/wABI/8A CtWij6zW/nf3sOSPY3vBX/Ih+Hf+wZbf+iloo8Ff8iH4d/7Blt/6KWiv10+cMEdBRVqPwr4duI1n n0DS5ZpAHeR7ONmZjySSRySad/wh/hj/AKFzSP8AwBi/+Jr4urw2pzlL2u7/AJf+CdSzhRVuT8f+ AU6Kuf8ACH+GP+hc0j/wBi/+Jo/4Q/wx/wBC5pH/AIAxf/E1n/qyv+fv/kv/ANsP+2V/J+P/AACn RVz/AIQ/wx/0Lmkf+AMX/wATR/wh/hj/AKFzSP8AwBi/+Jo/1ZX/AD9/8l/+2D+2V/J+P/AKdFXP +EP8Mf8AQuaR/wCAMX/xNH/CH+GP+hc0j/wBi/8AiaP9WV/z9/8AJf8A7YP7ZX8n4/8AAKdFXP8A hD/DH/QuaR/4Axf/ABNH/CH+GP8AoXNI/wDAGL/4mj/Vlf8AP3/yX/7YP7ZX8n4/8Ap0Vc/4Q/wx /wBC5pH/AIAxf/E0f8If4Y/6FzSP/AGL/wCJo/1ZX/P3/wAl/wDtg/tlfyfj/wAAp0Vc/wCEP8Mf 9C5pH/gDF/8AE0f8If4Y/wChc0j/AMAYv/iaP9WV/wA/f/Jf/tg/tlfyfj/wCnRVz/hD/DH/AELm kf8AgDF/8TR/wh/hj/oXNI/8AYv/AImj/Vlf8/f/ACX/AO2D+2V/J+P/AACnRVz/AIQ/wx/0Lmkf +AMX/wATR/wh/hj/AKFzSP8AwBi/+Jo/1ZX/AD9/8l/+2D+2V/J+P/AKdFXP+EP8Mf8AQuaR/wCA MX/xNH/CH+GP+hc0j/wBi/8AiaP9WV/z9/8AJf8A7YP7ZX8n4/8AAKdFXP8AhD/DH/QuaR/4Axf/ ABNH/CH+GP8AoXNI/wDAGL/4mj/Vlf8AP3/yX/7YP7ZX8n4/8Ap0Vc/4Q/wx/wBC5pH/AIAxf/E0 f8If4Y/6FzSP/AGL/wCJo/1ZX/P3/wAl/wDtg/tlfyfj/wAAp0Vc/wCEP8Mf9C5pH/gDF/8AE0f8 If4Y/wChc0j/AMAYv/iaP9WV/wA/f/Jf/tg/tlfyfj/wCnRVz/hD/DH/AELmkf8AgDF/8TR/wh/h j/oXNI/8AYv/AImj/Vlf8/f/ACX/AO2D+2V/J+P/AACnRVz/AIQ/wx/0Lmkf+AMX/wATR/wh/hj/ AKFzSP8AwBi/+Jo/1ZX/AD9/8l/+2D+2V/J+P/AKdFXP+EP8Mf8AQuaR/wCAMX/xNH/CH+GP+hc0 j/wBi/8AiaP9WV/z9/8AJf8A7YP7ZX8n4/8AAKdFXP8AhD/DH/QuaR/4Axf/ABNH/CH+GP8AoXNI /wDAGL/4mj/Vlf8AP3/yX/7YP7ZX8n4/8Ap0Vc/4Q/wx/wBC5pH/AIAxf/E0f8If4Y/6FzSP/AGL /wCJo/1ZX/P3/wAl/wDtg/tlfyfj/wAAp0Vc/wCEP8Mf9C5pH/gDF/8AE0f8If4Y/wChc0j/AMAY v/iaP9WV/wA/f/Jf/tg/tlfyfj/wCnRVz/hD/DH/AELmkf8AgDF/8TR/wh/hj/oXNI/8AYv/AImj /Vlf8/f/ACX/AO2D+2V/J+P/AACnRVz/AIQ/wx/0Lmkf+AMX/wATR/wh/hj/AKFzSP8AwBi/+Jo/ 1ZX/AD9/8l/+2D+2V/J+P/AKdFXP+EP8Mf8AQuaR/wCAMX/xNH/CH+GP+hc0j/wBi/8AiaP9WV/z 9/8AJf8A7YP7ZX8n4/8AAKdFXP8AhD/DH/QuaR/4Axf/ABNH/CH+GP8AoXNI/wDAGL/4mj/Vlf8A P3/yX/7YP7ZX8n4/8Ap0Vc/4Q/wx/wBC5pH/AIAxf/E0f8If4Y/6FzSP/AGL/wCJo/1ZX/P3/wAl /wDtg/tlfyfj/wAAp0Vc/wCEP8Mf9C5pH/gDF/8AE0f8If4Y/wChc0j/AMAYv/iaP9WV/wA/f/Jf /tg/tlfyfj/wCnRVz/hD/DH/AELmkf8AgDF/8TR/wh/hj/oXNI/8AYv/AImj/Vlf8/f/ACX/AO2D +2V/J+P/AADnp9AguLyeVri4FvcsHurMFfKuGChctld2NqoCoYKQuCCC2WXvh2K9lu/9Nu4ba9/4 /LWPy9lx8oQ5LIXXKKq/Ky8DIwcmuk/4Q/wx/wBC5pH/AIAxf/E0f8If4Y/6FzSP/AGL/wCJrZZB NWtW2/u/8HyX3LsR/a0P5Px/4By48NINRa9OpXxka+F8FPlbVcRmIqPkztMZCnJz8oIIOSc3RvCV xZyXlrd3L/2SzRLFaJMrrOiRJEPOzErZIjUkK205KkEZ3d1/wh/hj/oXNI/8AYv/AImj/hD/AAx/ 0Lmkf+AMX/xNWskqJNe23SXw7W2tqL+1YX+D8f8AgHN3vh2K9lu/9Nu4ba9/4/LWPy9lx8oQ5LIX XKKq/Ky8DIwcmo5vDST2utW76lfbNXbM2PKzGCoQhPk6FFVecnAyCDknqP8AhD/DH/QuaR/4Axf/ ABNH/CH+GP8AoXNI/wDAGL/4mpWQ1FZKtt/dXl5+S+4f9rQ/k/E5ttAPmu8erahEJ9puljMa/aGC qhYts3KSqqP3ZXGMjB5qObw0k9rrVu+pX2zV2zNjysxgqEIT5OhRVXnJwMgg5J6j/hD/AAx/0Lmk f+AMX/xNH/CH+GP+hc0j/wAAYv8A4mhZDNbVv/JV0+fkg/taH8n4mJLpYlmsbg3dwLq1Up542bpU JUurDbtwxRSSoBGOCOav1c/4Q/wx/wBC5pH/AIAxf/E0f8If4Y/6FzSP/AGL/wCJrKXDfNZOrt/d /wCCUs4ivsfj/wAA56fRHn1yHVP7Vvo2iUokCLD5YRihZeYy2GMa5O7I7EVAPDSNeXks2pX01veT edcWb+UIpDtVQpwgbbtRRjdggYbcCc9R/wAIf4Y/6FzSP/AGL/4mj/hD/DH/AELmkf8AgDF/8TWi yGaVlW6W+Fevfvr6k/2tD+T8SnRVz/hD/DH/AELmkf8AgDF/8TR/wh/hj/oXNI/8AYv/AImsf9WV /wA/f/Jf/ti/7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9 /wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg /tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8 n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/ AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0V c/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMAp0Vc/ 4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAM f9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0L mkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/g DF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/ AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/w h/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAI f4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXN I/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzS P/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/ AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4m j/Vlf8/f/Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBW V/z9/wDJf/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f /Jf/ALYP7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJ f/tg/tlfyfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP 7ZX8n4/8Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlf yfj/AMAp0Vc/4Q/wx/0Lmkf+AMX/AMTR/wAIf4Y/6FzSP/AGL/4mj/Vlf8/f/Jf/ALYP7ZX8n4/8 Ap0Vc/4Q/wAMf9C5pH/gDF/8TR/wh/hj/oXNI/8AAGL/AOJo/wBWV/z9/wDJf/tg/tlfyfj/AMA0 vBX/ACIfh3/sGW3/AKKWijwV/wAiH4d/7Blt/wCilor7g5B9r/x6Q/8AXNf5VLUVr/x6Q/8AXNf5 VLXC9zzZbhRRRSEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFcvc+J9 QtrPxHP/AGXau+kzrBBEL1t12zIjhR+6+V2EqBVG7Lnb6EtK40mzqKKjgMrW8bXCJHMVBkSNy6q2 OQGIBIz3wM+grN/tS7TxTHpM1nAttPay3EFwlwWc+W0SsGQoAvMvBDH7vbNKwWNaiiigQUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFfwV/ yIfh3/sGW3/opaKPBX/Ih+Hf+wZbf+ilorvPTH2v/HpD/wBc1/lUtRWv/HpD/wBc1/lUtcL3PNlu FFFFIQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVyeraRd3XjmxkRN+n3 EUUl4SCAv2V3eJQwB+ZpZ0fGV4gb7wJFdZRTTsNOx5l4601bq61e4NnqEWpwwE6ZLZ6Y128ziMFS JvKk8gB/lCIYypDSZ/eAjoZ9Whl8c6RKlpqhiFhPC0h0y4CK8z2zIGbZgcK2c/dwQ2DXWUU+YrmP OvEVmttovjbSV0O6uZdVaS6tIbaxaSOQm2jHmFgNiuJY3bBIckAgEsua+r6Nbarr+oX1/wD26Jrh on0z7JpaO6xeTHjbNJAxt383zOGePYfmO3O4+m0UcwKdjzbxRp1tf65qaSaP/aUr7UWG+0OaYy5i XCW94pCQIc4yfuSGRjxXdWup/atW1Cw+w3sP2Py/9Imi2wz71z+6bPzbejdMGr9FJu4nK6sULXU/ tWrahYfYb2H7H5f+kTRbYZ965/dNn5tvRumDRa6n9q1bULD7Dew/Y/L/ANImi2wz71z+6bPzbejd MGr9FIQUUUUCCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAr +Cv+RD8O/wDYMtv/AEUtFHgr/kQ/Dv8A2DLb/wBFLRXeemPtf+PSH/rmv8qlr5E8Tf8AI16x/wBf 0/8A6GayqwdHzOZ4e73PtCivi+il7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR 7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRX xfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n 2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD 6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR 7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRX xfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n 2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD 6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR 7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRX xfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n 2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD6v5n2hRXxfRR7DzD 6v5n2hRXxfRR7DzD6v5n2R4K/wCRD8O/9gy2/wDRS0UeCv8AkQ/Dv/YMtv8A0UtFdB0n/9kAbh7w ozMAACsdnFFBlozbe/74GKTQUnn/iVBORw0KGgoAAAANSUhEUgAABtYAAALZCAYAAAAjnxWRAAAA CXBIWXMAABcSAAAXEgFnn9JSAAAABGdBTUEAANbY1E9YMgAAABl0RVh0U29mdHdhcmUAQWRvYmUg SW1hZ2VSZWFkeXHJZTwAADMPSURBVHja7N3JcSPJmi5Q72e9BzQANCA1IDQgNUj0ypeXGjREqG3s qMHL0iCoAakBqAEpwXvOzBpy4IAhBh/OMYtws1u3Muv/HLvP3OO/uq77fwEAAAAAoC13Mcb/EQPH 6kL4v2m5kQS06f+IAAAAAABo0F4EHKsL4Soo1aBpijUAAAAAAPhEF8IiLXeSgLYp1gAAAACAFu1F wJFu07MWA7RNsQYAAAAAtGgvAg7VhbBKy04SgGINAAAAAAA+dicC4JViDQAAAABo0V4EHKIL4Tot G0kArxRrAAAAAEBzYoxPUuAzXQiLtPwhCeBvijUAAAAAAHjbbXrWYgD+plgDAAAAAFqzFwGf6UJY pWUnCeBHijUAAAAAoDV7EXCAOxEAv1KsAQAAAADAD7oQrtOykQTwK8UaAAAAANCaBxHwni6ERVr+ kATwFsUaAAAAANCaZxHwgdv0rMUAvEWxBgAAAAAA4dtptVVadpIA3qNYAwAAAABa04uAd9yJAPiI Yg0AAAAAgOZ1IVynZSMJ4COKNQAAAACgNXsR8IY/RAB8RrEGAAAAADQlxvgkBX7UhfC/aVlLAviM Yg0AAAAAgGZ1IazScisJ4BCKNQAAAACgJQ8i4Be79CzFABxCsQYAAAAAtORZBPytC+EqLVtJAIdS rAEAAAAALVGs8aM/RAAcQ7EGAAAAALTEVZB804XwJS2XkgCOoVgDAAAAAKApXQiL4LQacALFGgAA AADQEifWeHWbnqUYgGMp1gAAAACAlvjGWuO6EFZp2UkCOIViDQAAAABoyV4EzbsTAXAqxRoAAAAA 0IwY45MU2tWFcJWWjSSAUynWAAAAAABoxZ0IgHMo1gAAAACAVvQiaFcXwn/SspYEcA7FGgAAAAAA VetCWKRlJwngXIo1AAAAAKAVDyJo1m16lmIAzqVYAwAAAABa8SyC9nQhrILTasBAFGsAAAAAQCsU a236QwTAUBRrAAAAAEArXAXZmC6Eq7TcSAIYimINAAAAAIBaOa0GDEqxBgAAAAA0IcZ4L4V2dCF8 SculJIAhKdYAAAAAAKhKF8IiLTtJAENTrAEAAAAALfB9tbbcpmctBmBoijUAAAAAoAXPImjDX6fV biUBjEGxBgAAAAC0wIm1dvyRnqUYgDEo1gAAAACAFjix1oAuhFVatpIAxqJYAwAAAABasBdBE+5E AIxJsQYAAAAAtGAvgrp1IVylZSMJYEyKNQAAAACgBa6CrN9OBMDYFGsAAAAAQPVijI9SqFcXwpfg tBowAcUaAAAAAFA7p9XqtxMBMAXFGgAAAABQuwcR1KsL4T9pWUsCmIJiDQAAAAConRNrlepCWASn 1YAJKdYAAAAAgNo5sVav2/QsxQBMRbEGAAAAAEBxuhBW4XuxBjAZxRoAAAAAULteBFXaBafVgIkp 1gAAAAAAKMpfp9W2kgCmplgDAAAAAKoWY7yXQnXuRADMQbEGAAAAAEAxuhCu0rKRBDAHxRoAAAAA ULNeBNXZiQCYi2INAAAAAIAiOK0GzE2xBgAAAADUrBdBVe5EAMxJsQYAAAAA1OxZBHXoQviSlrUk gDkp1gAAAACAmj2IoBo7EQBzU6wBAAAAADVzYq0CXQj/CU6rARlQrAEAAAAA1YoxPkqhbF0Ii+C0 GpAJxRoAAAAAUCun1epwm56lGIAcKNYAAAAAgFr5vlrh/jqtdisJIBeKNQAAAACgVnsRFM9pNSAr ijUAAAAAoFZ7EZSrC2EVnFYDMqNYAwAAAABqtRdB0XbBaTUgM4o1AAAAAKBWexGU6a/TaltJALlR rAEAAAAAtXoQQbF2IgBypFgDAAAAAKoUY3yRQnmcVgNyplgDAAAAAGrktFq5diIAcqVYAwAAAABq 9CyC8nQhXAWn1YCMKdYAAAAAgBr1IijSTgRAzhRrAAAAAECNnFgrzF+n1TaSAHKmWAMAAAAAauQb a+XZiQDInWINAAAAAKjRXgTlcFoNKIViDQAAAACoTozxSQpF2YkAKIFiDQAAAACojWsgC+K0GlAS xRoAAAAAUJtnERRlJwKgFIo1AAAAAKA2TqwVwmk1oDSKNQAAAACgNnsRFGMnAqAkijUAAAAAoDZO rBWgC+FLcFoNKIxiDQAAAACozV4ERdiJACiNYg0AAAAAqEqM8UkKefvrtNpaEkBpFGsAAAAAQE1c A1mGnQiAEinWAAAAAICaPIsgb06rASVTrAEAAAAANelFkL2dCIBSKdYAAAAAgJo4sZYxp9WA0inW AAAAAICa+MZa3nYiAEqmWAMAAAAAarIXQZ6cVgNqoFgDAAAAAKoRY3ySQrZ2IgBKp1gDAAAAAGrR iyBPTqsBtVCsAQAAAAC1eBZBtnYiAGqgWAMAAAAAavEggvw4rQbURLEGAAAAANRCsZannQiAWijW AAAAAIBauAoyM10I18FpNaAiijUAAAAAoAoxxnspZOdWBEBNFGsAAAAAQA32IshLF8JVWjaSAGqi WAMAAAAAarAXQXZ2IgBqo1gDAAAAAGrwIIJ8OK0G1EqxBgAAAADUYC+CrOxEANRIsQYAAAAA1MCJ tUw4rQbUTLEGAAAAANRAsZaPnQiAWinWAAAAAIDixRhfpDA/p9WA2inWAAAAAIDS9SLIxk4EQM0U awAAAABA6fYimF8XwkVwWg2onGINAAAAACjdXgRZuBUBUDvFGgAAAABQul4E8+pCWKVlKwmgdoo1 AAAAAKB0exHMbicCoAWKNQAAAACgaDHGJynMx2k1oCWKNQAAAACgZL0IZrcTAdAKxRoAAAAAULJn EczHaTWgNYo1AAAAAKBkDyKY1VYEQEsUawAAAABAyRRrM+lCWKTlVhJASxRrAAAAAEDJ9iKYzWup thQD0BLFGgAAAABQrBjjoxSm57Qa0CrFGgAAAABQKtdAzsdpNaBJijUAAAAAoFR7EcxmKwKgRYo1 AAAAAKBUTqzNoAvhS1rWkgBapFgDAAAAAErVi2AWOxEArVKsAQAAAACl2otgWk6rAa1TrAEAAAAA RYoxPklhcrciAFqmWAMAAAAAStSLYFpdCFdpuZQE0DLFGgAAAABQor0IJrcTAdA6xRoAAAAAUKK9 CKbz12m1jSSA1inWAAAAAIAS9SKY1FYEAIo1AAAAAKBMexFMowthFRRrAN8o1gAAAACA0jzHGJ/E MJmdCAC+U6wBAAAAAKV5EME0uhAWwWk1gH/8twgAAAAAgMI8dF139h8SY5Tk525FAPAvJ9YAAAAA gNLsRTC+v06rKdYAfqBYAwAAAABK4yrIaWzTsxQDwL8UawAAAABAae5FMAmn1QB+oVgDAAAAAEqy F8H4uhC+pGUtCYCfKdYAAAAAgJLsRTCJnQgAfqdYAwAAAABK0otgXF0IV8FpNYA3KdYAAAAAgJI8 DPGHxBgl+b6dCADeplgDAAAAAEqyF8F4uhAu0rKRBMDbFGsAAAAAQEkeRTCqWxEAvE+xBgAAAACU ohfBeLoQVmnZSgLgfYo1AAAAAKAUexGMymk1gE8o1gAAAACAUjyIYBxdCIvgtBrApxRrAAAAAEAp FGvjeT2tthQDwMcUawAAAABAKRRr49mKAOBzijUAAAAAoAT79LyIYXhdCF/SspYEwOcUawAAAABA CfYiGM2tCAAOo1gDAAAAAErQi2B4XQhXabmUBMBhFGsAAAAAQAkG+75ajFGa/9qJAOBwijUAAAAA oAQPIhhWF8IqLRtJABxOsQYAAAAAlOBJBIPbiQDgOIo1AAAAACB3vQiG1YWwSMtWEgDHUawBAAAA ALlzDeTwbkUAcDzFGgAAAACQO8Xa8BRrACdQrAEAAAAAuVOsDagL4UtalpIAOJ5iDQAAAADI3aMI BrUTAcBpFGsAAAAAQM6cVhtQF8JVWtaSADiNYg0AAAAAyJlibVi+rQZwBsUaAAAAAJCzQYu1GGOz QXYhrNJy4ycFcDrFGgAAAACQMyfWhrMTAcB5FGsAAAAAQM7uRXC+LoRFcFoN4GyKNQAAAAAgV06r Def122pLMQCcR7EGAAAAAORqL4LBbEUAcD7FGgAAAACQKyfWBtCF8CUta0kAnE+xBgAAAADkqhfB ILYiABiGYg0AAAAAyJUTa2fqQrhIy0YSAMNQrAEAAAAAOdqn50UMZ7sVAcBwFGsAAAAAQI4GP60W Y2wqwC6ERXANJMCgFGsAAAAAQI5cA3k+p9UABqZYAwAAAABy1IvgbIo1gIEp1gAAAACAHDmxdoYu hC9pWUoCYFiKNQAAAAAgN/v0vIjhLE6rAYxAsQYAAAAA5MZptTN0IVyl5VISAMNTrAEAAAAAuVGs nWcrAoBxKNYAAAAAgNz0IjhNF8IqKNYARqNYAwAAAABy48Ta6bYiABiPYg0AAAAAyMk+PS9D/6Ex xlbyu/UTAhiPYg0AAAAAyInTaifqQviSlqUkAMajWAMAAAAAcqJYO53TagAjU6wBAAAAADnpRXC8 LoSLtFxKAmBcijUAAAAAICdOrJ3GaTWACSjWAAAAAIBc7NPzIobjdCEs0rKVBMD4FGsAAAAAQC56 EZzEaTWAiSjWAAAAAIBcuAbyNFsRAExDsQYAAAAA5GKUYi3GWG1gXQjXaVn76QBMQ7EGAAAAAOTi XgRHcw0kwIQUawAAAABADlwDeaQuhFVaNpIAmI5iDQAAAADIgWLteDsRAExLsQYAAAAA5ECxdoQu hEVabiQBMC3FGgAAAACQg14ER3kt1ZZiAJiWYg0AAAAAyMGjCI6yEwHA9BRrAAAAAMDcehEcrgvh Ki1rSQBMT7EGAAAAAMxttO+rxRhrzGvrJwMwD8UaAAAAADC3BxEcpgthFRRrALNRrAEAAAAAc+tF cLCtCADmo1gDAAAAAOb0nJ4nMRxsKwKA+SjWAAAAAIA5uQbyQF0I12lZSwJgPoo1AAAAAGBOvQgO disCgHkp1gAAAACAOfUi+FwXwiotG0kAzEuxBgAAAADMyVWQh3FaDSADijUAAAAAYC779LyM9YfH GGvKauvnAjA/xRoAAAAAMJdeBJ/rQviSlqUkAOanWAMAAAAA5uIayMO4BhIgE4o1AAAAAGAuirVP dCFcpOVSEgB5UKwBAAAAAHO5F8GnnFYDyIhiDQAAAACYQy+Cj3UhLNJyIwmAfCjWAAAAAIA5uAby c6+l2lIMAPlQrAEAAAAAc+jH/MNjjDVk5BpIgMwo1gAAAACAOTix9oEuhIu0XEoCIC+KNQAAAABg avv0PInhQ06rAWRIsQYAAAAATM1ptQ90ISzSspUEQH4UawAAAADA1HoRfGgrAoA8KdYAAAAAgKk5 sfYx10ACZEqxBgAAAABM7V4Eb+tCuErLWhIAeVKsAQAAAABT6sf+C2KMJeez9RMByJdiDQAAAACY kmsg39GFsAiKNYCsKdYAAAAAgCn1InjXVgQAeVOsAQAAAABTcmLtfbciAMibYg0AAAAAmMo+PU9i +F0XwlVa1pIAyJtiDQAAAACYitNq79uKACB/ijUAAAAAYCq9CH7XhbAIijWAIijWAAAAAICpjH5i LcZYYi5bPw2AMijWAAAAAICp3IvgTVsRAJRBsQYAAAAATKEXwe+6EC7ScikJgDIo1gAAAACAKfQi eNOtCADKoVgDAAAAAKbwIIKfdSEs0nIjCYByKNYAAAAAgCn0IvjNa6m2FANAORRrAAAAAMDYXk+r vYz9l8QYS8vFNZAAhVGsAQAAAABjcw3kL7oQLtJyKQmAsijWAAAAAICx9SL4jdNqAAVSrAEAAAAA Y+tF8JsbEQCUR7EGAAAAAIzpOT1PYvhXF8KXtCwlAVAexRoAAAAAMKZeBL/ZigCgTIo1AAAAAGBM vQj+1YWwSstGEgBlUqwBAAAAAGN6mOIviTGWksetnwRAuRRrAAAAAMCY7kXwkxsRAJRLsQYAAAAA jKUXwb+6EK7TspYEQLkUawAAAADAWHoR/GQrAoCyKdYAAAAAgLE8iOC7LoRVcA0kQPEUawAAAADA WHoR/EOpBlABxRoAAAAAMIbX02ovU/xFMcYS8rj1kwAon2INAAAAABhDL4LvuhCu0rKWBED5FGsA AAAAwBh6EfxjKwKAOijWAAAAAIAxPIjg22m1RfB9NYBqKNYAAAAAgKHt0/Mkhm9eS7WlGADqoFgD AAAAAIbWi+AfWxEA1EOxBgAAAAAMrZ/qL4oxZhtCF8IqLRs/B4B6KNYAAAAAgKH1IvjmVgQAdVGs AQAAAABDeg6+r/a3GxEA1EWxBgAAAAAMqRfBt2sgr9OylgRAXRRrAAAAAMCQehF847QaQIUUawAA AADAkPrWA+hCWKRl66cAUB/FGgAAAAAwlNfvqz1O9ZfFGHPNYeunAFAnxRoAAAAAMJReBN9sRQBQ J8UaAAAAADCUvvUAuhAu0nLppwBQJ8UaAAAAADCUBxE4rQZQM8UaAAAAADCUexEo1gBqplgDAAAA AIbQtx5AF8J1WpZ+CgD1UqwBAAAAAEPop/zLYow5ZrD1MwCom2INAAAAABhC3/LwXQiLtNz4GQDU 7b9FAAAAAAAMYNLvq3Vdd/afMfCpt62fAED9nFgDAAAAAM7Vi0CxBtACxRoAAAAAcK6+5eG7EC7S culnAFA/xRoAAAAAcK6+8fm3fgIAbVCsAQAAAADnum98/q2fAEAbFGsAAAAAwDn6lofvQrhOy9LP AKANijUAAAAA4Bx94/Pf+AkAtEOxBgAAAACcoy/xPzrGePaf0YWwCK6BBGiKYg0AAAAAOEfL31dz Wg2gMYo1AAAAAOBUfePz3/oJALRFsQYAAAAAnKpvdfAuhFVaLv0EANqiWAMAAAAATtU3PPvW9gO0 R7EGAAAAAJyq5e+rbW0/QHsUawAAAADAKfpWB+9CuErL2k8AoD2KNQAAAADgFH3Ds29tP0CbFGsA AAAAwCn6hme/sf0AbVKsAQAAAACnaPL7al0IX9KytP0AbVKsAQAAAADH6hue3Wk1gIYp1gAAAACA Y/Ul/8fHGE/697oQFkGxBtA0xRoAAAAAcKy+0bm3th6gbYo1AAAAAOBY943OvbX1AG1TrAEAAAAA x+hbHLoLYZWWS9sP0DbFGgAAAABwjL7RuW9tPQCKNQAAAADgGH2jc9/YegAUawAAAADAoZ5Dg99X 60K4Ssva9gOgWAMAAAAADtU3OvfW1gPwSrEGAAAAAByqb3Ru10AC8I1iDQAAAAA4VN/awF0I12lZ 2noAXinWAAAAAIBDvH5f7bH0IWKMx/4rW1sPwN8UawAAAADAIfrWBu5CWATXQALwA8UaAAAAAHCI vsGZlWoA/ESxBgAAAAAc4muDM29tOwA/UqwBAAAAAJ/Zp+eppYG7EFZp2dh6AH6kWAMAAAAAPtM3 OLNrIAH4jWINAAAAAPhM3+DMW9sOwK8UawAAAADAZ/qWhu1CuEjLpW0H4FeKNQAAAADgI/vQ2PfV gtNqALxDsQYAAAAAfORrLYPEGA/9v/q+GgBvUqwBAAAAAB/pWxq2C+EqLWvbDsBbFGsAAAAAwEf6 xubd2nIA3qNYAwAAAADe85Cel8Zmdg0kAO9SrAEAAAAA7+lbGrYL4TotS9sOwHsUawAAAADAe742 Nq/TagB8SLEGAAAAALznvpVBuxAWQbEGwCcUawAAAADAW/rG5n0t1VwDCcCHFGsAAAAAwFtcAwkA v1CsAQAAAABv6WsaJsb47j9zDSQAh1KsAQAAAAC/ek7PY0PzKtUAOIhiDQAAAAD4Vd/YvLe2HIBD KNYAAAAAgF818321LoRVWi5tOQCHUKwBAAAAAL/qG5rVNZAAHEyxBgAAAAD8aJ+ep4bm3dpyAA6l WAMAAAAAftS3MqhrIAE4lmINAAAAAPjR14ZmdQ0kAEdRrAEAAAAAP+prGyjG+N4/urXdABxDsQYA AAAA/O0hPS8tDNqFcJGWtS0H4BiKNQAAAADgby1dA7m13QAcS7EGAAAAAPytb2hW31cD4GiKNQAA AADg1XN67lsY1DWQAJxKsQYAAAAAvOobmnVruwE4hWINAAAAAHjVNzSrayABOIliDQAAAAB49bWF IbsQroJrIAE4kWINAAAAANin56nGwWKMv/5PW9sNwKkUawAAAABA39CsroEE4GSKNQAAAACglWsg r9OytN0AnEqxBgAAAAD0jczptBoAZ1GsAQAAAEDbHtLz0sisijUAzqJYAwAAAIC2uQYSAA6kWAMA AACAtvWNzOm0GgBnU6wBAAAAQLue03PfyKyKNQDOplgDAAAAgHb1NQ8XY/y2ugYSgKEo1gAAAACg XV8bmdNpNQAGoVgDAAAAgHb1jcypWANgEIo1AAAAAGjTPj1PtQ/pGkgAhqRYAwAAAIA2uQYSAI6k WAMAAACANvWNzKlYA2AwijUAAAAAaNOftQ/YhfAluAYSgAEp1gAAAACgPdVfAxljfF2cVgNgUIo1 AAAAAGhPX/uAXQiLoFgDYGCKNQAAAABoT9/AjEo1AAanWAMAAACAtuzT89jAnIo1AAanWAMAAACA tvTVTxijayABGIViDQAAAADa8rWBGZVqAIxCsQYAAAAAbekbmFGxBsAoFGsAAAAA0I4+PS9VT+ga SABGpFgDAAAAgHa4BhIAzqBYAwAAAIB29A3MuLHNAIxFsQYAAAAAbdin57GBOZ1YA2A0ijUAAAAA aENf/YQxXqf30lYDMBbFGgAAAAC0wffVAOBMijUAAAAAaEPfwIyKNQBGpVgDAAAAgPr16XmpekLX QAIwAcUaAAAAANTPNZAAMADFGgAAAADUr29gRsUaAKNTrAEAAABA3fbpeax6QtdAAjARxRoAAAAA 1K1vYEan1QCYhGINAAAAAOrm+2oAMBDFGgAAAADUra96OtdAAjAhxRoAAAAA1KtPz0vlMzqtBsBk FGsAAAAAUC/XQALAgBRrAAAAAFCvvurpXAMJwMQUawAAAABQp316HiufcWObAZiSYg0AAAAA6tQ3 MKNrIAGYlGINAAAAAOpU9/fVYrxI77VtBmBKijUAAAAAqNOflc+3tcUATE2xBgAAAAD1+drAjK6B BGByijUAAAAAqE9f9XSugQRgJoo1AAAAAKhP7SfWtrYYgDko1gAAAACgLvv0PFU+o2sgAZiFYg0A AAAA6lL3abUYV8E1kADMRLEGAAAAAHWp/RpIp9UAmI1iDQAAAADq8Zye+8pn3NpmAOaiWAMAAACA evRVT/f9GshL2wzAXBRrAAAAAFAP10ACwIgUawAAAABQj9qLta0tBmBOijUAAAAAqMNDel6qnS7G RXANJAAzU6wBAAAAQB3uKp/PNZAAzE6xBgAAAAB16CufT7EGwOwUawAAAABQvn16Hqud7vs1kIo1 AGanWAMAAACA8vWVz6dUAyALijUAAAAAKN/XyudTrAGQBcUaAAAAAJTvz8rn29hiAHKgWAMAAACA stV9Wi3G6/Re2mYAcqBYAwAAAICyuQYSACaiWAMAAACAsvWVz6dYAyAbijUAAAAAKNdDep6qnS7G q+AaSAAyolgDAAAAgHK5BhIAJqRYAwAAAIByKdYAYEKKNQAAAAAo0z49j9VOF+NFeq9tMwA5UawB AAAAQJn6yudzWg2A7CjWAAAAAKBMroEEgIkp1gAAAACgTH9WO1mMq/S+tMUA5EaxBgAAAADlcVoN AGagWAMAAACA8ijWAGAGijUAAAAAKE9f7WQxLtJ7Y4sByJFiDQAAAADK8pCep4rnc1oNgGwp1gAA AACgLHeVz6dYAyBbijUAAAAAKEtf+XwbWwxArhRrAAAAAFCOfXoeq50uxuv0XtpmAHKlWAMAAACA cnytfD7XQAKQNcUaAAAAAJSjr3w+xRoAWVOsAQAAAEAZntPzZ7XTxXgRXAMJQOYUawAAAABQhtqv gdzaYgByp1gDAAAAgDL0lc/nGkgAsqdYAwAAAIAy1HtiLcZVeq9tMQC5U6wBAAAAQP5eS7WXiudz Wg2AIijWAAAAACB/feXzKdYAKIJiDQAAAADyV/M1kIv03thiAEqgWAMAAACAvD2k56ni+ZxWA6AY ijUAAAAAyNvXyudTrAFQDMUaAAAAAOSt9mJtY4sBKIViDQAAAADytU/PY7XTxXid3kvbDEApFGsA AAAAkC+n1QAgI4o1AAAAAMhXX/l8vq8GQFEUawAAAACQp+f0/FntdDFepPfaNgNQEsUaAAAAAOSp 9msgnVYDoDiKNQAAAADIk2INADKjWAMAAACAPPXVThbjKr0vbTEApVGsAQAAAEB+Xk+rvVQ838YW A1AixRoAAAAA5Mc1kACQIcUaAAAAAORHsQYAGVKsAQAAAEBeHkLN10DGeG2LASiVYg0AAAAA8nJX +XxOqwFQLMUaAAAAAOSl9msgN7YYgFIp1gAAAAAgH6/XQD5VO12MF+m9ts0AlEqxBgAAAAD5qP20 mmsgASiaYg0AAAAA8qFYA4CMKdYAAAAAIA/79DxWO12Mq/S+tM0AlEyxBgAAAAB5qP202sYWA1A6 xRoAAAAA5OGu8vlcAwlA8RRrAAAAADC/51DzNZDfKdYAKJ5iDQAAAADmV/c1kDFe22IAaqBYAwAA AID5+b4aABRAsQYAAAAA83q9BvLPymd0DSQAVVCsAQAAAMC8ar8G8iK917YZgBoo1gAAAABgXn3l 821sMQC1UKwBAAAAwLxq/76aayABqIZiDQAAAADm81qqvVQ7XYyL4MQaABVRrAEAAADAfJxWA4CC KNYAAAAAYD61F2sbWwxATRRrAAAAADCPuq+B/M6JNQCqolgDAAAAgHn0VU8X40V6L20zADVRrAEA AADAPGq/BnJriwGojWINAAAAAKb3kJ6nymfc2GYAaqNYAwAAAIDp3VU9XYyr9L60zQDURrEGAAAA ANOr/RrIjS0GoEaKNQAAAACYVgvXQN7YZgBqpFgDAAAAgGndNTDjxjYDUCPFGgAAAABMq+5rIGO8 Tu+lbQagRoo1AAAAAJjOPtR/DeTGNgNQK8UaAAAAAEznawMz+r4aANVSrAEAAADAdO6qni7GVXqv bTMAtVKsAQAAAMA09ul5rHxGp9UAqJpiDQAAAACm0cI1kBvbDEDNFGsAAAAAMI27BmZ0Yg2AqinW AAAAAGB8+1D7NZAxXttmAGqnWAMAAACA8bkGEgAqoFgDAAAAgPHdNTCjayABqJ5iDQAAAADGtQ/1 XwO5Su+1rQagdoo1AAAAABhXC9dAOq0GQBMUawAAAAAwrr6BGTe2GYAWKNYAAAAAYDzP6fmzgTmd WAOgCYo1AAAAABhP/ddAxnhtmwFohWINAAAAAMbTwvfVNrYZgFYo1gAAAABgHK6BBIDKKNYAAAAA YBwtXAO5Su+1rQagFYo1AAAAABhHC9dAOq0GQFMUawAAAAAwvFaugdzYagBaolgDAAAAgOF9bWRO J9YAaIpiDQAAAACG18L31a5tMwCtUawBAAAAwLBcAwkAlVKsAQAAAMCwXAMJAJVSrAEAAADAsFq4 BnKV3mtbDUBrFGsAAAAAMJxWroF0Wg2AJinWAAAAAGA4rVwDubHVALRIsQYAAAAAw1GsAUDFFGsA AAAAMIw2roGM8Sq9l7YbgBYp1gAAAABgGK2cVvN9NQCapVgDAAAAgGG4BhIAKqdYAwAAAIDztXIN 5Cq9L203AK1SrAEAAADA+ZxWA4AGKNYAAAAA4HyKNQBogGINAAAAAM7TxjWQ393YbgBaplgDAAAA gPO0cVotxov0XtpuAFqmWAMAAACA87RyDaTTagA0T7EGAAAAAKdr6RrIje0GoHWKNQAAAAA4XSvX QC6CYg0AFGsAAAAAcIZWroHc2GoAUKwBAAAAwKlaugbS99UAICjWAAAAAOBUXxuadWO7AUCxBgAA AACnauX7aqv0XttuAFCsAQAAAMApXAMJAA1SrAEAAADA8VwDCQANUqwBAAAAwPHuGpp1Y7sB4DvF GgAAAAAcZ5+e+yYmjfEqvZe2HAC+U6wBAAAAwHFcAwkAjVKsAQAAAMBx7hqa9cZ2A8C/FGsAAAAA cLh9eh6bmDTGRXpf2nIA+JdiDQAAAAAO19I1kE6rAcAvFGsAAAAAcLi7hmbd2G4A+JliDQAAAAAO sw+tXAP53caWA8DPFGsAAAAAcJh2roGM8SK917YcAH6mWAMAAACAw9w1NOvGdgPA7xRrAAAAAPC5 fXANJAA0T7EGAAAAAJ/7o7F5N7YcAH6nWAMAAACAz7X0fbWr9F7acgD4nWINAAAAAD72kJ6nhubd 2HIAeJtiDQAAAAA+dtfYvDe2HADeplgDAAAAgI+1dA3kIr0vbTkAvE2xBgAAAADvcw0kAPAPxRoA AAAAvO+usXldAwkAH1CsAQAAAMD7vjY278aWA8D7FGsAAAAA8LbXUq2dayBjXKX32rYDwPsUawAA AADwNqfVAICfKNYAAAAA4G2tFWu+rwYAn1CsAQAAAMDvXku1l8Zm3th2APiYYg0AAAAAftfWabUY L9J7+f/Zu7PiRpIFDKNiYDOwGdgMnBCaRdIRhGwGMoMxA4mBxEBicFPtO93t8aalllzOiUi911d6 +6Oq3HYA+JphDQAAAADe8301AOAdwxoAAAAAvJUW/b0G0vfVAOAEhjUAAAAAeGvV4TUHtx0AvmdY AwAAAIA/9vk8d3XFMT657QBwGsMaAAAAAPzR49NqXgMJACcyrAEAAADAH14DCQB8yrAGAAAAAK+2 i/5eA3mTfx/degA4jWENAAAAAF55Wg0A+JJhDQAAAABepQ6v2ffVAOAMhjUAAAAAeH0N5KbD6w5u PQCczrAGAAAAAD2+BjLGu/x779YDwOkMawAAAACwWCw7vObgtgPAeQxrAAAAAPRunc+uw+sObj0A nMewBgAAAEDvUqfX/cOtB4DzGNYAAAAA6F2P31d7yL+3bj0AnMewBgAAAEDPvAYSADiZYQ0AAACA ni07ve7g1gPA+QxrAAAAAPRs1el1B7ceAM5nWAMAAACgV8dR7dDdVfu+GgBczLAGAAAAQK96fVrt h1sPAJcxrAEAAADQo/3CayABgDMZ1gAAAADoUZ+vgXwV3H4AuIxhDQAAAIAe9fm0WoxPbj0AXM6w BgAAAEBvjq+BfO702oPbDwCXM6wBAAAA0JvU8bX/cPsB4HKGNQAAAAB6k7q86hhv8u+j2w8AlzOs AQAAANCTbT6bTq89uP0AcB3DGgAAAAA9WXV87cHtB4DrGNYAAAAA6Mmy42sPbj8AXMewBgAAAEAv 1vnsurxy31cDgEEY1gAAAADoRer42oPbDwDXM6wBAAAA0AvfVwMArmJYAwAAAKAHx1Ft1/H1//AX AIDrGdYAAAAA6EG/T6vFeJd/7/0FAOB6hjUAAAAAWrdfeA0kADAAwxoAAAAArTuOaoeOrz/4CwDA MAxrAAAAALRu1fn1B38BABiGYQ0AAACAlh1fA/nc7dX7vhoADMqwBgAAAEDLUufXH/wFAGA4hjUA AAAAWpY6v/7gLwAAwzGsAQAAANCqbT6bzhsEfwMAGI5hDQAAAIBWpa6v3vfVAGBwhjUAAAAAWpU6 v/7gLwAAwzKsAQAAANCidT67zhsEfwMAGJZhDQAAAIAWLSVY/JAAAIZlWAMAAACgRauurz7Gh/x7 628AAMMyrAEAAADQmuOodui8QfA3AIDhGdYAAAAAaE2SwLAGAGMwrAEAAADQkn0+zzIY1gBgDIY1 AAAAAFqy6r6A76sBwGgMawAAAAC0ZCmBp9UAYCyGNQAAAABasc1nI4NhDQDGYlgDAAAAoBVJgl+C BAAwDsMaAAAAAK1I3RfwfTUAGJVhDQAAAIAWrPPZyeBpNQAYk2ENAAAAgBYsJfglSAAA4zGsAQAA ANCClQS/BAkAYDyGNQAAAABqdxzVDt1X8H01ABidYQ0AAACA2iUJfgkSAMC4DGsAAAAA1Gyfz7MM vwQJAGBchjUAAAAAaubban8ECQBgXIY1AAAAAGq2lGDh+2oAMBHDGgAAAAC12uazkeGXIAEAjM+w BgAAAECtPK32R5AAAMZnWAMAAACgVr6v9keQAADGZ1gDAAAAoEb/5LOTYeH7agAwIcMaAAAAADVK EvwWJACAaRjWAAAAAKjNfuE1kH97lAAApmFYAwAAAKA2x1HtIMNvQQIAmIZhDQAAAIDaeFrtXzHe 5d97IQBgGoY1AAAAAGqyzedZht+CBAAwHcMaAAAAADXxtNpbQQIAmI5hDQAAAICaLCV4I0gAANMx rAEAAABQi3U+Oxn+z/fVAGByhjUAAAAAauFptbeCBAAwLcMaAAAAALXwfbW3ggQAMC3DGgAAAAA1 OI5qBxneCBIAwLQMawAAAADUIEnwF99XA4BZGNYAAAAAKN0+n2cZ3ggSAMD0DGsAAAAAlC5J8M6j BAAwPcMaAAAAAKVLErwTJACA6RnWAAAAACjZOp+NDH+J8WbhiTUAmIVhDQAAAICSJQneCRIAwDwM awAAAACULEnwTpAAAOZhWAMAAACgVKt8DjK8EyQAgHkY1gAAAAAoVZLgP3xfDQBmZVgDAAAAoET7 fJ5leCdIAADzMawBAAAAUKIkwYc8rQYAMzKsAQAAAFCiJMGHggQAMB/DGgAAAAClWeezkeFDQQIA mI9hDQAAAIDSJAk+EOOTCAAwL8MaAAAAAKVJEnwoSAAA8zKsAQAAAFCSVT4HGT4UJACAeRnWAAAA AChJkuBTQQIAmJdhDQAAAIBS7PN5luEDMT6IAADzM6wBAAAAUIokwaeCBAAwP8MaAAAAAKVIEnwq SAAA8zOsAQAAAFCCdT4bGT4VJACA+RnWAAAAAChBkuATr99XuxUCAOZnWAMAAACgBEmCTz1KAABl MKwBAAAAMLeUz0GGTwUJAKAMhjUAAAAA5raS4EtBAgAog2ENAAAAgDlt83mW4RMx3uXfeyEAoAyG NQAAAADm5Gm1rwUJAKAchjUAAAAA5rSU4EuPEgBAOQxrAAAAAMxlnc9Ohi8FCQCgHIY1AAAAAObi abWvxHiz8MQaABTFsAYAAADAHPYL31f7TpAAAMpiWAMAAABgDsdR7SDDlzytBgCFMawBAAAAMIck wbeCBABQFsMaAAAAAFPb5vMiw7eCBABQFsMaAAAAAFNLEnwjxicRAKA8hjUAAAAAppYk+FaQAADK Y1gDAAAAYEqrfHYyfOtRAgAoj2ENAAAAgCmtJDhJkAAAymNYAwAAAGAq+3x+yvCNGB/y760QAFAe wxoAAAAAU0kSnCRIAABlMqwBAAAAMJUkwUl8Xw0ACmVYAwAAAGAK63w2MpwkSAAAZTKsAQAAADCF pQQniPEu/94LAQBlMqwBAAAAMIWVBCfxGkgAKJhhDQAAAICxpXwOMpwkSAAA5TKsAQAAADC2JMHJ ggQAUC7DGgAAAABj2ubzIsPJvAoSAApmWAMAAABgTEmCE8X4JAIAlM2wBgAAAMCYkgQnCxIAQNkM awAAAACMZZXPToaTBQkAoGyGNQAAAADGspLgLL6vBgCFM6wBAAAAMIZ9Pj9lOFGMD/n3VggAKJth DQAAAIAxJAnOEiQAgPIZ1gAAAAAYw1KCs3gNJABUwLAGAAAAwNDW+exkOEuQAADKZ1gDAAAAYGie VjtHjHf5914IACifYQ0AAACAIe3zWclwFq+BBIBKGNYAAAAAGNJxVDvIcJYgAQDUwbAGAAAAwJC8 BvJ8nlgDgEoY1gAAAAAYyjafjQxnCxIAQB0MawAAAAAMxdNq54rxSQQAqIdhDQAAAIChJAnOFiQA gHoY1gAAAAAYQsrnIMPZfF8NACpiWAMAAABgCCsJLhIkAIB6GNYAAAAAuNY2n2cZzhTjXf69FQIA 6mFYAwAAAOBaSYKLBAkAoC6GNQAAAACulSS4SJAAAOpiWAMAAADgGsdvq+1kuMijBABQF8MaAAAA ANdIElwgxpuFYQ0AqmNYAwAAAOBS+3yeZbiIUQ0AKmRYAwAAAOBSSYKLBQkAoD6GNQAAAAAutZTg YkECAKiPYQ0AAACAS/yTz06Gi3kVJABUyLAGAAAAwCWSBBeK8SH/3goBAPUxrAEAAABwrn0+P2W4 mKfVAKBShjUAAAAAzpUkuEqQAADqZFgDAAAA4FxJgqsECQCgToY1AAAAAM6xzmcjw4VivMm/90IA QJ0MawAAAACcYynBVYIEAFAvwxoAAAAAp9rns5LhKo8SAEC9DGsAAAAAnOo4qh1kuEqQAADqZVgD AAAA4FReA3m9IAEA1MuwBgAAAMAp1vlsZLhCjA8iAEDdDGsAAAAAnMLTatcLEgBA3QxrAAAAAHxn v3j9vhrXeZQAAOpmWAMAAADgO8dR7SDD1YIEAFA3wxoAAAAA3/EayGvFeJN/74UAgLoZ1gAAAAD4 yjqfjQxXCxIAQP0MawAAAAB8JUkwCN9XA4AGGNYAAAAA+EqSYBBBAgCon2ENAAAAgM+kfA4yDMIT awDQAMMaAAAAAJ9JEgwgxof8eysEANTPsAYAAADAR7b5vMgwCE+rAUAjDGsAAAAAfGQpwWCCBADQ BsMaAAAAAB9JEgzGE2sA0AjDGgAAAAD/lfI5yDCAGG8WhjUAaIZhDQAAAID/ShIMxqgGAA0xrAEA AADwt20+LzIMJkgAAO0wrAEAAADwt6UEgwoSAEA7DGsAAAAA/C1JMCivggSAhhjWAAAAAPhXyucg w0BivMu/t0IAQDsMawAAAAD8K0kwqCABALTFsAYAAADA0TafFxkG5TWQANAYwxoAAAAAR0sJBhck AIC2GNYAAAAAOEoSDM4TawDQGMMaAAAAACmfgwwDivFJBABoj2ENAAAAgCTB4DytBgANMqwBAAAA 9G2dz4sMgwsSAEB7DGsAAAAAfVtKMApPrAFAgwxrAAAAAP3a57OSYWAx3uTfeyEAoD2GNQAAAIB+ HUe1gwyDCxIAQJsMawAAAAD98hrIcXgNJAA0yrAGAAAA0Kd1PhsZRhEkAIA2GdYAAAAA+uRptfF4 Yg0AGmVYAwAAAOjPfvH6fTWGFuND/r0VAgDaZFgDAAAA6M9xVDvIMApPqwFAwwxrAAAAAP3xGsjx GNYAoGGGNQAAAIC+rPPZyDCaIAEAtMuwBgAAANAXT6uNyxNrANAwwxoAAABAP/b5/JRhJDE+iQAA bTOsAQAAAPQjSTAqT6sBQOMMawAAAAD98BrIcQUJAKBthjUAAACAPvyTz06GUXliDQAaZ1gDAAAA 6EOSYEQx3uTfeyEAoG2GNQAAAID27fP5KcOoggQA0D7DGgAAAED7fFttfF4DCQAdMKwBAAAAtC9J MLogAQC0z7AGAAAA0LZVPjsZRueJNQDogGENAAAAoG1JgpHFeJd/b4UAgPYZ1gAAAADatc3nWYbR BQkAoA+GNQAAAIB2JQkm4TWQANAJwxoAAABAu5YSTMKwBgCdMKwBAAAAtCnlc5BhEkECAOiDYQ0A AACgTUmCCcT4IAIA9MOwBgAAANCebT4vMkwiSAAA/fifAAMArxGbXge6xYoAAAAASUVORK5CYIIA bh7wyRUAADzqGWgBpU9W1Nf4u5NQ0En/iVBORw0KGgoAAAANSUhEUgAAAKAAAAAmCAYAAABDJpDo AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9z b2Z0IE9mZmljZX/tNXEAABU4SURBVHhe7VwLeBXVnf/PfeXeBMJLrBVrBRSx2lW7Lnx21yqVVVyp 4quAYhVDBJRHCKbKqkxHRZHwCMIKFhBUoChoKZ/4aq1FXNfHftUuVKkUrLiKBRUJ5Ca5j5n9/Wbu uTmZ3JtAwrbEL+fjZGbO+Z/HnPOb//NcQpZlSVvTqMcei3bZL0PSnaNnG4XR/nZR5INHhl5yd65+ y5xqS8LBfoFI5E8SMX7facf+F+/p0aO+rXPoaN8+VyDU1mmXmA9NiBYWzE93igWcgCESCkhxLCY/ 3bx5wazzztuj9/9TJ35spLhoeg0LI0EJBkNSf1rULq9NTph7wFjU1rl0tG9/K9AmAI4x588vCMik RCAggQz4JBgQF2DB8AT8na4vSSISmJgCnRGNiCDbaJe2bTDD8MPlgZp+c/cHprS/JeyYcVtWoNUA HG1WDYuKTKqTgBhgfOR+Bu6BRHFQEAiHRvoBaIQCIyWMIWMRCcTQOhQUI5WWRG2dxIqiZeWp+Mtz a0LPtuWFOtq2rxVoNQCDIo/Wue8K9BGBzOSC7r1IUTh48vRPPone06uXSzY9Ho85XQv71gQBOmSJ hMSIFYhTlxQjmZbauoQ4IitAekz7WsKO2bZlBVoFQHC/AeBf3TwAMgE6+CcOr9590ralZt/eC6RX rxdIsa/IHhRLp0RsgA91zE4iKZJO457ZkWgo0KPcqR4w1yh+qy0v1dG2/axAswAsNR/oscSa9oX/ dSBoByay2FPgywDQxaMtiRRAFgkPxJMLwGAyNTABbhcIhcSpB/Agqo1gUpx0BojJlNSj3E7bAyQk TQBYumFDjyWXXdZkLu1nqTtmmmsF8gJwtFnZJyqFO0abDw1Zbk16UW/siNPDppxV3I9czCEXQyl0 Ope7pVJiOOEzs+2SybMkaIhdB4OFGCXwKLLJMevTKIcorgesU/WdAcBGafxLv72kUCLPjX/syVMW 3TD8zx1b+fVZgZwAnG6axm4pfqtGbJoYL4ATHgtOuFe9NsyN/YQfpS4B5EB8GuR4yA7AaCRxT1Am UqepNnZd4jSaKQZ0RJv0SYhi13pBe4IW4DPqU5KqS+0TyHeV4M75xkHbfu4gxHXQCbyNuR1zj2Wh QUf6OqxATgB+JF2eBDx6NACu8FXcZ8EEDraNDSFIvQSwuSAC1yMIBeJUKGbDod6KxKmt7+Mi1gUr 6CGKXSbKMj6DPgCuCOVxm76w8aT9qs3+kNOpZNe/dj9pLeqv/Dosfsc7wBHiX4RRZuU5MQlew9BE g5B1+peY8+cssyZPJf0B6fnbb8rnAKDLA10AuaBLkOu5wCP3k+K0FKj+i9NOsDpeD24JMU3uB4e1 YcBlkzVI0hJBd4V79m+Wnt9ym9266dUqJ5ns54IZfTuwlqOJ9BXj7104cNHdE97s2MD2vwJNAIj4 xKw43gsQAbwIMIhM/I2JU15qVq5dYlW8sca6rn6MWfUeir/jLgHFaIZLEXgSAmDgkE7X1cnEDZuL 67p1C6WO8aIk5JJOGL3DFeOJcHJFiu+0HEgmtyw44wxXvE58ZfP3w7Y9OU73DEDtJHGFiI4nEhJM pR4EyQXtf/k73qARACeaZmFSug6KK87mocsFYS3+hiRMi7arVxpYHhS7kuB0kxK7BBaBBgMjFQoj 4hHuHpJ94XRNTGyU0wp2gUhfoBLBcMMYKQeSPP2o6s5JJZ+Pk2MCgC6oXS6IjHFiYpw/0ayKLbDK OK2O1I5XoBEA90qni+Aa9pgSMq1VPYE1dSk1q55YYpVdXyj2w6irzCKAXJBWLDifgUwDwwHI6pxU 11AoGqR6R2CmAUq3HhaxQATTZeP6AB1DvqyNL+Z445779ep0IlXsJKAIkAPWEojgnOwf9FQPcHch Lh1Rk3YMPk7dL4J7QdNyOV5Gu8uKYcWsYKCOAgiXgvtsKjXnPQ3aq7JrQGOEICGwkMDXJOREY0BR 2A4CQOR8EM8EpkEZr1ggkF2bdp5ceeEP6sZueOmHMTs9Mg7QwTEI8AGABCHEuWvkuP26H8cJ7Xzt O6bfFIB2NYFmQwP0rooLeqBkYvQDd+tx6QZP3/RikavcwwcqUV9z7+GSwd9UIhkNpKIBWr0OYr9Z 8QtHtMJfEehqJOge3wrU1q6Psw+KXQIPotcFH8VvJhHeeKpuzQ6apsm5U81legfH0Srz9QPa41D3 H8jquNgzoF9HetRdjYuyxmls3Yy6vI5y37hvgbaqmXEvQN04dxG9tB30pk6P/rrjeSmyCkh9Cprb mulzjdYfyTaCflUz9PQ2qEXfDVrXAPXNgTYAJVE/5C7IubwqBtryXICbMO8FuGQ9LI0apCTwBl1w 5IJwlmRVNKUHKi6Ia9ebzHkLH7WmTAA3pIvmB41mRgBBrLrSNQB5G5ACO6AB0AWfFzMmSoGGlxcN v3z7uMfWPoxISGfXoFHGB3W/ZAP4OE4EDesl8Ua+xWuh/HKtHt+P5AUg6joj6y6fP+HZBSDS6cjZ hcV9GXJzkRp9XBwHkqpm5slNOkOvx8YtxkbuVmW4/xJljDQdr8rwPB3l6uPKNkf5KXgY7hvvHDzn BCDoB6COH5hKM31zOT/Ttlcz76BX6et0GSpOVJWNALjOqtg+wpy9EwK4DyMdniWseF/DHT/LIgnc Cqt4IXwukyFj32liDdDajYMSwJOg7TguAKn7UQx7FjCd0oXIX6WlbPTiVacXOM74OMFGUQuL1+WC jBP7Esbavtyq2HmIL9+uyDKgagS+zAvci+sY38tQZ75HK7sW9+SK/qSDX9WdgrGOAWA/z0H/Y1/Z MvWMNpzDkiO1qE1YJgRnSaHIKxSkBKHmC3THVCW1tIMlvO7nVtkZN5tVDNVd3GRScK8EbESFDwBM wXCDCKaOyDAcUlyMjcsn37h17Jxl78Vt0MHX5/oVGUnJkQB2OSjOTUdqAY7CfvQj6gy5k1sylWDz bwVg9NPjj6BcB+CoPAAk18mVCNiHclTo3JLi1w1/Yvy+OcD3LsrmIb+PfNgRqtAA896z37LufkdN 4imr4nfXmHNmwMq9MwUeSH1L6YLKL6hEMTjk6SVm1Y3gZqWFYuxq7L5RnDOZsFNhBzFegIstvTOD vMCdIrWBQGmJtfAmw3BOczIWcT5QUNEC8K3l1pTXdBqoAefCMv+voxBMhzUlbDANK/1DpmqjqxrU k+9SnQIYe9CGADgrU3Y+nqlzKRtSkZ6nTYQqO9VupiYARPtvolw38FZobWf7XmgdxrrmsF7SRxyy xV7xfXNGz7CkxmyyzOdYv9aaetePzcq6TuLciyMC3kkrZI9n0biAqwV3/DxR+8gSa0rBGHMeWL/R SESQplbCtWE47wyBTxB6ofuR0O+HO6zEomVW2e4Sc95iGDTNvgfBCoDftcyaMkMRlphzrsYnsgjz 2YcyKsLtPVHMqrQFm/smAME9+bdM4TRcswDMlJEL6j9nIKiyuh3aX+BbFBoqin4g6kMYx3MveMmv Kz6m1Q3z9dVmSRTCpmLj0tFCCW0cbM78AyIho160KraCE943wqzcWiDBX5IDMjfohA1whEiOlJhz Zx8vS8Z+KmNLQJZFEsV1WBIHIOfDHmQbfZgpgO8WhPjmoQ4sMn+ingBRPQyhwF+RCrrnP9oSWh2W YD+aJxDuxzTTvC1VzU2rLf02aQsg0P67UatgtIeJBoACYCAjhmmZq0TnvQ5AimHduNDF73+j7gkf PQ0Elqmk6397AE4aXhS/2bMAGcLPUHegrYsQgqMjCvMA3MhB4DZ9ZieRLUPNmeshbm9eY01bf7VZ dRLE8SuQmL0bi2IO7YXpohKYuk/G3geI3QKQLlKfk+cuSVUTgEZWlfFs9XpJj8Mpm+4FEitrONja +HUyjvCdB0UGrbQm7UL047haMVYUSORi6qAEH9UC7fDM4a7HpVjYvxnIWpic64bKJEe5SHDdjDl+ jHIvQC5CHTELQNQnUP8Syi7K1A/xjaMbIBtAXwN66nQnZ+hG4OoCkOIbl3O19su1+5N8/R53qGuH MfOKtxDAUp0QuxgH5MHhgjhoYAOIgWFFEhx2pTmr8o9SM+19y+rzE3PuTGz07dSACQzPUcO/AeUb XLzUKhsxzpxfhtpTOVmO+oHU7RsifULV8lXD6opsXW5NXQZH9tp84KOxgbr7odvdiSNYYYj4+TCK JnFEWtweavjkyP5WKL++xTwaHu/QJuE3DO5HneJyPbDxV2JTn9HoaZUqABJIV6H+aVxhT0ofjU5F jn6BMgV4xV1Jprte+KwDkH6+I55C2Mg/AlTnhgG8ekCGTjul6wGIFWdJ53HfNR+c+Lh1+x0QyUsi EtwILneq4nLkgQQhjJDh483KaSkJXwGgvucByxF4XFM43pwqN+e7JVH0jp8hXQHavmGJXO03XMgd wdm2HZTkpXS1lJoPlX4u3avQV6ECq+7o9kaRrBF1mCtELP8VOd8XCsW1wc92mH0fMjnFKogzDN9t 9hTKvu0Dji5mqQdnAUjnOOj18a7DA6JUMkwvBJ1aJx2ABOxQ1BGcukFBEeuK30zSrW8WUQB90sza qXbNKvfc72exgedSpJGjURwjYovMaAjBZXSOSWAFjBIov6lrHrcq+o8254wBx1wIEGaOW+H3H66D JrwAet3QUnM+vmBn0gF48tQsqt3+Xa42e6lV8WdYrs9nj3NliBAlhvs5NWEZuCNOZP8TTty8jF05 Sb254nrqnA6beQaSs/6Qd7sx4UtY5EabpFdjY3rj+VD9jTqAWpqOf1N+5mvwny100B9z+2fMXadb jTY0QJiuyFx/pPXzvLpHu/fRnvobHe1MFMMEoO50140P0nzqm9PH6IdumTal0Gfw4cDmnkE4Qy9z DQ2aG+RT6lqLZyD15CIJvzPSrHw6KeEx35JuKz+WL+aC240nZ6IohG1/KYDTF0e2JgNg1wJymlfe 2A1AByBSK0aZC0+FiB3CSgLIE7f2wz3lG+W7ZVcRfvT0qyKJXMaPgpy2QUnzRK56pv7JL6hIque2 chVyhY70rpqr93MERgU+yjUPbPaxvvJs9BJ1w1DXGiOK/j+GwVT6OW4UAMnV/gXPugGixK+iJ2DH Zh5GgJ7Gjrf9XvIDkAaMnnTR3srlx/7VW1Zt0jSnYaUf8PQ7HsOnTKIP0Aaf5RPdJtQPHc7wKrhs rtgpeypWWhW3jDKr7gfdsk5iXAQHMUU4wXB5SpJDgxKmi8BN4K5fwSChhQYxnJrNHYDYpmvleYxb utQq/wQ+xYqQxGZxRIKvgePpPK8BkFwtGFF3PIp3aPUKtL6hH2w8lPF6nu6G+co/1J511wu/yf9x t6Fp4nLQcFBx1B8CNH3AhVwOjesmPLM99T6mOdo9n10PgpaexL0CIJcyG+3A/efkkjoxntPon/5X AttNeL4L5fflmOshF7lf+C7LmnmSafJrGgx3sQs8ygiCriDrhmaE2PtA6vBzIrjn51xvzp0MgA5b Y5VfDI53JiCzrIsELsP98eCCb4KT/UTNBJxsOHS6Lag7oZsYQxH/eRuALVlulW0B1zwH5W9gzBO8 qK/icQ3cTvkidZMV8v03q6ypyl1xyC99hAhpeeqpHBtC390KvRBldCzz6JqeNmY2kDFXPew2C+1p 5eZM6ItGAg8JqMTNz3I93NMYmZypZN8q7Ue31NeyCc+v+PRGnb7RO2jNpuD+be35XvTxPTyvRKal ntOjgLH83DPbRVbE/MWy/vXbprkWn97V5D4NBzEaxDGOjLrw9M7KEKDpE+Gs/v115rwnDshXpWss 6xwc6T8PnG8wqh8HuPg1u4lA4xVic9Becc7D82vTzVUF0CdXFUr4Wm/MBsCRliUciaJWAZDljE2B fu1qa6o/Zqmtzf/vLRb1Cyw+ucxUbaTlKKNfDpqNq8MwqqCLNZI+i7bqZ6d+sFU1N+uMsUGNR3me RmK8sZo/jhJHAVDvakOefn+JcqUv6iS69ZstJ5AwXgUK9AMcbJ+rD72//G4YneojhFX6wiICt1oM 86NXfeY0EDlfBOvJY1peJIT9eT+vpNsGJ6Ovj0jxsFHmnOEQy1R2N+dbSBgprs/pBrNy6GcS/AVM l07x7DgN5qg6h6SuHJEWNNSAXfAA3rLaut3lIn/PhA25DRvCL59AVEDjVAm8XGk22nADKb4Y7tJ9 djSI4FFqMVHF+XeNiiAu53PGuCCn859S8et/qvlTuPGDZy/6eS/fLFA3G3OneOY+dmtxti0QNFGy d3jm+AknmGZ/nI4ebEv6FOhvcEcg3gCTgGKZEORRhTBMAAKEnzpCerSDR4ADbgcI3eB1vgSaU9HP j+D2aXKqokH4NrTmb+4wh53Vkv71GqtiRxtfej3aK+Po3Rb6oqW4DllZ8y4X1xM2ZD42hC4ShrAG ITMk2BWZ3ycBxflSd1oN2mqt7fksyzwTvJ6fquVEsNPPqoygnr4mBPhQrYzc0g2x5kjkgHTn6O7Y l1uaAt6DH393vDfVNuqE/JiU7ulv7ud+1EWVHpvzAKHbwf9a1jZcmBsl/mYYSki0j0QL90uqMIQc k1BRnYTwn7Klu/eTeItuiw/k4I6TpXgD3D374No5CCDHYaDAkIgdTMm+WojyrPumpcU43HosXkvi ItslaClKWwy2g47zJUdwufuhJLRhuCzvgdB8faDdl6jzO4z1OdPHx9xiQl8EMY2nViW0J1hbBKze OdpM0p+bcMDeOOQIjrYWsOWR0SJwpEJ8ngV0GCHkJpvAAXu5XNCG+4T6YNj91DuDJ+IzKsOPxpXU zPtSdE73M+ec3kmCDyZcx7fB6EvG9dNZxpizXZ0Ph7PYJ/7PBSMOnluDa62Ns1rgiMM3WtPyKrat Ws2ORn+XFWgCwA9xAuNE06QOcLEShxSxXyFT4JKfMzxAfYyN6YmGNrgNOuJFAAX1oUNKK62psxBn fiokSTqb+3AMv6WbMT6MtKTxIThFGXG/8YUO8B3SGrcHopyO1htFLoFs2AFjpLf+EnQK03+HQwuu Z9AT+oHbXrOmUS857LTOKvsLGvW90qy8E5btfZRjyhb2flFCTdOzgj23uPMhwKfrN4c9ZkeDo2sF cgIQYtTBUYfvgNO9DmCcrR8WU1wKp2dewP/kcgMOKuxp6ys9Y1XMuNR84FFY108gKnKhipAo44Yi Hhb5H/ZKUj+p0dZhO9ofBSuQN9SESDQto+/BN0hn8q0A3j9AJ6xD/g2cxRZE9dYjOX+I793ob/CF 5gNnI2Q3HaCHCuCEAMJ3wQ0XvW7dndM3dSTn0NHX334F/g/PoVRsrTwQSwAAAABJRU5ErkJgggBu HvC0VgUAuOlochf2C1z4/NRk7IJptv+JUE5HDQoaCgAAAA1JSERSAAALugAAANEIBgAAAFgcLywA AAAJcEhZcwAALiMAAC4jAXilP3YAAApPaUNDUFBob3Rvc2hvcCBJQ0MgcHJvZmlsZQAAeNqdU2dU U+kWPffe9EJLiICUS29SFQggUkKLgBSRJiohCRBKiCGh2RVRwRFFRQQbyKCIA46OgIwVUSwMigrY B+Qhoo6Do4iKyvvhe6Nr1rz35s3+tdc+56zznbPPB8AIDJZIM1E1gAypQh4R4IPHxMbh5C5AgQok cAAQCLNkIXP9IwEA+H48PCsiwAe+AAF40wsIAMBNm8AwHIf/D+pCmVwBgIQBwHSROEsIgBQAQHqO QqYAQEYBgJ2YJlMAoAQAYMtjYuMAUC0AYCd/5tMAgJ34mXsBAFuUIRUBoJEAIBNliEQAaDsArM9W ikUAWDAAFGZLxDkA2C0AMElXZkgAsLcAwM4QC7IACAwAMFGIhSkABHsAYMgjI3gAhJkAFEbyVzzx K64Q5yoAAHiZsjy5JDlFgVsILXEHV1cuHijOSRcrFDZhAmGaQC7CeZkZMoE0D+DzzAAAoJEVEeCD 8/14zg6uzs42jrYOXy3qvwb/ImJi4/7lz6twQAAA4XR+0f4sL7MagDsGgG3+oiXuBGheC6B194tm sg9AtQCg6dpX83D4fjw8RaGQudnZ5eTk2ErEQlthyld9/mfCX8BX/Wz5fjz89/XgvuIkgTJdgUcE +ODCzPRMpRzPkgmEYtzmj0f8twv//B3TIsRJYrlYKhTjURJxjkSajPMypSKJQpIpxSXS/2Ti3yz7 Az7fNQCwaj4Be5EtqF1jA/ZLJxBYdMDi9wAA8rtvwdQoCAOAaIPhz3f/7z/9R6AlAIBmSZJxAABe RCQuVMqzP8cIAABEoIEqsEEb9MEYLMAGHMEF3MEL/GA2hEIkxMJCEEIKZIAccmAprIJCKIbNsB0q YC/UQB00wFFohpNwDi7CVbgOPXAP+mEInsEovIEJBEHICBNhIdqIAWKKWCOOCBeZhfghwUgEEosk IMmIFFEiS5E1SDFSilQgVUgd8j1yAjmHXEa6kTvIADKC/Ia8RzGUgbJRPdQMtUO5qDcahEaiC9Bk dDGajxagm9BytBo9jDah59CraA/ajz5DxzDA6BgHM8RsMC7Gw0KxOCwJk2PLsSKsDKvGGrBWrAO7 ifVjz7F3BBKBRcAJNgR3QiBhHkFIWExYTthIqCAcJDQR2gk3CQOEUcInIpOoS7QmuhH5xBhiMjGH WEgsI9YSjxMvEHuIQ8Q3JBKJQzInuZACSbGkVNIS0kbSblIj6SypmzRIGiOTydpka7IHOZQsICvI heSd5MPkM+Qb5CHyWwqdYkBxpPhT4ihSympKGeUQ5TTlBmWYMkFVo5pS3aihVBE1j1pCraG2Uq9R h6gTNHWaOc2DFklLpa2ildMaaBdo92mv6HS6Ed2VHk6X0FfSy+lH6JfoA/R3DA2GFYPHiGcoGZsY BxhnGXcYr5hMphnTixnHVDA3MeuY55kPmW9VWCq2KnwVkcoKlUqVJpUbKi9Uqaqmqt6qC1XzVctU j6leU32uRlUzU+OpCdSWq1WqnVDrUxtTZ6k7qIeqZ6hvVD+kfln9iQZZw0zDT0OkUaCxX+O8xiAL YxmzeCwhaw2rhnWBNcQmsc3ZfHYqu5j9HbuLPaqpoTlDM0ozV7NS85RmPwfjmHH4nHROCecop5fz foreFO8p4ikbpjRMuTFlXGuqlpeWWKtIq1GrR+u9Nq7tp52mvUW7WfuBDkHHSidcJ0dnj84FnedT 2VPdpwqnFk09OvWuLqprpRuhu0R3v26n7pievl6Ankxvp955vef6HH0v/VT9bfqn9UcMWAazDCQG 2wzOGDzFNXFvPB0vx9vxUUNdw0BDpWGVYZfhhJG50Tyj1UaNRg+MacZc4yTjbcZtxqMmBiYhJktN 6k3umlJNuaYppjtMO0zHzczNos3WmTWbPTHXMueb55vXm9+3YFp4Wiy2qLa4ZUmy5FqmWe62vG6F WjlZpVhVWl2zRq2drSXWu627pxGnuU6TTque1mfDsPG2ybaptxmw5dgG2662bbZ9YWdiF2e3xa7D 7pO9k326fY39PQcNh9kOqx1aHX5ztHIUOlY63prOnO4/fcX0lukvZ1jPEM/YM+O2E8spxGmdU5vT R2cXZ7lzg/OIi4lLgssulz4umxvG3ci95Ep09XFd4XrS9Z2bs5vC7ajbr+427mnuh9yfzDSfKZ5Z M3PQw8hD4FHl0T8Ln5Uwa9+sfk9DT4FntecjL2MvkVet17C3pXeq92HvFz72PnKf4z7jPDfeMt5Z X8w3wLfIt8tPw2+eX4XfQ38j/2T/ev/RAKeAJQFnA4mBQYFbAvv4enwhv44/Ottl9rLZ7UGMoLlB FUGPgq2C5cGtIWjI7JCtIffnmM6RzmkOhVB+6NbQB2HmYYvDfgwnhYeFV4Y/jnCIWBrRMZc1d9Hc Q3PfRPpElkTem2cxTzmvLUo1Kj6qLmo82je6NLo/xi5mWczVWJ1YSWxLHDkuKq42bmy+3/zt84fi neIL43sXmC/IXXB5oc7C9IWnFqkuEiw6lkBMiE44lPBBECqoFowl8hN3JY4KecIdwmciL9E20YjY Q1wqHk7ySCpNepLskbw1eSTFM6Us5bmEJ6mQvEwNTN2bOp4WmnYgbTI9Or0xg5KRkHFCqiFNk7Zn 6mfmZnbLrGWFsv7Fbou3Lx6VB8lrs5CsBVktCrZCpuhUWijXKgeyZ2VXZr/Nico5lqueK83tzLPK 25A3nO+f/+0SwhLhkralhktXLR1Y5r2sajmyPHF52wrjFQUrhlYGrDy4irYqbdVPq+1Xl65+vSZ6 TWuBXsHKgsG1AWvrC1UK5YV969zX7V1PWC9Z37Vh+oadGz4ViYquFNsXlxV/2CjceOUbh2/Kv5nc lLSpq8S5ZM9m0mbp5t4tnlsOlqqX5pcObg3Z2rQN31a07fX2Rdsvl80o27uDtkO5o788uLxlp8nO zTs/VKRU9FT6VDbu0t21Ydf4btHuG3u89jTs1dtbvPf9Psm+21UBVU3VZtVl+0n7s/c/romq6fiW +21drU5tce3HA9ID/QcjDrbXudTVHdI9VFKP1ivrRw7HH77+ne93LQ02DVWNnMbiI3BEeeTp9wnf 9x4NOtp2jHus4QfTH3YdZx0vakKa8ppGm1Oa+1tiW7pPzD7R1ureevxH2x8PnDQ8WXlK81TJadrp gtOTZ/LPjJ2VnX1+LvncYNuitnvnY87fag9v77oQdOHSRf+L5zu8O85c8rh08rLb5RNXuFearzpf bep06jz+k9NPx7ucu5quuVxrue56vbV7ZvfpG543zt30vXnxFv/W1Z45Pd2983pv98X39d8W3X5y J/3Oy7vZdyfurbxPvF/0QO1B2UPdh9U/W/7c2O/cf2rAd6Dz0dxH9waFg8/+kfWPD0MFj5mPy4YN huueOD45OeI/cv3p/KdDz2TPJp4X/qL+y64XFi9++NXr187RmNGhl/KXk79tfKX96sDrGa/bxsLG Hr7JeDMxXvRW++3Bd9x3He+j3w9P5Hwgfyj/aPmx9VPQp/uTGZOT/wQDmPP8YzMt2wAAAARnQU1B AACxjnz7UZMAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAFS75J REFUeNqU/cvPreuy5AdlrOMSLtlGSGX5IhmJBg16NJApoTJdegghRBsJ0UXIGATIgg4dLl3+OgrK FsYH5EsJW8dlELiCxl7zG5kZv3zGrGO59t5rzfl9Y7zvc8mMiIzQ3/+//gOrVC6X6i//5z//U3/+ d1WVXSWp/dv+f3/555+/95efZLukXz/7zz/jKunze37+bPsz6zePP9c/3a/PvP9G/1zz5+afmf9b f35m/rvz+1Z7Zjo/v8tVP8+uHk+4xr+Pz/Xz8+fP+Py5+R3rz+f863l/nqEfz72Od1vwPvY/zX+2 /77Hp+z/Vu1PFK6VWt/x+mz9WfU1TWvi1/p8P4e9ztbaHM/3975/jc9G6wL2h12l+vleNfZlPfbM t/2iL2sy9yOu17bGxx6KZ0zvMf8v1+j8hHstzudQ690Lf/recYLfcn3v31kvBZ9fXz5P7IH2aubz 1fFu5v6vtl6Knl8713898zxrKu4HPuNpn/Jaz/Py2xlz/Y65v36dtfsM8Pjn9DN87PVaP4vWyP5O 4xPFMx93yJ97hc6WOK/W/vFxeuQZU3gejLXZfu3nzBWcS/P8mb937ve8z9az+fN3Ck7p/T75GRvP 2r6HRu2x6hM+d9vv+rW219k76om4o77fn68/l3s7VxO939cZ1f+zjrP/OlvptLrvRD7jPs8vz4/7 zsszTfs+hbWae7Ue/9zwCbLuyvqt33F07vNPu+75vZMc+8JYx10/f547dMbWcaf7a33MdwL/DMde c9TYc5+v++p5FvH/nuf9VYNd90Leg/u8uGqb/V7vZ1CPdXJXkde65jPWZ7VG9z39JK17N++wq5d4 1Nt4duvR+60eq53DcW6s+2vUo1AL9POIa4j5M6jW0GN/3/vGvOZWf51npM79hnUM9N78M7KH//7n X+fzuocDN8h+K9969hHXXb336O4Vrvvr+zlWxz1z7Vk//tm15ugZ6uwLhGf0XQHmecv36H0fXHX6 dZa98aE667bC5zBrRMZCrjqE/9zv9Wv0Ob7jS/UbWI7O58a/Q3xn4VnMPS+f3fnWd114P+N3fbvv dq5vrzPnqo3yE/KavupHHc/76sN3bc84Yj1rX8ABz2fsoz+91yRjoVzf8nNed/DoO+qs5e9+6Xfu LVgv0FNf535ix9eOu2rYuwahu/C1X1+1Wjz3Vs/v3vlbj/d7v3vj19RL3uuT18B11l91OOM6hEFk P3ph7e8z4eo1e5/E5zP17oI1WYAbrJ5x1Yhuv+bC63tvRp/vO2ZB//x9ol8964W13Xjnhfndtc+1 zi+8/KpR771+Y98bF/52hs06XI/a0A+OSF9qo9/BHf3lHPqGZdaXenv2CDfizXUg82QVz6ZOzoM/ 48Yt6DykGuaq9/7J6uaCu70QB+AauR77ubBf4jv21Vu97thXfc01+vvP1RfM2/GZ9pl+1Z56/nyq h75xw37gbXXc74WYyX0O6eC8/KVeqoO3ffFqxrqO+rE3vvKtN3vj/MK78e6F6tHrJFf5fh98Zr5w 9ltfEPXywKSZ92Hcnrn/enCTL16wfqOnylrnVcvfugLq6d4cfse/64nrfufqX1oRH3V6YsT9nV09 R97/uU/GvdHqXr5v6jfq0mvv3rxZPWu3iddSf1a/ddI9+pLHraPH/foNE7wxEeLr63i3dd45a+38 b1z1v60vGELuUebJ3ziHkft+1XJV9bdU+j9X+b90vq/F7bz4gb1HKv7OP+m+vPqN+i2O+31vfONB 9eDg3jxGnetWXz/n91rld7k7PXVr9Vs14etMr684xeZHiHv/HSyQ7ucbz+J1UfAZ6Q58rS/SzdG7 4Z61fpOD9bFO9aWu/8bn/x5H8r13X/gmaC/vute4Fm7888B64r75HZTtfhen+iE4ttzPrL/4xsP5 OCfeWpL6UjNfOlj+2XVjKGe/X/Vd+/oN36pD96pz9+Q+phpQX2oIfcXLuCd/655qKdiGJrIY38me Pbm4On83aw2vd8KYXh3P9e4hGVMsxPoLeNo6sWN94eleGP2FVbw5POx3lg6onifKjcnferwCDuEv 7/sPjY+inwe4/9tf/qN/FMHXbNu4HbRqf+fzAjVeem9Mknbbm7L/XI1P9JcHUSD02eBVLm/XL+Dv L/+r/1bHd56X5K9X77Fk//wzqvFvufQyFiP+demsTTO3zQLvSz8veb6DtUXtc8l+K/K4MFXb7A1Q GAfwrzeqfPbrt/56F39ZE6+iYv4zYaG7180E/fcqcjRI/bm1v6W+lgXtVDvQjrWTq0BxSEuflau+ O6TxOT3eJkFPin0zV+xFUAgOwbYS1X6bBD9rH3rzv/s8+hy/GUs9cYni+Ky78f71O/ZnMaz39c/s h2gmgaz5W32WgBpr8M/n2c6QEHe6fRN/HoVh9es7VLhWhdeernGC/oAwsf5rnYXVTkffxaj3M6dm UfHnf1aD+FyS4Ey32xml9a7+sqd+fbd+VjrASrfC1etdXkXRnz9J3Nbae98kyazz/tU6k//cJ3Y7 T9ff/PPR9eKg1tvq5+v8FOIO5jgNf84w0Z9fJaZob+wz+XMG7iJQ7T0LwWHDTvf40NIFGH7O3767 POoQH2S3oFHsxGPeb5oVFu7gfFuzGBT+3s+z+XWWzLWr2STACez1k8Zn116LuyCuGO+Jp2Zo8xS7 ZgnC+vnOZ8x9Nn4K6c878XhPvw9697Xm9du07gO1ZqA9Ge2bQeMMynNn3yLrd8T9Q8C4Ri33eXau W5CGp/Q406IxXWKEX+cJi9w1bvdRR/wMMC4Q/axmNO4vA1Cg8buWAEufXifeu/Ou/HlP/uyl/vmZ dIfz7LhDdbWLbm9MBTT+NQg3602Glff9vM9B/2xgVSHhMP+0scf6Vffs9f9z7qh+9mo/G4hI/9TS tepe/dQQH/LB0B9pkQ15xivugLm/3e71eZbprMwUd8pD7K5aIL7gnlCcRXRP5yqh57Frsl93vB7P 53X2JAC6AUeqg9TuGCHMlf2L1s+Lrl/U2xHsfhEdNdYcA+vzrBkrczRIWiesoRdZVVsMaTGJOP95 9kUFa33W/V73OZAXC0id98rnOfyqt+e+EOIuv5odn4MB1DsQeGyk2hR34dyTRDakaOui0JTfw8XE Q/8c5v7aq6YQ3Ok/d+7ARLJmnL3xrLU3FuZBjghrlFr3z10bTxwPbyfV2jcKlKn/p1a9pai7vGBd /TTS/aw23nyExSnWidpnzPNfiE8mnaOBXrougSAMgcPdofE8a9yr+775S//oJy5IwyafwkPwrPe7 bwDGfgKq9Z4relF/EXsQHjzrYsVZ2O+IX/+89+dvbPRXvaEJoxMi5H51E96puBcCI1HHDGvc8zqe +MRDJ5Lo9Qx233b1+Q5iL5HGWdd+EyjOO9gmPLBzDrumXN/cV1cwz74fPP3CWlRR/2fdYkQsagy6 bFLccXN0duGDuRj2twBP8jk0rHrg4N79swfWu/uvij7qxR1o4eKJE2/eoEY/qkf/6XWuzbVcUYlM cS0NGBjqhbumMzxHvtvrrMCNOOzvcDVZZSWN+cFEJ/atAwkY/3bwZFrYLkquVt2igTFWq1UI5eAO VcfZ7tZ/a5wXm9eh7ldxzxJC+7kPsyffd4cWr6nRp7CQj+rHVh+P/Tex5zw5BLUCY3ooUF44y4s7 0AOPvnEHGLWUQGjw2i1CTD6QXSd+RljXB++fcju3e3ecg9UBFsNdZ5CA+Auz6j/7Aa970ijj0Smq IhFH4uCJXlRdItFv49WJSepHzFknMl5T9Ro94sKyCAuQgnWp1ZsW8BxXPXuJMQX4nLCzTWzCwPSm 7sGPt1WDw2eBC/fyPjCTjdyO/7Y47usAcHAxULedQiE1rNJouJNCaDqVZ1/W739dNY90cq8VmL2i JkXc1g65UKpVNnacDGunGfgcVrAYWa9OkVc3kmE9jcAgZQ3cuIDtvPaQs0rTYph+Dgd6vm69p1ov 7YPrEGJGoi5DFRgB3Z1UadEZAgMz/2aV/+VdK+/+8Gcf2rDPhPf6W0weDhGAy6QJ3saFgpt1HXwS 8QcKvob7Io3TRV9k0NxxavGAdfxOrTf7fpYGJGbWXQodyEaVEmOYmIijY/KJNmWvSqWbi4ZnFGe4 QkPDliuXZq0OPYJOrBpQjMXHJh6gSm3fvquMOK/Os4j/7KzIeg9wD/grsH8fup7ssX3X3b2OAWxu VwJ7nc7he3Mvhtx0x1Hmz9/crw/Nxq4rXhi4NLEsQj0673etSaoDOhexh1u8ftYH52HV1+buDHcu KfhqaUEnntJ5i6uDJ0G6QOPohdeQdnGqXn/VE+O9g1J08nh9PdyQndC2R6F701cT3c2QrXWhXVN7 cfeV+K4OTmQ9oTwrPe7pZIw2D27Q0vjYu7WeddWtb1XiMdhve5xlW43odS5714ezsId+ZmPmuZLd sOoPDq7YP7VUSjUwIjZOmb2w9gIce/YPh+RbC7DsX5bdZD5iwylmcV3EyG7+m5xATIb49PPIL3m5 RneQTaf4hV8ouYD6hKMu6DiLP8X/hjZZSboIgOXtRnI3OVpFPgFgxq3vdeBoEau7Vftc2DkI4SUI cvF8p0Sb3ngI7aO8EOgxCNnrJGAm2T8/z0dkbLiIp9ChEDo1HBn7PYjFPdQQ+G6D/CwKCCxxXKAM OWfB+bNOxISHesGgChGBsJDcV/aClu2xtqhArgVKh9w/OgctkCpJFB5OqLP5BvofpRIkQUJCUF0c mM9qlzkd7O1F9AagouAEMfskvny0uzoK30rgTwlbK8QwFftqnAQmgrOgyE4x9X6XUg1hRS8yvAiV e/rSa12rKuQji4BXDfIpRVbCVUZwwI/Q+89Co39fATFp19Fk8g7tjVGe1T4onBSmzLW5hZF0cqbQ RyCkvglBIbnGogivIrYOCKYCMIu71Yswe9CWhpNr38C9mKyAkLjB1uEiNM4D93O/I83kAKaHKLKR TwHsOt6ZgObog17zLNDRaFznTL+/D9DHl0Cm7xEjgfICQARv3a253O2xFwlicBWivXje97juCITU aoAnKcBjNn1oiEEP6WhilSTly8n5M6BUKGieA4z3LvMCdcZ9A99f4kYvxbxM0vW1PK8yY1VG94K/ NM0FYP3PEFOQzIrGvT8b2pGFZzILlRSCwVrDoimIvNzlNPYBkyckEmbQ3HUPLTt6Iy1Qr9PCGvfl FoHtyt6L8NoC4Q2U8QDLZ3/epKygl6FhyorOLWW6flJ6ij4ia/7CDJgUWJAwQAxBiXqOFDiwewoM 4KErBAkJppDBCJF1InNRz2PAt0tTvO6Stj5URw9Ggorc6QHdtUQKOnGQ6BGJJnQCu9+wDu/ac5E0 c4CwqsJCYAP7hff+Z0huP2N/IdNIKkyiJS/8g9yXfA4nbfGwNAf4PPoQQZ+qeMv9jDlJqaOO2z/j W2LMGBIW/9kk/epA2rgOZuI1Jbm8e1fPaJ89OjmlbUHAHOrtQk3+ffWU68Oqc/qmbPG+EWaePcAG gb/7HWnd5/mGckBMZ6cxfo7yjNQhPfDTsFCHgcVr7IrWP60HAeaYdd7PvaPE5PbZ5yLMTIfD9J/H oF5+ZA7SrRYxbRhNr8Af2E2OJFvptl8L69xCBsFjX6iH6yDGNxGT97/i/bDwz1CH7mf3K7Wn36te U9WTdOrkixdGdDkCOu4VErJsTCbrVMf4XPY5N6bbhUWMK80zxOsejtty8TybREcsw06MU/T+FLew KnGhaT5Bw5wFPZHx7HE159R6G4Jw36Gjc/McMFY+j6gLQdqeCUEOCSZ3oAIeTsGB6Mfs4kraS05J gI9fRH3ng/ZwlfZYyhCQX6i3TjyQEpik1/DTGycUoKxqfTUJ7w1zfVtM8iOaNsv4/bjDBPfUr4Wm 0Suk0Kn30ZNYX46SvffTFrxUbZOKz+9XpZDd2HsLRXdXf6MhuDEaNN0sV2I4jtrtgyGltOLnf2uL QYRcV0i1fGd3sVvrn2tMF/O5zlM7OPBLgki4y+zJMo3AJ6qc2BMzFN+89xWO74r6CMSQoo7DiFcF G7/N+EyY6F05J5fnhs2Qq6tBXJnDnT4EODR0dg3o93eWgwQstJk6DhaN6khxGn/Ot2WDcI26Noxm kMPQdxSsa5uE/48MRs+haEISutj6Evhts7fdP4ZRiBS4O2dBK3nzqxfedVb7mb/2j6tOh3hKN9jr bJ+PjqFyweAXPf9JNvphNsFDyp/YPwMSUscoe8opCVF44Aj9n+8a+LP2/8uq+p9U6T9HGhAD6vKr BuVRcF77Dq504trZF2weV2N9zHrak6/VNIWZ+JVAY0G6AMUt6HAK3qanNcSoIuPK8ex/x9qvcj35 YHY9V83QWUgwZDjvvjD5UdUlEJ/ux8np02gzIwbGdetDpK66k+dJicJC/EJdB1VENQytjHthr/0r Raac9/D9bMguzrWHSF+jtqxA0jBevDnBGxm89sQ2VLwTnvRAj64qTF96q2ku8spO0sK9aIiduKRf NbVOZJT5I4UB2/4M7Q3a4z+T13b0o9NQ4RqY8oGJph5g41ZSKsL24FQFH+fz6W/e8kojmr2MKoct 34iH2p28z8zsJ6fTOaUa0S1NSZ83N1ehlOEa3oDXXxZWBg6tFnZRYzhMcK4aNcw6riItrstoNlqL hXTVYXG8+beN3y5rA4FBgVKba2eH9cKPPrVm1835gXUL8TId6QPT9DCNV/8Qqv+j5JhiQN+k8y83 vCyhvF4gCUOJRpkHKJWgFRO3vLikCnfTXOKOiSzD/0vCET9KqAI/HW5MgRhvG4Dk9D+HiPbmXEIw dWffRWbF5AQJGSqEMj9PxSQ70wLxliC/O6j4mtzbx881sa6Y5GGCyDjJ6fWdipytYTq2Ay/szrkn AwscnbZw7zUnfa+dWmKyO6LpBXQI2+iCQiOdQraToo+LaEOE1/dMsnAc4F5wm2o08yHD92zu+nSu RxF2fKIF/haShjXEKvNCELgGbhepK/rLj880Kv1ofPfcdBcHfvNJ2Q3ynOjns+glW7im0SomznIC vl+WFQ5jtc45sSsEOej4csQjImU2d8NBLRw6X831EU3s1WasnL101aOBjfUX9T5DtijuMylpIAUm 8DCL0JezlE6Z+RAwqM4GjIS7Pu9TjTP6FswLW6m5PxTnZ3f+8TPWMsU9HJPZSfcCmLXA/UwToNEt qrsKdqqfOonG8WcAi9jLuWTDB3k/MSCi8+xIp5N78Go0wXUJEbq7mEEIP2uDHODSdK32i3DLEYV0 aKcJ4Bkbu91ar0EqiuXr4Nz7rPa4Q/WtJjFFfznISy+B6y1Ou2LVZiOdYqQ3sLSHBnSeVTUIeXZS yM85yBJVCB0Uz1fLRaMIallA72p2fRMe8x7dJ4AAVMy1IRgGvQgkg7v9Fev8cwY6xbh1iF5KmRox XXLr/Lvsi0Xn0HfPRE6emtlBl+/aGRPuqxL71FrDjUL1jJpz/Nxdbd+Rhq9kGPK9mEC+EORBpxXV 8e9UdYbpLkFaTbeHK33m5UNDo75PQGrV1BcQu4UVU4Dj9RhuF6OpUROA9lr/zsfpOU+aKa4rTO3T Oehw1VHpTB+ScafjZgz+2g3cWv2s2eXTl4uRXhHe0w38I3QTdqs52JvOQ7rAboNfp275RHdynACl zuHAa6zXrq/CDT1pBiaqJcbutoPTnRshqLGrLkckcoxNBztKF/Mg9w3JVNnn9KG7/b852WcbH1xd 8Pyca7IYXfR3f2js/maanmAM6dXnbrcV10NmDatGi4y9bjyjgEAtWewmSDf5/hqUS0eeLZGTJkm2 72HCL/PzGxJNpsD67YSv0yCDQX0dlK1Cpn5JOSJJw9TfVqHzvy88YaZAbNMat9qlML2kgOhPrztD fPJFxpO9SB9ukIQa11kPe+B4nJAy61lhF0/djKNGezmX7WGx/p8aJM9F9LtxolqD4K3vP+vkj0HG qL1dR/JTcwrvIi1nX0xOdZlI1M8KPZ3XhcM3dK/1XluY5dmFeZkAeaUP57BWus0KMbo9ZBK4kLYj uE+8RJUR3SSORTcv5Oao13/nwm5GkUQk6uJedC/fYj7uEKQaQk0WaF7CfxJRV+z3h897FQwiClbh D7EszjG8DLvqcvlTCijHc/KsZ+5Mt2rD/2B20+ufysGbT4LmPKOMmDW5INIZUGPf1+Jf6YWkqUzy Wf7iDElD/dnn0O/1SsEy1Po6hsG9XK058Xev8Cniz3QQh0jBwXa/0lV0chl1cDJCSxTEaJw/k9Nf uCK63F75+/gwkKmxb8lQ4cVxTBNBHamLQm7k/awnzr+5t8ukKJkXSnUhNE/jfqEE40zLMnB1hVhX 1ZXvUsOlsx686t6/0QesGlNwXm68uwCzHiisdBoEJV/j9VmmMR7z/BPj5AEDNoEbWIDmPT3TYAVv gZyM53c19u6uS943z23YM84zL0VMOjQJP5/7P1bp71fwTjSIo9Q1OX+3whVfcMP7sEAaqdh/uPx/ qNI/SxoQ7ok397KNC+Z9sNOWLpHZxUueVp3mjkWkKRGoxbw1RXzO8Sh+Q9tGalAON1MK+Kx7otv/ qqegQTjhcPpRq5me9vf8E12JVAffqwNNYmyTBhuq0hBViKlcdXw3+fnFnxpY89072q+igvHOvOuW 8Zxe1nY61vynv/jB7ZbxgZ+Z0Gm085MsfKAayc16GdBlHZn9Yy1OXo/qtWmvwGnbp0JDB8JowAyu AWjSPOqww0yzquQe1t9crs2UOjueoPrfy+FarMzE/HAd9QvqcewKSyM/Rh50mdQZ8Ag/6w9avzr6 mzSNI+ZMaYmFZ2MmyAvSN5Bt9dTC5LCdw3gw+0Q6gVzTgKonRREfzFeFwYg5DcMLuPSoXz7DAg9+ g+6OGEQP8xZmPA3D1FyzJQuwh4sVSTO1NLQ8bLH3FetRncOD2vjeBm1rPNe+/v/w0TAmmJfTnHXN PCpBzDrdW4gcJbA7ow3LKcJMgJGcvRXRqkxGZRF4EuK+Wl8fwDxN6aTwJx2+fIDPs4FQCMgcIHWC ZLkoX54a453omNVSZWOs2QwrRFiuhP4chE5FHHUezcN4FZ3u2YmSQ2dfZHlGgc6mpP10bZKuhkh5 XCSmYMEe87bJEof3XXkDUfOZBRgCe0PodO7hSOsil9vbl2Q+g0s4s8j6QTjtghBmaX03fD/fU4oB C8OBO8Hf3bSnk6hX7M4dt7MBo+vP3LFnp0Cm2JF7R8BxFM3ngTsIz6uI9WpQCJK9AG3+btc5fU9Q vqMf4+5RSnN/BoX9Im68SFCfAJ4R1nBGcI7jqd067czM9USEgYvFmduZlPcJSSM2oPGJeXa44ttV LKwzBWuvf3dHLufg2joflrODofx/mgYCXDbdu1e7AIJDk1P6cc9oFXLb4WOAY9JBvtSYzP00aVzD FNII38QYF8hERSidaV7xZ1UYv7cnM2GvzfVKUUguqY4GT0h8p3uAxv2ZMtF5xv2lTnsnDr1yhLY4 5qqv+zDf5W5Lkc5vB4j5HOkshTD28Ve9ooM3oJPuMHN/+YxoNACA/uLboBU429eFcKKfRChTwG+A fNf9JYhJ638jCKokzw8vxHbeXr3YPOcGoLVjYpc84XL1qejB4H5wb6613G26szC5tU3BzL4nDKel wjWjHpGzvCP2uewAjkhs8KJ8Ta384ahcCAJ2lzhemMb3EMMWe3UJgLTzVDwcvny7I/gk/YjcSnGR j5j3QmIta3/2UX0Lf/ZeCSDLJMQQrsY6SMkEbvRJcsBKw+fdlEB0OgbnZzUMne83zqJ2khJ4AWz9 2d8uWpkE8UMYi+phIf6RA3gp9+R42azFvO7c7U68HQXrjMXmAToDwdoxDh1ULCLbKhCiFJLGvs4E T1cOHtlhJ9zpTCi4X32c2cvx8zAAYHGMH44qhfVBgtRe/+EzAtYHRL/Xi2GIiBCbPlRhrPPIEf8C 5YEI0S1KutzIgnhptTSJ/xJ7MRKoddQPKQPLrq6qjuGuevbyRsIwxTebODCSQf1XKxymDYB5nTKB Gn9nD89v52lyo9XA3lcNZ1pz09Es+zpHf7clf796ynA2xfrCQSpXkWuQEKW5g8T3XZbGKv0OFBCr Ovp0MlCIwZVwGNRjWCUHObfAlIi1TPTq0eRTuHKJDOZQq5czKon1fPIVgr2lgwDrZhpGLEcjgTC4 A1XIiFCE0JYyxSAjNolcx6vTTeGNPe+RdOZe70MkDCmQeQioZS7wb0fEWfMUpBddA7U7Oa4T7D/u mJqYruoa0XcIzi9kZdfShtO/C9EfdgV1uQIWmhFs0lPnPWgX4nN+rlONXo14sGNy8WvH9TJ4MPQm 1zuKk1VbAHmQ9Whuk7zbPbyd2JvxLC8caAnna7+6SagbVHGGJ/ea4kUhnnMzfnPonMyYXCRY8bq/ puuyD0xK5+DJ+ITe62P3LyuhT9QFTmHcr/0ZZkHoOD3vszEUFvvN6KWcZ2odeFvDy5FdJ26RMIJC fkhxv+rIvdpog4/vmdwAJVFfsjrXdDLUkfpTq5blpIKN8dxpjA6TsrRE8JFg93Puu8rB8BorQy9c w49a8u3S6arDmgP7P3vg3oRz6sSCdOJhF467BUKYWG5CFxzJ8TcvNU0bXSzkurvFmb7rcFVll252 oOb18gsrj/vPBe/KS+szzgVde9SY7jiNNi631O9jxi+eVFWl/56q/ltV/qc2V3UJ2XwMAtkHH6Lk wTlPJAfGMhWU64RrUOjCW1XNmEkKHnO41ftKWfUX/L0/l9lD/tyr0rb3mx3MNgFDN2Od5835s1SZ +ApnAjnWc05LPbFsY09j4Diu9M/NoyUetxO2dl/yS+yq4GjWoLrrMcx5DDj65qgGN1ZvJ3+TyH71 E52/Mlp03RyKAjtICxRBxfRyi48zyD76GTLbU9oeKHHWPvRjMFzjsy0xA2O9ytoRIS/gZ7dEGEjq UmcPkHx16re0uJGtI6E6jxKPucv5DLjOFSJIynPYNY+dIMiYMeMtOzUodQLbXX1qmNIRn03QUGSN vXwOrRlMNH+enz56Cj94DsdAsBd2cyUFzmHAmZqVfHDHgF31SMl6mQa/tWzT5AUsGLap54LNHGlk Bfus1pAKa7HI2GybAt/sa/KjlFnhutIID7ZN3ziCtFfun+UPchjRitLkH7wPLo6EVBDxfpDk9HAN zpzssK3lwFLoikSOKQKQ2QFU3uRPoXjc4FxA3iQvUjpFzqvYcrph3BG/26H+EjUUTPO6MhqdJt9e QgUfxeIj3sZ7ykXYjM310WPaVSM2yuzbocP957V9cvowG/4KAp2bypxu/UwqpqRikyowDdtXsfjJ p2iiouEUTlWnqwVRjDFMAQ40lLCQkTFNkH7ueXb064C4VEDFE+Tpw/fWcYF6AJp0SL+8nXzAJNR4 GS/s+5/DmeUKiqTATW7u+x7V6UXqQHPoOmkdncQ5NVaziSF/FZ3uxAs48yXQqFOo8SPYlEZkGs4L i/NJcj/Rv21Cyi621WxAdK4DAsXmvfJ2SXQ6jf40mRx9Nv/9HetLDZjgcytcBGj9Zkk94p5tiIMT xlAR5LyD4XZEE7b8NgoEBYIvTrUxnCFX0/gB/LKxYFf5CYSm1H+vwXD5cAEwt6NZp3D5lUQhKFgr COXlgLI+y8/EvLTqtl4T1AMcT3HfVauYnNfO2srHOWQmnr0Fv0IgymvA8x6aupw4DQSOUBzwi1BR pBtx3pGhqTE4dKUnIwAU3ruQnQTTEYDcfwyuCjm5vtNoMoKNkpHMjbuJCloUhir6n27ULPwdO55T 9Upp2HWnD18JclEczhRIFgMFrxpDT3rEZXegwtBz1gKIQ8PV7ua360BBJLyLBXuGvq0OV8c8j7iW 3CSiYDSjE8eqFBmmAKif/5sAmzVenrHpIsWgpINc8FeBBA8f54jZHKZOx2qSVhOY8ZYiEMBFYq5+ 32jco3tor4qiEH8HxwA3FN2JRTuE8HS8ePQX5OJfzW0GxaBedV9Pbho0jSO6eILdeyg8BXmXsOcS 2QXRGgkNfoDrxrjrPjhYroMUqdJJQhSec8af5CPGOcX7viRApkGU9maUHsaf5LxaKWREPx/CNTH2 sZPzOPK93W8rKWCQCpV5bS7u8X2cyvvZ9XPLq6cPEBtQgO1WPu4a53Dt7ZKUeNsWws5nLKhdX46V Wadu5zuBS9ceGMHEJHTMudbNWlm+8cpxv+nW6qSP5nSP3olNxs9fYdogqg8B69pppIJzcorMplPf 7Wh50emtfhLXokTyZlLWyrKzH/mW7wjfOjqAm8Qgc5UpqsjgerUo2z2MxRXYFM+2FaV9vngSQFvM FxSQ8BlMjKftOW8vsjvpMqU7IJjT1e+0/R3CLEYWkzb3gb2pSPyt9bmMvSasKAmEAtD1kZNfDyGU ACNLUwtFXTfFEznET/2nRkqcl4HAxBje/ul3j+6iWzrPUp+DAGCtEwOXXDPVMijZLuJe+U4Li4Bk TT9rYA0jiG4a4rXWN4skwLDpDBQ8hbxD3BKAFgenOrAPXqAUIf8UJSlzlRQ1ugtTXchFffViulLv ntMhbEaVuYdeuCkMbfnC7q99wdYlJNzvIjn95vfSceKlgRqZbfBzp7SYj0DzSlLY63JuA0cqkKBe EAzyRdXb+uopiDFUyiR9eGVoTjy6J9gWcla77tZeN5r41B7wTDHIjSj/3EkuzHK6BHv+uloTAyLW hhIesmeqIrMhRfU0XYR1GOQYcBsP8xiBIHtiLXlS7xqFxVTE4v+qfSPrVI0z1OR89cjg2vaZp3u/ sy8IbNOF7uCGOpgEZGoD2repWQEWkR16VnqK3jIGDkXZ4skAUL3otB9tdUxVoUhPgQ1vzYIieUbY r27dyHVL8ul4J8R1N/22x/+TKv2NMVUgxadkmtn7JMjbe/Rtih6/fY+/VeX/fVX9M/1MznqLBu4d uprP36eEsNuIoQC7HM9DetmV/gbmyDWLN0YyHNf7GX6nBL3FcA3fWT2YIiF33v0jJdlsGMRcbX7f LizMsZVbQeImrmY1hZ6J8nyTXWY0zLPkgBrVh3VUvRdmtkXHBqyrG33O9WETV7fqhjX0fmfwMlbf 5RiXe/JUuG3d0pY7CxM6XumaZCpTp9Py6v8BM7rq31Fxup516pDwgE4ik7gKexQBV+JQGxpQjkeS c68KxGmdzIu2vtMbg56DG1KBhJ21nAI+3U7sfSsvCjgL4YlRX3y9PWqsIu4Uq5o6ulsNMX4BB9ix t41mhPYncBvu1rYWU6U19LnubNXJN8yhvDRY8MW52dBv16nt0MlNXfjsRqhfWmKN+6Eng/3wOFsP pqwCriH1vRJGIgdyLRUG3P2Z7iE8P/qPzQAo8PbZt3UzRyO+t2sLB/bTP9kfc0PdRPUdi5PCGo4Z uggNh4Cy4GDI/7bkNV5uGiCWKii0DYVOHZSlorDfxcJ2p1VxBPCGf9gtd1zoLmi45udW9QlwmjIv gJqyodgLXYdAO2Zh7RVV6EHgua4ZEDp4Nv7NDsPzOSUYlM7kqgqZfhU76bxifFx1DAskibdjMVmo oEqxUxI+DrJlu2iEwKhowq2OyJwOWDAYNSerbh/SAqc//i4KsvCHfFiRr5T+sIXyKUhUcTzbFk+4 LkmzsSjYMfK1iF5BbNY18TWL9+nwf5FUq0V1TpIOElVcvMdp2tw8AuB3gu8FyQR1EgI6Z/2pBGYY +uV/AWccibi/uHT2wmmIk75IRuhsMHwGFqnXCh7XEELcwyoFQAkLBZKq64DWJII3oRXTk9LDpfoV kQjkue53kuusk0le9yBHM+3UEKOwQejGaBhQ6/E7PgCJKay4x78IBq4D7P+I8K5WaMf4JdDuIie9 qj0UQoRpIdlRlc4Tlydtxl67arz/22E+xxI6MDoj0glC00Pc4fFz5n2s5dKgo04tiOvic7uLFgqE H5+GJptjiub06cTA4gTHAGmt6GnXy99RVceQnY5mT+d9sNdqirBr1USClBKhlCTB4yvWvU7QtYum X+5Or/N31u7sgJrJTD4cvXwQPbsO5D7MEXc6K4D0nlTbB7mWmJRNMki65K2qlKcpnf8xtu8gypTk 8Wzq7x41vTDylN5EdeGtns37bvQpSjo6xSAHplNMdZc5EcCUgoGf6Du76hxOzbrtHmIgZ+U6KOKM CRf+/AJwteb3hSp5xgGqLpeXwqQsYb3DiQw83uqH+M/hjNuev+shtaO1qtOhpwJgu8Uh3xyctitf govzDONUCx0iIcP5XnMw3BljywgGdxbXYP9IQXNBBW7ExBx3igudyE0uxDq+dx24W63+Y4l+wwnT C8u5h4FwePTMriIHdg/iPwmwKZbwwrbI+5butIlhCWpZR0z6HJa/hhnr7Kh8OM7/qi1ZsETniNCx 304Rx7y/E8DnRBP2hXp/T3Zk9zJd+IWpUqbWLfuce/eWaLGbfFIK2TXtRIh9bpdfYgVHqkap4ye/ Ix/u0e1cFddx3qZL+xxo7SR+Ud3sXbcx3k5Duiy609MtN7G2OkiMHSns2i6/l5ty72u3wQ7eXFpp MF7khpb0xIYb4eUYa8gtq9Wf1ErJWLXDGBo2Ig6FQietQT2jP50q06pICN5FaSmeJ6Ezu8qTrCdR 7I2J1uofjLTry1H2U1dqCPqM2ASLM5iyfYkQqroYed+j9Rj04F5zj3o7eikht0JJFBQLn/iDcHBD 4PjMpO48byv2tkIAkD2gF042hU2FfMtlWvCqia9UkfIvA4wdwK3iAQA2hOBb4BpL3BUfJ9TNVF8/ R3sSn6NUxD2sUScOQZge8zEa/dQ8g6nXEFayl0P3lSQy61qtlJTE2xyyP1WFBVNPVio4e4XpOi8j Lly1ZjZ71oG32dFrN5LATUv82M0GuALTSkvPHlUHs1/QTQpzLvvXXA6+mjhVpjUWvl+s0g8MJte2 z0qM9pyPgXhCMmbyVvaM+2d5mYQ9HYtrDzLUcP6f7qBXf1c/uFAdA0GDL/Hi/lVnZzGF7Hyr+jfM 7frvIQHVSLBSpqjUwuW3yZIOw8ItVuv/TIsD/6k9BDU+OHYzs1ohGrxEmmnSkXwW8+9LcKl9ZlcI yageM/QlpIpJXrOWmzWx1WlKRwMX26AMuIx/t8p/ra8n1jsJwEtv8L47EdneO+Bfd9W/xBZfGs84 +wEWscd7jRyn7AOGoY3pe/s413xglqypCaMt7aFwxpN8JrqorpQdwhrStisZ1RTdapmO0N4idshV h7UHnuGue/gEGSOv1EyvWlWYS5oY2TYmvXCgnR63cHEvWOWRSl1PbmfXAmk+MmGyW1DtqhD1+mn8 pYJj6nBW/naOGJDti9VSFZ6CjjSLqY+bWICQV933adVOnhy3kl49kw+9zLfv8/a3L2QBCrhr4NE9 jT+07s5USzjwwCHO1VpHItRZo56qquOz5V0wzfm8ks3XGeRbJ9cHC418ah1iZBpj9XFvEn4z+59j /PiBz/mouwl58eA1BPXdXiU8eOil3y3kbNH1f7xSgznUy9yb1joZWKneCSE5JKeoRCf/M/Rg9lJH erm/0/223h3I9nyaLeyV5YGd81C6K42QhYOfieTs58GGSz56q772/8g72EfzaAjzcb3daoRXCB+E Ov+uQWhAC11jEp5IMNftpL2cNJ1isi16LJzkUrG7/DxMyZ+4Cxc6ODCnvqcIpIJqVjtkBSJLgUOw j4VUZymAchgJowrHNB8CNY6pHZokr7oiGn244b4E/zquYFfGTDiK/36oTZeLXFd72ouP/pts6hNp sYu2+5Ovt+eQZhRGdDMEcpETs+BU5TRiYZO4J9ovN+p01vDX8mk+q4RAr+GTw6/hDKPz8fa627BO EG+LI9a1EqKSq8xdBd0SX+zG1tiuL7GiCporrcaSpsiMnvIbXCHqgKYAfQZYE3XwbbhKIaUrBF4m SJv0lIqi8FZIFJeevpsxnQB3El1e/31+aOEd/iNsWwWpIeC8v4erxHu1Ogye6CR9Ch3FU5jhdZbr ENZm0Zg5BuFG6ivK9yXk13Hn19nW3fFedJ/pjGOvFUerw4GqwO2iJ6UIhhv2x+8g0JXEsRMJkkwz 1hpY+zkBhBljdUx/Kwl5BpKFpN4vUv0jZsozy1UQ70R1QfqZhOuIXlT8NQ54V8hvYtMnQFZLDCJM F6A9zCDOJGXTqT5Fkey4fKV0fIQgc/9O14dMj7AvceF+ZEtIrhq6JIMYiB08Lwd7itFu55zbejed vDrOO1gDrgWsv0GzTyJRuvs5nHDJu2zfa+xgoXCmqrqF+SxmHOecCsEJB5m2IzHvmOEkmY1k5xFE B0Jr/yZITPUzDTh1R3Kjb2i8XfX+0RB/20UmHPNIAOsV//dKwoozwElqYfSi2O1OXeECcdZxLrrC iznP6+4Ym8QORSMq0j/4potAU73lFHuQkofQlc75J5Jz1U7H6lTet52yz0Hbz3P+1J+1zvpLHDb3 bSa5FeArDJLpqNE+glnhACHWY3G+XO64Xuk1l4iigGzg3dMTEC6XdiTir97d6dckNF/QsYdnvOin TlyduxJCzvQYFmKp1SQoqHChL4iWY9hNYMXuOXfGC8O8aiIvIe9rrwsccUUCFdUSZVQMpE3y4iIm fBKYWh9z0yyqOtPLHPUHSap9nrzf5KjsbpckUxXVn1oJJbfz0MZHulucYOX4dFRL+ecgCVbawJNg FYXbbuB/J7nlUxXkpH6rR7yGMnxGzL+f5R6EUODu8PxcSM5lVK9D5JBpmgf173vg0bkzYcXvtbLT EWtEROcwu9rxcNyLOz3S/orYV3AA3qgenHPzbss0gzoTlQwylvezXsjwGuycQuktEkxsLN8z1ztb IBtD6toywFX72Vgp+eAKqm738RzQYodfP5w3O9nIzyAHSfTk7Kgn84H70z2pejuWk2fn5DNSZH8R xuwq+XGurwNf8U99OvfHZXxF3uSJt++BAkp2MOCrmR2ZrvZePdbLG5sy+FgErSMYPEUVRsZki9O8 7iWupn7hNkYTqGWmJbI8A79UsxOrj+Hvfh+z/7LinZ32aZpudDrqQJb8CnvVK4N48y5Cf3Myd0iB G3d93xBtujPTNmH+Za10P0qIb9/XxOmtvthcS94O0px++uGcddxdjhog7T1UPEy3Tw8ySElsUwtL zeFlrxR21cssyIgTtt+nm5nLs9pQvxbssZ5kWkf6Bq03MBwzpfTk+fO6OwVn+nTojVyX6cq9B25U 2LcYkq8YL4UdJt75OhMoBLjUHIinfGUj9u4hsHbgEzVqlY1RbfMUTivYWD0ZfNDvHt//Bzic2IND UKX4PKqthSHDoNjHrqIqtJ1P/0KV/1dV9beTA9CJ1+8hJU4eF+IEOjo8V5q1jYEcZ3WnykS3CxWv Y11cJmBeuXI6Rsn2WsrhfjJX9IHc73E3AXuwdV1V9XQjnqaImRLTjRDSwmyc4Y+h72rfncx+tuFG Ggws9MbL/sk+uMI1AKoCzvw1APiy5Ot1UvaK5z0iOuN5jV7rMrm3qpdjP5/NnHHJOofXulyfX+yG PZO3agn9LzxCgCuQ6PbDN6ahxXRs9oGFzkRiGNrvPIQvnhvONSVHLhzauMdgdiJ9Rd/CRsiXS/Qe UsYaN3gtDWfujeGZBndWPedISGEOtv9E40CtAUfzwgYILyeUkDlRGpqZZ8+tbNjjfGpcNA1rvHKB 84ScBhJ7wHqa/OU7Z8y8IUKe2N/rLEymok5Du9ew8jQibe9MsNNVMFQy9YUXJpfIcd7hP5pBe6QM MAtlcLY31jdTk8BvWkeacv+/P2bEng9rffIfnaQ2C1YNs5DpcHI7e73iX5Oi2BIaBvNTfEck2HxZ btOeBohOazOvqwhE6USlzqmWRsY+Ls95qG+gzTD566PI8YMIzCEHD+cahnLz4vdJL26BBJP1biDJ bmT2tZ/ODr9cIXzEGu1BgCsCZBz3fRJ9DyO0d2hwjdDpKrrJ6w9I5PF+dxG4RQ7gkrl23BVrUeh2 4XANVUxwLdfnW0bzgGjJT4U88QuFHxTznO65KYjY5PR0MEywW6dwt7soUDyU6xbpp1OYFvnDhXxO Rhr/OUVaur5Hl7XG2NS4XlGP352QTlrb5FWQE+3Dedl+gNt3wojWc1U8v0naD0dkZ3KBQExLU7W9 ABtujNiUQCNdWueQIfLYLXI11z1NzPlRltJa8Qnf6xEnmiLPisGiQreZEoPF98Tq26P6M5HrbACK 3Ygck+oJas2Y9UkDGoDuqLh0Pa+C2c+5r40lf0ZBThErJMBI6MVO4svpNse3/Z3ek43gFVFNIKsO oVxVejBg0S+hwxS3Ug5wfBBH21XwouCdMXMBhkEqihl2eHzmOwa4vM+mWQ9QLJgxQnHdLRKsbPaf oWaIzz6DM/gHkOtNeMj4JHAYyn2ZziiF7se5lt+0IEZpO4dOuyB7ChP2Pl5EB7iodIEgQ3QO8MeV giodVHiPNjeSqffTEDhGXm5A14q5HHsngTL7kekoli42DmdYmhwXxNZqnPuZLEKOhXP9GGpTrlxe ghVdko5Fj/PpvHubi+4tV6UbhSF6PGNKo18/VVHbDVRf3MmFT4RkBZ14pxhmIvITNRCSWOhtZq/o 6yp2j+f0sE9c+FVn67eIqPxcJHDTwhXSCX2QVSayaPavHiBwRZzp7M2RHvmco5o9OOX/GYewfJ7x VyrhPncoVyMxrsKf9QLjqIbT6AkVcbsT99FJtpPbspT93FWx6ehDGOdyFSSdDcxNmSZhdC8mUJ4m QnyA0nz2bPLH9Rpu1WMUWY/eyPhevZw4qZqoQ6LsSKNr7blzcLDrJuZdM89XP1KnPuIUSt16m2N0 ZyPy8B/72hXmGbTOErsR3HRzWEsHOTmdwNOgRAs/UqRPFpBDdJ8WDDkVrD8a9D/u38fw4HZxNwg5 XFtYqyfRrwODmXdnDtg7BpenoN2b6IMzlcgjnxgSyTde955/hkuzm0k85vKFd6WzmIO4LhAHO+5V GmpDdF15Qmz311t2V2GUoIWUeGC+jOPP5AzV/km0irvwJk0hOtbmg+e4CFiWI/CIKjhJuyeldqxd C0H3BmkAt6S7xws7X2iI51CCUYxsSPzyuAvdsKdwSo36mJLudHTrAuTpTkTauJ+aoUAafbR0RxOG nEJDH2djFxj7EDB0EWPvG67ByXuA8HXeqC7R7RbY1XKrTGx0n+OUBpACFcI1jGT+dFg0OT6axhoU 3IlioPl4jvrh5uOz9kSkOlE5hxOvtGUx9A7mMxEKV2aaY5rZGIcU36YKtPv05CV0DFVp9AD6ynEE d3tgi8x58dB6F2Ll7iK37M87umpqr7OAHUmpZrhGVV9OiptjTbynEL8hbtJoi+Wjo/SVVgR3h8Rd 874vAtHyNuCrQ98hTCHAIb7AF2hvGozlapnhVL0s3ogjljYT6IVB+sglyJzPM02JJd0r/UPLDIqc tKtYJjwTW4wysnYXeOMkuzapupN/9GRHVGzAdfHyUQ/oeo4Lb/SsW2rxJeFEbjY0nPhi/TtV+r// 4NUuOAWuFF+j2kB4jrbPpt1rjcSKP6rq/1hV/wwl3l6pD9HxuL54J7Mok2r8F56yk1p0pC7HeefU U2il1zs+6kw08eGOnXqDxl+7nueXYE3P868Qe9aJk95DJdG9SP8EeFCNdENBvZGGGVV7OE91Zbpv A1chL/NLKOkvuizBfUYGHpy0odVNTOE1DVwT11LIaGRVxUkBVAH5t7jT67mkMQHocfzNBBAqpl3L ORDfR1pU/txrWOaTPPSZ3Jn6xVpc5MYXHIkvPjHiXqdR8i3pGbd+8U7Y2DV6Dox4YVHMaZLTfuCs BzZmQHG1TCeHUdJybh/GW8re+pUylAOvc0Dcy0TAB6cysai9i8GA6DkEud6bgImzo/fcp3mY6UCF R+nnpPX5YG+3oVomu13Y67oZtM/nb2kpClstrhWTzzQOKE/9zXV+6uAbPkZljmGaXNs6ebOd2me8 rXRwq0b2dKYp1V2XrDq13zV/fPd/2iC/q3Ba8oYiXpBjnYc2k7Yvx3luzgWkm44Cu75MURokVx0o LxBD3+G9tz/JFcmS7mKfRbC2uFTpV7enThwRITUcgTbFoUUuaTmtJihPcYNFjXw4CBsnJXuB/hGT 7EhHB9jbY822cCIvcp3rwuC8xmDNFAZkIoDPA7Eiag3GMZaofl8asfLCGXimC9QBAvdim7+tUZRr cCMyNNzZZFCsn2HtsW/QJc+lKGgEe7ydhS6nVibU7FrOqYq1kEE8TfS2HPIKQZspMiXhtZsihkK9 UgifRcOGpH72jjYIq/OyXrQzthy52msVfO07m8qA1uCpMGI328MFTIOIUwc5twmCCbTuMy1JiByq KmiW53seE4OHkxDH1N2+XVVX0esDonuEdYELVU65X2QpCYX0GF5Kp5y3y1LSJcY9xPGfhmI+ISLh U5zFtfAMCVe7gxrhmHHVLcUTyCs2CNm19DPGmWS65UIA+xIezCniJPhmvJ+OmgdcG38Jtfy+Szdw KRQM+Wy6bapccihsCudT/qZLcCk+oTkBJAE3P0jMag31BtpzIKuKhxK9HERJqKNo2F5eYdkSXyI0 bvmmMFOV4jEfGQuXGOkWJha5rAZN6ti/t1eeI/Luigy/KO8JjFQVgq0MQmSEaYLLOuuPebb8Ot4/ 54WOHq+eYJUQPOn9wyWsuxr4QjdvdqoqdJvfNeOn15gA/B7kyqHXC8ifxJ/Ovq8LsgruyVsOpwX+ v/r0kOf5BiQVw+A16qALFNui/n7G9kg+tSjPiyD8NrxDN7rCwWS5MWnfSz5iLK+BcMWQhDZJKx0S GsX7TEdYh1sD3uXh9pOxmEx4bbefKTDUEDdURNK/qkutugt9BlVNcFcREmxEGihtjM6E34nZ7cSM QgBwR63SUJaOwYwXYF+FMj1RpzPPmZOgdT2/r9r/w3VqPdb59ewTC6J+KIXxVSSaNZ6Duw+47xsB AFwhxqnz7iKpXB0d1OqY0cFRx7D6THBRkQhxD+RPPGjnT3YhVE/+UOyhDAKeph+IEZl6RnFP7fnT Mzq737UkStEa7s7+t2pbqFDVfiG8+YbHWS2OaC9EZ41iBnZm9coNoZ5BaNViwEtvp/aj/v3V1tl1 I3wFaDA5Bjq8LLsj9/gcqspBBT+4g28x49mHuTgFQo3UUl3OYS8cn0PthXWpsJ8wujWr4cWqOvDp vacy2S1rSx7KbHeyGMe+PNRioADTTAUpJT58jHuv2uqO5Rg3ya6NER/r9+P7Ofr56PrcHJnVXZgv yQA4eVdFfcQ30xQt/Lw71eR1oI/jz5D38Mddun4DIzPUuRfG4yVELzC7coha+rrsw9xI5IbrXQ6o 3n3MdkUmubDjFtxnfX8Mr9Gj7hyodb7dw5okOTbvN6eTnqqC/9omA8aB2uu5cyUaA/8o6Nqc301H dwFFT+XEbkoXd2X0nNcabBimJKZbeJpb3cmMux7NOiTONM1nIaypbx7RTwymBk68XT+vPse/FkkM nvkQ9FDvRGls2fkwb8/ihoput07O/DJPy77MqCHIzjhTUfk3agh0XCkkjIS25UocI2Cu5Kub0Fer ZkucbDq8e/GQHzf89PNOjtun0DXHkY/1tdEWJQrONbwWjrrvN538lBeErrMXVpHv62UwMJLqjnsu a/Ut4BZWzlskv3uVLc798ByceOOowxR8hDE1byZVGd52HWkcP+vJV9bEdB+eyXn1lFIPTvRRvVTV f1pV/0iNO9+9/E4jpkyTazBG4E2rY23+WdP8q1X136nS3+JcKhqG2jaBH63FYbVzJkLpS81pM5Ym GCYsuEs/OELWxNsccmB6/edGqurqkX0L25J/F55L7liHUkNSh5XIJRC+sfdMRtv73AcPl7WrDiyK DDZbv/LAR8bada9JZ5+pEyO9OMiqOgx5yF7mNsm4cbad2EFYEztv60yw2Of6qKNM35Mdje/x+Wk0 2zVaV7p4jLBrscaQZDnTohz/7qhk590izeHOSOQ1dsk6dZsV69Znqg4bWPQ6ZSZCbPNDHj2tb7Wr OmfF6ambv559VhETi11VaoAWrrLwpuSZZsWtXSnagEUpnNx9Ob8776Zhunbev1tD0883I5LqYiOE Uh39k54mIsRfnblK9pnYvUkWYt2Fp0uhkVemNtLaL9QzsZxcB1ehL1iN8D2x0TfrDoQ7na3uvrEi OKC5MEfMBgjxjb+YsxH/+Jf/9QcD2z5AkzsyRqcrxDWXeLtHTfCWopDqLD2rHUzhcr4OiN2YUZNt v6OOA5Spyzlii5BeESoN8I3LoJPoh3t1iIANU66fw7+G+3Q9fGIXlGkjaDa+kV5Thzra17wARBt+ Od/vzbvjl/UUQzApZSiRfUTV+GqbIFqXgyavEKekT/cqJjJpgu/1ZQ/qBNBJ0kzr7Q6h48aBXNSp mZhCSJrzvyaDX0MFXtPFXShdT+J7uqasa1JE0SnOiYKCe06L12OC6crBmOJaaYOYBlJ6NhM7GpEm eBVENk/I1SIbaoFZRMmmmGENVSlJRY7Qea2tBb6CzEMNlCeX2Jsa2M7lKnLVj/uh1V2jWYmmfyev ZIs3iBqEo1PkZ3QNu06HdHr5ODQWFvPTAZaFmARm3jDaHkrapyjHbE6BgGMvUpS4fiPJoUdGpRD8 cLVEoKnAU4iEMulUZBQ/3r784wwTkwvh8q6ZdjMdRY6YSjHAVsvVwCHeqFHP9efvda/RFL+ghXWx uJqomU4WJ8AAjrGuiBO8YBbjzX+5g1/xYJynMO7u9Xx03JKTWON8poo6luPH72HBil5B6HsyiZ+M +cuWdMcds6hI4K8hAC/ruY5qgW9aNaAwspyHhK5qb9Y9lUSUrtP5jk1UkavC7ZOx40dJcDDBU3bg WdXJ2b+h+2Q46GxgdIEN5lrtvnPozsvPuVOTiFowAoAGt1Ny7JyfVRFrqeXe1l1w9agRSfxJwKvO PaazCsgBPsGJtJPKJoH76T1HFaf9lgXii7XaTHjEN5eidMKknl7HWBQl+dQYwtrjRRTZyXtZJ5Fw jWzsfwaE5nA6oqjRHhOpa/xr1jhh0KgDA6kjhWqT45z9pxWYqD5wg89Qp7tbrfuulgO0D0rfEDmd 5x0LyEg4Q3diojUX/c/kkQAE5rrwTo3heiSF4UaYUrUHBkS3u+8e3XCv9bjjic0Z5aN+Dj5Og4fM yTHGpmvdzVQHZXU/yZOZAMaoDzljUY/tosGs/iin6YXASVKne++XM0aCQRMHkfIh/ZJSGKiWcpg4 /awII9Lx2Wu4dN5Oi0zkjZ/vClGKzrpLcL4o0qBuijYHKOmcU1Hgq9f++9y1JhpFPUGKekgdGSV+ OniSdMJH4De5Vmc2AQgYXdDbzeSXq5PRA2+9TQXoe+9dr3qn+yXapCN9L080El4Zz1jqG32QQ3o6 vdYT+UlMIJkknWgIC/OHo7MIzU58j8dZG6mvfkYemJzmqaRwHE/stM5eMbEbI26QhKR2rQb1O8V4 09mbAzYGGUg+D8PnrrhrsmupLUuglJGiEe4b27xTu+qoZSrFMTY65o6BD+/ayktwd4w26ML7BNS/ F96oShchdpn7ccL3duczDF1xOo4OgcydbLNddmvxMu15ogvvTuPbKbXck3UMfLtG7tys3mcJ+bI6 3yP1uN6DWuA4yjwt9IOqg0+h04Qdvl/ma2TetoUC7qIpcX3j4HbqQP8M5928//Ku1kqeZYyczOMI S/AxmKMw/riwvD2QIVRBnDWBXoJqHjyvo5/h7++R4J24wVYv5H3T7ztyDb4GGCYPl7dfjoum5UlB vZPDT4TECvi8xA+F5iMwjAWDoKRyIHRmDxX8OnuFw8uJi99ute0c3zzIuHPoDviWCDdxs234ZRrq OlEGFSUFesBmLYrjNzQ+PlK5+I58aSR+/vt/UOX/BLnGhRl8sNKu6/GRML7wRc8eavZ1P2vvb7nq f1elf+4HQzLpWqbJ0c+watOBE/s4uFXTafUSJfe0iJ1xaqzuHcnmhtTfplU4kyyzUO1iW8Jcu96s /47PGawXa3K6t+fQR301JcrUgTqfs1d9TYnrdfQTtFsIwx+7QxNRe2XdUkL0Z7Caq8DsAej56skH 1DMpjo2IsLvW5AKO/PO4bXfK3dm3idaBzs+T9frqf7W+q687m2wnLqxj6oSic7Jjj8c4j/gu2t76 5ao69D1bj8WGAH445c+90TmfTK3VWaORWWAmu3jw80UpMVVxJir2CfOLhnWVBrA6amYanJs11u6x fv6bKgbZfvSW9sEm0cDydu///ZSDocvVRkU0kscurJXes4ce1XA+JcLo8Wcb86DLKolxlKo5RMV2 mFWXnu5joPFCOplPd2DUXj33K4GD+tkrfYp6lz1Q1HpD+3nnkYnmxvg+WB6Ndh48hLIfE/SUNiMZ fTf+cUG2G0gsJGIUMWWzSd2+d684MQIOWuNsh+z4BMK0RZuzkMpLpkYU4AQHvs2eVmVkp3A+tMZh 7AdBWSFEcRM0S5cLg+BquMQnCsjEQCioMpqyu6PPC5AvkDpAU56CfIPsJJT5tTZEjQ7DaMVi0QmA +AvRsS9GIXFTBM0dQOBNkiUgVUfBvqdWeU7dJ+XHE1xeBQ3tIfo+4fjgFo3hvTuOA3XF1W25Q4pd tpNHNuxVcwCBhhcOGmzsxVxTdRKDDPAboyszDo+Eli85xAT9ulg0BV1e5IUP908VOdwamkwvQJyc vX/2bI9ZVUb+8OWVwskJgvaBKZqgW9GxBvc4XUBCOqAQwLsjhchlvIawaE/bLpDfKd7WAil77N0R RI8FZwZbbhD8IqpZQETTwCwoM8hVfcBPPr6TzluQHKOuMMcxBAcCqBT8QMmvz9AVCdAZornE6D7v LvLg+AFk61v0rNYZuJptV9xXW6Q4wSoSTDGZq2OieL/zOXzDK04gEuHnmHfHFmsZCd116mjWtnFv tn7aT2csh0vD7bZ8OQDcyUizUt4CJ0McmgIQy+SPGoLd9LHee+6IroXBIy9BUZkr6b2PXDWn0FvD rlMORI3VrieZsHYAA5ffy3SUq9MBSKdgMEnW+favwQCWpMw7iYQnPoaT7DpEtj5cS+4YXHI1m+A1 pAx51+ten2sNaImIfB9noED8kZSXscepJxTn6DlJrHN4Ddj4hnb/OmvQ3vT7cYf40RktIYkvsMa/ 1ctqDW3wmbtP3Oue3qJGGFQgEJdIPSncxblO0nCE8HF2XK57222bKOGCGkQwSEv1gtGJzwg67+HD nQhGGEgNt7t1CosI71tGusXj7Pgya3YfGMKu0aaT19VnF8TPawg/hhNU1enQu4nAmxxREk+inaaH 7MVIB88UN0FPssX2aUqwY+1TBMBDRa9R/Dq6ZsTIVHDGVriAXT5YnzWYZwnnAwnPgnTvI3zBWGNc TsnpBOo1iFyIZ0xCdIuW1go3uSF3gmbuky0IumvmO5p3D2byUJ8H2M/uTCxumi5WkAJw5JIZhxJ9 ujsmNrT/NqXlrH1mT2GLZw82xQw17kLh4EUFJpuiuayXUv7lc8hDJ+FxJ2PkkLoHuVre77mqIgG0 It5+Y89XwHn5GBcXnU4F3RyNfwqTY+rHVfsbmbTjtfnM89HH025KQbtzPS3xwmWTM8kxV0XKZKIv T3HWuMezQqN0zfRQpaHKFS3eV4ioikh3V5Y5MM51MQmJGe2+efXENt7vkyxc3901nHp9uCL+CK61 sX66X+96nt5Z1PhY61HH58fa5e+6jQIuYyr+DZev2jJE8PVcluhP0J954U/ScWqsCPqQWup8N4LV FaKWJlC5hSH6xIur0LWzzid2RY2zwMuHWH0K0/zzObyTTTVreRo4vbvoT13+4YzyDhv8m/hsuIa4 v53HAlzkTqo19lGXx53jTNFDXEICo/XPfRmafMQiHY/zwK0o1c4nu3P1Cl4iruzQQSwnLSQSRHIC /NMbKVjCfeCajKZZ1RLEViKjgSvSNoXKhNGbT71dYnn4jLjmOs8GHffqTkS+jd7g9NLWY6jV/Pse zM+uw1Ap+9ybgWYpDmObvUZSYKyCMUMf3BG7oX6G+ThR0OtM0nEi/3CcynrX9nkWERNQyJkX6D2y 6k/RlLEu+9S4WXuyoRUJmLYhh0+JvU4OzFR1/MO3RLYNbbgPhikMgIy85DZTmttiid7/u6r6r1XV HxNjqxOT70K8zhv2czV1SFN4yYgN2aj0AQuP7+2LsbLX3i/sMHeCk5cuZ5xNSgOdOwF0fTNInQJE B5LiBWeTjx3zwrkqzxzz+pti1cu4yqc3r6E7S0ZMobt+5bTOPrLrWLgz0pfh7s0LvurgXHdG7Q53 ZvmZdi0duAUG71FK7YtpJ1npTMHg7wh1yfqOOtYXW5HVSC8Hhc3PWWIQ01foaTr+Pfdj1PJ0xx3u 47k/+E+FpnGZon16tdRa6InIaKXYzTU6DWdfhnKE3Xjxi4XYx89d86z1puZhYvLr3WrrDHVUMVsz pNDU7O5+i6gT36Ia8OIlFCoe4vuN/XE+555sKmnV9Zk+Up6Y2OyLNNLDCpnMdpM5+Z1IhDPXJXst 756tD231e9VTHoVpvlXXcPMcTiHDaDY+ywTQncy5sW9Dnc8DJVtnlEnhwb/bWQOEOWTynxLffZ2b +WM2qwXU4jtedEQ8L8FixVyR0ReNL/dFYKgerhoAWYoPyfT23MAyxyz3i2oTWUY/qDo25Sq4o0y5 52r3Jc0Ohwcs43oc6ssNwZNc64f5y/Hl4wKXC5aERj5KJx0T4SSG/uUWpdO9W8fP2e7jE4QRHMYa E9vzQtheHY7irRAAYMCivy4VTyBvF5jtruoiZzueln8LgjJGLw844T7eTZIa+MZT2HOP1dGY8KFb nuR3uYI4ZvrGMelscCKnT3PFtGaihKCMVUSsGki6jwCARBxXnsByu1aBxIh+Uwpv2Algk6CCp+qf f2X89rUuKoGL3uUF9ooMKwDuHQXccDwZkWopMMirfkcPOkU5vmk1HxPiOhxY93M6y2clQcP+zXqQ ggoRIcWxbfcO6WqFq8XRV+zgvNeZjstJ7vTyyjv4DkPdDkQ0GLddXLK05RtXAKz4ENtsUIjdyerR /PcDr1acsaFpIY9NrE8B2mqOtVGksguBgPCfxalR7NiPlS1IeHv4u15CcGrMktjp2a+7tsRbi3iZ qt+IMKy4WSb5v++4PPUJEFYI7IVP+bXGpqvGJzWn8t+R+FS0JxyxgWo1jlQhIL+mmBXRrd+/C8f5 ZVOWzhz97pgDvQYBUNQ9VSMhxM8h1xQVf5r1K7h706xIN5zixTy1Z9TodCjPaNuZQKOqE/QsWCO3 MDuj0kEw6gLQhVI3cu+ln1SOIKgDJdLhmKmRxnIRGzfAPgUXdZAKtPO/9WAsvmzCInMvsEX0iQ5s wbTPPmL3vHr66vpAASoqiHokos2+cNcLfggjtrjj6t1c02GFnOamSJUcPPJepCGyHSesw50xU+9+ ga9JJOT9s+vFDwDHYhhtWbbvZyAkTygxar2NNWT4M8yneyfppA189kE6sBg/hWVOoDSGbNMBkxCw m9gnhMfrfmWxZSZkVV3iQq/IYJ9UR52JajHEfIn56o4mvTMqVDQwPnEr6GW9937GzPtMJnsNE/B6 sMmtVJOc9BWizcmVdBaPU0l4mtB/VA6Nee3bdP8lh3ca7AqnJ08XwIt8SQLSj/TPq0/U4xRuYmt7 uf3A+WMmu3aKJ2EsGblexxl/RYXncL1N645HTuy8p2+xlStFegZsdxtFfKK2xzlsEhK1u8FkCkCD UBvLryFaod5um1RgAs6qGLoDWieSL5GjAp+teour9/pcBKQZHw+RVfhK+QvNHAhGkWuY0KBHDxTS MFrhkFIZqm6feHMXRb9cp6umgPbKT9Nv3J7+ImbxEPYFVyK6z5J76skUXczEA5zgRunk2Qowci/x Qq01TViVhpP4bUTlQ3RQZ9YM9Xrz/FCGsYcgm81b1piMjs9tquv7cF+Bg51PkcsWUdUr1dSUNMIJ Lh93Pq4VdDjEs+WPfvNdsPCXMejLnVg43tjTUDuOPs93X3KeyoERwpXv8R4Wb/IogE4Jzup1Rn3k 8pPJW079MACc4vR5TxlQ2Z+7dg8ix3DG6enaOHTzMF/0MXU8vzUiLt7r5fs2+tQKydNsAdSQdmi/ 5SX+kR7CkDRN6YK1LeTaA2ZVLO69xnR84NDUP23udIuYbrRQiAH7VBGQM69H7dadyx9vL87frE0z UfI6l/zlf++1HAk5msOYAvMAHUPLyRbuRBen42hUnKBNuLA+7wQWB5ZmQMGuodydguCn4Q/dD3rg r3Q7JieXJ8/EqyTQeJjQT07czpUgV9XfKAR9VRVu2hp8kwscjOG58MjmxkFdUv3tKv0vq+qfK9St 0GckrGLW1lNQ+s20SvgNxg2ki3cr7FtmOkBFwtGVSqVhKDL31RyY6cnQe5d7abhmkrzBGI0TPXlt bTyWcS9B/dr+jlZvH5iBDk7wuFMqBxgpqWLyIGnZNAcMun5kGYidZ4MxCW1ie22oQVU8rLYHNfYg 0BzC+Qx7GvV1FalBRlOPnna0UwDS/V5LGI9d0iOpoH0TbSbZ69/NdJXESbQGLXJI5HWu7wQTfXXT v/B5HVLqbVbqpZcRPo9MA72ySKsyBYsRg4mH6eA+1c6S7B0uafbG7vdApsH0YQzdquoyjO3O8KJ0 Z3GfQzxQIVZSyEsI9BI54LBuNwm0NIwnZU25X6JCD8jmBx0mn9ocwnR72shAoLX2hdg8Fe9/bf1T IkDSJR1f7Hzr2fZQysDNxFh/JgJObYCXRpp1cT74L4H+wYF3FNiTENbiPYi3xK/dyKfjMMQmROo3 DS+7Hr3VfHd/KB7uO2r6OT2pbEocQNblXMPkpADEVrx6H+SxDuDI4Fbn4SSZjtBuC9Jhwx8uqib/ UXI3fLV40MI6Qeprms/Iciku1R0v8bMJlY7lWp8BAbpVtOZkZx0ih10Qb2fMbC1LJHJJMHxf9X5E LLL41ytKmA7Gqpi+lI6BDAP8D8KqJXrww2GhN9ExXel1EZkab26EE0w2uhiSF+MWjOuLtKVPzU0A OF0OYw5V+1BdB6CBMEBXiQlWTIdhg4M5DxBMwZKR+FY0mPoi6lacU3lSbwdwAkk28MrO1nRR15ra 3hOe9L4VYg92ShljUIvMKZSxVxAmu10hSNrL8WRMTXZBeXenOQnkpEt+xA4u9GfMCOocnupOKXsC n6SVdQRL1iqNLnCkjnWX4sq5P3Q2XhsQzZ+eJC9FCD4E6Gv4KPd3Hc6XWzySoMAWlpFMSSdgmvcJ NWNzkE+r4byjo2uJBaSK5JwObEjpvBMCFlcCFAcYuM9SaRMkNOyWlJgv2YwdZQvvulY9mmqtWxRS 0XKLa1ysjZf7xlnTTNA83U/SIYiGW36EaNJzl7NXG0ThQfOTaQEqEnWNP2UmVOjvsKjnOiMCisrv 5Uy1sHMP5v1H4lIAJAwEpra7QQK+AjC81qDAN0+BOTKXCUqduGeCm+PR6rE+kfCEuD/pig7l/ssA TrCTDN8pU4gIQ3qqk4yvk1ITRJ0XAFm5D/OM3w4MD59wX2GfO11mDqjkcKVW+lSmabkSgBhDqEoH iJ8OxAx+X4Rrvyc7CGlcl3emAEoXDGiC07OIxCjkkjXj+W4yHuQIsL5JID3xhehLQkCZQr5N+ucS 3tKSm5aWPk5K3QE6AhUNZ7XyfL+DpTXSC/r8RJJ2uX4ut3ASlAqEmT5JfQJHL/ciPRx6ex9KwZY+ YDcHgLqjn+uxf8cd5/pSaWzhR7rpuYOwqgi6rQMWZYBYlYLTlY7oPO0FhEb2q0maTcecuW/2Ptv7 T4eL3SRqqrYz5DUwW+AuHDDY+rld8JipfCTuTIf+H6JRWatQ/o/O/q6JfWNAuv2nKwToRmlTerN1 d6Z9zwhEK6o0h8j79uVzOTtKQv8Yl3HsjauOyIEJXgdd6FcnqeNid89VAaG7Mzk1CRKw/BC8aAwS qSjRxc/acQqOEmkdaX0xOGYYqGF/uy1a6Z9/44Gz770SWbX2AVHcHY/hoXkXpYIZ1iwINCTEHkdf islYKZC5TDYmOexjLXtgbjq82K+b31C/bzEFcUk2CymoC0JC1W+B+46yHj2FjR1wHWNmPEC68VnK KXJqQYsH6Daeynu5p90RAjXTUNPVstUrmpivAoPJhBoa5I34ddV6vxdepvNZ81AaDVhlUsccSN4i Vh+u+1d6WTrnpdx5O1EvPNrdAbTaQBBzf5cFmCL1jCLRZ6/DuO/sAfMsqCIDkclaKWVuv3imVlP8 EooLXO3pDKoiSwIWetI5RQkhdSL2kRPCWKCuPvYe6PfBQ28B4EfIMZ9T2qT4mbrBmL6RpxUyuN+4 AQOyxi6YjqQtSNzG4U0N18NXIkq6Ce6By5fbeNaHcZOp0JTi6iE7J0rukQPv5059Cc0IP88aLId0 CtOofj3PxIMn3z9FYQ6usxYeN+uvO9fr1xnIrtBC19GorYfD+DLckM5kzJECErWFIMlo39t8HlGa 1hyQm2v5F6c4JGyCe9WF4493R97q4yKBmuH7ODMtYfDJYTRFIuEKg4SrdnRtIfc17D33xMIP/8ZV fz1/lx8pbCRr3CYHPbF4YrU9TT37Iv2Pq/xf2d+x6kp3J06WnFKdKbmtnuDU5plOnriA4Aak56t6 JRbUk1F4D3wQFzhN/G4TCXZlF4obvZx1U5HmdRPO3mIalKz69XStpYHNC9M6zrii8yS5bXYd14I+ VUWfScI7U8NQaStPphksOqkH9nQkhxwY/M8z1/zsPVncp34mdYQ5dEwA3WVgxG9jDqPlIHev4+bA HuuMWH/0LbWLh9/swrRZ4ZCNxwDhdFkn85rOhXklKtVbi/REkm5WaQv3FeYdAn3E+8Sdd9S+C71w OyfyqDpGZlKh2nd1N3rrg18qSriv5LZj7dFa+GaGwaYl8+4Cayknupr6hUyW7Do+sl4jzQcZv95J 3JkoX8W2dnOY5erbVipq6TE4SBlgPDSfRgWLXz4yhNMEoWuENh7x4ieuNL060m2yL2FrXYcBa1XH AFID8MGtlmmH5r4k4xI2jGGer5+7f+TFu4HTArB3y0RfQDhPtOTC8WNzahxCFZECQtfQKl7YGyDc ZMJoFdW+pQ2OJ4YokhQkOVw6fYAxOWU9xK1KYWq/sEm8zm6l1xxEPQhpDbBwCzQ4yoqaL4+manuz KEBNFclHHI45s2xLMnY7hegQeOc14HpL9NOhzseRewnE85skEW5s+se70yEv0p6wrAGsq1I8USFj mcJGkjfv8vuCPgw/uZzEXwwQiEC8QoDRe/pNQheiLuTmGVYt8OuKaRIUDN/OOop6btvfh3ClN7aD 1MkeTEE6rqtMC6DRdi1wEiUN0B4uiwDAkYj8bvDaatJca0lY3oMDWu4MHWCLGFt/80mjfeshot7O zvpkzCLN1ot0B6nVBzVezlsVTSIHCQlIbHIwpIEHATi03G4PtwKRK6ahekYRJJ/qOk9odg1SI/u2 m4SPNaC1FxWkG8/eEwnoiKS+wCIdMeIFU52FgqNIQXCKToz7s8b5iO7SOzhAmSzTwdwUabHYGiUk rhVfpuUAkp9nF75XRN583z5a4m9NSE5yK/ZZVlMU3FkrHrOwrr5ljDqgeGOlcYnOK8ReG/SYO6N9 W31zyXlRIA6Xz3qCOUS2L3GQAEQdDWedwxWbIMykIGPqBN8TfrREHuePMWaxosZHJzLdBLkjPnLd Y97kZGUKgF4BfDkYYrjbN/lAQ3CO4ZtvFbeQ/CeBK0tITVlbY02TW1/mnc2+S3WBKVqu97Q3pziF kjFmhKBD0LFBmtxROs+T0U1rdy96RpNO1zVKuKmj7yFCbAHsgttOGoBIF00q4tv7v8tkJIPLt9Gl QkiqI1mvOsja6775CI/UNh0JnudgzmtYPpMfrtQj6o05Wpe96AwQphph8aklDe99glIGkstxZjru Wi0R14dgdl0C9g3QztrJ+A5+JY+MeqSuSPB0tOF0HQ08hElDGjpPQP7ab4UdTAWFk/tISxh4jWYR JrTTHasKEhnVBEA5UF2DoJtDmzWIMR97wUH6CGcGBC7Sgp2anzFd4ni0F+VoJ1hbR5JNeG6J7/BO olDM9iUazDhTklbQGXGIv/3ZU2+anBNQ6jSm8GFaUVWPyFyjEUk6JMX7ceFgJd5yov5OD9L3xhbH T4Z7j6g3dhROInDjSXR3Fo5bVHXXfmOqKUWN329rxnMzsbKldmMY2CnJnKSiADv0w3bGLQHgoqEE qWBch47abTlMj9VuBz7Hb9uQ1jn7oI9DZFL2GxWXLky3ag8vUJZU9uMpOh0YrBLp1ZdzYeLYHIHc nUQv59LJSxSu1i66zGQvFhq47p52u8F7979a9J+5Dx6R8xjLvfG5CtJ2DGWLBjQpZUCYknTVFNOd jJGR21k0zS18cjItlVi1BDmJce5BJuqU6hSa+RgK5D3V65YfB06i79DtNPE6L8dL8rDed/nlPB4i p1FjpH+5qMYPbkKblkTehlJux2/Q/jOEbrHUSOFG57PqYZwpzX6ov4qUtDWUUQdPzrYxAjxnRren HOJ3BO9Gg6eBrYIxwtvVMD2RCeHteO0cvkpH8egLxUIS7lFmD7j/3uTcU1DTP4UxCd4gqBLqB/jM Iizh96pgTkNJJNiglfAa5NMYsL5WvQBnX71YHxQSSwmFdxa57c/UqJ3Q6gcXsbnTMtcKWivWz76i Dk6XxWsk2BY4lCo+owIH+fABl5u34Lxi6eQtuTM+nypKLr5SwtNs0UtvsMW5zGldfP9XvOz/W1X/ P4c1tbFniN7fqSHp+3Wm78x3/HEsraqqf7bK/yNX/e03R1SIO/Mwg74gN81QwgX9TsMktHizVb+n S2xBX/0yqVA6y653S/eVLhzJoGuAVZ2Gg29WZry/tIdcddscQia0rjf423xx42Sk4TDq3XzwvFz/ ODABAWbzzdm3pxxMjFHQw1ISgr4Y5qlmEttMU6L0u3rUph5mLd+wyFg3gWu5rq6+js4wjxtg4gOj V3CAF+/h2J8b7Wdh7hT2f3rc7cjsIhPBCt2RAnNmMziBY34hOyDs/jItmhL4dOKk9DNVNDgzB+g+ Z6MiqfHGI28mPuskcoo/frbCtg9ZV5CY/+BTE6NYQ8299ja7eYdupp8Lghpw1CtYjT1Y7TSNmkMs s46fg131OMsVxj0aeKYCh/aJSs9e32AASDhGZn/lLSbtG/dOPd96kcnJz8GMvMFfQv6JK+ihFEmj 8jePOf6mPQd4RTeHHjkVPAzCQ19pAumq+mO0ceYgOAbvM+hdxeT47Q5SXxuteHC6CQydgbprIYmI HyaFDYTdeyp7/hmX0+NROievdnP8icNtF5CWgF7ZiJyTdBgVTNOuelJisbh9BQ2zK61a3Ngu5J5R 2wCO+hSmXYCA6xXXZSwiuIi7isl+mCbU6vP3plyYfZ5up7UsfioAyxmz+m1cZQJX/gIC+LiCpvhb UMRPF5h0bPcJKGpFX83oHRatrxPLcxoynQY4mm2UVctlUseZVAdYgAW/GE6nhri78/WSKWOgCpqX FceG+54iIj//W2dhR8D2ferPz93XKssykAzeb0gaUVYDhAnHzXme7rPYK070DjB0gIq5H3cTtr/d FTeee+TzDmjq0bi+CuFqL6JLxdOBKkzMcBIMFKNKd3QSxoab4HrzbnHMOs/MTl5kXXFT9h/Afp7x +14LpxK7NZ1aRFqNM6jv4Zm0kaTjbFpS6EAO0HqIU38aJmrvVCiAH0CJ6iTAco0TwLdAgpVoMABl FYBzn3sAHTqAhBeJ3A5BTcWapFgzI3mZUDoHJF60/gUS7D12uQ5uUUfA6CqkQnMEiEEtU62OBMJy ZBA1SStHASbsN6lKQG5UZaYAUR/fZgJCc129IkUZyNnJPBg5eZx2v5p0qmO0BkFo4MJw5lMCV8QP moGD3wK/bSCkt4OOERSNSe9+9iJ55RjcojOPaW9BH+HhahIJHV57btTZu1baUB055ih6jStx4Rpe yRjMb/8ncMmrIDhJiG90RqizP/ykP3j1EJxQlZG4h7BXc1/3M5n+ngBAHa5NX3qpR5D5OvkOsaUN Th0a55OGOG/T8AqBAvdfbb37AO+gPSax01gv5qypnVLQX8j8PpRAdt16SoePLrjVqh0XQabaqV7c Z3yIAU1QVTkcXz1BwtUSxzTIi3sQugIUrkW8cMoRD914DNtuJ3t9wSnqIZzIc63GMzc6kXPygZCk mA7Jrm8CuDhpNPcdu4XtGvblziV8xkQt5gkhcMJbUC0m0bU+2eQHcxNCu8v3iSRUS6F83RE6EsK0 akZD5K7ADXXdEV3s5kI390zJIdyucsjhwKCKyI4Otvt+AhW1X+87HIRF3sU6UhnWWnMKSi/s8udO Bgcdxx2RuEtBf0BdyI8rMpwnefsYUmx8EFPpdJ/Ottc7ZVxIRQS6oL658IpMj42Vp0QhGdurcy1G fqdrfV+tXjrPtpczv8Ply1hV1XJtp3V/4+IkctkkmaOWTuIw13T+PUprLMBM5/DYr7tbR+1KaCoL l+da/Qy2adUNdSAairr9lS7hhZvTqPge4nBVDHokXb6MRpb50u7TqF5iLoHxCw1eTQ+G7/V2KD11 D0U7cEkNzm49NzOewcRwYkIFKZo+Ok26iVN0Lehjac0aRRLdib0/1ZlytyPfs3pk8WeFA3uIt45h 5xTDFqxnPXrUb47lzNZ62sCN81BP974rpaiK7ZgUaV0fp+zbUVInQ3ElX058ctZdq37zlTp0W79R AjX2Z4iF0hsRZm8MY6xWsyevdpm3UdJAVSGGpKLsIY/+8+K08iRZWTXMkURvo4N1npgQipdNw9Dz 1mP7G/4nIzmABLFVZz/wq5/p9ZiQP1q5qL7EcLM/uFOddSaD9z7CcRZVFaR4XyaIywYLdinxeSRU 19lzGBIQNveldV/NFM1aZ7Oe/XrWSa+dr/N5DzfT1aNvTKYWp3C5PRuGV6+hNeI+IdvhH6jqH3yS 0Rh3Je2OhzP0OmU8nVPnnlgsx19e1b/pqn8l75f3YIonkAXfdqdAscD1Tl8g/KKWYRSbWuSYxIsj MeYupT5FVYf2qJ8ZvZZNJ+TEykgvJuq3oq5fvEzgx5sf36iADpwocZaepMku7+Ku0oXsUN5khn7k qs4LuCsdOhXuk4MTh/Mz/rZ2uloa7k0BriNBIkxAIw1NWEsIRNk8/KNP8lLjjP1gZ/XQIxYwPxvj sKcGIwSlnvi2kCvz13qv3/+MT08tzN0HEkvrpxEhsfxVhz2XkgkNt3PTt9XZG/BZvEx5wVg0ce6J vRIL6ienabbkNT+tzi1p9VGf3lgzSjq4vVmveeHgmbBYBztaB05C3uzZd+nkJkgjAr0m1Hx+CLh9 DLr0VAhh73f3UUKuj7uk205MwB0YK0Zj3ZS4to5EhTujN+/dzd1p3duZPpvJPtNjfiauJ5/jQ9ey a/h2+ktYXxcwAXvt/TF+hVSX+j+dR67D1QeEpUdTsSc6XYXOE4LJPSrpFL9FVKSooPwQNrK7IBSW d23ROFvl4Yi/IlV7xAq3lrvB9CkPd3E8uBDgne5oFMNGYPN0JVMQw7OIY5dGHwXabjS2kHGTNZdz h2uK5dKdmievaA0m+Kk4VsYq0IpFM1Ng4824TpoiL45qU+IXjV9V4MboIB5eqQjb5ZnCninylYp6 Kj8cTd4gse0zmMJL9JKOK+jPhGT8B4gzFtUFIOR2bO+iiRnNlIX4ENE9wMNZhPsLRcAho9MZnNwc fjea+nZvMkSGzL3MMkgWRpII8kUo8QkXPmTH18yo7jkFKdiPmywwTq0KB1scwxd1nPYEGqYzCyca FO6aQglhwedXUfSngwDSWdChe4KoLAm4tK7p16uA3HepobHQY5qxThhh7Xq1fa43ITjPpl2Ek9Bp iVlUx3qu5cS1Kx2vhoeaPEf90smAj3Dncoxtov5wffGiG3yQYVrAfjpB5cCRiiPzNNzSwkFEe8dc cvP5u0zulAeQrkOooQNk7s4EU7ApIIv3eQI1W7Erv0bzkcAjOdHqPGMZzFX8rnS4IxDxI4Ldp0Cr GlQn1GSMJRbQVLtWy/NnCqgWca1Ndevp6sduPfP5bVdCPYZLkyQAklRcq2slZXAkr+PMT7CL7v8F YhjAvC1aBgdTrfsXRUcogDssVYMgcNwyDB186kEXO19N4ZMedwxDFBmrnSSpTjJTI3PMD1TzNbj+ GWoyAHvT9TxkmdLqrRYI4or+SNXdorTqoBTpprPpRYqqkR5eJCa5MVSQEAXRvTwerqNa82O0YKo7 NUQ8Purdq77f+IgPge3sEVmQugdfaj0TBvUFTj8SgF3SMT7NMag+/T8qaqstTfQB9l3k4PUOK876 qsKBiS0gyqQq/vs6Ut9I1PGqeFci2VGHTjf77AAEtUzGx9/JN7sf1UEKk8v0dh/aAi3DZ7tSQTje fTtuq21DTXG7KsQkNOA2q+Xlay0dzuZpEELiup2Mc48Taog6WahJ9V0hdmHs3TdmJnR2DDwqTt+q T9TqHlJZd5pJBDGlolp9QfbWnODIJ4NSBHjhinqd7YS3TTz77v/7WfMeIv04F2ZvZ3s4uul8Bg4n YaxvFhfgo0+i9/Sz6pQYZDVizpWknNDtTsOcgAbGp7uhzoGemxjLlI37pe9hMDIIqgOT0jB5oXWx RackbjSQ1izSE/tZd5MBFwhO3is96x7R9dNSHK5ukYb/ua8jcUnHHgQEPdkR7VSYTDEjDJJFRT5f 9+7/FZZQe0BfR75U7+n2ecWieMVg1ZW60l2zDXjztX90GLRMaO/Cl4/zpir6IqlKD8KZz33Aaxu2 z7K4N5lcB+fI5j+w5pag0Yt7iVjvg9H7DObeBiOZyODT+EmQ7qCaool55rLoZX7PVhdqpqelh97V 22282bGHyf3btZ0Rf6cHYJ4z7vZ+5mree90pO+usC3ngAff3fbWfpVeKs0IU+RnYX5isrz4pzZqY j9jDN4kNa70/x54jTn8aQhjZnsvV2jDmU4B/MauU7qNblA8SHl/u2MQfT7054UrGGllRX9EZlfkN Oymk6hq52DKiaZpUwDFkMjQbpuy64kpJrXoliu96Q2hDYMBXyZWTT+mOA1/pVteguqnn9cWL7vN5 foduMJWpqnsI9cUiHuZIcLbEGImnEPCXAJTSvUi8RU7frk5yMIdDp5/hzHDVf/aX/38mXtxpaJkm qMV9KJLuV8q7agm7618s1/+wqv628H6hnpwEask7lG/si+xw6sCbRm38w5EJMB0t5H3yNzru6Zuh IDyBeAOHuLVOrPVKz833rSfet1KV4DkXDsdNLptw1NuoR8eZR9jZxmHZOInSpbaB6tRB3Uj6nZjH OhAdXEW73CIVKHGuhcGoORRrCix9JNXsWo8GRU3cVrEmST96b8XA9G3TK8BT9DTG6ckdflUmmnza la0TGrnA7m/MO8fI60wJdhhjViR31Jl84/BZF9RFNEy6z7PsaC6tF5v6nueGdKeFnzoLnwMZjF9M vEl6IUc03KA1aFjD9dpr32w+zievVGdFTImMbHyrnyPdaIjZ9wfjppdpl47u/GMqnGlR3vWIiR/N PsXh3A5GzTg0yOnPV9cRBo7u/bjAEGZ+wp2qOZ/7fs7rmWri3hfGSOYS40w08dqZtOzaXOs1jFlY ++/7h/eZsa//o4sTfu9gqKKZ50uAbizU2PEjxTEZIb9fMTY4dkQZvFwEBOckTTOOibMr6NQfB8YN NmrEm00S+nbXu95HCgTHZJArSq7ufqC6ANxJHlyEwcf9DSIo1vMTtFljlxwCg+66SqJmWo/zEwgu rpfA7SLKDUKOkKthzIqXaIhc9dNNZToebUfTHeUxY7nIAWc7atdZ9KjIMav9fCXQXutAvt0UvWd9 ajo87Bj7Ng3rnNSZQ4/fXCwV8fK5v5KmJKmPw7V+ghApEtNTtKJBvJBLwCZFNYk9F0AKF/ChQ2B0 uedzuLoW0SokKNsZtJrtS0aSMV98mb0uymxg+jADxa13ADtFUDmec01tcqtfQAYXgJIft3ChKxQ1 3qoNcrNzwg1tFAKPCc74QeCuXSOhm0qWaBzTtM8RA8DSQcU+WPR2AjKCwI6tpicMsJ+Zi0EpH1Ff /LsoUp3f4zUilEJbQ+Dajgbbgzmfhk8HSJekxDzLNlmXTu4p3s5hgHTREYgCEqC6ok25tb6Ibj3q MHJZ1RNEuqaZ9blT1/DrBEAo7rWOOjChhu8thE/aJIWUqhSCFgx2TeeNWkTNFqLuerMP1r4HgV5N 0bqvEeB1iBQM53x6WjoEtgxcXARqEhz+kr60gcQ6bmaDMKRL6S+B/iSnQh4DYFo6IpHDTDgcBcC/ SJUQ2M1G3AQKwx3y827cK4Gs7+/TlOXmvf7Pe9l1u/Tk/b+l2ZkKZnS46nXV6Y6v24e8D1c4wAND YDkA2cp6sLuR7u6eQEnHs6shjOzN7I7f3BhAH7wiGpC836ag3uCiQOClkdRSkLt7J8+ox+l+VQd0 u/fiOhW1QWYVhyIbnCPqqMGIIHLNQbYr1JNTv/bf4hS2S/j/TulTcc5YkoP+Aqup6pHQsdec0mNo 7fFN0/iM0a0QMvhYby8sS0DIF5weWp4fBqFx0ljaAfAquBs0hK4p7GNMRUqsQWtvFpxKPK7bhoE0 Adifs0nTqdx773v3hIqkytsxKA0fxt6ApBQfNwkCuEryqp9fdPMYTxClhYNdW6DVBdLjbAYjCJKZ BRFs2EviAXl9EW8wJeMqxJdvJLvjoJlHcIkWHg5aRa7lWtjrRS45o8uVwy7D6QYGbchxq870Puix awtSZhKLz7yxWoMRiSgJa0lKcfmFpW88ICu1MagdNXIdA/x7MGtW5IjTDOw+pi8Pk5l7xeZ54Var A/mn7ZwNPI0Tl6KUzb7vCFePwcON9ywB6FivmjgCDSfvJGFBb5TJa10sJOiZNgOlOMcKbw09PA0p 64FwAOEI0e4zMsXWIF7wA7clcvfzzs/ayS1dyenum2lb8xScA5rbnbEWh5D9fFLXtL6qdgLXvOdU KZtN8waf+AR1dRW81ckjmARZQtK8Bt33ZUCgKkxp4oQFbMELd0h/SXKg3uNogmwVwtl14MUNaZfA bOoSMPCuIvfEAvzAS2BRgHu8KkVKDyCOeRpyGd6lQ/bDQvFdazmw1/rCTBqgrsvLr4scFcNmrhSK fgaUjPitAzMLYYhJij0HyV+5RVUsvKLnxHLyQkyU3PJ9Zvul4QfK1kTPnzQB6wwQDWNsCY2AUxVy UT7NvahXpZ3Bbvi/k7Cwh/ICddLuaraLLw0EuFgwp+O2T+nZluP5ZHBgMCqqFdVrGKUPh3Yxmo6x JTRKG+hbsu87adkxkD5Fbleqz+hGTcKhIwlPjL9Mgb/WmlPKmjS/z+nOP3699rHz9//8/584SL+z FXqgyxjPa9Ams0H+/Hf/a6n+8zqxTAPHm0ZLlKk1HHjxzjJ0uYJ/On+bIuG9DqzLcE6xa3IdJ4sB lSMO7xrELxx3J1vFe0BGz1tCTz6e/k4aGqQ4cor/lh7I/sJb5UA7ixUnTuph0AOMnXTiIAb8yuAu /BbHOozF5p+5/IWhchFjVXXy0XeScvaB/BT8uMGTMzBqUoiRjWSbc2C2gK+HAY3G1XMS1jaWJSOj TJ3XeueXMoM4X05MyqGp7VxOp4BUiwtMPNqIEqsom5oTDEGzKAU/96rdv43P5im5zkhNTIPtTai3 3BqhpXAQWNjpGOrANZKGn0Iu6EZiP9g/8+Aa5ieGk5Sk3Pep1RMx932pwa2uumYkTM2BAR36RU5v IHSMEzRomPbiZSmhhUfBXD3Z5h4XrKtpnOteNMxJSoj5TIX366XJ8nHHGfqRazjFD63B1D7/0UnX quUy3EQGu/D1SSHMiFQdFyrLxTeQ4YNqq0P4o6L4qsLp3AW7qFCowA0YRXAv8smXQ9uMIVGA6D6f MoPwNURFXu9LMAW2p+pSxmm4KBTtWDY/JPq9C2OpwEmnHh7PBe77LwJsi7fnhtjxcFz07FiZHeuy f7fqLZe7BDZro/ZIG6i8xnm90gAMwFIVrW9zuyOSgui4JCdQIjisCtqSAqJLSB5u5+JazfjlqDkv blO8rtlZRmcxv0Xd6RPRger7YlO85+lG7LpOo96wDmdpv9ztqjJAVwGF01R+3o3sSoak/wJZtRyO qHHfwoR9sfWp2T2JlqeQjghlivGeTtH0PX+9L30Jp6mIBa0VPcTOVb+Wzud7kfO4TrpNUTDoKKoK 5PfbwS/JZCoCUwx6T+kJSrT8BBN4MkSU/oqnNgzYFfrDFAofxk0CwPMmYWfU83xGRIrrcJf7AdF8 NenGMHUFcCcWeKgeAoysMyYYnc7WOR2/XT8FIMd0HdAZu2kcMvwIsHxSGNQ0d+BniwXonPOKOtYS myjOTp7WHwMlK+7zkr/XIqY5OULgTG2QMZE8agsJ0sGLCcjpssBOfkyMzoGxLeEWjPhx0/e5R4W9 hgF8Ar9mJLb3T/A6Y+mcEoJaxrriIoQOb612d1OU9l5LVz1UAJfQ4HKN3uA6G7dY2TCwqvAV8lmX V3yfioaYAP/PwLBBuOwY0jWAKiTgcfkpOVCx0+rmWnVIqDeITjkD+Z308KiZgs8Z61zn+bL7Yy/B coqKCkUcATt3pycAhESCHW/hDCUgaEYrjnWRAzNcWwCFYNoTtUReLNq7hoWMz85FDt/jT/kNtt9u LBUkFTkw7y5wihv2QvYB1S4zAReIBIio5g5Dh9ykoGcmsm4GQs7UvCEeN+eNTGeqinpgj7noAS2+ 6lx9qXZVNcSLfGKTK4jqTgTK+yz3nw/Q3kBMGapz7uuNCIjWgJyj/2MrjCNeuaUu9D4U+8fVY1Ky l6L3hz5OmUTzibclF3FOJUI5HcQdC2Q4tCL2v+ticnaDzdQhqim0sCTu0QscY1+dBol+5vCj6nKL u6QLnkYWdQ1/XsN77BBjSMDRmV7De4kG8QKIV/67a9iWc8a4ohCirALHrasXzveqMZTJjm3kGblj xTlifr1Z511mU39qrKM21qwgSxNvCeOV9U7QOQ2C3MbwbsOHMhW1xn2KfYOpVveqGbdBTS1yyCcv c+UqopgfBFeRW6HP898i5En4+Ti/tBySt4B+764mTHViPkJLh4KfKRz25NNru/gWOoaR6zAmz9kH /i4YyeA6va8h8oo98Xt9xCQzpYzd6KZbmtbgOtSk7vHohrToG+/65WSa/Ngm0R09CQ3aCDnBeWYI cgJIvNLNhnS6I+90B0c8fD3jzHm4YONgW2CoM8VChyA7/+044935semI6cACmQLve0OqutMlKR49 JaiGk6CCixScORtF2cJGr0G7dRLaj3cF+JKpKhab46igJmi4HWCR+5mWSIL4ys71D3acOY+fvbJD SzfHvo0opkhT3BeaB4c5T2MaxShSwrxYmIUqRpJ3DvT0oVPHaaljbRekXukwNukpA+zKy0IeRy/q Q1SZadNCXjO5SDaM2c9yGk1w4tGdh8LGS7kHmrmI56BrmhvSwCY8cxjG3X8Cqoqzp2ehHTlCF9zt qjqGPHJ4U0ee5Uy6J+wpTz3GdAbmfCThbdZjGAZ6p53CwKw3N6H4bloOwYx7F/bLVfpHVfX/DgFd 1HwGvDwxr2uA/jIwc/m/qNJ/v0r/9DSRrENL8uF4O+4pwJIUhm5ZN6fxX+W+8exnC/h6FlsadBLM T/pLt3rbE6nhwYbalzhdHay7foNn21VE1SuF53bibYNhLriB3EKdHOnuP+JKV9wm+f4rcB4/e/W5 0yZ36uDnzuGdZWZgNNow23vCMBpV2A5ckP5e7ymO5NlDh+DAEbRM3VZ/Ba7QFUZ1Kq4Sa+AXDm7Q eP9XsZ6w10mpk/QaXqw4b8mgjgZdc5SL8bqqnd4juDs219j7n3rwgTpPiO2S7pVk+j0x9oO19pqX dTo3Y1tHlSZIu7lNanygmZXaKkgJsgv4TB24IOessppk1/OK9K7dh7xMlXL/TwOVzl/TmF8OON8Y s7CP7Hz1ZU64z2tBVlMdSY05pu+zr644qShxIk92nzjYt7tPOOr7Jx/jZYKpXTPsT6LzvtwJBdSh 37fa1HVkzX+lsTJe5uiOFFXDH+wu89lQVyyODtKwT5axPx4QuYOM9EHgG4jgg3QwkaSFzRsfR0Zw NF0yDP9uurwoYiF3jEi/aOssaAwEj0H0lEXyHavegSyjMOIVrTILPdp8M76WBAE81CCc8Nifbofi ACFsIhe1LmCixcmLxUiW1DH4cMV8TJCpUNzziwxk158r+nBH/TlAWwM97QN2rLNV8IQ87bt5dBIo s2+9iS8djWJBgsPbgYXeaXenz3PFj8voE41ZKLMhuoEbrhm/QD4ywpU5L+JJ6u01q2Kocjun0QTo mrdUi6QJ53kQStoPEU4rMAznnbNYTkpDCLDkEEUdT/TP+800GWacX5xL1lDY+Ytn5MsJ/gMQ7Qk5 Q/nPIgraB0ICYU5rQwpDRDDvH73d13bjtsGf2bAQcDmHARzN7iQoHQ0Cn+VC2vKGs/aE7BJVaMZu pyfBdpndEoD2vZW0squLBxnc7femDvDO4RLrJ3gj+NmzUb5WscE9JVNj9soYEL/qALVnHUkjf1dj p61EuOQkmt/fJ82dTvlaxbaam6kXOeDh6MBN0CY29579eZOuEf+po9ntX92Hu0sf3ECiwletsX6W Zg2avkSKsHYEQc2ifV1JDPmNTpHYXqedrKPb2XhvcTqAsQ7I/YPjZNIhL7lF8tPh6l67terOQvEJ 1eiGlZUDIm9BsGq6mNAQrw5Qpz1l6Yg9W+eLL3fzvH8U4sgdU10A5utwf6FqjZLA2hM1rzwhtKZx F7HzhEK8SeIChXBN6LinGNbjkfVhJusXIMQ3iA4XmpSv+Kiw8p5LV0SvQaL71t8uqbtW2S6Yl8j6 GnjoRJPX+coJAo69UOj/LFilnAiSxgVbpJPi7+1oGP27i90Bq35DhLrrlgtoXb1NF2f7QwLkIJUB u5nPWr8Vi7zJgnSgMwhOGBcxihi2EDkjkDn1i31RyLGq6h5wuM5NHR6MNEz/qZuvJD9ySzZSwxrv drsOK0icKhaqJZkmMUj8SSQCv/5f30kpK6jVgwtFyWIhHJ56jghxJIMQn9zn0e5FuMYgtzlF35my sULhI4h7Q3DACQXXSX+TrxehtFayLmK8zhRKqo6uwWpBruldE97YgDCprYIE9TPBaCcnblzoSlsp MFupOFd2j/PyP/UjG7RGn72o+sON1nFua9z5iSXOWs+Vqa8nCRlpRIr9Pu64Vgyl4O9Tr8z+XavW NeL0fdDmh7jat40nWWnolzf6nOIckk+kAGNjBjvNid4bI1U5fDSj65Mg/BFj4h3I4oku8PmcdRSg bVxHgT9VHYMviVNrKiIQs+8uZ4bvEWkcy5yJ3ll5rg0DDRqnibdxU7r2ufUcf1nnnzWgyjD3yQUk Sf75ffXz85ILmG9KaMjRn/EmYg33wZVUqfiz001PYTTyoZogMafXr95DnVcFafisfOYJbQu83Hav vn3eGz8EuHRgyUmDu67BwT4E88pXEf5MB+p/Cd0IK6IEHp1Yl0eK4a5jk4euyiTDj3mX4B1fznef 55SJD5rYN95thFNsIQulRW5THeNWYLOWejNVykHomWrN7D2lBlaR2FJ1uZJXFQy23Ot4Y11dJO/T vZKcx7dQ7RJek1Mm9YuUu+bDG7dGmnydlegt1Rq9qyfHUXVlYNANKuQsXX1ALYWtO4Vsj7Q4cK40 6eP+3CGwmTw06UoKuK+O/QvS/15peA5twst4at94Qxsj/v3blI+GH5kvpvVslHZWpWi8G4Z54DCv jBwfd8hOD2xDV5Pj/mtX/eMKs6/1m0T34E7L9Cma2/3sn3//r1T1f6ryPz+5c0WPmcK2himqAK+9 +s6+h2oM4rNLfR3A7OzZvAb+yLmedDw5xJXJC8bvXkeK7zrvBw9gHEvXef77C0ZPd4i/YAtqtYFX feT5booGRmfC2BiWRPmK0EyDDW52H9VrVlL9FCZk9f7Gy5Bi9os+uedPb8RGmJuz9KndEWKJBXxi ojArx2WbeEhxtpLewV/0FZ0bmPj4HqlI6auBV2Ht5De5bzuT24Dq5lEz4fZhKGFKWu9cD1VwiQ2E +YByzXFCF3HU9UzZTTO35OQLc7MnN0KD66kvOLhr+HP9TPCo8VXb5K5qFyZeKdhXKuCFBe4a4mPQ aEhev/RLu2I0DJD2gTLUi6oe2pzCAcfNWfHZfSVtXWd5noTT5LDVeTTAd+bw1Hked5PkODldcJ63 flWk1qmDx2Fj4Z/1o5pJlEMLfVnqFnYpOvQDkTBjI3/QTVOnznzXCjXuIjJJFp6Us3L4w4vM1gJD aDFuodwu7QxR8z6mtbXIpz3VQQ/w5UT44wK46VHXIsLp4aRHYcY+cFOTXpp6EI0gXhUGqgawf0Wk pFDh2noVYECKx1Mc4fUs56RWxmVtAXQvQfzcnJumreJYgxqFyhaw/QJg97RvziBSzC65hL/k33V+ h3TMqrMYKnCMd4jwCLQl9+m2YsyCMRK4+mhEKVJaUafvaf37IN4FsWqL7jLWxyj0v+bpG6nTh07s 5RB6udRPV30jzHrFXPnwO7tdT31AU5OUWoIHaYktG0jrTV6/BZaFjmReIgOesM+BimwCe6TXeO+L zPwME2AGxHLV9umbwISFD0CUotj5DoxCRtsZ74q+3fG/DNjO767AK1jO/wJVr6aBh8TI+cTDKXvf ffPsETSL3fUrYnMgwllnqe3h5N+Lf8NkpA7CXW2fsNvJB4hksSsJAvBWB1LujnKbsaZ5NnC87u18 ECCRHXFjOm4jjGAO0cHtPzz3/yYHN8V6w8xM6uTAVZ5FFPybg1c8fjmdRhR7c5FLvhyFndIPbTKr qsARfcaeJsmUwo4jNm4RITHwJRJ5pODAMfC3Xc0LgN2EaLZbVuyTE1T1cwgs3ROnsCwJCcNZK7w5 +EzNe/p26iOX+Hx3OiiuQRau2ms31PN8VSRNUZN6h0TCiWfXJYs5HZF0RYry9Pk81/s+cjyLKYya UJ4rB052P0b3tWDPVICE1zCCsotRdrHbbdTn7bGdtY073FGLzM9qdA7Y78cLgOT0C5IWJPmdzmOb 2NjdTya3XE5CBNVe7nEX8cSkwibx7sHv6Wrwl35zOwECOOrlZiPdQpwi8H3fHQnUXoBsDCtsd3jd nkEOQm0PYVTERBqp8LeDnR7oBrl2f3r9ClC5Dv+WgqSRQsc2qvRqEbE0bnXhSwWEuwHneMU6EyF7 ZZo5vDbqEPdd4uXLKdR1DSv5a59Lg6HT5WzFiqvfheRygtUFDATssYGDNtKut99Ov7u62U52W+wj IGvSOEDRe6V7fN6tXkMBOhGp/bymW6/RqRSqAgMuucS6oVE4MCyfQwKw7s09y/xZRrKa/s73bL8k OLvL0hJCVAjUw2WUias7PemDwfg4awhDEjqH0T2b1KrDZUeA3UPtiSdjHaTo7S5/dt5eq8Y+e7ha 7omOBLF2f58e3oW1enwbb3jDkS6bCbaQ1hTre+71XyLvX/t1oDxKTMY4rLh7Lj+/daEsggxCthFH esNPdzWv8+fC33bCF9N+9UWc0I2I9KD/XezGf+/fyxUuk8mE510tXmq7MBrq6o2Dg+mNViy8qarx dIHUrgXnd+7Y2FzegqS1QiHIPlGlheHBUJIA+++OwHlWpNnLi/K+evaB7SrFA46q3FEHjcpK83zt 6dfJGwpP0L0v95CqoPd29Ho51FbQje3hi37GqekY9mCWNslekPxziBFStp8u58xrzvTXdBbmXj1E Ad64k8eQw3bFu+4Jg8iIcYOaScqeQxtCrIV4wm1iVKt+XIlr0sI4qvawEAv9deJgQ1wl4hTf4oT9 URy44JVGvGvnvSeh6xeIE5X1OeH0F//bDZT0wNivDIZCHEhnRZW1xnVXqfYQuxF/VBs2Yuf3RE6u HqlmzS5yADdjo2uYr2M0O53aWIdW4dB+Xx86WKaWGJOeFDlw4CpMkyjspadrqtGVdGMzwiRAHetD YXLW6/c6V6ROkfJeQyxuDRE8ZLhG34H14FIAzPf0j6v0N4lfF/A6U3ehEhozUTYF4WJ//tt/1VV/ r5p+yoBk0nCDRxLFXXO4CpKVWxrP1RDVTJ4y1oXzM/SB3ReD9DoDiPdIMZy/eOsajOxmkl/aLgiZ IR+6jH0G8J1RC79pP0u7Bl8mNmJU+y89G8sDP0O7QsFfgZkcJZ1/9mM9bGMcKWhZVxkHoYeA3r2n vs0JCnrxbdbnq4cy9VF+YKu7J70T1UavIqER5u1nrLjbjR3fTiavShURpQXmGbITHAzGIZ8B1byv fL4PnZywXmkMR9ro4PhFZkUfrrRzVj47MwOv5MDrJ4bRsA/7OQRRA3ed/DiZkrwMHFSQ7DuS41Yy Criw/7oL/eC4pqZ15aOCRmiksthxDr1NfJL/Q40VmrwITp9a+FBLgUJO4arxqS7VSpCMsW8w7Jo1 j7FmeSE8u+oz3keUL/YZWLsMVQy6BEfCUMH4hgEHF/Cs/Y416HSSu6mHuZ+WAslrULzgrVx9j5dG N/lBVx2cgePt/UFO1OxEUuAg4Dh0UnTr5e1YVXBJDzePoOEMFIXh+NEQTPRlwILG2SRxqceNXMbK ibwJwWOLHau3A+ac7p8AY05N363zEOvaEDtZX2i/DAabgLR5kkUqdmxyRMBtB4RedOoBN6dzfGvS dNFXIORRHZ9tTXBCfHaFvzyvgiSPHaLBT7zEP1k0Dze9bVVJC/6bpJVjspkSEOgAZqr9JgnB1Tem B3UILdpPcML9Pq7gKPQ0QT8f1ESFCIWKhwQbCyUduocBoEFNANuP57pivTSdHz9N8RXy91l76SQn cFjYaykvMKGLgiPuyIMk2y6yykTn5YbVHbq0hBRXYsdFjHO5Kjw/djPlegGCkEyhKwFC7Tt5ic0+ 9SSBKlMYs0WMRlLTsGbz1imMN+V41nweDLYXxF7tSLgkwrpgjgkpnnQ3DPX0fTHcc6pm04jhrHUA 9i+od4sbfZw6JPlSEB6KKKC8bWqdP7/AljocNT0ELY6YSQpeijE5G4GeOui6W+ZQVSQqpxbR171D MnofAIigyPb5XQsd8AvXcRWFUReCSHsNcyjTftcprt31o9ZZPshDP8i3WUmMBI53TCpTImE6fUWg AeAo/IkaYAInBukcVtRDPlDHHZFDoQzaMPXj52ovaG3zvV1OyQ34bbHY71jMLUq5SMwa5+bPWeZ6 QTEHOaoDyJjrcg77ekR/5irc68SDhBNGpxs6vVqOU/Q9uzPCPJvGwIVpcIuBf52e0iugW1qOKBeZ KxQvvfu2lnKgNcriub6HRMI+yDby+Ujnoj2UkefqW/SIMnFV1FP1lEm8HGizjn3VNkT4xWtZCRfU qW5hpKP+Skkz3dC/6sg8G9kjZdTay4WpDiAyBPc2VtcOcdBOF0vqZPcesc6jrmT/8Ryo4xpqO8jV ks84euUdfe7lnJmOUNvhA128oRIvrGOM93V2IjpIT6HABQnj+DtEVbUavhENn/++6jo3DE1cAXeX lSnIZsffLhjaOI2ixqrhtPMR8SniNC85rnAnd2EGAeSqGVefruyiys8Ts/LRr2aHAy6iIBR2TeFB xxM2GfLj5os1zxJZaAqQbKgPa4of+ETOQXqW5+uo9b1uwUAkD3JzYhyf93oIGheBP+8zVz1SbW4R 2+XDqQfSsQ1s1hkhto2gZMstFPfR3W2y13GKFpLHm4BKIZVDiDYHK1zh5O6P065GH9yekOZw35WR ZCB1+p0vJSYx/rZ3j28kzmZyXK6ZNCgSEmP2HqbxUV8mXuqiAYhMqhKuSw0BwahvQQziI9Mnk9BI 8FzYw+dQ1PV/V8x1HTjiRYoSVp8OqeNEss++2WacVYjD1dnbToEd3fNVObBYOGxRVc3xsdBVthPw BVIA5gAV7B0lgXE1Z8ic20LCY6DJNMQ10zrnsHwa9uiqSwETqvXMPISb2ZFQZrGPhIjOo/XP7hBl biOACyMz2qdsTGXyKV7uy7lm+5hpH+rxGY3O/JYP0dPuAwU+f5SmM+psECDse4YHfDSGmy7up+No VzLA3hd70JEzAEgotQdzBXfNy/BChJLMQWlP7HmnuO6eg5IdloXWD46V7tVePQ6ww974hG6Bktaz 813b5P7gtEsWnYMEzm7vk7PceX8WDOeR+zzd/Q7+7OIrZroViYxWupYTL9n8Rxf6TKOSuZI/hi4F Ihid69QHFrUTmxV41NpxSr7UC8foyleBxZAxZ4/StGoJehTYwuajhY6ZLnYfbXep3wKj8T4f2DXV iNz78ff+eb6ivgcS0z4/+D+q8v8N0OmWdGTgA3VqKmgN1jBs+Hkef+Xy/1yl/0Jhnq4PbEattqJn CyMfSi7nVcPW0SNtgXlgH6uv9dG/HMzBgWvsM89nv5rnrlcFRIOS7ec+koqosnM8B2KCZzrBNGlQ 6BO+OWX7iTjT7Xph0ffoluH0E+ls0FCN7riPhoQGbwYnH/g+pTJsrVfyWG7cyhRJrrMnEhouDSGw 7Tsh7RSaUtW57jffO4KM37ZgdwvHfdRxXQhMCsVdh7xF6oXC/lmX8oCcgCu9E/v2fdxqUC0ccfQF 1/mc2MDoQ933aT10JomOzeQaMj0qTAEydpmFTP3sIb3SlATnHKXTeX23xZ8qsYHBg4q0PMJBve3c 3vm/zYHTyF90qglAAr8wq9PRmzs1C2ncm/cd4w1pXbJHIerEf2a9UUsnoyceM4f/+fcxhusqEPCz WkgHCrJ7s4p0Ca8hEc6CuuqOoQEy/b6Kfow1EsuuRVxdsrYieYg/aAH+AobPLW5jaZw+WjyhSuXH dBqgNm+XMHPKaUw7+Jtnk046KECwQVruok8H7DIbRK1DnmOlPRxbt/O3QShH7g/h26ftJHE38Xq6 3tFbY5jhLoIP0ZiSUFEUabNH00M0JDyMViyWXxtmXpTh0jpEkA5isIPU6PEGCYGf6E/a1Ft0UA/X nev586E6ANAYXe8N/xU7mkMffsRIqwtnjgPsckLtojYErB+CcEHSQqEDfgJ7hsJNh/DukH9i42Us XqaDTXfw4vjGTe5nfCKHrnC6A5EnrpxGS/fuy/suAfMs0Hm6vdTP0qqcHtuRMJu8NjSgAvLr2v9e 8hYd5U+eJV6gnOsKeeIieBPpvTeLtec6nOR9gDqreDGB/+xuv3f7PWEtIPLJqQieoWgGcTk1g/hg f+d6DKL4+A5Vl+8TRU6yi1adp1+t7+9HtOO6/X1F9lZdcVC9rtCxk/c90MG4PdFcQa4XEm4n+FY0 8pSSMxbMsGOthwjHWJvUIQTYAk0K+Mv7dk3Rh3Bziit2osyudH7AIpGzBQyQtsHF8hSeDSI0BN6b zW0AvQqAFw53njGABdHcE4TykaDhUxxWyyFe78rSVHcIGqq8O33AV+wmnqux78kd/Jnv0Czg2NWD jXt/D4PqJAQMyUnkNFC1B9DuATYC5XYMZE8sSQAmnRL8OLcy1lnQ4Ot8l0JYmEnJy+F8uTFI0LNm Js4nlcwLSN4NOCUjwH2DxMnlUKBDOk2uy5RgNAeUx9puqSwZDUquOuSKcLisi1fap49yfcsoY9kO CVTegcqFCVpMZPgATon4j1h30/DFEjdqOljr2MtVOqLVk7AtBNazcqa9R+AguRdPcZ6WiExNWKki x4qRTAWdZmENQc5TilDl+gLZpYPoFRBNO1dRw66uNyK9Lwo5z3AD2E9Pw3FvCQZiE9ysQ5gBAoTo 5bMH/jkTjoSW6SDEDlt1EnnbiTbf4Qb+DYO64xTT5YZpEHRcyIZWP8Y4jF1QCfp4t5DOpRxbSlfg F4q3ht4pXe8caIEeU1PI69eg9SBd9pv1gnTgubuw9/JRR1CWhAGbFj7x5da+6ppPQtLrXr1jXnkY kkQCfN9sIxUFMTlxDxKUvLInEPHyXC/k7k3n7Ew8UjieveUCgnSlWR8JiZLZc3Qn5T2u3o02fKRR FNKa21WQBuPbn1fBGmHzgDfeut279lniRYaSCcULcyAfbAXW298B9S7s4qdDvL37HiPm0QdXKWfM XYSsaZywRcav2hhRTWdNdKNr2U+G45h2vkwmdhJyf0kMOIWPUfh64JBVaTzjONMUSR0T99CxL+tw GNx18o0F7b3L7tzLOASw2Gl8s/p4aZhe7Ht4ikJWMsvDBTfHZChZkHjGe8Ap3IlFYo3HgK4Lup78 fTON1IgLju+lOvrOtpc0vzGNJdJdelmLCXfeJvFf+8JL7MYGbYo+QTj0rQI7LOXNttkjn8Hx2y1T xw0xsTChkUQVud7adHpMUfYnRctr4GO6BPd+mOqji8H8vAOfcgsy96rDzXniQS/O9/KKpUT7X0mp Xpij62345R/Ot7AnLuRyvO6HeiTgfoaqr3E2RQ/opkNwFfCzxLlonTvZX9aRrdZrUwM+WVUPE4eC +lKQnlu13ez3EFHYDGn3y7naxkCLbnOQuAucp+Fw4w3ecdelU9jGd8J22FWkgPlgLS9nZ2LIdGL5 r6pDyBlfbvzALf7DqvqHJ08pWudqXEEFV8GJCOlCrqq/W1X/zSr/1V0x38qUHNjcxi7QRXUe2BvR UlE6ibZgZtUp1+A0pXjdntsVvaqh9v98Zo27YLvcshN5dpk7Ma8P1PqwtciBu4J1u9aSNgZdgc/y CteRVkHaiUwbvtlcTmT8+VsucDPWSPq6BrY3Xh6byZMXoXePKVXb4Vs5/EvDQFKhv/6+L8YZoKuK WPiO6J7f7uZC7K6fxZHiinzhlXJAtmfCoXGHOcvVEb4M3Opwal51mOqsxyb+dmt3FGthOzLfyTMp GdbSRM6zTZEoPLWQRkzmtpQycqp1aGEKBM5bb3gzD7vOVMMZ9SXVfA4JXr1QMiL11ZdbRQJ7hw5F yLUbcb+OZyhMmTK7d/enH7OVqRu8ciQSF/aB8OjIARrVqD/6q1DIat7L86677VcKUdxjaLbz9DBS x33ccUJ76mVSW1erpjXw1zpw3p5q0rQBK21h0gXJZab5Iww1RX3quk8u1x+dUE03kcNHW5csRChI KIjF84fNCAp3HqaXP9ckpwwHSKEjTCE4jYI3dWIWZyMwMrk3LIZI3jMiUCSUrFjgWovAzgs9AwX2 rJjCTcLXxOSDRGc4ignNcWT7co9sT9E14+9UD3HLOvRM68FLoEMxvi8RSk7Wpx/UxxGCm/wCtz8t 0i8dxyi+M5+zISqHyERH0VLgtk2NLxV9uv2LqjuHDPG/0qnX0RBeBVEDJtz3ah2ygQQPjKQBE/8C PIEi6nyIXmYDebWL28mwx+m0gRAneE7ifIpfDLBwCOjeJQE3trs8dHimJME8i5/5fY+ASXFR7kVA kV8Vnkpih8or3rSqTvehDaR0B51xOrhOeqCgyNzrvEcPTzDVCEbOdaKIHx33kbLYDMFIuCtcgnYf cY4vKDvjdInMziLUWNy+5CIJeZPARVg8ajn97M/mBMXqEsKz2CDFBYaahs8Q3W7U2vCIo26bgzG7 zqN9X1igbpCFxyDmc/eIBeYY3iuGMPZZvUgKQcH9JQa0J+Ksc07gKLMJjElUqFLaT6B91R4jdIDr nwZCx2jHFBTPOjNraACmiOjs3xPpay8nHIWgixNKNiBzpRQR2FY4ojlJA6GYkOsWg4txRsPtPijf xXY/JKGAoLdaYiwV/q5s6ncUuWAwagnVTxfua/DEMBg9e5Epct1LaA7vFe6h15hypiN5Rw5GZOyu 0Qxk0Eugcye1mAiVx6cX3lVtSAUjLlXvdIztrKAz6Sifr6IvSeFNIyVU4QAcg4ye3oOUTyV0EFM4 +EsVTgPf7lND2kwnWHKfEKEvGHtc55ezO9gDD3yGzmFprVN+OFOoVmwJOaU7RDZ+1Aej9zZRKxrR 3ZfoWACip+AsXQcrzneIaZTWs+FdtPdLrXPqRikyw0/hsu+iwNg680HqGaJ8hfWSg9YGgx13Wg5/ Xuk7VC/q9OziHsg4tj9JNKqF+1MeLsWbIllCnI3HfMQulDylQ7xxuQ1nJ2YUFdRZB3VzgNnLboBY iEdh2o8uYUxVpgHmXjJ6wCZ+k8A6DXHP92xX3UNiHwyyu4OnkUchAXIRrthDqFDceftU3WsjUxUp KWqKlKc4ZQ3pOvGQy6WTHNyuQY9IAfU+2wiDXg7gXpHO25XLNIiZ2MWdsiIQSdSz3yL/LsZMM4Wy sANzRVoMDOL+CAI651E6+A4a5r/98/nv9L72kvjxEFckVHSKThfZJHSUvSh3SlXVgY8S0TsFgpe3 mYqHW28RzXAQEw/e37dzBY6RY3e1BETVcIzDU1pa3WviYZmj5HDGvdiUrLkoHbOqDh/ePWQVjoEm fJ9EUsmtCTvllQykArzQOGDH0dWCTpRE7ImXCUwMtk98CsoIH1L06RXpu+mEPY23hENZt5GAT7yo TrkFnU15hyiwSkqVSc6RuavMLXml41Kf/LNOu4nPSkpiXuJdcSvqioIx+82P6J2wqVoEvMYZEcOl mJiq4DQLBe61DFsSH51/f+JSemCzH553i0wEJ3zeH1tklkOixMvqdI/d/VUmS1Kq8C0gCx7vHJIx 3tNGvjoTBchRUdIQd0yX7bYHlkisJ7XMfUCo+XV7KXmoXz9DfFoadRBadYWCIzPi6YcxxpESqiY4 njwcZq0vgYuhZ1uBrs0x9uIsqYvN35PcrQ8P5fy0W0olAAHXdzDjWmmK5HXn1UojTrRJYVjH3/tO cr8HBtIZO7mSPjyh6Deenu/hhvvnT/gPqvTvUdL8ZzgQ8ngFyIa4n2X8RH9VVf8zVf2dkHc6+WFR 8oj4DtN1T+4BMtGI5SUiVSTEOUwLKPnzMni7XIoBF6lMAu1aFyEvvZPcE09PTNDAATn4h48jdva6 FVxEDUHnZTy5+QUfhp7GPB4fGVICVohMLrSErh9x+MVn3FJjMhyZg8RZ11/dJZ2DeSpmIhiYYiE3 S2xMd9jPRG4eHH8lt95ro595/TzVYX154Y3kin4NNma9YzC93D9HuM+FvaPCPJfrjMJ0ueRhWoXk 2Rea+CLUnmwzuVR99HOFUo+uUYBp1Kwn5zswYbs2Q9b/XbUewAfat/WFqb1UlSqwq30OSz2RUcGx bJd/YUZ9+z4mFisHo8KAebgwGXb+xv2y93fVmQpdh8kwcYk3KyNMyDF4pGNPqU+tYFzlPZ0mMUQ2 4rk6cEaMceDQW03CtiM0XDGHuQg/89lj51sx1CH8+8cZoAKTZX80VqKehe5M6A3XQMYfQsELX+C3 69P3i8KPwm1GhmpFW97kXJ2HdgrhcFJyEUc+XuG9aZiYqboEjAbhYCHQrhBmeD6nAQInZEohZQFM L4ddvmYgrN7zkGRXoIxSNxbsPWauO5Vupw2eHHM0XdWmD8k1Z23PJRy+iBwBeJPgBxfCm2B0UdzY Rdqu4tYpKE0X488BNuMFN4gnBD83GDciMY9YtOFE4X6hTXcdnf4DS9CCelUFGbGbqBcNVfhv95iO MQh+FEMHgCR0N+zOrwbxRLasc2pNp9C3wlW3wN+I/k5rOFVfznbV7Wo7i9V9LtI54xBna4HoROzn fpxxrB2cqyUqv5raPUHmRU7occdxEyP1OtVrMpEnYGfb/oq+/QDQs1ihcy6ddIzf/3bvTVdiCrtL gsBwWlYUPu/9SSKG8QlcUch4xLnWs0grdDre+9yHM13u+hRKeRE1WeTzZ8mn9s1PwQguV1HCTheG bbFoaQOjLPrhc5bAiRwcyL3n0Uz8zvrYgjq6aztpQncRuYpU/IzdoBvj+cjnc7izux5OzfVb5/p+ rvutujKeWiEoJqEagy56DIvsAUof666OgY8c9vQSfRmAIwUI1gkNjvRixyZ9uVsMsEAFaLtro1x/ GiJSr0aeRNfXe6nD+/eSf9a4a1MA7iJHymtwlNwTYtA5Wr7jPlM9z+J7sE5Qw+5VkgHlU3xhEN3s BAUWcpAzlQ8gbYuXL+FmXStQO22iAPIWkpfCKGcG6fGT2+ffSlAnZYkzecyV4lvDMOIWXLa7F961 PW9pHVjAJOE8RBrkMVoPR3qjpLbOHkXYgwgq5C2H2MW4loAhRcZpGjB3hWEIbwiOtSo0f6KCeVir /27H8I6+9szbnWL2tingfNWIWkPsyzNJOh2oDOKzeHswjMtGBJtgSULl5bhCdg7ajjTuNS7VYq7f i5XO4Uwms/dgFtUvPiDN3e1uMQsMtqpG7bzr8pGo4QtAnvXEu7vQ2mOc5GSsftqZq4+7VLquedRi 482rYr36zIPag5dJTs3EPyYz0/nbRWI/Sq0gs4gC5x0G9Oe583EBLax9DdhsRd1Z5/AFRYq/sRCu NX6dHzxCnfXYJoGi2l5hdf46vMQDhb+SH1ncdqx2QV/Ze2gV9nsfB6Cb6N410iaQei+WYwjKXrTV 24yVv9GY1/3RMUNpCyppwI0z8VyUvAWYoffpqIEPfQZ5UvBhGEa5saIpBgt/cF8jxd3NnobOFLUL 1cRGsjhry5+fYGZJCgaFJ1Ro6I45dprEDkYR059DLG79uwtYjcldpTEL1V/z/tqOX4Yzh/vD5JnC bqGJiox4zJ3quyvG7sAcYo/+Ls0o4r4nhsPjwltdd3LgNg4xiOZDhB5pIXuVCRiDl9kLjF4L0sq2 K7Ey8UGAxtZZuRl6wRyoMJL8U2C4Ubq4qY4Eb4PIu9BQpiA1UYeTo5f7oh+9VZq/vNLbaqcOmtAC g6BcdTtiJs6hRZxoYH3XgEKK5kjSVWT9pN17X/h9onTJTzMmKxQQvPb1ljowT8DmTWmqkZzQIWJY w7f8Z/O8ubCTmQ48z89vWTO16qnN9YyEciX2Q46aOg2AKEfMB3a6XXU3/sM4s/H9Xs6kDoMGo2FH Df1C7wMqUh4bzm+fXEthPmPrmU0CVB/Y2pGT7RyKvXvmjeP45MpFFkjaA2xaPeWsHTyGNSfuaOQs D1H+r1Qqbwfst2N14f/LKVaqaq7btZLefN4gtYT87V38P6v816R7mXx0ocOssJc3ZstOnMB/165/ rUp/BEYvqnVJPbAHKvTQuCiqBp/JYAZcyHDGaw0B3vyTayftsXmO1nDoGEs+DXou/UsFbpepAQWi 1KorhTt8ncWs7hB2Cv7ZOmV/foMKef0K5Ne/ccOmadzE1QGL1XqaNiTYGwZb6GzQwRPo0K4VYLb1 EKL7xGYUydVkTEV5SNNctp55W1dCOieO+bgvslKHESNfzEHW7cpclbqHEmhAx8nLLnE7JxoqtAPd IG2bKtaBhwpFxAquaHMb1Plo4ZqEA3LKnb/oFty0gRU15K+zkcyr+osgY5zsnyYKuPm9q+Zg9Jwx DQ8yQL/Nm/ixngwpFA7t6sS1Q+vlQvxi10ADj9Ye0nglANWT+85EGu6sbz0QGZZtI2k9O/fr322O 7/vopVFhZdR4+bmquJO7zMe0rM5e3SA46LugR8sU0U86WNp/Z7Lq5tKuod98N3+QI8kW+bAQWodd /u38Uacze3+wV1QzvYRb0EKflx7MPpK2vJsP1wSAIk7nkGbfL6jgcl4iIeUz1hKf5zOAKSJfG5Fd A3WCYjs6yQHAPZ1mR6HWIvbE7TstYkHbm6QcAQyfQnxDDvso/A5LwnFrhLmCrPsUUwUAhg9q3Ogb 1F2xNUgdNTx/FS3g1LUd58ndwa/DvMXX7fXpUQTu6Vk/CMW1B0UEKQPzOiY6N9B2uTm4uR/qcQkb msFOrE1/G6PgQRFNvv6tdkzUhsj0uIgFYKq+PHOjNIPBG0dMGYPh6aCR06V1CMkYGN6kVVXGnPcz ckR+aw668P4TuKPO+8l1S5SpeUn3TX0l3yuaIT+aOnpeBseRfgbx/ti3gQ83TMXd7eNdXW7tiunA XZRqTER4Cdl4xj+hyAvc9QJvrjJ2OsLGUN7hKGIAk6arJwuIOpCcCR/93nPcmkMQqNnC0L6kIKhZ wBJYrwXks6tfHc7IDLzM99jXk44I7PYVgzimULgLgNhAnILQNjiWA3Sra/TndmpG6Mte4Ei6y++h vyRIfeaZFEo69gklmDRO4esd3SvO3GipQlNcaIwDNMArmaqzM2xchc1kRthmX8Hxjxu4mKJOh9Md xVnS5H/GapO7uh+g/E0M1Ums+gzK3L0HRVXWSoqiGiAGaHxR/t3VbUasfc54H47/NFBwu+cFVObr 5nQQSnUS7j77u4/gZQMau8fSeZPHm7cPjxuSTWTiVg5xUIz2Pu95+FIHOez+DuHsHmvBVZnkkyQp n+qzqjXGZwsEDlzXe9UCxjurwFn+cmhJ8bwXyDzPje1m4khD6n3Gt1h4GrgZu1fkJpTOLQUgbILV JFzcdU4jazUHy2gn+SRqKoY9dsLBHi+PePLVH0wh5Hrb4a50nYsFaVM7fpb2ksdP+3kvYtOGO9FI 4aQdxiDHgCgmD3oD1RAhHP3oJLwzza8LJqpFnJJDyhbrOYZhZySsixPuiHRXdsWugwicd51qf+b+ XM19/npk7Pwy8Q2pjuq8EaP2kRhWlWI1VcEw0h4kcgwl5rl5y1bZGdZY23gJ9jfkr6IB8VHD/XJv syudhesQDDBmqLqxRE47o33ZgXS3/ykk7rVcY8d5FPuA+8bEIzPZqffQe1gHDUnwXSZBsodpu7Cc kuA03ukU/2By2XJiZzfEKSS+49aT6HrlzxmwtirKSfPAtr0Gequma9Gs97xEKTyQvO9uY2oYCSSF HMNI4Dz9QRlrGk7WrU4xpj+yS+K6nWP0gYVLhXzGxG4E+3f+jlhvINDJFA5BXbodM+epI3HCQ9Zo vnLaqsCcSeHe+fo/2g+GtIpaPfmnLvcY6j/izI/hdOqLjYk7Gn2zlpBDiEWTHyYMrNdLcKHHwGLr z0FkoOvUMN3wasY2c4314bfpokj0+JWkoHR1duIkdeYu10iTJZGAozthTLbiLFuJv194yGLE+sAW t3GVH2d/jfOKB4zqKwvxM/R4YgfXiAO7Y2s4tRdiozlUdIlZ1zsyJf8I+i4FHv6pJehEmSI0r75e gYvTTbv5Bercjj5yiGi8ziiFX/ELn0qjn3l+OPrharyTv3A4LGK7TKocnDJrKVS3KE+YvNC/U8W5 mM+9gMm/nCwh+VekvdCo2Yl35pTc3Os9rUPa71VDIORDmbGOdegB9mDyzSakCeJtPzhdvZcVzy9x nvYdOoep9ptjp/W1alSjzx5Jgge6tc8An0Jm3coPbwwptTO7rmt7+j+q0n+KSeaYmcn11X6ninpy 8Cx/Vap/Q9LfqVNS3nk4tUELfga3AebGnBJd4u65viYxjnPqOcjffpdpz29jtVciw2UoxrcADaa8 OOQ6OVri1AXGSldyrFda0IWwCfDR25i1r3RDmiWxXGwPeWD+2yhWxx7EXtmIx7xwho/eJ/Ff0vlR nRPplHCc/J4Du8bQTqY0kkv/pSvzcMqngdrUfXzW2DRu9FPRUef45nfz2lhhkbirc30nz2BIj6de 2id/nsyW188mN+nrO0GqGnBvOW41xdQz3d4HJ5k1/DZY2I9WB7aj1VtQZaCiNOmCJ2g2VpXiLL/T XH12Vry3VLfGMhEbr1pur55fHKUXNsJ2SD7uxS86CfvsggoQW+L86O2rKJX6+N2uL3vPYT5s1EQ9 rBu81/bkTS/s6HLzvwZA7zwAMEX02iO6kJGFkqjQ4IlOgLEjnFYFQxOwzvc/NJq3e4nf9dJrAe6H +I0cXYRRCEmMk347lpGnfb6XRJNcpJnhFBb0TT09BzyIJyFouJwKIs5JB6GVzoTpvlajsRs/RywI oittF0K04af7zivGjKCqKZXZwxW7IUDwywR4+XQLEZL1Ake9gt/vA0S9yFidQN10gc2WMd+8Djqp AZ/SEclGDjdeTj790P4G8k1C4UpMqACbagGgXsXHmuXx7TjNoMvveCCbXeRbosAEnacDmQ+x7p46 6gB2nTSoEMg0uvLkuuRpOwVhRwTVNwdQh8fAVVzuc4iEMTogEB2gnA+AmvacuEDezkxtAKMgQnSK zxTBW4LCpn9fHUSwD9CTSpmClASvkpLn4y6hFsghtWHIJDPupBSDE1JO2hniI/0IoKEGhaCf27m5 DmjriiZi5+jx+6Qgm8GrazXGu/AqFAX0QZ9B1pvKZEdMWgXJtx0R9/T7asyKhN88ez7e93LiUNVx yzj253R9UYzNVOy7AsHEPR2/66edhrOjLg1ESRcgITShSZb5kBLV8Uw4qs7r3CYxeK0Jdx17og73 WNf3Yb1M7/D5xKm+oWhZcnjaO8lrnb8AoQFJR+2qaKQ3Ke0i2eEVo/5rn14eZoVi1oE2HuTUBX7N WG1yslRQ/Hy7k3t3P8F/OSiTU6Rru9/4gLP+FGSZzsC3w3B3Ocxh1tnTZOyszvHgguGTKz9HeMZA PeW3A8udDMLV1w0matWTayzSH+JhDqQv8rsDcaaKeaZAZB+gE3Kn6PUKZ31wiBB9vw14XO7AeQqk kE9fxAg0yMpn8CRYpkgvnboM5JUivtsI8NdMAdJ2MusYSo20Mh8k/ZXmsp2zL9eQm6iZbqYfcI+S /+DnKQH77Pm5u0vozwhb8t3RBJHgPqSwZPJwhacOboutb1HaR2zEQwibgLtA/EWyn+5IG2vIdLR+ 9iTGlr8/CRGt+1UHqWmuyVXwViuchWM83G8sIqhCF4osfDgg7YGhAuzMIbYR1Dr9zLgogs8d6Eeq yR6u8CBZiPhKh6/pznK44HqeBejIVTMuGKkRv07tuYYzScGHsEGYDtbJhV17KO5FL2nMXguXy/tM USC54b6Z+hljJDEPsmSLrbRB/vs2qxjamkSAKH4E2PFftZyxhr+ITsA87Kqj/rnEMJk2lgTMFCrN WkIkqg237VVZrHhc1RagFFSdPqxGwOW5nwBtX+6hv8kNkIuwbuLZjPcSx0BnjItTR+h9MT9ikEJ1 0tirb+aeKYXLGoOGZ52iJPIieasu5/DDfGl905mcexOtnU+jhJ6N2yYOqSkGwP5LJ7dgIP+uNCh2 4kpkaAq3tkgnb/7b119wh2o58NZxJt/DNT7u1lrE+k+/o7zTrqFxyrn74TJ0pzlsEVPGyyv74F/b 2ZReQQO0KbMz9P+7bmXhxHxOjvSyzce1FBlfffZaH6rTWoNZm1wDl3WGH2dW8qfGTlLqdVaiPtud ug8hbCflD25E3KPHcU/7xJEOeWRA2guXBaRHhWeIILEkHe9TIjJTJ25OTGGaVadhxsYDhGgDG8WQ 4E88Tg/35J1cURcTLiHen31kx8jCHfq4b29e41ev4CP79SNc3qZ2PrjTNlAdIC+nqxq5YuD1gZMn awlOxSHTxJeKIz2meU9kGucji+fg1+7EGMUdLKjLCcF06E/GmYdntg/x4fw0LIxOfPTupGms2hOb fWG9ZkSGE1cEBibrHv7Lf/zbLv8jdiT3OVRq/LQavJGDMPjZq//1qvrXqvzHhX3GeSLC5i4u9HWH 6YuLaa/V6jCcIt/8CvfdvX7nFlKRELqfBVRbsDWlz6Q0rb2RqfMv9N9gbFbAS2sMkWV6uSC9ctf6 lA16C9aTcd7DLTTsWVCjV/b3aHK4dtBhMLExz52owOYohA3PXs0XnrKNMky9YQXvI8RkYBBJWvYT u7+9e6SJ/+c6KeDSyX25r1l/UddV9GE0vKg0QrjS1xam4dNm96o1Mg1Z5+dNVeA0IiBlxtTLCFUI 9LQuzuYS/bf9ZQO+w3V5Kh880nr2/SXgNmhfXjWOnnUTrxGfn9t1JW5lJ5KGAfRk2NxgDgFtMXLY Tmv/HuG93LmQbfLIPYRgoPXCeK/BYO5XtbShZNLRk133kMg1RNbv6Gn+QYgUDF2r8K5Jfm0aOL09 /7X42YsDJs3Epx78NeBTtZPkydS1ItFzm3eGXvWX4XAY/jruwH6v/vET36wZIzrjO4wucuT8wXKa e0L0KlTLBSGcGtEs201VuvxXqKmdLlWq7axdCNwnAXKV5mNFfg5/QcM1LpUdd7hB91c0QhW5PoCU 5pQHphNKHXTK+lMqmPxM4Y4XsCEMPKfm+n1wdDFd8JvwTS9xaaGDRg0SiMryTzye7wYK3XPut4Jw hgQE+beQbuEFNyd/tRyu2Y1wiJ+8J+D20IZOD6JCwCsphxnpls4N1Ayjw8+rGd+k6ypmDIVNd9zS 0dwTuUiThzPyslaBpAdB6LNoFRADjgjLd/AKrR6DmHE2K0SmsCB0FnWKn0GlnJdDQ30bZIm97NW8 N7K8kXFeTuThGSxFDPEldtRzb2c4EAnT2O86Yy0VxPm1t/SMqSQXrAHqeO261axSIB853BQ02ldR GxCpX7uLnCZ0APhEjm0Xrg0u0GDBFIHp4RLYp70d8aa0EfcwxSo6zavKjx2dbpAz1vk1QTtBogKK GshJ6RB6XAHwl5tiDh6ocf6ZVaGf5sKndNsRnSx8d3U0QzepYnTHzIi8vImoya8zQHWfzfoJP/km Hr+9ujYBqScYni6KdAYYHG9zcEBVMDTih2fGTjpwa3g+gjKFSGO7SQ7QVDlVrZXc40dknmB4aJJQ SayzNIOi47crgI/VQeTYn03204lpxyi60vnjz2ekoxZbJJHhPBuCmJpD0e9xP62eTUjUpp/5HmZL p1edA9yCocIEz7xidxnq5wGqHMTt67iWKyR7yHXBPhEFdcsRwvEmBYx3zUD9+v7Oe73m2I7wbkjJ icd9yskwhUM+/upG4tFXcn15xd/u3kV0clwd+IeI2WtfN0GYdTVLcOOt+MJGXkl4NSNA1zVA2RGY IeVLol5AICXQ/d2ZJMUtUpKqRteUN0l/36daxFCeRdcgeYqeWQThlULVe15HPVfYa/s8zww/51sd NJ1uMj493bG8CdYvLmQeZ9oFuK47XTVEWDmAsuoucQ9rfJcsvFPc7dNJyq7zNrvO5ojHVeHvZrJY R7W0BiB1peplNsM+madT1jd31pfT5QdLy3MjAfgfQlNUW2xKj4giHY4zFQTCJcrH/ko8Xl0YHX5R 91fymR5eWuRsa3x/CqHmp1YIgb1xNVa6fubdl27r5PZMZhjt7pMO/MxHcup2mErK2I9YYTdMjsxu 5gDJJSHhXZkCQGOyYJ3DyfmN93Dm/gkGzMI4/mxMGPQ+45ewpRbRKZAZqnSsTYFffe6F7KP8SF9K EfbPNzfXGDp7Wj65sA9u/zHc1aW6PPbYPCXrMMPZlQxCyhIF8kJHN92Epaq6kg53opmOi1qY3HbV bW61rYDorEPM4GO0TzjgyD50n3UsFCZSoleKCkPEiglpa6fYUS/koG/iDB13vep/Pe6AFKNceYMp cvdCql09QcUPJDZly324PUf7Xn68FWNygd2Yu+29avYz2NifjtPlwy2SQ2GNdK3bjGYOXdz19T4V l9xJOk8ovoP2ULuHmMPHulEkrE1+R+fbKRSDk5VbOv77TKidu51NaF5J6dGbeuoPXmnuw1DBLxHf McxSBY6yrZ72a9glEbaeChEnpnbaOg8K2AUJd1fK1ybYV/3tWthJcs6f80/wJmnP0Yinv/JKBr6A OBj2zt54kbEOJiMIYxL2NuXxw+d3mh/qOF23KHPfSfZLA6LjhLh23+Yz2eBj3Kt6v1XsCp39fks7 /8dV+pv6ghjFfivF2VxHDbbrYan+qqr+DZX++etPksFHYhPXrXQN5vAQ/W2YoEqB8Xvg/C88Np/H e8/EaIVn/7WfKydXsPZjDsww9qjaCZEXh6hzlVJamQ++eA9/apnL7O8/BzWZ90293HSy9anpar9L Fb+z1l2Q1dNO1HDRgB5qOJRvsGsfvJ5VF0e7faa9mij5+Db6WE9MdWTZgIkOpDezU3em13Rcok77 yLQcTQb6GvN21FlXnqmBX8LErCLTs2vgqg4h8HcRfNZ/2e8SBvqycnXcraxguPfJ5vYa1uWC51rH 2lOIrH8+mak3p3yXfL5XrX7dW5TaJEavwxBg6iYVHGnHb/oAq1Y9SkiDz7vcyQngPViL20yjKbqf XenwfXE/xrrSVc9kpwL23cWjzwV798Vczt6sc6qU6MIGSjpwnBxmnHxiwXoT1tZaXdCuZdLqLHuh sctdoLGAM8973C5Tx37VlNM4fRlvVep5/hCsU4+oAUNBrDatSEWCwh2owmq/E4OzWepAsBbl0d0R BADJVUSL3DQaydPJLqQhtIiMTvT6N8JMxVssyTqvQ5Tmsa7DxYtArHrFi9DFMCdMLiGiHtE0zkgO v5ocHxdDHW64fri/tojvU4BWSNxP0ep8DyOGUbN593CQUXNbnPmWer63dAib5U2KPwxEx02OMGg7 G7wmdPQxrrIiv6a4Kc+HD/hyC4Zm5C0XENrEFTzDLiztzXVe1joBsIS59IhOgbguz32A8YZQGksc B4YFkR+BX873vWPrs1hOcmg0X3tYw1liGVIacoocyoudeqACksFxCyQgxecFgwJ74uvnAB/vXPi8 Oyhgdkk7QYY5Ma4NePeVpAoibztahbcogPvpS6ZFuNZBbWQsTDr3C0Q6BWfUJRyh6XUvwqywqZpC h8ungby6/ADHBIInrX9fdSddLJdI0Vm1xQE78DVJUy7KX2kbRmJp3yiCdeMYoUjRusGGiKFTgzuU Y9DtvpV9ElTcuGsmAnmLkBX1l044TiBi8Bfhzu380vcwA8x6ttzkRLPrXocDzUcksgdCX/6Kbzl5 AhIEyioEeH5QVUuUW4UEQdIIBpECtYw+skiM68hf38iOole0wjrJ+XWmqADUE5JfBVHMKaKhs7Jf DBrDdRX1QKGTuQ6iwxCmuNNxNpGp1/AMCH6ENN+6uXQB/jyczUCdovqkaMerlphgKwnchaDoJZ2+ ZAO9DhC6Y2ZvZ1gj27VlkANSuFLOiOR30tM1kFAI4xrcHWhATdA7q9hJXANop2HQy8GcfPwMjj3C b5zDqYk3bDDrBXVNNzidhMwWK+oUsWyK/NPD6NF7Q6+uOvoucL33iqSOI/UmS7/9nxfZo6f83RDJ W0BJXI4S8/m7JcVsl2A9UgVTyCQAS11FTlIHhrJFovsM31GV5J5oBGl1kC0FWMLE7TaB4ihrW/Ur 9ta9w8+FxHvcuWu40WvgUgf1lPfdG8OsDQaPO6yByKqaseY95SlxMCLEmWxn12aTONuz72SioE5a rhYJFbgSgvh69MaECxhu11o4p5eo8eVmXTNd03XUsJC08Bh+0EPI4PCR9yG0VrFIndzju/hc0Bfq wI0qjEi8hPMkQJhEt+BUUljK/Pynr/6B32rUCweW7ZM0aSKZRWJ7uWWy85RHDUT4sWMPVcQICxIo eFzzgxlfVkHmTL665U/3LUhVtKKuoQpnO1/rx6H+JSCouof9aQ9TMsh2CHS4q4kT0KoC4+DeiWOd KSkspY4pMNgx3hVOZ6rC0ZA6x5B2OpkQ8/TRj9WBoqk4lZPqI0HNmkR9d0PNvNk6eqE69mGmFF65 WTrR5isDkhwgfTg8XxhAcoN72IOrtmaUsni3qtewOCVcX59QDzHISn0xcRRGcYbOc8IHBu2zbu4i U4Gc4JIhCM7qwKuUUnj6jjSAsu9eHXtLgaULBQ402GqssQR43yhiV3I21VICLDcx58tRPU+evRYv geWuzbYJ17WvkkOowyInUUbH+71zd64kWYeYZq9zqhEH6qjN0ivqdmPSZR24eHdX97M+iiTy1WMp GCGDSV0fBnT0nUZWLbnz4bitB4epGvs/R/A3zsQdkJ1r97b0SaGiQ8ha0Lf+DhYxU3rruco/CS7S xvOrwD4wkiw3G5LDUUsjoytdWljXFoqqLxyowH1z49uvJBKtWsM/QxI3Iup/WFX/1qVt6Q6+mXuv GYkGtyznfdTfrfLfq6o/UgSZeJcQuSnADCmJJ89n5Y1SdTi8T4xdj6p4GQIExplC5ng22nuQbGkc nQayqxJwpD7yw3MP8Yjs2v3m4QA9xsz3GT/Ns1bVKebm9wCbgy+ddWMmctBAnXtpcJgrCW7RbVZk YAn0xH61NDYd0P01OLHvUlHKyQMDuvsF4rUXXh5V7M0d/7yLbZImoa6Kxji4Jrt5xBxL73eB41wl I1MdwvXtcu0jUaLOAbNXgsriSk1sUiG3lQwZ86qUFqyTqVeRWWQN7KDpwwQInS/7uFUXtuHXPZih cKfehqxV08jzlZNu7D+uymbf2VJVHQ7+sU70cjg/ZN2u38RLe4JhnlmXMumHQlEdmI7OgY+hDDDh 31o3hSBj3QvXg2GCx3hincgdZOvpy+CHL1533qpea88nxkm6gjrvT613JzQemPdOmoNtbdiVbqOx HueAZmrjdtJZN5cghdQf0dy2wa8e3Z0gGJNBOuDvC2atYpcyLzeKKx6TYxq8XFlqAM+7OOcpHCZh 3Yq8HVFkFNWtmL8AC30AHEu4hYKvO8aTwUUWmA2GAMFCdkXM5vqQZ2lvdTjkvQhD17EVC6K8jUU/ kYEGh6QdC8cTUARP54btMWM63bgLIuB1lngKsMQhYjZejLwzGHSbrnckOiEXgsIC5jMxT9F5LMzz cIXeJMWOeqojYnxP4O21letiOrpuoWY2SboJUM31rOeZcgmnbgKQRCxDWCV+l5uMqWICUhAb1kEr jaGgtRK0pQOONp73u1rkmY7Y+3SWVWWkNdF5PIGXIro8UzRAgCmINxY1l1Mjw14cm7MHIGpd8D0W fdy+yig2Klu0otUJKBe4ml++3VWvuFq+Q3OIIO+YTh75Ic1VbQKfnY70+DQZoaXmqsIxpb8Dk5FL mA8A1UcMenr5cJQ8J+YUNqbkBgdUP8R8aQmUqup0Pq4gd33uAR9CCKdTSez3Y6hEH7ECBZ54NVZG 8prEBYaklinCcJtO7U9LyntIJ139EJaqHiSO6xJkCUkRAQypGLy4G5V0zmOyaTe9dQBABYDb1Xxn baFiF4OD4ghhg553tKogUUQxAvp2CSXRBMWR+yQVGCDUKQ7fEYQzDvcOOd0JVOu8ModgXv87Y91e Yn2H8G9PyM87d/eKbW+5FjDtB7BKb9/4Hrabys+KXe5g3He4Xmk9BD56HFlX1PP1LaoKQQu+t8kl 3VDFTvcxPjlzqC69CXLvVo5PejrO+xjZNrgs8Nn+JjP7YNKbpPeCseZ/D1DWPk9aTAAQEUbtbTgF GHkXzD2bAeIeu0iQXLDpZv/5gMilKO4PJ9mvM9qbEtwYdCfCawp9VPm0WSTlMwWHor4/jenHLYZF ttOFpACr2JWkztqV8biq2zXEEWXLPld+uNHU4e72cMsMR7M5PHyRLz7EsY4p63RV9UHEK+mNA7D1 o1dYw5E+XPB9YAOV7md7+GAPt6qSl2cRgo91n0OHk6j55uRkFHRk/wz7X2DY4AvH5XQS6so/JLsQ D86kASKu0s3RUIW5vmFXuXb2vhWMDNsGwUUhsckicnonVa+kRJiNhLhhltkZiEgOHr4dwIa724lg k4MsnSM3Sf4xjWjuVvCu7//bg7xOqtDZgynOYrUh2DQK+YV5pcOkilkKpxGIXVe+zOj2jqTEjIwn saOBO7liydNxvB5COYHL0hR9BMiDmzzdpgxClTt1LZ/2PVilQyxAXSuRyHtEW8iWkXWAzroVsb7t 5Op6iltf/Bq/Iz2e4+5/Coc+0qiji4OBMC1OWLjffIHrJ8urf+p81xMb3UNTN9bBd/K11usQJXQS N0UUF0OWZ+7kmlzbLESI2QlcIwt7KJ2YreG+4bMircp4nd0c6IUrpiTFi2MWIn5sdELM2eXXqcpU Px17MEx1Fq+r2oM6JD6hUyyT5HiwN6Wh75Fnhat1pB9LtV3eOUEssZG77rkT56+aLdga14HTcc9S mHDlMCAi6c5EPNoK95UspNPPlrCwIVT3daMrenfH3dd5mcUE+sJk29ocpl1HreVZKwiHku79ZBAJ GZCYN4bKWItaD+dTXTJxGC8soDBDpP1G5Sn/M/xcZIjHiDSlX7zyBvN0TRHoEG77OnP1wMy2SGkL pXX0sY1rEyHR4/f9P2z/uzp4w85Tu7nWdkNCX2csrJGq+itX/U+r6l/4DHRMncTcj2Rak1iSceDU Q2hHe/5OpnFzwa/6Lqi8MI7ktfftsJ3M+YfdxpHs+ptYzssaktB5NS1Bfiut5DdncjcytAtDdX3h t6sy1cSQWEDpiRWJIBuDJyMkNjSrukXLfiTZvXiRbZCkRgtrnYN5hgtSYi7Mp86BDp+86BwENCKU CixXVadey5AI0c5zX3eyTlu/guq635N7/3ZzjBwCY/3Ij0lx02+60gyT8prPu8eJiO1EQOJiX+fQ 4MXM2cQOhmjzEbdXfBe3fxIGWWGVQ6Rzv3PPq1WvzvRjrd6W0pemYcK82a/0uahXTenw74FUzkG8 VSBdV/E6P+5echqs5AmtqKM2ZzmeMaL1GqYMs9/71Ot9MHFziVdKV0/YEaKCqTkdSo9lGLeHrkR9 pd633+RWHYhzPTl5H93xzqCuR490p23d51Qd/JYjbakPK5BL+9QzZS08HN0DFu2OcdLZDF9HeB2h a/UU/+b4BrtPwZctJv5/GgjPQucWM01QQ8e0DV5WpgJZWHBoFTOb/CGntul8/XZrj0lMX+A++GCI ifsFrx8FYn0VkAjjhXe8gkhH0C7xqnrEbXFz9Cr0KgAoHd+2nM9N8DNfKQem9pdvtZCexefdzpcL vPESbJAI6oovU93ymQKgimecFJM3ryK3R41vEYNjD5pdjvt08nJYh7K9rnjPODTFIKbBsbBfUjYF y3LpwRFChWTiCp0pjl42rod92Rod+6d7VzqosRgjp+UYuFETyPRo8LnH33u5i9AFwPReybuYyHhZ 4Z3A0kWQZYpkg28ReL8jdzyxgebPqdRaRWhOAAewqXSuRjfAc3qTB2q2jPPOTVBVuIgYphIp3aKC PMroXJ3vsqfM+HGHfKYTZ7Pyce0AP0VP96BZRJP/YowS1S1hzHplEm06xgr3oBK76N8nE/kPoeRx CU+/R4zuJB+cvdc889Nf9BZ3bvBAKzWoDyoK9qMOUUk6PMDwxLBi8QNKEtYUt3OTviQVKPbSFX3L AiQiqo3n+yaFZoTVdJapoNF4AERXkopB6uk6Aj3TPWnW6RvEqaN/eTnjFVRIqpd4ehMxSbr4UYXp DFUucFjPSXZ61gDrI3BgGLSc90img3AcGjv7HICOdisMp/yIMbuzcF6urN73j6+APZhUt3MIWVm3 K2Lo69iVPkIQjUGu+9TqREGBWHnWVpd79Uo1OgCqX+eclPKADixT1OKext/k5CdRbvYHAhRQJ9Es AJImUO9zDSpc3pj4M8gzVNv5bdz1YnKE7zE/wc4Ueu9PN/vaD+Cb8vo6OqD9pHty1SVBD4chvA43 oUBDU37coEzm+sxDqKIg45Qi5GCEkDTu6U4FQ3UOAJHvGGOPbxCjG2Qr20lmAv3gaoYQNTu2UmbO LavJQaQ8j3NYe3/eQgLoU1t0N9QKseg3Am8nGLzuoS2QLQChM2UqySEdtYGglztqCNeBvc7hn33n GMwA5gApRWCnI3UFUagxrOJRe1bR8PQ7AS2dmXIwV4GhFqQjbdEVDZDsO1cY0FvhllNIUCah7+VK ufuN1xrtg00+7nqtRI0+ZE8mMfz56iDEaQDRUZsbzo7xTrXrq/sMmVH0OqnhbxV59o70rqnXRG+p uKc+JNpiKbxxzU24axi+zJ40jUzwng9+g4QULCIsOnV0Eajwls70lTkup6LstsTY6czZpighIzbV epDA4zpi3RURx/UcQKW9k6IG+jN+1hk6iWVaixOX3aTyZoU6f+JBntw3XFo/sGx8kcbRufNa+5V+ fGVAbIEbDWPRwGq4XfqDnaTDHcWQ7/vC6PjfxXJjlehOEyUjnYq1edVfBrEDSJDNPcx26+xpOvn9 jMO1KPnyxlau+smALDoGYAQiGl7717BJO/sODOcauNGxp1lSo1Uj6BAHZj9+u6jDPSsBv5SnSexX XempRoxLByJlwBFSBCEcB80azAMLNEhTtGrNmd7hZXZiqMhnargBWzXIaVTLqG7dP8L1w2mf4er7 le/ZdcQ1gKXj3WkND6290Qb9CkQ8nTvWMURCZfqFWdA9dmkrtsZAmN5hZCRuQ0CjRUomB7GotON1 Bl8PYSXWPq+Tl65EyVB4FL0f8EWULzY5whzRNTizXp9rdChajsZVJ6c0ueMtJk+GI/UFmTxbz/rk Z93/h5L+/RTQUhJq/eyHFIZp1U+67rP/hqr+XlX90Tl9lrMV3HFaPbdRNPtLdLfdfy+TJhyKgATw 6+7zGl4VmjYR/+hlXLlWlZoBStTUfmCsWuuH729GzmZLfY2q8p1WUQcK7ji1FKs6e1BjIg3d8wI8 I7GNrHmM2TsXL8/GljMFk84K4ijn+a12tytY7KUOOGuz14DadmBOs935zmjQqkKL4tB1+dAsZA22 V81PDy8y06ovOORHT+DAcAmJotsgh2jd3LBnz9UNjAtzEvRKUdHW0ey0rWqC6+u7U5LHxibpLs+h go4NnsypdJzFir2odlf0NTdT4z66qtRXtT5qGxPpqOvGzyftxcscdes6Js+T+oL57Dw45Us/QRit Zl1vx7DyVf/O2m/WVMOJ3df7cibDQl9fB269B4e6A7miL01TA4eWpPcvhrP6819Ggs9RY19ndtYB IvsN7G8V/ZLxhPOpW5v8wE4poBThTHoQOsgTlrwNKrSsHvZdlCNJU5P860//4eU+1xdCj30gIEIH gZNTifcmDTGUaMLrLcnN6RSPibiIt3UGNBmnkIwA7S5odwSe8XKuJC5cK/ZwHSzezmedNMmidBcQ WmIRB1BpPBDRV/aLYPcirvKgmiS+o+VysfvVFpkRAHwFPVN00G5a033WzTn6BxyxD3KSKVWDGNTP CdC7KIIyKQhkw8TkhxSr2u5eNLFuHhupdNgSvK9r2vDlANymrVAsXBhXpKMkz+LplkjMi5qSHnwA ve0pqOBwJ0d1phQoxIV8f9iJek/gE1HAwuOPq+s8x+b5PYtGLsh8iif8jDCee3DwnNegzAL3yH2E nZRSKKDjnsHdZ15FhibeCDgd8X5VMNFWAcBcsp0k290a6fZclFK6BGdJtEGA6/fhiUJHT0EzRY9V 6FwpFJRVkZOdV1McjroRF8kg7k9DJXLkWOeaZqFV4tphtxNbQECFtkhQBICiQ8jQiTry8dBBHtzn dTpRaZyFhcMuAI1LIcglORq50nxcy/oAXCdXdKabdFeK15gmu4/rkMMAWaFdnykm0HlYpA7yiu8B rtsIAOZxnU+zV4fgZQ3UrRpju7BqCVyYyKFJfxpA2uKSJqiQHiReVqt9aC6ACNNTXITbY0JaEf2+ bgN7Jf240jEqf65BMJNDhnsY4a5IjSKNBAUMkHoCJy9HbMfEtY6dfq1ZAWlfBcksApBrRehq3QP9 vNRa37PWYTKQhmR2GKQDmPvUUpQ5sLefSBxUFIK3dpIq4lB/1onqqDOvnJPP3/l1ZtL6qKOiYOFQ DhONJ4J8qSE0PnsIHZKPvde6278hoNAH4OsQhxDBn29GUH96Pb+LpKBh9Z7Kk4ORit3Wnfe1HGu3 mCT22RKgTdJ739lMAPalt13fCnoZEifS4PgVX/3qA3R2hLO7zaF6BdFLgoAk1oiKMhBa+RkEH1Wn 8G7Ws1uEgcP7Qc85HZEBu/NyZtwCQp0CyztW+x5Ir8B/LgFJ78d6v3KJWlUkeOTkD8JBjI5gXkTL 5WpkuIcmWb2T2va+/9RwW7B+f2aCrGhoZbvf7RpQUTNQPQcRpzfGv+o1PWqYKvJdT2ebb/udx/V1 rNHAfledu51nBhYwTGQKa7wC0r2KBHMavhYp3GJnwJ2QeNU4KI5wH8StGAhkconFABV33zaigVju 5SRoIE+ryFVVIPYi5+B3Gt8lblTteN6q766c1z7lSvMv93edginFzZHCFKZSCzvudIvP3+iTTs1f uPGGj9vaxvbT4/LGenlQmMTK73f1pgq//cnphnv10nUkPjr+nT3l2BnjrboFmZPnyBPYVWtg9a42 LiFmLYQyUzfnsNH1eS9xdQ78UvcdP/fT/ESXvMcpBWK7s9YXe/kTtm7wAk/MvY4EULAN6EZBNor4 6aYzYOKO3vxey5SalcN9ORJmHI4gHmMOwPn43Vs0mTzJ5gyMZ7UPrH4LhXQJJqF+7ukDZFyho0ud 5wEyYYC7fOEFz+H5bjgBDtnngOQa2oS+1jDYJUzzFph/LV5Addf3qug5dl/Zk8wzVYNq4ewNMxWV TB5q4Sp11g1pfvHRH+SZWcde3CKw/Ww9atDxPpUJ1RXilmQfDRqHC/PTl/r4ujsNNWkdp9g38TvL CpV91Dnarepu36P6cBo49fo7RblbgJj13XVGTsHaVU1tqxSt0bQbCS/AaWi3KNAW0P5o91hC1o6y Mbbw3qBoMPTjf37Kv66qf2fXqpTuzR6rk6fc/fuq1P+pKv/rrvoXKWmrgJdKEWi7eVQDY9F2oNU0 7CtwNq0csf2pO3OQdibqBJcQ6QKQ2tjWiIEL+vRkVTTw7wN5C37S/mL7U2f9Savc6FJcgwff33qn e+/6bOKQ8907Uq/WPbPTSD3rBy28zZh84jBEU20XYsYPorNRnZk7FZWdue8T9cWcrn2bCOrABh29 TAF+TwZltNb2OTASCgKf0zGat9NsScuh5E8iN0jj/khTxldqdj7rblg29UaHsanyrnVUy+zmnj1r jTOszsTuehgLvM3uZl24vyfddqvrsw9uZnNElyGNF3cx8VLkKpw/21D/PofBNM/dySXMpM5f/z9x xQV9sxY/bkw4EWJEXaAvXUgNdd66mOI2qKKlXeOUpAsbTUMVMNVwrjM2Ztjv9cHVCOr2X/2J5mCH 1hmza0QRT6pcY1Vk0GhkRiYm6y+1+m18kjglpC+rjvODO5GN7372K6+f/U90mEn1T/1HJ1GC4FQt AJIm9dIVOf2xaCra9Tk/82AlH9F6uJQwQeAi18U+KUCAaDqN6gvoa5QAb7cJN2J9LghyJHdcWoVF e8Hlogd5k1GfW6QzRT8pnHW4A1Y0cuxxAaRb2DGko9jVOiUwAeTSUfYy4MoOf6Mw0HVh1iDpESY3 gSCKGCObiladNNTt/L6iUqUFErepf3uFIdGldclWtKJfdB6UlBZg53N+F3m80gnCqAfdPgtNH0XY dO3jT0ZxHTUiWD0aqClPUYh4Kd6SHBimo931HXOts89XJ9ELHDCTwH0Dp7MY4fjJnPoi1zpDwcvr y6O4JQA7ykRwhnYQxekOpiA8ppCIWq1CMRK9l10EskjFDJGvATWfJbzvQpYc9cVOlz4LvlmoXZFy W1xxwXskPrnuYQ2HFgbxdcZRt3ek4rv5a4SjRprMdtP9LgS6WoIlPhg1mXiSUzmWmMfqLMYNo3t1 NAATSBC+n7fjkBexCYGxTofQPQDHA18F5KkjOCYn3DMhZZKEE6wSAJ1apPR2EOE7bg5asdMtNIKm IU0Dyfs6OdhJMe/1FeU7hO1cE77F0RnfndGOvneaqupR4RVGJq5qUgIAwRBKrwOo+dTEhuSTOXzk qJ3SGbedV873tF1pujiU4tbmr75dPSm5yqfj4HVudnKVBktVL6dbhxvS/K6brLjOSATBXQ9vpQRY iehVgB9M/E2x0UsSNu+nz/m1RJVmAoLIqrrO7+UapTONKcmf7ciwh0Y+5+E9MJg1DdDzP4d5krxJ vm6Hx8LB0VmbdqA53ah3/ZNuxSD09QaWBQ64LpIV+TzbpjvncKVa6idhvbkc3MR3vsQgeta+5EJP Ln9wj6hQZICeoRK4sgmd24wV/BVfDJHaNvbXHbhHAYnqe/23xSIIRF8YSd5fH7K0C86hR3o6w3uY Utl1yD+mc9ceciWasZPfF+DIPsoTO/Do30gmus44E8H06VdSxrHucNcQKKbb6+UumDjfBrK5z2Gn 3ySuNQwryAk6aiTdNVbmuPhRJx3A9qgfevyrj+QCIi83CF6P88BYFWTKKPcZlGhDlP6VlqOVAPUh 9lO8NMny1ee5DgLnlaZhwJfnkNYb4eJBZHJgUr3DjX+dZV2YRmYKeWYZ/JsLCV2fJOlHiLYJjsIT Hvq/PjDn+oIt7Cejc91lbVDF5hhQnbmwC0v3ZkUq2STcr3XzEHvD8KoW7uHD7ZhSw2itdZx+j8OR +MGABYwdoyoe/LuSb1yFdVyiDFt6deGP89xKrKPX7jw4xOdPr3O7yxwTjSx42OfnK+NEaD7kdSYb ao3LTW2uEx2GHOzXL+gQlxcviojmyZVyPcF/35hGjfN0nAdY81znV+vFQVzmyMXREAp1MRuOvLiG CMCm87r3AlnrjA5KenOpop/juLNJgHRbxhhqDx+iFsKInZ2DeV8ITsK9FlMsNd3HDfKfWmKFPrhO I79e5g2DG1eda5iGA8ke5+e7aPabWkIKo7zAP4Idn8ZujEndKdrmOsD0VgrEch07b2J/O0R9O9mm XOG06dAA+Ii8v53YZ1KXoW6Yd4dAE5A94R4KTsuDvGPu2r7fHW9XxSpywhY8e8EAix+oToHBoVAT QJzP4v5sZDrnPt0YGAl+PPrAF9eTfdVOJDfyBDrqyOHAblJcGFBVHizbQ/dCTj2fBKfR0J6v4gFT HWJ/ktIaeuCqOlyTt/ypiiWh6zz5f1X5/6PtyqsKzsK1PdMcZguZmjrOrf9qlf7ur+77B8PXhWde fuOrHn5gn0XPRMKxpzkQtnmjhchppXIsx3cXmxQQztDPJQ1iPBODeb0uaaQylcTwd1KwutGx/A27 ThSm2JFhW43kwT2o3ocP1YbXFbjG4sWVZ94H21nrZg3N7jTWnZw6ViD2SAI7k8NkFThzevbB0Xj/ LhZ13kaYXul0Va8x05nMkPdu/3c6TEu2FuRa+4H9SXjn8V24hfisITCmAfGwTrwFXbyn0ONfkWJj TsdQ4R0WqWGImbbB9kNzkqZfVfUY/hu4NOKrU7v5MfSso3MlAa4OLitTW7dxGWHllG6sg9P6pHl4 DBJNfL3d1Zru5JcN1o1D50DvVRvMjG84h+3aCVaXLYM/hx8m4b7Y0pD8++Z+dp2U/eWujVKvrGKl 2GXc23kiylskrDYTYOtkiLZmh7n4l3Ey68E6DuFNMMKg9+X9vwfk84kpMFup3YeedY6WBvHKqqlj FfyhiIxMuaGBhORNo6MZLHh4n0jraOp1bbiM6iB4Py/WnNY3+FnUEKDXKhpvqPFugb0KzR4J5XQ9 G4co+R4uPzgQ5PsgOO3tjlhHCHKBgIeIJs8Ym2cItCGJeUVSP9wxKshEAWgjEI3UeVnSRO99Gd8e gnt7X3Huffq7N19zItYwU2mYmxY6uN1vUTEDusmjSTx4TSzeK74Xl+MC8SYFDCLM7qRATuopas0o SwYjs5Vmty67Tvg+ki3qFmt0oWU6rTkKx37Jb9fXHLBhKDZbFmqwX+t5AdRa+zvaGcE5NAdcLhc2 Fl9lIU/tBrrteAOpCwAQtw4Et5Hw8QokZZf/bKCEQobusGkkAa6khDntXRB9Ntfc5xmkGC4kpX45 vFcdIWbHeU03PblkJhDLhWQ97u7LxV/rTOMZ/ihKEYIiGZAC1EQ3Pa13qSuOyNCU+AAy4a7UnnV8 xQVu5/XprKHBPHAZO51b28oyETEJemHR7grH7p/v6zqjVqm4N+wJyhPoIjdBGoCWaOjj7v+pU8k1 VHWdCZdImmWKdoGbau60CUZcUPtdvaKrdKSSsDv7FFnQgMEVqw2xe0ejduQBjOdUR6LMdCNorgFH vNkQbmoPIDnEqnHWQfydj4BJHfD43scd4GA3dsNkfdVO5tiAeJlWh4B0eQEVbcW6r0HX98pqToR7 x7zjp/DoPzJ+vhBQd08MWulUlO5FxGZVvQeEsT+4MiposCOj7oeYU/t8dN3xdtkbbhEBE9cVp/tF BnQQ3N2FCCMH522R781cC7qKHU5AgKNLxthJYAJn5xm+BzCve23A5+KdPJ0a6KyvL1HpvPtGDaT5 rr1pXy+6GPvcvY40hnQd5KWgV/ASEe1eJs9Ddr68xK/weX3ROHRzgHhEOhx/vcQ0xjuufuu/10j4 4fvRx10v7KZsJhBrnSVetdX+UFvwdMXndiLykxDkqBXZc1Nwx646r+9N9708a36K2Mxaltx+s8v8 AVE1BxJ0oErdTTUkkYAjKDAdH0QPCMYWtqbKxCYeeOIozxwUIef6Onqc2dN49REz3lewFu87spOF 9+l3mDiYUkazb/VjkK4i+WS9Pc+zbTvV1YgrTlmOj2S/eZYI7h4G8HPdt5/hetAObcf6ruk6Lplj zAbneMCJfTkBVd3++gYBnY67uaIun45XNBiw8Td2tKQT7CJmWebj4djcBQ3hRAT4hM67ZOIHY4hf ryFicojTnbxyUJ9V7Es/bnVP3kHjnzsEENuCgROfst7u7y8G7H2TgNM9Kr/r9kYVJHNN8s4nvrLF XUaMh048Y+2Z7sDZTwmx4Cu63IfR0x4oYYHa5J/WTWbq6657NfEQOgM/g+IGoy0iiwm97cP5ShH/ 6l9+HFhNCT4+yOI00zDus4Wvg/HCMJ/QTG7r5hXd3GViFncawcZqr1SnrAm2ezbbSN0jFkaH0O7k VssUwiD6/IWNSe/hHoWL5qxZvc5SZsAvXG86iL5wax2SD+I5bryrioTPgq59/8SXeZCLkiH1XTAS uDm59nqkOkxBWxOprLSScOyUnhjUrzpUP9CWzxt9/qw8Rwz30zRt4EQjoXkRiYM//bVQOLyJYh4Y Na5Kr36KxayUNNVr1R+xsOtgPa9hO2FCrhYOEMnu3knYOhL81Aa0VTzMnpqJ6MrClGGOuSEb6Xok PeWn6YK1neA0E98NOOBtAHWn21xYe5245E5mJNfw7kReiJNM/PE5IAhnow98UZmU859V+a+NPO3m 4xWJ9lUpNGPE+OfP/A+q/HfGTbl1LOZUi23SVLWFgLmO/ORYlWZWooR1xWDI7qm8hGt19J2m9Poi 4wvHEPes2nnAmzVCQl48h/xxzA/PyrMmFPWI2A7/lqHSuEWk2BO9nunDViQ5z9+n9c4MuOaV5nhx y2q4Vup1+mCBzipluor/+szzPPf4e44+lOy5fXD0IML03T2zOQopQMQcU/1exlud9/49pMxJMVWc N7W1eK+7PHVQyQEL9q0OzIyMPtPAICuzfT6sFJ9IQKFky8sshLIqtwHFHPlxVbj0bxG6jvS9wUPp 5U7fda0FKoTECHXc9R9sNYfQcxxIRUP804yYz9UcsSIcoULjiSlN4n4419hKgD+GJqqeMnLkEIVc SKdxmFPhHtVwNude3HxxDns5sgo3DiVcM1pJucWf0wVJ277qKKgC51AL56W81TeOXVOVyRKO02/z gp2X6/oTnT35TvPV0jG5/uiAzj2nkRcPiyo8mn5jM/haxDSFV9ksuoonnA3EBUusbh8dL3LrEf9S 9XSxZAg5ZyaHGzDEp7koHiKnWDcYOd34BBE38zv/uFFKKJ4g978NmKs4smiSC0ZH+gDMPItjPYNy MwrcD/HAFPV+HDM6gSy8oOoRGVrDbWZOwLFbXL4tH+53winhj+NBlgB5ARDhe8QKmtaizwjCXbx1 EeArgnq68xCok9N59ZioEkaVsLP8j1OayVXq8/k6sNuLjWtC8BqHuECE6cqRK2Z7HDHAnFOR9hRi u3y4oNIVVKsw9UniEKWaT+OKVT0u3HoB2CsCdu3n7SSrCIfKqOv0ttABIa1IqkhJeLlMURzxOi+d JMAHKHPcPTsu7Qe0lzJWHaYte0QSu/a+it8bzAy3HO9zT+iyvwWEfZpvT+X7nArfroqcibF9wz4E IBNxfgArOuL99hm1C9tXaGmdZzStbuF7+h69rYiz33/sdp/f4Hr9hlBgkqhz6rqiZuz3h0eUaB33 4YvQrulOskTJ94CnY3DCq64il35/PWWJsJ0OEdfoEguAPvuepV0OkMQLiL0/ueDe91MoSM2yYujs GvJrFK6psU9nBXK6lV57gAjXOhqzOhI40uftA+Tw7bPdvjgNq85zLtMTiMrRAQy0O0a1yB3HMzYI HFLoX0Ha89R5OjfpoOHJ/UujnlPt2FGidLdwgZJ5wm0S+zCGKt9d3qpfvJ8HOZ1xxPh28p0RqBso 4VhESgwypqKAw/AiWxJE1ZGMlCKyLoK6eutPNKIWUbBqJhuEv939zUUuVNddhp9HOuSo1/82joIU gFB11PEcVyse6ENsYjkq+OO+/PnfRBhWuEdPoXQXpfCwuaQDGks52Q0Cz+/sR+obkoauFfW56zkH /kC/f14fjv1BA5F+pI9c507SsHoQsYdQC9EJHa6JOTzqugZK172i5QikfW7rUUMY3FnX+hDcY75J lN9Jf7xquwtvo+Ga3VcODz2tu3WTI4AY9EpMj3GwjPR2kO3ZR1Wdw3/n6nQQz2QfsO+GcBo/k68O QU/dcirCnme/4Ui1osHxftYJyP/LYZYwsP42jES5qzCSu4pNGkj4kdKM2wpA0d+wSEErCXOnZzb3 K+mMRk/n2mm60nEQrfVH9zGT9Yra9O0Oakws+UnY1Bbx6Mi2UqS7cA4WmeWsJ62sv5Pc9eoXbsen TTozXpd1hU/Uv451ed3LeUuNb6TkXrYDJmGgJBa93nGcpF4pasoBUeq/WZgzTzlj1ffCn8n8wAeG yC6A4RYnrT2d/R5xVP2f/RKyuPG8+vJ9WVYx66udeDMF3rWcFgnV1SM6+852EAqMHLXnxlLn+stk rry/1OLUuXLcooM5RLCHlpmd09nDM88wMH1PHJc5h0t8thObHXd0DGg4z9cYFHLVNcRw3/deg9xs AjaHmn1WhJ/+xPhcB6ejC6XLlC6fKaL5zpgrI8zyYo9INAF+ja4YGr7EnJ0nSFlmASe7K1U24DB3 HvHzHe7j+nH01cKKCBlwpKYxDi3kz6m2BNOqfvvZtV10uY72kTDS1qDrC2PoVRddjrLX8ISPfmM9 AW/sP4XWv/Du6Wq8hClj4GR1897cK/ccboMQPoai42nrs/8HJunEcnLEzKN+6kK2bial4AuqOJQx zU8mV60UihsVCci/zR7Sg9M2YNHf7snxnl1rMNCHu7NAqJppBltTsXNZDK69avtsOo6v/vIvvd5/ XFX/l284pqoOg8wC4bWgvlep9K9U1X+7Sv+02j0nLRRb137bWo/9whUGegoMYnHpBg7AWaspEqUp kWRj6fOsNgz+cAaAHzXxS2+Q99ng0teJyC74lNZW0Wt+9h/35q48q3qKSD6HzeO7phCv/SYFYj0S +sZZ5WvUWbB3tM5vNa48OfkpWl/9dzcFdBvA1nW/0FmxrCWUnS8xUyJc5zgdDSmzwdQ7EJExgD1W rrPDEaZ8HL9r1OMb13AYY208X2d6J1UqXpXWlWk376FrxJjq8+TVbkf7PZSsYmOzrQzafUomWU3t R/pNUSI03cTZB6m0ks+pDvPC9HYyqx4DWj5GnSruocKhUOq361k/hb2CwUw6dLm7Z7hRob1eHWnO zCsWpP+RAudChMiuhfD8zXHsuzU0BWrnHK5y1WXWNYcTebCJ7grOzvxgC3sQ62e4fg1JDl3ivgG1 tVHcpfS+OZOq9LJSLNZWc/qLKHvQnPzItVk98MiXOsOhDXFV/RFTgjtq2JcTJR39L4mVkMTZoMgm LLREAf3D1xEuP3/+BWRmk0nOBKU6WiU4DMGJVxE9U0h6SQUORRm5oeWoyk5XlysvUiOjONli1Vkk zi3v9X4S1tkiqFyaxhZ9RaaEaCGJiqjJliPLPZHiT8z1mLw+vWCqDve3GgcORzbsomLGg7MjQoJb PsU15FBwD2roPuDOaHaNdcii+Sksykt0R/I6hgqYYkgH8YDhnTPy0g6eW422tJpEWiGqrfrwIlv0 kIQqSOoE16gp7JGNu4maUatakYcU6UZTyZsgBQdVUSnNsT7hKuRr2qpHqBU3ZxsQMEFD7Eh6vYcM mty/r+Le8HlZX6AlD6dkZKajoZqOcbMRNZXTWtFWqrN4nkVvIbgaIZEuIA2u6eVHSa46SOIJeAbk 1N27zM4HeyK136NEaA8gfQkFSaxuLwAJP4EXOHvEjooqKSEwTc0unzFvV9GcoF/AlyjmvqqOnBbd 0CkKLyoIGbVnutvDay15DV/tugrWqLfozqeAXycQRo2gH/vfqzlnN+9BRA/S4R4qsIH8dAExSfet wl1kO3TUmHr3qs2JSKxjTfhoTL+t10Lxj3RSWqfLzEVOqpE48bxNwgWN9XUDA9uN6naVm4BLVYGr eUYrGm67DY70AcKUwxeQvNwVkFDLx3k7xX4ct1xBeNTZuaUYIFaUFI4WPiMxayU86IuvmsoIfJBY edder2BnA5CfAA0ByuNedK9Z85kb73d27t395jdy8tfv9pPU0IqE3Wu/MM4zncApBjqhl1KNXnGe YzvGV1QBLBcuR+R7nfQD3XuPodoAO+v0TUjwjaKQEwm+HNKH411N15GJ8dRKZ5kuzlMgLEReLpHx C8x11G8e/9++qWcENaxT6XT4r5Ng2DG715v3gXHtKFwiyRLw3KC58B4tHOGZQLIPvGITK7A+KpMl tnuyoz8zDDfepI2/JsTQ4ISbA9l+niw4NN5niZKxN7thF05XWy03xomhqUiIXbAeqKK5hn981J0a d0CB+MFAgd2Rpo5kTcXfG6ez/fQY3neSQCB8n1tJJM16oCEj4vN345gpUNkOj/XGg0vrXZ3V+hGV feHnTqFCpUzdJy5Z43veXkgsrr//mXBQMomW+1S/6htRDplzoFT4+VUkfItPrzl0b0x4rdqpclMg p9aztnfpq39JXGcTkFNosGXQWfN+0iR8SAvmGdLl1TrShgTGQv33GPIxv5OuOVTTsU9dGIdr1DPU 8847T5BCmdiM9Mal+Lv5qM06kWwURuf5LvjsfE7Oc4qcLI++XjDY0oWHykwhIjc3jZiR6/256+i7 51v3kWvG7mh8X2oxQ4ZhRMV9t+tWGiylVCFBT12L5M3P56phVjPv4z54mYMRrsKMo92/XY6qOjFr x2B0IcagwOeuXjEMq5T94hCyxGcTpjV03IlFyp+05G08VCFN+KRcOXiil4FB1UvwuZMi79S7FAC4 /MC9hNzqfG/kX9mE4muokXBlrSTnrF/bHnOt268OUUnu0Z22+/L/y9rTIP6vygQfB2ZZ2GMbVQm3 RGzdkCIxUoo0crgGeALNOnMnRs7dnnWsw3W1qlDYcuFhm4th7N/Bm6hIYCiR+Hv2PtwfctYAnVXJ CfhIXNCaJcikpm2UsKG3KVaq6DtddaQm1ulWn0OOE7i6kVA10Sm57l9DF+lme0i+Gh403af3mWA0 gtx15IWJp0kFp7Jp3SsVyaBV+vft+vcK1CTpqs71HOGrO9H3z//7X1TpX64xGJHagjqF3vmZxg4z D+bOOmrVu0ou4zOQTGc8mUmu/aFdmyXemV2SAmVIEaeHSSBzx4Tn+DfUK4xZpNfx5ZJfgycRcINd IM87CCz5nLLNkN66EAevSrGkwtEfhvl1ceyrbtQ0cvJxew+DyvgcN4pA0sh68IUXnlqnWPrqp/yT 0pvD7vO8jT0lWtFpNnQlb6l6OrpQhK4YkLg6HdJa7FtrDeH7NmDtQxp+Dr72XvnaX6/3VXULem9L 1a67271xtfs8vJsCh3P0gYQHKdKt8yygE+eDS7Gx48RXBCYgBRqRqq2jE3JFk4POVIuKRPpPXa9i 33cdnDqZL+Wz1llDMwaf54Iz+exEH9n4lRMldNx9gGeZhvKOPUmpOUfKUTdc0ZmZHLmPoAnSB7OR 1nC7j/SSOw9n4ri3WUPX8+pRN82zfPPflyWnYzi1a42FfDX0x+ZKxMVJOb++0x96gn4Oseonxq9v wAJwN11zHZFV9f9n7E9adVuXp28o4wjasG5YYC2KNgRLRFQQFQQVtSGCRdOe+G1FLLHC4rVsWDRU 1LDxnr3mlRm/GHOfB57/OXuvNed9j3EVmRGRERHtea+EPQE+uAWmXiV7Ung7p7Bv0iVWFKArTR44 HPqGfBvF5D99v5xqX0jVgfd6o34bZEWhx86oDZ5VHPAtRo1/ApHC8TbtIJNeMt7oubWna9s8EMej MIAjcDFdMVQh/lQRgMEki/JYWqCKHUCKahDiKQqi6fmdoLg+e9u1L68tP1FTTF5chztwGnIfQ1B5 nuv3GCC6vy7wEk3bWyaUEaM7xBYH+Uxl5fXX3cQOYSWIb9Mg4PDHKcngQgtTfP3dd4I0Rd3v2qAg KSDINCeR4tAHusUdkCfi70WpBQyEucLSCkDMJ/rOMMFPZDB7rzHpmgMdQtjgPHvTsyLRt8JB+bqt C8QCO1JNDwA4UPBSRKk/IhQbKXzf2SCssknNRrs+4I3ZEfW6Vl4XpCte+Aus+RKHJLlEdPalln/P gzCC6hwc1c7f2/AqHNx7MWzPx9S5UkwC9dDbWK7nqEGn6ymBRvMZpcwuiK9LlUqkZ7pYZ3sebhtO KIvW13uep0v9rfJujBwkpghOsSL0y/EsP6RYfva3LrrR3eupe4NqX8AJD4cy2NgBFhdKmkQcKTpO 0oZExved3Lpdw+LBgT2ZkcVDSVYAKqkMoGZMrwAE+xY8GcD9kAnYdRDZCOALe7Q/4rcYQJninLfd B69Qbw8L+/QJCbXdCGVa8YMDSVsU35zhcygPCHCzU99UiLlF6p7hQRhAXTHVpu7DCIz8tEtnTSpJ vSWuL3f6HxGEbsIWDcNlrK0iqpuJke8wUJ9zTCCCUXFMfACmeh4J5MearyFdEp1mfSCQCfqj1vER vZCQYPePmbWUYrCGpGRfqOLIm/hHfhfnyeU54mk2XqAKO9y4xDdRM2ygpAohNaYK6hZI9PTyjnpw u/25CEhm10eYaHh76nOuFYfLwXs1wfkpYPX1JiXZ8472PHeHDbhbduLtDCBPT8H5fsJS14Bz3IMo O2F394Ees5sYOsBqweA9iQZUZCKzj/Aygi2sQYlwFor7M/FqZg8hpmOx8BPQIEH7hoKUzHfwP/1G SWxBI/kpoN5toOK7uKZ75Yhn3hPfKW9THZG0cDiv9JTnvnOKW8nEgvDXOD9CLAM5Ipoi+GuDT3OI FP72X3lYwmrq4g2GG9sfFQOftyp9/IsJrR7ItJ7PGSYO3R0PfvtbUfyQ+UJZwABnEeYBnkIiveLg K2/8J876DiBgyq0hZchw/5LI9uf33l7rD35gY7+ZzpdnoNH+ZfSfXPsSC6M9xoPp130xU475LV9h bEhQULTASWmK2itFHCqIsOrgIjv2pbseudfuaj9NJ/YQvw6X1onw/I6Xp9EZYlMIeRtKcYfR99CF oBPvTpR/DZreCpydzHS4H3cyW8Ka5A7LbMflY3Lkd+8zN/KzL3NA6YpZr6j9ivoYkxHyqsJEWBgT tFeNMrGeFGZZU+9n8k7fKK5DmJsMUrrscoVGGKQO5sc9J/EuLsIsxsovV9qTjn7Dvi+nP4DFfJvT 9Jy1H3FKDN86E1iNTAeJvTLFAjJBS59fkij/wr/ss+b2Poz70wOmTw60pA2MCGqAVuNT3XnNZhzJ uQJOlzi742xp6uM4aWKfY7sucTEOUcnZnMNj/pa1Sjw9ccYrXRY0EVdXoZqsSb3qDF8+V2iW2IdC p+D6LQcHqgRYkgGW0BreoiGSLdZ31BT67FJnnSPnT/5vpflf3v4ohzIzqW7gpEutxp/P+W+amf/C jP9lZKcm5MFoqIf/u2cwafY6ntLdr/NZjYNBqQRx1Tvo01v6+y7hvLKXNyHRs6Bn7sNvBoNQg2Mt DZkOJDOcdajEG+bDpgn7fvMgQ55518gu75pvE56m8TlpX/UOSyz0Dp+6YsowDJdjF4go/ZybjxnO +S7k/D6Lr26u5DomQj0xrw/Qcj/pX1b9NelVYK138MlR215jieR3Ws+1125gZ39xz95cWU9yo/yu XQfkeItPf8t7hFPaKF2DzHwYt/EZHnGxLcm14A9exWVVszbvJsqwoZ1nPtK3Zyh9M7/vvgtJ8+pM T3wEWK9Q32hVqnIXT9lXPmlHc57v7hddUb8pnNk+G3yS/75SkZvkew+KJ0asybRSBabxDLYYVDGi vF8BcoEKr75PRHiu8Z+1Z5Fa4ZtIkp8TMY8YZHcZ/88a5A6IaRRJ91NTHf2kCHIis0td/48B0Jhi Et8H8y6UHweDff1dN+q3VGxfJmMut3Kg/T0Pk2j36voRpLLz03YdyQnE6w5yhQDvJPOdoeFoJSIc NS3U+jplu4QtDMi0KNZXIXziyYz58Olnyf2NJnE55MXh2NJcB4XXSUIw1ZcN8BxQk6I091FJk4u9 UGGK63UKZXFRc4razc52f8zCLpw3zHGQLpSIC1HOB+V1mxW4g1PB4nBCXm9PLH5LooOcvLZweJ1d dkRbcgzvdWqbQ2y4hMprEb1JMp5rSPT+XAhwfRRxSdz+FW07hdL4KcqmuFDva90H1DHSaq5ODvsc nYQaPbgHV1HzEOpG0DtJka94KQHxWwPV/CUWMOyTdFjO/SYQ1RDU6NLu6hCrEMl7BnDeSMAAWszN 7iUa75qoJZQnYn2CGPAF7HqU8AyPvk0VRADooQFg9jcBynV28AE2v7z0BmoKlpnEHj/AIDfp5CzL 0Wpr1eoWg45nkwXjq4RnF2Nj3NtMDhOYiVN3oDPD0XS0AT5ngrCecBUywFntLQxsJ9QrxLv3sItD aRIk37+HJDorcNrkuH2jmAUO5+Tdxg5WQvfZ4qCLBMSpZ2pFKxAztD323SznZ0/S5pIDlMahGFT7 O4AZOxt7WnQ1OZc77sGZG9PtWs8IRXStEZ2zl1N8T/8sazyVIY45Ma1ttVAiibH1X2dAuMUkiPvn adt1VW9REzfn992KSCYP1Ma97b8nnWuF8OVGZzjvdYYGvv+TCVYGmWJz4J1yvlKBRSJQY+87UBNR x2vIdBKQyzg0VD/LnPM577RM5MnhRk4HSgfTG90s3L3lNPQAmKjq2tvvg1O12EdU4Eh5CzGz021O t470JQgUSUTvng3y+E+qH4/5Jd3WRhaE8tgagexGcpEEQHken6G267Xif34pu5PA8w6Wq/X53W0x iSCi+MHJs58cQPgahqBeABhAdiW4TwkMlALxulraXBcLzl+DS1mLTvb8JhjYNZ5POuUFmBl6bs7h g9gIJaosDM9dhJS0poPAmEbMPZOPeZ9pVKi0BaxP4sQCN+g49+1DFNN79jlbbpc4f+s+fE0cDC7i c8bi8TpDaQSTiUnsOO50D7tWU0pfFz0pXKW/U6xcBHbzgXkMrEXPRM92khAejD2NYDhSmfz8UkAE iYyw7v2NCpUkm5/zmIfb8j4yEGNMDhfhiNP9SyD0oHX/17MNQRVKxbbj1LvGfowEXiH5SYuB5BrG erMPMLjqpYtzevN7EbAPjm4+W/cg7q63Ndtxd5Gja9g7a4JXxPsOKVMo/JRd13zOv02EHD0Jp06w 4IIl3HmTug50One0vpACx58z9iZ0VtGgtBH3GjqFkac7/1fbkf2mGOFgePx+FVzzN8xzcFDY8Q5+ c6LPs/z2Rq/46uIKhJe1BEYt8vytG/j01i/9cBt9ur3OKxz8q/9NPsYgqEtTEBLf55s8KWVn8eb9 m7WSzZgtydpS5Ex40Mtf0B3qknlOvpeDCZQ+z/COBjtGfg098zXh0i98kj6StXX25HVTJMGKER/R x509ac8EtUkK1naCb+ZQ3/PqxW6EiMJJHDeYX5X+rrsxnuGiMjaaf/7nfjPiHCeF4fLkH8yJMYWq 11XEqflw8gMVHN9xLsN0xzEUE2V3XZeDNYP36E6oy34qjb2uOyxUU2q6kGsiMkUHMIfjhsF/MW+0 nKifs/Gttwjp98FRV235L/6Z/82M/ndvyvJgF5qJW44kdIWx0IM5/Xc8/jdOtfSggcuW/Wisy9/9 csXAmVSVw9UOF9svntSlzuTPR8xGcmWuOL1wZCitaBx4banENJOuy1T7v/XBqSM0iKt3V2Ij/q0z vNogm1fDdO/lhQPa9dm9mLn/RgqyPwfqU9+UGd7bUEjE+pv1V01cuX/ONTYUdvKRcCfCpoT4hsfV bFC4fin1Rse8Y/OAOeC5/1wmi/DIfQ7+370AKQlhNJq8/HpWmqMd6bmxuyPK9A5i6NN0rPVdbRDB 8AwnarWWDOS5BpJ3jWbCjgBHzYEglc/owonS4AkNfd6EInfu2DeJ63I//uCHHlNO6Qw6/zwj/S3M mToU/alxjfi5PzmWN70pdUazalW1e2i6GU72IgLefX5BRhw74l1LNKyWLCVjH0a+4TkDoq7+6slT UG/42akk2Xfk7ieI/6fkF80UDe5NihTqAAza6OQTot+fQRd3HtDQ/CPjUNhlk6N+01GIpUTXSv6+ lBnyfdhOrsIJnxu7TY4hy+FZLwDZjqsUouxX7H3RuRM8CXa4TsIShN9o70EA6m1oB8FMarI86dRF ES6///cUNN14tgsOLtDEHo4kSXqMiUixiAFiKhZo5PtMUvbyh7SUhgX6Oz4kxZwHnvKg+1mqRITg p5DcEZC95Aij5cw3UOb8VbBpFW8u7uYTTsA2FcLcSDMBNRiZpgAjyFVUQX5wHJKPo8yOIG10/gQA kbGKLkWZMbZKIN70eQcqrlbbeTdKF+Wp/CUXFExW8RAChcp8x5NqiTSEogGhXiPBrFd8cs9fP8Qk Car3vXMFNw3qvb+Xw4Gk7rPu4y7+ni3XgdTxPp7J9ku4zI0Sfs4kbXd3ctdhuD0d0VXKiQ3Q5mS9 Ixnmnr/p2kxF/5DwKeiZ3aBlXFJRJZzBnPTH4SQYEpW95Nj4grdNiKZFZtPomLFgp/OMHTtSUPk1 QTsh4EwBOpESFOGYv+qv7+nPZvG4zRVHqQTHBDIYFop20HaTnPGMDFGuMyVKaVAE3yKNhWkVgyQu Jtc4qWGiL3Zjw3V0k/DfCnHXwT/36TuBKwQ6roBigCC4cC67/ydgwNCzagtKtfeepp7w5nU49byA WFutLK6gE5Yc4RlYdHXZIuGzkapWDGGo/FaWnfBI63Un2ikJ+iWg9DcAaQOH2aH+JCu41jBMNDsG KGvdpPkbLhHwztyiVecBudNniiKy3z3xFc+XgJ5RfJMuEo0MgBQt9YS1CWB6nt7QhWC9NayPH4AC HJuPdJkfswuD+NnhyikkYxs4enAN5W/fKTFaYH4PJD0R0yKyeiohYsRxAD3QJfpf13XCiE6qAHr6 PMIwcY+99rgGe/G773Vq+TsslTjMDInOjBXd+Z3O+jiHEQzvqlsBpJvtDAuaVVzEkxhwccrLqoEI JhXYfYICojNjgrYjBzgDBTTn3u3fAc9ZcL/zR42egr1GGpKfmysZoEMwgNx0piQT/i7l/XbWNEaW 0x7Lu7iuleuWBMPWgcd5PgeLLxFgENvGE9NP/+qZvka0awGqOVcvFsYne88LCXoacJizj2logAS+ g37zOyl1APvNVbrxvB6dTJXpHUTbqV+ub++nzmAX1T3IQlTQ13ndCMUjjkcB4dPTeJDAc6mw1ze3 cXi9uSznOS/wzfI5hXPolj3of4xULmHkX0aSvkQ1U9+CSm3+nnGD+BoJayP5xkVg/iEWyjP0igQm 6y3tev51sP4asW/17nuuv4N7iJuKam7yfG5C8+agzutRZwBDBUtryFlhK+C2M6TN6IPXYqRnY7gT /rxe66LxbMxxOMZT3/TOdo/6jGpusRXhni9v1ZMfvyPSW616CXshVkO7dlby8xpi/aVPaMNZW3wC oporifU1D2hppekGz+OpM81MZwtC+J4UpLgtYbv0wSX3muqn39bBoCPY/ucZanjNeIArzwFjsjXT g/erJEVkL3Tx6cvKuZ4lqxu/Lv4VV6E1x37Cf87pyQRsSnNQrDPVuunP8zSfIV978wre0kZB6128 tUk38VDgv+y5++MYvvEZlxrnCIvVEaqdfaDaD2+zsafGEd0zxJwyl/hjcAWqB89HP/iV+jGzBXBT VR87RekOYxlqzDvMJcDy79j/7Z80yZQb6yniaDzN81mllz8Y0zk3b/KafxnO7U6qOQyUqSKA74m5 2H+u4//jzPy/Jmq8Y8hwkq/jtwp4vD8/xv+GGf0XNfMvv8JbVSNNx44dTCc571uq7IN+qZkUe1tQ uxUNjVlVw1jWdSYedP7nLqqt4eRoWzKXatpZ1gaJfRlPBtZB3RP9mh61u+EI7J0GqD54whIiKo0I QkgcZrLn05pr4WCmnvs066yL0zNPcPUE2KOeHiTx3VRONAl+zywh5tSB1fnUaF/GKEZjnGffi9aU YJhvYPiCnbMX32vHfUMpeH9McSTMwnCtUxuGLEB/v4yJNF/JcIr+PBMnjLXpGfD2dkQ3YMDURVxs AyoBvH9fTonNQhJr5ywMY++X6TAXu/C6w/4afkwtnyG1tmHDxXxPycP7wUSXCN/GmlrPYPHEOXO1 vNCLVdOrWd/xDgsNotnGf/5zbhow0rZOmB3ifZCJXmnqQH1K5gD4vB/hHrt6MEFnYzCa/EgC9uah OP+Yh9un4nP5Ln24icSr6SrKcwIzD3zSes6Q8j8SWHTECL4xf5e242bDQC7QQfxWTNchbPolHXGt DJy+X1o6wnERWSiUxhhs/dMdYgoIC0MEJ8alTqj5XirpQuNht6SBRkZA+O4CcD4Lues268lpk315 3riaNx5xE35vk9MmlGYmnJSEbqG7gMT4sMch5gccYlLnAlPzMZGuU1wRND1P5DNdtA6Ak8Lbt0v3 6xrXC4sTeRUkhaqYqRWcNKkr6bjvCqjdXmQz4Z3F1StuYMfYuPKK1MBPEasgNZMy9JpUvYQG07WD 50xO6ZVozl9jmBLkneqb3sCnN272J7Z45mv+ikqLVoJl4cSNQ4OTD291hAW+jYHpDNAv4gxDdP1b RM9kjGm2+w2IpucjNVDjuKJou3c2ufMFDicIfB2igOJiORAynWiS0Pzz/3umDmTpebq6IhgjqTTn riOZ5i0Iu9Oh4GzRcVe9xEPCq3qB53Nu/Yvg3szrxtkkKuvcC7H7BmlZlNVb+DxT7zNhAGrVKnjn dbLtPusfgOSK/Ujw4AR8PMOCcHo7X4TjfAgrDPvVy0X6NmFUQ26BrGp9vIWHioEdLUzW2LreAcop DixIm4iA/lcENI+Dbo/fmhBPeAHRPPBBpJaeOl0BvaiAxo4hCIqiLjGi3qtPIVTlPZct/A+xs/f8 QNfUHFyp5hPfQ3DfqQhMac0uEsznPLcreMJwoyIVqY8z+lfgIO+ugfqXgZeZ4nDghEhdPWy+nI27 64FL3UPd0T1fW6R0JRV09s2tcTSljqHVwW7qKexWqQJZnLjFegLy4wwL6U2hYccAHszbhJrRyeHc zUDqXtl8dyEh+XkCLMK6T5+39RoOjCS2WWB1pu3Q3ecUinhmghRgWG5R7GLRNAlnhAlICXneAWFC UPqN/YDf3n1wc9E29I7bPY1GdynxgvZTnmPkLEpnSoqGHO/3ighURCcKEu+GRmqa/NlIJAgdywfv gr3PjMD1FIIg/YTpjOIKoohq3OkxfYxYdYMJf9a9gR95kyouveMgpvruVyGRGCSuyS3G9X25xIQ+ JdsWfvz8Q0w8fEVJryj9xcUE/n89Le1Gl3717irxqynE6k6iWxjs2mfQvv5217uUhuLnaw2u61fs QPBsKEXya9/sQaHNgyZZfEUWUmK5U9+rQqhBw6uRCuGDJwcm7ck00OOEDieXKrb5CKPE93fGrafw zWjcwXHcPu+/E3Fa5+j59vDkN/8xQGtT3L09UOuxG5bK4IXwbrliz+8ztPdhA8YnTMRlDDj9qu1c zNhWqX+VTIQ+SXZG1VOQvXmB+Up7iZ6rpIt5hj8tp4XQ/yUXc+GQ1He3t24A0e/9yHZD59eb0Iuo JOOa5wNekxxjLT1HNNDeONHFNCbcE3T0SwJj3uPcIW2eiBCiu8KF4sG3LnFDuqWZ6urn6F/fevm6 BL7c4xVavUPdLfZcBQ/NtXCHx/ptv+4mEb6agpq6V877+b7zKWXlK/3o7pNMmqEqkcSPf4YNr6Mk 9jnHRs9GrNRhOLVFEZxK7cocIl9WksU7JnYTPm9iQdaahgpAh3tpjoOEjUx0Ka8gOM+OTEv3ErY6 drqgIlfsCzbdyCH46ME0H47TqWBYovmrFFEOGfvjzH0NpLZAlzGdPaDrZwgi8dk7wMCe9y7YwCNi K3y1qolhsnJsjdKwsjaw6HNmXx5F0Aur3FFG7PRn76vqE1Cj8PPb/n8z83+YM5Bx738NmSu2Xu1N nPsDI/23PP739Dt3TqrSdV0mD+fvlIW7u642oAkCVflylzSxq1X4rubXahNV5qpYyHJg9QD2+WXd M4HhkpgfXYc9iI2SFNnF2FNHq2CwteP99MP5XjdgdNuGjEfmH/yUXDlUmVyk0FBxmXRqSqqM5u+w ViiQReGzqk6srUCsEfw1lq5hY9Ej3HwMKH56IX/yL++9fpU9XBsy58sGV8ldXM4Sscm31vI9RxSD cty3exlC3o7di0e67CfrtSiFmNU8hjoSTDLPAlbl3Fq6vZHv/SOG92CqCuGCOqkjgvSAW7s4zhBi 1wSKEh29YcfReD/ye/fBmQZOs53gN8PO5YIUn7uOke3cK1W791BJuReYdn4bY5zz4zVnQSPhdcQu Yf18mMf5mHlcHUGuTUH2dL6Fizld3u2axvprFTxYk7RF/31wbeMRWYl6piTK7eGr49J/U3hEVZGw 70uzwP1+sifbd8U/0hlVcXEyGe9SqjnK7b9AEccX3tGsN8psHcJnsoU23yg/Bc8oqOKBdyow448d BIQg5myoAXGbqhloDDZhNGcazkjU3cVL4pYBmFGT4qH87zmBmu4m2fgrDrRbzIY8x0mm/wFNTW4m P8/odStp0z4TooQEkl4nRZTMuYsWTiDWNHeMwYgd4xwjRVSqgQ5AsTQ/Zh9RgioB1CaUDYSaYc9R M6xVfHg1khoWex9X3+UoJfCocyEgaQ8ljIDBop5wA2JpyRFHAughKGCpRFVdx/l5bzRKk0R7AXpP IfI6RYJwZP0WXzLfMaShz4loDbtKse909zM5zrB+yWLjrhA2dA1kSrdbkTAYGj6hgIwaeW4ZZpq7 KdF4z+/RgFibpu/N7vbYqE19G+v5OQX8hsJyPoq2LPoMd9133PgcUr4LnA3E1Q+BwQNjbz2S54Xx Z15QeABYnJ/kmfPzXWLGWoDxeyaSw9DbXHcnA3bIpaJ/f1+XnzFxSu+7CGJY1Yjwt7H4umvvtPEU yPgZJLnRs4+zwut8qGnum/ocULrxfVuoknUt0dOZZMLitqhwTKKHQ4Doveeu2+uXu6HWZ/uZTL8N 4AO4SEFUu4BeTCN4pkaqz0wR6r3DQxTbTeJRFUFwOKnqtwSVkgIVjs2UHTInZvIr0peFxgJy9a/3 dePjfoaABvdKuB4WMFqYhgQ7Q/3PsA9zrocFI2iA9Fapj4rTJIrOMxIR8Gn0ILUb1PTdA6xPq79D 804BknnAJYA9IOdV7lAdcoQGbL7dNgacNs/68Y7hZq8w/SIW+SsaMskwhzMAOxPdKjc7wiu2pDNr P3/hGv0ec30TgewmDXjEKhL2i3QvNZh5nyE37267NWyjhCNUKZH1lJtDlgmKYVF9kndRM6v15T+p LVlncV1sTwGzb/Q4y2JNdWMRsL3v8DqKxLlhPhmCvnDrK2mERxGrevuhF1dmAd2Vkn2FUXomROr3 SScwu3vAi/6k07bP+zcIVae47pnkdH8UDYmdGEkxILvEjkCG2MJtJMF3WcfaMiVzDe0+P7ZXlrun E2Jkrr3yRBIAj/B/DTrEXaY5JAkTRorEGENC2XUmE/R7BnpJ6DB/BZWa+RuD7K2W3C7IfbB0hoeb 1bJdosZTDOa2AbT3nMoEKRXy1OiKfYUwt+Z+fo73eMF1l0ojke1g9S8m3x0BpE+E9a17WsjE6r97 LzGYQsDJn3/SA/AEmslxJur1HFj2Heoim5JeiaRT15Wgp3P3QIxy1t5c+wuZCn8mgw4MmuZ9ETel maydv024vvgqx7GnkCCTZAy4+V1fgRi+fYj2QPMdKrrJkuQSq8BLiIj3n/ofpFYhEnkNI3bNyHzU 4gNfAamZtRO44u1n8/IJgo65pYDNUELDxgu/BMpzUqqYUfKwWGJqBzSRcqP4viSkvgPIPymrNGzt D9OnOR1Rmvp4icJusrKDGzFjk+L0WMIC7yBEijdbshScM95iDXaXfLkWOoOvk+TU98IVkD/MA24a SNuNW2brh7NHrk+PWAz4E+Yu9DPIjiIboUjmj17AM/OLf3liZP4x69CUnpdxbnLP51FrfQxZChAq fTjpDwpDB5HRi6ddIaUjvYVcHu9Qh3FInQVLxqE1sAUz/ZSGE7qYlbwGiF9uxNtIZ/5GWtmbxrwG vkQrWfGM/GXCYLCF0NT1RNygznrO97B7wet2u/r8qPUMuDcgiiZsDJItSvX7R1joHKgeYK9fs7V/ /t//w8z8T03rpfa82xE7T/HXTXlG0r9CM/9FzfwruBuhRB9H3cvZncyTvWLIa5T1mjdQBloyT/ef E97qTLHwTTjnvICsv9kYzs9UvA4v5eh6OQlIyJAmj3j31z63m6kCCaPTxTldbp/94VuPtO6cPsHv Cbac/H3uFqeAn12Az5vyxdmhW/W9JbQDsuAObEoEBZ9zkdgzZOsHMw9TroFVw7wCYXQLoZIKtn2+ hQsWquQLV/1q0sBMGAfn+1YMml4x8HYvFyhmfGpvQzfcuM/BVDo9uByd/gPcYHLhT53x56MLOWV9 GA1RhdvruwFOyjWx+OLaPtjMa4x762nCKq5Tdna2zD2m+/irb2TclIxDCVHaCdWaKYrSXI+HDzza u6gL/xZ6mf3vrQ+uXkElUYAYhFcfIRhMu2fhXxzj7hmuQce+B2L4GhJc2hl5ccnXbNPY9/mT11UM 8grPi7TU+XvZABcPT24mew49CeGrTvpImGsMscKkJnHvi978Q5MxNkPL5wB9SPp5hpyj3iZbh4zZ tvq/ADdFYPOCN5esu0F1lwj+F6ccXA4r10msFPcLnQYWUatOIM5xZNtA3pTWrP287sir2lwlURV2 zvhuWjxGis9e0MJfcevKbfdHBKzrzus1jJERe+XCixGBK84XTtdOiIMyAsr4jvKQaJEZ9ykbXLO4 Vd4ucEl0c0hdXiz+aLz358zQU1e/sSlEyw9pkyATR2u9ByoIYYaibfRd0DqFJy4BO1fUSuILYTGs UqDlheXiCDvQ4LbylYTC13FyuxOww/WUt/4S+RTTLgBUt+NwjgwNeog0ct2/kPnXbZaEKC2OT1j0 zzSXCnYzJB/wJiM3COY05EbmmSoQ2EW5j5jnAvuOZg72vn2A6CjJP0j0KzP5WXeCwr5FbwkaGSyW 7XLm852Vk5SncPMlCPUJrsZbMTRwutVWZkikh8YdRFIMKAX064G0i+5q//ufazHZlyK6RHSTppzT xSxv9nLEJ9Eu7csLd73TsS5NglcT0wYR3/NOGpCu6IgaHCDTSzarRiJe1/cEMITnUQec7Fc8Qh5e KqRRqwBb+oghG+UCQgMN+HH+9K5HvQAfdn7eUYA5HR4OI3alGxRpEC2x5JLJVHP/5mSua94KqVAp uNjrlJKEeg2WkZjnDtcmqmlPZDXC4OlghNrAM7j34HGa9d6xORv/EXnpW38SaPI24rlWeqzsITSl ClzH0ozBwKxZFQCKA2igYb1LYHS6mFMUNERiCv2LuEdVRIpmL3TOL89wjpDXELehT2jiQ69EIa3E ldvPhcDZ6bTKIlWmVENsae5B5lM0gvKBXd8phy20BFY35vk4lb4mBJ5CJKTwKTrJiKB+h8eJ8Ntr UJUyagIA1erCQ25iLa7y532v2USI+o0oTSkcr2LYEsgallIpBAv5HZ4BTkxaevGUmxIA+1Oq7uME Ir4gqsi9S4/IBIVfPSWmCXKSWiDXuVsfJ6nQvNyX29fCgI4YLnb73m98Pxpcul0cKzlWe+1ITemH VGU5NMwY57Y4rjXlYsK96OIsJDy/Wt/teD5CBlKfSXhzyJ0pQp4Uqvtv9I77/91BKsG9uoWGjt72 1jQkPmCxBBGELiQIrSmdxJONgxHitGPXU6QcIn6ppIhkt4vP2pswUg0IP0k4JeLBsQf3gG8g5GqD yzo4ZsMYj0jZBqHJxiINwo6BfaiKbBk6kT0Ev++5KaYoWqKgQWpMxxiJ3NR5OCT6rePkaIgzTo9E PQTh1LV09yndMZv01XY4C2Ktp0E20aCBXBfcbS2mfBlZRPLB2fE6GL12vaJAsLrQyXj+zQcyyx5m WolUmRq0zFYwQcgocNl8nmoCx1uX3/5245Ca5kveEncVn2OGRvhnGk6QzmSCUeNVq0Jde2/Pv0T8 xJ/5M+OwewiqcliCT/qstK2j3u/cX2xN9iL+MDuZil3R3Zm4rgDD9Fk7ExwhiMyR9+ABJrb3URko ECRDExqdHFCTh/0IPYRs98UeW+INJQe7vFeDKdOfn6xrZpUc4zYB2FyTxD1jfirH+RwJTL6nsFcK neuwW+Kq7KG4sVn/ZvNkdnaeIgQKl8V1N/cM6EwNECSfbUdLrfvn5+d88+PM9v0kqwvxFupv8MQ2 4ezsWKswFnJFHygnbQo2y8PthJ2VJGT7POccBm2WEj8iPc1vhj+UfKCH12r+yZfPegcurkic+M2f YbNloPC/npn/Ra6IpmMx3mICXOXB//6rM/qPGLhrIQ8283m5BBNssKYUYkcbe38NPnJtJoLEQvr9 4/cgsQ8v44PN6quGuiedKP1RD6dhqB98vM8zhVBFbKzAL/Os5N7+iCd/SYtLjqYbwQkNdAQDyVVq XrUqf3hDDbilE7d6kHrdtEDgApR10rqDzdzrH27Gv3FPiWloU8FPwkee7YrkEa559vvzL07Q77sx 7MOvtKkUuP7gh2mkZ1AbXfyD5d13v58UbjyWhKMQy5zGXG+S7SQle/gPluiSrn40JG5GnuIT1A4M UviEDGjHADY22K/7aFy4TqH0gDuw0TSrW4W3NaJ3IG4nDPlgaBv3TFw2bWTOjtX8otEYxMtVuG0d nq/puej5q/QLc7BGl06w8W6tz9vD9u8gj34SEF3MZAIXUoyJCJIsGpf2itqvq/mfdDl3zdE4eWHC ycjg+A5ODegsA8nyAI+faSntRH73100hdaRUtTH1y8/PY6buqAX/QZNsBplLAn2Gybz3UOK4Vm4E Fc6iRpB4sJmc4kD8UrA7Gk4d6D2CCgH5v4UPdCByA2sUUmSb4CgC5oOUaVu5Rc2kIPUKoXsB78/f x8T82da6wuZ0HmIX8KnRIhQjpU+ojNzNXFtnHzGMKjl2Kf+H7DHBHpkCgAIQD0QOGgvAbArIpbzE ulRXfy2hoTEcxUWSTM5ptK6LW2ITq30Qu4JYeAehodPoip2aI5ZZ2OL1tsVwWE+ZkDu/V/escemq 9zNJMDK9mC9MQQTse9a6glCG9bSBkl2QtayF+Tg/dhzhBa7ufeWHwP9yoUo5GAs0t9DS4dZ8iZzX jWidFf4tmFYwHOASiSx0wG+OKjbdAU9xKpJd38ig07S5ERGvoNgfn/t8hxBuuLjtZoPjcGi+e4OA UAZaJpoN2hvCc4ydyP3RjGkmHGFIFqJy33IuyJ9hAhHc0chmI1joiNpKRyFPczMnGSwDhq8DZPgM 6aZzHAApBhz0EZtKRDeBAq4g1t1hL8BGccE7rksRSyUAmN9hJ32cGhx5y9D8jwNVE/wRPJlik+Vw 6B1VpU+n4N8cHLnOazLgBBIep2ftM9fRaHkR/wD3FZHCBudiWl+3rtVHpZyxrTpOdaXdDCHnn3QV oJinOMnkYCEFvWuZoic4pkgjsgeEIDq93qlWbKweozkXxTA310b3XrEOLT1wjU7tp2/aPwm04owt Fv5x5LawtjTUpAagTzicYZSk+FdQajvbJGmReMC+Z9INWTea9oqMz32Q/miCis69itQefnoH9Dk1 6roHGN4a0X0UJa5z191agYfCJr4/D4jeiGidRCbX9Jo561L5nX3rsluBaDkS32Hb0XateB0xVJwf G/WEQlwTqe+zNj2/Df5fsFt4RgrvhOpu6uwGE//I+vben24jJRJUjEdIdBxDcBgRRHUp2Gf86t6t y8lJE5iAA0tMAVA6OQJxu87KH1LAEXPZRL5NeFLwKHHF9OducvbXgreevkj7DBe49Rtdl3z6EXK1 USF79JGAkZ6b6aLPPukef0abczfehD1wFojd1x1n5MaydnSr8D5LCZpB3H9iZGtSpOtdOy11JJxU s8Ih56gb7x0O+59yhS3k2olVmXeYY/M+teaAkMaHXJoQd1+znPWd9Qq7elz2HfqpRjEmspNMPibI uhyv+82rVKuXmVcMot3j/zgfwQrUxR2bFLVnPF2hzPrUUgwE+t75arczuzv3CHUQLIJz100VdkG0 N3GWlTj3/EKUFmtx8M4k1CCd9K5zc/YNYe7i/FmETxvuJQcYvfeelrhi85X6ZQfsWnaw/x1ckcJ6 9g4+tIj2noFxccnEHpNTIbxM4RSmmcBvmkiKcDuJK1oi2QNlsAEjoPt7AhszuqceAYcuItgG6YWc cEfVkeWsTn8GjP8VhDPLyJzoYHqviwBFILpupg0n2fq4hdutV/u+bWOk1bubJl5+kL/JVAbmUYfP VhyApLSdPUa663/BGXXdLnXECLD3PlGKHCA08F1T1kz881VzGL6Dw8bsOr2nOE9/C/8hBoq+g0Cg vn6Wplbkg2NTmXWWKSFU3Rmstd6Ugs0B+ytN2oN1eEv9oic35U7i/kUrza7lZXO297cwX5+SxFvD PyeyiW2gJKj93XScSVnUp3qj5gDqvnNcBnAGU6zmb+D9nMjGleubHhJi6P/LzPwL83GiUcXCqXBo XvOPGf03Z+ZfS+/0rtdMWdpYRt4Y+rAEuefSNc6c50y+60qVE6S/64Kt32H8t4f/ygObqoAwvpeL e2YK5ISGZhqmRtoTQXJnvXtzTRvTiXM/C5MO97lHRnYlmy/GbSpXZBglO4YcZDTQRo9v6g/dezRy 84pw15577kFO71XN1PAH5mO4wy7/aaglVDuP5CUGejhW+8xwWh7hmGRpmL2rPoYm/Pk98tP9bjZV /o2zxr5akC3+vam6eow+7vM9mLxUkxYQgVVyHYTjcp/aOXJK3XNxtqchUpKws65Sk2bIPkOAEzoj PZxp9NIXN4Lv0k8yY6J0GrqxuQaxXoOmqj8DoFvP5+ilBvDfZYqHJgx7v9+ZH2Pa1h4a/PO9AYf7 M59lF3zw62yZZUJk7FMNphrb1OvVs92U5Cn14E0l3gNNhlRLb0ME0wlyjH6VSQzbMJgGcq6W4Yt3 IH7kqJj0s67YSOWfju77mzhgu4z2VilndSanS8SwGLyZBSqpkMCDYoMetd3C/RwNDRKs2p9tgPiX pgMb6uX4D3gP/9Qz3fX7NsCe1jKKismc5YJp0q+IlQHyhIGkXfxfsNFAMlHhoaTQ/H2J/xZ2TJJQ nrzPqNw7ES6kyXdEmMJJ1uWdoyRmCQDzyCQHlgPva2ZQzMjyw4F2NOPWyEktiUG7+6iTIP22yNcx d4IYT7LqbdAyYmbKxU1wdhnasGHAIacy58b2PlNUCjDlimYdwo6fZtWfQh7+38JStwkw37VDUquc AP0AuzVIzCxg7DhiuIECZx2+SSF3MjanBFXOh+ZK1nyoT4TKEiT8kHI+Z640UXjb/be9QtIUO/nE SPmjxTlidRvbGW6l5ji97ZSW1SC5RCt6F4qK6MArkJgPgYSw4FbIFDIWkNwEXVyVfQUn11UYidKs JlQdF6eIWBTk5naDoDbwEmT33nQtxPmOzgE89uVJce4Ucp1hAx7DmSPcyx2pU5f5NMLgzOO/I65W oXXpfjdQuXnHbFckcqzNFJH1e1XADxtchO4zUxD02E75ksiGqM9NgHm2qz0LAYUjbymbOaNSnl/I AqrVrvBpZjs1G73ZdgwlnROvOJsCinmCmokk8v6hCeovhzJ4J+9dKIGw04XgbQlQCTb/nPUGIWyK WG6cLJNUu29476i448BJ3abq9cvJJ92EPTzyGf/UExKWex4RKc7VFkGXzl65yjLufUCdjn9ZPXAu uQ3x8jCOsfNp9YwPGEqE4TugkmJ2I3DlThf884e0GusPKKOM6QzH7MnhK363M+yQ0SK5eU+yG7Lg vd978MOlZ6YmHTB2IohsvmP/xu+dA4Q5DPMC2C6ELTo3rGQH1VWejuRfA7ZNjHIrLS2w/i83DpVK 606qaboZgT+wjIm74lZZrlYF113LAwM8H1T9tCG05170+LMTFfZRMz3a/ibnHbQxdfkPKKwigJxC iriSmXtwxEMGA74pOyK3bsoZaR6dEz1WVh/9TlEM91O+WCPcVYQE5Mt766B5xC8wtFD3Hg0qqfaj l1Be68ZUVZYhMnQDn+NUaiDec2ShSQ3e9/njqPvtLPsmlaR7Ntcuf65WN+KuEfiHWNPG6V+Bcaaz zRHPukTRP/em0rX1zxnlOQT6LLfzHxjkDOnfc0UCsUHWauFSOSxfVXHImyAYhbVVS7qhWPP1hHWr cd7rWUP+Io47P9UFT1C5s5qc2R9oPEk3DCjpPGJtmynXXqvAPVGEM7c+IEwQTW88mGDTnHozvWbv j41LPDWu6LZU6+AXLqDYu8//NqOYO5FTQCPvZ6LPO8IoQeg4xJepBd9ZGhbIujpbGrifh4S32V/u 7MGoAz1rKMjg+5jPT6vnWPUG7D26DdmOjBi4160uBVfrn5oExUaGlZDO5oL6k4CTfG1yoEcEAHhH pjFT7fJ3nLApKcMxij2QXeaDuRj7O33WBoHSrxDtM9zjyxv4PNHr5Kja5WynXi3seJs4qI5+7vqf hGe3QtmJ28J31JK5BA65Ps7uzdGckWm/DubKu+2mgrjgu1dg1wYYt4i4ozbCJPbGzBrPaqoTrsWd Fic5c5PTt5mJyoDWz9GiwoQTyqaVAO0lcN06BT0cMrkhU2/JQrYvrJLTnQWioI7GUdoqS8Z9+lp/ 8LWtKn2deL/xnbRQUvkdc4yc9cEhOJMDoVq4aoA8ww9G44ZLeWb0v5uZ/6Nhfbmk8fDAYhn8Gv2n Zvzvm2D/vPjxdi8ZNUIqJ3DPRtGfJDwyXBvMirtMwK6be8KbjgmDivVK9u6kV9EHX+GKi6mayhBe 1/Q++u42TN6wjnXNyRBfGF3HPVdvbaqDT+3hxNdFMmjN0vTcVIjtcL+53GsWMxVJ4EHaQRfpq4IZ wJ8NfZUmDRMT7799qg5vTxw/py9P0asYJLqzsCxDb/IO3H/xTlMHy+ZvfLYcNvHBS1VuJUNvmZ/j DNeL8PpZONtff05P6ul6NjBFITCUIGMt4h4EO9rLTboNtOz9aEyA5P2+LEM8R6+Sf0+RQDdRS23h +tQ7cUIFx30RJzvrF0x1Dt8KJ7vmo5NmbW8inZCuqstFaEo5ebAz0jG6d3jS0snpJJTMeQ8/ic7C PahJ4yPjcIXS4MtPou3pxzMv+6Zxe+4wto5pVCIN1675wTi13/2soSthLypEc+aTN/jhXuiPatIE 4vY/Oz0rkmsgDf6mWtN7/Ed+CI5c2UKH7lzuUwS7FPJ/XRT644b5Tvk00R7FqLqABx52en7s/I1+ AtBCbWe0RmVHtDMWaE1MOLMnPFzBACIiFQfvz6V/QV/PFMKsO1NOPV5+ew+wUswO0UmEl89WSMuM zhUA4eCoHW7lWk7RGfvUp8desoW9PAimbAfXFfbnd9YvJMM7Adoc2xXFrYEgUExSOgpZRwQrxb/n tNDzu312A8RjkKCvPhEPXCwXPGsF64mIf8HNUTh733PxHtT337ELkwq83SJkEhC7F2VEyN0zyFck 7o9z651E5Cn/dJebVbRHox2vVgE0XuI2aG9PTNLTUI1Lg25wXqPi7o9boPekIg1kCEGlU2JryjMW ElZ3SvV1SenitF3mbWOf5iCa6/6KPXwI431neF5Xxz9RQPDk05nlQnQGMPhxTvSFoo+zdDgEzYnp EciZYBzKPkK7Dxf8CnJdJ+XrgPoVQ0chPucEFdUEL0jhD9r4DjFwDGR1c/AUcujer01w7iiAcRBw 7REdIZwPACho4DxU9yZkz+IGhXuuodAWDhBMaW7nY5ww03dm7alwPz5rgAEkHbc8xbrygxQyqXTv 6ZSD5Z1767MEgaSZGus7vRbq/9Eic+fS5WKxU5xI7oAUt1+OGyb3Hgme33pJUaMKhNUEL09ZzUKi hsQTKdsY7RPox0GeHdJpgO+LwOGIxIHh5tfhxgGmC+9bVcHEnP01xcWXPX4TMEh5xYmYtOPOGtgb by9N+RTpXCR0VdupYsWBUTuBh1fWrgsuEKF6f95hmdbv3MjnMzTmmeYCotkCtz+grMjPTStZTNEj tdFo1R73tzMI0+jWWj/v2lPqZ+OZ+YqkvoC0AZGDYMc3V2YVatWx4y+p32H5RrL9eT+3HqnBT1uc KhTFFMLaRP5oMuLXD9D/OuG9EdMpdTZKMhgl2uIjAwk2Kyb4ChianF4YPNuICXKWF75XIcl43dcL HqKpxO8H8d3PiMBOPC1O0+hYR2SFC3GzheXsjNqT+zI7rGGKL9GV0dA2CUwGKBnVs4n2ssJFrJOI WumfLrVfVn0/++WIOOI0mgdXYZnLiFHnnZLHw3w8InZ73oHPZOgNAZkKTNCR2BVepyVeeFF8ftNu ppB9zcThmssU3yzz+JzAfdHFldlh0nIwN2XfuhxUQYjz1vPXufU7z5M8hhJJNOTHTJDtswSKg3fo GYYp0rDEPM678j4H6FRNd9ocaaCn1olVQffmwPiuOZIiZJ2xazQ+EPBKYVCwhXGqlkLp5KtTY9jz wdlwjL3NJ+zFoUn8su8XWhc6fcLB4pxj9mv4HFx0CW/s+HdiGS4CFRKrqSCgnnf4dP8pFQfuG4Vu 6AEMmCLjLflN/yotCb/fHMTBgB/Rpp/2uH93unu2UE4Lq0v8Hzk4M466MCh1LC/dUAd4RiWG+n43 7z5f6ND+5c6aDpDrFEl1CkSc+3BMPFA+KyFygs/402caMM63ntEPj9zSPr8FTddMazYm/LgfXqMs qd9k5A7KItJTx6rZOLiwaw3LzedFxiADiWdZk2f6xxTc0PiumoCe+OWvpOJ21qcewiSRl44wiXL6 2Hk0cSIWdTIPTC6jM5ROg2yqguGNpC+VwWZ9nr15B9Ze8hV1esI1N2voxrlMwf3fo9RDiS87BW1z CYjve1C2uuskWjGC4TiFKdx+dr8ZpFzuQyV5rrE8uS8r5w34z+oA3JNw3mSurQ2a/8+M/+f3/BFq KtrY5kA9s3in//bM/FsJwVy1ji9OMufz857ODJKWm3MHiIyJnITsvIYUQt5qCp7zW+Wrj3ri8O0u 6dKYKsraDn0MdBoSdnudl//ORTXTE9V5ZIQNd3gPbcFrunevniIk15AWanpeBq3ExkXTpNLFrd/I 3/qYvrT0rmWG9Yg1KffMqO0BDHElGKQofmsQjkv1NH4vjTojnQQMNW6yWttTZKTYuSmvNZY4OJ0z gzjjn58i3s1/0k2efqyhCHmjP+9DF4M0IiwrZdE8/qAP1uVy6Jv7awZq52SQ4ryhmyOsniVEK/Sr ee5MDHF4QFs3iGFfXPL2MxpKt3pTDTNtxGGmQBiqapKpP8e26Dz5SjZK1jazLOgmmc+EnYFnyLe5 P6yfDgLqAbx/wgDn9vXvQKeLQdaX+eKcM29+1UDw+Hc+M+O6o6evD56v1fPr90locPDqL29q+U1x FBgO3jtdNbniX/zn/7hf/i+w5Q9wr/PvpFL8GaetFEIYxUF1D26Xl3hBMQKRv2S/f77bcyEPAXHD k63+ILfvgU8zLxNuowaSno+R7QaqEOsMisMpyvOS5HyIUWFOE6IZrT1nCi6nGa9D+QVKvx0JUojQ XZE9LeZQp2g3uIJeAFDLGWMLkCiqSAXUag4ZJDL2r1cNuQ08P0kkTHgdGxwgk74aMHzGU6NjyWmV wXYvsc2fb6Ep4OEP2NcjZSfEpOxyLHTq51DjJLAoKuNPwe1yauhOo+ohsQ2Ts819HgZhnNN1BinK JRBfUjsiDcEBeKIZU4CLCrd7EjdNpcFTDGiIPntjYqdcz7MadAMR10+2p4E4HOR7ThibHAoOay7W LnWbEbTcU3RvfDs5YU+5Z26xpo+m55znPjHIUm1VWDSS5IvwXhI34dIBdrbIGeawz4Sm0BvErXDW LLLN8E6z9qnZBFXwMlCiCm+KAZfGrM92t94jgxKI9HGp+BF9GYCeDbClyMGtYYbpfWqUG1WpI1bO BAQfZ0QmKHr8McTwalZkFCUT5Oc4Z6bBBc4z5IW2XGQP8W5zcU/Awvm3UX/puM4npsKCoBf0yIwN z+/iUD2gi7Dh2oJzfziEwrCaf0hXhSOJ5u9HTg/Ken2EE7SOVMFWHgpZIiJRZ6T6Ti/4NAgVZ3JM guFazrbXteMnUSUdqoOrqo7mHCXKzX2JmfTX+9/f/BVER4y2CGzdjnw9xG+7djEJ9lO73oFtf5JO DJL2s/zHLcsRCT7DwssdpWeof9gN+TiYmoDsdFGhyPSvIfeX9ESBtfdw6xSpxiXkV1SwuUvLu9wg T/UHWP/WLC7w6IaXfuoNz6Bj3IVeU6hwB51naIB498Q7VvvLyYEBzy4tHKyJjX0wi6mehjyJkjKk EilKKEH3NwmuK+/wJiPfGlybOKfznnCXHEifc054OT1vspGh4gSJrxhJ4DboX5K3uEY1IlAH66tZ Di2wl7AgRYgxkWWvgzY7zgujhr/qiK/0jy3m1Mce4d5KRUgfkge9ol8n0RfUHaeHtIGUcIrUFEpo O4waBszTt/lZi961zXuO/WhKdNxhfr7rK67T+V6EsdJw5VvP/QaYp3fmK0gXiPBaTPel/3fvfmO8 LwEVAmbpwewHCeR0W9cazhn8fTM7ZcV1VOIVtOWeioDbgirkOfXXXbVOTz9noa4AYD4wlRwHYiKX hH153qxqVemC/AcDsOtdNOhe6MD5vOofQS2R35vGIqJqMmUEtJ6VEa17Xv9shSThfgZj8zzUwaZf w5+d9uc6IEanc5JvgCmi+YNYwOAfMVKKTPZw1x1U8xFLXxLUJXUgUimlEAyp1jIXH911OCNNKsZB 1zHxJBKoIVtez38nN3CqZMZrX+y8iWDv2UMjRG+fUMa/dHHLH+7y4lSEAAXe60H8/c/n1yycZx5D lY3PnBpGe0hTkDJHqTgX51cYgcwn/7bss6TC6bj0+VPt0igFepQY8h0Om9c9L4Qt5M+tuLsWJyIa NOCkN8Zcp4yYfj+PdDDMuPo/q+wkrZPIlHr6H4xyQFzHg5yt53d0Fungm32vjlmCQ4DiamRxuLt5 XMmO4+lgt+LAmfwp2r+DWm1QoyHK7FzPNaLg3tR0Yw3a267aBRq2VK19VTpiAbpjwFa+zpH8dz+1 kg6Wv+8xsMM5tdUePuckFJDxCVKnfR1Fs9YmfuqnBsrkr3UPlqFuxf725+AUqQr8S3Lifk5HUAQG bCrJ8+v8cHZHV3DYu2IXnFT/t5n5nxu//2M6cH+jr25lsJ71zL97PP/RNua8mD7RfeCCU83M6bly 4NPl1s5Erz1MJuTT9DnMtEV+P/23PtLNGlfG62API3tq8p257/QxvLmJBHfgo52ve5Dmy/ghz/tu +2PsC9gNuDjlFuz81US9PJiBDdu6Eq/6Mwe/9ewDYX3KZ2Qbdhk09GnoExtkXS2bCk/w7GcnTjKV WRfk6hK/cpMbUoK8zRFcMCStPbVTlOajDp1hXaGr+RI5Gl+sQYgdvBzyYC+pUw8p6qN9H7zYwY/W jGqgnQAkGDDoOPLPMzIizJtLeo1qBWfKO0yaxot6Bkxd1/asOsXTU8ZvPynUP/DQzDnnzxq8eU6B LJY6j6qAhrFHGhOe6aQ9cakad62twhe0f/qXLu4m2zg+m4ek2szdzwfW9WOsnGaKTXGbWAOZWGaa raqiYWuJnnfvXodd04R7BvIQS4wPzZRMzD/1iDFbHpNsicfXwQ62jq2rX/9K4esM0v7s/3BEi213 gj3Bk8Xdj6MkTzN6AcEtTqg7y/rDOfGdUiZnpvAa0d08LjN9RrI+3V4GCesQcvs2Z8ZLnxZhRqRo 0v2QiUem6zjGd8wbhmJQDYMFx5A5HFOoJcTJdM1nFFm6VvwUfhRzuCfAqdGl7+F12akW+HqmzdMV wHAANAgmI4pfQH1OkZluWWtqrniFXoee/N5C/I6+Azvo6DhITGkdVYrtdL0kL0sjcZOfVQDqD4pU rrNOXgAx2VpEKjxJCkDd6/Z+jKd/QNYr5HIZAnHsh4HpKRJLOZw0J67HDesbUw0Eg0+/zd7l/t6u z0nlvPvFhxSe5UA8n67NE5/1ftodZTpw/k8UvUKC8ALRBa4xgQKzxONCIqe02CLCVwiaxSiS69jU 3u0iZzyKMBUSrY6dpgO++sOHhYAloq5VmvALqHDQ5AQB7BeAG3K/d4hWtgTNUIQbGjuV6FsvF8/f AtrIvdfDUamT7t6aqIcu2HeJ7RSabJDUFA1VIqszT8Znr6RYk4C7dLTiNJ08w35bZzy1rIgG2/f8 T918Ej5O+gDIg7JyVXvzeuopGuMgJ3FPDqLoEBxc1ag0lfoQn0R8twh0yqSLRYR7hjybd1SsoM9h sf/Ad32HDAREuuodQ8+5kVl6YtR7I+qaznLBYC1HpoGwMvrMBqHBK6z7S0BocLwP0Z4UMkB0IIgz +JzNbn3hxOejRJkmIFMMvvSKMsUEeVZrBlztGNBkN9EUP12RrsPvxf30V+5WR1z0Hs6+q8Du6xZ7 eWnYHdrQI/l8D+6xVxShmcRhYkO/gpCqFtcGYJF6qxblRzXQ19mQYOZ970RW+COl5SVv10ksonne WOoNrht7bx0gnkHLNiBtBAF1CGYm8LRc8tIJKU0EXERJngFXIBenC9r/RGT/db8La+w9IJeyGw07 UN1Upjbky/fxoC8vkZPs4nXTm9ruuk9qYzN3dWeKzibxrjjEQ47+gj78JhJep6TugNd3dnOf1Ukl fL8DYZu0Z1xcwTTs0Oayo+YXSrplLr6/y3j2ablbLbJHd0iS+y4WLMIb0MDg9MVsyK3LIWemFA3D 0wsMEA1KGLOYQ6Cp5K8kscsYQ47FEB2ahMyOoTd0gs++03VavEmgEzXzHAzm1on0nsgMJW8HHU+f 5x3qnF9ipI+TYq5wxKeH1rlzaHCIs3peIf7XfZ6fN/vyH2G0k9yjOh8Gt6fi2gHwH/y6jaZpbipk d5SlBLz5vD9dBokEyYQcpU5D6DPoEm3ucvooZBKaLmJuETfxGC9mSpWWKYBCREE2HAa8oeFtu35y yddJ86infjou1beXbuKHl5Am5299Cp1vP2l0vdMIvzOh4UvEfERAbxS6sW4XpGDxXbswHLyTfe47 QfLdfgxrUM8uiQszmUo38RzJUR2TJJ01IK2gKf9OZSDbn6Y4bf+xuYsjvfZNklHtQjzGOuTHnV/V ETuHRPQ4+udp4F+Gu1qvkgZy2ac6hJfbJVwfzunXEubPkNwnj0wDMa7DSr9lgM3Fl5RpkzO/mNbd d/rMkrwpW4kRC3sdrJbc8BV2FL/YgM0I3U/ddLjXasz221jYVM7icvApPP8xAjHeMTy8e6tUIb8i qBmfU0Jw/2rXGTc9m3PL9r42RBJq6QEuD8Op03/18AYkqGJnhpPA+S7eIbcrWv1zMvganOgDVQbB p64pjBjVUmea7jrYGhonxyVgcDzZv8/AgD0L0jz+P8/o//CVYLAHC+7Z2HVH//wb/11J/05B3T/R m/Ag7LSqG3VE1MntXmBf59uAhMYIXOv3rGb9mNT4Q6jJzIhQ9L1N1sjvdSfV5rr2Mkbd+KLny9wl Uykcz8hDiUktYXxmwL8ZttfqJbP38DJ47YPDXkY6r8Hji1/sFOIrUN9JNTpGE4QX+NGi3Ge2bjgP 8PyULPpUU+7GfnfwO98ppGMdw8ueRK+6/lWNBxo3mgl05GB++fNXJ2OzVnD3+1M4gJ8+5ZoJstnN xswMiSOXYyL9w0WIVTiowEXdNCNk7kt8UrKTe5CD+v3GQQ3UrqcjkGB9+pirslapcUwOrPpboRH2 GSj6/cakvwyBdergpv34MVc1pu8lh8kqm6gk7FPzCjAAFT3Kwe+Vtf1NuGjDLJx15F/w9Dlrj/oZ eBt2aIwY2z/mnx40irz3GyX2Glme5JxWwkb0R560B/Wp3Z/vryeNyYTRG2oJP+bQgJGcniTXhmMt pGg1zST/0aJa7rR4ukD2tjiL/YFmUx9NNU02cdzzS+ZnAMWUOEtuTK7L8etQYxJURaPnfXCcKCFN c+thSdAgIT1I7lA880Abb3RIIcePPWFtFKXxoaRyadNB0cJdmiAkyaAjVEZwCKXNH6TgIb1NbjD3 Ej1NoXlaEdsS/1ycr8tBNo0E0Ud798QZM5CcLinp3pWT8VuOxHDkdkx+AR3jYXo/v04jNoX4pdUw xffgDCCYnB0dgEmcFycum50KxK4cvoWClrhdowN+wZks4Y54Ha/Mbcr0WDkeMHIL6PaXoMEAbpEH AblSbueGdNmHqDipUMRvQ88RzevTHBLSEfELxNc9A3T3/3Wh8y/NFkST3gYWCD3DSv+WNiT5lztH R5zI0DbR7j2FY6AIpUit2yRk4SKQIVxgzUCefqV7uNAC+iBgGOjWOR8U0k4i++8E/wJtoaVTgHjk 1macrHaN8813uapBUa3CgF9Gr826z9an9Bao3oGPDA+8yQB7mnuLUanh4SqqJ/cYG+sB8O89I1km pzVIup7dGpj7EmAJp+Dxnb3uSPanJ1AfujDW6J2oZXehJAw1U2CKnvaTotE9RCv47oMisQvOqQDV v1F1NJw0EAdMyQI7susBUNTA1wPt2PV8atka6djehpG8wetDRjmSpWDAl8BDt67n+9muZDFMteIb 74o4mJBz/dtE8t57U5POzVyjo7y2Ctzb5xL8v4G4Y77f7555ANQW967Wx+WAn9FJUOCGtp1oaDw4 erw1EfrCiun2dUUR1y1M9YTt7nl/LwI7B8J5xNpVMuBypwrdKtLX6Lc60IfytAm8c73vFekmQrC3 Z9nQz9kC9zzTB4DL7d4i/Vb/JtmbQC4P2b7noJ1r3ZcoCtdYTXPL1a8VvIu8gBCNFus8ACbuAbbu f+hJIyFyYdVnv6QDwDfacLT31Ts4LcJnQOBNkgxHhCs4xdsFGSGHJF5f1zUI71hwEE7fFeH9z25I wmEQwnyaf+Dbc6RQJ2O4d6yvPva4G1Jc/l6SIy730B7B98a9vAUCM/x5hVgFUf7kfgN3gb4ESFPE DryWUv49FcHcKaUuu4zuVi186UfMOtALPWe7oM6SzlnKstZXqMbpVwq08a+0QxZTHzxtpkZRO5yE fDCYS5Yb3VczXEZwrneXpjOZ8JwLDjw2ziz1lApC1CfEEMxb3HSqfV4LMvJ6Ssc7cJ4icRfTm3QE pAH1S9CzwEiL3yDcOqrP5/xnM1qQyPrKULgjWziUfxt4HEA+mjv2RnX/CPQ8mP9DVdDdqz1y+r3D i6Pdn2NQpfdxYG+YRSG6LVSEJnN6w7PudZND8hTeKapXhJg9X9wXAjHCBXvMfnp+nWkhFXdjzIS3 CJ8hJzZfjIQNf6YYJl1euCcXUw2cCRk6WNLbPyiGol19YLmXGMSO52AoKgZGQsf1lGdQnhFI16e5 3r3J0BnT3nnne58ODj1lX0cSy8aVD+I0aZSkKjIz9BPPuR2ltGeKMOQi+wrLuINpPBjFd821xTrb obQ5EqYJVsOskutl7IDWWR/OYsOK7OcHTQQmXI9/k9cft3Xws55gW84K05x3opXSo8JZMeadteWq gZ15Ii9vmBjiEarrZji9CQkbf87hvM1jZ2rFj8hRxTgsXeFdtB+DLsd63EgjLWd6qt5eRzPb3I35 t95z7LvrTZH7eW6Jp2jz/f/CjP/nefeQwdY35pHjhf43z+g/PTP/su8Uie9KkGv7R0eEJhWJ/OVg b+NmNlfKgkFOktIvMBP5BTMCMdGv/ZgrvXtgV3/vfkj2KoWQOUjmmuhz+5QYBTUJ9y7nKL65xfzA xZ57goFwRDgrKcM9JkQu3+QoWuOGROGpPTslCXBN6GqX8BjbmnUiq892x334fxsczhWYrJDLHrwL 886k2ywVBYlHbYuIH4wBjAW1DQlb8IlKrbJ5lRxCVVRGA3/2Dn9NrL/GSwjutZ8UqvlloECAJXhY o3m7JA858SfWqdBTEM7/iYn797TlHLzduIlhmMd1YJr3dpouKDgf+94Jz1MVPd9tUiRRHUK4Q97+ W+tynqgGcaypQwD5c2koSDAAts0MDGdt52OTl8ia8+3HYj3ZBcq53MzzW3yYLA1oULqeWeIuYvcb H3elru6w3zNvPfymHL1aVVeuj5whjEOy9/c1neWL79/n8Q70/XVG/eP+xQXqi+PldYDjTSIR2C4s xlHUbC7k78Hg9SIZxkvwZYs53iIiY2v2ok2wl1rQh/SEosiN2CukiZGWdSniL8ByiWYlufHRtDRf Q3bvyZL1NvctLAhCN6YJe/IQch4eaoQuuVnnWjStWzXPGwH5JQSmmBq+n/mLPvvdqWJd8poanKRK jFw4xcuVRh/e/AKgaLnOfTaP6ZY8eK3qlyDDR9DiS9M3Nx7lpBLNren442igICFYWWvY4m22XhLo ikWaUCQcZ9+4zumCwnRmV10D1Y1M7e/dYno+PrtPkWaM/p24f3Kvk7z3dXZNgns7VxDpe10A70Rs i1UiAHBWI+MPV0sGEe9QlIHs265Zmi6gyhPsvac5EDPBgt0MXy9eV0ecTCbJ5yExPdKSMphCYYD+ bRNeh1IGNpoQfO7JCKQskduKJ6jjYvBDwOewHspufIEB9l8wiEa44SAw6d5LJQ0GBgo2BGCYVH7J 8AuCDN5TqhWHFzg8pR3OU9Lg4jch2PgSnl/BwCsYuaN/xmfzLbwcf/1D1TWZNYyQeBelSJTaMsSM ZidVWiNZd7afLzwjFO7khnunNdH9XTJZSc5fqjBfCje65/USemjAZcwB39Pd6pnVXBr986iqVNa8 /n7P1xMnY9vZ1SSIwz8OTVy95V1a7oly8uwaY+h0qIQEkSLhW7PAySQ7dVwp+zCRwefCIZBmP8QN wM3Xs9EeGnuBM0PA+FvjtnVNQMp8CFFWvHD02JcYJ4DnOpkbo9TpE1w3ieuoOAcklF6ylO7Stwdu TsMG0n6wDrhr9Yfs5bXz894HRANTqstnANnkILMBM6oHbqLYfeeZPCJ0qrnDYPhd1RwQc8T6D6Au xikyRWCC7F1P0f5IYHsIYhWH6nAIoTupiTh4oEzYV3hoZCPlGmx8kO+E3Jeg+j4CDZ/hxO4KqQps 07DD9SR6XfV6BfSVGkj3yHEoelzOVIwW5kTgbpLs7t9Mu2wJAeR+rUscuIDvmGo08ExFFdxx3t3O STddZwq2anRIf/aW95C8oa+mXuSnF3eI2akX+etubslzG/T/Wbs/Mag0ZA1PzrlX338mzAJsyUF3 gCJ7+Dbi/o2laVLIt2s6I5H8TydTf+N2F0HuYn7hIPgVp13cZTtSPWmfZ00kSX/EHqZI3811fP59 XAVesfWK/idrb8JH0txhsE8hN2Nh3apTI7jcfxnuzkkF988kriTcA7l29cEqTI2i10rtvb/7S2hF /ftKAPYgViPRmtxmBLEPkO/qeYJbPJJIhWs/TOcIp5t6rU0Bd9X3atb0A+YjE2vNjxM87Z11B5hq RiiZ67fjfjXOW9N696lj//m9tPvZLdoqJkW11tiGBtt51lipzqTBikHITLzellLQ7SW4w1TYPhej l90nfTvxvvXRqb2uaVDh9vSxXrn+HuCR2AFSwe3x4M3tuS43og8rAiHWBr2af0h9ui2aG+jtITcO nDj2FtPn3v5igHfKoOYmY+2aiLj6NELzET68ifKOekdZT5z0XiNXrqYc+KjFyaG0gbKOwcpBFPWm b7nUzyocuXhvQQ+VZ8jGhIR4hcNt8xvzccjpEjO8eO9lNXbyaDtHXO8/fdxpfrCE7Oc44+AHk6UU qJ7vsHmc7Qwr9D/epcTtq2mNuXAJdPcJOSe6LRJn8BpK9MV4A6Mu6VbFytKRCjyRbpfvVf/rmfkX 7gAeoZX33uGhm7cumP/azPy7eLS8p70S9vye864uslNZAhYVnrfi1BsIseLdLwxgyVHjRWIta0u6 yD194EN8dp/gqQkve0d1flqyfuFKkylyYGbHQlbmqG79xYYkqioVPp3zfOyc7kxopzQFe6M762qn oK/DRHjaATcNaCYHvSgdT5Pu2dsE4sXkJjC1fZ9uMw2V/bY5y0z8Tv66G+2qsXLAMg/0zUfrofmV R83MFy9T0y7ebplU17my249wPc4DBBIhGMKKcD+3Zkg7w0Ps+gVHMYyBK2oqB3ax168u31AxOFVU dzuaT+G9z3dV525bp8F9X94FDnOHyyIo9+oUixWlEXJm0O7+aRvA8L30c9erqlXeeowST66BbAzr hQkt1aEudzgMin6mOx4eS1Oz6bh3hO7KjEX8+d7iRInN7X3lUwOOpm0O+kfD46kaZ9U0+Sn41jXH vPeVVn2dJnh7QOwf+wLRiqhlz1Qi88gxyR894gd4oW8hwm2XbwQkg0BC8k2HxExnE5fQ4IzM1XTH cUO7ZXSM2S7gXx56fRrGHwFXg81ib+pv9NiE6IAP7JkuGpu6pYkQVrilkl+eg2Tsh/+zjv03D6RP iJUL47xAboyyPkmOOwm6oU8DafVz0vykEGSD8cZVsKvLbjibXyPAb6doyCKFXbRU/Kl9hFV5xTim /Z8EBTFUj4CxEmyAFhOcI1wui3dPneLXj2DqKZmN4vQZjl96id0ur7uRKT/kgpCsrav8c59w0ycU TGhF6emc+5d06+S9w715TwIyUDqLCN/xge33ZLKJPtZ1b7O2O8REY2wPiDLmOhvkXaRGcovd/6NB JVJ6Dzwsx+15I8Wfls+7nSGHKAIcjbeSP9eZfm0uFMTDduPY98YVelIk2c9+EQxYuBeSpSl6gLbZ cWzcTNz65Ucgvh0wFXSOliuCi9C6EwS3yeuNl+CcUiEH2v3Rm0gvotWneM5beZPkKnd3uia5CHHv uaRSb9B0OEWR69Qu0Ix4Vvxo8/p1AdgYEFYl9r7zGA4gHrGqA9VsgqzvHTQIixOoKGzrr1gB4T33 2pIGnpIMZEEAR5nqZKYY6RRyY2bpnk7UH8C6nvA0IBHz/mwOkC2H9e5wcifBdtIC+zhzNd5d+AeB 7Db4RhVpZBxF97Wejem0FuwrctRAaGtSwGikqIT7NyOtZzIZw0FW7an7tz9Yd8bUjLPHbUpY5c3j nMsAT0Yim2K04SRoa5AdPYVVzhvr/jpjqcBKW4yaQgrFHvYB7ZhYz9osHaVXlSSu1v78bwI+nRWJ ZztbvqKbf1FQMeBQS6SSz89711+LbGaRycVs2DE1ydm2j/dQa6ej6X7gm4Z6KSM1RLW+ENybYZEZ i3Rnge80+MoxzUyltqGJ/ft1gNTuoAGVrGeuux3/PUOlfB1u9HF2U8aPzuCJh5yJM9kiTwwBgd5X QvZLf76/Tq/4Z68diYI73sDjeVpOhF+u/d1Mw1F/XOetK2a4otyfO+UQkae3jxWgCded2we9tZyR Hvb6eR5/rP29LlKUfBIM/0De/ly7GQX+s74orYoGPHo2J0ssOm5K5w6k3OlnX98o5OtOOUeIkvfb fKRd3brM9WTe/cBv33kw7eqmaL7Jq9vBvdSeIrlVDn224eGsI7JWuR3OFXjuVJ28EahKU8nAmgcL 6HgWrBnf8y6HF+h7UEKJtD+3MNmK+ZhN2AOqogH37zgZytBNOkpJjJlyDaojYmvVBKfhTEGT4ZQ/ Ny2ldmkNHOomH/g0h4MHU+mVvbAidAXV49Ip/UkT/TmbFWTrhLhNa1gwxB6CPgtEpD93iuGm1uE0 Uyyy6lilTI8SYH6GJC5PKhQXJ2eg4x7uaY6O7xn1nT7mcObeDqpXkuOSQqHyWXKtkmDVS1zwCA11 sJrzuwWjDMnZHQdoxMmFAv5vN2t2zZ7jfstCg5so4SFRmCO1yZur0+6LLm8VI0oxeHz7+0HR4XbS 27UJO0vuxBcNC2xvr7t4bvNnaXLrwcRxMSqgqbIrfSBOKRIhd8YXFyv5jN7nwih76nRVvT0h4xJ/ eDI3HARUDN7/9117Wuk58yFs+fkzKveixPckj4cfrPHZoxpV/cVlMlx/m3HfengMJQWApacPF/Kp SDXL27TwIx8c9iYxIsY+PYVFzxrszrcznG35bYKVKYoka6XRnS8MfNe/xAO9Pcqf5/AvnpH/C8/8 v3nIrEmatXi+YUO0f83M/Odt/ytDv/H0s78xfk1s5dUjC1ezEINLUfJrNpACbSN/axzun9obJMf8 zWrSUMZG8/N77qHHZ7BkrrC0n+UKTvbb1iqwH7042+VauHZW4SjugPurRTLwtnMwiYvOqLhnD+G5 y6REH/hADjXRUBGh6XyrswntiIY/CKNjA9uXi/+pi662Z9BpfaKLNuLY3B+nGW6aDhn/OWO/zxvx xb26IcBg7af433dEViIBqfhMPGqdjk8bDTx1xM9rAN3tjt43ssDQk3SkmQScie4xXBbf+/cbW6FP mUGDYOV5knhRebvqLOjlkXd95A8G9e1TVO2ObvL07bsnUowH9qoqr/++e7TR8YQhizAlOof75r0/ vXVld8TfB5fyXG0eu4bv2nRz4ayLIgOYNBi+2KlwgPV+CyEn24wkpaIcUNabXP8mX8aJIMAbOfeQ CIeB05k7j+QNrhnk6/JPwxzN7PQf3LzwYk3w8m1cjFQxT8nkxD9BCCQxf4kSEl+pTsU293J/eB/m teBhh5wJEOZLwM1zgEmnKqZ0NQORipp0xDf6iFcvMA00N7cAcHF9Y0fmLMSZbE1ylxwFd8yLgbg4 cFsAdrdYEeTmsQBwasGezXyCCF8RV67P8nlG1WEln6s0i7TV+l40QTnDfu0ZxaYyy3ivXRqOuBO6 KeumxIEB0ltQlvsXAtkVtGCo8yXQWPjB3lzfzvQp+DVP56Lc/2v6nuNd4ux5Gv9LsrW27Ipd/NkE tbNgC75/g2CGwFrnhXYHaG7KyHtO4x70RAFIvj1McFEU53d5zfFBjvdxBQlErOrDBYAFNduF0uCL 7jUBu3//X3etoDDyGsyhZoZdqMgZOL9bizz/uV/2RK+AFCensmdPPAC18V54963rubnAewkB5OW6 4v2cDRG8GbyawkYGiQXhaw4ZxmBznG5d6+yAVYIu+J4qHCGyVwH2nSh7b8f0nHx3/I43Hk4x+jMh 7dm1BcVDzhHQ5HqwGYRxaWz/Avs2GeFHqKlzt6XzIbn7Cus9CFQ2jR5c4d0+ayQSH2/7MooyXo6b SIo4zisWEQzE4N6aiJKVZlhQ+ZD3R5Sbw7OutxV717JLJA9MeTmbKJyuc+p9S0lb6o7BU2tWCpfB nXSmeVJ6rtPWFFLk6wziFBxypjCIGppUxMMOytRXvbWaV13Q0lEcdRsndziA3oDcK/CWDpaP4Mf5 c67wa0/d6xDHzd8zRSTvm7/OgzoA9OBgPFWIDHpyvG93OUq6S7UC1nzVcMP9og3SJUOEoDbI5nsn KkCiCbGLgxxlKPy422sCTBPcMwtJ0ByBG30eTaYVCNxLyQzgJs/oJAQZhGNfcDGf3T4gKPkrEYnE g0yGigDAN4wu/cpj2+tiijADk/nQrsNBeXAPpg93EcN6evsQPmdvKtMWmmh6SqHOUHIXWKTU0R9k 8vwyFLsxj+onZIOHEt3NhGtM4JvrewiIWn2J1nJQ7+KjzcMvCQxXqc96R+IqXUcMfZMfXvdNowss SEC0T+OfaFshBatKtE70Puiu6vmV7L/oqz5OH0fdc7+34RydcXH2mkK5Cr7fFUix52MOm3sJd5o3 /DvAujGCP5HU8Lsmknwa/StwlNzDd+vGcnq59r6Ah26n3Nuve/9FwUaNwTCgf57vU+2sPEwodAwc kdv8rdoECXuJ1N7PAOeXiFyjZMmLHe6ElvatVYaL4j39gWOENPkl+7OfaYPLPiSoPl07V98LA4zs aWno+f0tCilsVJzmavf2xg2uiYOKS9d1aswEqJkmgtzH+64XqN7YGAE54N6UJpbd5RCZN5eDkev3 3p8jPNt/lvznaDBXmsAU3gQjGpbzB5m/BdVG3ukajYQPDfJcnETTcI9Vj6DT6SDGszCEhSXsIaP3 jtRQiunXf1Q4HBIuXLd6g4ugg1tLDMOVA6Rk854vqsoB/Is1lRDTHcCcboWk2LezBoYWhmWX5FKH oVsIpWzE6yaweMBONQXpNbJ8xqpswHTO0QfSMCeNbv45wzXRp84RWEj8/nTu80wi/VrJt3d2pvVK wEUYEs4dLtk58HBqg9N/oMROHUmJPvMjZ2gLl9++4en3PKAZgDOWkhALrdelbckC0JAuCZyoc/9r 8EmffP/tL5o533x86t/wX1hnznEk/wCLRXD0hZ8+tbdnyGLlmhPmOSXAFrq7rKT/u6T/BSV+dNNM GG8wOnD/ZzzzH16GHK+REhqKkNHGObcfgfw1mCL9yl1rdMb2PgBwsVh1Alx1YggjfOoN9i5mZ2Rh OlNyIxN1qCJ5qw04RvLFEay7cABqffvpzq8aIjlIGKGFzXf5RsLQctBpQjj4nvj218mgdLuN/s1D Ds3v93774jus852neHlwrt1owO4tOfX8ox/MAYaWTTYjJOkXWI1xEgMydn+uJ8DpTDfNNVB9tCi6 eyN1I28HmykvNGRImh/glxGdv/o7MMLQFhXf9ePnTH+NrpK/crUjGtA3KHpEY93a6uuLC+QdT+Lv gochKqvVK7ElbTsTWYeSZ0p/183g5gqBCT+++HA4s5dUoq/bNYeHDL3tfNgGFzMeb1OT7LtPP6/s ICixohlV/dFciM2tO44+2KNswXlLRBnUj6HZi/f/dmE0fd69gK/6wmu/6vBlmFLTdfzxbMgA470L mia1JzV2/dvPb/iHwWvOK2Jes51CdqFpdPJoxATFmNxmXyjs+pmy1vpMqpv+OqWwwPwbkLhOjcqJ 07niwSmAHrkKDhJe1+V5AIbeEYjXSVwIgrEzhLGF44lfgRPcLbjysOmBdlouQyok6SUuc4JtHwQX ZLnTYklcvpNpLbB6ZgveqHEignawwCfHRFp/P2TEBdPT4WWQIDxFn2l93zeTz6tBGD9rjBo0r4nG b6I+SXUSqrvGrIDA3o4JMHatYEB4Zp6p8EZ3t6i/Dgjlmu2uBewP3Z1ir5MyhVMawMLPqdLlQP8b ZUUuAyS6USXFBR6aE+DlDA3iUMATD2b4xKqlrKEBQQbgUSiCELbHDsAAQHAAcNElYaYMCRnFAPv5 G0IRh4dZNMW3XnFuMwl8J/CMAG8W867l5p7oVXGjJNAyUxayERj4LoY65tRE5ewZoKbfdIHtZDML CCcPYI76Tt/+9rY4tcKrgWVfFR1A5IL1TNJ+RZ4R2EDykJ/Y1+2UsVah/QF3Djari1IRE/7XCXKc HrrPv4DbfztMvuJyhGq115m+XNqwbh4gX586zY47TsODVqkh8ZAY2bGujYKFdj/STPN+pypA6gDg Rb6nqiDdjpebuFOZsJ9TT+1ECccgyxXM0IT8FZQBPO2Mc+MRXQ97AnVqaruTNiftgTSqgYb3L0ee iQaX9+EXTSionxvsw8NtP7Wo4cx5h5QGoatcZfmefcBExwCKSqTjcWJWVkUOUTmLmW7y2L/olHLJ rT0lzzCaD3nzVefu1KjrZHRPKs9x/YM4z/ddUd2/h/WOxNoMIbk6cWq5G6+Cx1PBsyWwmDcuMO+v 1tl20QX93q8eow9sXgC0u0JR3TNF2DjYj0RUMBBME8NiLygnFiz4rIE3WluqgtZM4DNUrWxQoAqw X8e8vJ+v12a6mDj6+JdEWbiYeifgIDAuwOxYGX/OhHBBdURGpkt/dglNZpAx6D35cCdSwPepFSQJ hJJE4U7zJFMtEj8xtuXmCgD4cjZyw5KKwN0Xx9IxLngJ0Y5fdGFdVvoGg5Idv75NKBbI7pboyOub CDcehxwg1/Z9mns9ndVmiZmEdSuLqlkIRGO0zZn5knocb87vSXPTih63al9x6yCufd0yG213+8sQ zR3DB4rzTod9hSGCUXp1z+cnGU5X1ClEZW4igEoCYg6/cp4MYR9NpMerA+rpwIzMPfnjcnjz2fSR t6UioJnAu43n7xL5lfdD+Ae75nvS+9Moggly19eF8iu1VtjpvANiftNGRGj+HbIgsSHhAE8P7+tQ 1nuYV4iTjqhPX2efASwepAhcpvJX6Sipj9jomyxZpM7IGXZUmOpZg+BmmwX4pHFm56NisKUwu0jX MQGmcM0VssJdu1hvrdZ2+JT6Mx3of861p5e6GKGyb2kVCd246TKcCcGDgoRZeNTtKZaYFW8mFXkO 9Ro0DEiYI1huKLFYcrn7y/F/3XZuv7OJTHzw/Nx7Co9bD2VEMe+q2uvd+ndj9Ype6fZ7Dsx+8NxW C/yO5Nc2uK4u3hiqpy83wczxK04hPOImAehgHsshW3vArAv6/x7Pm0hKcysnMeaTxOezXoGT3w6S M0ODlvZnrUKMFj+J34dTPIOmY+Tav/GsPDs8E2Li1a0pE3whnyjeV5jASKB1cFmvXoNj78Dv1W6o cHEOvtqAa5GxyjFFMAnSX/5FeIrdlI9B7MSlc32TXc6fekXeQ66+Xv2CP3kgzYz/hRn/r/Y62oMd nG3k86wHzlz9lzX61+3hozxiX7GYY3iZEszSqT+GxuNsv+6xmeSbdeJb9ztQ+bcOpntWoR3RSql4 98Qeruy996Ax3feaus/EZwj/7e2I5RD8uzQhJb6i4zj7xlbph6bUjyCC/Os76KY0bkzWYXQ6sWfI UEaoixBoR54z/AjG3774ptV4vvlH3s+/SWT3HvZkmudyRceLVqGA2H3h4SCduCDXoQL9z07Hzfsu k43vWSTsty9K5sOE+2gaDVgiGYtQApMCl/I6r6f0+r2bINXcm87wGiGsFJxzIrz4hSDbICzqIg1Q BwfamrlMoiGD133H+jEuUtHpTO2mYH+aEscN6datLjCaLF/u+HU0Z3Fw2afK5yDkwQfQxyeFBbDL y5kS/+mjoyClyvq9Uuch7znoi6966x+k2QM/7ax33H+vaz2jMN81swBZvQOtUg4wv53NX59hGb6K WHs2spijYybbul6rE1LI6ZZuuJKEd9sdduP0FkeO0/vM/yEMXmo+Qc1BSoUoHYQ0FKIDw6I/AKNa cJKG4sLm45NnkSoAaAXiGGPTcxcPebDTdA678ZEP5P07iqYpm7PrdOMS0vcl1k/3GV0RxWn7BdCZ PlopBkD8QaMz7cQylEEJUAID72Sa5k7HqkrSOynAsTDXZcy/+BQOAAJbyHZJP38CIVskk568bZe3 sCWFaKK6Tah9wwLkH6dCiqwzUrxGQssxUfot1pniLHklBRlz4hqrpABTvdyyBMDVxEmhJM5sEAR8 CGM8J5bVQcXMcIy9A9xMqGHfV8Y9Y3AyaN6u79r3M21+wThPE/c5/LsukEaCUIUbloPkvI6/qwi1 UdDUiLELJO69SjPKHDeTDhUG4GGmRUlRU5FzwkT4O+JG4727Ncuc4pGAq4AMuASHogFwvXm0RGp0 49yG0oX+XW9ZfAa0hj9dL/0B3HaAcer7maGJfnIkvwNjArCGJu1VfvsGlqe8B38QubBfC0g84u/t IReRQekK04U65/awZJkcZgzwmiKALgiA+waMgxbPDV2iwgUg8Wg+yNh890zY5n4giZCR/G0xgRP1 3QbGHVV0cwBShdi2m2ImOXQX1wF3Vg541BGATJ2sJlenn0GIZ29413CUXjGYKeVDMLUkjbP9PwRz OkKeAYD2z8C0BCS6eAADBNw4aKYNMr612AvcLUdn3aHtd994dhrGlHjR++4mAMsW5dpSRowQB/tE EIjQkor+/HP9AF40pCkNOgPt84r7H0OsZQIsF6z2GaKceC5aKNcmgj1T3D4MgF+CyTsJrkcqXvd6 BOMmBerG5/jeo8b0hOuI7CI8CCJf2bvEb5fK+T2/dsns/Mm5EUFqfvqWH/xI8E/fAfQr8MFu8Nbj OeBP40Vt0DO7X9VzkKo0Jg544Ek/KhX8hHnOEFWTcgyFjYAi+e0lwNO1n4X+RrKTRaK70qEEsiMM loYSqdo7oYTD37CVFNO0WNV+rlyhwUt0Y6JbqaVeoeB19DE476RT13sf06fXAcd7uky427rVN+wd zJV8rnY+TX9E9ILY3PyNxmfZnGVurzW+2B/E0jt3Xg7UTzmjVWgAcpDef/UO9mRa4pdJyxxji1wj GFd9zFn+EChqNI4Q/RbyB/TGHHftFbOQQcSfPaFbt+ae3me0oK+aDyJXpZYWD7kEeTNZozvroUzI IBZFedd4pyVewdx268t+QyAATSyUzVVSiJ0doGcizegdZPLBDYWEIuVDTZWivC5z93PdHpSdXo0E XSBn0gemPdgTrbrExxpKs+tANZSEoqFv+liKGj3HwfGDO6Fz6w489d52Sve0azL6XVfERjta6HCY e2Pizrj1F7vQ6qT+rgGFdyjYtC+v462LgGTCRXENGWmgN9u9FN8lgSLXs07UvZqYhzRHuHhJGoRM wXXaAL+CFe3i6hw9UmWftXDhOfgM/VkDq1QdHcHdmwWz9zmx6EBg7nTPX58z8sUXSbp+mVzCKogx pSH1LVq6N5iRsyJzMVVjGiPXoVEYy/0sWR8dAnD2d4AB0sFzCGYAwx6saS5HaDhTpiDbxiyy9wJw uW8Iy0kE+c/goDn11MHnAS64EneIqzkYlKbgFs/addbYg1wbp1anCzbwac57IO0GOU1MNW8glRSq CWA0iDzR27jy4g5x6uJ9RR3WdQR+vgOULM0Abic1pcCQko9HUzkeFefkhrL+87//r2fmf8h91MxN ueoGHrF3/v22/xNDESUnpYsE9aQlub2goh7JWmdhgYCNOtiYnzPhz9mnx6DLT7WimRTNpjHIet6a stc21j6Eu4W7bv6sm35AwsRMwBvAkTO15r0H8yQQ1sIz39/3DsBqMt3sniVovKqmlzNwaFTf62+k zrzajcEhMcVn4tqINSMzZMzzGpTwQAihYK78RiCe2rvty9Ti1iVXRrv54WN4d/t/TeBvOXL0czd7 EodHLhlMjHoHlTaEzBV79xxqz/xWV4bkgc4JGyv4gY58JvVh23wlfr8meljSKG7dxr5/Y9i6DqBT Kj3lJf0cuV3ROjNneH3K+fIa8vict3kXvL3lqXFWeZtpYlyBJ7eV+PDtqNIQ0dX48+ljTWe6Fidp GG95z68/XJ2/PtMghp8rku504T02oq7J5bl63iR4UtfqGOAM1i806KhiDsTnhYI3ykTRPvBGWAkb d7wDdk0frWH9201i7PrSN1Xri6VUwe/2T/qHY+o5QSBD8b2n8GY49NYfrdx78Om46vBD7nKTPSnl j4m2V/T3JUK/jy6lk20W9Tog3WnMKcW+DgFPtNNTotmrqL1OHa7F9fezZfEMePI/ETx7Wk7VF42j iEnYpnOscKMZzaZm0GXUCZT9OLF8OYTSJqVJdwZacjLoepQx8LEFtCpTkkYQdABAnyjsnrXi1sh7 3gm0Bj660jI65CqTc0na6BAJzTX/BctCfj5USpJY/a4JRRPhD+Be6PrTBR2XSFdxkFC8q4HImT+N p/alOwiW7t+PkWuXTtHMoKPRlPP1eTeiuKMmWyAAlgGjlxTasSyuHoNNMHeLfBXCMl3mNtiUZ5ye minTBIQE0ERU5xLprb19pj+B+LhilZ0AMtOiyG7jrgOyKe4IThhgAEHRFFBZ2AfCslkPgaepmXZQ nVSkL8DW9yz9IlwSesGZd+/3KYhupEElQ6pwhNoLIsajUHaFFJfIQywSeYHNr7ulOfQIhxnzdmES aLD28pAz6cwcEVIm2ST5LXDe7+c21U2KtJk/cViQ1PAtFdQMDuD0WL4lWPCgW5RKk9Brs0PCLyCp 14pYcZqJXqItqbJiV3DXkZPttj3zPcagIbH1Jcgy8tb4ufNMG5w3NsvV/vTbSxgiHYe3wRo6B7BU XNRUwounDPy97vczd+DjrecS5sznpNUTXe+l9okcY5x7qP8M35nrzh9Xr0so/FifX8H4jc99ewgG AXNHpODnJkTt+yJq1EKsTpENvgTtTQLYP0fzd0WCa4WbSa2d4PQDBKv+ues0ef90ijG6kzS7dbBL C98w5EaWNXNGMw66ZR5gSZlCZQBfVWL8KOElBR9CUFbVd45hXF4DdI/OAmRVaCNKsGH3Vq29FVkf NuMBbvlMA7YG7H15hzF1gLv7U/4S/bBT+bcLn6EeTv8piv1lhOjKOC8ZL+x/VJCY5tZlrIUNIokk enfKAo+R7yQM9tjfiOV2hnLgb/M3RvbITa+skFXbXVLyK8Azz7FGSqTTZiUy3lQMCdbhEUDYQGyk 6++fM0dHmOEUcr7YpaJDYcGz8MTywX66IMIHOyBRUX6/d3hywunZk8LO5cLmNkbcrV0EUhTsjzXh VpnVlBEL5A4PiL81DHyqVnMm0vv9VZysiAC9I0VXyPFXqsSO6x7oxwd4iEGUKHICnIKVmcF3wqJy 7+FHv+tgi6RUBncjdl6Z2gSU6LThi0X8SH+DIdmDh+nu+mAQiIEVYYHO8KY5n+zGJ78pwC3ttuM8 gXxg3+riKq4wNRKgKiqulYn7bw5swAtL03LbKCLbkRK5E4TXd3Wg9WAElDWJi6zEmI75Es96et69 29JoRmUPdLf1TUtn2h76hfkMdmiGhiJ8jAFU81Kzh1x12B9Nxh3S9e4rQoAId1CpjOJs9Zxa8+I7 ty8f+D2uEoHEB4XyhhcDErCC6yT2hAD2HYyJARM7DTVqrzsftdEgspyaagfGZpAqrKEw85OhczQH iybOWSOmzENwAwPlr4iZWVJVvPK6Z1Ly7Nvf6wip/eDVDomp1u/Ic/zhXs3DwYb323qkrM3m4FHN kMKPI7gLgnjtjlpWGwkwjDxXvqXOb6veP5Td5jBQWNiKWg85pxbb/ORNOxcOdDBqM2A6mBwVJdQL ns8xOwjsNZO8Ltea6UqXi769t2LY1x+uqAbnyb+jXREmXwFnBrWfz314KxAyQHg5dhVTqv3vfPDW izTcesDD0sCLQ32n4MzM/2Zm/oWO07ngbnkunjvqvy7Nv6OLNxXJaTfRnJJmw3pSlIiwh0xV0nhu tUKGhKr93sMdDgz3m/BOzjlcxhJiiyyfQV1K7Nk4GRntNNH7VbqJk2MESJbp5KDhx4b3dgynWVx+ 4fUOHc6Dg5lH0zgHx8XS6EeXooXHErc8tb8RmpvcPfSm5vX6ke9/SgKaUuPpfGMPi5R/+GuuSFQx clfEvKWbHbk99kQGMXSavrm4lqvWBwM91c/e8txBB9ex0fngejyMpb9azZ6Y7vPnGq4xh6fy4QhO uo+5pvCpu6NaM/elr+7Lx1Rwgq9VSQ/kAW6FWzbzEoTVRaaEjhO/yGR2kB9RXekKTCTRMMefffuF W78vPYrZ/o7v/zR9+PP9RNgEmw9sXv6mge4eK/eaSz13kHRnPbA1RoMc7MaafzuHS+rjMei7wyuO Z9tP/XedJC9L5/RfhmkTnEsqif7S6F39yU9SJ2kfXnyVtZxXPXGH6HLId0bzD322/wlmZXlDU+8s nBsEazdZzMAnuED6CDb80zgLSONdADNRfh10HNLAJENwoiWAAoqWgI1Va/308H3BcvpT+vDXdwwj 9BhLcva9sUbXgZjnwVQIe2E0LBKLMx+XrD5/1wUZtnNfHiJ53LXD4BTEngKsAfhyUgN2XLEPWCIc kph8M3sCFgWZdwLO4RY7J5aWfWmMk4Zrr6CDs857mDNxxVOx6T1hcK29pKAq0OBTPudFNIXsEUzz e7ZDOAOMNOXOIl+6OoC6eAkjMwT7JVdBZ7EhkR6Ja9gb4TsWN58/tUY+ooq/Lt63EH7fF0elFPAW fs8Vbr7TlYMgg4I8dX3TrsFtvEYGhLFaUbnrW0vlOTSHp3s/fjn7awFf3W96Cqj1kjA/wkgBNOxz /t7CVIWyfJu7VyDhADEnagPBvvakS9r7eQSy+TYqt+JQMXKNouwmzuC/tvclsgR3czpBOtNj3G4R YYzWlwyVgOY8YbWbTecu1QILO6Ss1WwMxFfNcjtpEHN3bdt3V2/XG7DvSZfapxHX4PqmhmbAf1PQ RIW7MLkT+VLJBAg2QnCDXk2ss10T2an2fm7/Ar8kERia+XAi/NMoaXBPsWwhfeiFDucXyN5r2wFQ FveU59xjp68tpvUi05lsaQGcbwLThdF8Yr926hbFbG+yY0HlauTuIOVnFOuoun60/ohvIoUb9/q8 UmmQFQJGasubszXdOznhfwFkhUhzJ2fsodEN1QTFPOQm+9fPE9bHKaaBMbIjTmi9NMXQkS/7ruEy mYpr+ZeAW3/aEA1Z6lsWaEwAzm3oKgfmsrbowyJ9sJDJ9hR6NWKM+zgh0OkiarlRjOm2xqfZAAna 8QDCdlxI/QuWpvvtO2jWRAX6lYxvTtwD9ZsDP4hoWRsdqBw1hGGIgeiUfh92n8xrAMHOpj3FI8H6 dsajIF3ZKwrvIK7LBDWVi1+ox5ieQTT3PcdSmDhBmtzds8UZOkMeDgd7BwalFMEeAfzMHTqG4WIR 9sd90Ipo/arxJgeLN07jIdejlrT4xrFTtCxL60DogXRRCvru77roXpIwQkEBG7NQjSXoloR9vurY dUsOE6C2nuuESbt7YqjR3T9MDYe6QuZdfdD59RK/Gwt/a2utdUN7Z5MYG+dsNO6NgydBZuyJ1g1r 39F6XBQdtaMr4UOU/+D3EeJEgj7Lsd9C1YIyzNFklDTeHW0fb7dK317o7g50+RT3bfBskuFgPMsx UpeDKYN1Uxtz2OZIJFQmQjOHfxo/Ucfl43zETGHt2GzVOjMHxnzi1Elgd3Ewn7RVEpOg45oPRulM znzdV3smL/hGqyVtKO5OhYGNQYCwzaguV5P96it8I1y/Iw5zbw5zVPp2LhzACCAVyjMD3tg0HHtd ZGmIjNNXb2/AjvxrvYYLvicF1I25nXWHKExeNjb/1t/p29vNGTaeoZMqO5tzBj6EBug4KWEmZYMb N7hiNnJZ9pDZ0xW7ZNKyogcFzktfPUdmaxkGuuk28RE7K7LvCAHSBzv+Cit2bRzmUHhibcET97g8 XNXMsbjrbMPaaVfgmiLgkIJTj869o8GGQ0/in37BE9tdqpOc9qPRYCE/pzURKksCSqF7vQDf3knD quoBTjHzSeka/DtZ/3d8ofGAr1CvCM5MiTdHcKXGX+e5zsLa+dCETLyzMdXVLa07cSiqz553/v+d 0f+sDzBq13olUQcEq//6mflPzsy/jDKyf/pcrj/eR+SCMxprknaWOQaOZ/bgQmKwLlz+wf/eREyn 5zALGidwrMHzLu9c8jPOXEAyVkphXw5PfrMALv0bVQdkQPImsV+F0hb4euYjyW7jQQKzr4mhG5ea KQdyXb4LD1atOsQXI3pOykgQvmkTxnVtNEssOFXN/P5IvjN3R1ntXCluatscjsn82QgbYLRxNpYH Yt77dzfem0ZhaU/iGZTc30GnYwCiTNAh1vXiR93kw4tXT1PaHEJ8/49LBdjtG2jUntJG52iCcmf8 7AMfzuxwq9PsC7X211ewTjMIXrfIe44coweVt23k+7WefybqZMVjxGibcinPnctdcMLkK/PwMVYg fnxwX5PBKQ2/ommqEie76WHNFBdPMd871UX90xnhbo3CYwiXl0GuYHGC3eysWkeC5nLzusmz84+4 RuIxk7JrHaVpyuIWlAYp+5xJvcxOptzn2T+yUVYVRKpeZjfi7jZKX3Hw/hSS8EKBIlRXOOC/VQht oXa6e5C7sNCNnKLAdMTfXk2ua/tnKDIdQJg/iz1D09u29Jf7O9GP6eDi6d7XU1yIVJosx9N/XY54 uv3PAncmEmyHWn0Czbe+0hIx7CLxBeduwfNOvkR0p8RAggjEysu6HT7+cEsdKAwHKJ8fUa2hmdyA TUjkDXJo0bM2Frg0oQrHaFnFiqZ2XfGlYRTSws0h9vsMpB3T441vo/9NxlChsMvWjJJTXesweWp/ rJLmIrZdH67rzlcDNAhn3rPBz/TYYerg/kFHCOcFnc8PYsXQ9bMFOZ2BFBC2u5IM5Pr0xuk+Z8q0 0ChOIYn1Bw6xt1n9BjPbHhTcZ4rvJSX4I3DwSqrq/q7Bhv/WBIvIEzdlG3B4hDKiT6IhF3gB8O0Q oaicx5c4zSj5StDan+CkwEF/F6C89pvf+4DUIsHoNgXvPZkrLtpVYNeoasQCjC+ylsmLKZDzFBJm Km25h2P4eaSwU0BaTRWb8L/b6R5TXEBvBBTHGLY0ICHg+DrqX1HHddtRaZbC49xNaHSk/9KJY99E q9EpY4CeJ/D5Dku2+8LhtDMAa7t4t99zXJ+O23kmhYum23q5zh4+BJDmxri/BLtrL5b3rEt1GRCX X6E9CVD2mfSHBAKXGv3yXHSFF6dBvm7CV6iyhVb3DDacu+la1l2frhhjf/J/MS7OeB91AdQFra/w tZ1kd2AzK/45InWjpPimIvRTON/noLOGS5Df7eGvi8eiu7zT31pHrCBu812R6HKKo0cTPRFh3lw5 k4B2uPTTsAAN4cwfkHUT8Be3SLGDw6XhfV4eyu9TrM1BuLucNd4gnMuaYRes+ciJ+YLXhXXufDj/ BSHzp/hTUgnmUe4L9rrUEfbgvs0hV+27MMadFCI5lz7xJokl7pKDyc1BcA5oqUOgcjwxuKsMuZ5Q suRNfSTc5R1O0BmiJyfOU29jOsNA5XwB+YsPZQ11kyI53npinKLlTtH4fE9wEK7yH2EQ9dbH+fiS cx+GJD/CzYZn3PPI0fNp9pBy0DcS4qwXz5pI/VRNdXxv2eUkfoiWnzTOiRBcrpraoE7WLlmzD+Ax nZzavdSpjzWTAvy8lzw75eaFNdfd4dxPV6KSA1SNiuZ6xgWvUMVxtkPYFAfWjRNM6eMVDpc5ZJHY oopc5u0jfogi1Z7RgAVk6qELsXtqM7vcfVopZa5DaoyJ7kHbLRlDh/BbSwfXtCPO91CPP2pI4HF8 E81UqtSWOqkioCMfZJJ1ZlIvigaVdcR99oLEySVcB3xela8ZdM/Mm8dBhr9mHa+Q6Y8DZa19bteu gz+49Mj6MCJQYOhzxBQ3IUVfAwo6eEvBCyqOo5nBDhoMLV7hhlMcsAdOe53r8rkEYgS8S0S14u7c 7mDCXXvp9Ccw3Mh0kRdTpFS0xcE5175rj5XJU4htavO4hBBMTb5MTPutmd/E2lXDgoC+STQ23j7T RI05Ck0pfFP55MsfGd0b886+90r+byWGDIz5ruVVvRAvx94wvDcp2oVr3u7NmRVmdK28ZgBT+3we GiKBx+vmahCxvphH4VOK2ZGDwyXEMt8z8ZPdjdOY0AfoHxhPuQ6y5XjoxZpyOPOnvnXF4/58Jw/i BCnj22vit3yxH7NG4cofND2b2q+F+OnlzvC+GUTcB5NurqDOqxYcwBovHvaD4d83NzMz/+cZ/4+v PNEf5leDhnixA/+rM/4P0dn4ClFfg4BrVCDNGWzg//4Oy+tD+L56bL0cFPeEBjWGYT2+eO+PdMZR k7myuzr14SN4LcnHhF5w3wlDhrNdZvWBh/IovSqe3RIRQ+MhZg62iDb3dzwLTU3YEGCCA6Z7jXnf 5/ZMKn5g3ypxkx9htHKQxobqWeCo7rnpQ2mSoA9j0/b+dIzxWPDt0AW4KiT86Cp43ElnWInSxH7T RKT7/etmLDDHnUiVuUM8PXdZJ7381jVg8bSGA9s+yHvzGsnsvtCR4Xe/xyBL9FPyGRzUKV2URe7z iekM1rrDnVzUCIPPvrMucfvagRNfjPJrPJH3ioG3PMnba40Mmlw1ZGeQL+gahMBeltHB1894zZXy GVa+zoNV0uLTtfmW7GvbAOO5R3X1AL/ffgNDElzD/5ybodNd2oovCT3Vq61/4j7u7anr3eaWUDdz jaIEyiiH2SLtrZ78qi+Nhd/aYe+Jf7Tl50/LeILqbgPnj5ZfARjPTABWdyp3TqknfJGGIsrTxdzk Zp1E3G0eN1ifr8QRXEKg1gY0N8mjRRi84EfAmvaw78sXwPa7WIRiq7K5zuaPY7i+pkeJrO8NXLqH 7+aNo9VU1sKR7Pk6BjrcBi75fKF0CowwHsONiDHsre7KTE6vu/iBZ23e3+TWJowXydn3v9xT022R m4srIqJodYcPVnf+Fp44P/HbNMG5ydVZxfKfCKB2CYXwhS+aFG7sSyWJLAPcs8+b29QKouPdPAt8 AtZNwl5Pc6O9jkpazTkNNLR9bHTdJ5+VTXgS0EsT4jpCswsbuzYar6gAAk0nHXsF8HHKMoQxze1c zjisdq5fkb8GAvDAWWtNr9sMAGPheSOD9/m/hS4N9Kd7StPFSDe+8cvh69k/2gBWOuRtJyfO88jB huusMUEmGhI7yK3EFZJLgqv68U13+DSC/b1R7+A8EbF8l/kYU27yqjXts0CL/NPhCnCVFPPjUPMC /ElHXRe2mTt4xJCKzhTxJkWTrG1nHzfMJEROoWgKZ3lnubi8pXjd3aN9+jzwdpb7iqG/Daph33Ly wQCV5AI9FWGThL+nxWOmC2/ub0532mCNJ4PfyFHiUmcqIKei93LUhX+t+5sOFLvNTB/6EpxGL6rt SupZhHM69aeY1s8Aqj6A5yRV/ADOpZ9zDzk3DL4uCuWJUH/vjdHHegaB/xWIEZGjqBrpVPbcI9/F Z30LUG4Sm8BF/fg6u5/zCcJy9DalmmxC7UcYRfvdSMNzStlycgfyZrsGzLzuiNtJnwcRGNTjCD1y dJszZCRejb9iDDNNtKI7538i6WfS1WgTHwJhQoU87YNJTNSFWf/te0LopEPV6wYrXxBNC0yb8qwA 5PdMk/3sf6BpKUwJNGcaihFjoAFwOvEERMjFVbwGyF2sLy/ofAU8KUq7nuFGwltEcGtWHzjiXhGd f5oAYtX9RPa7uJP91lvxUOmfNaqpRMb9DKpxo2c/fzpT5ff0R8UdY2E2A+D+zbYik3fsrO9dxkGl mTukILgfqNsjd1Q2L7hI7SWuk8D9ewITb6mjlESbNjbpualy+bOSQJyogkZ55ymMVdLZ3SHC6OkU 5JqXoiDwzw6SYwoR5HrOCUUrG4PweX0uZB/dDv74Do1yGrzht7hlkZGrNiT8WL9++8RoBcLfdHLz 2duOddZR/rcfe41x7uDRFbxf3yzdRDIl+fYXtrYGdtywI4ocdmGD6J//iBEVZ5BK37tNOJLIbik6 cwjaRmB+EcN7OJcGEiCnN+7CHEr9LS25iTHaOkrMMuuJLzfS/N1CvpDGH1/rbn9KkPS8yxB5aWKQ YQ/inRrEd2DCGHu9+R//iof9Zj01GG7+7AVfzDs/dwh7h9zyaRi6DfzQEOceKG94rWv66b2DFIPK wvxmIU+4zBTsQou35/t+ZBU63ZNotSYd/yed+sVMcvLoxvPjGtLvtLMaOP+kmG5OaQtrhOh1H2hk XDeTL3SSv37qBhWEcor/7Y8wfffwXliMh0SAJO2b4bHMKX/Ghd9KDJLdzdfJYBfpC6d6ZN94zwmd ES0XfMzVrGXd3SIm3Gg6sNe6S7/sat/j0IGoYHLaNSFgPfq4V3LYpOkE9NQsW2x407dZkJyJqYSb kPvvj7P9gJYA3ocEzpXp+JymJonF6fIuuomdLbnciGcJe3fCad//DgoZ3TFu7OH+D575XwmYZ0f/ 62nmlm9fq9E/ZuY/NzP/KuY3dNLif3q7NHP78hffNfLrqM75eTyocVETGrHzNUa7HOIj0vuDy9il O1IZa9+mZr02nrlJ4j53x8K2J41Wbyrj1isMcGUwvmuXczhrhTe1h5I7jb0mDVpmjfJqSoR8fR8I Jk5XIZz8GoJ9noV3KtGLQe6hw4nkJqrnUrGjP9qpxsbzqNh3r0HcyO1pN0czQ6JoHdRNiHa2xJGy 002Yy77bXtOuqwPZJmHb0PabCQMDTrFBmdBVmnHtlgv4Z9jFXmkTAlNg3VSlMjDwPtd/EXNl82D9 soo0lF74W4ps11ctnuP8s4K2zFS+6DmjtLVkbE4C9arZRKkZGDssIrihvuqUZg7EKcX3HdF+bLyJ oU/hHm19V+XqXfdaYHKNCyQ9UrrEt/o3xy59Ele/Bh5amqEjGf4ddLtaZzJ3mI/9lsmAd5CXcYn3 bnx7UuJtXAwWNpbvrWeeq7PdeMytFYIr9eE+xCnrHs8/XmJvPiAcinm8YMEU8mgVAuAQMsPTi/vP D8xrfjuetjl9Fu9kAaQPt5Q5TZoOUERS7+uAKCCRiFDIDbsbJ0mFEB24+JqkgA5Sf4CaLhSgIBJL SP8xGTDTYjVeVz7D+IDRRcAlNNALXXJMOd/iNC9RB4H8FcOd4k2O/cupUYpYdhUlnEgWX9A9ifbB Q/QeyCyQ4/8YCtR0x3oF8gOR4d3d8Li0zXabSr95kiDvSbE/Dfn9OdrOlQOrX+ed3Mb7Bre/QEZz 12fXLMd5c4nb5uJzmPYihGn7NuerJlw8BuJhT/PrCTF1dUwAB2GXRpXjzfckdtt769mfIv42RS6n 3wWB7nT6dtxxEW3oBCuptNrzIYLxh/+dB4d0tJ0EaN6aHNfI8f7HPct/AMX7fVZB6EGByz3dLwCa wJewqF7ehyD6YCHTifT2lHtzi9qbA9w6xzUFrH6m802y3g3Wva5uLPNXAYdoqMRAykRWR7kPfidN NyBMjsbDYmu1uyZdcUJ0+wyszbwRupdQ1gMO/sSyrfbJWasiOWh654ZI8R7EyS4lW3xy39aqQdQS WxzA9ft3VU7x+SQgj2h5yCHTXAs97hEYLBrRrOk9JZC853lAGUnknJzk28/H9RkbIh8+f4gTZ98F 4zvmV6SxM18Rc+x4KwAs2Y3ndZ+7bo/vGhMIFskv9j1nDb6z7PI1Adq6OC02UH7Am0MiP4OvocBX 6Ej9CAdxzhLrD4BlzfHbNTPoDkkJHB+/h3+EYBg5jDURGvWeMUx4gIh7sqkML/45S0ut8e51FzyB HGuZDPNyUpnjauXj+j6FuvMB+bQEQZm8FtgdrPWkrVvykUsXf8/fFiVJbmosTv3ykfshJ/feS+8F AQiZfcgFOhvleevC+XTUEfSfP4/wh3RVhfm3A+wAmH4I21XXbXJrgY4G0O+6cB4CcJ07znVIgyss ShOsTa3z3iCSEIK8U6QiTEap1o/NFSfHQPrQPwnQp4hMkoR/nauS/NmxsAM7xkWggs9DqsjqjnNV 1OMUkbrdZq4b9SyC+3vIeAopzrIRx/k8Ib74Mf/wQ7Ly89377sVgjOeQPl2EeNhZ6HOZvVIkkZwz +w5NvX8vpRYqCKDr3cW4qSOa+3UaVggUPW3geTsOZ+XnaUSTP3gBVbegG4EuRD0pn4FJ2S0Y6C6B +8yIKUGoLkPFPc3xyJVE1nAE+IS84X6Yv2rFLTzTw/Hpg4OAn/cHHxg4f4x43pd3YKC4j5v0nXn7 wdp0nFo9fyed4TdSW8DVGEdxnzpHSRBmsDsMhnyu/C1ScCR+6MEgkjfoIqF9E4cb+i+UPw9tshyx YVFSMn9EBPc7VzBMPmjykak3jLH9eX5qeZ6Ce57z4P4aNPIRQOa7EeKq0Q/bhfOYiNtGBGHVpz7D ia3yIsOMqbWgUfzREive+4I6iDPspd9OEQNG7Q9P8hyGlRJjHjQOeN/LPe/ZEZJqCxdTi9tHr7P5 r3kFcx8+H53NaGC4K/kmX2GRthBEZz0PVK3bIdHf9fLw4Pnr6M8dRxnd92wzgYpiaK8/TKOdaSlr Pzgwp2QMVnTszt2r5kzwyOri45RUioqoamS3xiZq2+fKF8agSIqavCs98BME7+Py1wPnt35BPPRL X3c53Z/+W1V0k5zZm3A2k6m+NGS975U9GCzA7/701vbDPySecQdnyLTOBQNhsfF81OGZSJHV105p I+4o0+S+atFMUJ7JpMXLhf7zn/2vZ+Z/dFOD7j6+WFM3u5nx+D854/9gTzbo3fHr+M9qJLpVH85e 7RydQOL9MbjIw/YXyyadiI+B5gAW7WNaBemVYk0Tsc+vFiptfdiLOb6bLse9zQ3J4PRN4vnqZz08 lN7OqRxwVzi9x/BtdcGmajrNb/xR/d90zZ+hn4d/164Bdc7Si+3raFUGuJ9MfrspyrR2tYxAHUZy yTVywphD99aduhuGQYO/gzu4DYperoj0G6t/MwwpK+/iZB98RNe8MilDcuKsGDhXYNAaRPw/CUms +aTPrrpz/LhVfynm6HepIEapGXk1KIldP2vGlKLxYpIq+/RiUSpc7SvEJYycUyva2eTgYN5VBHeG mbvnWtcFn5kYDlm31+UP3XAEgwnd20sL9yCOh9lxvykVd6FBYUWX1+c2mmuRSqJ58utjd7IwngaG 7x239+B+dqo8olD/eTXIkZX9F2ZcUpfIAtEf/IIxXZH225QT9dn/S9hu7N3/+nT/2FO3zcF3oGn+ mtI9y0EQoyyBZCFJ3D+AlE4B5RQw3GiuHaE0J+Yvrwii+XopBu63boWSQqr4UxTouN9RVPoE+fVN WmX5UGituIAnytw2kQ2HoAYaMAMwyEKlDrEcVzJNTHOSKJiexm3IWwDSdYGmxldIwF8pmmrD/dfh 80dsjeSvqywiZInkEKCvCMX7yZxTnuPazm43g10+vLFfedCetsdTGg9XoUbG+zCBtSQmdjQH6U74 TGBXsscopKfiloideyF9+MzHpNQVORhJP2MjStkdRue8LAB8isbdTLbG9zxTKQTSzS1uTnxcXv98 maqSgWf201ngSyok9QVDafpVOHP+12V8p7wFZIBwsETgQqflYuGg7xLqo5hqFlxRA6XIVbBpzUz5 Sc8ZFg2FIu5d51sICqFOyjbX6Q2kOZw7FU3FX0TCO3L01g8+MaX+ELKwcONCQF5TrSFEDVFlCjfv GdSdN8p6DSBKn+c++/edc8alySln9QWsP2PpTcQxpX5Q1OJ7FmuBY6/bzAbN2ClCyhXZb48mW2Cq o8VdMSnmFbveXVsGo12/m+ppgPRclwRKhlnrWvts2QLXlv5j9AmfYdH2W5f/NmqZ9ZyBLP89dYGf 8o2y71RguHH7itWNzhHXPWJPXvsXQcV17uhVyfss/1pneqLo9/1OA9F5/0yhmr/JGwE9sO+kEJb4 DgjeRJevc7Gs55fUXjFz1GtkraQCwiY44ujb+O5/hVMc8cuDvHy6T/GpG7X3pI/EgX8KTDxAthPY Np/uc37ShHI9CCX/fz7DU59NXZ8bSBSAUj+1TLomXaFsEwNssK7fB9wXGEDEJiLjdDN2JKf+WOus cbkPr/vxdjY7JJco8cp/g7TVqseuu9HCcETO4SpD8tQp5bh766Pf2lYHGxHs/z97tfY5231/IgeR 14nxebZ7Cs4mF6wIxOeCfmGv/42psHAz74q/ny0EHQG6oxaCRzPN7IMHAffZKRx4pphswDWW8OeQ Ud5YGZGV/sBufQanmKgF/+yPVCM6xZZ8T1qYyl89P7lHEv401cJBIBDZZM9XVoPdq7g26I+xrkvA sF3Wx5wwQcQL3cnLmXelrBR3nKhdyBWUMdTszNNxjodVL47uQp4RsU/uv5QUU2gk7cSSOT+7Od+9 /49dcl389PyBsxsIuLZmFYLqRd/onurfAvA9nEfuy4kc92HxIhT+wFyuCUc4jca+ovebqPz+HlQL 6MFnBVi7kULeeNNNeWCB+cAqvI69Ep3HPZ/y3g9ffsSZLHMHPAg3TIZAtQfxGtJ++4bvVEGVnF4d rGWC9CVXLuPwXMMsuls9n9lc/6an9o8RkKKfvi6n7KY4y6GxJRQzvr+FFc3rXMirXZwB0yj/SoH1 4Gj7xPsTSjgu27ZECKZhq87JkUD021hjpqVYKGLifzC5ZuiUAgptbqPcUMlpejkA3ztcxaUxba0E OVf33v7Gu6/RkuF83X+tJZPMkCBxf+pmxcQJ7C/vjT0fvL9vTu3UMj7mU8e4ipLbvoQRgWeCyUNL ghvkfYF38Zu+PXV9MS6j0sO9KbvpVn4RhCmMyp9EVAnr8s2btsG/ywX6g6tRsTv5ktB0g0AtIace otmTiT2KnlRr780Szr24bK5LMo/w0YHsjlpxHtddm4Q5VK77rMn0d2Hu5k4A+kz405weoek3VDme r7yF5zP9bzT6v759uihV1Q55NosvNRr9Nzzzb9+GPK+4kxNeX9OjHLAj2zsNDeWqpEOS8Qv3rIqE lKyrhP2JUM9Bwss0F9pryYf/3Wc1n7NfyoyNDd6dfhNAL+fW8KXvm5/7UO5+BPy2f9FacBKFloEC u8hf87t0rX5+gw4ao12X3nTaKVidTS7HhrHEec41YCGWf+jXEA6t6Z+15cmRyFdzwl1teyetG+hG tnQfb4NHRRWQIlvP1lbN4vD+DJmdJLmtq1FmxkIa4FeaZAhEK4J6h8EI9W6GQyBkNaN5juGc7M96 IhxzRGxe1VDG/Vx+DO6+uRY+C9LoaK+fngrfk3v9kddHxoRso7DuHbHp5cX+0lxFUZtTEjqybboV toqdVJoSUD9LI186fgoGnvQOJ9sDz/j5PMW8Os7Mj5TUP3WJmVMVpma65Fmkcz299/W8DfeoBrvI m9Chg3Vt7EHHPk7FKDTvK4Et1t7H/si1CVQjstiuxu1NU/mHQ1CRm/w6c2zRHoyFRnPi8/AGAe0E NptPqzH6OYRq2hM594UlcTpYHO+ieiAqZv8+vmxS3qhPcoBgb6FPbxb35Hx8f+Yzbfk0s+mvpvId WNA6CEmdiZviHMg/Xx+rgUCHG2s1IaQKd1fBOxU14tQoTHVsVYhKlNM+eotCiilVEb0AWKl6zf3Z M1eoeY87ntHZKQdDTvZHoLlFmQ2s0iM2AUjNU4YT7gVGs8hHjuBHjKL3n4MzC110nh0dXYBcY6F8 yDFNkDIuEVVCpz+F06dLBO5X6X8JIz51nlUGbjrC5AeIH1RxxPclT8+Jp3Rrv0FiKeTojY5nO8Rw MX8nCY2EtZHM5d/9AoMk1bzuMTzr9ogdjwD752KPmeL4+y1quDWNezDDC+j8C/ghV4E7OPCuIUoK +XEgNIJkO27nCyi4SRi3iXW4t6WToxGIyolcJvW+ppBb6oMiarM3lsJzOYnhOs3sC75ul9ovQcoC tUxuSulUwE4wCfIF3OROUP2JPQvgx6vojwbPVCMmVHhFJWaZzAGKEmq/A1pC98S88zt5NAcsOz/L Pw/vgiIu9SjtA653HO7eAhk5Swdmfo1Nf2sGM+VGrhhvj+Li7E974ltIm+QMDTh975QByUUfiYkT X8I71fAtfuq720/1COfb3HfJZ7qV/Hy+C+K6APqcCjCfTkoCh8x0xmsgdw5fFGeUKihhueUfd/7X GUdQObkB69/ur0z4w3t1Vnl/et0AjNi5mLvfIwwxr/6fOMa7nI7oYA183H5dH2lJNPBD9zsLxV/h yT1JDE4uuV/0IaQRJHIlECt0i9rYxAQx5s+0C4oNHfQthpDPIzZkJ0mjE9eLvyRwqQAkVz+h+wRP vOdxVZ+yF67D2pcwXiURg0k4zxRn6BxN6sRYI61ziOt5JmojLwZk4SuRKHG5v3qve141IF5PxHtz SOuCmyMsfVNPJKQdsp7KtStwjnb1ntcZlm9usS0U+RItgr2QpGRWOzoJN2nG8ZejbToP6XG7nZNM 8r3ySHTsD9ov7iYRYdR8Rq9Qo6dEqhLFqkHpdA8qRJwk8Didki6ucs/ZWf1Pq4svakMv48VXXARf tBbeO2s7tma0Lt19ivTHqUYIe/iPh11uDPkiaUWDHOSctPcJpevZU8T/4O6llAEOOvozXp9iDSGe Q0Y+b5/Bo2lbFLt7fNUkQ0qgomGuS5jnsCmhAzqJCoP1TRJGu9b03+j0JhBNUxWOnMtrhnGHg124 n5tO4ngzPi5fOBJ1XM+FUpuNYe7a6yX0hSSshgZpb3VwnblJoJ7c2xH0QeWgXxBFPzwId4fF+b0w PiQcuX8kblAbarEk5fM+/jJ38Wd3HSvwuLpvQa6wEiN8M/PnkmfkdLGBrv4K+G4NTEYIpwqVVs3O 3rOElV33Xh4+8POsdHBWlzS6NfAMGDdzygd/N5lAXR7zetHP38BeZveNHtxzG9M8+955dno2JpdO 0AMO+PobvIZjqHYqLn555G0AcNeg8B6ewgNTvZgiJ8p2UKROcU/tyqmJB3YBw8ue/ocL00lXvUYq t/Oe4NIyfTvT239qO88elpnHSEgVJ0q8w4gdq5yx+w0JjBrePvx1fV8VpP/ueavgi2kU4ysZKISv CXbjulMkU55zC+5eh4HVY3AVZn6ESzD7sXiQjz1E7J2DZ9d8Gz7tYdxW272Jbtec400Eu8L/OTwq 1+40oLkxRcGd9s+18v+cmf/JrXcyB0TLQMaeDwHe/Ntn5j+mmX9JYhI6wrzXQfXpIUVGByoDfIzH DVqQgWxWeUq+d15ibEazSBWptIMrJYdtryvYK52a3rVrrt/XefxXX8hGqj7mloM3x4g4qryfL3o8 qB76TkZkXF3ze8ICSD1t6MMe/YGvQJ4SsreeLuvAL7RwwIDwN7ZLXH/qcgB38IIR1IUFiMZCBIZD +jQhMnL7hrsvV/0dohjYuTTI8OVXHDeUPRg8RSkKiIu17k6Ha1cMQRKm1CrkhhnsZNfn83jv6TZ+ vrlEGvBix3nOQGDTphdvana4ArxTMMy5E7hPyu8dQlamJhnPEzbRuz1xq+kSxz5VyC/cSBkrLSve wyYSzKca8NJI9nD+HXJy71krqu+6mXxJhKX70YpmDnlHhZqJhJ5Ba0+aXr3YZ2KHvY7SzC9186pT kQfod5TDGPS3gVajWaMRr9jvnAzKM6chEwuKBV/hF/7F//aPLVR1gHKKqehLRJ6loJnrBn6F6Bww pBO9vZtEATyXgpQuvJoCDJF4SThxeYtP/gzNBewWSAm0fjm1U+yBOmAXRBAX2QKHcH0Amyye0fdl HnLE3QhsFwya5zRChhm/zp98X7YXFFYFGNE9mkQdKGicaQ6O0YjOVyAteY8YwQV2vYXoGm3nz/F+ pyT6eKN1p+6/VgBraDrU5xnkRbld8BSOXs0tdg+9e66o5vzMa6Az7KgnXcAzKft0zDhQlPm53EZq F6MfQ0Vx6jSAyQjWvk6sX2QhX4Z5zXO864Bw2X8EWtdhSyjwnbnTm2u2XeRE/3wLk1RyRxbRlJyx oHnOMc9c59Gc/xsg/QjkMjoC3ALfs915bgP7R4DkJFcZGDSCoa/LyBqEus5hGPm77/+/xPcu51on 7FyB6fvNNelIteAaP8S3VIR4M+wYOPUOvU5WnEIx5wyYQqI9yQk2OBUZikgnH4SOM2c9/DkWjE3A YPufYpC/1kaSuELX1k3gnncToLF+iRVUTRJgKTFFfhpOqoG7tQ0hXLCVCMQkHLQGC1h0rXdtQzNV I2klvKH1a5NiDNIk12V2yedovOZsz8Lb6xokmH6md7pB+R9HpwS6BM5zXWp+BQXsX3xFqhR6jkSV KYL7ayVn87emnLX7ivf7N18+z1coNPR4lTxrketXXKh0I3SuiGYabvgGL7l8dxDAmJ8wnueeofAk 1Edwyf0IBULv3ncHtGjgdbnmDoyWmwBm6lFcYud3+skd8HrvsU2QOQYKmlfmleMogB8GsFP4QhWw HwHYnf3PyMcNcHd3wWlgirubRu8GeTD3CvlTpMufj4baNpk4ky5krmcTJf4IepcptB0RA9wzM8EI lOOQazslMdHdvipyE0Gs+TsCqVU9mIgwFTLC4abGjpf+EHW0+megV6Cb0gSpxz34m9MqimpNsnR/ VGeZYtdg88RoXreyK8NsPc8mpNeQ+3Gnyx2vUhe1b2eICjfUsy70gqP2Y2chgUjDJb1mD2y69Zue ldjwir70S5LAAEblcc1qsemJ77vaeNY+nxoEy5nCxJ/vCvl2PP0PMajhfb6F22dVrB4L3KlEg4he ggJaK8J9lGRZRrs3DOiIu54aOftkxhFyIKe9b/CMEiMmM/NLT3U/54v5/JDma/9q9660+oTppdqi 0Xqm7Wjdi/W6iCpo0Mrrc/L+u+JaulNf8Xj6+Bvu9XTH1akHjViSfsl8JWe4RziqQawl8B5fJ2wi wdKHN9zDwiaBWCYHkxE1jAbNImbaQANjGpq0PXA46XbfrynOxMb6jg1ubldk/zbCPuhYOWfPz3GY FAws/kbFkpnGOfEKb+byvZuJhH7BKpIr9CGzM4lgV7hkQrKNewysp4AzIXOkdJNz/R69dxhM+J0w 1frKW22jmT+b5kbcOyr3P6YqlzdadMId3B7kAnJhGdfUHmBnu5ydbqY4+zUDwwUCHESIFL7JbEb7 M5X+LTG8dCjtiSW5YvzJPf12vn118ojsaNeiAg5owKEx06/TesSYlj2cZK3XSOWLk5jlcp0pdmf/ /sWHuD+H6wT+nexn1EWEwYrSGknAWZJs6q67PwZ5pt7fiI9ecc81YptAHfLsJzMKY147p15yT7rF /NdgBYdaq3FhurXnudH5I3GX8vD0uX95aGpzrcMZN7DH5jNV04GosinE6n3PHe+DQ0Xq0794f/2f ZuZ/cg3J9CHwfw2schBjZmb+SzPz7x2oJ5cYzYxzUb3jc/bxQJA++NfUQPiDq33PEtKiCJGTgSrf 2HNPQR5VFSWuWa1NiM3mfukc7hBGv8YhF0MQfrbLP7b08tUp2IePMOBDbDbxjYjuFKY/e1mJ+Sa3 NUf3IqyLv0bDmi1E85XePNbps3xMh3x52y++zmGL8Sbh5p2iM0ghSHCYqHMo3Tk1ff4Q+ZIVBmFL r+mfoLt4B3F26nLLP25YdQ4+0rDVrWGfT6pU2QnHBr6waRfE/jp5z/CIxUF1TYjzjzYw2AhTNfnz /smswmE2IKwSOUslB0+p5yFcxjXVc45pRfYGr0FN157cu3j3yO/96cK9oMGi83foIxk++FJ3m+J1 xol7A8MQxVff1PBhrtvvWvLCuVyF3clqeOakM8xco8fUq1La8MAdSfwOc505vHkHsYzoD/fAdIOR zuumxO06lhIQ3mRFHYNmffXYM2ieNIfLiCrtn0vsH3QAsavXiTjwXVDkM90kgEKRi53HZzqwa8gh xbPdC+YT3EuCL4sYIt8a4OXqsa4S3/c2bDq/909M0vGunU8qgKNJmmxmR05dkfcEwLLIE+0Crh33 fybZbfx3f9yAw11ZsFZI0uZyNE4RDUyC/TZc8Odd+qfJ+CGGCPJR/RS/xSZyY7J/JhX5JIxgseU9 XDeQKeWTZHI2iQqNykSsIfbkKyiX3GoGQQwXQkRPEflD9L1FIyUtNIe2dA7TGc7YjZ5HH957LABK APjGt3SgRDOfkcTP99UtrxzkV7afmhzYSQJGo7OeKUT3kAxKoOkFtFlyJwx/rczIbLdEAWD/RxTq N+5lTgy5FqD+p7HWJqUGd75+HQtwcT2gu+t1IlCJrN+uMb8N3KiAzAf89ayzwwSy+QChDzjTh3nu Gdbpv5ekNsSl/biMZpTejjLdwMNvcTkE5MVeMpNacXKKfo93+SuKAzeAHTuNQhAyfV1aFuyvb7nr W1RmMgcPWSnAZ/3ZT0ZJ7SaSFOJLlcaFYSU+YQWNtqLV47gw/wJUd0Fkzug+ApfXNcy7kQ5g3l+D TCSyuATifKznVju6CJZywr1F1BrDmL8oUC3B6/eA5u1JoIkm2UIkFgiA7IzzXkKHI25kxwMKPSe3 l5k2dDDhNKqPMD9BTOksYPBKvm32tSXSNU9NHRI6T8X3XOsDEgMN/3bj2IKkj2g0XWH3DgdHBToQ p7dXSAnTBRH0uSsTxNzE44+T5fuuDD3mHQy+k/e3lnpEX1hnZy+bMe6OVAEfcH5KzYMwn7kPngWQ qwI16awGDmpBpLms8Il74BUud9dIIBlVOjjTALeDxLn3zxVYXaCbIPIx1N76ItiSLDfmn30J47l2 UqP0TA63LmIMkk2qupSQyOD+lHQvbTJlFgOF1FkzKbWiOFOq13uE6RsuRi6JPwJcxfmeQsyUuWsw n2F/PukXoN0hDLk+KJFEhQ42GkoquACmJoeN2VaCUgzhvNE5G5Q1/q1DXDzRsw/TSo2g4XAD4P0a DuwdmNYM4cgYBLhKF3lB7dOh6xW3Kt6rwL2f1vmutQzCnrzb6Rz4qhUQOMczfEAUNDEYeDHAK85w DMAZyfKdrsJ4ytUn/6SxDQw5zycWRMNkEhNr5ESuEDW3KOf9bgdo3c8bVunOQ0MquweY6eLfOQTM D8H3ivgNQ/rkVnWFJ5l9ecXe7LzrMkR7XWNT8HSx7HtftnQvl3udSSvXu/1mSHq9c4/X2YBTqIWp 6L2EC6aeuO2f84kwwGki0NbXOxzVDayLJ9Nt59Tl979nvX0HXMH8o3yn+UhfosHA67qrIorIbwcG ECdR00GKJhkZQ1fSRxQ7YfOX5CUxwLMePyLnc4hcgVt0N08vXFOB7XnV9z84zg/8ctc38X2dBUmL oAE55UTa7T+xPTWTryl3Ikv60m2YBzx9eL/rbv9jRpaC4gm+CxKzOXfkRLZnItviYtW8+X5ERfo4 s/CO88Qe6e5yzD/t/nsL+VVx/Cm4SH7mm5RBPTsau0WGoAv3q+DW8lN/uYWWQVdBbeizVz9drgl3 ckVrtNyEiecWGFsJRXVkfuPDSwlqy44p+oNfEJwDl3/igeEBKctOGeiOxdeoagI92/2Ipw3mHZ7a XOFlLT4rQTDN+p7+2JmoQffmXwOo+oVnoO/c3avzDO84nJfY+jXzon1MPeE6vTUzH/WhNLhLt4j7 QE2PY/OPkVWuz13HayKJFfxI/6kJ+d/MzP+Q8bEyBKEjSdsN0L98xv/ZGf8rvrh0FZEu+ewb8HtF p8VGcRe/oeqblTjPHq77qCecsuFYDhXbU60Sdj2j4TEJle3S7BI18ze6yLuG9vpuY1Q7UYqyMNan kMLhXMc0yWZtgHBwRaDbyQTYxAAZk3AdBtXal3geezorYcPpkby8T0LGFvX+paXwUKrlFUaTie1O CZ5V0yWGpEiLTdd71Tv0sjyGhA7/UvNlHVrwxtjBLj3OOVe0sRD6jGScYkiMzzGW7j3vkvVLJhmE uH8Nray3ISW35ucs9lmrYg2Ln73LnbT/yEWMe5PNeFgiTFXEXg+vyZDQ3HgqH3fr0a9Ezuk2Isju enqS3FsT4NCqzxo00XpKw+rnBDZiIdl3ZNqnz+/1GQL80TC5jO/E6aPk3RLPMfAdZECjlWymwjQz Xte4hHOCeKdH+RNdG9QPaMjpvZt2qRpE+8HiSMPwfCbfWlKIh010S71CUAz6Gs7sf/Hf/KN52Q2W eZsg+Euks8AeKLZ46nsLtLycbObDYeoU0y5Tfh/NIInctgCuAwjv1EaLDWZKucd6kehC+iaZjaAy FaYcXT90kHlWVI4AVLuxe8VHPQq6e0m+F5Lhwhkoe9kZ4a7Qr8i+wUadPXYMk8fpvuw6TU9lhGCy czC++zp+vA6Nberbxdck4uddADssbULmCMKTS0JT7Pm7T11FZev6sKFUv89/F/lRIE6K7F7hzw+5 eDMBklxYa19JrFxXZrqoEsj9irtq54YOkaEGl/z5sJoNUBBpY3AONVJibmMj0V4a2vfrpJdN3SkP zMSkz1TYnqrba4hgmEh+eCJtyPXyL2HwdiIgWSc79uAbfmOlTedyFqs0OJACAbrVeRgqI9ES3tkR iDcOfMcAGgFZSgQxFPo3wnSXpgZgMYBTZ7PguNN75NNuPDe5vN3MnhtW+mwuXiDsTmj7rAMayBhz Ietwot3E4XW0U+3YhcAvi8oY+H5jXjVbtH5BSAYRhVDYHoCh5lwwL9wciJq3s2Gs5zcH2hkepjxA gsFX4x0KkWC9GgCUItIIEIQcC9mV/KtW1odz/s/wAlNWPFj49fmbJqG56PtDUOECJtyzW3MnrgmQ FgDqlzwjd9U94VwGXqUArVC68Yq5/CVhEbgPbtceLTDj9kUz7DyfXRTXjAn1qdyLDLgK64tBcEa/ ErYEHA0QOY1EfoUiX34G6034S1gNz+sd4PprvXkwGlrnPHiFmOlsuAeJm9j57cF1Ip2FSADDgJ3u SHezN1rzS4A2bk/y9gk9vUYI2qSg5RK3L/jfHHD0y/jeC353Z/TsIIWCdiKGdZoRNWgeSLnfSKnm VewXRFirb8dTQ2qfNqC4OiEJpe2DQldIFzok0/tJbH98P8EpmvXSbyLF7bjsGB43SA4Ev8GnH2Fh xiGeVt/d99PtkVbyUuxYPyKCO8x6BaoZF97c2TUpTDEKAhyOlDpE642nzjEF1ycxnnBdip2jAffF DlOPbw19gHoP0MPPnaEBgd6Ap6eKr5KjnszbkUk8Gmql9CCSiN040n3WHxzNhN959cAKFyyuxWmE erthUj31NfKUiRiXKF9rfN2/Lok45B82c0XFo3QIpjTEW0l4maN0gXrWVDS0IuhZIJdU/O484JAY T7il0ZyUSrFEg1DSPPvgeauHPO8Bef7MOj2pmEo9g8nUdxtHIanuUvyMa/RDtcPhCrzzdR0EngJ7 EaB+fw3z9QHOQZGQMMEqZZTCYVMacc6hrez4XGVkfA64dg+/swngImy6fwzkquGc8ZzgvbqqBSLk nWzWku4oUY0wd3BF9hTO0OC6PoHB3eSXPFM8OTQAJ6qmpsGSgDVx34aJbZE0r+lZNfeuX7MicnUY nKEhxFtPUr+wuQwQ3gN3ZsQ7tPD7ljixeielQEPRz15sQwsLVBkxVdk/hoGYOKUhFUKBcXG+kSPR Uh9YH4Cy6Ljqw6+Wnubsk6+72oDBZiIcrTdzZyxGAi+icIVBuslqoqGv7di/scoHeTrn364RvWp8 dgy9gqrn6Zieo385Ex3encbeef+9La+jsYx9R7rcKg1TnMIUs/Mjo2DrZjXxTDrdQg4X3dqQnN1n KBmgI2Prz2mgXpghM0bqd9BKTb0ef48cBaekU49uvPQ1yeK6W4enNbBegjOUsPVrIMccW9bfCjET cyhexmeXZ5WufuRJr3iMOJZUTfS9j6DbscL/VzP6X2bys6EGdnxnwFz+4575j2SapE4q8RyecioW pTP01TN8G89BYmLm1gT4ILu3X/E326Zkjo+etC2tXpSfxxHVmnhJPalama7aBj50entOqdPREqhg 3JkooUlM9grYqZ59jV7XcB3UrviOfZOffPCQc4ZpMHVIWKvd/otk8V7Jx5lmt+/15uEvwLM3F36F 77PuZiGr07OE3/Xzo9fi1Ki2N+79MlgHavHYn6yvbtdpzJeKc0HMsOZZdkwRBAkj02TMT19sxu3m nAQdL2I8X4BDGDRhf+o2J+vmTvquZI4fob8+3qdCXv9qu/66X/5oeEqNbrSaZb6tP/9nwNv77AQ7 plKvHx0HvIG8641YzlROg1LYaIwzsdXXxHJ9LjHufvsgk5km3ImR4uSf8/dHlyfkQ1gpks9OlV3h bv6MIA6xbvuu5LTk/VkF/bIPp6Q/JjRzhjyNNb8rf85rI1PcLl+SLDZ8dujdpPSGn2Vmrs/be36p hiaGePY6+kc2Nob5wg8xvDKaa1/+Oip+l42j4m+xP0dIcfRTpF21v68zKIT1jgmAFgaz7d85QETc hoyjQGmieosjunB8R58MEyCG6XhPEDUhK5M+IkF9ItdSfByCKA1cks2hkwI2/UtTbAR0qKzPAMDc 7Fdgo1KWZ0wENaNUzGT0sQs8G21NKfAyQaF7Ems1HnOIVBaFX9D5ApfT5ItPLLNBHvMlAnrT1rJ4 9NqfqxnS/mxt9bzuiz/gNACqbgMS91Cf2a7MOkDNrOSIiJryDKVU0AV7kwjmRBxmgPRxxlE6/N8L X3X3CcEEjnIebE5/Ig+9hAE71vaS/zfKyR807nzGU5M45aYn7MZFw/PwXu+TIr5ogi/KU+0Yn+4i oenOh3eSMR34oryyQSiTZztPIwMpPemmm8TrK+x1OUcuWLPPYgVoBI6UyoaH45kdco5MdkmRFboY nTaBadP7/afUFDDkJS7Vi5/Dj2jGM23IwR/Ooiq/l+qaP87Q2kNOPd1kT6jue5viDt/7K/9Z1hfC Zlo4sDUVzOyCtnRtvdHVqyLQHMHmT1JRCinTIax6qPoVbwMpse4WY2Qr3sLvO/FEaskf0O5xJHoB FREY4pkmTP4BBPyArblG5lQqBpiKs0purd7fcFRqoooqY2YbSC14c1zjDaZR/JzXZalCBUVxwFfg b2fzOtAP3fNHRZrEchSh6JsBN4ZWtvtNE3zs9zuF9LkN35eDfqZX/AjbrrPmBlZm1aGan2Qh2+uZ 58DjEVpLIHA4zb34dL/vufu4abnJD4JEO3Ka3fCJdNO3W8GaHDUC86OkTy4m8PP5p1K6RCqR8zE5 tTe/0PZ9MVKzgk4NZuOI9e8TawpYeDtT4Xn6IxQ5Q2XuArFwPpJA0J1RxjrnZjpIGYix4zq0PqvD TVEUH68J0tTlDMZTwgYBg4eGk6ZQL3sYPAWJQgeiI1iUcNX8RVYZelk/zfV123QyzYA7eAHZgn6M yPEBQra7daTLoZdZQkn00hdx0AUQF7UUjjboDIUxAblre8dQfifVtQhIQV+lJQJyIZ662GJ1UXb2 U3HmzEP6tbpucn+VU+kVTl8SfvWogrtCzehEH+5I+njvDpCf5cIXL9ln1RbGpX0APVt23DIYLbRK SbWvSexExccxpV2vk60nB7SmkJz0+1di5EC0ujMjJ4cZ2uBnI20HzQmo74sxUJPQ+t7t/vX3/wwW amh4aqB//SKcmwhuHuzT4YzpwCJ2D+OPhJaMQDcMffN5SY7heYeNGE1q+2KvKXZxo7osuwmdVKyN mXL6Gp8ZYlboYy0CP3Hi2jcekIKVjXspBvIFKYu/yReuaPBNxzBmKXkG+KFNRhulHo5e8p7/E3Wm j7joDuH4gz/gPEV/YtmrvjQ5Grvu2Yb7ZWw51Zml5y+k9BUaLIf1qAt1xCBC25TbtzfzkffGzNTp KxCixMtb775O6jp9CK0eo+M2vZ/17yNdJod9u7PjFX8R33vvhrx5b5roEqmchODrMp/Y78V3msP3 zAYm8rbgWpbR/X3ub95AcEfNg4dc07M17qRjrKSb5P3PJBEpnrNBNGJI+tvc9UkyMzDLvjxPG59k w6rrdE1jF++gaLO8WoOk9nA2auckBhy5r/HHfGInxJ0Sp8Hdgc7g6sUcDB3XrH6A0oeEmPm7zgnv uiZLlz/fhkEzf8cl+ufRG9bZPImN3EfdHGtOSPKw42njbHffGKO+4vppnzk01JFDSnc8WuIqjRiC P087htbmfzUz/1/iGqfqKQZ65j//+a9o5t9C7y/TkOf0QNf0ilMNruld+Byfobh9/lPiDD391pfo I/X3y6dYJeHrovs/glNKBauGWqJRqTQ8ZJ6btSfZa3nICIstltrAUOoUDCh9GDR4OGUmzpyBhJs5 vAQPa1O9JKx8b+LX5Rf2M6WjP0197s8UDC1xWozmTQD7HbWmU+MO1q7eiRzgSi3GdTgLQ6WvgUO6 ddMiLZBCG7BgTw5uKZ67CltFPH70Hr8ll5oTMKtztakjufjK5boFNfnmbHW0Kfue0x8MMPgPn07L s+4hLd3GFLVG64/zfAwe9fTlMbSip3aFu5JwpTQxbDXaV28/M5+Y58xEbrCQ53O5Vzq6kOmGvngU JkLOr332y280hCWNNFTuzG6g0uwA9bHvVGog4rFauuA1yL1ozP3n7+ABfWKfZFFKFjEkTq1V4hye G78m5/vEb0J57k6EGMhr6KcYdDS+EULL/7oj/rGKrYhQe2OSE4Dek9IXPjkHtpmkdQF0FW4wBAER AbfFbVm8sesQu87o82A5QWQB+eRz+XID3YdnOuoMENGCItBHuDAhoFjP3pecBJDkKSY4OuR5D36J 0Jk2j+HSCv39jUHnvuuc6y1wDI3RNJF5EUPkxGtK84zR4F8ehUax6kThriQRTiN2ndG/CGMu5iCa 1BRRoVsOrWbuBq2m894bK6cjcBXuPAbethOxQHjIRYOwif8LPNR1bPd2EjcUENeJNQvPh0LS1MGa RuJuwYbgkt+gbUq0mzPhfhc5qXlAUX9BGhT5/Ra/BLRdh0oHYb4bp5wibQ6teU3emOw7MDLz5eQs AGQJ7CXw+pIdPLU5MwGDkSBsN/d/hMdAjKSAhWLgeiiTQAD+ije2+yGlNTjIXpMjFp4tQsB8qmjs fUdaYsMbLa7TlLneB0BDO+Ezdqkjp+nv1sVDLgBKwWoRor/DZjvJwyXdgFymFMMlCzhQxhldoMlF tJ5Dki3e+WcIb7vBpktExs0a7g3X3bQjvznc7efzE7h6milfB8Q5BNWUs6WtiguQQSUdzjTbNQXX /uxUCQWxMUBsZCR00N32Iu6ztn/EGNIZHPKxuXmBNp7KvyCdqvthm+zPO4f+nbF+UP2z112Yp9h5 vy3hSuQA6UCzTTT606f82Uc6oJ24Fu6+uKq+uT4g1/oMNu7vIVBcnzLtGgR8XVrumbLJKEo22GKM F7RN8inPhk0CaPbMnZdYYI6weA9KOqCVFcVtvqU3SKYZ8Ov9IjYvMHLJGQUlMK2inE+H7gCPNW2g Swhu7L5/wAd5Bga0NeU2SECyZWX5CH4FA14eGPabiejS3jOSv2pLQtr15ganaafwqJwC4ErIMlCA 04N74QFT6/zsy3Y0smI964zXC07BAx67iUD8IRJWPlel6cAGhzOinu8PZ2pJiaIOUa2/MAMjHS3t v3oTuFT6LR4wIjD/9mCX7rrpYG245NxTV5By0y1w/KkjdmudSp+dzo0N18xxL2IC1hXIbYNuW/Dd 6dgrgjR2G+/dZvgW0nelfR3m29PkwQV9bCVjD/ziNoHeOe8HfwwuuFaCVNsRPdCc9DcxnS67O1ZX p0fqDqlUS3wNZuzh+k2IbTjG6CyWRhD3WLmuvs1/7SZV/dbNLrzg1FuqgiYjNffeuQZCiI0uNCle nT/x2P5MdbudwyE6Y9D5eo3dtIUBMTkN05AFDKJlK/WOchinYXN2JAjcOqgl3TqSoL7w1UwMmkAG +7qZQq1efM1HvOiD7ZCPH1kQzQw4H34hN1n3oamNdx3TuQ3lGamZLxG3Z8rgzqktvc/jjlHOcXil 9I6Mab8iGOHNpkjV7EnMWucvpzLOH/MXynLik8kgOlLlCUyEq2/MPCUC5v3CdRDhw1+p255tKgVp M55aU07k2V6XUU4uegceysjflt6AVfESf2K/K+DuEmtlsdV2V78OzT+Dhf7Ad/3nbPRHGmZYwXjw PfLQa55Nt6ZIl3oS+Z7u0Jl+kGlyvQqnNUO8xVuTpux8c7NT05hv3+IZdO/XpMOzJttMA9eTfM1a Y0pM4q5Pu41XUWbQTmXnQeKnd1xFmB586AweagAv372K7pDgm0opEskRf3BTtjKh5zPt1SBgw7OL nLobR0JnpapjLnp5Xj4WRu48N9E63cMdVda563T3BomkYc2c4cUU6jekjbsvg1pg4Vae+F6bk2b8 4mvACJNHZnBAYSNif9be/9n2f7+LfzndyrXx9L9zZv5jnvmXEGYiJU+3OX8SN3qmJgxfs5BrCpB8 w+3pGW8UYE0Xz/ZQ7mbWXGlYBcE1YY3xcu/2d8f3mtx4Wr25z/U0ftKwQzA5Fk/578K7ZJ1pkRZC 3BDUTVLHCf5w1Zkt0wZM0ok/BYQDJ78+8VVOgZjo3+ZjD13kRDXjtMvxNTSmJUxt8sF8HSlVUsMl M/Hvo8Ib1rKROk/nLtyGmMKzzGdveScnPD2mn3pzPjFpHsGYGUg2T2yOh47pToYqXAN1YDeX+oMT aQLfzHEn//DP3tyGCv68U1b0mEOl/VnTi5D0/A6LdUHuPr9zQJ0HQaacFdnbzAeGOYkjP6Za/ril KZnkaoC+UQ+PsZvO01AwavMOTQ1WMSq/0RVt3z1d1ub6dU8pdD/J0bEVMvUUGyP9DY3T0dbScKAm 0/wEP1/ABN/+a4LDR8OGYfOqv/ikna7sDx6IhtATE/lzu9oliVzBXfms+60/+Bf/1z/ml1DX1zXY y31GEBnlDlSpO/5eIGD/u0sSZaO9xbMb7Br8ndf9wkeEQhMOUBgeUTqR8RcEdolKuJf2j+sxO9ug /OSj8aQmTQs0bLL+dIJIQdkEgDQfM6SDTdegQzpFXFNxfV2EclXu99zF6E1o0Bp1nWWe8Zs+TqWz 1tq3Y9bfH7i4jb+i+U/ymMNgEex7IkPyXTjmzf2x1xHmVrs65zht5N9e05h/NcaaAJOTpBcSZJmw MMOOkW2O9Q4gaAEi/oTh529RPXTdE4W6RF7H1aTB56t5sznS/SnwPDRVugH0NoechJIhhvcp4tSi i6YWf0zeHYhJgzQvNo5u4qj3Yd7Jfp7IfcWcedeoDDRloWO8Syje5RHtfFB+43t35Jm+Jw2fT6Ti ugj/XlGQCSEkBf3uDthgOf7jhPkzqHL2T7jquDaZGQ/dqNocmlLcnz6wxT1zdsP1DtpICXvQnbIa ATexroDISCAuhQezwDY8582Ch2/62PG5mtvJD/jmj+ngAXhJay8IHDcEEeHZWLnWh0SiUBPTBx10 YtoHAI7dWO14XK/6xIWEn4iVzj/rX/YE+t2Ja4H5qjlQqrH7D//ybled5pkWjGUUJqRQ+duBYSB6 cKBuIUe8yZ+tHIjgqgfcDxFgURHzztCUu4GMmOLikyT+4HlmBFM0g06T86tYoN0H4ZgkHuD8cUEz DHgRQTOxXxzJJn8pWc7Aq423wM+fe+oFCaOQHT3sANjXADFDf5jPMAbeH0Xadv9oXjy51lTG//L3 EqGvMqDJrsY3RU6HzE4hhYAo+KrAQVj7Tkl+uE55UlareCoGsvM+fx9gdwq4asBpBFHLxQlXeQ/p AMjpYsHuvm3E+63tSADBkpL8uywk9hrYapYKfA4ZwNWOAF+nl+V6q4luzfdP+dsTaNWB2n3B+3c1 gwP9cZuuq4AGKqlDI4KoC83z/pgZdJ661IGX0EN1QIdOFQMFfIfqzpnimeYad+9TNbHbcPoO9+rX 0VcxlK+PYZ6JU9vHuVRH1Kk6FJC3XDo0Emk04HjK9SH38uu74Dr06RF4fw4MQ2jyvlL0E/54FoyR uXnmkHHq7MHG5iT21Sdnx2AgAIrPq0++kwdPPPYk+vIGfZzadYaKNR/E2sH2pY8x8t+SIIXu0vok KMVEVHHNylWqEJtQCmI+LeGamQ9ZBhFGxsTH47hYiMtwCrPjnldJsLt9lU9agLALJZd3Iwk5geF2 AWFLFrh4irBnUrmzPJyU+LxfEBG7JHxOoMbN/ZJrcen+TRq+FN7VFw00OPRvg5bBM3SmJTfBLF52 dnEf/za8sFNRdUY7pwg7hHfjPmuN/YTgvX91W3mmbPlgmAGYbhYDD0W9rgtuIMiqq4xtLC109YVP 9+PCqQ9OUUOGYNt8I/eG4zxwMJq393Wcg1z35c/6zJEM3jF74VnvVouMJ8nLk+gr/cJ9pUlKq036 WJPCF3OtI3Wekhz8ogIUrCUT/qAUwF2hvxTO5sxD8k3OCQTv8E/yHi8OnbXyVIz+GiH5aBiIF57C fWb6fEnl1jV3eh646CThNVu5TjHTMqd/NvYSxDryZ11Vmtq6NfCwybvrwCnvAG8TSl5MTlhjCNHM xKYv78Z1Cw7/r6QKHkhu2oZ3aOomhPgxCKPPJFgfmm7U8+M0q2MHeNfnFJZbkP2yaz3Ds3rxJ80V hM3MzL8gzf/k5Q8Iu9QvWqHn7fwXZvTvGzhBbkL8oPbga+hCgF3oVggzJ6nit5pI00XHd2jMce+0 Pr2ZcGzn5KnCt2tOMTP4lt++gr9V2ujc9f3Nh9M9f++d2+tEZeQpWCfVJ+3symGX21/9UFAO3NQx 4DOTY/TXeXmC93etB+dD8zRYl3iI7wLNmSfO7zSYvTV+9ooOpZbTGXto96b4s+kdaDBi5rd8dMas dTQSrHe4ph2PDkvJiPz5Z5roeuZJBV6fyF/sREPRExfx4nf633cxrb2GGpEogskBqRPU20vpSYjH JHInCurMhulMMtldTsGYWYvICqAzuO8+uBc3laeawMx8ZTmAVcsdsqwO7K+JbfLWAwxh1htsE+3Y 90fHITZeMpkCHa5jUW4xpEa7Vfgzr0kQGdUJetFv0+KndsTQ9JvK2pIsv9JjOXHNtZdsJqLPUC0O rVwuTJBiqFLTpr7k9sMXE7nachWTaAHuuXupjYf+gzdzCmr8oPjOQjKKz6+A4DxoHB5dU8Q/X4If H7eWdDfWch3bcWuzCi2emiBytjtvIsDtmTa5fIuajD9QETr5xFGlz9cXYEHC376IM0pA7bsOxW86 4jcFpVhcbS6TZp4Kpm5ysrnTugRGGkCFgSsx3YMM4LJg0ONHVHaBV5ciz0CeKIB8IUGT8eTknpEi jn9+Th1X80pxJ/H5uoO8U3rbAesKCy+I0kGRIN+Py266LQ3SJ0tip/fih2mmBbzck83DouiZO2ij aJhVGm1PisgGwlIBXHtiTS+IvN3bc/jkJTNvZBABfVxGCkmDIDE1heKaICNdoL0srBRg7AwliXw7 Ua39p+uANEF8dCCeJUNc3H4VIK6gz6DQ5Y3kVXFRfZoh5d4z0HbCASEHjJIuFe37GNw6E1yinU+y l0XMz9uYgqBFdzBB090zDHtQT0LKJZrvGd9IRmFsIIkSjYSiJt0vs6me5TJDxIxAoJLNlTAhR9HG vdG65FLsP6k/p1F1d0K5keTX5bzFuf5E1b+1oCdddVOcIwQOJuouGtzjaO593v41yc6AIJNfrxtm jyOEWElIifg6WRqF2Pwg+ljmsZet8aMVYju/TseRx0EGkxv1/V8qwpbbsRhBrQs4Omj2RpCSSPW6 ahFtsYZPPQXgS6en8Km2sWbt4o0B4cH9ZglE9R7QBfwUgB1UYyTBeJ2ub5R63oOayBLwrr86sJN1 RDiQqsBcLh3PE3k4z72SGdReta+/wPg3IrX0CPd7vnHh72BA3mkJHM2prH/uyEcwYhIsEjEqFMxz VWcceNpESu7b9L4yn/pv7etZ8YGXvFlr2IMh0O/+1TnP896eCnTliudKeosYSopF3C+KziMrkeYg 6kVJ6JM4uvjCxP6uxBVKybMHMKQ78N3fhrav2GMK2afiGZ0E9E5aIxF1y1AzpPVRJO/GuH56+m96 tbnd6NQefN7Siaji0ZOk7K0bp5z9k3TJEcxN3OWJ3+kTvaN6/bov332rIDWfXa/aPWKN/Q4g37NN YWpgpCeYWK3eSn/eKQ9o+EMYQj1Dw5W9hLai+N97izvvHMoR+UsgYXDWZnGqkeT1cdrb5F7u63tW pTMNCwhIMhwizTWs/A7QnTHLmzSosjOdXd2bBhDDCQaRkdkwg7wXPV2o5St6wB6aTw3D+e1idPDy DddU5Povud0T4ve2kBQcqiOqPXv9PYwmvBN/J/MGb58/rtUf/lLUdf4h2w+++jV+xHkJtzsUEGQp NFMMmyRn9QoDWBjfEqqyungTb3OHa7bwzlgNqd4pzdP+CFhA2EfU8b+IG2xsXwPtwjlxVirNXPf6 PdBw8am1B080/OJ4PGHqcz9Mk9enGN9Djo1/fpdy4DxFNttBrNWURoHOlMruDt8IeSNDbZy91EBt 2YRxDt7ziga2MEef1VkICJVpvdR36qTF9UGymywGjnPSWsMp83BBAme6c2nrcwVWMb8MerllFOiX zAcQzJyz2Mf4x3+rNifegIdVdPhQ5utBkB/v1Ye/zQFpFX5IH8+3SXgST5xiSLP3YN4ACqHEW1/o o+fLvv4KV/Y9FTvHPmmGmcRNd2OipwIX9JZO5OPqyoKZtfqdbsxapivdITPf+RYRfZ1kAvzgDqvt xF1/9Geu5+HVhBB/zVUpMqyJxWtzxdfAizC3efB7oSaG6p9BLm2LiPTw640rdQw8DHj6clWowoO6 KHom0siV/cr/bkb/g3UGqb1H+t3rRvlXauY/O+N/eXsLaXx1+XpWSAzUo8Sg+FNWSXcDDZp0Kw7F b3dl5AdqxPn4rm2fbWPRgQrxI0nKNGSYycRvquTAWcpE19kLakPqA4OwxynWdELf4SA4f2BoegSM vI1Jn1NOGaHWJzHuy/VPUQxkOkGK66fWxy82J+B/j4RcpCu7zsOZ4ptsF2CBzuTYuxccyXrfBoQ0 TsDfdYaMSVbF4JfbnW6OVDLcmD96RbTdWuSr34xkJn1Vl64Ywxou9kQ9vzkWx/AyZd2r4vyJmPqD H1HpJlVdr5nPa7yLwlbmoEFK48hEda6ONLORDD053gzVVM4fyMxjBAV6INVkGX0iGflOGsaU6yXP 92OQpsvRMwY8FZlJ9p+yBjrHdOso4Z4ZuC+2TsPAWw5Wn+/7dPDo/sAmvlnr9cSIXzbhdtc5/cf0 +2oeXTiTwKhgfxlq9bTyzGGa+13/0QDGu3z1OODdg/k3N5+M01HxV7kEicMVT3Ch3EkigaRCBIxK RazjJq2BhmwDaoag8vVadAObyPH1xrc3WU53wGZnx7foGIjTvQUmEWauwI2hiUZBggbJiyxT90bK BmPALY2ECV6r7v6sQbJRp/Qgdw0DcT4HAMr3ZCSwzzFiAwhI0Tk39pqmcYVOxxyJeN6aBkUw+nTG OpI27SYgvMDCrdRA9zXhBslhr8T9jQolOcKlW15QxWVnPYWMZwaFIE+kzSewJ2w2v8uCbzHnukB1 43t1BBbXhdh17wyIaWjq/Z47Nl9mrnCrTgmSgtOfM0qLcCFBcPNSyM/iMuHafYu+ZBKKNpKAkLxX TRGdAMLMZ5wRQIfSsNPSJZSvg70jxvg+oy6udiEPWMR+C8QUtXtN8XvIEcwIFBnuEM8doDO4fxkA IiCZRWW2YXTHn5QIDTwZABpy4uhuDAAI6zj82Mthw+WWVAyPHHEtxFu/LvQ4HClwVJNKdfDUR2qC njs5+2IEp3Q/bj0RMO8p70NxvyrApJOU4StpOzF94oBQmiz2IXuvwAj/m7/beSJxmS+/a1uTDhdd /pDpMK5rNW5JG9IMZu4gGe83V2JyxQjC3XEHWVRIloF2WQiEJbS4ha2eTLLRqd7hPdlQ9xkdwt7J emGrqFNntufanb75nB8g9S9ZxQAKjM+G4O/LQfV1o9muahORtgI4Uh976jc4beI+hudyouN3NCL9 9L02XesDAdFiEI2wU6eOIxt1NprqBXkIc5W6n0nvAdF0JgIN9JgRFLremeNncrc9IOR43fR/BZKk Q3o+QhVRssE9V13cGu5z70C6S+2Jw5HhmuHAh/zyS/H0HCJjRU8QN20kJvnDAZnThprT+0niq6Nj WlGMXRQPJKiZpmp9p6D2/CIyXSlditZuAng/TjO/EwvbDfqsSZiVVH0e7Iae0hZDNXJ9IzkivYL4 Cz9MQLX1Utm3KggErBNmE1q2q1Rgyv5E8YG2sYZrpaSgXjzfrng/wnYt0UWD8fNtfycrsKNk0tjd IUszn3eFToTqHHPJLzMSI+7IN+ZzTnuLWQaRwP1+E1eAat/zQbA9hy7sO52z1uGGnmT/WnNqBJme uun5XsrezB/yDBZvkYPzKxQxet2SRYrAbXjtDbPEhIYZ6Sx0DCj6nBVvYtDtKxWCbEQyTwpnouIc 9x7D1CZcOveqzyCDKMFKKTjw9DQLHRTvklacVspGJOkC7EJovk6lJF2ggaqZ14lRh1/4ciW/Am9K GxOOal6uieWlU10xN676cy9sIphP2x+B/oudbGMTL4f0jjPOEv3/4LDP7SO6y/f9tAdfSd4s4J6E PaGwAYXv4IvWQzqaLg6UozXvczLUOQ4zJMGw5QAnNPAstnt9ri5X8bf0W2dOuI9xfLutZ06vcpgs 4Z4/qcc7eSfTq13YuwkmxtsUwa1Hc6mjCLeiHucM/7plL27sjCQYelLQ7fnE+V0H9xQ9gxdmOLUO yc7xFWoBi+Ip3B3zp/s95rCIl+vfPL2G5yul01BVuhZVWnj/70nX3WSIh9APX6Kf+pbxTj18Bifn 3WGO7hXashjPnek5HOnEILR+5Sf9gSY3XJTNLAz33DodV2LH1kh8JSZQL935kRRVqigMXk2KIZnv 5TtUDSESPxImsgw4h9NZdtL2dO+Wy0fs21PnnE2lyFQzPXqPv0nd3ur/n7/vfzYz/w+q8wfwuOSE 113775+Z/wCjaTN3CJgN0PZ760kU+9x4++nODjfYU2G2R+MvX/VYW4t/xGsScqGp9yBBcLo3v8Yw BmO+P3d2DEx1sfFNVv7z7SPuwVw/4xArsYU58CkYZmaMzp+aDp0Bq8vjGrQM+9On9kVDhmI/Qy3v s7t1fJou/vQ/dxTPyMCpsML33OjIUQzYnvVEskwXzCzP160dWAnocLa53ddnGKClUhrvXeJ4Xo77 YiXNykznLlPN0m31zXv2Z3eVQ7bEx97E8MSE3tom75SdjJ54SO6ypktJg71mEbH5RSO2d5+vi7FC xxAGeRudPbCHnxMPu/sqMzZ3z8umwDSMQIP+afyza3RPag7PbSeq137gQDKgmGpHCfig+pq+bv29 ytBsgxIet2265691sgbldYewBrD3KX1b8tJ3uJ8TSimhSR/P4Z61ZW2DA730Szrn6h0G1tvZt3/q AM18jBEODsUQP+pgyS5n9w+eAr6XAzUp/IWZ/FABpQAqiSm357eKC4k82wxg0gbqqUARXszXrWOg yXidiQam7VQmoQEOchIfBOkYvRknSM6c7mMI55Lf0r1AwU39dbtc0+rnCD8OTIrCZk9+CBuBLe4u 8C2Sl9XNqP4EfxbiXQBmlHrcA0kQz+ELeouJmHTU4ngH0/DC5BTrKnjM7gsoYXgK8xfkeh0aXYOM L8hxyV6SpVxBh2CCWeEk/a6rO2kkjNkUXFrX0XpPnf2LAhYXyuY3wQB/O242pxQk2/2IyALVEMx0 oFiOeMpzXKHscMjgYwhD1Eb3/7jO4SmKx4GzZI7TzBbW8MTrH3cy3TPw3bcz6ZQuWP/C654AQcF5 qo/pRmGDQxGxMwNBvtcJ3+icdAERMWmr9D4lea6iseKpw1ydDEL+vKth104P3PXXIeOU805Yghxw fwiYdKnXR4B4gh8DRIFwfQz6QlLj3SZ4Cah3tshrupscBwTNJtz7+rqbbni8MXZyQG6y75brCDwp cqgKtOti0NJktOLX7v6mTKO9ExzObHfQTrirVQQHgkG8+/5VP89f71Yfce3cnPqjoeQYrTztWiPp GkdO0fLbNYe8AAy9yZQGHyJg1Wngv+564m1dGvL8th7y4dxRe7kWM3Vgu+Ssn6U9JMUu3/yMZ/gs IpFjCuQVIHcjDKmfENa6r5hW4Qr9VbPmaasApO5Z9T3FX8A3zaRwyZPOgSTSUdYt4e7gDxJ7A6r3 PsuemdOBUFCwgE7PdmpKIPS6dtnZ8a86+CHbrsdHOkpCvfb+L6XAYwAD2ERSugg7xhKBgPDpfyOy kx3oGA+gZy8kagRIRMbXTjj90r5Jgf/eaz+OyAPgL4P5wkErAeHngsUIHMp3n8LkiiMlkD3WbwXM LkGMGZDk4Nxx4ZaffXL3ob+gPK0aVSBeB9g1UH7vcPl3EsvjMKKM5M4ULkEywpejVncV4ZHB68Ka qYH+qHZf15Gpg8Nw64NDTu/HNkmRg1e/wfz8Rt7kyczLUOkH5vRjtz/LVMlXEGHAecmJ/w7E9mpI x/lyvuB2EF5cgUaR3Us4nqJPkQXVp2lTYXQv/elDPSyKjQ5YAxTNSZmMe5FqhUuea1zuicSTHrzt 4H5C7E2ALjd5uhFv4h4293qOLgn//lSnL2PPue8qDzmBc1ywD1H9QNP+qfv+6g0Mw/33Hk3TlxQ9 0vrxSaNgo4dMeBCS5T9O4Ip67OJvAkTueuRmv/XudxUxwO5r4G3aiYoaiEjP/G6kkMTZIvTMa66J HFjw4ird4RG1c08FcaliMsRpEbe+NAyj/LWODRhEGje4YnKZGmE2LXmJcdNZn6lTb99hrL+a6Ezn eQp4M8cg+bc5y8TzWKkxuqIK5R3sXudcUthhKjQH/9/phVPHbJstlgZyzg4r2T2/OUEuB/PfQfLR DCco/ayRO6jbYtJ1BpmFLt/PuxUJj3Rq85YYunu+3Xur2rv9VRu4RsG34Z1T24l+zxVeJvcZfLPp tqa0k4H+9Ef8jHHypyZz1QYcllr8rBVcV5oX6PPe/xYSxUCmGT36q/56zUmY4WtGT5dXIYs/Y5/Q a0SFhYLTNztM9K75zJ90rzCpc8EHr6GAK5euI5xkp9D21q8T/Jz7gbhu42dYhqpV+N/x7kw/PG9M +y5SiLaHsVNYSzcFssaxvGcq4tgeckptCTxS4uZG+xthljJxtCyYm+GE0HWO/N9m5r9HZ0WuOacy 6XDxHv8XZ+bf1lbqjzA+z8rBZNK8w9Jd2H+4p8Rz7gCNVjpUcD1S7eUH+dyjZTDjYxLVUYkv7cSi HExOUfpJdwmDqfw2g4yoUHcjUOm8PQ+7e7dk5ExV10oGImf/66/OQ1X+SNXS7MQWwR7MVKjNkxpS HHZve/B60blzB2KawNpgoEIJYzsJ6OVmZw5XpPxbN0nlOv4il2wWwq4TXHRSHs62pie4Jls0QTbz P9u4KtzeqRM8qW6jXUspOp2fhftHxL+WHotEadWxxaeefcHcyB7qaxZV3+PJNYme1uZVrzg7bsM5 fXHu5MXZMG2m2wvfvuY10+J1053kA6P7WHV30HwPwj+9tI2Ys0I8TTgy1WSMvzYY2P4STLf3IqzN yLzqK/mVBNPGzMHWxz/r4dmHJwO8GNINctP6sI9J0xYXEPurbk/ddaqb/UslIfwTU9PqdM45YzqM 2gC/CVELZKZgaKpn8j8Mr/8FSNvWphgll3gDg5iJnTnmZrefQotjq/5qwF1BMH8cUaqXKDk0CByd EiLMotWl2b8w443xnQLwtoMoXe7JM2kqUO1fHdwpmliPQC4vCYoyvNJvEzC2Dk9ooQCc0mcyAR0T R1zpgebUZaLbqxdN4dkUUM9JhOJqaGR0E2JsQKsPcpBc1xELx37nWZi/5OJyMfJMRoe6Al+r8PIP KM7ebS6NkKKI0yEPVwKx6LMx+R8ysPdAV7sunqEbZRz1EkAGkc5nnirAesmPPbFPuz+D5a/40Fjg 01AQxWWyG5rWI/dpWshDnwDevHVa0dRECyrim+kNXCkYkmh0nEP+dFnckbWrlZViiCf9GA3Obc0l 2RCfdYX1P4SYcV9o0pVVCFkwwPd+j6lAIyer/BZbqTItyE6Pr7PxdpjxIh9N4ED5ju9dpiOgW1CF 757doJc/IqMSLNYvoyRtQOsZHJgrmsNVHmdEur8IWpINql25Bgd+n0j3eyKJzkAQvZpqvS/AooBU +iqtr9hvT0BvsY/hLtavYpwvB5OBAUqfCCpulJK0T6ffO93taU4yU/xB6AmT2JAkRinkd4Tbv3sk RhfNv9lFNEORtK/j6CbototLP6N+W3/+FGDuoTOX0N1+HvU13ytNonA3cCd0gXEMv6m4jBdn1pni ijAA1g2IZ8jpQR8rsQsx36QXnaSTIAiU4v+ebtCpWZeKyp/x5Mf1WNfhz7hbJ0hlTzqjCKuHt/l5 XVRyUFKLXL09QSY9XVjRw+NIzQllKn1OjrYxJPABcb7Ol/fkShe//SwpJWrib7iAg1yvL6LArp0k UR1xy/5T+Pb2890796lXzYPhCtDYv37/CVI/CbmNz7x70zBipOiZuvDa5d69IKQXXrDPhjKwLI5u fwcsCdYTiMpu3WQQqxBJ7aj6sqPRIY6v5OLrbFI5nxu93WrXNjD9xzHG3b9IeKe+KRQ3wFh4RiaM q0M+6+M3U0+rioBd4pTib3e6Gt/bmNiCz4kNGZprezrx/7jE3oSrKZ/oirz/TspaGzQxOlLfPlW1 lyf33iZIVu3Xn8Q8DxLfFA++sLFrWOJziytJJs8VNxlQw5/foxiQ+/k9fpy6DbHJRD9lwLljH/lv 5c5RAigTQP6lMp1Cn+TeOkQzVENpVvBRRUsbNxJ5LepJEZvzXdORK7+5Sr3jv1G97/N61x9+nFtz mJ/HQq9YsvM/JMRGnzABbvfeq7qJw7McyzMJQmXgwbEe4s4Wn129553AM6biGK3uUpz+fZCXhrYd pKjBqGffmTy4/hoX6EsYWmPlVUSnc7iDKc5chHNoVHb5xQZc9rwL3vvZhSrPzZulpvjODmbmp/af IVe/LzEVY5b0/LSwoDSCUBH0GGWxN6U2VvxfWKlZELs+nfThatv3zFduURMjJPdMWJfzuWuQF1s7 XHmj7GSzxCLTwZMMbtozaP7lLV1ABIjCOfusMf9W+03l3Qd5htZhGu8BYnZ6ngGnd8xMH4igqgPS lf6qY29O2J97ezlYag3mU4eT6GtnoNv/f50cjfztwWXsGeyz/WAWCv742+1y9jkRgxcG1Pk1/puT lMsZjzs9RB8ZIq6rjDlBgx/zzNewQrqkMpIktBn8SfO+6aDzOUR8cABpKLH8reN2goymizF/48Ku 4Ps9Fzs/ojDSur1lukj/4aONiRj/+5n5n7a+Ft2PT5rgw3//WzTzn5jRvzRYar+YsrN/B4Jp10QX k0prBX0m3qugTPoQ4N2B/9M7md1Y9YGzGXfZFkjTu70CQp3akXoVReow1WMfKS7nGZBgT6svcOkR BVztDGVEJr58GTLHwJoxTfw4Zzux1ftl210cSAiYtLzOyvH3zTvLR/R86x6H4SjtzmMCgPz1F9Op 2eL8xsYKB7uplib70+sanRq1bn7BGDJpRATvUhQ0j7X5NqvyRzLjOeH1pIjon8/IvUtviQUq2qO3 /7+pVXlPqvbMf7gGqAHDUM6UajBFk7Xv59zLjTsT1GAsFp7PPtIf+GGeumnAmca7mYpn5IdfN/0Y rtDsd4w6wS6p/zFFuJpWShd+jQZ/fr9KovdUFNpRnzRpd/IhKoiYikaJevJ99gl783OPQAqcinXH HmrZ5oVbx/f7gHLcN3ZlR2L1n+QY5olO2t/6X1RVsIA/TaSeITVtcxd99FgrFc2u+LHH8w8Nzewn pEAFgqJoOSCu7qTrfGwoHzK23fYqbnUdjb7iAVV6iJwJWtyyimxgRzC+8UWuAqAMzZ2ZoShSuvx5 xmcDLDs+MjerT1zclRC1yE2FK86N1xCSGYMew5dc3417OL+Inv19nv58Xnod8GwQPtP/D9CUutep p3u5uMMx8a6+vOVo6ICOiuueT4DQ1xXAUJahbfOK6mtJCVWKqVuM/lI0/Q3h4NsMSX/nnNhxsAw4 9kEZmnEXTNOHjEG7yNlu7fmwdvOgAuI8jnv+XqEqZEVGW9I65oioHA85TdRpUt/Li3Yku5MbaNpb UBpJXaOAvEc4dfHCfic3FttBzusAsA63DhJdCBw7VEg0cjah/e44Pww01CBg36EJjvrdIpSM554K VPw069Hkup2OHPdNgKc0dYK7PweOEVWcxXxv9D+RKQJ5Hm1gSDXOkt5JQ1YSwH0bT2N86QWrfNZw xtP+Rud0ycLMVFHYTLog6zgMtBuIb+Pm3DS+tfF1qL/EoTEOm6MoU+iF8mcNVrUECVJU5d0jAqcK juRLEa0hhYBEUhlH3gmhGul+Gz9vcvFnP9wIzDKIAElBAbwB6HEb4x0HS5KXQ86611QTVWy6NjUB 8I03pv6mUpPm0+7KMsiN/+54VWL+63d4uYhNEZnksNbzs54aaidKJZRtvMXAjUknYlTw/ivV+1sn cnais7ZKZxWV9tdDaWEkJhDUKy6Q3KpgfSAoCYS4CSD+WRmaIBD4JOaqn2M0ieRkomc5XeBTEjin Toiub8LUFbN47v/2fDuGHCpNg2RQc0KRdg1nbyBL0FOsZ6XrgnbX+E2QepJ9QhzzlUxFt5k/XOzS j2vVIRqoA2lgah5w7D7PBNc9nH6n29uqn78T9e65EcRiEXouW8hwU/Ao+eUKegWCj28C5XWoMw6C t1hifxLulyQll48AiPXzzIR1PIkLPXeQ4EsY2tAVozhghlPZZvbg9AThv4UzLokOczA81aHIFFxm xfQO1vvDWfsSWUICZxa5zGTqFPKriTCEg+t/kSyvgQfhK1TPmLBBSDv5cRjVDPXpLumXxTFNIZTR EsHsO+AdlFMVdWyB3dd/DhHicw4rqwet79Sco3Y/eGvid09TRagQMxvcgynNj+4NEiYSycOx55mJ qo2/2esOaGf6UA/kRojyINoWs81MJfs4k/VGHL8GQWsneKdZvoJY1Tt5Ps/xdafWevRJz0Gc8pg1 6E3l46fNdQXVugLsznjnJ4bRxkT5/ug9F5GUB7U0uTL/CBipKnhFcYSJ+vREKCS0T7/sMpApOOcd teE2Tsp745KUWReoDO5MPL8ubOVzxfM1eMZOxpG2W3EDIXNKvWrLLeyZRPdudZ7rguFXXU725x7a uHyVSkNn+fIoKmiqK0e0e5GpAp5b/wv6dcH9uEVCE7WFi2AlOg/f82BKzeXorG7lyINVxB2kV2Yd jxE9q7P28OB6zjad9efWNxuHWn6KIsE+/3b8TjRdcWazaZHWYHYmMbfeI93nX97nZ7iLvvt5t3rr QRfR22FtfGupxEupPr6pLMm0esMpD1d4n48CdTecsS6rSoVv3ClWLniGpkuP3j7YiADt+i5NE8WY HRpNDbKbJOA1rlIYvIs0pQdPeZOXXpM1EEdenvWLG5oPIz7C74yZZzTcbcBSfO6c7JOozxnIb/6z z0R4n/93M/rvhY7DV0BMPXastP/0zPyHmKcgEybSTWxe3mD8aBCEvYNnO92k5n/EWTPRBVFNv/GB HEYfXGNZOyuymlze7ZQqRwuDdEWypqSvk3ieWCCfoXEeNvtZq8tQ05zIxJoXIY64Po+T49QfvjHv EEqkoWpQmuhd7qCxa+fvSJZc3a7INpLSFPf9Kg3e1a6KJDAIjaFlD2fI5VjUNlRwPT/bIImAq033 41urg1FPYbWm8D6vztxFk7NxNBKP03CxKh8Y6JYGcOE5+76NGD6ryAOYEvQn7kPU78Z5edl3H6+U BlyzmQjVjR2ZV/o0pTkDwx1fy/Sg1KE4TP2uRsSQ9n05GoehhQDD+zF95hrzwT/FyErgp39MYVXO DkrmuCnHqkOB9M1djAY0lM+dAxCXG+ljtcbBIWHqyhy8g/oa6Od1ucoc+h1dbcLAuhbob87oSeAB v7POnm3gqJI9+3InNzsqDSYpN2MKtrKxvhwOp4GYY+uqAXzo51P9Y9ArQWUZGCZKfJy5KS4si+RO ku3//i0XuBO0A4XajUa5wpCP348N/j5miHB/BWkXqBU28M13r0V1kasOixTiZwcweZvQUyibJuh/ kzZ+CRDKBI35El9CZ71xP78NT0Aj/TQge/r0r0t3psXMM5nIUzKXVFLM/D6XtQdJHrpQ74w0XuTu AyT8Z7NRZzLHHzAvP+2B5vKShEx+/y6IZ+AsEw5yOohcznlycsYF5NviIyoKGnjBgq1BwlmHDLyz bO8Z4+KqMusSM1wKG2C7YuvB2wFi4WH9+T0LzQC2Acz6813VIpJa8ZJeFcIYQxco1796r3Z31h0N pBCg6rnPfprkRW6tGMSMZ3YQaekxlA36JstugZWnu2GC/xW7TBF+tPaCZDGKs18AROgL4lMCJW9i gq/zYPE7pnLugkOXxErw4CuOkgny7jCSwhktx+j82TGxfBwu7Ilzip6BsJA8Al6McmvELhXVzkbd tFr382GHO32KOgIO0kTDnhGbfMMkmOYT824gNYxAw2/O7S0FiCMXPwQ+TveJvk+N8JkDgGSij4Mi W0KKprmr4x2IO4unqCllSTGE4uIErThpWQjJVfMAsLT7mYyovQ4EvBYEZOLT09hFbiEQoJBb9yXD he/rivT0KeTg5pvrmewvGey7vWG/qTeAKAAXKZbv94HKP+6X9hIo5bozeLBOPe9jPRKJLSYbvBxV k24Tik4GANRBH8FwmfB2CmJRqoPwSQnEm3BBeTEt+vgF6lJYfN0vyHXujZXMzkuII/DTY4fx3074 7CcPABgOJsfpFIgBSpv7c76I+2OOvZ4YlGdyw3jmfUU7/x1v3+x1+IxZdcR7zSudZfKu5LN8JWxp ag9E/XUXml+iLY0GmneRb1+DkdO5/79B/w0OuqQnBZ2pgZ72K3lkmwgkwD0fVN2uoX7ScBqG0IcD yEV1hpNj+Dvxn6SaTXF2zIGEv4eTLxH7c7d3c4yL9mlIzP5PolA/QwuK4a8pt5iWk2ViHRB+rC/x WtuDE+foPINR0j7yuV497uyecPXtiRJNRPJzZyhihNkRyfMjOO5EiAKr0uqJNZngRm5bQsL2xYZu ugunR9AgSAqq3yHzt6b1Simkgb9nvXkLy6gmEfaEubdEgfZqPed2giTBytRWTVGvsXTdJ9lvPq1D 3kFB1ZyDhkVCup+28crlE1Yy1SNioPNvpwekgPiesXrOCTVO5Ag/3E6Kz/s3RSgGD7l77whw/DvM 2YV880l650CHkey7rpzbwXV/t/fe15BrHPW0zd0895eXE/6s83IAlw1ZjLJn2uk+uXdm5pMLanwR yFyH05oVNeHG1I39Gn8Sfxg+paGJZtZw9RV1fzEel31TEfr+JAO5iBXy8Lr9shYu78AqlkDeU24D rosFogYjH/GagpH47VYnXsMY3dEuTX7eATmuYWHvaZsLUVYH1/wH4fWUs7R3iJsraMk0uXLtHGC9 d9FUsda+BzJl+3pzG87pjpVRojAnlN+MeYfILQUaBgFx4mhGYRLxV+0+fgbDXnMzMy66KjNtYbnn Gf4KPJoHxv3x736ESDNbSObAuu29smzibP65Nz3Bs7CBweV/hbcVjwE9LtJrL9H7I+dTEsE1wWOz 2LvrUkvYc0U0t/4QVauwF7M3ukKtVhdvx2x2pNcnUmVEs54a6gxLSIA4S3+LMxlcEYpz93zS/9XM /J/vubeN7/yxN9Z3/0/NzL8asZjXbwNFr8//DrfVc1ccjJ+Tip5EM/O7ckFl03RDsWp+BmU9KeW+ A2I0Lpp5EV1fcxeFK5uY6c2EcGkoJd4mPm9icCDz9J6fqluvzicCkXu9mcRs4fZmXF79gnGIMX9j S38yYNzHuEHMVzf89M8g9BlwxW5L84EjkphXB5U4JoFOkz+HdJJ0IdetW/jGtjO6Pg0v754IvtWB SIK2xI8Bw0G/ncP1+8xpd5XB+vbYL0Jyi4cSUb6SPFzTP68w92c/PSeTZsACYQmir4HuTpw968i9 rx4cINcvCLLOOzC4Yk+YEJHVjg5HkLzGhuYpU52M8K5+Q9jfetgMbxZXlIxBS193GPMypvnWe9Dl mnp81gnOSVY34PCZkpWJlZsbM5qhvmZcrArIcZOFdi3ufuNa21Dg7fGNnfAMGVoyznmHA15eFVcS 4RsCLD7WvAMvi4TtwqTc2iT1xpzqhiZ9T9/1DvkYastIosRqm9W6npl/kDNKxlsZ268Qhjhdu25B i+/7grTnyysAtHkKcKETFEfl9DCs7QQYUEVe6o9T+6jF7HjaRPyd7sy4VgGZpzgkBxvMWyLrAFhC gdQtwD1N/E1O1hEONRwDbgQi7mRXkx7mkMp3qC060WtK8UTAXU7TdAD3/flCp7FLiG83rHSdYBiW fZ5/yGh9FOj38NjODD5Og93TjgrrjO7qhLYhqNJYjN6Jz7U6TLOSXge/yMFWVCy7Hu53oCcdU2Z4 Sr1FnFZqBsihZx+LQYy1jz/HArboQrjKunuAqx/K/5+yP2nVtV2SMKCMYz8QZ2KDDlQcqNg32PuX /QXqxIENoiI40IG9IqigKAgaDqr2WndGXPnsY0FVnfN9e6/1vs9zN5kRkREwqWxyEzZSf8ZY4Ytg JEFNNh0OR5YZEiR1ieKZT7LRSBz8fGVfZKXLYuWPI44X39BNuU7A4wG3h4JnAs5Tk9YpoLwjZjMy +rqzmJzPu8kBps0jxNhTuruOcLiLD97q6ecRzuvuNouHXBRAJq0mT0477t/TzQMlu3goGPMW0F5n Ot3x+leFyBbEdpFO4WRzfEICqGfIsSFTXtph+Y1H/GeCrWj0Y60XTQlMyFFBSygwnwTsLeZsQPM9 7zpW1ENuXHe7aYR0u65tZ54W+B6sDIrxXOcwgpUmTzBKwNhxvw0i6XD2Ig9/3qVzgro+XaGvKK/5 dHC/wHGo+Z8a69flg9wuCNxUrDEmMnY0eIYLJgBG+2jOJp13oo6sDz2uO49jnF7xaL7Fr9EjLSJ+ 19js4HXRgK7mn6NL5y/pEi+Y9yNQcgqRN3Cvw+2e3oVRNnH1bP2mq//2lwvQda/EivbugejPtovT s280p0vFW9NyFcyO3KN7bMxOpzIj1pADVOwk+beBjhz+uO79+SfW2z67UZwr1aAmA3jCPsanMORy aMk1mvd9A8RTYtCNd+yYxK/7XgivGfqAXxfePhGEe6mTVVL0NXhGMXJlBJehljgHDgYJYAJ8U/zT 8fLsVrlNDujOI9uL2+2dgyXVYoA/fU66Rfqru+yIywaMXWTYl3j67ZcEwKxwKG7XK4IRaRYha3hA nqXfr5sJudVlqoeBLC4U1OGoo/65+07y3xEnNY72pmOcqYa+CGayMnEYeQxgmBf0HjW+9s/wGdN7 v6HE8rQiXBsn+xERaZAYGbSK2CTKFqbzYMaUbzOtQZ15KYRn97rZZ+h27Hud57xSTdigJgVqM9+j ELuPYwd6ej47qeaqfTfZ17g0GXZgnFaS5z67pSGzGMLKfQxPkLM11UEl6DcRkF9DKDPsrjgfDlkb 6yJ3YGNCVO4MSooargXsw0ZAcZ8LegXGm1twfo2DXrenqsak9JTMvrJvj0Z9Wkhg1tsP5LjX5t3f 6BG2kJuYYGg17z/PlOHUHFirg6g2fKubk7ktSd7em/LxtqNzChg0nKVJz1nL0GSNEf3BgkWIBt81 i880/C0zakGZE1XjaYqTTX7vxc2WOFvcJ6QAhYTM+696KBkgkzlzMDCl3p7Bs5oE7r3XBnil+RQ1 X+iXH87sSnaY9Xi1jGSMqH0kc/0Vk3DVRil8gx1QSeOdqBA7QISO6UnpIORFkGYdGJdyJ7Bo4YdT fbF7B+8sHeKiy2Yt8VuXS74PAcuLxxnq9jkq3JVo4t86r88JduDmlK4bR/aheZC++tKnrlBz7p6B ZKgD+5lOcboSZpCDtXFULPcY34WEp15t+JtC4rWWaDT59h0mJ1128tbZfXyIrtdnu6Vq/O6ZqV+n kXhwMPvK37QAdt28s3CMZ+2//sb/14z+Z3cv1gMNbypJPM//wsz8lwz4tFD/wNWwIh3EIO5dZ7X2 sDJWWdLcn0ugFTHe8fvsm5X6KzwXkl/0tNhOn7X6uwZVqah32p2GBxT69puN8dsgthYIb418sOey VhBUAYOmltSrNybaJ1R3Chp2k24cbw8TTyUA06ANJ6D0EOEfXOJNCnH1fBMmp8bzop3S46R1vDmp uEoaNhHqYXrvNwufic4CgyZhrpIe/mobPsUwS1Yqr+bKj7mpemik0w/ZWAl55jJvor9DJm5UASVT pBMTK2Oi6nHDnRkR8F0LUxfTyRzwZ06Mkcdu37PZiGlReqXQEoI0MNv8uetWm9jhxg98domHeVTV omTCeZtyUj30m2BowD2hltJUZ+YP7untyVnz5tUrCj/vThyWkj2nQbPsk6h+3Brj994RmFkuUysx G5fck2HogQa7CHeu4XFPJKe4TI6FNxDVF60VWfWb51Nz3LxInwNGfKZ7v7tK5b2hQzOd7+sfc/z1 OeGmh0z2jhJiUXQfaz4n2txisfcIEJVtPoDxGQrX0TnppuFPb3yQr6CYxL69cbLQfx1tBBHxt/Ne fv8bGjQULDojApcY1fydXBfeHGB5Okq4gOz92S6ZYjdPv0Cqo6CZk9bfBHuXCAYygg55iuzZEZBz UngEnSZQsJ9TwwQ+L0IQAHvmy3/DIHYhUdm3T38DKu1oP59A5IQTVDpc5sSnLlE47ut0qTYIvzrC Rgd0QQKcKwaJYnopiHri2aVL+l7nQea4nci/CIDltqMGvkeXkyaBMz5CTUN8ckwi29Qad3KF16DA 9dnmcRrdIGK7VfjEjXOAYot0FEW5a41J18n1LaDeYDLlbRgm3TruHCk4zxkv1iACOdTqINdmkY0U QcdiRh/nj2AAbK971ZDKBgEUKQtEgbSIbBYRqFGRgi0CJzeK3zM3kw2S+BQQC+9neGMajTFmf5No AEkjkI0rib2vuPiJSHaFM+8WGBhrq9fRZP7a2BnBs1+nJJz8n6nJ1ruE9oJoyN2X3DAuwaCR6CDX 9ec5mKQg/oTNXIDxJeW+5K1XI+GaSOeq7Hf62R9N9RttteLz9Di0Gu5qg5eXrwE4aGCdQHKDMzhx jo3V1N9zNYTd07yi9iSY9BeJCfk59Pffghd2ed5iyS9H6u0cTW557B6dwt7XRbrHErhmoLSCAeFp dnO/A5pEgO/75gJq5xi+beopnfB5XS/XlDXcZLwPBmjMAdEODxhzT+w1RKS/SPdTBLErgQ0WGoB0 nSTyIMX2PNEQ1b1OWpqBvngKVC8aRNGrovv/N9HYcd19J6rytbSGIFiUIyAXBkMddXQfNJJDz2Lf jTsVhkal39p1ZfYcLixEg/pwLHqFy9Kc0Y/5nH+FbN9pbSs9CofwW7zwNUzRzhczM7eHbzurc31w E/XPYJy9cB0VKSm4kb9CVnek6cyNC7w1KNUh9iwBi+GOuAjbEq7rnxh0AgOGW/ijBwe6BWV7WLdF TnSH8LO7RFTUVd5VUqc3zIFLNlXdyQvpuKQ40TxX5PQWrt3IBz0bxoNymGnwBPdnxOmVJ9PGG4kc 3N7BOh3n+Rv7QIeFLlTSPQL5Co4Nw8YC5OkS6VNVMvOFf1+iqEi7U95IAndjMVlZ+JeRYJk8L81r jATxPpOVAIPTldumT6T24gR2WohDjvmv7zfwiY2/R81u9sZU1P1z5miq1kcmqPyKGtispMVCD57u GXLbm2NgdKIOy4QD6gT+1COMB/j433kwDXZwT8FR9iJL0On+++1aSyvRMbjnJeAW9OyDVON7bpCT 5JbepNAJHVLVGP4SeZsz89KBcPVJyvM2xAe+Otpdu/zwHKKhMH9iFS3k1vCgVae0lltdkPDNOfDQ 8ZRzovtcC8MjY8Y03zx7iGxQJCO4MSvdEW5RHfzCH/L8h2Nb+7UNWJz15Ykt6Uh7IoE+Cd8E94X/ Upd0bdv4ufE87GEGHujvXtOIJ6RbH41pkBd83huUynmN93M62YNdSNADXmkdV93gSCLp3m/JZitF WeHmOJjeuVyGd6RPJdsK3YEvn9mNaZB2YIuys0+lc8t/ybjd3MfmlWisY5pvzlXlvUduhoyHszr5 SjGQlAObL5ewU1z4CVAaXZqxvBjns3Y0WPPeWID/knau4psGen1/JHkU3jmdjp7OuluQ67nctG/O 7Ds5bIo7IIESKQoY/3p/R7ke/xl+KOOuNiT7U1v6QK5nO5j+72fmf+ynJuU3ej/D53z6r8/Mfzjr r1UF+J+0N3o1PCaf3Ex21w8XzclyxuSPQTSczQjeO/CuJlR39E4SIj56r22XPoINP8cXuiHU3zCO 1Xfxm6pycdhsaqSoRfWBe02lnZ8aooUvXFmtPEjJeBunlQnSkaYSHYG3ObUizXNf4tw22hPcGZdF gWvQZ+FKpu9PzwqGOXL0TEJuYH//LyNUrhO+8KJ9XoF3fmhquEYbSP0wIGjUl08h8Il97EFtVbIh DkWvRHQaDnzeQZhP6ekVhdoyIW6e6ZWU0EIiehO2DfvQkPI+mFypI1/WJ5ZuxNYgK0ZkCJmaGa3U ZR/DYKlfS92goYvKASDS1r5Aym/i5xymyr9YnRDxbUuANh66UzXbbIjqP+E+ZLUFGej6TMv5MYkU e5r7yJekNcXshM676DJYYCOsC2+77HoJH+2zvbWHbeabmuM2T9DHM+77S3PXqcb7YeDczL+1//k/ aA6BJnO3wON3IuyPU5OPOIwtQL6La54DMjh9koM5k7Uc03OBGwN/VlDEfsXFtifFH9eYt0EXHP4q CisL1Jkpj01BlGe6ZvbEySZe/v5UtriDC6Ns9JZD0LyOXrG0ddF56bDRgbsU0iHcNkKQdkLo4hBc 9OTfAPnrion19NTtDbKRW1WLG33KWy5n0SRl+nNQFOC9CqhspGZCO4aioq51Nik/oGHEJNZwxAsq a1aj1USFH3FHrpeMc/PMGVN1O5BzY7cF9Q7xNtO3Gc8tuFyazC6RrDNqUoOO6znhPhQNzIM+f85E wcjA5eExILJVNU4cNdh7BURzSqLgbQ5DuKGpNn+gOfLxml1n9ByigRZqGTwZSeig85zoRuQUbseZ 8k0JGMG8OYObvRzcHGKT8z1Nu3xMnoGeU3gicLlYk61S0ZH6dDLriJw/E51dnF8OMdtZYZSO/DPk sEOQ/s++KPd8cLY9J8EhyspfYvgmzVdEVJF3ubZjwlfteuD4TyrRNtOYTf5q3rQOTlqJE8VzvHOd 7W9F4n02tz0EQcDFgFjjd+CRxXmXhKjjoX3U1sIzxAfNpSDUyQsboP6ZcyJ9wvXBi8hogLyFGYrh 0r86bysJ9sGz+BIEERBPDhEKsdMiasR31gAxSnVarrcmXBscdRBzzmrLFzEUtQrcd+MpudkW/5Cc wycdNWdNuwfBcFANSLekSjkhA+Nyj9q8Q5T9QYa9oqE/ZJCwW9ICB9Ppcw8nXO6WNBCYPeLfYtKp ViNRsIAMumIJ45Z2imVC7JaAzemonQMYt4C4xMMiskVF9Dpc5VsErkcUxsSmPs6XHamaULkqWpv9 2ny6JwlrWdh92vvXx5r/0wP/Eb2sE+uoz64BHqQ53f1REuoifMAZ67mfpUuokaSBEBYTujwpBgUE Igm+ff1pVuAiHrzIoQ3uCd99u78TqP66tWg4vDNBw7eHz1rfZ9qLjhREYZT54Or7iId29+bpQLrF B1elPQfpfyUUzaAQL4RgRnA5cUSoL7T7cB6OeGKB8fzVzIervGB46ytRRicpDNHtUI8RUoeE69DY Up8hP9/GkPHn37NEnzcU3XqcKZfvysPpSrvG232ACvh/B0MHUgENvZ0CS6eo97uP73ebqZEtou3z G5yJ7AMNuZzkjELPrtevoZ1rCJBGPPXx5gYdj69BwY2M6YMg3YOFb63yGtrUCIjIl7+T+AwEtSJC ehCreMRv4Y7K2NaOpEyhGa2Nwy+1qyQNjinvxJ8vnmjg9gPs6Dlbbkdq1X1n+Ps02F7OeYIUXXXK HvXst4ckDQgbyPZgQdyJk46e80cgJUY0f12aJ3ruFJKAXK6e3zG2owtj3s+BBoPaqX73XjToxByX DrzzHuDwOfSdCZueCQMOnf7ahPhm70LDDz1wV+ZBtdbiLPMW87j6JkFa0TYlK+Omeg+ZdjFQbwjE 3teuz6QbOsiEdh3dD3QF7mW85DWQcwloWNa+BdRcE71C9sSS495+j+afel6AjyZmRalfnsvAiutl nWikysGbjMVUJg9kAiBMWWZXyp1I+3WepMT9SIbQzKe788sj6ekWnEi7htIfSJgicFK/hb1tKPbC pJQQ73rTd0LXm0ZMIsbGslzcopBHnPX8BFXOz99QnycznfrZP6dHSDaH3mkl8/QU5zVGTrACE0C1 DuRvyhMf98dOHyaM2HHeQ9VrwwCygbFlRuQ914SKmqtnY6HfEvK5z+h//Zv/2xn/D/Rgunt1aA1V vFhJVCL/zhn9V2bm39Q4/ixNymAtH+lY+v3zr3vucqvW5o83v6xn0PNLhzQf4jD1XpVultXbRCQ5 SFWtkn2d5zYD2c8wjaXIpLSNDtqpefB/933P7FamJu+aO+/fAa3OiHmrOdQRawfYaFpIvFPjkvzZ XuxL/4Tl4kyaY3C61I+Zm+YvaCVp3p472YPcM/bIr3mjLnNMA5pISgveo/Ru/KEzEFYgNMzOSUP0 adoQYA4+NIWkbOb08kCs9BLyoAZzrdf0EXHU2X3A7vuCJxSbNUnEIe/noRjAb5bfwKcMVAoOrE6A QmtpIHm0dPe9f5JKLtf1e3/5o8dsnefWPm28LIfnajjKfWP/nMM4lGIwZPnCeKcSO5a+VQcG5u7z r171rS9IB+uDRyD86TPVDnFMHvYz4OhzoKOqjpVPoeQLsvunoVAfapQ95DgwhNYDsvowZ/TBpwpM QpnF0nN3Cu8EqCznSldpbugyvX7TwNpoqo3NNP+g0OUr3uFyLyKh2/pwHgB5W1TE/luKOHAf0Ut5 HevDoXAOydGxYMUwPROXV6NMAaUqIOhujbLZNYLZ63lKR7us1Wxv5+SnCfAl//ECev24gDbtSZFb LUwnOFKi2Kt5pn1VLXAJh6tZEF5d1dSLInwTAN+xXb8F73wAWn8Ll58HzFUBEOzs36BKC54ggscz FMq2AT1Fk7yn49qVbR/if8DT1yWEqPEBccOUY/5uxBfxqHkOPwjhVsRxvkCvaar4K3qViWxyVCAZ EbmbV9ytek/fKRPbsefXwWnQWdoI3zzAivvd1wBSRoa5pEGfF/gibryTPPpJk6NKA3q7AGjpDssK ha5VaRyuEB++BTfnC8zZaNJdYyjCTlJ4GFz/BS5yMk9HSgu3EUlKduGhcH2gckVAEvs8dfPn7WhQ AwGd+81wu1KUt3G2Ou/TF5TfzeH1NpLqZCDBKBhhB6a70OTYOx2fZjcvc5atRLDTb/cxDKQgKNa+ cI7p6aCq+/zo+L8AJ8xO7K84r9012tWdz1dKhbkaq++qsr/HvmvvtBASd7AwgcDmBcS45b9G6cIF MscJbh8Oudfe2mJTR22+7yu6F24yzt41jrBZNN7p/mi6aBJ91WZPQsHvvUu/QXg+dhtqbPlywt6Y vrGTj3JM8oo8/Do5fz6vrt7MJbrowQKh+KFqec9wXDcRoP4kBxT7VbHfhYKvL/D362RvoccFPK7a RO2u69kDzulmsxyAvcFtdgeZnQqIQoDoj833OLkSLUfK6B2kAZCRAd9bhjDzN0+WOYDFFJ5KWQF7 dFQ5SN6p94tPIehMD3X7o2bUgRik+x0AVqdwjxPU+mTX5FBQJxX89qX7nULcpWftZ1GVJJUAhwTF FbKqSKIwJQvw92zJu043769zuYVDA26xQpHXb7/D9gJegpXvMWQmhQBMfBzYaGx1Ob3CacUZSSCR RsyIRbCEVQyKUZ7zpZxCtWKGXQNYbYegGnyiYTFDre2FRfwOv6QJAwvAt2A1zk4gCxn09UmpDCYJ XMNmLYbNmsfn0P8lERscIclRszclQoitXCIhLRfB1U2oa0dKAdwDZtfd7OiVBP4z+ty3jGN0HbOd 1Wjt7E+WcckXzkgpFEZS2jW0zERuYK0SOI5yNDP5L+b/CrCcV0iZZ3ZiWD3oEKeKmY+YIi6N7mAt MHq5CDbN+a2HfBLeWWNfsc63qEg/v4eNWXYyj+Ie7a4yBdxCIszlt0QYfo839/D0vit/sRZDnaqj Bg83zXjP5SiqrzOR8V8cWNXX4Gf2KTrf4uUVn73yeoY2O79qVnrOgPhlf/8wLIoeaUJE5MOs589n 1cy0QQ2fQQNOp9XjiX/eK3LwIRgi19Q8F7cZVDrdqXquTIDhwaIBp/g5KGuKU5+DaBYInf4u2FxO 1LlL05UXujE1azJkrKUQSVAyLeEP30nIOjCaTAfp+5hi1KnvERL8rgGgt/7UMpGJG8AxcKyo/490 vYpFqDWTPM8l3hCcW5TBxSMmPSjdBmRsPbaNUqQ5+Ow2v9AHn2kUA7/Plqyq/InWkxGAgtdgd9nd yqchzZcw78jbhYr9X0W0dvEKrcl8RGForHGxky/GOngvXEqH77uSBowySWog3Z2Sf3QkW+c+E6Ih iU8Qzv0OSlPSwp0S+fd010EM9LpfkyPU0zPms1Vgm1M9YNY4zB93Lbq1I8fPPn8GYPLQ87fp408P 8L+a0f+Fk7JmGRiQ++nz0/7TM/Of3M7AA3fVrxturotbFLk1L/q4+cvKQkIV0X1Wkd2TY69uPvqF X14NwMVG5eD8O9z20UlEPSaoCVzn+2Ct1LzPAM9rwNdYiuePYeh3gOQayiGVQNfjSzwqrgFt4pNY /2JIVV/DAmBcWIM8qSqCAeityTFWG+S6TgPFhuSXHqe6TXa6F710TXNUIokBzwyY1rhwE9eA4rcx w50olmamlCjVt5Dg82f1snn07yz3L7FtmBJo0DFbh/HIXSWyDuUeVwWXddAx5cD2gM6nxoOVd/mD s0snztfi7mv4cKLfznrjzALZvbN91Hv8rDr9e2tTyPSIh0apA+5EII3wPZGeU9NDtWsQFN62gkum 2mILlXtglWq3+Sf2xJwqCiPWT9ortvrbVXEnAmvY/PG2cxBwcSs9ZdKwSB/7yzVQmTVJ80vcHzTy zM7vb0Jkaic6nTJ5owvriPFoXzc+Vy7/IBEbQTLVIMDEtS5lvqYK6S+RbpOnrjjyu4E9ppHFl4GP b9jXmD79CRViw3VoLJdlKHhO0qXloq+LFH+SnqakFs5ADNdGEPlVtRiRo57ng8RmAsefIsxnheoh 0uEwdh1WGpoam8MpeDf+cwCQEWH7owNgQDAlDP4Uz+zp1y3OuC/ImRRSvKkCqu/0Et9r5Sk+Vwjo tjM+u0epQLBNDu+i2h+ikQmXmK8pWHa/2i47IVjTwGQ0NGLD87dLpIcOy7eY5QZEaG3s//znTPnb 5f7G863T2jlZ97s+MtbyCAKc7XIgoHZ3y0NiZ6/XLKCV2Rk5n6uqKeA9WGJy78/+OmUYmxYquHVA FNs15/YlNwbJ3E28Dte/33cnWHsCIcT3XvqYoPRgnPndHHVDTkIfz9f9pilT4gHfSYyfvkvedoWE 6VYJ6pYZjr1icUOSY1/7twMfu9nsmFlydWynOB01npBy3U2QoXnn8lJDYsb2vQyQ3N9tyW/T+awm sUPjv6TIuI6tdyitgaCZy8lSFcE8xxMzOkdjKJOeP28mDjpCXSVU8mzhFZ/Dv6RbjVh4ptMDfEhn XpcmOi9aKLDcnbQB5eV+EuI0w7BtdiWpraNaf8WPIv1EQM/lpp2gg/v2Ep35LSrLpJafJt8XXT/D graWIwL0+pyPOx7wrr97QGKSMNMl2GgXmg0KbBG0p+PZ/RQsxufXVEg6znQ1FsM5zn5TBerP4UOV fdfaBW74j0iVQdr+Sc15+p0BoWeDftkPzbPveTCpbiJdvTj5il4Dch1td4+6o79Xw3x6XaFu4aen 5YB0qxmgwEvsl45p/hRU8Kn5DiK2kNlzDUb6E4QeHB6jyMpX7GYknQRJZLPcXL7hQ++BGjXBbzwP +755/7zB1ZTX6lfV540EYDoAdDom0fN8DGPsFJyf89a/WBQN56WD2RW6SxLhLWbqfvFCzXgtdYRs ri9yLnKZE+jjJ3Pv4b+IRDIfaK762PykLvK8eym+s6W+0zPRJKOtd6w21SaDn9C4B0gUtOvimRtP TAME7ut9BJr6IG7TIbZRx50uo4UJM9BNtadBeuNI8rr62VgjOuQZfpwi3VXn21vSKJ6g39tAfwzy aGPAiTpnT1X1jhkRo/6DSUTak461JDgDWTB1+a4LaoV9jwt+7+1bn0TPFn7EmeA3UrxNJBY2vJIh VYY5KldiHnwjF/OVHuoc6tRpubP3xzEWLsJOdESI9+gAwxA+iL90fiUeQOcZQRmtVzrUdm6l/JVr 2GYL/9ag2zNc4qrdNJzeq5PA5BN0igBNHHbAGTdFrTmYKeAHXtxrVcR24VqeAdyp7753baowROOI fzlQw1kocCAbqHcYq2o3+OUYqwFeYSfB5NrL2pEFKBNDIfrgqvTwKin58fwtZ+S+v1Wx6TXQSNGF y8k4MfTbzIoECNSvXUPmjmHyQV7lxphc/TFKDT8G8m42OM98Eq+sHRkLXXDeZdr5cjI96rtMkdWQ KNGAazNyUGKuI5HA/5QcpAfbJ8yrBurDPQiiEyvFNWCufelz8V3pGNx28MtRN/lrQGU+zqFZ51Ba TXDiCPnYxs97+yql+M/P8IByXKcwwe4VeKhjYnflzyWX9xwsf++3bQ63hVC8Fm7u6K0FiROUrnNU 6CRLsq9fYzA2QiF7wqtL2UO0QsdQA3+j6g97CHQq9TYTWQ5jniEH4HeV0LDzNtNobk7bPG908tvp 8kx5kf/6T/9fM/M/JZzJqM+4nIxnNPqvz/jfw+u832MOubGR1BbJK5ID/hmH++7qhP3eRCozmV34 r53nw5BJUHeRk2uus+ZuB/eD+U2ZcLHDvVrJUXKXve/H/VwYp2Nv4A0VGXpg4fd+0/eEGPZ+7sXf m4bzBBi1S5cxQ0aRjZH8cnP9dxT9s+jMlM5ctamuzx+JzopUhy8U8tt26xZJdqLGIA5DKa9sguCZ 6s1pn3IHqIMxuZReb+3+7HnkKXvQ+8KI74H2N9325mXIsVx4hxvv710jCFa4KiH5us1poKd42PmB esr0dOITpMErKW/swXvx6hPvPbJxykudMcVUDWpICLm+s1kevOEr/FxTt3Kll5ZiQ8Fbk9GSzupa H/piSWc/sixp1ByZF7czrDEBLNUHDkKmnneqG6cJfGH6Orto1+el5IccOuth3ak0zgGMaI4qJXUo AgvKNrTmHnmmBzC9cPDXRNvH2fabINP1oAqH+vO+/pHxajfZ93w5z7FJb3eYK8a6o+F8bBK+Togc LsDzcKkiMjOjshJmRAlhNOi/xdAT6SWtOKarYb7i7ehQ+ttBYljkOjbTDYXQW3S5pyeolYRvS+Wv ooeAjo4UfGMW2ZEurlKTIw0ASiaSaTfr6SKy59FvYU02tO15JRSdJNHbQbc7svQr3mdPCm5nLIZj yN259xj5ht8BfM/xKx2jHRdJ/xY1j6DwKAwZ9DMWpiQ3uiY/DSILBcALsAq4ss7QUEZdSAU2RpQi RLn8CCvWxbody3/FkVcUtT5L0LWuzAKLQcpWBYR8C0a+BBtfoJmGJJ+a7QTIMiiAqmwsBNl3+l0j 7MAmJCGp4IBYpoMiMNIDPGA0zhEaAtPdjjgq+BPivhusz8EDQ7gYR/JmEXUTHO2cSHT/I2zQC0xc E/b3NOclF9cBbc9TuO7ziaXxKsFzQ0wX5drxhey+cIFz6ZwnqJk87d2WlNwLEM2Xa2WRhO0iJs0p pNjk3HbbdjRS7+TpujP85Tgq2Jevy5HREfQ7UCu/F4D+KN0T7BES96q87O2dVPCCvW9dy+4jBt8c A3GoJUTJGjvBVxLeVlQpzBy3q5TbmVUz37GU5ADJtDOdPwafXOPd5MOnPEVbN+TB615Ykw/RDhLU 9Ip8DC/RwG8sMcQCDjthbEHJc3a7B9/I9fl1KPyao1/rbF6Hz16xBKZuJ6w8H32AC78Aj6PTadeh 57eCFvMc+HoGZ0dfwoWBrqud4RE+9EAMsmA4qj0sOip3kNp9XQP0eQbGCrYPMYjAFWoqrYLIGqrK +3t3lUpDGJeY0Dz28PMs9AmSXv3iLAHJYLWJbwZ7kC+gllwxG/jz/D1VweX+Sj/LgDGdI4BOh97u /TSXpLrPQRZQz+rR0wFpkLYQQtNvXO8C50QknKHn1PF7H8zlnV6mrsV9H7p6NQMYOpCS9w6/0/3N BKU+aRlP74omdV/xKftt+/AOy2eaLtJE3uxhmiKgPR/E774XDQ5d9DTYBYv2F4+M5znb+Q9dJ/ZQ 5FVl6HBfj++ggf4nBwRcTsvSnMRE40I++jsQzjmc3A4ytvAoDxCEVy9PK1wL136H1vAkFA9pLJF8 YZsT6RaNWgvuOKxLsuPUrnq3u/fcuC0KZAbxh/c6TRerAdT4WiEXlrb7qh5kYxfzxNk7fn59Rjc+ rPlylv6tDXe/5yPDzfUdso9K9NLrZ+JY88zH/ajzfL7wthRjCghsVw/to4b9dcLfsdiCb7NWA9YP nRBG+9ozR5LMdQ4/XYWTX/jdw2TAMXMlBjBmP3EfkrAsv1dj64+Trvg9bpHl7SNIdScPRc2QQyGn c2U65C3IyiGyJWqnfiGc5q6UNXKWr1TkSCjiakPoSFjperifJuq7qSS5Ky79cubPlIyJJJRBweMl SRSuSwMe5cMXj81BSKjnI4m0/2S/33TrZjx9zmepQfdgXXWSOzFKCte8W+SR2J2pTtfdzVLn8wpc fDEyHlzBb/1UNY4NbnvfCarMldxCIc2cw7QD6el3RiOZb3FWT+GlJpHQt0OtgX9uxp2SgP2B2fGT SUdbHX3pnXrXNdU76KTAnZqzdfU6o6tnYvl9c44O8Yug17jE8o3lsFGQp5NGvji91+jjNQp5nf2f 9ay/CYeyZvwWDu5enYRaVx8uVMzsG4lNJ1Nnkpj4Tgeis1xRwwsH2p/T7v8wo/8xo1HC957f/1+/ /b/P4//8jP4NPsxBOqEiDQkP/Ne8f9ok5lbOXHW7Fwvrz1qcO+wBnreHGbp3yJ61vZu/cgtu1lBl IEjmDwOJekN6hT/mVLoYUGM66sQwIw/ODNTuA27EmjbEEjITjFEIRJzZP00NCr26uB7m34LtLfTc AzEXy0sJDRc/m4ZHlyVYP4MZNsTtWrKTN6/71we+cBtP0jOn9M/5QvbMmpuWw+vUU3TfFH9XjV1m sj0Pts9fzoRZteybZMLPxIA7ZDUGgnlNrIG9p33wHMRhpwGhP3SmdxZvnxMzORa6ubuXj/gxR7DP dZbJAW1C0xiPDwQmzYdJ8UFmASpedGtN6PlzwvfFE9B+dPUtOlLdKLFbhQ/4wFQheRNqZ73YduH0 BhNXFU7fd23va5377dIcGFNJSOuxMd/EhoVpm4P2Vjxo/hqgvUOLqQXT50l4DUPpqEX6PFGlVevh /efAD68U7T105Sf96h87ZoxjCxwAdFrw04N4Ae87+GlPCPxGNYQTqHt7v85oDnt+mv0XXrBJ0Hja ocjpQXMeoL3Bp54DS6Sz0aOgLeHrTjJkO1m9k7eCaO3nUPZF2JLTKQGvuSk7jJldyhBpieJ/PwF2 r7mAdUFEg1u6ZSCcwq24I0WEwPUtSuvJRS1iK0GcI+YpAe7ncVc87bRYcSDW6Aax//Wfev4psI4l pT4vSAZEUrD1FWrkJVat9esBCVpPq6l+1ywHhTlJqF3Qf02bk/s1Tz4ZppU2WeEoguls+m0KhUkR 6fRIDic83aa6tJJoaR/8dPGfKuAvUECHSJBLRX/AkD0z+Xs+73uoI4AUz7T3abqx3ETtdpRahZPJ 9ccV98xrJ4UoTGIaGgod4El7kffzNoaiNih5t5wP3OOpJnf3V0IX3KlneUGoDkJfwx5ce70P1BQ+ YB9XwCM5WtDaEPoa0dDXQIGOSSb6AFVmzmZZSDIEySj2QvpJRHA8R89H3XNFye9o+vyc7/6dY6jp 5470K2R4hzWIbBIkMeiuNUTCGR9kg9CH9xXtGWsj1+ob8Mmbw1+whEdKV5zteLddbr6iwHlAj4VV BAReDt0z6UT/OlgywOX63Q5He8N6KyBOX8HDLSi6K73byYvvuKkaKCMwObZ+jnM8HU98kCztSv+u bZLCqIioPWz6utorBO8NwrGAUFhTq6JLa8r8GZjh8dN7ULkJG3aKdYkLFSL7dIjbg2dae0xQSeqD BtbhpMKfczvt7vv/p0907p2mTHtw6nkO4jtkPp0MVX2j1l6durMZ5NCvoBiJQoBwzcAZAmuec2xX ldwjiAlX3NE+BuDmL0KMBE9TPLKTCHY6EVWn6Y+dqIrrrF73VX23/fkofQnv5tlODDrqnd8B3VeI MnML5wT/S98xz6nAHMJx7wLgNvC9TywGyQFIfvsof4ONvwNEFyj4DIWYhk+YkNUDqqJ/kfK0vMi6 HJjLQGu4uz0gUppI3uK4y5fcVAxH9uCePntHclDZwlMj4drg69S5ulO4vhAYctoj4QCcZ6ZuMSra hktKKEwVKbnKl1TTF71KQ+7zEXvcDlmcSgEYgr4ytnZ0+htzve+e7wGFiTs+e5gtau69UQIYDSKb Ap99SprZZh232+JAVUW18K/T7H1PaYmgyJjA6BKXpiPGgaVb3Ml2By8Wro879bfebE5DKNGr+1gz X87eLfgxpI7GvWFCvfPs2b3aIA0lWB+UjpC9l2AI3EBGNqa4hRhkprOHNvRPSBJm3njySxy9sRwd t+x6l55y3WYcMkXUaXayB0NeEUHXIHPWsH4SCOa8p8ih30B0vsMjjW1jrekvkcTu1RKTy++kwpO+ 7lzNHJge8Yy/nFwnD6uq3V37sc8n4ecGsbif96qPUWMHtsS1/j8Trt6C8mvQKM1BhDhrG2tcGaJt DsW1UnMEKVZnfLTPKP5OnejiEiBsMVBxsPSGvPcPi3h8uE5eyQXMP5MQioX5m6v+5bW6pxcOnYGc XdP75XW/laaNZ57VIaqL/5aBpboxptKNLg7+evtGRiTPFgWfO+Bg+ue5XulTv2KZf8WwdZ913Mfr SL3ntUHCv85y1YeEWTWMrfnCtBLxa0OP5tgRATw1A3PgKBoyZXr4MDe3IUBSKdkoRhdrdJpHLrK+ ZNO/ZUao+ehL/ZlCfe0Xf5yPoiZtpcbmkHqeJYThp97g70myqbfq5GTu9L7k389K+t96/D8kzNUH b4/mKuP/mmb+cxPc/QS2teol6ejqBH0Zfy6yOWAub7BWSxTZp4bgwIFowNjJfPtwyx1kf3fyMSXK +WQ38jmXfFq3aRP1hju49Kty6hQjcvk2Dl3tYXRlmtvZO3GygdCV3MdZlglDuT514HuGjBCFuF24 4ihxorm7reT4TaOc5sxOXMBHCiMMsNtRRz1ibFFv3e+5LcZ6EPY1AdrvxpGAC9yWvtJJ+qbzYZi0 a4BZGgji2RKLprtbwB8y+uUfyprfpdqcVppBLeB0/+Xs/Tq/xqFXvPiPd2CbzW2Jj35/zOU4T+OP v8lKv8l/Xrhyc0Y0svYwfRLWgj+GGtXz++MZf521Onj03lN3Okr8e7Uw+1IlfvGVeoZ1U+uQ7+4H t3YnS3ItQzldm5M03jMq8xUazO/EDjbFvfrp0kvZNbzB1URXo79YjlB/5NJSGE58NjWhoVpjz9s8 cfdbOlDXXU/60EDr81yds5dOrvDPt/5HRyn2BS9YSk1iZMTLJtkNYpZv+cG+WBSgXjsMDhIfHg5G 77m5DfK+Io8XEH8biBcsMFIH6ZiwvbNfJ7N0Ehc6Phgd1jbBJ9gYM3O2wV9OJteklE76yeWk9BJf fyEOjuhF+jvCsKF0xs5IHxLqznIInyDrf93bjWVUAkR38e2DbHudtQSAusLdRmc8cK/BdgHZABYd Thxrn8UGwQUzc1wW7SRyBdEMeC509GPAPGLqzgU466CDcjJ2qiBOx/MtiCBpC/37Bk2/kyZSLGtw ZBHsAgLT2BuCLzUiU/YeV7VA1CTxsMePi7q+mqQm9zsy+gt4vs4acuSfYQHO5RMCfqF2RcTpY750 i2ee/aKz3AfnnpwAJNeqjGFioJRJ0Y7T6xj1y2/3K+4u1/bzbaQVdz+rOGZq+2fXRSJMCuYV69wQ +5n/fszxWhTINRBAR/esMp3DE5Fy5BhwJS7sotMVX0SEkaJZ/jp/XM2phl1pnQLXIFFKdO88Y3RC 2dmw/ABwyhJfEJm8hds+3cE2CdhuXp1IkU7j1HgaI8AHKfifdIEQwUiDwe1wU83G0gQCdQYr+pmS E3CuiYnIWr7Vsi9oZ753sMUggPk9H++1m/UD7x9h09rpO/o4uwRynDdyS+FGyPFpdzSeqj68gfkd QUhDVSnKyaHCmU6RETrxMLDSv93HuSh0NKR+qWHygIxjEGAK4kuQhCT9+yjyX6GlXgWucVKJbgh2 cHS5CDG5Q944NHT9CqAZijSM3L4Oo3SnbVGto8e4+pFvkVkLEy4qLL+j0FEgsxaec1JMPzSx/nzz vJt03ZEpKOKTqOSmbnfVy5lmk8Ap7hGmjiVIfDnCa9DX+KgWXf3I4CfvmEUdXttfvj07ipjBsqp7 ZwJvuhxqHtFTDg34W7pIpPl5trx4l+ipsxDmHapnR7skz5uccApMxIlJCbiqhiSBKHaTkVvsqNoX 6QZ1iZt++6hZwsZycFnpP0ZSy4ET6JNAJ+HLP5NQ549EthlOmWGULfsHP+k7O661sbfJwSClsEng jJ51p8r1rH7PR5LBn3NqD7pRqs2Lq6n27IX2zdDAchMYM+3+T+LMdKnUfA3bkOss0RFESF/R8fNB mnIFVhzJ+ye8TVt8GC58jaanlOyP2EvnGt+njo46sclZ1QAzYbhE2xqlQdsp8JeonIUf/Yr2vURK 2UcRvdKRv4Io4953g2vrEVK+GIByvWoRx+ucxjQiqFN8YaACsp1TwcCiBWl0orscnIAiHaP89nWM CmqKKGw8jAQYsOfEox8+kiWzPkVc/cVx1DWqQ6xWJ4ZTSEHZGbv2dmAoud9ywAu9dN2Jcj7XjH/e A2OKgn6DBqYgTcYXhtAJyIhVP+4EfQ75QB/T9bl5z+XULE0ntpBgR8MpO5RO8rXWtliBf8e3pUgn 0w73JSUwuQekBu/eOewB3r2uwz15/ok7kZ0yRzMTeZIpslt1g8J9W3CGuJF8wX23e2/GRjaHx3LK yjTSfBD5/mC893MnoVwmBlaF46mE7u+kpwHeXdsF+qinmVPR0fmpcmpRVrPq5N/v7CFha9oI7Z7J uA+b+0iDGI1wOGynbuvA7Wh3tUvj+5k17HaMRi2eA4ch8TekVZrwc06y2ejMToCobFfF7/VEH0Xq Dj2D1z6q8cBLDO/eRhUEp5DMwZVTRSRYvbsmUSXt3TVJYgKkohHuOuIxKZnUuLvSZbSHPDWne/CJ 9Pz8k/+NZv4vE3y7wUAAh6B/F+R/eUb/9puz0a7GbHxThb+BKds9mKmqS33cZwb8pvmhrM+bq8XB e3VWoQ+zRDq7f4eBmjc5veTdjKsrlZiFtwNmWDqTP7ILFOp5jGtomyTOaa+0TUN0mHvOXFLdFqC+ eg3WYUylXHaN9ltLtaUaD1YJtA9Z66vWnxCDuWYluO7zDPDFydlP3NFr72rA6Z+xsxxwTHFuc+PP LtD1Xe7a1mf/whobfagDVvo1dkGdoEZ1tt+SeBkq0q2o4Lc1V0pr89iXhnL3SD6VRdqxfoCT5Du9 Ba5HYq8yGWHz6Zdmbw2v+dK0dPWmD2OJr4GUgRORzHiyxzQygYZbTMCFaHyeWXgaAdIq0N7+GiVU Qtq7A2BwaaV26Guo1kfdqerifXCPrP/IdauF0TEHRIM0BnXGw0Moueyr19Nhkmvg0L80Jq/A/jIp 5XpyDkxMobNshtqIpHBvl+ZdPNTvc6ADUieeWuIfA06CXMjtQ5Zs+ck1QnFRtQjymuYx/uyLYGER i0DsM3HwtZzxR2zhict9TwlTnKuKeIMLJUVoa+ETYUCB0tRY8eyEFrH77evhM/TzbdLvg0M4jatq YlOo/jVxqAcgy0I5RS46RSI0ySTwStISrOT09iBVC4GwvgY7NLcUZSu6f6Yb9SVGTDHKV3LBLtZ9 NfIejDR/n107s0447A4S83Vs+Uu48+7HiWEXKvp67q/f1jW93W90iUBEwyhU6AzE1Ro8PZvO63Pt 1+GHBFI+B2ja2dl/bUwMkV1czvLQQjSJfs/QPnPaYZQE1uE6InaJep1qiTQQRdIi4c/P34mn03o5 p9OSOCKh19TaeT/nXejxup26z27HL8eUeQOZHK6EQP9LJg+B/ip4Xo8QXxVLP0CM5u9z3MezDCgE JdwxIsbEgzYBkZF7PVP/Eddro4BG+mfIHCKOjKGXG5QcuAvZpbGptjPw9rj1L+ErR/y9ZItmytnX IHX9+WyaE+QlMoLX/yYIXGKLqMc0JQNpd70pN0udAXXdEvT0eLRchhER79X+I1rS/RkSrHmH3zQU UwcCPs/Q8NqfLcIOlPGfDPFgmlNUQKkqJNZm0F6HH5ljCNPgxaAPkQ2JJzI1g9NtNrjk0+mxnbXI aYfODh5QfS97HRS7qq5mwE+fdOe+83NS/oKCdgpUpvuES7tmyiUXnvvuIwgoEb2hqi9wACNOQFMU M4C9mkyPyJXuIlxahPUKhBpYTVLKEbV8CVTyJmCv3VugmOdLCgQMtQiRFoZ7y/A95hGF0h0q/CZ9 T3rYXU4lYB3EPAzJG3UKKglkdlh9//4vaNtRjP7oJ9f7NVb+09G1UzU0EWOXwcA3niNECwxCtMH1 0T/3dbr/xRl+hwro3L4E3Uk8TBF8t7OIgBDQ6RLsGGDQIewhcnQPw/nI3Hv7Zp29BzvDdT2VIhyB wOKD9lIOYrbfXIq40gnbntP9bp3hNlQfN0TP54+RXJsSaQhxgImkuO6lZzrCNJ6Ef93MfLqdXGmK s9IxKBVQH6AyWwt45iOzUO8xA0kPM2bJh3Q4XRtEHDpvkTETIooBim/seX92DwkaCUueo9PYJOg7 oLeHX3yIR7cb0HiCxJsg0ml8ScNGKeEWDkLZFrS4ay20nREKEfqM3/WlDgdOVY01hRWk0cuqIVbq ZQ43+kIAipz1MsDp+N1VY+t2MN0DnnuAQI+zoF9Bfhii6KCW6hwIt/NMudlO8sS3XB7zD6FmIrie u0eDrr6rNo2fhxWJyIGfSF7Np8HMGhIUmggJcfVNqnkNx+kgw2NnKMToSxxPZgOMsPT3aRxZGhTr vATqEpgs3NWHe7FgbRObo4VhExKysGJNnLlTJjOOwfFObINT2oxhnLjER0XbnQvUZiJSnpOtVANg mxvJuO/9OxznJrvBvqk/OcDgUzTgeyD9B/O6683OiyKRFGMVroS44/4ozIOzoExYOtbdcc+bexNB /fw6XiZb+yusv1JZYtDKbYLgSlO4hIopxP9OY8FnI+JJuEsh4UjfO52wwNzG5nHodOnV6Pm7vQxj AJSMmHfBtw3TgEA5ubJd0/45j9/7VpDCxu6eAqw78Styk++zXTBAnHmvrMFwmcZcVVciY8Z0A9rb G9v86owJ678ZCcc59YvDpvHWZazW8tKj0nDfTwe4Uef3K6wq0bozTZoSsAmX0bTpmaL2/mIYv8bl 5jiTnydz4hzz/5yZ/8n6DMrvzkNl8Yb/k5r5LyzOSWzG8VMFaXeveee+qT2vGJiYt9xzro6IzRnX mZ1DMKYhD8O7m2lDK8q8mNh/4AFtqoAIie2+r9MFtUwRptaaD67k4CtQA3XVA2ytiAcLaKhEteeh mhHweKrzKVefzy539ToH8yTduNvLWeTJrhwg98Q+oRPX+GkdiXjUCRRf5ii/ytjt947pDAFORbxv foe2pfdds79UJ/DQrspo9uscpL5DdS+9mpXWEPngNzZO+/ZBnPLcNfjbe+VqNDp6+xh90TkQpJXK vc+hHPhudcKVAcc8VL1Dvef8Ni9YTzGHFURKzBgsqM+lSJf6suD04ip/hmJNSF0aQLMibRZPugdY tknAZTMbt703jvltVvNb4+ovNVOdiXCsC/kYITbEqoBOScmzWVeN/RjXSVc9OIivvhrQO5OyTQmy p+m+3sUXz0ryyV2vXxNRfbN0rBP+Ul7E73efCZ1IamKuH+wrTRxce4i4E89rGr051n9k9Jw+g4ZC tObrelEEi9GF76E4M53OvPSgZ6ZcYjzp7NCRRQ0U/fmr61hVOB+aitWWwWhuwfEWjbD8irdFTtj7 L/+/oSwia1bMg6MdM2xKMZmagN5vjDwB/TMpJBVEPa3ZegkmJDvu3B/Q/MwWoK+oF3/INkzuJinW CnBENKDhWw6i7S5FETntjNXgwR60uEAoH8ROkyI+irOXmFnlnChWNov7CZJjC6FSXmOg0K5rVuhS 2+QErd2J2Dce7rljLElq0GcGPnEk5LNomHIvFDZgOgrn/J6KRvqN55vTrUNw9qne2UsqttjZUYjr Qx6T0aJQMLzNko9CEvYBzyu3c1hPILL/hj4irFQOOZqc0l8uGeUEBoMg3t8tJw6pyMRmUDMlKNX9 TfvWfc4BDUA6DDJmI/EWle+ZeEUr5jmbToY5yMTR8zrBEjxnxVSM1ppiYf9KuTkEEf4n4mizyHzr jddVyP4CIn3EWM0heDECXfPhwjh/dc9UvU9/nJFzRmOz2GlQLkGAk46Aw0G4I1AabhdE8JCKJFzy CPeEcGaUVByn2WHhGwhwRXYVHaW3qe0z+BVf7+SUfyXWpScK0CgQ9ZBz4CzxARMEddvUACMJyLxE LZv4/zPI9odEUGeezXx2JkyqJ+BYjZ4YAFUIGjmCNZ0yDLCuP5y30lFhYpBippweYVCVRW8AAYvo SGG0YwGQpzPY/CVGNEUyDXZmj1QknBo44MrNhx8dxUMPuBNTV6hpx3vqKu8Y6r2nppKz+p4QkmOv IEolpqN6g55zVlyC1Xo9g6fOcJ6xT60scrkRCxmggk3A6YK1BgaXf8gqM+l4Of/oqFnvAaXv8Pjt +vF8thKPD+yCr2QyDboGYh/j6J23gMcwkHoJxK7vXnHn4GacbhMu98XYrWrHjATdKX4zV/uN1exo 9e3ucb1jP/dT3tM6qLLoCe0ie4xdz21ywT6rRE7Okd5GQg0/w9x7nSJO8tZennB/91/FbOyhCI45 C0PQUafDEDcMms+HUMuVYLYFUizHods2hTUUYExDD/5IxHSch+yitT+3TsyLnQTnuCt8yCp8YKEZ 2U2U+NUX0TCf18q/8tC24/muVVw4xTZKScH+xvzU9g24EJLcprPNJ3mdAkjqHb6TR677yNBZEP6a t/A1tHNjd+wrpWNUuzNM0naCElCScNnu2xwYLpDNscwxyOAw2pl1HhiwIyaCBhwcN8ZLtSVzQOiu uFJmEq3ySufSUOInCWiJYG4xz2AkvD7Zq8y+0geOYfvETl5sczvTcSrWRL1w9WQ5+JaYgPFOnpWO MZVscmO3dOYLeszVZb+idV+UbySsnLzR75n3KzRss4nFBSiTCFSrSdGPkwClnxkgTmZSOp971vFm tH04c43Y0r7LdtrN7cjKb4M5F4F0wJQe6Ted++KKDKxsIwXZk/ovdwjXJb3fbi7oeWNVvELKkNPR lvtREna1sCLrizT/SGxqP9euyne6cmM8LdS2b4OSNEf5yuXgFPGuA7lWVblUGkQn735JtP/CYGZI Xj0gMicMzWcdQefFTA69CwxAvM7v3/MyUGVR0p+KJ9gpyo7f+xph+TAEOcyK7OpX9WEPY+AEKKVH H1LoKwVp5k09MAhu2h6sk7bpnuM1vExdVq3h0lzMWSMYEvBCYTgpnOYesAbn3fVYDqCd/ad7OELH 5+devT8ivedGN1xmjevExPN2Zsb/h5n5H+nzLIoh2MCD/5V/+C/M6D82c2OkjJH/DhnvZx5Yga6b J3GFOQfHhf3Tc7rpEjpTCo0P5mRAHwD2fM4ehHhXfpIC0T6OvdixXl33iPGc3c+nUnIPs4LNv3yl 9rGmJlP3frG5zkK8rNj4nNNx53Q92Zx3Y1idjhhIiG7crU5LNeqVAv/3OGucx5FiGx299734mse9 Jhwbv2B7sh7woUSOrrF3MkG+Nc+dXm/EC2bIdfuLHXTbZjlxlZe3h+fgpJ2/usiL/6b9S/YTV9Lu nWOS3C2aK4+PAY1MGCZs2csY7e4cjHybi287xuNq6GOGB5sbty1ROeATlcyQGN2ftDRduhQffFJr Kknrp6hLfs2heDwq9UApYr91Jga2s1M6XEbRGxdwYYmJbfgD4UmjHswJPFfjHjR6z7ELD94pK23O 29iwTo3MqS6JpIKL3zc8u0ulY8xNnWOUjnsEh4ZwQKVEbKgO1jEH/xifduibX1PyP+v6H3M8Gm5G gubVVxjivpRZ3PUtDtwFu6emwJ1N21OgapCKbp+4EPeZ/FqfqXzf7mR9fbYd/46G24UOOTt5uTz6 +LkbWmIAuRdzXe8Q39sb/CXjXACsCuK6gvlmWnB6b3Fy3FSJl9tXyHEAbpfHcIm54is1EP9HQOyX EEEfJNIVmXodxAR/3UGPc7gD231JtkNlF+h+9vT1mfLi+v3zGnJVVAGwl5vHnnrnqOPn82g7ze/Y N0Pb/wwMmN9DR2Gnc7krHSJpOpoc9CnzFIgQ9tCMAjASEsm9YyUQpflyWLkL3ImJtD0Ywg52ApGq 3cS3f+s/FJ0kObnKIXMhoo99mqRGxq36FEe4CPCbDP4lDQjAaof4jhdN0SuBdRSes6YzQTTgmKq7 furXkNuOqWVgc8Id4XWeoqqEvEM6OeNKWFEBXV1i5jPa510L+5tsf92pXK6eQtK9I72pvKVEgihA vWPPu9C+ivImA3TUNdfgI8erGZvYgYSFARe4BHKNAhKeZj5C9z5WFdW6F8DxNH5PGsFL1A7AKN20 NeBEAJmwDqB6ho4afTYm5K69Be+7QU4x2b5r4l7TRZV/D9Wyw69rorldJG5Ak+Nmd6yd1A5Um1gm sr6B0j20eMXu5q0sIN3mSLdgN0sSy+QZOCjocdVL33+2QXVyD+3EJCJfr+jnBm4pSnbws+oEWr5I PB0OWHpINZ0uM1scobOPSon7PHUAnU0tLU3h9vRPnAzeazHb83vUPYhQ0PzG1BHJqCF3jnS3pm9l 9GzVUV/tAY2koYmQ5b3h42704ivb8frrfNliRJ/+Ffx/d6JOw7k+BS3tuOmfR6VFoL5ilUwgw9rI PZrx+3e+nJ+E7qvbOU0f30oHuRZeExLmDvQwl0JcfiMOtONQZikS9+rsl3S4neVwMlbdusSI7tvN 0DcqztsQzdPwngr2JFwnHKeXW+GcBHCK3XQKdXyC0btnonvX51udj5p8u5TpXJk3Gdexn33OHymY ekkE2NOza58bX+pPw5Hq99jMz7pEYiiwPwnIeAb1GXMm4eoeysiUGaHowre7MdS+TVbfiCQOfSep LB2iEk0mHOqo63GPVD8Tn0yN0+6zgF3x7Dsl60uy1p+4BS57YH+AnNpkH/kPXhyDDhk9GQMQ2Xvh ZV5CF3KkffHyNg7pnAcWpwwQueR03p6LagwnRVH2WQ/XO0WcStCb+BBJ5J/fZgXGKG0KPvdcwtZb oMS4j2t/6WNwUIVN5lXICQiNUW/cp/uFFBG5zqXAwaV1b1DaXrIWWQPfeY57d+3h6hsrWTWlkhQl 7PrGYAZ6SpRomOoRn9mCLca+hsQH6hgh7p6DZCTxTGJZZ75uux2/DnJ9nt0s7a+Lmk8eqntGhftg n3A5pCX0vbssIgw/5ULYmTeqXjySC93Z2MMO1uTKd9ljKc51wuAcYtw7zU5VU2rIeVeIn9Jg6ENS Q3oGnYMbq6T77a6TSUB0uX3fPGWj2CrzsfZ01dzpcW2Xphmsu/l7CpJRWeSPjG85474iX2kLP/7U xTwK0njddmucedUeJL7ewjEer+4hbFfqxM/547tjoizqi6tgx01HXTox2PYresyh3e6b9NS8c2BP VOdsM0Qd3dBmxD1f6ROqgUGzEKgqTRIgeZs1mRIM4m/YyCPo6MNo+CPT3r9MNRof7aGmHMxYupFd c/7vZ/Q/mI/cs8IkVWfSv8Oe/8bM/Js5GWQe04WjDn8M03IvXp1YI4ECxO9vaYfZ2w/i253C1Eht apeEAu6ZbbKT6cAbz3kFuJxulpiJoyc1azNAgPju+31PdZ08x2jjO8S7bk/fPWvijDkyQHfzIOZG d9Ul8JzjRO1k+/okUt+jR6pf7wXPlXT984718uuN3zI/zNqRPchqqDdf4EGgTbhqjaj/dLNT1EP+ 4RAHVUBeAn1HtWmoJi6x+zbwC/fh6Xt9p1L94jeCwThOOImeyz0YdApL8RThbN/WL6b2hzrs+ei/ OU3WldChqq0V95qBC3jTkw24dvcbPiv6Ic2BdBhifInBOZ0m0yc9c3SNXzjGbRs4gVeuZPqLc4PO lLhZHuJj3QrdGVkL0zd964jL/Fqg3ZijJv1CCidwS2EyoeEOfHs1FZ+7dRNexp0+MHAyq/49R8IO 17fpUX5mGPf+UBZM9WJcOfvM2TLudvHa/GByKTFirYN/Xdf/eIk5n1CMT1CKvapmRTn+TnDRAZZR bTNXNE0SZykM/NrMm8hNx6Pn22uLFZKUvFxPKL5MayolDgk1gGhyFztotPtwMbQJLP74ijqeaoQ3 ATcRhfjlt50i3MsNlhz+XheDMVHEvwePVwPrA+T9Ej7RM22xNw0Z8Lq9XASNwNQ/E+fG8ZcsAZiI z/B6+OEoVUCK8aLXIy74ijAzAhIJRqibFTNpuwcr9ptjJ+CMXz5k0vZ21yuwwQdJ5Jpygxn2Veik +CzXbRHInvlbYgNGqusCpgYJ1CIA1M//gh7LaU0J1NxC7wSnt4gqyBTPcVFn806x27wyBiPQoZCX Jr15jBKCXdDkpHTu1Dd6qB3YBCKkfAePE/oDGi5HKCiJc0r9FbyQi8YUxa5yDOhoseeOS+f5oRSK QSAbwuS20EECcj/h3cEp5o7m6aSQHaV4ixYnnUL0BfIGsKKMrvd8t4pCsHKlJ4ippCRp3vqPZXUt lt0pGZdggwl2fRS1LPBwnbc9ISqUTX6LTP1BzGluZ8SncvUrAPLZ1JKo0Sv+9a6JXpcCY0S9obo0 DI35BLgbNNBc0dyjQXewFdEmggEI2vMagDPuST633+Z8hhxgupvp+fEkjAfW+JwJLhfRkI4bgiBi nxWTS3xwJTToA4yotYbCxAYPXrcq9g3QB5ltFAYYgO5335RD1ftMCPCHu5V7qb873d3EuqrGnBK4 NECzwTjDGbXjg/UIR9b3pzQtWtvOSEmVo80COX+Lzmd4iyKNacAi8kN09+s7mrv/XWewaYE+HiJI GlpewKq/6YMkV7YzfaeW6ON3kqDCNWzpSnrjpJMdWR6G1djpOe69plCMlMrvMM+zYxbPBQJaoQ3B cpuurs/kNHGL5oy0umtYx4E3UHfDXYYrlppTeAjO89D4/K/7Y4tA2ufeZ51yUVOus1l4b6CHmvrf DfZqz0mEwxnkbsMpJRyrrEqzSaLfH2KJlygz9uV/JxL6NOc/0bHkBzVtTiUcdCwV4GccL5rP8o+r D6XU/AogfdxjPoaGOZhZB870Hqmu97YJ0kFEdM4xU6aMbwJCp4DH4aL01HuUcKVB8N9IYJO0IXrv Y93+ulk3CZkmExcK2QLfPk8d6zfj39O9O/3HFrxxxdkPOfceApmFkWl6SHtYtDTzQd4xT2GklgyE VwsydkinFk7gA43nRD4ST6jfrQm5+4rd/uACdMkr2yiBztd1F4rEd4YOUZ/0+Ov4TSnBWwRORhCU 39sYumrtdG2vj6BwfeSCrkh1z8l78XtUDav7cmSEAftm27aw/DpHqavVIeLxmWeUiA5xbi9G7yMD UeX2bnT9nIMkZTHBSn591hCTnJnG4+91ESZZr3A8+bub69BRaXVN0OYHXjyCLtdIsxNpGiwwzuA6 D3SeNwIOY5+Vc7IQDpFg9zuJcfr8Obvr2alnRgfVdtmllRKogZc1Wax34yBeCu965Fo1OOpKexhI yTCKC9jVeY6dlNWn4p7T8Zt8jpo71sXdV+R7d/T94KF7cvczmYyVQyV/y5rasgt/9Jpw9pn6/5nb 1GsuZLFYk+yN/QjN95DuFr/9GklRSuYxoOlLENlJ1H9wVQNzlOZcVzrSfv/JawiE7fDMtH++whyw UmnPobQXExfyt3NgD1pc365Hbhy3zwHNJaxjQwdHulkLS3v/pYGfEXMRnPlpjpFO9T56ke083Z70 wlruxw129a/63874/zq1Y+lUZAG/Zv4To/lP8SDxg0mIem7XWb6x3O4N/3x2/6WiNDP0wOl5mVV1 UhS5UqtYAi0YVNBjfTuFj3bd+g7RvEZk+sBrUubYskfBHlUkVulMUJuT6wnjLhsGHru3J2XaNmTx aVyxzFX0pFK4771MZ9IxCkG4jYB7+L1H2DiK0KZvJUnz1pX8Jeo3t/HHpQ7J+8dYq7T+IV2RG5Vw mWRsTOoYThDpBndKxKs/IfGwUDs3gFfOMRR/1yKN3/Bv/TmPbK6o9Q7l/1yu1etf/eScfTOnib4a CB4Mo33c9UEOonHdwdoC6pZ/fp763sr+P0X17ChuQAVVMm6PoV6HXVHrdWZQa5RGVmluQPV/1gWc oMA2Gp1t8GV+wO/72u1sh6OjRvupByXEcisptlazULms0gDs+q9NEzS3TjpGljShB/iqBG5X9lmD YHSe9uAP9we9HvaQfr/+K5Nzit2hMXhVwqGwNnn4X/MAQfdP1xjnPjP/UQeZ+8L9ml6ggkZLEOPz Ya+FI4hLF0mwO2aED744tDVxGBhFe4oYzmq6q5B5PpubfiHBBsfFCaZvP2KlPgUcPDk3w/NwGXnb btMdSUVAGxc4rc7R5+U5M1dslbqZop+zN3i7Pxrn/vhowTkuUUs2GAO+BRD6aKx30XIJ74iqMvq3 sLvA6CAb1ZfsK2LzDA5QGN9dpxNEAA1GO+4J4C1eyjWmA6TKgsV/IeZYkDoHJBww6hLw0jPaApMV beo9m7cHcTYwuYF4HbCbzlWbM8H0Tcl9tKMfk2SIhhULtQbBjAMhGyxJMQ6VBvv3NYFnjLSadeYR EJ6TzCSNFAzNXGDUu3/egsef8Tkp3let63ePv8kBryONioxXO+fqnxF0CEFjhtRpUGAXsSns0Ckp 0NEMdBzWHGcRxUXNQRZytaJPN2xqlG+HKx8RoV6A9t+aIk4mYAK+n2wKG90Ft3sYq2ujq7kgp/gp 4MmnJIa9ugZHJRwOIR6CJAjg8VzxZ575p2qubtA4NeZydrnhjd+9T1UdVYg6Asj9cYb6LyKGdiYg wKzfUbtKkkfLr2P6Ee17yB9Y3JHAPYv4f/67owdR1KZigHWOnkYRJ7jJZyNxRKBMJxE4iKG8fTRz uoJuN5QeolGRXH1+6CNqrgUdX06ME4IohwSeZJk9WPzATSao6zu9JZ8BrxneB5uANHyny5HS2APy MC4RVwPpQm99v6MS33rh/QUvSPSnZiBh1iBw4/PE7KjN3+FkHT0OnVQEnPz09h4Qbsw6b9Pl5m9j RDnA2LWczh6n+8ePgGHTGUs17wBcpNHn7aO/3lLkHbgq1WdomeHUPgu/3URmuY9nf8LJO/FW3eke e3j1dnFUOUEbHMruZKd72BCeo4TEHjnM78EfGpWdIJvDLcYMMW6v+j4rdTr73l6Gc+4dGPB4yTap sAEh3NyEOztukYmEFyD958xzjRSreteNJBKGIhDjt9Myk4pfvQyRBSkoDImu9BEQ/4uPkvXITqTK HscxIBXOTY/oWbOdpS8TjSJEkaq+Bl+PIS6o3civ/qfHdtQHsT/JTdn+pmb8iSO4ouZ3wtrMTuYh HzDCKbdzj0u00Wdnx+nue3sPl0NGxUP6vuYPJArQlwv52W1dNQClg/mMFxbUo++QGPU3C8s50tPS CCddqLZ4mz6bihgbHGMSPrFMpvQhTxCYg+gD62OXtFlOqDyuRgJew6Bd11npoO1n+H7d52BCsQl4 HUIIHYOsPjiX7A8vd7aNg7ZZh9HPbp2ubhw8CWjfSB/wbow1FvbmTjhMJ1BNp6H/nGmmgakjul2E mU5h2BwB3zeEsI9qrI0ST5m01okqbbEMCTIm4rcdA7F9ZlWvbOJDLmJ7jiEfSPbTHENVLnEpWwQQ Dn0nP/jk8lgoV85vSkfGSEOcgVTeG8PlFIfBd6FCJj1s+rMNQoRomQ5xTuIvgYfqrudrBMFbREvJ ceSh3a6WPQZG0pLNSer08ve8A3uuXmwAG6I0WhbGcLrzLZkBHK9Q7QH8aW5ZseNZ+DVXu/q/fVZV tqsHXIBjZOBIwtjGIZAfqRaxCExrfAwUMj7WHIvQt/bFSH97g99kt42rbNEY488G/myvr4l1Naen P6UN9Eyrj3tNMKozXDuN27T6s1bL/8SpkDo0EnNoNRRDgF4DPnPWJX0CcXrtm2KcJh1jVkuIepPj /vhXweH/bWb+u9cZ4MKggbX7F17pPzMz/8E2+GKcp4csVTXGcsnPtSMaUswUF9XQ7JyJoL8EhCH7 4RYVUvqHcs6lzi8f/JgyoehUnrCx1UIpfA0IQsKmiYPtE/0eOAS5oUhQ7zg3E/0QcqIC/vI9sRTP XUHkemH1O4GiEdXH6AA5ujb229oAeirMBM/cQ3WaK/PPyO3MXGYcnewwqK4QoKBpctD3rQ4Wfw9G UvazDqWankEWP7W3n375WpWUW+QyMmp8bvfQhur17iEFH6qHW0jDRharLnZSp1nKdd+9OkIH3q7z N8e+0wDvuM3UDGjxlaYo9TPOAWDFffpzv3iwrzYM2QgMA7bxD2Ngm0tgA9yX86wxb113KBmW8gAG J9xr0kSEeP+sqxd+FpjI/hY6s7leE6g/qeuZxtOcx9UX+sBR+Hx8MVV99L85xOQwb9P0YDJxTJ3o 2+iARMjI1T11evCJ59mHgsuxrlyavzd9dqByYy7Exymyne238P0dwCPjCxV/+Oec/UeVTZpT7kKC Cp4KumTIAgDFwxN5VMwN/rl27p2KvVE5Q+gg9++D/PcwckxIDZB88SKVl3Q/N+PFcU2M36AXTe/M R6Txnh7d02zkXq6PGNxsmHekkw8xCh3uBHJfl2OLc1bRrj2dmYW1jhBojHhwH6qCovfyC9BRmq3v pJk5Yo7uA1oVe28gWO45KwIa2SGFGxZFsdvOwb/RV5tAcnz+WW6Ls56RsXFr8p1JOg+FCK4mwSke +IDntQlKwV4ztkWGydmOyrmm2ho2obgYwbSv50od8F/i1RSXZruc+BCnR2yYZvRXWU6XaL+OFrew 2HF/vYkiCfT0IFMUJ7pg8X2+ETX+ugKliDN/7jsc5QMYnU8xyiCgquccyKb7Jq6F7gvv9Oct2ebT 4RYNXbGmOzYvye0kpX7BB/ap2a74R6rDTJCsQjHQ5fRyAy6RWlPEpfAcTXEsfyOIkPcVXWz4c504 sd1WblBpu1kM7kUBISGl4yydTY57UsNha88J7YsOD8DMSXzEeoe9d/sMzRrKul2SusH6cjIwSFOo nVtON6uhNGyzL4c7HzWXUbij87OE65i4XwC44CAT5gChHcSggVTaU/84jSyoQL2HcXzSr8LzxtC4 X9/nBhH1EEfkdJ7eo1+Col0HvnfeJvhapG5fzb0xcvmSMthJh2R4s6KOSXJ5whnw+RPK+ocGgALw kLg/o3PsdEgYIAuMEZlTwhlPR9HOZIpPxcVK5VTAnhvCPvKHKLQPEGQ+SBQf5+qUWwUJA+d4Fyns m3qbv6DHK7ZMYVu5on2QIV/Ofk0kDNKq9MwHhfqzQVk7QLSZ16XhSvWYFT9MPSzVjSwCeJ3VBikg TTkmekDsmXVwfHpfkh1hMk/jUHvIlgEyCnDtdEAa4aXRjp8/L0o0uZzY0h3Pj9iJqXMdhMWiCzxd I6odu3Pwdf+9FHj2WmkJ3RXRbhZ7eZ4hbkENR9W2AJ7VGojV3MLVX9HkJuSEKXhhKuE4F2284yZc oSg352+1SgrRaDBVVadFz+EmV7oL+Cay0FpEU33qqtOlGiRDcxOzc+AXGb0xF8F+TgFP10KUmPD7 ndpb5qL0O1WJEsz2QrqRncstT1HDHJJGZSB3+iddyLww4WbCwatd/vb+8zpn5qBz0xl4C3d62OLF TF1Y7U6jczyr6z503actAv2tpX+HhPzUf3HrQV2oGlrgOtur92kskJIoUjiY/4zHku7B+fm4XYjQ 16TY3JVK8zr8p5MUO3kOurRvDBmtEGYn0fWacPwz4SBmnK7Suu/Jac2zcUUfJPndnQaWoXby/8FS zPX11Tu1YPoW4b1OqULBR5Ol73Hw/hkVya6p5GOgvTMBtQVegiFHXuW3T5y2qYGnz69KBJ5J4yet eqB5kokBjYtje++ybcrTIxFLZObs165h8qn3vkTXniXq6Xpm37eaHgD7Gz6bDuQpZuPTyQdft3Hn TuX9EtP4MJq5EueSIYwk6OQmaqghU0jIUCp62khHZnuDwXTXHFhnj34V/+kjrZHNPgyDTbf1x1sr spTccXfkT1c8F31w+5VLhThkr/EWlxn7FViJ0n7fmtoznbz0fE6/d8dMJatCVTtzjXoa64qur+l8 23eRIJ02Mbs5PIXTUC4r8DzTM0Ho8rnu9GRKb3ju5n8FeX4TNrCCj1qHJcGtzdAhoWXDkPrd/9of bdOff04ISH3PN7e3+97OZmo8Nf9ec7OKwfEwGvHlft53vXAEp0/h1iN4PP4/zMx//0tERi66YR74 79LMf0Mz/0Y+ZYVcRq/ZEGepxd4O7EU1mBQCrUpGunUc/kkIzNH4aziDDFq+qqf9eTVb8L01A8ab ToUx7/pwZWcp/3z7Eb/YVq5hqskVOhrM4SQ+aiYMCXWcoRuf1qtb0U68HeAoyXBzBkbw1E8v09lq ZrK0YmEGWQlaBlMHyinrdWiyjLERjWDzIOZsHCm/pju1b7BVL0+8+7xJr26t3YQH7tnfXl0wjrrF 12RweqX4zkqv3ukCOTAoGnOFu+Tj5vLJWrM+AtiG5EbnOOcHNB8/AwHwx+22/dg9eHRN7lQxB27q s/4/1Ts4kvCeYz+DwRKkv2gN/bUtz06RzCTd/d186A3AGEndEeyhZdALeRDlT3woOaD+zySaPmo4 7fekwl188nIrCedppt5aa+vnVHzlZdFD/dOqdTWFm7z9uitHahtpT1VgjIdLwps1hyHuZPLmkW2Q zrvd7Qkp3HWsikfa6SGUMO/GmY7abQ/EDQ6nVy+h7CDeARJA4rW/1z/ux5eNGXm5Ji2V0zAxWWIj 8JOXye2G2sQQSWgu19cvMGeOmN+3OU+A5Ba0eHQUiF9Fq9bv48mHXQiwoGVNRiAtT4Du+50ACD0J qzhMvA8NQQlSYlUTBG+cOP5qJPN7UmjlCwwbotAGXAqW0FPfkR0enrbKg+iYOwdogUsU4Xp8/7DP 6KLcIwxIDAibdDqZJVgmbI4Hp/QJxhtdMLcOh1CfNKuglGson1yIuEgo4FD8m/pUOQMBP7/zHdW1 L8Ny0ZdiMvZyfm03XNfZftFp7FhVhL5u0aP/GujyrKb3AtAA6CcAC/XTuOC9VIKWWwbn+E5nLI8G gEWYvdec8XdT7lkGckYnNPZObEokAf9I3liNiQP0wgBw8K7QdtRj/8zY2SQMHCCSf8GAl7DwATH/ EfnRKaDYLzP05xRnU5NrPk9+hqB83u/zT+w1qI90U+QNZMfzFDu/UcX3CkwN35Jjo4n0ZOd3akoz 0ce/Th4/UY/Cp7iBp7cpmABxBoiFO/hcn7623GRfonj2Peaoex3CDDGoql17/60W/hsIbxB+Lodd 8ZlHopoEqoxEz8Df3vG6BpBcz364vIivdf0D9J8DYB2jKAhv/cqEuQG5Dfp+0dz/TAKBMWZUDwB1 Oz74L7BYpqL0wPJbizagUUS6mbje+NDlNt4VSjvCJnHdgrr3rtniJkpl+AYRvwR/CXZf58gWzvwz KRAcyScg1NtdiEky/u8JGqnq/teV3h+Rnvj5/RUVLojlMyRP/QUgAsLv6uRU657IpsuNddcgCQS2 Q+ZVxwZhcPR5RCi+5BOdtZcbRAGVmhqQyfeoIFZpsOMcZ/fUPazzdm1HEj9nDt0eKsJmk1eu3luA UxkcinKoREUY9XBAu4H+ONnD2aMPIbGgLmjg2UcvrE9SoMXyeb73fWrYQQyJ7z9tNANoVys6C198 8Ro4XMNe667l2zXjrjPW+iJ+kpCjZJJj+nhmkSxTZ8h4/nJWk8Caa/AUqayzXPogA98hp6yZb9fi xILfoUXBAKCOmPn5ctaW6hv/bbhecA+AF+1MubsayHshsrbNN+YkNDT66EM+RDAhEvglaP5VvC6h s9pKf5s57kPOiajq3FPvgdz+N+nfAwv6qBQ3JnGgqCEA3Qk5MKxpn+7CrpRTraGxFxdwiBFILqI4 wxTDZTMTwwHvGvE/eX4bE20GZSwCF9pIeNLMlwGRjqFmsmshp/geitfjMrUHBvmsJgMmBx9zCPvK SddDbtEtPHWRdpfb9ax+VH/hUVJgnTtcx/Mz9D4khIoBGl+cXgspBFyPqpelYY2Np9tfMhMSFKXx y5vi5E8Uprmm3/3bAywuUl4fK/rn35j7yE7+2sStPzFY6KliDa/BHQ/0VD2oCD7RIEIJB/jimQCP P8Qmb2KJK8Vmqiff9fB8YjJf4lR0jl3CDj9i1Yn15I8K4uJPt8CvezrCS4y8BNUAgnrA54D9xH18 D/S/v5UFQ4Jz1s3NmFJqH/G1pmq3LZ6Y4jZJivUOMPUJwq6RlKFCGNS4914Kgd+hVRZB8X3/ZVIz x/nZwy9CvoD8/Peb36xIDyHf63S72PpwG2+TgUxAUtnL+OiGvI0spKpwv5C2b5GRHwyA7wjBsCUZ vaU4aNXrns+RRap5jGf/lh2qqq5wL3ffzcYhzP1tytRKuQef6sZfhnddi7Dp3E8t83/w+H90D0l7 vrxK//Vz/Cdm5j9dqRpmzmIAX1C4eQ8iPK7UgXTPdwyGXiNO/jSuYj7/dlHnOzX7ukFBcexD3Uam dK68pldC5tzYiwgF7MRTXklOKgR3e7i8OLGmdVY+2H1PiUrX3pi//I+hB2CskL797+AUDa6kEDoH ukKlpz57t9u2j97p2IXSoMJJdJ/m3hemh+ijZ02z0m+x5pVOq3Lefr+/jkxQlyP68+/cZrJpfUUp lDsFwicPyXYFxr+zzxmt1F6fvE3vVUGGSg9w95j1dk5+9ou0UhUrt8p99lEP/qbfDJzD7//bA6ts EHkruXTq8dqk6zXOy+cp2Bskv3Zx53eCXydp+ORkun5/jX4TD7Gz5yW+U5jI3ii/4F69uVDjnopT Q1p1zqW3HejVBNzP3knJz8ewpGltNk6ftaI/WOFrZW1cgNJec9gOTBK0OXIvDE8xsLcHlHgwNJBC qTlYEV7pY7e1kbU+zBBbR6qFgf35lTlA0jqAcnR3uR5haTq/Snp2st3uY+2McAHlBvKcl8XrslAR r89+FLhIGJa6DyFWO3RQI0Jur1uA286PXcjn7/uGjxhKK6DdSTbnAdQklcp7jeR8DKDsGHQxGKFw iZCKOBJGUFzyUwE99azDtzDxFppUsC86YqQoo4c3EkLZ4mM/z0bTLnPgz+nL+U0V51XNjQGGcABB utoLiqdlAPaeGtRx7egQXAuEYjR1R3NAPUlMACuDQO2IN2oxic9mma5P82UYjbRhUIe8xTJGGosG Z9HhInBvxxRhUZ3faxMT/iCxvaag6dm864r8GS8nlQlBiurnpFPf4KDP/o083CSER4WhekkCGwRH FBbmMxWjicx0hR8kMY0Apw4iw0f8YP6zJoP00TwY1gMA6B4UhLlA2VnxYQTi3HBlO3z9COj8TgOq Pqvi7vYB0ugEtC8Ceh5hx6BHuevnUZrNfDb9N+GUTVa6vTcgpb9IRXyA31sMPxhYqtMx9HaQ/vln +nbK+AU4iKjedyKTFcbmaD4gXs/X3uRin12JXoCt3YbvtIljWlZT+QI6xbv+i1iia10Sr+kglvpe 15BjFDkR9qACxSVmcCmtPnpxuR6MUYw/YL8NA6w675tO9JkQTDwtrKmGSChCQChusqGdE3v/+9gf wr00D6metaA+vGC+pQhz7rMHWBJU5vYhZkjHPgZhBVFtW0hNBMJVPQnBDTqTSTzRTnt5Lvog0DaY e4fDCYjyWBfxPDtB5zrJye0478y9BzYYGc9Qd416rZv+ZE0o+DzrumY4XarUt5hDqNsO4q8o/AWp B/vN6z/TZ/6NxWTHPU5+GSTckpzeX9rnEMcC0Sqm8wXffQuVlyCRifsm4xkI46FAr7uwjRzu88kQ s64jLlhAODrqw19BjQBnuIgPVxQ5eMjMhGOXazCL1rcP2d0b/ZrYxTX0zqIE57sGowadYvuvWNU3 9vuiixLg1UdtSyHX6l7MX31bJgYKsc7udjSv0zq51KgcZidRjN+3r6n+9BcbNLz5rDc5Wvu6+4yp GWCP8NOLvbVpxMESMuFM4KA7mgdJ6m47RAhTEfQDgp2BWlxHD/0SXv5rPdTmBD7F541j+OkdJoY9 cwjzIdfnK9P0Ev8G9h8Cfp/ur1RbdW0ymB83H2KPWF94/gv6Bq/30z6Oe3jLy+l2152qO2IQO9WR +zkwCCHoRZsA92cq44WD/bpQJ3asmSNVrPGC7bzFJ/CviCpzOxIF9YOX+1g9rl6HMIRLLNRpmJQ+ 2IlgX968PsbP9Fdrja93thOebhbG+ByIzN9npBdno/NERMRJl/848wBvXZ91ztpzvtAV+rlevXve DXWyPf+v52wzpdNVWw5gMG9tKxAlTSGZN2a57/4LaSLMezvQ5s+jZ9HpUvOIcSCmnM5nz9EzgQur ohLyLGMvz3Qi2RKhD/BrvzwnJVV+4U5vUiwl9ioSijnm3Z8daeO37dU7lYakcnT3KTLvfb3+V8kk KGScPup4H2cfr80/QxZ31+Yy+prHsIJZNaEZHrvx79RZR/LLIAYAvbYGaottgvH+5/nEehIb9VFL u/hR/yVhbtXJNrw7Hd9ZINrUwv474WzOfdXMm2LIcABfyIHmp7fy5WStcIu9knff7lzAbV0pXGGo pJlOr3chsJdwuTm6Z0g2DVcrnbXx2gGUbCdDb9OB15FYy6lUx2mkJZDVkbygxzRsDgbiNkhTaXVm /L/QzP/7C8vrmsyrcZHmvzyjf0+9Sw1ytO/gyqdu2TxgdmdyXSnsgh55EJN7cWcDLjrA3a49VztU aO0nGP67UBPuyX7FboqnpDrDWXHAmWsfPfTRm/m5fxgfgjNU/eYYy47+Qa/G4UsHoYOFpf3+9n07 QWib/3SaMb0zoXkJmHM8pie7fuqeX0emBq1+Su2cz4G8uFOc9bagdvLJrbGBVWttCM98hwy43vIS DguqJZ3y+2+T1PnkmMR9ZeAtbxJjpXGZBz8bP7hsbWHwcRkJTAxgbBb21ZNsfs1zJYFp8VtfPdlE r0BvgJLiJ1I69mdS9ANb63jloTv2+Js8rxPjug2mJ2o9L+2fA8PrBHPCJzuVQ59agOQKvtGlL2ZX lCOtGUplIz1n40GqPZYe/XludJJS3lr6SHcKPDgHNHyhJ93PsZIq7TU1PIywsRTCNHgtu3pfRX31 W6dfrFY8NU1w0Xz3NwfpMkbPanvjF0Ic/jc9NHTH//rf/2Eg039cv0C0/RZkG0zeAhFy0VBMIDb0 o6NI9kfgikAINeA0YIz9feuXWkBDUd1ECCuIWrrctWKCfcgS7uKWBDvegwfgvr0nM6aI5Dki038n 2CmIbg5Q9Z62ae8yBekSEjH7kL5mpE48SUP5pWdySe3IoRIxUBTqboTtAeCRWrQWZV+Of9539XoH 2WwaI10SwO2I5jkFbr36M8LWEV8q9fv1KbzsuHWdMkIjADwfgw/UnGynZnAvAVnOS2BTk5tuBD/O WSeplkXmFg2wr6JWM5JCpyJ3vu3K4HnPUKzeD9AMt9ProKuIYtIJwrEoSxi8frvtCkr+FNBSekBO rhl9hMFrSheAcxdyhv8ioIveO3WfV98uCe2RTaJg+jkhrNUU6cRt+RWDuGkbdE+Ppj4dVvzEo1MU 6N+L/xR5ZrHVwIjoO+sVe8b5ugqmnJj2SVHu+8xMaYoA/V/xydo9vtZbl5ztkP59HyPgL6g7PHPF yuqvu2E/x5b4e5HgM1xvcewrtbJPM6WpeM4fglUJEmRx3mfWlzfJr6tXN9Lz15hgBYirq52Ydmvb RPifdbsHL11S+mtyux2J2UlFj5hmiblM8J6GHdNY4DDLFSWkFu/7q/ryCsmeITcChaii190VZT8P IJmx9/4gvgQU56x6Q+GGaXA4nhJZer5SX3yOAYDI4NPzQBFTr5kQbpIDjo99nFHdmwgXivQ1W5Dz OleI0sMECVG+z6rvJLHYh76pASbT5qj3e1jz8qrqgZwcor2hEx+ebi/A/fZKHUcnJBQvKO12YdoE qg9Q1ZhZsGsLqtB5uFRArnwRIgEKOgZt5it/TgXK6v+PlZLiQs8VuPjeZSrY70xTUbtT7+GX7ilv fzIXqP3rcqdFHqQjFgHvVz/8O8hBdY1DiHP1pDqo7ax2YyB+bs+Ji574+Ttm6poJ8zkEOv1G2kV/ ov7IjldPNDbvKh2gdD9DHgx9jS6+o+zFA3TOVeVpJ5Lv4V6OpN6mE53K16TdHjolgsiRqmNca1/i uC2mjk74OYd/Bstilb6Rql0tn6d94USq93G5is50/Kigkm0n0429Okw9ZrkLq8QAu3d6O0YmLd70 DAUhQJjVPmNclhkzKfBKokKfzv5pODCffXv7Xk6QNz4o4qynWeJOjmxXQmgOYHBF+a/r0P0MJ2LK k/z706O5euU+D5cwU/feJyLl6puF1aam/EKOk9gxHGvELDuNgIXLfyMLtyOx5nI07n6OcZxw4P/A 8eaqH7XvIwGJu/elTrTqCJNetZ7O23RuPCzSzNr85xGDeYoHu3bZwHvYQr1b1KHgpLiySJc77v/9 177DxR3k40t+Jcn/Hr7uNXm9Ax0dON0Ub2+507YUDIHLUZIcFZNj00dvljO9LGjketXLKVToHuu/ rl8Hdr37D/L2y/c7wHP86at9YFDv4KcgD4eyDCnx5lskFoJVFLyk0/KXJ+5+C39+lpFLFXw6xxn4 tZMM+K3mzjvUiX95JZbRO+wV43DXtqdqHlVqVqSkIJohZM8uDk8f2JiUe67TK3/uenuLc1EQoxoE 5wHdnQSTTteEmVDaZKYHfCeKGT4V1XbzcP56HO9v07ZL6pwCdb/fQ4ShBtYC6Wfl3qzsffLeNPK5 VTlKQw6pLiOxHtJsvCn6Pc2RBEjcpafHNrIOcQk8f89LzjlpkzLjCaPrLSp5uB5yMaRVacj/2/Ez GP/lod0tRWSLgTd9gczBeqC/DbQozWhmZv5vM/ofc385gb0Z9rJmZv7dM/pPzvgfySfRd/1517p7 /NeJ2IgR0L1mNPRppQHJSB08JOEXe4Cp/ryuetggcDyJ6kmX8B7+BFfnMFmokVBfNY8/aqFZ91l2 xjGb95MAtT+j5zJkvIdkfSSsuzkJveciOfszPphpuWmSuvo69Rknnagg4hApv95i7odX080cfBnP 3kYP+ouOAjDA+H6tNtjny1fHc2d/KdZt0JanZJiTa3fdcDnP87ddmgHT26K94GHTrLxPVHz4YA9F eo/EvYycu4ZSe/d92NglmQ0QI73TJXcC2T8xqISn7RxcanYcwUv5yn4QGrTttJe35mBp/IxglL7T uLdTv1fCeePWE/g8MLwi6zw2OGsNx8AZ8c+8i64rBVoR1FjAyCaxjyQZz3fJvDT0XNe7qJ47+/c5 niOvJWMf7bMmurQxewhHn2iRYo3/OOgrUx6v2kaVeNCJZpAaoo0dkanna+xaKYYO41y9ddBrzvQv //0fTC2qCvCfQ1F/P0Y64kX1OgUiFGOkSk43DEzTQUwQCXzEjT2JnwfEvAN/py8BD83UvYuoD7mC /7GduWZKPROiLh0QsnHjCJrSFlToKNX1Wbi4LmpX40xBGW/d1eSpK9wmm+wBh6MsLglm6VUzJZx4 RXJ6Jjx7BWXhrQV6XCKJNxay2qknaiSjANMdMqdgfIFuWOx3RNvtKu5D6uIDLrjBXmE7EnGHHxTf cZ2foxdEPnacjOsM+xEpi7MHXlJF4eSYYAgHvufz9HL8fM8/cqxM98ELuh5w1F3TWQUktTvP7xqf IpU16dbGayWhJRZL+IlK2q4ejguwz/COplI1LSri42+etERo0ADYC6Ktty8NxxZqWtSzHWYmgKWe 5IU7fd6obtqPV6pFz2SmyABjaMRuYoI7SgBkeTr5QggGGs6A+0x572I83fQOE12A0hWvejn4X8Jb Pw5DHQPGSRb5E6P5Xk5XHpxIrgjscB2t7+y/DP8NyiIukiHJy1dsrLMJaXHmXm77DPxd54JhHaEQ Qh9+0z7/+7/+/BRr2WfVVfclxpiB65abRNQDjPlwun3JUl6VlKZDTrA+4rkG0h/wT4GE1VHj/NZs +c8JBlpunTgwcLSYSG4nTK/D2fpxUTiFSHG+uiGuFGBtVmeAfthNXjk+uu//QUe5Fh9l3CsJLrry M4bG8QT6I3wy12dzBBovaOo9FzOeWxm1uEFeqdf9Oz0+H+57H8XqkDPXxFg30T/k9qEzv4vykkxP 6BNiUtQg5Lp4AdPX3d2VkQEHaOBWx52UINZXzN/df7ZjyIaDLqo5XDU0O077EFktgbv7N7RbITnS Eq2fKUZDNDLeDQZC5EeY+JxbKkcFg1j4InTBYS/FMI5uWl8YEbvy+Dn3mhbM+ngqUY9PmU5F+6nL wS1PRR8JHOZukG6G1sVMCyCnvtc2nMhnNFgvFSEYVZpPqYUOiPP2yBMkLQK0PT3UvU0IWnZ70jqN c3gwoapF4I2T5NBp9p9J2Ht4IHYA5eTTnJyMHD20oEbYZCu5qqncGwk7aTcVg2swDYBq9S7CbvHX bY08fQz9cWOSJdT0hWkIMIi/kWFeLnzU07bc1ygEagchwnzIVcqIqf44LiP2yQ6NRlLFR+qQwsF8 3946k1fBFOMPJqoW6r/nplEscQlsjiRFzeHUPXG3Xje6hpzi1ppTkjQ7zWhiHedYWQpeqcf8cSHC itmYRjXpBvhgPymG5uSF7F3iTUp4t84S8s5kEhUKkENMToYb/pRBpJByIO2uh1PqHNLeby/28z4D geinenSM+n7QSw0MjFydRA5HTPQhdDv4GMl6cFh3SgIPmmsn5MF925yQQGRL+1SHoIN7JgMGmSJe rYE1YTB93n0qR+APwT1gj19DC67+cjt+Mj/5kOn2Z/LZipZXnpUsIq9z8+SZ2AU03XLvlJ8bVYER shP9cgz5t4jVx+DMbD4AeYP3PL6lFjtdiVKaSTBFwwaDA5yOYU5y4mTUWiiiUBksTHF1zPVQMphK 2K7JAU5BvWLA6VX4pMctmNDciaLvJ85zm9atdCDunRxCIpXsXQz8MsndukbNfQ/ur7rGnG+xzcbV MzWnMX9aj5UH5sHzjHDP7GUHhodvgfY+J5P30eEIrOhL7hxhSK+79BoHb/cmSiVat/aIXSaKHiOm u42p8hzy/lnVX93GcYnN2HdXed2z+y7ygadT+vjEMGOzWW0yycK2Z9/8r2fmv/NVAf78XuxfPZL+ 4zP+Tw7w9CKht+bkNt89tP9u24wNcI+3L3KKJ6lCTkfk+Uty+sC7mNrfF2zdY8UGfNk1aLndsWPI 2BsR+1mf+saW3gTIrQEbTFr+87lSwP5Tx2tKkF70GT5Zx/MQvucaY5FwLLv/5BSW2PW1C1sxWr7o 811r0jl+m0WlG+42ldLnKTuRbniRI22++rUOLk3SPOtq1hps9diXkYZLw7L7hPknhs07q5MNe+5U WNU+JaO+t0cYsMwTYk1Uw6s0VHl2zI25v3iSuc7PDMlVG3iLTV23q09Di/zcqTtqbE6Ryr155TUA 6Zn5K+fvM4+POfL5C54+YGbVab06WdNf3dflai48X3jIdfB7tLbjxZ25tkutQqe9M5eb615zJ2S1 vvHCCdMIQPQplUP/GjQEACPhGU6g8pnS9eCjYAOTeP0awPGhWUA5wa4k+tMKh0om+IaFM+mqt43r Rejg7tArsuYwcSnC1V+cMzlqnWbI//Lf/zHnF99N7u10QkCelytBEkt59G9puD7EMmnXf8Mv6a6S ZJYO16Jv+vtyZxkoMkPGIFqQOj3rDE3inlB8NjFMGN/R7ANQsIuG5cmudpKkiWj2hXS4N2gdOByR PCV+1LvYTyCDixTyI5wqg6bcrYzi4zkP7tUsOYcQnuLYJGmgUirBn95/OdOTF7FmSnih43fOZ6v8 d8F7HdLeQPOvUNEH4X+BFHOAizqhkCnScV9AlISQzXtPBFOBnqTib7SQP2Tmn5OZddJwRIkgXeF6 ZnR57igsDTvgKICkvRoUqS1Ox1pnce9P4jQBtFfI+e4DT7iZish4FZHPlIvxDrtd7cjBbrvUGv8O Aa8pSOQgtck149dV66ILc6/9CtDteO5rIMvoekluiPZ1b2Yc1Kx77IpIHHSBzASPLq4Z4txr2nDu 7H3QdYSWQNNRuBlrjBQ+pjsVidbY1aRHocb5rDRz+HSfN5wNVJcR9FxyIB13tTYhqSMOUX+NtqLv FsNtuifZ9dGozvQAoBraHRJHGkD4JANfsuRNUEjhEU654p2WA5dXgoeWK0uTeLOF9L7PlvzOoB0B sTQ5sG5Ccu06TwnS/CxrFwXkPXjrHMp9n88hKoBTpIdfO+LzFbP/1qAZxdikheE+HM3p9UEiMa5Q L2D82Z++CGi4p7yBbS+S+yvql9BjAiGSBFI01tR3fHn/eZN14uyYdL4XEswEll/nVPdMfyWqPAVi DFJvM+QS9DcBSbtstTNsTs7PB2Ho013iC8Jj52xBn/6TOGEG7tMRMJ17iCy6/7Nr8GnQ4XYTmjsJ iO8xI7gZT1hT7nHrNjX1OQRkd91IZHCWfwp3pvXOlZjFe+ZwrONAbGj2yjy04xgwuUmvfDcpAKeQ 5DmSmhJEN4qqtngsbx2p8aO/ubBeHRyNX1fi0Omk593b64pAFfRyGhZrfcVnDtC2nKe3iRTK5KDc Lsd3E/RLXzKwQZJhR6sLhBnz6eq6ql7tPeRcz0OO7VvUkDhh1niL7PL8E+RJ3Gd1J3LSHUULEymY sDu/Z3bL5ZtAa2BRVdcP4K+ze7oksMSInssR6AtJM6SJCu6fxjY1OSDEJN26QT3H83fdVV4pLYOn hrBf87pzNUwg9fBOd/uQgwO1Re/BO93z6YB0OaANkI03BXrVow7i4xZzdk0rEJDs5zXg+qbDE62d 4hcJp43fG3JLS9x3OBa9d2s7MvKdpDM5rF31DfoDwi8/Xebc4gvls276DQUk9HvZYZBSQ33c2zoI s9kCm8B9TszWmWI6RcL3/pgQGMV3NJ0fMaSqwYTWAaS+U3D23uX9372IwgUtRRZbFN84et4xbD41 gJleCRBeuMO+0ykRsrMGvwbTXIJBH6dZo6/da7IL88YyFD1RDuxyAmjX+Yxa40C5dFbmza3sgZaU hP+asXgnsqgH1uwbs0guuQcLdp1s4BATO85h2N80mHtIvXsXHcYegQVImCj+Ja5hDCAGdMpNmcTp eSfqRCKMicuebluTn1YnJoEo4RVRbXRuwqjCwBX5SJsF0W1hKZkyxmc553H2mM+FcXNV5IO7/IvA TiyJKdGz58O9WOX+2V0eDBSY9QjkeKuVEOOurKHunHCm/MEinXW2a5T02neXfR6buVBya/OlrzlG pQBJn53pu7d/0+6yv58QdPZ9vJIs6/deRnZ+eD7/U1qfWr3KfcrDk5Skp487XDP/x5n5n98aBMU9 iCmf/6UZ/Xtr+NdcZ+nIyyqzGOhPWfsQGqk4f/2JZeRQkY5zhpQXHzi5rrM/cHG38dPLqwgN17b5 12uYVkMmMUBCnMePMF2R0C6SlCZ/cJ1hwHqI+nOq9hKjunBKNlHICluoqxjUmjDn6xL0Ovo/Mq3w XEYizX38y5kkSHWiv8lmhT6Gjm7nZ0qHy16YbOGo1iZToTnuY4N5nIet6bJnce2LTnTgWrrPmq6T PNuczct8IfuFL6NWZsL+jnoyJyMNivAHMaDnbYnrotxbHnKp3+vr0rbMmyQqEvW3ViEHU3ZBewwH qdfZxtIOT3/DSJHnMBy7DTK7ZxQoH1XaFrbGui0FUsMxgHO2SBsGLKSjfp/hAXwcC8Qz2Z+D1cak wxTJvzowXyedBrBkylD0eVfxJyZcGlhgpSVMGxIL8UsBQp89rDCpKpH/PE+LWZJCB8HD0DttzXNY mCyMGodz3vXvv/Hnv///H+RWRCHV736+/Il2xDAfqCqyaRfv7CJEsN6Xr1QTK+i0zSVRED2iqwgI vVdoOeeWfMW19/GYkbexnaKASWfl24VtcIHriJ/UUuZw8yKImvkl8cgJ/irQryCSjrLOKX7/UxNV RhLWp0uioNBRjELsRsAggOmJqA2oDZClu7WBSGFvwJN8zdE1SU1B/06Ys/vHAPnVAolZQOev+HYX CWUIAPR3Q00wsfVPObbqjBiuy8zXafCCsU2a7Oasm8IX1mMXFP2TIol0UxeIcy5o/nXWzAntBtPv GOUWr3kN3uxp73Uh6hlqEZE0rni9d31mVHlPibmiV13uqjdNSg6iPk6lNRluY/NZ7ulVIPtDWpLv p4eT3lNCmiEhMLcuqv+7rywYRrpWlhtc0dHeaeav04TcaPDU5uV1++t00286oxpFzamA0HFP1ze4 yY7Ob9SjkBy+yA1hoZ8xWD0+EFkV0gmKuZpHn0/2PV8Idvg+06jBbRAhyc+3QbzFFRQ6qVMc55M6 VVAhOxVlDWjl2ajtMG8Qs9yNJQHMAvGY8bNmbfS34R1BzagD3KgbRTcF9OUrlrWHtvK/a8mi/Puz e9IF3QUs+y9P4m1fr8EIR93TdR3H8f38BnU9rGMUrb0zYxjvqFHOd6BruppF6AW/SijM8BxunJoa Q0rCGc95D4hROfRxnUO6olCzTt/x2XaTNtkT+UMgMuAuODOHo7+RYP8mLFIYvXs0r+GEWUKBdrsU A5DoP9Ou2xPg+q5nsus3eki/cbJ1bmJv9JKsLrf5rtP2GXhBSosk9Q0yvsNSLxCtc6/+3hn5HVWo gvYNLbo1DQBe98Kvg/vrDKllLmAYnvT6/Zrt1KaD/Gn49AIvHZH0Vzwxu44b9uWNC/jjDADi5fiO t8PT4UgmItM9FO/u12HfRLJtdyIaun6JS2NP/tY+LtSEyP7LpfkmR+cQDvQo4pWo0Hjdb0TmHtL7 cjLTpIGGMOqTExx03Jfv0KdQNLMdYNqdUbHf3rO5Y9Sd/ZbbxIDSBBjpnGmn4j4dp8hio0kJDT4x zUF/q0e229WZBqOFq++PMITcC7fjTlbx3fG+NcDMHAR8iL0k7FeA0hqKkFXcK4Rj3P/jZQxAbtqU kkIDku/P+SPkW2YC5tNPhWmphFE3Rqe4r6i2++g7/0LQX27+16hIC6QY5SmnLW0cvaU+YN8jnTle bV6SrtrbVZCp1CbxDKKLF7u8LBTmcMf/FZ05CFCfJgJzdG0vYd5YmcFBU+B0K8SIBKSv4N9PuZf7 NK3xUTORW7VXTfn8DsF7N1iBmIQQM+T3+ZsepgOl3+s9vUhfbOxNlhXumJvFY3znK6VVs533cpBG o6Pm81nT8Rmyso+koqkrWXjVTvrLt8+1eSWdaL66zLm4QRjWmsQpJLhvOfF2VeGC1NL6/ZQRnEI4 3+9a3eOu4StpY2wu57RfB0iopbtSFb4D5qyau7gEfStNp9xFM3PD2DPX8zkGfVtERAMMu08QcLu7 ZyXse/Mmr8O3su/G/kCIMaXEzp+u0lFVRoKIA9PgM0Bzp5zOKT3vsA4h1jdzpex2n5X1VeFCNtRF LJfJWkk4yNw3+I+Q81l2hvO8cKZIU5jCRHI9cYbvqu3FveI2/SLhVuBZmjIDulySVftAdXvP+Tz+ gqvq/X4z3wloXf2oej/IU9WbaNbnA9V1hJXqQ7b1y/0b+OI0o4KxPH0NpAqGPB3Jy4VRemb+5zPz /7lvRw9cD++f+g/MzH9xZv5RKVJicW4llY7qF6y15ks221jTHmQyJLbcyczCs01zmb+0IJ2QxK9z 2Auz/7lz1JhJugi/g9Q9iDcLNxFi0rSeB3Q5aWrUz+SXmyNzHyNH1G+un3PeVIPpJnRmCPfofKbg 0OCWb/zx5YUQL21jVh/6p/y5y1hqcDRt5gOx/RVpz/DAsUrDs56uGG/d5/oUdkqyb3IZ9l8YacLb vgyIenDQhX0IanEyBZ3QWLaQf/fCkFsEA4pRRXnvVQOG76HEInbc3unRu04mA4hMmBxzamInddI6 SszNcdb4xIsSI2Gn8t0XTqy7rZ3yYAqrOP1w/R67jQUAC1CZkKrTBYZMfshkkiwFWnfi+TKhzT7l 1mUa1g0bIKYKuI17ONlnD5/k8C/nZeX9uQcUGqOIGt+GU7YH7nXyx15alWQ0ppnLOFtmyOHehXnp sFMY6Ef0VxZS5xCdPnVASkO+oXP911iw8fyrd1CtxaxF/tGW8cb4te2WOQhqkrC8Y/Z8FAU+Qerr krrCEAad66YaBg27uPaiGSQL65Kxj+nvXcC+TlGHF9Rc3tt36FKCRBQVmkVjunwZYvtmFb998H64 8aibno5TmWMWM8CitRz916aLC0wX+CUIIu81MBj15VNWrX/SyflyE+2mb0Vla7vLOABXr/imK2Xg mRgER2gS+7TbHcTk/iEzXkDQLP7gqKg5fKHFfDu6bM5RMOwotp+LQwPXi1EkcScWTBQghgJkpn2f dDY0Ba5qr5F0RaG9+9MEikQpsQZNp0o7Y2UhKx3Ee5DSX3J8VRTXjrMXUe9iR3WeVyPfii+3q77T UmDJU+LUVDK40dGH5KZtOF0IgBE2++0z6oMwbCEMO2DqKDL+5oR0Cc34HHwdgFJIR3J4LXC2m0OO w3wEGC6Ibdpd/XUF5glPItl0PAkG4Tp+bQ/2XEHs/gsY0XfgIHAKk/ZqMKjGiNxELkC6SExS+5KO DnMC1lPnLSVfZGoN0pieqlMURbWgSH+FT7dH0gfpElCFTjCqh6io/VuiFgBy+zwnkO2WjMwDtM1f TlkaVrlF6JzH0MLpCwy8gGVcYect8ZJ97VG964cUOPqAkCYcDkiGkyDLcoaORCgDOibYI/YN7P2K yWbG16du2bVK4ARr2SxkyfW2gfKvnmLf9/c8uMohea0TDQz4xOf2Bn0yIjxFkXqSzjKCtV2dW+iy XRodLuCG7iSHCrn3cCTicLzc5QJjAL5UgwNCkYeDKFWBiQIpRf1E0ZB6E9FJqszROfh5djcZMnM7 ZadI4Gkeou64Io51VsqUjEXuSq5Y3u2ecaArhvXxl3hJw89jgeO+U3o44QWTL/fN3K89DEMQ/Hze qDdI7wuzOAC7BA7HcGdEvZFrrcWPf/c13s7g7df2rh9Tz4hYXYO67ajbjoW/+Faff651rLkdKmNA RkSCvY644EgCAzn5GRLb60Hg5/SpGjfdUH4VJEa3cQdKouUY478Mt/4kB5SjCMdm3yO/MySu0wwm 05W7EqZMXJHFqrogx631EDl7L+x1409ovZNW9qCu5u8DavSTyQyha/8b5/4+Y3SgXoSCzUGHvgL5 5dRXrr4qFzdy92zhy/ykbeh8+lkLqz1FPTDk4enEUR4oILEE5Vumm5pLWDNQcyrWWn/PHfXemGOK PRJ3SHmTF15xODad/flEcsDvuagPaYgOtoQ4iTKHMQj9lfWSe2AR7pV8bj7vUnY5v3AIGtPkGsq4 NpZj7LDzq4+BqMantyD/TTBuvCEB8HCRFRgmlWv2nFwN+bTqqIITu6KE2Ha9zfoosUtyfr6dLNcw KUo/hBxN19AKHPRyc45OSfSNL+mHjqySA6o38z9k4KNPl9AWGgxIT647zicafuFzKp5iv5PN+TSO bKwwPbQvtqD8FTv30PHmlsiV7x5u5b44B5XpeeyU22cdv0Jif3F6XqkOM5foNVOjBSmqOk6+W8jP 7N124fv5uU9q1e9w+cyViJEirs0x7N6IeYcHWbBXPfFtodEZc3QHXansxac6uTodUglVTZVZDi++ 8RpavDjNe/7qGBpOYaE+uMweSPnqhiM9KtMeQhouwJ4oYfDnbepaq79Rzz4RyOZwFePLzUDvFLAr H/FNCPg1uvA/jccT5k59efaTVN8qXTdL4HaJ8lQCp/cc1ZCT7SAf8cPXhuO5yGbGPFhtNKe6jMWI 4Z+Z8f9uRv8dEk4q6pVLFTD/InL/r+y1wAhji35jKLXSEH6xiTUIVQK9B5dT3IAaEEzvIe+rmDCa S+TQGv/9HkZr/ihFzwbkIM0//o6fEQdAfQENN0ddUMJ6H660ikGRTim/9hSaNx6VY99DV/KUz2p6 MMfNkNCjgxfyiYnQwOh7zt1Jrpq23dJhTpTDdTTgzX3tGrazq+YT5Fn74CFVWg0diG2ntAk5qnR3 FughtJIMQL48b6LNnS/Qo9I/vIEoU+S+neZG+7FfetOy0Q7D2161x/83D0RGEIlDXeLzPxqx5P98 cK6CQZr3G/w5p3ls+jk93APtLjMISuGhPJnvYYjWfhlWjYIbYaZ2nxGZhDZQn87sQZCoG3VnmV2q Js4va61KD1x8GdhkxnokjByDd82x3paPo+b0dp1vSFvonaXEiKpu0F8wOBd+nsaXQrtAH1wV6zNU eKVRP7NMqg0D0GC69LNn7LlGyL+rz81je53ht0HrrUvoJ5RWO/p1dKd2eGbQiZjC4ZsWLdmH9yJu dz4NRxnmo2HhoMthg2IhaXKfo+FyMX2B0jMpJvVno31dT4MhEU/chedDBOVTFLIAZw1OKGUjPh8u Gr8OkzetQxPr+nC8HphOWoWaFM7awvmXqctp8HBWUTcNLZKTmFAQ6DW59+tSwUMU/kujnGImFQhJ zYkrqt7r0M64PgpWnyLzvAqgKULKJQ7QAvR/J/lTpOK/0o9zipiOaSLPATpEe/SKEtUTWUkuXc27 IQ763vXp/D0IHG2wPAUSOvdlTleXMNtTBWWKal6XWqFzrxYJ30KZC543Er8tcnIL+j4EwORy6LOZ A3K2mrheazaf3E1C+cMZkgv2F8xpV2oj+KGnYVHd09uV/L0v1rn2nN+qOW4f99DX6gZQ9hyueb4v rKEaKBK1uDRhmM7xVCMkGfYO53zfqA2G/x3k4XniL99rLtuWa787jj2j2q+Egcu5kxrLS45BsNAb c/wSqZ9CLARHFWRz39x363CBTSAOhJqj48Lz3kPp0Pn70jWlT4p2wyM/TkcNzeKLHhLw9HRZSigy vrlBwtelHnaHkPL4hEJ3JQ70hWGd+rhLffUd6eIJYmYAFdeA0xVH64x3YzfW3Eklwiti/x6OoApy g7pHb+U3hlsVt55ubzSZrkMEe8+TK1Kevk7Ka2BFSADZvZ87q8EgXsuBmjtV6vevOvo6ioN/AEK9 NZhCDLbPnV3X63Ty1cwR/Zt+VQ3YCuCq6g8i+URHvGo72n0NUtENHVGrJg+W665msnDmDk6cUxpP rmwJugz2hz+uncr+a5+DPqqZdGf9bf3Iiz4BHXLENZwmJM7ZIhFTHVb14eP04DlizX04kH7JccjB lxylw41CRGBwfXmvwq7lvdxMiQgl0baDZHLcUzogOVffPjToH33am46WiT1b125IZtIR/hn3ixQu MI7qI53l2zFc5XFJ8bEz5Ap4OoapUxMX+Ir5swYiUGd/MZ8nWf8dwdKrXeBteqGTqAIRkG5iIWvq /X5IApTDyZTWFMB7ODL+DLAWcXEnqlQIu3KNunC6wgZ8w+d8VxkSEF31uCMFbarm6Kj2rpVbfMAR 2CQSu1YZ9QYzHVufBGMkvbx/S3M4c0b4uDqG+621GnfpWymjnTe+oSIuCKNLUvHLTGL/ecVZ3qmT LIGJG1vwNrx7QxJsKrD6u8u/7kd2Ik6C+NdA5HZO91y4C6UIPPexrlF7V8x9vzNBP/sO+6tyRogC Yw//xr9rQOEvw67LaEVZ1UaCA2JdWuJydtLLZ5FYgXqIBa0bPGxGIHDD1Vy7lAxU+vzWR67uzf31 wMXt9Mj/2Z/UqKta8UmXSxvj1MnRkeXUJcQSig34M+2z9ae/8VVnODjKe8++5guK3pANavQZ6k6C jIoq9wT5zHe9D86XBbJT5xkZRSmGifnmvwxaLh5C04Zl7Jrbvg2dPrN2lwivjTpA+46ewGu34A4Q Rm/3Rho2FrhpJkd6Mc65Vnbib6cupJ9qDri1M/Xd42+8uIdivLDK5jrXfvF+VvvEJefIAbyEDPpy KJdxvuynjBnObqbR1xApp7unNoHllsRbebmLoiu6e53sOlCY3jlnrbz7psv05XYMFfzG24Bsf4Z9 R7x18O5jX8yDU68UGN02v1H1yRfSWeZp0l8VIWksleZJ63z3FyISjauSbQL8pNK31d2mqX6DdKCp gaP/48z89+qNS3MJpmZqxOk/PeN/29ufCtx9b/ud1pew8/Ks/X9V3XaOmAv2yZviZuCCdveo09CB HWcz+Mzn7gqhsxOf6zqNauv3nSg0GjtV9nuEubUd2b9Ros6hM9BlWfh3cwydgtWpdJU5qlJyHZ/i a5+7p3AqIzq+azTw4rYP/It57JmvGpW1aS1+5HQIBa+7BrK08ZrBnuh5lnbZ4NCAYw4X/w7BpvHF NnBVJRZy3dm9L+HJg3zzHHcbYWo+nMoZI/fBcew0ckJCSYdCKIIBM+C0hu5PhJjGTDubt9jV7QM5 86naMfQQwTtLi3tdv1FzcJ2si/juce8qce1yG3mu+i2aHhq2n0fyaolg0MFzfyYT9goJiE7DLQ8b F8I79DbWyb6dVswMDw32cK3r8wvGW3JvC7hR4i7KfPVdP9Ljw7z/rxEBdO2ZxQ2jhadgjwp6swmu 5tqLXQ/+1j+ZQG027dUAT6/oF8z8yCcKY+yWbkd++ob97v7x5cxNTRhNglEtk1KWHZvnD7eiy/GF pnb9NNtxbSshSBeIyES/4TH3ZW+4DlK2k+TQRQDGSY7PWgrw5Yik7n/2bBBf4noGjlwF5kOM6J2M p0MvSr5DrPRbkLhEK+0U7Zo80lyDCjqk1Mb32Y3zINnwrh1he+p1aJBr/yaAdBAfGSM1MyRg+HTE I6BDEPyn0+FXwcA73oM+AIpN9kazdzrW6HttGuZc7fU8fUhvDA0BCbrfaNWOgtxCQQOBMqeL7lTA qMhF75mymg8f4nv4xrXiFxgf6824KlxN3o5hhBbKNA2r+f3HnHdxwa4ZZ/+eMwZQy6Yi7G+70Md9 5yBp7zheAwhoiIAmkt7LFZQccLuA1CFZKdFWCvZqSv+eAt6DMUwu34TDoGCDxC4dVUauoJsIb/fy i9BIV1sdZ0ifoZcfIJFDdAv8IXi19tg3WS8k+6Pw0+A9CPISBMI2gPf3eOhb+EN3qNZEsbB+4+Ev uhtoyEQFaAsAs4dc8t75qvueCep37xvJAwd44k8MTRhhbRxwSjBBQWwbwOq7raboY5S7rHXLZGm6 acx8OZK9bms+YmMTOGtHSocL3TsU1QOhPB2+nQXfxBkmm40C9JfEWs9BfU/XveovapZiqgffVIoM Mhrvj+jak0k9JILwQ1ju4VVh403uXANuvh0ld7lWMtXFPWDeFXyyCfMxLmB7ypkLHDeI6PfGhy7h RwZSzxLaTdST+4elu5gjelIFLPzWEb+ux14De5tw+UutXfWzQXw6s0U4KmAsCbHEAnyKAH3IKCfu tu1K5QK5DyendW8ZZKVRMwdB2n7GAiBHIArzz3Dd3whRvjfmwy+m98MSWjjgKUNlo5dYvcU0nJBB YKlhYNVHX7Xv5cvVs/zB/C16mSRRnW0aRyT7cKokqvmPyCmHo3WcQiv1bH4HplyAIt8KXcPrFPM0 4fC1mhQr15FekviePs5X10B4rQMQkVZ/lOmE2u/T5up04X6e2g+GzsSf1foGX7fj3G/vkk5HRGHj PnaedQ3Zv07ZLWxpDOPiOdrhCUha9WD/hb8MjJ81PiocZkwn+exdhXeMT0lJhZPrJk56rUZ6mPf5 oDOil9a8EaInN90lzPBNdOqkxDS/5mD6xISEQ0tJkjeBRGgCCUO6rk53xwrw7q7Uv8/fJ9atk9T/ FetsUszlGjVHPfO7vz0ZQ/7PYeiExbczJDsE5u+sM99TTuxnbolnOt/PhbP1/SFIEOwh0o0VNQZ9 CasJo909Tg9A+/BY5eSc7Zj2Du6kYOIObc7EFkUfrFMWwBh3cyM+sRFKS3KlCOw47R5ev3HiKYxR ZTbVicRcg1xnq+Au8nQVob/UslP9PmNDxPV4yDnNiNmSVLs/xe/ArvvuWoOGhE8lzm/EVnPwrM9l QwoXveNZ+H3jMSlIFd5p5NbHphuDZPavaMlRP+yal8eFQGAGyUVkbEN4fQ38KF2gJ+4AMg5JLFqI VWpymPStnwjbnIUtuYRCE/2JVz29eDoTTkdsep8d233PxcMxfm/s1V6H+xTudUqjfn7HHrY+zgQp BrdJWhJ4tDrh7s9nWQYSpjt8i7pLqB8mQ6lR0OPmyakEIMY+RulRRicWj8xc5oQv9uWVuPC3vvoy C7jSgC/RbDNSRiyDOKHN9ezP4lO98ST9xMYnE5WBnmyGhiL2HqOOhRHQW/uC6aj+coLXodlpJkdY l2npO0h+9ZoQTA3JD/ftv7/1f/kvru55923s2Lh+Z+z5D2n0n3ifPwmRF8/unX/7u8eF+yuxDR7d 2gPD64YNPKlGf9R99T0coxiM2eZeA0odQmJyGOL3vNDJzS2woIwU+3kr7vrk1zsNSGdtzOJig4aI awYDD3lhB2VC6Bm25zPXuzZW0BNMQBp80qcg9nBhX5F+uAwFPP8Ent4icEVy6IARlnBgVYXD/3Nq ldTiwa3iWQMTvwPtpGQLZj65zMCyhVafBhxeIObmYa6B/pmNY32iH6r+W9ALD2DtnY781hhkBteJ Ns93NOkhuI99k81v1OqqQdn9W6fB1KBZytrDawjtYisG6kPP7aHNu7S1Cl/psrtiSG62k2sbi3i5 uDVw6+vu2FxT6Q9i3Up98vxZ37t+b9PUV5+yhkM0gS2SUcJUT+ihdBKFji/M6nTxyvH3CZ82p4Bz YnIaMCQ22rWXnu8n1BzMUSneiY39933231sXYzRsJVbPJ75p6PtAXVWpxGkKY6g1ZtgMZJ+rxv7k HUz0/KNFeM8WEQebXO3IirgslX9/2UEBURe+5Q+XxZ6EV2pPaoeTnfrA5Ukk1ccTtouXrCJBxHRs JQGK8XJrkS3Npx4TReqmyh/N3G9kOBVMj5j/mARbxbA4xuRn3ZgavI7yvBrJgVXJRG4LAFVEGzXT ApCyXXlpHuU3wnmO5nzqUJuhGTKvs4Cc7QiimiPK0nNFakQz7Gzn54P810IfL9dvAqZ9eLusOC6p m1b1GYYiPNO7cxM+6mIBKI8ixhd1qQ/3jBcEs7FRb7J3ZosVeXXbA4ALX2GdKEDEc5L673P6KvRn x5POVXzQXKqxAHoLJAFh/iXcogQEF/EgAOU+4mfs2SJGCskygIV96aeT/elw6iZPdwRiu5snufHr BuwDrtNDEj9gl/uUciRv/Jw/BzjNrtZTd0sSWvoMpxSQYPsUWW9GAwCehgSgdfPZNbhwnd9z0mV/ dzr1VXvUdLrjbnQJG7gkJOcJAKT9fZoYI5QIctXMEbV0VkzaNVvHRg5ExIfDo+YIguuf45LI7ljU FBW/d09Gi6nuymwqfskPV31GE8Wqgc8L/EtRgj5hdiEgJ7gjRDUiuPNpTRVnm3617zRkdBMriwDy V8A3E7g/PcMCUwS1FcV7pzBWpyNzU4m3C6MOUucd4HoHKDuk8Ze8EzqTTgF77yDy65x8fxsdoHyL uzuZSR/+fJ4cxjC6JQtOlFfIQs6PxtBQgpIJ2Da4so+iJvPAnepRAdUqxwSDyPdyJUthYhKaa0BM M7ebLzmHZD++36EQkFH1My7ASUCID5IuTMP3m3FHitXdoSKwdYQzGlxtN+G3z/f92Y29x75ZPs+5 kr8muM74hK+Qesf7eHqMdCaTqG55HQX57/mAf9/+53bkHTgPGNh6+yQaUx2IUHU5kjfW8TuImHvE q7/ME/bLVOAHMxO7Uw06umVyRK7TJprzXN0OmV9EhosY6Df6t7BcxeB7VUSHc+0zRDHs+KhFxrbn YJ6vRufMTPHaALtDPL1OLfsExb98MLmG8rCw00Qzrt6MA17jXPCsM2u7i3qRW5fTbZ85PsgzElr5 xDpewtdouJCDMw5BXxshfPUZJATx+f8pa4owwmfVSjMlSlKRMORhSlThKwY/c8REKSb7++lIuXuf 75eIZXAHzpxmExpwyRb0MnOQavD21pbbTkI/Z7Q4CaMxLCHeeI0tTuHgntMYAJ6dwfXNH3X/qhO0 SXsdY+BctT1CPel0Yl/1k3TsEX4VeWdssSek62jANfkV12633dM0yZdIL+slEs+9A/LilETtt9Ip pQrhOckzriF75iSMe2oPd5MAxR+rSoDu7Dpf0IcLf4I/XLMvxMSmbL8v4YCB1qRBD/J524KmK5N2 2hYCuAp9vJXnaXg+MtaePRxnbNW8eB4ptQWVduu/4jW7VzOmAO+Us3eIW5DoyLhcf+42m1LtCT+1 2ituT9fcO9Gb6qlenVrmXy2UuMh7ina/DBfYK5NM0ZqzqhEu93n75y4wpAzSWzDwlMIV8q94iBhn dfKQp7gXMDVxbZHGFU5BiPoWbmgiejoRHue5snBcRnZXKmEKMZ73ro1jtrNhu+gvrFQbP06u7DL4 +vICFaSAkiFMJ6ywA6+fvZsiVJVrcpt4kOGh6ha4uFRBIundZfl4IgPmLR+j7sFNtalAcoH5ffxR me2hJWK7N76ctjHrNvQcN5hBN/LrVjvAc86BQ/hMnA+eQduwReuMFd6mnaSwqpn/x4z/RzMyVzYp toShcM1/YWb+yzvN6UqjVAn6tr7pwui0tQdnfpCivt140nv2++MMJm66rOHEvYZr6LUHXwW6Fapj /3Cc8bwPbLv57Dk0Mr/42uC9pFPLpJVKS/zANhyILelYC26uBysFEU8IupJ639fppdIBzQyqfQSG UIQuUHJu68m+bNscmJ5jCDjxz/n7z8oES5OBbXBB0j+hWInUxOj72eE4b6pO9PvSDmwMv4/+O7f6 HpjosT7BGmxD26pRfnrzNorYz32nLRieT5oB/jG78bThcaYTeZhD0FDqdCozXKY4nDyvz3SLjZuq kn+vIfgaYqgzgRN0yrxIxIEKcAjGhw28GvnYraFih7mgNL2yqVchJIUGeHqopfo3Jyaok+GmsRI2 K7qGRrYhy687/+0Mbn+fWcUXYDJlmyh3LzofljKK+mLKCMd17ufQCrFnOjGyL2M5hYHNlazYBmlU owVqLqi353W9J4yyObSJXv5XmE/2dYq+vzGuf1wTu1oTjI/Y5i/iuG2V9U6MGC4zLVehOUScr0vW O0XqIn4biDcRckpCn+BeHVtI4TZ7OVFoMja3AZuOnk8y66cI1+Ujk+CqsAA1SHQ3LXlFV12z4w5X wXaDSvdzFfFPBRu5iVyh9Dy97LiUyLVL8Ts22BZ+Q54CaydEMApxgp5GfoNy4sTtAPnS2WYPZ8x9 4R+B1+mE3M4bApj5dQxxuCtcrm4h+tDl4tMNxJ78cTUh7yojwVde4n2JfU3PGh2eXhCX5oiISLto L3JpeQEwlcvIVGM2Bz3xI2hREpcp5/Ail5cT7Ipo5Gappz99FHMTcauq/99UkOYS5KXQ9SXXyEXK 5Gb5CZu57gqhS2eeGXvS8WBwo2HQ3wGzirJu8GQLyox/VzCNvEUV/iiO3rh31X2wXdnZeX5PDkZK hpPoJBHOBQZ/uVlMgLnHc1ac9g4XaHBAeZ9DwXefwy89PdnpLo8LhOl7PGKmEKgpBJcUyctxU0So PZC09omjGIJJN67fIQoSVvBwg/PzUqS9mrBNF0+VaON2SANqa02w+xA88ASywoXKSESp4qX2e6GY Jtdk+8BQw3aq61gwg4sBTRy3GJjE5jS04QNQb7Fp3JH2R2VAAz8gRqtYty0SZxgWkk3s85QpF94Y llOIprxI330vMzE1ReZvx/i9pgmUF9x1t+s+NbctH2GCcdYg1Rf0+XtWqe9Upzjl+14eFDGky3HW NOy3xM6/cWaZxRT9XH6FS9IFNzjcJohCz2HFqWQC4TBwgwhZmRMAMAv8NIAwL/igEDDODwAxh4Tn Xm+bTOwRD5015isyEQy5ziG+WQlk1BfbAGY94JqgcEBRxu1w+fuhdNx7Gbs44GTcQHIKx949MJ7l usWezB99jNYtMgQD2nP2Ojzm5kUMf8XFRqE2HdmqSuJ707uyu7iGtap+VNcuHE/p4zfc7jX+uIUG aoDXiWilbkS6T961+2dlOsZOg2CTBAeQuddbRgU3jC2QJ/EgyaqTlDVFY3cCgqLdkC4XwATft1h+ S/F8kNJaffc16KYAfC8BW6N/t1yjXXh2z5piQKo5MsC1MCQJCYbuX7vnT0wDqwPRO9hDRTplQBBv /VezkSnCbwsF8434fFoIsH+sc9fQX6eWtYPYJSHaYoFrePLFx8gQY5Nn6W7dVhtZ85QpQOBOJK4T DOG/hGqTyumGBC7OemvIdil2iMF+xYd+nFZ1Codv33wdI/ZiZyWz+csXXX7V1cLuJe/i/C458PU8 Y1PlokMAyzxJ1iG/KZvMj+xh7KlkzHLbEkldWxzdghMDNj6Vtrf6bwmxggH2oLFbo9zqNB/C9Ku9 b1lw3fHQhnPLkF3ST1iwz/rWWast3X998VJbWP32C2TvwLeoIWG5MZZrl+SJyv1jrIxycSvUE8UX mlmpWpunYHGrAu97TxfHmV/Jb3F2lriueqeZQdsjDbqcp4zln0lOguHqNlVyTTwZ8ycbYyIZeKaH CVRJW4jMqDEbM7HQJwc6SvipadF3OCCryH1tjP4Uqw7UZVB/it9nnvFroO8UUPQIt0D8MODuyniL gj9SIO4uw4KdZucT5zfwGzem20YA9xCEsUZ8U9CaGQZccj3Dy5HZKDiqsR00BDG+D+7VN9d/Gxuy iLMHsQeTxcoUQMI7CpMUTejF3iPXUGfWjr9Ovy5DGh38nSIlYglu38Fstbht6wcESptZmgiFS8N7 JpExz5ZrB39g4vO2ViGFVJymQ+YZrSSg/l7P/fOvq+l/a89/uw1mtsj2TT2EAdD/1Mz8W10cBZ33 Pvp+shNTcZO7F+5bmOptL/x5Yt1NrSte08yMoKe8QlfwaHMySc1o3hM9VZxlKkGt8LSg2n0Kj5+O Tflbt6MeDE+hYjsu72HgNsUIM9Xo0XjET0PGGfbFXQGLrYud0erAfeIYc/T9nWCfww+DWLXRVFPQ 66WLsg93+401Nl69OOvUOBRHsGtKQ1/5inwHMRxguU8X7kylFZCNPqpE4H51G9wQ5KwjRaC1mgNa mP3cySB3ok8VJg+857wWd6FwF9c1OPmcnzrQ/S9m+cYbIH+yDEOTG6AazHjEagaSl3SgnVTl9PAv pWAndq+jH/8dMlJoFrPnI2yWhpZ9DLgnz2vG4EsnttPGLnOdZGPSELKT22+tgU4DzOibNcfwu+AE zntckT4yOIzAhmdtgLX6Lru6/UvX9Jv4a0xiJM12DoXpL2Z7XRs5+NU2iC5jNdjjaTouyLVaHLL7 6f5of9x4ZN3Eoj5J8w+aHOpF9ruZdvOYwQVbGEfkIkF32WjkEZhNZDei7ShTUbXuoi4LN1okl+s0 z193gdPAa7qlcpT3H9Gq5gp9+XJN0gHOX2SOj7Lf0N4/xIFnizwOgIpApaaNW9hQZGi4OjIxcYM+ JGrR52afIECpvFaB9louVT7m0LTrJnLMVwKmhqPZGG9G1JxKKOVz2oy9G3Vc+bdbTUBPf29r9Dt1 q4gQ5niTlMcIfzsJDkhw0pPdRmBCuHpZrtNA6p4U50+7Y9oN8dJ/ppV337RjpLrZ3/FjqnWoswzN CGhhvHK7l/24PWmfh65IbXKueRxU1YCtym1xhmJLk6D4WV9uX1N9BBtd61+3ef8Ckg2k8b0+L5Hf wHNWF2lukvqNlkqCzgdAKCS7PIMOkvudzwGTOgffTPORDnctn0XhdjhP2vX3zxicqO9RA4HjLoFR zz0covLfIvV2m3dNzLrTEoLsuoI0yblXCu9CG4reJs9D/hguwgl0BVCnOdZNA0MZG60DzikX+RDQ vnGjHVqdjceXaMIQ0fd1h9FwwsycUNVVr+gAIPWxJ2fHmJUP9SbSDGHdCda2CGqOWKztGLwFs4ah izkBGnaAzdXBIPENTuRtcCUJOBxGVGv1Fdj+nEu+HNCELqF+krLSdXmJ2BVv0txr+CJmfNVm8V1m QFSmT+mNinz/EuXprMBfwbcmo/Wmat13/WoNBMyxninhRUhY5338CtL3UC7csQDKQqV69GB5l3oR tO3M/+27elPzWnHmzjSZP7/H9BR5yO7PO2Mn9Du6kdJOXJYVJK6bw2WRnMsGnXop3U3LaXqqqyIQ bU5xAQlprnZURXlr2hVoDydT5KpOQc4L9NWa8RySFgWmkjiOMSJ2vWNfg6u7b5klRtBx1jyO9OJ3 4Q9C3h89/rdYZ46V1t3EFEBMeElHYvsk+TPV53F81xy1Rpw1ugjHHGLbzs+10sT9yu/91UNXDvHB ADJhxFpo8HxCzCIQT3D6ErkGp/P91S0kZmKkNVRYo8oo4R6/PMe6fBF0FOMKnZv4Hq1nbhaNunql FhBABRV1zCAReqGndjJ+LDbtsWnB0B3EvDqJHgGRmiJifZwGBgg/T4VMqdHCBHvgZz4x+HIz1l1r 9B0jwKQT95hpoxEajAO8v1aqP/qnSxx53QTpNHcIQKQgy/aROatPGjhfjFg/Ya5Mul5WM/6si7oO FY7Fv4MgnD4x4GzIeGy7S92JNu/zqWdmFg2/3DgmjQhEVC8CFAmrP/yOA/mxDzxfldfgI3EqCVLu RzdB6bg3XaTr38TjxHkMCiDKBOFIZNBfhyEvrKH3mc+zLs9XHeIdQRXdRiw6pQ7C233/HtV9XDl6 /mc4nylO08e5+bqU5+CzF4fhStz4cn/UO8w47IC4jccIpXkMNt4h8mI4iD+8Box+cU07zWUIh9hi h1fwXcHlmgPLHxgAM+SmTCU0DaTD7DNJ1SEsnFIsgnHUkLt+4v5fxaXy4EradL1zvZVMYGOOgZFN 90wlYmk+pIjDhl6MWlD63tUPcX8K/MQxYDGN5i8BqjK9oHr9fbduc5trMHb3EH1m6axrrqSkSpx2 rHYPnGs+eO/5yzDaBEc6a/giTyfFz+9ElMHzf9ccnEZMFkKcMMt/83UVv92OeaibeTYHX9BOy4zZ ezK3bHPTz31gg34ABH+ez1Tcl7PDTsTGvKJf4zO6u10dFPMVRk6pb0cNuzajMcr/SZr/waAWSNjj 7gFu/Qc98598hc8OgR597iu31gM5MmvY3oxJYiLl0w9q1685yqW4G3AHmBktoWEi1FOv663eMybP vxs/3ToMHQaUOhPfyEhB6Bo8iJH97JEwK8khdeIz7gSgqZtKQtYeb9ocRJMG+brb372foZdhko5V mxgb6Vue7kNtJHjYL/7FtV0AIHuZ2Q12zYxRTdRfPnpWk7h2JgZJugZnc8hYXdLH8NReE8mxE86o f+qkybpfYKdL+reZyz6JMoVUfbiHlYSEwx64jKZqSRfvKMyS797uObPKmbuH8vm5CvpPwnJD02CX wWfd5abK3LG7GvtojYFQk7B4evOaf3u05oWuCt5gFDWgOyITpRt9vJhFYsvoM9zGsK49+5WUhzXO kZ+X9YGOsRTkppO/kIbTILV7VP2uabrj7I2DsAE1M+Fp6iE8g5415DkGAahHE2Duxuf6s89NqhXN qZY7zGBX36x7YDfF7i4Nl3CA0eP5R7dz6QawJ+XrQPSgW2vC3eUQG66nqmluIrNzET7/Tg1urkNT HD/w61TXjSmJgb8DxvhQ68tqH857ItoFFPOUbF+iLlLATZCZItC6CMxYmAUceA8fuC5/mujhNdJQ qjDwShEdzBNHJMQNr6BwWb+nLy8SPBw17c847gGxJLtGEbjXwj/aRylWZe8APszZ05fA84z/0hFr c5FcLCPoHeYgIJmEzqlOg3vB/BPgfgfK9USr6wy6Lg6hU4XiM2+iUh/g1Ey6xS6y+pnhUaQJvL/v nmH3vK6KwsKc1rQ/4CmCPkHu4AIv+reYgFdH9Nh2Lqi8DJvmr59pyDmcHm+xDseh38X19e8OaHIJ RHdT58/4phIu64ru4WEmXmUzgzGE6avTIlEFyKez8fd2v9l90F8i0RlE+F074R4Hn3/WYNJvRKMh Vjw/dwNkUzSVQmg4Jzze4pIeBCMJy8ztcDhIhvOK34DBGfLubp47ACud3XfD88YYMsiSk87toCS8 v1uaRzBepyv8DocomxjHeWL2xW0SVnMPrLT0wDiFPnMlCxklIkagckaYSKIgTw0uN5R20rG8Cnfe WUTUFh63E5OxzifoE2ooDYrgNtDPQqDdYGV75IgL3QDyO7C13XENNaTLqeK3sae6eypGd2JfXb6f 70CV4d5TuU0wCGwUZDSpZXR2nOO+o2j7/vf+IBA34Ng0muaOddNR5U5RHltw0uDbBhQvoFaT59+1 HrdjzOsSt8+kK7WI3tFUn8Dg5na50yF6SkI9CWMemhKIijxcdfkQIzSY6Rp0nYOo07Gi0/Xm70O4 A0TvG7vZNeN1W7vqY3I07l2iT2AOI099wHO60i0mRJlTRLspXvh1ixKBrBuUXk4gMZzpGALe569n IFL9tz6ewqu4bjecjxexdI2Q6OgDwHdXfQYoqpVbnq91L+8h0e6JuOfSUTmrsBce1cpUQxqp19zi 2l9ncR+CmHWj+MCyzF5qf/q8K1w8n2OC/Z4cAE2ANwHbfLpdgyYm4o+B/CQ1vAYK2kmfO2xKknj2 XJ2n7Vv5W9PNOcAmDeZIEt6mR6Tp5UobT0kpAiIBsP/ibnx1RU+t5uv+ZQLnm+Th4cP3G9Jwgpcz FpOPrlEZcoucwlx1EN/Xd9WR1OkgBpEEDsHHG3dPaFLiwpqdKvHr3DmI/5PYh4cp9Zf/PkvEQ06Y AxXT+4z9iXfutICMts57nMKQScb74uBbiMPn/IXBvq7v+lgbA9j83TcRBiUYhA1BotrLTLMH4JYr oLoHENZ5lwRUUAsw8k8pJzkYQ+kixBmkWykJKFvEOYUt+WCEfLAI7LXbw67pykujUS4R+D+H73ef Q+LSL0KdBQt55uP5pq5mGE3cffUlCfkRrwF2TwR91oQ23Sw75YFHx4O0F9/3Cp5Gxah28gRbKO2B 1d8hoj0+8UXQZ0bBKwzvYdU2FqLufJAV6j7uFUJlbbeHBYQ9oj64P3KFv9k3o5fe7hu3aEA4Vp3u wgO5AjzIzkIj5iqJQ79SGok78KUEMJ1PwZu7+0VhZ9oO6zuhh9KgFAmt4qO6BFZUQ1FClwvXpKQr uj/brGpuru59z74GqBznVfZgbXLn495s98g5KpPE1bcQSSXlVaUB9GDazDW4cf09qlh0sbWKz/Oc 6T4HyW8Uv3A4zXF6RbKJuhe5V35jdLuP85P+zkO5/flJq2LohISiJn8mYNXA3//XM/+jmfn/tOak b05HOtC//tv/gmb+K6+LsfAsI7kcy9KJGR0wOWnjst3n+SNRUsGa2vOk4hnTP/8I5sh0U5m4mXu6 huFyMH9zMtu45+6Dd//z7vvgLb3J3O1o7w98tfdrCo4VxLBx6iBMNm2sLM/E7/F3emwldwcD6xw4 hT7MUykbjndo6BI7V+J6Y11rM9N6s8Zf5hPv8PgAd12jqj7PhZmP3F2ya+xwOledbuyp76GVvmfu fmThkK8mxa4ecydLkyC6ByN9Gb5ijhykZy00V0vv86aX00CGjjzB90yqvyFQl5ix+J9+1q2n4tRE qjl8DAlQ3eV1bqju/C1alsCEMDpjspTVkZAqqNK3RoYteill8bbmNRoiEu+Pz8j7nJxDWzKIXwkG ZjSXjsq1dt/97A/JcmD/+sILCFMOvszUt22zGp948AT+M4gDThgHdRahMY19jttYq7YjxU+aZr0D 8Ia6e9CU4MKRf804r65jJ61t/HrwPs0EktvIQ0dv2OZzrwHFP+ZwLEJHaNGXvujSo498pphTsCQA j9O9YD5lQ66FzI4WGZmgA8xwTSHP6YweRY37Z13R1v0Mr2mTXtQ+gGkMZlgdtWEObAMMAjD7doDp aNAsWXwAKwUSmqgGdvBqIemeDVO6mogv8ru5y+Inpl71NxrsjncpUZ77kO94cdU++j0c5kPOQk2I WwBkXnNvNMwX2DcHScUwgYtYHyzyn3fkDde6vC5vAtTgYj0lftgA6V3sCsuSKyo7SSUfhdiACOUS lA4CSO/7EuxF1Vx5x5PMcoShxvlqCHIW8XIQloSNaZLzMyBaU/+Ol4BaO0VfdCcNUv393P2dFtzF 5HycHyVcioLjbZTSITMJQWMZxmv1HUAiJ1BBPGFGOQ/Kd65oMN4jKXnkIOgWGi4h7uQU965DGjwk IE1FPXZzuEUg2HQZ1tq8Qh5t8dcMTtqyc+Dt9KfhYPkJUcglipmheg0SfEBUoIisFDq6X4M9BDTo uF91CB10Jgi9EXH+PK9dkdKqelY1UPSzTpUifapODPvs3KHo4vkl49if23edHS7DBIZQtGZ/lk47 oc+2iXjypDIDFiaSWKfrddOqHSn7itxdWSTkPATCoiBGleDtAisE9cx3LLE0BRA3iShot73c0Ixr MOsDjib3sTpvjx9/0i+GweipM38Gp+Gfnu26U9mduAUsX/IP7DmS5P9ZQ5Reo+pN2t2sHQxahP+u qUN2G6Jgu2/GJVIxEbv7Dvwm8Rlue4ecL/JEAOLOuXNZ8tsDAR8rUIP3DwlbL8/PCWHpex59oRg5 zNPpFZmu004XDMptFxZjosu+W3yAex132lAsJXd0mst2sOz6N93qtF2fPQfMCm5ZmlXvnnsljoUE 0TQ52MhiWcEtyrvmqdUXzmT4aYM10W8Pnc91/33X+em1r+luWeeUr+QSHUDtTLolTQl0KWGlus6j d34Ti45odA9Et6sosRRnv0To7XROyZNv1LtqoE1QXZOrVY9BuKRGQtuMeE6e+kz7bGqgSSjoYZIs XYO43zWSbRtTJfTtkp+zw3PjbyovOU6vmI/vysNtWRf28M5F7Bt6KKpNE/GIb+SbhE0AX6fb+aDr 7iaY/NllpJD7NQCgbkOFPWRKXOLnAiGDDhdeEvRq7ePCUn31BvOB+dF/v6i7b8HFBFfRg/Ag9JQC g0vX2Tnu5sZbrnpYR1LRYJLCH2dEFQpCdYkg7vxbnDwzgD3MiXV+G54IRBDX72CHq6PPjWF53gcC fMMz45OFovVGRHffoO38zAQ7SbB7WFBHl3xnj3bq38sT/NZzPbhA5kZ7MO0WP1xv/h4cps6qB8Ku 9LzrZNxpWgP7Ztcwnqs/+MJ9HgdHb5yexS5XwoL/8rvJ19XYnyc24XIoz4qGB+v/GUGvF77UuIbm GivcbW2mI2Wy1CkgIdHpI2a5+ScjSnTdPBd+99YFXp/nVzTAww8pVuBkE5+fSVFzED5Jw8M+TSG+ 9pgOPGYLFJiRf5PsSNgyp1A/5QVpbXT7U/J56tE1HOc5+cwpTLL7HLwxBP0eIuq9n+ZcM7cj7E5T 4TuWhqxJiGvowxZmpB5K2lhJY8zmzg/ESj5N4+boJwZriext0xjRH31h3FumPgrqSGlx2n6dimdi aMfojvwrIgrlhrjrpXss72Lyp/Wh2Vj1ymfC3JsS6P+z5o+b+1WUB2qt6pz/kzPzb2n/UB/9QusL LvPAPuUbV+sEgWbnDThT8W3Sjbd7u7nrg8vTGkRx8DEDybH0G7X2Ko/Q04kkwBn9BA86+FkX33yZ VsyJYMcA3sdtvKpv3TfL5actSMOageQBkzHLlbr+eyf+GSA8h2XVxilkkfEK5q8Tc+DplE2RvxI2 WHTtqNkLX592PJ6TJ7p/syJtZNVUHuDYYyjT3W//GGRIyDbtO4u6cy389RV0rpWDc3WEJ9MI6J1m QnXI21PQm5e0PpQP84C8h9Y9bWMVOMs05Ekd1CBvl8/KYAcoHKbqXTClp+nayZia0716v+PW8Qju z753kr+mxIa+qVqXQmMgc5j06LqMD+5Pa6H2HlXVP526fqkcVNoYqrqvHgxGfXelXkaKOy3402yu nNe/akmjAseAF/fAL1sxZ7WvYctl+8IsZr6TnfyBDbfBlxBP18dJQ7ZlG2vYCWkGnEiLd3qx5Ps7 79q3z842vPvHJs/Yh2Vgcu12u3FMbammQN5L5QJvFU1Hzq8nQKlyhm9b/svthqKBTl8rX27G4Vaj nqray9r1+RuIorlU/fVIW9LBh+BKMvDriKWJ+J5MJHJUH0AQTwAnAZ3NMs8gdbuLrYlpKoumV7wc zQg8Hogav5sgllAh+OE9vbs3ftJoIBaGfXW7n8wzEdTip+3U1lFeFIvqiPD8AmH3t8liweutk+B7 Ayeb7HNN0rqKE1ej2yRparBVl77W70jiwhD1Z3AcVkUsRZyeSSSY/8zQQHbUzRyuLgnwOcCSqffx 9U5dkFERHJ46O26XgSsNYQbdT3GsI++ES6j/twgZAVB9e/jN8XMyztDFBLF/ecaKrknA+kCqc7Wb qZBk6BI/zLRXIstctCL6AmzyQMw1TapSjM5DKktzuT1JFV4UfoM74ljQXnGMYw95/ILyv0W8kuyP IYtfEZCL1uZ1lINEPtqti3pod3YeNfJBO31VCiTgJTAxRZqDEEuD2IOQq8JVo8vti/qhOlAx0UsE lQ7wU9gAkpP3wPmVCRx/QLh2SZ4FpF217QVs71qcQN6nTnIOfvYEdk1EZ8ttgguTvlEJgzZRPbAm FGItYXOXojVO6WC6W9jfUPw1nVP+ABevhCrhkC0mRcT9nEOpGdGedXo6HvuzambhjaMXpB4u48TT qYudA/MEuWLD5xBQCNdM3gN7oILq1X0PZAQ6JR3cbs4qCqqjkRMYJXGO6hmkq/GKdX76zj7TGxTq PSJ0S9zrlQbuBrzOfg8udAxnWOdjNCifkvCZz3meX8OZftymjc4keWcVFa1O4np7/HZPNqQFUP8v iO+MvreGf79HLnutsasKxbX+DPJFfKtKuEGi5RbssHPb1aM/w1TahFIP2JB/z+XgSA6eV6aNy8Fk sKYCakwshjQaIkQcqy7BL6RISUf99C3OIInGnAIfNrX4jXBWiVPP4V8JXO2+niWRkKo6S4EZkpu7 KNXQ17396zrNCUo6KsaOm04AmgwDXCkYvRYEw5Wpo/4z9OdKMRBka6S/jcoXsYZgPt3QHWLPOev0 TC67q3mtojjdcIz7mAWgnLHBIkOC3qeIhKgvlEkYHDfOgzMpZuDTRigMHUgiTRKeqf0vIVcmdyKu bR81ckeu/4oJgyBJEkxX8iEJr2/nIBYPz8wxZEBESj8/Pkdv4c/AufiVnGjEgui+4v6uo8y7w+Vn yf5S+rhPLnLN1VuQ+zv3AfwO1hvWJ+2O7ySTTLrHfX6jm5ERDvzS4AvUcB7ECPI+cg3ENZexb4vb IV2VMMEiNdF9LnI0NiaJfps4aeqCCiGow0n1TWe8TqhfXLBrWZJHtDCeXNnA/Mv+dlE21WRhx1NR 3Zd4JQWlLjH6b+oX9T0eciemu/J3iLCHHQR5jeu+8Rz763Ah1BzpX5ScA8MY4bZoOOcYx4TE0ctt dSbc9XUgjNTrO9as18BvI3bCgcntOu/ue80CDhodoD1AGMvrMtvnjgoPuXiCweHDS2Tv4IvMdXfs g8Sf1zM0JfsZ3af/POM0/WnjAi3BFt8qJD7/Bas0t0FUiu1uzCL0ESiRyQH75mM7jSWRhzZ0IsGn PmqvxlUHXOsHejIdLPqcZitspJDeq/tu/YN7E6KeRlSqdQumMHrx7O4Nsqbzgw3tgQFy0ItBd+07 zsiQksFJJhDfVapOAdjulfvjCodUJP1vZ+a/PcEPOu5wwnz/9Tf9hzT6T/cA0MYAEgPpe1v4tu/0 Ikpy5/OJsBfjgKqjrtTRQqiUA66ev/Hmb3TKH7XigYug4JrSnMQ3rfqsy57gFbstRYUHDCn8gS69 mg9jdbx0GHVjqfbprWnZLtctDo69495lRm6/h30YX/nXu0WpWjNmW6RpgtC4llzLjU+CMUEv4wt9 9JE5hIfndHF4WjVv4qOYQAI9YuIgguQ47yYQsSBitudEQXp4/tVO3NqPixuLzyLCstkQo/qCxzxV wwMAjVvP0k68CXYp/m3DDYeqRGjHo2PYOQfuHMN8pbt5ajgDC6ZCYaj+Neh2nt7GgIotPPZC5C87 KAM20hzRxsb4GmG1CSXJe9p0hNbU4Hk4Z/IDqyQ1oARyJLoQEqzmZd6h4Uz52nhDaOdC16CoX0W8 kA+jNw8Y9xlNaHKcrOxGFM/JM6WN8xz65n0u/SbJ7/qfTObaMMmtK6jeooc9FbaHrNvZdc2bZCLS AWkglcJlsvDn/f6DLqUNxG33SM0cG6/dpZZCh5pYcwxO0vM6DmiBozhNbfhwEvmN030buzmmOXNj NcivAHozuneOsqMPDkG8wcD8QhSIFRW/I1PZMaBmsmG6hieqZsVVDLpfDBblTATY1DQoAB3FuEN3 BsqpSSgivuIWB9t/4TxWuTET8XxERvw0q2IQPqXJJwksoRvvHLIcdqVJCKa854YncIMmsfGbrP/1 BmPawZqFSxzP3aXJfp47HvmO30t3dy4pmPB7h2AmgH8astmi+jWMo3QkvIQts9Z4p44Z3E0Fe23+ IuyY5dLYE3ztVt1zVb/veTu7fUWDZrM3wwLlyx/qOGNinV3OFC53gPxMKS4yODH2+fpO/v5WSWT1 0S7Geca/IqoXQHARpFdsUjp79J37Fow2zffHvSHah/9amOjvZLCTwMmIZQC1Ckw7wAFyruG1mlGr DiFbNh/sXJKJNaNs2u5ncIFQPD3ZwLqGxGwwuW0CKwxC366d+LlONLSeqeZTxwT5NWjQwJqRXk5X VB2kyVNHiqkSPhVahPRT4rpFUHeMNYnO4Y3rcYLVdufeZzI3TH/24H3CPdWkUkynIkIHHd3j90tQ w2fFtmuUP84WeRZXPROAGHl7kgvcleTRAau/wimdNUIO/DBY/gvMUoRZDzT0HrhWNwNtEokntBZS Cr9v/1B+OuRyorgD++mqolI1d703w65uxiQx8jjousGEd/7F0dxwpvF5RKSSAai+049aeN+19nIu jn2KsZDHalfFUOd+N9QY4dJYVLqRL33FVQYsgao2Rw9q6MYY9vWHuIrroAJ59OUV5zi/hHtTR0S6 Qxw0jwC8HVD7jrjSZdo1AU4Jcx37QWkMuzVvVySBvKv/r48OZHoN5c/1oOyIToyMVh1wRG0w1Q/h 3VA7Sxm0hmyu9exDFmOQMJETRjseXSLeXjtGQQfD0bTOB1CC26VXMHD329vSGso+ew+N513zig18 OpjPzLDPZ9cLXUWGg65U590PuOwewFchf3PkEBLO58CX2KMl039SOlwEtzScWMnI2aDMhQiNFsYL HLp0dgbUJzxidDFtrWGn6tFE2mC/DyS+K22mh9iGfl+hgNeA+xduGsP8NorcyI2oq/1Iz6iaYZP4 fwgEn73OzJxU9hZVUNy9RrfZ9+zomTcRM7GkwmkM9YKmPv8dzQzn+Lv/vQXFPsapc5dvZ6H4E74G zIQj6z+D8Ge6Vw6Mt+icsSdGGPgmbvyN10Z+hqznW+DbGDTtOfrz7ZrvU+ry8A6+pLeU35JdX4iL 1D5rjohmHKBx3gLtdHtnMhp+vz4SvHKPQu+CCRPCyjqdtw0GMc05pGh/asCXhweFZ0FGZN9ukx/C 8sOxzekwZqOpjMNBlPaRT/zVw+I0nbhn38LP6lT2YxtXJ8fW17xIkWaWIsxOcWlxQX1mvaTy3/6n 72ovzNUbszC7S9/D0Dr6VM2VBncJiRVSmtXvmFGkXyMbkDZ94N8Cee2rorgGRNv1j3rOCTFfd2Mv Rv3H8TOTCvvumUOAo0PYcblCv3zM1/7OZO7s6J43LcItBpzJc1DaxR/qGAy4cSTDn5tIONtCEmHS y9Vf+KeG1TEopaiRaPivax3YB6Ja4zIr8nEHuIyvkkucj8G5vE+ap2W3dVUC+OY3dhoY7cseetvP IPcnDS5f4mCh1gVH+UQ4d69FobjWxdUYeusBdGFOhC73Co/gHm3A/3Jm/veFNTl6WROyq5nxf35m /is+UlKp38t++NuB9nr/ghrZ5zmuZeYDFY9J+zC1b0n3QSMN3MOGg/hw2kcqinzgIhdGnrfsMurx gKWn6ix710ybGyiScKCHnh5Ke5PtVVV9D9uqBliutKjB5z915ppxZJFYUJi4fvWwa+/6GnNq86YS 90rD6Y15J78JAQI822iG0cZ0uw9b39Cc3yFgRVrn46M+vUyNuFakpFPpGL+2a/8QD0uGkjRc+cM/ gNGG3R3Uuj1N6RuDmrPf0rLvy59nqussNyD/qv5haxO96ra20iCE0efI/TsYkEicDs7/5Uhe/F5n B35kIHivPaxipWZsNfVZrp52ECEhblTY73dCFKyCkJK1xolS3BVO5oR3XdoH4BqdA0j73P3RwulK JmWuYoob48TPP33Onlkwsls9gK2FTWQy6zs0nviLQJR9JpbaT2+t6vvGaQCs0gFVfRwaQf7+mcIg GNpIznu/L4PR8HfP5MM2M76vf02gX0F+pte/2+wffXEkuGRU3hPt0dfYGwcIQjvd8pM3kp0jLUnY 8kgG3AINA1Cg85/dIgIWLrGI630GjktpyPHe2bhoyJc+3Wh1ABi/cX9TUyZdbqVg33DYEZlCcncN eYvvS8P17A1HPBdLBJwecXbgqNei/z3osR1PvkkgiSKpYy5RFD7GcXBz+FkpnEd00KE+ypA+OHS4 0uzFozMKDxosEfi+AZDfmPXBBjuj8lxnA1HAM5e32J/3w5F5IEjwDDtFXS65jzuf+y2vC50cMjwA qAzuBRLCrLPUM1dAzHYae4j7D6+yOe4HDq7/OiMz2QDiAsHxoCU4OxEjLzd/+mx0g9uZDQMNf4gK 0oU/IqwTKCWyIFNPyJGoZ8+T/stzViC8ucAwRWFON8N2SO40Bf0TIBelGwTQaz7Zf4aUcOitge6M x/TpfDYfoFUunyjPPOueph2R9/sdLHsJ+S/PwSbKd4OSsVLPenE2Ki6wwHGE7GSUd+2luC6aWV9g m4Eoev45uoH3+U4eHPr0qubsF10khnfdQmS7IqFoO802efXGAvpwxhJWeAqB95zgzOXEyD55Olz+ 9VcanUWwOrMJjLU6C2ioYcF6dbGs8f/x+bYoSZRMgAQFRbhF7ViC/0225FOpRAdfNfRFoA3WoToi +XTe0+FDaB4WmA+JyQAwfTlB3kTWBLjqdU6keD4BVZ+unsY4XpZK+7jRzFHqJFOwY+3S50oXkX4+ nsHbgH5rrlmOm3zrdSa6vgTzmmvcQhAhG7ScpzKECHz39Pw+DvbN4FD7LIHOYI1O4rx8B8IzJNef b/Kv5S+RaMOD8UCZ1F7/daGgfbEdkXdfvV1vfusBf8SWD9ToPZxTcYUjHOnXmcTB58QbWd1uajeZ anK2wz5KDfD/BejeA1cKU0u+We3Wl2nmk2Zdb1h91zmJSAcW5Linnfup/Wc9NADij7B2I9HVzohG Yqldhuc4fXOgn/2rWVin8/5ZQmtMREnCbsDZqaRocPYMnP/gfouV/z4BU2z369j43YU3HrCJxgs5 GzylZjjZ5Sv9r8+TFrZnap1QsJg9aLsGk2A6qhodzpro3PwlhiCHR3qnNNAy63nlAE2JsBHH9oEt znLzZMS+rTtuJ0XCb/bQnRfp1pWMizy5kaRKbA2MVWHwkumL6OJcwtXtCO0aRqdKOs57TeGxnNKQ NSLcN3rTF5iMGkhWXO9W+lirl5zsW4xFOb9lIOSZwah0rnw5ATbWHYhJr2GIFhRvZ0j+pjRISS7y nWIxhf0CxvcQzjrp7FfcAEMj4ISsw9BBgW9qif0j8Sl65U7tmBKY63TK1nwJwd5UC+LLBpNzB4fA Zm5H5EG+AM4B78FwoThgn407GfjufC+U4Bb+XSIjqs4WIgt9yD1Qp+hxz/rEnddI77ysOtCQ9hom 11BaTyY5b04wuZk5/OLzTjOuqD6LZ9qYi53m+5xN/mtzVS7uQcsUqoe0tngv+6gh0yFw8dRpGtTp 64791ysrE6iuYa7dm3EuzubCrjMee8KDBeDPIsjU5FFkGtdWYceeOV2hiVPIe1Orft/u8HETeRCv XIMen8ld84G17jUsGgH2MS7tAa5OHwZIxlttRAOWOmqIX1zL0D/eBnxkLhG+sVLUV8MpCoq9YTIB 0cG4a+ZMhqVub877Pp2tDbW7gUcb7DL1UafNgfN+3Tv7WbQUXf93j//7M/LuY1NvpCcRMHFJ/Sc9 /rdUUvhhhhQqnOhGBty+2WBsAJXlu+34n+TlxTVmvyPPJYu88AWDEY8/Bl7TxEBgZrWxy8Y+Vv/s 3/+8jM8oU81XqiRw+Jp6U10XcCK2q48iHnDrdX6GZKQTqfSHq3EOeJq7RMjRG+jHKCEhDMSO5B7h e+PU7sZ3mpsZPBuE97yPlHCF8WWeUwZn9N9e6W/c3hy6pYla0AcKMsdgKmkEBGc28VvCQYLrXo6R NsQSFEZW+kxhn6N+1ZHGfg8mDvbBHjanauMusqkU1oG8Ll/cixEd0gI8b1m7VtOH7Zej39i9rA8r GR8e4sxb3p7yB7diwyjvHmbdZiNQkygMNbSfnw9dnYo7H9Q9qTKrAO3TlOf3tykW9TmNAH1yNzV8 oSNIpUXje+8YOw0SeZPZmZDrMxi6KUxCN5fVKWw5rPCNVqjMu3m9vmYyjdmb6yP3899ieYEOdt/1 5e4uNS4VacAr8fxfP+s/hFOROtrPlLBzvB5tgg57JGI4HN2ULmnb3aWn1B+pkHRcxd+HtmHKahD6 VM0zzyFO0Mwm+yEu5X1pgoKsm3lPh8W5Wvg/hab0Hiw94U4OiNmuk9NHAjd8OVEh7nJJqevWM9cR 5EOGyrREiJkOL/gtBHAQEBmRvA9ChZSogmFtBHRRMuGOMXYAdoomN4cbbqHal6ssAL0Cj1UboFCd cItnzoh6g3uQ8AqYv4p+jE3aBphoKr4nk+cg6md6Ine2E1NdZL8u15s8eIhUTQHRJAT9ATp0Bxn9 Ctj7NGrHjJ4uZsD9hgPnoyS9xKH6i6AkI+0GqUvhRa41tBJEvNmh5nWbEDVjIYKRegqe46UF4JCR rEySPcGYi0LIqWIV2R7DXvbhXNdluCuKnGPd3qgr43qhqfpZgC8Lpzi55aeYsU/CZqchpODoqzGl Z+EFGmpNeXct8vu7KZKcHGYMEpgbetzkUK6X2D9u0rKTLeCt5fcTnb94iz7v9CImHaRWiA2CnrDv 855AiLdmtGlPf4G4DocXgzN3g9L25agyq6HwzKebJpFeQlJeq168Iu4NzQb7IM3MsC9D32gOcEif oomm0Om9qcDUK+ZrJuK8dEf+EQjVoG2TV32GDhAsmhbM96mR66n+jAZEqLMTtup30roR1jY/6+dx N7L7FmxSxEDLkCNFA0w6yXp9MAEq8P1l0Q19Tk7SZ3+UrhgQptvk1zGcRnelHrfh2sOmvJiOiPZx 8+iE1XlobZZAxfGOLxDUBTwZ3KlvEClOBG2yVvBnyMGsoUMQRPu7RpwC3C4g+cv1twfYmaiP/xuR nHnPSFoi2Rfo0eFHnCvNTwKYwWWqnO78ptbFz9TUgDwJYff9NiWsyLWhGqlykNR5fm5nFqOo7ase 6tS1Nw5a4djJ9y2R6dddvu87ichIACvfusf0rTSDCVkpVBs+h5TR51N1wtqvpshKHSmJc+AVgqGS t69VkX2N6xDdQdhK4xdnKpD694E36yI9XtHHXieZmhODpqdbdwrQqf6/7k8eVcQVL324tFGFN9hL 6rSLIEGQSlyvwkMNxOgA+ktDflqEJrmPJrG1RNXuzwh+PiX62vHqnh161+IuRyKEw+GQnTIpgvwh 7txYSJIjKTyuoflXzAlHZ8+Xq3rpGqmFYbX+KezC9u64wgL9jSe1sIEoPgcpKcBSf69fFZXl6RSg lzTZGJyq90kxkhGn72SzJiq5WlOJ4jh4u6ndi/xq25edmtEpWdcgz3ZPSoGAjj16OXGvW1+fqqES qOzhHRcmiPd3nb9CaJLcqNiB8TpZv7P49nCQa31c9kSXMNoTaT8OAltcxw6PYAC+70MMQw7OVFsf 0nQnutvmDewu2PW8fWAx6j7Mx/3+4uQ0YtdCxzmY0Ym+/nJJ93HvC+tyHsi/0fnNYREXcQlg7n7L WD/QXmyMg+tCLTRjVcXqesgfwpgrb3aen+cPPppTgC/OF8wtPjBtHkpyuUPvofGNx64EC8Dvm8+K U1+3rFXHiFcPziS2/pWC94vFZJ9++U6TcUmL3PyIR697Ii3jBtceDSckD96JBG1a0dzq3wT8D26i Zr8uwznPHJYIBqyOe49KYdPuCV9jHHaZnrPPST6Vktdf87uzC9JA6orReEQzYPgwXHv7dWhNB/Xu agYH49v05zqvhYP3rtqf7kfpkFM+RoacnxZnsie4vUzi7TSN9+66jT4GMOqf7/+/n5n/1hdzY2B9 n2PyPzwz/5nCZ0W6gubWjAxW6nPIO3hA40D8yK10+Okr7TXoKsDgB26M7oU7hWr3MVP8L337931X LazBmql1EttA7wcTOwTiUzjiXS/mCSfo+fYaYc44dWGUmjpQ83V68CnbnO/hV6oDVBLdxJ6YlROf 4+p1qzgfuHdP3ubqSgf5fPo+/VQMfeAsnd9OWKduapsC7jugTVMvs8q6Q0yfr/WCdD67+ufBvpoH qP2Ja2ffKWTA49+eJnONK13YpU9eZMBZvvvVC3Fr5oyTfd5/z7rRNoVqg4NLG6J6d0Zn8LznXWdd ntk0aJmDRJTFMdU1DvTiWZtxRfyzYkV168a5Vp3mI3V41cSuWm0qbXFjVI1q5GC9QGNE+TRcy11C 6as6u9D1OXGDrqRcA0itvRWc9SsJE05h4/kc6XhjMH3KZ+piU8f9nLhfHOQkNj6VOtb4mcedvDV0 2/ylzeHmSFx63f8Hh+CX3vJff94/bleNmYEyjyZ9VGB2g1/vJIoAEODpwGM6QTM9dQJkiidEQnMK XG8nY6EH7C4eeGJpOSNIw+5Wwqtlu3jqcAYXFOQUgTNItBB59RIlc12TYpdH6T3Qje46b5HkEh/F WtRvY1DAk+cAQ/PK7EbzcufI72j6zt6DCJ47nnY7U9zQj7Kx0lX8GGLvoJCIy5mga9eUM5cFPfEm /C5JQCoIsj4beohlihaOksk3UKOcmFQXEHtAoKnh3ZQK4mkmhj121PnPAXvECA2KITrs7wfQ8O3Y f81qeQadhBB4MwlmbpHJduAgl/xvITwPVbRb+YCT0CUFKLDGfRZtspBJdwUR125Ht/8HjZS053IC 0kYgj6mJLvDvkytjbAKEFAl82G2TnUMesMtN1CnO2Y5S3WKbPTVvaNje82pOgAtK/XjZv3GsW8jq SI7RDTIODzkN3qw+HNGTdPJfJr19wsl+hFnC9/+64g8Qcoai/VnNx7CdyvUoaNmIPxOSs0L3QPTj C3LLJ3C2f7Yi8vuKLqZn7w9wbgbiGNV3oOskUExkTxX4+nBcUTVWgkZwr+t3EIJOFRIoRxZArXtV g+1KBtmASgsuWnNodDjS3KR0Ptc6pw5CvUmkdOdRCQNnLpBLcGcIgBxxAwlg0BbfdYyokcx6Pql5 b6y6XfMB8g6IQgTOT/rr378HUvi+5FraWC2sp6tb5PzjniaSuvCtbQCbv84GCQhi3SkkucZfsqIH EBLwuBwrtrBylNHwPiA2xy5gSWB9fnuJHDdAuQfZtEa/DPTbfhns5tD17erxneS4j3szhRgbNBP6 WISj3gS2oEu8c7iIKweG6f7fZE87ZblJG+97+NfxoQU9txPN7bHkI7HtHlD71/8vzrpLp3khaQRU i9vp+edPC4j+ugspCWanCNlJ3ubQ+ldfRyR/nhXbsYySBlrUseUJr8Bk/ywiPASu4F8JG4K8gY1v vGZSr9OSFhzRjY0KxmVBUMcDz0GMdDXuRVgmkEw14RT56vUd34TD+YjWfQm06fv5I41i8AzyDJhY fIkcdfYRLHDrWuKSevymwBlJLkWyVdeNJfvWQfJqIB3DCPaz6Hb+gkFQLRWDx+oo6d+hiKdPlg7S ONwWHW70WAO/gzEi5HnXq5qjFsv7bde2a/hd7d6zUzUbgzpJVJZDVIXhiPgttqTodCFm+rNnIp5a wRWk+J8TiHaftlOSfFBn4H+sp/41rWPujUlA9fGNgdz6m2ze32lBIuRV4Dzpo/+eMn3JtUjebtQT ZaonJ8QxbZk4lD5vDaO77K/7OQ3Qur7fIAlPol5F6soANzR1xrCD8PYoXc5bh5MYu5Hdg7CCWlhn eiC9U84m7azFjf3+RnZPvIMP8xJPpE34EGUohExav6dTDOjTO4bRwbvS6YY9cVd0Go4PARamIEJf avCgnSCE2+1caM6xSfJOOvQ58CRAl7zwhxxdSqe2V3xY1aGN69dRHxze3yi9SbGFnz4me+iLqerE 00Fzt07z7MTmTJLW4l51fPapZO4p7rjTFgU2Py20uFAaQz+hz5SC5Cg9g2Y4ZL6kY21T0rxPwUqc Vcr7f6IeotyZPczRgdFxF/mrj5noX+FzkuGL+7v/hdk+MhEF/46EtHTux11hNoF7+ygdw56E5feQ WIpthBgYi18BYQuucKefkd+ql5EY8yQ0AJZ7c7+7Tobn+kBllPevdbRoNCZ/VhogxliHeOjp57eL 8HVB6YAM9f9ZM//DOfetK6kkbu3/7Mz8Vwd9et8eh6vmFI3+CvVm9Q7C27NxOs7ZUuEWjt7xd6A5 B3Q7le5n5atTzn/EYqJVqoMhay2Vz29Cg8iq9S0R3i/cQz5RMzK8m7ibIJlAQoM21lj4OCO/88AG 9FCe7xTpHE71EsvPkOlNa3/6Humso9bfdCqvwwn35b17QNJVT7SWYkoHw/uXOLsvjH/jq8Ke68aF 05ySOF/FWnVdrxrSCU7hJsmHee1FQeL11z7YfKSG8yNub/RMvmsR+nq+YiZ7EL9TrU8dSfWqPXi/ KzL9yworz0PiooX92dWTTmCInJqTWKvX/dhDNO99mYZarFG7UbRLIzWv2a73nr/du8U14suVeZsg sz6pz8b3/iEMXN/ZYeuZv0LqTLC8cKaNj7BJ6Y1VUY3VfRJhGcJ0M219hxkxVKmf00CVeBvCrr9M A4FFF6OCPJTb59qhwBpi1M8ky8C87asLmqqB5i/u9I6+Kevof6TY6w63JFdDEm57gRRehJFqajGJ 0rfx7gfmHZs6GZHgFQfx2t83gPT7orcP2+s0ZpyiXsCMeIv3k2vAgNuwbjzXVBAInDnkhQjDHTdg FA73Zie3bANMNu1jPrT0JsCVHxDQWRj+RhXUuIXYUXzA6S6323bnIAdL8gzxaoqXsM3sUsKHlpD4 MwD+dCn/Cnq2/DeJfxJtuugdviTugsSPMwyJdtiZ4G36VAS6O3rNLB7Y7hMBIBgGa4533NNZX65j hwu4BBNqv+dCjwhlHPNGDNChnAy59C2NKeDXX8McHPt5xdBmQ/vjkm9qvYCE9wBJtUUrnqnBivl4 R+MtTNjCngFxlVfROB+AaoJuPgo5nu/WzIdDF68zbh7qDnxBEHAzmLmbZZ/v6F8/iecvn+H3Hy2R CxRdG/yGOFT9ng8F8Klpue3sE3epO+/jblD34NG7ZqhB62nTvwlG4l0XsvzrlE/xuj2R6XKHfB9R 0sNErly5A+3KuQFgH82BKhJcR8jYNdZhHOD4FQjppAOEbf41nEIDYVeiDxfQ6c//Euc6ciyy2RKe uzxQwQB/rpm6HQvoe6PddDkR18YWgGtd1ZQkQQc4J4WgJAf/Dje9GfjMX+LCrgdUzlqK+oXpz8yt el3QVCCMh5xokti9nRav8Ytrrer0dvi9k7NujJrL7fri8eFO0g0v7Seb6tcWXRhlJcJcCZ9Oyq6n 51Oc6SWm41j5/c54oJvqK0rQIremZ23aIdD2IzQjv7GOaPbp5MjkvQLs+MpsYBfaN3LOKxZauHp9 jiQJbnVBTXQ5y686+RUv+3F0czuVc+T1HDWa57uqcjks6CRo87R0DEdt5/UBYvKSIGBlKYri9PCA 0wCB3OfeKwRQ9bBCIcQrYM+afHAk3yCwGMQbuP//Gv803IUDnrjaw7yrzqWEtXdIkvsFTzowwp7V TLp+dUDz7ul/BsjT0buGpNL146pTZjIB5q01yEUk9+sWABPB1EOU9x7TSqcQAuRXx6PAl34/nwE9 4P5lgpx0iUlSNFPR8ZrPE4Ud/NoxaNDNlvYN9560LlXIoz/SP7T6q91PtTv27/DyTdh2d6ITIKde gyonH8Qerg9fJhBws+ruExqjYzG0qie+anAQTYSz9sxXj/66mwrqaCMOtExlRBhm39rpaL/v3naS LUTEXSu74n99YDRXJ6NKz3r5BB+JNCTH2PiFoE4UIoao+ynklZ1251NQqBMT6gQD4k4mjEemXMb0 uXfavXqOc/MyWdERan0PQH/JAimJ0XMEwQK2bCQrDeKBJj8F53MP8gqJPy/zIzrn2hk6B5obV/mz 5Xcvxquwk8MysZnwBRJgey5XfuM5fglTm/V4n7v0Ou3+K2bcMPpvHxXDMt0funCHH8If++fABB88 vgdsL2zHR/95D+utky0wUcOQGTFxSnmIuMarqsZb0NDngNYlKfj0a3+4B5q3090AB+m6s1uMYKx8 LuTld/Dot35X3fO/feOLYa303U+HVPEaO6QJOjlYNnbAZxVuzLe5G43N+wMfTHbywD7gsxqxzTu3 7HZe9FxCGofn7yWupPXQo/wg3lZzY80430Pj79m0XB1NZh44FvLwXHGeaPBJ5oCjo4/ZKVdf0ng/ hgmMQBTGIM09WNvYltBETbW+DPkMlBTwxcN/Yfe7RtfxZN6U54HBUUfNK+DcB3nNxRm4T3nV99P9 Dsps5XI4vuw9VGd9YQfmOoprwvn/zOh/sA2LfGKsR9X7n5jxv4n7Nh+YRqc6z9IHuUxKKFlkzvem 1fP+/DNdaP37O/daao2Klvt+90GEFueA5T63SOxYRn/v6aM5kMcbS9b1jGDI/F+wT/KrfnQ64Gb/ vsvkanWuoZ1c9s2aRx2pPbS6+cDB5A7C8Ekl8CXovKyNjvG/5zxKg6uNTbl4yMh1FKeTViWiwf6v lF/O+/TuNWvg8bP3DRZBt5HXl7XZldiS+Jixw/FKEtXlxA21y/zllvyyHTIMXjIjvXGHP/uKdAOr b9fdd18MpuN8om6ShtZbpRcckBJB0Cd7xfcimb8adUCrb7KJCYu3uQfEhD2vjyTiAe4fnoueZ6uX 37t6Dc82y+j+yYEVrvXlrORv1IiT4D2UOJm4Va0xNdZHeg6uHxKL1F9XrP+ajDeg0SKjg+f80sxd p2RyxO4jtqXLViLYBz5/9FxCbPz55Jqh9DFKctTCDL61DKv/8KUN+ar7frWFiXi8Zz2vuf6ffxhi aoyxKl4Oj+uq8sT0e0dvaRECOsh2R+N9kcVNLtFBlQ20wq18kzE5Q+VF5LsOtd1qk4vJBsC6mWBn pxZUtrP4WzQlMGXcAL9E79QE0pyymWxG3/iyCXdsAJTygoXr29UgE6FxAdQ6yCf2/PR0vG3Bsf4l mlUDB88KOXimX9H15RlDLidT4NT3BFyD2DsOl6OWxl9PKtcqFQmv8/LURV9FTQgFeDdvAYLLXWGG HHwSOtjkWAMLLHk05Ffk3hZGtzLgcs3mtdvSEmRq4uwRgG89FdtAZhdUr/DqOxzaHxeFKlp+PQex A4eX44HLobYdw9P1cw/k6BF47PNbH7OyGgogYPC+AfU5hA4UtWx0CabPZ3BQJyCYnZDeZs4A4E+e Kaa7tQupnlj1UJA1Pbkkwn6iERE+i5hiCbzbCDC4BjPSCU0g2jQ2fUUruc/b1zHPQGYQsJGNO0Ui t4P/Pmv2+0wiOKkKECW47wFBiON32sx1vvmY6iZHDqOonuEcx9T4BNlLUsn5GFJp+InHmQypAMMy BQ04Gez72ShWGqAnHRPkLrB8DXOIPJ838EFwCQs9cwI53kNV0INxcz7SNQbOGoHTBc2S17CeuVop mxkghdrZzhF9tQUcAsBc4FuNpC+5ESRxBme+hoa8/N0nuLuSdtWFgQ81QEQpRLuWaJnfW682KdvR Yp4O1dRJ67+CSHZVzxFiI9khIJ00l/OyjoZ537OumL8//8zPf6ez8+euE9G7+hAxkwsoDeTGf1ev vaYohG9jO8APprvMXEKkBt32wEmCXSBGNZM8Ha27nVdJIDAohdiiz9dBkrKDqHNS1RiU8ODjrT7A s25QlqWh39Cz8fNeYknXyacC57MmnJm/CChu9zoXEKqPO3cQ+vW5CongI7H0BrOzR9m9vx9Xyy18 EYou8s74U8tdbiAOgI9uh4WhpfMpSlLouQj6/RTfCXukF9vIPswA5He93hHA/jxvdISNX/UduZMQ oZI7V1U3zylk+RpuTiyTKU3/DGirakVOpSIRkvCU2k+jHdcHiPs/9V/WANyrCDDKIJ/EhCEN0vf4 Wz5xhUhhAGhPTJHPzFXricl7H7HdLJ25zDTacYlkN4M0stB37msgpHuIWwxUcdxAWDvw5b8lCLyO 9jRM8tsvvQKiTcARMXjJFjuhgjFWIWbXxgcbV3oHYv2BH2xSjU4IL8F8D8P+OBZKiMPqjD3njMOZ dlMtXElz1BUDe0d/qfR40IxFcd3DF2Y07Wq6SWedrtUTzo+VAEupVnC6/qZVJC7f7pDb6eoaqu97 zweCMSgTNaYo59mr5boHaISBZNXmgSBbrKQT222RRNeC3KnACbwTynj47mYq9JDJjar/GhIZMGl2 RduGGLeXLrmWG1Iinoh4zbATf75j4rU8KQrM+pKlOGK80pnU6AI9t5j8Y+dHQtGNDL9pFZ1wfZ8u QmJcyFELKxxhCuQWWrHpxDYYI2E0pW/weLviLJu5DXD22unzS2hoREZnejeAex8I1qRNDHvUzp5b ugRmU3uI9uJHDJj2ILNMqUhd/bVWwfHd/9kKb1Ao7IDTcii4hSeAuuPvKwfVSTHutyFSDydHgg7h JXVOJsu5a7Tkt/2BVdHAczp2GrGJ2ZxwJYseN6mE3r9bmKlIIu3+0ZhuSlX7kdIONZ0PzHybV+3a OOVKLz/HhhoeSmu8hmS96t+/JcUGjKzNTWeqRNyZ/2fb/70WLM1Q+stEKohn/v0z8x9J8ZTOXLQ4 s/3ed0Jc6+sOQSw3OHDSXxA+x6YeOSg+RzZb8n0+R9TXYCDVqHrFa5QH1XhN1fH+0qtwNVl4uDop kQSelcaotrvKIRVeE+QaHrWU0yStU4O11YzVd1KtrOrVOGUwLADYq9qG5MbpxFIPYlSZjuOSWG69 kQqBij7APhANcsLu+7Wzsq4EtWud7bt/J7UPpBBSchnnnw1ausQICaYk6yPviQw15rg7ux9atZxj +NkDeLA/9udz+zkrMc8cSVOEp+bQOo2+DtQ7zUXMTwqOVrIa24algmhWurqrAhtEOvvOfM8UQarp 37Hpl+uZk0MmTQ6zPV5J1u+fM2pM55NHurAkTIAycayEOf5iy8ut/bCaec/K5K0TN2r75E7lncKS LsO41M+SspHH/LeQvgeuHTx9YmKCumD3NH1SZBJDD4FxlgulVH9x74SOTXwGV1LtxMDPy6ld0ngf DKEPHrDNU68Rpvc5/KObcHi4dCE84sNf4s/l4KiPICHegPd/90n6x1FpihhSFUjGefogOGEruaA7 wbHkEtsQmdRTyEbZGl2AtVB1kSEN8FExEv37IT1hEHTKwZrn4PgzESG3yZts9H0EwQ40fWuI4kNQ 8DONJbr0dmHa4OYU0Hx/GnD9MMUwNVnGJB4ICpzRL65p+Rl2luXI2Hu37sGABIBaqmCMcWuneRYw G92Xy7nYXheNoBS7SEqaLKTvwA6uCaQ0OUqAYEJS3xeQAKgKyl4CscrtN3YWv36BPXLX5Um+Hf+t 4xkYhRfKzA4lgBRCGTg73nW5Sf2rOH4uTzWgyLE/3azwfCBH19Oe8Yen744g7/b81910E3udhKB1 5l9DOQxNTIEiVzxi3ctBdL0umz1os+8P4VTk1/rjqsFHczzT8VN8egM4ZziNCxxyEfrpBuE1Cc0F 4ibjruiv/LN/i+6+ZQwciuzzOe7aS/UMMnrX2dp4DvL8OnMEiR4cU5jCrHa+uhyaoKkPApOG+qhh aDmrDjLcKw1ljqjkvPvec5/uRZFQRengMCUk6XBoursGHCvZxYeiLQVAo2HYZEW3vkNi/hXArnGD iBF9ncruYYrLb4Omo9+Ya5bm3VlOHgrCJFf4qp0Fa0AChxQdb+IbPOxkAAXRQS6Xj2AEHTGbeGR5 5turZa1AhO/ttvquScO4lo6BMyNI39KCdy1xbDIJHJ7drE08Xy6CFw1b1YZ3pCGTtsJx2/UmXiFJ xI1eZwDd+jk8khGfE0lOWgJwLeFR+THYJ5Uo7H27ElgO9QKBBiYLCUUpb9/i0/2I4/UIMONRwSPR wa57m3zwmvwRZgLsVCxPpud4WhSsx+FXB+RW56yueNnfX2aohA8fxAcM+R7CY1B39zB/nEOlmR7u 80n9FDJRTqs6z6v2F/oaQs+K/nb7uM7jFr/sz5EpTCkY3KkR2eOCuEWzHcueevdKIhpcxxG/eogh ffTn5F9LQwSJY70YqNG1XtF/ap3Lc+JH7L7NAos4tz0HZtHYk6GOkKbpRQ/26bdz9MZP558Az5NC 5Lt4HkOAg2yuf8IDP44UBhI2XIRHiyu28GmnYR3CSnNvRJQhp91soUuJwj0nqaSIBl7frT6jTyyS iXvjG3A8D5+yKM3fB1qycuWB3/E3uUvOmju1w1AHsJO34K7JRKmrC/yzpNlEYbBWJPyj3cP7zH1F D8Yaad9v7dSkItGFfASJswl/dFey/vv+1cV9RGJVC3PmJKYXDlAJIulqOcMM19eg/R4mUYk7aMB7 f68tl/SHw5mL09GZhkqDH402LO4DTBEE74wzSbQSxzQt2mtuhs7m4d4beqA5XWMD6fG38zYn8PkH q/CnW+5AzU23l25RYpiVUPqWADlW9HM77QfsWqShVKJKnNXGctps6xYqlRC4EubYgW5KoGwQcetE Kd+3SckRjUup6hmdIrqo3UwGGr66A+wAcljekIr9e0S1wcLPeaNvw4WdGPDsEwMfoG9BAVtMTf3d CwPlfCXB+2DMPxCE6XGHNpDIitSeD74hBUtbVHNntSuGC35dgrvnzqx0nWlgtdJ1rxuWmujgce5E TU7cYTTRp4DKIK8Scg2ZdEJYzyAH8KE5iRgU+/qTIi9s4BThfvDmoSnvTy8+8Kx1HxhV/nzCndqk cIBrYsXE7yCLYWcpBgWIDb4QWv2vZua/OacwnR3Yn3vnP+rxf/bn8+jCxh3nln6TbgBVcWJ3vmvo Gu/xTAvvJno8PnOEXIPibt0pYDTu+mnIVJ2RaDeDqy9pXai2d/V1nstko/lipRZCVJvR/TvIG+e+ QfMr5V3HieQ7MSYNSzL9tfuWmZ0EmcP8WwDaNcB1/2QNltxG4weDz34NX6kZwpRB8nh+pA9qTnOF q45711uxO54jv4bWFtQLaoWX0Ohj41q7P2bsX5i+3TXmGgoz9+7Cip2SGvNEfrBKMZ6tv+ibLkRa 9a6OpBqTsoLc/un9P5oZH0ozzdaWSpWgwD9/8yCUi2swf6Rzo4xYgUMf7AqudPkwa7ZxGGXMlYgn 7/BUkAlssA6s7KNzRxPpMn00LClDcjvgfk7dgBFHF+KjiVHn0u5nQMMJ78A0D1+3pdNr0JpjrNS/ /yTHVO3w3aMS/ilMeZu/8IiDGgPjgP1tCJTPlBkkLVNtz5RhQzr8XwmvG2+6qmFWV+Sa+YcCLMJ2 yCxy6BebIsSczvSH+Jn8utKJ4XJOjqNZOh2/OB48pj6PEosKgHZ89FyhjO2G9/+j7E9adW2XZX8o Y4naFCsUxLquQERULDp+X7VliYodQbQniCWWIIpYYIUgGDb+Z85xZcQv77Hch332Wu875xjPc99X kRkRGdEW/jSp2vCIy729C1+KeGjBxwt8SwPkdrtF3A537BVoKLINwsaWgl9ktTF2m8FMmgTS1HQo tFh7DWQsPB0qX9uRRkmeZl8T+20/69PJGGTMWkLoJG50CrJzorYHQXqOMado65urgeEvCsT+Inte 4H/+gszkNbimhEMcSo77RCCxKyqJo6hQ1BJdLLeO5TrA7pwM7l4lFoNfg94OGwjbRFsXcVKmPzxA wkf8/DUr5tlCJ6P7JTvBDrZqhx+S47xdAg0dBQE4iXiKXN1xtT5BhXWK+Qv8U+A0X83iLTLwIzDc rkkJyvXZrYqX0yleeN/dOwfhEq2wsO5vNDBECxGA5rliinScwcK0hW1exI2kY4+SQDNvjDWI8RTB mncIaGa7HLP7pVFQrxI+qO7DfWawM6aD5NkCYYo3RbJx5hBU6RFnX1kF19BUit6E6UFUHSkmpWfI I1uH4+cBXoNj/uBJse9h46jLVOThdsrpmHMVofIv7nBTM5/pCwLxGrtQthviRHM/UDsBdJsuP27n Ia5PDURXpjzoo3Z/6uaNE/98U4Uw4RgI1Zlm4wOszXPKES/umd/86jzwnGYG3aHm+P5awtMGP3cv 52ePEznuaSG6ElgLMY8zsUfvz+g9IrjvNbf8c5HHbuIhhQ2G6owEenYLW97BTQLRXiLkGk7gG9yH mP2HZDFWduDAaQaJXyGD8Dv7rB26i+idzp504VJqD7k0+cMv1JX445MsHjgGhYSBDhJtD3IRkeyj rph/wmcmhabkUOsDz0hXLDz93PTwdidMTOCqra7+kqLFX5JfPwZZEgsTdLmuGxzv/AshIwBIB8kH 472ykxgM79VASHZd8UMWO0Qxr7OvL3II05IaeC5kwQ2ynkSW/VGv+jgfU+BjwFq6Bnjrw6r2wlDS btJl4w23e1FLBbYDTJ4dncUy6376c2+lAI/A5j/vDBNbNF+hzkVk/i1M/NXtDJA0iV/AeIeIeNWH pCBNQIAgF7u66jQe+Uq7mKivq9P+eSIl2ifn7u7L3/19e3b9eRXb4fYVK+766alQNAdJ+g7X5D6L 3l2USNo9jkPIosNvOY1Tdm0i6GlyWFoIpdfAsbuqoaDbJubjnHeTuVkLCt+xPviCGEoUxUCTqOBr eI1qJs1XdHJop857TxAabrRrqDHwSLm4nAM54W0mHYwVSSOJ97xDOs+n0SBhexHjmYLqS8h8GrFc pGMPUL+DSiRAndE5OowosKcIOx7S9QeuOMdZzPXwMpqxP3NCtwApaxRX0uvbB6WAcJPr4SwplQs0 mlTYR8JNcwiuZ+BPAYsDO8+kGz1Ya5PWjJRvnKWTfK9kqFVlKlw2i0FMYbY+8BjNlHexImK873dK uhjIXeEBobpJ8Yy/SOb17qVjxSsMlLY5A+PN91N3OemS3KnFwlmLO6Q+xoGidglncfdzFuj5Hm5J tcIlsUZnnBy7zqcyvwiKfBpsfD3jiWGG52wy9bk+h766xqeB8OR1E0NkX/frBM80zLxT/zqDemNh qR8waBjI+3bXY3Oc+0Zn3jlc5YU9852Q7uWAHHwwpMUyniTEOgSsI6ZQev+OyA2CQvPhRaKOSezQ J4qlwHlVhmnFd+kaAtcxrtBPYYYNDQf6J8bXFOlJcC+Fy2c6Wqc7vED3sPakBmrs59wuvjrT2tmN dH+5qs094/+NpP/Xx4EVa2v1BNLMf0Iz/8Y3meRil6SJsUCub2lI8a0v9t3hGrIgAZvWIJnjuWl4 1LfTu21CFBIDImEzGSM4cG6BxoV4cFY4GAV0z7oAw0wPp1G+Qvk24xLwlHPoL1wcRLuR7zP0T09L ieTpIP8Ox++zjjABGIzKlaeBBO1OJftzjm53YMHbUGW7CbGfViv8xg84+Oviwl49iKl+a61U3uZS fwfp9ijed5h+xZmzPs+zxtCXuzDjqw42YrA/BmJ+6goy5VEMSR5JmEenyWVgYwg+zCpzkJdSUap+ t0MXxOnJOjKEq0IS5JnZqAraPS1lzBqGNJqPujB3FrVPnSOpjxCOFfAkwja0+7l3rrPx5SZ14G// XEKWeBDJM9+O9KyNWAOWmdfrrV0p9klfip9dx/eZ6pXstt33c0iFbZ/WOvGNlM+RxJQcnuYy9AM0 SIMYuX3dJ/R7953QJjNZ6XnI3OHuqXrATmW2QjqJTLMQ7F/q6S4+vdORGa2b82T8xwGx73cPU3A4 LXoERhkC964A7gSIMiaendR8HitehZfAXYej+i545XZA6+swBWUYJ50XngZFEY6CZ8IhTEPOhxcw 4C0C8mDZ9Da/ijg/IpoHY1VTcAHb33B9O93iOKKv2wSeMjM4n2jY7a4dRXWALEZydOCyHQRyv8RM X9F6FLXFU0oDgo2Mpv/z+tOtRQGgQCDqAeJogYJ/mwR31DS7+33JbTZI/zpD9szedm1VgRozgw3S nigdJIYNhBtdaUwqKoDYOUAtH03Cy4OSe+xFQNOkpT5A/LfR/zuBpwQ2Z8hlj6GFjYscnuEFtUxF SM13RI/4iSyX+hLGdXOwAfEH9DgR55CqPRFoexLVB8gzBx06MF3cxOIfofErmH0nZjNtIoUMl3Mt 7TIN42g8NEGpBC2Y0EmRZAQqCZx0ENOaFinywJY+i3zXlC14ksd9vsHG5Uaon/3kNVHOThV0n2Q6 hIs4mWkXhj/ijgfcc0R/G2KNAYBHIbDyb/T96E/gbACcasBLR+R3NsHposGnc7wnHCzT4bSgY61u UJSHyJrc5+Gbd60kXUtusjPt2qchX5C8Z/sWNQgKOhLWlYzgD1GBwl2wHcHnoMuQ0ItIr550hoBa s+jAx3llFDmonuRbtzpivsvVW7n+upsggO9K2klhpmD9CM5MG2Qu/nBECxGFwC36HJ5DsEvHiZ/n ikHc7HbYgrM7Xaf3/acQ3NAePxykFxAM7q4RRdpn9ismmVhLhyxWGa+qA6Bul7kmT1SZZnW/SQft 0mt310x3VdrT/Tdc2yA2pZtcfeZdh/BA2NfAhUbgOEHpb4OpMCz23vuXyF1VXOUUmHtHK/tcvVRT 7ujP7c6dn5WdIUuI44ax9k6//ObAXfIdyM/P5g4C/fvv/xrpdS8nvJWToGBxjbOuizfWQHShXCjR eevE3xL93u/IbrwHwBtP+3Ivy++zegkBUehMm+qf8w7kXN0Pi60EJFwDoEsQ7gvnpPQGwI9sOFcF n4dq1fzeTUCxs0onEM1kEs0XGXG74nTHatjhieXoWFeKWvQi3C4InZLJ2smWz6znEyglDOmeN9j7 Sj9/d46BWB7uNd6zNxrUT0BzYcSNhdHpaIhpHkjKuZCqwZ4OUjb05d+q0xkrB8pG17n0ig/2gG46 rX6b4Mx8xX13D6sPHInPyHdIn4enBV6qijSc/e8apSTsVnBGbbf8V5hBqU5VR0lBlh0u+I/7fLp+ 3sS/l4iwE0tdUeOX424FfdsHBzEl3jHeuzzwWpY02mJV7ik7q3ROuRwL4NNUQ0WICvqZK/t3J7tt HsXr+QlxU0Ovu1e2WEayDWYCD9xJkAY05EKiW9jeztqJq12pzhTYnedniy2meMwDORS5/7bDHQd4 GzOY9ruj+kSnK6GAu9Swmc73WJyOp23owSNRF/jPL+seA9P3pl4S54D1frHNwrMJh3MwSZHcUv2B cm7zA+F5zv27aCjSPKDw1/BJA5xS+PiZelHisuesMTuZYuYyneFhjG1ksvpUGz/Jvs++0iDeYex7 P+inYIxTQHXOXQnYOodJffhcDyA59HOfn+SvyqTZRX381lfvUGZN2kKSv6m7sRc4RWd/SMbWcg1r Y3kS1sGEUpUwpQSqb5p391XGG+cXEfeRECQc9puhxHbm+vIuFKSMJXfCq0CxH9pw4uobhRwEuZgu XGiaz88h4X/xb//PM/pvdP/ctfsh1Po3e+Y/ttcMY9TImXrmHm1skTGNatE+TYOKnWaSmL1PfQxx VD9mYLvDqrVhQ3+3TekMd4wA15iHK968JXZAxaH+JOU2nqs0SsWhfuJC2iFdB0tFbEKeJm9f+fe+ dHicV3rpxhb2vd7r4Fs4vteBy58fLDcffO2tbWuUPHiHHsL/bZicdXmK+rZTxp/aV3s96CtFc6Vw 7TtYwHMJfy8nKVH/kHf4qzHUYdIq7ZOXscYYYtTWmbx4xn7HbTw6MTiV/d5O6eUB2VWjerBPEmZ7 XxidwwF6wuTjeQ/o+O1Jo6s5PtMyDtY+w+2vN6mDZ73+u1cCbt57lDDgwk4Ge6M50r/WnagLg+vT S1V7pynh/AwM1rB2Z9urcGIhL7ATIEPTl/V9DLmkOWremj6tSLiXTxvsd/CoT/vv4QrGDMjQy5UH dWVgr0rRhLfpuOOCf9BhnAE9rUBTxHybPhMj5xeWXpNGcl9p1xrWADcOMYdpeGJDhXJpZj5WVOrN bf8Ruh8z/u5ybIAU8emcyXM9X5dSxc9oA2XdAAmmB7dr4U9/RBHFMcXlK5Aa3EPM1IVn0A0sIZh2 z80pwHQ80b4wxUCqT8rZSPUnYa0R3g1azXeAhPYSLvhsHgGMEk0rT7hYkLjNAd7QxlfBCuhkkgGD 2lGoLfjO4hFnz4YDRDx3TBtFuS8UYa3TT4GR+/l1saMQ4Cga5u3u67lcGqbImNchQQEqfXnq3AV4 whj6IP4CWHIUdW4H+SqNpGMe6iKXCYARRIT4KN6PaFQAv1+Slmei2JF6R7swRKvD0YqdwC63rY9o KSjWLoJLedZXFFQXyn8nQU0E/qwEgu1Kf4tZFYMiNzGj3bI+zfA5xfc2ESLw5abLfwbBOkWAmlEm dVJYxZFzc0yqk7Bnrogwv0AqgU5dNDkFIzURaHD8hMSWcDTfzbSeu41muMUCgNOnXCcxls3yW/YV EIyJDy2GMKTt3O4RE7F3LqC5wSq3K8zMRyOl+R7WIgCjP2u6OE85cl+T9TkQoyMeTsf6zknxa0/k MKc/mgdXI3A351pDnjdMq3JhpSjGOUFhDw1IXnTu3wEJz9meknQBgT8xsO1Si14OjDymyG4vHd21 B20EdYJQ0ENO5Yqm+cZcXhCQ70v279JqbNvJUriWU2DKBKjKeajv6auO4Haeo6Jvmjxrh+28MfA7 2Bnkm57i724ASe5gXqFEbdWM6v2lEIP4o95a/YkI/ko3Da6dK1RW3K8SEHOfjT7knS2QE5K/CZxf CVkNeFyr5fI+YffB/tYGAUaSfCmAtAfpJX2sNaK7PexONHDO1DnuFGz4gPNw9Gq+og4Fvcb9pPfg MrmqJ4DHgYQuYvU64/0kufQ5JnRH3eJ8HxSIDnI3h09UArIpl410bxQQeTo6Xc0Zu57vWHlrqO6Y K53oojgE7sYGwRD1Jy+xSk73DMrS3r3unBazvSlh8wzBNzGt7bY5V78V55CSkODECuH5NnUXC57V HFV1u+oz9qAPXNFAAuRTfp3uJ3rjaxApxQs67nnK6xzwpctalLGCC5+9elcdNdJ2B84kqnTO9IEA Cs1XSGBHg6YznAeoD3MOH9/uShJKIQMR9E1wzYlxsOyBHNGF5PZMi6uZ2G3cqG+oLzcrzxfhwxgw i6jjuYXowr/2Zi6LH+HenCC0/SnSwbFt/+DXwr48sU+DC767hvY8kc2Q2mjuwS8s8LZFujFd12Dz /fxf8YexRr4wBRBZ6BCOwkqiPGCun3724x4CeYf4eOC+721OO9bC/gaJ3dcMY31mMwawVq27pvTz ihY/qO/PeTuKGcwscnUZnm2KRIznA+lKHJNxRsL5WuW/O4wphgp1Er99FqPc3OlASYOD+c6vnnGC UJ/pZBmq1barbqcdsou1Qxgl2GckcnPnaMKIvDEj1njKaaVCtCHCd7rjnHeLQsANXbqN6avLqEmC NCtXDSlIHlGdc7lP9PlNdiLt1xlIA6ksqBe4PebRrkfcutzU7d6/0VN85P0ClpT3LX0rznLTlVFt cmVsLYRPs7+heBjEp/s9tTnJTzrVe+enR/3GsGZeHt4n7uMwUcuedpt9c+JPp0f5NF1QYMNophNp 3gYsjutlymjWDKbZzpAIPXm5TAgWsNmOwcB9J1PaSPaFnk5kULiikpZiYypXdZb4bmSJQj/492/9 72f83yLhng9eKOq9/4BG/7E9nNfpmlwn+alX9Uv/ep1v5CyrOFe3qZWCk5a+xpVvzj6/n/KGhMTB uc5TMIH6M/Cy1p60EtIIh+gBjYmUhDSQc3wXGgjVUafvBCrKbdv/fw8Q86A85c6r3KUv2Tylh74m BskrUcqrTr1BcJelV4FKI1zRb8OVzSfNUO2gOWxjm/v2Ty+wXK7VBhGMMQwMA7Khw3VW3wM4gQdD Kt/LffUAbZ8slZTlgdTLCZfuTnk1DgPOoaHYY8F7iJlrk52+ln3gdzpCY2C9k3otXoatzYx4rkGV 4y6Rlq5hCKHQIBKY9fIeSu7eTp9574Ed+sL4ri6J2PLsn41pBSYmzYlH8U1YCWGh5Hg561ofz88m DeXftaWZvuN9jLgQxmHoqlQD03oS3+dj4GTKcZ2y5i6jBcfo9b5jScO1hedGzBxTvivJm5HMOXiH daOHoSnd4bvmhHMXcEnCkAbz3lpkPhfHX5qT/Fz+6De77yEThj9nxz9oRvUl0tkPSAsD0wkxH3FV Q9P1FzSUzTxvaLbl3wRnRWG5N7bC2WdP3UUBICJU7he7LqmYInP9jIyruILOKEZgP2nDtWMo1BI8 10WahyuPXyBKCYp5vnytm/xuMLAv2JgeKRFnR2/fPoEpdt0aq4xE6wMxLiJ/wZvzDKTHuvFuSqkh eiO6tzvOMR8lkrDcbaz05WbEl11Huc+HcKCLEH2UEhUjT4CUt5PqcpB5/246na7nqFOWtz6xs0kh Gje/nbGR9YfIgcNF03GkZXg58ahpF41X5I0SWhvJB2FTeBVsHMWe//zdZ8afl1PK4YYnFtD+BfS0 10VHomf00rvT7sny/LaXtGzm8rtUOPjsee6OJ7sLny30MTRBquESH8V8v5lec3OUG+/+ovimVYBB egQJfheYocH1RjF5FDGvcuzdQ1Y7jvAC9RkcvZ5nv5d2nUky5Ke5327RB4AIQIFiPaXrRDrmZY1w vPuHPGjxAMXI7ahsSuWxaUjH9b06gvuiY45xPs+gEx5UnkkUaJhcaiFMnHam6WjYx7rIoX1AatLt 6J5Yv2pjdgq4g5hpavaPa0PHFO/4LWE7fcXLDbgFCBpL2ns32TBnEtRu5vbwKMuojUklPsCZp9Yx Oeo+9477c9Kffx1h2CHYXA1Kcw2YvGJM4/Olht2rDu20qwSbLxmSQfAqELLMr7DTHsDlekWHw0Je IH+eiWrd+RBpbDFyOuT0t536uT5TnthJSwBItyimRQ7fLsAMDGPl4e9efSYdN3/2Aot3LiDmS9pO /4vh9kPjDt9+iAPnftxqIuhxO89VPPbqdbckQ59hzAEOPbOMnhtsJpEnS1yvyhb+uZOo3kOHOiFW JsvYGYf+U++fFGr7FzzJMBh7OWsOBLP/1Ggv1pF9nJ8/oxkUWH3FLfa4iaszcdQZAumbQJxH73z3 zDpEKzzo5xIc0LKhJMDXEOEliNNIoWvcqwMnAnaWe9dgyPMeJtSKh+ZUHZ+441vXOrAqSg9xufC9 e4TA99uleH7t7X6TF/y90514kJB8OuuKk+RI44Q+QyZO6PVPzCk5POqmmxBLR5o/70uD3/HP+1zd jS83665OWlZnINwpjJxr9esMv4SiCoe/HBQ2ihQ2fiussYV/dj+frIGeels9hL5rfz6/212YkTe6 nxiX2Hu4BRl9nr49Mbnh0ThDd1g56Ej36sUtGHGoNxFBONjhAqRd+3njRppOi3rvw784k3a0eQpC 1lBJ3TU660lBdoROrCXMSyISPEXT281xx7frOPtyWHkneQlHcAfrZC8X1BRdkpjf4GM2UB/983t4 Y1+TZkPLYCoHNRQCZD8i51vOPusMT6xTHzh8nheU+DtVI5q+rXfdsAffW4T0iSKYBoCFGCK59hdU ddb0iZ63I/N7fvK4Svf1aSaz67RB0cXfOsd3b77PHBbIvC7/b70hFDNN9REtpHLhkop9rhDG09re gmB21eModa27wViRqPDXjQPeaaiE52z84XU89Cd+8ufzsYQg3tsjNB/T/vNR015CRvRVDMMhYhK1 U3+comhD730Z0nyla1NC8cb7W4IU6b/JcQCzZ0yri4EUs5ZC0ylEN4WrcySBDTdUdcA+L7PK0mkO 8oUz9RrutVpJhJCuhftTgwMwXwOKhrp/D61zpe0z1bbraXIFdyaV+MoJ88nLT9VI2yGYd0APd+7B c8I/iQuZAwcaz8z/3jP/8/rOJqF+cRma8X/Q43/Du6d9YF4tJk5X0E4MKBG889+QkNCLt/sRKLpw W2NnkENgmehMtVCbEnnuYYONcTUW+fd36UszlWd3rpcc5PfHfqe9n4MWYfxWYnkhWz+f+3FmfjGK 2LxUJjhRssfEXcj6oXkM7LLu8NWTUjWhnwHmKez4n4H1HRoReH91V3TaPf54veZpMzt1VaAEbPHp wL8jjk34jrez9JWq/VOzclIjCdJJI1eJK8qz3TUjrBjUuDNu9SGydzM/Yof2tqF5fo8nRMZhxuLs aQ1nj550qkzTNRj3fSWhGDFQuqduHGVwj16pc410REqo5p+4cxU9Mz31B+8kPsluTYe6F//BGrbA mzCp9zzWEjNfKq7uB8lwMlFefeBalDkxpx5m5jIsfAf9BBjCldxEaa1swtBvLhHB/fRcPOOlcNhm zGQt6hhmjhTCY9iB1uSPqXCcJ2L+Vph9c3F//tQEzwfLuE18FAZRPJS2B4S7smP845O1/Jcc3dka vy+el4DqKXODSCY2axWbFNe1Rd/GuL1dYO5DuYsFm8X8I7q+niX7CKRIbHqFyuqLpDeTkF0ET5AQ PMHYl73KlU4fMfIkRdEHcMUNdxOBDOiQPIVEtx1r9RbB5HiuEsZfjkldVOyYpmuT9qRSgkavoDqJ OJ9Ezhv54gVuM5n75USnInR8xHnow42+L6J/4XDhGRIvZ1PPrtBdNpCIc3Bic+4G7n1HohkguhCg cfdMi5z3ebKjar4kFR1Zbwf4EKIgDm/bAipTc3GOcCRxyus4i5qOcPm1g0LirUOKHsDB8Sl1x/y8 wvw5/BQWOBWyF68mcSadCwyOxUyd0lrUIipcEU2DTkQ9GZ+NI90vX5OgLd65nDi7nEnw6dqL25Ep UyOy1KnkChH5/CMEpXSSdSeYxn5Y6M/vqgXN6eYuuBv12eyQsCRcYZzEjQ/62x+NIw+cMOi4AcvV aIqclt7m16ewReCW2neA8RbXpEDlcY75JebPZ92h852s89nv8MIXhMAESUcUbiHnO5Syai7xN2Ff 4+2qxk25nlhsncCe0XuMEhR+G8zUXNPDlKI04dzhl2QssmJQ/NI7jQaOWAhOjtPzi9PaFl0IcpCu cKxBEOCH3Px55u8kNKVi9aADEZ3tuH7dHw4hmUEMQMlH696As4Rc/xMGYOIje5IrHUdDrpftdAud 15OYuL/3Jl19yI7ed7T3/1cYNHV69z2mTxmDQEjqEMTcZyS7CJDY/BpwSS8HoyhFeLYJ+gKk1f+m dLliyik2dI69RuRn9yz8zDfAzl2GPqtdBXnkpOFFjh6NdaTAzh+B1Fc9ruh7L8fur/HTAfLtrrIb uMpP4lWrUSrV7dKrcE9r8QOhVJqmfsjZZScd+SGhNtiblaeHxNZoEOAcnjXKB9oZskHEV1grBKJ/ zq7tFL7rzxTHvSYBOnLGfoQVXqT5koxC5PV2G2oRAjnKNoY1H4k9773d4pZFmvgRRh9CrQwQn8CX dNzHlOHgeCck3qJBTIO4xYXREFGtXzryqN+8sZHPYWfNfKVsDKAr7AqlGORTPGM+b2vwICOyA/cR khcOAZRqja8BBLe058UHX6LyfUY0OsX3+Y0Np4O4oP54HeeNtNMm3TdJxs7VbDahj1sYhSzx9Hes MxNhrjS+a3hkO6RN4cJ3XfZIJjxAK3P658sX+GAmlnOpslfwwoQyW4wEMJ6Dt6A94SlieLumUl1B CTEb79An5kpmEBlXH7iWpmqeb9c0/1qBlQNp1Pr7o/kTa8t0rD2wYOC+IKlVxARtMS3uMhuGKLND 7FqeeKjbhoPTq/pedf2Z4oqU/NrAgOJXuiGLSjrNiQVbwiHiqb6WE6XV7nPzGqYcmYduPKtNNfJM 5bQaYUS62lXVFPHdwrk+qxur0SncJY5Gk97O7xrP9BzVv9Nnf1EItXIA8RLq3T1wJp5l3bl7e4cL tMtohhHCzQu60hZywGevpzepus2yUjQ5MVbREe3+kPu8RjKaYed2R7KlLlxGlWK9bgGxjCrx7z53 afjKS3jBveuHYGVZhd+C6DwJb2fCxq98pvAMahva6kWPeHLzLPo4t98kPn2IXfk+bfSdT2cVpmoQ Am8TJjYaFN4Hrt/UvTUPHOTAbSYyz8FlGe+TvLtcdWslvyuT7XVglzAcMwPd+kDyMIiDXkpbOn6v wUBD0/Z3qbWY6jE1mRxBHTIhdAd3sM36/u8z/q+s4cLqES4hsWZG//oZ/SdyaIvTXHygGnNyFyR5 +8NfZFbVlUv0lxdbru4PHlkmhpoUEatPf+AKiW+HNFwU5N8O/Xow3C+B+Ooa1P1AY+dGcWDWIGn2 wb3CUy8lO+CpdS44w7dCwJMJDV2nzS+Ytg489K3rZrYOykfd6RjEncm0ihzE/P5sfa+/a9WTbusX jpTDb1N9QHNMUJecrvCJTTZmSYZbjHVdvHj8jFfHcKSVUBJampf9MQ0gk5C/ZrYxwPjTbw70PVeV kntJpQs48XU4994a8a8bP7jr33j/QJpSu+FvrR4PEKLx5dH1v/3vPbCY+0sofmaN6o2BXP08OVCL elptXGLrAWcGshpf05cU3jMf/HMWesig96lL/W2mwUYeX77791v7QqlHXR29uI5KD+khDVKmZ1x2 ur/jSq70An0opH9D4RNXfPHFn/3lo66fD/x/qi4jQ7o2v/zBPgxDf2/tnYPGyddeKOWbtpV9YZpW /sah39ik/ynr2T//6R+ql/0CLkHwSEHOTIHafXD1MUVCGvCFRNHKeiECIv0BPIUFAsVXbQHTivDx DIvTuj3xCUglMHMsatc3hOfKszLgf3Q4ixhJ/zkpwC2QuYSbTdDNUYbsgobRQx8Q6lfkGx/c5aXm C7o3OhDMr1P4WpM0fxuNI6JtDmCDJNLC+OML4t6Fhw+RwI77EBSEV2MojP3pxlbhoJHQyXEKmGEu AlPI9cJBxvP4xocbm/JiaxIp96qn3eHmOLuaYGxbzC6kdvEpiAHK85mgH50XpqopIifOHGTi1ooj rAVCtR2FM3MndLxkQYtK3rsKJCmrtpRS3OLlEHc3uAKH4Bi0Uu67juo0hKwTWOFqgkjEPx/nQgqx fnvv8b4xAokEtN5Fk7+FmoOf5y30iAgejFylYms9SdOdGGfFX64mm0iHc63wtNVHHGqSYDdB1+ep 50oW0dyyRSIaXuCNwAZVIyaMFOp3mtB1xy/6kCjpZ+hk3ck+mpmuHOchIUlwVM2J8h5UEdK3K4ZK BsDRkrF9wL2K7ndy6k9XKx1rzTWUtiuWbHyxzDyrNH/UB1OgCwFSlfwjkvYzoNZCdZ6ifgElf4oy fgjnl3hW1RRfTauO+zlGc7XX3iug0FWPTUulSGzZZ88FN6SLzww58F7DxtcQFJNqBKK3Y0aNDzjB DYO0garlLXT5A+hsN8upvLCmxTRznnczl+tyxsNjBHv9bRbOvxADVEnH4PaXA0vckLr+7pxuMoNd XZLu7fZW56b+CZhCJGfrVK/9fP136fiU1PC9uDt5/zL25Ir6XJ/Sc+yZJABc5KPncDrIU97v2UYx fvoks85qvQYzuz8e7Kx7n2dk4jwOFctZFQYrXkCM3bZmnSP+RUjzJRgfGNyeIKdZZDHHKQSBoPqi V1nY5zqTr3cXg48xMOjDaELQI044cpWPotq7tXaViATNFd0i/ItE4LVGBgrsVJxRyi/p/OMq5aOe uaT/gSoVUd2ZEIy3+UNUJ+hh9FGXQX9+OKenMLtd3437krsMFyZyj21pOZGxWzXdMrvO4kpRq2+/ XY2nRgd2bRoiHLWw3nCu5iBby1i+bELyTjQKS5q83H9Ol2BDRDI57sru2TizSEcqlT4cn+i/7yrX y7yF6zo6u68A9H3fTjjl/fQhnhzw8dErvA6HAqdjzyAJ1gNcy8nfLEzrZxyYl/cd8YoqhVVOCm1m yNk/3ei/BBNXUuqgV6U/+gJ9OLcmRstjSInZVuy4VMY+xrMnPq/SGThIVXU9uk5m/2aMMz94pZRl ZGFyL3fzpsjs95E3uD/eZIumBOLnjaO/Mep+BolnDdg5cIeMCNeqPYScjMhoqvoZwfkndKW+mRb6 /j7STX7q+IZR7iG0LWyZAw/t6HiJ6jZy+KShWUZsL6f/a3x8oDtNonq7z9JN18MY/rBG2OS/fzE8 8qdYoXc3pTDCiWiqRXdPsrp4NR5G6YLUYejqoz/rLx1opIGbF3IvlPCcVgVvf1TDNmdV0wYOP6KO 25Diz9nSonx/7rPEdfbwfGPvl1nK69j9k8ah8xbMt7DFSAND01nnbUOpV4qyXN/dzq2VHPeJfPDg yJtgvwetLjQEZGJvUpn9uRtzoIftQu40pqvW/q0/r7TaSGRtjs8lH9y4IeCaiI9P1C8k4n+HfXPv 6DxzL0TmL/5twtFTY+OyURvokXw+Zx33bFQfq7bR/3lG/91Zg/CUtuDj7Pd/YGb+Y8V1Ok3FHIPc s0R/dhsGsNFEp3oYuaKZzyS79yzRW5tufLfrYQ9bnF2DYJFQhpivT82Al6DQYAxgNgaczfte6bB5 5248qM+mwTvUoRegpDwf98WPWEPBD8+5ln3WVBOO7H2nvRoYrySUkBuCTkrLXHUNojD7uPb9m7qt OL/yzalSZNiwlDDu1btLB+Lyk8z7rX1KnOLC1am/7L2Tg+u+kpRXPZHDFEfHoPi5Ik1DJ8ChcqYM UVNb2cOTBkO714X9UsNNCtG9e2g6geabcQXjvk49vLnUy47w5p8ugy1/ivsb1fJK3qEeRmhCunEb FXafKZWb19CZPc93uhamZ0xR3eYy7w/OxNfXFX2CJ71wS4EBm5fO7gtzaJx66wHJqGabV5I52rVS /3DuXgl5+tDIDPbqxVnbzZP64r0H8MBOi6P0V9YmtmES/1bmeXY67Zx1XJ+B7+9uc5ovZj5poW/D 7EHsaaDCyjrNTvyGjbfec/0fU/HRr/PVIyv1QKSRjleQk1nD5OX7NU3R6MKFrpiu/3LFfX++6uCf cFx+CaGOoBYUiO04wOFrHS1d1De4HGVsw25Y3kKZBVFa/+8CVIxTdhjSOFsYdMVhT8V0KEkAw+R0 0dxU4qUreU4KZwEYRLGocL2Pro6dNDrmDxRDJPTo+EfPV0wnkUg6ocMBt4h+x+8lxgfOLJdqJia9 wFydhzQ5LPYAS4q09SG6EByvimGMogDsAJ+u56Oaobb7fHsv10EwZE/TGcmeLlwGoWFhY7smxExr 9gLiHdPRPooE/ziifxIoGn/Kj7+anOu/TwBCgw39FoZ2SbvOG2kRMyoR7FsczlBco8uNl6LlNexm 1cCKyV1JOuTpCtFHOBFCY/TtYcLiZd8nIJxiSs3LbCHjJg/vKMscEgFyPNdAwxPzOgaRx+cpugrn N5WL8j1DaXBn2MAq7Qh2H9EJ+HquDAc3cnPIbu5QIlUUYhbrcwBvhrqq6ZE30SIBg3T26Gn3qedp aCnpW30NPSRYyuA0NxQJlnOEmGCivW/1W0DF+yTP99u1VBht17Wo504HaDEyA5mGpqV/s2sAiOUu U8T5gOMJPfvoQRwiIFElkSITar6gGnZG36WryM+wrIAoMdAcRU44BQiXSIcIQh3wg35p/lWup55O 9ElvNBRNl0DjEez4Sb3QwEBZU/FL8AopIUuME+fIC8S5RBY+nDSAvhBkdJj22Pez/hp8eNMA5rP1 11EhK+7JTtvQdb7OHi5UDSM4nKPn6GnSjZBv4Ldf2/vJ0Pdc4wI6IawEsLYzO4OR63Z233sFeuc5 qoE6w0es6kvkbDH267rHULQPZMU4oOqZx7GqSdm/LoTeYkESue37EIgGEfnRd6bqjgDQUPMBfmWv 1mvJvkUaV1rhDIO9XQE+n8dz7Mp/NtLZSLwNxJty2tt+1nb42jmFpj6BdKFHX7t9MPBpjBbN/tUz B5aXTmXGCgHBZvHZ1LU6JKdN2lC0ozjJM95aoIhwAMftr5Pc5+DlrPXc9bYBVzkHR9wnCEnxvwaK FlYaRBrnVWwnzzQS6ChfqPHFdSVTfFQf/ZKsYv677aKo+T0NketSGuptBx6u6dm1Zp9z7/m9sW/P 4HAN9NfS8dn5vmGHrHYaFgiAOpGqg5a3GJGcsTSD4qSLlOPYeF29BNEyNfQoJEylriy0CO8Y7dcg Nn6T0Y0paOYQu26Bp813kNCEZeYSOtLw135eTdpjsl04MOag+lrb2NXu87PHDPtn6oOO5qF/RcqR sGfZQ4VZxFwCZO27RM2VXSlPmZbU9dAc2FOnEmiZJTSvtlOk9NET6KBmBfiuPwfxCYfSL13vO9Q3 kfAVXVfV09Ic1bfh02ZPqWlR6BYc3NLm7N/IcTnxRep5euXfyTACbKN5oNfxPnkqWInMInq/1dcg QB/nM/GRNOCriL0/3bLnwoVc5iI9hO7NHRdXI+4hnMkobCoWJ8m04GnmW3Tsj89B4tJLjCNMklz1 kRsjmRJ4bDxZ+mJeaXgu+eepTuXvIO8SzQzWLX85x3P/aL7Tpb2c++eobdgwbQ8ULXZC9Fw390vD DjlWYhAEzePgnbvTRw/XdeZ2p+1+hpIfBdwkDI6ZB2ZIfvz9Xi7X0NvZms4xVxJWjj22UFuH2qNM AT7qKkq2FOoa5i9ORGltczw3nQLtK82bhFqMX+yq2/87j/87XbsbDRTUd8i/f8b/9jIyipQZHCZ6 ecAHh6DhGwHbSkaQZ4IqDBManvX7p3oAnzQEOfw5hyZGOHrP3Vsn3kxgbZfDNOrR4/NcplJZP+67 4DIOY53AOyTyk85tuN81OdySdBEKYzVoLLeepGFfaAID/uqYABsX1TiN0RsGj1TiahJQ0qD0lQyc PcyE9otrgTYwFNajnYI1n8YByc91Fb6TElKk/JrY0vq+BP/kDr0FyVSrDLAdarYBEoAR/8ZB+0f/ pvl8n6vXFg8x3XXYZQQXTwUnnRw9+2Vq5NoTOnUSYWZqH2hwY7GUSkNMo9f2JrWMlzmRl6lHrgrP YJe6sdxtTknosJHrVSV0PO9LXeslyu1nbziTbzwfic1XKnTXbW8q5sDA6cUMpph/JyF3TWIelpvU LRrvtzj/dHcn9/3kwrwusxRV7z7F2b68dyv7vpOjX4MEwzPTp2UUmSH5GMzmc6swSk+ZDJIehvUM E2Z2dBb5EOLP/KOLjz7U/uzfn2J60Om4PaVKusofxDsedgvDiPSJSRp0NMqpm0En7nkdKvK7KCBS R1ERgwBzOqaqnowZdo7v970J+g9dYqMr/uhyICIHUbr4JsDojL/aJPJPMaoHkJj6CRR9ng2SYLp0 FSwioqqhVnI3U1xmm0AlIIgufwLhejq2C/zr5/xMmq6Jf88JIl+N8wJp4hB997trCvBLOn0dksbG ZgmH3WC/p92zGiSfo9h2ZAwYY1L76RiFF6O4dM4G+Z+fU/w9zaIj9epd65m0kqIA82chskpnD0Rr pSyfxI5bhECy7ARtOYPiimf97VziApWjrW5BBq5kDZBQv4WoCMm8axCo3PSHY9SMAohpEGz+mSgo PvuF72E+mx8HEL7OllcI5sGYHB8kxlSxQ021aiCuEzDmFCPMXN4+13e+XH/Jz8wrnqjf7+VumCTk bg25nFS7awueiokMd913490ObPJ5UBjAiRbUJBFZqfp+6fxFDk/puCd0SJqKQVqfWwMii/ccueNc E/ppKllzOVwsMNckoNJxRvkcREh3hssF5nXCZhD7khi5HPRI9p5EwFWLb6GAisC7xEIEPBoGjHzU bHOKGaae5dUKvkkeqiSUKUh717qaTJ1qMa5WSlVHshOhbWy43/NH6EQymPqhmRJalwvqkjikgM1R PbRf0jzDBz2o6x1ffAqyqHN1nINCMHYW2UD0/ExHOB8ercq6rSJ8T4D3PZP+1vaYdLJFMIN0Gvc6 TXxeMfbxu5yRci5SYQxOapAaksKr5cio3Y/398k6uKf3F9BtqOT15WTos1LfLmZE7OkahcGztMTI /9S5NHU3vUkFtH5/7tF0rNOvQuxXeEIEYR53LST3cpTwL6lNl4hlE5ns2rhuDx01mu7+zI+DIRGN V56Kai1nQhHViJ/ZVTPnOONE3cbYQ/UF6kj0PchwkCKmellr8NmnnDwgWSAEX/fdV6D6g2/ET9as dEXqmL1wxrfuphQXAqcv6pfcMvc5Qu4rTkFN1BgqgLqJzBZ37v70HWa5Vte+Q39ii7dL8Y3mUB+U A35/7lE9rJeO++rdq5uM9Uquy5tX2ANv/OG2U5mPs3a7NzXu5IPCYSxCa93tP+bjbG9p221GokJm VLXmT236GFvYQ95wlKr4Gtt8Y8aGTmFmwoxmD7/VKX8kXsVdrguzobd13afPIIbfk5kHSvYBtEWs b/qFTvdNumd7nGclQR2E5t936O5lN7E2B8kdnat+/tcLtxUYZcxBTCYR1oLPdMJMhzESKQhHAo2D 8YQLsCBoznNhPhD4q07JQb6BJyAdXaeu9BWFeCoRHh3kewyDgojzGox1icEPQQ46faowH8ay2MH1 EtxxcvCVJtF4W2NAKjxLcR5cOJGOJ5eWMC9fUPiZtISc7FbY/81AYuuU3atXQpl+cB1a5gSHSEuF q2UXI0TrO31EH13IZYBj5FZz4MCxxziPs9NNyckyLaYSo2x8+DCNgITxjWP7szuazyF6P86cPSCO Ax3edZyRP9QxUNV103ykx3EGqaJfE3I4dO/Q2AK5cqrYrs13LanouVYMg/eZqqEPrvw13EhXwhhE poSVVbs9v9eGgcvr2Qt5m53EkTjZ7VlO4h5pqiNtf8ZE6IyNq9HVWn+Hc3/MPwZWwRY6OoZoG8sT /gytflnnHapjf7Vxwd7/wrSyuDfNpi5XjfumyBuGb5Nf1Qd+33hyJzd/4fX/4j/9f2b03+Oa5R4G eHbuv1Iz/8Hij94hb7WZ1jVszMaKLbPK/ftlUtCJ5JDalGkgkKK3B6GmeCYdHH6PsKl4kuZF2Tjv 5p34W69VrKt/vZKz9j65ufl7Ha9aQsJza37DyTTII+V8lGt3p9vyneLYTvRpMuIjIfyuwHSe9f71 TdIAP2kdEjffAzeeNjo0cEkUee2PwdHGACrPS5cs8oebUODfvUb7ue29CFWhuwb94oI75d4HDzWg MaFUgasOYQ2hsSYlC4ELnfj9f17dSQ2xvH26jsEpM99hkKw3xrGbaxXKa67HtY1fyDB519OdvPcm cuh4/nO+ZX/uCYFedOtMabCY+hA+E0WmewKLFv0M0bVWxR/4Kuge7arPruSe5H1+2gEvnYPPtDIV VjrFIg3yuZkwxbgNmDh4P3sa2d6mM921qlKitAYWjLheol6PrkekXDN0TGbhuSi59ht/7Z/Zempj kvxlMkJ33lfKwwTu+C/9u3/kI2fRRmaKdOQbH7YEYngybvAt0GtiydT4pyNyE0kpBpbaKW43uO2E Xk40ogJRsSiu4soFVs8XZeAbYHidZ3/cAfoqu0WzQjBnN7nCkisPswb5U1D1J/KSog+aFKWJbnR4 d7sT+nHwHM9RDIAfuGhqTx8RETr+HMVSHHSLSWQ0+/sZIHRpRZWnm+lP1KZbaOkU5W6Slr0MXIC9 oZCtiU6RH9AeHmA3nDnA3I+gFPe0l3ByqZsk4/BExKAHiPEVFmK4hF9gLWHu/dkJ3H7qIV2FosPB x58kdcWniiS/WQ50/GWLCX024xNAcZLvJGKgGNwpQvuOplpkrpJEGngfP3uK1u6KPbJBhOcDbmTX wXT0+Fqn8wnNZGyUIaPhnqG9fp+m3esOGPcoTozihb+Agm+JTg+2UbzSJRp675IrBrf3SMea9Tsl coBiZRPM/Bng4oGOBLUETmP6mBxlMIkc5RLKjhWmqTt10GFQEEMJ7gbPMM59HnOkpT6Ihj4zd53D A5YKorMdTLeoYjcuDdwLpR4DTcMVoZVNZEd5uQicjgUjulsgPnl+p7/3L8vJBoWoXkKh+wTMb9b1 NNXfDQSRA6/DSUVrjV4ffjtyTUVyG+ntjqin+l/42dc6JUG9BvcVPVudQh8PuZxeiVLbA8ufdKtP 4iRJ8tvLpJ0wKK5+kxKveN3QAzIdl/XYRSGr7s10/xUk8WxxTpMj6S7GhEiCE7zu989QDF6DbN1G 4vcG4oTPnaI+R0ByKInqgTqDayW9om3p6Dp7eMlrz74x5b6djA/JjIdGsFS75+96tEFYy3KJOSri cL6CPSsAyVu07cgttXt//4lxTwBeKwJzp0TVHnmHOUSdYvZCxhptiSA9LeKdAeH4IPjdlWMKgjTk Ws6E1MfQi+nE4tjrtav9hfLMWf9dXVvjX9Szdh34AsaGKpAH8FWefuQaRM9CWKe3AKecQ6RyP74d YrdrCt8i7K39umryq9FRe6QpgIbCAhJP8OE++jrhGr+hF0blrI21+z9Dv6oSZCpw0psAU2E+99oR 3MBeTo06QWtR3zjkTAZR0fqm4tKM411vywlVe4iI+2J2/TOS24rnT67qgz9b6L4jII2+HLl6eOnF xXOXVCS5WpDJDp/ft2b3nwN9WN8nQnLpFlbyP5u7z9fAADqJFZ4zUXwSIalpV5qDjr9ppEI39vIO qBh+pw95yO5xB/bbc69JB8m++3qveivGeD2n89Mm/CD9Yjl4+WhF9NFfgOjQve7bKesW2/y43oPn rY17+rrlBThZisx1DEu2my95bRqZmurV/6QoO53FjP7Yby22nEp94a+G2+iu6Sl7gIa7Kf1xwJW5 ndzTAMZAQKvd5rHH44y3vl11iizIAZrE/X/5y0k3OuJfXPeSznWUvrps4/I3Ee/g7d4BoJ20IMRz ttj0Snz9ThChwYQrpdCnkM9Q/8+ge+zkQBYldvIK2JgRY7dZ7wqHmPue95nEuIeftnhrm8mphBnb 8VHHSfJjXtZuoj6FhZcwwXU/93CcI214DrO4W/SSgovGcVg6PafFQYpTHWkOWzQ09R0d7o5hcvPY iu5UV0OKpUFkPXOl5VbvMmSSss+AxoqN9a9wv7pSFNmhNvuoLYjaKXczPLwSQ90LuxEwm26dy3AS 5/cgRGoCaJgv8a3oszyVNkL3aVqzlRg0Psc73J4aD0LbaQDljynPrqVcQqlnPfwfZvxf+8L92vd/ aSf+o/b852j/GgbCfdS5mXJzI9v6sMyco+fqE+OomoFvPepOzXyN1c3xzMjoyx+s3x6w+M1k8zBs i/QT0hEZUugrl9NT6ZKU24IajeOueZN5r3vo/b2CvO6fM0MxBNNC1B7xM3JHPhkcGPyL57X0Xm5X 7rSTo6pjDtMeA6svrGfajIwN+q5PM0urouPmUOIoJQIH1lNbe4XDC+vcb7sU/RN7L7ksHCdQp4Qw 1+bS+1H285W+ybX/PgV/7lx91jCaQUHyMkkATKNtLAYyrCF1Tq0L6zqOHMwF/YML0+x+Jobo1QZs zVNso9TXqGvrEFWKw4nam/USMbpgdgv/0eFxjW1ch89q91Q9IlTy7JrmdXsX9Idv+o2uG1JXYimf d28tLND6fI2Wcp0msHDNflJhTKBfTai2oVAP4Pfd3PiuYfh/D2DRyqR+q/WyKgf/rY8xYVbeHF2f QzN3Ahgbo+rk4RP3u7Bl0q9iXhJiPv/4U9yvhacWEkh5CSgEQTODDmU9LZ4P10fRSK3s5VhZUbya Inr+bljnRM9MxxfChNbpQHsdLkeBJRL3ZmN3EzcdH6kjEl3lR6TrYFli0yRUdqElcCHsFtLrcJO6 cXVFsL3TmXHxO64PNRTxTrFIBOPfLkkMQjGIbJxIhehB3cfT7coy8RyYHBQ2Xs9K9hb6CMA2nHf2 +65/iqRsYrLQpAlen7uBY7HYLcZzRW1uxypXEQAeRiV80gwHRTpByEvCmO/jBS1ecZYBEP9xTsnp qwW76wipfT7CjzCphQjG8PF0xPF8RxddZ5MPmu4rRWE6tUOC73fHWeqvSOYmXTMp4CXRdBBFKfjw cSpvQUY3Q5c75Ff50q5KXt/PRXrriN3Zt6aRKGqnTHJGof26IxKJkMrmfJ4m4+e9tGD0IFK4TUZq t5MY7knb9Q3tuRwOHO9H6FDrD5Jm6j78JgL6DPQR7XrlsdzOd++0LHvh+Pz5M3PG3AqdUsoxHp2m yet9PtyEnjhC541++FqeJFzeu7nC8ru0gPh2pLjC3w01yZc7JFHQ37HLWTdnE3JNLW8wvBuLN/lI 8f4k/iY+/KK6abyl2wMAYop/Bae6sKcIf0wJIX/Dye9DVN1uQQxeHu39ir/GoGld4Aa9z3YLOuUF ng9K7KuZHQDGgz4yDZIN3HfXXdXCFpXAhGHZDkA86vB6Dqpu6SJRm+yag3SDQWysbz2ZHMQxluFC RmC9GOzZQyItQO0IdMP5uutpwfBOB073rfuX1LNPErEJGBADejsxdOgjDz+8w/TkHnoRt+8whwvU nOkhaXJHEwJ2QiGNWDwRvd1254C7SO99kWKeP0RmuhXpxDycfTvSpi5AdTlsS+WqdMGZX7XIlwsX n+AtRqDV1XesPqnGcmlSQNDOAZoBD3G6LRLh2bInTlQAQZD20MJNuvkH63HTTic2BevXw1jBIhsM 50N+d0H/C/uTdzKTyWsgTpmScecemASImiAKps5IHwS8ho0YVMPF+16wA3DHt9H38l7XtzDJnuMM jx3nJE5UGE27UD4EhAkz3v15Gg2km9UPNqmPenMqxlxgZiJwI1sVXhgKcCfmj3Mt0zLmF3xyCzMF gy6edmwXDmQO1GVBCIWjkqedf3i05RIQTuA5aU7xklE+kv+eOtGND+dNn4OKA4PUV74J/49DItoY YKZQNO7NVCB5DregsW+nFl/owX8vyc/A2hlcJ1fC4lteZqIjDStqCcf6/pzDfbM+k2d+E57lvdEa Oi0MKqPDUwTxpl9cN8At123DnH7Wc5CJVy1A60doXAGU7CKP3/PgD86fSTydcLNNgtb6so+Kn8hO F6nedSJaUlR9TdmlA5xTJ8pdXIXxns9MlxKFHljVLJyi69S/fEMiG25M/86yuPhTxp9VvB/Ih9Vi gLx3/9TwdwLv3kvkadt4mU48mWsWhSi/pSRJ+Nu7q00Bz0BH7wND2hjCnfbSmYeaRjIefuPvoGAI UjxhNnfVPJTM0a6fPvnMo+Z604TjrrqGuZpDZff/vw742jUuCZgo4bKrE8+g6J+E7IQ7qe5kJWaF QVywRg4szWStoXYN3u+E8JrmXb7PgEaWipPVAJavIffqvNV/3mOnvW9jrm0+aBz5UWEznh6UNxj/ 6Lg382aa0lYYjBAc9XpqJbLaupALuFuV7u25R0NjEPsz3aOpNzaYTmYKwkC3+sOzqwaXC1P8l57P /94z/+27ruGk7Mck5N8r6d9P6A5J9HSYkLyuqK02uM5Nkv1emOoMD0Mbdtb+jH/2wDVoy4i8lsNw i1EffYYJx/PZG8/z89lMTsAzpeBVBzZuGHj204cPGFI0fl+sm490TN2skgKrJpadBoQ6fWrOjth4 v29HdNYWPX8/cPw1rKOjlzJZTH3jUW0O9oP77bONBkKMyQxjYvs4MXhq4JKZsHR1FzqWT7lkMzbS 9YNOCa0Bp75tcn7lzrzPzN1H/Yj2l/nMDAw2h/mA7wGpi499TWVoUG/SqC76+xwW6aT1Zj++qsLB gdK3znaYT0XFi/v+B0PYmk+hu/dPP8bMQaOTW3/ye4oGVZkC/H6wfhcZhrg1AKmZdGBv+xQSJKyl cVmYGldypBCRv8T9UykZzIOkkcLNP7OmwucQaw6h9nnlI1GFuajrnzu0aj6r2tQ6CIawqg8ADrEx FLJWocShRSoDgym4+2BAv1Q54CzvbZCoMhjYOu4rBc7TiQ7vp/jHD9hn2PquuF5/BL0NuO/ugowP fJXj9Avq3y3tBBG5Rd8ZwfREJT/Y57q8zJTib45c74GB0FeIYHRellMFzYAA/Tu+9ZqLuFxsszCk Qlgn0JDTJzM9ncli7Sv6/SgPpI8DjdeIz6vUMzzzuy5alcj3jRPzYDQPOBXiAewEaA0F2RdQeeyE +MeaOeIm2E3zdaGcp7FVAdxTV+S+lIxFiHE/+ZAnJXDYBbYO8KYhBkUppoPkb3crcu13gYyqSOG3 4PqKv5uPyECK8HsB32uWc5NgKmLMcdnkBJlh8puAtg4zuy9EWqi52lViLR8l/o/Dlgicm/5Ol7g9 2ov6NExH3g5K7bGVn9wc2iydRRO5NOc5vHaS2wGK7mljBsEWQdVwiHrfCgRQ6Vjz9nL3QIMPlzUh gbijgEl2A42+2XXyVz9jsd/VHPv5Q2Zzxtytu90zX8MHht1TIiO7qXmRQ8KEgzoTeJfouh2IbjCw zzydAGgJTAIMetMoKCAshcC38xmDdruG+xK2k+NEpOa4kzxIVLRWr7PbuCd35wRLNXec7a4FFtCO 571RxLqdMOfYt37EfgMNoAGs4Ro34xSrqTyCsNKPNV3f6IlesYNzpEFsV5qCLs/xWEMRd9UEf3qO dGcTJueoanGHE55g/OCKd1su8GYSd9fsx/CAerACBWbuWuQV/hP9zwNF6XrmADF9pOBA6o7ZL+VK Y/Cvca1FEkHjTt/DmEjF41H/QrwqAsEf16wYZKX7MsnWr5sth/P+/jypktJ8JpgNCgL8OH29JaOj ttlnezj0aPfyKgAd6qXACl6hiscfEOpAX9RukleEagoDuU9s8MnDUdQL7o+zoNNRfOxJn7DTdlUy 3Gs+avQ9RHCLxS5BxcwW1eujA9hun+xwdffOM7fnXwmeleApOc4L8QwicFM8MNjT9vtiAbPqjh0k pPKO2fjQGtiwy6k0Cc3E4aY6f3ZsSSHMtRYul3K2GCCnYeoo7jX45XmtGhl3EBA9cEuClj0E37Gk hv3YBKnrxkoRxr9EDM2QCP1OjJpyiv/zI7o+dhlXeAn+0km14+D/JjlWisfPWb3/e9aIRA65iDyF s/astZAR8s9K98SAvevvbkeg3vf2rsFJfkMnPbsm+cC/ntpE23HtrrCOXA2/uPjGw1zOsjodyrN+ UIhudt/iA6eaX+oTEnPwyX75A89VGw15EyqEi/MYxnR/fw87XyM9Dpdhco0mCxwWXXYHFTebAPOZ dkDbUcjk/BfulyTglJDI8uTQj69brZNmNIf0QUe0OlURBg7pe31s4cjMl7f1jRNE6nDVFCzkwZtf bK7SmF7X4IWzuHHtHyEyUf4+dqHA2J9w/3BN9KwUHhoo5pg6HURwr+tbfvXFN3led7k2foka/BwC zSj4u+q5EzBy/+Y9b1z+/+zKTgfIU8rnK8VKB9cZ5iyvIbMZ30KsBPiZn9QruiOE6dcvd7Z2iH2M kl5ppWlwdJgdefO2PShzV/Y+HEZ19B63MEK/IvbXwMgepmlRiae/X87P1NhaJCNvfCyGAh2p6LHn rqGXOTpeGj97/6AqG/fMcccNogMH8RLv6qjJDd3UlfpxD2u+TsKM1RiTZ7vXCAd4JU/46kKmMLV8 ZCmYfFehPjwm971Eovo4M2Ow5M+a9KNT0TMkmp7nqJv4vOW3dmaCW/hyg3bdKXtASNiTzmEsttQB s3WUj2ZIwc1r/r8z8z/Q6P/d33DX93/OgR8seGbG/zLP/Ps41bWxDn3cRoae7B42u+7bPi1cnNTW P7DcC7BGsUlKWTOa+n7P3jDvINIANpxcy0AtbTDLuGqlS+A3c+l0ts5ru06PW+SZ3MbCD52Y2pWy mILgmd8NSlnM387HhPumCSLhtV+DJZfAfz5M5d66Vucd1nLvTkn+uXe9+gJKrhtIoHpNPjiViept 47vj8Wwf+M7+dNs1fmY+kobnTOb0XIOreNrYxV1PJGlp0T23SHYZfHhOHY4XD0l3gUqMzZivivPx 9MDgOt/WInakOBLzGlWErwwqA97/GsDyzySdyDqLNIixrpuukoyN6QZpjOGz/3NxoIUzRvYk90Rz 8ut9b/lIZNiJN4I81MtwaNckilqr6yb/go9NlxM8MOgNxXjI/pe0nbPM+Fp3xrX4NlbWXEkjv2ss VPVYp7XvZ7n3zZXw82AJpRGBVEzksr/tJfXR87uSOG7P9jSjVDRymWJ+jLdA1yFU3CU2opl/4ej+ TA9tB+02nb9Ldw/5myZAUpFD+i2eV3hNc4wGUKbiAz3/Nx2d1rS7N/lF8UP6CpzU4ERDCvHIsysj 25L4uCF4xWf+dppAKFchdED3taZZtvOKT8BAZ0vlujSzkJjYZHjV+ZrGvcEEnfB4Nhjgam6adJ/B +W01af8TVUeXr4vEawBXQKhpD3scE0fV7Jon0fI751AMTRR1g+sgMrQ+a7ore8gp7YLHtwBlithp N2ujT09GQB4gxVM0JencCQm50r9c8XchODA9OEcsyhzBeeuTP82B1E7oKW75/89JpolGHxSasAT5 FrUcMMCkQ8E3NE/ndeeLGMYIGp70L+erDuJNH4XElCitMwq6KNpx3zNb2E1Om5r5lHXkfrqo0HRP m9PZpdaSmsD7irFa3qHqAs+f7upeQu/7d7pAwf0M9MtN8s/IAbqOWIIWTCUZINm2CC8dSsitdA5w hWFCIwhHxBzd11xM+5cnR3Tw5dx6kOIgHhQAFyW0pv2p+YCZXgcEX/D8AzQLhia64J/ZA37paLqe j4kcTKKi90g71BtPpRUEHcN+2wF46jytCEK9IsiOh5RuUqnrfX1IQChgPJyZENBQCVJ2vX0nrKhc r6YBRVrzYgKsxVjPM0rC53M4d4u89JJ+KDnYT2yvr+c/aYpE4F2s6HAMQ7Lk0OwmUeaLOPfkcHDf mnQP6+wD/JCKb093yZj72fW/80EIJ8DwVtYK4dJNwbqq8x+C7kqWiTpbiv7V5w3AiUOq02OK3Jwa ir0dF/qdbIz1Ie9F+Q7GnqfBfZ102cAQZicqqIS8NoF+4WTrDVq5XPQ2sPquCYHwQjVgFGvH6QBy nRm8ZiV2pKtnrKNa0hx3dfdw5FLzvrsUjXflucVYKcKdcO0gTxD/kvSmM4nwAnb1uXc3asA9x+Dd wkmENfQrnTVspnJx6gLUunoSFj5qmrvrekRgz/JUAcfbOZbiiqlGyrphx8TrPA2zPxdhO69YwhkV Sy5z7H3tYTOAH3JncIj6PRc1XzkynDKmEHcqfnfhCm6s0XBmt1PX0f2YV4gKp2mnKKHZRBoCpPgm 0qBMrr/7rCsMw3FymvdQu8QT3pEkfLxpCZI5tYc2AxM1RJo3ObfFR5k2eKGjjbXvnfMXK3YbzvT3 NdTtArL0clZ04ZGdGnudntw3GAUOOtKodJJdmsOgpVxNH2FB3qymgcL5QLR0nOVCoq1x4CCQPBEb PDN4FnJn1OL1vW767naIp9ik590rmilXvCna2IiXdt/UWBH1lVtI9PJo7eRZo8Me+DPtEkn5C+2Y Tw6tVAVdWQU75pqSYlWk5ZftkAPfCITBtyWIoK9O90adnaB3VLq6b04Clh2Rp7g2n6gUo6UTtaTR SKFFRi2HGDwbb0yDKh4FlvcVye7ZxhVtSvLWNkbXWqo1Z+Zw9W8M4Er2ZTHSn/es527/208d56TC KOJvjRXDnQY5I9XuJrxYg8lacwwVXahrdaEi0YUr65BSYupt+ytJzwerr0lDr9ukKZEIncMdfYO6 aqi/vZN3Xf53DYhSzYIn0axBuTQJEeKN27Wb7VlcUty3/+mBtd6HjT+odATjOc73TD9vDsh437WJ EhpDeWAwYM67GQ38nv9788QehmG0n0NhtvolnYfM03ZCklAn8nJGO4lYq4+g5Bkd3JnLod1PWtR2 SP0NrZuhwTZ/YDlY+4nMekDbMSxIjLP9/zgz/zUy63sx6IVN7D7t3z0z/+nv/qPRmb3+WT61TXnS LODtq7IHjR46zMQ4o+lCfhXYCCNOWrjmtV+O7sx9JpXgUVfSyJVyo9IU3Lg/4YtvPw6DuKWLaZfo ZXSj3Wu1+c3G91r4S6mOguHVbQojzOBSaSYmBrS96hTDaF9WSJFGUk7+jMm5hvUama7aRUet4Y3T G6qNti/wk+J16y3I8IQk9YrkiG14odPY6MU5Xbqf27SsWQzPTpy70Or5a+BESboKvpP7mRnKeHkx 97xNhPqgAQ4gOeAf5/02wL2wuz73d42vVff74J136umV9DbD49D+VTHQhrPPbzarHjXE87LI2KfF qD6wBYH1797Xwt+pX057IU+W+je+p4x4VRoLKsyQjIOsF7JGBnhRG4jOqTTCgeQ3z8GZvIOR+1kk RuoQY4/myHZQ8XNdA/uv0ce3gYaDI3kM4BBZ4NSYN0E7f1an4IExkskaW+f9P5G0lz1DrrG3Hq57 /ANbVmBhFxup0ts20vyPWTGluO4AMElAejtMtpj7d2iYw01mOYXSgpJocoicsb+gAzeJ/hTuGZVX 7pnqAzbB2xucE15v17X37tt00TQeLu1QlQepf/lsORmewn8GGmFSzwma8GzxiuF+CMkfAkYonQt/ hb8HgCDii51rrylImtYFFzVd6y/vACHxsA/z250tRVPbVQWEWygU4tj3v42sLkD3XpkCvy6BuOTv loHOTHqbLxUol4WO5nJiTke0gLDsZ/qSGn9hDeUAX4UE+36f7Sq8C0ImmTrCbjD+lx1omhCeukzP WeEUWoGDkL8gjhCUoCzXMGV2UAfbSdMhTu6iUCfddsXa0E+j5v0WOQuBa5+OPjrPmG/iLgWDL+lF cebpXGQnNGZcLX6AXR1xrHpisg1kzHYj8Jqip9Ot3QlzKvJ2YHgdeauhc1OzObjkFUlP4EG7VvId 1sNAF4xPB8wraJklss29YoTE2vHzlqernMHTe87Q7H9706s+U4rAryJ6UABBaRhUe77O7h1pzJ74 rwjMSHUbKP14236dhYV3++UPKIiyb1E3OzDVKaf5drlV3sM0PKa7CTW5S0X9UlU8JSl4tvjOw4kl nnbk5TQJ/sad5FBuIEtIc50riR4I5SMZMT6R5TMFSjkcK1lMWd2BH9GNOAGo3WGnvk86uqewpdar +E789nb7qh4FYg5yQWkBjVAIcgGcLihqC69mMiqed/4s0Lt9V3UKB253nAQVvAawXocYgaBF0wHd c4KKfT+9NTGnG7nq7++MEn14gu1nSERdExxNEb2gbe03G+pBSkTJKN3883dUZMLfOn7H6+61Abyn hq4F7gArdQpV8h60k7gn8eArPpmTTF6uf04QiwQ5OpCOizi76gkW67AQZgtcfu7iWY7FpntKmU3o EItOkDQdmd3ioq9aT4zi4FB71l0q1/mu0jyXK/ErzEG43pdMI0XsRN60Q9m7htvdjgkKrT7eK3Xx IsgTe7nvpCuM2DGg4096mlOrZgladhy24q5tbEjlwe1VZ3G/SY5ytxOfAh27f16KTPRJWNN304lz 3hWB6ly/R2eERJQPUqgx3xTs/cQYC4a12jusdv4yAlH04l/UfxoVPHWHN/FxDeBQSk4T7fuR67Pf 8pFkqiIzBuq1a8f9JXWVqOjdmzjPHSSb/E+vq5/zPAmW++zWBx6/h4svMqhpW6PsZJ91C+sLbCOH Kw2JPL0n2ZjnPUMU+ErWe39Ew0IqlqWJLWwfJCy/ziEcOgFsaw9RaA7JIWMonpkPfqjrJx88yhSJ PwdmopkylkqRuqEv74EAQeXdtUzeXzrPx8RbmnLe4iz9klT6rA8/d6S6KvxytkT+6xDJfHmyXinQ mcrUog8dg5SC/C6ViHHcVH+ieB0woOmEVBPycIhbjH22kCe4UhDaWTRrGwFm19hQj24ImN/BU/OD jzmZKK/49R+HTQMXRQ55jFB7OARA0KvOeRPR71eYV83R888R3M4nxVRaSlu1LfONZ6jD1eFcKOZr oKAPqYsDP4BeE841Th9z7ZefgZVjuEFTyIkD/6N983ISr9DMZrGUMD2lU4jyhNVR3WLXoHT/d0GU hWSozYfYqVWYWvnzGC7LK3IEZemWP9m7PQDQayWejTtJcc4ejnqogfPz8q0PH2O9/Hq8T10DIoO8 wGIO1Pv773/2HALWWSmbf7Awf2COxLGpTDS8eBiT6PDtXX5W8v9pZv77ZDbxJjsJ9Db/4mf/hzX6 zyA/XRzSHu79a6QzPPT9gxtxje/AZq5+NpPuKoEXs93UTI85ofHFtdL0gplqwQ7hZATNwH7vvZY7 8+cuzdTV/fzqv8NObxOA3mWZ9pQ914ttkRlD6rtUnEALY7OGfofnvIwfvjAS4vdZHP0aJOTt3/eY Zg6vd0cfv1PKyXJNYFgAhnIhJC/01sCrz2sOxOldm3+/euowzdIX9iAY7iPNBXUKR2/li+3wXINT b+21BhzKSfwaOnWfadEL9Q73iULnF3h1T+/QiCDBozijw9Ofe+ZQD9j3qnXWDY2DvOdgnjNenJ7q 8xeDIv1THQV3j8mzeNg4gFJiu/Zok9TsK43Zevl+HPeAy8R2oNbsdZxVuDADdULJoOJ8OCOcTt6j P4fBbq+kxN07k52hi/NmfOlNQNSZfPz7/+xB+znwwXxHUzhudmr6cO7/uzZ8YbFXGtdOWvXMpyEE 5d4Ovv9XR3Bp5Qyr4Dbz0C81/R99mQ8u+x+bxCJSJ4sMnUDeV5AzzX1c7kWrWDOB4HuCbCKm833f PuhipsEaZBNK8nN+QSBaUMkIe0IwPw8XWwmqKgHwJarqsJEBqvor7NynwPlH0JXxTO3O3UX+C5b7 KNL+LMNXPCxwu7wcZTli1+Hg++WlQE8kXYJarHmFcy3HBJH3fBd+/iA3G1btElYAuKqagcu74Uuk yc6twmOI42V5+r7BY8G32mRLi9m5Sdt7xUFMvxPqW/T+OnQEUJ+km6i9cgDd1NBzZCQ5UH65YMw/ E1yKMZH7XPPQ0FEWbvtsYlKaY9V9ileeFeN5CMlDKC8m3FKEHJ6E0Da/7joTUdFG4UC7vimm+kHE NAysuIqOIJ58OS2DE2jcqiyiFMR/5sT5D0HwA+z6uOGfoi4d5AzO1BrYr++ebQKg4G5PxJdfEg+X cIMTWao3nXug4QfU1Ed82Y5vvoVI7SEcLrfKO4HC7TbAOXONMcxK0yntGIh6SqTtOYjX/H0Abavj Xq9snH2uCgUxX85kdXeKAG5IB6gatyGSDaz97BESKpez75D8ff/p91ze8fNejUMDflOgxD7jNDQm NkhEtps4icL45Ne5N8oJB2rLBDt0gF/0Obc7qE7P63bTD9moGDwynOcZp7Z2gAOUgRSonwQbHc8k 6iPNfOUO0bOt6L7ZkdV5S+c57blcBuYks25AOd63CaBX1CgJCL412wX+DAowWlgQ1YUOKaA7JlnQ 0foU3V0e7F6OKO8A23Z38VxOMkkP+NMZf2owe9WE/oqy0wxEs3L0/OX8tQVbBdmbBm88h5f8/vf6 AmS+I0d5BfGTvIb+cKQirDDXHaxLYEuYiIHe+BbtLvd22A82OSnvdf0zLJ49jCoFrGUZ3UUPeoYK UCEdf3fXVGsoXu8ePfpxMHZIY4ZXYGjsSbsKKdL3GKhdfYa2KPCtxtsNZGYwShNDyMdBW18ub1sA kqLBGBOQPs6x9w5sYVSLszqtjtCpJWjRL+5hYikt7TAfNYvjeV1DmJomHK+sK31K77VEuPmMeTdd OMuUGJ8cJDPCWyeZM0DaJD5C4Llhn9z4kh6Xt0Z0dDhUhfs1uo+LbDQ2jqUm2b7eFqVmQjzZDHps JebzJKeK0oxe448zL7TTGOt86J/7np86yPrCTJaL6gDum/uzBxEUw+dNjcEdZnqiM5fXu00V2I/L tH5JssiBqW8q1AeK3s79enptkkdzbcJWQOzly4TWihZ21zp7QPDnz1E91VXv9bu3wzILCi4Bq87q geQLf/bOK6SkFJB8niqMQYx1mUZq91n1Ixy4nUS/BUiJuzTZyngk9+HNfMzQkLU+hjl9YGAk0L9w lTdZsGl19TDK3D7VjCfMwRvMDPBhU8xlGhfNUS0cdYc5V3hxd2JX3z41SPCmo5c11BAzd3Q7R9Pr w4jDh6EAJjnbgFnx3tVnH3bjeP7qj9xn5l/OTTuNkO6mVywnTWH6+nj23N/noNztbJxYxlQNf5mD dEKlJwdWjKuOREMvx0Y5C8Z3k+YXg/27p40gOuVqwLDLM5XO0jjom7pzD2QBcysW4iRfVtifujr8 4u16vaTz4s/AgCCJ3VBPb1MhTiRivKgNgbgG2Uk/+jgPtynNLXa/9AeCJJx2IIV/FgOqrqEiMkGc MHwiltoh2OH73L5Qx69hHhY2Z++Tu/rvgLfu7uQvdqjoTb1ZGp/rwSXje/tuVWLMw3//iFD/vzP6 H87of9l7yWu9MIatf5lm/t3cazAfuk25eu8Zbn265V0QOxkW8B19ieocQstaJbrwne2i3zs0sXID q6TzPOs8vT1kiSiqNldLCaAz2835ToPP9CRySY8bT0L1jeI5/pgizOcebLPLGXapDx2S5uyN8pzr tDgeyNnPdoa72CtrMmuIdOM21i2L47ejNiHuDe4YvQJUl0lLmqXc2LtQGP89Ev2VJdZ/xiaunPjb rlkcvPj7XtvPW2CRoLlS3wZ6wc2HsCEhJfch+6XoiR5NhOss7a5zcz8zPLDoQzvYWHOanv7ZW2pL qmcArA0fXy63ecudqsvstKHn6AHr3AfGATZXP6LT99vIJ7z6qsPaErh+LR3C1U/lYBanLms7aXvr kOqEM2NizTnzwL/LcJjqTzBj+WTwZq7TuT8Nj79s8ywdXQAzO+vZzVSNfaVCadoQSFRzAg6oeQcI B5Bnct+fSlifSp1iNmKbbBne/waW32HQ1dNE+tTf7+CdQPAmg+RZ+JPG9p7N+yz4x1TDsMmotQBE YPiOdjGo+F+HLdUl3AtbdUADqeSBi3zWwdmNnuIQDH8s0yFJ0Xk6SsbXLdNI1/eBfxVbAwAtyQRZ FDDTglUWBt90Q8cKUxORnZ4LiNBH9Ci5ranifuliEm+uYX/onynHWYTfRRW3oENInX7R+q+oRADp NCEkeLYJMJIw9RYiZezcC/qJ3rm3UMwhJnAQjcILqYczknD5Z4HQLjR6opBDpK7L4cNlBMjSt5Fz OCW79oKKnHsHQ9a54pk5HEUGVxfF0qf0IybGDJOZc8VB+6T0pHcakAC7PKEdzaaCyGgnqj8TWT+R sxN/zwVs1RNT0ecABww2fj7+OcWif82cKQSJRbh5jhQAaJVEImCzuMOzSGeahq8BMXCq2qKWHbm1 CaUmAfeaEbjc61jzt4BrMrJMc4DY8bNNcJNrFbxNh/01txqCwBLuADCmQYEU32dN+LFQYIKA5Qhf jsganA7fcUczFwQgcA3P4neJ4twnf4sjetiiR4b6vQmFNMI4P33A7juSbickOFZJ+XBL2DJcZFwJ RKOh57u83cU1E66b2g2q5q+A2ijpEqRpkJ/adT78vHt+DzMklh8kZsjJA9xk0T124mzj501ijO2i +ZtLAUW7D6z4cI+XQJC097Y06Gxv3Dk/n/cSIWBCkUloIfSB0AGYFajlQTDicjmgf67lSo8+YeWc VjBFOVX5rK919j3Z/+yGf7nzOr0/9CEQwFEF6DNI0NKVkj8TZlzAsGbAvX6LULOu+xnm9HFjeQHX Ew5jVZd+pJtg/Kd0CFv4fmI/yC3sYdEwheDxyLPOW3sTSALRg1YUoWGgds7nzPc+gW1JDHQ88UAP cZFyTNzq6Lp7gOlnuHs76BK53aOy+7ZmkXaSsO+9MNMep+GRrjnEPJ30poHe7ZRRTBDMMNg013BS 3vUzNPyWJMjl9jEl+lMMw0zdlSxu1FGndoJV1haay2WLxQCu90juWA4AmSKOb296GJ+v4Yd8I8ZK MvCJ2nc6SDlyYTWQ3YQC+HyK35YNdH/8uJpzza+6iQSYRJ9XPv4UyIBsJFCF9d0WSF8DLZeT8jtQ WPXmmV74Ndj3PEPEIMEJ0nBW6xZ+7jtxat3bg7UQY630/Jmw7wSsHr4r/KEMFQznCA9mXa4/JIBo dDYliJRIoEeQqkNosGG5dNZkvEnBJbQYski/MKchUTalMF7OsJl66vO5O0RLE+KCONH0dbZQUlyY EJnrVZ0pJ3TPZMpJ3NXexOfGDVsoSfY/OkZHpngvYl5+BA+vEOAlRz1GXo3sAPrcSgOkJqVdSQya 9sG+99c2yph6Zr+e557gLlpIqVX7kGupoSoXsFs6K1EyVjIS69G1e2Ad5p8S5rMZzTaEZ8A7QINY IdYq+xy9MNv3/HfJCLYBS3v1k5hdK2FkIOyeuEd/jrcO9GcqfOgehPkyMhI4NDpSTF7+a8ppUQtr Ipxf+ySW4r7T4bCpM5Fcaf4h7rUc/cMg77jTgDxgGPFyeWq+yoejdZ5BXph5p2gMJIroHDRP2Ylg 4GaWoGJxmhKiOT0KZ3D53Pv7NmI6xk2UEhDBnk5M29gP/PRfc+K1jU5GsjSY9BntzibqiI2zbb7H hZeSEdCbUGIzd8ZukXw//ZyVBmSNB7wUfFg7OT8VowQnsIpf71o1zkhIBKS66UsYV2Y7MLhDWWDb 8fWy7/vp618Bc9/pKpybdSKu4RrVc/H/xeP/avJSe+9o9rDveqf/5pn5z6Tw+0doHIn2y8PLx1Aj r7McqujbOJ/yXqMt/O/hJLbruGw0Os3WlDJzoBPriT13FKXJ57MkHqX0XS+v4iHEt4YNHJh+1vKU GH8z7FN7petJnWmV3QvTQBP7d9/IsbAKpWGczmK8+tDNS+a/O/EtUSrzpZka7AM3J3zVqp3g3LxQ 8pbCStKhT0idQY80DPKMf8SVzJ/vgbg90Ef5qYIk5n03vYnKAu55O7IP6JEorT2G7TSYKXKNiM4H 6+1KCZxI1fhKl2qNkVYt2HqXjQvleQuMh19ncoNmxJWYIWAXSUieXEf3/kK1yNbzQKJM7NfE4lJD t7A+G7hH2m/+0GSAZsI5mHvVnnTmNp+Rw6DrLSu1KP6F15l17tdIn3O41pgYgTW5L3WWEYVSIQK9 F7vPmwO3c6ORms/so69eoYcuO0uBuVWfo1v07/fzbq3Yy98JU9q2ESeZZBqSSf8+f/V7TF5CwPOt OwfO1jTZ/cd8BKAzidbUPUXdrqJR+bO0RE81D3DEBq1XLfo73VSm2+N7EBQpJI4pbuqIXaP0C2CP pZKpPLpcP3S42Rm3HxfEB6HhK8ZKQWQTxSsMm6OCU4cQs1tZfzqHUvQmiUE87Q4950VFreMl0L9l vrnhiba8LqC+OBW1I1+tBTHae8Lz3aMmUe8PEfOzXzOutCPyBp0H2jn7p5m9I4/p8NYDKFxuOeSU zt7H+83tM4MAfzhY/Tph6SRZVyMPbjl/nikP1HCApQ6AjAiC10lmEthROk0phlM6CeIHyOI4waGG RCo5gKIp8DsoI9rbJMJP9+9+B8Z9RmAHNU8UbT2/gCaewUYiYFZtYJ7nwXkgqWVvzxkTgskrntsH 6N7Onj7cb6/GmiORr7K0E0YcwFDcTRBZ5hBFrEZOAlqS4FKtqcDdgF5egl9Buin8FgKXTV4CaHsQ xC5w+XIVaIGjPtzADPBbkn6/BZVtF8F9xv0MK1C9yQ6WuwVkMVy7kpHTt0Yn6GWUoK/7xCWPqWfu ioWcc56bxIt7iJPns3uYjKGgnwlXJl3TxUdIANHglSpu1wF700DelbSynrRZdP93OKjuzwPu1dQO Hxi2/PuMlMSqhxyY5wSqw4HIV7NNTkxc5SucCF/wIgVHnsttwOt5XE3/HCdjCylegbq+pEKf9+2V ApAdhg4Xgk18GioGQ30tBAUuEuN1L2LXPx2+k8LA74ZnjUBq9xPCU5ZE7oNAmQC4zISAGR4OGLz5 chCxHcbSCesSv119z00xOIBT6tMr9k9cr/mxddFnrXjVh/enFwHk8WMh82y/JTOZAr4T8N1BMOYW bO+ULMY9rv3sqxv+c556hgZddWAQM+2TLkAOXCk/XsCr4e/QSEOHYuYQ1swWfFH/Di4wvpzsfPQV X+SbgLDfYgzD/uqhxH2+C12fjwHwuTymVETFuzfb88JYs3S4dQ8j5N1/gfg+8/Daya3P9Yt6vgHu Jnh8EKI86DUVva0Dh2shjX8ht4jIXnC1iGzK99S0Redy6kAhMTi+EotwyFJkMmGIuqa6Ig0COlFs k2EpnKUBz2vkqZEmF8bGQzlMUhwOiAvPeYVWfbkYiDxX7Z7GDg+uJf1yzwlSGekMuepDDYm3CT82 nADXz2zMQ8GDGUl7wSBk8xLZ8/QdpXOIn2oZFrzttTk4Co2fQQO5FD6r8nT5rifjq5rJoXIhN6G4 gHwMQBuJNU8OpyrWdtdR+ni+u8vYw52bhPsZIu5+r3dr3h2RFpGk4jH0zbHMNCjRMr+vhNgbYUwB FAv+oVuYikXHpAjBwBknlQ4aRuijjySZWBCwniJkXeQopNWiwNgx5OVyce2hI+7J3j1K7v8Kp2+H RGwbRaRQZupzJsb/viMXRrxrlL+fVfPJD/vBW3WkDWYFqgM5rFTUz/Mq8cKusd4agip3Q3/RdgW7 /i/nfkiLvLMnffZPN6rMqa6vmYiG0uZiYMfX8JZXH/iKbzyvmGkGDQNeXP7BLW8DEBX/bUgUpeHi vFO2wIISv/ue78FbA657mXXke9x1kCuVcrCH23uQdBT+0ARQiuGura/7i8aef5JJhb3QOhvUolV6 5tJteDFHWkB1XCVq9l7rJawMflvNl1w4OluMMKe+9qK+fqbrMxk72jiXzcns71vzB7s5kJUrpSkd 42RUlxoluUKh74O3/R9n5r85Q/kveTZ6uX//i3X0756Z//id3haYuAQGhcT3Z5/A/Eb+d7K3o1SH t3/2+ZaM9hWKYQbGnx5BaN0bhvomnVVDeO7QuPgHVzcaAO4BzkvbkzhbOc/mu9GVgMS8Ail/rpQY dq3fg2Nkoljckeme7yENhTnc6TPuNPvwSllRcS/GrB66+1JcbKyAXJm78yvG6MLOa/C3tGJ7KG4b bfjERI2Y58VNGNAILZ3P+yyMPMPdN5YFhgT2RHcKJBtKcdLejybS71w8clONkVM9DbYfznul0xT5 bJnqI0hZ0Z9FwcG0tk2zRdWrEvQeQHzx/vlFsfNjoglpikeP1Om5uzYk7LnVXCH6htKehqSx+jAZ Sgqw5RdzFxr+Nj/sTzxtPtgZFXeQO8I1IJn4ZWEhenGYt2fxLzyUV6pTGvXsIXMPJytd5+XWstxJ j5yaelnfGO8l1oimSQD1F51cNTdX5Tnx2k676GzSgTRnHXhtW84+dYKhFxNrdLoXcovkD1XIP/am vAQKd3RCEQC6XbvJkXhP4uskCOv6DCKh49jjQnmbXLUE6RLiDCyzPIAzwOSO+GhL/XbO/Yr8yiZB h+jBv4KVu4gJJ1P7kN/R8m2S8gbzqZRvkRgLC9mNTEfT0BeRwD05HQ2ojCL4iyfQs410REdkk5du 6Wuynyh+qQByY332PGdBOacBgtIH4J2uFcJmMj2Ea/Xrghz7zxEJrZi/GhRD9Kp4m7ZMJtiAzt1m reJFsybpfggxXheqIZArtpf2sH9t3t8G+47LnSeOmcEMEeiZhA782ZcU1AXkuEPTigSGGMUrrvJK DsmnvoRw7kaQhxxUe3e5PtvHXOcuIhYM7ywTfJAtx2S4KcRVx/fpIB0ixurWFcg0joGzjrcxZiaw bM3TU70+GndVQ0AA4Yu5p9v8LVzps8fwOVK46HC+ycGcS+i2haGXlzuRNrDvnWkSBPhecd8uYoyl zBvAv+5x8rjsm1lATCSxR1Vn145Gr6grGlMHGdyk3Q8Y4nLg6Lt3P79LWHQ99Zv4SfFp13GCWjqd HRviI3dMg9y33wDVKDSMesflGsFcSlX5cZ3Zzypduzcw2f6rqswCqk91kA6ewbjcog8AIFP0F9cE PdMSDRO4nIIHXN442loxXBa1jH3enPz5Uty2e7/uMgRE7+VINXAf85jR2nsSpvhovhIqHLW6Poho Vz9hrFvZZe/LIUInuZJr9hJ/+KACLjBkSlTicCmZo8ZQkENG0Uq7N7/pPE0iHI56n6uRSG5XlK4B ou1K4DnTUQiv80zoXoq81WOtmJMnuqdNTANqL/fv/Evi2Z/n6+0OSuDfJbjoWwlT75RvxSWY3Z9p UG4w4WpVg2bqNeQjCW2OLh466mlR8bXXDzKo6paIfXanF1HqC/dt15rd8eO8n28AnMM52y2FKuu/ 71KCvu82ishRSoOcPElUm2kqLcFN77FeG0SWsKiZ6+DbsoFAc184aIiSepD7vqeuSNh8V9t9t9/J Si5JpMpdrSY+lgMtJDJoKYYPkYLBfAL6WF3OyVq90VfS0xyiTSZA22kGn4XIGzAcq3ycrxo8a3f9 EqegNql8IQs+Uuz28AHVTvroVWfhbRdOJRBlbAzvdmnO/ZHn5hu1biDxKofRnk8BvVIME0LQR3DU srR0+dW08UlzKTM9vM1GAT5qbu4k9MsawL0jcoS97W56aKH7WH+EypN5BxsUCZMePe2inumjtF4L +xedX3kb0zl3IdRt7MF3gIYGQPp4z2QwY/1PPFWJJdS1G6WgUS7mK4zgwcR+DjcRa3jfLeykMwER d6luZMFZ/A7U8fijPphA12AHY2Dt5ej6Oaq+dvAUUAxzGrjMnR5K3CELznQILiildmMPWkYFes7O dPfPAVcWErcIPV+9P85HVb93IUW/YwBCe5aB0+86S1VOfZ4tzCKXvCt7uwcJ3nptpwVvcW4LjYjl +sFU/CQyCRKkUVah+ehPPJRWsY0m+ixNHC9xWH2OkfWQyp96zTB076Ni0rQYMs/Vt+7iwZjumL/R mi8TrRmWKRuFaI2XR60orvEoF0RQsw/aUP0zgx+LCS+epbgtzWHOwvb7Rw7utGUEGWJQasQc+L5o 1PyjVRektu8hg3ed33h68+9/zuAlivLrvDoxHAVenq/+w9kXz8IkwKbNM/rfjud/7cU3Dj73P7X8 8/M1M/+2Gf1rjQPiDw4kzZx8+hQm2Omfc+A4qcnYXOy1ThRcZPOAOjoprcFWQR2cv6NTkBtf99xG IC5xomPt0R0svH+vJAEWpHVa3C0IJ8f3ORJLG/+i+0DwPaS8TdxJeuJzeQ34rcE/6txnGQdCwwl7 0Osp2WQrehibibjhu1egxFyvz5JO0qQ3EeAwO+F88w7Mh1/pOPcQvQ4DBnAHhrtQ0aMk3uxTGNxW Kq/u6K+5G34PNhT7cZt/UzZ1/u59DvfQRhkq6TIw0dpPwrrIhSus+j0GbymtwZ5P3EepARLdw/c6 yM8hNcej21cexp3JOG8LuSkvK9OP+ATb5+biGv1zPlVybYmq9cKA82oJacgCs2lNOcIeMrnbfZyK v11ogaZwN7KnXasEZgN+cD/NncGcxgk/ph6UBbHNeVxmSpVTZTIscd3jbZrh4LP+WXtK93D1gzF3 WpvnTr7z7JSi1uR69RcqjUzhO+KUhMs670pkZ8PfC5PxR5YNn/L/6EunF5ExTnFv5CY8vtw1LjBr FxU+Jkb9FGWOgpxt/3dcEhVde0qDI78MZMYSQ8VEtQOY/Ck+JuLUw+23tiO5PA2KJNrpboajz11F 6wukXeS9DhJjXYyegzDdBb/hqbr4nitWSABAA5hbdDw5rO2DsAGUR+jrngh9N2xHvgnGJKacttdB qQYBfoBEg3+kHoBqhlwXhYMTG7S+2r50dL8cCAdFTYp4nJmeejJCEHcoV1OhJzijFFoSGN3riSPJ GhTZ7qrt4LFF9uCY6YSGjpgpswvNO7yjU1z3A/BtRzRFE9PFyivQaSHPU4hV8zpF3FL2Qnq5vgLV PT6xhXOKyMB3GOMv2amJZsd1zzlAwj9/940aX2I6tb8dt5AKV1OK5WxXc1UZrmhMjHuaSngVAPcl 0gFgBpt1lzB8O794ODTZIGPyQV3RuQCAysOnboBPK8ZM5drRKQsF54rvyx+g/CG4PMcNGYCYsznm aNgvodluAh7yUFOCvyRFeML79lq4UxOEq+7na95ihz/n3eve/a4zn7WFlsDgNvhLUf0lJp2zPswz px1d2umJCXGiWK/aONeBg7QbAAMyNYdcEVL23a483Ra4gMBqgTUoKhgUCOT+oGE9Y7WHYn+R261m DlcUPWDdBTpku0dDeVUXHaBhC2o6kszYS8Xe8mAz+vYPOqebB52c3jPkIp84IPFr0POqH3VQkCpC msJBdcpz5rPH9Bm5OTNFRjyAHYhJhdLrFIFkP8Bk2p0ocYFRV7oC/3am9LM+mgLjkjDPe5jFiArQ WjXMtcYVMLryEip01PPb1zrJ/rhThb3rrlnnFOdkfcISyRczuMRyayRJqneRDiIuUInPphHfd8zi qcF/094ON5nzNJlVR9/mjZ75CF7/Sld5QTX7JtYMtXLFOw4NF+tDoDVYg94UqUMQwbHoTRxG4pW5 Jv9xayRSZ8fmtjith1TuIU8eUEvnVnvq3r6EAq9ohvbd6gYvMd7QYJs+RMn/4ve6h5T/3qfe534m 06zf5TlImK5b9FFj+mH6dOyXv+vmFCXt+5/cNomQ0IHrXVI+x/2jSUHV1/8cCS66/jT3exT5XpEY MRShsxdoiePM5fi4sV9hLUrDEob/TcRPqydtFo/cBmEMWTqxK2GuZZ8/jCHzaqaq6nqH0oXdXZ+I 3OvzM1xJqV2Bp+v95Qb0cgGJHTVKc2Elu/L4caESmBnooz4duLXm7DcuRK6Mhzyc3BGx0C1Wpby7 Qaz38PVr84zZjrM6DU9+8AGHUxolwenvmZoDXlzfpsjkj6u5ngHCF9cynEE+hn39Ibaas6MROgyu +ulIXbp6kxIviMS2fWfwKZ4Dwlx9uSS/Onr/6MuhN6h+VHRWXA6scwpCenDGxwlOyVYu8t9Bio8v CcXlaOpD6DD4/FzDnINjYX/NqkQ1RA7UMccr+Kn54zildtAgJQcj31qEBjJ13OOeK/txflm/MxOc jj4GqdlUR5gE3ki+6o7jJCUjZntVUp08PkODGT8cjw93vLvvzrP6j5Ahh/6FI6wqbJ64NpMtkq8K AwYXowcy3sb0+6hOotEFx99RTBS+nKsPLDwTS/RRSaks6d7+hccWc8Wl6QTbCxq5RxZuzzFcrENC s+uO7st2/7RFQenY1jWuMU0z70YhB8PpnN+489fYJa26HL7jJFDDYJoBV5vTF/RKlU2uft//rzFY Jj9UL6AHdxFjIZks+lRX/zeP/0ukB0FjP1U26b/KM/+pOWrETOMhW4s8NxgvJl4z8fsW2HYtNetd 09C2zzFrw1u+ejutYfPBdfTVnbcYj3UUjabSjUp9N/UI10kxwRtz/ZYDVAoR7utp4MLlddoEGE38 SON1P0cPpYgoRK6sTjJ0ecEtSpAqNs9Ae97/NyrzI0bsDjJ1V5mu8pq0bdzaMzhE6wOzcuOhC2Jr jdA8PfVAMjp9Vr7n22Stz5Rtiia8Szc+5ODi1qDEk4i0jZX8gRGGMaW9ep/Mrd/De19c5dT3bLzB K+n6q8vkWrIHILTW3rM+dBmrGY3QXpPiNrpjA9A/75uzb425GpeJVZ/EwTIp+bpd7+uoH96Ekfct k8YpTT/W+kxdyesBJP4ENxavw9yM/xmlVBKUb0+d5f2UMxk+bgOx0FmQkPqNUCu0DXvYaRsOBxaO WMR83N+tLWWkT/FoW9PW6RQODjLMQPzRzySfchkULz6HayfN91Dd3St88Wsq8wwfrN/l9v73//pf OLr/gA9ZTH4Xh1vM6+MivxZBOHnrpClmjuCktcTLxUF9KSNEYoxHaF9axSd2g8bTLuHpVv6BYmD8 81Ah+Agwa4pNWfQayhB/lMtEAtHURZPQG5g8vh80TAlmvY9vXe9L7EABySr3k3YeM3yX72n696IV TIZ5ObTHcIS9iNX1OXyRQely+3OB2UTyuHbVgHiiyfYNprgKUgamJoRc74E85d436LTZ4wc7WpCl eQISRueEdB+CRgGRQmAx7pIO59bsBnDr6E8R5S5qmBiMQ95vcRgFz+Mo9i+9CybmOAZ1IpoUYClp 2lWZ3K9JgP00s24nbc3UnvkBVnQ6czVBFFO7IoLQq2CaOC8cpNdbMLaQZK/qksY9MTf/0jTmtfY5 Su1L4EAuWukw3uLpQQosi9Iuc9TSA3eclnBohgDUvSrWSembqsjou3zPb8ICxfZuwe80IOkBh/lw IgFXgY5eTHdUVaF+gRLfCQU+yssBEGFPi+6hqaZbd9qAA6idg+RkqIYbn4xE3sSBQvQqlN1APSkm 3udonl+h53v+v86QHOn1xnMNQFPp7OkiTfpO4mB5Hz5yJPYiwfZXFZMA4SyBAEec5z7+ijlUNetf 78fnSm5nLjoXPhx1TUS2HmGL6lNqPr2jj0nxWWfedtpMx60eyCUxTk7QF6Hp5yzCYWAe5NWwz2T2 SDbSqufIQhL02TeSuyglOM3htjmHK3l6/bJ7/U/t9D108vx97di2S+TW65CGDdrRN0mRrp3uwbn5 gEnmlAslIOW5Y7mNXeICCd3OXLdoPN4SkBUpgncQqn2veAGoOtem55/xhvcviQIDkEoTAL4behDj 0bsQiG/29+2ugjJUMu2F3HXeO9pXQoDzlkrhntaPxX+HZHOsMzd46tkmAn/2pOHvfROJN/C4E+v0 ix82EwQz7ALfken66KkdQva9z5hg2OemIYmtItaPM2v5kTvJJpUEY7yTzHrfg/uaSdyVhhKNq8zc PmtZU2JWhkAkoS2Y2s/LH+IqHoRQEWX36K5KeHTX+64eCQa6NNDXiHzch4d5buHgt5v0RWjcHqlM nhwJGXCHa02mGetlnU6Md4W56yqKM873msOMnTCRd9d9Pw2LOoGIf4nUJfV76s3rjTWlR+IEGrIl UlRQTwnr9sup1P+EYYsC/9wGH4N76BWgGG00SNxqxGtyD1btYF7nmVBNGM9Ej52D6HlHXf2PZ/B9 rJRZUWbXrisUA/1k2MI8yiUgabmMQQxSONTrkPaQx11FGRzq+nPmujeOGHt9/3dW0A55tKcEzfeQ ws18vctHE8daVaHtGpyOeNvwxIe/fwvvBsjRvl8fQ6L1Rz2ULUdna691GHs/zG9du/c2LfAnhvKV klxVzoEF9s9JXGYLE2JPeD77kStmnvN52JlvfQd9GzzkfcrR4uL38NlLTqRc/Ri++C9FqYOjE5L2 E86Y99isKy3M67h+TLbCHdD3iPZfsZIjPXFzG13b86rjfcCO0Bp2GveRUkr/TJCHM+scWXZa7npB I0jL6CF05yGWJmZo+TVrkJIGBS8BpyqliUzVohrx5SUs6OvqpCqMSkePa+RUCDPJM5lwdFqnPaRE PXjb5Olx+dbRE+wUJANucuNGWVO4hsj23TAz5Sr/DuVTGtWRluVrUKmNojwDJhKKvjD/vqqf+sN/ G9hfxKFjHzTnYhBs/V5vLxMVJ4r3unXPXEYrUwOr+hxvbSftmRn/nzXzX0+x3YXFwH38752Z//SR ZfXoW+aDG7iSPLPXMJ4nA1k5PjAxnRzOZZIB2GitHOLbHOZNqp4tsxN09oaq87gTcLETBSfnwWwM H+7VrTH5Sr2F5K9KRuAuIdf13/PHA1ZLLczb9QHeWL9g9F66B0X1QmuHBL06ElgbT2z9y3uGCfmQ 3FdgIFh8exjZqVOpfOyufQZmGl6aN5jd2N97Qq1p6PTCFAdfxgGUOkYJ3TmctRP4XNq8TnnwwTGs Cl9aOKVKztv6vSt3/X1/xmGSZhkU/ZY/+v7eBpS1LmDeVPylDsO9bVLMeRK5prv2EhhJTiVsLd59 JRs0slrnv3Ow35Vi8PcbFN7QRk3+Fb983ysNZ8NZWInKqYHgsT87z9RO3v7BCULHJtZlXCadrhSY THKabXBQPYgObu/uh6vCFq9tTv8lnquNEe3vu81leLP7KeVkqLrO/GvyqWQsHCMzdB5dA900Phs/ 3wZlxXWHdj9rzheaAfVWm6Dd+XujmX8I3EU3ESoMxOFixAj8fYml56Od9dG4s3+kP7wQKJBOJWfo wtYF/i9pCALeLg2WggDxzCF0eVzd/0wk2e0PoSSEOuJHULo6pC/soKsnYndPzgqb8+vSVBGawskR Wpri+N0VfXMAtGpQgWUu7bDeroczl4soCSl2DNLjtK38iJq5nFLhMN8gArmuDRxSOdPqgwBTTEkL LhWOBfo7TajfpTkptWKJhWECED61b0Ih96ChCWzp1/t99vvyx5nxU6iT+9TXNHA2PbkvW3C6CfND UqOJ2NCLPOgITBQpmcjru/Rq571HHKgGlF+iwx9e+xQltWNmXiCa42rn2DV/J29nwpF0KqJo3BQ+ AQEbtE8SvBMVJn8PRElPJSIYhJeq5nEC7M+xjFcAipPn3nFc+/cIpzf7nvawEJeA3Y66bwEOuZhl C0V1CIkLw+GrQI52IGr/GoNbTzZA3xLDu9m+fYMYFL2jqSpOyC0gPMDHk4zk8Yhu5jfQ7X8ql6Pv 7Ia39rT8fQOtu9a3gP6qSr99oFQF+fdogk6PsaI13ACUISI8h9US+F1DISWkZiqsa/yBBrlrD+E3 5MncOYb2EtgbrNKDHCrBy+A95qe2auKLzhh+Co69NMq1flHvz5Dg0etQhsXbACfBagDa73QNdhNp 4ivdpi8x73a7YZfO/Z2FTnwtRHyb2WtfkZs9R2xSrscehPrTd3HtYBguw0oM5867FxkEfiYIOSZn VIBcJY7VQHlDokJymwitTo4g39MkGkVEmqIK1n6HXcOw438KlgvaNjsiuobZ/lkHVnYhvUb0/U+c YTNUU1LfM0vclj2eV+LM8/fs8+wkOFWPeH3V7wVMezL/pB0/faQ5TESybjH1+3527KRLwOcA5dEl xt2zEm7EhDS94FsYTXXmKxb7AcJpoOtySWlXPYrVTvft6y4pp+8X87Mracg0fKFjb+feUK/jTSRe 7ptTSWwUg5t1yRdp6mME5MPW8z7tnHeMgWrXDAogbmdeH+mHnSunOvEYDrvSVwQnd/axcJ/W8H6K KFVD9VRjb+xB850gQRiGj6p5sIbJPuQia9/I6BrKdw4zukeQtGlI6mTIuoHQz8tcY8JtlZ7OSxzj 0zPTpwOfcuHcEtxK5XE27abY2JsOlDBFo3/c7YQkntGsha1cXPITA5U8KLLpk4OHFAY7o5mp5Nvu 6/ZfItnc5RxXZBlijoTX3XzKFk2wc273Tl1dqMjSHlYRyEEIjxK8D2N/ScK0HqEhm5g0+HiTGEZk quCZA9sm506t/y/cssmTNlxM2+G904V9cTMeSKAb5DT2IJ4A38q+7EpH3cTxF5k+hfPquWuvZA0X r6QSbkydG90BJ9eRhH7X8DstJFNY35jxPqFenIB7BJeMNSVmmdzDWIM+MMU5bvpd9/Po1LVHYc3r Fe8E2u/5wHNnWlzPYvhZKXghMAsH+R8nYUpKS85IP+9ZzSMlXz4zxxj4z88ixpTTsYT1Ybse+nzX f/Z8uq/+eaZLYqSpQWeDeczihdVC/XFli0KGafcyXlg5o789LK2DvwVBqFJgQWZKg7iPq4dU7GXm WQeMvni9+xjdfsTp4WT/p48yGhMyqqOcyCMJiUACp7dS/HYRdqQhb0xBMDJOoyE/zsY43Jipg2I/ f+oPUtTr4N9U5ok0EPScazNnOkAbwFFSLThdus0eT6Hq+2bU1c4r2t9pgW0YkILHlQCewpa9nj0z /5sZ/Y8SF+jahT67RzP/Ls38u3VglSohpkAwSVXNmziZYu6JFCK1s6yaT0wOQnAuX9qB+dxDOtPw fobrWNBHHdeU3Zmrlm7/es817toqouRe2cf1Hd69cDqfGoo0W8oe1dD1Pee7fgSA/T0H+TISol9s 2XbQFfCOM2QC6Tjjr050oMPaNXYaYQhqbjKIGRhj2/iG43xy9I7cf6cJbCdc/Jb89CYxD/ZpEzyw wxTh6sGp8p8Di9u9wk7GmELzXi6jDT7zdrpysP3ByXtYg6aVLFe7yxm0ROZcvOouPKG4X03wHtv4 8DXxJV0WcySKlLc5K4fcD3uo7epxsh6Y4tG2+Q5hCToSlh9esXBXZwmL2Mv6HeabLdNvC9F1G0D+ qRuFPffze960gzBrJa40TT3z+V6pvg50jjVEdLbu59c8Fd0nnjkUDxq2C8kUnBpUjqFI481xmWMJ tTT+XKucwLufwaALugoTmRlMuDP+O8P5PZFW+qb57POZ0/R+at0cSEzTk97HjYe1qvYfV9wtHwkJ MlyexxBX5jvOlWW+btT3dLvjidebvmffJYHr2eDBOkvYkQTeHN9iLc01/XBvs+U4MttVuQUiikMm 5VkxQWHecPq7bmFq2BfNT06bVFT7KCum/lzPm14y+d76gmLoBuH7nadA4HXvptgjn4G2exLqxxEN XCfeby0S2M+H8M4BSzWZkOFOAvIsBYBG8PGmktYVdYE/dgGSU98nxTxRcJgJ/OVAA6Wga7ovxQOX 5JKcsh1FnA5RyReRdItomlC+BUbXYEOD/x2Bnd62s57zTpiwJwTTz3vX1xnbTbQhSna9mYqU4lSQ JKIGQg7bDUYASX0VFCJgJ59YiNO2U2sPyzQp3HfI0fRAYZXiAQfQ/ed+yCGoLZQhF735icKtxlmV NECN2d9pbXDPQ/JKdHt+tYLklPN1f1/urRk1JAACoU7yzBxNNIuP2smVBMAsoM+mb87muYeYSOD/ c0+5znp/TOjfYtOM6P1zllyRua6OD1zYaKhCYqL0AdUUwyKbtHWBA+THmfVMijYGiA0Cvj4qQoYP xJAHnyEDDfUR2etp4us9cZyufA5SqkE1jBX2NbM91TwNDB8mIOMTJHKBag16RZutTrGidSeI2M6R mldg+gMA5G2jLVpS/ux+1j4i0/0QjER4D5CIA/HGL+FO9KPqhPLRqBs+K4CXQArtcy2/7XbCvRwU stq16Wyc2qeqrtNHqP2+bdf7sj/qRnoPnvka2jZByJlvtfdD+pENAkf7THvBWRoiePcPCzChxvPl k+j1zPGuOk44HyRDAxwbWJS0hmI3MdYoxVX93w6ZRg+vW1y2nYV4QDR6YEh6Ifc7YX84B7Fo7Jh5 WE7n3Vv9jvLPsWPe29Nk3ShtcLXPxAHSgMSK7zAfAemXdwwkqWG/NR9UbMeZv6T4NfR5guDoGO8P YNVYZxtivhV/R5G0w08qxW5EMne098LxdHmH+PQq2q5/j/OWLzyQJdH6OKtVAhhBEqArIYYrY8N9 84VjDjqX6CNBYD4SNdKdaxZx6CJq0jWVcEwaQzf0QCmlVIgs9Nfw/3KBMdR02TXR2puDVCUHsjvR o4f+9Hf/Mv59JbKQw+uVExhOwprDWcdFrhE5+JIqhkgyY9IGyBfEd1x7uWkudNhHtzJ1HqmeyV/s IcmT2BOLhIa38Hdde6LW8+m6/vsamlnJFFddVAKZXb9lv0X+ZbW+3TyHj+GWJJE9nT5iREtc5NUs J3lVPX2nGsxTIyic0imanGqTJn4HECF2s7zdgVsoQ6YIA/V7713impaxie+bAM8JfSFgbDmgK4lC zML4owrH5OCZclzk21S/7IN2vS08SwPYaN7vnjtF8kqWnOIXHP853QR1/vzL8VDEhq77WZCgTOmL l6fZHjzVpwWVw0TJv6L1Azg6QJ7DwjAitXcc/JTRSIuM/FEjcqISCd98iLLe4S/h8+8EUsYSBvEw ssDYWPh73+uD2+4q9pIELs4y3JzJiGSibnQmuJbQcD65kuYa2IbOkNibQ7RZfztqpN1/Evfm46y/ +q4e1GF8wNMGZPFEPAe/p49dyk6+2xlbr2HhMSiTuom8Hwyj7ymQ7kT0xgJ8nIuzhJJLfWDWbRBe 8Ifv/bKlue9THragXl1w37F50T/zCVRjl542Wevk9tyHyQeoOGmFEziZnuhN3lP3u0MaEc9H/bMf 9r/4Hv93z/wXcR2uu60x+n/xyf7lM/oPkhFbGuTsNHWDsWK+FWOSLxtWZOJ7Y1JbX/A6/BP37rmT QdkA7U1DFap2NSwIVSWSDGJkm/9qpuL6HioViUPTNMiHvaLMTDYIrjkqqTJmCWxG4Bgs7K6To6ea V5Bmrg985x3ku3CoAbxgZifKuxzLBXoD4qQvB+h0j7/q0zu5Y3PDikFBNrltmyMhb7i1QAoTTy0M ozmHegbiYZLuqvqtvwMWPuSdA++n1R9spXSladF9pl849p/eu/v0WVxZrHy1oclqBA7lThoIu865 e/3UDalXl6V/Qs+UdSmNjR5Y5KrfeICb+l/CsS6LNjTfVOqXZuGub18i/J107nm/V7MO9TKiytqU tHHMew7glImLzN1vmZI/9EvOyWU9TafLQJ/ZfPdWRa449MO2CtKS/GVq0DgIpy9P/d4Bg5D37ndp J3NQROfIBlgm/FOYSGIs/L7aMG6vhR8zqxww63TzzdFts+jQzWmQryweNdbeP/IIS6cll8jCp/zJ WExtAEKHxOUmSXKapGOlmQC64R4iZvLz+/DsI4BluQCoY4m2SFLVzNMxbaBCbZKkZ9tzXPSGmGdx E5z/+T0kljOovl2YXID05XHJpDYHWdNs3peblwES3IWKkVTNQiGjd67jxSE48Nq4htidt/juid12 OM2J7H3cCx1VjZfCJr1ShNY/R0uA8U7p0GQgaDt/ilINDHrwHthiLi/wOyNL/sRk5oAA75j33Xo1 YrtQuRxFr9nbFt8YZ2j9QWTNcBBa+Im4g0lumVavp1wTBTyuhInhwgmLIp0Nr6oRG26a9Jt/jIeE 8P6Y0u1GdJMEOmD/KyILHYndF3FOtTKwMbOHYXZTsZougUAi/l4Xui5Ruob20ePi+uepCIpi+xRn 0BAWNykDZOlXdCvJYlP4RgIxA0Ch4/Oy9/GSVjmiB6VLqgxrlIpqYXGcTlT/kqvgO5nPTequR/TR Bm6SCJtOM0XRz/Fb9CENDihpEuhIR+MpscM7rLdXih5gl0jwo2FTNid5PuxoNR2VoNDN1FjPXY4V iqHCBOH0i4hB6NWxSQtpKhZwVe7a55yQaKemUOsMlHYD4hPIADFOEUmceKAzapvk8wl2bDfyBYKY egeGCwuUQBferJtUDqH3wIjXsyURjI9ELa6Fb7c0hmq7RnV5XQlBKIaHDid/Sh6AVXoBDPOKnN+K xj7qNrPTZtYo7gbb5Th6CZ7JQfACpmc5pLU3XRIst/COs6s8lHjlo076M6BGMM4mLX96ypq6t4uA HwzV1oEkfHnvUe9IwocbiuUEHf4z1+jhl9viFCi5YyJ15YB6D83oGM57hWUMlKeoKGPrc8UEGf78 YJ29zrvvVITfYEczH8B+DqTrODe6nlhAq/hG2YPJd2Q9+V21g9U8aVL+TKdqV7sHGbARP5njOxvd Aafwi3UOQE1ByUZT50vLTRwkU4+N9PuRrkSsli25ku2OBCnlzwvyxfvEpX1yj9RmTo2gH9WHkCX7 UoEMZGoNVM9jo1A2RViD/c1Uj4QiOWkuFxydQdkv2dh/I5/VqjlVK3Dd00SK9cDBTXSlv8vXgF7W tNzvvy7pBkfz7D+TSOOkqkGH5RlKcmPMkdfsS3b8DBa1dM5kZmMfCGzLgFCKaB/U/FFnHNjuD/Hh TMbuikgXEqdyF847RUdSnD4EEUPYYxHDSWIN9LheaaVfOODmRJpsTFOMro+uzzY4YEcCgR+soPHM f+kzzIF3bLHAK9yigd03fU00XCU+i6ga6njj2IHl9pmSFsaHXkfd6+zPc+sVsOhAY/6+H6hfdg13 GarswYseCM4E0dyHl7EKDUvP+RkoleRGjn0wX88aUz4JgbjbR33x7WuewyVXemqe0WnKZMAsdODk JGHiZ9sCARpANAzkb3R9C0jJBKvWrA01zBbabiEDY+Q+votLoADPGJNaBfXwrLrAmKLbhL4W9uAa T/CZ4CQc1LiFMpopJ/ip5BTk3E55xJHWJp3dLN13lB5HBi1bgHr3eT7W0l0HCM6grr9zUH+dBtK6 twSDN1wDD6RG5UjwbVgysfYzSZOFIT0URphYD50a7uDsF37umuRCbnE2oH7KdSwc9iw9iIh/y712 m0IlVvDWCf5lTDnrH8LwvpKwhKYYPtUpl9j4GlieUWF9ZDzVepM4E5KzC85dB29wJXQ6rfA0h0Ll 4Vj8owWx5/+imf9aDl5yfaxiAzTz75jxf5pWqLKDyGEYX8lSeeq2a6kWbnDUdKJ90Yzm7oEdjt3E P7d52OUyTjodT6YEulKLqhu2f8GpVdxlJ9RCKoF6xEur9+8hYZf1okIIT0PHw2fOpRSChBJ+Rp1k m+kxx5jTMDoq1F2851jiYd3vfyWMth6tB7d95vnOwnlV9ZGgZ55DqUN1UfZIrYV4BwRcHBTZLbRb s4HT74H5rnNV5kvNnVIygeCsjPO6BukHeb32H/7qK33UZKo7xh/1yT7Psh7OoSEfig1X4tniPD3Y v/0dgBTf5GtYPgTJE7jWz5oSILXJfBlPf589Ko/9azidkGu/B2t9tAttVHMZtPkcbH7Xa55E/sCe 3sHxbV6RwyzPaSBCOIU7oPotpd6LcEcDjtgGy+MZHgMmDIEHVUvZGknBb/9VyZ9H9KsgHcoHkzRh 2mY8Y4xs1EoWk849+qPb6trwSihPDcE2pbysdbT2oMpMYXa65GGAdSV75n4kxJlxC1XfMjPzj4yL yuYpXTyEpQGLiBzR2eRC/ffwEDwID5J6q53Ry2blodeN8xJQiBpqBkW+Lg5VUcjBPnQosYBo+7o4 Do5ZB73ndlBoh3qcpDwdjgaiOgQH6SyHFyMRKbzgj3A/kBZwJBVF9zFhlDT5LZraDrI0cW0k5loI JwQWXMLan8lGDprfn34D5enm7npugqhrHxTTXdAlWaEiLf0xMWRsC6+Jo4RROhqkWhpn8+BHjPV8 b+d6bdnROvADOB0zbP06X8+0ex7HLutYuzqu/HSv1l8Xix+jPFV0OouDpuKuGlTzQYbPcu1nwtXD IblPQZBxUzC9rZKh6CBWHDG2xqaEnioJUClisCMmdYCD7RT9AjS02qae0TPZhoEm3dD8LXKkqenF Dp7fYgJtILuaT+eUIDUsOugrL6HL16T8fMKxr8tMD6Pkc74dinrdp9jE5F63LfJ3bXTQDrzXL5JG B4A6C8h8RZwqcZ06NnQ8FN+0RUC7UH+f9WgQJh34niwQaWD2y52lKY83XWI7OUh7h/40wR21mGcn nTQKwOA7Vo2io8959FNkv/5vrLH0pKrzz94N2sxx0zqc4XQM3ZBzO+wX09pKkNzrPGR585t6QMQI e+wP1g4uZ56+RTpy9BqzI3Bvu6Z9u228PcqPe7aqriCBY9Yoq0KXJuPNHeKQwZNESC53Gs0c9crr tPED6r3AdIuufcAQ7HYi6Atc4IoJAsA9qjXUSwOBdLm2A6Q01ZgLnBLbnT4BKI2Xrl/Q4/p4cvw/ QpLMM6fL1e4HdMAyP/c1iybraphMocj+TzEg7YN0/MwE+Ejous/APYi2HXHZN8IHwdSfMJNKGBz3 QVL0GfXnfN0ObryfDYK3S0SwhhPDXcXjg3DXSp64UvyyA+3BP47+/hIH/Nxt0T07B4g2mfJ3MGCR /II1ShS2P4gbDZ/Iby0CiW4wTIAkiPadp8I2dt3P7/t2Lm0XX591amNXKncfkqZ8Jxo4gFgflH7L c94BkQXSSlCv5MCh0K+wHcepeHL9r8oRn93fr5RDFmfsQRGFoGgLIr6G6w8XqMmYdeqfLtc5I/g8 u1Sda9jqNBaJ/ZuYLCXEXaMuRofOQWLzpiq6UioyWAJZdsTFemBol+oavrMUQ1vs6h5njB3/eU5s NWsOwY3bgmkf2KDY3gT/Pg3SDe6jmak+VNjDk1BKhQtc1aiOrv2i9AnX1lGxNJL342Tafcw1HjKT 5ipGORQJk4x9Vt/7QRh5Y1g6rHiwb5cOnPMm5z1tetHC1uhDPtLojKQreQ1SpcTvs4c0n4Hx6NHT 9IWxWE27An5xUCohxhZR+kSXtUjnL3sWEgqy8JB7XkeN1g7Cu4aZx9GfSM6pNSFMkSUf+E3i/v3P DNvDf8Mu4ofT9EXb+sNb+OojBtjU6+2wiL//jJCL4/XpuaS2bwqdg28iFztKipkj1Vm1NnSe18ok iPytNQh4yq7AbErI2F5jTvbe6+U8bJcA9jYeYJ703T/k8Pezd0qGjOZhu08a5ohf/B/50wlTF4GY 8HLRDBHEIQbOfpSw5Xdva/F/V5rOIYaYxmfe1N7rvmAuMnGAuzbfGgQVUvPzjuhdGpJEOX2oa7kr gXMKE50jxWzXEZzI/CX+vNAUThgF/mzSfT3rxUF+yTWifWkMHEZODsFlO7GvWt4k3rlchl38bArb OR/rrT3UKZMe5K/6PNxYPmFuRlHsTKfjzv93NP+rGf2P17sRJ7a046jGM/9mz/wHB3qtmSkt0cbA dCgPYmAtTMOyU9UP5PWJr3heqF0nc6fPM/FNHn7+va8+oHsWrdrWc5t0+Bl+uQbzSQ/kD13I791S DVXbB5dCnHFgB058TOyn7eRLrk4kkwP0Kx5+YehzJCihFsatlVP8Zxc6mVyH52anBJhxcnmXqz3p 04ijNtz7U/fTm5Bew8zan+M73erdLwqh84WzG7n1rA18CP8JXXpxlgHlzI+5SnpMX3arYtxdc6Ry daI2pdNOmMQRj3djw43uqJRBhvTTn/eqf8p4VpBC5kh8cSQK7zOaWbLgAZCdaRT3x8BrmtNw1Ng2 oHFs/NspknyaGO6Gtw/QiaEkZ+DAESdE5Xp+/vNs1edv20AIVB56RM0xZOBv85ffu+8wQPMsHumS yO9+VdWlk5al78Wte/aDLfojKaUHHHd9x7lzPjEyAY+0d+jze8XYFlhEYgq0yqTYRz1P+ogr9ffn TLhGZ+YwGmHdn6atE7/NGP4hbCyv2MMdS3CBNxl7KpjMuQvovDY5eHgB2fqk9tB5hCIZr6h4njJJ Nx+fzdQcDYQgLjxBtbfxXzP3usUoJDjdpwWRjLf7IF7VjmaipuIMJLTCwV9RhBN4uCdm2OWJ2vIW y5BLv+BP/W08dBWCKTK4QZZ0mjYSwl7CcUlLl+ZjatFAYF2hPSR29HI5vgANQTS4UNTeF8kM+TT/ FPr7cmZZyXvwQoCtbnHH3zXpx9FHwmkuBdB1Oav0JLfh8L/2WRN0nvkF6g6I1k3A/nXukOCddpH8 +//4PLdKXCcCDlucTl5KLynmajJmNWRX7MmcEgsiYrMw8gJ174n6mfmUsTL1/cYN9ZxwCyYG5SEK sd5Hoai9ThIQzYhoQ7GyBTcT940A5BO6kFMAtcvR3nMF/uQ/e0mW152OHFO4sb2iQlvg/OPuTekG TIJcBFy6luyobmqyBwjSmTvetIXlJHyjc/t1Pu7xlz34mFPRArCEklsWgKNO9ikA1Ey65dmaLhzr 9+n7TOuWeKaFSF8To9eM66657G/CA4FRNajvjzW8Bx84Pnou0kpfpIwL1sh18+2PNsPpOwMuLzMc MZ3/v1bMIEd34m/8qZ/dQpfLR2o+9t+eah6I6HZ1IRhjVo7OP2T8W6M0gZKUSLrmkoP6EZMrblQd 4omZwcGt9rzqOGofFcKXQzWBgRqawn+HUxIYykYZEo8K4PFcMq4zIjqcMdJNOp30/tSZXgN6E2To BKnNPaUBAPeQ85qqL2xRkM876R1mZuG5jjpLxz0pAC6ySvoSsF9g0yA5xhkctziKu2pFglWKu6bu AMPA+3redv2dPl/zkzSo/RLkTdaH/eITL98C4f33Fc+rgUKfctIbRyG4MYRfSgfP7TT21n6vQcOq RaVYA1rurg3jKmrVHPZNJ19FpPt9C84HZf+KVO/Ekp8Ehcv1yZjcoGnnIx/jMdcuc9+NPoutcCZ3 gOksJxKeDirQeSrh4B7C3IKacPCGz//n+eujPtr1nYDE47qHPdE/hn00kBLwnFl2RagPnHGbFI71 rE7F6LrpF5y2otSNpfcSf8cF1yJdHeD54H2ij0rUp/sm1XT0HGfmY0ApyToask7cpteNUL5sUwqM q1bZphMphHK54+gT/bnJuD97RGcqoQ68dNcQTS7FW/C+a9upcq+1TL3b8bcDg0bpNE5YTDtcZ/27 BLDnGn1rQj6vL4HsFtA+IjkPEkDEoIwH0qsSQ3AQ9UMjtiBs1JnIyXXylCMb7nBRbzTIGTmMB3j4 nN98mQRMJ5O6SOsLU+ieKMVhnTxEwx3J31zd/UC2Id2dmkHM6RID/rP/E32m8zxnJ9otdpkzTWGJ DqfdQK+BrOxQ3nX+YiUvtuxh8RYOPOkVXnuJI6gX6kGvHqS+RmTSvZKF4534apTHGPhS34O5vnqt S8Z6MQ/CTEVeaz77uW0S0wMn77mkj/WB4nezu172N+/d8mM8Moip8uDj1H4XoTOi2mWn6uWQ58/d nGezt9HCO7RrTvjLhDpORDO0AS7u86rfSr4LInwaziTf2RRXaRni+Jcz25iQWALUtdZYeEyD4gbD qBOLe9JFCcNvY8Hb8ZfEId13dFI5YfMoDwPDDTYvyzUBhnl6U0R3f+KTH22BaHdfO+6ujbNSYzDL zOPCs/+eATFssvQukNeyzAA+ea99b23MvDUiaSyhox8+r3G8mVpO9CZ5Bl7x/9Dov/gb1tXn+t+/ /y/T6D+gmX/tXNJNzcJGNenIfqIRoRfQ6HNgfOOw3UlkGlG7MW9zPh977mcdKXQLjAE5Oq6NFTPf 9OzKuPftGUpxZyWCy3xqmyz1J5tK33AMcxGmkDmGCn2MJ01kqlfTQDUm0LK8Q9lzYtHCvq8RzBq2 xr2kMDAR1k6qU6qHeAyYm8+kCnKW11k59+cjXYWiBgHGyVM1f94NgsF0DyX4PNy2Lpd1HTVtYyjJ CN1spqp/mFI17X7VkERKo5SX6WwnWRifcdaENBC3U26AT/CFnG7hdypSCOdv3I2H3t+q9Md4Lo3t NspmqFl8PLXBQckZ1pU6OBFQh2ibZG1e4dKgTKQXU114YYB/TNHu/esDZ7uzIcHMQunIn6dP9y6X 3Sjc6c9dRvaX8J2PJ6qhfT/DKeSG/sOw1+b4J5HwLgWGMMAl+gNtVvG6/uAzt3HhbWQt0GdQPVtn Qp7JHjC9nMIvf8f3qEfherbNd/yB+3d6Rt+aDjPMXSX+YwuHKfJpKopuTQ6YgHxubv827+7pMiIE pLtYlibEH+TiezUQqoJsIDh9PSr74ztSy0jyYWqir4iJg09CCHyweaSD5Ofw6U/EPmYHkH64Lf1M Zj/Cd+VkWE9fvKR7rgWHm8BAc7tAj4hTSyKeAHiKhTSJEv5+T4MzPU25ueDyi8ogUaV/odnmdOVu WqiLoA0mdQNIQo4W6Vbk2XmUXzBTSYE+mlAYR3mjYaBIHUWMTLhmvO5mLJm+4tZ9xlams2XHXdN+ uIS/4Bqo73CifD68mih2p0q8g9DioNOc8F0DOuDI4hqgSQcPl4A0nRD9iN6Ewy86i483XofcAC+y l1czE+MptnL5NAMp5bvpKkfaiBoXkkI63O2ue/8WjzGIxE9hYjjpPed7WO7bBYlcz68QScec4hUH 6CLqODLLSPooGrT2JHI03X+JNs+aXNava+3HqcNQoQhSCDghQlg/UGwrh9nmUMPj7iMd8/U5zHLf gaoZIVXRuoflfDrjdQ2YTijkLKz/Pxp2FoaoiDm64/MtCgHhTuRgwK2BogbghE6fV5qIgDLRB9Gy 31cNbLxOhtIHgdq5QTPcE1xNMzp3uF3jOaHocpsGNxaIIcs79RIEZbeRaREpfk3yYsiJ8RTl/zZE 3DIJrzp6lgtHPjGD+IWEdnPEmA0QffR9RGC4SEicI2uuGjXhsfeJ2hfUAsQy9ZVv2h5UQ/f74XP1 BVfy5n/r2frEz8BTTu+zj0hHhVeSgK/6lN3F7Cb59vm8wW5NjhlsB5/2DNOnFP7nuTGZoCGRGTuA rFNCKjDTsL7+Ohm8aSQOcF2btCUwr2EsVQ22e+jENKYcLn8jQ/pe2kMif0DwuyLrM3aD6xfQ71U7 sQNHJ3X4ADm3uOkWTBnLzuj97IpF1OTQ75XQM3OlN6VD7Bw4xczljkFOPfoAFknGcLlAJ7T6QxAa BPNZw77EL99XGhqwyfedg7nXcM4WY7rqGi2SLkh1DRJvV61KgfbvsAJHIvOeQX9WdXT7uovV67Ow qpM41HGWt5T7jrqnQZWLSPZK3bsdfHwMO07dIl/rpp1U/YGV6MCdWnjK5iCMa3bylHF/sGBUf3n7 10U4hbxdGfjc1UlIqUiRTishd57+rDN3EsYe3qBz5k1a/BE4GfDHjek4zur1TdyYcD8DHVhMO6x7 OunuvVfbdelZU2q866d28/G9dGC+F6p6RNJLB6biE9dvAWTWVTrFwT6x0+e2lw5zAH3893w/PojX puXZ2TdrbaNwSedev9y5KX3DiJl5vvN0i4twru2NY3/1znn+040wc+UpDbhXRh8pptm3IMBHdp8x K/ryoG+3uvnYI1dqhuGnfw0obVzwNSbCXFr34Fo7vnJqDg0s7Popan/c0YR6GodVyAxpD7ELxsEI F6MVDUnc0PvOB/eReIqus1s3/zynREIBY93pHrsa04G35ZsjT89XDEZ5qI0T9f51nZM7MdWHYOpy A6YTichnl4u84Mwl7jvPhJWcqR43Zvdaw75u47nEkS52dPfGdypc9xO9mm4nXc/vaUyzeLKprCEj ylU9zmFC2PIXf6x5f9QXcf5XOuGR9hI1PCV7O/iBjW+5kqha+r1/oj2rZ+b6x9DLNAVHDqGNyxKW oqPDuJ9Xag725+/6XaBhMJh8rOGREBqnVBnNjxT354/B4f91xv9VEWdd68qTaU4z/tfN+D+dWBXx WYgpmTDa+11szQpwOm5eWlh/wmCFJuqhsiAB07r57E2T3yUOqfojZ5eShjibF07nYkKhXjzgx2Qp U2Rc+1yVi2A0DTSv/v52unUvOm/vV5PBvcBPT751RHoMEC9DN77Beyj8Fg16ev0PnJPHWSPSPOjj HIekSV+DD5TAY/gZ0ZNo19LGN5biUeOgrn33ozOdMmLYn/u8SPO9/TsLk3Lzf+0iTwNzbTzAthfp HJ/8c2Y38/iokbmf8zw9Al4WHkr1fbpD52e/rP/yzpdmKO3wZ4/fRpqCzqLPXJB5e5+rd0L3AKKz 00py6N91TqEqBuqdrzrXQ+PtOBgK7/HVZVK9832neMg2QpVaYBwg6LVpSDr5Sma9ue1Bpu5KfR44 469+L8Yi3IMad2f4DnFcn5KVnPMkEfezMehJZg1nupDMxuwzSeM1yp2hjC+hEY1nPpVyZIj1hzM0 plp+ubM39juBjbxmmNm9/OOPa1BGDVIshYg2Uop6iHYOT7RQ3mehSU1Xtgp+SalfC0U6uDJ6ZU+D 1WZROuUIAE46GFwSrY4cIMLPIP64aPgL3n0fIk1Wg0tUAXo+XRTIM/PH4YCmmFLIbSwAVrw6TIFv 4GGOBtblH7CFjJskFx2KnpnD8e2NAu3L/QbdyUd8TZETSWf00q7D7ioi5xfwW7U6fQTXERipOmR9 hnO4RLivmMLp8j8XYPNF/LBrvZeI5HU2cTV+r7sErXR9kBw5X1ViSs/85hbLcU5XBBNfqGsl437U /B5DFukFMEFe8W6aEhTMuoS8GqokbV8hMAFcVMSqzpQ5mzQWo1/gCxdKl+fiCTBmYfER2JKulXOS M93A32U5ZQYE2eaOLrv+exFaniKl+lG0KO4iYA0h3QKpwcwUoN4UxFs/uJrm5foreqZ7IIIif0TN xjD4m67ju5nTATTPvKK5hjquSDtj65IuwloN7xaZTQwSbmeJjtrbrrIgiveAj5v3+eI8Szbx/g7Q bffnOBF8Nf1dIwy20j0523eMYJ3RZHTDlOxdKQZjsch/eCj1PYuVr1vM7JlDCEx01UMux/SsPpz0 f1ywDCfT5fxUAcntsPi3Ptr1Qbni6SI9rzOfugaSWbEfw9tMT4gwfwC2BJs2gTIlnnmAGbMjwu1K 0fd+ebyaxQ6aOcVd5HS249H7tNrgzwBQCHHaFAb7J6nHc5DBUx4afadlyhTdS5orDJ0GZz00SPMS Ztup/3aeE+4YOrPP+Hnv+713lj7qe4j2/UiBaIeLHCTsym27ZQ6I7Vy9eUbICwlrLmXbhWcLf9jZ nOlgLaE6+dLuGrDj0fO8orvJITiPNft8C47TpnEzn5HB80+czlmPzCECyLjRfteOise/5BvNWc++ fbIug4MPx6ushy9Jwnt26XRpoUFPzZUqRIJbD53p5DzMgzgGkkRBEGS8aMLo5Iyex9U1WDzaPbdX EtNvLnOXgHCQxGZJnsOZcj78auE3aJO/fsgCYcUoFJb613MSbidft7jDYWlXFX+GMO4qtUfaOFGl xeVzOJLn+lg/2U0kJhaqeZ8pCUi18UrT8GAC60asy3g2Zv3R4kbKhLvlPP5mDT9I++062IQvrSv9 k7KZH7EGJ5PulC7PxN2WKWR/16Hmkxj8eZ6X2Mu7TlCvuSuGvEdmwllKxCb4cPsl2eROsE0hM483 6DA9ec15fggnTzsJa9Ur0YH4Jau6dt6pO52TSekA6HKnTFhrV0HyC2+zlHD6BvxSVc8JuJ+ZCTeq 77QHL3KNqfasGcncZoYE+EbM9qpgfDg7q3C9b3zbxbf9aRup9juz8arfNd6rVZN4wolfSCG3a6lK gPB1l1z9N+3l7neM2LaXGdGuywx9ANXRr5sf0+G7Rtturelozz3mNdrixV18UMzOrk3HbeFj+MqY 1nsJwu4abACvv5xjE6FUIFIHzmjXvSx0SOWEah0imqk+QEf1YnjOOQAtxPAEKVs57NWmVD0so6qR 5iPJEwTOHpbTaQ9CsPusz17qh99pfN7LqduHv7LKRT7HH43cG72zKcyasbD9Pp39kg48q9gJchEV 7i1MxlaL53LtZr6qg1cx8PUpDCGZSQ9gsRRvu5jr+KycPLKG5RFZSZ4dqintavxiRhfnOD4+k9bE ZFeoHiF13g6zX0LMGzek8WfFPet6f8yfkOHd4Q6uFLfy6KExP+51eJ//78z8L2bmfzJoAqVJiZen DPT+LZ75j25O2TAkx2NtewBVpWfKNbxTA6ALUiDdutdY6ztIKZWrP529ZzDhx+mM2x2sFmewh5OE KIemDRK9BrId72qj/ckbTfChKkHp5WpcPWNoenTyGIT4C85kZvJdAuJdNb/9FZmKUFp5c23dlftf LHCXkYPjZNRZ5RoclAcSIvIntEGI+ieGGpiMeaj6KcQEOJS/gsqqzlWJz2081gZZmIAmOmPT5X0P nb7mV8Rh4IloHoq+6ts5zW+35uHbubpre8NpcNfhv2kUphLaNfNP8UNr/Yk9njWDCUKD3GLXfIPf lYZsKJ0vbl9pKBmAzhPVXb+HsNbZ7MBvHFYUYa76VQ185VRmDbbS+9R17x9TlDaaEmofvb5Dc0KZ gDOlYXCNQwwwgYUq2cea4LVirFIIo4Fe5ODtWr+ytYH7jvOBR3Qtz0JuV63wNykMUAbiw6vb98C5 wBzgoPnhwF7aqL0jHdnOftKg2th3AA9+01BNPzN6l+xC/y/92X/8LTgFpbBb2LxKaTfV0/IUw/yH d2SpAvR3fo58cYYCzkDacWSZgqz9jQt1EH3pIjwIDPEm4tKLZqzno4WLK8BTW2KRzNokFk2LEkz8 Fvfb7VAVHSUkbBuWMIJJKgL9JrUNtyzNFME1p5lbwtpuVLvJ7oJ+/Q4RqMRuVD930o4A62PNQYS1 g+ffv2uS3Q00xc+B7a/WccJR+5r4N1xgwrOkDm5HPKC4QHvFYkgbABk35zwrC0yqKNMlQIg35CvY 5yhTlQ1t7bq1e7KQ3IJPAQmq6UGNezSF3H6J8KWC9i+g9jWafsRMXSC9n4v+/vOuoZBr1IhPhI/C XSpiIwk7AZmXf7dPSS+HiV3wK8Ddgdi7Lvb67iH/bB8CqFjZInBIleZiWK9bZO9DfBMElLdrcU/6 JQCtI/q2p7ZfwPUMXpM+ngkT8l4JCf4I8L2GBATxqz5vQ8MQ4Aw1HZeLmiAik1dLDmqsInZ6HG3g 1BvzBPMiY8J11uVMNuEa8hAvFKauTdy+kuL9c2bmIyg6K9X9+eajifoSelxDB0ZyiAdNW+DZMVu7 xmgxqNbzEpRP7PJpJEwVpVRXdjoJj5ZZJAEDwqsaPoyIwicparv8u+hJdPSToFpvkl9Ql+u4/95h zdxjXs727LjdtdVby3s5q78Nu2JPNYCe979C3CKO2zNW4LF/k2vv++BNadLHmMlErDYmQUVs+CV8 afAl72Utt/8twhsQsvgQCgq8AbaL0mgqjj3jC+eQCfzcCV8Na1Tf6qGhOYSCN7BKKSDsXn71SV8u YkSk+XTOzOEVug/7fezEp5tcHIxZblQjaStP9yA+aIpNGHU8+k16tuhjrXAcdvKZU5IR2Jcznou8 mSmHGX2RvGpxx9pf+SzD7S8EST48UNegDXTeGTs7CHCGgMcG0FUVG7nTFS6CxuuMNIqJQhASSUxz 0uhtZMAx9Vq9g/06e00IZlT9pFDCcAh4UWSSta+Xu+OdrJOk6XbeuqRnrzhMh+N4ChBe3HOBs48m QjBUMAUiM/6SKTCvOO8Hd2t3nF2/uTxvX1drklry89/ixT/nao6x9RC5AUNMwfaPU8wmNKPDkwo3 6/7IJXyZOs92XPxFWWbSZb6/JIqoJjckmTXK7A8CyyU29rFXy6ABe0y6oXZd9v0Ouy4jL8W3rtUh R8jzUxrA73Lt9Wk1akRMn9HmA8Nhzz+DRMFBIncPCpGIhMR0LH6MVSGi7FzkXf+57bqUDlNvDdA2 EOwM6xKV7LtBR+6PQFCiA5dJ3N0fXECGg+HP+xysaFGpCsvdZkO5egXpM3PgvBcSguJD9HAnfIvP ivHV11yuz3rua0qLNdQ3385yf02M3LdP+zv6kEWYEyxhmILCwHUMu/zsGx2IBBgMSDBkFfW5FMOB s9fEB/S9RXv6VcBAQiTPF9YIHsGaXzFBFplcfqgtDPaJOROn+dSZx21x9WDXuO1NDegZBGwMqXjP ha8OYrR2Y8M+6uC3h/ejePEhLHgHtV/hJxkBXGNZ7xl+DygYzboSJlIOvuka7gFEz53GvuvhC+f5 WAsS3GLHfeM57qseSXPgS5R6znyLD3x3JxcKcLM5zkJGUPmfi9xKzSZ1mkzm2/zKKI0ypgRI9PtU /EDe1zxEoaOXVuB7giHXZRYY78yVBnIMXkNntFxFNSg4XdgjpNjzgBnzu0YFR+Nx2TO3qNN1Rgh7 cS1jmwuFf2tGqnKEjujzONrr/z4z/8V6qsT5/3kuzq7U/87x/LvSZXz3yu3NuzlL5pwd/IKGTYdo 2EW/1Fl9T/I52R68/rifB/sKPu+uHBdBakpjAR42scm9JhS6zWnkpMlkcVWyeWKRql4hPrONOBkz E60NyvOGdpAKi2NRvRHr8nL+z2HkgV4kdShUuyl4pTzltrnYZcrjA8/QwedrvoZSVaaNhpqgDfMI B6q7R5cDdg/lUwX6m40GnXCDAw5Rlb88oXpHvatsmdK4zwLqC3q1ZKotm9NSfyPoRfbd0mY50jas yAQqQ9qQge+tO9wfgp8jx0wzdfZcuIqPe5Acrvvu9XoeQvPRL8v74HYUtULU129/+re/sB8DwPfe 3vtTof0hJ3hp8Ly6zuhBFjPMfEuzJuzv5mPd9nqjAc7kc/v9vjvo1fo6asKrpmKjizaw7lTWXV/1 YPaFpn77npOp0Ji1D6s7M2NQL0fAyrjrhOhzT8DzaPFLmV4zxTO3Hd4c+M9+5u9wxWVQ48Aoa1Th qR3/0Yc6Rc5uR9+cIHwL2o4rJIcTFiX7aA7eQpwmFB2xzovKcQAGvhaeomHM6W6zp7RmeEKSQ3/o aOEF+UXyx58SXd+qBeUYMGiRNkektZvvu4gPAAb/LbdT6CB1Fq6/eaYfophF/BvI03uaqLapE0Tx R2goyb4VRAY59tO0u4dcqaW9qWsC/IpNVod9vEWzPtq1OVyi+/25L2D/EJxG6J6aXZ1hJdyk6JdV 48c1SugwkMXES+bmM7zEB3+BBl9gNotbZg7pkeYE2Uo4cK4pWqdGh/RL6OEi7nUmAZimIVVyh2gC OT53P4yrESWxNJ26hrPW+7x3D1TM6SuUM9LuBlsqAcaSFCnde/J+3EVhC1rBG0XCEjSj+rbjfhY9 OWdOoC34qLgC+36OpVd8JoCiTXfSFZdJc5ETJFzeQREF5rvl7PuWXAquYZFNfBrqDnI13iKRa9CK h8USUCIKIH1wXuetjOvTkHSUBz1eQS815bte6+jrX51IgkR8CZn332kJkRviSngSwWZxTbYFUQxi EDAmdEcKkikSXN7hwgsUbbpQ0GhP1MSP8+nTaLQ42R93qvZAlUNs58vDcZaj59/hEXHj5eV+dcgS 1ekZHY57CAnORnQPE1B08B/n2B623QTY5XpvZxMuAKW/xI4CEmSDihTuKQATXqFbihwGAP/lEqDn lvAg6foj7keYJgBXim3btcZOgTH0FD5OSWPNmbtqnU/xkwxAmJBk3U7hNOyii+yIyMGXPHidBgSA IgP4QPafogsS9Ksom79rzP4gPnpl6wNGvF2OfIySzsw5PDH1M3Z86f73/iS8mYa5I8tJJDDYIe7U jMAM/LsPyNVJ0epuOFeYRpJ+xiOClj130p2Ogb3thuIzzvUVJLHrC1eiia4ITBDS0bjBtK4oXXVc phu2o9gb5bvd1b9iM4V91LWKmPzQgSH8vc9E9bsnE95cf2ew9rn3Azlv/7hGszHFrn07KTDQNKc7 P+NQ2Y8WEqm+43ufPC7qv/YLmjlFS7vvopSYLa4S1IMXxkEVoarv/QuM2+X1xUjQ1WMa7r69p/Uh DuGO/xpsbkfOnx52Dn9Ccu8kxIjJYiFK4hro2IN/t9vjjjanlK5b7jkzGDWPN7mSVIH7yFN9yLeA hNKxwA9USXgECSI49b05k1ot5sHCHJqq/6YBQ5FLynC7jZIxxZkkc+SurVXnAZ6lf/4SkWh4cCB6 ih+TkPBk/NtOQRrJW3drJ3/og88wYuTktr9dIWmI4RrWERD3lLVIzmPJWfRwTKZLPPtW90BooTrO tZdpBjnYQ55iYWhTw0CBK0iNIaNoKMhzcbdwkdF/738znqRz/Oc1t+lhwLd/VqG3lxi6M0tcfQLz jV53LyPhxLtlLP1b8xEeNnMlbLh4qexVjBiFT3zSuY/xz1A6BvWihmrQlZDLfAu4463hitwX3LH0 75glOqWkHok7nF7XPMhTtbam0U8xoirgH7YA28cAkJZQjtf24az/iOnJVX6djKbU8l7xr2iE0yXa UfMPB+mFz74cPBiEeT46GjAdwe8yTz/jz853smKUVrKwC3f8zcjmciZOLE4zKNxjfpo7+l6jP0Nc wtqtk5TEyLEG64yB3nT9E13Gg887edecphJnbrnVHnj1g/V5GVQI9/ZAj8ena3LA1FP2GfXDYU8l oesYHMo3zyJyNlKY0ScGQAMpf3p2MhAx/NwWz31nVj3/+f82M//VOv/VYtS/9ZYWG/KvnNF/eO+V t7+55IoKTCCFpVP93tuPtN7j8gEeQFFa9jlV33NV1Hopo4oi7591eqaDPXYzLq7HMaTLA7uvPiO9 YQU4N6NA2SOmdsiYPk5ciMAlXHM55NL63Vi1j+fVeE+NAniQO8naoLnOn6E5yiQjTIKGRXMIv/c4 9YyEKAX+6M0HZPLJXyM6O4TQlMTpdSe3psdLE0gDh8nhC9NXONmShx90IKr+3OeDdgv+FXlf70MX W8fC/d+S2dOAlMwMi3/UoZPwFK+W/JBqQNI4sE5maI59v8+t3XcP/B7iELMP0mEb+IWVk1xekIHw xdvwYNNAT0eGj/9CT/anh1Tv809cOQxXFl4V6bovLk6D5fQEPxFFt5M7Y0mX+ctOsiabUjZPNXAI P5+ehq8683GgznKfueJkYIc52r4ZBYYlnTzGhiWzON1Mh3MMGSXHjwmgS7RPN2SnqRm7ju6lHSkN f5MmgXdo7P5gY57tzXqDF3cyp3hOGO79i3/zDyrKbhrtKPGU5LUe8cd8XLRCQmVH9EULaSp0OMLr rWP/giu6IrI7vvNLMOZ6RMYD2SB6SJc/nkm4Yv7IifpyWVC8LR3tAhExOi7nnkii6EMdYIFBMvAK 5Noti53O+XK7wj18EF2GqcsAYAHsXa4h/iL7NfdxLgDsM041Nzd5tgsPlowp35NDt8N1Ou4mcbwE Ms6Js4HCZOD50Ru9JkL7aNUBTlKcSa47n6VOg3A7Wky1Vr7iVt+zTDMdK4YN4RzA9dTZ4FgTO3ZS SNjuCfsr5tJAek2QRY6G5SbX38uwQfp26jWcxwMO0CmCY0LeSJr//ueSwCfCama7/EwUdRfYeoHY V9wxjWi6T0rdZ7trIAeoBMX9L2owfEbFuWBeRRM+JZYuwUNMiDdJrvi8F3Cow/eIo5De2Db0ErAx gjOL37fpVEXAOoTBg+IIwT6khI0WFfF6zzvmhtBdRLHPxvFyTnhAY10B3MY1zJkMDdhs4uwYhROR xLdgU9GkONzcZ46mU9eZt13Y/6yH7zrFsPf23vaQ4/flYvO6u7vAYYHrv5QOxQpwzQfJ9QpvtRpZ hfU7DSL+iVVLt9mihEtoMQHKzC+ikznO+WOg1MZYNpJlrmELTYG6t3hIIe6/hpIMriY66DUeOsJo VOjOdFBixnreKKaU6KwTAvqXy3aKkgSiKi2XUS1hCkkYas3YKGzl8eKI23OLB1YtYxZOaAbJEIPb z89aut2w/tZWGvTt3X27lvhJBSRtB8l0yJhhL2xV3TlFtg5E59Kepaf1Jgf5GDrNNdgO/vE2HiVd 36c6Ijs5kHHQWcsgVLiGDTiJznNFF9NdaiBxruqSgEVVrH1iGO/ALDq0Awiu6p1cd5RAgLsJW60E OxJu2Uw8ziJmvkXYBayKxTI5HL0HO90xu7poEcVe1CmzaiGujgE3H5gHQVY6+x/Fnt+/USQdmS/H sgRDXef4zOVYdA42SEv00eKcTssRgawl7ksHE64gMElt3vP/cjLp7oQGtw1DX9LUiZFvqVM3emSp XIp1YSrG/9QDGILBvMvFNs6HydRIJs1LtFEmJzPpWKUaWoh/7hY2e9okZTsTZaqfFoGfw+xfcscb jxsg87wwBoEjq39dcXAnBAG59ypFAHfyiY8UGEoXybtkOXdmrLhjp2qnORhwWcJ/9Q51vM/LyQl4 ehCPXbU8VwIVV3uvq2FVp/aZEEXnOokh/vZJIuOfJ+lOKgyGUI1MvzVW1e2MS0NJAnFKf1+h4PsV jr5D+Dwe5OOePTo+zS+ENmH2PxhBdbRqbMiAFY3TAELf2MrR3+eZR+fWeIY6oilZwgDnlUPnA/Wc hmRyCme93ev2MA4laV4DVEavL50yhYxNv/ZrC/F9rCJ/4Mi9d/855+hdX6sELi3WmcMmx2aSOjF8 +t1kxKCDPfjKzW4OimrhIy/SiYUO8sI01Lj5Bpel2F9MVirMjh0eL1/1w/3V3q7unseFr7F5fxoK 8HmU5nMDZ8Hu1W6+SacQYeYSmqY4bZuPJN7ItftHDgjejTPpjEn3oYCVYH5QmjLx8YHPUn1hz7Si QL/eJapRA075cmBV/Tt8Pz9duKOHUTlvGyBvYZ9W/atzTW0uMvavWMjHCT3CHvaPkcZygKwB2It7 AxmPeA8rhgD20LcONcN1F7DT/F8szj3A4V+0H3yj7f9E3cdbPy8BlXSy2jmQ+JgD/X9n5n8xM//T ZuNIi+LgH2Zm9G+1/Z8lVO0d6NTML7yqA2sxMKlaZwg5+86pvxG6lrNhyMUrq9KadioHrWHX286T W8A9q87YkOfZJy/A312I4+e/N3JVjTOLsuT9deuACer7tH2fnyrUHQaaPAfeow5U6ty0437e/ZOG hLwq/GaOM5A0Ncb7ovVfpHErZ97l1j4Lf/2jiblNUr6qYQ0ZzWrd58JhdSPGNdMDqFfy/F6VrxHs ncxIzNPbszHW7DDMsX+zptKnXiXr3FONURxRC8hdeoE3mS9Tp2Fl2r92yIOKHMEZqbPT7do6T9Xs zShdxTBKG4NdcTbsoY/fqlID53/fmdiN6uqY/E/UdzSYGMlQUYuTkJ+/I6UuU21PednbFHumDRm2 QVfjuBvv7pwhutuaP4QBRw/odY87euHAhs/CZkStqxC41BMnoY+RG4VBWuu/jBjVrD1+JS4I2MLG g7Z5y3oa0eA1ThG9RZrU+u0XNGxCZNBK8Dnxt2Z8+KR/rKZ8KBZaIZhRTVs1cc2TTC/R3sAtRVoq ZOAKJ5OJILMsLN4InU2qXAJNHeLc2gyemjLcLoI6yt5NbCbBrfq9HnS3iqNEx4SI0H00HKYQ46Ug XHBYETmWXNdEN0ElmjALL7agJokM+j0XVXd9JhJP+ox/ajDhkhM43E+8LtQkxHsqnCLTVFO6Z0qB c/JrQISiAtxm7gmcJJbZvWuK6For3cbra4lypdnRegQB7rPpT5yojwY1i5o8ODN2ksUZUfI4yV/j CjOCVBewxh6LPgAY0TmbHhriSckGiRqEep14hHFGBOU4Cpd5RFYJOuQoBwmpJ6aEfYJsnu0qwkMo lMTRAib9OrXehXxSrOlameJo8siuszyHtg4nneug2uIGikTiontP284M3d3hipFDFYpCyZPuey3m 6knbI5LIs/ahIyp38FRqcnhA7JCFfRbsby2whcHPmajYHUox9QVssKMOCRSbpNquekZQTAfFDdCV 5xA25ADCHMBWn2tznphCqnIRmRnZm82pDZAACTEHhA0KYn8nZWTU6y322K9eQY4wideAPhGt99y1 8Nbj902hlQmG0LDgV4zZ3jPpgDblct4rYQld3k8vIuW/osEUEbd0dn8Eymqf1HOeJh3EuD65US4B ZzHHhK3VpgYO7YGIVX/UHQLwHCBsZ+rUfJL0JAduB4emr1Lo5MftYA/V4jgkxLW7n4YPkEr6RQLM pOI7vFijCUqwBn6uB4GAdAv4Jk33IMr7/zztbv8jgmpPgXLuUddgG8zaQ+c8hGEEeQYG726o3HCO /rixzSd9y+R1wlV/QPyX2O1EAHYEafeMmX/OrazhbvJIbS9JnQkP3TVcjpAX2Rugrbq/usWO7CLe Q/s78Y19jOK9O5zK17Ga6RKXDEdHD93nr47amQDSElYrhyRij5yyoBwqpyr1dtq7/3kPfggHouck OxV3aUPgPvu6O98OojE1EFB+pyaxGIa9trz29EyPgxkihg1r4HL88iZcPSXoIqMPIhk0NKzXgo5G ERy4X9/1C19SpikKe4RLQnLFJs9JGP5VulRtyoG4c9bVr4DTiM+4SJTLYXUli70okdhndg/7zErZ UzmV6pPi1PlnQizuMHCB++5yu7+6h15NWoTDuqmd0gK6E+Zcz3NIRGjoYCaF7exFp2UQxWlpLExT ndn6EEnPJXyVgJKn9M0c0CZikhIz5oOM8yk6aRHWRx2gxnJayEYi7DsJq2vteIYpDhQT80jCamDY Lus2Yb/+5fWoMG3yUNIW3PGaQ/bgJWASuIwvfuqUy+gwMxrEJVX7Zdba4j54QLTDiUqv23OLa1y8 E3eILqdLBT7VHsx8nzi4hHUbePDE4/OJug/itPRxBjcGl0wUSXANNaIqO+FmLGcOwyvNZ8fu81Pc Tsbfg+PsetxiMx0sXoigFEMSQbR3P/H24DpSiDOtfIpNxuFQ+xfrhBjMUQgHNMv9+QtTMfbBQjHG WQuv3vrdDLdRhubKbN7DDr44RnUdeSGTFzd+oBGQvOAPibeLq1+fwnNgDVkLJXPsWttSJ3dePV4L YzzZ8Wg56Ib7sib4xu7bdNRd82svvH+u3oHCVT8ZfkeyBgOoy/xTcrB8nwu7CiON9567cZLkaVUD 2+l4eWO1ZK9336bfffm+oP4KDjXFQRrSAzGxoVYWJHR5aze+fHDZFqXSCv8fM/NfoIqERORiHOXf JOk/9M1lTPGsPgf6W2zG3EXieIPchANHHWAMvpIkfe4EZTuwqw9f6cb+7A16GIne8c+ZmrVMmzVx ZsAepNhpxDoVMzVOvnf/c8bdg16sB9l3btRR7pTiFEdvvD6F8hd3Y6gXmR/sf9/cyBxICuHRydEO Kq1UWXSJZ5EkdXNwrHkQ9Lx/+y8T07tNcanO2QPMed6xiYKAa2PLHB3Y+pQ4V5fjM3iRrXeTw2G6 U5gT5+NBGX9g0QOf9flM3v29Jo2CN//dKRJxagnsVn0r/pymmYWwqPji6o+cvUibDbz4v2DvMt7e g2kvP0boz5Wk6ZMjVvXN1L8O4pysERF2xlF12792KsJeh86GbdR0p8fwUZ3DuD7fx29D4B7OrmkD T0Yx/C96sCsNlmtSzZVgm2nLU727sNtuc7g+hzlDIU0IjWdXGk28teBOBdTBZ2VH5sA8XfwZPX/m fGYyleRJ1vKV8/LV8XFioRYG8C+E7n/dPSpq4RK6igW9UHT2w/CK9PNQnMBFBLIz/GrYTI8oYDYP vFR/CJGATBBMXKqBs44IIvKw3bPIT/2SdF/Fd7qZeTqoe7lwTgIWVIi1CLwPo/udCor91biIwfEs a4yh0tkiTjVYL5eZLbbrZ+VUkA7h3VSDvdzeNCuuUSWIPCAg+0MEQgRqRhpPOLQbBTJziF74/eqY hptseZZ4qa5oDTom5mXo6bgmEnwIABAXwU3OWS2c6wulL/Jes6qV0/GB7JySxOuaarahOB8Iw6QI lpyr83EucyF4bFwoOvULIJBR1s+0sb9BXwFYwWRMO8h0ZNRdML0N8JdzzzV5159M66xqAZAwdqga tyrEaAgDXGWB1NDxHm8yte+HTUYqiAWvBu8Vta+iBsU8CcRdgxdTQMSfgubP71RESl5/L925XZHb Cr+qYxJSG8y7RMNFE/tx4bUP+ut2gyGnFiFpo0OOTJ5XnPxC5LvgzDCCnF9EY99iVeqbwcQF5qiT GIwRUSG0fIC1vV7B9VU0yOBDXvYRVwUpEZyq4wNCmBAL+KMOTOI2CQ7D/X8JKXTcEjrBpfe8+CIU LnCpnWx8gEKvy+Ne3+0ccjwr7xjHvuEEBBINVIRPn5o899Cg4BSpyV57+z59hS2vm18L5jwDb5ii PL2EozdBuYH5vYYvT9gXuCFgQOjOme4TLLpRxaKG+BzBli125BQsQa+aLiQs1iaCnxyhUgjhE+Tc gMXdLydo3W5Cs4bCLtF5116KumDfuTAEZY5UH9hLPejITmY5JAz0wMfZEn8++gZyoaOo+z18M0dC GA1abeuAv3ePM+1OUAtfNDKdy/4F2HvjDf1BJMG54TmI8/uE32CgoS7vk+pN2lEISXxiTp08QhXV TgnI+4BFH8KUJdV9mv270CTiMgIoCnEG0+0u8oP3mD7qy3THpbPg8gLZzsF8t/4MOyfkfp87l7uq ydlVTVSvXku7h6t4ZH3t9cB04J57z4A3fpTO5mvN00ga7WVPu8ywS20MUnpjCZI+9mq/Z0eNcONR 7AhDKY+5BvbQjQGk34N0d1Jfx6G/DquaO2XC08l5Roxv48qulMi3dvDHvUeVvpcLYqbZ/XW4NmGU ba2Sju0cnOtF3OkREeQgiD5oqUtcsU4vcLhtHdoVY/ysaV0jvC3k4GSUYANMxA+buSBpe54TBrJd w954FK+80dmFnPniAOYD4+n1UBWpEy3VUVttp60jQ2RxEezym7fbFttQGsgyzHkTWLQTgtnPWweR lmdjD2WrDBwOfhb2gjG6/UeM8AppOAbdKNLwKYwF53lMnepENepPdKzpOajI7TJPIodMyc1nSsPb WiZWNU4pTbuXp8s8m50ocPl6Z7plvJOCUegZgS5f2LOjd3zr06/EBw25knL//7cX9gCeO0fNxVXa u14d2JrOfrXXgoucf/6++fz+g/k07jPQL+faZ5SSsIe5BEXR6fU9oqkSFcXYqgFIew5RJ+H/NJrg w4aKk8d5NHzfhYr++3XF12vAMPc58pVSQbZcxBI130IHbw/00hD/FF/n4ovXPlI/tb/isiUcF6Dt OqyueqDLeH8KeBhBUj1lVw0aW+k507xwuvBB1nuWw5nm7erZ7vqvVgPz3U/3UKr9OmWgTTNe4b6B 72TxE7mvwr798w3NlbFDHF7v1AMmQkYTwx6NTUGQYrgu8NgVGqtf+T+VmyrxWvp/zMx/uTEvcmIF U8WRbP97ZuZf/X72zhrVISSjBDQDzqRnfXQPS4LUEvtp98T52vhWJy3U7g1f/K322qnr6TXh+nmp MWm8YRufaOafRJL24KZWgv0gP7/3hyfNDWPFafdbPhmmxuddCqfmvV834MwhWimxxX+RSYQAacgx ES1DNe7vuCPV6mGSV+iqNQ1StlO1wxT2a+AvE/Oom9TmyaWVuMViWkNdOAeGpL0H6wyOs0KJh759 hQvLm3pexJz2mbh+v3bPoRkwnPPRGwUPgHyFzgyuND19ca7kmAzc9ajvVUElyZlRpM2i1ASuqT/R o2eQ8P0djhTlbajm6s9nmcUJ1vjGNVeqpWcbI5TRpOa2X82+WVjHtjpBh5GX5x7ei5+pQdyIjIaN Y/+EjTohduA2VDj8mOuUxpO3vshkIINrUAc2bqwiBk87nYkI85EQ5DIFu9Su3QOSuJ31qF3lqNUv 9efnMq21kYMx8h5Xfk1jlzkodN0py/jVoQtUfh+qKPOMaAyS1sc/moC4XU30qxAnqTyXENYB4lAQ n45pnD3d4+ecJocuzxy+oCvuGCbU/wrnoLjKiOomGmGW03NcU+lqNxX83cIrFnqw+2I0vqYpJiFY 8ulifEZ7fMU7fIhfMUy3D+As8gRA23YH+XEx3sTOO63epC47p/xO/i+pkzcwv2+IjgjGeFWlUCLk N+aITy3hKT9Nn3tGHweWpiezZ9q1iSOiLjePAShoDhEwRatugB4ktOJ9c40stCgggP2IeRISUoqp +XagpBLyp6Z7CM7pKbBDdnFKEqi5NzSfdNH/NlWeU3XtFHjTojlk4zpfDYSnonHRP1VE+5cQvHSR JRD8b7w0gBZ/RZZQ3LEk1Ufx0g6kEklWBPvPQ149QqLydkqajySLciyHxvuH0Ow4wGoES8TPzg86 C2+OU0/hxz0WohDD+IxyFRRc57nTkTbbHf+tQ9TQ3S0n6LfaAtNuFATJB+mnOCcYQyfWLWn4eUUd rCmsSXwUxyQ6fB0HX0dRBWA1h6w+zzktYEAoQLlSa8QiUd+Ay8QZtxMaYt9KDOup71qf4qPHGfc3 0ciw+xo58/qMb9PeVxokFFpA0rIcJraMAPyUyKjXfN8vzyrRW/+7SEx+qjxMy2GZChLaH1InktGo hLHlXqOBns1Iyn95mStEJn8d1e3rdCuh4bpz3AKSv0/fFwDTA5TZc/2keDTxeNHnH9KWv+7efBcy KU9Dz7uuuqJhKR/l6puEJN2XIwSTnTCoovvP//Sw/iBPu29U1kUaANc5HYLI2fzzFBmeAhYfe3Sg guhBSo3nGvIHT4+nXt3O9nPQcVvS8BIEgudirKjDPf8Qpgy4Z6aI6x2I3o5xApIgz9o5BCxTwZr6 8DXJO4i9xQ0SmVt4957z6U6nZ+BacS65HBAFPZWjf/GGHGuQiYYxOClv5svDdNcelGhDn5VOsCRd PN9JBpSM12cEYHrKRCPA9oaitCllq9dUE81GWoocbDx3PHI7ini5t+zzwiW+ufGNZ005ew4hWO6Z YyiABmm3Y6Eg/aPjerdUoE/LTON7XX7egRFPujdfdxEgZ4egZNdLSZZ8ud8P3agacPsDkYcYFdqm KY9raxnGzIFVDwgV+uevzkKQeKEfh/y3trysZzahZ0CJBQYJenReLgfmhWW6a/p7kIf7vVzfi+jE vdqCHnIL47s4T9PYV6ZvsfEew2lAhjcXQXVT7Dwu/tbMXnexkEQf/L0x8KA5e9+MBJ8PWcbvns99 PnWyZQ9/L0zfiQUxGc/pI0koG9J000xnPtzU0+lqO7i1Q2G++4xkJuGdAEkMEh4klLqRgHmHrXN3 pRD0S5aqI0K9KhD10McUDxGfCQdZFUYwNB6rA6MmEfgAme7p5Dkdrm0XPqrApagODMdysRNdps+y uOQSTvuD+M6hBxeesB3VVX9mizG+SOdLRHQJtAcFqeieqxlOHxt0uH5dwpfxlTNRghJ3484U4yk7 ddfhngvMWOHOb2qIPlYz1cCzBvXWsMAyq3o5DeY+v0UqV72+U3subqp9lSNd1bnPBIYM8+GH6r5R fZvfvHxUVZ96NQgs/v0RZTnMVxQGa3FHQM/Eye7arushWusKYK+BykCzW6vhWRw5YpFonvbsUTvy KAV4incN6hlKsX3rD82VGaadWu0J91qv1I+/moA4G8iIqJlAAcM2Mejtxl/jCHnx/VdA7Y+6yeWC DXWzVHWfT0G/SifB6M0eKn+SDP+/M/6f/0v/q4/RFRo6+bt2/zXS/Cc7/VF1mv0MkZix/2CZBMLA PJeuHrf1UD1kT6LsrjjJZXoPGGpxXJe5R1oR3cNu973RjtY5VN792IU5G4ztBLghI3YCkyej4Q+4 z5rO+OcsNYvzCi/x5kZX/53CeNQLdN+TKRzFdkkXQhbY65ftAQ9mOgW+Ybr2Yz7X64yG937uua1p oXeiZYKTqUapSNs1/DKH81FPIFp0DQ/nHSc0XLjS5Kg+cWHqrb2wm1mfMMzsWjF4AMRtfYwl5f6k MeQ5z4D51HHhjkGsbD/N1imxhZ2jHuOBhHx3yXvPk9Lo4/O+nLBPjQ3VgoNpG7tu8ckXNrdOBjeq 9Hmt2ldrvwh6zff8zEEA1i0028gjmJQqSZjaxnDWmSFk34es9Xp4TKXP8ZEcRBh53ERHVihoQZBP 9TJCvFNchLyFl/iWkwd0GAf6eIKb32r3ddTXKvVGbfLChkx9vsLttfetr7OSe0yd+AQzZMw/Un3k +QeTEDMtFP9yjtXxoTkMTVDM6cMKf57G653geYGhGZrMGCh32qWhxfhZ0LlfrATiifhTJpcazeXX x8eRQYzWztQ9cdxgWEbWp7u7jitOB8m8n9+1NnzQ33RAzlxx3TrFLfOAYFOA/98oT/GzEWzVtxlO J/MGaXfD/bfQFsdIVSOohFCTmK4FxOKEmQCwjHAS71gPT379RnCQ8JijUHhylw531fTzN6U7Bbau Z+feBwZY3hilNHgZd8Nzi3XWd0NlmA46Y68qISm61+gd0EtCHg7D9OEAqcORhvbtdneh0004bf/j SuCYktsgZMezGMmWm1gExzP/gHT1b19nR6n+Wf47cojoYZ7LjVGnv9tgE8IThwm3rVvXRJ59kZdA koH7dcx/R8zxbgiXxFog3EGKfAPHJFvnotXo7Sl06ZoT2Ke95UfQn2cgrkIxnJnANAP4+d2oMWRo 528Khbt01UE0XpBru6a2y8YfAJcH8gSRtL0ufYrMUmwzMJF7ywnQ0QPBYTFtbi/SHUFQfU2ze9eQ GhSA1ElmPhE2aaKZTzd5qn9SCLNrFRWtMAWA3sDTbtPuu7Qd8tmRjHsLH4Qvn5zaOYTgz7pFTpG+ 4W47263eh5BDCETe4GPfkQYg9v1sd2wjR95+n3DzRPqls1F76/y9P+11nr8ga0WlS1gLXENXr9vK FmroCMT8qnp6j/4knF1Nea/lltNQ4lXen659TV4g3Ge9aRcT4DP67Vc/5w9H7XTAJMcDHetof0cm WfLsagrF9W1JTDNOsdKzds7pK4HUIJ0ykkzzGYXprO01n5Aaj1R7j5x7sAv3R82XAB252G+AK8+m Ld5w7NEL/P9NzgJPC86PnwhpIVIgdL6zmfjJxJYFtCH5tt2jNXd+Re+1JgkEpP03EXznpNDnURLA ugYiuwr12dsZb0TVMKvq070D2lkbtGgrhhSfl63LaQdPRXFtZIOrVt49HhROOwnVYRe3mc+4cp2d WLv4v4IrwUD8lvJd3aGAfH2xMYL98/zSiY5tx+ZXPAJ1pxqT2ft1ysma7qVeSyxi1UHa6nSjo1qZ h87vQVlNDlZe+UaedllSYHWDQjMWDLIrOH9C6ofYOGUK619/9z2X1WTYj2iHamDqzYSDryAfGxbA G52FtvCEsnkuCRH1bj8Avute1cKClq+Se681wU/knJdIjEhir5o5k66yv7gdngz3OjlAjQZSgHSM aKpIanJtbAxOcA9fzo17mNcgFkiMif3+b3yZ+kX9WuHwnTfIrsH9lRjJR/zYe5TQkPBtUpCCNUG/ B659WC8n6bvrVh5i99yye8Fe9hI5voSxHkGSjkHWxF57tXWaQqeiCMfEE+P+cfF2cTS0HuboBqqP IuPF6BSNZ+tU7XZR/dI+j30k4fkZyN14/+Ae83SdkD2MsRvfSQlGZHuGYux93P9pRoLckUjAQXWW YZyHBF8zLURtRl0Hrt851gN3mXCf7UG9vk+uAbp06iUMm0ULwVx7MBfvs2Fc69HB93jj2JGgapBG 9ODrF7ZtuI2fO+YdCAOjn06J4LvhTSLTdMuRd4g+1uwcJ6mH0i1VHMrGzl5cUZ9ilQuf3APifW8K TQe0Uy8N57eyR6CaXTUwtGoKbZE8mudkf6l8fyQ7TvdjcibdAxTvnXV3FyFU9RzmLoT2bVxNqFPZ a15RN3PCaA5+6P8xM/+FOdlpEmdXgtC/dWb+MzOc0rqqELUpI+k51nOPukpnj6WVanQhBnpwqjkx lZ3sPILuU30ac3JH6JXsj1o27ati9NZGdpBZFyFfRiyztA0lfgycfPah1AXdtmsHz77exRZhOp5V VQrOof85jAaS42lMtO5lSIrJW2XXRD8i9z3sqMgGzr2hX5BlF+r01h/vGnsF4ZmENWEwxR1s1x9X z5499vq5uu86F8Yyw+mTyXc+KfPHwPdAirCQ4foxc/CVtAK1YmKBxsTs6ib2yeqsCzg1oXaojbnu nq90AarfU15M54lqCPMrHbyHvFqc/p5fbwLrxuBywIKykduUzuH27kNfySjA0zfEIIjQQBoRW06t SXMGEYfS/MObpkfm0mQixwZeINhWnnFpPAUKQ88Ha8ZfO83qPD4Sm98aV5P6IUFPQPzkxmFbS/N3 /etCwG4DWB1o81Ra6cxt6iMYO/g53/bQ0IvLzOfZQFyuIDlh31WN13VCbg6L+eQRdr2/E2ne/bnW 8kq28/CA3sa7/uEPGu5vFOsi7p7XWLEJ7NpMgqgs/GY4GvwtznrWL7uiL1FYf09Px+Nm4KDnEqAS Ec7eQpf44GX40pVLM+AO5ckJH4rRyMKH/fbaxYsENzjJppys9geYt8Eml4OpxscnH4DnhAXmJj6+ iEBqXXDtuEVh80EQr9+kjj7aP88oYFCJyhwCScHn9XRQmT7LX44dTZefbxfQlqVNOE4lmQEz66Y9 Sa4DBLvfTlGaFpyWI6H7+L3kySme4GiZBrgYlCF3l5xcHHQq3GTg3ovffjrXz5qYKhwMDVEBOcYC aRf8LsHEdj7XARynqzpF/rBjPN0tLUocbGT/ipU1EMcGp9pH3KGruBQAcntK0weRPUjJOeJ9vkBk CPPO+KqD7ubRmH4mrtPrx8ng5/++0e5zlOvvROtXHL3hJMjm/K4HFM9xn4vfTuYprxVEQ2aqx/4x 92DCW+gLhZEHXQBOGIboXa0J290YpDDL58Bcuz0azuDLvW8TcIMk0CDw1s4xJCrQB0jSNehVIN8i ERICNOhEkbhRp5lowSvQvce5bxjS6Ja696xhuG0D+j9EwB232WJZEssIwI8m5l83BYEsLyOtHc7D Ot6nZlA4pojPslM40Wd6gjB/6ySsFTWDgCQ538J/8uXxw0/ay5WeI+14Cl0g/VXJK1lIOSzCCRFT Ajqqc3jmHqH8AYF/hmME5PYsEPmSL1z1N5LfA3HkBZwTHC8AhwMAKbe3+QyOVdX69F4U9ZSRMMUx Y6ef7wy7BboEM30ebcF0RYenO4wvERX1229ZswUd2XUQqf2bvOnvt9F81Fc+z/ymyfusa+Frrqkf EZ2rNuKz3VWz/1b3Xt99at36GeQh8N/DKQ+3xCIdjLZDYhKLX56U2/Xz/Tyd6ZAiwZlrGNZFeJK3 aJ4TfLduooKS9lrOchHZAlxLcOZf75kTfQa8TH26KnFPypTH89NtGCYLiFpfRMNeZzUCG47x29Wr BQRT9NPrQLPFFy9WoIgiNw63C2piuncMg1jz7P3GDDqnckdRJ3nb5wED6YQl1ZCAqQf+zVQkYufV fk+OFAzB4Cu7GDegPXBveWbIKzekL4gba77MFXT2SNll9eh/pxLpqGR/S8YjcbrCQfMdgOhu9nkW ZmfBJof27w6v6eN+FOBeRrwyXfJIylbokL+84z0U8/sOXvSgWfMehAduF9jmGrRqYH0ymumMnELi XtUuH+MdT9x05w+BN0DM9jCPce/MoKmNAJn3IZBw1wMzc4hf5+N8BcQiDAXa40vBc1GfmAYuF7+V BPtvsngyW/pZ90n0fj2N/Wfpnjb6m2tmDVWkwQwLa4wo2Et8v/ePQQqzcCfj097PMOLi6Twm535d uNF5hl/j9a56fosV47bTNSK1xXQ6s6KiSlI729vUKWm+XDCnamnNO6Cfa1Fxlsw5GDbL6KPNj2Y5 mxfH4Auzep3B56Mz9gfTu3Hhn5TlK6G58RtKKTvp5n9iSG0+ebqLP/WHQMSf98lg/cxDj7/VHjoy iPvUVu2P7fD7vBnRGTNzGRK83O/VFxowKa6hIBERnOITzxrDs7Xnkhh15aCj/s731SecsNfL77D7 iJ2mR1juFqxc9cgU0z3YPeuowK57sLm/Hsi8hIEb8wrzPvX54M8+2TgwUZW26bydMkzcuBcxaqr7 f//5557WHBYkAim6P7DP3bH7OYOz5/oeAZzx+P/pmf9SJet4qjfO9frcGf+2Gf07+aTbCQxGdc70 oKfAtMU++fAcRkDpl7fZQg8u025sE0/Ghp5z5qgRNTrqa0i0Qu72x5CLB5aAiTbzb5xio+D/tzHp HHeXUEXAmMqZq6sp47PNdU6YrCXG4vMeTUxWiB+Es67Y5oD1PJ12sO8eerN9fr+aipdz/2cMUd4B xpJCn0mRQhH4fCTDLJEi+PH3GJ5wj131Ee/AOWonH1oQ4T8vtEjC1JV3RrnNr3ad4cnh1ucG9RTn shNifCAdKk4+MXId2O+AwajBtJXz4VWD7jqYPeEedxhaAqIohaj9lxSxwn3d5mu6rIG7ulyO5sCu ztp3mUV946hzjF8RB6xIlBkcSP3B8jzsqK8atqDzXdCpHGvqWJvShcEzZuF4L07zKtSTaNiSRIi5 /OUj1AhsK/0Ew8L1J+os63Oae0UdQ4edNjhY/TUOn4PKeXPc6eOOWujLRNLn95gTi28zhD2Y0WYW hgSHx+RDPZS4kwd+9H//EH5RPRf7RZi9xSpFK2rYp81DfnPpptVkSpJMz//VILG4imTz8XUJCgyL ZQtncpoFrkxtL4z6fSn40xzF745xW+IIfQlFSGw6WKhwdMygCzE1s1vINQiYUtG7QF6YCi1KwwMi qpzY2hHTLHbib6WcMIdIdB2R6et5aYuNaPozEwMGSOd2GBkk78lhlMpj/ROO5msqrKI3N0lHf+aG 2qLgFJFieZFdgyo62wi/Tav2NNqsCA99lkau2KUsybejVUc8qZoZgzjWnmm3PAEoZpLklJT8c4La IEy0D6HeLqDbPSPP/y9X3e0kQY5C+kgV0XzF+Z5+IbF+PJiWcHg33ZSboQjd0eE6IecfYEmiM7oF 1Jp0KvgBkrer/uWx6WMo5Cq/qBAyNgoUyf332+hHwCIohlX3dZyXERW0Y64EzmlEvir+PP2Zdj4y TPkKzqh15mmTVS84qaHwdQ23/dDgKKfBL5dIjrxjKRoNu9H05i1fGATnbvnLIAlYwexQUh8x7Nr3 4p7Q1kFKvdF8gz+XAXav37nNP11N8VrjOVwiqsT6tEwxlH8hvk3NNCSJCN+EgED4ppR0kmIcOHVN P/dksnBgc0mcyp14BkX4ErhIexHTi2Axw3dJ8mTEun6veGrNqk56EmoM3qt//7YnR7MQnNIMRgWu e8JM2tIJRWIDGqIaJJd+EY6lA5soUJLd+rq2MzgM3sOLDqHTS3RoSLyus6fFQcCjmvVQFgW7wA+6 HBzxnQd06wBL+BxnCa/p3HaDy8ZhIia0/SFCaVkiEUXVLR47MmMzjXKHdlcLEm5cd46CqN79tObb EVSnSzQJMn9AaHIz0SEBoEjq3HN9Kv2sD30QQzw6LAR0d7RlSyI5g8oz4ZrkjyKWMmE0A8P7eyjx ogLSuVafnzZHZDK56NyZ9idSgfWbDYNs3LsIsiFyMKhFGWA44aO6c/eNSdCydId6Ou770h0pgVzp qwNzO68ukH8PL/TapxpFgJMMDLVdnRh5yO3+4sfVjwmMxi2unvCyDqFxpde5jYm9TYrqWKMdNruj 1mcqcU99rn6J6vbK99MbC2QNTYB1YhJjE4PCBbqzOseTJHZXFhCljNAZpRqygr5F110bHvcaHPb8 IR7afS92+synC6l4xXsPFr64og63LeIj/j4nX0kMO8UsheeXa326BiYOkdiFfxEp05ByO61xTTC+ OJld+7cT6hS3QneiEHMUCB8E56iq1qY0g/7nfT/1Hf+6Pc1hxaD5dkx3n24S9JNM4jJOkL0VywmE MIRBgDynaGQPhDN28talnsueJXkzLwEB5x80t2MkW3vfEQLE4j0+E3+Eypr5qJ6+6ogWdPnA+6dF Ds/zVDxrIaE+MFzmxoHOqpFzssdk5rEd3MrhFPbq7tfnFG3TfaBMJJtBp+B9xhjPKn7nP4PGerBh V9Woj+SHKUumK4mEsMU2cBDeEf7oMudINfAH7mHgR/tc3p2qEfN2PCdjith2RJwTs7gM2WYlolOy Y7Czr1DdMG5qrr/ovmTThisNCPQG7gG6PQwhrNl/sMpnHwAWCeMxMDDntZbmE8PYZnOUYpYO4w7U xJAb71Pk1HuT5AYrkcIX3nvlMhlYX598HqPDu1bZST86x7DX/rKPQX/AM0TnWZoHXt/akcAoMGqM XArNkVWdv69k4kNJ2s2RzvxzRlHrOf5/NfM/08z/fAAXFwxwbgH8jEb/Cs38Rzyu/JG//01Zh+5B TjZEAtMW6XGkVdVujGr6g9e4cex0CU4hvE216MGbe4ojd2V9brT1Dx603cAFqh9K9cqBe0pGuX31 v9KseRjPINpU8ZCdXD9HL/w81zD76SFSYw98jeI0pqKV1DGfGIPOs2yOO4vNLQg53n357l8XSTnD uajFsaXD/ByYuz8xYbBWUMtWX32WT/NL/bLWknXgITMhl0LMlsELXAdz+hhFxvJftZHfesvHGJKj tmRNxzJMnJvfzaci5GI011A1DfgJzzkfTtrXYBohzEYMhLG23t/7XTAnnIZIxXaZ+7G8J3kF9jAM 5bG+2p2rLkpD4QvzK8TQDk6P0/KyTjFgm4yGdm2nD3zbH8hdCZSns/04f+TWHOR6UuzpnXTF7NB+ xoTBcqcl1PttfJz0n1OsV5t/vEv9izv66r2+kYVnAMKk77iMXfVLXf7W1vp7p/xuzEumyfynbu3E Dyf2D7rqk1r2PwFE3a46OiQaUw5N3NgNxCEOktvVRDyTGOkmOEhHuIi01/HVGH9G0yw8+YfUsCHy HXzyfqYx032SfQCFV8jttL2nN4RkCF+8WkQIN6TbvVgRbeYl/NQzYXg4uJkkAHHAOJ6DZm6/1Q0L 6IIfT6GkgORTDWDwZaKPom0ChE7ZmzgOMgqAhueFUAwVCuk2iSR8iS0uYjUFAZe8bxeHdGyTcOOc noXr2SgIuOOXSh4Vwy4TAJ3QR8flBPcz9czuaOzSIqDLLrKngecEhdqJX0WqXC7uKke23lVazcre r+mQl5KXjgGjosMgVjGWU+95ayDjCZwznZdqIYYvmN3hnK57wIILkSv1xOEYt+mpikE7HN6n4n5u EZlwGCTBAB6ymQPS7Pv6/fVPQ6gB8n0AgGd38dd5zUu0TMTQHBDlJcBh8Eqf5yHHErFANgG/vtd1 DpykOD/3jutm/BKTtJhYtbcvRy1j+/SKjP/a4uP3N+6pOW/0WWBxnO/SQcN2272/r880Cxe57yCD GjRi0Zyqis4hJX0M+XBqQu/tlDeJIsuiBvJ5bs3d+LpJkb0WtwNPgh5GEkYFbQ2AoFnTGQaJBgcy jcQ10pLuDqTFHfPR7rOwgMdBvEiD3bQzLMHpJC0KaeP27VSgQ6rF+0GFjlGSgME5RKcJOwupX0Bp S5E97ZzNFVMCfDQ4eT2BgRPXJ+AXNaZDkLBqzA0Se2PWJ1DgDyioQdvdK7zuZAKSR8sxVuE25Lmi jM+Um+U45jo3Pbdcy+DKq4oC3iDn355TdFrRcGuLyNfn0SA0WE5wKJqjQd0Lujacdl0L34KdgfNS a0Ckzw994D6q+v7yJM4I1J1m5EOwsb/fioKUjsG4dMWdj/M2a0lBTTWHaGGOYT2v9aIhF3FaKwee 5NtlKPcQd4Mfn9FfgbX36aYVO+vPPsZnxafnM3S0Mb8xchxzJ0kNRbCHz108LxJp68Nts1CE52Be 30lF7gc6ts90h3u0qh9SjToZSBp9CKB07IL9TDuxwQXAa9+L6oFZ4xmnTwC9SdXcU997UHFGO+oT EjFp/3/rDqFUAZUIuAUO315hNHD3ZRKw3ZG2iQvXX1/+rKrRTQNWwP7Nmik8QjBAZJCX1zOPtd2D 4jRsoDmkwz/1sCaE8yTH/+flVZSy8OIWaeLCn3U7eDpwRJ2JlQNu5UTU70h1I8dxDQZDNL07SaRE 65qqtXQaTzjOExac7H4Q+n19n8uXj/h8DI62eMZHr8dDQUucYE6NrVtNP3c8GZgQrvOuQ2N9qFUj CfKzPJxs8vc7hSBmJyB+S2/y2WsZTeT+0BquJIxrYbKa4qzYl/tKo5njHbKzsqNmffHUnyGcFg3M Sc32MLAOZ2BOHDIMXfy8sxYuAIZVOMwbV24UZYl8DuOuzIEXn6LZO+NAhNH7h7B+05HJ6e6HM0pB TUlWTqTwK5mxh41dNdzVcwUIMlfibg7kKpI3r2SYa+Bu33/JEegQ/gGG9gydvdjiVy7OVL2WmGzz WG0a4SP77/Z3FQx6o+AazMy+DPaX82qZXMTgrS+0U9CXuJwcp3AHViwUF2jPlQ/mEvUKjC0Mb/ZI ZMkKw/wWjHv/Oik7QYI7yMAQw/QoX+nqhQQ8rbIyFGC3s4ZmfWoruHcUcnid4kOdZqcs8Tn64+xM XLBLrKgD3/HwGObzNv6fM/OfH8yH6vf5J/U09vK/cWb+o41B6uCFX4xa8c6IH+7347oT1W/PV3rZ DKdakoEfpzxt8bCAj9u8+Zusq0ouGGDMH/fjodwOF1c1OKA0C3f7OZ+7T2D+cz7ZTM//j7I/edWt XZp+oYzXAkWwrhAFQURtWWEN+lcqgg0FOyIqYgFqS0HBhh0bdmxYoaAiqGDt0bBxvrXmlRG/HHO7 D9/Z717Peua87zGuIjMiMoKSAGH40Kl/mo+EVg8N/HLC8eVuazAneTEd2t9teHGnwDX3ej1BMlYR 1KqqXnzwM0pz3K28g3bC4l23kamjoq9hpVLuLz8Drc2FXHjcGq4yV9DJ42ftoWVMk59Z572rR//W q3cPEP/gBFeCImgWjtGLPq8vg78pdoT3DWH7aVS7cRd0ularaXqsjtK+N255j1lfHOEjZg7TNBcX OsPDiAIxu0+j4Ob6LuyTeynN1LBlrTBPrUt/DNF2oicniezzxJ/jSY6KrhCwwxy5uwDOs81xpUsD 9V2TdPJgGmnqH0h68LEfHGfoq8HVsbpd3HqaG/+zAW4bT/7EQTbn8puyKN/ETl34uPHj3mSj4VVX 2HB/zu7pHIYpxTp5yAhFca4P1jJXb/Hzuf/pinSdoAwuUbWqzTYEvemZRFAsEJpgCOdXdesu3Iob 0HwdcKdIG74O0o3+x91aEGM181ssg+FSfIG/HXNDUcLP9/NEc32BdtBQGw5n56WUFz1BPPqYUPwZ DkjiQ/rYkKLLYo62MKMShWv8nUw2xnEMwr7k/DoBCv0VGfkBqjUz5wxegr5NvLH3nI4/6wGGelfq JlfgAECFU4uhnhUqnTSacR9rbmE2vcNwWcCJ0qTkB8HvrIMSpO/IDI4AoWihjAv5mbrv77qdYGha 7CWVfABdmt9cDphWpcL1clDOPauDsHaREmv9u0M/L2K1C8p/5P2/Rd1uXgzfa30/NZj+BU+Tk8pM u2vbDSIlQTKf8S6O6Ew3uQ5RbN3szDHEst3L7KsJnEV2MY0Y55HnGPBKl5WiVhDAcwB2SVbuYYXn /C7x0y0ZG1+NjMBjRDWNOTiW0YRdFn0dSfrloKMdY2QDGHLFTLLY/+/3jYSLTbp/A7VFNqZ7+ccs OjnBZGTVbtg2OLTdvKE1VMsiLnDqahheQXk65CiERvtzNpVMZ2y1T+LJYTvcWsRgWUaSn0kSQ67q U3trfb4YqkxwgT0TVML5P8CrQTyucvX1OS771vQ5dCCsHOmMIUhBJxjp6jeaRM31qgCvcyBEAJiw 75CwtuoYzTngzT4PktzSCXOE+N886NoCmu7l+H9N3Mue7yGlThMQiTlT8Gdy8NLxPQzAsRiEOrvh mWu4gRr3DSwYgvB2P+qouV7BTgtIpghVHu2eIpsXiASOf+3r8guxPFtEJ3gPNKqYgstcuzycc8cF vvHGeWYp+kmmWo1U/g0w7VrtR6xENRELxRyOyZp24rpv7gcstLd7AwijM2HND4BVAilT/ybw1dF2 mFUD/T3oly4oc4P0vs71vedICnKLWjyDApE3NYLSddjN078MMlGPcLne9tAIh6ITgfH+yB4WmrkE fn4TlkzCmu2cmURXAt75tYxxy/5I9gHHKHiWF5i8zmfAPHrwhL3J9KznP2SWa+BHQ2MTO0JV4dTE 71dHtmCdUU9+beJ+TTRdg3B9Z7/k92CveQ1d0dB748Vb1NVuk67+qB2fb2pQyz2sSC9voc+dSdFO gp0wFKQWYjE6nPmxUoYh9vy9VK/+tlty3z8/86mljNTdRev/I3G9Oion1/c/wp0Ll7hrN59iiqxP yEjDSPaT2YrmS4iftfBbw/nD5VlA6qPwQBOu3CRIPlILPSgUIQODrhku71wYRAAikpJf18CKKGEy xfj6kDjo4Ajy8/OAKqcWk3AkHdsuQUn3jl9uZTxy0oLmNuXw6utfV1AfZiCjKX5uFu6971Y6CTAB RYBVKgbF0oHYcZKaVnQmqGhoYPhrLWws7hVYdS2iQ2ShA6deTm0S3MO/pef8iKmNKZuv2dA2g1on 7NMa7gHKfyYkD5c7+4vrFPBNjnRaJvz3emo85cWD2kRsIs0U1p0uHoUSTyY47mtY0oiI+hHXDDib s4MyiZ2/12bX519JtO+Zw4mdzFErOKj8fpk2QuwejLabLVC47zTKnpknIoxTcAbqMIDKXomMpMRD jSB37v0w88ttXVW8DozlG29oHwhDzSsQjOwU+WvIJbC3KgOeRBTC5Q8uqfPzvtKgLpZuJ3cbSDjH Hvj2RgbdBZgvaC6x68BdBG60NbzyZV4m0Gg8J5kH1g0ZKrw1z/2sf/Q6jPP/s7vx/+aZ/waJNd/v RSYdjz7n3zSjf38PibEJI6cP5GebqDe6mtbB/Sw+4jA+mMNss9A7NH6jIc0cvJ+DS2yGQJD6SWz2 VfkwYxj3hKZHJb2xNE+7bvv/D8vDKy1q4l4lzLJHA5Pnct+ZIrYjE6gSh/tH+FVjl+tIkBaeubFS k3dbOHdiYDSEOwenTJyN0YCQs2EvM9PvVdZJIrpPd2nKlEdkhpl3rR8zOx5Y+DJZSAuKxk13UgJ5 QmVSDfmVGw3nQPsy+uDK5zRbK1d6e0i4PsdzYH7twp93X7a52pkKAAJ+gxOFwo7AlzHskfOrGVA3 zsAAW2IjhkFEyANe71CHdiORYmPvf7+Hv72Q5mNFtYlfuXd7yghFoEtxGMStRExHqheiZ5xH0WiQ Tiy/7i8nf+j6c+NAgrGemGnDFZ8ifT2i9D0sSdy5EFXlhO/XlMOoweZKteuXTMMQ8j7vGZk81V9M /OA4d107xxpuPct71enscVX1Rw47pZE2cR8+OWTNP+1FPeg4SRb2OgnpTTio4p58kFdHY2AqCsiZ A9o+Zfy0UXDhcggwgJoG8mUO4MdA8KjEAQSWbbJnivQURCw6pjPx6tYGIF3iozkb9Fe42hsRyil1 hFsXQZ45IA2haF9nGKw0B+DAsQ4r1sl7U/U0SxNof51SxDHZX8AJRcd9gygd3dQxVQ0Esu+Kj0Oc 4dlrnfWUZYpaTy8iABWa0GfBT7oBKoQyD0DtbvbeacqeHLvSKRh8mkhW+PspPVxMiSVHCVCRq7LO SI/b9+4iG7drCkdR8TszXnQ0Rfpn/+v4xooi0ADdU3PvSNeg8+CNpjFKWnZ0jY9nessGOz71vd+k GzpaP8FXOPkA7OXjbxZUUpFSu4ANZ0FRA6OKPmsn0yim7RJdMhVHAKKKnJoXYwJXoCQVxoPNYQ6X VKkoQb1xQ9Nv2ggKZS4ICSeEqwI5gImMsBQ0uT6AlzmADUTC131moEFPx6B/1tX/rZTsY+dMJLU0 SPkl0su4UE8npDTBKoCENhlnmGrf75omwtURjs7P58mwxU6MoQY79p+NA1JSkwUG8KwDK3WGfTmI jz8uLO1qMwjAbPFSx8YSffslDFHd1bPWGk5o20cagePMuGqzDZ5tced81NwJ1v44nP4lmXDYAds8 BEiJhG0BDJH+G4R+3VHeveP5iiwTuMT02ffz/A0eMnP0D1sI0tGvu5nvhj5uHkwGeYeW529vmYTE dnn0B0hx38l3tK2BYCRoPBy2TRPsCvFJDgbUk4MT1jUYrqMK28+0B7jnBLgalNuuBIYRdZrmNwiL p2rPKYGXkFrNGsX1bpqOfvciuwR9kQubFPgrRvS9ihLcyprNM3jLYNX6RKx7xdmLvEmXIF8hckpR +Z974wdQ9weV+o/+50vM0IG50kE2TzVYOC6RBPQVDnk7d/qIaico1ADP36lOlCRHTpIuOJmci332 DTN7MPty89UInGMa97vEHg4c8E0meTEEH/iFg3ykIdSNR+1BkH6uBIw/9UE4hLZvODlaAc5IOXIC RMSMtLp68KBBxQl9KVj9eRaDRM9+0i0seIeEsh+2CcJmukh1jk3EOl8110CtokrROH15pMCcDOKI 7jH6RN9xsK5300lNncRm+Kl5UPUQQPe7HUnct6DmioRFP1d7CT7evb2xv3CSntcZnnEYElsSAWm4 u+mZ6wNv5IHIFh9tB0gWngjSzLKO3k91C2ebWNy1NdOYU33hnLhMm6cY3j0K1zWHAFowrtoiMEUK J8vmBL+/nWYbL59aJ3/PdsRAv10fG0/cRHCKilPsTzmpKf4WuArrSGd0DghiD5Q1n043xwmM9D3z jSYUW8RHmJhJNCK67bZTWWQoQsU1y3hB0e+vp6mu3NSX5j4H1cNjJWbIRFYJzJEENR+heI6hNa5N 2sTFleCTOggVNyrMsu2E5e2W+6bwErbtlRKkWitv6m8PQnQvaNy/PrBORtwvPkgxdKu6u+cwOxjg hn2IanVgSjmI7S1ANHMZXT9sTKlHVz5cnPFPiL9PX08eFmlcplOVjPgyvXNtN36om9o5NxMTfHKy VGV3j/+Fn3yNaAruIMaCBOe+z/tzhpyhZwhjaTyuuWDKadlraAeh+6MDDD7M2bP88Jk06L3NMPpM 8MF19DBSn81sHuGZD0SbezEW2lC3PrUfhSnF+zzMJUpGKY6kKWO9iWYIOWSggfs4EqCAx1n1aoji 1RHKb9/9/52Z/6lG/7OZXxJEK41mGan922bm3+gwAWyX9Dbn8GFGsbFQPaLhzTqls64KNeyEHKq/ aORwYc6Bic8QPk4jQsaU+z4ZDP/tX851GuYdxLdR8PtHS+H+ZKpUx7YhMhqj6RmGMPrwk0nQrpse 3gp7Fq4s/jEsspEEqodpEIswdGNN/RghKZPILg1CJ5h6bpdoxnk21pSC2AGR+nAVv06al6Mcd7/d ShYBmvrdO7BW5R2O1odmD0Y1JOBGdqJSyoT//la9nOkt/t8D3PNRxzWvmlXJi7WTBF4P7v0OdDo4 Ex4koRSLNOVw1BV9MFzJei0AN+Cy4B45rS/0gda7MNw5zoNO1vuqFQT7+u4xVRiqTVzExjI7lwcQ SbfuBSsZqTS4eV7RiMrSVSmr2SsRw2e9peJAtIZrkK+oFEEyCIuT2V/9yVeyED+XH6zeM2Wu5cID Bdxhd+I5MLO1rt9pufu7kEGZFs7oU+/48mcvvEImX7XwoE9+RfP2zDZMvJPDFBqFne4w08PYPMIk qOf/iUmvj3FkiCi8xUk6GjkiU1xTOBPAlnH6LEV7L2l/Oa5sIciP4JseZl71OggicPkxBlwOueEl 4NIxgrrFFE5Sof0wO46ro4OWe2xd7uQGfU3BfEXz9PQJTWVuMUuCC3dUIIn/BOtyRTytWFrfRQYO JvxWLN+FKotCzcIRDTTYe58JgqpmyFHjmu0N0MNJW9EFP1jE0VzNJfRiZ6T+yQ+WeV5gW+PUgxkk RcipOA6uVwjPgF7Re9C33zMHHwk9BXZRxJ6X91nNyRjtBjnrswJ9OuQY0I6fUOzgOTFYrK2CyLx/ GuDxh4+mSjZF8p92ixbKV4io2+RIPusEJ2O1a5YLNouX751wRU+za0CWyxfgTE397dO1HXm+xQ0U e+SKDokW3ROk3wANbCRWQtd0tvuvw9R15mwYyr/UR8ZBqztqVBCzqwOICsep/GeGXejbAW8Thh2X lmeU2OPzuUu1BFBULZBYgyS+RiHBfDuXeyoO/gIK3wgp1Q2pIk7aEdOP6HeLAJsGEgjVGahX3WU/ Th8tZGafm6+I9flM1VD4RphFWB/3Ck3Bs0hQmN5RoumKXBVMS4djm+LWN7kt8WCXqmFLMnqfAxC8 3M7jTodCz+VKJXJx+xvnOBHpt4UVHSe966B3Kt2rV3XH08cZUmJKZ5/EgLkOgO8SorwxpRckOZqK fxSAY9vRRSFkUGyh7EF3Wgn1vsJ3RjXnNFGYcd4eqPNU956QkHAIJAR3F58XzvteBG6myKcH8dgr fp8PucZKGuIW57oIAiN8T47ylM3TQzauvscABhd4OxTLfA+Zs1BhQJjTIvJXdOVrcNXtIbTFifMk TgWA9BSxKdTZQqVBEc0rYuhY40zWIFyCfNSuDm0eZxJOveDVPYgDUB7hVS3mYAYNFejjHaRIpKU+ vtem5iSuKPac3ZgGBY8DovgfMqe/vz9k/u/nTWeYTBR4eyUdwigde70IKB1r5Xh/6Rzasevkqm9M pjIOmg55N+Gpi+IADfzcGDaUjjU68f1cIzCU6eEl9L1olZ1GiRWQbtyLxi174J7xjHT2RbwZyWuB oNQH6Z+CqctNcIbd0IX1i8G3scnUnxrAj4h3hgUdOwFwAsNOQUHjtSmcwjGNSD3RM7yZrnTZ7X0l nLArMjmGpWjf59Of06URHKKudaKII585+puDCJvBv7f3tLGHNTrEzxnpO+jK/eKFZCLUNN021xmO Oj7cWOmNaF73Ts1vJjWMCBIWDD3PL+5dhEDvgZjss14zG749fvZeJmTlkOkmft/+w2VqNGt4RCgY /srKIJfEOUQ3LNLIEdMOkKYU5dvw6YdX6Z1NA3mKdEwNcRqEWX0lMQ6mYyWL8ieRV1FLvu/ZYbLw Ot/yGfH0nofo4TakYP6ocDl1D5k4S/ZincRD9SP5ru47ggap5zx5hTco1aSUqJC4kQFn3li0EUu/ TtqdNJbcYqcBdK2uuVKQ0qBjxksUnb68gj/VdBq61xq7uqVb9uZCZV7nx0yQ0SlOIX72Msubw0pv nTTad/FZ/5yO+FRjCz7Pb3Uj3cPT5lafPBxhIXMm+Ew9Pa6Ll4BwcjyMd+/N03+7Xb5GJ7qGbp+1 9qYxtLhXaGfwinRMWNCT+E7nlwG/9fHs2bDHv4yQ0CghDV3vda5I8lR8P52s2bH2ilPSB9YUfc1Z L/2zNV1Gc4FaavVQ/3fP/JfaVEGRQDpw5/09A/9ltv+9WaPYA9qZlJ2rku50cCqNa5I5zwyNoWdd 1/XTjRfl8J2Ak6ckwy8Ecdd0KiM8TBw+pNLcb38ZIQJOpaw19A+YB7ycIWhoRM/mK2kwuQ7/GAwN Jz1+mRBM9M8TPEJWJva1CkI7Yg9Zk6jux11bzjF0fPmqiDQ4Jn4tE4ySw/LnymZjUR/n72NiYbQe +NCFzNwGaGEUY3Oy4VxjgV2vpFZq4yyPKZRdNepVBhixQ8NI4J2W954Phudzm/oN6mS+xj4U2hAD Q08y7JlWZ/b//7d+h+4inUl7X4aBa3hVgnfRAyaYgnIaV2V/tPtkfdSEL9ZEliYqPaThFFNhvM1t zycuTooFx92oz2GhTilJo5H5dVez8J90YxfbWLWyCLdOlsYHN+0PzOG+L3SYSN6DkVdF+WVKRmaF wkSftTdM/VD31JtzIp2GjvTDzd/vpNs5jCrbtJZMXTfWd3FBQkzsz2/4pya0Zy5vW8PMkEDM6RXF OQcAO+VE+ddJynvC++/fKQeDvGBbyPU2FSW90hcY/x0j1w2vCtDZQB853Pb188brbDCV3eRXbKHo c34DW1fheE15MzHoj8NUf10Y2TneeEntYovd7a/i7cshb35xHU+CpYVuM3NE6AyCstnKUAg1Q8cs afbZbjPR5M+CvvbFK2wSuckJyVufxf4+xF5RhvD5kSifIVEGk/bE2Bub+BdAdxM81IIy/PEQ+UrQ It1g9+WsY6JaQwkZQWr7e2jlGyjfjUCSmVNNZEx8Pu62f4lYu6bge3LbCHWUTOoFFNJBDC5marrn AAVW8kE6LntKEKACrzuyWM8lboybvAcB/qYRSOFCL7hP0hFMQBwYxSjtnu+5ZR0k92XXLqZ0fUKF BXR7Zot3Uv7Q4CxNbl7yhdzTLhDJh6jIWFLrs1HwP3BrbiF4i1Fiit3fkX9zAD4dbfW61t/vxAc5 0tBpwvT33zH4NbxbfMeokoCYHHpUQPZL+K+4uwDbmVIZBip+cdFLod9uuhTf6W7eGBDKe8+rYciY u3KAemtSiItttzAW8Vy7fsDBfD4FKCpwpOGTmSum6/0ZSe5MAMnLje/defoie8EtxRl/u1e0gSRR RFb7FfVJOPDBrtSuLuLvmSE+/Xe9QYvOew/oculmUOqPG+4CtsSeptd5pmqGPeTj+urKWSL3i7Ai Qb9nP/yp1fRRUyBZqnbuoThnYZqWqrdDglYzU+TN46gtcnwuTPBTPkBOKtfQtmrAc4648QFHSSHQ SBLtFuwq6uWvvlRAQIAjqK9UgSZ733d0OQqrBq92LUP7vF27aRTE09N5r4ixHYpoEGAWmRAOGLTX n7SDxCm2q9CgmKF7KAVJRgR2EtQpHNTRZ/8kJ6X7dVeEM5To0X2nQniyx1E4b6p/Bg8XbuEMGQtc Pbqhr31FqYzLdE/bCNdODTzxLXT/8CkjDeSrQPs5iKAkB/bQBgwplvv+V6w9nUsbuH0TW/RRH/qQ JNw5NzprzGvgi/oSI/7F56Pq/FHIS/RBfm3yhQZnd/xpgu8T+2iqFt4i7Z+zjV1tYjhC+qjVVcOg iQPhCKvJPUrr5/kjTpqNP1xRwIKnvTBvt3gAh9neJ6B7cGf/rBZH2Hfi4i2tvQwWzMQK7vfOdOr+ VCUouYVkTM1ep1O6Vm+Rhj8wQeIYBt69wKu76x8ddT/1Bdlb5D2JNZK6JlM5TLJIk3z+9ZE2wkhI mhz9PqCioTQ5nb1SCp0opHo7Tc5Bim7C7HX/VtX3WvXYexZukWzHcvd+bSH3Jq2N684eHBI1iDuN yHwabCjwP51OYkw3XsPz92BmWCP8/Q7EfRkHjO5EgcEzcTtK1iCmDn4kzs/m0oxnLB1TTNQC6yPe V2Ra8XIbaTqkmY/Ui+R67/qJBhry3KT7wNBTNveViGvvtb+DJyECmNNe7Rpweb6fdw21XK/t4h67 T0xO3L9KSmrtiDuhSVQReN8yB6p9kBhsimMzWWOLqF9R0FoJpuGr64wQsoI9bGh4r3s9pHd/9y5f eL/qXNznCg/IXDX0RJLmO/D5V5BtNgO4OKFBHNQH73KlNIAFodnZnyWfwsRRf3QBbIckHJdSVbI7 aXDxwmLDgvefvQlSnWr58JUlu1MNyjcGQHdNcnhznFXUr+4kmHdIufh+U56NVu2mj9PvsiTaXOWP qZionlk3NaB+nv+TRv/1rrE5R2N4zPffJM1/AC7KwqYN1oCt4+C64DV02WcpvIHoV/dau2oSQweQ qJ7KwM5XkoPvXv7OkXGhJT6wiZ0gSTh8c28vP88it6euDNNRY99HrJjnKzn4/reMFi6Lo0c3Z9DB eIDn07H3tfCL/lQufJvGFaeYyeRSjk6LPFPU3/OvyYlTU5Caldv8krByTnPdScPEp7Dm7qoTtii0 KjvvvkqaM0lAWMm+w9zMaTM//b7Py6yqM/Xy7tGB0BKfkQakczAJmQS2ksvcfZl+4djSYInq1JtT Jt6Z8CCfyGTriS6DkUHlxUQtKkjAWueIVPgl1rFuvcbWV33toy8MS8gj/NnDGuHd17lFlyCbkv0G 6/drCPTluW+zga9uEFIKxJj2BF6rMOTLpOefflFxt/02ytjj9z7Mg/tujZReCfitfe/se8OLr2at qQ4OlVIHW9PdVwkYaoUlTqgMatDU0U9s49D907O21ZB5G+ty1kD/yZ4a9SGPoztHPw1Ax/og88r/ Uyrnq1eQQs3AX5fMimLawsKpuG6dQPQGLjcBe5H3GV9Pz+UFlhSAB4VfY7QVTHK8DmsCsrvB9766 XJPS14XQTgUJuHdsmCAaXkN+xH+XpnLKR0dMu09YXDiv1t5oKSe4HSd5BSxL4edd66e2QuqigBnT gSooGD0poL0d+lo0QB5ADYI9v9NTcsQtrpnHrXbvRY5mp3bFVfT+vah0k14d28WxRAwPqg5sTTsO vkVDAx/CVegiEcEZPdakn0xWEk1sl/l7hRNheMeR+fh/8SzMz44Bmi2c/fszdIU8zwKlXqHvPrW/ ArWSCDKSQ9xklUyIfQ+2Gi4uzo73Mw63aIvpoDhRCbp03CspWPjyGNlTf7vovMCuy0n3Ji8LrPYt iCaSiX7qD5k3n5/lZ18REP6Kebc480cIpENw0/eC53uaUuiYESShGdAxnPEEWv00WjOXMyzXK0Ix gmc7k10AEzlnbZHyPz6R3VK+8PP/c34oaxMBWOn5iiB/3ZZ1xgoLnT721WwgNnpw461wyN9D5VYx H+tnCvS8HFPXKlQ/g7fZ20677fp/OTX4WO9imAWe7xzvkMiOa2Vfbk8sLF6/3y/w1Hekor7d0YIb vHsj3jl6LfwLzGRwApX6cDK/bkRFMhTBT+Tum/2Xlii495mPPiiFIFddlnVrDumt/kAbLLpoMaEP 4ADJ8Yrq45xX7FPlgKE+4yKJPidHwy/RBw+O63iTgjqayACuuX4ELyqw4H7HOQw4ILRhInGy1nee pPpVivBXUOiZwQEE6CNOomQAQBN4uvkE/gjc26kGhj581vnis79voK/dyQfuvh/S+o1B1i9ilMQD am36i3xX7M8La2AgDx30MfJwDwZdt98gEcfCIKJPCAew31Q/fmcC4SV50G9ydL8roTG9IZaRBoh9 kK8A3Po62Q0B4F0vVQy2vfrkS9TSWUBevbUrzpRqUS2i4RXA+hCa9p6f+Y4lhS5Vc0T10r05H6K7 mQm/GcLqiDCYExBXYFlvHyGolx2iD0M9TtHo7Hav0ZFCBOPkAAtl76Fy26FTAyoSSFK8yAM97u/7 znputUeBv/CbcMXdtbx+Xbur2rYBB55KkpI4waa/PojlI573vU+uVIddl/ogyH343+rol7rjHaDg utsgcxYPOwNmv6vac+k8KyRvNe1S/ThK+eqtr4F/Bfl4RGfPwP2hT0KQxRwKT8CpbqUFZfEOQXRN fk1UZemDVv6SLxh7MkawaeTZJQC/Vqi+JFp9x4XjYQ+JXdhKoKPKRs0gcsmzXLV+1yoJccof5/HX FKoxB62znwxvBKnCy/0OeY2P8TpTRfDwbZUABpm2OUz9/l+eA191cEqXEMKrr79xTpZ9OM6q72Sy CbzUIUIXSk3yHZRbd6UE7HhvquNUdYyWu60wZTvNyficEjgBzgeOTJ9vjrNrIk16YPD6FS6+g72U ur1ktXYZkAlwue7VBob/eoi5kya65jHU37qeh5oZmxM7H8CqIC/bLSq89vnap5pI92W3z53ctOtV HaJi5mlfusbAw02t0fvNNpag4rwFSePzgYxy7SZlf9w/5U7ZNvDkbMYDjNvqhbbodEpaMjMwSjAg 0hGs1zTv2Zho44E9pCpMzvRxxnvIXXkZ/CjMw6QSQfkRfdM9PcOmiIYU48TJfnhlhyBo30/GoTXX oD6J3qT54N9V+AaOKT+pNZ3cqeFxwb/1w/9H0v9oxv/z+RiAFGGQ+5n8G2b07x5UGE1x18sH7ahT zttdWmKvy7brTQ5IVGOnzByD4sivDeCClBTWSUKU88Gph/rAZTYO8e6JOx0lMfyUAQp6ARaQ5hDc l9FUWmoN3pOqfmXVBoaaQ9yzTyYuqNmw11iC3ItpMOj3m/n9Yx2dsSPBYStRuJ5tTktlokN9n/HG n8+RQR76+C0XRYFNeG4LS73DBHbtB5WecOAeNSYnTPW1R4JWDK817q250lBwRYh6Uuauh85/6CfX exNkeivSco7n5cOzffMbKt0HrQDXuXq5/5P1k4CDMqRY3ibDiRlXpeuBfRdGS4+Zh6sfC7x6YaaH FaRJ9C/ANKiu1DMLRUPVd90/UN3lThF84k/1gq+M5cSSBNj1xels3Un9ZN04vw+s5StFiIY025CG bw56d1y9zaFKmDLboPSvNCcxDoVHMp79fe8MDx5rOF131T26kB590i7fCZ6NqX4PEnY6E9dTIkd3 iDsqICYLwhAb2DMf5YogkswfLn00galyu5xFlHbJaZBfDxbU3bwabhThRa/DaWgQ0NcBxsxfAWmS Dz7IeYX3zZ+CoEGznmJPRyESgG9h4kta6qPgyVnVffA64vuoOOiA71hR4MDWccoukccKv3B7rP2I 8vt99rBBOq3Q5PnzOWwgQP5Zce7PVu3ZX/or7KKp4YvI9lOos6+ghyfYc9UKyRSdAHg77VKjkO4K Kkcado8l8TiFgiXB8RZfPxcoxet9efSTR8kDupRzfF+qGxDMIMtBcCwnPn/EBOebWOf4K/7n2Lbr svb4KAn8ea4mYatFyHZxYpwuu4RmTPoJhQOvwOEaCKHGa5NDCcR72s2Jmih9XvPvdy7gRO862Gen qszyPi9mDue0XR4IBCPpOLW+gZmkptQBOknYHXkKnM8hLq+Itdhjyqi4aHsdYigPALpcrf3dERBX t4XFxqlDFB+4gQd/yh581CGbVFwnhP1B3lOz9RTWNhJygzf9l7ghScUGhIlkakHerHOs6k0PCD+Y QGInlhTKCUEHfwHM6Mwj3tdLnOSDfvitPtdcIlp/roOrDeOg7S/HhwtgmI/Qev6ZP1Hv697yF5Ad p4UJWHn/EZ3ZSO1hv/DjMBFAx5BHqz8BRuNZehNnk/WVB07MfLrf60kIdrqGnLquCnJUeVZS1sYG MNslRR8ymku49DrS7kFf8ncTCnj06U7AQmnhZ/ornj0SPn4XBYg/j+nMoXVy+0pc4yZNhQK9qxZn rLNeA70RSQ+CttB2lBEILxx3xw9JKDhFPiISPyiJrEsdqQlCYkBQI8zx7CGeVZeALgZVlUQV/TS+ P89BKyVov3fuj+h41jmlc+z8awg6E/xgYEA0JkhCtynhSRJpu49isZQ0j3uofsGkZgbqCawRnv34 ir12zzFwmn4R2TDS7i1nTPOF7ZRHMoe9p4oC0c+Znlicz90Wg3wKIeAhmM//pr+fDqXvkLFQQPbV k2p13CzYaVdHHUPNjh6Bav0efGJX7gHUosBs8l5210RNIA26q/rwGPQvWNDfn6Ku/N997uwpnUD1 dU/5lJjbhKf6cEJTnblp3JJEms8EHh1kpiIpgwdm6b7/HvvXiSn7uE9oEObFhle/ab7TvjLarsht 451AqRlbHJguVNsRXIBNfWFd9Bx9InmaHL6OvjJ7EaTZCN/j9BwPOc/lu5q4u1gsovOuFfjLxziS Q8wznDpynwKGoSomWYX+89wLGnBLGpdOsw4++++Ejx58FkT9Xj2zQ+TXXZ8PjDidy9hReFqQpzAP wnPjIMkxiTUxifc8IDyHDa5ewQnuP717ZCO2LfSjiSnClVz91+1Ep/kyTng5CEFNpBVv/8XHhZTt ENffnp4sahsSc+nAOI7RKhb7tAN/4rIplv3qX/OOv/A/qre+7j+XS2+mUZFBTj/t7db+4sTPe1bU oe//petd0fM683nPdKEW5hBDd/Pn+jT4MHLR99gqo3M5eHCtK719lQPPXViRKr0xMSGpObBV06nx F86augd2HErav7WSyQm1U3tomO4HQ88BbBpSd3GiM8Yk4pZTMb7lSFb0Ye8zJ7+ZGF+6J6bB0r5/ GtsgAzES5DemTvkPXEsY9+XL3/8V4iOO/ltlYrCZ+TFr2P0u1QtPRaDGb35M5l5xkQpvID6v3q/y 7t/n5vsB1JEzs8X5f//q/3Vm/itVByA2SZy7Zkb/pNG/Y8b/iq6XhYPnL0ZodAwf4IkapYDM0uHE zqhlRcO3PnAgNu3R4qVcvZbNPVTX9XT/pEC0UVADrtC1wkeK0gw62f6+98ioZvCfdyfEjuICndcs XIAMN9jluHkxh/iQK6uNGffXvozB8vNNJXXNeetfmhesmxF30qHm4N7faF7zGkfpM2HnaziaeBeq b/awaIzUKe8KQ2Lv9e1U7tKus5S4j6tXaaOJuqWegXofg4Kl1pMO3QabQAre55XalSL69sLPoVuf Qz5/hsYv/FPH8Oy4zzOdPJWwj19Iky8V26PVFBtHdWowcRc6eLAaq93rQmT0atRgGO5hYXKhoocl jjkTSLb+U/Ni/IR3qM6A4twxV6jxJRV21KLkHLj3iT9SEoNurcnTV2zz2buW7rtvn39z4gFz1ArE 3Ong4yNpaz1Hyovy0HA46dJ4yO3yv3foi1g3QohA8zjEmxjqbU50YhTFxb8szZU9/9SwtKuZSajy L/B7CFl90AEtoviOPvghdZsMIMos3Zku4Tm7ULb7SU+B9mZgeQS5I1ARnA6GgksCNr19FsQ7UnhP xyT4/cchZA8uzKADagE+HfHQJXi4ijq+szZQucXiv4hMaDpXt2AGWqfH9bIv83YSu4pDPSD0Vbxm P7gLpT9Ot/vvQZST9IAx21X6df2pt2hXmNbdUpFkazvPGMjOWRdnCJnOGV2D/wsVwS2/NcQK1TSn 2yGyC6qMdBskh6fW8xSRl/FAr1BEl+O6LrBgzkao3oK+RDMTMvomkX0SzQA2m+lMArT7TFFcxhyh RDE+b4HioyHRPxC7eq95AD/tCMy82n7Fvh38ztT0O9b61UK8b77daRXn8M/5ugHcnpbNMQKkgXw4 y4oi8YyipDnIl6/4PHYVmTO6XrW+4KZXAAjaozv2DDmrLEJNF3wDT8+er+Ecac615+O3JLiVREtR 1Roca7mcOxqs/vkuSDib/ENpmtiTIrS1hjC+vt2+qBnT7EHKjCLzkSHzBUoLiOFNXrpICP/dCLRn BMBorpzv/4vv74Z1f+LpZ3Ial/wV0wlXCKbcZ/3aIR5YU4odnn5yz2/WQ0rU+XV5R2ZMPNTqUoW8 vVPUe1A2E6A2gV0AnlN46ajn3VFlKM66xU112ghE/lHD+SQi5gN4FsqI2mVXcS9tMISJ+hkWaHMa jQEUIhj/N5hh0HHIDauaJuqnCJY+//ad8k1XGJr9S8zlIfcwl4caA9ZMhN2jqv7scwbASB8kSN5f +nhLEMHn/S7KbVJ8BvefvYP4TcFNnJmprxE6aXzJVN7h8U0WNIXMQpYpQK2Jx6lu25NxuueYhbdo VxBhnqkMqlQQtbO0+9zqNTAfIPYU0fZ3VZpEF1vwfcVMvyKxfygbw9cJqCchQFUPG3zN//YtmhO0 M4qFfACKKQa/Bkr9JKgpRKaD9TSBhVo9purf6Oc+0QtDXoEb3G58cNeBLf6YdoP2d/oSObZfw9gk 1RwkeQXdMvcp+oytft1ejeip5gqmVdTqfEb30MvGvd4e7u2p+t7o+qs+p43ujbsWe8VCUzU+hsn6 wnsHe30VOCt0jBe8s72OdQia5jgHsoYkXJKc71S3VwtILupdeCNxr/kQo6IeIyV5+hD+9yjiAAHV 8egTPbiPvbZrSsLg9MUrxYkgxKWm7kNX/0z1cNdXPj7lGzt/RagPoZ1iwnEOwWRLSF3CKFff6+h8 MmHkl+GRIxyeU8p0fvcN8V+mKzpFEyT6MKa1GaPYcXgefrtP0j+9i6eMgfRRLRPdR2h7ig78aY8A A49ufPtn4Cfvds+d2eiVzifonXI/l0bvrHHjO9on0UqyXK7h5mQRFQKe/g2u84ZSBnbKGxmNsIAt U1Z0DK/upLjX/OTGR76tC/xRnRiHwt+aa1Bs4M9siAE+7hIHaJlWfHl/f6VWGzGjTLwW+qdvHLrF zdzbphfdzKDohOrTyo9zCoWmBmYoR3QONvXtJ9iSJNNQKW/Zxwr5SBqcTsbE8TFdWPIA9xNcnL56 OgM3BeZfD/798tS7+zYIYBqHTI5hIXW+WLpD9OW+22kYOFMxNm5NnpV60hEu3Pk2iug36OHkjTvv blvasYGe6tv1/ZFrpAa3wLndx/ji+jZmXcmPQR5VfwZxV2IPgNX567MYhtn2QDGnuUyZQa4U2GFd Rwx5/59n5r/Dvfu0gQvyGP5Xzvg/sM81wI7cJpWG+8czgAcMnNXkEuqTh6h76EknvcyRLr2I4128 ov2/b0MTqPqcNTWz70ZTD6pkWabbWF3/fZ23y3c+JBn30Ynn+u8JnGDOXmOf132udWInpQheZii2 uSbUXoMrUQ4y6tJhu3RSOPAz96ns7xrk91Ho5MC8cL80lXGZqczkuK79ld44p7Fnp0uJTVg+esLv jJ4U6u/z8cWufNbAwYXREJka2V5/TjxD2Ude2hMfnFqY8xT3Cpi/5jEWm5M5m/N5kBP5foeEZ6wh e30lqOTa5vRag5RKBzf4Drdm36mje6SOaOM/ycfBgNmZ9TDFv+jqgcA93KWYSPPfaX7Yex3+GdLT ifXtZHR24J9v7YK7ktQ5eq3irCht+TLQes2bvbC8/eRUw5sCLoLwo11j0GA38oy+zKkIu7rqberU yPhp8wKGgVghc0HIcmtP38GS9YxM9jWeNvgzmjX4MfC9kJ7ciwIG+NWC/VO1v24qKwG7v42bUhyw 5xIo0Be8sGcgCvKGGV0Qa/sVkoBLx0K+XrBiIT/fxHM6r7bz8neskk0lg/cl5SDnDseO7Qazy52C XqoSMT7hfq4/B6gIErEBag6HOFiMXhceRRDN4dVzFTguAH8QjtE5DYRAqemZPW/ahsIgRagDQpDn k/jysDY2JlJP6LhAI1737Dg/B9RJYx0h4BIDyOTL46LZXfFY5evjJgZnsuicIIj4sGQBSk4Au5zj gLo/ZrTeuFASgceK05Qw1iUQ+HIqHwBNqVzr/cEtFIQsKwuydqv2sNjVCAzTJFsL+nbkKnt5zUER u9pNz5w0QiKjQloPSfVhgeV9ZqGnI6yqos6KtN3CgudZOyFmo7sM0xx+HoHna/J71JN0CQIJnK+E 4h+6Pw3gZIMPtPb90VTnxPJyookm2xXTzOf0gotEbv4aCixbd8kLTHsO6YNwhVENw44Vc0Yhtv+d ql7Yzvr6e1RebjP2BYlqgaro2hPAv2DP/AjuE1hX3W/kFnE5wDfZqYgrJsBbB/g/Nwmo+QA0NZdT uuksVIv1fNZM8yE0yW5gfx4Kpe96Y79fIpOX28n59hsIMoI9WZW1KBplG5rzXL9ovD8g0Y8jDokK fcIcgmGmd1ABQ5tL2Hn1STvi9wIwmDDdoojt+COQkEAaFDljH/0YOyVzBOBPnU0Bn9cYDNcW9D0d QCb3UE4G9SQm9OlifIkjhX1xEvy5G34cZppoLLe+OOcJ6LshBhL+x7MMctZmAqN7t59zVHCvb3HH oLdBuy9sMQ7VFttRvOtjQQ1Jw+F/yBYPC3NU+92fNfp7LwrAojnPlceVbhhYNvSYuc5daS9MFG8Q caA/SDOBHAZgiU0OsZdERxTdLKR1jDdMC/spsXCAKOsVvCM6/66D43w2yA4MVCWBjzfk1w7VKbTn 4ZNMh3PcyUYiuXGmjoJePaEG7rx7IDRjizm6Nd00jclwPmUMTaQZJUA+qghF2iQPfRvXKDualWDT l6vJ5aWOHTwIF6/EgSQO+vwiYthDDv4+7l+v7pbFMFMilTuWVSfmsQcUFWQLiwdeYk5znQtbxCL0 uRaedRsv9Upoq4QnO3fGiXmr3M121cBj1D662u+6KQdYOOXC551zDVuT4IdSBBHb0Hzu3tdZbUpQ kQ5VYiRUW/ioqKsG6UqVO5zfZ+eusRZO7lsclbxCOjML8ddbMDAxOM57uRO3LkEbEcNDtZv0IVDo Go/wO0ct9Pfn++rtejhYn97bOvuKjtye6MEp/TBv4Mstfur8RIMKk6P885SVNZoKw+Mn2ncR3zwK TDL3cwzYlHi33dvXoK/nqQ0G5V30fthkZI76NzlQHQJChcENYQu/pYEMZB747BUJTXgFnNlH6hRV zFFvZGdCadkqvLT7wwuXGGTzLoflTgN3mYIwfaVIWKJhXh+cHvNdJRFzYzGNQT3P0lfKWJ8wf+6G ZZokxtMvTOMLe/DCDG42nLKOVfzYdhXV6ZhKvJOAhWBjJna1F/blmf7K+LIh+5W5As0Xne+Th7hS szJBYJCLmjDm0Cl66XrqGoAbTBtqY2+dDqftnnhaWQBeK+TGiRkjD/5851ljqAY5fZxokBPjxMey bsuKZWPbXz7Yxj4ehpB0dTVgLlfY2swpb9XdX673ZEqf8f9nZv7HM/O/LQG/ruEmNM78N83Mf2IW PgKmFprzfWV9eteeXxmnzXso7pGWX3oJov3LMMddW2+zUMoA7dQ9D8nnNDQwIPSsn+Ex5p9eU2Bs wyK6EqOa8TctPoMzgqtfcp+/Wjxep2OQVuZvfajbNIDM9wQ1RLqKC+0T02xLsApVfXNkcEPqze5N Ut/jY3Dj1u0Qr5hJgO46vb4325YQJruxmK88WzrryfpIQ2mfF6vuwCGu2/OnvppIffx6JtdOV+A6 2yZKhxYhOxpOnSTsnrCfy8l+G61ed+02x53D6EVhlkEo5fM5Nb+yZbRu5sMMwIX1Mx7zGvsK8JtZ /GI/i7/mqPpH+bwb+/w5675NNPbd79XfC9OPH/2J890nPqswSOR0wuzdXIMnXuuk8df9HF8ee4Ys D9pgqE3dKNnDuB6+k1QH+M37BjckHAiMdARc1RrcxzPrN0OTAb5CfweoClF2GtFt3NGw9+ju+DEK c9Rp2sZZSvzqWUOeYhgEuNvWTfpDmfJVN/x8m3/KMijjWwUunynSeCdZewr8OXzd23a5Xg1P+E2R aDRFks5iF4xgIDfJydUYjOMCYnNu0ihn5kMui6tw1nQ2PUbhjY9p+PfoKUALds5HUEU/vxC8TpVk r6vZEd/rD2mVhAI+P0W90JVsg7zs5/wVCawDKKX7p8c13oPsb7nhm5AzkZuaszUhsqa2tV1uTElA 0efK4u2NPb8uhaTLO5zOcZjSE8j2jICBfDbcrEt3rFeB1uLmud6P2pHFUTz8+WgdC9nOQXtqNa4W TTVxXrdDujPpE+jKs7gv8pvk7Um1bjw3qcGlR6cb5ARpiyW/3JzuOTcGNQSypruo28DDHN+9z19y SukLV58A7RxEHjlMJQnQlKrh7ujITT4PKQzNKAJtodoVUL2JcB8Rtp45HNsnyINXSETPalBgmc0j nKBOMvc5NQqY7kZyD/sZBF4zPTiT0VXeIiUa/PJLvMx5j5H70DW0lu/1/jPw2BELdbxYFKGT0Kp9 PDCYsk+oXEur8TT5Yb6pKwmY7fU0KCURukflv0NUhWBozodz6UXQLgkdEEssFLwEbS4BxVurpcit TyV91ow0VPnl1pFCFX2Cxd2G9TodAPva1XQ5dPl3yArTbrQdq4hMuMYvSKCfzeNPrTvYh233xVdQ QM4kW0y/6uqInl/DPuhOMUDOX8JQHYkSz+pRAr9fg8Tr8ZdD1l3PCe6+jh3fpDoNCwmhNz5/LzKE 1hzdIh2lqJMg047L9jQABD3FlXfWtIgWeKKZOwHu6WHqUR7DgnmGpdtZ143PYMJ0TC/H4t0S7/6d wjsA81WWcG73iylsy5vBB9Dt4+4V3kf0bBWA7E1WfAL/R9pLr9BeKzns4xLI/nxGTlCbOj2uoSwc OsjPvoBYqkXY3W1iAF9HbSxYJ+qOeHfm7h6Ya1aSLnMEJvd9G0vrwV8tRyMdZLE/k7j0QcAcz9NU NbS7Ip9hLb0Y6A/14eI+BwagU1Di6ianViwMUMysIa05adUeeHjJiZ0AMtXn5NmiT7ONd/+xKcl2 Rt8iTc9vce6e24maUqB+wyP7TXxhIT7RJh8x4AfNpAl8V7juSRL7Q+jkoFF+5OgNpel00SYV6+57 CZTD2VxA3JEQUp/Pu+snriNn4f+X0xvFeL/4eAuz6GwcRCuvGeKdSkfnC8UK73uiR2+TBFMMnE2f rk8giiI1SiC28Ac2pgeHzvpip+SkM+UW9FzpXeuf2OeaqZtRKoRyvyh99neGoan8/ZQI+9bEEifS AcLw1Jv+OOemBCjC29rrfTKKfkgk7Nqh9hclvrGYTJgQ7m4fAzrMd6Tik2LLO3Fj5scTIVxa1cfh dpL8uQP1nIVZ23anyemfe80JuLU30aBTC6v6UPcDBuyTME1jCsH+GUbRwYDA8Rp9mTjpCReNZ+Q0 sMm62h91Eg00G+q8NnbxtOHPQLLocqx7VeQxkJZJIO3kd/SjwyYqlKibAo/OlqXUza6usyLKpF7p wtZbGvHeIzk0l5/xTeoa6CtUz2oP1F6Do0Kzm6n+dioNhxIEv/lqEk9MISoCfr8TEXMYcL1bLCbY pGg75Lr54toNnKBBd7muExpTaX2Yxdx3cgtdyZznMl1J5+tLsqMaLMqc9YE07FyPDm1G4946JHSu mubtdYS3YSJCr2iuRyYcjp7UFw4iHjmUQ0m8rxmV0GmXRGfZ/+Un3Zj2X7zk/zoz/xk+4QbrMEyw 8/ybZ+bfOSeGTwP/3ankPeYQWqfLKOE0A/VBanIU5k8/ibPNMekafgdcUTgkSsafPvCJmR4ONdbk ia33Hdrd74/uQZF6ljWAoq/1wnO90nR/+P8cqncJrp/P79SptEmGPkxdLlf8zf20iRXdB/PRH3Z9 btBkZKoMMf+ZYGjgz/Ypntg1j1rl0Hwba2xjiYPLBXzdB8c8n2nD8QlM3EO/v+UW7ja+Pa0eTKf/ FGZFGKsuwwpNVdT7DtVxE7X3+ja+bcvQdEEWaT7qk5i5CezbNJ8pLJGKnWftFr1ed8O7Ro/xXh91 LipzaCyxE4dz5QjsovxoBW40Q7Aubo3Few8bNLBpAKxPDeKrtejPlMPl/tuHX5oTroea09OhwHH0 HwK8eO8HFXfnU/+QCXwzl6N+Y0WkeRtkNTb38Q6mePXAYBATehROS2ddxGXexB08p8v6HBQQGiAI hsc3J6G5kko5PV7YC/lK3dDA/bHxJ9JsEZbAFtzUv8380wBUrE+BhtHpqElPdWOpg0CXjoiFE8aL Jpqdxa5DyARhaE/mC2je9fPMk0ME45AvIYtLI35Tg247f8BXIRGs1WSSfPuveEbz0azkgX3FiIRY Qt9CsIxxUQl9siCPC9f5O0CSpnmGLPhyY8iEQirJ7Y4deXXEOkkJIHx9li7SUwSqVfBrUpD2gr8N qN2TtAW+R7PhaP6MAAu0vGuqjAPu7PmFcGzS9pQk2Age32LNOxqMxWstZtsTrD4ipXxAmwbSMQip IP5LOGlyVjG2ZBnb1I1xX6xJGFKqgDGK1mvNd6N+RXUZW4F0jjKCjQmE9e+9nPN0kALdgF4yBTp7 esjk8OSBO8+Hm9DMbxFnvJ+0XOPmcMBf9I8vsUhA+Q7Szy4AyefJG0/du+nrsKYfQoQKO1Uj4Y/3 HKkwEhC7mxD5clgngDrXlHE6eeaMLFK/0YzdTYHBarLNLqQ7Qu+abDVCDPd/3AKIp3ntNRikiNoR KIHDPzWjIODtXWeXXN1L+M5nnzEOfWDgxNNpH3fQ29V4vABZRowOngxe3wVJLF/wsyAiNwFcg9ts 363f/gj+KDFvF03PRSZ9z/YO1SWnk/5D+uhyHmUhyL3jC1pbcfZ3R2CIB92kKA6cOePju9fyKUQR ni+vm48jqan7GvbHbweXGY6j7Z6THcu0eqRdg2pFbd6g8g007jvsAMXtuoF0iiyuGtMRA3cBOmIx fhAlJZbQT3zr60wy0IG+WYIbmG8izOmUrK4nvMBUvnP5+RoJxr0n03XSeMfSW23CLijVt77RdUa3 OOQlC37iaNPZblDo0VAxQbLkQsegrgGMbRHAhal0rb2HqfaKafc/MyHt6zvtGp2C1H3Ckvr1prjE ziWOedIhKGWpXJ3s5eI7R9D1zO2Eue/k122Q7kAvx2dOf+LfSms/XbiubBhpkGj2sKPcXOiJb0rp 557Scr1PJ0sO3Jxj6JfF7jpjnelePdxfPQHoz/HzcojxFbxoifWo4iRCsaONp3oETsZ67/HLbMHo TCbojUkU1u6xUyLfrzOHsCmf/e0AJaJzmHO70XBcsU5SVojvdU1/J7dlmgLllo6325yqYuV6d4mi Y12uQSTddTenk7F7O6V30g0k0ViwAyPT4eY6lfx05SQaTD5eUqpr7gsXywGEQxiAXrA6SPyBM/Hn Pedg24u3kBuoqxdlcalhsKvuzm4KsaujiOVXtKcQ3v8k2PgR6aaZihdOs3Ab5XrTccpHxa9rDOtZ VyIn/V0LCFb8Mq4pgRoZBngE61soZ9zP908yWOJDr3nKOvkVNwwkE3APzGf/5aRNfVj3vRemSV5z LG6YUXzrl//i04A5gxAKpjOt37prpge3jvtJ8S49hDw9gsspfiDfUw/cG0jofE87UfoV2TSHeMWS T+wXBzlNAmZBr3DJuXkI7JaqtMBsu/ezUcbmH9qNV+cw3hZd+My2EFRO/ujLDCZjX9WMjup9og9L 0WoKPrYACfFZzbm2PXedzbmJjs9iQDq5/+JhCQG/pyd1Ius2/3pm0TNUmGn84Rg2n/ByCWF8p69s x4nEz70/ySjhPUsKjzlQYx3uvOt3Rz+pw2e9K0wBL7D5Tv3CLuXTySEIQ/YtmU+QdZSRrXM5Ircb dK5bfwxNKsRNX6lRc+BzF+LzDoP6SGchDnrQHOgejot/X/PBXcyju9KRtPG3vvvfeea/ud7E4bp3 mXLZ8y+S5t9FgzmcEMsevw6xL9dxb0rfnAJMYZ2TNYWPisrDaSRvJedKm/Mz4Mf3/E+tkueyMX3Y YYgXHJTjTLVPVHxZJEUNwAlgrmzCWcOLfS8JtU0f+J1aF9GDYKDc0j+QIqGoQctpVweG+vM80ghx dFVd2/hn9e0nh2BgplRDEWk0Zqy4NDl0rA/n9eSJ+N8TWvnoqjfss0P5OR+bZz4d4LUVi7XP3xpK +/2Ps3aeA72gOzhM8CiFS8SZUVGmlRLXHK0xVZGQNOpP9567kjz0wdN+OY47Erl5QG4Zy/hNxjCY ed3O1oOoAI3jJpaahiBt9JZIaA5e6oNz8LSBwSvG/nPW90Cri5Xcyd48CLI5SP8d5M8+ew95ka2F sbf4x+qel5eLs9Fd12xxO9cMjmTKNitSrJHdk9Bg35eR0R5ajr0gxlSqD9HxTWBoaH0LU4qyoK/q Op/d/NPAVacedJ1fIi1OIAWeMMZQmVhTv1w4Gdw7O9/4S8vG2pFOWdgmI/+0nSay2OcCUAAC5MHg NzbbRJZcxRmBqzM8dW+kQVvwEkJe7zjNHTnjw5GkneTQqfhTOLGnsRKUaT/YgZj1JMromTgmeZLk 5YhHf8h1fmKWjEv0Jf8bAOmCI6N8U/idn10Vh/19/DoIZU+7ab1u1PyzOv6R3BPvv7NhvD8kgDSH w6VLDKRhV40kVV/wlQREFPyTpcMdCxGRJfaOkqoiGJpVMUit5cz828WaF8URAYqRMklC+24o7FME kocyT/LqGXAg2YlRcptPXed0VE5d+i/paZgk7Ga+SRNeM6ozksBKLzLA9S1+LtIGzpqcYGHr26io 3H+ZwO2BkTin8Prta3eGfPn2PeMaJaDnT9Pm3XRsR3idMgx20c1Gvr2WmaRqEvF1MGABwI7b5mEQ HxCcah8kuUcxi4uEjOatUz2MLqEJYG3BYrpitqPyj8C6XVw6SaQdwhqkjSbEF7gHch+306hDKPjT APUa1ppiJ8cHIoyEbhTzIVbREmA46p2fhng7x3hFWm/BgQvQW0W/X5C4dxD7Ln85zXQ0b4N0LrJ+ N5sGX3jD3eVIEYknqW5GdJA9f595JpCEAOtn3xiFHincdADlQoLsAlB4uElnMLc//r32aNa5AueT JCDZUsIgNILlNdH9CG581dZxp33m/fRAawKPHhK3ReTgSeZ2H5UxtD9OiBcR0O+dI3KN7tZfwgjq MZOeY+/E7CkM8Z4gOdFNduzovenaBOtoinyHVr2cA6g2bIeF9oA/qapydViR7vrel4KhNhfhtMXq 6RDyh5B/RVCGHnl1nR7Ivsi1YoCACG53rWNT3YIEDCRdKfaw5xRMDq49umdTJuuFAyQxnwTJIGg2 Q47GRCInqd/AWtcSbjhzJtwi6u4Gp9vuym5BMg1Hf6WBuH7/5R41i4ju9IAtKDSSUwbqOUFRShyD gWhFGtVKu/CB2VBMtI+O8CJN/ICw327o7YAkiC+OPtwDDoMbq0lx2Tssfz3fdvu99uFP86vVizDq +XeQW18OpkKy7K2/9YlYaQm3GgdNQkLRi7Qbc9aQ5FK63WZ37+Lf8OaFg3kRHLsuMgyq6IhKjnQC dC+m3lrQ2bnI8C2I+xrZ1Snd7JEA4XAjEQ/pBrZvB+PN/ysGruuTK85VD4nyqCrxh9C4f5fCYTPJ 7Zkr8ad7OD93aQ+x/MT0uvAGSlTdpNOV0sVDJFXbggs0D9roU8Kkwnfu+1mxmsjhezAzg8ivezQs 8TnBEDTdzi/f8/ec0xaa5KAs7/rsvNgIoFOpYPzW/hC2ETYj7Da9BHtTZ2WS80nS9i5h4eif+HhO GFWLbRwrR4OIBhPTv7FbBkdZ+jlenFreq++w/jVapyOPcJ4UaOMK5aSixPpzaPrv0JEd96hR9EOD Ql4alX1u6aRifwbqDSl9fL6yqyKdTTqsW/p/X2mUjXcYROkuLo/sZnrwLPv4TnaaeYd11hMKJ7md XDwzmDru9U5JAPmnPtXB9yUu3fZD9whlchfUjw70ebUK0hxOu67Zhh0Oh3+f1VWbf6GvJqyLWYYk r6HBfYpeydtbzCPgUt/aQiB9zs6fEubSyGVwoEKVpOIPwd6VQOSjVjSKX6b4fD9DG6IEUPuoJt5a D2RgJsfWGi0uLNaQpKCzbvHRG+moUrYbev8tqjdgNysxvDx10gguh78Dm9cl+LtrExqYdWE2A7vo RASL6/76e+tJlbiQMPa8R0PA1PXD/3tm/ocz8/9pfkFYMSvr73/+H/xrPPMfbHz4Zyhyp5g27tmj +hP9/px46RwY04XRzczRAzPSmqlNd3UzkDMe566o53zORanXGq6OJwHnz/CfgJtE0eeucxXj8P5I sKPxJw0PO28DnMZtWu64JyUor3jK8/XKKK/mGdLfL/3DAIYoNFCb6scVZ/+9wwVpVZRI3inZ8/FT 28AmB7q2a7LnTm7Jc+qyTPBcx+tuYY4TxXPwf4LvmxiL62bZg/lszKBKP7v4yDnz8fqM2PuS0dTg dpRcViL/cKal+WSlH/jk4wypDe950bgbGChqKtFsngGfwSeoMAP8ug99ss2aNB9qTMPDiTddkxrq gq+O6+VRdJzKrqaKjC1qUA465789qXutvUNel+VJioTn7AwpbdQHnk2spI+xGhdu2aYzOjrb1ySR jWAFXWjyZSWAB9z57971wGhXI1F01ikGe/ShR+heYlChoF9SaIVYpJB3yttPhyYr8TXPwMCejl7g sgM13lCdJGbsZ3kd+o+je4t20qGYI4K4kSmxuGa5eVIxdYXZ8uECgvJ7br8hoffw0RSsw/HzGQ3t A8YeEE5wDNEW9/oofL/EOcILb45YshTB+Gzgu1hrweMMhXL/cRSkiSEdrgI/Tjf0vS+3Fgan1hyQ ZnJCW5p2DApnDxWodg9n6INQ3wWn11ogp+S9ZtiFWgUWgpDQ9H46KCrJv6tJqWNQJKzoqAwOoFcJ Ke7QYUdhpekYKfZQugmd7aioaoVcU1w5QJAgUDpadYMyHdHiAZFvf3YPOyKxe187JRlApTrrI/Yt YdgfF8PfxHJilxO8kG4XyrnEOPbprDRASs2XJ4OaGMgYZ6FIgoZbBE23jnvJGC9EbffVoOu4C1rA fMfpdGSMhpIbPHO6TMwijyYA+0EhTV4L7NOXYv5NIqejDJ0zGSU8B12/JmRNoiOocSRsS4XOd9pO a2qnCUJZfMRFlVuwXvcEl7tjRg4ZRf5fn6ebCQLjuPkG8NfkMps/773T8rwWnokkhOgTX0DKxBtD 0Y7hruq91XWxh1IC7mD2uCXEyQl1Qpuq4BDViM7VHZumSceGnMddlDGur7M+9t3E8QBNPlejJPPA GICyu/Y1+W9fHuwuKO8P2brcqNWuZDxQ0UOEl2hLR59hiPwaIBn6Puhxu8vFRAqy7ZfhWKMr+EwL ngQSTCFA8Z7PexjnEa75Gfb0d4td0fIok5+5hJJfANfM5YQnHDqg4YKqve1fSZcLsBmjz0X1e1MS 69s5u4WbGRPcrpx/xGl/wWVlX9k3dIJ0JGnXsA8CVZpvnYeuvOVC4SB79dy1GSeZgPjl0qUzwWrq W1291040aJl4D2Cmc3l2lU0vG50X2WmX4w7/pq8kpOaOcMTkvCOSk4TUHHXefZgecm1XQkn0NYyp jGqdmSvZqffXFalJgPDgGZ3inFfIcBk+9GCVQ9jFFclFSC03Yqdr731eLrD6SN7Y2FQK23Ldcm+r MnTou69wFn/txtjfJxbFKT4b51MQ8jrTa1Y9quEzSy1qWOtbc45DvjG9LnIrRR8+R6gKNNe+137v 8wejX5MMNOzFm4DW82hAgiQaXY9zvwYA2gHXEL3aIkEfAH35PT4D0DfhlFYo9u6ls0Z8DSl8CjU0 5AD8JqzR0EontLzDmU8dqfmo9xx7Y5uBGIl8oUyz3EsD+/1yDEqDgddpVUHSG/CuTmkTikaoO5nZ +qQLR9tpOlTf+KRdabgssR+dWNcMOy+yM3OLx8gtjUxFUjiXt84WoO4UGq9iYv/ui2xWpEUq0AwV FurgXvwlNEBeIz5LDXV8n7XtQvmQsP52l2UjkX2GplGRhmLMg+bVa7CQPIYPyfZ2sLvmbrre0rFv 8xlqWowtGOScTjo4Oved5jxzSXvX7wrZX6IK1BMaB/WbE929zNdgQnMIZNaTxkpC8eJAYpxnaiBR OKA8RxLaVPpl9kIxeCeqN3sdLBFl4WQ+XS5TUN7ZDD720J3iaLyF3eeukwva3KQwaWWfT1PYehtD UIpLSdN8SQlcbsR5v6cJxPo8YgFR52j74BI7HVmBiXba0kDfKWAidfLuO81B8zXo0cPoAn78Yie6 du10DxcXJcjn+eG7LnEbC4F1GA6uNDsclSYR5kAPajQNKvdOlBO1FGawxjWIjucfTKrNxHQX10Ds MuEVf3t0zXFmdZ17YwrzD/BTLkz55F1Wz4PJAf8PzfznGQu6jPumehuN/vUz8x9K7GGVbucAbpsz rc5QgsGMNhQQrP1LjO0z2Z5rvSsNr/td4nYDmzNxSfrAmgf4a+BuRYNLglNVpTHaQ7b+xUQnP4cx TeHvu7PPPtSo4+pv7DwDE+f3DBtScl5iSYn9xVT1UK2wfheeL3fGfA7e9Tvew4OH+Z3TDELrXJq+ NSrpt++MO8Wazd167+Ld/A8bd6H1FppcECb6OkAb12cuEZ819fqLpur5lKMUdlJpMkdq4sCqcjg1 r9pApN/zsAUGJ6O+ia/bVHKGNImUaDZgQnmbRV1mQZo0t/QxokPGDS8+VGmnEiRKkwHllWY2R/85 VTe8pg2KmutNgKE3XTtGwV5qEFfgjLn25DZpCWD8po2ap3tswP48pCnmYZO7z9P5OyhV16cCQR9M ruZNDmuuD86WxD18D0V/Oc43LiO40y79FGfHzsynCSiP+AqwSAEeoaFROR9YJd+FPzW0YOyr0228 sOrUPf7TVHyYPw5YQSH6iwhQLaBhen5iAjZhA/K8IXcoindKR3njxudprNdZgqOhu+Wbc6Mu4ZR9 xt1/B3ddcTrdDBV1inF924F0rkPQRHb3pWZwP58CWmgqSwWiGkm8OQUEmj2F/uNs75Zy/NmUHjg8 2G0zhzOuY66jddNLKMEHQfPV79vl2gAHnhgEuUqrq+DntmODtnU4nU05BSQKYMIJUZRgZtGjotwH 3LB0Qr27YMsJ7PhE6ojVv39LFxnRkdnbtSEF6hkjfsXHGFsouqrI46mnqJ9iK+LZW+D/FpRzyIrI OaTPr3TF1nFev3+3HXyI5NSx75LgzEn1FKNGaX0MAsyK2aVpTGhJgKTCqe9yefVxv6h2QgJal8ss TcK/52RFtttxF3CwcDuPbIGBF2k80061wljjFXumS8wDhCrc6SuaepEETM7crtBbwOLpZ7Sjx3yA gTPkoEvSq3ZdBFApTnDDoCG1Bj5BVYPvrj4EK+AHJTqLBTFUxnXxrg09ZDknJGh48tUYIZ/C75+7 9CLs4sYSEQkXgE6N6itgvICUPvN+3Do+nN2HInTzfGhxpXBNJZ3XYEmtQvVAUgMUA/WnjoSWTbZ5 ptxG3svbczv3zQwSlNx4B8AvdsEuehPuj510NTUMsAHoTZ9pNZCedkfez4OcpjlTxfismAjNAVUd wz4PIC6iP1p8zM5D+QECmNITMa+b6H2dVIx+gQJxkgEkvWofI7DPYo0r9ttAIFGk45baktvRju3N IY4+CS9IJGuGM3dB+nDx0bC4s8HiGx5rSkJAr5zdopoQcYHZCsFnEK0eHFbcwGWKgJ/7V3Te+iME XttBwTCkNi2C3u4RdPe0+Oi68X91QvIAbrTvl60nUvAH5KrTdwBLFA1jDwMkZxLCatm0Whbf/Tzd De1CXYIE716KRM7+AHwbCn171OiwfTl1qIRKwjERlRvh2sN+0yB2v0b1AWdLKXC4y3nuy82RXFGJ OOG45tdFkasmnW+cRnLXqeoU/pKbGtFV7DqqIfE5CyTTuXBQCDggnErM6WbnMlkJaf2HFGOKhjHl K4g+cSSKwsZn7fT99+eOToGOWLiB56JmMKmLhEI4hKmB82uwJnvrnvs+nYM04FPVnwTzFBfggwZr x69MUDCuJR+1Pp9nvKYmBggxzcRda713tD6xJhqFNFY1xpU1hVcu58X3U/lOklTcgXOeKTygTvgT nX80vudj1FV1B4oTwpT3xtT7InuHTVK/BheHKc1JrD1Yv6bIZton+sVqgnA4n1jKGxvtT5ujL9OJ 13HLpyhgPp7FI7LQcSYd3WDyWHuYudkPEuMIxS0OU4SsWffQs87hMU0Kl2cytaB78oHTs9MR92dN ka8+mJYeeIX35PsE0bN2WFITAlyn+LzFNDtpF1gFk0EEueBruCrwkSXlUxSyVrG61856YEMM29Ds 5gV6f8B4aBHtnG8xS6R4CV75Tt9pWM2TdyqVKnla0LP7QLP1kdnypktunqGFDzp4hjmSFxwGEoOa A0q4cNwVQ7iGeu+mU7mKN2zxIN33e+i0zfF0jrU969v7DDDu8AcjxWSLPaS1096+0E4Nj2gL8RUt stKLu+H/CPg4GFao9L8cOf/pme3mX9vJVyeWx08BTLIO59VrBHSOc2Clv+kdDvKJLO/+tz8D63GE PJSDN7tr+9hrleT399/5X8/Mf1cnt/K+m3jC+xf+GzTzb62uZPUXd1KLY1jYVB2Jka1rYHagkqYn 5DNjm9zH9dE16zMh9U2M7HPB82UYJKiPzJ1R8eEeTrLvJHYt4Zo+nmuJonVhdImLZK8w8HN1dFO3 GeX7TNMkyGd2kGt/dJLGiyPp47w17m8Vj/9yyuze+z6Hrb9R3Yx/nJ0RVxGZZMVzN+kjtibvnxeN t9XaNkqKntrZd2O245QuSl1fvSmxf80RfHdRb5LWFoKzRaFOzQVo5qRz8F2gzPlHcMdvz/+ntvd0 Mjp0kIz19l1Ngwh/v5++8YbLDseh4WJVS7h6m0yAXPqBv5/fg/jXMplV95qEi3j1oiocgxI0Xe7g gtNNM4gm/azh7QrfSewLY/HAsKM/rJjvP8l6SDPQO15DPTpUMmFW65/vyBZfifgazQ4ENTH3/swr UL24sXdXjZV3lo5U3uYYDDW3oL9OYyd+T2yM/P+PMRth3YI00t8qSS3+tJJCytn/rrWJR6b78yeh 5tEwl0u+55+uS9THtJ4/SMTLln7wCOkpOS03jijmHaSvXU1FHjwCkbuOaNX97XqCKN2cOCzjy9+w Xc3fokkHAT1zRQte8RHC4vzne2SZ1hERPgAYdJ/FNkIQS/+6YeRhRkVxQq1uscoJ1D/P1tmCzBIp 92X9Y4/kABC28HS741RTrV+pI0gQ2A2q8OpXOJv1d65owzNe16st8HFIpzgrgaGXUE+B6jtEwDkD 7Yqj2tdewmvnhQTF8eUdk1RnD+DcM23bAZ18A/oZja4SIMVSu2HmCFumfOsKcgMYHbf3A2A6xCR/ zrp0IfZzNqvWL00PZ/t4n9m0KpAE15wktY+zgOmd20XC4fD518nJDatfAoW36brOyz8O9RzONNCY 6nCe5USGpJJ20wxEjMsXe8r9XarGQnV3qtJKKKom38R9XnqJPIqjRQLTQyHlczjwkcA+59+Xa6rT 88vL1ept8LXArS+SId2W3/tyO1yvwlgKpxHjmUfunToJ+HZk9tEeLHGHmh6aascEaRbhx+omAzUT LjC5Jr5CAG+w+xXA+Gha3s9N0gpXvasDoO5BOBVI2KcBu2hfCSzGeLn62Sm0hh17tU/z2TCGI/jh Xunl/sngy221SnW9cX+/Z8aeAG7wUYdIooUxBkLgw8k7DB3+TOtv53QNxUR20kdGWE4Bu7SvBkga I4hB0+EMxiTofe85l/B+iQo0g2kFFTG8hZbkUL+irD3oxEq3kqHZpn/WbgmXRF1P3zgRKcyw3rwg 3CLOvh0833SBe9h7O+NPSaJ7UMRYc84veUqGkXGKxNQB7s6w2JUFuT4kWI1AzOFAlPHtQhKCkjC6 2QsJhGZ6qFBPDdF0/SW+UAx13ORbvA0PxkHmGTLzDt+nB/Qe4MN6SjmoxVGZOwLxPR/90S/7GIZq 6iafqE/05EpluYSUIbSyhwRlO7L0cWj0HvTpdLnXjTCIO2ct0t90Yx10n+Qe0YHiaDqpqN93Di29 75fDnvXRnbUQcuA8nyGhsQ9xQ7pgea5QTBdKdAkk/SkNRTcy51Aad0KGzmP3khf+9u0P2Z3MVaP7 Y+CurUbem8MnwvMIUHEu5hIn+hiWdnWP0hwEbYo4ZgmMWrRhJN4pScuQ6JHD+2nIciVddjehwhnn iDL+Gk/rToIGKxujz1ot65CJOuXEqc2pg+xOJ1oiH3DOYUiDfVTH6b5pAT8E/T5ROaEqSXvui5RY JryD9ac21D8PP4Lus1Fvu1mXL9cmzekrX89xpyjpEHtvYjDvdJ39uRvnq5ULw3PKu8xD7ohX5PVL VhrE1C8pTpHXVN/wnmVZg066kIZ/9THIrrlyO9K0Ip9PpovM6Su5yfaV+qNIndU1bE8OaEePAr0f YRE5+Pv3XPZUPyhMGjTU9SxcmKrrwuvedBvrwKkfDP5NJatUGg27JF+u7rS2tpN0JcQ+xcVy4XdL 0lOcyilxYaxhqt+FzqaMic6JX1xuuSnGEJxQdAK6Uk5p8I3cnXtYwGlw4AlxBPGe/oiW3yYfxAx7 fuujsg73IUyaSWHZ5ry+KvnbifHHQVXVi7TfslFYrBqmCFzH8wunp1/q70GkhSpHcqL86lOb0/In 7v534E6kovDiAF4cXGe9+KFTcA5JX5hPs0yUkEpn4ddoYLPOnKLbyd4+TM36n+mDcfoyybptHcgd P/tmHQ7SjUzyPUxYzZOodg6j+TRjMIhABQmj/+xz/j8181+bmf/3b2YwNIz8JCD+S2b875tHWlv8 oG7snb9fuOXXGbnxzU5wY0HrNiZ4tCT2eVf5Q1xvGIjyNdKoQdTEUEO4eqnde1By+ZwVWOx3+zPh qXUXPzj0tZZJ6Gfi0fx1ywhsOnbyphYvNGF2NJCHos96fDCJ8V43/kBlXnzlrzHRY175Ayu6jLf4 7DFiNfpYU8QDsMCc8W4d+qPXnZq6w+3gbrjHm4MxCGfpXNMaIMl6VnPlYwziS5fGsZgZvD9cSSXf tdhUasIc/VD2nSozkT/mIz55Wj6rBustGtxwYK636a7w7HNZEmbCheOZlBlepUbtczCTr+pz6zIA eep3+1Ch5M1hWG+xWiXoK8iY0Tev5tfwqutMV1JqnsBCvLrxXu7J2xYrEJMwDOaEpOhVxcnrOrQj HjIN5lSRTDTvc7xRhR+cy9UDLc2GCH+58A7BgCJofaaNFa8qQcPu6ROJNp1KTfwqDZQZuVnP3e9U R+3GXpsCF9qs7frrcn6f4BVcGMCfdfpPcwBz+TCuiYj9Az13tIdjUtpRz7Rjp0tU8DQ5AKLqjAXd 4NwWBuo4mAWLiooEfxxOe0r8T5OPpGEc4BqOeL2ua3bk2hEAuEhiQ9zTZulS62MT/JCg5OT/klL6 oEk2sM4gIRyb7ektnVfv6+DtOWKLHpDh7+XiJPinJo0rJM0pcHRFSLiaWdVaMwqKVc4EQjD0iWt3 OiFc5WYIQSBCe8e8RBGja0L955Jlh1IWNL6lfM/CXUQnXfkqOt8VTeWTQNsi1mda0BMOPV9DNDvS eTvW89AQ7z+KxrvPhgX5agosdBFphtM1L8p44moxQhbxBI2QE72PO+TbDU9DgXpCUXwL+jIezcHC kuN4FWDq+LPlvq0BoacwFntHU27QUCgTzXwCV+yy0JGane/nbLQvyds1hd+Nw3b6YyfYbG5onXvF 8saf+foeMNT2PMGm+rTut5mBeNJBAoWyGDTkrfqK2PP7GZopL5e8u8H9kjfR7bfvo7WanK1eS6Ob rHStvUoCcRNqr0PHdizzXOLGOaeYO2Z2x6p/E0UKh+2umfKu1ulg8bU3vsDtJmsFg3yKhgPclvRF UJEffwylmdu7nlonOYVrj/Pg1HbhplpR6LHaAq5FAyEgcT2N5xNrADzXee60oGyLK77BlBYuJADz MwAoJHUaRjGI+nYqVgrilkDBvW69+pJMdLjvhpdUp7uCfFJTJEA7aYFvmiKbhPXCbs4NhCgNcySx 7yHHH0es4Bww+E4WoR7tJ5Gr1/7Pv+ciYd+Izh1vePXtV+S5lktMdl2XbMa+aoffnCYZl5jDwZBF AO3UJhBp/NTYt9v5/vPdA325re5/2zWgJSDtfQx++IMcJzlqu/3SM9Vs8djl6BkOzqbenO4tFdA+ AMcaRupIOPBnPW8xrD7INQLX+rzZA627Vq9RceVqNK7HWTjCD5nx9r50Lm7860hd80570GdN4bm8 lwncFJC0TRPitz3xtTldsAd6Nx31DvXAOiD9+0xRRmuaI+F1DL7ofGKze0A9xCXcnYkVlquKDyzu 3UMmMYvDlYWh879GDjPohsn/vc91HWicjnOmnxfgfZqTnplfhSFa57nqbr3ON+F3vFbxi79tktd4 NisSQvpZHWPfKGjR95Csjck4f//N0zU+8cUZFDFqi0DqU4kMEJpfcAhmqxcRj+YIMLFdH7VrsMEc YjthC2Vdy7nvGQbbhi7tEVtVlhtv4wFxlSEO5Ru46qt0wx1Y7/oINOa9tRIfsTrlnm2AO/k+nb0G g1L4/Vvq0Wu2wlk/u5+kAZ2iqaXjDqI7ZWaOAWOV2YQWsVrjSI8weeP2TLxfdXR2hKveEDkUDuA2 3bkPDpDNR0/9ELmeeM8zLKQfxK1TDLIHdAZMvFucLrjN3TaAR5Q43AcaSPlgPpFqlUw1dBLtOYyx kghc5jPGvdHP5GdwNowOdDF0CnMySDB9nTpFIonsoZ9nFcOmnks0zOL1F1tZ3IpTvJHEeA+K28eJ azbD+PMef8yC5sQriKPez5BxSKHAu8W4emo7rE0B8xU4xL/1gsA+5QtDc9y9WwxHrpQ0XMN9Cpu7 7Tqi034cmDOhMVfShAorkjo56xoVulBeTqzcPLVLJPPcH9LCEv2BayaXufav8jPxuXUJZ02iFE/U o43Fa64sSP98PzuMhq511mlp/hXnFZ7/PtIcNw7OvEnWm4nXUoq4ak/3wKhh7VTfKHLOhPwu6bP2 f57rPzcz/3nqfLsuIUnd3zf8r5uZ/3jjuZzWOzMr7YDv7JcLbAM/dMmO3qWHHxRmVT9mDGSq2WK6 xjq/jJPSrENwVy+GzjlAS6lVWU+7zMto+McF8b8C3DnxpDXsrq/c3Avnc7mAf5l4qHCmV0bW4rpt 8DmrL9lrV0faIg1sa9JAdWtTBnmQP+fZwjgUiZLSP8DZ7vro5/t8oSEPZ7mMlrL+IMPH33gCz2tu eeEOQoObAY6Qe9N1g/i2OblYlikeBcSlJuxqD9NW/ohvswxh/uMhBNbh6bVwpOD+7Y9etC0+haY+ Cg4kKnZMXaW7b/82TtkkIycd+6yf2avLQW7xlzQyl5HGM/ilF4LMHiMH2aiuAJTXX3jjfOzW5y0q z752K7+SKO7Bm60n0YnkJtM39R5/hrY3bi/gGrrb8Mcbu01XGmeeNeykExNhg5XU4y08Ql0bFUdr 4srYZI1x5078aBOfNIaIGlTNyc7ilSb676iXPcH7b3zlMp7Juk5iVukPxzZoMDizh8L1aI2iZzV0 wyaNlP8I3bnouKJ+15/pIiupATAI9+LI9BY+XNMafAEbwPQpki4LHfpeKZr7WxQsMSkdSJ6e7Hpj UjqGxQEEbJCaHS56cKDK4TrIhBGI/pAbNPD5fu9srqnQ3mDTzCXAq+kfDRxu7gbKJNcnZ8+pRmYP K1z/UZOZmsNjM+OqnzWnKAz8gms6QJWfyPl3YnkVLLojA1esp/S4iO5GouKpJl1SmPql69Ao3Lji 0vrPfEboprCPgCofLl3szJD08haFwGCF6VKKdaQuAd6L9wITBDBSOwa6hHY9Dd8EU01Uek4CQXdo aZUt/oruQ+cp1+XsI+nAUEgl+Ksi3Qz3wZ7q3nEqc8gUdrw4QcAlHPCU8Cvjfd/9t5s0atsNv3EO YYDnThcx30UfHqC9a0m66rPAx8GHEnu6CB59wMVNBlNkYD831bqbISHjICnGhd1AodcONRfI3HA6 kk8g7F1kq+dvHJ1RvjPcLB3vyb+6Qupxw/4RBgiIJkeMesZ56XR9EYjO5ylo91Q0j2IoxBcuAEv/ wOx5vkcjCUJAMcfK1t8TwTmao0VZ5GUTCpdb0a5VG8Inpw0CiuikzLuuB0WG/AzN9QEJmz1fAonr 7BImoXzVyhcogrIiz00OmMAAozvBD+g5FafMwN+Oz9wxzYLK3cekPKePrEhOQxqEBKTcV0jdNV09 M4c30sB5kRT55QTuYy3U+jTJdK7bwPiZdow3kdB733v4HNfok2BFykhNhl5kwSj7hKa1WxyZriEf svwAE4yT+gh1zODv7oDL3mv+9QYl1xqjfETwfecZ0mwM4k4BaNfaHhJoAt8nCNyOw5rfRKQUoM6w Mdc7KYRzJG2lwYKW45DguzIA/lMvL0m3jU6FWiTbjzvy6wy/R00GyNcvw4BMvdMpfHL5Ds4nK6ED s9rC98bJuBeHe03dHacjU+5LVa9F7uYDJNgmdo23y8x3glMQ5PjJ/AvQTSSZi9yd6tse0NRdx+0h j9/rQ4jtO1eAxH9Hi1gig4cfp6wl9AtRQAtThHWkoAv5I4y47nF/RGa3KD6drDqJwZXqaCAm/ZHS MEf9bd6LmknX1WsccM531058RD69Z6MLB4WETbzv2oHwbzLMKfDshCbp6k2eb26D1+5AnzLH3nYQ EgM1tctli1ND7qhyIcGq1dvvn/9+x+tUuu/Ozx0dQ9iaHHKYNXi+pD7azmG3w+jrKG7AF/LsSiLL 4EfqT/K/cB8HZq7NDX0NUuy1wT311Bk40d9sQSSZ1rj2mkLUQ8NRwvUwYX/Dzlh0YhCPcA0SEsnc KT4pdkLDA3yn7znoq4sI5948CV+Bg4HY/hEe6tfacqB+ctxpHk4p0Lla37qzHbzphPd8mT9sjJ4S 6fqG9CMAMaSj3HnNc6wXcgOegwx27Me+E3ciQWBEHpTBUM+NBgKaadG4gsdMrvA1Ycj0BS8ivHHu L9EV1wabG1MNI789xeZ9dhog1rIvf2YagzAMiH6lGXWf8YqoDfXYV4/x8o7fOOV0WingIm0lRiyg 6yfyvT0rweD2Gr++u2Kwy0cvO8VXt0NvVsb+4KcN95Gwtn8TWem+nrOXZ3bylMnrPml5OGyA/ze/ T1/MhQZHDgWDmtpp0C2M3/dCGXFo11kT2FabJyrWvUqgxhjkwyvbyE5kHwPS4MNyb7uF/r27Km3y qAVEOVpzYAWJIH2nk/U3qMGl/+/M/I9n5n/Svd0PtyDdXOQjBv3XzMx/SFcyDDiu6iG4BDiOP2qu v5/V+++Tc/WJTXuq8lO48ff3FGAiczooe+4kTq1+ubUbteaca0GRZJYGTN1zC7Jt21w0tR7h2poa Kl8cEaXPXPtvEHvafeIsh/Tcr5gUr76zpTnSZfvOJlGzPTh05FX3m4XzvjRJxhp+m78qDHW+7lb/ wqTRncvKMZerNeMrBv6fzp2rN6v7UQMci8u89G/6xUrV4UGfbbTGwzia0/phOjuAzfsMFRt1Lxsn pnPdt+j14S11mlaoOJa/z9XbEGAAM9qJdDPzYcc782VBQ3c0JVqxeYKv5PI5hrDSKEs7lUmfyS/E mBOO94qk/YG4pLlQ63Z0aBGEY5RaqWb6BZc478C4T/L2/TsU5LR24B2SWpDuSgT1EPCoOHTxcw4y Q8HJnD1a7uEsXBpWi/pewkpRdVc+z8lX8iJahn3w1BufI+6FVtgeYt5D74mn/sH8yvg7sNbWkOb9 SsZXQszwHVJ7U0gSE2stxE9J9E9EwiXYvCMmOEZZH84P78HI0JUm468Ta/8KFZtVWAw6ntaEpCec 5DlmJeN5sthrV55++D6Ao1nRfgLJWYct/jjXAFg3HSjI1/ElxlM1VDm1lgVeEwvhLSrh5mtweQBo e9zP8KCnv79L5Zf4NYKlHPc5Hy2xjqul4zQHhLE/DeImhwRAlvjwOYpNPSLIPEx2rEkUyBENuqcl g7Q4/8TzMXcOAu7XGXlHirV0wbxOTMDJb66POlwGCeTPqXHhJT2aIU/gd7qIXFu3K6f5wjY7ilEU mjLGR0TGBEgbTdvttKFY/4OTetkcqOKVeI41z97TS0YMCLDYVcNxkTkBLwbSNVU8k7fPX3c0XTTK rCEnlztw35PzIVifw7H0At22654+Bi74/C0HtQF3TVifHnL8onVCIjKSI/qjLfdHq85rr+err6D3 jj/rt8NpG+zoosje6KhFQ1ThKhWXEcuX66IfUvKmtvXpdp+kKzlI+IDnFWk8XZOpyMgrBYZOcsd9 /9SagkZbdGbphIqv+OL7/4aGN4ZB7cEGht2t1U2tBiH3WyCWLvpf4pWcF69MihYo4EnUYISW+OYI ErQRaOXIcxow9RkvafCGaYeeX8BzUQSZn2QAfdyL20HEH5XJ9X5ITIr14kHNUzelU5iiuUXEPPJI Z+5OCmEyaL2ZX8VVfCMOxsPFT9E32Jb9SveUCneYJKfyfhdof1TkjsMdu2vlr+SxuNWqZBD0rlf/ RENzg0KLPK93slP83Fds6Gs4dQDUHHTr/nsfeqrGScfKF/DQyQ9vJ0GDyJuHOQn8H4wAbz8YhYi7 76Dvu3XC9ZGGyi8ZhE9UxTh+t4dzrlQfA6ZDwvfXRfdHBEhEFp27r1ujF160RNkhcL3Ojrn630kH kaOjlA5QUuDiS/f6FZrcICbVwh2UPgAqCiTpRm+ermd53esga+Zzjb1E38Cd5pMAMQyar/VvL1cx IvY3Ma/Pan/qWbR87hUq8jMz1H1eCWyvwUWu80q/DMOHG4UyDg7n8Ic/5S/G+kVHWhoNH/8hjFzG G1xXCwkXQR+4CZH3nvZRM32TbFxR1FBbzHfqIBzTlGMPE3guxPce8mQHMJX7oEI4MceZ8QwMfQz+ 0r2Uw8ZFhH5+zuuMuLy6fYhhFZV6Jgc+54TofJszUWeJNj1NWgaJtPEPhbu0zj5lO2oKBZN6aidH PPelchOg8eRh7egfygBBA46Tefb5s0ZfQ9qeDzHhwOC0AdHvnnYL7l1JJ4S5Dpp0dIqw58DOPMc5 JeS15uBj/CnyhpNdR8JofAaJSdB8zwI8xCBiykG3PQyYZ7ehP53AjFo8k3vJ82UQs6dXfs3Fc36z AUHltXaP88kXPtW9OQ+LbcG1Z1Acc9/0lE/41kpeHN0i8tViX+5gBsWBCvMCn9Wsq7eeX/qwTK5q jmJO6YJ9Scrb9CpNjdrRmZDsLS75g1eQ4zyb2FASB/PGiZ0YzkCqz+7VQmsyk62NHB/xoFMp1pcw xGji8A6rNH++B7a+77nYA2AEwqmxNI7HHS0i6zZ2lsviQ0Jxu0+2OZPKjLj4NpfzkygxSwQkDST0 3ifLQoH0j5jgdBJWVY3uzBRlD+YLcW38wTX8zpVdY8YKL17Shrh4OQ07x17/ywemXfeEBsT4uw55 B2j1mQHvkw/sRGvXGgoHg/en/b9m5r+YqGPWT3meHXqJf4tn/jXf3MkU9v8OxLnws7ZJrDNczQKW msA98NMcOqkuBnGMNmVMnYU+bOLiN6rNCrIqZQHvg/eohaCUEubnn+VAff1MtpeIoevEoChZ7v0e Luf4lglSjz5H7wLmTU5UW4Ry9s1iThBBMf7DeRrUJX2+7PVOuJuPGqH5e61UZwcW70+mTmG28FQs ZOIYvYcrPW2Ov3vxqRO9wK38S+y3znXvhN4Xc94JSV9mWK4793RqPxJ70svZZ41mGMq9zjbjkHfX eYk1cK2L9/rT5y2sF/j8rcshL37cuXiH+jGBTWMqgU7lHfg1Ppe3pvr6ZFp9sT/7cddF2QnB1At0 otTfdZh3sF1c5Or0PMU1pG7iTQ6hgVVOoHSl1pLZ1N+BAPUdy3oyLS1cZswYnqsnk2/TsduROsn3 xn6LaSyn8+8nN2rgKG9GHTgqQo3023kYxtiGfuHkyANX8hy4+JeJ4POelEOtOUzOPVafllAzVF3r jY14Y3KIR7yDvf7pYf4pQRLHdEFKEX4Ee0mWBPxQ0/ID07eXqKOdeGhalabzVA1OT3xs51CH0MDT kcXgOB5Nno/HP0CWVlukOeBUI824xarkVKSQJvlo8YUthgLgUtzkClBJp7DkiMON9cVt5QZENFOF 8v5nvx1us36GD3KXCcA5wGvjddlg794PDgLfZ0wjFXiKqMJ2g+AoPC7d3ktEKPoRNCaeFIzTcMRg Ix5TmA5JuQTEDE8HvSDSK8BoEYQOIU0Xrf4sxji+PAmsn8+TF8FTrPkfc9XeE6s6XGK2s4GDhGmy rmFXQQs3h5AVCeEoxDky1R8An44zOxuYPOEERA87LLFnIYlTVe4zdkaW6oMaJqfknNhNcOl11ktH M36mX6TijmhWgVA+nd40g83qnGKBDfT3J+Hm65rsb8jvkA9PuiTb/X5ZrB3DayAM1VwefuTBekAj gvLW2dDuMyHvFUe8T7xZgOZ7ADDvSK96J0U1c8JvnvmoTFQg5EDagg4Ye0tX/FE9sEyhXKHWmrii 4hyE9dcqTIJDB2EuAPB2ZGzWnlPRtO9AKVcr+oB/8v+ha9YSPl0nSzrS5/4i8QdA4k+SReUJOe87 WhdPHHVlIF0O4P1phIKpDsAkedUlPHIIXi4iaQu/NZx602lLRCb5U6juoaEcSpriZtwgCOmx2b2v 2mmX5aHbdbV9vrOve4VLcCd5TsEKnwpU4zgAc4hG9l2jTZHhHRArDTvQJKBPdbu6/s96dTsLcRzq gBDhlk34JLKuiq1PbB+OGF6urunUPREFfIkhtEDOOWw6NkCjz72kJSpgWIryUnZseFEmlUwGgkf1 Srodb4wu+b7kKvaZd0CERJoWCF1KqI6euOs8GOEZQpysC4XBoz18lOD27qW7KivnjTivWxdmcNHp /b7xsrf/dPSlRHtoevQgwl5Nz951m39HolJags4bc690HXWXjv6qUReDs7PBfOKtZ1/njna2O2T4 EgTj6lcs8I4Pf8+anU7YIfdGT94Jk4yFNkDS4sYT9Xn2YMVgMtN43p0uvG3q7BYKYweJvr2fMl7V hRIklipy3Is7vyPdOyrcUI+2uP8ewqhUuHRsV0bBzlC0e7tjNoFviJEuFMMx7Caq50D4ACeXcE1c d027QhrOZE36Y+usLfyJV3yty8N0wXOGE79E5TWmLhy+b9e/HsP3OqNowFXw934pKEEU19ISTkwl qR6kokyTxu/QQsbPv7VAJ2XqrEHYKdMrUplIQcVq5Sob1mz93Lc+2O9atU+yatPRNQS3IxrcnbM/ 7ERQttiYkqURwW7oZ0nUN8DTqYwbaqDT81Htu/BJhVTAeNYIzid3j6L5RRQzG7sKjK1TBH8EG5df XicrN9dBQ/B/UzZWL3rZMAmGSB390ASn0qjnnbQd6LgUddY5BhmDM7sH9zoDes3rGeJKrqbuad/n VK76TIju/83CnNFUjWbg+XxwDj3MRS6cPyQ8uiaDADcxNJXjeGdj+qNj657sGrrpby9ikCLRoN16 Z3JYlrC0xqV1OBt3osdPz+NKDtv/stFB2uG03vdB1mZemoHLCMgXwq9vYQiix54yN/sRdf383Bcj FGB72CX7PRD9/dnMPB4NfuhQbJD78U9K20Tf40/EWkoklm0T1/lwmtbkIJ5LbuG5B0Y4C2Tzqj5Y UGHaEWOh9w56//XXpfTCuX/nVVgmrPUszTjg/2Vm/kukaqExK52ibP9LZubf02eOjl5WQ4POO3Oc 7YhYz3JVdXsNK3Qi7WR9e5H//cluzMuBW1645iWy/udNEVl3YhSyxpu0W/4uPkfes+3War2YJzwH fSWXXqNRs1Ia2bBGZYy1B25V770GunThWfnnqs/W/N5PMpfD+FWYan7belLNS8qHrXL4Sjr9snr0 3M7bWcd0v/xyMO/aEg4l/wya7T1/PfPE817jyKnf5WWYuc11MkHOYa72OwdG71Ho5E25iK+OZHXO Z9rol7mKyzMbh5Q/yStPD/p41Tgbm+1+8xM99tGt+zbRqWHC973prnCrLvb1WX4eM++kYHxedW3o zkj7wmMLKoObNg9RrfeFIeriHRUpnq4+hfE0FeYhMObpVBkBXrfvHcU/J83lnMmgL0b19q8/bvjb GGbgrvJ1k0FPxqxH41ekedSBJFJPkbVZGOyB4z7hebWMM31sicv1wflwkgh3yW1C+mKZrHse2Ceu Co5URVST/k0n+QPFi+6YuDvUCb0azT9l2d+ut9MQnJkQ10cTmMJMew7yRghiVPy80+1jO9v0K7r8 sGaJaa4LQgU7NkjVgImLxOWw+2MjIFBIQbMCioRll0xe3lfrxMGznoiuy1RH89UuLUJw6IJRjG7f drYUGZO91y9NMG/Rm5E6pqu545T6ckkATjG/0vFdtA5T1OsPsapL/MAUt9Yl0pP5PuE0UzJBCKld 3ytjQRXT2g0OisBJc6m/QRNDI7WJakVshv+h924gUFNcAhkLIGomoLfBUD3xbeFHY8+ehtrOsu/v yvdrFK+QoCibIhKhb6BniyfT3W03LUTgvGf8lDTILZoBCckgcZTEA7vidvEwf/fvmiSsi11HcgcC SGsQgn0bhU7c7PCR394Yrchtwi2S0UFcuqYMW2Cdt2+Sc5o5JVgKR70b1NvEExJJ5AbrYzIczvdB 2ceAsxYRgvH5dRPt6TCks3Cn+1pY4XSE8LOLxakBPAamT/fIBCAoLowIRBJaqIreFohd51dKMtI1 SLECKdq3J+i3S8XbWKVPQwKKU/fggINXu8XoYQ9UceNUa82Uk+EDwhFdxgB6uyr92Vf+pXEBuvXv fWx0Vm8Hkjzf20dMNWrX6xiITQ96lFL0NtWOuiuo6nn8DwCOxswLnYKJdMDVheQMD6EE14MiH3I8 uGJtOZ4yEmXWlHU6eelDQp3EAkUzvmfplW5C8EffPOx8PPF5ya1+1zWdKKDDua6/U8td20GYegNc M3A+DH6iryjLASh3CvByJHPM4R4mIFH5mRvdk3z4+BkFHz2s53DdZYcQHVR81/0v0JO4ib9fyJBY /HX2E/RyU8KTJhgE58PrvHm7HG+X/KSTiHThOo338Sb53oEmhciAsuhux/Ob3nyqBXNv/vbkDR7r 7PGKttIWpbKbqqJ37eEkweCTyuF7wgOFI9m7Pmi8oL0rVYCtTWta096jDuLGGPXdAsoL0iXH9We1 me/KJnjaWSUT4l4R6FUV/DhCab0rHTHbrziZxAmGu8BxpwkHtpOAURlDvGSsUcShD0sOesd07n58 tgO7or1K31F172rmF0uAt/alc+utD9Ot7BsD4ZFJocnJdogtSktTAqyv/tHP8bRrv/no+aPPOAZk 7rvJRewVPenGknMHkHzcQ0mUfT4zsdRk7sKJggCcg3TvOHlX74Z9OQrM7/pTWRuKTR2MwwHG4GOd fWK41n28b/YOFSO+J7ZP/UBj19uN7Bqa4wEAHqsW1K68jwzYwkWwUwxzk59eQzw5JK5Kvj06NUH9 ajaDELBEl6xFcC9vTMDliEYDpS9+rsNRkAdfjT0JnT8GDihNYn6Wn/Fnatpp1UD07969jUZSjK8l USLxySBepg9Rgu7KEU/IzU8kxgKJKZCWREOEbx/E+YXBIVS3qI/7ZaaGWqif0hz3+UfOSvxIDQ8D uWro/rtr/UyOXf7Ghez3uXGtGIbW5jcMA4Z0Du5OVVXL6JRJJtskYL+Zv3kn+cqm5Gjq7PkF3+jK 6u/z8ODZb6rXgI//O8BhTgbcNQXzHltsl7WmT9Z/1fdhbbDv8kzrm9oHKhyL+Ivf8DEvLqtFRx// UfQ39txGXi2LMyZG+a/79C3m5TztH23JhThtoZY++dmsDRU9P+OxfZNFHSZKc2obHRp0VvTh9lSC YyUoij/XnPfrHLjbrdHIszVqtf/PzPwPZ/S/uViW1rw8+hsvrOFfN6P/4AT3Mmdeu59e4gc7eNep 6xmQaZ1/YfHn4EZpkHIK5+gB0M1pkI/v4Jk84GAdv0uZFOiP2iTelH72uQ7dVVtpxUiYewj473P2 jW/20NggtthriwxXnv3g1F24HMZvYWXXpXlHcTqMS7z5nrudxu5fuqjW93CSbt+qwu7an8jzYDrN rgH/7N9MHEOFinai5TnQVPqJNhww1mQ/++zHDbpNb8cgUPUMm/V9iYEH9Azdgwp6UDJo+3vG+WGi /J4R0P+ceg3K8dWqZZUi4U/T1uSZXHjHclmHwd9iGyOtMTnar0TF9z50DUnqlwGNn+H2gUQI/UP9 13svTXwOB+73Y15x1TqvDnUPDKaB5TZDyTP0h+uhROyBupWNhN/zkZIX/vyOxcE7E7aMyZCpb/tK 1UzM7uIzNVsztgyyjhTrRgFd6/LW61w86/WMOwVGu6BCjFnHcBrvfpXOmWo/lbIqzld/84l0/lyD aJ1eoUlDVn/oEgQYHlmb/D0zpdKl/2gsdSD2e+Dnn3qaSScpe1vtHxeridzuaRRjNLJOV81//nLl RdjSyBamDQBZLOr4+nY6SHyXZOFb0DGnGxsJxT1zTmEOTgwl4aZsQHqJ2LhohNH2HO3yggEtDgGP HekfEFrkxmiHTBTjqRuiHfMLjWzSw25woYCvA0D8e/+6hVsUx/0FJBtonBZ5qC7Qy2d0uUCqAUGD OPXHwZTE6V0w2VMERDo+2NNHtVR+ih2ZO0wsRDrD+m9HI7wmr/RZjG2R5CCk8UbStSnFnnLdhBA7 xWXzbGyoVa4t5W6gbtDbxSYjwY1O4AZ5zd/zTrwT1vvUfQ7/fYxqMchbEAmDpG+AWjhw4w/6wi0n 9zck/u1SQOEtnh/spl3UBEITBWk0Q14YiuZhk8QqYtSHl8wB/kQEDkcJtVvQX6DK3aQRCdzTilfY KEkTNGdU656GO4peup+N97SPprSfe/wMz8cZTUS0614ZcJTtz06ZE/6AQy+3f5oIJYCNJtV3Tciu hE2c6bkrKUbU5a6goeDXFPMZHKtddeLbSAsIxTkIE1WbzWCAzrUlBAv1EbP9ivD9NM4qUv3y8mly LM/bFgPf/mIucu7XHAxTg9eistupT8dzUQ3gkfi26lT13cdSjDi//ohPTJ/L4V6eQtMmI30KGn3W QGv4Qps8wHhZ8cmBQp8xiFvNALqmuuMX+Msz/RWfUF+qAAy+/Ma7fc66VXD2P8/P3dvoJPAfQgbp PEFc96C7829B9ekeu1y41c2+cFCGB5wMQwued2DheTflsvAxVGcj0N6k8G/06BZ+sdB2Dhouz2RX ksiEa+xPm0CRxo+bb8XQd6/coqp/9lnUAP4X/qCIgdw1nzGe1iVquUdlfAyRaYlxuk6bSBnIEz4T AjMeU3BmOvacD1dYdtTPQZ+f/93Ssct515zYteoSHRGU2hHzagzEeOfTcNhED3Y7A88BZ5IIyNMg 9RsJy8ICzSuu3Ck1nTbRzmOcvZAA4utmnQ5e5TAqcl8kKVgTqyFDCFcuo/vIAGD791mEc0oaAczx Zlni0kLE7LXS4S0jdX8jPLdbjo+7sf9tAy63jQ2ypv8+g9JZi98e75dRyh8gyVJH9Gv1T0ICfuEH K1UiBRpC/HuRob7v9xEjoTR4rQkn1BqGTmJAxzP98j7PhJKNp7VDdezZSHjYUbd68ACd4qvqLZXD pT777xffPX1zlX7OhjpJBxJjFjBo5nLO5wHMdmEaGDFeo2vqIRLXkFUPBDh8j9MrlvqWFrW0oPIn gevmiIxCzH+ML2ksxHDWRg3kgfD4CUIycezZZiPo8Nh9Tw2/vyR3uHxtMjzkQaaq5pa5EjI1K0GO zmCuCQZXnOYaWWEM7ZB45cOP82M7211SPV0SlZ/vrMFbaomagHsZ9HdPv0eSTlDS9UUqa1ju6QNv U6wHDzkRZvpCYU8fqdrNIeQ9RelWMNj+xQnzSp9rlGs7O/oQr/jbNdV9Z6Y7H5/keWLstc3py66h yPtsnq4dQbDdVSuZFETH5Kt35FQmPVeVFt6Z9ekPJmZyKPSUeOqFfpb798zZ7wdqPDUwrcay/eJN iIP99Ef+a2w2KHHmVKFZWOLGH6/ePUbQ4a5Jvocrf33w/MbRDz4z07NTvw55XKKljaO+faNATSFQ aHR3+iZ6Ux4cczzkFasnccPRzfXP/S3nzHWnMh5NqgX60/d+MgxDEDq5Kj8Psvst0PxNc+LS0jw3 3/97Rv+lOsG9xUivcZTjOz59+r9mxv/RK2lOWB3O1lro0gRk2rvAfdfnCr76eU/3dxJXR694z9lb AlKF0ls1NpbaBQNev9NreFhYE2ffyRH6UBm9hnvCz+6zXyac3h/MkQ5jlBwEUfMMwGJWSmLW597D isJEVCHW056ymmvA/3d+d3M9P27gfIa/eJnBJzd1XMS3evUazdSRwZU/XZl5zzUm7jMrdCV8e6ca s9jZH1oRQeLTnJjSILNn0FywyYMPHvXnrO/B96+Oa07+ixLkUttSzluHS31bAiPWMhNDuP+IGWyb CvkwX8wUvoFdSyuGkj33Q+mf6niX2wTBwylAbXr5w+e9gwx59grVeppWXl2am8TNT7WH3WZzdtWt xIXRfKnUZ8L6b0/oDPL83jj+nyEPfWqNM+H9qEs9qEnum3i/5xZDt06nE/WMuEnbA9GOVnGnOoTl u69ha4NWmLWR50tfp/YuKyEeaCYmQHXn6DSISfvd1kkxFzqBr5k1DqJkjFgb+tnT/wTBF1iW0Yzd q89rmPSn8KCocB+LwufkaQtDBp3KqGgYBI4HxDKCdmcXqxDJGYADEYlcWPeFdglR7ll9chB0FZmq iVNjgcnuA/uinijttpP3vhh1QrFEJFPMnz8iQn04W85kJCVNvGST7ntbhVDZ1aQLJ+eetfsIjd+C uKfHZtjL13U5dhHLYpL2CFZFT6jgIhD6YQzGVMGZQx6biDlCI0XAzxVN7JAaqIkxMYjmSTeYbBj9 AQ7qCJy9HKcd/jARG6NvaO+6fARiQ59CDTob2w1plc6Oq1PCE3OI3K39vPfZC66ls3aDZ73b9Evc 1jHPF0VMg13XDPUf8Farn1YIPXIik/3MpgaFHuC0YtG+RK8PeOj4Xg6HkW1BEbwuO+He05haYHET Qm8DMOgYRcQFZY/MGZvmNfkriIjaLo0+4qH9t1G5grT8CcPPeUfpmH6n2mUDpuQ0zAWnA9x5owIX YB6Trj7fO2QSeI6mXigESREbgfJ/3I6uIjmdu8iZUXW6NYGk5R7KUJOCkLTnH0gYInmPod7sZmud jvYBil2OPjrh0rVizM/yD170Eu0+pQq7kanfYk5L8UeM3xwVXJ8rd6cwC/jy4djCwofXOfJ29NTH p91DR/6goVbUoAaeE9WvPkZur9VrEJca75vXCUP/4DtJSTENiX1F66Vj4Ns//PPCe3YR35H2dJe3 M7U+ozC7L9pi80P4/+eZ6a0PqI7oVZo//xJR7Lvji/bdMov3+bF4fOrMTHFNCibePV1i4SJium4X EjubgNlT+Tqrt8EBKH2DMAC0Gc8GIZArgKv81GbvbG27scxyHTD+LgPRnTVSVPTuHXoEE9eZk8hN Ci9/7sdMM9pxxyTImF8/D5O/LsEwwX0ut4ibELlwgq5oNyA9j/MckR53zYF1gThxIIcbL5ducrar gU+gQfqnkXGEf6UgFC7wJMMgomBKmA+9muc0rPD0iELGUK/IbjMuJvBonctlZX0nF07UqJw/KanG rsiZ7Y7/HvjkE276FJ1KxHuT5rQX91mtAJU5rvYHUNl9/E5t2Xe6P84plbiOMLkJuLxwyjpDn/vH iay+sbiJbXIfmKufhuPWjHqsnC3Oa5KIHTiNa2cPBsJe9r6fHe7/nXokuKNh1N+E9e7eQcouXjGA 4Y/o4k7Qy/QzfyA9Teb6U0SwxSCX0LdFURVLHvgFGRJAtYQ93ssbbOzJ4dauQ8DiD67kQp1ahElR zibRADgZa8hXGMyEPIej5Kw1d3nJpoDV8V7JjOY3cQGtkX0P7bG+/d4ioRQw6+VKrxy2LR/yqj0u H/fG6vMnGTEtIU6aJhUX9qElPiHn6ZmpIezFi2mzV1I/5RQQzMcwcw6CHAzDPjX04nJXAqcqXZC5 GUKg/JnQNqfYTPATkytq0fJe40IMkc29XGdn8YmaQ4xpuKNC1G2W8LeAmXg9INnBQT3lH1UfakLQ 0OlGaIhmSqkkUXKc+4cr9UBK2xZhazsk6uLFQUwdRmFbaC9g3/gZbmMMA3rCHOUfM4UfoQbXPY57 4EJ/VSgvDaYMJt7pMHF5zxTNNr/YZ7mGkhSznqEs3jmw4r/3OaooBiznjFyEPWc/et9sJoft3T9p i3F4tI7570wrowSBFq7PocwwGNm0eObmTQW4u04scN/ARg3Bey64RMdk/vOP5NTwTq4T1rOGVP2Y A3hmmf/sQfrh3sKXGgbdt//3Hv83q69XD1m+6bOHIc6/ZWb+1Yzt+TjtGenpBDbjfV01mhkZ2HWN Syg2x4olzO2n7PnB+xTJUNtwiPOLbNbOoOhZEzz27SO/04mNN5ISh/Bbq5GAPZUE/DtVGgtKtCIO RmdN9TOw5B72B96iMWb9pFt4Dt4+T002Aenz3HDzl2/t8fl2kiwllr4C005/ebUKj5OzjUoQMgDg hFHB/vsyKBWeyXOYidVP3O5Xxx1KfK4Lj795lTaQe92jEwFJjoMNp+YXHUr2WK46k3D4ztrLvqex +ler8Xc4yV4DDtdwO2kodPRHzThodoq5MYf0J/1yYpDmMhYZtOhVDa/p0NEkvjXFOdxDdWmw5cZU S1RsqBsMn11Hr3uN8cJdWprbTOdzaFQMTCbXsrT3OsWcNCw//K/0zW1+oTL5Hne/q5OHb6zyS4nA jMadWJ21JQ+wd6rjV2q0lhFo9m08ZvWa5urv3UDD4Aqd2dag3pU1rcA0K8vB8Bz0UHHYrea5DHA2 NvrT03k6IfSPWcKf3/xPiub69k9Q0ZN6APZyYnqqxD2pk8ep1wWlo0i4Dq8GifdhJYihNoDvdRm9 0eTq8kp1SRmIOorTyw3hE5Q3iGkTBKZNac8/AOoe7udHcfiCE3wR3xEUJHvSWRIMxHc0cf3Z1Pvr amR3zAY0EZ6ZOaNJ3V7LTqea2wfFJehvArafVfvzNtl4EfgX5ft77Oh8gjITgP/t1Hs3nQO/s8+n mtjS5RdwF5+OhqeEV6Z3dI2ukNMvC74nIn3IVZv97zka8SRACzC/gPecWHyAFnDQTnHxe5ZnWgHF eWnSBfGIyZxwzTzE1Vfs5PceZ9Bl3VCa5U5FojTjHO6XSNrVlH1Tb0RS/xS2i17THPG0iuLQAfAQ 7AHOq8dwxgtyXiKP3wHrTDAggeuUwPN2dfumNK+b5S6fhZ95jjsgpUhXAsBNINHduUmWW7b6rAeb hziG93Y2+91EM4zB0/ZdrP+pp1yC+KsBaI+9q6ZYU9h6QYl2t0ghVK65amJPF7que7o2UwkzfcQy tmOUPkDdaN7FtcEfwPV1plvpLCE0mHqvG9RNEasnp4N9gMNbrPXTmAyINWLF+SFd/eWX07X5K5zu kUFPO9ca3TS8/vwGrH6iQpP4v+ma9yntBKHU+FG9PYfI4PLSVzXnPoGK+exTWmSwRZA74WPOO9/g LHFNtHM9/kyQmzqGIDpr+KgTkQj800GzK8B3zQ2qCH9C3zF90rxDZNtJWyfo3CBk1eOaj3ehQ5Cg HgWV8MxqAeXtqp+wG8vWRQa40Jvpo+PqgUKf596s555iqh4NmRIxsNB+Iv0sxQpzDD1fNaPOfl6a Arja/fmBp0R9X95KsN7c7jBCYVULFGggsYnka1DPH6YCBJTep0rfKXCvuJ9xf6u+13qkRScqwqlT asAxhxiQdL+wAcfaniHBMYOaWY/tPfwjVO86UUCqkEPH37tbOaQ/8yUQ7mG+rl3DU4FFe/h78gz4 +Yx/61tn52OIXd1uM/s7f3TG/hK36CSM14mnOUQHLkJ6iQ+97w7/LcZSOGZ0zMwayjigIazZ7xX3 M0ylIHzKpcxJsvkDRx7ABVrO/OcsNb6HXjMZz70cj4jYFp9SDqzKiAfe5MRv4sF0IP0RQ305pDWG +9Y7jRd3T7zPifscz7P8y8/ydTwu4w8cXNGR+jFwjnYvNkNDY+wRLZhYeR3DVHika385aXD/YHWE LbOQwx8iBwd3Gj3PEuUfYhXtPVeOnG7XyZV8GBHj+hzmMvqLlWFLeWht0o2ZERe3dZ23SJweBgs0 OsBmQT6d/9PcJhNjDHi2pl3wBvkAr+SMK92shl9EiFmbXJD09RV6CN3S3vueuMGrd71Ek4LOiwYB XHWskACfX3pwlvt45mN9f5DAmPR5mdC810uL7KlKz2f/9zwXSFBenilSY65Rjyls/LvH4aSKPkuL S2X28XFAhPvWN2/o1VcNnHHpkv9zplU6sASST63PyKY4hD5eHvs+cJxMSGL0NNeQmU1i3ONNw7FB ApRYyPW721jlC/9IzcAeaid8zXMNj/X91UmluReEmI8Ll1xJDm/tKULHBffkxjD01HK6jKrEg2bk zJlvhrQPQ1hgdaOGnoDuqBlOGPlHOB93ikjhBo+xgNnQL8W0qnpKxVMbEyIvyaALmx/NqnOa72g9 zW0sOGUApwUur8/0z834vzcz/4dOg2nxEulGnprhXzrjfw+/s0406UQnRyLvZXlw+Cn/Fdkp7qKo 3aPX2ckN+ZQd/HY62Q+KG/XUQl6i8wGelquJ5t7ZDCSxlDbZE6DM8Xc169y4TRS+EqkT0xQKf5Pf 74oxUxC9XHAbb+Zcz3c4lblDgVaFRb1f1d077Jc1Kb9Zer46etlMyWhMuI0rHQljglot+lQn5m3g NSmtyYeOY5Y531f3tHglt8Ff/x7jyhQ6tztE3kK25Q9+pEi16yRB1QjsTpfQaSlVdXWkfr39VqJi LSKdg+tZ9uQ/IlgYnn31AoT0Z5orG9x4V/giRc/Gnl8cbSqpY4p/oNqHq9kfY58cZsma6E6M98KQ BvhDLxyd6sQXi0ksjIfY91nuX3UtZDAkOAnmtD6j9PVH22q+4XXo/O7x40v5t2vfK33q5dMTP95G jTrTt9bAIAw9p4njWvPuXstoLHulMwEW8NSfG08WDtVWHfSppeO3nGOtjetxH8N1x1ffGbel5sCd zYyE42krEr6ez+anf/3ze//Jy+ntAkUirqLsn9ROTHFxEt2cIK3QIaIjKYu+kz4PvbdwfRdU+NVt Eak4SoyLDwVRx+K+IvphgjClmUWdaIY8ytc3EpF/vPiNpToDaCMiKre7r8+fQdEoOkKGNXtatAUo myTqw4unXzr2lcUknjmvAxKeGbzPBTFRV1SXSrTsav5/Eywng8lxVD7831T//tQaF7hC2P94eM0F /tbknWtFL0FrRhv9IS7FobXDUdG+vtFqUBZAagzI2yeZ3/8mF6eQceB5wQDsF93bsTyzGnIi7Hbc 3C7KJ4r6cvnMhsm97qQriliH61071o1ft4K9vi8Hh5zKD2rqOOvezzV15/EAyCWsjNPBXZj4U2Lz FfuuIh1vsYnv5JH3O4qItE41abnCc/6pyapz6rTcObY7Pomqs774mujmBIML9DyAeB7vqG/OcbS9 5g3ClpesvdrFOU6Gbu1V7mfZiNO31OECx7LyvC1ZHGZwgHe47PdeDwH0Oue/IrupKXlONIlj6h+w 08OOerewRse6I6Ct0zO2JPLyBaL4XAaEb2BxxxKmxGITIlPRv9dZmeOhf1M6TMMCcwDTCfoyRGXv 6V0FaUNeeBnDmMIiquz6G+r8zATgejkXdOpNAz1E1ipcwZ/zxlPpPz6qynT1ufZjvV8A/lTnnhGk 5sGbrNtolTOteVJW3mfW5ZnyNtLlsnPSu5cjvI91oRrY+iEVWbjwOjTtYDefhLpgLwpAf64jfHzD LUDdQirhEagQJG13SKoxZ64BVhKZXUkfRkLHjwvN7ZRKXfpF7Hc6QAwcO9JtDnCy7nHxk3lFQIqS jkGiWHs2uB1eo2LUx77nCiU3JB4zw86Aby/hv4S+D+DWAHlS77H7QXZ/uHPYIAGjIO2BYYg8x6G+ c2MxU+A3EF5Q/c6Bi53iLO8a1g/Z50u45YH6YbsEVhIUujheALuxvv97Jwju6JmKDd3JeS2W8DPQ noC98ZwcjOhNIjejwOekL8kKwHAjv0M/AwN0rxPZBI6p+nuYVSm+l3jQUIB5sIx3g9liYkldw7Ww gwZidKI0RQ/YcMZOnHsplBnAcrtvW86eEvRJqhTT33DbOe8PugP32bpqJBF+ze6U732EscNAL3Wl 5Q/RUAuiO8r469/rWtmYYkmR9Jz084t87gPRdRDUTNwbq/Kv5CchjlUktr58zvNOE/ZQKT6cMtGJ G06dHKnjTL9RZVet3fWC5h3AFAyqsFP5wJm5BdkLCRFjY9dwQ7oGXyONJOecGL7rQfSBc8txPhkQ Zkq822/PJTzLpM3vVMscOu4KTsiPvfgb3JSItxh/wvc7qg7MhK/449s1zvzWbpyj7A9EZxDP+juA 6hTotovxt5jYQ6kYzHl8DXY238VWHMLhsvfMeIc1ddTWghMmSekfIVzKV9rdX/oyqfJx1+UZy6YQ UzzynNhkOpVXSpxWBsPG7PRTAxCntrFOXnerztXv+3kAO34HZdaq9UBdQnuP4+MV6dxUN9PAgz6z gPpdr+eqqYEkN4sFd+x1Z/pxLeUEvT/crGr3ezjren/u87Y071ufQtCPd1N/bqgerlpjjhqKOaX9 Pihjt40VprgtfzpgG4cWFfj0VVvudBu+x6/BjoHhrHZWfeslTB0KzNzDg4BbyNz18y/kfWHr74CB f7lZSUvi+uw9fAhOpf+fGf3n8k7WgdtsnFnJ2vxr7fkPkjZnr5zNXuZwXJ9LswYvvpUWITgXufg3 r7zNCcJDeaXCNCcldNb/Gs4gI07I1dYMy96iyrrSKEwn3uZjNVTLb5EhjaF7GUrOR+pur1Ppy53a c9kvTtzRdK6+SHsO5Qu6oxvPJf7i63TXwhs25qDgBQzGKVzzTvVamq/B3EETOzKb2L3TNiX7wV/e NaQQDr/3Vjv4d/LQbYkKXM2fQWkRYyTs4QgreA3XNu/y43i+zF58r2OBq/PiRA/Lk4l9QgYUiY50 shtpq9KczR/Mtg9sUUdWjQDFi/0FYvar1r9NTqew6Dlw9fdcsm8W/28y74MvGHQ3wvvg504SmszF UCGeGSqBb2qaLjn6hUYPDru+xlWJHcAQgTvd1peaSRcz5KV//RlepV5VWO+2eQsNATAGTdoZqe+Y OZgwesJVdwfeilq1M1ky791mwaT9CIRmXm3Au3UNAkQ1OkJ7rQka2lVoaVR3sIdVs/pUpgx0FVST 1vmt/PnGmgqzQjzzT99Fc7tt5UEoBKB9eKPm8SgA32hynkFMBgImJji8iPT9nFOgzYtDcwuhSjSj dPK+gYxdiD4OCQc0OwFgDhC3nj2RTE56d+Opcr3n0AYGSV8RSrl2m/3Z2wk6CggTYBCFsr5gvxl2 ZwlS2kR5fAtzGjC6xSEqUc58F2FAQ/qjTXpJ2yuw8v3mWEJAfLBPMNzlIH87Sn4D4UV26Y3t3QV9 igD/edejDRaTWFbr+Rzu8bFGfwYVvB/xQYe9F6BEsIWjaU+xxPxa0KFbqe9L/D2v2YP+Kcox7mc+ pq+1CiAOAeXoyt6zDfp7BqbHsHVfhe4Ww3X7/kXKtnsCRIIdSROCou11Uc4i6mdaOEm23hMtYOgh o6usSEDSUNzkSW94Liz+7B3OMB659V7Ahz5+Bwuw30nbBAd+YtvmAPZmOOg5yzNymAsK0552oGlS +J53z/rJJ4FEAesGUkJFUuQNzV4ELKulv6UPMKUFuy5Ca2YQ2jImhmSE2AQgd0nwaweJHQj/MRcw 1eAUgUVNJrli3jcg15Ly1yHE1WZ62AXaiZlUC9/T5wIHna6Hmqr1c19OAcsqQNCHSKbr3Z/7/Yv4 dtXVBm8pn21mn/C4gorU/hF5aoGa90DORfhrgQMQ5areiReY57hLtwOGzsb1mrJOYRP6A4QI4xJI fp05LR6fA4SjOMpbjPQTzdzkGhOSF6ka94o7rpjJ1e328zPcpBPm+4lkI0DfhxNE1zPXwOy7T1wk nSsZJl1g2p0sUx2ukYUU2T6iIGk5vM3prOGoIyMa0j76NVgXcfbNkMO6f5LrDifLJM3baaKH4+19 oq64+ScJ4iJUTwcHc+3efaxgSJ16XSArcjcr4pnDAVnHW/hy0N/gMPVJnjv1LSMbafiz34mAkPZc 8eB7IL/I6ZkP16AEFnP4kEW+P2R8jrTSKNrPvipHYT+Dh5ol+A4vnk2rfA7gxAhcxKo7hTRqulsf xIZOoQbbKZBIk3CnfIKOwXjFeTVoyEEEYuORLwS5hzBT+E9nCZPJTCLuNCOWle1o8jtOfcLd6+4D tvlAO2rPUW+W2PCo+X4iTwfW2ZTgYrvyqXDTd18oSAPBeXkhzi28utzSQVQSDpz6deW/kete5I+h 1/Zsh6OMwt6JC3uFXfenQAgyRZT1PSzoB/muJvHx1M8SoE7cmwt6uKnvoBO7uF1U9UkgczD7m3a0 BrvdrqxrXZgcyencv/EyUVcNCUgZL87Vqg9hBt/GV3aqgQD9Et77cKBft6uw6weSVY1nrjsJUdUY 5QmDD6fwYopaz4HsNwWlcb+vSPQJ/KzrnsYBB2qfQbF4IrgqD9fOSCPxwMmx6ULg3vrl6iO7EnyT e1/RYoqAWMi0hY/vUD25ES9DLHOtwUKkfT/8vFudd03i+XwXMWcqSFR979lthjQgNhg8P3et2ikK +/OGkyOahLChBouFfMgFUxS3z8rEvdq4KW2TXGKjlwuq3szd//T5M0fC2GXiMojvpWfwxuBS1usP Dto1eJos8/3pr39vMD2bcDcdmWzp1M85QT3A9wc3FPIKYCywOJspfDmHi5k1eM/+TvFOAX8aHznS jVQukRfXA8OCcJPfcrvNFv/oB3Tevlv4vt9UpwCyUcHLYZFRQtZWW6TmoYFWn+JDMBM567yP2klk cjbfGCxUoz75RAPjSyaUea90T5JDDK/7+0B/uwzP7P/VzPz399kgrKG+0pH+2X//qyX9xxyGOg7z AR/4bY+X8+DAWj8e6D3FOBog89fJ8vf/cj9DHcJkYw//3IbKGjnP/DRTU/9tTG3yMtP7q9E5BPC3 mYoxrZbSzbX6+ub9317T+DvndAK+c6n4jnmdw7cCrfGVje1cY05Ru5ml2tSrtEorsKK/y8qoAUt3 ftX9xDgPfy79okDS4tDKskApVu+0zzcp9seUcvNPPi0p5xyO1rxpNx5KyzP2poQvGExp/tmZosCX wmTTM/Ge6Px3LYeFDNlYYQll2GnyStzUhTfs809HLZZ/ts7k4O33eWr0AZ8XYyzdgwID3EniyUOn qLiHtl4huwATdvT5r+5pCk+8Ej1vW64wGDXrlJhhgeEvhymCVDpWlV6UVEQ7YS1T8X6GlSlhhjQs E+kq8c/0U6tdvvx5V7tE/4mxdaebaZ7CPKArLcNYP5GhgYc0a82v/+XPdY9j0V4zInN3F88Dpwqu 7Rrw1+ZdtPHaraG69FE/bvbwkzsNwTRy7yFjTh24+Ys2+TPZmYfypZl/anW+DgGOIZ6ZBAnkRtok GJrxO0VIU6RwL7oUEl/TlNksCADYPnj4992NhuHIMUQK0pTin0k1hgUVzfMl2pxyVLt+L7XGBQLZ WIQbCOKcNF1tpvrSYKGA6rsMivt0BhhejUuJ6KOQEsz18DTdxMEgFI2UkOgg509Jgn8KjB1VxO30 GmrwHNHjFMEmALOMhNYrRKGgnsGrXPDMORRqnmZsN+ZEhAvWH01l86GdDgE/sVrZOJCzYRMLf50+ nELIr+jcp1w/JtpoEGCefyfFX/6V7BKcsYMTmlmUCFwf2qmb3/NgGd4N08/UpArwpJ21Jt21Ez5e x+y7tUunB3bO+fKvzmIqxakZv+wxvh7D2fyH3FeRyFOFXCakUFoLn240SMIuO0b4W9OBy6rzJuM/ dcL4jkLyFX0BlqX7/Sr2jTAyqu91T4qtbzd4hxAp36miDtIvv3tHK15jSwMCmzzX5zizhO94D/Xp gJh01HP0DLfY4EfMCMTj4S40sXb+MX+cvktVjUCmsWgRzca2h0miqXt4N303ZdWfrQEUkewI2gcX weIh4Ryd1y328QzES3OD5iIE49ua3O/8ASI88c5IutLg4i32YHkeu/2dq0nZfvM9+u1AMHBuzwEg g2NGnWrzsZ4nhJHt7N7jD+m22/ISctncDjl+tZMVLb7OXdP+2YBap8H4H7rP89MvUkQ6+rX5NSx+ i4QDTNfhgGcGFnX1Fp9yf3bpFP78y002BH8LlKQunibpM8pxYq1dsoQnslxQywPolmC5AjNYbzMd h09ii9OZ3uSI7QKsA1QZkI7t4W0UJGmTFev8fuKWtZ6zPk6Z7Q6s47yZX7KhHLTTnVrEEZlKsgPO b9eOO0i697+hLrmFmE1sGwlJlBLBep+j+zOOkm9XEcOaI7cjTt/zUcOREOUChvcg8saScCTFg0+N xOlv37oE/zBgt0lPqmp9OmkZ610dWE+mOzFu1/jIrlUL+Nf8evN83SDp5rUxKNqrgyk0tWfdw5N1 DBeW8EPs5UAGDmJKMBz03FivwYaECRxUB68K2xOOqPF0wc2OHEGzn9445vNnQgp7CwPq3h/oDQex pnc+vZOZEs9pfDCNHTKZ6D7HmzpV2L7/xfF0fOaPHC3+vu/gZ7sdJcGmX+or14jRTLso6/Tx9Ne6 Tyc8G76zgG7LAfo95Mk5D+S020Lc91HvlNokuFpM7AMP+BRuedciU8KZjfdRD8BE/My3AJ6Gv/XB r3R9Mr7tJja+g9LbwvsIz6wBObdRCfWbrkvUsK8U+IFD7PdEobuxciGmTth4uKzqewRjPnFzwQiN joQBGg6OMznEOQIc63VgVfW4qh6W5HhekfEGjPXu+zNdlsWie/Ao3WYNiRw+WLTeC1/IhADtJ/fh qZ5/jvX08r1b3HjV/T7wJjp/fFRLX3kaF0Lesp1rh5Bxj4q18kqD3veBUI6wh5OuGpHEVfvTb1GL 0TYu1+IMjw/NTfdPCwDj8ynvMB50v5lLwpQ2rzeHuHHfiz3802IqFZ7o4nC+8cSS6Ypc0gX7+xd5 vqZ4q0EUdZuzCIS4Arb0O5N8p/yNLzyyJEo/tZtUQ55/MUHTft0i+akE495r+e/fNlI/FyrL8Tof VSWwYcs3ltHeHOAWifGe+HtXu7mfHrownMt3DnI/q5/kggkB3ysWJldfBd8dgvP/l6T/6oz/X1Qi 5L12py39FZD9W2bmXzXAGrbov0YsD07LlTXzngTbwKH1RHfuuw7NiAq7e1OMMt2+Uwrn0J/AuJOp fvM2J3Bz5sTpKMx30sBhSic0g0m+JuzQaOSZ/fsyOFDXaaTwmcBffXY1ih5s48D6xPFnJ5Xr4K4W h51DFu363MwppcBu3nP5gIcG7EfjoYNX3uYylGzwj/CleeK3sdGuCRvP0DcyKVBN+NbSMIenX0xw /WGf1UlDOvb/uhfVPe7Pe6rdO1uIqxPTldoFmfghYe2Y98+XIYFOToZSicnmInktafBW2mlH+XfZ TEOFfwpSfZr/MqaqfCXbbjzeID1/62BOgG7NxDaT0uJvjF7jJGzedS8NkuxUsZ9BCrWHdXX3OUT/ vqO1A5xaXbKz1nCCJT/51C52hh3dsfTM9cnQ0qCcqw4jPnLKeMzVzZh7aE338B7k2N936i8/F0MX 6OZu9zubGUhUoE4NkwpmoP8ZOMl/kjFVygAYY5GA596Y31tP+hc1hk7TgJkv29V/SsiPIYXW7mOc CkS/JGlAZQATIS7y9qYn7xi8bsS9oBLXbPxFg1+ilX1h/4i684CCSD3vwvQlh7J9y2Z/u+a5gI9X lJhQDzkbGiILZ16HgLgUlztQTmlcwKUOYuj26eiRg75A9oSwoABj11MG3ZkMNTlhR/QNOlN9xJjM XK6ND1moTZirAJgOF/VT9e8p7a813JCpQ6a7i4VdKHnuucwsits9bR/CLcpi5zhq4pNMMYp+tOLe lXHVvskjZzxirhdtcdkde0XriaLcfLTlU8IDktwQnUzkk2uQQUf0mgtg6u/FbqM+gY1ZcVjlxuct wJqYFi+Bi78md5P8zCnMjM67pSbrhPEmNFMwJgBBKRYUL2oNEEPUEl7FjWf+oUbXnQ7yiPPnAVne gQ6iH5rEFO7DUxTiJHx7gItk9ROurHzuGuP/5gArVoWg3aZ00FQ2C1lwT9zfh9uO2LMGiRPfVBxJ hb+dWnROrs7jwGd/7a4WAjgJTkFtcw4ThjDjXWOAUNkFe2ODS/HCLId6f9eg4zmfhfR2v9y697lj fPY83qeP9sSnq+SVRKPR2fqluC+cS023nP/259d9iJWhMplpCqC4Wh0d7S/GppqHdm4Ids53Tc+n 48z2wIyK/PC5Vtg3qwdgexgqgVBN52s8FKzSqY0g299iBXnwhx15GNzUm+eG7Z5QPjEzH6lEFylD bvmG5y8g+JqsXetRnADhx0238xr0UX9G8s0pFfAJwV/3zqA8vN2YfgDQr6QX6k1/g9pdzjYMAGqd K5Q8sO5e957q848AF4XjYaZ6GGQH95DKSxrt3pj6Ra9j3+h0AfHllTigb/ziF+Ija7l75al6F6pu BTVqft6UI456TetIb3vBwRcT6Pe1DQn8JZTAepnqef/672U0Nw+RbbKVbBiyi85zWTBk3a7YAHBq 92LZ6y7RnmjggVdbEhucN5d7p8UiTeBpiZn90VdxcscAZuQ6d7ve3X2rjjOQPX1+S/bzYPw6nFlJ eLxDeC9x3m6qE+cqDTZ2AoyJKNAPoG/A6PLuoJ2TiWopmhP0Xr3TvgYUft7X208WrbRE4ELyWmBG cKVNSnedlDWHD0EhDW7kHclyOXLJ9MLxHLVKuvL4RPl8lGQhTlPneBjIzTz3/pw7ay2IBoze+OqQ MtolIO6zGO7dV7DvrItUBjotRHn61dMVWjOHGKqRIAM2TY7HxsGXurv0YdmgJhqXGMqG84lSDqY4 oXSwvs/lG9vtdiD4J0iMzHzHJN583hd76fMQzh5qpVTRQ8E3vzqlSofxBPVwB89Qwl2haUNye7dd iRcu8p4RneaxuQlhxRTup756rURxiLwVYutz1M766OP7nelI9Iud4NkJTbGQdNZLmkFX/Kl+Js8R R3+Q4ih/YAobO3ck4A5gPbdNB2O7aWp2oZI/a+gSlWgR//c+SlygrdxCYHbcYY6zq9xna/hT4WAq GPlw9XabN+hkrMQFxxPvXMheJ44tfQ3IOZzzdo2zuVJB9vTlOL7NEHzWN5CSTjld7s/XOzHqaDUH vdObDIhhiP7Ng3jExb7dpGbQFXvQ1b33UYtKBlIuIAUWU6x98NsKR8rs116nX/Io9pPAqergM1mS RtgUF7wnxWmMS5RYXnQ/++wVfOWYPUJm6Xek5OXr9YGNbv0GDbyJupLuQ/SHc2bmPY0sdAwAQQX/ n2x32hy2fPEVvlU08y/V6N/bjCUN0+hguQ++yzNz2ma9XBDfFUIM9WvgSh/YTvaTlFoixH/ftLRM HHG+679peFsI3W7LlHFD442b12qNkoOHvRB2DxtfDOCwV3pj8iMubkRz2FCq6/k7GdxVF5axybSJ zVKe2B/4WdbWLvfuKVOTxJm8NB4+MIOX30xdhWuItB2RG53RBzasv4O3+2yk4Syq3Od4b7eoHY3P tPdNa+aj7jbX2n81AG6TLi9ejZ348971fBvMktngu1ZTh1IDEcMc03zyKmxwNDWI0+nUPswDDAPc Qh3jjV81t8819HlmYXK8TqbJiKF9jQ1CGn08N8rcyG6th+sMPflMDnL6FPsaKqfb9E6H2QvXMlrp W2Vs5AuP4ppuAnsVaOraJqsNSeZMEWWjqm0YJdBouP3VqjZIwxd4HvVOEnOP+t47ZXfCRKv7M22H fPNe7yG3OTmlOXEiOoFbDZa1VuI0qt931Xqp8/B65pfZFovbaYD1NWXV/FONJLxbzCSfbFkEA3eO AntqUnhOT4U3ascQ6jxnA+AzxmtLCBLoaKpNi0wxTkazG5POoiSB5oZgSWTnIowNbqLeKbhBmCgW 1iZifF4KS9j4giAQoU2+I1ezdgljmPRsylFAMb+OfH3BsuhT5SDo+v/6iPSx6WbaPWiDM3Q16HR4 z8iVGYr+I0daAlL3u26BaZOK8fYc9Nkic+An2QDyd14BwZJfBLCHxwhMl7bnmNvreMql88EWKUnZ FmxE+DlOJW8nqXh2rt8yg9FuUw7wX0HOnqky4DyJlY1Seg3lAIM/BCc78nYLTvaZtGNgdxNHrrnn W9XXlc5n/Z6UFHyPBBcDiNQ7PHEAJqYYnaTk5xC6hNNYNGdb8LGJ8PlMgmiHpYzLXvfFTMR7DYhS yJ2O46YJVs13yOIiivjdJK6gcTGePI77U0db9L5HHYWbwrXxp3hdsLhgUvd0xlYVkC4CdQ9uOCPP AZi6po2brNaP6FjREPl2GRfec6poLX2QVBtE7721AbgnvteeM57uJOZ4bzuIEpAFDLmg8wCKhgc8 fIx/Trj8EeQtPNfaMU2xBx1kpoYdTlhkk6Bhih0FDoqCVWEkPFSAqCAdQgGcishUz7nGkgTfAGY2 WyQW3mfsG2WWooslhVULQ1rESk4pl2fVFdXrBTCjyG0uh8B4TyuphjwX/AsxwyAJn8dfrvTZ2bUb ez4b4017Cw7o7k73jQYz5mjoIcYyzrTfoQehfKDoNPe5cOel5OcVOow3cOeDrJ3hxCwizedxlh0Q dVyDoR50ZTT3vX5BIhDx7zX1umNRJwsBg9r794yIr/qASUSTS5tpTNunC/bfc0+DwJyht8xksC2M xm8xNeQEkOXAjjbSYORiwv/+DbpT4kpgAmIsxkEwC85QzZzDwg4jgFtInSKzToTSRd4fZ/NFcGzC 8wHXA/P5IXtbZCR8551Y1SKewXfJIhHGT6iaeiNzy3ESnbZZYrTqJHv1m90DQndrFwnMYevkLP9b 4hqJiqNXPtIUKGEvk0f4bvGwsYOwzhQgsuliJzwzrpv6d2zYH/3FwGnhYTKao9vbBc9Okofw2qma 9MK1G5ccOLeNMbSXi9orqDEKtS6U4fIAa8wj19si/73x8Td55WvojmXYjQFLX35lU+fbH6GVywEr V7s/BgrcmL6uvjRT/DwFJIbxj0/s+ML2Bp8/ucD9DHHwO/sR8c+Qv9jA2McP3nFEsi+s1x/ktsGE g7qAduMa4IB4MJkTa15XMZ0kraCG3oRj4l2eTlMbNU61E4kG3LJbJDmQ8HRxDvrtLoFkmXSU71qg 03PxE0vbPVM9frx7bQ2P5+xzjBOLZqXD0XueU5SSYqnGNr4cMFPixoT2z3rxYbAyIWj5x2q6J90F 8PkLi+TbwMudOAUQW5w7YWa1uZPfhImNmugh8+/nL33XAu1werj8eZA9fgd2/DFUwGIGXd33FuLo NfwIIYBndRsOoezf34f9vB4+PbmhyFwwfzYa3Np4ACMNV49mn90u9rk6kAgWZfd59q7TWZghqwk2 9+plMqfsFeNpvf+HkPN4TVioqtz863eOGD1HHqih4dQe8mORF9eFl5BUpxu10TYjDQCmjBH+csnu 4b0yRzGP/M7BlxGi59O32kMZ28gSoaCyxUTds2eigcPM7R7U8YdOIhMWHXxz89KMVsbQ0P9Xo/+R x//LV1jKiL+Gh/gWb/KvmfF/eDuVC9A1OKOqp4lUGulwed7n6XbAh9oFXNDXfnHz5XMaTxrEWQNi /lnn/TJ0KU3LD56zEsFXkv1j7qWpOpLrogm3+8YvU6OUn4kwhD7btc7s5WyL58dOvjPyyvxO2mGY sWqTZYF931+p0ZDwE/QVuPnf/Aw0AtlGXVPPVNCvtfpDy+TFIHDvVCaH5q6rnB6Cntqj25gv0xFy sAC0XyaUYBczS4swc7inC9O1Jr4P8+0+EkeVtlC7LziHOFrnhyyYBMMgDk1iKyvW/3oGSVv7QELp xnU1neSu4Fo27rFNazp1zv1+vVMS50TP7oHbiy9jEz6jxmHV0b94QvrQuxgc0JOzWmOeungEV3rZ 3Ucyy6Laz5e2stM7eyhHkfTTudn+GOa68i148OfSgkxoOoIjcIr7DVxZmrldPMl1VrhGhzur9uqJ jGYnzM8dQxcawIDn5En3oK3WEHXfuGQEwntl6WLFPQslDQrqHxpyZ3y37/dOIrjMxTz/lLb12a9e MTX69G06pjX97beY09uaHZm5i2hu3jq2ip1DhHKPPLb2ZIjjgQ40zh6OoGWfc58kxJzyfp1y++38 4Sr3HMDrfMhQVvOuHacjAF9vpwWKVFMJHm+/N2PI9BQZirNm0/L0lKz7oFv0KYvLAQwuHuKpiv1r srjKhvCfv2Rm5hcn5I7nmA8y5fZA3Y2bwoHtDripQDmxI2W7LxIwsPd5XqSqZIkmLJdg1kmutKh/ DmlFF9uqaOYveUu66b1rLl3fO2LIBZ14NU/tsNYxyiT1JGCE4p3nBHKz6WG3jh2lSCT9HMU+Fou+ ZuqNPvJCcIj3wY4Be8/0d7qa4nt7Bk0Ch7aIRW25t6bnvQfvm3dvVWGgvo/pbulIUKYdG2TTQTI8 oA+QOOTC31N7hhLsKpp5ZVKjs5MAZig+/QVh+WzNgSEqGI2OKJ2Vwjd0zyWzpFpnW3CXsRQRer5n N6mualhd+x/bUs1c7piDf0pTzxqKvWSytwWkt0tmkyxJiqgAVB/+FaoI565DruG4/oxEAifIJRSE 3e696/z3Hb23m22Bo+O3k4oOwSoJiIUjWDx1TtKz5YDirod7qtsneSAN1HgJpEY1+ZwH6Tj9rgOO gTa6GQlq2+tebvfa8ERQR202iPslU9wOHu9+/qoQLrernfIQcJYHB0i+P+VNP20yp1OBUqCsJaZ4 Kgq1p/DrfvDTp1L6zQaxM+VDOImfoE6f3R01JwAdh7yBRod4ZQ+NkIvIFja3o7I++oLn//bvpO4L rBlr6hzE2qTedsNTs9bkn1buE1ciUNOOOmQPTTQ5BrX2UFIJz/XhWk5Aooio6bSJXZNTLepzn2EK Wvb+nkNQdw0e7jPjXU88OD/guAvAoRPzmWMUrcnnv3tW1Bv67Pm35rGFlG99ormGHslJSHhetOh4 lXHTBgn77Fo/i5IVtUmUrsiMo/OUatTVOgs28E2LhkEpEwGG0x+lQiZJ/vzcfe/4SF/bMQN8uxsJ VBd+2X2AsPc3DCMzVWY8vwVSXx1Au5aD54Cwgu7djvhmZ32jmGECuPZJ3F61HDsjd9//lbgQ+ArA Y4eNxKqdfXQpt+XBjzFDvU2nAGAO708e57+RYBI2qyinXL8kcMmIWsZ5BH1/OzHxCaEL7Zj047zd GSPR8RPfaHyoMUjCFHd8seP+6WszxVJX/3bhH74IG6y9HCL+HrfotN733Qo/b/YEOmoUfSA4eZv8 OGN18tol2LvSWF5XsTkkb467+XYr4z1MDqrqAbq1Xzzfw4Lt8Koj0S330Y84+eknTTILFVbTYeXt ZpeUPgkw5ugyUoxJfFfXKS8nGDvwTRfQTwplJ4Qy3lNCjqrrSMxzYxTXqmkjHsGdyGPPnZFLZLoQ YUO5nehmgh2uncbBu4IH3HtAltxtVeeqT5GyQSiRqa/7nO5BsMDi1HUCncE+RTczxHju7rIxkXvY jnB+z+9jw4NY6Cvg3j3fxf3p/D2cgDsgeOiBndcJ/E7k0tCQiY9+l3CwLR56xaBt9taWTz7EJzuB RFQt/7O76ifNwkcqoEaI6v+WIs9GcFvICq7j+m3FTvF0njSj2vt7p4OwMIdSvk6Bb/RZedftoZhB NOtew32Os5+rFjaJ1aEE+J4LG+ZOUIX1DOCcO0HNTx928/Y7cdEwQMTpXK67wDMz/9zM/GfvoXoD Q+lTleLxv3xm/r2aFET2uepKKG0eIW+KiXVvSN1dqJlm5sxe4+Sjt88XPo/XXCnrHEgOdmKCzxkT 6VneUUKxBuPm1kQdqcCq8969siF1VjF0y+2aLnlsI/trwLsG+1QaMCO7UwMGvXnoXWn3gMPowqSz T/8Zmmg88XZj1kevs3ggEWPW2BbrO4T1Q95/zR33sOO3QgMQL89Q+t7VWxvNWqLmdXPL+jBSdZyJ Bn2DzzHzztUdRCFcv7HXJXko39x1nnE0DILrPYYGlp8PcbGRbutDdnob2bTh29ZbpIRAxXO+/e+r 89FRA5K7OqeNMM91ea+3UPYnyUrniahTNC40JfORwLUHkOxBDJaMm97azFQPYiDdYaiAgx9h8rGG q7NbnLmTCK93QwOUlF4b2IAI6/8xsVJh6DyMm2Zlbaq50/m+tUicnvdj3HrVbBtJTC2ewLZ73+WJ h3+Z0Vw6nH4bPgz9UtmnX5h/zzfGMwea8OLVy1QozcjyJ4t0zT/f5Z9aECaQWk+42X21ZGrHpCJs SThySRa8HUDLQTg/T8dvldTGCdMEWeOpcsgQGYSugxCbJizeZkVrzwInt4vK1xGSxeOPY3IsK9/A /Bxw9J7m1Fyue0tyLH0cAq6QOyrQ2NmeJ+ZS6qwzvLJdRzXf4SNNR7niarHof9+0k4jmRm6tQm3I bU+HvhNz7ZZzg3XtMp9FYQqYje5mT5OkmVNU511EqMpffwiW3EKVv32LP1zRMmrwecIiwUmXFXQQ q57VzwEs8ArJeESOJRls7ufDBYZLZ4Gr/1RTrhoyaVrYtb+MBTENHs2RHpE70BVjyWDgYLCpluNJ uk6/D6j9JMgBHUhe/wAbEk9BXwXwfEDPBTqYPB8GqH1eB/4oKIUumQnKzUeEoT7b2qn9CwC2hCBu tvCabujq7voFop3LdbIK6TnOw8tfTrif2bVTSyRZNQnsI10uRDOH0zA7KRlA1QSXOQqoib3tUnlL FduxT6u50wfZfn+rWWC7MWr0JiuzWCbf5nS3/nK5mRPcewWMRmCzKdrn3bmjYzOG8/dkkxYUcroI tbOuevx1vrKblNF8xaM/n1V8Ak8l8YTgwgxZDQKIqvGujs0buFf9Q4JPh7PXObYGk9LZmONncwBU v9KkXyAv+Q29SQ0q4So5z84HZTswwFIixLOGpY7RQGACSKiJ2HAh8ZyfmpJjri7mJYi2qKA6nRBH q8CPrF9yEHW7lAzUWDlIoYijYzfYGRqRHiDm7/Uk9ihD+DSHJw9v2snJe6Nz8G2N8YonOqpXxxAw DU5wsDBF19IQClaq4dCcPUM6H/i4JdId9h3uyB5A4Tis4617gdR7D1/SrB2lfJPcAwlBDiL0s/bS Hlj5Afvm6LV2HZrD7zVEZ1d9k3dZOk/kMLEDozGCc0IHbR7MS+rh+UlPf5yOY/NL5WFwcin/DUwD cJ3M7XTSaYAvuU9g7hIAiKKFqZtJor9XEd+J9D7JsaMHCfmfbUA7Y96/aJB2wPrp+3V99gCuX3E+ Y2IcMN3359UPstjpyw0pHYbJqGG53hy4YVRW2MP7gzbVseq6sthpBN91KOfdZBrNjfZpCbT6JbeA 0Eikz3lXcUX2QyL6ap8uh95hUdJUfSgkmIbqQc/04Et3NCwmdwxKQHLiS9CaMTHCKFYEcN117frT 4maKRyaUol0ZS/ZnQqn9xPHOFso8dyKJVLdAsbmWHlSjOz+EEIdwq0jwz0qzt8BraID4KA7KfKEd 7Ry9Uh7nwm4H6gL4TfYHNV1yll8wPyG3tPecIzXky/W+uQ3DcC4RiInRplB8Dzc02fh155FRgB4+ yec9dg3uzjMFmIJY4176xsK1Eg1ft7Y2pJjjO80HTpgmFJrtiJ6Mlj5xcHMmI9SujJ8P8I4p5lGJ qOL7+5tbyP1MJhybizr2shof9MGvCN/Idi6fDwHnHzOuuuF8o72/y/F4uIQEFHpw3pUy6G/2NgeL vxwNc1/4WHfD3QisSkHC6i2B4ZXt852kZuAa0coejI3dzKyZ5/hUPoxn0gHeh+Lhwpa4hvdzt+u8 oZovyDpNWDPq5FlmiVhU1nOc5jkhGmn2cvfzQuzGR9YK4lSRdPk90JeutNSPMk/lQnwHVsIx+PKj mIr05fnkCNpN/OjXj31ASdkvBkT3+Y/I9qoHFVoB6v9IQDz/D4//S3xL9nlDwy0LM/X8a2fm39CJ KVNpvjqd3klmuAcH/zpWL5fWC2Pb766d4w/RNCI2+w5KbqMksnaIPMPMTGRV9WWIacweF7DJ2SM3 KkzmUlN3nREzBUGq+aTffNLF4ipw/F1XV99c7tKJ+b4c7VdPso1v+Flsk5IS/pkRDGaBhAaNheHZ VX2Nt7Zja1MG9/zFKkzgy+uTOPFh4eCNdGkhLv7gGF6ZWQPBXrhanvMupmzjAnQyqpiRXkucoOXZ z7w1kWme+eKnT4Kqjcjxj9mNgUv7NvsTZGgzBuilV2xoi3dmmmJusbVDWP59dvisOS9kuc3ffjBd EDUvgz51z5IWTtKJdfizFvcSnydP+d7dlAi1jSJaUZnu8bnFOptBMajyOIFDosA2Pv1J8NoGrHOq zVpoTecNaHydp2lw7OSh9FH76kQok9eL80FfrOo7IHTrDLvyHBTqU5qCozbBhA/E8Lfo3WHc7BoQ +kgwnJ2Eu9POqC/S53u5xiEydZJNRVoz8Rob+G/IdQya2WWU/t6v/9SQX07oEEmmNbl8gzIxdVFg dQskelIlC5fBOTZ04Izppdd1kaOlX9crmjzz6QxkdGTwkLC0i7CnwZodqyC8AGdowl7LMSSEJxUF dIm9LveKjH/syUV9HGzsmC6M5BSJql/BpH1s/kEA+P2/Fd/7EgnO+Z7f973FahVvVM4kxgZvA/Aw FwuXSTs9PP/cHd9xOURv19IeBHijKxn4bzDGntXE/QCQDFynZO3vJ/XXrHHvYY9PgErPpNUl1Bh0 l5gQcCoKe3KC8Hl4G8UODELmOSskFBrEVIGN+7r9swcWuehjcEDzCbkz7TrHM/FBOvKFXNJI+5xe znNb9Wzb07nTO4zuETexzsCtTjrFBUzOkCf9NzXYjqv6oiSPeFl2Zv45i4JgM7nENtXumeWuyq6X 1Dg9sW1iMmGL4b3IVKej/HQ6CfsgqoA1dLTEWcupNa5z4nk/gao/nA3lCyi0o4qKdM6GT9Xw6/SK J4cqfwgYsrnYIEgCaAbnskGyuYWnuxbrQv7nfNx7mYRpaxoWHVqF4NigYDCdMnriuEkNInojeeQh X+7xue52CWQaOClzyp7WPLupKdbQdmr1P0AYv2BvxQ6LG+rrP7muDSBGgt1/7wQR7aezEfwL4mZ8 vQbJBHK41Qepc9WaG+RkkchLeQru4B2hrgKgbSICErDXIXHVITb5TejcAtN9phngFXJ728JUcnV+ BzZ13pX+rAa9anQdwg2ukvZwUd9r7R5pcHDQEZtM9UULSK6ou4ssTKHE+xm0+q/0Gvh6zvxu63x8 +rTbc4kc92jA4msd+teIzJ0MkYSc60Sc6mvbKftyQ/AZ2b77h9XjoztTDti4ImINfVUmeJ3CGgDY kKoSVUd+7usWZqjEElpERjtv7Lvs5wzpQa/tEp5Yw51I8oL6Sico38DhBnMTU/Jxo+m8dWnY43UR S9yMLQouIdf+Y+MdNUt0qPU+N9aV2IjPTjGd2ea4g8lxeOKs6WqpU65UeFlGgXMPGvs7U9dMRNj9 H05So5ja7HfSR8eAiUxlugzkNbxn0sBneX/G5YiUw4mnU4v5vKIh6+187KpD9NFxN07UopqfZM5B zC+xlvfH7rW9xxF35Pg+N1horMP3XUEMwsBWnAUBrYcA/76Fv86EmewpLiKXcYcNGTowTtedzbG+ NI7q7gk9KBWovruE2XNigdU5mKQYOnsllwi/e+BtJkJDt3fF/S0S273BaIBGTnfWTrDgwekfJ+RZ YuJZfe+dysXomI+BKfa91YFHk/DYi19pvmZODHkZBwHXZcTNWWTyI8TddzgnzhH2KuyvX7xpYwY/ RKBO5Hn3FlcPWpj0EqAM3r10ynA6Q7vXmYTk7qwMI5LH/2sQDae0LM+V47v6QCWaTMmv1G19jXXt mn0L7m7TAH3UlZd8w7i3W3jS2V+N73252mdakY7URx8I+P25Z+bkXGc6jYKSgjkz1ZUi90u9/txx mdiweDDghKm7ugTNNLxHSVTtDnjz5Spx42/JeU+iEoqMuC4mQy0ygWBX+Dm7/xT1dC0wH8ZYA+m3 KpGID1YrMaoWpz2cl2m0Kthn7+9MuompfSvgxNpEZubIVJHOvVOu8dHj6Rz2AndJTfVec/bb74DL ABdCuJaHBh8Tj2Xzr9eMwI87tmbOwaQHL1F0Vv5UsJzcrTHLIOuRefqY+Rk4BNlyul0SThY83T83 o/+WRv/H4uedz+yrx/i7+v7F0vy7Z+aftkmTz71A9VjyvoZToVPpiPniBBtGtA3pjtR1u7gHH7j/ q4vgO1qYY6UPbrdrZsAOjj15Yldq/s/we3y8r6mzWR8ZyHe1MoW5DDwdqrl0CJS/kpM2VqhwEb7N ZKDvE9dkfFqSFZla2SXgSDWBY/banemhNyO+lQnFmawca/bBUX4wwDT1uJyeMXcYFBqN4+0k64f/ 89Vf3ooIn0kOX4gl8QDTpovImWtoIIDSSr5q6qVHNPX+Oqtrie+eKbf2NHNz4+UiXNqR7KjgP3Rw jcFa+cxnbezSnSysD01U83hbM1J8mrNuN55DryGOP2p4gz7j0pBtfFyH4ZeW5m+CL81x3csQ5S83 HpjO31Q9twaBjVC4psuh0JmpHuYvlhG6SQVmwkalX7//WytKw9eDyE+mcMBwkgaH63WaivTK4ISg KTbHbr7IEetACjhHqqpInymuJweyb8skwhP15fSasWd+NWnrAEwa9mDN1k9N/U9boHEtgC4ccuL0 Bmh3bNOEY0na0hNgnQ26gAxYhbdngxzi+KaXtKQmxXS4I93mg6y4ReHkFl4YQWywdkyfOtQ6fpad NxVOGAQgq8jEgcMnyZjL7Z9oiBQLbGCT4qIELYCOmHUtJ51N7jm+WzfNHFXarvI/k+Dr6tGXk9Uu grKI332yMVrDtZlbPJMudoYivy+U3LcpfpzlWozzd1EoHzqbcmXYs+aKg9bhsGpwrJuZO0ItYvLS 8S2HI6Kd9Yc3tbth/XOu0fSSp+NVuvT/cSNUkSNdVPz8vvxZ9DS0iBevy5nEAjpjYWhqVLP3Lo24 9JV9FRtbDHn55Cgn5fw2Xky19fwrOMFCoaxjkEcHCHr5YvsR0PTnuoikBhnbSU8lquDmLkUTDiAm AVHVd11loanIFNB424Fx1SDS9CARXyd/iTzt2ObX5eh1pWPPme+G11j86giFnBmk4fwXRD29+iUk qTOScereVrzyK4q+QY0OiiMPnI7P0sc3H6DimuBhF22HUDnn/V2TuOzgTXUptf5fDSlFd+skTbMh CtDNFHE6MUQ1UQ+0mEsHYSsE0dMdeeZ2tKB0lwtU3XfORE1q3Dk7GeRvbC2ArtuJ3B+N63Y3zt8/ IAhdol2ksfcd6wNwTtDzBaZU8VuC96ijJvYWoT+F0U65UDSp059n5oha3i4I0qCopVyPjG3nJ0B9 TZLff6wALQEsPGsPHtDYSQecGmUAq+vUFz0fYeKL4J6sM/Yd9DYRwJuk3cNTO+LOJ5k2NXjlSFpi 6pbE/44z95KQ9H2x4uWPG5aHBsgJ6HFGqr+q8+ZmAHvOszOFQ4Oeoj6AMUc8YtPl7wCx6kb4IlNu fwZH/TgHsdKCe0GPl+4KdE8KIfYrye2nfMkYex3DGgNCG3bMf7GRFj4EaeXfqZCqlAW1jubEvfT3 3L7Ei/pYV0Sye0iQ/LfWFQ2nTAlwL6KLxg33flURxT89eqdwcT02h38kuNAcAmjem206kBW6ENdx OXZ3tpiO2m8LCeaor7bIYt9bgnqkiBYnBjRAZuxhN53CiRkaxMR6ZsKZFAaHdupTDv00jkM1nWtl 0L28Rbkkyf+qR1ZnZYfIWIdYwNVDq1CG+++/54Y0H4KBY4DPA73N7cxPmN8miLIuaXObTonc5hXc XzjG3EhgSIP9OoaOXImP34kkOgcxh4hWzS/1qzD+uQVhnh4+ZqONFIrtrlb1/X0IKH7/T9bWwlSP n+TYXTPvk/IyEvoKAfev5HILTLYYMGtlHXXMAKdy30Gq33E5gNX+lj4d8SnEOrH/Rl0ygeTHvXbV KzMg+p6zli22RddZc/X4X2ssUzE77XTdgW6HtkuKJ6ilNw74wlyEGbyc0YTwrOunPoXYRZ4Ql5c7 IrRr3+c6htR99hw/uMbua43dSmJmPGjZAhFKnJ0jcWbzrCSMmmMl3mwyYfZzvI8JLnZQdLbFVkJe jM6VxvVVCW977d4DQeyCeHniqXhTn0kPw3cy1lQqM45Ewd6B3zQAGRjeJp5D6PvevQmnbKv4/MMH vG4Xr17fH3J4Fk7k6UCY3g/XsYczXi6QzmRKsc1hiIUvxl20+4gX0iDzOcKfXLgLn7ZGLsaAoQje n9Ya28/5cpH9+7vrTKI178EECMWprdYXeDgl0Qc6WVVFDMMVR/I6kR7aGalVFG8iOd01a4lgnSRO mlwUWfaRKp3DP5Bd+5/GE1bf5wH7Hs+/ckb/kR6q0lk3v+kYf0V6ymQIhahv5hW/XhzTPnO91qTq XWTawtTPoXtfH33hb+LVQfwjE8tpaP3C0uaoF1P/4Egjopp+O+Yjw+vbIVqQn3vXoGlUFPiXG+XK myL3vbBHcXA1b822scI3/c7wzDbXLuDWKEHsShh1qUX4jMxEJUAOHSYpM6B7YG1aaws29/e3Tq8z 6UqYCO3RmRdOWAeLIKcMLI0s7hDm+AyyrTvU3DFdPXd1ZnbUiSrzAcKqabzQMHS2TflIs5drqpOJ boPXUDbaTy/WyPg2LP7H+kjhMHqc6JrjLBbgr8F/aNBEpHud7jcTsU7sXyA29ycD11j4Nouaw7wz FCYinaVqz03UKprf8K7vT9scwwwNx988mufO4nPdYl98zFW3cf80rSE6zhR798tpRizIESGe9R// vC7LDNcOffgWD+Bdrv3/JsiqDKxenJdVI4aBL9KU3fY2aVyowPVeLnhryjoVlo1i1V3Xwb79GFtp Zv5JGoThyDPnO/7zFsqkK0aSJQIRhg+4pC5p7fLyJVN50p+INI7pvi/eGQpaOjeyG9QRPNHeCKrJ 8P47uXi72b1m0dulOpa9+WKo50JRiBD5Y/RjeI46TzSLHF0mzdEsxlr07SOWBBLH87JwwLhmvoof injLKNMN47JTUAv0k7TysTp9DVz4Ky7RFYekieSAs5DJGN4uwP4SqSKfkDkiDDcQtckbulpiYt6z Jg6N97OKUE4Xqalis4Wrf8UOAL3pKHD0a0QKO6n+Fa+IiCaKkuwGacf1XftmwAWnT5Yb9mbPuc9G wnmu6Pi87LLKQq9L4LwLCIpqmo8SwQsIvabdFWRUfk+vSUwfzTAJN24QkaEuj49mgokGFgZsMmpi avULtHclI/BEJYKtmgIVcgp8A5dHYeSTKjwcYvnkE3hnUszidhcl7xU4CST8PQM7POseoSt5nzEK kQtHuBp9K+ieIJBDGKF8OVS1gy47nvgYHJpp0bFmiwszIcanAKKbp/7+de/6z5AD0aI5bLnPYR0N xpdvl093ag4O1kk0OiLFODLsR6zZoPd6g8rBnCae7sEaquV/6n97r5F2UHz+vlN04WosG4gjEBUA tzWIdIGxTPQo+o90Sx3dblJ9ltNaFIJm32kfwnP0BjL0SXMv4uCt4d2DShzxecfIJujkSlm4XXBz TS7X5nCB2W7YEcfsPCOjGXfuB/6MdL7kOazlrLWfj4PCWO/6ddbSRa2AD7AvMILcO/gc2QNpMy0I 43uj91gP8rwpMj7OvSYAu35lsIcRko7iJFHePAO6+/3vPkYHwUCRtEQbXUTfW3NMETgU/5pVARId UE1sYkrlUaEDc3AI17bbcgOlSRo4BDCLKFVI991OhD4SyvIz/hVvRTqVo+dZg8/6R/KW6H5jbIPi T/Oc0hoY2kOWdIoyeUPOQ10LXsPfE2cF7cm+hb7BYnKt7Lu0Hbp/cLi7Ix0NklJdSzpEG1fILaTD 2b96uVUapq7MF4PspcUXQmh4kzYqN9kU8RuGqQm3/KJN9JB7jluAY+EVfac0eDv4uMUMd/zPPaHz DPpNNm9IDXqTzHQ5nMIoigHD2rjAV+qdjkQKgR/O1z2XpOnGlYdSDCYTEaYEHtLt0DdFDHP/bWAi DGKpFb/8CwaSRFN2IWPCdI0EJA99A2YW4sIk+u3v/SPse9/7fHMq6Xq1kmZEOEKniybG7JmP+j4G yDwntsZvRzU4o2NNXH3Yt7HE/h3XYOMAef2Ke8gsKe/9HmDgSnStbLHLvyB1gzsuGh/h4VIdvR7H kAfy5/702W//xTyeXi4dJsmf09DH0fm+0yG0zl/GOlrM7Dh/hJX3V5WkIY/kEnoGV2U0K2pZzO4N DGzslQPSGArfr41jtaAznSChljXv8nRy1YkF3wmhdM7awzWhWBimmV+GoCituBMTevROnw7pa605 swb3HbR5KUB1nOe1gqrSDLjAEtbzJqa+otKu2y/8sQVrLSKaAzNUcVoluEemeC8XFltuMc6qke3p 8UuVIRP3Xy2ApYE5Q8/WGTxxx+orVSPTKgffU4/NXanZhmSGjQns4c+oju2PO9x4VlJNk5jHV7WT br26apbZgzB5VuWA7EY+Bli5AQz4J23YwdEbkMTFr9fruweS3s9+jHmUGYi+0kiRce7a5J89of/F zPwP6FmQULwHyav++FfPzH+sWSqq3TLJy5WkohJbNl9ZiIAbG3/5lTXsXuconWuNirn4sa+ehs5B Gi3qxKUhZ23sNAUMJiRXB+aYJpk5xPhn3V1GEXvfpUP083nN3GCduRrELrZxaQ7ua7YZ4knwxqDR M3z6Clsf/CXTYYSanEgop5Q+9w7bAv7oTU9++kZMWHtziZIFmNHFO27O3sGlDtb1xrRX0gNSCvON Bf7gDD6TeTVCdQ2bzPQzm49c84l95OqvqUdNHOAdPN9DDiqMhAwu7+564Ea6RxhXIoUdvF9zIi+f dOsmfPAGfBZoDesreFXaAd/Jd90JbK0Dp3Dl4IpXTSvMC7pSd/ZZ0zgEfdreH0Jd3n3HrDr/c/XO iSb4TJwxDr7xkBnVq7fCZmponboMMkjpEbC2YZpps8XXEJuWrIcNXPe55jIGn6MP671wGTqo7lWB as6fK7/7lDkxMGE6V6ac3soYHesna4A/wzO0vnWkbbowIq20Azqx3/r8n+qSNvlxtTt0kp09vwoL KaCC/Pdf4riJd62itbaq+3Caz5IQxKzzOzhLRdUcR4leV5BzHnaLaYWRIX1J1PWSzb/zbQmbt8uV ZREf/hKkCh3HBfFH6aCfpXfGm12F3F2ouUhCAajYQEYTiLPI0b0DFomMhaPvGOeIHp9XRGKKAhOQ qDMsJHKJ+brojotGc1yi0Or+IVDcDmoz1+UgdLVTRKC2m9Q/4mDUITLs0vDEpYlbQg01PV0EFYiB ALQBoOy/p9XImGiFv2fiu473cIIOb4IuhIVxOT/n7s96NDo9tx/ZLkp4nbaLVBKYHNrz7CVtouq9 QNtxVofQEFQn5udWDpLOM5Zo+OeEewfwZ7BQeEnkdFPPudU3NqjAt4ifmQDfdYpovnZTw5cEEOC9 GKD8X5DfHel5rxqK6E3/bR9xdDs+ynBvK5xFMDbdno6OnE/Cy8dktY/n71/Agbtx8vC4y3w0LINN PotgGIwb9G9RDfJNufc1yPgjOpm/m8W/xEut1gbJzhSAULxrux9RUsQxBhnDhAJQvj2G3qazHUFI 7Ezgn7HB9y8wPbdYF9jlIeGZF+CXTreDgoGWNjruPdef8hlFAqtdZ+1zuc98AxhLUOMMBIjZtYt8 CrxyaEEBvGbzKHQf+hEn8s8nz20VEaoht5E8MzXXQCn6GX2AIxmHZoDb+F0m6GOKmDe59LULZK28 qN+F3e3XCd/k5BU/nQRyAiMj+j2a0/3AX+/BazT2TGbzoK+BCJ529wB6ahqqL2oICpOxrohiqg0G APIGiRmAnfmO++U0IWMwIcvu6eekG4mXCHu7Id3R1BskyxjKN72FOrS37tKBMySBM+VZkR1qrtZr FIL31etewjBuDgao6odN9LgcRbRcIwjkjzNSLWgR1jpP3+cYPvc1iv2C2DppBQHRz1Lvy6LA2Pu2 E8/zqXQNM9HQ153DNCfU2cS6KH7YU0ln2/XDOHDdUDIIyQE5XH9DdP6QWzdJDXpAkl2kdiJCClAr YhoEKZypxJLlcq4XicF0CgOacB7AcYWpnV+JcbMGsTYmUnSxL59UInpVTvg6nDtfV5s/y+unVzES gporGXCfQeni2kMgwsFcxlpbcOFjn3MCJa3AD0LUNHDKRhfbHasd4JP8/7tXPSEA1kG2ae0jX+9w evjixceY7MnnYRTJT7mkVbdZlYuReFf17n+ETumcvnuLSxDTn5/o+1m9dJPlxygxDHgNdgFdW7P7 7hpkEWP2+pRr+BBoCyVp2fHf+Ix/wbpUA5w8rHTRb51aQOOGFG9vMKrRie2/b17n93zPuG0k1XWt H0HRi//yiaXl1MVU9hypTNELLU6vZB3l2NqmD6pe6LfBqexsct2mkNAleEhpg89TQbguKQV5ZlYN Qgk/Okl67rE5QbA4ERt6iR4q42pf9femOLHrjroxrY3rsbkCDeEq+JLEApp7Yg6Qk34pVYqSAQh1 9mPGNsgv/RXT+x2e2ZxFYshXQmMbqLn4vn3P+ewLbi7c59/XeX5d96bOkwL770e8s1wx7fME7UHz F38zYvjkeU5jRUazoesdPLxvDIhss588LzeHeadp+FeUjjj+rkMguUG9/rPHq67gGAYwmQYgGjP8 u92YYrtPeg1609WtEy8R4HBTCQXrb5s6l/d/CAzOnkRerGJ1Dq5IPKTSSbTplh7c78+/98/NzH95 xv+vTx7eydka68V/tir+9TPzb9YHHvh7EtO3sR4JyhR4T+FpmjBBHOC4Vb3FlUNOGZwtJvu539Ix nARiDo3IHNzxVO9p5K0GapUedOj30anqiuAofcpmU9PgBwdxcZG9/gst9QBGAj/jScJO0aRDkGxA PfNmF6KiQlbUD+7TSiuHHkyTAzqFoOegq5PV9VHb6kOV0Qk+iRvZ736nelKfg4S8HhnH2UMG+sAz vowRmSO8Urt9flJahzrPikwIyrXN55oKL+bO+ErE88GdzZOmRWL3q74KQxoRDspmsQb+1MGXDvbT CgOvB49RY/4DztDJSlCOR/EUbqzu1rCkzpLzS0j3mintxlX38Ln+Frc3QvaRVKNZ2gwfZ4QBD25m ovnG98zoc7IH4W5mKleoEUvJc03HfnnNeP9+et/DBHgeaA5bwJnfneUVRi5sOtnIKxup7i7iUmQ9 WGNpRlTGCXfKMOkmjqSHjwqODWwd79af53kOkb/4fNlG66oMfz7JPyWR0JMmCt+S51eBa0e7aNPk Il3DntddHoL4ECzWAuuaRMxJmjsOuqmlSwKd4sME+PfWpXj7K47TIQQjMpnb+QSIN3h3AX4gG3SD wOywmPNQPksIipQQUuoMXl2bfwsiBrdbO3mkUPX5e+7fn0SWS2hxFXJXCdFF2F8CFCZ3fhN6dTFR PvldNOXBbANkx3EiLBa4SJprQnJPd6mAHmHw6+fzVRMUOhs2clgQhVECyakCXUlo+fcANj2bt+El 8d2sSMn6NtohmgJw3y+aE/BVQY3qOPc3kk0lXIszVdmA+ygQv2Msu1iiIsMoDVkOqfCzqbEnlzIC 4Dvt4WfY4PJIpJDzBvC4QSGK500Ie+cIWfRqOEeEHuA64OsdqRPC+0Mfh3eWOKHCQN614EPokp7f wMd313TKyRbKaWjA4gUXVI7gX/VEFqyanmIPICbi8/qu/yDtP4lpneDpBUh9ke56wNJyHpfW0M/6 po7yV90++CRkuY7UA1ZeteTg8zQCjzcMk++CwcIEoNcYktQEuI0O6qsB9R0J6iA+fIgx6O93da2P 6fA+D3I48SUWef0ZGs2Pc9p0X/lMGOnV9DWAd/+nq6ztjrgB5R+wJEGlt05acI8GxQwJKC3pv3TQ 2hf05up3truMD7LqipHMfuhyUMwKy+V50qKVi0yN2t5EvD8/RzGe5Rg90/zaSCukJi4CTk9K2AWG PntSM4MS5oRgMgo9ahVlPa6bdD+GPVI8x+tGf++8n8FKfk/swPCcZmoAzQB6cX21q407VWGDV/oA 7weI4PaD6khGT4acdweDbkUh6iXfUINreLmaH2KFXU8SEd11r9HZSAhy3r22DzfFd90rSFRXLZXn iZAA2H16C0CzdtchgJlwXb0HcLyS8brfWsIUUU/kGEzxh0cHAZBJPt/kiw8BSbrzXcKLiSSIHJD3 Ad2rarHLRfIiVX6GCnOtrPNdX16+ly9fu87ks2fHsxScUsVFSRIX9hEOUqKalhwV53sNIqHOcsMU TjSA3q5jA2TRRY/d/pIu+rJ+n9Se4sqbOKRc6oShAQI50eO8u7cTp9CGw9g78Wj1QDKgJ88AwSlu GBm6BMmHcFtTxNcWsoS8RArcgYcX+h4WjvTvlNYvyclPosQeHhfWIYN4vY4cgR5S1hJJRxXqWeYi TLb57B92KiTJwR7R7SOOIrHKHn6eGCj4jTQK3MKDuG4RxbOHHAiDp5qmUxwoYVbTxjpE7V7DcWGh pKi1EEPbMjtOI/sNl++R7Mv8xpgU54Nr+C2tMtH2mzgddJrvXteBK3735Qri/03b2munHSk9nbag nSaDwgNweLuSa228gb78yxrTd+E0nApmFNwI3exo+OsbJRLhFCZJQdc2gnFNQvU495Lx7HZB5/d7 81v+wPiJ9/J0MvJwf4gkOGCBvkl0HQKIL/fmfubZZ/QYxeVc3jZwXU/QM37Tc4TvLUUj+wwpUzrP xzk+n/cc4TvrrXqOSptS+7pOGarzYh/7I5FWT8+36+wWG711yJUKcOdaGweF2jSqBbX37tmO9j7S kan6biOBwY6XLAkvjvZHd/+sKhMfmUM6O8XuHG8wMfuUiKEjnXbrI/7ia56PNOPAVt18Wg82MGYk /YYaf5x93veHgdthrmen9OXe6p4y7hJ3vbmPzXri/8IZ/ac6DY3u63uo+Pnzf4Fn/u0z/icPCequ PG/S7LSxnFomGLWNwZqu14Yq1XxzygIuhsdeYqi6RjeeYXclv2Csod7aJROgm5Oew62/64we5DQk 4u5/d5uyXZV+Gq9N6Wo6V0CHhRllhxI2ZLJOWaYZlfTjr+zZa2isdTBzmGdq4W/JNWr1qTRQM57i xxd/INU536uSDAkunMvPMbk52dGEGVVjMSpZrItfASYZ9n8mGPUYtCFZbRutJYba9c4eovbRZRhG eGK4y4345N4z4LNdTTLS+dX1lD7Kj+Gj3uTSOZ4z7wBVsteFQP+cScloJXK0ee82bv09a1wf93An GSfyU0Ml+rKzcPH1gr7xdb4XdhzCmtvuKvDFOUW1NmALiPsOJOxoAJO467juITWsh0uTQB99Jw0F iHu3hatuc7Y220ytIKd+jifwY6qxw3wXksX0y4ANatKo6/bNdWdCUHJIO6m38eofSkwwpK9l2HoN OMwzAHx187WzTHWHD/Ue9ynvnci5VD91xDZLZT1O/uk/tZAvJwAvl7ZZsWkJnrwOTVR4JTHHdM4W FbYzLjmxtbaUybjpAsFzkOQ5y6KultYzeQhb+zyasFEWiewFfpM8adGOgxp2sdqFqZZIQ1DoCSY4 2RFuDq+D97LjQGvVFChN9imKFY148DgcLjYp5XbMVDteOSKcvkN6hAC1PguLKdCjp83aVbSPHhbv EMmaJP8rEr8ictJdqx3YqWRkd5J2G5ooBFykwyVkzHff5IPPomCWEGMO4k+HNC9dII65Jg0eyn8a Xh8FKA3GvI5jHpIe5im695SO9fY2mUVSQtlGTrNe9x19BxYQXC3r2xgKQsFu4o9CNV0rUQc0TdO/ f6bCt7BojrXi4fSMOaPS52niTaIqb7F6Rm/+OMhejn2OojGdwTvaModR3mjVPHX0WYQTsMzhyK5I U24dCLRpAZ+BurzTQDTzmc7hR7SbDoPbkVZHPGdK6gRg+uWe0+vdBzCjXyQS+2fcYiCj87SWG8Oa uhavuk3y90mk87MRnPU4RXpwktPuRtGHQ+/MHNP0A8/JZ2uTz0qfpIW2k32kf/gBlLeYM+ADt5/3 23SvBmjalWxOMQLJqIl8HGwsaVL8JQtZaGAA0okOufbDz5MnUZc+XNhnZjVXg0QynHkZd6asO/ay djVsvd99EFhCN4PL766Jkp+egAjSmRQv7Y/RsD0lT+x/FwgQ70EBH+6MGQMrbcDHUSMqah1yB3Ws y/W/fe3tn97t/e8vt70/QOPljTkXHe45iOavqDoVkDH5ebyH4RJopp/8A7Y5zhki4r5db6+gPlp/ kaN1gs4+zh2qEW5B6odrprJ/2j3cRep3XP1FCm5H13oL3t/mx6GCnsIcbuaeKeKq3Y9bZN87WAXE 3QMLX+KJGwBNMNpwM/nsuPmnp4uPi7gX+r3z0MV1XpW0Lwi1TRgIiB994FFUZ+wnqJUasFP0buJe CGYn2bqeofMNedUb+iXVzZ7lHtrk/G3GoA+y6kIMZ+a8wd9hKOO6pvOEY5UngPm+H414UBLueSa2 SQW5heZAbZ9sf01HdBHeKrKja810DGMiRIfUJe+mFg0MJoIICb5B3OxAqurMJCSKsklpIHYQoXZT zY6fnOQ2rtMrBVIgpMh74o0q1kG89xPoNd0JQH//LYObFwq4HwMAbYxQ2ti2MbWNnZxSbrOjwrNO eAmfN5nTG5sX9zdKV3p3v/oOayvwtvddcCx2//5bhEsi244bboKs1/BODeS/76glNnJOaS4Cl+ZG d0goePJ9C+OaX3oWI7KW5DcKAw5cRIsbcKFDgiEAf0hvhCmTA+KJxqVdAnutdT1QLxvTXal/zp67 xYmue9hR58zML4m2Ok/aiWQ37yFlMc5yiY/S+OUdEr8EQL1ujZiR14DvNfyV+dP6QLeERknfHSMb VzT/SenFjIH1DrqGZptzNOLojUVS2myKPXhcQIfZ0qzPiDyCQUQhgQ0QDLRXWjetli3aa8McgRFN rGPpTFS5zrjEWshVWXGXCp8ROT5rboORHv/fOAFVdCo+bzvwhdTCrt3OQsi7lkUzITKr0pvKNAej yiOHl6CiJZmArT+JQj+u7lE1ew5s7wfzTvbmFmv77DtIFZFcFJ8vA8YLg2fLayrkekcOjv9yQw1Z pdgQT+eJkjgi4TUbR/FhljOw3/yRirUN2Ppz+qwc/MlOEifdLtDBf2oK/Xvew//XM//tmflfDe42 SlwZ3HcPV/avmJn/APV4F2ZYbrQnjk2ncdxXHrDl6fko45D4YK2uM1no5buIL7gNO940chqF7vS4 iy+/XHrb0G/mwhc6ffF9LkaHcsJVLwyfuVgND+vpU0IqYHC5CilHcqXLbw6ezYkZ7CTZr7tVa41t aZkX9/i379LLsQ5gAD7vnzm4967RZi6jKSGKLuDVWXyeoxpz7PnuhfouYP/qO1Ur3xf3jK95pGro 7pvdgFtGgX3B8OraL9q81RyqOSNmMJFC0+f9m5aQ+IJ91XhgK3wYD1WPLjZpI9beTh5YsZdU+r45 1/lhPDQ02kc6p+xEqXZlrcTuB3WYWsXA1cvV695/g1q4fQdyOu5MJ46qsTG7nldlsKDu5AdDYw6U tXaGHlTn827+TzMnx9DDCrtCbZ3WoA5CwOnkrk9D6+ZQWAuZ3MqPcbJPk5uXq+I15aUTq7tUM3eS yASONGDlJXxuV+Whs3IlNFsfuhMy/d11VzrBb/240QTgz530T79NP+14CW5DOkotAWsKTo8IQlPx +hQEnqL5jHIYVwTiPZmQkz5zHHDsZiyQO+1i2IdDyhVqqSHHzRe07ALD4QDVzVzSVIJoGI8/5rce gbqTaDA6UZwwtnQSPVw2U0yOwyHTS2D7gtsJVCcxvUWM5mIVhyuu+J53OOOneaALIhMC8Mm74399 kApd8LcD1YzLheUHhNkHnA2Os9qNM1Eg2+U134kLQFkUa11gDHYaY26mzoKJCJOcGNdJNu4/K/J/ 0pkedyZcwIMlfA8QGKZEBfKHL4B7737DKqFYroOC/nH71KYWUmx8O0RnpLWLmF7rW9SYsZi7IVsP uelwxL07QvhpWv6Sut4FaEbwssOy8ZzkqT8/zhPv7yeQ0RV7SW4fr9ObI3adzl4C75YjHMZHGRoQ VarAHcQ+5S1sU+HvACNJRBJxP2bIkIiECQHRHLDOS1L9mZxusdkEoTjY5FEM7wZdwt003G7fJjsb mXx2VFN49pmYkct6yIEWVzPQ++W0K/C8yjsgi1baV6UMnJ2K0kT77QROTW7HDx7Oah/OwttRiZy5 nr0gWmcCUurnTBA487AgQIfTZh7TOolb8iqbE+71MXg4w0MO6LV/NIzCKiCTPYwjZOyAukU5l8MH 7UkifLXIXHLafkkIH7VurW7R2fLseWf9JOgHPAP5RO+5tgSEykExV7OaQy/sKtlx8++go8+VcTmA 6+wYyPn8y73ldeyvb6AdjUYJW4ahSX24RexedzuTGc5qfdBdP6CIecBDLNBOoX8DjK/zlT6ECk9l 4xlKkehbfoAsnRrZvMUF36kCc55OKVzzzHkq+hAQ+SORKOJChW8r9jQMTgdRtgd/phyPf/apUZzS 56mxv2HBQqfqXIPDRqSBhjt7cD/fq8t+jLGda71Rh7Qd/+icoJ7a0ylS7d6aVM+FhxgFJjPfQyNd mTQRJRBavf17Yxs5fHr/dl9J9H/XXRIwRb9qi268MIIZjKT3xtIM5/Y38btd/N9eM93c/OE6svo9 RZKNg4RY4kISbL11JTkgzwfB0u9gp2ckaaVwpZ3oRxPI7xSLqpPOeqixiK7st6umkKIfGA4yYG6J i/oDm9OBlHHV4V+oToL6M+WvCUiHcYDOGmw+9qFfklbhxK99o94njHYilAJTd9c2jYv/1A0lN3iH KnU5UH6NlwurdgNZZV9yh8dRz/uuvWPQtRI5/pwT3YPBDeQYQhHjsZd9ywBRN+XkSHeuu3M270Uh sp5pP1pEmaru8i8Vl+F3swBvmzo8RGrhxJ3A6nBHpD5zu/ZNkIchWjCcYNKxHl0YPKcfDUp0CleL oa2BurnISk8QxzO/hafTKZ2oXTpZ07m5eY0vKnSq7jnRH1OyU5+8hFO/+FX2+B2l7lMYtLEwhyGM kBXKXo0c9B3kdf8UAbbblerGnXft/pu4Nw2eXo6GTlceqWSXuL4phZzmel/I11wx7y4XwqtufTmk HqShp/TUGu73XU70HhCHUKqg2crKjRf2OddnqA7DJh3jgD2Y1EkJfN/oPJeEQgWB0MXAXXyhMPuP yJJp9zgGbn7flT+9hdZZdaf1THA+lD0vwNC32F8H76gnfXC59qvfJCWe7gEBEIDEevJhmjHwrgU3 /eoNzTjHbZoivPtp2PLLvZRPltg3lQLuco7IlE8aTPAxUvTebwaBa7/zGBb2hTn8xEvs5BJVCsoE b/yeUT3q44UJEt7ILvoazfwXNr8zBzZCrPJrivHXdfRfpZn/GP97lxlCKynq+Z+cd7BISqwDhrgV NbAHK5T+DIlnUVV8DYG5s8Gq9XfcDf19uwr6/zH2Ni23tk2SVsbjR1utZYuC/0AFtcWBDXYj/kVB EFp7oBNxJAo6UFQQ56JzBUciiIKOuv3qcPC++16ZGUeea1d3Vb31PHvf91rXdX5kRkRGqB5l38Br +nkXT3undbuakdpODbt1O+PcDB6KTToJp/SqBbxc24Vn2t1t/bxnkXHRpcPRMtBS6Jh81L6FOF0O An/W4sZI8ydq4KE6dB6zTtkD21W3uUP2c70umOk4OaR4W5TVgYH0L6dD75ZcdgUXrG84JlTVXajs g6E3DABq1VnTQZ10XmQ0ZBCZkj5v7So9O984E3Lwae1R7wHpnV/I9rMGPDxNXfqvM/TRW1vS//zm C/m+++hbNudfR1/kuq0NOfUgBzBzoH2aucwaeCZyzDuH/14Nk6/OGV238dQdzP7XC5sctYnnKWWT 7qSqjtSkgr6A9vmtIMh6O0XLfjAVnG5VYFqaKQOH+sDEo+aOpHReQnCGsXAVst7zbuFhgTqMFnLV 6njKndNxbQs8ckn/hlB3bDUNlCr02P0EoT6HcE5Bmu5HB5Brbtevf1yixBmZkzKdHa+rMbmQkx4+ 4F2MmYqHRbOr23HOEC+YxPybWExARSd4QTGadZDgExTzATT4cOYgkkBBDl3fyzDTamg7rgZzTi51 0mMFudSMnaglimQSYz/PFCRRs6sQAAsOfB0DFrzOGNx+xqteF+/e/FKIg0UJAfRWNMUMGgBHSii7 oF4wRWUkUd1InYKID/bWczQbNSavDc+H3KN5alRBvAkjdmZDtmeUuljxp+A4ooRZMDtFFjlEs0UY wtBndYCjMoL0B8SSwgXsPjVnQRriyTXcQuvgOv13XG9O1Gfw7+1W1oU7rd0VDwFMcP5y5p9ugcJG h33bdVJQ0+XIeKEXi2m1QQo8Rds9YAYvpCocOiJJ9HpzYsHHBEihAFpuu0KBwARnp1jjANyCnKbn 3aNovT5zFx1P4lnRmGwARM+zyL52VAHgcewZb0dnapj0APN4j0+3OeMdFE2ZVjz9hqVVWFvsWNcO +Me0qwoKelUdySG5Zh/O6ljfCe6xe3XyjlcD9F4CtA3MCJKOQK6tBxGgqu3w0uvVbjx4O/qrONJt tyGCKOW7TRk+cXGu70jQBZoF5AveB7pi+boIQQfhOdd+urldBJwxFrMQUHIIYW6UWOF2p1VjxtiK dEyOa8kt7myRfU4aauUCR3kI/IRG0ped+DzfXUA+FQAatW7Qb4JOPVvbN4hXAHb5K7i5id+Mgub7 pA5CetfgQtJ5t+fTYZeEDVPExs7z9gJ5VYOM9a5nzn5wpfwoHXBCULUGIGoRBy6KFM7+TXWJyDTu aBY+sWCF32cT4WHENInrrkrSEDvf/rMu4ckaFI+Bz3T9fUnV9QV8coh+enx3jpdcMgsWrxmol+1c WgBCVVWQ8ylg2cPU165O8qfgbebQD41l1nnCULdvpINjcFPCU+h6v0nP7fM1b5QuDqw1qNLv4L3u Sby65EKHIOGuRgr6DIMbtmoK6QzA/s9nd4Hz46qlbRZC9Lcodhvew5eqLbA/Vhsksm0xxxYDq8iB mTxn/YX6TzGZwcl4P5fhEtlF+lrRqAeF6wN/q3Nn5b9zECzGJDeqGryTj5zsGGOvCwHF+tgHgcR7 lHMMjT2PQMjmI1WHdlb6ks33Pp62N43nY7D7WG/Scc/u+navBSN2dHV5eZpeePeF2xpd0WNFqY69 krfkdG687ptXCggjxCMRbSUufBz95kDVNv5QJNTwupGYPONBlqrt7pXdh0PYSxWAXfA78/yZ/cu8 13oPJhxkaW9Luf+6SL6faUYBYSPFQOOzTSMMfSf1JTtxgEQH3sNR0hkbnSZEGi6xE3fVSVabsLjW QmSyFXNJ1aLKOx7EXBjX0l0YUAtrdRdfePMBvA9nElwOpPtgEJnrWeeKiWeanFHHn6nL7Tihjx73 Ruq1PpfPfvbqedHTX5eAWshH3iKwl1PbTHDo7nzGkYvpqD7rgC3sv13c3Vyk91B58q0ePbmOMbGd NniS/lVVR/ZDqYZB1BZ6XW7UMd6q7Hy8+kwdnE4mMFKVnj3C5W+9+zefOLcB79C64Rnj+9yNGjW/ RsJfNa5UgKnUOZQw/z6b+rmddyrm229XQ5OcBfjHJiI0cROC9V6rTlI82zoELPWQ97mZPHF2yD6b WbDKu0NjqFmwRjhh1FUgF3Pgzptb2QPrs5/IwcypeZh7QqcuIFziJVxHP3Wa2l52VtmC0Vz9BnYh rZNIG7/1QkD9v7rqP+q1I/NiAhvGLf79udP/8ar65zbuM840c22t07TtwFVd79EOXSqG+fcnRnAL qwVDInWmCvgYSFrfx/n7FTqW5K63GHfiyzpSWnPgbJ/mOtTDhJ9e9o3znPd6nsSDFiTKX3wE9bRX WsN6N9ocRb4zD2fd1Ix47UZBcmNFwuw2zHA768mw7xpDTaxh6mQSh/8xpbAxaWwPtKQw3uMM1MlZ cSpZmq56DHL0+v3yef/5Waqj/iXdmFMT47niPoMcGhiYPoXZg13eSXQzPQFPB++xD4XZqp4aNNLM aGmiVDRsSkYxU9PRW72JW1TVfeKZDDJeXE3lZxNpItiMrmMn3JPz3qGBUmPNXsm5wgBlvxenca7m fakDQ1LFwFWtJ+1nOm4+gx8MDwe80ihw8o176MegaXj345nX6NpWlr7qzYW/jJ7XFz54MTgChjUH u4iz5V7PqFGbmiLXNWIVRmMiQ9aqyxDx6vHjk3p3I36i4/jdHOgo/qyNZ1UMiSeeiIj6Q00vZDSz UqvaY4Sf/+uPPRX3ETnNizqU+VKx440gdiu3hYaLTEb0BkEuBssHOXbQca+YwCuCTF9jue942Vuw wRBAnaE9Of1DbtXkwMBTk4WEOrb326VmHfSiiOsFCPYLNKPX0+k2xRgsg4n1Axu/oGxkUtnrkLpA uI+oltahR3HZwZgKIqwLbD4TXdScz335LQziUydcgwHm+Gcn3Dpd2yHg09fMkE/QJ6E5gxhGIKxN J/v577QewI4Z3lNtRhEzT/l7TVZTw0O5D0IZTWlPKSdQtgsNCgoZzbYv33vBWppgOvvJCddjj5Yl clP18nukJogd3XuvLlj1exBkunclkf8ibIkUzzuKzpEsnRWDGYXNcYhOkEho3p1OoHE7Tkyia/77 yw2P/rlBLOknqPUSCc015/O+TXF3SDxEAdN3fHQKCnYhWwtI2aDUdq5SDoyJTmIDkK0BmlwDDG/Z lYsyOghsmFPk22nFazjFR01FZ7eQsqAA4nRvvUgiHSKIeU7oAWRcYMBw0DbXBA6gvc54bCLWYsAO 3HAU99F2TZ5CAW7Kha6y2c7PiCo9PN4Ysmw/0URQ+PH+Nhje1pgzjecFZvehIKEXOwOcqtnka9x5 AKlLx9S0goDwAoaE67VOIMUw3JT7heFDh2CqgVsgvKyHLKCCEPHZwWTc4D2Rv4cSXVy7CZKyrri9 saZcAJ4qxB9+1vyrYlc6CRQIlMrUdGc0bva5E3Teg8GUHsIi8/kJO3k1REmqOC+1QLedDNGB3ikI yx5inBKuKhgI0lcZdg3Qt8D1++O601PE/PxZNYC4GXno4njxe0X77p11UdvTTRud4NpgwnQmo3tj y57v4VfF97pSIVzprHSNnjFpX49o2j2+3Z2+xhMzS+u3+5irDrcMArcrqqDEMeh1X+6s17PX4XxN QjgddT37FX1IkKrL+XMLVxR3kwcxOFOQtqP06qt9DQ1uMa8qkzMU954e2EuSt6rtIhokgOAzid+m QGBAziiUfriJtd8JN95DvDN18O2T4pVSGUSxSUSyIuO9SHldZ0QBqb+f0hGOa66ROe+wfR9nPTEF GAV47a4sNY9RLbLfhh4W6ipx17Dp9iFExveugTdwjO+demW8b8QEE2QkYnqphBJ5bQcv+2FMYMjE EXRWGz/NjegHbg7yraNLMdRUhONl6D0ZDLCzu8PVbIth0tghEwMHajFcoRqm7mm40VOKKM2yTh5B 2E/4ELIr6mZ6wjp2xjw31ATZxi4jRR08bLmdou991N+NWr1geOcDo2xpmQY0BSWIIoqNUiSNd/oU d12CR4cnZS1RjdYdvvHEfM6bLyPZxBT4f8qz7BMyAYmxQ5270if/NcXp2Xdy+i+7GRtc1mKd2U1X SMLM9Evdzp80rjgTxuD8lQYPlsS4zgS8/b3IvXufpz4EAJyuVHWlybz3otNZE2u6D1baa1M9MD81 4V+6oB4+5ipwc6tx1/NOJ8MB4XrbJhzhKI713RoB9HaorFHHX5jwmT3m/rMNe5WEO8mlpx0dCfku UwCFIysNltmc3yJ0A9/wYxaFPk3yDLYdCjxFg8vg5+OGQdIN7Gaopcq+XYeII+5rzQEU6c0CSN+F Iby7jD3GeObad9R+V8kVV6U9x0uENIYonD24TsT6m3guLb22Pc0YOtRmNFQ8FFCPmp7+3Px577Wv ZnDmqnO1de49exQ2d0nOYOGNVum/Ktf/ufUVBhdk6tWBB/oHq/wvV9U/ZM96cNSfqmGkUnWP1cSI Sh/o1Z1btOsoxHykMDr7joEYuqFaZ143tKBuamKKV/r3HgzofMoWhMdAzTJN2UNAlMDudX4JUrt3 auOVZLf1VDoSXwZeujvdn//oIbT0ye/XwBg9BmGnxsDmbLreS+uBjhqwZUGKYAqyKT3JexT66POy 3ipd98xiAUSfwy3Vz0MY/x7PKDhP8sw2VMeCu7qgf5z7NrVf16dKfYnmcRP1eZrlZUqdcVA86+KX kUgOOzqGrg3IpY5RYgU3eblFb5OQSMMScByqQ/uyBs9ENnBcsxtx/nn3zqRh0Gfq1gftOme7nNeT +9jJTHMgO9ds4hh7mP5ym/dzKHCb1laR5UXW5opkQRSFm1UBya93DgsSsY96OzVNOrDRStzs6KQk 7l14bX74++xjtbiWdZ5AYjWtNrYL48p0GMb2veudtObQDGmZNV51tzGchUbwL21trTtJcf9curdr IIVZ9VqJnJlQ+lWjt3Sz6Z0//+kf0ylNp0sKu1G9ROLfp3o6sDcdJebhfIMiR7N2RjBdbjkeR7LR v+sb+JGuGPGqREdB1RVPt4sarUvHsPiosfRBJwivoM9nNXNEs5HDiOkFTGl+R9XtBVpAunQS2AAg o2PFg8J3rFUtR+Y9wdWev6pebv4DAhAJczwcPqT9XCsAVZow6g1CtmV+xONqTUCzmDOaxJqCmIyY ZrGeDoIqmndwp92u7RxeOR3y+wDBFtAEdeMN5tVJhRO4uQEwnafmhtz2ezIUrQpQyoeDhFoFH4VH uE+Sm/iOJM3nNB0KfQiMd1xjFfvtdhJlu7nUQUDO4iRnujTi6vp+8bGnCoQZsVeJ7EMx3Z4QnFOd dbRlxoiaVayLyao9bNaJ1C6q1QEKDAfZEIZesl+dxfH26E03jU0+CuK264Cot6vq7Tq5x4qMwxmr GJPgXknHtn2mUygylbjjZxSLmfMsVDjfs9scx3QLxMebENPjqetR/Sg6Jod4wY+aahfa6dSZQ3w+ 4zjrS13oL01SrmJHA6HhutOFCUMWJa07u4qnxzcx/TvgDUTbf63qjFP/mwAOSMFMMG03B657kw7/ /L153zqcmxYQq1tQ1W/OcP4SicMEq9eH6D6FHUlaJWnms/k1kqxRc+5zA6oxIj6FbXUtgMInGOgN wAgIvwMSHuKEADCzMt2Ak8ANCfONlGem8fQV9A86XebdiHsfw9AUI1hH4gGBAgLwn6qmTQhRf2Jn tXLdmt0VUUcFPnv+/MyZJKYgiAsAshQFp8vRBHbd3LAnEE2R8nQ/XO6GOsjdK6WC+qA55LwF4zt+ MIUutA+nGN8D9LErHciOGsa4r2/X4EwsSJo4zcYgdcO/kb6wBPbxKcJVjXtsHqbj6PD+HrYP3BRQ UZRwCrmHS4Q9+hv7Ivipu/UxRjoFD2NXmAaFN8m98CT1FINpNmC4q6vtOxbZ64xLrbjHa9X7+33q GEP1Cft7EIFJtNZxt2a4rs57MKU2QlESu1VN99I6YF/HEGGKSfZT9RoEnjHQNQQqvM/1ZfCcgWlT XakqTvhjkSkmRiGlPnED8pTdBFOc0BLUSor7PwdJklh0Ex/wuOiqnURSZ3YGPl3vTOc630q0Eu// muf1B3NUpStgOusmAbwIi0KOaOBF1H++xIWUn3UleRhqWRKAzz2EY6+rLmhnpBgH2nUbJYR6r0/V wKqoH/JJDmYdSQTa5eO08curw6yzznB+n1+GE6u+8xOD32lDVy5KGjrs+/09VqmRlgmo9k2mYe8y zZzSgdjBK32G7b753W0HN9dHJKxY2xo19pbf1KPvmyYEW8jRzR86nkHI7J1Ckvd+YmuQbOHXHeWT mxTyj6rtnL/PJV5f7wH2jc+TIAxNObRNWib+uNP+uvudH2iso/q/ztI9+CQQABi7gc7BqYKLf+BU 6X6717KDq/ADzTMKJy6TFeEe8MkzspWI+M4PzvEymNJwSb8NvS4cjwTgWpxstWGqxDocfYPxdwlx PcHI/ax9P2Yd39JG9udRVN5TysEDXPnEBH19moYJuH9+6jPBrgjxd09p2n1Ec4sdA5l5UguzHSmB eKdK+JQNTZOj3e9RArthcI9Hhitwfa0CcNu6XeZQc2o1OzBVJpTm3ULmRBv1oS583+mkGZg8U9Z+ O1E7O4tuKAFi7y6IlZbWoSeDtW80ks+U3HoM/wkVPH/+339U1b+R8aAkNmelRU8q/POn/seq6l+a 3OVOeesK49zTtwu6IIW26jKWM3ICl5JgrxodcvdCjGrj+44kicL+4kIGY2xSPama8StyV99nVtX2 mtbxmw/jKddhMJEu4VQfe+gz5jqmevt619yvKTg/svbrPcERanvw9Guw0Gxqp4V7ch4G1Yx50/o0 R1qVBxjOCLiAS2OgQHJYd7Jv5Wtk+tb96LmrPrqTivv3RjjuJFdX4s+JO6q+u2izMRHXOby3KeOL TOo6qCfgDzuqoqs+35Z0UId8NvNcJ9MoTwfv9o2rfiR/q4Z4NwwDRG9SaOI1jUG1GhM/k9frVEAI cCM/TLEMfBHdnCoypsTOWQIMzKdLuT3NdSvSgZbhKxj+CPEzx/MjvGtXwMy/rx5+aQa9Ji11JCcb OBbCtz/8jyrGk7SfuVtf62PP9fpsfhbSe3oNPNyGBFrmvQvzlwIb7+9BQ2db0M8nT3ZpIu5zlsak dfCJqVP+DJ7VSF27+Phb8+1IQvjhuT37tF912B8KgBguCiecriUqd1xoGSOoAIcUL3hTDhIRiPel ejfUjUhxClSGSCboLqJdshFM1/nbe6bAiWkKq/iideUmJFfWDcIlJZLT/1Og+onVuGFZNTLoAswd BzQD1694JzUhzVU6kIhmF44G0nM23nuq8Y5rpLZiR19X0RT4Fohc/3MWLgyTS7UcsNsdYpIneVxy P/eKWByUoq8r0tVB3gjl4o62doO6BOjCysOWeAwQxB7YxZQOKlwP2JgFQiliI6BRD1kJwbTXcwB3 Eq5cVnQWgxleA4AdtOgEETUP5GiFRU9lQ9iB/lHwqsLL+Ackinvi7fBgiHurQSCQiMZP4fK+L4XC Ii1A3EVRwtnwgj4I6dnCpqMDq+y4xKLbCdQ6xAZCN+13vE0dxHTclaoTct6NwmzajF7o+gLQCVv9 NVT2JE/TaXsPKhnBdQUxf+3/LRX2ckbzmvaMe3u8S2fEj41FqoIQOSQ43gKTFBoKG6hCCYvEwPwV wSy9wpcYVDLSsE+KPEGxMZhZh/ykDkBAGLCWYhyFcyMHG2sJsA1EHcSsK4GCoDJ0ARjZskoEwHwX IMS+ViEpTg3PHhbhqWO+A4ZDNDhsoR+aZzNrABv75+jpP0Q2fIaSUtzfxZ+GCZY9VIrRa9UHBdZ3 c5KR6UGcEWQV4iIevvNJdhqSpCpIKoqIJ2KrngDYC4KrRUJrgN7jnNBFsfvRCbRv9DMk4/ik3b18 nOcHrfdxUF/CUGeFQODLRZnPQZUrKayKXNFuN4hvQgWodteP7MC84Da4o951jBY6BMvlKVSh/ZbA 4x42AIeds164fn7WZ3uYOFy8XEhm0RnmYzhgno9AZWuLbQwEVQHwmNVXHxToBOjsGzesLZBv1cJO siKj5IU675Y63kMC3334Su2MeLsMg0uuuSfZcuOebPDdY4kHnnqvpVOw7qMyykSPAnxFkLSWwymT hEMS9SBHd/0vEh+ZzrALw7mzlXaaxU68y8EKTpqLgecwCqi6jSr2+wKy0YVJfTBSfgyW5cAKDTlc nrxRJ3jXY1tQ08VBBft8pjfpLkZPitOPdD1ynauotzuRv4cqhGJ38lrdSRZSfSETfDiL1QDsHe+x vtzXQvG5MFGPB0bIlmI+V062GkKw/tNdBxnSzw2oZYrkikahBokhdk3BZxGlTBSQ30ZexCAsyf3G a5BQIB5WNYhR8jvpeT/koCJn2c6abwzm+UrC2Pst39rPfzLXWoPuUuG5vruiJPGoLuHPZJQi3B2w 4N6qWAPzOe8TPX+zl6s99DauqlWP7WFtoUlAHXs3k3oMmLLOPFnByTdNZxIn5M6x17xsl0PukJGV y7HyIFIWiIVriU4K0JeBR4cQZA8spXCcUzO3mEDDhXAa+Xy4V/YY7p/DpQdG9cqTnD2sQay/mcx5 itwpE/OcFkXYR1/B6LWBWcg6UGtotPcjgnPfldOIQmc/x3vVkct385p1DnWQAJzc1zv2/xpar1F7 GuvvPSy7biTf53D+bh63yl6j4D6+zjK+zYycTMG5YdwBO9n1hfsbuDXmawt6IT1yGycSRs9nu/Zf 6bCXIzwhA7PrMg6B0o7ftc5whd0JFab3ftuCFHC6JC5TJMnryRhvkfBljzeTfxP1Y59uH5yTj/Xi wVWPnkJTsCsYADgxdelIWHHBiOd/X+X/LtkD6sP5nWYKTf21Kv0Nxdm/7kLl2WqoE2+s6q4HqeLM gXGdplj7LNpqIQMWXs+zqr5goobs2S1wvgRq6zTzPfwzHZ/J998xhH6fe6SbupxiZ6bU5G9bz3j4 5/IJxL1GGCocd36mhRs43IljbU6TzV427+MvWRSc8LiHtUZPbGNyG3fIU+Dh6skypNPRQ3OQ5kSZ 2pupEnOwwU+MSYNXNBhHJI+8Led0IPIOR+R3Skcd+gIv7IxS7wurxOv5zcEJhzv7GrBZA1hpFOM4 o7Td4y8EXC+1SWF9Nc/Ty753nUoqvDv9VfMyMdCqNGD+3IGJeRrUN3v9Us1Pezy1pInnTTsuWm86 +oIczVyn6MSOtIenJwccCjAV4E6KmopPt+zid7po7zN0dJp9kP7nfrLDcIl68LwLE5fog3jcj9x6 xDQ62qlHgm/vwHIKMPXXIGGqk3ZvpPW7ddzftbACP1UvuRep3gCm28m5CvrVbjpFnz8r1MsEFgYe tGvK+W3/6M1ZTqv4xwGGYox6Ua26Ywi9GpN4oc6H7XjwHCXeL1APYuSWD+ekzLxs/QxJ5zK6jsmn dOqBS2MBofWI5dASy9kO4sBnkbkOdhsLJY2Y+gwquiQtWYAqSLHp/rKgTudUtOsSFNSYrtmFdp8q egnJmewTHDeFcN4kZvLouEI6qLk2gDYzFrPQKaRPJv1EMYmmqXNaTAO88gmI6Cgx2WFYEBmveo8N qIH8LkagxYTTKKTvkBcavuDve08mOQ54FmXOz6PYW7vJTDEHC/18nq/fivScHLyEiul+nNE7l/vQ pwCfgLeecd4sDekuhBlnfk2i+Wi+8/lqCw/XBKbPZkcH8Jdr6RqamiNGgoZmp0L4q7RlFrpUFLwb 6wKBgdDfj9wTbteDaERX0yuM5fIibDKir44mfcdOpVMeRU0RPMn3fHfSpEI5UxgIxnOlQ4iW829F NCHFuU7xAtGOCfl+ajqKpCfhBRZqp98gDbT1uiLWPIIZ5B5tiB1Pl+j4b5Pffxbot7vfEuFJxzTr 9vYSNNMFoOAlvrhcIfM+r0FWkCilBlFb6LYzhUc+Kg8bYCf31JerIXZ4eJKsYp7XCZJfT3v8OVVR CkJ3iO6R17XIjw/w6gEKGAdhpli0Iv1nr59e32xP088/n2RAVZ0OiJw9Qi6zEvUKPpzKV0qLXSFG WwIPFTugbCFbrXhPAs+2oFhHz5V1kPFmHjWks5KaiQU6RnHv4aRdh2bkavYiv+7tz7PN55RX7B6w nuLr6OHW0T0ihVVDzFCngJzInTz/jQMZJHdQ1J1d10h1KMWtDzLBDIjjoL5qOQ07BkbTOXWSIwZX Oq4P8jb2Kd/Y/cDadyJhQSaqaA1bHrYAD8LFIF7J93vV8bviJkK3vgyM7EHZ3b9MF2edY8leDp/p 30xOF9Qnptggellvwc0erE336ewdq7arhz17n/4zHIO0b7KaxP57YNIH1kWikjQZcIjdFJhQhVt+ /RY+QP1ept5toXIdQ9ljAOM3If10EUsRQYjzdWFZfuyg+59L1OnR/9QBYO+tYpQWCEW+FSmcEnWc q89SnSKeiZv0n8l1ug13SL9uhyD0lRa5TVfSLS2je3mYq8cy5yzuy6mWhXITGy0cQGRhpaCXoH3P UkLj4P5tvrL7509NMx3dh7PycTbRyWi8rQTCtAsrNmD/Vd+SvV6rFePd138cpjumSjuJ1i2Gfg0d x7twgZMW/W7XlX16j44pnmUOwopGoY9nywPuNp/UHwc4cDOMnv9KzivYZ4KESjozZ+qQj/tfr9ph 1Xr6Oqq7RXE6aHdDf7ZNTFgkt0UbOt4X3fH3/TTvA1WtZJo9uMmY9s//A27mShPKJCo9xaOKVFcF GhgmXRLi6/4ZfBSsiRp4pw7ncQ/joFXPaNcT97D3FLsSAumqE0VojJ+Ef/LnnFoJYwYcl3H4Pfwq TNEtHOLIG4yMpLZEcSQ3i+PWp/fAJ+ltj1XsRAMBTrd5oBR9kZUFCwuC8/BMgtnn8ZvH1iEGJ+fB yd2SYGjjNB1fvIwBtM1evPurQqzp5iDqMVi7sQOxAZI4xYpS4mvghFWUVgoZ9ZO/D2xjD37S1f87 Jiuql3kac+x6uPOyKM9HFvHcy3v4tw6hZFUdGEVypd+6o7setF9jdUYUgjMbhLzatd9mcmoyhZzg w36XiW3R8PU2Lwrs6e+r9B9U6e/HyKTfvfhP/euic/0vq+pf2e86bkpf5lNVOdh/cTyJSfA4v1Fp QXfarFP2OIPgbluf13W85UvyqcezpuSQS+PT79HM9J11xzYomKgJ2g2aDDO0qmOf/ZhjH2m85V9c TPbuRR1maDl+3Ru7Pt3OuHVYRt2d0ben7984iwSDyTwEIlatLQ7nHgKo6wz3DGpOfk9hgNONbPkM Isf+FMj25+5i3OYcqRFw8NW5vWn4IxxT3zotIz+NQ7SmKq2n2dw2J9v5mbHzmXxNpgNbACpwvPbp mO/x/blO8Oq/WW+kMOvcAmTST0xc/K7SZvIGn3M7YZLOZS25sQ++Y2LtdF5pp+Dt/kTcN218XJCQ EOZE3lxSod7BdRsL0UAx14rHNjufy7yD1XQVhiHBzjGT0TIPB1btdA+DDsnxLm/dYh8m7HXf7tcc 3E/WFF7DaF6aU0W3dNX4rzV26Xde+2AmlQq4qp18aF8o0M2ZFuqFPDAJ4krZus6oKtOqk/PM8kph UvwuA8rxxwT24brRKlbNwswxs+I6HS/HdN0AZBgg9RPEnnFtuwBwXXGzRlme6h0EdIkrjEHMU9SS 8ORi9Zco3OfiXg53qhDGJ3xGEXY6mzlqFgTNT0ZjTWBgz4P++menP+nV12+gaAs2VHgYT0dGf6Wc ugCfrqX3JH5BQc6yg9c07oBgPAFFQ6ER7+l0JzF68nexgM2CkhCPLmefvEo9RPY+XWmn278CGNtT c0Z6TrWjbhzijwRzfTq9zXjainjSLXYpuMgSZJ57y8VnQp6V6eP1JhwpejqJdSM3l+40DIumNMYA xBNNwlkKHNyoyGUnYWkS8HmiFzj0Ke65TwqA1/CXHwQjzXyS+7kRVvSKVjhdVnxJFPzwT+cox6tg +pzZChJ3Owf6WRwdRNkQAKSDW8W5MIccbjhhgqGXC8wmE648BnTmd4LNOtwYybmTvfKIys9Y3Ev8 UAikvTxT2plimHo3NM/mWmg2Oil+02hY/AOeKpIO5poQDIdNYFrnvuyiiqwTL5C9IB2kKt0CdIjw SDDmILx5YICc86/1qhhIuu8uqjNYpLGJZI/azZj+s6ND56DNhhSus0oHgD0nfqsyBnvUREfs+JUu QE1QxgZ+XFcVvc8UsOkQmqi2U6YOocYijwDQZ6cPQx2/T7gdkTZlFTuaUM/qQkG+OwN619rn4U8G RECI9+MK8Hug7uWpkrvWq2asYj/AdOD0Jvm3qEyvTyUkQwvFE4peTXW5I03w+0Wj/PybraCKoZAt 1BHUErUSRwrIZfII1Q1colhZB4ClAK1/DQzocuBA8vsiRueAlEb/KfDUTfF1ioZ5gKu7PX/O4R1L X2etvMEl16uXvuiArBte7kpaWIahf6p6p3NViBbmnanj9zPlZCRd9kD/xqa07yQ30Nl+CIiEgF0p 61wvN5aJj1C6Dewn3XGpm8hQcVrZ5ZTWezch9mIQqOx7cIqSyEEsPUf8BYAHzOsc4rtGObapgwOo 3eYPm1RyiESMlWgdwhV2264icWYO0Bcm1tgb9TuDVjEh5xpQwLTKvd50RzRf0c+u7Wrs7JU1MSt2 15tuanv/9velkwChQdbp1kvJFfP7GQwvtJx5/aCUNIXxsR9a9S3uq40kcgpsavXGjuTFOklSn2J0 14wfTmfsj3iB8x3zhvD5xFTp1zaxAUUtXnDGCN47Cb8MuHx2KYIabJPhyhrLjrtFVedgcbrzC9Iq fbj1toGRAx+rIMXfDMioarwG5FGAlGKNHVvd1/Ps67oQ5qLKcyCRM1Db5/LupnxgZFdWQjowE0ey 32KKNNgfNu2noEr1FGLvc2oPwTrCz28cpi5OEBB4Sp0NvkEcc53CZHgKUBMN97p1Dk83eTdB9nZu JRdQSgO4RstVhWHbfuKsijUzh/fvZKns2Svc7Qro4yUtcz3w/OyYH2NdK3HBILG7RBg1BrzrGKA1 DCDYUME7eY5f9dR2iXTURR53ipAXFD57wxn8i6zvw70/ToViN8ysXa873SMJ62OG5RP7KLjP7wTM xKMKkjGo562BL7C4qCrl76Nug6FL6j/yhjLy8jTCtXvCS+i06y8vCdUc0FAO57uqzhOFzlnijjTO +l8YY4pjtL63g8X2wr0yGUZ4W9IZJJF5DQlnNsYo6OJf4j6PPU9pmlWJ/WeyR8Opsd7VY1RAUGeu /LiH8dnPfbVM5VS3USDaFu2BkhNPEXDCcWv93ar6dwhR+4UFGJGz9qQDQ5Wq6p+v8l/5WkGpoIt6 IbjbPCoH1GlIh7lPEgz2ZNltaODQyFQYQjK/ea2os8Mx4xjdiEBn0l6uInavzryyXtkpeKwa+/2B mHIPWjR0uo1OdWJABuxuJ/5J9ahLC3QJWnVwopB5V5Ez78tMoonGt+eur/OFeJ25J7kzpsSxiSHH gAEmtKSAW0+Tp/m03x3L7cb8chA32NLFYID2wLQPPlCVJprbPJXT+KaR4147CxP0J+1zrisfz0dH jUUpa4r7hoe6Vw+ECRTrNhKlCV/9P2HNlExWa0iyCYZNwwPEHLCWhtLcJnOrmqnya1hrDfNjVou3 jqKO86AevRTv61/Pd+KZRqzewyCmDrw36xRMXIze8kol3bUEn7KCtcvIYZouC7EGtTMv1BBP5VPi nx+xdzw/NSzKaXYoGIL3wqPri+WzL84WuITxt2JQ2kXpbZtH+Hm3qvqeKAbKGk8M1PCbd70gvAN8 6GQ09nzvxzqPLarf959/aM5+/Zs/AFKvgkgMY5x24bRhd5NmwJXIG0PcNEmByZ26zotSEK3pUxwk dIr14VjXC8ntz3oBOwNMA4G2K6OG65g+9+Pg1HHhcZzoJm7T3XIKKapIdLqb6R0PJuXVTcL3jH0o hOS8QCiiYXSsnS3gEkzhVzh93u7IXKhnyWxX3ZH1282dIk0NAaDTnTbbaPZImodGL3DyitLhcLPX oxsQU/WKzZ6grx5Fc06Op0PwjlwTAMPGZAKdYGKdcqGbkPcS6e5LXAGsZHRtP9e2INqjcSoEsSfI xY6J+8w0gkO3s33VJFCE7tQpxmDg0c92eQwxuFAgMO+XpA+nY9t1A7W/e5D4RnmMTrKVylYbKO/m MlzO8zWbznyuPl3n7+ik3YhceQiDSPL3c4FAjSkQquW8fssXr0yCqvoC9Mwor5wYvPaxEmTRJnJu 75MEJ3aTtMEyI1inII9ob/loXEjQRAkZHyfcj5CKpJKCQLJPI3/Nq06ycg+R1QnE9rW2Bd5XlN10 uMqTlafNPYi20bz6rj12bUST4b0Yd5Fz2d4Xc5Ctp6344Qx8xabi74rKVY1800nEjWdtpm4oWqyg ntYJ0fsRXcoOwjN14OWtw0k66TbzImUJrF41ohTAmIfop0CIu1z4oC4kuv0r3Gh6usIbjckFVboN JKHtBTbSnHYmcfnoA1utqDwPCsnXF3hIHZCOnyeUL++aqotGqD50pauisN7JaHSjSOZydVM8Y/aB yrhTPe4uHkZK14jPOn47vXoAJlRtpoPCPE8Ng/i3eHTGd17CIxqBhFtTWatonO9TFKoFhvaw0n2n Ks6WBeZJABQb5EoZ4akT+qMEqI/YfqYK1HAv3Y44g/RTrhIdsbch/Pkqgt8kspfwhOLoP0BaF8il KGP1I3+ug7ZYPRNQjBlJbzCx7UNdtZwC2AyHFxvroB3TfZpXBLa1HVMh1eAY2KQI5YpalW+2Lagk bxx6pz5Gfdd4w/y84nt/n8uzntioqNbP8Rqu9bEGSOp/4yg/STA+0pTKS7Ci5/MnAbzXfRZJgd5p B3XiIQ7x1Oy1JlEmwBUYo7oGcV5ONIwAX/d5QR3vCFGaoiit82cR8QtL3PVG3M+uYQ5AN7PQrGTi vGH+Ef3F9QznPUY1TXQAXpW0tNz0KHXBYDAgvA+F70mIp2Z9tUnM9W67K3PtfebxDK+4ZR9iGmIA iKL/hUFl75IxyXEPmJy1Y7oSXPwTU7yGWli0wJXDrzqFf982Q1nYmzQGrGs9H462n3diWIDYx84D pF50SrDYVvXKON1JLbf45erfVoD3ElyQaGHXp5cYWet/CQyKskfqGNkcqEpuw06BtcH8wujoKNiT ndRXfRuX3ueqluhl9KZOLqceuE5iROz6SFgC974Og5x06VekilzYOHdt9B3XULpSIEUx8FkT6uAT 2VRBz5h0up/qFKHW4iLjHFYNbsSNE9hJXVmbcv1mwLErap1M90nDKXJh3WIBGN01JVBxrafgium7 6asXerrwcyIMCwEndk3su4NTn65LQjxQZ3Vd+M1o3GL39YJ9mqmsqtud81UDVDmGMRW9GXEC3Lup Jblt0eJ2dUxJq4qH+6/kmsto5F2jCu2eaLCC/n7BANY2MTQYrF1pD0pZkC+sUCcycqVA7+e2NS/U 9e3EgMJulwYYDGfIjXMVcEEz3VNW6b92+f8oQH1//onJXI+VKX+uy/6iyv9C4akhMBmgVBePZPjE CQhruxGEHHbWSB/dRhE/P13M/Tv47rUjXMifMY4KKhilScEc7M7UjzWWM8dxvE5qO05+zEPVxrk5 OZryKHzWKxrGP5NX2VwVmSlt/IQG/wX4sr+gcw9MEHQjV7/Tz86B/2vqNP70z1L3QdZQm4fXxmic KdGsmZu3mWqbzDrrceVTysQwrnOr7vTWofay1/BBZsmMOsOXSc1SoUhPpFDL3GIPO+5kmfkz8bSs nchENdk9DEvGLQL+k4xr6+Q092ejkf5rjf08UZFhzZ0nc91QDrPSTH8hPmxrCi6eyw9ekxM7afgM hgg0U6C3JmEnfs0+16OfDwO0qjUsrIGz+XEW9HRNYVIGSeYvM45XgiO54psD55lJOzDvq2rR6gl0 6AiSc7oGf+qh2PmpLXVxIPm+qT/+4OZ1qLHuobQCjlOip6JDIX1hTZc+jdNlDb2q4CTeWQrGs19n zSzQVvx6fnsAt9eBUzvd8eW9nz9/5g+air0iih2Aj05KrxOHqepnd7Or4NCD/pri4dUouJpzSj3c yV4gQjZt5Aa522Se1vNZfLOcIx0f3nFK9ZzgBTQcGlICXHd0pU5JRa4DiDrAxoJAiwJXAQ0QJSGU l2CHZlLqKJZYyPVx7BQIO1wVxVMd7mFGYYjiwC4s+Fk47sNniGSvU6yYIoaL1NeD1G9ksAovzXhH 4jjN2fxqiZ23S56wmd1TUOWrNGO3Gg715LAnck4RUvjskD3CWZzkf7SWYsfcFElkUUeuEkIBQCHJ 3qeA9xQtn9Qw8WkKyxK4aVVdg1YuH6S5z/A0LbGencCJq7740TpahS0435PFY7IUY8NmU7GbVJxe tCOyzeAhOs9UlkyTr8IW92zB5n6vXufgdXvnvb6/c1tq9pPUukeGKsjddOh5AYMzveZyPWHHGn6v P0WcaCIxYXtjk8IE+ySbd0xpLUGOokGRuOqSNvHh5w6hOXRj4y4ssKdowcMFL9/nJZRRbaFvL5I3 UJLDl7W+e+G3zFSiCkfJFCoWNlE+vFx6bLTOZ1m4T7tr7FWzn1FfMHXt9v0EoIRg7XehUA6ItrVu ECV5raIYwaZBrjZoBg47PJjj8Jy8nZFdrySfqIYoxlzU7M16z2OAxQfg/gJ4JoE8B+YMg6W7l7ok BRfpdYEW6a43CRuN89YnyeMHReyHSzjd3e+fleTJAg61IeFJpAVRv4adOjBgBPZ1vuMNozCdO+Ol fwhXUZdGI760OlKI1sUDDJ5OsXdB75fEeh+Kuob7mCxNJySNZ0HC9thPflUTC0UQpdBda/zOC6kz QNYjGtJn5zfdKnY/Ksw/UeQ/fH6AihK4dJx+V26IvwhzZj/xCq/1k3Ss5+nIA9l1CFxiANgFRAPX awXPt4A+mg6MDvd8Y9xWDm/O1KXco29ZjfPxY//mMQgXkcPSg3jYA9EFhHHvkwrA9E56XCkROs4I 4WDy+AT+EOocw1oonvh5b6Y1XzhY3AlXNTY5EyEFde4LE03sgsVq7CJIKYBSHaQZP5PLy+gnFUeE gij6zynyKugvQfyx+srfjT3GzDZBFmP0pjp6ltvTKc071lCWsyfyE6HcwhMBOVJ4xu0zZ97jOk7V wwGpqg0j+0D1ZyJVDrtRMoMBW2WCl1J/DLjbL8OMIRQw3y2b0M6Uttlv7WSpLnZ5mapQrZFuz24D ydeNSsk/NM5DQikQ4ThvqAKClnpqHaKR3K3JEvShwMtQISua6Q7uIvf/feboNMjhIXYNV3BKSzTe 9peQwQPjinpn8AWFPI+f9KWPvsl4LkYyhTYGVAfp/UlVTtZl9m8/Z5QTaxPUWsIz249q1MjZ3ejt vMEMaOkPBiidNW1KenT4IXthG4TnKbE6cGMtuDUdv5/6JIWjptaau2vmJNzT7dZVp+C6Yp1NnOBi Kzd/dxmOTHxXB89Wp5N5FTvJM9OpEHAklsJ87Bfn545fKlNI9aUPyj5i8pI+cAP6/ldWEWLQ592i +F7Cz6MQC+sUsdQxirSGlisH53iAzSFpzIrLD1FJk3L1nt1GmUoFVqfhgqqTWWeTOsrwY8ZbX/BL I8tcxRoLn+umsD/LgREd58olBaRzVevsnQK+wXOGMZ4PO5Z2m7me2CLh9+Sgy5oGzVr86DPu80lf uv106fxz86kq/xvBKthQW1PKL5twqOqfqNLfuES/c+DI473QrbMTZoQ9kseA4c9Tczo0kzFb5/kc /Z2x06pAT5tEXlskncYeDjTqparwF7ZTw3CzmzrtoT+uZcjatB45xz7RvHRpbwO8Xs9E9YVD2PkU NIrXRYEraaZo9CFre0WS0OZl91CnB7fGcn/CbRoGJMpc1oFs0RDiJ+FxaGPAIJBqOq2BHBoDnIPp Cq44kajbfKsPYOz0j4/QmTix3K8lMrXganP3eiLESDzE0TEAXxoBRDvISKnqSlb0seZikNPMxJ0D tXD2DUzVmWx28atX5tM+Py/bJIWKTYemokb6O3naT6Owy5RBq6/OM73GnbQSn5XDIWkCN5/9Fh8L UIjNe3bcxNt4oHPHTtvljqtxMnYNnL8WVpMcPjFRO4PuOuc8kmpvA5uGuT85ZoMOw4Hdc59Hz/wy mnoYsLrjtgJ0xZXaKMFqVrCpL11BsrDGPvOnXnO++xwcnRjHJzXxHoqpx0Av6fPIff2V8Ldx9Hci Jd0KC68R7ec//ac/7jY+J2f5UqXlozVVBVIwX8tylzQpg7UnwLCdFseUjLaLSdXlH0X+YF6Caq3w 3XyxvdjdpSwLGKrqFLxUd5Hqk3RmwKSL0XajZQry9BYlkmv27WhfIML2o+ESAkUJ2BjLcCIwCeDr zsNJ/t1xQQz+9cLhT9P0c3prO0J5ROoaJo8Ne8GN+KyjwW3kgv0QAGVcUkVkpWNqsl9APHqxxcRG jPCKy9qupZNsT6cpAtjdydMoaPaFMp18t4PSjzNnjwRM/7wQIiiAeC1R4SS/jGQ3CPHXJaTTRYHi G/ka0eHkvtdeDjPNi1CtOJ4NVIr993RkwlMKc+k5aZ6S8/IVo6jpDD4ECOSGvd0dc1L2PXOnqqdI Oieuu0Of4S65RQkehf0uJhQmNIpzWee3uYe5CDi4g8VmM+pILaDnpsfdMRMtJCoGr31AEWgMZdNb 8260VEdck6se8uOfu+hsTGtEmmXxPF0RM5+ESA6GoCaweLtRdWc7Iv2CuDMPRuiMluP6bpPNXRRq 10EOaUU4zt+2yclJEgkcJIT3LAltjad5CiLU3vFcmdvRh91vbm9LDeG4MS7xcz7QUGYKz3P3JYXj 482qNblVmAgVg3QUy5hnU3dkcH+oRzSfWy1BAC/Fnd4eoTqaqt2/+BAROcAgukfYvb07IM7xKR/u BDrvqTv2nAZWyHVsRnBfn5XvA9U9SEJkBeV43aKAivrDR2dQCMWxSN1rANQR0ThlA3MgcyZH9c9D QzmzrzWQL4KUr6q3tI7ScFg+73MApiptuvWFism6g0zs+CZTAEw0QumDQBB+tH2XVqyTvY6yHqTn qgOY9gI4jZ8l3c6TeOhCyHRjU3StOQi/COkAh3t60J97FU/B5FjXSMXoN0hAnyQx9SRGIExPmpuS Daqu0UA9KfQzSekcjiSH6kJBxeU4F6MOeg0EXZHcAmrwfv4vUZBbT8yYj3+Dyqvz+U6HWEWCASc7 6uwNZ+/dSV9jzDAB7L9cPy+E63Im66TfGBBdlLEivW07FDJFepHN6VxGA89XnXfVu3dEtB41UvY3 hnVIw16OSGRKkOx1hk9hQq1B4gsQNzpjkTeY14CGYZhBA+PeJOor9WHdB7ocwjY5RHS/UNi9z1oS uF4u0NqDo0010ms6hYA9iX+H430Btc8GCSzeTNop7v1G4m6Xtz4QQOL7xL6NZFb/XdJ6vqKMnW30 oxOLyD1Aoy5rD3vVm+a0u3vgk4fJeU2s01Z7f+kg31hItTsCjf6P+tG57xNbpdEzFu1SV7+NEers j7p4qg7BA+OhP/WdCtPamMDtdzPmM4BjszAvoaowbYDu+Ymx7+QKrUE5Lec5Za3+W2TmMrUw4U8F GBMEhzdMSMhpcJUZ+8/vW5AGr7VcTD/DNWQm9K2K8uE5XYF1UR29B89vAdQtwKnWr97i9MQntc6Q /Y6li9e4xznZ8EBP1+Y9FFcP/71ESRKz0TZjaLi/wqTm++BgLUdQ1Xapz+erWHse23Ka1GicXZyo d6W1JifPdeZOtmymBOpcXg4qMsqXYrJb3usfvNDPp+zB1QiHa+8qA/EU13Ao7UmZmzNLncHvpthf aY8NR/J0n0/jNR1JDnrUzOl8P49F1TSg2wnAPvgodoCmAbAKAzg+xfaw25bnf2olHRxtgYh63ZSu 0Sffch7VZZzgSD+owHWqyICO/7SjZxjEfD89/6cq/TfTbZbwhqy5MrVzvK+/5vK/vnvHeJM2Vksv IRWe6a6qS5Uy6rbWG+5PrhcOVCeOoMWPeKQHKxh4tqJ6cbRzf2g8h9RIeeEOxqGziSC83aEFqcjf DGWmuYvXfVYPxMAwvmnQMtx4HWmtgI/qGikpaqqoGbydbq+BY04gyx6OCuCdfFZQ25B81Ge22O6H DJg4dUfz0TowFxLk+3BQ1mGD8DGWqIPHeOVEaqTgDAMnV0smvVUcLPImTeDSljiHrvP8cSRl1sP8 TcEmHzzXSuZLjSHdlu0c1Kp9VI2fpQo0hyuS/xQaQeiZvWOoD1eqcpiBeXyf/XeKeqelC72MB/Y9 zQ7UilPqMrX4PB/D4MOqofWuTX9E6aLqxEGPjtXTw66064D9HtMwo9/TaYDGOpzOJ/hCshvunYLx ahrfewS33+lXB098jJfu9TJF63z04MQqpetbFxMZD6v+TQZYiLOF+QxhKqpwfX89kcTX3c5BFaVI GAzKd197cxeLAzEhAwWVh7C2ulJVckBg1lh/CBr2udCE5FI9o1t8AjObgB/iKH8raQSiGDo8aU6x wOH4z4dDd3WqAmfHXHobRI4LN+fjDih7xo4b/qfgQpkTR7/ndrijvNSepU6xhEFEQhOVu3EDsPEg 3vrkWRewpUtKgZggp4r6VNYueHISkKbPXXcE0OCjA07vjaLhcCIh0a8C5qcZW9HrDp9rrbgXAkW0 QN0EOj5r382VacEd3tF0dJDNwrhOkXwWwQVEWR1HNMUtejRQS1RgcpTfBZpa86Ll3myYGNtnVQ1Q cUR3i4J+DANFcHJBhPosPrIh5XSD/jsc6F8H4rzPBLHzRCFowS7gF/mRIIIirvhsUtY5RfG220W1 8LZ6uVtNBxxjs8mBf2MoplLcfF/Pe4JvHDTsQKWCGDq+E2ZxdwlVjOQSDRdQsNFLDL8B+U34oqvp oxl+Rz9mJaAQnQhaIME5bXD3qcdnqdXEdKAnhwf5htEJ5tTDdTJFaAT8JKmwXT2ExJ1G3cDR1Ucc klPkucH3OUBULfngBShVE+h3FzQ3ocoVElnH3XD5KmSJvh3offpvV9VRP+k8g/YenP9azx3hg9gm l5ZFVZhI9wkU7jhfmrz2cNY4SJT4XRRtvOtEqvB3XaQApShe8CJkv+b+fCPRnKBhDjwWjNaKwaS6 RJp76EZVACCkC2gSzlfdJoxPpNP2Tirqa5l8cjqxuAkonvLe9xk5zSmcNrkO0wAORU23iZLh+nND XNuxHAWT3c3MDpdVodtk9i4+oBt2t92D0dk9fmqpa79MkZ/B2a/QiaAOIHoPPGi5fV4+YJtM9vmU LhKfvGGM5JtbuhfHf+67KfeD47NqiXQvYrTgO89zayaaMJm3nIWkQWxMheAG7H2Ixem80S3kgOdx xWZuV8PdH1MMLo0EzaSM+X1nFLCwHi5YCXt4YA7cCd1AhmlBFWZq+UzrqrgnvdbQS5qRAoeEurvr /EX0Ml17UKoqdF/bRPiOtS4Umiy3fBXuPR2JN+PuU7rYXO87nXqMoosCzGY8Gd9jw/XFvKBYehDY U6/j9CBiSSSZQ9XQKZrOsFWroUPvhXPwGZH4T4Eg0ss1fj7sTfzrqLW3+OXOzxHXjMupeKS4sYyy btcvn+3ljY07hOReQ9N5b4Dbu4EcUhrKbIMJhXPf/Le+MAyWTlc4uSGVv1OJamCf0oUmkbXGonc8 186FbfxyiucqI4ddvPBhH/U8O1hrDaN51K87kYyqGsYV9pClGoZK1TInvG2s2Fit6cRD8zkqzhit 3/Fx7Lq9cO/0pzpXRvJF7E41RcsKHmL3t9lL8bshR2ZCVcmTlnu2rHfLKVLM4dONh2UfmkJoUydB bF4j01nY4yUKUCSlXZjWFhS8zKHqOA8XWaus2/xF5OHd20ASzysJgTBXx5+hdLh0hMsz8eM8HnhO VV3+3z8YqdJpcFemArOtTHXWUYPNDjjEVb5FIhXegs5eWvR86TwTCm+8hL6/3q/WOYn9swsG4ec5 6FbE/dyjcL/W2euLf37VwBmSZ+VMWOoVEu9Jrt/I3gl/ztvkjE0MKCmj6u0LrhA8fs6jXJf1wMnW d7WLkxg85FJ68M7XaX+nkk/uIlwwVcHBiO6D2JM+bI72mQx9ph2c4dZNvDhfwtXqsGJ5ZVzVrsM9 e0bIQj1qJUXdl+YrGx9Jk54uKtqCXDuff+Ljc5gxRP7+3Nl8E6uq9G+7/P8koWpMw9H62TuRq+Gg /6Sq/tHUhEyh4OwldOgw6AZYOhrVk6fpeMLFF+tegcdIQa1ab95QfCZevJ3P4WVMKvCrc+L+8Xal 96n28WdiC+p6Tiag9clYb2JUinF/nQxUPcabeIjXDx0B669SUEy3kw4zNzYTDZxZWXP6wEQ0eB2q ordxok5u+B7vXzVzf1uYqDldqXWgVBXYbTeW0MlQ3KZsKSrvg2W//rtjOsFRKXEizlid2GSYb2El 3vAO1fO9zeQfV7rPMxq5xz+F3M6NyffUNC1mkWqfea/fd/OVA4fqEn9MLxGhMeG2NCC/TGBB21Fw OtWRV/uzZsyYv85kcOYSex3/4YxUM83cM5Xxh1vUQ+Ei5JjHkKVmj6rV932wC0Md3cwel5Zlp/nl 8I3XMKpDU+ihOV4+9bqzo7B3N6/+FGQLOQjiWAzmOFQ5zPTPHAjfdZgD3+n9p+sauMq9fxtI68s5 PGoOX+j7PAfSUKKiH+lmO9hXLKwssx3YRls4eNh1BVs/NPGSP64IsnRu1wEmCF0Cb2H8/Gc/YKy9 InWIEDDEstejETd63I7yTM1ZSRzIhZNqIoeWy2+SRSH9QJqklI4Ik7sk4CNBT/fu2HiHpCynBJeb kCm+6x1lgkXjmvS5pqPnZbaBvvWcNI/geZWwK1rFTDqJGDWGQQbhEMBjVTj5uMXDHoCXwNmShVGX zwM4wElDoPOJQVelyPbjxronE3N1Cwl1n2A4wzT3z0xBsMPlMEHl+GdR5MxgLPu6IFYksCjC5YgI 9iQFGTa+Cd5ceztW6iWebIIvd+CxwuVX4Fji4/KfMUifS64LB3TEV1WRX24WSl6CfOEkcT4zfXVc Z2Cfz2qKuwTCEebJ/DjFBpFsjldNjwMHKZ+uUUZysLBZZVhHATbSir1A4PotocYlwtvxSNJ2VssY uYrkkquJT4f86Tpy39LCwRsgKl0HqHWBWPdkqTFSTPG7s9i/4qlpHlm1XRg4RrKA8vWo4fRw3C5B ES8Y5vsiLKmrfkJaVSHq1iE54cHN/DNd+EquO3uamV2kBY2VikWsPBxHIpnZuExCTCtC1CCg2C/c UGH0PffNV/FzZC1Xtd4MKwm1DfK7kaVuMb9GEWjb4yKys/B55MR0nbDbbsES8Prz2m6DhCFoEd1b tephIrlU9xDMfMZ6rJm+VtKn1F8Sg+qLUOB2fYnhL3KAj3v3+M0qiJZcg6YqFB26LodHL3K4nzFG 8IxWSjoj1LlmN71G8b7drYTICY9nqC/3oPB3k8dSuqMYwCSUlszPPW53rbSUjPB0OK1oEYXTQdng zOEHiE93r2CUhCkhfRI7RMJuAUHwOr+X2NKOgdvhlmZD3d6+YSOYJyXDAwBMAI7GeTlhXSkC2zHD i4g9hmmcz6AnkM1hsp2ItOpQ8TB0yD4Esaia50oGFyf+oRVP7zFwN88xkgTm2vFB4lfV454Uob0H VTIEOPZR+zro9eucvWQF6SS7Tne7yBDAy0UvAz3fwyVMaqbA8EqVUBCHhWIaHbGi+TGWj6jym9SB nE1S/bp3fd6PBOL3u539241Bv+P8kw7y+dO3d1zz6vY2gZZpTpsI0ok5GXFfLWERD4jUcgDstbe3 2OAYKpH0hTwW1jWu7VQPCaGnK7VieGziFuu+90VFd9e6OoYkJ7FYV7qrKt0k216oMhrC0AD8RZju ASXGFHxgus3x0zPmflhdaO91GmDxwCk+ZxsM3DkFTB13E9RBOabiceZQTG/m62pGZHsHBm8coLZ4 6STNfZ63Ne7HyTfc6MLnOeqB5gjx4ewb9Diz2wp0heO5Hp+iu/9+7s86eYiMxHZ4F98phHWeUwpM e/YLic05sQod3xE+CYlfr8Srwj7JUVH09TbPX8YWI6HNxFH6IfjhFFWiZSkunCO+a9Wu8+8LkjeS 2nXkCVNGxhCNe9bL16AcueON3y3uEew6BaRFPYN7D1Lgvpb7UsdnopS2dJmvJdS+6j941p77+U70 zvPq04dX7EXD+Wv4if2s6/tnYgCU7msQgSxRvvm3x3CBdHP0j0H0OhCD7X6aXLHrTjHs/VPr8e2q ZSCXqdIgizxSbq/zoP/snSxIufUHEh48yzivzHmEOaR1DPz4zrQpdESu6Ad1GFBd+RD0FDiNVKuf q0j56LjnqPBM+NstmRy96+LaNgZEWHcXH+7egYcvqBPKHlBwx37DLTEtKBydJ1an1Sdva6PJwdJn rL/n8r/fDcaMe74yjUkKnOkDH+ivVNXfKDqTAB1LHI5rSmN632WoZkxz+bxz3tFdfOjwEa1z3+lp QpV8Q/Zus5bEW7YlLYuS0EHhU2tYmFE7qnnnfbMTSvteE7i+j3vHBvFf4TOZTuYq1p2B+aavQcFC /QI6OGtqgnbK/a1fKrjXc2hTwxn9hVEbhlsykVdf+P5Xmu3r/sP60PscAC6t7a1yYptk+eCDW93f 23DyFZy2nLy+zSvz/Qvykfrn9hj8oTpn1sFaIxv9fWcy83XmF+it0vCH0jxpVRZk0xhcsfl8hhRb 1ZHolGpLl5dZYa0+9kiLqiNdemk+e+/OZmCUj5O94cC3m9P9aT639vrkTkHLo8+zmwaiDoPPjlfy UE2uW4P2YWP9wSCIOIWXmeTc1xr1zDxty/lcX8lfdIs7arnbZHtoApz99+RfdQzVv+6nOrgsBT5o qA+GoN8FBqI+9l7qfvve32Yj3FPM9Iyd1jsHY/fZSCmP9+Dcz13neuCys1e+VKJ3Em8aiG2zkS3S /4OW157azGv9Eggc4IILfS694igSnCfXkF70TcDqM73lB6F9zYrrOFIqCGADJMji61mkUiRsbwAv gaaOkAyORWVqIMSPSmeVdDoyHCkAeLQhudeEv0pHAVdIFheEf2fzxoAGy9YLwe6L5OX1DTJYz7hx Jia2y4FWMfY5uM65S9XhGHsT4ewAxxFyVNpnNG0ebhWA+wVwb+dnH1Tzu8HgqO9N/k9C26tJziGP WuCfv8LtGEFs8AJpLi48r3SBgkxi+0Fi92j40djrNf1+CXIcTiuK9duemZKA9yk0mmfObI7VCk0/ AFcvMrzQ8TbndHU6EO5BFYp0F0Q0j93gCkkM07UTeCuMB9IXQnCCBI5G4w1S+yo+TCVNfkY/mnIf pKSR+soGntbhEHg38VUSxlWnQ7E2nOIY9Nl3132Gzfthg+Qv4PZq4jYBeJO6a0hCXGAXrvlDxLoE 3JMU55aWRKN3yFV+Rh87t4K4XveVf69lulIaeN9n5JQN36UtIkf82nV3CW4Qr7NkizgyuWisQnL4 aIkc/f1dPoo+ACdyHOqYjA9H6cL1u504hTGL+wzrBPqRvsZ7XRXA7wTwDCCxV52wk11WnW0jldad 0yQSQAic4BhoCEc1+xAE9Xv8Q+Q6atfpStY5ai2iEGiYdYNfbpTXmdfPueUkcOrpfexZDyJeIRjw US/m7lOcaiavyROioUotKkxRL+lxIiRZnik1pYwLF3hzFYr6VXU46QmH0z2cV3JsNl3VXBl/+Olv rswM8KHXonGCOJjFVuwaqAcS3Ko2UKlieXvWgns9GmM4+TyrBQLuN/cBnRKvMPaO7EDKNYoOkcIS GTdSM7EYQY4adJ0SuhbNZz3jg3/qGbVnPFzTCFeoEK7sba5zqLDidCMn3uzVluBe1M0pzoMh+1Ed ZxK5NNXo6wyYU4B8SkdKO6utqc0lQZEOuegLF2FHqQ5OahEdBqI0h1DSpIDujwmgTve7+za47qJM RKyFSRlizNX28/V3haeOh6OyoF4RGgmQk24iGV3Yts9xjSN1kd9BNl4DovP8mudTrfthGQBoD51o nXdJMJGLchC4vokyPc/0d6w7pVAYhfxBLwLGVmt4oBCD9JHDYEx+26JCgZhU8T/vDibx4st9daZp KsmIXcf77btaGIueYz8GDoG6nf45o+a2obY73qwZV9nR9gbjjc17FNpeeOx/HaKIt8hj4hs/bve1 z9+q2yEaq6whnid8YtQ0LsBtXSlFMGJFBVHQda4OHigpyMQpsdCmkDOokUD6qddY8oI7SgVC/I0u GdYmuaO3uwB5OyEig7lzPcXZ2bPmOvPhY6pFxG6xVDru+bH7Xy67UiEW6YOLnDVuxbNbmYOHUZZW bbQXtxuXs8h0Z/090lTrMpeBekjTne46A8JdcN7WMVDr9Ww9+kwFPlMHJ3Anaxnd+BNPuYY/2Fjp c07qtFqhPm5vgVe23c/zFg0irz10jMbu+10gZ9r9M6NdU0xUx4DvPlnJHXZXlL3n5933Suyq4721 +8ZG/HDWMgp3Wx1/Y96V+1enGJNkXzrE91d1V+dAPTutTqf/9Xwewyjt0jj+Szc/UNWEvown72QZ O89Tne+6fSNxn0L3whTaLHbVlJgBFnuaLo6Zfu6qIyVjCxi3gQC9B509cgHH3u+BrOjpjEsu6j4v XWSuoB8x7c0iu6r8X6jqf/YaruqiZgU+yXfvL1fYP5/3/6ir/vq188ee8bd0Yh+V7e8br8x+lHfK rCMMqzSTh7oINofM6ujJSSBbbRA+a4e8V3ctxUkwYzjhOMB/ffbuXvxz/x5GK7vmYz57YneOW3XV ZiYNguNsz7t/pwjzWtJpzFhQi07DLq2hCtWVIptichranInD+XcNGMW0YbwY1UzG5f3iIoXGFKMm b8GDuKzUmekdNIBBffY+Vy/ju/y5aucdG5TxYJ4qU8IyhaLAXX3isJgMa9cr7RRPue3u39J9/XBc Ng7ICu1QWNCsIQQmjsAxYFiD3+zPcuuvtPgfPfIz8hOTUeu8aaV6mPfRcPTu5+dwCPFxX+8bLTxI tXYtcf55GznSMPIMXFagE5v2VSXXo6OaCapZ35p7RBuwg/ZpVfFcO6foKuAb6TS9htJ5IGgPKCg4 yIL9JmSytg71TEXmrNIDjWupX7o4DKMuKPU7NRImCL8jU5I0cb+Nko2mCfXAHLuBeAXvVG53memN s6JgVL4uGA7JRNt+T/9hJ2GfizSdDRRSFR2CB2q2edqUnX7ITZ4OjI/4b5PyhQddNiuK1jcPfiNI Uyvqa0a0MLxUVSe5V0h0JlhUSMIKp91nFBGTTdR8zUPjeqa7ObM3GJ4NYK1md4OJ5HA0I0Vy+MDQ SnbyjglcWm86pi63QL0WcVAhnbnWopSF6GdarmJa7toFG6Ds77M7znDIRfuknoCbIyRnO0qv6xej Ldb02iEK8nHJbuKpgpTZRCAfxNd0c4oK2CGaJgAdl90klDhWvrC4r9Nt+RJCUIFCUYlCD3lqjHIi mFM4CAKccMCOM/mdgnGRSCahuYsi3dZ0QVH8WdKmr8aRvHRSzKsFQhljleBcg8jCDzk8m/k7jnl9 D1Fb7zZV7LVPBU3vLAzRs13kxysAsiqEod9cHhOYS/Gv8DzRckje5wNPoicsRlOWAnCYQWbX763z 7Y7pRZIJhPXk1uKx7jnmKGsxnWDAT8oHgNDqDb6Xw7ev1cltFxNe+67XasS6I4ICkFMQ5ylYIpjg Pus/w2tJNHkITD/ufzorqFxXhS468c9VZ9JOJ4RyNVfxYMIVMb/vNRIFplNI/y0YqKs67pGraSXx ladYBho7L/BCh3Blg6pjOnqd6T7C4lK4L7x3CuujIwJ7wZkpGu6v+jG5vWIxhYNvefoJqb1PyyB0 o7tlQIYcqu5CGSlBqjNyM39Grf2fNUHcK+b+TyDAqJPkBnIvwByfJB+CiCYKLal2wxsTrY84S8xS IF/7naPhpjCTANG7j73OQPuWuAS1JKiBRGTzBHZGTa2C/aw4U7pTWFbvgjuEkp4uiYCh7yusMS7n uwsbUV3pawUuIxAVWr+TYEMBxRrOhMY7zkEo7vOri+t7Lyns2dfgkLg/R0FXSCTZ/fUWFdRBZOQe I9GZz7sv41L7vfAjHnVWnkPIeBhRSABwH7C4xj3f3rq5nrt9Hpd7kA/s7kFn64BWx80lPknUiDF2 eaxV48+UyaTds75TJPrMPbOHThg3VfQBtV2f4mR4+QC7YTqU/KYjkShdUr2GDPPMcgDrSdlM0fzs eVNuRWdsYqKMhYYkrgv7FZLsQ9oiEFqQA9QcxMohDBqlIxEBnbeZpqBHvtWvdzRdpre48ophJxL0 fcbZFcLQcZtA3LGAMXK8F06c0TbPGa66W9gsxJvpXIjaR3s42OeT2U5CtOL3np8JWdzZkUts3iU+ alwf1dR7/LxO11ZXT4Lokee5NdIBkqaT47k7bYYcYnsvzANwoOJUoelcOwk4xXD0/B7kIOrBs2R/ /MTZuyDC3zHRe9evnaG8JdPxy0ePUWO/zt52m07dNWSktynX9MbTXXeWH/3Py8ZKwDNcbOF08f+1 j1O0lgT4rMsEpPedzFWxdo1cHtUcWmcCicjhHomz36tznOZmsx5qZ5d3veMQg+QA9vX8DtpcCguW qjpHpD2wuNlbMfe00zp4mCGNKXLAhkRbrpmMPAf6OYmGPucleBjnvldfrqpIQ6Ja23Vw1iy9yR6O +eyrN/Ihivjp8yq5CSHXwkZQ6NirXlNk6tmFF9M3yHFGLb7Sp/rhzvvb6S+f9LVpdDbdQrXqhX3H 6UCdf7ATb/7GwY1O7ofe5zutdwwe2Y/rTfeTUa7MuZfqy7ucAkSy/9Pj9/LQXNt/Tp40LbSM/PQc XDeOG11uzOLVE7zCSORhQ8B/t0rWvglsHBDw442Nc6fqr6nqb+6ezI8aLquC9u4MfAcaeAnx1TSR y7NqYpB7nGUOVAuw0Bwy0+mBW5V3aDc86Och4p0jlSvfO/WZP0mkSkWPWtn7Eaax3eHbaKKO/pvY rZoGJaLB8pdq5rUqVS9B8bfB3flLciByYopCE79tgJAaGRcP7NbSjG3MhtQHlw6GTHcu7vf9lt+D z7VczeddnljL6pRESS8O9ZSXDmjNvo3UvcIzD2oob4OCuf/JLO9nGKQb5Q0zNK/3p+gBhCaLYIDg zT2vIdQiOxYDB/4Y2N6GRjvlPti0Lry/zlJFvV2QeV2YZZx3sgmbcA2OXyeOcWkKfHKNdD5c2Hby sDUSVrLig8HoXseaBjto9JaNISWua7atV2YETJMMyEwMI+LPUKN2IG+cEzkgViv5IU2aBRUY2wiw +YKRldgu+ZdRn6OXn7jOzfEJrE0Ng1ukde7nxuyLK+77n7rFPuThAvu+5Ot4eM7rz6WixIBVvhKM es0hMJS5OjBVIXuRw2YF/PPnu/0hweah6AUE+gvIQSgiVEdRBABUEBwsAXJMFhKQR0XwcjqpAjcp EnOo6jyEJmH7vek1SHkMInsvIIoPWcNi2+KU2fQKSYZ8n7Np+wXMDlG5c1a5ExrUcDL5ABH02hel w/mozsCywqJqxH5hbI8O0XB9iUe8m3qFy3/h7xsr8KcJEfpi1+HQuB3ytpM3udh/JskLmrEVr9X+ bMyoazb0dhZos1CZUeECMO4EjNdqsQv23tsj6psoNbz8bDhtGOibTrtJ5qRgZk6KX0KI+M9K8nw2 3xMEUxA3FZPm5LVBpOFbmP8ZnNjgrx9g12709QUWS+CnP2vXFc2lg/7bROh27KsR605kW7pf+yTl QVj9Z5aVY8joVtlihhXJaLhxJPD+rMfnqnAGppj0+TvmHUT1AgvLfxe+mIkF5KB5x0juidQrRl7g 9m4o5NOlOV12sr0YUb/YPLG3b3qMclz3JXZjbzotAQwMzUiDpNBwXL2+q+JsCxdbgmJXk/XTQIqa 7F2Ep5MHAZ1aMWF7oI9ES1WFrsV039xxtwlcE/HA7o4ZM+s1eT/OL9Wz/j0oRxw02d9xNynC2mQP j+16YNbYDjfy18gE1VN5b+6Ulqt603FWJI2eYEoOVcBnVx/U3PXh3oUCsb7AG8Aw9b+aSLFYZw6/ 0nCMFgBWAZ5tN7r5LPks74RMpg0keaHiunSsmbWH9+DrryGygjg6dhPhu2FE28ZzY/eMAr/12SeR r8w8qXUSvNwj2/WA8rT6s37nXb7fnECwwTfs8J2DodPVuseeEolAPVsSEjcpR2LaBHWMoO+ON57P Q2NAmIYxyQVx3j+TIL4dsq+kmBCuKodLp8iZiXGCde0KR6rs2C/nwly1JIPQcmR27Z61oFaYuMs9 1FaPzn2mY+Agg18RxgIs5nOkkhNjuvWuzCR0tdKKmdSzk7nFIUnQpCmEEaOZPX46DenAOuI21Xag uROceKBGX2uYWKe64mdrED33u/VxdtzGDx7EFt0NKZgU5En6lGiQA3NSXz02uzChRHWFxe/79kro 8Un91KNr9xI9LIzv6adEwy0Kl6Oql9/oNCUZgzrOQcRhlOBtGKIDo0o8hfCPl7Ath2FhjMRz4L27 BXXxHaW7XXHhOQAIPtuCv2uf7vDT1emiw8gdTDl4qh75ne71ux75YNd9/Sic31V1oq11ePXTAM12 dUtRg+BeFtS9UwDkPYQPEfK1cHlKHijsfZgQn8k804n+Z4ioagmlUoyhU0TmReZt0bAB39exklMW 7GK3PxKUxN4aNYfPNbsNA6o9k11TqZPiol77knU7LEUKjaKS/H4N/BmGBepAL+sgnONWVVpapZjW IHLfHFM6nFatntR14HyMSY1httrmHjA66uxNdd5ulIKsL1hgrqruBt95lGtAKzpHu9jVX3z+LxfC EOiIeDI80XLluKCvTOyXOF0jl2Kol6bxT+ET/pYwR/gWOS0r3TRFVm6F/+keyfz05juRz6tPyYTl /E/RX/8a4vrl5Ot3lfRjLBJ85ebDM1FsmgBdvXsKvqZjZ2JqHniVJycJ8hcHf7jv456izXU658Ne ZlSGdDxVHT3q5qa32GXWKAJ31DvpoNcM9hRAu9hkIVKTVn3Nw5psKDVdNMnx9iXK3AnSe/j4YkZI KKvzJBh71g5BrHDgrWC9C+u+6Wxdo6/I5wMViH0Oq13stQEFbr/nf6vSfzbwHU+sN5FHFneBoPkv q/TP7jvnhU8nXjSTczpOQXvdh5FVCtV5aGEOB24UlxI1Llx4uZb7PcBsFOnrSCNJDQ8LLpkviZph DZXe+QVkIpjDkpnQVEVDW44hBzImq6NL9SoodNwPBTXP/NR9ACe0EMpTLeXIOvopgaXbHGztvaJ0 c75eg87pP/725FVobZjXV7G0ME9n1ff0lov93IZ9hp99r+c5AOCzR9GjZ5k1+OZLt1s/raGdfrl+ umrVnwZu6eIGKwz1PoOArq3R/JxnfGdwsgCvAU4t3kpCHtZN93/ibDdPsVkSJR54Mr61+FwFb8Im gql/Er7jTKsydms6LE+/8W8T1+bsR4864gfbcz31KrW0J7ufvjD9nSi1XeJzaGWb+zn6+d2nIXOi b0OLcI46eXbHSamvJxIPIn7umOQ1fCSjZ104U2uJJ1Oc9DkUlRzMfv8fPpv5zuTkeOzw5i425/pS YFyIxqWjcKt/L0PKqV3T+nuRmuOLwfjT//5jAuZJuhrIJS1XR59uYy+JCgHdmuKViPm7dP+dlKzW sNxRZHX+1C0yzybMIO9j8DP9lLd4eFKas0zq0+0z7iHF+lUVU/6FMx0+yIDCC3/8aaUwo68VBYH2 ARUumWlG01dRTMUoGQ/nmh0N3AXVhvbiO1Cp4YpNU9R7LGA3Er3p+bg+XIXGFELtKZU5vWaIBRK0 oAnmCQTJSbhtAVGV63CFN8O2vwQX3VGBRwOIsKFJ7P4MVuSjFAV0utteE5Rm11xPN2yJQHutiA+3 QnU9OVVdgjudhNQtDEzBlr4KPLaDyUV5CveiiwWI7Lj2U/yvSOfPeoPpUL+aNzrFhQ3SHpKhdRZP 2hsEAUfDQ9CREgkQNoeD/z4HVF1oxcStj+/qBSw1h0zx+cDztPyOQ2Cke18XSuKEIUUOZ1cVup0j yOTDeTIH1aZLa9Y4sXs0i36OnXeQblvI+ZRq6Ljfvjol3M85nSzoXH2NmGxHdEHBXwChpnibIhup 3TYST23Nq6rCTTqqv/Hs+TwU1BmX48b+Hrvy9VlF8lSyD6GoHoRsv4NIGFUBvHXg+NNIGEUb97CD z2EwrefBvmfZEDpEjTVqokGkrLjEAf8ZBHwqFJCNFtMJoe5hO4fwker5jAhk1/9cgx0gyKjpAuGf VpzoTRGm0AGgLTO5xJFslZ8hzk41kQufAZQwkPPltUDRHSPMzsw/f8YJSyhi9z5kWY/5y++is14I MgTO033PoOv3K/ZyvxAXgis7RjUB+2NEbjkzjLQnXb25YO8WVvIp/NEAyZKQrEHe7/qKRt67W7GL XWWIQu219I5NJTJROyULBoE7eUGDfSziJSeDu5JkgBqlDbXdPdnRpZ4EzfjfqhjSdl0+3K8EtN1Z COpLfyFThKSy6ko+MQz2zqEYx89blZ0IWK1Hqlgtjwc9sKHBGiAWkISg64pzFvYbhhthCuq1hjRZ ODDPwBZXfoR0ehGKALBrO2b2NeZwFk2E0SPWs69PPLv8u079ffAf3EptBIEvuL5oj4So4kHieq/f PNPqqKxd1/PhPy8IbKah5Cs5zydsvhJhXEh2ibvN2hGoRrceHmSYtZaREtz1WYpOp+hvut/tmOcC DK8WLuSRAMcJcxXpnJjZod6bpNCpDiS7QiwiGEi/7iMVprBq/lT9xlAIIyfs2h9VIAxJ0KB2DeOQ 155jr7Vv42cbp5wDS9kfeLlS6UuiyE6dqC+EIhnaXLYO7NTtRyKcBw408AW/zqZ6uueiuYYv9qZi CGyj1L/OahVFp+tBjH0Ytj2ovwdVDRV8RmRnTzFFWyoSJe3T6lfvSxjGdlClLDeDIQUNddXCDPw4 1beYoaC3cwhAaf+0ql85yP/pDRKj2HstsQpKdNSRNJyjGGwEda1ipovJbZ9xoFnPcvlzIZHt5wuO ZbwLFOnc2vWyEyWs1kcTYf6BGtKpToET0qCtRl/I6Ci8O90MMdehBSlcc/UKKpyxszyFDl2YpZBf 38M+42zV2pF+JWqn66EXf6YllPwMw93mLT9p1VKcXaeQOJKoHfdUHya0r7M9GXke3tzc+UoMOgY5 +/14DZnvvvGDWWbvddf6k/vyeio7rXV/Dj8E+nkzPvAqrfOlP0e/nC1zX9TJHWzc7BgQVx9K4Sz0 nej2g/uugX1K6yQneYPJTQ0MoIInK3w30yRC4L7Z639/daUmLrdOhM1xvhKbvtn68c7+TlX93YFv tP00099JQ0L4hav+pCX656rqH9jYSw4n1IkZ7Jpii8xV9RBesa7lg1MoUhBcdTgUz57y7ouo226O 7PbinfwYu2BMsK8lRY15GarQueofkeFmf8gEJllOPZk7Mv0bolRkuLSQueS0tukO74utlTF2BXPR eBguGPHQK5nhxrsnUriT3rV4gtSfCPCX7MwEPAHgZGKlwZVP2M2PXtm6kXoO+2Am4BDjqMd9Qh3r 7qteHC5pQiqSijqOOE042Cxkn4tTq+RhLLbxTV019OoRpsATnk03EbSxh5iDNh6atEhqPJJgsNvQ kYi1+trCPlaHt/XHsIDTxaki3GkdpLoRsmuFnfbWThjQfTJgET40Oqt2Fyasi2Z9KlWktGxMbBu8 BNqiWmvZ0NfoxELulIfknpNH+tRvM8Fup7zBmKzz/ExDmmRZU5sgwFJ7Lb+M3VRf65Uc7FIhdYvG htS31zNxpPc87kLxxV+TSUgdDHyluuJIPsmeRmGwMO/dXc/G0I9Xzexp5jdTBroWgZQsFeJ3LWH9 H/Ulul4nPDDfls0bYG/v3fx5/ZYeCXo7jfNx9QP4U2x5bAB/uRyFcYj9gL+jpo62xuSaZ5zq7XFm 1X4vPS/3G2gdPhSXQdEZ9WyKBSQYEwQ4I6grXqRNPmmBta4DXBW4vTkI5Q84mhNdhWFm0xnYR4HG B9EKuFgiymE8dO6Ptj1Fjcu8CLsD4hRaMz05G0Zu2jYo3992RvQ0EE0kczPu4+lgoJM8rYOMykhV rQZhDxgUxm8Imus9WfTrIiFwooujVXtvapGHBE0VykUujzT6vCHiMpEUCRNEo2gG5+kccew11bfp agFQ+Us4tJ8vubzmxNe8bHkS12ty8j7tO8GSq3Gfdgogz3BeOYiC15stdDDcRQPGdGKKCYGUOz6L 7rGdvrH2mWeDtoV+JOkvEOZGnLuEgOdsZ4jQvZwMWBCk4klAxT1ZIWjesaV0b9DIivEz6ekvwg5c DjFY1lzrZLNPQJzjHHcyRA5tbaHzVUIbBVZOB2fnUM0m6e8BN50Q3xz+KKxtqMVXuGDVkdQwwXoC W/ak+JXpk8kYy5FN2dR+ovTqK9Fa2ufAlsS1wTaTRIpixV7tb9apF5TS3ZMVLmHQ0ir3t9Zk9QZO 1Zxos8EzCifsglv7tbp9tK1bsL1r2HYOCZ6r8oywuUbWihwMSkK3CDAHZPuw1BSwjJjGPvh0JC1s AksnEN/ctZR3SAjg9amLFSCHjwDtKY7wKebwILFz7+/zXQfAJSQeA6p3Aoa7Jie3/Rz+8DNppw+R /PQa3qRr9scpEvVRjyT45QUg/gykh7Bf6CyqfTMahASuB2Q0M9IETicCQffH4cEfkZw9nGG6KLIn tQgq9TtuV0hnZK2zyWHjeyHi9Z1WsGuKqyPbLm3sBP6iG+jvjCEoe52/dbv7h4CGRYzbHEBXBSlh rXhlNgww1rsDVZGrD38hfQgEdGedd6qRaHqLEnQgGRzXq0ePSoNr1OVVc5MtqCFU24XnF+CpdlEp 7pXl7rucLWd07BL9iijpWgJqJuIEEaM3PeSjm9+D8BcBM3vcrFl5Lfg1FBZDGNCZnI5pV5VswCQY S409qSSrb3sUgbMV7UwSlqVrtoIcFpIswyk2bhMmAhVELJ00xn4346enwJXO43m2+yDmwaUQhSM+ blCdTt2fz3jnvSAh9Iih3QMNfXhQ6IR2U/GdGOkE43R5FK7uiQtQTkvB4JOxWyTRCA+m7h5+ivMY u39Ib0yohiLPk95DmqSwW9iobMSrqJbTtKoPzZG75D4nc9CHBcoKjGqT/mx4ofE9p5nDrCM0DHC2 NEXHOMGBuT+cwQtF85sr4efMI4i6KzHfAhnOqBL0JfUzsDfwsOgdSU44HbIZJdeJUicOS32nYI0r sPt61OFaIrlCA6VMujJg459z7TLzutz1V53qTDnT+veX67cjscPJVUpFg0vznlt8gdJJmwUwHoNv meZ3DeYUYlHCrFZ9sXhwkuyH/L4WKvwRDrbaNQw5Fr4Z7ydzbrQq507kG+PmBTeqFwasrxY3Y5UP Q6LFe4E45vPebxukzrW44XlGPnlbwHENs4fWtU6UWxDIKFGeoF7CDNV7SL3wjql1E28DCXbUXVW6 En10bfGU4BR5DMjrXatxNyNYh5vz4TNrGypug6nklLXMT3Ztv4YCBAOIpuqQ61TiQKvIyX7z7+15 q85KuJ+TeKJr3fnK1O2fRCOoTClFsv3evx2rotfIquLUcbitPbQtf1lVfxOZVWVdU4vH4PXiwJsL +Kd6VsR7OCfr8BuLbvsOhjLYvmglRapWQorQbZ540/38eAT3SnG59DkuMlbZ+6trCJKP1Jf+Xi8F Rwz56NBb3ULznXALOU6ad5RAK9TF+N1E8ho5n8lBl9GVU5sRBoV+tG98WvfeBPIZB/8i2IPGXmCn 6SSnkXwg7aMpflarhThfrXAt7h6s/7yxei8TsyLdyzQe+FVvhHZBqf25MHUf+GJqDI4zz6m10OIi +Ilto+Ge1reMKrTsBpaxyZWDKeTuwIr4qcHL9a5j7xWu1vdpV1VgwFyrjs6BZ4WOwpAwnmgIG8td 6VfXvWvmQ4uE+JuXp7PLZ0/SB3f4bq24U3Nt3bquOgx5No4Q9Zs4HYWNhG+cvfclybkoTEaCE+ln qbj2/4au7Vs6U4GFOUc+b06BFmSbj9SRdrYHsm+Mh9LQ8xlW1dOIi9Ju57BQ9eE8df3FxBRGD9I1 O6abzDlYtJOpvfnpP/3ZP8ZDkFAAMp2kwTVGCewDdDIOXh8N2W7844CFDUbxvoJgbsNB/3GBv0md DQBeC5f/2XTZq/WiTpdiMVWWszLf3aq0NkvGIfgA1DbxVlHavyZdkzp0iEqkCkfI6XqeIhwSovpw LtvfmSErEldolYSXG+Akx3x4XW2gxgEICNezD0BG6JtZIXl/F+9bMKLRNI3YeglIV0OjWgAgV2HM qV0kl3a01EzOs/yhgXKruMuTZp1pmsDWduCcjnMVRLueYOxuOrKJ30C9F0Ggo0D0cE65PtMt/p1A dgXgSw766Q9kFMfvkrQXGNvl2/F21Ka1WOQxL02vpu0iDDZAOgvePQyD7pu78VSte21G8PXVlMKN nJLL6NF0D7Sp0dMJMdT573VM0e6Ughp3hk9x2SQy91Bbdyjga8vY6hSC68bvmEMrTFR9ABGDY62A 5NMgz3LKd57OLP6/nGDmyU1ZMYNI1SQPwzdY9SRdwzPUnzvsE2epiN++I9FhaGtErd3krq7GqZOj 2uL9eW6KgMbV2CWZysASOeNTBfp5Ph1UTT/M8xUEKWDY41z7djeWwun+KXKgOPAtRv2ZIF/C1xRB 8dCJAB7V6eqXTswdMJsAhuvtlLod/oggy/Oe7lqqWQkmrOE6vYE4QxPt0yWjA1ME0E6RdzUyKGGH VyDph8SuNthg7Hd2yg6J5W63PmNA5kx5Wf2Zl9PWHkp1DcekvcO8BrHqIPQH2daemRZR1F2HU5pR T/KrDnCqDipS4nrFB0lQayi8UNxu/Cmzxq1B3ArIpg7mZQ3kg9i8EkI+4vo+f5ORzwXiug8RGH2W tEB7FvroOJFdXC/UIu67k/V2SppDxdsVyEfdvvoM+0F6GAEi7pXYETcJo/VnlZIHA8nkIGwEooPV J3bfDW/HsUlc9++Jzije+/rj3urVa1ykrWGN9udNg1teQq7uvGJ0JEusZJKeBgJ/yUhMMpT3OIHr GNAPILBCgMB1yCXQO1xuQtzBEa9hchHE8EZRVBwHfN3dXYBHFUg6LyVgX1GH3GKWK33SkcDmJ/G3 arYz1ec1JJ/iFkX6351OdtdYU+iVg3fpIOvDNMK/RfjWWUv7uC9MKZGeIrHuyk6DspT8sTG8nfHE A5K7x6LetQ5PwyRh+/fTk4AhGc/t2eXYJ/4N6ULOkJKDvgHzu4xSfp59dafNOjHMYZyxnW81exit ekEo/vC4z7YD66i1zDLj+rqvjKL1HJzUF0Meo1j/ZQpTeJNoDbWvqx161RTh5N0QK7rXFypAVwjb 2nVS3s+bt5pJnFx/79pn1lbXMEvWOJdE28cbC/mC/fg7yEJVQepn/E2viG1frmleBjIbw8zkPh93 6xzgAs5MHFAvlHW8BjB4SHtGehvPATRjegrYu/i0/bNIyc00BEVi3EYRU5hzn+gCJ+MrLaJQiLFd l0ctuVzWPri7H3dARR33GuGrYBFVc4inAv8i7CmEYBvRNBuspQDtcxA52LTLmVoh+3w/oHRY372m joyssf5No16vLDXq5zYPdQ9WfPik5sK9ap4hJEXDOy22yEvMUAvvTjw/E8aXAFkFCbTp/uyqEFBv TM/Yb2RqhLE/1tETkMTPw+Rjj84xX7zdRyf2QAIzhxOijv6fHBorbOEM/bG/GhCte1Wr9hPJwHSa L17PV4Db9wGMFxZD+JiOz+Dj9JsKl/ZufOfIqyi5bb4fhditYCDHILIMzPs/qar/OXoAEbe+RYCe q9g1+CVJf7XK/2KKuX32djmsQCiqQnSq4uH03XdeY1DT3K2GC3OuU7pXdWKM2GX5drPu/OPPJ/dd r9cYZpn3to4ezPEuiSE78M/y43YRGMAY+E1lLeQ+4HZJqX3gPbWSvKimKLQqSw5zf192qp6O4HRe ZH/4qben1uMHc6JE2CPBPDH+z8/PnHhB7qSwIgFVznSBlsJOcq6jhv0p+w8dJji1dFDTEb1xqySw 1+wZvYCLbdqhEM2yuUyKTL852BvPnW/u9by3FOfLXuGoeDKIPY+k94ltC9JnBRpN5tR0Dhpcw8Ev TMlNgzT3yYU/6Ugv0OjNtrYm+7V8bnp8z71G5mC7V88YNmimHS5In3bUd1xb1uDytPinOrvCbfS1 azafHcw2Wdy22BO3n9+ZsLaJf+TQnmH4bHMuwcWJkGZKdqjoxy9Uuc4u642pTmNcN+O09ztMc1aB c//U+LAWdxlXRs2YPY1jDmu/ewd/Nn++wrhaMCjJLFTNRLtYF/c+0NII9Tf6R0V8G5Q0ul7uAgU6 Ueb0F9ASgF1FQyeWXTuCkC6qGhE0DNWbHW2k8YB6LDGBnAlkrQAGG5akEeDgIyhJoY/bo09qc4qV 50WxpzM5Ao4mJ3nqSpXO9FjQHK6Ygon1Lmzv/97R5NajdMonX96u5NNlOVyEPQ+CdAtQ6gIaYSoQ jXYXk08BmE2lYHWTA/0EB7N5VD2m1COONadjTq6utuCfgVZKK1j+TzWn9oUCA1eVfsM5LSIMlSQQ 7bEXWPjzLj1BdAIGfO5lauCXCFvtAh9N9xTKbVc3D9dfcpNOR/kLbBlAYqROUDiOj3U6nYg83Eq1 GrQ8PylCNxxOsVymcGMtVxPXdl8Q7uM6KJgF+muTQLPJuQZoukMU/2atUkD4T/cU96scuwo0ciqa Ilf4U/3OUNUtqLvim6boPJvZJJYITpxwaHrZbLcLDm3mJjUAQm+XmPk9Pnf+JV6vEJjcDpsX+AHN l/vkvMOLniBjnSFJam48syhGp+mISasT0L2cUue/A9d4F7rvUhXADoocqV2+gsLX6WkXu+0WEi3b OcQHbJ/rk8nqHslk19MfqP9Mo1je4Tr3864vcqeDl6L49ouAv8hRiLakdaUF3CkHpQrFHS+nQxqw 9XAkZ3JeX2oFz6G+xjD2gbiTAPWsy66J/S7I65+NJY808OApnGqReDScQF6XNJimA/TVU/rO4qGM 0uakJC3C0uPfa5Cv7DxcTzBkisj86LtmfcWur5dIcwqA6wt9nW4URIpsom/2hPeAq3+jQsg+eDtq O5JEbmOrnxjvMwEy6J/z6XgJCTJWL/sBgWtRQb+px31+5SPs/XA5TWZP70XgXHV47nE3/H/HoadX 0r5/9zCnsJ/ffaFCTOExyDKGg1ttqRAc7CGUqi0Ej1WhyqFEcY5UIUbB/uW9NycnFenttJOEVy3h Da3gHMQZ4766EkKunvNBa2mvzfYslCTHrAF/h/T1AfZmnbEdDX+eoEkKQD6+XgN5jBtNUUlFz7PJ HEd/V4C3zHvFJyHMiT4TRtrrRojv7Vs6EA1PBKjXFEfO38IiKL52EkOfRItde6sJVnwiOILKcPfh O/L6JiQSUx5d4SJE594lWlyxpueAV8cRjUlHt9hg117C1A8dXRuS/ViVXENr39ABjUHX29HxJdzR dPUJkUPiWHmebVOB7Sa2U3u2qHOKgWZix6tG5vD5D0G+jUg+e2Ynp5JwyWea6mXg4+gZSai8/5Mf tbxhaJvc7gi1YBdgcjzmPnw7/11nAdem3zPEgt7bwkSIzP41pD4xfwXpuH/Tdtb/eUqusfd0Ch8X LwWCl1nbz9U8zQjq4F3czDc87sBaOKYXnrwHMA2YyhRrsbHQxhSmuLWwvlOkSuohkRDcuANID3He lSZdQCynAIhSOxJ/9TG49aqpz5h7aaVQa2GvOaCo+LmU0uUlTLt2L2H/v5OqSf7iWX0b+5/W72q6 7u30FwPHPGqSRaj7SD2ZQyfznOTueAmpAtE19ov+gvneowHpgveSAC0/eMDAbm/BQsGXK8XN0P1K AyPvTyik5aI11V0Zt4DOmEBTj1t0+ZqGIJx6QhcZILGBGXHfd7Jupm5XZZ69DjE1S162YzUzJr8G gHJIQCCs2TzdPL84/VfAnbB4rw/W+UDW75TeCgOafu7e8sJ52uIw1MnlXq6rs+csV2HehKhH+TgY C6RAez/d98n8Lnt4rqd1qerfrfLf7+ccD5FPgz9KYpqGJFVV9Y9X1b/Gldl1z131rODuWjtMZJ6j KhAeEhKxU+Y7Hu+QmTVjtvHcIHEREPLsO/abXvJ81cFzmXn4YXiV/LRiCE1UNZ111jSVAU4bztzE G4T8ChneFWBAu/5RVWh4GIOqk1PxwmcM9783rhA90rxn4s/67klwQNp0J/ispRK50MAwabDJlXZN pAaow8XfeL4vAxOxpjDWnoOFrnuAgAah/fPY+vB6omP5rgowhaoKvhUNm6IvUrGRUUrWve6rNE3y sY4retpZ56aoW0dP1jU+43n5wsFVLLtXpcD/Nvu964PN7e1nJzQjJoxwp8K78nw04DJ6JlVQvVhR +XAvNw1VhInfyWPRvtv2cRX9DnNM/QzXgYHPes+xnrdubSaJhRIWPpe4kwqzJiPCnVrDT+f1qSXT XJVVP6mdmrrMvAMNONs8wKnPWmtWhGh5caAvW2/BGxSkC+at7qIkvu1APzHPaf46cQ/hT9dDD5KJ FNS7parO0IcK6vKVFNXOmD/yUG6bwvPF9lg5gYh7Ri4J6MmcxN4/43RtOaiSAadISD5mLG9BE69m n58OEw6v7F1i6wS/VDNmoSBm0FU4j8iuLFdLvxvlLQIzCn+EYtYtUJnAap/wp1byT+6MDJg64lry sByOsOEGtp3WfQPvSkA5iUwvUEUxTcwArOFNOL0hlS72Gf2WhOd0qLwkHlfhOQtCDYEJxbCAuGPY QsB308uJxIdb0gWkfpqXX/99ieg22EBZA78TtXQVXxmxoVHEbzI+i+VbBsjAfQd4hWefQbpyOdrp cJy7J9waOSpBgzIFWUIi1xgX+HHZaSWrQtW0TkEfcT1EAjP8PIV9OkmFayyqwn3ycl4WxrcL1xRF AxqFHDqIES3hjJaIaLcW7ESrIsrHg+TfAMSLYK3zKVKjO12Ene/ey73JhcDQmFw3E+bbcdgxIbtr lN0UddeFwiJtOrz6dH1MJ7CCOqrqcqSIc0bVBF+KZvTbgEuCZtmwJ60Ebi3qd0vBqnLEqzr2Tgq9 psDd0cDuItwEuNSMyNVyWSVnn+kCQGFWPFwjdI0gADR3X97jNaeAVbg2KGNDQJC5ahELwrylvpeI nlc0PsL9FjXqGKYypN/MumEOSRF0vs5wGwmuqAZ8n/PzueQApIfQB+5YL9GW5tAQxgGr6nIXvSIe C4iHwsFcEgDXl4Y0RxEug5nh5kqVBboA07DBBbJruM6np59g9xslGdTH+YpHq0KX30tkMffGIvNO gfYivMoI3gn2e3dIl756rcY6TiHr7e4mcA6iu6BH0M9aNl3KSPjZhUKjz4zawgiWB+zhvbYmkf2r P2XBrh+Cgu8eulsuJ3CcJwnETnK5XSamQ76XkFA1HUv9jOnON0/30Ca6p/D2Q7h+HM9B+Bm3pQLJ sevhJkWjPSzrcPTGPiqStff1rdK90kwmYB2DdJr1zjZ80LNOo3EPHZ9zCmtJrlzoICNEpYS/nfpN J5HoG8b0cvEZn1o3BLpF7hu/1BNI9VehaSZEsQDhykDZe5P2bq/XfWAn6O7uDRZP8U8IoVTficZF dHCVssT+0kGYLwwDzqftdihCcnWfp1Wv0bMUNjBGSkQqk+Mk6u4DzlUcoF41ncbJJYqH0HV8xpB6 tOFMLyz0yi3h4Tg/0AATqhK4fYrXqUZ+C+zmQJ5jX7PoYdd8RBIqatmsXVjCMak7VUq/6Ry6zV84 Wr2AtqI7qw8hGNc6i7Qq6ox1DinvrP0sUiBC7sR3muDY/9JxPjpIe67qs3PedXF8d4Ho+tczVdUe WP3Zu1LaDtgcKw7pLYQWvG2PdAgFamAgQnJbwFkwNUo47eQ8fCZJ3tHlPvk1D6dIoYP1JqR7wmCt bMTPgEIKUBR7zeM8tpnpStyZqi5xzbCiuq8I8b1eksMi5+rdnyrcyHeCkRbuZESspqB7rF9zYiZj 4I6ko4mnuAqC1f3orjcuiakHXiiOr75Bj+5t1tH9bn+NuMd5az/Os+Ss7/SjQnfOOoxRLve+LVjp Qg1BGkLidcS93R6hfYhWUJNt3J2zP/dXSeHaxJv64CXjJGzxxnXSdlaf2A73x2RKNIZmXYdjahUn QOngkFb3BNxwVvQK6FhPlmahQjrZyqMzVSg40vRMQy+i0ES8Bm8EPfy84xVY9FHHiPc1pW9TgpaX 2aFK6DLNfExLQtCWGhKuWItLoD56fY+R0lgl6X+v0n9eJWvhEcEGml13Z8JCDNv/U1X6i2Bvv6RQ pDuyQmtDhly7Yu51mSARVDDEMHkOjzV0jlaqQmvzSij+2augjNu4h4/770oKi30eWgXCegq1NAXr vlZydNeH5alHWMgrhVdvdlLvbn9DS3muzqouE4F9noXG6oRd8fkWddacg5tc/YY35OXAXvGsktCg qkT1dxobbSziGrYMg81452kuwCZtWvV7H4zzwVqryPho1wdxr5t7KR41FZFbUD0ujtOTe0xW0cGP DfGmiHlbXfjSPgyMTlcl7QPfz+TWXbf8DEOr4uz0ye/tFKUHdueX+QxVsr1eYO6izr5/Gg937Y0A D/YSWvPZwzV/cv0+UD7XTkxpQo4j2QGS2LaLtymRlRIwCH3Yd1v+ntefr1oieefJSao2rX7SRydP fZchFasnpygE3KmJ0PpsadirSLrf+L2GGZFhYHThZK5HrnTycPedVssV3VEfh2bFiTSxpoDuXR8J 25/3PRNMFEmHY9DEdy+bK2KfZPlvFdrZWQf+8RETTADdI07O6xKDcgzi5XZrmVFXqnSW0nnVMiSl x3KZoinjvO4V9+WIKhaKA+oBYs+NleFfSZYYRcE6frZBCrFFmfT33xfjjiJWOPhNQYIhlvpPEz+1 CP9aDs8MDBnWUQQf+CI3JsigiIGpk2JI146cUKrH4ftzOHpOT87ioIoE2hqgpFek9j6jPhNuiojR CVd0oN5Q9PhYC53Q9HJRekUiFTosH56HcWbox8EDtNB1Ox0LyNQppgjixnXspBrNXA5BuDntZkFL 4ouMkJsOqVRMaxGE5LybhDm5M7ycEhxgeAJDPgXivYmjhmQOPq3CUjcMTS1mTg/rCZDTNLNWkd4l A7drUU5iU3vy2etToJcEcD1/VoKxRMP+eYrZE9A1OPcYJYKuCurBJy3z9he/PH44daVGs20cCNjB Cf3uJD8+e7u1saAzm3kjuT17TB/JEkLRzV3DTIfBnfzC7n2vO8dPp+jbH5haF8F78OFAdYkbZq3g JfTOc3lOBNu7UdxeTNNNkb6aDiBbX32LX/9uEeT28R4E70yr0bsTTEgs4+Zor3A7YL8Bw/tyH2LC d5XuJVXfBlzuWMl0ogMBuOoY6VpzvxLu631X7vjnTX7tYdg1UnFMubsw8UqzT8hJ6HlHCXJ2VL8z QkFiMgVgWEhGgzgg3PoYEGXSbTpDdYCBQVI/UqgEAOgU24xnqy9Uq1fn6c+QhI+bqa9zdmsiR879 zOnMZHnL+33SkZbpYXG+6OzgUPzfAS8Goqj+aGew6uyget/3AnI2NjCEZJr1lopcFxeQ7oo1uZ93 9HmevyPiBQ/6haQPvplT6Ot/j2LQU3QwB/P7s99eJdONuBPf1KNNsbCx6jPGtP/04lIDEOc7IFkc RdvOvm9JPjwdHQTEcSICOZikcPSvoG3qcRbcAoF7EH6nVg0cAAfvfPaqW7ZuMxXmmsNIedK9vo8P jERnv0UYQh29sYZzLiURJkm34fEKvKuAkCLqmUUrLG2/7DamkGznpnRhZY4R5Grb918BSP4LU5tu vlqY3MYQktyPSs5VO0FuE2sJTBsJGEHcIY1P8ZlYQRB8+movwTHU8K5i04Il7XJiLqcLpxij7Oub b1qjUHD3aGS4kK6MrtvxMAVj3DMK64b6iY/vzo/CuiBP87n/ujtTF4R4DJrv89pzUBUxzaz3feyh QkeoivdsEkjXToatIzFpjwzdLmzGrp7c0i47EHrXde45FednbB+weQ7M88yHaYmAB3F02Ppyf3QT HAUBVl++of26c1by5s/9metI529xuJzVl/c/V0uarVAtRNi5VxT9r1po15g+8BhHisg6gVxVkDbZ zZ22wIx6dEfPpnAc7hwId0PfDFhquHkHXydOIPGBqe579FWz13lHGbHbYYrgfXd6rMNde08ewMfu NdpuoRPlPoeclVsfHN89dOeNCs56AwG+hQPzbN9pmLfDZT0wyw8GoLhrPhwvD2T4GHm/5Yy10g4p 8dEw5FKRYOzDkXh0VL7OGZ9dpY+boyeQjkFi3Qh+1nN7eOKIid8uz6vX9kskBPiCT4FFe1NawmMJ E41dPu57OEddA5Ou01VTwa1MvNZ4z02BzKtvVOB0u/vWcoa8uBcNE4U6+0lD6lthN7XrAFp/hO/l d0vP/F3Hv/iPAkzVVV+SbpLfb2sGxIQed5vOWohuGNrKu8qc9RdpX9Lnl4zMVDPNa985bf3+7ar6 v2igtwtvp/h011sbC//5339RVf9qdbOLhrG66RXSWMNf3m0t930XDVrt1kbwZxTmE/sWSJO1whMN mFIb15yagSaZibgo0Tz7j2mUkL0PGez56EhFOiJXYID7XXTjOMq2M9SIftbdVwoOOHd7nZO+uOwu BhZisGzvkTxV4PROV3zjDa81KL/G3EXJQPv5GLDPpW9CUzca68sR7EjlO2qwt/nLVcvfP21gJ5r7 /XOGJQZJqRB+5SWr3eWmDBZBlyrsnPlZfvbBxNmXEUXKXaoONtBkOLhN9g5ObQ7tXI7qjv9LS0eU acgbb3es41opUzlsl5xF9it11lt1WCZvIxVBzdprQx91V8edyWbA1CO5/z4vToPMJHxi4LMPr6JB ET1XYh/YN/INOtLvXJzaM7iys5/eBoRHH4945GXFKLwj46xxJT6oqxfWgQcyY8IM1PVu9rnPSY79 Pe2hbV9npe/B1DS62bgq4GX6Zq5yIJguqPpdWwqzE2/3sErH/D5DrnWgYYp6O2qcg3tNc+n65eie E54cXaI4WPOam5epsaRYwIkzVppppTqEGOkeMdp/ezjgJlCTPs+uGZ+ptfkLpjF7M+gDpAjXXD0o fe8CwSBrv6YmGZRS1Sn9KLjAL48YV43pV0GhO8Afd5FBYSFeSL4eU3m6xWk/Ex2aDeV+cjpEIv2Q +KybM8h0NJr90J8T5t1txUC+eDkOz+N6C9W6Y34dV9UWu2TMFL1dBQChk6qsLwXwbA5/ioC42IV7 V19A6LymnA0CRHlea24MbOg6esX+v9KjsCEvKyFpd0m6CJTkSWqdDnsJDOmQKuSQiYesn6a4/aVw +D6QxJI5AoC0APUEr/xFkEQx9PX18z0cq5SiqZl6UStJ4tUabufbjBj7nIFeju7pqKEnZbsLLw9w QwlzrSZRC9xKWhejI/H7ptjS42d0klbQIMz3vJ2pO5D9EXBw/aKg73ySEIL2oXD3T+Fvd6N/UgK+ potn6smoL7zdqbeMh+IF79OOITTXnBTd0fJ5N3kNDm2RY51OaO1O789b+d5qOWyxt3MBedEcK7zJ SjfggSi7asU/OB0jGFYId6z8wrVHm+OW/aiZDavYeDcpRPwfwN4HwVawpss1AORIy3nec9P5a6Y6 PIYinffNr3VCjqTzvNxnEjsvzrrMhwvD4fSGohsvceJVl7swpaifabqdVdPljUTE9SC4tljhg9pd gH8N4cUFiHoJUB39Tt5ZAvJYi5Sv6jGzpbt9ju8YsY6OmupnsEzCrsNPyJf/FCUHTedC7g49zqx0 L9oikwtMmAIIr9hOHf3l9d4rRGJ1rLOLNmIH8nRJ6KTcfH4pQqzlbC7dHca+M326OW7g9vJN9yJ6 73qZcIsJEPlcxVzHV70GrvxwDU7/Vy2K0QAqXSOxxaTTEQMs6h1rOnImGe41Da4lQoE7SNmd+SAL uFMi4UQOOXczgxRC19FjtGeqOmqoeQdQspRHbaWGaXBNsv9b0U+yeyFbQvSvRH2ZDoA8V1O6w+eQ hs+UMG3ftrrMBi4RFBMXPlAhNgNIowEDuasiQZ1HVHEt164usE+yuYIomzfXNFTwwB8FpicFlKrh fsvnvym2hs8e7knsjtsJUe4Dp2lB29suIAs3rq1lQKKTsPXmA9aWEvbZftRGmQIxhbeFwgUivBMb ddyhnSDSuhuFhMjEHHJAikiKef6mqEFjXfvp1jUdi2/ZZy0ihJyAsleaLpt6dPTT1SmHeXYU8naQ AiGx865ht+xC0tCIR1BdeQs6UkA216+hz6dB+EzQ6qlXWrhO1Rx6vIZEt2Og65sJUH5XTq7LBEeF CGUm/LFIkWqdvVK7GC48zrRde5PA1sF9CSu/PB/fY5UV/fU0fZkMgbB6aziN9kA5DTcnduGweGHx 2k6gnPKjS4S6BwknmZv9gC9EqmoNnWkkByruMq/v9uESydX4jlvvPNdMi5638XTdm/XgFF9Rj16Q PqVwV6PaPQduFDkbqguDvyRb7f2b0MlbLv3a91T3Gs6XQquowtpApxkFM+GljYPfPNe39NTeD2Bv 7WC7fnr+LU54CkuBb6asvVibNj4VHd9T4PP4GaTZZmQ+R6tnIiP1RwW9NmNb/VwhI5uKRNLXiQsi FlWYTG0tgqI/OjjZdbZxahlgn74FKGyEZODWvVJyia1c/ZFOJLLYlHANWJjxMjKI8TqXVVpO8y5y Yt4c1KxlbzfUjtsa1QezTjZkTXkl3ozhPlUd6Wt/p8r/X+KqHjVVpNjq4mKHZuGvqvTXqd7qYsr+ sfTkpR3rYXNXlOKggT8asYHdBVy6o40Bsdxynhvb3OxKCRs9sSuGA66UKzawXDoOe7lFX1jHvjOI CxH3jXbwIbXP3M0ZPDj23XOlXqbO6JcXk/5J+5g1OOfX8nBw5zF/Eng8E2F//pYrzqHbTKcqk3bq 6DlBVBxi91QxToMPqgtTS+FH/WviTr1PWEFCsqEO9zLObIkw0nlC8GfjlN0PN1BnvXThoB4vc6dN 1HFeMf/Dpp1Tp0BmkcJESWbH59COszJ2miCWCwauCOt/MxeRMuWbVSS59+ZbdorzxK33mUU3rR+1 81WPKQxE1DjtbUgzdQjtPtT28dVPogenPm2NBxsxUscSfNjqTW4PdIUNayFum9hlOIeHce8cbnsl YjswbuZK0cRU2ZeB2nLqgkKnoscgcdU7Sb0OzofE+Vl/V20zpgoTlsu883PP11HjaGiYby90RU+4 BeSbdlG8Ax3J7u+8k7vn5xrLyOulOo0wOZf/JHRPwQ8TWelm09yKlJOXfZp5PGa72N2Onaa83BOq KIrontL7uD8QtSQEJ6uuaEkvAfj8A0l8XBL9PXWpmNTdk3/U7OkAawwbjiJhX/G4fnja0uLTMZrQ BWIxoQabmCa1d3SX0Mm4RnHBRRNBwUJy7uMWsMHXHcm53SFJmOjKGEEdVLoX/QKuz5oOqt+lDnPC 36PQ8CIkDO9hRnPMGAqQ/UCR3Yk7n2soCxoCBHZkWV4wAG10UFkJgWx5rxe5xxc/l3696d4OYiom 7XLP3STplUZRhzdMPcq++XMdZPLnfWhczFkA3C46IU4unpSseObXeqziKHoS6jCQv51RnFT/0Xxe A156Fth6FlRazQS4YJiCcTTXGpa6ovYLzhKiSlKCQuLdKf5zsVvo62b1Ia3edcUWtvsQ1czm7yMa m8Vbxr9VkUuIDUSTG2HpTOXooJKhzhFMopJgbhNmBbP88SylaAOykkky8WrGqJYoJ5lG635PFlPg dEJV2SrR4JqwVl3x2yiMK3ze6qki614XjI2ET6/AG9wujrytA6hRgsqap7TE+4Aj4WdUVDoiOMBO coBneKcCMOez5iJtG9jZnbzFtRS5sRqIPkfqQqs4sTY3wcb7lB1/T2ePVEc93M8mHXS26ARc5xiL XNihYpN0+/xx1eE6uhtzZyZDgJ3s6Cie3deiHETg4xZSPxxkocn2w/dqJAf0/alZV9/DOA4vSx2J RrUASK7D4GQMsduuGacTI4kX7IL1W+t+/fTrWs5IJnHHeK/teerdU+dpmoLMHjt6OUFM585LKKkg sgshlxSDd7e3rLyN3k860ljynM/P6CCMaolW/aTJL7KEkREa3qYkkq/S4gBkr7U9PET8Ifg4Wj6H NIJAEdS44m/JsehG7x71ugbO0j0MRsO/UcdruZwuCcNLPpI1nCNa2l+GCzehOYwG7PsdRX9ziSiF 8p+dRVaVwatTJHMLQj6DKwY85v4vP1bkhXcViRPEsHXe4Vsg4uWk7hSALNKL3r7awIvg93P8cbrb 0IBaFwuNHaN0i6MKfd6jJOvYKQfrfhiul3eXHd9Zl1h14nlqzhh7IGrjeR/ckPp7TkXrSSaKYeaq LS5eGUOVOZ40UKPWv+4sIhcNMheggAWDfSFEXzs0jVZYLGtESUDWIlW6repw0KzBN7you+2mKyU2 6VVz7LjnHLOh2wkGi8BpjfridIPttVMtrDXro22mUygHUN2ieHgvBryO6CileHEbTuy0gc67/OD/ XiYzkBTkKnT9NNFmnmevY7gm9xmv21rpgJR68+JMBBiiKwVZ4lmwjSS2IR+HIJoGK1112FQVYuhT LFqAbki1QiAWJuQ3k/TNBEKRCufYzTEQ/eCa4q6wBynbOYufuhtdofeZp7vLUPJpmVo95d1TZCvs wXVi4NNgpwsrX1hzX9dRqzU3TeSb9p3a6mHu8gS3CeAW5qH7jQja+x5se87UVdZhRPJKM2rP2oXn qCDt8pslQ43USnb503lmcwL6JUh3FZ57GnWkahvUfHBwhcmVcRjA2J0U1rh7HepkBHyeiqtjBwHk FP3k4PVOXqzTyia7qzQImwPLV+paVvuEja61ZGP6LI0GKOojAe8qRDx4nW2XTuYHBGYW2+gukgW0 A5L4bNv3eh36h85fD5MpaQy9uyj5QMtu5mOw4stpegjCdfCzBYNXgtvBkVwVu0lhUxLDZVU0brBr Dv/HVfpfIg30TC6o5UprQP7H6faXVfU3f/W5fQB5u452zJdMWbycu3l0iQwDK3qscStIMTbyQgYE tY4O07GBJIvuTOGQc38es4ZIrEGn6ZqWgQL1GReDbkRiXuneQ/BNCbPjc3ANtOVtWiLXrFHXSJzN b80TK5ocGXFQVAP7ydh345F59nuY3XkLY4sMJowcpkbK8qpdPM0R9eDfpDwdBHfOGE4y8yin7aMq sQhXXS7lEmP9ORroo7e6NBWcanrVsVvb5mXUo5Fq0zn+D5a708Wm6dxOdKy6XNtLoC1AXY5eFeus 47ciTJOv+fQ9G5czpJZzFi15sn9Mxl51y77HNYZ1tdbVz+COdgJ5Ipq3gUvypcmWds7MDZugpGsf eXo8YN5x95tZqVf3BlzLVoLddmn9P/hUhGS3vu8nwV1w8ar7Ke+kBrJ6cfT4nDQ4Ey4uPKDdMdIa AtxifU7N9LHKkql3GLHl3VbnkPjnTilCguJOnrqlT/FoYNRylU88Zp+hv7QJhgSnnSLv1Su807w3 dgmJYN5IlLbgKFbv3dN8zpQ/6ulvvI4r76N3RdwojwRq7nuRqjWdoSiIFJdTOhpntIajKatnwUTx L0sq+RQs9ALTDRTm4rptW1+kwettEIHBxaMAYKNm/jpkNQ6gi0BN8fcWxnSBM8v25t/zszzQeu+C FkwnXUb/dItBMLLa7DGRl1+dV5FPaii97CLC2CREmvHKRme4+awF1/OM1toRHBkhNsAiJWizG76M StrNLEW43O6etZyB+7r359Sfaz8iombsKj3fKdBeMeLjnIOgWpFQlY7kXJ1ajhxb2KGYQCQhJrnD beGMg3z1Ao1mczKdA75HVVV7XgbfP52Oi6qMzkva+Yoja9IjKNx/ihvjiEvNyTnDGe0HEKloGoye dxe4z279H0B8OuVFesZ6/j4FSV6iny3O3tGXIAoMqAQSW4jUDdJDBzFerfCCuzocDFnkMmuTHvnI bgMci7XaNF2OA0bAIO9rPyAzckPRAXMpiB4aCLqyXIbgXeDR6Gw8tvjgJdb6tQenU7LPdifzJmYU WUJhNEbQm5yK6c+ZmFBYxF8OtToH5wrFV3OCV0dzumKe7SIhoY58mlLhXdxdLLVIICGQOYH3OryW GFSoqiAafRBHHuI/9o9kgcd2S+B4senKEDFvABq7aPgy29M6c3FUnHQvnNhXsTN4HT3UKmsAwNYQ CRsd7etBdBUKMFN+s2MoL9lIQcYI1/j7WfmCW7Xle34Qw34Ofe1vHhTycHai0FUVuY5dNM71dLK2 3wSrsZe+PcSNdaiRfBGIyLazvRZ5cnerKZPbf86Hq4oBsGcnRUMPEIlifiWwsMvp3ElqqWWqdF3k Oy6HmByE397vyyOuCXEmvkE4hZEsqWONz/rG4Fb2JJ6RYlDlwMNrfaqB1kbDgt0/xv5Uvn8jgEY9 sdGZf9yoYsHAFu51pzxdbu8j6S1HpPLzVBBeF5h+1RRG3E0gllnOKJ4kux/7VeDOXnh/uQoRrbwd iNJ53VzaBAAIFAfO4JvKFmQY8BhMDh1vkUsn84eD3xm1md/B5ym7B7S3W3VQX0sQopqOeDNCejp8 +sxXItKfiQYdYpUbzdwrPQkSHesOx6QLUz7ClVxATnJSwPueNqDI17D3511QfT+HVw9yHxMWqJfN jsaHSQFlOnCHtwcnyV206qoOXzXC/jvUp3O6ZOHQYuEpTaY1GahrHI6+3BrpHSQutLFdcnHfCZ/f qbglNlmCUu46ajiajsGaMYDM2JJO2h0SIMdrhcQQg/AM/Q3XkFyLqe/9oM6a30vMuT4WJhJOB3Ah ykle7nXwBYU9eDjcmQTRbPHk1z44qt0c4M1kt4Lzbw4bCYbsaCD5/txeyUe16sWs8yHRh/agsFJf RDENjbzvpvSfL8D0GAunAcDLAIDlHLzneMRp8Sum2qv1XMoUxO5getXDifHm+WioXEsksVD2htq3 rWDgbaHOXmvdgO+H9INqBS3cgof8CB8TnLMp1thvXcezMxhILbzZFRXtVXt1N+tamIngNDMmNNbq c7iuTROE6eQtHL1euIeTh0ljLDdKVA+u3ON8fX16Zi4318f7dKcXhNGdWayrMH2bJnZ+iDYLc9FS C8Fj+uTqPPvC/U2FuLge4l3DoDpYfog7il0hafEGtXghFQ8WaO3rarqNWm7iDvHvenoqTECfRgaE w31S27aDviJdgv1ac0+EmOvfq6r/dz+7PUjlnZIanEFdfd1fVPmfgVf6Ndd83+Eh1q070ZJM6KbR JIvhtu7nqv/DbtOZ1EZp43RXfmrsy0bCX9ASP3G9Kz1jj1rYgKn3dWXqQzafUGsFzSHreUcBhoYC RUFfz+fHTHnbe7WO863OqnHqKyo1EMBVz+F4RefM6Z8CPFLIFihw9uRcMzmXU5MdA9wNY17YQF+n H86W9kmmU5GeKbPX8t7ciMkeLt04adfa4B1mSqRhhCo6NREuO926/yTmBs4f+07Db3Pw9xvB45H0 vI83VtP7yuvOm30W1K1LJ6WTTywcu2bDoewJv41H7wQGHzzd5K39xJxIdZFjNhrGFZeJkZ8I5mnD FmvWYex244zcCxreiPIdKtHxC5nQyeYyhkBGILsupDNW2DMJUucrhnp4XMEHj+KDbYChRXC35zGa 7a3/Gg6vTJ2zYTg363YaKAv8xHVqLoTrcu1HTUNGrYTZgR+qDs493fXrgTGThqzjMjnApwO73pxF YhF/pDNH4QGiEcvH0FUtALJPxAgLwC8uSgdUPoW3StDA05HIEIc0wQza+huMMvrMn641tSY6jikp iePs07PjAk/9eJ5vJ1gKhWFRpBF4VpDcFxQoKBrnzx0lh0l2mq6tO2L4BR3epNtsjO9Jeq0JSfbK v9oP42BHwbOu5eTj4T68gTemFQ3v0diWFUS6DViqkYwSjVS4rhhzRzwcvY/LtwcSFuxDxFKLLKxH 3OhNfvRpvp+fKaIIlA6/4qukkOYF0YldGVOWzWcX1QjjETlicgtZFFLxXCMs13KcAV7wb4CvsUMz lprOpQ0gOYr4CULpKJ7n4EQ2WjpyNnbRP+OsBEKAvNw7EaRF7mVslA5A6XIq4ZlbEkPX8ef0cBzV AqG724XOtt+LwO2CW3IWTIe5gjZq+ynQnLmOMMk8SzLyK+4+0a1qBMqQnDiixOhmYCJ0D4MomjwD +VtnpTIjrihm1od4tJM+PmIIFXXLcr/WcnfzNf1Ow0fz/FGsiXYiuB4DiovshEJcmu5Wu4jfgrE9 Tc9QWfv0vkC3dXppkg3kdJmuBYvsa3eEXQs0WDX7HkQTiRd2uUT38FV/akR0qeakOIoODmjq+1Oe 36PXMDNNigZRDQCZTjCjWp3EdY7iPLlIcRUlbkwHrA0cBqim6e6dJwQL/tKpPdvWHUV+w1qcgOCn BKQlv6igTqDQQwbGLyHcG4xjIcHlCE9kVoUL2ia/BOc37YOKW26S0n3f+kjWylSs/XknEbkFexok X4JOvEMd/Ut6BetMTqkBwNssI6liQXMdhMHGCvrfzwjkS+BUZ2/rIDLy5NvuL2V2RYv14FdffxFt a/U6ieA5NFnhBrHPcSNZkTHwKY+4MJZNBFxiorxnNw2XiTHpIsP9Ot9RtFcIPJ1nuhchriBuKQXl G4m5V9Q9nLB2ogriJKl33wKL2Qf6eH4c3X7/l1HUsbEbQUTrJotchfHBQb/Fd5zD/FM4l1KcV/qG AgthEajAcWueoYGHmnCjCOVGt1SfJ2oD+u1JMNroFrgHp2dq3pFUCGI+Tilj3IxvaAO567hzCYPN FJtPjZHD8r7PJL1cohL35vvR8W6TOFjYilYcMtZDAvekda6JcUY2QtByB1ud8YgA5pEWTuapk2z8 5gmrQfCTQ7cCgfo5L/x+b0kKJ6F8jThyLZd9CrMa2/V/P4VMZRFWzHsQ45C7igcbjH1zS2KtFJGy 2yYIS7eY4Mu6YCyzjtphvrc5AL/vSGJRrjybq55qw0WqqH0Yb0mM66pzBLVMinrW3hnmB5wEdtXp e6gnGKh2Ru4BMoOr3BbybYujydvlwN0UWJHgYZ4Hud4usyDhoDXxbQVujwbiW8AwzKH0ROB0YoVQ p6zPX8dgoTHe+0AW3XHErNUvkc50ME08NOrCI53nMoYRjFVRj66nyyGzehFYUXcSVfYNLMKhDrbA UMY4fOJwUa+nPQv480mYWPExVapLprlcfn2IqQnTOBgzJ5e+/RozA0OP1PYa/d5es33gpZs8hQui Cs9tMiPqxgn1yCV7ZeX0odE4686ftlMCyZOTMHd29OR3tzl+HXUP7SkfglnIPnYhv8ZDGdeO1ZFq u20TiOnQ2lsKR+uLGxVyZffapHFaobiVOYiezJlJspt58xg0zFRaIfK/zu//sar+yyr//bxdjlQ9 pZumTsxC/0BV/fWq+sNwlrLT6kyhvIy/MmvdgQGx5F9ggJPGeHe9zGferxpT594TcmZ0y1ZxYoTq MkPR0XPXcQdz35MYyKoXxXWGD4Fp5oCxScVL8Lndyunu+dkNv8RsXrj1MgaZCdvZqRJHMZ6Fr5Ug wI7fUno/WQYfI7D+woHeVmFheuDtJp8u2QXczzBy+9IpzZ5WqCTYlVOmN7Fotg+6zRqnoF+vNbxH ioitH3PUK4S3/pzUuuoWRw1oxB8ubkYol+01BvWchjPKdacETVzY9R7VVdVpKJV1zzCCOY2fHPhG njt5eug0zdCqgxV/y437FazHvL23VirPPh1YpAMTpJRwnx35lQrcTdu27fPLdNOrl/Rx0xR+d+YM tuqwa/N83BOzJnQMrY+95tt0bT+mHGqZurdMOlPRGO40G0zOQseIBZv8CNDCZaQiTfNH12+sC0rs W4ZFx3dk08I2TLJTFJYGoSDvkrodHqJxTYMdTrzfpteZNvkwMBPZD/zp3//hEA/VEd1MG+GONOzH 9gCg9XLWmxf5FSPaVf5z0phcBnI6fYt6eEpdjxawAFr00X556FQdEP9q8PwpovQUXnCBq+XCcJdr CbSl0y40yN5ghUOUIgRLdB5+CP7bIQZJEVAXBJCzCTVO2y3Ti1DlMr4AfP0UYJtsuUgRH+GpwmBp xZTsOpZdCQ5BU8mFlrEBn8LHCXJfMMHtDNXFVV5rh2UbNOU9J/y93MS9wPh5+PuIZC64FOMAVbYR XSS6J7xzpxmEHjAw0hoKQTk3p9y3i30dZ9ieRlVdAx9R3JuJ8sIL/nLC2Re9R7E5iESRcK8OcZ2C bnj750xgVl3Qego/hESXiqZdr33g49M0Ykjk1kbN4EyvqKpn/GoWGuz+QU5a18mZLkjCuz6jNI2F VLYqeyBsCwTIj+ZzZ1JRzEkwWQTizLkJhP2ciZdHmPCmpZhLg8NjjntcrgZ+7OL9M+nZUmz8XWCv ew/fz/U3CoDfj9CGm3HH/V51u1p9aoUr2eByNj2EAqoFCl5EFLtxaoHvYyWM+LUkDdT6HS9HDj/e zxaWqmYc9zzvtGLevcghOre0/mzBvtwR4BNQchMtOZw1BXUGAdUe6+4a/Bj7WlPQ+eo72MOfBA9T KLcd4qih3MN/vfF/ioLso5bL/32Jnr2mpgvO0SKHo/o2NEIOaeyEKXSKWSezck8TQbiRaEN1d3Vr 9aU/mLHsOgDk2aNsx7rvw7a7vmUxExHyGY9KeyWBESF4V0eP83bbKKw/KFa9HkGXVCd+oh5LhYCI DtelIVJdoow5UO4FzE4B5PuZzPt5x2YzjFMrtciRMLPdCn9+AorDvBKdhOCsaw78K+IMqzIRryoH /WZ1tAd8jfLtmThUC2UgHMMH2GpI7Bvg+hLd9cEjTl/SMUDAAl7B54ebbxB1u+fbrrYchTrBvIRM 5/nADpGf9ZF3UgEKYSAfc9hJ617O1IULhtx7YIrao9ZwHS72u3O/UmbafnI9CEI6UwokF0cNj0ei zr9NGMqnlvIg6Qo7dUNfPwcRdHQzae6h1c9u0Vk6HX1qYcZMu4tW1TWIt39y4XuoxxCdD4sHRmJm QsaP25eWrAXJSD/QBBX5EQl6vELsu4aTaMpseICeicLPAP4+f97O1kZiaOx+1doRah/nCm6e5NpD fg81wy0EJqOYOhH6Wut9k+E+iNpvzmQFu5Jowxc9+/7UtzOt0LF7irwXem0S8x5GLT2R1rmPND8W Os1nLVonNlCDfM4qkQ0B7gyjE6+Ie2rjvxtb9HH6vgcfC4i+dwquit2cLyw3UfdufvDBoo3JW0ZR SK+tNIacYhAScSidpKXABftnqfXa3F734HsYqtchG49M85ZlyWUv4pSGgnOY+/Z2BgZDCqxgCkEp 8YrEtpn/TOZX9zj+ejbKmnYmB1w5O9xbCu9PGlzq5hY+RHwea4HOnz20TEybjtNVzTUxLVqU55kv jlKVplC1Ei/rwDyq5vCrsJ5jzIkHNYQ9P7/FblYjTD/dnKIfrnzCnnayiyS0NjoMXmfoHsSPxGLR ELsrJfc8EOGRuFuH2R8MOlVBr+znXdD3wL4b6Sww+l3OQVgjijddTx153v6N6oOH7zfPMjniLV7K FN1rH+kxVGHTQKRDkPrhEqf4SphfflbtwJutuzGZjAI7m0fl2AcsdPQaPEi76ytDAjPUFP9WVf09 SgfcqeGuff5OvPhwjf1HquqvEx/IK+7ezzf2+E1cq6O2Y23CnVBFNwn92VfPSZy/nxXjRgwY6Tdy itvoaQua9+eZdew07Jvp3voi4TbwTty5+9n5fbQ0zLctjKbNMXnxaju1l53TL3549aGLy6P7pPfz O9FzpK2HluKbiHOeDRKveaGDLjC20kgc8dASvJOGF8kCmP3S3jg5jYsNFhpVJDfSB92MNTIPCaTR h3OQW8LhbBb6FuI+o6PeyWmqYgsHX6hL9PuDLxdX+sH9Hu/QjXu40hTQwthsS5qmnQZ1Qd7C+87a d86vnzXuE2+h7JubjwGL04maumsDThF2js1ATsvIYgq0BGLn5EEIa9ZYAxUKlt8z4cjhrL05+HSf PP9WI3gN/2/DLoXpwB7mG9Y1nhxgf/ZaSfOpqWXjDhq8oCdDlcE+4/dzYpMUMlp0vUyNDL8Lh4G9 ahDz7099c6aoKIYJqTbbNb/jjJjmeVvl6kT0tPUkwkpIwUOSWRZZhBdgEqo/tJyx3SwlvS55YzN0 RZ5PoZVgY9cqugoPgw32r4g+70N7ul31z/KzaaSz4YEAPCodkDT9iG8iEOgj9l2HQMQhaTfPLLq8 gN1eHBgJTNXlCfp24MlGtE/pJFE/gUWH4NBXLmaQollEJX0+LwFoHruDnumQKwhSOJ6EP4f6Ftdt d7KUrt8TNURmTNeC1WrqFadyO1MYo7tzv9S62imI6BpICbBfnwGGHT1h10EkHy7ZXwVLDGr9/M2+ JkF4MIvJGQ9Cjc6OpEsBI8T+mIUVE2wTAm65xq/G1gcocA1cNKIjItAqyPVC5zqOQLJzzXJM4uXZ yS4L1EQWxm1/wH5HDC7T1vN9v+eyCZYY03q4hrf7yMuFhSCPCVhdsP91MswpWFcKrInkeg++cYM7 xb2zqF0NO7jcSAAD9wSH9Vd0xiPR95hETxeuZulmAJi3VEZP4r3vC4mBbk5SSFFIEj46T7+qz6T9 BJF7jUaBlvkZo5FWkmA+ieJ8l4UuMleFcznOp0xsJGN4xR47xUV1CgEA5LSRmL3n7e8RsaRVFdOp BfDB3m8viHiQXdWdEYTBtQWN9HaAyporia8aay+jiqdjrKLap5rgp0ZRFQ3W+QB4KsC9ijpex1m3 ieBB1HvXGQWUjBfwsRv/b5+vYmiUhE97hMeHA+UG0jrI7QURpSvma13r2D+5d2cIuM4znwPvBSQj i64y6s0HHDQJzwRJVpydvhMnftAbQwxxnHkeU/Ae//cUOnitBZKZ+Oxvae3M2m/7LnC+mYDQGq4B h2Amh6MrHB+qXDSwxWeHOCljPfPe70wXqNf9u50thbcU38kr5jfi4jcZwCd5uopfRIKWy3UVpS29 iG6vzJ+R4OQC4lRAQxqoiem6q3q5UjhuzswHIidUjzppD0Jcg3Y+eor5zhZBqBtH6gOgjmFUSDSo Wxh3jvNj4hs56F/gOzkvFj596gtuss0gJDQ4mm9g8/J7m8NmRtF0kp8LnTqd31Nc5YVZXT3F/C3d 6fGFXsw48Vkf7f/eYgSdXfyVFlNPdIv2KTvZrN5Z8Ey9OgnvWmeSfr5qCU/RcOww38l/cwBTkNCn Y9/m7eQTa8ldmU5pS6yqQo9CJqYMfp8LuZPWcLkO4fWFQU1XJB7tuNLIHN/xHg0R1AkppNnIUmKd xsS0vmaMpNRFk7JTlY5qd+Ngl9iAh2RpcBd2mNaQcIh6fDxBN2c7qpvJTGWLdXkV/DpTSXJDhgUT 75tcgNp9OHBP3y74W/RHqRj3Tt4pvZub8IE7i+tiMSl9E4rXeaEjPcTBnfS0uYEeSIN7uh2nl/nE QdZeAr6UauSN+rxDlJgU5dHWIshnYs6FcMw+eA+c1JkYUFhD3D1sFbu07bhwD8HuZdqSojhFj0Nm HHQXF7hI+hIqj/v7LZ4xDl+4ttsbc3CCwcvlVNnOKzKhGcI+CXHxCtMVzsfc92L8WQnfYyEPPvHz V9KzUYBZq5ajgeZLqkFDeVfC5J//rSbv7oVh9UHI7flJZ0G6Sl7noaGCc7GLKSENNGDw2deOerBW 78uJ47jWvAdS5kD13TffHcvu15NjeO+fTGzUWBsCIxqD6ZHiHLjNkjZuEP2UfVR4tO92/W/sj7dA hWsRraTbrNK9hojrPNsNibfX4D31BDzKKcDFPEwF0wF2nudeyfZbv5HvHMZk/2+X/8Oq+v9UR9Jo VTIQIqG3UBVQVX+1qv7FOFNwwI9PsguByQRBYsZ8dFGpQ2BENms9L1yrRn1L3czNwfk3kiJ6/aDH UBn3FW597gcPZ8M5H7nROSTdE+Ypa4Gq8osH08FMpRP1NF8j7D3TvHUMo0GiXtVy7HVNwSBwZc6T I/+7YN94mC7MemOimFc6rr9qDgy1LhusbS700gMM86plHro5ma2l+fVrX1VzcqiMWWfich0Y+Uvg T5YQFfv7Hp7Rl382rxiNWoTw7uOOsJfJzqw5N/KKZ9l+p05brTROowFKFSnEPhx7moqMW1RCNslY Iazh6pomm/ss+wxskJR21iRYmXj/GTIFm67en57j4JS6zlLANOk10Em/v4oH3w601u3e9TVyxCty p28YcW/BYK5xOMeB/Rl1L8mDUd1xIHC6kKnZ//t8rh/d7Uef1TFD0sLqyef60AgY8ZIqTtbkOn3U StpcCQ/wSq/E64IeLs0LfgZWBDYLNMwkGMJ3BQ6W9UZhv0kaSG885+QXFfvnj+3SOKO8ptiuxwkY JqerjiixIG4F4PFr4tgAOH4aVSIMxhSYP1MhG2iriOpkIULhJ06X+k3UKSbgX7KHGzRN0aVOcqqL 9rKYcsSoT0e5t3tFF+BrONwKxSpq+yIgdukpBJhN0zxwL8HhPHBaoa5CIKtU0fQJD0/jgaMLnLFX HOyDcLqh/OEA+zy4j3Y/DrAlntht4F6/QfHbCGzpAN+CRlG645Cr4i10c12ulCm2MTQa8zVyzNZx PajALacwWupymTCIEjLuZg+BGNxQUujjw2mkzm8knNW642wuQcrd0Kg9uA5O+iRDGSRzbXFpYaFb CDy8BoQe8dRLGM/PlGL63CZIBc2nj/tGxa47uaahrYu0Db9C6lxHI7dL44y8/qzFeTcnnTwbZtXe dxlKSQ4rdCpPQL7G5DQld9S5JmrdLcYiNY6JcBO9BaDf1+MVmuXDidzrjq+6JucdhXRb80hqHOc2 UhtJ45AL6T4z9CBqLllrDosp2vgsqmetETGUvs8fhWMGk3vfz9gESrYw0w8IsY7UnvvMvMRnGcrH 7s/9fCC3Pf6OeV6oLonDJUowvm+eSg7ox1OA6AsMgKqx1/HXnPYnEnDVltoOoYo2fhB6Wk6MrqNe 272M4y3sHR2jOTYQJbPBN8AiqjUEozUMPZ63BrmejnMLvPSkTox1f7U/q6dw1liR+KhtZj1rqMnJ KzwGM3GIUQ2fp1P3JZnavdsaItT6mdp9nSrdoTfp6+KwuDpolE0QCxyDPzVRDn9zRTZrhzoEOHoA StRj0/qZKXWUPaRFkvtJhCXBAbQ5+1eZgPKU55NxwGe4p04PdJ+CuT6MLBRn5B4QhGIq0jM0opCN soermoj3HT0nuafAiG4Tul3wqwdGxHckO5nvIXSjBKGKRc/qYGHcJ+ytuwfQtrsNCU1vQlPgQP+O kt8uLBep8SKK9aUK6uv5Espe7jeXcAmlfVC/XD5ogaa5lhOrVt/OyUteTtv9nH6RFmRiUCGKWBWo WJiyXRINNA6/uxQbXj5bOJxR22VIf/7/Os40uP9Mghta36vu3rBcGyS+B+94fOum4mHoAbDi3hvW ErRUZZRtivmpP+cbjD/Xxvaq6socUQ5Q6Exz0SJUL5SuwjmvNglpotgL6/YK12+3moNqK7eUQOoy J/5kME3JoUFyFdUhX5z3CffBru+DS6p63AcFCSe5It3ux2sMaQ/ZH4LsJf77db4OYrqvUWWPr9jr O/nXy8l346PzSf+IY3StWR91lQNHVm0Djz2Ac4tIxrN3VtEhufHq/+0vrJDG2TZTMNvZpRfSq6NO plQMBe9UfNpNXMp3TdG5J68Tks6B4JH6nrVREtD/o9c51Acr0pnVKDJIVE6nv2mkYgcf9c7W2RX9 R1R0WZhcAj8t8UI9BgMEPXMTO/lV+3mNYVzetBVnc6bLuV4533tAbycX5em2710alHzVp3vQmoZR DaS/YBRPX56hgwvaQ8o3Q0gDIjUc7EnOGz9L2wGXXJCrKKheZ480BZM8iF15n8DtdCLa2sKaNjDR nDYJI88Odw7j6FE1vx2fjzW/vl+K5kEI6ls2T5jf5of04vu87n1TajUL1dwIfT1s4nggRMem63hC Yc1uSKVx9EgfJ3dSCqT5VCamaRkwfXfM5FGvnVymA8lmy7mJ+/nwRt97aZ0K/2lV/a9vTqIQa6H0 Cs5d8l+66m8V4N55MtHad13jeFci2s9b6ZjUmY5MuhlKFSzEMACNX3tDXyT7Fff7NVQnFBMSd+Lg sgQVy06w9Mm05dCmtCPjBdlH6XB8sfgFugnBYCiln6Fk0PRuHRxndyMmr/6qOhzT97/bAmzCMjix 5hpPTH66DqyisL+/pYw335bPtiL5x84/t1dmmj3uu/jTp59GtKLa+jKfgLF70N3ocMifrtQzLcao 5yB2e5ouFDr799QhWjtwG/zAZWs8ymlWQT1J378KbIf2ScVO3mJpLXNc5hhUl/mB0dgg8YXQ1GgP rwtPgDBrcVVPFFczumATYWFN7vVvLn4WRnbD7byAS05c6c2rh7ruNfuy9EZbeC3UnVzZg4zv+TF8 pbqyzhRu/h5ms6mrTXOgOn7jNJG+UpxG2nN9tKnjZHvWswsLcyZ4fvotHvCiFNuZYK5nXZmjhq6K NOg6VjUtlm3QebnXT7yU9N2IUCs/20x7SqVF1yxsbPxGaNIseZqW1Z8c3b0OqhnBUANYVE1hYE4e +CQT4kECmK+zWBSAJXUWb8MpTRAdvpeC2fnKT7kEtXY6CpSceVddLnI53cBkcLZ93yLhxoEfgmQS O2RhnkWmwjGtMGZO0Lila8nbrSYnkyJwWX3TFID4MxalztA9LH0PX6k1FPLjYM4k0KuonaC5H+Dx FAzrvIa3MPL6ni6OAc/oET2mHY3iARqs2ICL44Bi+F0gy8xoHL56dxpBwSW0YjmAJB/fKESTs+Aq vPzqLGg0hkA+TmSqHaNzn8U9NmmTLiRM0AHg2wm4O9znX9HUa40rm6srJrOvfy33hn0KM8mww185 trdqx0jSVGon4Wg+9RVRx87EDE7cVEQKZVdTqDoHUVg8cLn/K0T2I/pQ9RsxzhX3a4XcA+hX1VOa watMIEwWxGr1Zu47uXgR/puYuD20KmqrQkjPj1aBAbQeR/eK2NZO6wHAZ4KIHLuc1D4AbgjgM1lX p2gqW3tMg/nh4rya8rmuXVuY0f6M9q57O+JTTTfAaL+aCxoQnXdPb/B9uC7cMjWOZC6QIc6fnx67 HQyY982dLlR+7cscfDOcodtF4wrxnM611e5HFid+GmUFsIYOoYs8y7VOwzcpKxiiB3Ot21Nu6tg7 L1dDHaSF0JF8n1/sUTHjiPO5q/ZAtAA8nWR5v6P2fb0FGxNoNcK4IX51AkbbTdheezfAvHvdCUC7 /h1sIv6EAhAHaJx14w2M7jf6pT8V78v0lNKTUr/OxCke2XGrimfQB47Co9ur9zU7Tt2nM4m2EsD0 cjbfwKqbIMeHmzvVNemW3f/qjL909GI53LrJGB1ViYC4qlW7EVHqEH2w8/4m6XZilVIqUOmgYyC0 hOAvO7rnmSUVkC1Ve9hqnOR+1UyJFUyHxBQszsGUBe4jAeJH1dOBu23ckPXNHKBow7HeFP4cenIV mlR88YtPcPGBXRzU1OjzKwgnQ7+WGBrXdWv9i4f9jVCp8H6MaOrHrVxHTUx/JEWRApqzrX3XQviE lcuu3XOgSy1dsmB43o8EGBpRVYhDsmtp552ovq9FtteDmG21s0g4ka54nESQzz1xgKxT7Wt1tzNA FeRR+IqPgUH/kCTz7ODx/WrvTnjPkcctJ+/5Sug81vU8h0gcn5iM4D1uQshtUKMT6TP5bJGMZyLH hXdkQqEv0gzOiPf/PYcBDY6Edp6B90/l4faNiG4qVSsOOg129MSliHnoUyQKiKb1GDZ8G+gIRhrq ldRRUEfkObbjzwsxDT+SEHQIZjKB43p/u6fvz1qBYE1ThumYxsI+o18ljdDue/ROcWWndg1jnp1M 0YUbZ9KmeKB0iJP1Ht9JvA7ENvteXoKXT3JhitISESeB+qvn0mFudHdjeyjNIS1QkLvcf/m8g3ms x1/Gq6dr/jZoCa0b3tsCMTGndmHinK/MnnRqvhzDHZiuDjH7rNH2Puo4TC0n5uCatd/t9Q1yryU2 vwXRUwyo5TYdnHc4Ec4Bp13PzZj5OgSbdTyTKjKdY+uFmdixhVaDkVQFm1t14CkXY935Xt1+2ahu MGEJudKI9aXRHy034J+0gnYGZGpTPru5ag73xTDX4mHWcdZp7kGkYcJATcMgR3u413RK3KkgNbQN mTZ3p9kJWe7ZR/AtRRyi/cK4PvU2iWgVQ67weZAHuySMrjvP5sGv8Tn9b6r0fxO3s/eUg3HzWSUu TvIvVPqnx1C/Ceu8sscykfWVKD3OM9XAE4z3z0rns7HW1RZNCfBSEw/Q+jKoA9geRIfV58HV1JXw 54O9uM/z3+EO2BDDFzKJv+3HLODoC3eP4SPBRxffK062ilNZzMRtF980CnRd4wmJkQv4LurGr2Qw Ax+197XG58yukAf6r8yR5yrTfh6iiv48Q8ZJrUKB5jYeS63MzsPyF7WBihOfqAYv7GQK65QKztj1 7gVHanPsHH05BTd3U6xlwHN6GmPm0Ns6tzyFu/sPKngNHSmYhpOcxPGG4RbGJz4Gr9sIRmgJ2HtC L86kVm23Tbr2ux9Vj9gI00/Vk5rWgqwmFHeOnvjiPjsm1nlZs+6a+kpl+sGJzelHs2alPcs31AvJ GD28FHcxJ4/QO7uwYyP/J9RS3Ym01NUNA+f2z5jz2MaJyUdOrjuxPwXzNweKNhp0p05RUsCuPYzL j61i9azJZ/eew95kl5O44MeMOg01po7ipav8gwpurcPuU+Nz8XFdLnVe8xdBWeGKVHCh6nhoP0UU 2uLvg/Oa58xlekcH5e+uM7JcR/uscM57UfkkINYGilXFornu9KzaUTXhwubi6XDlBb5LlFeYVKGM 4xVqv0AhU3hJB7b7pqlid33BlIy/NJQpztcSTUWkvQqnuusRVap12Y/pFiRxqgpi6gcxIB1TPzqu qBSNpQO/QWChIM5Z5vvnM6wdYl7gZ8FO1zPizwGAJ+y6Gk/tS5vcNVbDO7N123paf+b5rq4Tx/jU xtmnghPQABgwdLy/K5UD1VxBfqYlcbTEYXvvAIM2HA6iG6dgaQLtF2ztJSjcWRCzWPisCQ1y9ddQ CoszBI2fT5D6PPvtUwTsBwl/UIaF0Wo/fLvA2fxDNs5pO2GBJIgQZ9pXlfHhswjVdrdvxGGPYxYM mTGF5KoY+mDBiQfDpnhY4xl4+7/5OF9fN4aa85TQwaHXKtewwb4vHCkPe3eY78sQhCnEb931OgfU mkOk96fV+ZlzoEHQLNUSkqRL0SQOBOS7h6DOeJZlTcoxrgk4v0n7tnco5mm7fNY1xqlZsCurBfJd 4YnZQ3TgTS70mpBcJx3xvnsgzCuVZUaObiL1BnYckbP7DKbUFEOiCceXbaKHQEq6kn0OMewmsaKr 6MNuI7J4kUQSQmpVz74jU1t8NPo6nQ6Nd7YwDpTEEkLBYWEDLwBdmCyU9sp2A86LgRDV0WtpEWCF YvjhvGJHXXKHduuoRUnY6no5sl3UlR/njxEEm79teO95Q8nL/RMdSicFY+fPLRxUbGIS1SmIS9xB gxyetZO/PLfb9RnpBWkJlF5JT9t1XyNKfNQJ9gk8Urf74y4PDiIGj3WqEWNwwyRFIcf7HPqPyudw WNKDwHakErRbzO8YZO6NagxU+QnFCUDtFn3q7IORwHKBS04SgQXkXbjkuwBU59E66aL61Yv8GOCt 6u6MH7HzvH/2M5xkFcdB1kla+DeQEx5aIM9xVeEIsB4ZHkYRyhQoFpLE6djrqiA8fKSC8D1AfdKu pXfKkNCd04NsGRhfGXvm2ZPPZLDeazDxl/cmu3z6UXE4/JdTcvJyyPSzvnDVgdltlyISa+Sg0zZ+ uAb29HPWE069V4XH+gg5i1LMfclZ+1k8hp4WbrX7LNpBROpdJy8N2/0Mf3kO1fxJrF/HOzxIOCRI GWtgRmE5rf3U6SSKIiOZj7B3i6XRCd8XUX10u9oC6Fu4c8UY+xC57/ot9+V9h85Ic0op1CGwRSSp 5lAtCREn3T/ddmvVyDOJKHFxBQFIN9lLPBH3iF7rtb1zFWaBEV7GXqKGpJTrLIXRDNeBL+/04UpH rKpzRDLFu5TN+zG3oNvZq29kIhLMaDp26Yp7d4oXXKc/rOjdLizSyVXqWV8VcGKUaSiMzr5ELh41 7C0ANayf21RGJ07ts9afGNYcJlOwSNvoxnUJWXufyTW118Caihx3CQv36uO7mdlRE5z4SLAIK2U0 n7Aadp24rg5siO51LdfC5HYE9dTkUWYiFqU8ZzLGxIPzDF4JRPbql650DHam1Bq4HPvJfO4ZxR43 H7vNoJYkJdbo7gcmDyh0S62zVl14mh3p2MlLv9ahMEWI3aP3O2y97YEj1ZE+2vf+XWE8eqyGEyeO wMJYrlm6yYYfDLyL3WQTT3Qk6YAZgFIjUq2H+hN/NT9fP3M8arzES6+hpzlyTtJFpXPtgZsmvqP/ ocr/beFYy+aZfWRQkN5n1E//cFX9rVlHadz1NBZWlJu6k3AANw2XX1+M2eXmXmutF5iQeJm4+MTA aP25jFzBXrcpYC7o3NJyIg1Z6jyL61TefNEbeY92zeSxadBymFuqQKBHfc6f756mMdhGaoa+gIyi CivoKHDXeqgzGSs5olqfx1WPhOBXIiGdVNsSSzGcvccid094jZPMekzFabrcQV3dztUHfZPrL2MC 77tfcdJf6NG+J9I5nnisNM2gocpZv/pIk6QeqJbeoR7mvXQq+skU0WDQxvNrYFW+caCmC+haTANm RiPwxDTvZO3suwsR5mnO4jXouTnTOvQXxMm6DRlq7fnXXbt2px/9QKXIuIvMBdwKmxdO/gh3lQpw RT0d2ffeuEZGso9gl3AjI82DXh2TuNg6e3M797D0C03s2qKpWX4lJxEfQaO8cOKZTvE8k8Z51tzg f5mcrFOtDVbep2zVYzjc72GcC4OipCjGPf3AeVM/JTA8nD9qvXNv3i5HzuoaejfpqFz//wD178Sa YpRWOQAAAABJRU5ErkJggmAhG/BBAgAA7tu1c2pAoLp3dnMucUO2FUAHAAAAAAAAAAAAAKkWAADX AQAAqN+GAHDuCgAPAgAAAP542r1Uz0sbQRR+b3bV3URR/DGUUCQNiAoarBdPtT166KGg2JuQ0qUe ogeTCN48efZqkBCLoJ579T9Q0lJovHrp3XMrjG92dnZns4lBUSfMzpv33vfmfTPvBcEFsOoWQB+8 BzlsmhY60ENrmkmNlPrZFZ5xKbmhDpkQwve3ccBfGTKgUDDu7yZRiHa7CBvF6+7RR5Pbf/CEP8Zf 7m5JL8RBgJ5FCLylTke4TPDpp/WD+wZuQI2feMRtsr4m+T87FEq7T9Fgj+bcRePyL9wz1NloZCRC LQuiDvlWgHPJZA8Zyy3vlMrehoqgEP7YXVoYM6Jabe5dnmXyVSwj5uqearCSlqy6vzD6dTKfysEI myDpc2HbK3qb38rr2crmllcslL2v2eXKl9kSzZWPq9mpd2+n3Xl4qp++qYcxTlZGDY7pHSXrOLtc wG5xcJgkk4hi+ZI5/sZjXgM78QLcz9HFtVSKpNVCseKV8vl89jlzMTvvKeI18TTWmZlMJoyuGN+E HSptrX3p0PqPqTbQdn3iaFjBI6xJOtM34tCT6O0mOoZdx3LgU1rF+k5SJ2yVTnFCe4Stc51HnXfC NlBitT3i4AQcAE47YiVOfuPYaoitdsFWE9gGamwD78dKT/1+5s32Bu9nd6mS1uqQ79iu2h6O//Hq F78W18KsmhmEFmuEiv/baQZRJVsBI4xlAnAH3v/Ux2AhG/CVAgAAQOvptYDGQz8Z0JsMOdBLJA4J AAAAAAAAAAAAAKkWAAA9AQAAqN+GAJBZBwBjAgAAAP542r2Vv2sUQRTH35vd9fa8GIXoYBGSmCKm MJAcJ1qcINgoWBzmSH/iYAiJyN1FSCOpYmvrISFKigsIFmKX/8AgFleIVSzsUwYNjm92Z/bH7Y8z aDLH7rx5731mvvNrD6EIYL2wAQowDaqQCRa64FBdYsqjrCF2C3e4soqBD5mU0su38ZxXM2RgUT3m ta6ilGmtkA37G5xRoIfbd/A9P5SH8rj5qnVEfvlqT482g6Czlc/vwSiJzmeI6tvFK3AAfrmOb7hN 0VGyf7HX0ve+pN5gg57ZT5/3fkBO8cdGyFpLRjHaEyifnYJ7oLqdg3Lg+Z3wfEDlmY14FpnJCWYt ZTAy08oveFGAXaVhAxmbnF9rtcWKr9InvLJ+98aliHIrZW/VfKJrmr4Xm/DOseEri68wwoinexKe Wy5ZD0RLNJ+JR2WI/4z6f1dRL9mekriKUa1iqjBMVq3RbKyItmhO1Neein4tJ6Nrm86V0hbXNa11 fRvmZM2vPpxp6ad+f2FiWTx53F7M03dSem/iNt8EG/r1jnl6d+F78XxsHRcay6vilLRFvxL/o78q drlpHbH4TfZX4ACTXw51mn+y/pvvj3MxuPkjrEq+9Fwn8fWpopvSlwsfdV9vycpiOzSKG8RDdgkN u4T5rImH7Dgz7DjLZ008ZHsB2xvA9hJs1zFs18lnTTxkayXD1kr5rImH7BY3e7bFs9gKKtbEw/12 9R4BdDNZxal3nO0EbGcA20mwFTRsBfNZlZl2ws/oE24PuEd/ex+Pz+9c/sL35b6M3rBr2B/N+kc1 MwjvuqVnhDElAH8AduT9fGAhG/BDAgAAqq27CBAYBSRVAqgM93b5BToHAAAAAAAAAAAAAKkWAADX AQAAqN+GAHDuCgARAgAAAP542r1Uz0sbQRR+b3ZTN4mlxeoioZSYHtqChpJLL1q8CD30IETsrRBx 0UPsoYlCb54892poRUWonr32P1CiFBqvuXj3rIXpezs7u7PZ/MASOstk3rz3vjfvm/cmCGkA67sF MAKzwMOmaaEDKVqzgjUsjYorPHFZSoc6FFJK39/Gh/4qUACFgmf+7gVK2W0XYaN4gz1GaLr2b/zh /os/7/6QXsrdAD2DEHizTkc4T/AZpXU+PQU3oMYFHrg2WZ+SfCe+SaX9StFgh+brs+b5NfQZ6mw0 MpKhVgRRH/tWgJ/MZAeFKJS/1OrehoqgEP7Yfvdmwohqdbl3Psvkq1hGzNU9/cIjd4/8BlcYgS+0 lEnjx0yGpOVKddOrFYvFfAmSn+Z1v/ySddyDpSzfemcus34uBVgQz0n6UNnyqt6ntfp6/rNXrdS9 1Xx5c2WmRnPp/XL+5VzpFZSG8g2P1xF1E3OL8yoEvN4+GiPJJKH4/c8czTc3jHgtPI69yVwuF0ZX Fb4J3ybbOl+kQ+utUA9A2/WJ42HvPhEt0pm+EYdU4lW30DHsOpYDi1kV65CkXtgGneKE9gi77+o8 9t1e2CYyVtsjDk7AAeC4J5Zx/BvHNkJsYwC2kcA2UWOb2B/Lnrp+5s0+COpnD+iSzu7gOnbrtvvj Tycv3bZsS7NrphE6rBEq/j+nGUSdbAWMMJYJwF+KydOfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A6AOJLgAAAQDpAygAAACAFgAA4BAAAOAQ AACAFgAABQAAAAoAAAAFAAAARQAAAAEAAAAAAAABDwDyA2oEAAAvAMgPDAAAADAA0g8EAAAAAAAA AA8A1QeQAwAAAAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAHSpEwB0qRMA 5ISIFvyWEwB4Ogsw/JYTAAAAAAAPANUHAAAGIhAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAA AG8AbQBhAG4AAAB0qRMAdKkTAOSEiBb8lhMAeDoLMPyWEwAAAAAADwDVB4AABiIgALcPRAAAAEYA cgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6CzD8lhMAAAAA AA8A1QcAAAQiMAC3D0QAAADRnlNPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkA dQBtAAAAEwB4Ogsw/JYTAAAAAAAPANUHhgAGAkAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4 AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPyWEwAAAAAADwDVBwAABCJQALcPRAAAAE5T h2XGftGeAABnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzD8lhMAAAAA AA8A1QeGAAYCYAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAHgAdAAgAEwAVAAgAFIAZQBnAHUA bABhAHIAAAB4Ogsw/JYTAAAAAAAPANUHAgAGAnAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4 AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMPyWEwAAAAAADwDVBwAABiKAALcPRAAAAItb U08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzD8lhMAAAAA AA8A1QeGAAYCkAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQA AAAAAHIAAAB4Ogsw/JYTAAAAAAAPANUHAAAEFKAAtw9EAAAAVABpAG0AZQBzAAAAZQByAE4AZQB4 AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMPyWEwAAAAAADwDVBwAABCSwALcPRAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAQgBvAGwAZAAAAAAAcgAAAHg6CzD8lhMAAAAA AA8A1QcAAAYSAACkDwwAAACAAGIAAAAIAAAAFAAAAKUPGgAAAAAAs6guAAMA/AAGAAAAAAEBADIA +QEHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAA AAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkAC AAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQWEgAADwAA8A4SAAAAAAbwGAgAABoEBAAC AQAAbwEAABQAAAAAAAAADwAAAAIAAAA/AAAACwAAAAgAAAAMAAAABAAAAAAAAAAQAAAAAAAAAAQA AAAAAAAAEwAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAANAAAAAAAAAAQAAAAAAAAACgAA AAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAA AAAAAAQAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAg AAAAkgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAFAAAAAAAAAAcAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAA AAYAAAAtAAAAQwAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAA BgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAAAAAABC AAAAAAAAABkAAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABAAAAD8AAAAJAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABgAAAAAAAAANAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAHAAAAAAAAAAQAAAAAAAAABAAAAE8AAAAMAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAkAAAAAAAAAQAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAMA AAAAAAAABAAAAAAAAAADAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA WQAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAQAAAAA AAAA/AAAAAAAAAAvAAAAYgAAAAQAAABjAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAawAAAAQAAAAAAAAAJgAAAAAAAAAlAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAHAAAAcQAAAAgAAAAAAAAAtQAAAAAAAAAGAAAAdAAAAPkBAAB1AAAA XgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAADyAAAAAAAAAOMAAAAAAAAAXQAAAAAAAACsAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAHwAAAAEAAAAfQAAAEEAAAB+AAAAcQEAAAAAAAAGAAAA AAAAAAYAAACBAAAAAAQAAAAAAAAGAAAAgQAAAOoCAACDAAAAvQAAAAAAAAAGAAAAAAAAAAYAAAAA AAAABAAAAIcAAAAaAAAAnwAB8IwBAABiAAfwJAAAAAYGBYs1H73H+Fqm86dQG2KYS/8A0yoAAAEA AAAAAAAAAAAAAFIAB/AkAAAABQXY8+MEAuku2OPtcJjJPSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH 8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/AAZXAAABAAAAIeEAAAAAAABiAAfwJAAAAAYGKx2cUUGW jNt7/vgYpNBSef8AqzMAAAEAAAAnOAEAAAAAAGIAB/AkAAAABgY86hloAaVPVtTX+LuTUNBJ/wDR FQAAAQAAANJrAQAAAAAAYgAH8CQAAAAGBrjpaHIX9gtc+PzUZOyCabb/ALxWBQABAAAAo4EBAAAA AAAyAAfwJAAAAAME7tu1c2pAoLp3dnMucUO2Ff8ASQIAAAEAAABf2AYAAAAAADIAB/AkAAAAAwRA 6+m1gMZDPxnQmww50Esk/wCdAgAAAQAAAKjaBgAAAAAAMgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2 +QX/AEsCAAABAAAARd0GAAAAAAADCAvwAAMAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAA AIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAPAAwB9AAAEA0BAAAAIA4BAAAAIIABAAAAAIEBBAAACIIB AAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAA AIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUB AAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABAQAA CMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoB AAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAA CAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsC AAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAAB AIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMEC AAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUA AMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQC AAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkB AEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMN IvEKBQAAjAABAAAAjQAwZQEAfwEAAEAAngH/////nwH/////oAEAAAAgocEAAAAAogH/////owH/ ////pAEAAAAgpcEAAAAApgH/////pwH/////vwEAACAA2QH/////2gH/////2wEAAAAg3MEAAAAA 3QH/////3gH/////3wEAAAAg4MEAAAAA4QH/////4gH//////wEAAMAAEgL/////EwL/////FAIA AAAgFcIAAAAAFgL/////FwL/////GAIAAAAgGcIAAAAAGgL/////GwL/////iQL/////igL///// iwIAAAAgjMIAAAAAjQL/////jwMAAAAAkAMCAAAAkQMAAAAAkgMCAAAAvwMAggCCQAUAAAAAQQUA AAEAQgX///8AQwUAAAAgRAUAAAAARUUAAAAARsUAAAAARwUAAAAASAUAAAAASQUAAAAASgUAAAAA SwU1JQAATAUAAAgATQUAAAAATgUAAAAAT8UAAAAAUAUAAAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUB AAAAVQUBAAAAVwUCAAAAWQX/////WgX/////WwUAAAAgXMUAAAAAXQX/////XgX/////XwUAAAAg YMUAAAAAYQX/////YgX/////fwUGAE4AgAUAAAAAgQUAAAEAggX///8AgwUAAAAghAUAAAAAhUUA AAAAhsUAAAAAhwUAAAAAiAUAAAAAiQUAAAAAigUAAAAAiwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAA j8UAAAAAkAUAAAAAkQUAAAAAkgUBAAAAkwUBAAAAlAUBAAAAlQUBAAAAlwUCAAAAmQX/////mgX/ ////mwUAAAAgnMUAAAAAnQX/////ngX/////nwUAAAAgoMUAAAAAoQX/////ogX/////vwUGAE4A wAUAAAAAwQUAAAEAwgX///8AwwUAAAAgxAUAAAAAxUUAAAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUA AAAAygUAAAAAywU1JQAAzAUAAAgAzQUAAAAAzgUAAAAAz8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA 0wUBAAAA1AUBAAAA1QUBAAAA1wUCAAAA2QX/////2gX/////2wUAAAAg3MUAAAAA3QX/////3gX/ ////3wUAAAAg4MUAAAAA4QX/////4gX//////wUGAE4AAAYAAAAAAQYAAAEAAgb///8AAwYAAAAg BAYAAAAABUYAAAAABsYAAAAABwYAAAAACAYAAAAACQYAAAAACgYAAAAACwY1JQAADAYAAAgADQYA AAAADgYAAAAAD8YAAAAAEAYAAAAAEQYAAAAAEgYBAAAAEwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAA GQb/////Ggb/////GwYAAAAgHMYAAAAAHQb/////Hgb/////HwYAAAAgIMYAAAAAIQb/////Igb/ ////PwYGAE4AQAYAAAAAQQYAAAEAQgb///8AQwYAAAAgRAYAAAAARUYAAAAARsYAAAAARwYAAAAA SAYAAAAASQYAAAAASgYAAAAASwY1JQAATAYAAAgATQYAAAAATgYAAAAAT8YAAAAAUAYAAAAAUQYA AAAAUgYBAAAAUwYBAAAAVAYBAAAAVQYBAAAAVwYCAAAAWQb/////Wgb/////WwYAAAAgXMYAAAAA XQb/////Xgb/////XwYAAAAgYMYAAAAAYQb/////Ygb/////fwYGAA4AgAAa8SAAAAD/AAAA3d3d AOrq6gD//2YA/5kAAAAA/wAAmcwAAGaZAEAAHvEQAAAABAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAA AADzAxQAAAAfAAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAAJgAAAAQAAAAAAAAAAgAAgAAAAAAA APMDFAAAADMAAAAEAAAAAAAAAAYAAIAAAAAAAADzAxQAAAAxAAAABAAAAAAAAAAEAACAAAAAAAAA 8wMUAAAAPAAAAAAAAAAAAAAABwAAgAAAAAAPANAHPQwAAB8AFAQcAAAAAAAVBBQAAADQGM0EAMqa O0613DYAypo7AQIAAA8A+gN3AAAAAAD+AwMAAAABAQAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAAA AAAA/CWIFhSXEwB4OgswAAAAAAAAAADu/P//Cv///wAAEwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgA AAAAAAAAHA4AAHAA+wMIAAAAAQAAAAkCAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAT BDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAAACAAAAQJcTAPz4CjB0qRMAAAAAAAAAAAAAAAAA AAAAAAABEwAPAIgTMgsAAA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNE AAAADwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZ AAAAAAAAAAAAAIACAeAPAIoT+AgAAAAAug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPS CAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA ABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgM AQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAA AQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAA AAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAI AAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAA AAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAA AQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAA AAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABo bmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMA AAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAY AAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAA FAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAAB AAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAA AAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBN AG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAA BgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAU AAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEA AAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAA AAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0A bwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAG AAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIoTaAEAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixNIAQAADwDWBzABAAAAALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMA AABvAG0AYQBuAAAAdKkTAHSpEwA8lxMA9JUTAHg6CzD0lRMAAAAAAA8A1geAAAYiEAC3D0QAAABU AGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAHSpEwB0qRMAPJcTAPSVEwB4Ogsw9JUTAAAA AAAPANYHAAAGEiAAtw9EAAAAi1tTTwAAZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAB0qRMAdKkT ADyXEwD0lRMAeDoLMPSVEwAAAAAADwDWB4YABgIwALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAA UgBvAG0AYQBuAAAAdKkTAHSpEwA8lxMA9JUTAHg6CzD0lRMAAAAAAA8A1gcAAAYiAAANBAgAAABw tQAAcLUAAA8AihNKAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMsAAAALwDIDwwAAAAwANIP BAAAAAAAAAAAAHsXEAAAAAMAAACoAwAAAwADAAIP//8/ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8M AAAAAADaDwQAAAANAD0ADwDwD3gKAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQA AAAGAAAAAACoD3kAAABPU1BGIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3 YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5ndGggQXNzaWdubWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRj aGVkIE9wdGljYWwgTmV0d29ya3MgAAChDyYAAAB6AAAAAAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAA AQAAAAAAAgAoAAAAqg8yAAAARQAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAA AAcAAAAAAAQICQQQAJ8PBAAAAAUAAAAAAKgPnwAAAENDQU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0 cmljaHQsIE5ldGhlcmxhbmRzIA0NZHJhZnQtYWdyYXotY2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9z cGYtMDAudHh0DQ1GZXJuYW5kbyBBZ3JheiAoYWdyYXpAdHNjLnVwYy5lZHUpDVlhYmluIFllICh5 YWJpbi55ZUBodWF3ZWkuY29tKQAAoQ8+AAAAoAAAAAAAABAAAHgALwAAAAAABgASAAAAAAUuAAAA AAACABgAAQAAAAEABgABABIAAAD//kIAAAAAAAIAEgAAAKoPPgAAABUAAAAGAAAACQQECBgAAAAG AAAACQQECDAAAAAGAAAACQQECAEAAAAGAAAACQgECEIAAAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMP EAAAAAAAAAAAAAAAAAAAAAhYCzAAAN8PCAAAABUAAAAtAAAAAADzAxQAAABTAAAABAAAAAIAAAAO AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8PAAAAQWNrbm93bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAA AAAAEAAAAAAAAgAkAAAAqg8aAAAADwAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEA AAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABWAAAABAAAAAEAAAARAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8KAAAAQmFja2dyb3VuZAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoP GgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEAADzAxQAAABiAAAABAAAAAIAAAAZAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8MAAAATmV3IFBMSSBUTFYgAAChDxwAAAANAAAAAAAAAAAACwAAAAAA AgAkAAIAAAAAAAAAAACqDzIAAAADAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABgAAAAkEBAgB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFcA AAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2Yg TGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8mAAAA HwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAA AAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAABAAAAAIAAAAaAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5vZGUgUExJIFRMViAAAKEPHAAAACEAAAAAAAAAAAAf AAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMAAAAGAAAACQQJBAQAAAAGAAAACQQECAgAAAAGAAAA CQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAAGwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHgAAAFNv bWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExWcwAAoQ8UAAAAHwAAAAAAAAAAAB8AAAAAAAIAJAAA AKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAAAwAJBAkEAQAAAAcAAAADAAkEBAgNAAAABgAAAAkE BAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAAHAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBh cmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsgUExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAA AAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4A AAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAAAAQAAAACAAAAHQEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIE5vZGUgUExJIFRMVgAAoQ8UAAAAJQAAAAAA AAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAGAAAACQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJ BAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAA ZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGwAAAEFuIEV4YW1wbGUgb2YgY29t cG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAAABwAAAAAAAIAJAAAAKoPDAAAABwAAAAGAAAACQQE CBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAEQAAAAAAAAAAgAAAAgB AAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABOZXh0IFN0ZXBzAAChDxQAAAALAAAAAAAAAAAACwAA AAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACoD6oAAABSZWZpbmUgaXQg YWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBtZWV0aW5nIG9yIG1haWxpbmcgbGlz dA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1UIGRlZmluZWQgdGhlIHN0YW5kYXJkIGltcGFpcm1l bnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJlIGFsd2F5cyBhcHByZWNpYXRlZAAAoQ8yAAAAiwAA AAAAAAAAACAAAAAAAAAgAAAyABsAAAAAAGEACwAAAAsAkAAAAAAEQQAABAsACwAAAKoPGgAAAKoA AAAGAAAACQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAAAPMDFAAAAAYAAAAAAAAAAAAAAAABAAAA AAAAAADzAxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA6gMAAAAADwD4A0s7AAACAO8DGAAAAAEA AAABAgcJCAAAAAAAAAAAAAAAAAALMGAA8AcgAAAA////AAAAAAB3d3cAmQAAAP/MmQD/zGYA/5kA AJlmAABgAPAHIAAAAP///wAAAAAAgICAAJkAAADM/5kAmczMAACZzAAAZpkAYADwByAAAAD///8A AAAAAJaWlgCZAAAA3d3dAJnM/wCZzMwAAJmZAGAA8AcgAAAA////AAAAAAB3d3cAmQAAAJnM/wBm mQAA/5kAAN3d3QBgAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZAP+ZAACZAAAAYADwByAA AAD///8AAAAAAHd3dwCZAAAAzMz/AJnM/wAAZpkAmQAAAGAA8AcgAAAA////AAAAAAB3d3cAmQAA AJnMzADM/5kAAJmZAJkAAABgAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZAP+ZAAAAAAAA YADwByAAAAD///8AAAAAAHd3dwCZAAAAzMz/AJnM/wAAZpkAAAAAAGAA8AcgAAAA////AAAAAAB3 d3cAmQAAAJnMzADM/5kAAJmZAAAAAABgAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZAP+Z AACWlpYAYADwByAAAAD///8AAAAAAHd3dwCZAAAAzMz/AJnM/wAAZpkAlpaWAGAA8AcgAAAA//// AAAAAAB3d3cAmQAAAJnMzADM/5kAAJmZAJaWlgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wAA ZAAAAAAAAAAAAPkBAAAAAAcAAAD//+8AAAACAAMAAgD//yIAmQAA/gAAEACjD54AAAAFAP/9PwAP AGwABgA8AAAAAAIAAIwAAAAAAL0AAAD5AQAAAAAHAAAA///vAAEABAAFAAQA//8UAAAAAAEAAOAF AABwADIAAAAAAZsB/QABAAIAAAASAIQFAAALAG4AeAL5AQAAAwAHABAA+gUAAAEAEyAAAGQAAAAA /3MD9QIAAAMAAgAOALIFAAADAH4AAgAAAAABcATxAwAAAgAMACAAow9uAAAABQD//T8AAAAiIAAA ZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAABwAAAP//7wAAAAAACAAAAP//DAAAAAABAAAABQAAIAEg AQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPWAAAAAUAAAABAQAA DgAAAAAARwAFAAUAHAAAAAAAAQAACQAAAQD9AAAAAAACAAEJAAAKAAEA+QEAAAAAAwABCQAAAAAB APUCAAAAAAQAAQkAAAIAAQDxAwAAAABgAKMPFAAAAAEAAAAAAAAAAQAGAAEAKwAAAAAAcACjD0IA AAAFAAAAAAEAAAAAAAACABEAAQAAAQAA/QAAAAIAEQACAAAAAAAAAAIADgADAAAAAAAAAAIADAAE AAAAAAAAAAIACgCAAKMPQgAAAAUAAAAAAQAAAAAAAAIAEQABAAABAAD9AAAAAgAQAAIAAAAAAAAA AgALAAMAAAAAAAAAAgAKAAQAAAAAAAAAAgAJAA8ADAQfNgAADwAC8Bc2AAAAAgjwCAAAAE0AAACR cAAAIAAY8QgAAAABAAAAAgABAA8AA/CfNQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAABwAAAFAAAADwAE8GYAAACyBArwCAAAAE9wAAAACgAAYwAL8CoAAAB/AIAAgAAE QQYAAAAFwQYAAAAGAQEAAAC/AQAAEAD/AQAACABkAGQAAAAjACLxDAAAAL8BAABgAL8DAAAABAAA EPAIAAAAUQ8AAIQW4hAPAATwIQEAAKIMCvAIAAAACHAAAAAKAADTAAvwTgAAAIAAbGWIFoEA/DgB AIIAf5wAAIMA/DgBAIQAf5wAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIACMAIvEMAAAAvwEAAGAAvwMAAAAEAAAQ8AgAAADYD5sBDQh9EA8ADfCPAAAAAACf DwQAAAAEAAAAAACoDx0AAABIVUFXRUkgVEVDSE5PTE9HSUVTIENPLiwgTFRELgAAoQ8kAAAAHgAA AAAAAAAAAB0AAAAAAEMACQAJAAwAAQAAAAAEAgAABBYAAACqDwwAAAAeAAAABgAAAAkEBAgAAKYP FgAAAPEeAAD5Af0A/QD5AfkB9QL1AvED8QMPAATwUgAAALIECvAIAAAACXAAAAAKAABDAAvwHAAA AH8AgACAAARBBQAAAAXBBAAAAAYBAQAAADgAAAATACLxBgAAAL8DAAAABAAAEPAIAAAAvw96ErQV hBAPAATwjAIAABIACvAIAAAACnAAAAAKAADTAAvwTgAAAH8AAQABAIAAoHeIFoEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACCMA IvEMAAAAvwAAAGAAvwMAAAAEAAAQ8AgAAAD4D6cP0BQXEQ8AEfBiAQAAAADDCwgAAAACAAAABwGI Fg8AiBNKAQAADwCKE0IBAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AQQBDADEAMQAAAIsTHAEAAAAA GRAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAA CAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAA AAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIA aQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwBy AGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAN 8JAAAAAAAJ8PBAAAAAQAAAAAAKAPDAAAAFAAYQBnAGUAIAAqAAAAoQ8cAAAABwAAAAAAEBAAAAoA VQAHAAAAAABDAAkACQAMAAAA2A8EAAAABQAAAAAAqg8aAAAABgAAAAcAAAAAAAcEAAABAAAABgAA AAkIAAAAAKYPFgAAAPEeAAD5Af0A/QD5AfkB9QL1AvED8QMPAATwAAEAABIACvAIAAAADXAAAAAK AADjAAvwVAAAAH8AAQAFAIAApC+IFoEACzkBAIIAhZwAAIMACzkBAIQAhZwAAIcAAQAAAL8AEAAf AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACCMAIvEMAAAAvwEAAGAAvwMAAAAE AAAQ8AgAAAAPAZsBqhQ0Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQCIFg8ADfBQAAAAAACfDwQAAAAA AAAAAACgDxgAAABVU/tRZGsEWRZ/kY/Na0hyB2iYmDdoD18AAKIPBgAAAA0AAAAAAAAAqg8OAAAA DQAAAAcAAAAAAAQICQQPAATwTgEAABIACvAIAAAAFXAAAAAKAAATAQvwZgAAAH8AAAAEAIAAYHGI FoEA3DgBAIIAbJwAAIMA3DgBAIQAbJwAAIUAAgAAAIcABgAAAL8AEgAfAD8BAAAGAIEBBAAACIMB AAAACL8BDAAeAMABAQAACP8BBgAOAD8CAAADAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEA AMABvwMAggCGfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADYD5QJlA19EA8A DfB6AAAAAACfDwQAAAAEAAAAAACoDxQAAABIdWF3ZWkgQ29uZmlkZW50aWFsIAAAoQ8YAAAAFQAA AAAAAAAAABUAAAAAAEMACQAJAAwAAACqDwwAAAAVAAAABgAAAAkEBAgAAKYPFgAAAPEeAAD5Af0A /QD5AfkB9QL1AvED8QMPAATwJAYAABIACvAIAAAAFnAAAAAKAADTAAvwTgAAAH8AAAAFAIAAqKaI FoEA/DgBAIIAf5wAAIMA/DgBAIQAf5wAAL8AEAAfAIEBBAAACIMBAAAACL8BAAARAMABAQAACP8B AAAJAAECAgAACCMAIvEMAAAAvwEAAGAAvwMAAAAEAAAQ8AgAAABNAU772P9cDg8ADfCSBQAAAACf DwQAAAAHAAAAAACgD/YBAADxgodlB2iYmDoAMwAyAC0AMwA1AHAAdAAgACAADQCcmHKCOgAgAFIA MQA1ADMAIABHADAAIABCADAADQCFUeiQf08odVdbU08gADoADQBGAHIAdQB0AGkAZwBlAHIATgBl AHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBtAA0AFlnokH9PKHVXW1NPIAA6ACAAQQByAGkAYQBsAA0A DQAtTodlB2iYmDoAMwAwAC0AMwAyAHAAdAAgACAADQCcmHKCOgAgAFIAMQA1ADMAIABHADAAIABC ADAADQBXW1NPOgDRnlNPDQANAA0ADQDxgodlY2uHZToAMgAwAC0AMgAyAHAAdAANAFBb7nZVXyAA KAAyAC0ANQCnfikAIAA6ADEAOABwAHQAIAAgAA0AnJhygjoA0Z5ygg0AhVHokH9PKHVXW1NPIAA6 AA0ARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAA0AFlnokH9P KHVXW1NPIAA6ACAAQQByAGkAYQBsAA0ADQAtTodlY2uHZToAMQA4AC0AMgAwAHAAdAANAFBb7nZV XygAMgAtADUAp34pADoAMQA4AHAAdAAgAA0AnJhygjoA0Z5ygg0AV1tTTzoAxn7RnlNPIAANAA0A DQANAA0AAAChD0gBAABNAAAAAAABGAAADgACAH0AAQAAAAAAARgAAA4AAgBLAH0AAAAAAAEYAAAO AAIAfQABAAAAAAABGAAADgACAEsAMAAAAAAAARgAAA4AAgB9AB4AAAABAEcAAAAAAAAACwAAAAAA LwAAAAEABgAAAAsAAAAAAAYAAAABAEcAAAAAAAAACwAAAAAAHgAAAAEERwAABAAAAAALAAAAAAAn AAAAAQBHAAAAAAAAAAsAAAAAAAMAAAABBEcAAAQAAAAACwAAAAAAMAAAAAEABgAAAAsAAAAAAAEA AAABAEcAAAAAAAAACwAAAAAADQAAAAEERwAABAAAAAALAAAAAAAOAAAAAQBHAAAAAAAAAAsAAAAA ABIAAAABBEcAAAQAAAAACwAAAAAAAgAAAAEARwAAAAAAAAALAAAAAAABAAAAAQBDAAAAAAAAAAsA AACqDzACAAAEAAAABwAAAAAABAgJBAoAAAAGAAAACQQECAMAAAAHAAAAAAAECAkEDQAAAAYAAAAJ BAQIBwAAAAcAAAAAAAQICQQCAAAABgAAAAkEBAgMAAAABwAAAAMACQQECAsAAAAGAAAACQQECAcA AAAHAAAAAAAECAkECQAAAAYAAAAJBAQIBAAAAAcAAAAAAAQICQQKAAAABgAAAAkEBAgDAAAABwAA AAAABAgJBA0AAAAGAAAACQQECAIAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQICgAAAAcAAAAAAAQI CQQJAAAABgAAAAkEBAgEAAAABwAAAAAABAgJBAQAAAAGAAAACQQECAEAAAAHAAAAAAAECAkECgAA AAYAAAAJBAQIAgAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgKAAAABwAAAAAABAgJBAIAAAAGAAAA CQQECAwAAAAHAAAAAwAJBAQIDAAAAAYAAAAJBAQIBwAAAAcAAAAAAAQICQQJAAAABgAAAAkEBAgE AAAABwAAAAAABAgJBAkAAAAGAAAACQQECAMAAAAHAAAAAAAECAkEBAAAAAYAAAAJBAQIAQAAAAcA AAAAAAQICQQHAAAABgAAAAkEBAgDAAAABwAAAAAABAgJBAEAAAAGAAAACQQECAUAAAAHAAAAAAAE CAkEAQAAAAYAAAAJBAQIBwAAAAcAAAAAAAQICQQCAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBA8A BPDMAQAAEgAK8AgAAAA+cAAAAAoAANMAC/BOAAAAfwAAAAUAgACYRIYWgQD8OAEAggB/nAAAgwD8 OAEAhAB/nAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI/wEAAAkAAQICAAAIIwAi8QwA AAC/AQAAYAC/AwAAAAQAABDwCAAAAIEDoxY4GXAIDwAN8DoBAAAAAJ8PBAAAAAcAAAAAAKAPcAAA AE2RcoLCUwOAuWVIaBr/DQD6Xq6LDFQATnWYYpeFUQ1OhY3Hj9tWzXmcmHKCDP/lTgtOL2YxADMA xH5NkXKCuWVIaAz/DFQATnWYYpeFUepTCZDpYgBOxH5/Tyh1AjAI/8VOm0/CUwOACf8NAA0ADQAA AKEPZAAAADYAAAAAAAEQAAAOAHgAAQAAAAAAARAAAA4AfQACAAAAAAAAEAAAfQA1AAAAAQBHAAAA BQAFAAsAAAAAAAEAAAABBEcAAAQFAAUACwAAAAAAAwAAAAEARwAAAAUABQALAAAAAAAAAKoPQgAA ABoAAAAHAAAAAAAECAkEAgAAAAYAAAAJBAQIGgAAAAcAAAAAAAQICQQCAAAABgAAAAkEBAgBAAAA BwAAAAAABAgJBA8ABPBqAQAAEgAK8AgAAABBcAAAAAoAANMAC/BOAAAAfwAAAAUAgAD0RIYWgQD8 OAEAggB/nAAAgwD8OAEAhAB/nAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI/wEAAAkA AQICAAAIIwAi8QwAAAC/AQAAYAC/AwAAAAQAABDwCAAAANn/oxY4GekBDwAN8NgAAAAAAJ8PBAAA AAcAAAAAAKAPKAAAAKJbN2IWYgWACFRcTxlPNE+Edgdo118+ZShX81MKTtKJLgANAA0ADQAAAKEP ZAAAABIAAAAAAAEQAAAOAHgAAQAAAAAAARAAAA4AfQACAAAAAAAAEAAAfQARAAAAAQBHAAAABQAF AAsAAAAAAAEAAAABBEcAAAQFAAUACwAAAAAAAwAAAAEARwAAAAUABQALAAAAAAAAAKoPKAAAABAA AAAHAAAAAAAECAkEBAAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQPAATwMgEAABIACvAIAAAARHAA AAAKAADTAAvwTgAAAH8AAQAFAIAArD+IFoEAGDkBAIIAjJwAAIMAGDkBAIQAjJwAAL8AEAAfAIEB BAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACCMAIvEMAAAAvwEAAGAAvwMAAAAEAAAQ 8AgAAAAKBJsBHhVcDg8AEfAQAAAAAADDCwgAAAABAAAAAgCIFg8ADfCIAAAAAACfDwQAAAABAAAA AACgDzgAAABVU/tRZGsEWRZ/kY/Na0hyh2UsZzdoD18NACx7jE6nfg0ALHsJTqd+DQAse9tWp34N ACx7lE6nfgAAog8eAAAADQAAAAAABAAAAAEABAAAAAIABAAAAAMABAAAAAQAAACqDw4AAAAdAAAA BwAAAAAABAgJBA8ABPC0AAAAEgAK8AgAAABQcAAAAAoAANMAC/BOAAAAgQAhZQEAggCQsgAAgwAh ZQEAhACQsgAAhwABAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4APwIAAAMA fwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIZ/BQYATgC/BQYATgD/BQYATgA/ BgYATgB/BgYADgAAABDwCAAAAHAIzxYSGQcRDwAD8KwCAAAPAATwVAAAAAEACfAQAAAABRcAAFMJ AADXGAAAxgkAAAIACvAIAAAAUXAAAAECAAATAAvwBgAAAIgDAAAAABMAIvEGAAAAvwMAAAAEAAAQ 8AgAAABTCQUX1xjGCQ8ABPCMAAAAEgAK8AgAAABScAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAA gQH/zGYAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/ BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAHoXAABTCQAA7hcAAMYJAAAPAATwjAAAABIA CvAIAAAAU3AAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB/5kAAIMBAAAACL8BEAAQAMABAQAA CP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgA AAAP8BAAAADuFwAAUwkAAGIYAADGCQAADwAE8IwAAAASAArwCAAAAFRwAACCCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAZlmCgCDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8B AABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAAYhgAAFMJAADXGAAAxgkA AA8ABPCMAAAAEgAK8AgAAABVcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQH/zJkAgwEAAAAI vwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/ BQAACAA/BgAACAAAAA/wEAAAAAUXAABTCQAAehcAAMYJAAAPAAPwrAIAAA8ABPBUAAAAAQAJ8BAA AAAFFwAA2wkAANcYAABOCgAAAgAK8AgAAABWcAAAAQIAABMAC/AGAAAAiAMAAAAAEwAi8QYAAAC/ AwAAAAQAABDwCAAAANsJBRfXGE4KDwAE8IwAAAASAArwCAAAAFdwAACCCgAAgwAL8DAAAACFAAIA AACHAAEAAACBAZnM/wCDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABg AL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAAehcAANsJAADuFwAATgoAAA8A BPCMAAAAEgAK8AgAAABYcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQGZzMwAgwEAAAAIvwEQ ABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAA CAA/BgAACAAAAA/wEAAAAO4XAADbCQAAYhgAAE4KAAAPAATwjAAAABIACvAIAAAAWXAAAIIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBAJmZAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMA IvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAABiGAAA2wkA ANcYAABOCgAADwAE8IwAAAASAArwCAAAAFpwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAczM /wCDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAI AL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAABRcAANsJAAB6FwAATgoAAA8AA/CsAgAADwAE8FQA AAABAAnwEAAAAAUXAABjCgAA1xgAANYKAAACAArwCAAAAFtwAAABAgAAEwAL8AYAAACIAwAAAAAT ACLxBgAAAL8DAAAABAAAEPAIAAAAYwoFF9cY1goPAATwjAAAABIACvAIAAAAXHAAAIIKAACDAAvw MAAAAIUAAgAAAIcAAQAAAIEBmczMAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEk AAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAAB6FwAAYwoAAO4X AADWCgAADwAE8IwAAAASAArwCAAAAF1wAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQCZzACD AQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8F AAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAA7hcAAGMKAABiGAAA1goAAA8ABPCMAAAAEgAK8AgAAABe cAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEAZpkAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgA AQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAA AGIYAABjCgAA1xgAANYKAAAPAATwjAAAABIACvAIAAAAX3AAAIIKAACDAAvwMAAAAIUAAgAAAIcA AQAAAIEBzP+ZAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMA BAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAAAFFwAAYwoAAHoXAADWCgAADwAD8KwC AAAPAATwVAAAAAEACfAQAAAABRcAAMsIAADXGAAAQgkAAAIACvAIAAAAYHAAAAECAAATAAvwBgAA AIgDAAAAABMAIvEGAAAAvwMAAAAEAAAQ8AgAAADLCAUX1xhCCQ8ABPCMAAAAEgAK8AgAAABhcAAA ggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQH/mQAAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAO4X AADLCAAAYhgAAEIJAAAPAATwjAAAABIACvAIAAAAYnAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAA AIEBzMzMAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAE fwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAABiGAAAywgAANcYAABCCQAADwAE8IwAAAAS AArwCAAAAGNwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAZnM/wCDAQAAAAi/ARAAEADAAQEA AAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAI AAAAD/AQAAAABRcAAMsIAAB6FwAAQgkAAA8ABPCMAAAAEgAK8AgAAABkcAAAggoAAIMAC/AwAAAA hQACAAAAhwABAAAAgQFmmQAAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/ AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAHoXAADLCAAA7hcAAEIJ AAAPAAPwrAIAAA8ABPBUAAAAAQAJ8BAAAAAFFwAARgsAANcYAAC5CwAAAgAK8AgAAABlcAAAAQIA ABMAC/AGAAAAiAMAAAAAEwAi8QYAAAC/AwAAAAQAABDwCAAAAEYLBRfXGLkLDwAE8IwAAAASAArw CAAAAGZwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAf+ZAACDAQAAAAi/ARAAEADAAQEAAAj/ AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAA D/AQAAAAehcAAEYLAADuFwAAuQsAAA8ABPCMAAAAEgAK8AgAAABncAAAggoAAIMAC/AwAAAAhQAC AAAAhwABAAAAgQH/zJkAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAA YAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAO4XAABGCwAAYhgAALkLAAAP AATwjAAAABIACvAIAAAAaHAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB/8xmAIMBAAAACL8B EAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUA AAgAPwYAAAgAAAAP8BAAAABiGAAARgsAANcYAAC5CwAADwAE8IwAAAASAArwCAAAAGlwAACCCgAA gwAL8DAAAACFAAIAAACHAAEAAACBAQMAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhj ACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAABRcAAEYL AAB6FwAAuQsAAA8AA/CsAgAADwAE8FQAAAABAAnwEAAAAAUXAADOCwAA1xgAAEEMAAACAArwCAAA AGpwAAABAgAAEwAL8AYAAACIAwAAAAATACLxBgAAAL8DAAAABAAAEPAIAAAAzgsFF9cYQQwPAATw jAAAABIACvAIAAAAa3AAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBAGaZAIMBAAAACL8BEAAQ AMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgA PwYAAAgAAAAP8BAAAAB6FwAAzgsAAO4XAABBDAAADwAE8IwAAAASAArwCAAAAGxwAACCCgAAgwAL 8DAAAACFAAIAAACHAAEAAACBAZnM/wCDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLx JAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAA7hcAAM4LAABi GAAAQQwAAA8ABPCMAAAAEgAK8AgAAABtcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQHMzP8A gwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/ BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAGIYAADOCwAA1xgAAEEMAAAPAATwjAAAABIACvAIAAAA bnAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBmQAAAIMBAAAACL8BEAAQAMABAQAACP8BAAAI AAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAA AAAFFwAAzgsAAHoXAABBDAAADwAD8KwCAAAPAATwVAAAAAEACfAQAAAABRcAAFYMAADXGAAAyQwA AAIACvAIAAAAb3AAAAECAAATAAvwBgAAAIgDAAAAABMAIvEGAAAAvwMAAAAEAAAQ8AgAAABWDAUX 1xjJDA8ABPCMAAAAEgAK8AgAAABwcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEAmZkAgwEA AAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAA CAD/BQAACAA/BgAACAAAAA/wEAAAAHoXAABWDAAA7hcAAMkMAAAPAATwjAAAABIACvAIAAAAcXAA AIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBzP+ZAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAEC AgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAADu FwAAVgwAAGIYAADJDAAADwAE8IwAAAASAArwCAAAAHJwAACCCgAAgwAL8DAAAACFAAIAAACHAAEA AACBAZnMzACDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQA BH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAAYhgAAFYMAADXGAAAyQwAAA8ABPCMAAAA EgAK8AgAAABzcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQGZAAAAgwEAAAAIvwEQABAAwAEB AAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAA CAAAAA/wEAAAAAUXAABWDAAAehcAAMkMAAAPAAPwrAIAAA8ABPBUAAAAAQAJ8BAAAAAFFwAAOQ0A ANcYAACsDQAAAgAK8AgAAAB0cAAAAQIAABMAC/AGAAAAiAMAAAAAEwAi8QYAAAC/AwAAAAQAABDw CAAAADkNBRfXGKwNDwAE8IwAAAASAArwCAAAAHVwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACB Af+ZAACDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8F AAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAAehcAADkNAADuFwAArA0AAA8ABPCMAAAAEgAK 8AgAAAB2cAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQH/zJkAgwEAAAAIvwEQABAAwAEBAAAI /wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAA AA/wEAAAAO4XAAA5DQAAYhgAAKwNAAAPAATwjAAAABIACvAIAAAAd3AAAIIKAACDAAvwMAAAAIUA AgAAAIcAAQAAAIEB/8xmAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEA AGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAABiGAAAOQ0AANcYAACsDQAA DwAE8IwAAAASAArwCAAAAHhwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQEAAAiDAQAAAAi/ ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8F AAAIAD8GAAAIAAAAD/AQAAAABRcAADkNAAB6FwAArA0AAA8AA/CsAgAADwAE8FQAAAABAAnwEAAA AAUXAADBDQAA1xgAADQOAAACAArwCAAAAHlwAAABAgAAEwAL8AYAAACIAwAAAAATACLxBgAAAL8D AAAABAAAEPAIAAAAwQ0FF9cYNA4PAATwjAAAABIACvAIAAAAenAAAIIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBAGaZAIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAA vwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAAB6FwAAwQ0AAO4XAAA0DgAADwAE 8IwAAAASAArwCAAAAHtwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAZnM/wCDAQAAAAi/ARAA EADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAI AD8GAAAIAAAAD/AQAAAA7hcAAMENAABiGAAANA4AAA8ABPCMAAAAEgAK8AgAAAB8cAAAggoAAIMA C/AwAAAAhQACAAAAhwABAAAAgQHMzP8AgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi 8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAGIYAADBDQAA 1xgAADQOAAAPAATwjAAAABIACvAIAAAAfXAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBAQAA CIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgA vwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAAAFFwAAwQ0AAHoXAAA0DgAADwAD8KwCAAAPAATwVAAA AAEACfAQAAAABRcAAEkOAADXGAAAvA4AAAIACvAIAAAAfnAAAAECAAATAAvwBgAAAIgDAAAAABMA IvEGAAAAvwMAAAAEAAAQ8AgAAABJDgUX1xi8Dg8ABPCMAAAAEgAK8AgAAAB/cAAAggoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQEAmZkAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQA AAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAHoXAABJDgAA7hcA ALwOAAAPAATwjAAAABIACvAIAAAAgHAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBzP+ZAIMB AAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUA AAgA/wUAAAgAPwYAAAgAAAAP8BAAAADuFwAASQ4AAGIYAAC8DgAADwAE8IwAAAASAArwCAAAAIFw AACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAZnMzACDAQAAAAi/ARAAEADAAQEAAAj/AQAACAAB AgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAA YhgAAEkOAADXGAAAvA4AAA8ABPCMAAAAEgAK8AgAAACCcAAAggoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQEBAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAE AAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAAUXAABJDgAAehcAALwOAAAPAAPwrAIA AA8ABPBUAAAAAQAJ8BAAAAAFFwAALA8AANcYAACfDwAAAgAK8AgAAACDcAAAAQIAABMAC/AGAAAA iAMAAAAAEwAi8QYAAAC/AwAAAAQAABDwCAAAACwPBRfXGJ8PDwAE8IwAAAASAArwCAAAAIRwAACC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAf+ZAACDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIA AAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAAehcA ACwPAADuFwAAnw8AAA8ABPCMAAAAEgAK8AgAAACFcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAA gQH/zJkAgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/ BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAAAO4XAAAsDwAAYhgAAJ8PAAAPAATwjAAAABIA CvAIAAAAhnAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB/8xmAIMBAAAACL8BEAAQAMABAQAA CP8BAAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgA AAAP8BAAAABiGAAALA8AANcYAACfDwAADwAE8IwAAAASAArwCAAAAIdwAACCCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAQIAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8B AABgAL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAABRcAACwPAAB6FwAAnw8A AA8AA/CsAgAADwAE8FQAAAABAAnwEAAAAAUXAAC6DwAA1xgAAC0QAAACAArwCAAAAIhwAAABAgAA EwAL8AYAAACIAwAAAAATACLxBgAAAL8DAAAABAAAEPAIAAAAug8FF9cYLRAPAATwjAAAABIACvAI AAAAiXAAAIIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBAGaZAIMBAAAACL8BEAAQAMABAQAACP8B AAAIAAECAgAACGMAIvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP 8BAAAAB6FwAAug8AAO4XAAAtEAAADwAE8IwAAAASAArwCAAAAIpwAACCCgAAgwAL8DAAAACFAAIA AACHAAEAAACBAZnM/wCDAQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABg AL8DAAQABH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAA7hcAALoPAABiGAAALRAAAA8A BPCMAAAAEgAK8AgAAACLcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQHMzP8AgwEAAAAIvwEQ ABAAwAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAA CAA/BgAACAAAAA/wEAAAAGIYAAC6DwAA1xgAAC0QAAAPAATwjAAAABIACvAIAAAAjHAAAIIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBAgAACIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMA IvEkAAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAAAFFwAAug8A AHoXAAAtEAAADwAD8KwCAAAPAATwVAAAAAEACfAQAAAABRcAAEcQAADXGAAAuhAAAAIACvAIAAAA jXAAAAECAAATAAvwBgAAAIgDAAAAABMAIvEGAAAAvwMAAAAEAAAQ8AgAAABHEAUX1xi6EA8ABPCM AAAAEgAK8AgAAACOcAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEGAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEAAAgAAQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/ BgAACAAAAA/wEAAAAHoXAABHEAAA7hcAALoQAAAPAATwjAAAABIACvAIAAAAj3AAAIIKAACDAAvw MAAAAIUAAgAAAIcAAQAAAIEBBQAACIMBAAAACL8BEAAQAMABAQAACP8BAAAIAAECAgAACGMAIvEk AAAAvwEAAGAAvwMABAAEfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAP8BAAAADuFwAARxAAAGIY AAC6EAAADwAE8IwAAAASAArwCAAAAJBwAACCCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiD AQAAAAi/ARAAEADAAQEAAAj/AQAACAABAgIAAAhjACLxJAAAAL8BAABgAL8DAAQABH8FAAAIAL8F AAAIAP8FAAAIAD8GAAAIAAAAD/AQAAAAYhgAAEcQAADXGAAAuhAAAA8ABPCMAAAAEgAK8AgAAACR cAAAggoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQECAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgA AQICAAAIYwAi8SQAAAC/AQAAYAC/AwAEAAR/BQAACAC/BQAACAD/BQAACAA/BgAACAAAAA/wEAAA AAUXAABHEAAAehcAALoQAAAPAATwSAAAABIACvAIAAAAAXAAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAAB3 d3cAmQAAAP/MmQD/zGYA/5kAAJlmAAAPAIgTRAAAAA8AihM8AAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLExwAAAAAAOouBAAAAAEAAAAAAOsuCAAAAKZpxgFAyOawIAC6Dw4AAABkAGUAZgBh AHUAbAB0AA8A7gMXDgAAAgDvAxgAAAACAAAAAwQHCQgAAAABAACAAAAAAAAACzAPAAwEew0AAA8A AvBzDQAA0AII8AgAAAALAAAAQqwAAA8AA/ALDQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAACsAAAFAAAADwAE8HAAAACyBArwCAAAAAmsAAAACgAAcwAL8DQAAAB/AAAA gAAEQQEAAAAFwQoAAAAGAQEAAAC/AQAAEAD/AQAACAA/AwAAEABMAG8AZwBvAAAAIwAi8QwAAAC/ AQAAYAC/AwAAAAQAABDwCAAAAMENehJbFKIPDwAE8FIAAACyBArwCAAAAAqsAAAACgAAQwAL8BwA AAB/AIAAgAAEQQQAAAAFwQQAAAAGAQEAAAAyAAAAEwAi8QYAAAC/AwAAAAQAABDwCAAAAO0BAACA Fk0LDwAE8PoAAAASAArwCAAAAA+sAAAACgAA4wAL8FQAAAB/AAEABQCAAJBlhhaBAAs5AQCCAIWc AACDAAs5AQCEAIWcAACHAAEAAAC/ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAAbQORAZ4OhwcPABHwEAAAAAAAwwsIAAAAAAAAAAMC hhYPAA3wUAAAAAAAnw8EAAAABgAAAAAAoA8YAAAAVVP7UWRrBFkWf5GPzWtIcgdomJg3aA9fAACi DwYAAAANAAAAAAAAAKoPDgAAAA0AAAAHAAAAAAAECAkEDwAE8PYAAAASAArwCAAAABCsAAAACgAA 0wAL8E4AAAB/AAEABQCAANjwhhaBAAs5AQCCAIWcAACDAAs5AQCEAIWcAAC/ABAAHwCBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAA1QevAb0O 9gkPABHwEAAAAAAAwwsIAAAAAQAAAAQChhYPAA3wUgAAAAAAnw8EAAAABQAAAAAAoA8aAAAAVVP7 UWRrBFkWf5GPzWtIcm9SB2iYmDdoD18AAKIPBgAAAA4AAAAAAAAAqg8OAAAADgAAAAcAAAAAAAQI CQQPAATwGwEAAKIMCvAIAAAAFKwAAAAKAADTAAvwTgAAAIAAzNhiFoEA/DgBAIIAf5wAAIMA/DgB AIQAf5wAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIABMA IvEGAAAAvwMAAAAEAAAQ8AgAAABGD5sBDQjrDw8ADfCPAAAAAACfDwQAAAAEAAAAAACoDx0AAABI VUFXRUkgVEVDSE5PTE9HSUVTIENPLiwgTFRELgAAoQ8kAAAAHgAAAAAAAAAAAB0AAAAAAEMACQAJ AAwAAQAAAAAEAgAABBYAAACqDwwAAAAeAAAABgAAAAkEBAgAAKYPFgAAAPEeAAD5Af0A/QD5AfkB 9QL1AvED8QMPAATwFAEAAKIMCvAIAAAAFqwAAAAKAADTAAvwTgAAAIAAGLJiFoEA/DgBAIIAf5wA AIMA/DgBAIQAf5wAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B AAAIABMAIvEGAAAAvwMAAAAEAAAQ8AgAAAATCscRExW4Cg8ADfCIAAAAAACfDwQAAAAEAAAAAACo Dw4AAAB3d3cuaHVhd2VpLmNvbQAAoQ8eAAAADwAAAAAAAAAAAA8AAAAABEcAAAQEAAQADAAAAAAA AACqDxoAAAAOAAAABwAAAAMACQQECAEAAAAGAAAACQQECAAApg8WAAAA8R4AAPkB/QD9APkB+QH1 AvUC8QPxAw8ABPBOAQAAEgAK8AgAAAAXrAAAAAoAABMBC/BmAAAAfwAAAAQAgABotmIWgQDcOAEA ggBsnAAAgwDcOAEAhABsnAAAhQACAAAAhwAGAAAAvwASAB8APwEAAAYAgQEEAAAIgwEAAAAIvwEM AB4AwAEBAAAI/wEGAA4APwIAAAMAfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCC AIZ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAEYPzgnODesPDwAN8HoAAAAA AJ8PBAAAAAQAAAAAAKgPFAAAAEh1YXdlaSBDb25maWRlbnRpYWwgAAChDxgAAAAVAAAAAAAAAAAA FQAAAAAAQwAJAAkADAAAAKoPDAAAABUAAAAGAAAACQQECAAApg8WAAAA8R4AAPkB/QD9APkB+QH1 AvUC8QPxAw8ABPCgAQAAEgAK8AgAAAAZrAAAAAoAABMBC/BmAAAAfwAAAAQAgABgSmIWgQDcOAEA ggBsnAAAgwDcOAEAhABsnAAAhQACAAAAhwAGAAAAvwASAB8APwEAAAYAgQEEAAAIgwEAAAAIvwEM AB4AwAEBAAAI/wEGAA4APwIAAAMAfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCC AIZ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAJwAtxAUFlQBDwAN8MwAAAAA AJ8PBAAAAAQAAAAAAKAPKAAAAFMAZQBjAHUAcgBpAHQAeQAgAEwAZQB2AGUAbAA6AIVR6JBsUQBf IAAAAKEPSAAAABUAAAAAAAAAAAAPAAAAAQBHAAEABAAEAA4AZmZm/gQAAAABBGcAAQQEAAgABAAO AGZmZv4CAAAAAQhHAAEIBAAEAA4AZmZm/gAAqg8aAAAADwAAAAYAAAAJBAQIBgAAAAcAAAAAAAQI CQQAAKYPFgAAAPEeAAD5Af0A/QD5AfkB9QL1AvED8QMPAATwLAEAABIACvAIAAAAGqwAAAAKAADT AAvwTgAAAH8AAQAFAIAAnF9iFoEACzkBAIIAhZwAAIMACzkBAIQAhZwAAL8AEAAfAIEBBAAACIMB AAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACCMAIvEMAAAAvwEAAGAAvwMAAAAEAAAQ8AgAAACy AK8B7wbdAQ8AEfAQAAAAAADDCwgAAAACAAAABwJiFg8ADfCCAAAAAACfDwQAAAAEAAAAAACgDwIA AAAqAAAAoQ8YAAAAAgAAAAAAAAAAAAIAAAAAAEMABAAEAAwAAAD4DwQAAAAAAAAAAACqDxoAAAAB AAAABwAAAAAABAgJBAEAAAAGAAAACQQECAAApg8WAAAA8R4AAPkB/QD9APkB+QH1AvUC8QPxAw8A BPCQAwAAogwK8AgAAABCrAAAAAoAANMAC/BOAAAAgAAcImIWgQALOQEAggCFnAAAgwALOQEAhACF nAAAvwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4APwIAAAMAfwMAAA8AkwAi8TYA AAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIZ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAA ABDwCAAAAEEDKPsAAH0MDwAN8NQCAAAAAJ8PBAAAAAQAAAAAAKAPDgEAAPGCh2UHaJiYOgA0ADAA LQA0ADcAcAB0ACAAIAANAG9SB2iYmDoAMgA2AC0AMwAwAHAAdAANAFdbU0+cmHKCOgDNU312DQCF UeiQf08odVdbU08gADoADQBGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkA dQBtAA0AFlnokH9PKHVXW1NPIAA6ACAAQQByAGkAYQBsAA0ADQANAC1Oh2UHaJiYOgAzADUALQA0 ADcAcAB0AA0AV1tTTzoA0Z5TTw0AIAAgAG9SB2iYmDoAMgA0AC0AMgA4AHAAdAANAFdbU0+cmHKC OgDNU312DQBXW1NPOgDGftGeU08NAA0ADQANAAAAoQ8+AAAAhwAAAAAAABgAAAIAfQABAAAAAAAA OAAAAgB9ADIAhwAAAAAEJgAABAUACwAAAAAAAQAAAAAEIgAABAUACwAAAKoPRgEAAAQAAAAHAAAA AAAECAkECwAAAAYAAAAJBAQIAwAAAAcAAAAAAAQICQQJAAAABgAAAAkEBAgEAAAABwAAAAAABAgJ BAEAAAAGAAAACQQECAoAAAAHAAAAAAAECAkEAgAAAAYAAAAJBAQIDAAAAAcAAAADAAkEBAgLAAAA BgAAAAkEBAgHAAAABwAAAAAABAgJBAcAAAAGAAAACQQECAcAAAAHAAAAAAAECAkECQAAAAYAAAAJ BAQIAgAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgDAAAABwAAAAAABAgJBAIAAAAGAAAACQQECAMA AAAHAAAAAAAECAkECAAAAAYAAAAJBAQIBQAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgFAAAABwAA AAAABAgJBAEAAAAGAAAACQQECAgAAAAHAAAAAAAECAkEAACmDxYAAADxHgAA+QH9AP0A+QH5AfUC 9QLxA/EDDwAE8EgAAAASAArwCAAAAAGsAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCU Ad69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zJkA /8xmAP+ZAACZZgAADwCIE0QAAAAPAIoTPAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMc AAAAAADqLgQAAAABAAAAAADrLggAAABAa8YBwJuCgA8A+APODQAAAgDvAxgAAAABAAAAAQIHCQgA AAAAAAAAAAAAAAAACzBgAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZAP+ZAACZAAAAYADw ByAAAAD///8AAAAAAHd3dwCZAAAAzMz/AJnM/wAAZpkAmQAAAGAA8AcgAAAA////AAAAAAB3d3cA mQAAAJnMzADM/5kAAJmZAJkAAABgAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZAP+ZAAAA AAAAYADwByAAAAD///8AAAAAAHd3dwCZAAAAzMz/AJnM/wAAZpkAAAAAAGAA8AcgAAAA////AAAA AAB3d3cAmQAAAJnMzADM/5kAAJmZAAAAAABgAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZ AP+ZAACWlpYAYADwByAAAAD///8AAAAAAHd3dwCZAAAAzMz/AJnM/wAAZpkAlpaWAGAA8AcgAAAA ////AAAAAAB3d3cAmQAAAJnMzADM/5kAAJmZAJaWlgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA /wAAZAAAAAAAAAAAAPkBAAAAAAcAAAD//+8AAAAAAAMAAAD//yMAmQAA/gAAEACjD5AAAAAFAP/9 PwABACIgAABkAAAAAP8AAIwAAAAAAL0AAAD5AQAAAAAHAAAA///vAAEAAAAFAAUA//8aAAAAAAEA APoFAAALAHAABgAyAAAAAAGbAf0AAQACAAAAGACABQAAbgB4AvkBAAACABYA2AUAAAMAEyAAAGQA cwP1AgAAAgAUAIAFAAB+AHAE8QMAAAIAEgAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAe AAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAgAAAD//wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAAB AAEJAAAKAAEA/QAAAAAAAgABCQAACgABAPkBAAAAAAMAAQkAAAIAAQD1AgAAAAAEAAEJAAACAAEA 8QMAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABcAAQAAAAAAAAAC ABQAAgAAAAAAAAACABAAAwAAAAAAAAACABIABAAAAAAAAAACABAAgACjDz4AAAAFAAAAAAAAAAAA AgASAAEAAAAAAAAAAgAQAAIAAAAAAAAAAgAPAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAPAA8ADARi CQAADwAC8FoJAADwBAjwCAAAAAUAAAALfAEADwAD8PIIAAAPAATwKAAAAAEACfAQAAAAAAAAAAAA AAAAAAAAAAAAAAIACvAIAAAAAHwBAAUAAAAPAATwugAAABIACvAIAAAACHwBAAAKAADjAAvwVAAA AIEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAQAAAL8AAgAPAIEB3d3dAIMBAAAACL8B HAAeAMABAQAACP8BBgAOAD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMA ggCGfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAAAAAAgBbgEA8ABPAAAQAA EgAK8AgAAAACfAEAAAoAAOMAC/BUAAAAfwABAAUAgADc8mIWgQAYOQEAggCMnAAAgwAYOQEAhACM nAAAhwABAAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIIwAi8QwA AAC/AQAAYAC/AwAAAAQAABDwCAAAAJIBmwEeFbYDDwAR8BAAAAAAAMMLCAAAAAAAAAABAGIWDwAN 8FAAAAAAAJ8PBAAAAAAAAAAAAKAPGAAAAFVT+1FkawRZFn+Rj81rSHIHaJiYN2gPXwAAog8GAAAA DQAAAAAAAACqDw4AAAANAAAABwAAAAAABAgJBA8ABPAyAQAAEgAK8AgAAAADfAEAAAoAANMAC/BO AAAAfwABAAUAgACIRWIWgQAYOQEAggCMnAAAgwAYOQEAhACMnAAAvwAQAB8AgQEEAAAIgwEAAAAI vwEBABEAwAEBAAAI/wEBAAkAAQICAAAIIwAi8QwAAAC/AQAAYAC/AwAAAAQAABDwCAAAAAoEmwEe FVwODwAR8BAAAAAAAMMLCAAAAAEAAAACAGIWDwAN8IgAAAAAAJ8PBAAAAAEAAAAAAKAPOAAAAFVT +1FkawRZFn+Rj81rSHKHZSxnN2gPXw0ALHuMTqd+DQAsewlOp34NACx721anfg0ALHuUTqd+AACi Dx4AAAANAAAAAAAEAAAAAQAEAAAAAgAEAAAAAwAEAAAABAAAAKoPDgAAAB0AAAAHAAAAAAAECAkE DwAE8LYFAAASAArwCAAAAAd8AQAACgAA0wAL8E4AAAB/AAAABQCAAAwUYROBAPw4AQCCAH+cAACD APw4AQCEAH+cAAC/ABAAHwCBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgjACLx DAAAAL8BAABgAL8DAAAABAAAEPAIAAAANgJ2+wAARg8PAA3wJAUAAAAAnw8EAAAABwAAAAAAoA8Q AgAA8YKHZe52VV8HaJiYOgAzADUALQA0ADAAcAB0ACAAIAANAJyYcoI6ACAAUgAxADUAMwAgAEcA MAAgAEIAMAANAIVR6JB/Tyh1V1tTTyAAOgANAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABU ACAATQBlAGQAaQB1AG0ADQAWWeiQf08odVdbU08gADoAIABBAHIAaQBhAGwADQANAC1Oh2XudlVf B2iYmDoAMwA1AC0ANAAwAHAAdAAgACAADQCcmHKCOgAgAFIAMQA1ADMAIABHADAAIABCADAADQBX W1NPOgDRnlNPDQANAA0A8YKHZe52VV9ja4dlOgAyADgALQAzADAAcAB0AA0AUFvudlVfIAAoADIA LQA1AKd+KQAgADoAMgAwAC0AMwAwAHAAdAAgACAADQCcmHKCOgDRnnKCDQCFUeiQf08odVdbU08g ADoADQBGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIADQAWWeiQ f08odVdbU08gADoAIABBAHIAaQBhAGwADQANAC1Oh2XudlVfY2uHZToAMgA4AC0AMwAwAHAAdAAN AFBb7nZVXygAMgAtADUAp34pADoAMgAwAC0AMwAwAHAAdAAgAA0AnJhygjoA0Z5ygg0AV1tTTzoA xn7RnlNPIAANAA0ADQANAA0AAAChD8AAAAAJAQAAAAABGAAAAAACAH0AVwAAAAEARgAAAAAACwAA AAAAHgAAAAEERgAABAAACwAAAAAAKwAAAAEARgAAAAAACwAAAAAAAwAAAAEERgAABAAACwAAAAAA MQAAAAEARgAAAAAACwAAAAAADwAAAAEERgAABAAACwAAAAAAEQAAAAEARgAAAAAACwAAAAAAEgAA AAEERgAABAAACwAAAAAAAgAAAAEARgAAAAAACwAAAAAAAQAAAAEAQgAAAAAACwAAAKoPMAIAAAYA AAAHAAAAAAAECAkECgAAAAYAAAAJBAQIAwAAAAcAAAAAAAQICQQNAAAABgAAAAkEBAgHAAAABwAA AAAABAgJBAIAAAAGAAAACQQECAwAAAAHAAAAAwAJBAQICwAAAAYAAAAJBAQIBwAAAAcAAAAAAAQI CQQJAAAABgAAAAkEBAgGAAAABwAAAAAABAgJBAoAAAAGAAAACQQECAMAAAAHAAAAAAAECAkEDQAA AAYAAAAJBAQIAgAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgLAAAABwAAAAAABAgJBAkAAAAGAAAA CQQECAQAAAAHAAAAAAAECAkEBAAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQNAAAABgAAAAkEBAgC AAAABwAAAAAABAgJBAEAAAAGAAAACQQECAoAAAAHAAAAAAAECAkEAgAAAAYAAAAJBAQIDAAAAAcA AAADAAkEBAgMAAAABgAAAAkEBAgHAAAABwAAAAAABAgJBAkAAAAGAAAACQQECAYAAAAHAAAAAAAE CAkECQAAAAYAAAAJBAQIAwAAAAcAAAAAAAQICQQEAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAoA AAAGAAAACQQECAMAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIBQAAAAcAAAAAAAQICQQBAAAABgAA AAkEBAgHAAAABwAAAAAABAgJBAIAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEDwAE8EgAAAASAArw CAAAAAF8AQAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAd3d3AJkAAAD/zGYA/8yZAP+ZAACZAAAADwCIE0QA AAAPAIoTPAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMcAAAAAADqLgQAAAABAAAAAADr LggAAADoesYBsBmFlCAAug8SAAAAMgBfAOqBmltJTr6LoYu5ZUhoDwD4AzMMAAACAO8DGAAAAAEA AAABAgcJCAAAAAAAAAAAAAAAAAALMGAA8AcgAAAA////AAAAAAB3d3cAmQAAAP/MmQD/zGYA/5kA AJlmAAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAPkBAAAAAAcAAAD//+8A AAAAAAgAAAD//yYAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAAL0AAAD5 AQAAAAAHAAAA///vAAAAAAAIAAAA//8cAAAAAAEAAIAFAAATIJsB/QAAAAIAGQCABQAAIiB4AvkB AAACABYAgAUAABMgcwP1AgAAAgARAIAFAAC7AHAE8QMAAAAAIACjD24AAAAFAP/9PwAAACIgAABk AAAAAAAAAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAAIAAAA//8MAAAAAAEAAAAFAAAgASAB AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAA AAEAAAAAAAAAAQABCQAAAAABAP0AAAAAAAIAAQkAAAAAAQD5AQAAAAADAAEJAAAAAAEA9QIAAAAA BAABCQAAAAABAPEDAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAZ AAEAAAAAAAAAAgAWAAIAAAAAAAAAAgARAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAIAAow8+AAAA BQAAAAAAAAAAAAIAFgABAAAAAAAAAAIAEQACAAAAAAAAAAIAEAADAAAAAAAAAAIADgAEAAAAAAAA AAIADgAPAAwEGwkAAA8AAvATCQAA8AMI8AgAAAAEAAAACPgAAA8AA/CrCAAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAD4AAAFAAAADwAE8FIAAACyBArwCAAAAAb4AAAA CgAAQwAL8BwAAAB/AIAAgAAEQQIAAAAFwQQAAAAGAQEAAAA1AAAAEwAi8QYAAAC/AwAAAAQAABDw CAAAAIMOAACAFvsQDwAE8P8DAACiDArwCAAAAAf4AAAACgAA0wAL8E4AAACAAPx3YROBAPhFAQCC APyiAACDAPhFAQCEAPyiAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQAACAATACLxBgAAAL8DAAAABAAAEPAIAAAAlQb1B8wObwgPABHw7AIAAA8AiBPkAgAADwCK E1YCAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AQQBDADEAMQAAAIsTMAIAAAAAGRAoAgAAAAAACAwB AAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAAB AAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAA AAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgA AAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAA AQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAAB DAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAA AAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhu YW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAA AAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgA AAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwCKEzQAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAAAAAAQBAAAADwCKE0IAAAAAALoPDgAAAF8AXwBf AFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAQAAAAAAAAAPAA3w fwAAAAAAnw8EAAAABAAAAAAAqA8JAAAAVGhhbmsgeW91AAChDygAAAAKAAAAAAAAAAAACQAAAAAA BgAsAJkAAP4BAAAAAAQGAAAELACZAAD+AACqDwwAAAAKAAAABgAAAAkEBAgAAKYPFgAAAPEeAAAO AgcBBwEOAg4CFAMUAxsEGwQPAATwEgQAAKIMCvAIAAAACPgAAAAKAADTAAvwTgAAAIAAWHhhE4EA +EUBAIIA/KIAAIMA+EUBAIQA/KIAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BAAAIABMAIvEGAAAAvwMAAAAEAAAQ8AgAAAB0CBAIzQ6iCQ8AEfDsAgAADwCIE+QC AAAPAIoTVgIAAAAAug8WAAAAXwBfAF8AUABQAFQATQBBAEMAMQAxAAAAixMwAgAAAAAZECgCAAAA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIoTNAAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixMUAAAAAACxDwwAAAAAAAAAAAAABAEAAAAPAIoTQgAAAAAAug8OAAAA XwBfAF8AUABQAFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABAAAAAAAA AA8ADfCSAAAAAACfDwQAAAAEAAAAAACoDw4AAAB3d3cuaHVhd2VpLmNvbQAAoQ8oAAAADwAAAAAA AAAAAA4AAAAAAAYAGgBmZmb+AQAAAAAEBgAABBUAmQAA/gAAqg8aAAAADgAAAAcAAAADAAkEBAgB AAAABgAAAAkEBAgAAKYPFgAAAPEeAAAOAgcBBwEOAg4CFAMUAxsEGwQPAATwSAAAABIACvAIAAAA AfgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAAB3d3cAmQAAAP/MmQD/zGYA/5kAAJlmAAAPAIgTRAAAAA8A ihM8AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExwAAAAAAOouBAAAAAEAAAAAAOsuCAAA AOlvxgFQP841IAC6DxIAAAAxAF8A6oGaW0lOvouhi7llSGgPAPgDSAkAAAIA7wMYAAAAAQAAAAEC BwkIAAAAAAAAAAAAAAAAAAswYADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwA AGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAA gICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAA ZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACA gAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf0pMAzDMA AL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAH IAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A////AHd3dwDR 0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8Amcz/AP// mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAA ACIgAABkAAAAAP8BAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAAIAAAA//8sAAAAAAMAABAA ow98AAAABQD//T8AAQAiIAAAZAAAAAD/AABkABQAAADYAAAAQAIAAAAABwAAAP//7wAAAAAACAAA AP//IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIA FACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIA AAAABwAAAP//7wAAAAAACAAAAP//DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAA YANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAg AQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMP DAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAA AAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAA AAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBIoEAAAPAALwggQA AJAFCPAIAAAABQAAAAYAAwAPAAPwGgQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAAAAMABQAAAA8ABPDcAAAAEgAK8AgAAAACAAMAAAoAAJMAC/A2AAAAfwABAAUAgADg noYWhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIEwAi8QYAAAC/AwAA AAQAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABAIYWDwAN8FAAAAAAAJ8PBAAA AAAAAAAAAKAPGAAAAFVT+1FkawRZFn+Rj81rSHIHaJiYN2gPXwAAog8GAAAADQAAAAAAAACqDw4A AAANAAAABwAAAAAABAgJBA8ABPAOAQAAEgAK8AgAAAADAAMAAAoAAIMAC/AwAAAAfwABAAUAgABc oYYWgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIEwAi8QYAAAC/AwAAAAQAABDw CAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAACAIYWDwAN8IgAAAAAAJ8PBAAAAAEAAAAA AKAPOAAAAFVT+1FkawRZFn+Rj81rSHKHZSxnN2gPXw0ALHuMTqd+DQAsewlOp34NACx721anfg0A LHuUTqd+AACiDx4AAAANAAAAAAAEAAAAAQAEAAAAAgAEAAAAAwAEAAAABAAAAKoPDgAAAB0AAAAH AAAAAAAECAkEDwAE8PAAAAASAArwCAAAAAUAAwAACgAAgwAL8DAAAAB/AAEABQCAAHB7hhaBAQQA AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAAXg+w B9AOihAPABHwEAAAAAAAwwsIAAAAAwAAAAkChhYPAA3wagAAAAAAnw8EAAAABAAAAAAAoA8CAAAA KgAAAKEPHgAAAAIAAAAAACAICgAAAAD/AQAHAAIAAAAAACIACAAOAAAA+g8EAAAAAAAAAAAAqg8a AAAAAQAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgPAATw8AAAABIACvAIAAAABgADAAAKAACDAAvw MAAAAH8AAQAFAIAADICGFoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACBMAIvEG AAAAvwMAAAAEAAAQ8AgAAABeDyAQYBWKEA8AEfAQAAAAAADDCwgAAAAEAAAACAKGFg8ADfBqAAAA AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAIAgKAAAAAP8CAAcAAgAAAAAAIgAI AA4AAADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPBIAAAA EgAK8AgAAAABAAMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEA AAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A iBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAUATK ATCeHnAgALoPDAAAANiepIu+i6GLIWp/Zw8A8AMoBgAAAQDxAwgAAAABAACAAAALMA8ADASoBQAA DwAC8KAFAACwAAjwCAAAAAcAAAAHDAAADwAD8DgFAAAPAATwKAAAAAEACfAQAAAAAQAAAAIAAAAA AAAAAAAAAAIACvAIAAAAAAwAAAUAAAAPAATw1AAAABIACvAIAAAAAgwAAAAKAABzAAvwKgAAAH8A AQABAIAAgHE3FoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAAAAAAFAHIAEP ABHwEAAAAAAAwwsIAAAAAAAAAAoCNxYPAA3wYgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEP FAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD5DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJ BAEAAAAHAAAAAAAJBAQIDwAE8NYAAAASAArwCAAAAAMMAAAACgAAcwAL8CoAAAB/AAEAAQCAACB3 NxaBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAAAAkAngECABDwAR8BAAAAAA AMMLCAAAAAEAAAAHADcWDwAN8GQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAA AAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAH AAAAAAAJBAQIDwAE8GQAAAASAArwCAAAAAQMAAAACgAAYwAL8CQAAAB/AAQABACHAAEAAAB/AQAA AQC/AREAEQD/AQgACQA/AgEAAQAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAIAAAAF ADcWDwAE8BQBAAASAArwCAAAAAUMAAAACgAAcwAL8CoAAAB/AAEAAQCAALh6NxaBAQQAAAiDAQAA AAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAMAAAAG AjcWDwAN8KIAAAAAAJ8PBAAAAAIAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQg c3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwA AKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcAAAAAAAkE BAgPAATw2gAAABIACvAIAAAABgwAAAAKAACDAAvwMAAAAH8AAQABAIAApIE3FocAAgAAAIEBBAAA CIMBAAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAYBUAAFAHgBYPABHwEAAAAAAAwwsIAAAA BAAAAAkCNxYPAA3wYgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAAC AAAAAAACAAwAAAD6DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQI DwAE8NwAAAASAArwCAAAAAcMAAAACgAAgwAL8DAAAAB/AAEAAQCAAHyFNxaHAAIAAACBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAGAVkAngEIAWDwAR8BAAAAAAAMMLCAAAAAUA AAAIAjcWDwAN8GQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgAC AAAAAAACAAwAAADYDwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQI DwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADr LggAAACwpnIAgCSqcw8AyQ+UBAAADwAMBCQEAAAPAALwHAQAADAGCPAIAAAABQAAAAUoAwAPAAPw tAMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAKAMABQAAAA8ABPDM AAAAEgAK8AgAAAACKAMAAAoAAIMAC/AwAAAAfwABAAUAgADALmETgQEEAAAIgwEAAAAIvwEBABEA wAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAAAAAAAAUAcgAQ8AEfAQAAAAAADDCwgAAAAAAAAACgJh Ew8ADfBUAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIA DAAAAPkPBAAAAAAAAAAAAKoPDgAAAAIAAAAHAAAAAAAECAkEDwAE8NoAAAASAArwCAAAAAMoAwAA CgAAgwAL8DAAAAB/AAEABQCAAGBCYROBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAAAAjwnfECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAmETDwAN8GIAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAAAAAA AACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPDeAAAAEgAK8AgAAAAEKAMAAAoA AJMAC/A2AAAAfwABAAUAgAC8R2EThwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIAAAQ8AgAAABfFQAAUAd/Fg8AEfAQAAAAAADDCwgAAAACAAAACQJhEw8ADfBgAAAAAACf DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPoPBAAAAAAA AAAAAKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIDwAE8OAAAAASAArwCAAAAAUoAwAA CgAAkwAL8DYAAAB/AAEABQCAAFBGYROHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA CQABAgIAAAgAABDwCAAAAF8VjwnfEH8WDwAR8BAAAAAAAMMLCAAAAAMAAAAIAmETDwAN8GIAAAAA AJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQA AAAAAAAAAACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPBIAAAAEgAK8AgAAAAB KAMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCK EzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAGQXKAVAxTQsPAO4D xxYAAAIA7wMYAAAAAAAAAA8QAAAAAAAABwAAgAABAAAHAAswDwAMBNIVAAAPAALwyhUAACAACPAI AAAABAAAAD4IAAAPAAPwYhUAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAQAAwACAAAAAgAK8AgA AAAACAAABQAAAA8ABPB4AAAAEgAK8AgAAAAgCAAAIAIAAGMAC/AkAAAABAAAAAAAfwAAAAQAgAAA LowTvwEAAAEA/wEAAAEAAQMDAAMAAAAQ8AgAAAAFB2QCSRT+Dg8AEfAQAAAAAADDCwgAAAABAAAA EACMEw8ADfAMAAAAAACeDwQAAAABAAAADwAE8HgAAAASAArwCAAAACEIAAAgAgAAYwAL8CQAAAAE AAAAAAB/AAAABACAAJgKjBO/AQAAAQD/AQAAAQABAwIAAwAAABDwCAAAAJcCsAHQFDUGDwAR8BAA AAAAAMMLCAAAAAAAAAAPAIwTDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwKhQAAKIECvAIAAAAPggA AAAKAABDAQvwxBMAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAIEB BAAACIMBAAAACL8BDAAeAMABAQAACP8BDgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AIDDGgAAAIHDMhMAAL8DAgACAEQAdABzAFMAaABhAHAAZQBOAGEAbQBlAAAARQBVAFIANwAwADUA MwBAADQAMwAwADYANQA2ADEAMwBAADUARQA1ADQANQBDADIANwAyADUAMgBFADkARwA0ADAAOAA2 AD8APwBrADgANgBBADsAVwBNADEAMQAwADEAMQA5ADgANgAhACEAIQBCAEkASABPAEAAXQBtADEA MQAwADEAMQA5ADgANgAxAEAANQA3ADUAQgBDAEIAMQAxADAAMAAxADgAMAAwADEAMwBCAEMAMQAx ADAAMAAxADgAMAAwADEAMwBCAEMAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQA4ADYAQQBHADwAOAA2AEgAMwBPAEsAWABSACwAMgAwADEAOAAxADcAMQA0AEIA SQBIAE8AQABdAHsANQAwADAANwAzACEAIQAhAEIAMQBAADkAMQAwADUAMQAxADEAMwA1AEQAOQBA ADkAQAA1ADgAQgAxADEAMwA1AEQAOQBAADkAQAA1ADgAQgAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhADgAOwBNADkAWAA4ADoANQA4AFoASQAyADMAOQA5ADcA QAAhACEAIQAhACEAQgBJAEgATwBAAF0AaQAxADEAMAA3ADMANgAxADEAMQBAADUANwA1AEIANAAz ADEAMQAzADAAOAA2ADUARAA1ADMAOABCAEYATABRAE0AUgBeADYAMQA4AF4ARwBzAGAAbABkAHYA bgBzAGoAIQBXADIALwBxAHEAdQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhADEAIQAmAAAA kwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAABDwCAAAAAAAAAABAAEADwAE8EgAAAASAArwCAAAAAEIAAAADAAAgwAL8DAAAACBAQAA AAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAA AAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixNpAAAAAADrLggAAACtpnIAAAF/BAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn 8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAuRX/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAA AA8AAisAAAAAAAAdEAQAAAAAAAAADwDuA60GAAACAO8DGAAAAAEAAAANDgAAAAAAAAcAAIAAAAAA BwALMA8ADATEBQAADwAC8LwFAAAQBwjwCAAAAAQAAAAHYAMADwAD8FQFAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAGADAAUAAAAPAATwcgAAABIACvAIAAAAAmADACAC AABTAAvwHgAAAH8AAAAEAIAA9Es3Fr8BAAABAP8BAAABAAEDAgADAAAAEPAIAAAA9f8nAWcVxQIP ABHwEAAAAAAAwwsIAAAAAAAAAA0ANxYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPDOAwAAEgAK8AgA AAAFYAMAAAoAABMBC/BmAAAAfwAAAAQAgAAMkTcWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAA AA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEAAP8A/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/ BgYATgB/BgYADgAAABDwCAAAAGoC3AEPFu4NDwAN8PoCAAAAAJ8PBAAAAAQAAAAAAKgPPgEAAFRo aXMgd29yayBpcyBzdXBwb3J0ZWQgYnkgRElDT05FVCAoRHluYW1pYyBJbXBhaXJtZW50IENvbnN0 cmFpbnQgTmV0d29ya2luZyBmb3IgVHJhbnNwYXJlbnQgTWVzaCBPcHRpY2FsIE5ldHdvcmtzKSBw cm9qZWN0IHVuZGVyICBGUDcvMjAwNy0yMDEzIC0gR0EgbnIgMjE2MzM4DQ1Db250cmlidXRvcnMg DUNoYXZhIFZpamF5YSBTYXJhZGhpICAgIENSRUFURS1ORVQNRW1haWw6IHNhcmFkaGkuY2hhdmFA Y3JlYXRlLW5ldC5vcmcNDUFudG9uaW8gRnJhbmNlc2NvbiAgIENSRUFURS1ORVQNRW1haWw6IGFu dG9uaW8uZnJhbmNlc2NvbkBjcmVhdGUtbmV0Lm9yZwAAoQ+qAAAArgAAAAAAsyAKAAMA2AAGAAAA AAEyAAcARwAAAAEAsiAKAAIA/AAGAAAAAAEyAAcAAQAAAAAAsiAKAAIA/AAGAAAAAAEyAAcASQAA AAEAsiAKAAIA/AAGAAAAAAEyAAcAoAAAAAAAogAIAAYAFwAOAAAAAACiAAgABgAaAEcAAAAAAKIA CAAGABQAAQAAAAAEogAABAgABgAUAEkAAAAACKIAAAgIAAYAFAAAAKoPqAAAAK4AAAAGAAAACQQE CAUAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIBgAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgHAAAA BwAAAAMACQQECBYAAAAGAAAACQQECBwAAAAHAAAAAwAJBAQICgAAAAYAAAAJBAQICgAAAAcAAAAD AAkEBAgVAAAABgAAAAkEBAghAAAABwAAAAMACQQECAEAAAAGAAAACQQECA8A8g8YAAAAAADzDxAA AAAAAAAAAAAAAAAAAAAIWAswAADfDwgAAAAdAQAAPgEAAAAApg8OAAAAMQYAAPkBcQCpABoBUAEP AATwzAAAABIACvAIAAAAB2ADAAAKAAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUA AgAAAIcAAQAAAL8AAgAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAAAAAAgBYAAA8ABPBIAAAAEgAK8AgAAAAB YAMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCK E4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAb1fKAXACV9AAAAAr BAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAALkV/////xIAAAAP AD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gOOQwAAAgDvAxgAAAABAAAADRUAAAAAAAAH AACAAAAAAAcACzAPAAwEpUIAAA8AAvCdQgAAQAcI8AgAAAAxAAAA+G0DAA8AA/A1QgAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABsAwAFAAAADwAE8HgAAAASAArwCAAA AAJsAwAgAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAJQFhha/AQAAAQD/AQAAAQABAwIAAwAAABDw CAAAAK0AIAFgFTwCDwAR8BAAAAAAAMMLCAAAAAAAAAANAIYWDwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwKAEAABIACvAIAAAAB2wDAAAKAADzAAvwWgAAAH8AAAAEAIAAvEg3FoEAYDUBAIIAsJoAAIMA YDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAAD AH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4A PwYGAE4AfwYGAA4AAAAQ8AgAAAD4CNgM4hVJDg8ADfBgAAAAAACfDwQAAAAEAAAAAAChDygAAAAB AAAAAACzIAoAAwDYAAYAAAAAATIABwABAAAAAQBDAAEABAAEAA0AAACqDw4AAAABAAAABwAAAAAA BAgJBAAApg8GAAAAAQAAAPkBDwAD8E1AAAAPAATwyAAAAAEACfAQAAAAkQIAADwCAADRFAAALQ0A AAIACvAIAAAA+G0DAAECAAATAAvwBgAAAH8AAAEAASMAIvFiAAAAnwMDAAAAoMNWAAAAFAAUAAQA YgAAAFgAAABZAAAAjwAAAKcAAABYAAAAWQAAAFkAAAB5AAAAWAAAAFkAAABZAAAAWQAAAI8AAABZ AAAAjwAAAMUAAABZAAAAWAAAAFkAAAAAABDwCAAAAJcCkQLRFIgNDwAR8BAAAAAAAMMLCAAAAAEA AAATADcWDwAE8BoCAAASAArwCAAAAJJtAwACCgAAIwEL8GwAAAB/AAAABACAANwiMhSBAGA1AQCC ALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADA AL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAAK8MAADRFAAA LQ0AAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMU AAAAAACxDwwAAAAAAAADAAABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsT JAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfCiAAAAAACfDwQAAAAH AAAAAACoD0AAAABUYXNrIDYuMzogTmV0d29yayBwbGFubmluZyB0b29scyBldmFsdWF0aW9uIGFu ZCBleHBlcmltZW50YXRpb24gAAChDzIAAABBAAAAAAAhIAsAAAAAAAAAAAACAAIAQAAAAAAAIwAL AAEACAABAAAAAAQiAAAEAQAYAAAAqg8MAAAAQQAAAAYAAAAJBAQIDwAE8A4CAAASAArwCAAAAJFt AwACCgAAIwEL8GwAAAB/AAAABACAABhxMhSBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/ AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBO AD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAADEMAADRFAAArwwAAA8AEfCOAAAADwCIE4YAAAAPAIoT NAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMUAAAAAACxDwwAAAAAAAADAAABAAAAAAAP AIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAA AAAAAAAAAAAAAAAAAAAAAA8ADfCWAAAAAACfDwQAAAAHAAAAAACoDzQAAABUYXNrIDYuMjogUHJv dG9jb2xzIEltcGxlbWVudGF0aW9uIG9uIEZQR0EgaGFyZHdhcmUgAAChDzIAAAA1AAAAAAAhIAsA AAAAAAAAAAACAAIANAAAAAAAIwALAAEACAABAAAAAAQiAAAEAQAYAAAAqg8MAAAANQAAAAYAAAAJ BAQIDwAE8BACAAASAArwCAAAAJBtAwACCgAAIwEL8GwAAAB/AAAABACAABhWMhSBAGA1AQCCALCa AACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAALMLAADRFAAAMQwA AA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMUAAAA AACxDwwAAAAAAAADAAABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTJAAA AAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfCYAAAAAACfDwQAAAAHAAAA AACoDzYAAABUYXNrIDYuMTogRXhwZXJpbWVudGFsIGFzc2Vzc21lbnQgb2YgRElDT05FVCBjb25j ZXB0cyAAAKEPMgAAADcAAAAAACEgCwAAAAAAAAAAAAIAAgA2AAAAAAAjAAsAAQAIAAEAAAAABCIA AAQBABgAAACqDwwAAAA3AAAABgAAAAkEBAgPAATwNAIAABIACvAIAAAAj20DAAIKAAAjAQvwbAAA AH8AAAAEAIAAsEoyFIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMB AAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2 AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A AAAP8BAAAACRAgAA7goAANEUAACzCwAADwAR8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAAAAAAAAMAAAEAAAAAAA8AihNCAAAAAAC6Dw4A AABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAA AAAADwAN8LwAAAAAAJ8PBAAAAAcAAAAAAKgPPgAAAFdQNiBMYWIgRXhwZXJpbWVudGF0aW9uLCBl dmFsdWF0aW9uIGFuZCB0ZXN0YmVkIGltcGxlbWVudGF0aW9uAAChDzQAAAA/AAAAAAAhIAsAAAAA AAAAAAACAAIAPgAAAAEAIwABAAsAAQAMAAEAAAAABCIAAAQBABgAAACqDyYAAAAoAAAABgAAAAkE BAgHAAAABwAAAAMACQQECBAAAAAGAAAACQQECA8ABPBAAgAAEgAK8AgAAACMbQMAAgoAACMBC/Bs AAAAfwAAAAQAgACgpzwWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAI gwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAAA/wEAAAAJECAABKCgAA0RQAAO4KAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAA AF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwAAAQAAAAAADwCKE0IAAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAA AAAAAAAPAA3wyAAAAAAAnw8EAAAABwAAAAAAqA9eAAAAVGFzayA1LjI6IEltcGxlbWVudGF0aW9u IG9mIG1vZGlmaWNhdGlvbnMgdG8gRy1NUExTIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2xzIHZpYSBl bXVsYXRlZCBub2RlcwAAoQ86AAAAXwAAAAAAISALAAAAAAAAAAAAAgACAF4AAAAAACcACwABAAwA AAD//gEAAAAABCYAAAQBAAwAAAD//gAAqg8MAAAAXwAAAAYAAAAJBAQIDwAE8CcCAAASAArwCAAA AIttAwACCgAAIwEL8GwAAAB/AAAABACAABx2PBaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEA AAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8F BgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAAMwJAADRFAAASgoAAA8AEfCOAAAADwCIE4YAAAAP AIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMUAAAAAACxDwwAAAAAAAADAAABAAAA AAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAA8ADfCvAAAAAACfDwQAAAAHAAAAAACoD00AAABUYXNrIDUuMTog RGVmaW5pdGlvbiBvZiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gbW9uaXRvcnMgYW5kIHRoZSBjb250 cm9sIHBsYW5lIAAAoQ8yAAAATgAAAAAAISALAAAAAAAAAAAAAgACAE0AAAAAACMACwABAAgAAQAA AAAEIgAABAEAGAAAAKoPDAAAAE4AAAAGAAAACQQECA8ABPAIAgAAEgAK8AgAAACKbQMAAgoAACMB C/BsAAAAfwAAAAQAgAC89DwWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEE AAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A kwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAAA/wEAAAAJECAAAoCQAA0RQAAMwJAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwAAAQAAAAAADwCKE0IAAAAA ALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAA AAAAAAAAAAAPAA3wkAAAAAAAnw8EAAAABwAAAAAAqA8sAAAAV1A1IE5ldHdvcmsgTWFuYWdlbWVu dCBhbmQgQ29udHJvbCBQcm90b2NvbHMAAKEPNAAAAC0AAAAAACEgCwAAAAAAAAAAAAIAAgAsAAAA AQAjAAEACwABAAwAAQAAAAAEIgAABAEAGAAAAKoPDAAAAC0AAAAGAAAACQQECA8ABPAYAgAAEgAK 8AgAAACJbQMAAgoAACMBC/BsAAAAfwAAAAQAgABUhowWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAA hwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAJECAACqCAAA0RQAACgJAAAPABHwjgAAAA8AiBOG AAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwAA AQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3woAAAAAAAnw8EAAAABwAAAAAAqA8+AAAAVGFzayA0 LjQgRmFpbHVyZSBsb2NhbGl6YXRpb24gYWxnb3JpdGhtcyB0byBlbmFibGUgcmVzaWxpZW5jeSAA AKEPMgAAAD8AAAAAACEgCwAAAAAAAAAAAAIAAgA+AAAAAAAjAAsAAQAIAAEAAAAABCIAAAQBABgA AACqDwwAAAA/AAAABgAAAAkEBAgPAATwEwIAABIACvAIAAAAiG0DAAIKAAAjAQvwbAAAAH8AAAAE AIAAIAaMFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8B CQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEA AEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAA AACRAgAALAgAANEUAACqCAAADwAR8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABfAF8AXwBQ AFAAVAAxADAAAACLExQAAAAAALEPDAAAAAAAAAMAAAEAAAAAAA8AihNCAAAAAAC6Dw4AAABfAF8A XwBQAFAAVAA5AAAAixMkAAAAAACsDxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN 8JsAAAAAAJ8PBAAAAAcAAAAAAKgPOQAAAFRhc2sgNC4zIE9wdGltaXphdGlvbiBBbGdvcml0aG1z IGZvciBjb21wb25lbnQgcGxhY2VtZW50IAAAoQ8yAAAAOgAAAAAAISALAAAAAAAAAAAAAgACADkA AAAAACMACwABAAgAAQAAAAAEIgAABAEAGAAAAKoPDAAAADoAAAAGAAAACQQECA8ABPBMAgAAEgAK 8AgAAACHbQMAAgoAACMBC/BsAAAAfwAAAAQAgABMQIwWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAA hwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAJECAACuBwAA0RQAACwIAAAPABHwjgAAAA8AiBOG AAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwAA AQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3w1AAAAAAAnw8EAAAABwAAAAAAqA9YAAAAVGFzayA0 LjIgSW1wYWlybWVudCBhd2FyZSBtdWx0aS1jb25zdHJhaW4gUldBIGZvciBRb1Mgcm91dGluZyAg b2YgaW5kaXZpZHVhbCBjb25uZWN0aW9ucwAAoQ8yAAAAWQAAAAAAISALAAAAAAAAAAAAAgACAFgA AAAAACMACwABAAgAAQAAAAAEIgAABAEAGAAAAKoPJgAAADIAAAAGAAAACQQECAMAAAAHAAAAAwAJ BAQIJAAAAAYAAAAJBAQIDwAE8B8CAAASAArwCAAAAIZtAwACCgAAIwEL8GwAAAB/AAAABACAAGBZ jBaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDA AQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8B AAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIA ADAHAADRFAAArgcAAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQA MQAwAAAAixMUAAAAAACxDwwAAAAAAAADAAABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQ AFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfCnAAAA AACfDwQAAAAHAAAAAACoD0UAAABUYXNrIDQuMSBJbXBhaXJtZW50IGF3YXJlIG9mZmxpbmUgUldB IHJvdXRpbmcgb2YgbXVsdGlwbGUgY29ubmVjdGlvbnMAAKEPMgAAAEYAAAAAACEgCwAAAAAAAAAA AAIAAgBFAAAAAAAjAAsAAQAIAAEAAAAABCIAAAQBABgAAACqDwwAAABGAAAABgAAAAkEBAgPAATw +QEAABIACvAIAAAAhW0DAAIKAAAjAQvwbAAAAH8AAAAEAIAABO+MFoEAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAAjAYAANEUAAAwBwAADwAR8I4A AAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAA AAAAAAMAAAEAAAAAAA8AihNCAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwA AAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN8IEAAAAAAJ8PBAAAAAcAAAAAAKgPHQAA AFdQNCBEZXZlbG9wbWVudCBvZiBhbGdvcml0aG1zAAChDzQAAAAeAAAAAAAhIAsAAAAAAAAAAAAC AAIAHQAAAAEAIwABAAsAAQAMAAEAAAAABCIAAAQBABgAAACqDwwAAAAeAAAABgAAAAkEBAgPAATw GwIAABIACvAIAAAAhG0DAAIKAAAjAQvwbAAAAH8AAAAEAIAAsAmUFoEAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAADgYAANEUAACMBgAADwAR8I4A AAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAA AAAAAAMAAAEAAAAAAA8AihNCAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwA AAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN8KMAAAAAAJ8PBAAAAAcAAAAAAKgPQQAA AFRhc2sgMy4zIERldmVsb3BtZW50IGFuZCBldmFsdWF0aW9uIG9mIHRoZSBuZXR3b3JrIHBsYW5u aW5nIHRvb2wgAAChDzIAAABCAAAAAAAhIAsAAAAAAAAAAAACAAIAQQAAAAAAIwALAAEACAABAAAA AAQiAAAEAQAYAAAAqg8MAAAAQgAAAAYAAAAJBAQIDwAE8EkCAAASAArwCAAAAINtAwACCgAAIwEL 8GwAAAB/AAAABACAAEiDlBaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQA AAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCT ACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8G BgAOAAAAD/AQAAAAkQIAAJAFAADRFAAADgYAAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMUAAAAAACxDwwAAAAAAAADAAABAAAAAAAPAIoTQgAAAAAA ug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8ADfDRAAAAAACfDwQAAAAHAAAAAACoD1UAAABUYXNrIDMuMjogTmV0d29yayBtb2Rl bGxpbmcgc3R1ZGllcyB0byBldmFsdWF0ZSB0aGUgZWZmaWNpZW5jeSBvZiBtb25pdG9yaW5nIHNj aGVtZXMgAAChDzIAAABWAAAAAAAhIAsAAAAAAAAAAAACAAIAVQAAAAAAIwALAAEACAABAAAAAAQi AAAEAQAYAAAAqg8mAAAAEgAAAAYAAAAJBAQICQAAAAcAAAADAAkEBAg7AAAABgAAAAkEBAgPAATw EgIAABIACvAIAAAAgm0DAAIKAAAjAQvwbAAAAH8AAAAEAIAAQFeUFoEAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAAEgUAANEUAACQBQAADwAR8I4A AAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAA AAAAAAMAAAEAAAAAAA8AihNCAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwA AAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN8JoAAAAAAJ8PBAAAAAcAAAAAAKgPOAAA AFRhc2sgMy4xOiBFZmZpY2llbnQgb3B0aWNhbCBsYXllciBpbXBhaXJtZW50IG1vbml0b3Jpbmcg AAChDzIAAAA5AAAAAAAhIAsAAAAAAAAAAAACAAIAOAAAAAAAIwALAAEACAABAAAAAAQiAAAEAQAY AAAAqg8MAAAAOQAAAAYAAAAJBAQIDwAE8CYCAAASAArwCAAAAIFtAwACCgAAIwEL8GwAAAB/AAAA BACAADStlBaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/ AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8B AABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQ AAAAkQIAAGsEAADRFAAAEgUAAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixMUAAAAAACxDwwAAAAAAAADAAABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBf AF8AUABQAFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A DfCuAAAAAACfDwQAAAAHAAAAAACoD0oAAABXUDMgRGV2ZWxvcG1lbnQgb2YgYSBuZXR3b3JrIHBs YW5uaW5nIHRvb2wgZm9yIGR5bmFtaWMgdHJhZmZpYy9pbXBhaXJtZW50cwAAoQ80AAAASwAAAAAA ISALAAAAAAAAAAAAAgACAEoAAAABACMAAQALAAEADAABAAAAAAQiAAAEAQAYAAAAqg8MAAAASwAA AAYAAAAJBAQIDwAE8EUCAAASAArwCAAAAIBtAwACCgAAIwEL8GwAAAB/AAAABACAAFR6lBaBAGA1 AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/ AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8B AADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAANwDAADR FAAAawQAAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixMUAAAAAACxDwwAAAAAAAADAAABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAA AIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfDNAAAAAACfDwQA AAAHAAAAAACoD2MAAABUYXNrIDIuMzpJbnZlc3RpZ2F0aW9uIG9mIHRlY2huaXF1ZXMgZm9yIGRp c3NlbWluYXRpbmcgcGh5c2ljYWwgaW1wYWlybWVudCBpbmZvIGFjcm9zcyB0aGUgbmV0d29yayAA AKEPOgAAAGQAAAAAACEgCwAAAAAAAAAAAAIAAgBjAAAAAAAnAAsAAQAIAAAA//4BAAAAAAQmAAAE AQAYAAAA//4AAKoPDAAAAGQAAAAGAAAACQQECA8ABPAzAgAAEgAK8AgAAAB/bQMAAgoAACMBC/Bs AAAAfwAAAAQAgADg7JQWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAI gwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAAA/wEAAAAJECAABeAwAA0RQAANwDAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAA AF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwAAAQAAAAAADwCKE0IAAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAA AAAAAAAPAA3wuwAAAAAAnw8EAAAABwAAAAAAqA9ZAAAAVGFzayAyLjI6IEludmVzdGlnYXRpb24g b2YgcGxhbm5pbmcgYW5kIG9wdGltaXphdGlvbiBhc3BlY3RzIGluIGR5bmFtaWMgb3B0aWNhbCBu ZXR3b3JrcyAAAKEPMgAAAFoAAAAAACEgCwAAAAAAAAAAAAIAAgBZAAAAAAAjAAsAAQAIAAEAAAAA BCIAAAQBABgAAACqDwwAAABaAAAABgAAAAkEBAgPAATwGQIAABIACvAIAAAAfm0DAAIKAAAjAQvw bAAAAH8AAAAEAIAAKLmXFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAA CIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMA IvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYG AA4AAAAP8BAAAACRAgAA4AIAANEUAABeAwAADwAR8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6DxAA AABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAAAAAAAAMAAAEAAAAAAA8AihNCAAAAAAC6 Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAA AAAAAAAADwAN8KEAAAAAAJ8PBAAAAAcAAAAAAKgPPwAAAFRhc2sgMi4xOiBEZXZlbG9wbWVudCBv ZiBkeW5hbWljIG9wdGljYWwgbmV0d29yayBhcmNoaXRlY3R1cmVzIAAAoQ8yAAAAQAAAAAAAISAL AAAAAAAAAAAAAgACAD8AAAAAACMACwABAAgAAQAAAAAEIgAABAEAGAAAAKoPDAAAAEAAAAAGAAAA CQQECA8ABPAIAgAAEgAK8AgAAAB9bQMAAgoAACMBC/BsAAAAfwAAAAQAgAAUI5cWgQBgNQEAggCw mgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAJECAAA8AgAA0RQAAOAC AAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAA AAAAsQ8MAAAAAAAAAwAAAQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQA AAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3wkAAAAAAAnw8EAAAABwAA AAAAqA8sAAAAV1AyIE5ldHdvcmsgYXJjaGl0ZWN0dXJlIGFuZCBzdXBwb3J0IHN0dWRpZXMAAKEP NAAAAC0AAAAAACEgCwAAAAAAAAAAAAIAAgAsAAAAAQAjAAEACwABAAwAAQAAAAAEIgAABAEAGAAA AKoPDAAAAC0AAAAGAAAACQQECA8ABPDIAAAAQgEK8AgAAACXbQMAAgoAAAMBC/BgAAAAgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEBAAAIywGcMQAA/wEM AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCC AIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAJECAAA8AgAA0RQAADwCAAAP AATwyAAAAEIBCvAIAAAAmG0DAAIKAAADAQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUA AgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4A PwYGAE4AfwYGAA4AAAAP8BAAAACRAgAALQ0AANEUAAAtDQAADwAE8MIAAABCAQrwCAAAAJltAwAC CgAA8wAL8FoAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAA EADLAZwxAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABA AP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAADwC AACRAgAA4AIAAA8ABPDCAAAAQgEK8AgAAACabQMAAgoAAPMAC/BaAAAAgQBgNQEAggCwmgAAgwBg NQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAywGcMQAA/wEMAA4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAAA/wEAAAANEUAAA8AgAA0RQAAOACAAAPAATwwgAAAEIBCvAIAAAA nG0DAAIKAADzAAvwWgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAP AL8BAAAQAMsBnDEAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAA fwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACR AgAA4AIAANEUAADgAgAADwAE8MgAAABCAQrwCAAAAJ9tAwACCgAAAwEL8GAAAACBAGA1AQCCALCa AACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8F BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAAF4DAADRFAAAXgMAAA8ABPDI AAAAQgEK8AgAAACibQMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAA hwABAAAAvwACAA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYA TgB/BgYADgAAAA/wEAAAAJECAADcAwAA0RQAANwDAAAPAATwyAAAAEIBCvAIAAAApW0DAAIKAAAD AQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsB nDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEA AEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAA awQAANEUAABrBAAADwAE8MgAAABCAQrwCAAAAKhtAwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACD AGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIA AAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAABIFAADRFAAAEgUAAA8ABPDIAAAA QgEK8AgAAACrbQMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwAB AAAAvwACAA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAAA/wEAAAAJECAACQBQAA0RQAAJAFAAAPAATwyAAAAEIBCvAIAAAArm0DAAIKAAADAQvw YAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEA ANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA /wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAADgYA ANEUAAAOBgAADwAE8MgAAABCAQrwCAAAALFtAwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1 AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8F BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAAIwGAADRFAAAjAYAAA8ABPDIAAAAQgEK 8AgAAAC0bQMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAA vwACAA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMA AA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAAA/wEAAAAJECAAAwBwAA0RQAADAHAAAPAATwyAAAAEIBCvAIAAAAt20DAAIKAAADAQvwYAAA AIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEAANcB AAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEA AIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAArgcAANEU AACuBwAADwAE8MgAAABCAQrwCAAAALptAwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1AQCE ALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAA AwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBO AP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAACwIAADRFAAALAgAAA8ABPDIAAAAQgEK8AgA AAC9bQMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwAC AA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A gwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAA AA/wEAAAAJECAACqCAAA0RQAAKoIAAAPAATwyAAAAEIBCvAIAAAAwG0DAAIKAAADAQvwYAAAAIEA YDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEAANcBAAAA AP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAA vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAAKAkAANEUAAAo CQAADwAE8MgAAABCAQrwCAAAAMNtAwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1AQCEALCa AACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8F BgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAAMwJAADRFAAAzAkAAA8ABPDIAAAAQgEK8AgAAADG bQMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8A vwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi 8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/w EAAAAJECAABKCgAA0RQAAEoKAAAPAATwyAAAAEIBCvAIAAAAyW0DAAIKAAADAQvwYAAAAIEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEAANcBAAAAAP8B DAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMA ggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAA7goAANEUAADuCgAA DwAE8MgAAABCAQrwCAAAANJtAwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACF AAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEA DwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBO AD8GBgBOAH8GBgAOAAAAD/AQAAAAkQIAALMLAADRFAAAswsAAA8ABPDIAAAAQgEK8AgAAADVbQMA AgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEA ABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAA AAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAA AJECAAAxDAAA0RQAADEMAAAPAATwyAAAAEIBCvAIAAAA2G0DAAIKAAADAQvwYAAAAIEAYDUBAIIA sJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEAANcBAAAAAP8BDAAO AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAACRAgAArwwAANEUAACvDAAADwAE 8MgAAABCAQrwCAAAAPBtAwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIA AACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8G BgBOAH8GBgAOAAAAD/AQAAAAkQIAAOACAACRAgAALQ0AAA8ABPDIAAAAQgEK8AgAAADxbQMAAgoA AAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAA ywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/ AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAANEU AADgAgAA0RQAAC0NAAAPAATwSAAAABIACvAIAAAAAWwDAAAMAACDAAvwMAAAAIEBAAAACIMBBQAA CJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAA AAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLE2kAAAAAAOsuCAAAAHVXygGAux2BAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAAC5Ff////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAA AAAPAO4D5wQAAAIA7wMYAAAAAQAAAA0OAAAAAAAABwAAgAAAAAAHAAswDwAMBP4DAAAPAALw9gMA AMAHCPAIAAAAAwAAAAPUAwAPAAPwjgMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAA1AMABQAAAA8ABPB4AAAAEgAK8AgAAAAC1AMAIAIAAGMAC/AkAAAAfwAAAAQAgADE JWETvwEAAAEA/wEAAAEAAQMCAAMAiAMAAAAAAAAQ8AgAAAB3ACABYBWXAg8AEfAQAAAAAADDCwgA AAAAAAAADQBhEw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8NYCAAASAArwCAAAAAPUAwAACgAA8wAL 8FoAAAB/AAAABACAAACFrw+BAGA1AQCCALCaAACDAGA1AQCEALCaAAC/AAAADwCBAQQAAAiDAQAA AAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAAAH8BAABAAL8BAABg AP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA8gJkAiwV 2goPAA3wDgIAAAAAnw8EAAAABAAAAAAAqA/mAAAAVHdvIHRvcC1UTFZzIGFyZSBkZWZpbmVkIHRv IGRlc2NyaWJlIFBMSSAoUGh5c2ljYWwgTGF5ZXIgSW1wYWlybWVudHMpIGluZm9ybWF0aW9uOg1M aW5rIFBMSSBUTFYNRGVzY3JpYmVzIHRoZSBwaHlzaWNhbCBsYXllciBpbXBhaXJtZW50cyByZWxh dGVkIHRvIHRoZSBsaW5rDU5vZGUgUExJIFRMVg1EZXNjcmliZXMgdGhlIHBoeXNpY2FsIGxheWVy IGltcGFpcm1lbnRzIHJlbGF0ZWQgdG8gdGhlIG5vZGUAAKEPwgAAAFMAAAAAALIwCgACANgABgAA AAABggAUAAcADQAAAAAAszAKAAMA2AAGAAAAAAGCABQABwA9AAAAAQAxMAoAAQAGAAAAAAGCABQA BwANAAAAAACzMAoAAwDYAAYAAAAAAYIAFAAHAD0AAAABADEwCgABAAYAAAAAAYIAFAAHAFMAAAAA ACIACAAUAA0AAAAABCIAAAQIABQAPQAAAAAEIgAABAgAFAANAAAAAAgiAAAICAAUAD0AAAAADCIA AAwIABQAAACqDzIAAAAIAAAABgAAAAkIBAgEAAAABwAAAAMACQgECEcAAAAGAAAACQgECJQAAAAG AAAACQQECAAApg8IAAAACQAAAPkBbwAPAATwSAAAABIACvAIAAAAAdQDAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAHVXygGQN3iBAAAAKwQAAAAAAAAAHwBE8T0AAAAA ACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAC5Ff////8SAAAADwA98Q0AAABAAULxBQAAAAEJ AAAADwACKwAAAAAPAO4DIhsAAAIA7wMYAAAAAQAAAA0OAAAAAAAABwAAgAAAAAAHAAswDwAMBDka AAAPAALwMRoAAFAHCPAIAAAAFAAAAF1wAwAQABjxBAAAAAEAAAAPAAPwtRkAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAcAMABQAAAA8ABPByAAAAEgAK8AgAAAACcAMA IAIAAFMAC/AeAAAAfwAAAAQAgAB8nYwTvwEAAAEA/wEAAAEAAQMCAAMAAAAQ8AgAAAB3ACcBZxWX Ag8AEfAQAAAAAADDCwgAAAAAAAAADQCMEw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8DQBAAASAArw CAAAAEdwAwAACgAAAwEL8HoAAACAAFACohaBAH05AACCAAAAAACDAH05AACEAAAAAACKAEdwAwC/ AAQABACDAQAAAAC/ARAAEADAARoaGgDCAeXl5QDLAbYkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEA AABSAGUAYwB0AGEAbgBnAGwAZQAgADIAMAAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAADyAkcDYQ3u DQ8ADfB8AAAAAACfDwQAAAAEAAAAAACoDwgAAABQTEkgIExTQQAAoQ82AAAACQAAAAAAsjAKAAIA /AAGAAAAAAFgADIABwAIAAAAAABjAAsACAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAAJAAAABgAA AAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBIAQAAEgAK8AgAAABIcAMAAAoAABMBC/CAAAAAgAAoDqIW gQB9OQAAggAAAAAAgwB9OQAAhAB9OQAAigBIcAMAvwAEAAQAgQHM//8AgwEzAAAAvwEQABAAwAEa GhoAwgHl5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUA IAAyADEAAAATACLxBgAAAL8BAABgAAAAEPAIAAAA/wPYA88MlA0PAA3wigAAAAAAnw8EAAAABAAA AAAAqA8WAAAAVE9QIFRMViAoTGluayBQTEkgVExWKQAAoQ82AAAAFwAAAAAAsigKAAIA/AAGAAAA AAEBADIABwAWAAAAAABjAAsACAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAAXAAAABgAAAAkEBAgA AKYPBgAAAAEAAAD5AQ8ABPBAAQAAEgAK8AgAAABJcAMAAAoAABMBC/CAAAAAgAAkEqIWgQB9OQAA ggAAAAAAgwB9OQAAhAB9OQAAigBJcAMAvwAEAAQAgQHMmf8AgwEzZgAAvwEQABAAwAEaGhoAwgHl 5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADIA AAATACLxBgAAAL8BAABgAAAAEPAIAAAAXAPdA8oM0gMPAA3wggAAAAAAnw8EAAAABAAAAAAAqA8O AAAAUExJIExTQSBoZWFkZXIAAKEPNgAAAA8AAAAAALIoCgACAPwABgAAAAABAQAyAAcADgAAAAAA YwALAAgACwAJAAEAAAAAACIACAAUAAAAqg8MAAAADwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEP AATwQQEAABIACvAIAAAASnADAAAKAAATAQvwgAAAAIAAcKqiFoEAfTkAAIIAAAAAAIMAfTkAAIQA fTkAAIoASnADAL8ABAAEAIEBzP/MAIMBMwAzAL8BEAAQAMABGhoaAMIB5eXlAMsBkCQAAP8BCAAI AD8CAAACAIDDGgAAAIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMgAzAAAAEwAi8QYAAAC/AQAA YAAAABDwCAAAAF0EWgTZC8sEDwAN8IMAAAAAAJ8PBAAAAAQAAAAAAKgPDwAAAExpbmsgSUQgc3Vi LVRMVgAAoQ82AAAAEAAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAPAAAAAABjAAsACAALAAkAAQAA AAAAIgAIABQAAACqDwwAAAAQAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBMAQAAEgAK8AgA AABLcAMAAAoAABMBC/CAAAAAgAB0n6IWgQB9OQAAggAAAAAAgwB9OQAAhAB9OQAAigBLcAMAvwAE AAQAgQHM/8wAgwEzADMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAA iAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADQAAAATACLxBgAAAL8BAABgAAAAEPAIAAAA5QRa BNkLVgUPAA3wjgAAAAAAnw8EAAAABAAAAAAAqA8aAAAATG9jYWwgaW50ZXJmYWNlIElQIHN1Yi1U TFYAAKEPNgAAABsAAAAAALIoCgACAPwABgAAAAABAQAyAAcAGgAAAAAAYwALAAgACwAJAAEAAAAA ACIACAAUAAAAqg8MAAAAGwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwTQEAABIACvAIAAAA THADAAAKAAATAQvwgAAAAIAAqBKiFoEAfTkAAIIAAAAAAIMAfTkAAIQAfTkAAIoATHADAL8ABAAE AIEBzP/MAIMBMwAzAL8BEAAQAMABGhoaAMIB5eXlAMsBkCQAAP8BCAAIAD8CAAACAIDDGgAAAIgD AQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMgA1AAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAH8FWgTZ C+sFDwAN8I8AAAAAAJ8PBAAAAAQAAAAAAKgPGwAAAFJlbW90ZSBpbnRlcmZhY2UgSVAgc3ViLVRM VgAAoQ82AAAAHAAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAbAAAAAABjAAsACAALAAkAAQAAAAAA IgAIABQAAACqDwwAAAAcAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBOAQAAEgAK8AgAAABN cAMAAAoAABMBC/CAAAAAgACcJqIWgQB9OQAAggAAAAAAgwB9OQAAhAB9OQAAigBNcAMAvwAEAAQA gQHM/8wAgwEzADMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAAiAMB AAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADYAAAATACLxBgAAAL8BAABgAAAAEPAIAAAABwZUBNQL sQwPAA3wkAAAAAAAnw8EAAAABAAAAAAAqA8cAAAAQ29tcG9uZW50IEltcGFpcm1lbnQgc3ViLVRM VgAAoQ82AAAAHQAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAcAAAAAABjAAsACAALAAkAAQAAAAAA IgAIABQAAACqDwwAAAAdAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBeAQAAEgAK8AgAAABO cAMAAAoAABMBC/CAAAAAgACwUKIWgQB9OQAAggAAAAAAgwB9OQAAhAB9OQAAigBOcAMAvwAEAAQA gQH//5kAgwEAAGYAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAAiAMB AAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADcAAAATACLxBgAAAL8BAABgAAAAEPAIAAAAFwcYBUkL ywgPAA3woAAAAAAAnw8EAAAABAAAAAAAqA8sAAAAV2F2ZWxlbmd0aCAgdW5yZWxhdGVkIEltcGFp cm1lbnQgc3ViLXN1Yi1UTFYAAKEPNgAAAC0AAAAAALIoCgACAPwABgAAAAABAQAyAAcALAAAAAAA YwALAAgACwAJAAEAAAAAACIACAAUAAAAqg8MAAAALQAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEP AATwXAEAABIACvAIAAAAT3ADAAAKAAATAQvwgAAAAIAAIEiiFoEAfTkAAIIAAAAAAIMAfTkAAIQA fTkAAIoAT3ADAL8ABAAEAIEB//+ZAIMBAABmAL8BEAAQAMABGhoaAMIB5eXlAMsBkCQAAP8BCAAI AD8CAAACAIDDGgAAAIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMgA4AAAAEwAi8QYAAAC/AQAA YAAAABDwCAAAAAIJEwVEC0YLDwAN8J4AAAAAAJ8PBAAAAAQAAAAAAKgPKgAAAFdhdmVsZW5ndGgg IHJlbGF0ZWQgSW1wYWlybWVudCBzdWItc3ViLVRMVgAAoQ82AAAAKwAAAAAAsigKAAIA/AAGAAAA AAEBADIABwAqAAAAAABjAAsACAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAArAAAABgAAAAkEBAgA AKYPBgAAAAEAAAD5AQ8ABPA/AQAAEgAK8AgAAABQcAMAAAoAABMBC/CAAAAAgAAYy6IWgQB9OQAA ggAAAAAAgwB9OQAAhAB9OQAAigBQcAMAvwAEAAQAgQH/zJkAgwEAM2YAvwEQABAAwAEaGhoAwgHl 5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADkA AAATACLxBgAAAL8BAABgAAAAEPAIAAAAfgm8BbEK7gkPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8N AAAAV2F2ZWxlbmd0aCBJZAAAoQ82AAAADgAAAAAAsigKAAIA/AAGAAAAAAEBADIABwANAAAAAABj AAsACAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAAOAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8A BPBLAQAAEgAK8AgAAABScAMAAAoAABMBC/CAAAAAgAAkyaIWgQB9OQAAggAAAAAAgwB9OQAAhAB9 OQAAigBScAMAvwAEAAQAgQH/mcwAgwEAZjMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgA PwIAAAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAzADIAAAATACLxBgAAAL8BAABg AAAAEPAIAAAACwq8BbEKewoPAA3wjQAAAAAAnw8EAAAABAAAAAAAqA8ZAAAAUGFyYW1ldGVyIHN1 Yi1zdWItc3ViLVRMVgAAoQ82AAAAGgAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAZAAAAAABjAAsA CAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAAaAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBN AQAAEgAK8AgAAABTcAMAAAoAABMBC/CAAAAAgACA2qIWgQB9OQAAggAAAAAAgwB9OQAAhAB9OQAA igBTcAMAvwAEAAQAgQHM/8wAgwEzADMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIA AAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAzADQAAAATACLxBgAAAL8BAABgAAAA EPAIAAAA3gxUBNELXQ0PAA3wjwAAAAAAnw8EAAAABAAAAAAAqA8bAAAAT3RoZXIgY29tcG9uZW50 IHN1Yi1UTFYuLi4uAAChDzYAAAAcAAAAAACyKAoAAgD8AAYAAAAAAQEAMgAHABsAAAAAAGMACwAI AAsACQABAAAAAAAiAAgAFAAAAKoPDAAAABwAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8G8B AAASAArwCAAAAFVwAwAACgAAEwEL8IAAAACAAGjeohaBAH05AACCAAAAAACDAH05AACEAH05AACK AFVwAwC/AAQABACBAf+ZzACDAQBmMwC/ARAAEADAARoaGgDCAeXl5QDLAZAkAAD/AQgACAA/AgAA AgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwAZQAgADMANgAAABMAIvEGAAAAvwEAAGAAAAAQ 8AgAAACTCrwFsQoRCw8ADfCxAAAAAACfDwQAAAAEAAAAAACoDyMAAABPdGhlciBQYXJhbWV0ZXIg c3ViLXN1Yi1zdWItVExWcy4uLgAAoQ82AAAAJAAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAjAAAA AABjAAsACAALAAkAAQAAAAAAIgAIABQAAACqDyYAAAAcAAAABgAAAAkEBAgEAAAABwAAAAMACQQE CAQAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8IABAAASAArwCAAAAFhwAwAACgAAEwEL8IAA AACAAPxiBBeBAH05AACCAAAAAACDAH05AACEAH05AACKAFhwAwC/AAQABACBAf//mQCDAQAAZgC/ ARAAEADAARoaGgDCAeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEA bgBnAGwAZQAgADQAMwAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAB0CxMFRAtwDA8ADfDCAAAAAACf DwQAAAAEAAAAAACoDzQAAABPdGhlciBXYXZlbGVuZ3RoIHJlbGF0ZWQgSW1wYWlybWVudA1zdWIt c3ViLVRMVnMgLi4uAAChDzYAAAA1AAAAAACyKAoAAgD8AAYAAAAAAQEAMgAHADQAAAAAAGMACwAI AAsACQABAAAAAAAiAAgAFAAAAKoPJgAAACwAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIBQAAAAYA AAAJBAQIAACmDwYAAAABAAAA+QEPAATwSwEAABIACvAIAAAAWnADAAAKAAATAQvwgAAAAIAA0HcE F4EAfTkAAIIAAAAAAIMAfTkAAIQAfTkAAIoAWnADAL8ABAAEAIEB/5nMAIMBAGYzAL8BEAAQAMAB GhoaAMIB5eXlAMsBkCQAAP8BCAAIAD8CAAACAIDDGgAAAIgDAQAAAFIAZQBjAHQAYQBuAGcAbABl ACAANAA5AAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAIsHugWuCvsHDwAN8I0AAAAAAJ8PBAAAAAQA AAAAAKgPGQAAAFBhcmFtZXRlciBzdWItc3ViLXN1Yi1UTFYAAKEPNgAAABoAAAAAALIoCgACAPwA BgAAAAABAQAyAAcAGQAAAAAAYwALAAgACwAJAAEAAAAAACIACAAUAAAAqg8MAAAAGgAAAAYAAAAJ BAQIAACmDwYAAAABAAAA+QEPAATwjgEAABIACvAIAAAAW3ADAAAKAAATAQvwgAAAAIAA3IEEF4EA fTkAAIIAAAAAAIMAfTkAAIQAfTkAAIoAW3ADAL8ABAAEAIEB/5nMAIMBAGYzAL8BEAAQAMABGhoa AMIB5eXlAMsBtiQAAP8BCAAIAD8CAAACAIDDGgAAAIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAA NQAwAAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAABMIugWuCpIIDwAN8NAAAAAAAJ8PBAAAAAQAAAAA AKAPQgAAAE8AdABoAGUAcgAgAFAAYQByAGEAbQBlAHQAZQByACAAcwB1AGIALQBzAHUAYgAtAHMA dQBiAC0AVABMAFYAcwAmIAAAoQ82AAAAIgAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAhAAAAAABj AAsACAALAAkAAQAAAAAAIgAIABQAAACqDyYAAAAcAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAIA AAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8D4BAAASAArwCAAAAFxwAwAACgAAEwEL8IAAAACA ABiMBBeBAH05AACCAAAAAACDAH05AACEAH05AACKAFxwAwC/AAQABACBAf/MAACDAQAz/wC/ARAA EADAARoaGgDCAeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBn AGwAZQAgADUAMwAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAB4BhsFRAvoBg8ADfCAAAAAAACfDwQA AAAEAAAAAACoDwwAAABDb21wb25lbnQgSUQAAKEPNgAAAA0AAAAAALIoCgACAPwABgAAAAABAQAy AAcADAAAAAAAYwALAAgACwAJAAEAAAAAACIACAAUAAAAqg8MAAAADQAAAAYAAAAJBAQIAACmDwYA AAABAAAA+QEPAATwAAIAABIACvAIAAAAXXADAAAKAADzAAvwWgAAAH8AAAAEAIAALHawD4EAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABdBI4N0hQpDA8ADfA4AQAAAACfDwQAAAAEAAAA AACoD3oAAABDb21wb25lbnQ6IFRoZSBlbGVtZW50cyB0aGF0IHRoZSBsaW5rIHBhc3NlcyB0aHJv dWdoOg0wPVRyYW5zbWl0dGVyIA0xPSBGaWJlcg0yPSBEQ00NMz1BdHRlbnVhdG9yDTQ9UmVjZWl2 ZXIgDTU9QW1wbGlmaWVyIAAAoQ9WAAAANgAAAAAAsyAKAAMA2AAGAAAAAAEUAAcARQAAAAEAMSAK AAEABgAAAAABFAAHADYAAAAAACIACAASAEMAAAAABCIAAAQIABAAAgAAAAAEIgAABAgAFAAAAKoP NAAAAEgAAAAGAAAACQgECAUAAAAHAAAAAwAJCAQILQAAAAYAAAAJCAQIAQAAAAcAAAAAAAQICQgA AKYPCAAAAAkAAAD5AW8ADwAE8EgAAAASAArwCAAAAAFwAwAADAAAgwAL8DAAAACBAQAAAAiDAQUA AAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAPAAXwAAAAABAA8AcgAAAA//// AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAHVXygGQN3iBAAAAKwQAAAAAAAAAHwBE8T0AAAAA ACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAC5Ff////8SAAAADwA98Q0AAABAAULxBQAAAAEJ AAAADwACKwAAAAAPAO4DhRQAAAIA7wMYAAAAAQAAAA0OAAAAAAAABwAAgAAAAAAHAAswDwAMBJwT AAAPAALwlBMAANAHCPAIAAAAEgAAAEDYAwAQABjxBAAAAAEAAAAPAAPwIBMAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA2AMABQAAAA8ABPB4AAAAEgAK8AgAAAAC2AMA IAIAAGMAC/AkAAAAfwAAAAQAgAA0b7APvwEAAAEA/wEAAAEAAQMCAAMAiAMAAAAAAAAQ8AgAAAB3 ACcBZxWXAg8AEfAQAAAAAADDCwgAAAAAAAAADQCwDw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8H8B AAASAArwCAAAABTYAwAACgAA8wAL8FoAAAB/AAAABACAANBZpRaBAGA1AQCCALCaAACDAGA1AQCE ALCaAAC/AAAADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwB/AwAA DwCTACLxNgAAAH8BAABAAL8BAABgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAEPAIAAAAtwToDSwV6goPAA3wtwAAAAAAnw8EAAAABAAAAAAAqA8hAAAAQ29tcG9u ZW50IHR5cGU6DTg9UGh5c2ljYWwgbm9kZSAgAAChD0gAAAAQAAAAAACyIAoAAgDYAAYAAAAAARQA BwASAAAAAQAxIAoAAQAGAAAAAAEUAAcAEAAAAAAAIgAIABIAEgAAAAAEIgAABAgAEAAAAKoPGgAA ACEAAAAGAAAACQgECAEAAAAHAAAAAAAECAkIAACmDwgAAAAJAAAA+QFvAA8ABPD3AAAAEgAK8AgA AAAt2AMAAAoAAKMAC/A8AAAAgAAk0wQXgQDi2QAAggAAAAAAgwDi2QAAhADxbAAAigAt2AMAiwAC AAAAgQHH7cwAvwEAABAAiAMBAAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAPICdAMzDe4NDwAN8H0A AAAAAJ8PBAAAAAQAAAAAAKgPBwAAAFBMSSBMU0EAAKEPOAAAAAgAAAAAALI4CgACAPwABgAAAAAB AwBgADIABwAHAAAAAABjAAsACAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAAIAAAABgAAAAkEBAgA AKYPBgAAAAEAAAD5AQ8ABPAUAQAAEgAK8AgAAAAu2AMAAAoAALMAC/BCAAAAgAC0XjgWgQDi2QAA ggAAAAAAgwDi2QAAhADxbAAAhQABAAAAigAu2AMAiwACAAAAgQHM//8AvwEQABAAiAMBAAAAEwAi 8QYAAAC/AQAAYAAAABDwCAAAACgEDASTDJMNDwAN8JQAAAAAAJ8PBAAAAAQAAAAAAKgPHgAAAFRP UCBUTFYgKE5vZGUgUExJIFRMViwgdHlwZT0xKQAAoQ84AAAAHwAAAAAAsjgKAAIA/AAGAAAAAAEB AGAAMgAHAB4AAAAAAGMACwAIAAsACQABAAAAAAAiAAgAFAAAAKoPDAAAAB8AAAAGAAAACQQECAAA pg8GAAAAAQAAAPkBDwAE8AQBAAASAArwCAAAAC/YAwAACgAAswAL8EIAAACAAAiqOBaBAOLZAACC AAAAAACDAOLZAACEAPFsAACFAAEAAACKAC/YAwCLAAIAAACBAcyZ/wC/ARAAEACIAwEAAAATACLx BgAAAL8BAABgAAAAEPAIAAAAegMQBI8MAgQPAA3whAAAAAAAnw8EAAAABAAAAAAAqA8OAAAAUExJ IExTQSBoZWFkZXIAAKEPOAAAAA8AAAAAALI4CgACAPwABgAAAAABAQBgADIABwAOAAAAAABjAAsA CAALAAkAAQAAAAAAIgAIABQAAACqDwwAAAAPAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPAF AQAAEgAK8AgAAAAw2AMAAAoAALMAC/BCAAAAgAAYpTgWgQDi2QAAggAAAAAAgwDi2QAAhADxbAAA hQABAAAAigAw2AMAiwACAAAAgQHM/8wAvwEQABAAiAMBAAAAEwAi8QYAAAC/AQAAYAAAABDwCAAA AIoEogTDCwAFDwAN8IUAAAAAAJ8PBAAAAAQAAAAAAKgPDwAAAE5vZGUgSVAgc3ViLVRMVgAAoQ84 AAAAEAAAAAAAsjgKAAIA/AAGAAAAAAEBAGAAMgAHAA8AAAAAAGMACwAIAAsACQABAAAAAAAiAAgA FAAAAKoPDAAAABAAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8BIBAAASAArwCAAAADHYAwAA CgAAswAL8EIAAACAADS4OBaBAOLZAACCAAAAAACDAOLZAACEAPFsAACFAAEAAACKADHYAwCLAAIA AACBAcz/zAC/ARAAEACIAwEAAAATACLxBgAAAL8BAABgAAAAEPAIAAAAEgWmBMcL+wsPAA3wkgAA AAAAnw8EAAAABAAAAAAAqA8cAAAAQ29tcG9uZW50IEltcGFpcm1lbnQgc3ViLVRMVgAAoQ84AAAA HQAAAAAAsjgKAAIA/AAGAAAAAAEBAGAAMgAHABwAAAAAAGMACwAIAAsACQABAAAAAAAiAAgAFAAA AKoPDAAAAB0AAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8CABAAASAArwCAAAADLYAwAACgAA 0wAL8E4AAACAAES2OBaBAOLZAACCAAAAAACDAOLZAACEAPFsAACFAAEAAACKADLYAwCLAAIAAACB Acz/zAC/ARAAEADOAQYAAAD/AQgACACIAwEAAAATACLxBgAAAL8BAABgAAAAEPAIAAAAVgyeBL8L UA0PAA3wlAAAAAAAnw8EAAAABAAAAAAAqA8eAAAAT3RoZXIgY29tcG9uZW50IHN1Yi1UTFYNLi4u Li4uAAChDzgAAAAfAAAAAACyOAoAAgD8AAYAAAAAAQEAYAAyAAcAHgAAAAAAYwALAAgACwAJAAEA AAAAACIACAAUAAAAqg8MAAAAHwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwIQEAABIACvAI AAAAM9gDAAAKAACzAAvwQgAAAIAA3ME4FoEA4tkAAIIAAAAAAIMA4tkAAIQA8WwAAIUAAQAAAIoA M9gDAIsAAgAAAIEB//+ZAL8BEAAQAIgDAQAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAAgBkUFKQvm Bw8ADfChAAAAAACfDwQAAAAEAAAAAACoDysAAABXYXZlbGVuZ3RoIHVucmVsYXRlZCBJbXBhaXJt ZW50IHN1Yi1zdWItVExWAAChDzgAAAAsAAAAAACyOAoAAgD8AAYAAAAAAQEAYAAyAAcAKwAAAAAA YwALAAgACwAJAAEAAAAAACIACAAUAAAAqg8MAAAALAAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEP AATwHwEAABIACvAIAAAANNgDAAAKAACzAAvwQgAAAIAA9Kw4FoEA4tkAAIIAAAAAAIMA4tkAAIQA 8WwAAIUAAQAAAIoANNgDAIsAAgAAAIEB//+ZAL8BEAAQAIgDAQAAABMAIvEGAAAAvwEAAGAAAAAQ 8AgAAAATCEEFJQthCg8ADfCfAAAAAACfDwQAAAAEAAAAAACoDykAAABXYXZlbGVuZ3RoIHJlbGF0 ZWQgSW1wYWlybWVudCBzdWItc3ViLVRMVgAAoQ84AAAAKgAAAAAAsjgKAAIA/AAGAAAAAAEBAGAA MgAHACkAAAAAAGMACwAIAAsACQABAAAAAAAiAAgAFAAAAKoPDAAAACoAAAAGAAAACQQECAAApg8G AAAAAQAAAPkBDwAE8AMBAAASAArwCAAAADXYAwAACgAAswAL8EIAAACAALjiOBaBAOLZAACCAAAA AACDAOLZAACEAPFsAACFAAEAAACKADXYAwCLAAIAAACBAf/MmQC/ARAAEACIAwEAAAATACLxBgAA AL8BAABgAAAAEPAIAAAAkQjSBYsK9ggPAA3wgwAAAAAAnw8EAAAABAAAAAAAqA8NAAAAV2F2ZWxl bmd0aCBJRAAAoQ84AAAADgAAAAAAsjgKAAIA/AAGAAAAAAEBAGAAMgAHAA0AAAAAAGMACwAIAAsA CQABAAAAAAAiAAgAFAAAAKoPDAAAAA4AAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8A8BAAAS AArwCAAAADfYAwAACgAAswAL8EIAAACAAMAHOBaBAOLZAACCAAAAAACDAOLZAACEAPFsAACFAAEA AACKADfYAwCLAAIAAACBAf+ZzAC/ARAAEACIAwEAAAATACLxBgAAAL8BAABgAAAAEPAIAAAAGAnS BYsKjwkPAA3wjwAAAAAAnw8EAAAABAAAAAAAqA8ZAAAAUGFyYW1ldGVyIHN1Yi1zdWItc3ViLVRM VgAAoQ84AAAAGgAAAAAAsjgKAAIA/AAGAAAAAAEBAGAAMgAHABkAAAAAAGMACwAIAAsACQABAAAA AAAiAAgAFAAAAKoPDAAAABoAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8DQBAAASAArwCAAA ADnYAwAACgAAswAL8EIAAACAAPwaOBaBAOLZAACCAAAAAACDAOLZAACEAPFsAACFAAEAAACKADnY AwCLAAIAAACBAf+ZzAC/ARAAEACIAwEAAAATACLxBgAAAL8BAABgAAAAEPAIAAAAsgnSBYsKPQoP AA3wtAAAAAAAnw8EAAAABAAAAAAAqA8kAAAAT3RoZXIgUGFyYW1ldGVyIHN1Yi1zdWItc3ViLVRM VnMuLi4uAAChDzgAAAAlAAAAAACyOAoAAgD8AAYAAAAAAQEAYAAyAAcAJAAAAAAAYwALAAgACwAJ AAEAAAAAACIACAAUAAAAqg8mAAAAHAAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgFAAAABgAAAAkE BAgAAKYPBgAAAAEAAAD5AQ8ABPBhAQAAEgAK8AgAAAA82AMAAAoAALMAC/BCAAAAgACsJjgWgQDi 2QAAggAAAAAAgwDi2QAAhADxbAAAhQABAAAAigA82AMAiwACAAAAgQH//5kAvwEQABAAiAMBAAAA EwAi8QYAAAC/AQAAYAAAABDwCAAAAL4KQQUlC6gLDwAN8OEAAAAAAJ8PBAAAAAQAAAAAAKgPNwAA AE90aGVyIFdhdmVsZW5ndGhfcmVsYXRlZCBJbXBhaXJtZW50DXN1Yi1zdWItVExWcyAuLi4uLi4A AKEPOAAAADgAAAAAALI4CgACAPwABgAAAAABAQBgADIABwA3AAAAAABjAAsACAALAAkAAQAAAAAA IgAIABQAAACqD0AAAAAGAAAABgAAAAkEBAgSAAAABwAAAAMACQQECBQAAAAGAAAACQQECAQAAAAH AAAAAwAJBAQICAAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwDwEAABIACvAIAAAAPdgDAAAK AACzAAvwQgAAAIAA0EM4FoEA4tkAAIIAAAAAAIMA4tkAAIQA8WwAAIUAAQAAAIoAPdgDAIsAAgAA AIEB/5nMAL8BEAAQAIgDAQAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAACjBt8FlwoRBw8ADfCPAAAA AACfDwQAAAAEAAAAAACoDxkAAABQYXJhbWV0ZXIgc3ViLXN1Yi1zdWItVExWAAChDzgAAAAaAAAA AACyOAoAAgD8AAYAAAAAAQEAYAAyAAcAGQAAAAAAYwALAAgACwAJAAEAAAAAACIACAAUAAAAqg8M AAAAGgAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwMwEAABIACvAIAAAAP9gDAAAKAACzAAvw QgAAAIAAMIk4FoEA4tkAAIIAAAAAAIMA4tkAAIQA8WwAAIUAAQAAAIoAP9gDAIsAAgAAAIEB/5nM AL8BEAAQAIgDAQAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAAyB98FlwqtBw8ADfCzAAAAAACfDwQA AAAEAAAAAACoDyMAAABPdGhlciBQYXJhbWV0ZXIgc3ViLXN1Yi1zdWItVExWcy4uLgAAoQ84AAAA JAAAAAAAsjgKAAIA/AAGAAAAAAEBAGAAMgAHACMAAAAAAGMACwAIAAsACQABAAAAAAAiAAgAFAAA AKoPJgAAABwAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIBAAAAAYAAAAJBAQIAACmDwYAAAABAAAA +QEPAATwAgEAABIACvAIAAAAQNgDAAAKAACzAAvwQgAAAIAAVI04FoEA4tkAAIIAAAAAAIMA4tkA AIQA8WwAAIUAAQAAAIoAQNgDAIsAAgAAAIEB/8wAAL8BEAAQAIgDAQAAABMAIvEGAAAAvwEAAGAA AAAQ8AgAAACGBTYFEgvjBQ8ADfCCAAAAAACfDwQAAAAEAAAAAACoDwwAAABDb21wb25lbnQgSUQA AKEPOAAAAA0AAAAAALI4CgACAPwABgAAAAABAQBgADIABwAMAAAAAABjAAsACAALAAkAAQAAAAAA IgAIABQAAACqDwwAAAANAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBIAAAAEgAK8AgAAAAB 2AMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCK E4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAZA3eIEAAAAr BAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAALkV/////xIAAAAP AD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gO/CAAAAgDvAxgAAAABAAAADQ4AAAAAAAAH AACAAAAAAAcACzAPAAwE1gcAAA8AAvDOBwAA4AcI8AgAAAAKAAAAcN0DAA8AA/BmBwAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADcAwAFAAAADwAE8HgAAAASAArwCAAA AALcAwAgAgAAYwAL8CQAAAB/AAAABACAACzTrw+/AQAAAQD/AQAAAQABAwIAAwCIAwAAAAAAABDw CAAAAHcAIAFgFZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAK8PDwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwRAAAALIECvAIAAAABNwDAAAKAABDAAvwHAAAAARBAwAAAAXBBAAAAAYBAgAAAP8BAAAIADcA AAAAABDwCAAAAKcDkQJJFPEFDwAE8GEBAAASAArwCAAAAAXcAwAACgAAMwEL8HIAAAB/AAAABACA AFSgrw+BAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwCBAQQAAAiDAQAA AAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAA AH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAxQI3AlwMpAMPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8lAAAAQ29tcG9uZW50IGltcGFp cm1lbnRzIHN1Yi1UTFYgRm9ybWF0IAAAoQ8sAAAAJgAAAAAAswAAAAMA2AAGAAAAAAEkAAAAAAAi AAgAEAACAAAAAAAiAAgAEgAAAKoPDAAAACYAAAAGAAAACQQECA8ABPAuAAAAsgQK8AgAAADz3AMA AAoAABMAC/AGAAAABEEHAAAAAAAQ8AgAAAAyB5ECSRT1CA8ABPAuAAAAsgQK8AgAAAD13AMAAAoA ABMAC/AGAAAABEEJAAAAAAAQ8AgAAADdCZECSRSgCw8ABPBpAQAAEgAK8AgAAAD43AMAAAoAADMB C/ByAAAAfwAAAAQAgABgujcWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwAGAAAAvwAC AA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/ BgYATgB/BgYADgAAABDwCAAAAOULZALwDbEMDwAN8IkAAAAAAJ8PBAAAAAQAAAAAAKgPKwAAAElt cGFpcm1lbnQgUGFyYW1ldGVyIFN1Yi1zdWItc3ViLVRMViBGb3JtYXQAAKEPIAAAACwAAAAAALMA AAADANgABgAAAAABLAAAAAAAIgAIABAAAACqDxoAAAArAAAABgAAAAkEBAgBAAAABwAAAAAABAgJ BA8ABPBuAQAAEgAK8AgAAAD53AMAAAoAADMBC/ByAAAAfwAAAAQAgABYnDcWgQBgNQEAggCwmgAA gwBgNQEAhACwmgAAhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAA wAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAACUJNwLDDvEJDwAN 8I4AAAAAAJ8PBAAAAAQAAAAAAKgPMAAAAFdhdmVsZW5ndGggcmVsYXRlZCBJbXBhaXJtZW50IFN1 Yi1zdWItVExWIEZvcm1hdAAAoQ8gAAAAMQAAAAAAswAAAAMA2AAGAAAAAAExAAAAAAAiAAgAEAAA AKoPGgAAADAAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEDwAE8HABAAASAArwCAAAAPrcAwAACgAA MwEL8HIAAAB/AAAABACAAORFsA+BAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAYAAAC/ AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBO AD8GBgBOAH8GBgAOAAAAEPAIAAAAUAZkAn4PHAcPAA3wkAAAAAAAnw8EAAAABAAAAAAAqA8yAAAA V2F2ZWxlbmd0aCB1bnJlbGF0ZWQgSW1wYWlybWVudCBTdWItc3ViLVRMViBGb3JtYXQAAKEPIAAA ADMAAAAAALMAAAADANgABgAAAAABMwAAAAAAIgAIABAAAACqDxoAAAAyAAAABgAAAAkEBAgBAAAA BwAAAAAABAgJBA8ABPAuAAAAsgQK8AgAAABw3QMAAAoAABMAC/AGAAAABEEIAAAAAAAQ8AgAAADP DJECSRQcDg8ABPBIAAAAEgAK8AgAAAAB3AMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sA lAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+Dj ADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT aQAAAAAA6y4IAAAAdVfKAZA3eIEAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAA AAAAAAAAAAAAAAAAALkV/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gN8 VgAAAgDvAxgAAAABAAAADQ4AAAAAAAAHAACAAAAAAAcACzAPAAwEk1UAAA8AAvCLVQAAEAgI8AgA AABQAAAA6fIDAA8AA/AjVQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AADoAwAFAAAADwAE8HgAAAASAArwCAAAAALoAwAgAgAAYwAL8CQAAAB/AAAABACAAOBysA+/AQAA AQD/AQAAAQABAwIAAwCIAwAAAAAAABDwCAAAAHcAdAG0FZcCDwAR8BAAAAAAAMMLCAAAAAAAAAAN ALAPDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATw/gEAABIACvAIAAAABOgDAAAKAAAjAQvwbAAAAH8A AAAEAIAAQGSwD4EAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAgAPAIEBBAAACIMBAAAA CL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAA fwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ 8AgAAAApDJECSRQpDg8ADfAkAQAAAACfDwQAAAAEAAAAAACoD7oAAABOb3RlIHRoYXQgdGhpcyB0 YWJsZSBjYW4gYmUgdXBkYXRlZCBiYXNlZCBvbiBJVFUtVCBkZWZpbml0aW9uIHJlbGF0ZWQgdG8g cGh5c2ljYWwgaW1wYWlybWVudHMuIFRoZSBUTFYgZm9ybWF0IGRvIG5vdCBuZWVkIHRvIGJlIGNo YW5nZWQgd2hlbiB0aGUgcGh5c2ljYWwgaW1wYWlybWVudHMgZGVmaW5pdGlvbiB1cGRhdGVkLiAA AKEPOgAAALsAAAAAALMAAAADANgABgAAAAABbgAAAAAAIgAIABAABgAAAAEAIgABAAgAEABHAAAA AAAiAAgAEAAAAKoPDAAAALsAAAAGAAAACQQECA8ABPACAQAAEgAK8AgAAAD36wMAAAoAADMBC/By AAAAfwAAAAQAgABI66UWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8A gQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMA AA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYA TgB/BgYADgAAABDwCAAAAMX9AACAFsX9DwAN8CIAAAAAAJ8PBAAAAAQAAAAAAKoPDgAAAAEAAAAH AAAAAAAECAkEDwAD8FFQAAAPAATwpAAAAAEACfAQAAAA/AMAAJcCAAAoEgAARgwAAAIACvAIAAAA 6fIDAAECAAATAAvwBgAAAH8AAAEAASMAIvFWAAAAnwMBAAAAoMNKAAAAEQAUAAQASQAAAEkAAABJ AAAASQAAAGkAAABJAAAASQAAAEkAAACHAAAAhwAAAEkAAABJAAAASQAAAEkAAABJAAAAnwAAAEkA AAAAABDwCAAAAJcC/AMoEkYMDwAE8CIBAAASAArwCAAAAOLyAwACCgAAIwEL8GwAAAB/AAAABACA AJBWOBaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkA HwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABA AL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA cA4AAB8HAAAoEgAAsAcAAA8ADfBAAAAAAACfDwQAAAAEAAAAAAChDxgAAAABAAAAAAAAAAAAAQAA AAAAIwALAAgACgAAAKoPDAAAAAEAAAAGAAAACQQECA8ABPA/AQAAEgAK8AgAAADg8gMAAgoAACMB C/BsAAAAfwAAAAQAgAAciDgWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEE AAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A kwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAAA/wEAAAADgHAAAfBwAAcA4AALAHAAAPAA3wXQAAAAAAnw8EAAAABAAAAAAAqA8VAAAA MjQgPSBEaXNwZXJzaW9uIHNsb3BlAAChDxgAAAAWAAAAAAAAAAAAFgAAAAAAIwALAAgACgAAAKoP DAAAABYAAAAGAAAACQQECA8ABPAiAQAAEgAK8AgAAACx8AMAAgoAACMBC/BsAAAAfwAAAAQAgADo ekQRgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/ AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAO AAC1CwAAKBIAAEYMAAAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAAAAAAAAEAAAAA ACMACwAIAAoAAACqDwwAAAABAAAABgAAAAkEBAgPAATwNgEAABIACvAIAAAAsPADAAIKAAAjAQvw bAAAAH8AAAAEAIAAVG1EEYEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAA CIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMA IvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYG AA4AAAAP8BAAAAA4BwAAtQsAAHAOAABGDAAADwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACYg AAChDyIAAAACAAAAAAAAAAAAAQAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDwwAAAACAAAABgAA AAkEBAgPAATwPwEAABIACvAIAAAArvADAAIKAAAjAQvwbAAAAH8AAAAEAIAA/F5EEYEAYDUBAIIA sJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAO AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAA vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAABwDgAAFgsAACgSAAC1 CwAADwAN8F0AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAHVucmVsYXRlZAAAoQ8kAAAACgAAAAAAAAgA AAEACQAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDwwAAAAKAAAABgAAAAkEBAgPAATwawEAABIA CvAIAAAArfADAAIKAAAjAQvwbAAAAH8AAAAEAIAATFFEEYEAYDUBAIIAsJoAAIMAYDUBAIQAsJoA AIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAAFgsAAHAOAAC1CwAADwAN8IkAAAAAAJ8P BAAAAAQAAAAAAKgPHQAAADEwMiA9IEFtcGxpZmllciBHYWluIChHYWluZEIpAAChDyIAAAAeAAAA AAAAAAAAHQAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDyYAAAAWAAAABgAAAAkEBAgGAAAABwAA AAMACQQECAIAAAAGAAAACQQECA8ABPA/AQAAEgAK8AgAAACr8AMAAgoAACMBC/BsAAAAfwAAAAQA gADoQUQRgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJ AB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAA QAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAA AHAOAACFCgAAKBIAABYLAAAPAA3wXQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAdW5yZWxhdGVkAACh DyQAAAAKAAAAAAAACAAAAQAJAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAAoAAAAGAAAA CQQECA8ABPB1AQAAEgAK8AgAAACq8AMAAgoAACMBC/BsAAAAfwAAAAQAgAA0NEQRgQBgNQEAggCw mgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAACFCgAAcA4AABYL AAAPAA3wkwAAAAAAnw8EAAAABAAAAAAAqA8nAAAAMTAxID0gU3BvbnRhbmVvdXMgZW1pc3Npb24g ZmFjdG9yIChuc3ApAAChDyIAAAAoAAAAAAAAAAAAJwAAAAAAIwALAAgACgABAAAAAAQAAAAEAACq DyYAAAAjAAAABgAAAAkEBAgDAAAABwAAAAMACQQECAIAAAAGAAAACQQECA8ABPBDAQAAEgAK8AgA AACp8AMAAgoAACMBC/BsAAAAfwAAAAQAgACYJEQRgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwAB AAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAPwDAACFCgAAOAcAAEYMAAAPAA3wYQAAAAAAnw8EAAAA BAAAAAAAqA8NAAAANSA9IEFtcGxpZmllcgAAoQ8kAAAADgAAAAAAAAgAAAEADQAAAAAAIwALAAgA CgABAAAAAAQAAAAEAACqDwwAAAAOAAAABgAAAAkEBAgPAATwIgEAABIACvAIAAAAk/ADAAIKAAAj AQvwbAAAAH8AAAAEAIAABJAxFIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEB BAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A fwYGAA4AAAAP8BAAAABwDgAA9AkAACgSAACFCgAADwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKEPGAAA AAEAAAAAAAAAAAABAAAAAAAjAAsACAAKAAAAqg8MAAAAAQAAAAYAAAAJBAQIDwAE8DYBAAASAArw CAAAAJLwAwACCgAAIwEL8GwAAAB/AAAABACAADSBMRSBAGA1AQCCALCaAACDAGA1AQCEALCaAACH AAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEA DwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBO AP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAOAcAAPQJAABwDgAAhQoAAA8ADfBUAAAAAACfDwQA AAAEAAAAAACgDwIAAAAmIAAAoQ8iAAAAAgAAAAAAAAAAAAEAAAAAACMACwAIAAoAAQAAAAAEAAAA BAAAqg8MAAAAAgAAAAYAAAAJBAQIDwAE8D0BAAASAArwCAAAAITwAwACCgAAIwEL8GwAAAB/AAAA BACAAKToMhSBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/ AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8B AABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQ AAAAcA4AAGMJAAAoEgAA9AkAAA8ADfBbAAAAAACfDwQAAAAEAAAAAACoDwcAAAByZWxhdGVkAACh DyQAAAAIAAAAAAAACAAAAQAHAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAAgAAAAGAAAA CQQECA8ABPBRAQAAEgAK8AgAAACD8AMAAgoAACMBC/BsAAAAfwAAAAQAgACU2zIUgQBgNQEAggCw mgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAABjCQAAcA4AAPQJ AAAPAA3wbwAAAAAAnw8EAAAABAAAAAAAqA8dAAAAODIgPSBBYnNvbHV0ZSB0aHJlc2hvbGQgbGV2 ZWwAAKEPIgAAAB4AAAAAAAAAAAAdAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAB4AAAAG AAAACQQECA8ABPA9AQAAEgAK8AgAAACB8AMAAgoAACMBC/BsAAAAfwAAAAQAgABIzTIUgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAA wAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAADSCAAAKBIA AGMJAAAPAA3wWwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAcmVsYXRlZAAAoQ8kAAAACAAAAAAAAAgA AAEABwAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDwwAAAAIAAAABgAAAAkEBAgPAATwXwEAABIA CvAIAAAAgPADAAIKAAAjAQvwbAAAAH8AAAAEAIAArL8yFIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoA AIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAA0ggAAHAOAABjCQAADwAN8H0AAAAAAJ8P BAAAAAQAAAAAAKgPEQAAADgxID0gUmVzcG9uc2l2aXR5AAChDyIAAAASAAAAAAAAAAAAEQAAAAAA IwALAAgACgABAAAAAAQAAAAEAACqDyYAAAAFAAAABgAAAAkEBAgMAAAABwAAAAMACQQECAEAAAAG AAAACQQECA8ABPBCAQAAEgAK8AgAAAB/8AMAAgoAACMBC/BsAAAAfwAAAAQAgAD8rzIUgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAA wAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAPwDAADSCAAAOAcA AIUKAAAPAA3wYAAAAAAAnw8EAAAABAAAAAAAqA8MAAAANCA9IFJlY2VpdmVyAAChDyQAAAANAAAA AAAACAAAAQAMAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAA0AAAAGAAAACQQECA8ABPA9 AQAAEgAK8AgAAAB+8AMAAgoAACMBC/BsAAAAfwAAAAQAgAAo6TwWgQBgNQEAggCwmgAAgwBgNQEA hACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYA TgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAABBCAAAKBIAANIIAAAPAA3wWwAA AAAAnw8EAAAABAAAAAAAqA8HAAAAcmVsYXRlZAAAoQ8kAAAACAAAAAAAAAgAAAEABwAAAAAAIwAL AAgACgABAAAAAAQAAAAEAACqDwwAAAAIAAAABgAAAAkEBAgPAATwSwEAABIACvAIAAAAffADAAIK AAAjAQvwbAAAAH8AAAAEAIAAwNs8FoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAP AIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAP8BAAAAA4BwAAQQgAAHAOAADSCAAADwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgP FwAAADYxID0gQXR0ZW51YXRpb24gKEF0dG4pAAChDyIAAAAYAAAAAAAAAAAAFwAAAAAAIwALAAgA CgABAAAAAAQAAAAEAACqDwwAAAAYAAAABgAAAAkEBAgPAATwRAEAABIACvAIAAAAfPADAAIKAAAj AQvwbAAAAH8AAAAEAIAAFMs8FoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEB BAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A fwYGAA4AAAAP8BAAAAD8AwAAQQgAADgHAADSCAAADwAN8GIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAA ADMgPSBBdHRlbnVhdG9yAAChDyQAAAAPAAAAAAAACAAAAQAOAAAAAAAjAAsACAAKAAEAAAAABAAA AAQAAKoPDAAAAA8AAAAGAAAACQQECA8ABPAiAQAAEgAK8AgAAABv8AMAAgoAACMBC/BsAAAAfwAA AAQAgAD484wWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAI vwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/ AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/w EAAAAHAOAACwBwAAKBIAAEEIAAAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAAAAAA AAEAAAAAACMACwAIAAoAAACqDwwAAAABAAAABgAAAAkEBAgPAATwLAEAABIACvAIAAAAbvADAAIK AAAjAQvwbAAAAH8AAAAEAIAAGOWMFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAP AIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAP8BAAAAA4BwAAsAcAAHAOAABBCAAADwAN8EoAAAAAAJ8PBAAAAAQAAAAAAKAP AgAAACYgAAChDxgAAAACAAAAAAAAAAAAAgAAAAAAIwALAAgACgAAAKoPDAAAAAIAAAAGAAAACQQE CA8ABPA/AQAAEgAK8AgAAABp8AMAAgoAACMBC/BsAAAAfwAAAAQAgADA2pQWgQBgNQEAggCwmgAA gwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCC AIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAACOBgAAKBIAAB8HAAAP AA3wXQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAVW5yZWxhdGVkAAChDyQAAAAKAAAAAAAACAAAAQAJ AAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAAoAAAAGAAAACQQECA8ABPBRAQAAEgAK8AgA AABo8AMAAgoAACMBC/BsAAAAfwAAAAQAgAAQzJQWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwAB AAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAACOBgAAcA4AAB8HAAAPAA3wbwAAAAAAnw8EAAAA BAAAAAAAqA8dAAAAMjMgPSBEaXNwZXJzaW9uIHBhcmFtZXRlciAoRCkAAKEPIgAAAB4AAAAAAAAA AAAdAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAB4AAAAGAAAACQQECA8ABPA/AQAAEgAK 8AgAAABm8AMAAgoAACMBC/BsAAAAfwAAAAQAgABkvpQWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAA hwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAAD9BQAAKBIAAI4GAAAPAA3wXQAAAAAAnw8E AAAABAAAAAAAqA8JAAAAdW5yZWxhdGVkAAChDyQAAAAKAAAAAAAACAAAAQAJAAAAAAAjAAsACAAK AAEAAAAABAAAAAQAAKoPDAAAAAoAAAAGAAAACQQECA8ABPBFAQAAEgAK8AgAAABl8AMAAgoAACMB C/BsAAAAfwAAAAQAgADMsJQWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEE AAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A kwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAAA/wEAAAADgHAAD9BQAAcA4AAI4GAAAPAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8RAAAA MjIgPSBmaWJlciBsZW5ndGgAAKEPIgAAABIAAAAAAAAAAAARAAAAAAAjAAsACAAKAAEAAAAABAAA AAQAAKoPDAAAABIAAAAGAAAACQQECA8ABPA/AQAAEgAK8AgAAABj8AMAAgoAACMBC/BsAAAAfwAA AAQAgABooZQWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAI vwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/ AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/w EAAAAHAOAABsBQAAKBIAAP0FAAAPAA3wXQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAdW5yZWxhdGVk AAChDyQAAAAKAAAAAAAACAAAAQAJAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAAAoAAAAG AAAACQQECA8ABPBDAQAAEgAK8AgAAABi8AMAAgoAACMBC/BsAAAAfwAAAAQAgADok5QWgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAA wAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAABsBQAAcA4A AP0FAAAPAA3wYQAAAAAAnw8EAAAABAAAAAAAqA8PAAAAMjEgPSBmaWJlciB0eXBlAAChDyIAAAAQ AAAAAAAAAAAADwAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDwwAAAAQAAAABgAAAAkEBAgPAATw SgEAABIACvAIAAAAYfADAAIKAAAjAQvwbAAAAH8AAAAEAIAAPISUFoEAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAD8AwAAbAUAADgHAABBCAAADwAN8GgA AAAAAJ8PBAAAAAQAAAAAAKgPFAAAADEgPSBGaWJlcgtvcgsyID0gRENNAAChDyQAAAAVAAAAAAAA CAAAAQAUAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAABUAAAAGAAAACQQECA8ABPAiAQAA EgAK8AgAAABd8AMAAgoAACMBC/BsAAAAfwAAAAQAgACIQZQWgQBgNQEAggCwmgAAgwBgNQEAhACw mgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAADbBAAAKBIAAGwFAAAPAA3wQAAAAAAA nw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAAAAAAAAEAAAAAACMACwAIAAoAAACqDwwAAAABAAAABgAA AAkEBAgPAATwLAEAABIACvAIAAAAXPADAAIKAAAjAQvwbAAAAH8AAAAEAIAAkDOUFoEAYDUBAIIA sJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAO AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAA vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAA2wQAAHAOAABs BQAADwAN8EoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACYgAAChDxgAAAACAAAAAAAAAAAAAgAAAAAA IwALAAgACgAAAKoPDAAAAAIAAAAGAAAACQQECA8ABPA9AQAAEgAK8AgAAABU8AMAAgoAACMBC/Bs AAAAfwAAAAQAgACA0JcWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAI gwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAAA/wEAAAAHAOAABKBAAAKBIAANsEAAAPAA3wWwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUmVs YXRlZAAAoQ8kAAAACAAAAAAAAAgAAAEABwAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDwwAAAAI AAAABgAAAAkEBAgPAATwXAEAABIACvAIAAAAU/ADAAIKAAAjAQvwbAAAAH8AAAAEAIAAfMOXFoEA YDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAA CP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA /wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAASgQA AHAOAADbBAAADwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKgPKAAAADMgPSBDZW50ZXIgd2F2ZWxlbmd0 aCAoZm9yIGVhY2ggY2hhbm5lbCkAAKEPIgAAACkAAAAAAAAAAAAoAAAAAAAjAAsACAAKAAEAAAAA BAAAAAQAAKoPDAAAACkAAAAGAAAACQQECA8ABPA9AQAAEgAK8AgAAABR8AMAAgoAACMBC/BsAAAA fwAAAAQAgADMuJcWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEA AAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYA AAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAA AA/wEAAAAHAOAAC5AwAAKBIAAEoEAAAPAA3wWwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUmVsYXRl ZAAAoQ8kAAAACAAAAAAAAAgAAAEABwAAAAAAIwALAAgACgABAAAAAAQAAAAEAACqDwwAAAAIAAAA BgAAAAkEBAgPAATwPQEAABIACvAIAAAAUPADAAIKAAAjAQvwbAAAAH8AAAAEAIAADLCXFoEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8B BgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEA AMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAAuQMAAHAO AABKBAAADwAN8FsAAAAAAJ8PBAAAAAQAAAAAAKgPCQAAADIgPSBwb3dlcgAAoQ8iAAAACgAAAAAA AAAAAAkAAAAAACMACwAIAAoAAQAAAAAEAAAABAAAqg8MAAAACgAAAAYAAAAJBAQIDwAE8D0BAAAS AArwCAAAAE7wAwACCgAAIwEL8GwAAAB/AAAABACAAJztmRaBAGA1AQCCALCaAACDAGA1AQCEALCa AACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8F BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAcA4AACgDAAAoEgAAuQMAAA8ADfBbAAAAAACf DwQAAAAEAAAAAACoDwcAAABSZWxhdGVkAAChDyQAAAAIAAAAAAAACAAAAQAHAAAAAAAjAAsACAAK AAEAAAAABAAAAAQAAKoPDAAAAAgAAAAGAAAACQQECA8ABPBZAQAAEgAK8AgAAABN8AMAAgoAACMB C/BsAAAAfwAAAAQAgAAk4JkWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEE AAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A kwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAAA/wEAAAADgHAAAoAwAAcA4AALkDAAAPAA3wdwAAAAAAnw8EAAAABAAAAAAAqA8LAAAA MSA9IGJpdHJhdGUAAKEPIgAAAAwAAAAAAAAAAAALAAAAAAAjAAsACAAKAAEAAAAABAAAAAQAAKoP JgAAAAQAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIDwAE8FUBAAASAArwCAAA AEzwAwACCgAAIwEL8GwAAAB/AAAABACAADzQmRaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEA AAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8F BgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA/AMAACgDAAA4BwAAbAUAAA8ADfBzAAAAAACfDwQAAAAE AAAAAACoDxEAAAAgMCA9IFRyYW5zbWl0dGVyIAAAoQ8kAAAAEgAAAAAAAAgAAAEAEQAAAAAAIwAL AAgACgABAAAAAAQAAAAEAACqDxoAAAABAAAABwAAAAAABAgJBBEAAAAGAAAACQQECA8ABPBLAQAA EgAK8AgAAABL8AMAAgoAACMBC/BsAAAAfwAAAAQAgAD4r5kWgQBgNQEAggCwmgAAgwBgNQEAhACw mgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAACXAgAAKBIAACgDAAAPAA3waQAAAAAA nw8EAAAABAAAAAAAqA8TAAAAV2F2ZWxlbmd0aCByZWxhdGVkPwAAoQ8mAAAAFAAAAAAAAAgAAAEA EwAAAAEAIwABAAsACAAKAAEAAAAABAAAAAQAAKoPDAAAABQAAAAGAAAACQQECA8ABPBGAQAAEgAK 8AgAAABK8AMAAgoAACMBC/BsAAAAfwAAAAQAgACcopkWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAA hwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAACXAgAAcA4AACgDAAAPAA3wZAAAAAAAnw8E AAAABAAAAAAAqA8OAAAAUGFyYW1ldGVyIFR5cGUAAKEPJgAAAA8AAAAAAAAIAAABAA4AAAABACMA AQALAAgACgABAAAAAAQAAAAEAACqDwwAAAAPAAAABgAAAAkEBAgPAATwRgEAABIACvAIAAAASfAD AAIKAAAjAQvwbAAAAH8AAAAEAIAAUJSZFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIcAAQAAAL8A AAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4A PwYGAE4AfwYGAA4AAAAP8BAAAAD8AwAAlwIAADgHAAAoAwAADwAN8GQAAAAAAJ8PBAAAAAQAAAAA AKgPDgAAAENvbXBvbmVudCB0eXBlAAChDyYAAAAPAAAAAAAACAAAAQAOAAAAAQAjAAEACwAIAAoA AQAAAAAEAAAABAAAqg8MAAAADwAAAAYAAAAJBAQIDwAE8M4AAABCAQrwCAAAALjwAwACCgAAEwEL 8GYAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMz MwDLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAA AH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA /AMAAJcCAAAoEgAAlwIAAA8ABPDIAAAAQgEK8AgAAAC58AMAAgoAAAMBC/BgAAAAgQBgNQEAggCw mgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEzMzMAywGcMQAA/wEMAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/ BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAPwDAABGDAAAOAcAAEYMAAAPAATw zgAAAEIBCvAIAAAAuvADAAIKAAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAA AIcAAQAAAL8AAgAPAL8BAAAQAMABMzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUG AE4APwYGAE4AfwYGAA4AAAAP8BAAAAD8AwAAlwIAAPwDAAAoAwAADwAE8M4AAABCAQrwCAAAALvw AwACCgAAEwEL8GYAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/ AQAAEADAATMzMwDLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAA DwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAO AAAAD/AQAAAAKBIAAJcCAAAoEgAARgwAAA8ABPDIAAAAQgEK8AgAAAC+8AMAAgoAAAMBC/BgAAAA gQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEzMzMAywGc MQAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAA gAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAPwDAAAoAwAAOAcA ACgDAAAPAATwzgAAAEIBCvAIAAAAwPADAAIKAAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQA sJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMABMzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAAlwIAADgHAAAoAwAADwAE8M4AAABC AQrwCAAAAMPwAwACCgAAEwEL8GYAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEA AAC/AAIADwC/AQAAEADAATMzMwDLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8G BgBOAH8GBgAOAAAAD/AQAAAAcA4AAJcCAABwDgAARgwAAA8ABPDOAAAAQgEK8AgAAADZ8AMAAgoA ABMBC/BmAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAA wAEzMzMAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi 8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/w EAAAADgHAAC5AwAAKBIAALkDAAAPAATwzgAAAEIBCvAIAAAA3vADAAIKAAATAQvwZgAAAIEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMABMzMzAMsBnDEAANcB AAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEA AIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAASgQAACgS AABKBAAADwAE8M4AAABCAQrwCAAAAOPwAwACCgAAEwEL8GYAAACBAGA1AQCCALCaAACDAGA1AQCE ALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwxAADXAQAAAAD/AQwADgABAgIA AAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAOAcAANsEAAAoEgAA2wQAAA8ABPDOAAAA QgEK8AgAAAD18AMAAgoAABMBC/BmAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwAB AAAAvwACAA8AvwEAABAAwAEzMzMAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/ BgYATgB/BgYADgAAAA/wEAAAADgHAABsBQAAKBIAAGwFAAAPAATwzgAAAEIBCvAIAAAAFvEDAAIK AAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQ AMABMzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMA IvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP 8BAAAAA4BwAA/QUAACgSAAD9BQAADwAE8M4AAABCAQrwCAAAABvxAwACCgAAEwEL8GYAAACBAGA1 AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwxAADX AQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8B AACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAOAcAAI4GAAAo EgAAjgYAAA8ABPDOAAAAQgEK8AgAAAAg8QMAAgoAABMBC/BmAAAAgQBgNQEAggCwmgAAgwBgNQEA hACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEzMzMAywGcMQAA1wEAAAAA/wEMAA4AAQIC AAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYA TgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAAAfBwAAKBIAAB8HAAAPAATwzgAA AEIBCvAIAAAALPEDAAIKAAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcA AQAAAL8AAgAPAL8BAAAQAMABMzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4A PwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAAQQgAACgSAABBCAAADwAE8MgAAABCAQrwCAAAAEnxAwAC CgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAA EADAATMzMwDLAZwxAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAA AH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA /AMAANIIAAA4BwAA0ggAAA8ABPDOAAAAQgEK8AgAAABL8QMAAgoAABMBC/BmAAAAgQBgNQEAggCw mgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEzMzMAywGcMQAA1wEAAAAA /wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAADgHAABBCAAAOAcAANII AAAPAATwzgAAAEIBCvAIAAAAc/EDAAIKAAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoA AIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMABMzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAAYwkAACgSAABjCQAADwAE8M4AAABCAQrw CAAAAHjxAwACCgAAEwEL8GYAAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/ AAIADwC/AQAAEADAATMzMwDLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAD/AQAAAAOAcAAPQJAAAoEgAA9AkAAA8ABPDOAAAAQgEK8AgAAACV8QMAAgoAABMB C/BmAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEz MzMAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAA AAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAA ADgHAACFCgAAKBIAAIUKAAAPAATwzgAAAEIBCvAIAAAA0PEDAAIKAAATAQvwZgAAAIEAYDUBAIIA sJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMABMzMzAMsBnDEAANcBAAAA AP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAA vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAA4BwAAFgsAACgSAAAW CwAADwAE8M4AAABCAQrwCAAAANXxAwACCgAAEwEL8GYAAACBAGA1AQCCALCaAACDAGA1AQCEALCa AACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8F BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAOAcAALULAAAoEgAAtQsAAA8ABPDOAAAAQgEK 8AgAAACK8gMAAgoAABMBC/BmAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAA vwACAA8AvwEAABAAwAEzMzMAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYA TgB/BgYADgAAAA/wEAAAAPwDAABBCAAA/AMAANIIAAAPAATwzgAAAEIBCvAIAAAAlfIDAAIKAAAT AQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMAB MzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEw AAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAA AAA4BwAA0ggAACgSAADSCAAADwAE8MgAAABCAQrwCAAAAJbyAwACCgAAAwEL8GAAAACBAGA1AQCC ALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwxAAD/AQwA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA/AMAANIIAAD8AwAARgwAAA8A BPDIAAAAQgEK8AgAAACY8gMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQAC AAAAhwABAAAAvwACAA8AvwEAABAAwAEBAAAIywGcMQAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/ BgYATgB/BgYADgAAAA/wEAAAADgHAADSCAAAOAcAAEYMAAAPAATwzgAAAEIBCvAIAAAAqPIDAAIK AAATAQvwZgAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQ AMABMzMzAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMA IvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP 8BAAAAA4BwAARgwAACgSAABGDAAADwAE8M4AAABCAQrwCAAAAK7yAwACCgAAEwEL8GYAAACBAGA1 AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwxAADX AQAAAAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8B AACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAOAcAACgDAAAo EgAAKAMAAA8ABPDIAAAAQgEK8AgAAACv8gMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEA hACwmgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEzMzMAywGcMQAA/wEMAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAPwDAAAoAwAA/AMAAEEIAAAPAATwyAAAAEIBCvAI AAAAsPIDAAIKAAADAQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8A AgAPAL8BAAAQAMABAQAACMsBnDEAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A AAAP8BAAAAA4BwAAKAMAADgHAABBCAAADwAE8MgAAABCAQrwCAAAAM7yAwACCgAAAwEL8GAAAACB AGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwx AAD/AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACA AL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA/AMAAGwFAAA4BwAA bAUAAA8ABPDIAAAAQgEK8AgAAADR8gMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACw mgAAhQACAAAAhwABAAAAvwACAA8AvwEAABAAwAEzMzMAywGcMQAA/wEMAA4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAPwDAABBCAAAOAcAAEEIAAAPAATwyAAAAEIBCvAIAAAA 1PIDAAIKAAADAQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAP AL8BAAAQAMABMzMzAMsBnDEAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMA IvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP 8BAAAAD8AwAAhQoAADgHAACFCgAADwAE8MgAAABCAQrwCAAAAOXyAwACCgAAAwEL8GAAAACBAGA1 AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADAATMzMwDLAZwxAAD/ AQwADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAOAcAALAHAAAoEgAAsAcA AA8ABPACAQAAEgAK8AgAAADr8QMAAAoAADMBC/ByAAAAfwAAAAQAgADELDEPgQBgNQEAggCwmgAA gwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAA wAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAABoTAACAFhoTDwAN 8CIAAAAAAJ8PBAAAAAQAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEDwAE8EgAAAASAArwCAAAAAHo AwAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoT iQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oBkDd4gQAAACsE AAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAuRX/////EgAAAA8A PfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuAwIsAAACAO8DGAAAAAEAAAANDgAAAAAAAAcA AIAAAAAABwALMA8ADAQZKwAADwAC8BErAAAwCAjwCAAAACEAAAC89AMADwAD8KkqAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAPQDAAUAAAAPAATweAAAABIACvAIAAAA AvQDACACAABjAAvwJAAAAH8AAAAEAIAASFywD78BAAABAP8BAAABAAEDAgADAIgDAAAAAAAAEPAI AAAAdwCBAcEVlwIPABHwEAAAAAAAwwsIAAAAAAAAAA0AsA8PAA3wDAAAAAAAng8EAAAAAAAAAA8A BPD+AQAAEgAK8AgAAAAD9AMAAAoAACMBC/BsAAAAfwAAAAQAgADEKK8PgQBgNQEAggCwmgAAgwBg NQEAhACwmgAAhwABAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAI PwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/ BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAACkMkQJJFCkODwAN8CQBAAAAAJ8P BAAAAAQAAAAAAKgPugAAAE5vdGUgdGhhdCB0aGlzIHRhYmxlIGNhbiBiZSB1cGRhdGVkIGJhc2Vk IG9uIElUVS1UIGRlZmluaXRpb24gcmVsYXRlZCB0byBwaHlzaWNhbCBpbXBhaXJtZW50cy4gVGhl IFRMViBmb3JtYXQgZG8gbm90IG5lZWQgdG8gYmUgY2hhbmdlZCB3aGVuIHRoZSBwaHlzaWNhbCBp bXBhaXJtZW50cyBkZWZpbml0aW9uIHVwZGF0ZWQuIAAAoQ86AAAAuwAAAAAAswAAAAMA2AAGAAAA AAFuAAAAAAAiAAgAEAAGAAAAAQAiAAEACAAQAEcAAAAAACIACAAQAAAAqg8MAAAAuwAAAAYAAAAJ BAQIDwAE8AIBAAASAArwCAAAAAT0AwAACgAAMwEL8HIAAAB/AAAABACAABTsrw+BAGA1AQCCALCa AACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/ AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8B AADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAxf0AAIAWxf0P AA3wIgAAAAAAnw8EAAAABAAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQPAATwAgEAABIACvAIAAAA UPQDAAAKAAAzAQvwcgAAAH8AAAAEAIAAvHftFYEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAA AIcAAQAAAL8AAgAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAaEwAAgBYaEw8ADfAiAAAAAACfDwQAAAAEAAAA AACqDw4AAAABAAAABwAAAAAABAgJBA8ABPACAQAAEgAK8AgAAABR9AMAAAoAADMBC/ByAAAAfwAA AAQAgACUh8oWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAvwACAA8AgQEEAAAI gwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAL4FAABkANYGDwAN8CIAAAAAAJ8PBAAAAAQAAAAAAKoPDgAAAAEAAAAHAAAAAAAE CAkEDwAD8MMjAAAPAATweAAAAAEACfAQAAAAGQMAAAIEAAApEgAAYwoAAAIACvAIAAAAvPQDAAEC AAATAAvwBgAAAH8AAAEAASMAIvEqAAAAnwMBAAAAoMMeAAAABgAIAAQAnwEAAPMAAAD0AAAA9AAA APMAAAD0AAAAAAAQ8AgAAAACBBkDKRJjCg8ABPDNAQAAEgAK8AgAAABy9AMAAgoAABMBC/BmAAAA fwAAAAQAgACsx5kWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJ AB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAA QAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAA AHAOAABvCQAAKRIAAGMKAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwIAAQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBf AFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3w WwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAcmVsYXRlZAAAoQ8kAAAACAAAAAAAAAgAAAEABwAAAAAA IwALAAgADAABAAAAAAQAAAAEAACqDwwAAAAIAAAABgAAAAkEBAgPAATw7AEAABIACvAIAAAAcfQD AAIKAAATAQvwZgAAAH8AAAAEAIAA+O2ZFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEB BAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A fwYGAA4AAAAP8BAAAAADBwAAbwkAAHAOAABjCgAADwAR8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6 DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAAAAAAAAMCAAEAAAAAAA8AihNCAAAA AAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAA AAAAAAAAAAAADwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKgPKAAAADE2NSA9IGNlbnRlciB3YXZlbGVu Z3RoIGZvciBlYWNoIGNoYW5uZWwAAKEPIgAAACkAAAAAAAAAAAAoAAAAAAAjAAsACAAMAAEAAAAA BAAAAAQAAKoPDAAAACkAAAAGAAAACQQECA8ABPDNAQAAEgAK8AgAAABv9AMAAgoAABMBC/BmAAAA fwAAAAQAgAB81JwWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJ AB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAA QAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAA AHAOAAB8CAAAKRIAAG8JAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwIAAQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBf AFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3w WwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAcmVsYXRlZAAAoQ8kAAAACAAAAAAAAAgAAAEABwAAAAAA IwALAAgADAABAAAAAAQAAAAEAACqDwwAAAAIAAAABgAAAAkEBAgPAATw2AEAABIACvAIAAAAbvQD AAIKAAATAQvwZgAAAH8AAAAEAIAAeK+cFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEB BAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A fwYGAA4AAAAP8BAAAAADBwAAfAgAAHAOAABvCQAADwAR8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6 DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEPDAAAAAAAAAMCAAEAAAAAAA8AihNCAAAA AAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACsDxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAA AAAAAAAAAAAADwAN8GYAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAADE2NCA9IDMtZEIgYmFuZHdpZHRo AAChDyIAAAAVAAAAAAAAAAAAFAAAAAAAIwALAAgADAABAAAAAAQAAAAEAACqDwwAAAAVAAAABgAA AAkEBAgPAATwzwEAABIACvAIAAAAbPQDAAIKAAATAQvwZgAAAH8AAAAEAIAAxOScFoEAYDUBAIIA sJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BBgAOAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAABwDgAAiAcAACkSAAB8CAAADwAR 8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExQAAAAAALEP DAAAAAAAAAMCAAEAAAAAAA8AihNCAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMkAAAAAACs DxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN8F0AAAAAAJ8PBAAAAAQAAAAAAKgP CQAAAHVucmVsYXRlZAAAoQ8kAAAACgAAAAAAAAgAAAEACQAAAAAAIwALAAgADAABAAAAAAQAAAAE AACqDwwAAAAKAAAABgAAAAkEBAgPAATw6wEAABIACvAIAAAAa/QDAAIKAAATAQvwZgAAAH8AAAAE AIAA+F2cFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BCQAfAMAB AQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEA ACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAADBwAA iAcAAHAOAAB8CAAADwAR8I4AAAAPAIgThgAAAA8AihM0AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLExQAAAAAALEPDAAAAAAAAAMCAAEAAAAAAA8AihNCAAAAAAC6Dw4AAABfAF8AXwBQAFAA VAA5AAAAixMkAAAAAACsDxwAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN8HkAAAAA AJ8PBAAAAAQAAAAAAKgPJwAAADE2MyA9IE5vaXNlIGVxdWl2YWxlbnQgYmFuZHdpZHRoIGZhY3Rv cgAAoQ8iAAAAKAAAAAAAAAAAACcAAAAAACMACwAIAAwAAQAAAAAEAAAABAAAqg8MAAAAKAAAAAYA AAAJBAQIDwAE8M8BAAASAArwCAAAAGn0AwACCgAAEwEL8GYAAAB/AAAABACAAJSAnBaBAGA1AQCC ALCaAACDAGA1AQCEALCaAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIA AAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAcA4AAJQGAAApEgAAiAcAAA8A EfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMUAAAAAACx DwwAAAAAAAADAgABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTJAAAAAAA rA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfBdAAAAAACfDwQAAAAEAAAAAACo DwkAAAB1bnJlbGF0ZWQAAKEPJAAAAAoAAAAAAAAIAAABAAkAAAAAACMACwAIAAwAAQAAAAAEAAAA BAAAqg8MAAAACgAAAAYAAAAJBAQIDwAE8NwBAAASAArwCAAAAGj0AwACCgAAEwEL8GYAAAB/AAAA BACAAJBvnBaBAGA1AQCCALCaAACDAGA1AQCEALCaAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDA AQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8B AAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAAwcA AJQGAABwDgAAiAcAAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQA MQAwAAAAixMUAAAAAACxDwwAAAAAAAADAgABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQ AFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfBqAAAA AACfDwQAAAAEAAAAAACoDxgAAAAxNjIgPSBpbm5lciBmaWx0ZXIgb3JkZXIAAKEPIgAAABkAAAAA AAAAAAAYAAAAAAAjAAsACAAMAAEAAAAABAAAAAQAAKoPDAAAABkAAAAGAAAACQQECA8ABPDPAQAA EgAK8AgAAABm9AMAAgoAABMBC/BmAAAAfwAAAAQAgADokZwWgQBgNQEAggCwmgAAgwBgNQEAhACw mgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAHAOAAChBQAAKRIAAJQGAAAPABHwjgAAAA8AiBOGAAAA DwCKEzQAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwIAAQAA AAAADwCKE0IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAA AAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3wXQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAdW5yZWxhdGVk AAChDyQAAAAKAAAAAAAACAAAAQAJAAAAAAAjAAsACAAMAAEAAAAABAAAAAQAAKoPDAAAAAoAAAAG AAAACQQECA8ABPDbAQAAEgAK8AgAAABl9AMAAgoAABMBC/BmAAAAfwAAAAQAgACUC5wWgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCC AIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAAAMHAAChBQAAcA4AAJQGAAAP ABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAA sQ8MAAAAAAAAAwIAAQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAA AKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3waQAAAAAAnw8EAAAABAAAAAAA qA8XAAAAMTYxID0gaW5uZXIgZmlsdGVyIHR5cGUAAKEPIgAAABgAAAAAAAAAAAAXAAAAAAAjAAsA CAAMAAEAAAAABAAAAAQAAKoPDAAAABgAAAAGAAAACQQECA8ABPDdAQAAEgAK8AgAAABk9AMAAgoA ACMBC/BsAAAAfwAAAAQAgABYzZwWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8A gQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMA AA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYA TgB/BgYADgAAAA/wEAAAABkDAAChBQAAAwcAAGMKAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAA ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTFAAAAAAAsQ8MAAAAAAAAAwIAAQAAAAAADwCKE0IA AAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAAAAAAPAA3wZQAAAAAAnw8EAAAABAAAAAAAqA8RAAAAOCA9IFBoeXNpY2FsIG5vZGUA AKEPJAAAABIAAAAAAAAIAAABABEAAAAAACMACwAIAAwAAQAAAAAEAAAABAAAqg8MAAAAEgAAAAYA AAAJBAQIDwAE8OEBAAASAArwCAAAAGP0AwACCgAAIwEL8GwAAAB/AAAABACAAECFnBaBAGA1AQCC ALCaAACDAGA1AQCEALCaAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADA AL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAcA4AAAIEAAApEgAA oQUAAA8AEfCOAAAADwCIE4YAAAAPAIoTNAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMU AAAAAACxDwwAAAAAAAADAgABAAAAAAAPAIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsT JAAAAAAArA8cAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfBpAAAAAACfDwQAAAAE AAAAAACoDxMAAABXYXZlbGVuZ3RoIHJlbGF0ZWQ/AAChDyYAAAAUAAAAAAAACAAAAQATAAAAAQAj AAEACwAIAAwAAQAAAAAEAAAABAAAqg8MAAAAFAAAAAYAAAAJBAQIDwAE8NwBAAASAArwCAAAAGL0 AwACCgAAIwEL8GwAAAB/AAAABACAADg/nBaBAGA1AQCCALCaAACDAGA1AQCEALCaAACHAAEAAAC/ AAAADwCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBO AD8GBgBOAH8GBgAOAAAAD/AQAAAAAwcAAAIEAABwDgAAoQUAAA8AEfCOAAAADwCIE4YAAAAPAIoT NAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMUAAAAAACxDwwAAAAAAAADAgABAAAAAAAP AIoTQgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTJAAAAAAArA8cAAAAAAAAAAAAEAAAAAAA AAAAAAAAAAAAAAAAAAAAAA8ADfBkAAAAAACfDwQAAAAEAAAAAACoDw4AAABQYXJhbWV0ZXIgVHlw ZQAAoQ8mAAAADwAAAAAAAAgAAAEADgAAAAEAIwABAAsACAAMAAEAAAAABAAAAAQAAKoPDAAAAA8A AAAGAAAACQQECA8ABPDcAQAAEgAK8AgAAABh9AMAAgoAACMBC/BsAAAAfwAAAAQAgAAEMZwWgQBg NQEAggCwmgAAgwBgNQEAhACwmgAAhwABAAAAvwAAAA8AgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/ AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAABkDAAACBAAA AwcAAKEFAAAPABHwjgAAAA8AiBOGAAAADwCKEzQAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA AIsTFAAAAAAAsQ8MAAAAAAAAAwIAAQAAAAAADwCKE0IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkA AACLEyQAAAAAAKwPHAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3wZAAAAAAAnw8E AAAABAAAAAAAqA8OAAAAQ29tcG9uZW50IHR5cGUAAKEPJgAAAA8AAAAAAAAIAAABAA4AAAABACMA AQALAAgADAABAAAAAAQAAAAEAACqDwwAAAAPAAAABgAAAAkEBAgPAATwyAAAAEIBCvAIAAAAc/QD AAIKAAADAQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8B AAAQAMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEw AAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAA AAAZAwAAAgQAACkSAAACBAAADwAE8MgAAABCAQrwCAAAAHT0AwACCgAAAwEL8GAAAACBAGA1AQCC ALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAGQMAAGMKAAApEgAAYwoAAA8A BPDIAAAAQgEK8AgAAAB19AMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQAC AAAAhwABAAAAvwACAA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/ BgYATgB/BgYADgAAAA/wEAAAABkDAAACBAAAGQMAAGMKAAAPAATwyAAAAEIBCvAIAAAAdvQDAAIK AAADAQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQ AMsBnDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAA fwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAAp EgAAAgQAACkSAABjCgAADwAE8MgAAABCAQrwCAAAAHn0AwACCgAAAwEL8GAAAACBAGA1AQCCALCa AACDAGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8F BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAGQMAAKEFAAApEgAAoQUAAA8ABPDI AAAAQgEK8AgAAAB79AMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAA hwABAAAAvwACAA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYA TgB/BgYADgAAAA/wEAAAAAMHAAACBAAAAwcAAGMKAAAPAATwyAAAAEIBCvAIAAAAfvQDAAIKAAAD AQvwYAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsB nDEAANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEA AEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAABwDgAA AgQAAHAOAABjCgAADwAE8MgAAABCAQrwCAAAAI70AwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACD AGA1AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIA AAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAAwcAAJQGAAApEgAAlAYAAA8ABPDIAAAA QgEK8AgAAACY9AMAAgoAAAMBC/BgAAAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwAB AAAAvwACAA8AvwEAABAAywGcMQAA1wEAAAAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAAA/wEAAAAAMHAACIBwAAKRIAAIgHAAAPAATwyAAAAEIBCvAIAAAAofQDAAIKAAADAQvw YAAAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAL8AAgAPAL8BAAAQAMsBnDEA ANcBAAAAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA /wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAAADBwAAfAgA ACkSAAB8CAAADwAE8MgAAABCAQrwCAAAAKr0AwACCgAAAwEL8GAAAACBAGA1AQCCALCaAACDAGA1 AQCEALCaAACFAAIAAACHAAEAAAC/AAIADwC/AQAAEADLAZwxAADXAQAAAAD/AQwADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8F BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAAAwcAAG8JAAApEgAAbwkAAA8ABPACAQAAEgAK 8AgAAAC79AMAAAoAADMBC/ByAAAAfwAAAAQAgAAQr5kWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAA hQACAAAAhwABAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/BQYA TgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAAkKAABkACELDwAN8CIAAAAAAJ8PBAAA AAQAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEDwAE8EgAAAASAArwCAAAAAH0AwAADAAAgwAL8DAA AACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAA AP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oBkDd4gQAAACsEAAAAAAAAAB8ARPE9 AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAuRX/////EgAAAA8APfENAAAAQAFC8QUA AAABCQAAAA8AAisAAAAADwDuA0wgAAACAO8DGAAAAAEAAAANDgAAAAAAAAcAAIAAAAAABwALMA8A DARjHwAADwAC8FsfAABwCAjwCAAAABcAAAAZBAQAEAAY8QQAAAABAAAADwAD8OceAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQEAAUAAAAPAATwcgAAABIACvAIAAAA AgQEACACAABTAAvwHgAAAH8AAAAEAIAAAHiwD78BAAABAP8BAAABAAEDAgADAAAAEPAIAAAArQAg AWAVagIPABHwEAAAAAAAwwsIAAAAAAAAAA0AsA8PAA3wDAAAAAAAng8EAAAAAAAAAA8ABPA+AQAA EgAK8AgAAAAFBAQAAAoAAAMBC/B4AAAAgABkEa8PgQDATgAAggDATgAAgwDATgAAhADATgAAvwAE AAQAgQHM/8wAgwEzADMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMYAAAA iAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAxAAAAAAAQ8AgAAABpApECDBPhDw8ADfCWAAAAAACf DwQAAAAEAAAAAACoDzIAAABDb21wb25lbnQgSW1wYWlybWVudCBzdWItVExWICg9MSwgZmliZXIg Y29tcG9uZW50KQAAoQ8mAAAAMwAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAzAAAAAAAiAAgACgAA AKoPDAAAADMAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8C4BAAASAArwCAAAAAYEBAAACgAA AwEL8HgAAACAAIgDpRaBAMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQABACBAf/MAACDAQAz/wC/ ARAAEADAARoaGgDCAeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxgAAACIAwEAAABSAGUAYwB0AGEA bgBnAGwAZQAgADIAAAAAABDwCAAAAPICbQNKEnoDDwAN8IYAAAAAAJ8PBAAAAAQAAAAAAKgPIgAA AENvbXBvbmVudCBJRCBzdWItc3ViLVRMViAoSUQgPSB4eCkAAKEPJgAAACMAAAAAALIoCgACAPwA BgAAAAABAQAyAAcAIwAAAAAAIgAIAAoAAACqDwwAAAAjAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5 AQ8ABPBFAQAAEgAK8AgAAAAHBAQAAAoAAAMBC/B4AAAAgAAYTqUWgQDATgAAggDATgAAgwDATgAA hADATgAAvwAEAAQAgQH//5kAgwEAAGYAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIA AAIAgMMYAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgAAACRA2YDQxKaBQ8A DfCdAAAAAACfDwQAAAAEAAAAAACoDysAAABXYXZlbGVuZ3RoX2lycmVsYXRlZCBJbXBhaXJtZW50 IHN1Yi1zdWItVExWAAChDyYAAAAsAAAAAACyKAoAAgD8AAYAAAAAAQEAMgAHACwAAAAAACIACAAK AAAAqg8aAAAAFAAAAAcAAAADAAkEBAgYAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPBsAQAA EgAK8AgAAAAIBAQAAAoAAAMBC/B4AAAAgACgU6UWgQDATgAAggDATgAAgwDATgAAhADATgAAvwAE AAQAgQH/mcwAgwEAZjMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEIAAgAPwIAAAIAgMMYAAAA iAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAA1AAAAAAAQ8AgAAAAwBEsESRG3BA8ADfDEAAAAAACf DwQAAAAEAAAAAACoD0YAAABQYXJhbWV0ZXIgc3ViLXN1Yi1zdWItVExWICAgICAgICBbKFR5cGU9 MjEoZmliZXIgdHlwZSksIHZlbHVlPTEoU1NNRildAAChDyYAAABHAAAAAACyKAoAAgD8AAYAAAAA AQEAMgAHAEcAAAAAACIACAAKAAAAqg8mAAAAOAAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgKAAAA BgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPDFAQAAEgAK8AgAAAAJBAQAAAoAAEMBC/CSAAAAgACk X6UWgQDATgAAggDATgAAgwDATgAAhADATgAAvwAEAA8APwEAAAYAgQH/mcwAgwEAZjMAvwEcAB4A wAEaGhoAwgHl5eUAywGQJAAA/wEOAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgMMaAAAAiAMB AAAAUgBlAGMAdABhAG4AZwBsAGUAIAAxADIAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA1ARDBEcRWwUPAA3wxQAA AAAAnw8EAAAABAAAAAAAqA9HAAAAUGFyYW1ldGVyIHN1Yi1zdWItc3ViLVRMViAgICAgICAgICBb IFR5cGU9MjIoZmliZXIgbGVuZ3RoKSwgdmVsdWU9MTBLTV0AAKEPJgAAAEgAAAAAALIoCgACAPwA BgAAAAABAQAyAAcASAAAAAAAIgAIAAoAAACqDyYAAAA8AAAABgAAAAkEBAgFAAAABwAAAAMACQQE CAcAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8EUBAAASAArwCAAAAAoEBAAACgAAAwEL8HoA AACAAOhRpRaBAMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQABACBAf//mQCDAQAAZgC/ARAAEADA ARoaGgDCAeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwA ZQAgADEAMwAAAAAAEPAIAAAAxwVtA0oSFQgPAA3wmwAAAAAAnw8EAAAABAAAAAAAqA8pAAAAV2F2 ZWxlbmd0aF9yZWxhdGVkIEltcGFpcm1lbnQgc3ViLXN1Yi1UTFYAAKEPJgAAACoAAAAAALIoCgAC APwABgAAAAABAQAyAAcAKgAAAAAAIgAIAAoAAACqDxoAAAASAAAABwAAAAMACQQECBgAAAAGAAAA CQQECAAApg8GAAAAAQAAAPkBDwAE8DIBAAASAArwCAAAAAsEBAAACgAAAwEL8HoAAACAADTipRaB AMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQABACBAf/MmQCDAQAzZgC/ARAAEADAARoaGgDCAeXl 5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwAZQAgADEANAAA AAAAEPAIAAAATwY5BEQRwAYPAA3wiAAAAAAAnw8EAAAABAAAAAAAoA8kAAAAVwBhAHYAZQBsAGUA bgBnAHQAaAAgACMAMQAgACgAuwMxACkAAAChDyYAAAATAAAAAACyKAoAAgD8AAYAAAAAAQEAMgAH ABMAAAAAACIACAAKAAAAqg8MAAAAEwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwvAEAABIA CvAIAAAADAQEAAAKAABDAQvwkgAAAIAAHMylFoEAwE4AAIIAwE4AAIMAwE4AAIQAwE4AAL8ABAAP AD8BAAAGAIEB/5nMAIMBAGYzAL8BHAAeAMABGhoaAMIB5eXlAMsBkCQAAP8BDgAOAD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAIDDGgAAAIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMQA1AAAAkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAANcGPARCEU0HDwAN8LwAAAAAAJ8PBAAAAAQAAAAAAKgPPgAAAFBhcmFtZXRlciBz dWItc3ViLXN1Yi1UTFYgICAgICAgICAgIFtUeXBlPTIzKEQpLCB2ZWx1ZT0xLjdlLTVdAAChDyYA AAA/AAAAAACyKAoAAgD8AAYAAAAAAQEAMgAHAD8AAAAAACIACAAKAAAAqg8mAAAAMQAAAAYAAAAJ BAQIBQAAAAcAAAADAAkEBAgJAAAABgAAAAkEBAgAAKYPBgAAAAEAAAD5AQ8ABPC7AQAAEgAK8AgA AAANBAQAAAoAAEMBC/CSAAAAgAC8i6UWgQDATgAAggDATgAAgwDATgAAhADATgAAvwAEAA8APwEA AAYAgQH/mcwAgwEAZjMAvwEcAB4AwAEaGhoAwgHl5eUAywGQJAAA/wEOAA4APwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAxADYAAACTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAYAc7BDkR6AcPAA3wuwAAAAAAnw8EAAAABAAAAAAAqA89AAAAUGFyYW1ldGVyIHN1Yi1z dWItc3ViLVRMViAgICAgICAgICAgW1R5cGU9MjQoZEQpLCB2ZWx1ZT01Ni43XQAAoQ8mAAAAPgAA AAAAsigKAAIA/AAGAAAAAAEBADIABwA+AAAAAAAiAAgACgAAAKoPJgAAADIAAAAGAAAACQQECAUA AAAHAAAAAwAJBAQIBwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwRQEAABIACvAIAAAADgQE AAAKAAADAQvwegAAAIAAFDqlFoEAwE4AAIIAwE4AAIMAwE4AAIQAwE4AAL8ABAAEAIEB//+ZAIMB AABmAL8BEAAQAMABGhoaAMIB5eXlAMsBkCQAAP8BCAAIAD8CAAACAIDDGgAAAIgDAQAAAFIAZQBj AHQAYQBuAGcAbABlACAAMQA3AAAAAAAQ8AgAAABCCHcDWRKPCg8ADfCbAAAAAACfDwQAAAAEAAAA AACoDykAAABXYXZlbGVuZ3RoX3JlbGF0ZWQgSW1wYWlybWVudCBzdWItc3ViLVRMVgAAoQ8mAAAA KgAAAAAAsigKAAIA/AAGAAAAAAEBADIABwAqAAAAAAAiAAgACgAAAKoPGgAAABIAAAAHAAAAAwAJ BAQIGAAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwiAEAABIACvAIAAAADwQEAAAKAABDAQvw kgAAAIAADJilFoEAwE4AAIIAwE4AAIMAwE4AAIQAwE4AAL8ABAAPAD8BAAAGAIEB/5nMAIMBAGYz AL8BHAAeAMABGhoaAMIB5eXlAMsBkCQAAP8BDgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIDD GgAAAIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMQA4AAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/ AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAMoIQwRHES0J DwAN8IgAAAAAAJ8PBAAAAAQAAAAAAKAPJAAAAFcAYQB2AGUAbABlAG4AZwB0AGgAIAAjADIAIAAo ALsDMgApAAAAoQ8mAAAAEwAAAAAAsigKAAIA/AAGAAAAAAEBADIABwATAAAAAAAiAAgACgAAAKoP DAAAABMAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8LwBAAASAArwCAAAABAEBAAACgAAQwEL 8JIAAACAAJC/pRaBAMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQADwA/AQAABgCBAf+ZzACDAQBm MwC/ARwAHgDAARoaGgDCAeXl5QDLAZAkAAD/AQ4ADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCA wxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwAZQAgADEAOQAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA /wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABACUoESBHI CQ8ADfC8AAAAAACfDwQAAAAEAAAAAACoDz4AAABQYXJhbWV0ZXIgc3ViLXN1Yi1zdWItVExWICAg ICAgICAgICBbVHlwZT0yMyhEKSwgdmVsdWU9MS44ZS01XQAAoQ8mAAAAPwAAAAAAsigKAAIA/AAG AAAAAAEBADIABwA/AAAAAAAiAAgACgAAAKoPJgAAADEAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQI CQAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwuwEAABIACvAIAAAAEQQEAAAKAABDAQvwkgAA AIAAhBSlFoEAwE4AAIIAwE4AAIMAwE4AAIQAwE4AAL8ABAAPAD8BAAAGAIEB/5nMAIMBAGYzAL8B HAAeAMABGhoaAMIB5eXlAMsBkCQAAP8BDgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIDDGgAA AIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMgAwAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAA wAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAANoJQgRGEVAKDwAN 8LsAAAAAAJ8PBAAAAAQAAAAAAKgPPQAAAFBhcmFtZXRlciBzdWItc3ViLXN1Yi1UTFYgICAgICAg ICAgWyBUeXBlPTI0KGREKSwgdmVsdWU9NTcuN10AAKEPJgAAAD4AAAAAALIoCgACAPwABgAAAAAB AQAyAAcAPgAAAAAAIgAIAAoAAACqDyYAAAAyAAAABgAAAAkEBAgFAAAABwAAAAMACQQECAcAAAAG AAAACQQECAAApg8GAAAAAQAAAPkBDwAE8EUBAAASAArwCAAAABIEBAAACgAAAwEL8HoAAACAAGBX pRaBAMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQABACBAf//mQCDAQAAZgC/ARAAEADAARoaGgDC AeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwAZQAgADIA MQAAAAAAEPAIAAAAvQp0A1YSCw0PAA3wmwAAAAAAnw8EAAAABAAAAAAAqA8pAAAAV2F2ZWxlbmd0 aF9yZWxhdGVkIEltcGFpcm1lbnQgc3ViLXN1Yi1UTFYAAKEPJgAAACoAAAAAALIoCgACAPwABgAA AAABAQAyAAcAKgAAAAAAIgAIAAoAAACqDxoAAAASAAAABwAAAAMACQQECBgAAAAGAAAACQQECAAA pg8GAAAAAQAAAPkBDwAE8DIBAAASAArwCAAAABMEBAAACgAAAwEL8HoAAACAANiNpRaBAMBOAACC AMBOAACDAMBOAACEAMBOAAC/AAQABACBAf/MmQCDAQAzZgC/ARAAEADAARoaGgDCAeXl5QDLAZAk AAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwAZQAgADIAMgAAAAAAEPAI AAAARQs8BFURoAsPAA3wiAAAAAAAnw8EAAAABAAAAAAAoA8kAAAAVwBhAHYAZQBsAGUAbgBnAHQA aAAgACMAMwAgACgAuwMzACkAAAChDyYAAAATAAAAAACyKAoAAgD8AAYAAAAAAQEAMgAHABMAAAAA ACIACAAKAAAAqg8MAAAAEwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwZQEAABIACvAIAAAA FAQEAAAKAAADAQvwegAAAIAA5AOlFoEAwE4AAIIAwE4AAIMAwE4AAIQAwE4AAL8ABAAEAIEB/5nM AIMBAGYzAL8BEAAQAMABGhoaAMIB5eXlAMsBkCQAAP8BCAAIAD8CAAACAIDDGgAAAIgDAQAAAFIA ZQBjAHQAYQBuAGcAbABlACAAMgAzAAAAAAAQ8AgAAADNC0oESBFADA8ADfC7AAAAAACfDwQAAAAE AAAAAACoDz0AAABQYXJhbWV0ZXIgc3ViLXN1Yi1zdWItVExWICAgICAgICAgIFtUeXBlPTIzKEQp LCB2ZWx1ZT0xLjllLTVdAAChDyYAAAA+AAAAAACyKAoAAgD8AAYAAAAAAQEAMgAHAD4AAAAAACIA CAAKAAAAqg8mAAAAMAAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgJAAAABgAAAAkEBAgAAKYPBgAA AAEAAAD5AQ8ABPBlAQAAEgAK8AgAAAAVBAQAAAoAAAMBC/B6AAAAgABIC6UWgQDATgAAggDATgAA gwDATgAAhADATgAAvwAEAAQAgQH/mcwAgwEAZjMAvwEQABAAwAEaGhoAwgHl5eUAywGQJAAA/wEI AAgAPwIAAAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADQAAAAAABDwCAAAAFUM VARYEcoMDwAN8LsAAAAAAJ8PBAAAAAQAAAAAAKgPPQAAAFBhcmFtZXRlciBzdWItc3ViLXN1Yi1U TFYgICAgICAgICAgIFtUeXBlPTI0KGREKSwgdmVsdWU9NTguN10AAKEPJgAAAD4AAAAAALIoCgAC APwABgAAAAABAQAyAAcAPgAAAAAAIgAIAAoAAACqDyYAAAAyAAAABgAAAAkEBAgFAAAABwAAAAMA CQQECAcAAAAGAAAACQQECAAApg8GAAAAAQAAAPkBDwAE8EUBAAASAArwCAAAABYEBAAACgAAAwEL 8HoAAACAAIQapRaBAMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQABACBAf//mQCDAQAAZgC/ARAA EADAARoaGgDCAeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBn AGwAZQAgADIANQAAAAAAEPAIAAAAOA1+A1sShg8PAA3wmwAAAAAAnw8EAAAABAAAAAAAqA8pAAAA V2F2ZWxlbmd0aF9yZWxhdGVkIEltcGFpcm1lbnQgc3ViLXN1Yi1UTFYAAKEPJgAAACoAAAAAALIo CgACAPwABgAAAAABAQAyAAcAKgAAAAAAIgAIAAoAAACqDxoAAAASAAAABwAAAAMACQQECBgAAAAG AAAACQQECAAApg8GAAAAAQAAAPkBDwAE8DIBAAASAArwCAAAABcEBAAACgAAAwEL8HoAAACAAPgC ohaBAMBOAACCAMBOAACDAMBOAACEAMBOAAC/AAQABACBAf/MmQCDAQAzZgC/ARAAEADAARoaGgDC AeXl5QDLAZAkAAD/AQgACAA/AgAAAgCAwxoAAACIAwEAAABSAGUAYwB0AGEAbgBnAGwAZQAgADIA NgAAAAAAEPAIAAAAZQ1KBGERyA0PAA3wiAAAAAAAnw8EAAAABAAAAAAAoA8kAAAAVwBhAHYAZQBs AGUAbgBnAHQAaAAgACMANAAgACgAuwM0ACkAAAChDyYAAAATAAAAAACyKAoAAgD8AAYAAAAAAQEA MgAHABMAAAAAACIACAAKAAAAqg8MAAAAEwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwZQEA ABIACvAIAAAAGAQEAAAKAAADAQvwegAAAIAAMHWiFoEAwE4AAIIAwE4AAIMAwE4AAIQAwE4AAL8A BAAEAIEB/5nMAIMBAGYzAL8BEAAQAMABGhoaAMIB5eXlAMsBkCQAAP8BCAAIAD8CAAACAIDDGgAA AIgDAQAAAFIAZQBjAHQAYQBuAGcAbABlACAAMgA3AAAAAAAQ8AgAAADkDVAEThFYDg8ADfC7AAAA AACfDwQAAAAEAAAAAACoDz0AAABQYXJhbWV0ZXIgc3ViLXN1Yi1zdWItVExWICAgICAgICAgIFtU eXBlPTIzKEQpLCB2ZWx1ZT0yLjBlLTVdAAChDyYAAAA+AAAAAACyKAoAAgD8AAYAAAAAAQEAMgAH AD4AAAAAACIACAAKAAAAqg8mAAAAMAAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgJAAAABgAAAAkE BAgAAKYPBgAAAAEAAAD5AQ8ABPBkAQAAEgAK8AgAAAAZBAQAAAoAAAMBC/B6AAAAgAAMMaIWgQDA TgAAggDATgAAgwDATgAAhADATgAAvwAEAAQAgQH/mcwAgwEAZjMAvwEQABAAwAEaGhoAwgHl5eUA ywGQJAAA/wEIAAgAPwIAAAIAgMMaAAAAiAMBAAAAUgBlAGMAdABhAG4AZwBsAGUAIAAyADgAAAAA ABDwCAAAAHUOVwRbEf0ODwAN8LoAAAAAAJ8PBAAAAAQAAAAAAKgPPAAAAFBhcmFtZXRlciBzdWIt c3ViLXN1Yi1UTFYgICAgICAgICAgW1R5cGU9MjQoZEQpLCB2ZWx1ZT01OS43XQAAoQ8mAAAAPQAA AAAAsigKAAIA/AAGAAAAAAEBADIABwA9AAAAAAAiAAgACgAAAKoPJgAAADEAAAAGAAAACQQECAUA AAAHAAAAAwAJBAQIBwAAAAYAAAAJBAQIAACmDwYAAAABAAAA+QEPAATwSAAAABIACvAIAAAAAQQE AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJ AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAANcnywGQiv0gAAAAKwQA AAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAC5Ff////8SAAAADwA9 8Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAABwAA gAgBAAAHAAswDwAMBJQBAAAPAALwjAEAACAGCPAIAAAAAwAAAAMkAwAPAAPwJAEAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAJAMABQAAAA8ABPByAAAAEgAK8AgAAAAC JAMAIAIAAFMAC/AeAAAAfwAAAAQAgAA4xoYWvwEAAAEA/wEAAAEAAQMCAAMAAAAQ8AgAAACtACAB YBU8Ag8AEfAQAAAAAADDCwgAAAAAAAAADQCGFg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAAS AArwCAAAAAMkAwAgAgAAUwAL8B4AAAB/AAAABACAAJTGhha/AQAAAQD/AQAAAQABAwMAAwAAABDw CAAAANUDMAKHFZYMDwAR8BAAAAAAAMMLCAAAAAEAAAAOAIYWDwAN8AwAAAAAAJ4PBAAAAAEAAAAP AATwSAAAABIACvAIAAAAASQDAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu CAAAAF0EygFwflLhAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAAC5Ff////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAPAD/gEAAAEA8QMI AAAAAAEAAAcACzAPAAwEfgEAAA8AAvB2AQAAwAAI8AgAAAADAAAAAxAAAA8AA/AOAQAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAQAAAFAAAADwAE8FgAAAASAArwCAAA AAIQAAAgAgAAQwAL8BgAAAAEAAAAAAC/AQEAAQD/AQEAAQABAwQMAAAAABDwCAAAALAB0AIQDiAK DwAR8BAAAAAAAMMLCAAAAAAAAAALADcWDwAE8HYAAAASAArwCAAAAAMQAAAgAgAAIwAL8AwAAACA ABw+NxYBAwUMAAAAABDwCAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAEAAAAMADcWDwAN8CIA AAAAAJ8PBAAAAAIAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEDwAE8EgAAAASAArwCAAAAAEQAAAA DAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkAAAA/AwEA AQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAA AAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACwpnIAgCSqcw8A8AMQAgAA AQDxAwgAAAAIAQAABwALMA8ADASQAQAADwAC8IgBAACwBgjwCAAAAAMAAAADSAMADwAD8CABAAAP AATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAEgDAAUAAAAPAATwWAAAABIA CvAIAAAAAkgDACACAABDAAvwGAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBAwAAAAAEPAIAAAAsAHQ AhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsAjBMPAATwiAAAABIACvAIAAAAA0gDACACAABTAAvw HgAAAH8AAAAEAIAAfDWwD78BAQABAP8BAQABAAEDBQwAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAA AAAAwwsIAAAAAQAAAAwAsA8PAA3wIgAAAAAAnw8EAAAAAgAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQPAATwSAAAABIACvAIAAAAAUgDAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB3r1oAJQBjp+L AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA AOsuCAAAABkFygGw31cLAAByF4gAAAABABAAAAAAAAMAEAAwpgAABQAgAGSbAAAe6gEAHwAQAJEu AAAmABAA5GkAADEAEADZhQAAMwAQAAN4AAA8ABAAFJIAAEQAIACZ5wEAlKEAAE0AEAAk7AEAUwAQ AP+8AABWACAAtMMAADkMAQBiAGAASgcBAGMnAQDwOwEAt0QBADubAQBFxwEAAAD1DxwAAAAZAQAA pBkAAwAAAAA87gEAAQAAAGcAAAAPAMUxDwDoA4kuAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAF AAAACgAAAAUAAABFAAAAAQAAAAAAAAEPAPIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5AD AAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMT AHg6CzDwgxMAAAAAAA8A1QcAAAYiEAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEA bgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUAdABp AGcAZQByAE4AZQD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQA AAAF1c3VnC4bEJOXCAArLPmusAQAAGwEAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAA ANAAAAAGAAAA2AAAAAcAAADgAAAACAAAAOgAAAAJAAAA8AAAAAoAAAD4AAAAFwAAAAABAAALAAAA CAEAABAAAAAQAQAAEwAAABgBAAAWAAAAIAEAAA0AAAAoAQAADAAAAA0EAAACAAAAqAMAAB4AAAAQ AAAA1NrGwcS7yc/P1Mq+AAAAAB4AAAAgAAAASHVhd2VpIFRlY2hub2xvZ2llcyBDby4sTHRkLgAA AAADAAAAx7YGAAMAAAClAAAAAwAAAAwAAAADAAAAAgAAAAMAAAAAAAAAAwAAAAAAAAADAAAAqBkL AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAABwAAAAGAAAAQXJpYWwACwAAAE1T IFBHb3RoaWMAFwAAAEZydXRpZ2VyTmV4dCBMVCBNZWRpdW0ABQAAALrazOUAGAAAAEZydXRpZ2Vy TmV4dCBMVCBSZWd1bGFyAAkAAAC7qs7Ez7i62gAKAAAAV2luZ2RpbmdzABYAAABGcnV0aWdlck5l eHQgTFQgTGlnaHQABQAAAMvOzOUAFQAAAEZydXRpZ2VyTmV4dCBMVCBCb2xkAAYAAABUaW1lcwAQ AAAAVGltZXMgTmV3IFJvbWFuAAgAAABkZWZhdWx0ABEAAAAyX9fUtqjS5cnovMa3vbC4ABEAAAAx X9fUtqjS5cnovMa3vbC4AA0AAADErMjPyei8xsSjsOUAegAAAE9TUEYgRXh0ZW5zaW9ucyBpbiBT dXBwb3J0IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25t ZW50IGluIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAEAAAAEFja25vd2xl ZGdtZW50cwALAAAAQmFja2dyb3VuZAALAAAAT2JqZWN0aXZlIAAmAAAAT1NQRiByb3V0aW5nIGZv ciBJQS1SV0EgLU5ldyBQTEkgVExWIAAhAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExpbmsgUExJIFRM ViAAIQAAAFRoZSBjb21wb3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAB8AAABTb21lIHN1Yi1UTFZz IGFuZCBzdWItc3ViLVRMVnMAJQAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsgUExJIFRM VgAlAAAAUGFyUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAA AAAAwElu+qwsywGmBAAAQBUAAAAAAABQAGkAYwB0AHUAcgBlAHMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf////8CAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQ3wYAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMA ZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAAD4AAAAAAAAABQBTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACgAAgEBAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 9A8AAAAAAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw8IMT AAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUA ZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVB4YABgJAALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBO AGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQiUAC3D0QA AABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMT AAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAB4AHQAIABMAFQAIABSAGUA ZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVBwIABgJwALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBO AGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAYigAC3D0QA AACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMT AAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABCAG8A bABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABBSgALcPRAAAAFQAaQBtAGUAcwAAAGUAcgBO AGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQksAC3D0QA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMT AAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAACAAAABQAAAClDxoAAAAAALOoLgADAPwABgAAAAAB AQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABk AAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAABQAA QAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEHhIAAA8AAPAWEgAAAAAG8CAIAAAE CAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAAPwAAAAsAAAAIAAAADAAAAAQAAAAAAAAAEAAAAAAA AAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAAAAAAAAAEAAAAAAAA AAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAh AAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAA AAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAGAAAA AAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYAAAAA AAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAQAAAA/AAAACQAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABPAAAADAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAE AAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAAYwAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAGsAAAAEAAAAAAAAACYAAAAAAAAAJQAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEAAAAIAAAAAAAAALUAAAAAAAAABgAAAHQAAAD7AQAA dQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAhAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA8gAAAAAAAADjAAAAAAAAAF0AAAAAAAAArAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAB8AAAABAAAAH0AAABBAAAAfgAAAHEBAAAAAAAA BgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAAAIEAAADqAgAAgwAAAL0AAAAAAAAABgAAAAAAAAAG AAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAAnwAB8IwBAABiAAfwJAAAAAYGBYs1H73H+Fqm86dQ G2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/AkAAAABQXY8+MEAuku2OPtcJjJPSIV/wBOtgAAAQAA ANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/AAZXAAABAAAAIeEAAAAAAABiAAfw JAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMAAAEAAAAnOAEAAAAAAGIAB/AkAAAABgY86hloAaVP VtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAAYgAH8CQAAAAGBrjpaHIX9gtc+PzUZOyCabb/ALxW BQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1c2pAoLp3dnMucUO2Ff8ASQIAAAEAAABf2AYAAAAA ADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk/wCdAgAAAQAAAKjaBgAAAAAAMgAH8CQAAAADBKqt uwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0GAAAAAAADCAvwAAMAAIEAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAPAAwB9AAAEA0BAAAAIA4BAAAAIIAB AAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAA AIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMB AAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAA QL8BDAAeAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgB AAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANcBAgAAAP8BDgAO AAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkC AAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAAD AIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8C AQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAA AMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANIC IE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAf AAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYD fL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAwZQEAfwEAAEAAngH/////nwH/////oAEAAAAgocEA AAAAogH/////owH/////pAEAAAAgpcEAAAAApgH/////pwH/////vwEAACAA2QH/////2gH///// 2wEAAAAg3MEAAAAA3QH/////3gH/////3wEAAAAg4MEAAAAA4QH/////4gH//////wEAAMAAEgL/ ////EwL/////FAIAAAAgFcIAAAAAFgL/////FwL/////GAIAAAAgGcIAAAAAGgL/////GwL///// iQL/////igL/////iwIAAAAgjMIAAAAAjQL/////jwMAAAAAkAMCAAAAkQMAAAAAkgMCAAAAvwMA ggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAgRAUAAAAARUUAAAAARsUAAAAARwUAAAAASAUAAAAA SQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUAAAAATgUAAAAAT8UAAAAAUAUAAAAAUQUAAAAAUgUB AAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAAWQX/////WgX/////WwUAAAAgXMUAAAAAXQX///// XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/////fwUGAE4AgAUAAAAAgQUAAAEAggX///8AgwUA AAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAAiAUAAAAAiQUAAAAAigUAAAAAiwU1JQAAjAUAAAgA jQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUAAAAAkgUBAAAAkwUBAAAAlAUBAAAAlQUBAAAAlwUC AAAAmQX/////mgX/////mwUAAAAgnMUAAAAAnQX/////ngX/////nwUAAAAgoMUAAAAAoQX///// ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX///8AwwUAAAAgxAUAAAAAxUUAAAAAxsUAAAAAxwUA AAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAAzAUAAAgAzQUAAAAAzgUAAAAAz8UAAAAA0AUAAAAA 0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUBAAAA1wUCAAAA2QX/////2gX/////2wUAAAAg3MUA AAAA3QX/////3gX/////3wUAAAAg4MUAAAAA4QX/////4gX//////wUGAE4AAAYAAAAAAQYAAAEA Agb///8AAwYAAAAgBAYAAAAABUYAAAAABsYAAAAABwYAAAAACAYAAAAACQYAAAAACgYAAAAACwY1 JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAAEAYAAAAAEQYAAAAAEgYBAAAAEwYBAAAAFAYBAAAA FQYBAAAAFwYCAAAAGQb/////Ggb/////GwYAAAAgHMYAAAAAHQb/////Hgb/////HwYAAAAgIMYA AAAAIQb/////Igb/////PwYGAE4AQAYAAAAAQQYAAAEAQgb///8AQwYAAAAgRAYAAAAARUYAAAAA RsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYAAAAASwY1JQAATAYAAAgATQYAAAAATgYAAAAAT8YA AAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAAVAYBAAAAVQYBAAAAVwYCAAAAWQb/////Wgb///// WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYAAAAgYMYAAAAAYQb/////Ygb/////fwYGAA4AgAAa 8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA/wAAmcwAAGaZAEAAHvEQAAAABAAACP+ZAAAAAAAA 9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAAJgAAAAQAAAAA AAAAAgAAgAAAAAAAAPMDFAAAADMAAAAEAAAAAAAAAAYAAIAAAAAAAADzAxQAAAAxAAAABAAAAAAA AAAEAACAAAAAAAAA8wMUAAAAPAAAAAAAAAAAAAAABwAAgAAAAAAPANAHPQwAAB8AFAQcAAAAAAAV BBQAAADQGM0EAMqaO0613DYAypo7AQIAAA8A+gN3AAAAAAD+AwMAAAABAQAAAP0DNAAAAEIAAABk AAAAQgAAAGQAAAAAAAAA/CWIFgiEEwB4OgswAAAAAAAAAADu/P//Cv///wAAEwBwAPsDCAAAAAAA AAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMIAAAAAQAAAAkCAAAfAP8DFAAAAAIAAAQMAAAAAAAA AAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAAACAAAANIQTAPz4CjBolhMA AAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTMgsAAA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAy ADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEB AQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAPAIoT+AgAAAAAug8WAAAAXwBfAF8AUABQAFQATQBh AGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAAB AAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIA AAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAA AAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQA eQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAA AAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAA AAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAA AQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAA AAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABU AHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkA EQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAA AAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAA AAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQBy AGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcA cgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAAC AAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEA AAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAA AGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAA AwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAE ABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAbEEACAAAQAK8PCAAAAAABAAAF AAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAA AOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAA AQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAK AEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAA bwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAa AAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAA BAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEE AAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEA bAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBw AGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIoTaAEA AAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNIAQAADwDWBzABAAAAALcPRAAAAE0AUwAgAFAA RwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1geA AAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiC EwB4Ogsw6IITAAAAAAAPANYHAAAGEiAAtw9EAAAAi1tTTwAAZQBzACAATgBlAHcAIABSAG8AbQBh AG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWB4YABgIwALcPRAAAAEEAcgBpAGEA bAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1gcA AAYiAAANBAgAAABwtQAAcLUAAA8AihNKAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMsAAAA LwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAAAAMAAACoAwAAAwADAAIP//8/ANkPDAAAAAAA2g8E AAAAAAAjAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDwDygLAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAAB AAAAAAAAAACfDwQAAAAGAAAAAACoD3kAAABPU1BGIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJ bXBhaXJtZW50IEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5ndGggQXNzaWdubWVudCBpbiBXYXZl bGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgAAChDyYAAAB6AAAAAAAAAAAAeAAAAAAA AgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAAqg8yAAAARQAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIMwAA AAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAUAAAAAAKgPnwAAAENDQU1QIFdHLCBJRVRG IDc4dGgsIE1hYXN0cmljaHQsIE5ldGhlcmxhbmRzIA0NZHJhZnQtYWdyYXotY2NhbXAtd3Nvbi1p bXBhaXJtZW50LW9zcGYtMDAudHh0DQ1GZXJuYW5kbyBBZ3JheiAoYWdyYXpAdHNjLnVwYy5lZHUp DVlhYmluIFllICh5YWJpbi55ZUBodWF3ZWkuY29tKQAAoQ8+AAAAoAAAAAAAABAAAHgALwAAAAAA BgASAAAAAAUuAAAAAAACABgAAQAAAAEABgABABIAAAD//kIAAAAAAAIAEgAAAKoPPgAAABUAAAAG AAAACQQECBgAAAAGAAAACQQECDAAAAAGAAAACQQECAEAAAAGAAAACQgECEIAAAAHAAAAAAAMBAQI DwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhYCzAAAN8PCAAAABUAAAAtAAAAAADzAxQAAABT AAAABAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8PAAAAQWNrbm93bGVkZ21lbnRzAACh DxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAkAAAAqg8aAAAADwAAAAYAAAAJBAQIAQAAAAcAAAAAAAQI CQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABWAAAABAAAAAEAAAAR AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAQmFja2dyb3VuZAAAoQ8UAAAACwAAAAAAAAAAAAsA AAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEAADzAxQAAABoAAAABAAA AAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAT2JqZWN0aXZlIAAAoQ8cAAAACwAAAAAA AAAAAAkAAAAAAAIAJAACAAAAAAAAAAAAqg8oAAAACQAAAAcAAAAAAAkEBAgBAAAABgAAAAkEBAgB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIA AAAEAAAAAgAAABkBAAAAAAAAAACfDwQAAAAAAAAAAACoDwwAAABOZXcgUExJIFRMViAAAKEPHAAA AA0AAAAAAAAAAAALAAAAAAACACQAAgAAAAAAAAAAAKoPMgAAAAMAAAAGAAAACQQECAgAAAAGAAAA CQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAVwAAAAQAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRo ZSBjb21wb3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAk AAIAAAAAAAAAAACqDyYAAAAfAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAA nw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAA AAAAAACfDwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAA oQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAA AAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEA AAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8eAAAAU29tZSBzdWItVExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAA AAAAAAAAHwAAAAAAAgAkAAAAqg9QAAAACQAAAAYAAAAJBAQIAwAAAAcAAAABAAAAAgAAAAMAAAAE AAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIA AAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAA ACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9 AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAA AFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAA aAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2 AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQA AACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAA AJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAA oQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACv AAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0A AAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAA AMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA 2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADo AAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADxAAAA8gAAAPMAAAD0AAAA9QAAAPYA AAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA/gAAAP8AAAAAAQAAAQEAAAIBAAADAQAABAEA AAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4BAAAPAQAAEAEAABEBAAASAQAA EwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAAHAEAAB0BAAAeAQAAHwEAACABAAAh AQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEAACkBAAAqAQAAKwEAACwBAAAtAQAALgEAAC8B AAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAANwEAADgBAAA5AQAAOgEAADsBAAA8AQAAPQEA AD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABFAQAARgEAAEcBAABIAQAASQEAAEoBAABLAQAA TAEAAE0BAABOAQAATwEAAFABAABRAQAAUgEAAFMBAABUAQAAVQEAAFYBAABXAQAAWAEAAFkBAABa AQAAWwEAAFwBAABdAQAAXgEAAF8BAABgAQAAYQEAAGIBAABjAQAAZAEAAGUBAABmAQAAZwEAAGgB AABpAQAAagEAAGsBAABsAQAAbQEAAG4BAABvAQAAcAEAAHEBAAByAQAAcwEAAHQBAAB1AQAAdgEA AHcBAAB4AQAAeQEAAHoBAAB7AQAAfAEAAH0BAAB+AQAAfwEAAIABAACBAQAAggEAAIMBAACEAQAA hQEAAIYBAACHAQAAiAEAAIkBAACKAQAAiwEAAIwBAACNAQAAjgEAAI8BAACQAQAAkQEAAJIBAACT AQAAlAEAAJUBAACWAQAAlwEAAJgBAACZAQAAmgEAAJsBAACcAQAAnQEAAJ4BAACfAQAAoAEAAKEB AACiAQAAowEAAKQBAAClAQAApgEAAKcBAACoAQAAqQEAAKoBAACrAQAArAEAAK0BAACuAQAArwEA ALABAACxAQAAsgEAALMBAAC0AQAAtQEAALYBAAC3AQAAuAEAALkBAAC6AQAAuwEAALwBAAC9AQAA vgEAAL8BAADAAQAAwQEAAMIBAADDAQAAxAEAAMUBAADGAQAAxwEAAMgBAADJAQAAygEAAMsBAADM AQAAzQEAAM4BAADPAQAA0AEAANEBAADSAQAA0wEAANQBAADVAQAA1gEAANcBAADYAQAA2QEAANoB AADbAQAA3AEAAN0BAADeAQAA3wEAAOABAADhAQAA4gEAAOMBAADkAQAA5QEAAOYBAADnAQAA6AEA AOkBAADqAQAA6wEAAOwBAADtAQAA7gEAAO8BAADwAQAA8QEAAPIBAADzAQAA9AEAAPUBAAD2AQAA 9wEAAPgBAAD5AQAA+gEAAPsBAAD8AQAA/QEAAP4BAAD/AQAAAAIAAAECAAACAgAAAwIAAAQCAAAF AgAABgIAAAcCAAAIAgAACQIAAAoCAAALAgAADAIAAA0CAAAOAgAADwIAABACAAARAgAAEgIAABMC AAAUAgAAFQIAABYCAAAXAgAAGAIAABkCAAAaAgAAGwIAABwCAAAdAgAAHgIAAB8CAAAgAgAAIQIA ACICAAAjAgAAJAIAACUCAAAmAgAAJwIAACgCAAApAgAAKgIAACsCAAAsAgAALQIAAC4CAAAvAgAA MAIAADECAAAyAgAAMwIAADQCAAA1AgAANgIAADcCAAA4AgAAOQIAADoCAAA7AgAAPAIAAD0CAAA+ AgAAPwIAAEACAABBAgAAQgIAAEMCAABEAgAARQIAAEYCAABHAgAASAIAAEkCAABKAgAASwIAAEwC AABNAgAATgIAAE8CAABQAgAAUQIAAFICAABTAgAAVAIAAFUCAABWAgAAVwIAAFgCAABZAgAAWgIA AFsCAABcAgAAXQIAAF4CAABfAgAAYAIAAGECAABiAgAAYwIAAGQCAABlAgAAZgIAAGcCAABoAgAA aQIAAGoCAABrAgAAbAIAAG0CAABuAgAAbwIAAHACAABxAgAAcgIAAHMCAAB0AgAAdQIAAHYCAAB3 AgAAeAIAAHkCAAB6AgAAewIAAHwCAAB9AgAAfgIAAH8CAACAAgAAgQIAAIICAACDAgAAhAIAAIUC AACGAgAAhwIAAIgCAACJAgAAigIAAIsCAACMAgAAjQIAAI4CAACPAgAAkAIAAJECAACSAgAAkwIA AJQCAACVAgAAlgIAAJcCAACYAgAAmQIAAJoCAACbAgAAnAIAAJ0CAACeAgAAnwIAAKACAAChAgAA ogIAAKMCAACkAgAApQIAAKYCAACnAgAAqAIAAKkCAACqAgAAqwIAAKwCAACtAgAArgIAAK8CAACw AgAAsQIAALICAACzAgAAtAIAALUCAAC2AgAAtwIAALgCAAC5AgAAugIAALsCAAC8AgAAvQIAAL4C AAC/AgAAwAIAAMECAADCAgAAwwIAAMQCAADFAgAAxgIAAMcCAADIAgAAyQIAAMoCAADLAgAAzAIA AM0CAADOAgAAzwIAANACAADRAgAA0gIAANMCAADUAgAA1QIAANYCAADXAgAA2AIAANkCAADaAgAA 2wIAANwCAADdAgAA3gIAAN8CAADgAgAA4QIAAOICAADjAgAA5AIAAOUCAADmAgAA5wIAAOgCAADp AgAA6gIAAOsCAADsAgAA7QIAAO4CAADvAgAA8AIAAPECAADyAgAA8wIAAPQCAAD1AgAA9gIAAPcC AAD4AgAA+QIAAPoCAAD7AgAA/AIAAP0CAAD+AgAA/wIAAAADAAABAwAAAgMAAAMDAAAEAwAABQMA AAYDAAAHAwAACAMAAAkDAAAKAwAACwMAAAwDAAANAwAADgMAAA8DAAAQAwAAEQMAABIDAAATAwAA FAMAABUDAAAWAwAAFwMAABgDAAAZAwAAGgMAABsDAAAcAwAAHQMAAB4DAAAfAwAAIAMAACEDAAAi AwAAIwMAACQDAAAlAwAAJgMAACcDAAAoAwAAKQMAACoDAAArAwAALAMAAC0DAAAuAwAALwMAADAD AAAxAwAAMgMAADMDAAA0AwAANQMAADYDAAA3AwAAOAMAADkDAAA6AwAAOwMAADwDAAA9AwAAPgMA AD8DAABAAwAAQQMAAEIDAABDAwAARAMAAEUDAABGAwAARwMAAEgDAABJAwAASgMAAEsDAABMAwAA TQMAAE4DAABPAwAAUAMAAFEDAABSAwAAUwMAAFQDAABVAwAAVgMAAFcDAABYAwAAWQMAAFoDAABb AwAAXAMAAF0DAABeAwAAXwMAAGADAABhAwAAYgMAAGMDAABkAwAAZQMAAGYDAABnAwAAaAMAAGkD AABqAwAAawMAAGwDAABtAwAAbgMAAG8DAAD+////cQMAAHIDAABzAwAAdAMAAHUDAAB2AwAAdwMA AHgDAAB5AwAAegMAAHsDAAB8AwAAfQMAAH4DAAB/AwAAgAMAAIEDAACCAwAAgwMAAIQDAACFAwAA hgMAAIcDAACIAwAAiQMAAIoDAACLAwAAjAMAAI0DAACOAwAAjwMAAJADAACRAwAAkgMAAJMDAACU AwAAlQMAAJYDAACXAwAAmAMAAJkDAACaAwAAmwMAAJwDAACdAwAAngMAAJ8DAACgAwAAoQMAAKID AACjAwAApAMAAKUDAACmAwAApwMAAKgDAACpAwAAqgMAAKsDAACsAwAArQMAAK4DAACvAwAAsAMA ALEDAACyAwAAswMAALQDAAC1AwAAtgMAALcDAAC4AwAAuQMAALoDAAC7AwAAvAMAAL0DAAC+AwAA vwMAAMADAADBAwAAwgMAAMMDAADEAwAAxQMAAMYDAADHAwAAyAMAAMkDAADKAwAAywMAAMwDAADN AwAAzgMAAM8DAADQAwAA0QMAANIDAADTAwAA1AMAANUDAADWAwAA1wMAANgDAADZAwAA2gMAANsD AADcAwAA3QMAAN4DAADfAwAA4AMAAOEDAADiAwAA4wMAAOQDAADlAwAA5gMAAOcDAADoAwAA6QMA AOoDAADrAwAA7AMAAO0DAADuAwAA7wMAAPADAADxAwAA8gMAAPMDAAD0AwAA9QMAAPYDAAD3AwAA +AMAAPkDAAD6AwAA+wMAAPwDAAD9AwAA/gMAAP8DAAAABAAAAQQAAAIEAAADBAAABAQAAAUEAAAG BAAABwQAAAgEAAAJBAAACgQAAAsEAAAMBAAADQQAAA4EAAAPBAAAEAQAABEEAAASBAAAEwQAABQE AAAVBAAAFgQAABcEAAAYBAAAGQQAABoEAAAbBAAAHAQAAB0EAAAeBAAAHwQAACAEAAAhBAAAIgQA ACMEAAAkBAAAJQQAACYEAAAnBAAAKAQAACkEAAAqBAAAKwQAACwEAAAtBAAALgQAAC8EAAAwBAAA MQQAADIEAAAzBAAANAQAADUEAAA2BAAANwQAADgEAAA5BAAAOgQAADsEAAA8BAAAPQQAAD4EAAA/ BAAAQAQAAEEEAABCBAAAQwQAAEQEAABFBAAARgQAAEcEAABIBAAASQQAAEoEAABLBAAATAQAAE0E AABOBAAATwQAAFAEAABRBAAAUgQAAFMEAABUBAAAVQQAAFYEAABXBAAAWAQAAFkEAABaBAAAWwQA AFwEAABdBAAAXgQAAF8EAABgBAAAYQQAAGIEAABjBAAAZAQAAGUEAABmBAAAZwQAAIwEAAD///// /////4sEAABsBAAAbQQAAG4EAABvBAAAcAQAAHEEAAByBAAAcwQAAHQEAAB1BAAAdgQAAHcEAAB4 BAAAeQQAAHoEAAB7BAAAfAQAAH0EAAB+BAAAfwQAAK4EAAD9/////f////3////9/////f////3/ ///9/////f////3////9/////f////7///+NBAAAjgQAAI8EAACQBAAAkQQAAJIEAACTBAAAlAQA AJUEAACWBAAAlwQAAJgEAACZBAAAmgQAAJsEAACcBAAAnQQAAJ4EAACfBAAAoAQAAKEEAACiBAAA owQAAKQEAABrBAAAAAYAAKcEAACoBAAAqQQAAKoEAACrBAAArAQAAK0EAAClBAAArwQAALAEAACx BAAAsgQAALMEAAC0BAAAtQQAALYEAAC3BAAAuAQAALkEAAC6BAAAuwQAALwEAAC9BAAAvgQAAL8E AADABAAAwQQAAMIEAADDBAAAxAQAAMUEAADGBAAAxwQAAMgEAADJBAAAygQAAMsEAADMBAAAzQQA AM4EAADPBAAA0AQAANEEAADSBAAA0wQAANQEAADVBAAA1gQAANcEAADYBAAA2QQAANoEAADbBAAA 3AQAAN0EAADeBAAA3wQAAOAEAADhBAAA4gQAAOMEAADkBAAA5QQAAOYEAADnBAAA6AQAAOkEAADq BAAA6wQAAOwEAADtBAAA7gQAAO8EAADwBAAA8QQAAPIEAADzBAAA9AQAAPUEAAD2BAAA9wQAAPgE AAD5BAAA+gQAAPsEAAD8BAAA/QQAAP4EAAD/BAAAAQUAAIEGAACCBgAAgwYAAIQGAACFBgAAhgYA AIcGAACIBgAAiQYAAIoGAACLBgAAjAYAAI0GAACOBgAAjwYAAJAGAACRBgAAkgYAAJMGAACUBgAA lQYAAJYGAACXBgAAmAYAAJkGAACaBgAAmwYAAJwGAACdBgAAngYAAJ8GAACgBgAAoQYAAKIGAACj BgAApAYAAKUGAACmBgAApwYAAKgGAACpBgAAqgYAAKsGAACsBgAArQYAAK4GAACvBgAAsAYAALEG AACyBgAAswYAALQGAAC1BgAAtgYAALcGAAC4BgAAuQYAALoGAAC7BgAAvAYAAL0GAAC+BgAAvwYA AMAGAADBBgAAwgYAAMMGAADEBgAAxQYAAMYGAADHBgAAyAYAAMkGAADKBgAAywYAAMwGAADNBgAA zgYAAM8GAADQBgAA0QYAANIGAADTBgAA1AYAANUGAADWBgAA1wYAANgGAADZBgAA2gYAANsGAADc BgAA3QYAAN4GAADfBgAA4AYAAOEGAADiBgAA4wYAAOQGAADlBgAA5gYAAOcGAAD+//////////// //////////////7///////////////7///////////////////////////////////////////// ////////////////////////////////////////////UABvAHcAZQByAFAAbwBpAG4AdAAgAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAwAAx7YGAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC AQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAABQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAA ABMAeDoLMPCDEwAAAAAADwDVBwAABCIwALcPRAAAANGeU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAA TABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QeGAAYCQAC3D0QAAABGAHIAdQB0 AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUH AAAEIlAAtw9EAAAATlOHZcZ+0Z4AAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQBy AAAAeDoLMPCDEwAAAAAADwDVB4YABgJgALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAeAB0ACAA TABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcCAAYCcAC3D0QAAABGAHIAdQB0 AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUH AAAGIoAAtw9EAAAAi1tTTwAAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAABy AAAAeDoLMPCDEwAAAAAADwDVB4YABgKQALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAA TABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQUoAC3D0QAAABUAGkAbQBl AHMAAABlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUH AAAEJLAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABCAG8AbABkAAAAAABy AAAAeDoLMPCDEwAAAAAADwDVBwAABhIAAKQPDAAAAIAAYgAAAAgAAAAUAAAApQ8aAAAAAACzqC4A AwD8AAYAAAAAAQEAMgD5AQcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAA AGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAAAUAACAB IAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBBYSAAAPAADwDhIA AAAABvAYCAAAGgQEAAIBAABBAQAAFAAAAAAAAAAPAAAAAgAAAD8AAAALAAAACAAAAAwAAAAEAAAA AAAAABAAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAA0AAAAA AAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABQAAAAAAAAAFAAAAAAAA AAQAAAAAAAAAIQAAACAAAACSAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAUAAAAAAAAA BwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABwAAAAAAAAAH AAAAAAAAAAcAAAAAAAAABgAAAC0AAABDAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYA AAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAcAAAAAAAAABwAA AAAAAAAGAAAAAAAAAEIAAAAAAAAAGQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAA PwAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAATwAAAAwAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAACQAAAAAAAABAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAABZAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAsAAAAAAAAABAAAAAAAAAD8AAAAAAAAAC8AAABiAAAABAAAAGMAAAAGAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABrAAAABAAAAAAAAAAm AAAAAAAAACUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAABxAAAACAAAAAAAAAC1AAAAAAAAAAYA AAB0AAAA+gEAAHUAAABeAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAPIAAAAAAAAA4wAAAAAAAABdAAAA AAAAAKwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAfAAAAAQAAAB9AAAAQQAAAH4A AABxAQAAAAAAAAYAAAAAAAAABgAAAIEAAAAABAAAAAAAAAYAAACBAAAA6gIAAIMAAAC9AAAAAAAA AAYAAAAAAAAABgAAAAAAAAAEAAAAhwAAABoAAACfAAHwjAEAAGIAB/AkAAAABgYFizUfvcf4Wqbz p1AbYphL/wDTKgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBdjz4wQC6S7Y4+1wmMk9IhX/AE62AAAB AAAA0yoAAAAAAABSAAfwJAAAAAUFbl5eEY0uvLba4/yHP5PIYP8ABlcAAAEAAAAh4QAAAAAAAGIA B/AkAAAABgYrHZxRQZaM23v++Bik0FJ5/wCrMwAAAQAAACc4AQAAAAAAYgAH8CQAAAAGBjzqGWgB pU9W1Nf4u5NQ0En/ANEVAAABAAAA0msBAAAAAABiAAfwJAAAAAYGuOlochf2C1z4/NRk7IJptv8A vFYFAAEAAACjgQEAAAAAADIAB/AkAAAAAwTu27VzakCgund2cy5xQ7YV/wBJAgAAAQAAAF/YBgAA AAAAMgAH8CQAAAADBEDr6bWAxkM/GdCbDDnQSyT/AJ0CAAABAAAAqNoGAAAAAAAyAAfwJAAAAAME qq27CBAYBSRVAqgM93b5Bf8ASwIAAAEAAABF3QYAAAAAAAMIC/AAAwAAgQBgNQEAggCwmgAAgwBg NQEAhACwmgAAhQACAAAAhwABAAAAiAAAAAAAiQAAAAAAvwACAA8ADAH0AAAQDQEAAAAgDgEAAAAg gAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghkEAAAAAh8EAAAAAiAEAAAAAiQEA AAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAA kwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAED AABAvwEMAB4AwAEBAAAIwQEAAAEAwgH///8AwwEAAAAgxAEAAAAAxUEAAAAAxsEAAAAAxwEAAAAA yAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEAAAAAz8EAAAAA1wECAAAA/wEO AA4AAAIAAAAAAQICAAAIAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAA CQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIA AAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAg vwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIA AAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA 0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIW AB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAA hgN8vgEAhwMAAAAAcw0i8QoFAACMAAEAAACNADBlAQB/AQAAQACeAf////+fAf////+gAQAAACCh wQAAAACiAf////+jAf////+kAQAAACClwQAAAACmAf////+nAf////+/AQAAIADZAf/////aAf// ///bAQAAACDcwQAAAADdAf/////eAf/////fAQAAACDgwQAAAADhAf/////iAf//////AQAAwAAS Av////8TAv////8UAgAAACAVwgAAAAAWAv////8XAv////8YAgAAACAZwgAAAAAaAv////8bAv// //+JAv////+KAv////+LAgAAACCMwgAAAACNAv////+PAwAAAACQAwIAAACRAwAAAACSAwIAAAC/ AwCCAIJABQAAAABBBQAAAQBCBf///wBDBQAAACBEBQAAAABFRQAAAABGxQAAAABHBQAAAABIBQAA AABJBQAAAABKBQAAAABLBTUlAABMBQAACABNBQAAAABOBQAAAABPxQAAAABQBQAAAABRBQAAAABS BQEAAABTBQEAAABUBQEAAABVBQEAAABXBQIAAABZBf////9aBf////9bBQAAACBcxQAAAABdBf// //9eBf////9fBQAAACBgxQAAAABhBf////9iBf////9/BQYATgCABQAAAACBBQAAAQCCBf///wCD BQAAACCEBQAAAACFRQAAAACGxQAAAACHBQAAAACIBQAAAACJBQAAAACKBQAAAACLBTUlAACMBQAA CACNBQAAAACOBQAAAACPxQAAAACQBQAAAACRBQAAAACSBQEAAACTBQEAAACUBQEAAACVBQEAAACX BQIAAACZBf////+aBf////+bBQAAACCcxQAAAACdBf////+eBf////+fBQAAACCgxQAAAAChBf// //+iBf////+/BQYATgDABQAAAADBBQAAAQDCBf///wDDBQAAACDEBQAAAADFRQAAAADGxQAAAADH BQAAAADIBQAAAADJBQAAAADKBQAAAADLBTUlAADMBQAACADNBQAAAADOBQAAAADPxQAAAADQBQAA AADRBQAAAADSBQEAAADTBQEAAADUBQEAAADVBQEAAADXBQIAAADZBf/////aBf/////bBQAAACDc xQAAAADdBf/////eBf/////fBQAAACDgxQAAAADhBf/////iBf//////BQYATgAABgAAAAABBgAA AQACBv///wADBgAAACAEBgAAAAAFRgAAAAAGxgAAAAAHBgAAAAAIBgAAAAAJBgAAAAAKBgAAAAAL BjUlAAAMBgAACAANBgAAAAAOBgAAAAAPxgAAAAAQBgAAAAARBgAAAAASBgEAAAATBgEAAAAUBgEA AAAVBgEAAAAXBgIAAAAZBv////8aBv////8bBgAAACAcxgAAAAAdBv////8eBv////8fBgAAACAg xgAAAAAhBv////8iBv////8/BgYATgBABgAAAABBBgAAAQBCBv///wBDBgAAACBEBgAAAABFRgAA AABGxgAAAABHBgAAAABIBgAAAABJBgAAAABKBgAAAABLBjUlAABMBgAACABNBgAAAABOBgAAAABP xgAAAABQBgAAAABRBgAAAABSBgEAAABTBgEAAABUBgEAAABVBgEAAABXBgIAAABZBv////9aBv// //9bBgAAACBcxgAAAABdBv////9eBv////9fBgAAACBgxgAAAABhBv////9iBv////9/BgYADgCA ABrxIAAAAP8AAADd3d0A6urqAP//ZgD/mQAAAAD/AACZzAAAZpkAQAAe8RAAAAAEAAAI/5kAAAAA AAD3AAAQHwDwD4wAAAAAAPMDFAAAAB8AAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAmAAAABAAA AAAAAAACAACAAAAAAAAA8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMDFAAAADEAAAAEAAAA AAAAAAQAAIAAAAAAAADzAxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ac9DAAAHwAUBBwAAAAA ABUEFAAAANAYzQQAypo7TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEBAAAA/QM0AAAAQgAA AGQAAABCAAAAZAAAAAAAAAD8JYgWCIQTAHg6CzAAAAAAAAAAAO78//8K////AAATAHAA+wMIAAAA AAAAADwCAABwAPsDCAAAAAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMUAAAAAgAABAwAAAAA AAAAAAAAAAIAAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAA0hBMA/PgKMGiW EwAAAAAAAAAAAAAAAAAAAAAAAAETAA8AiBMyCwAADwCKE2gAAAAAALoPFAAAAF8AXwBfAFAAUABU ADIAMAAwADEAAACLE0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAA AQEBAAEAAAAAAAAAiNkAAAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABfAF8AXwBQAFAAVABN AGEAYwAxADEAAACLE9IIAABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAA AAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAAB AgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAE AAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8A dAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAA AAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAA AAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAA AAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAAB BQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAA AAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYA AAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQBAAAAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIAABAArw8IAAAAAAEA AAUAAAAAABkQKAIAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA ABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AihNo AQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAAtw9EAAAATQBTACAA UABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDW B4AABiIQALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA 6IITAHg6CzDoghMAAAAAAA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHhgAGAjAAtw9EAAAAQQByAGkA YQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDW BwAABiIAAA0ECAAAAHC1AABwtQAADwCKE0oAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEywA AAAvAMgPDAAAADAA0g8EAAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg///z8A2Q8MAAAAAADa DwQAAAAAACMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPeAoAAAAA8wMUAAAAAwAAAAQAAAACAAAA AAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9m IEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25tZW50IGluIFdh dmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoAAAAAAAAAAAB4AAAA AAACABwAAQAAAAAAAAABAAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQBAAAABgAAAAkEBAgz AAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAAQ0NBTVAgV0csIElF VEYgNzh0aCwgTWFhc3RyaWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jhei1jY2FtcC13c29u LWltcGFpcm1lbnQtb3NwZi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3JhekB0c2MudXBjLmVk dSkNWWFiaW4gWWUgKHlhYmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAAAAAAEAAAeAAvAAAA AAAGABIAAAAABS4AAAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgASAAAAqg8+AAAAFQAA AAYAAAAJBAQIGAAAAAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQIQgAAAAcAAAAAAAwE BAgPAPIPGAAAAAAA8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAAAC0AAAAAAPMDFAAA AFMAAAAEAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tub3dsZWRnbWVudHMA AKEPFAAAABAAAAAAAAAAAAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkEBAgBAAAABwAAAAAA BAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFYAAAAEAAAAAQAA ABEBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQAAAALAAAAAAAAAAAA CwAAAAAAAgAkAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIAAAAE AAAAAgAAABkBAAAAAAAAAACfDwQAAAAAAAAAAACoDwwAAABOZXcgUExJIFRMViAAAKEPHAAAAA0A AAAAAAAAAAALAAAAAAACACQAAgAAAAAAAAAAAKoPMgAAAAMAAAAGAAAACQQECAgAAAAGAAAACQQJ BAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAA BAgJBAAA8wMUAAAAVwAAAAQAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBj b21wb3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIA AAAAAAAAAACqDyYAAAAfAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8E AAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAAAAAA AACfDwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAAoQ8c AAAAIQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAAAAYA AAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAA AKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8eAAAAU29tZSBzdWItVExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAAAAAA AAAAHwAAAAAAAgAkAAAAqg9QAAAACQAAAAYAAAAJBAQIAwAAAAcAAAADAAkECQQBAAAABwAAAAMA CQQECA0AAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAA AKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABlAAAABAAAAAIAAAAcAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTGluayBQTEkgVExWAAChDxQAAAAl AAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8aAAAAJAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8P BAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABmAAAABAAAAAIAAAAdAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQTEkgVExW AAChDxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAAAAYAAAAJ BAQICAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAA AAAECAkEAADzAxQAAABnAAAABAAAAAIAAAAeAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAAQW4g RXhhbXBsZSBvZiBjb21wb25lbnQgVExWAAChDxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAkAAAAqg8M AAAAHAAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAA RAAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMAAKEPFAAA AAsAAAAAAAAAAAALAAAAAAACACQAAACqDwwAAAALAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKgP qgAAAFJlZmluZSBpdCBhY2NvcmRpbmcgdG8gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcg b3IgbWFpbGluZyBsaXN0DUtlZXAgdXBncmFkaW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0aGUgc3Rh bmRhcmQgaW1wYWlybWVudCBpbmZvcm1hdGlvbg1Db21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lh dGVkAAChDzIAAACLAAAAAAAAAAAAIAAAAAAAACAAADIAGwAAAAAAYQALAAAACwCQAAAAAARBAAAE CwALAAAAqg8aAAAAqgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQvAPAPOAAAAAAA8wMUAAAABgAA AAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAE0AAAAAAAAAAAAAAAgBAAAAAAAAAADqAwAAAAAPAO4D OQMAAAIA7wMYAAAAAQAAAA0VAAAAAAAABwAAgAAAAAAHAAswDwAMBFACAAAPAALwSAIAAEAHCPAI AAAAAwAAAPltAwAPAAPw4AEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAAbAMABQAAAA8ABPB4AAAAEgAK8AgAAAACbAMAIAIAAGMAC/AkAAAABAAAAAAAfwAAAAQAgACU BYYWvwEAAAEA/wEAAAEAAQMCAAMAAAAQ8AgAAACtACABYBU8Ag8AEfAQAAAAAADDCwgAAAAAAAAA DQCGFg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8CgBAAASAArwCAAAAAdsAwAACgAA8wAL8FoAAAB/ AAAABACAALxINxaBAGA1AQCCALCaAACDAGA1AQCEALCaAAC/AAAADwCBAQQAAAiDAQAAAAi/AQwA HgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAAAH8BAABAAL8BAABgAP8BAADA AL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA+AjYDOIVSQ4PAA3w YAAAAAAAnw8EAAAABAAAAAAAoQ8oAAAAAQAAAAAAsyAKAAMA2AAGAAAAAAEyAAcAAQAAAAEAQwAB AAQABAANAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPBgAAAAEAAAD5AQ8ABPBIAAAAEgAK8AgA AAABbAMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAA DwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAYC7HYEA AAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAIwT/////xIA AAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchcQAAAAAQAQAPDuAQBWABAAgR0CAAAA 9Q8cAAAAEQEAAKQZAAPM7gEAwiACAAEAAABnAAAAAQDFMQ8A6ANBLwAAAQDpAygAAACAFgAA4BAA AOAQAACAFgAABQAAAAoAAAAFAAAARQAAAAEAAAAAAAABDwDyA2oEAAAvAMgPDAAAADAA0g8EAAAA AAAAAA8A1QeQAwAAAAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBo lhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHAAAGIhAAtw9EAAAATQBTACAAUABHAG8AdABoAGkA YwAAAG8AbQBhAG4AAABolhMAaJYTAOSEiBbwgxMAeDoLMPCDEwAAAAAADwDVB4AABiIgALcPRAAA AEYAcgB1AP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXV zdWcLhsQk5cIACss+a6wBAAAbAQAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA0AAA AAYAAADYAAAABwAAAOAAAAAIAAAA6AAAAAkAAADwAAAACgAAAPgAAAAXAAAAAAEAAAsAAAAIAQAA EAAAABABAAATAAAAGAEAABYAAAAgAQAADQAAACgBAAAMAAAADQQAAAIAAACoAwAAHgAAABAAAADU 2sbBxLvJz8/Uyr4AAAAAHgAAACAAAABIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQuAAAAAAMA AADHtgYAAwAAAKUAAAADAAAADAAAAAMAAAACAAAAAwAAAAAAAAADAAAAAAAAAAMAAACoGQsACwAA AAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAHAAAAAYAAABBcmlhbAALAAAATVMgUEdv dGhpYwAXAAAARnJ1dGlnZXJOZXh0IExUIE1lZGl1bQAFAAAAutrM5QAYAAAARnJ1dGlnZXJOZXh0 IExUIFJlZ3VsYXIACQAAALuqzsTPuLraAAoAAABXaW5nZGluZ3MAFgAAAEZydXRpZ2VyTmV4dCBM VCBMaWdo/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAxA8A AAwAAAABAAAAaAAAAAIAAABwAAAABAAAAIQAAAAHAAAAkAAAAAgAAACcAAAACQAAALAAAAASAAAA vAAAAAoAAADcAAAADAAAAOgAAAANAAAA9AAAAA8AAAAAAQAAEQAAAAgBAAACAAAAqAMAAB4AAAAM AAAAu8O1xsasIDEAAAAAHgAAAAQAAAAgAAAAHgAAAAQAAAAAAAAAHgAAAAwAAABKaWFucnVpIEhh bgAeAAAABAAAADQ1NQAeAAAAGAAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAEAAAAAQNvSk9QcA AEAAAACwA+ZioS/HAUAAAAAgCRj6mynLAQMAAADkAgAARwAAALQOAAD/////AwAAAAgAiRBnDAAA AQAJAAADUQcAAAUARQAAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwCeQChAAMAAAAeAAcAAAD8 AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAAAAAD///8ABAAAAC0BAQAOAAAAJAMFAP///////3gA oAB4AKAA////////CAAAAPoCAAAAAAAAAAAAAAQAAAAtAQIABAAAAC0BAAAEAAAAJwH//xwAAAD7 Avz/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B AwAEAAAALgEYAAQAAAACAQEABQAAAAkCMzOZAicAAAAyCjgAJgAVAAAAQ0NBTVAgV0csIElFVEYg Nzh0aCwgZAMAAwADAAMAAwABAAQAAwABAAEAAQADAAIAAgABAAIAAgABAAIAAQACAAQAAAAuAQAA HAAAAPsCEAAHAAAAAAC8AgAAAIYBAgIiU3lzdGVtAAAAAAAAAAAAABgAAAABAAAAkK4cAOQEAAAE AAAALQEEAAQAAADwAQMAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIzM5kCKwAAADIKOABS ABgAAABNYWFzdHJpY2h0LCBOZXRoZXJsYW5kcyADAAIAAgACAAIAAQABAAIAAgABAAEAAQADAAIA AgACAAIAAQABAAIAAwACAAIAAQAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL7/wAAAAAA AJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4B GAAEAAAAAgEBAAUAAAAJAgAAAAIPAAAAMgpHABkABQAAAGRyYWZ0dAMAAgADAAEAAQAEAAAALgEA AAQAAAAtAQQABAAAAPABAwAcAAAA+wL7/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpH ACMAAQAAAC38AgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL7/wAAAAAAAJABAAAAAABA ACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEB AAUAAAAJAgAAAAIPAAAAMgpHACUABQAAAGFncmF6dAMAAwACAAMAAwAEAAAALgEAAAQAAAAtAQQA BAAAAPABAwAcAAAA+wL7/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpHADMAAQAAAC38 AgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL7/wAAAAAAAJABAAAAAABAACJBcmlhbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAIPAAAAMgpHADUABQAAAGNjYW1wdAMAAwADAAQAAwAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAc AAAA+wL7/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpHAEUAAQAAAC38AgAEAAAALgEA AAQAAAAtAQQABAAAAPABAwAcAAAA+wL7/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAINAAAAMgpH AEcABAAAAHdzb24EAAMAAwACAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avv/AAAAAAAA kAEAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEY AAQAAAACAQEABQAAAAkCAAAAAgkAAAAyCkcAUwABAAAALfwCAAQAAAAuAQAABAAAAC0BBAAEAAAA 8AEDABwAAAD7Avv/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhYAAAAyCkcAVQAKAAAAaW1wYWly bWVudAEABAADAAMAAQACAAQAAwADAAEABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+/8A AAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQA AAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIKRwBuAAEAAAAt/AIABAAAAC4BAAAEAAAALQEE AAQAAADwAQMAHAAAAPsC+/8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDQAAADIKRwBwAAQAAABv c3BmAwADAAMAAQAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL7/wAAAAAAAJABAAAAAABA ACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEB AAUAAAAJAgAAAAIJAAAAMgpHAHoAAQAAAC38AgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA +wL7/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAt AQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIQAAAAMgpHAHwABgAAADAwLnR4dAMAAwABAAEA AwABAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAIkFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAjoAAAAyClUAMAAiAAAARmVybmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMuZWR1KQIAAgAB AAIAAwACAAIAAgABAAMAAgACAAIAAgABAAEAAwACAAEAAgACAAQAAQACAAIAAgACAAIAAgABAAIA AwACAAEABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAiQXJp YWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAA CQIAAAACNAAAADIKWwAzAB4AAABZYWJpbiBZZSAoeWFiaW4ueWVAaHVhd2VpLmNvbSkDAAIAAgAB AAIAAQADAAIAAQABAAIAAgACAAEAAgABAAMAAgAEAAIAAgACAAMAAgABAAEAAwACAAMAAQAEAAAA LgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAJFAAAA MgoYABUAKQAAAE9TUEYgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEltcGFpcm1lbnQgAAUABAAE AAQAAgAEAAMAAgADAAMAAwACAAMAAwADAAIAAgADAAIABAADAAQAAwAEAAIAAgACAAMAAgACAAIA BQADAAMAAQACAAYAAwADAAIAAwAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAA AJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4B GAAEAAAAAgEBAAUAAAAJAgAAAAIxAAAAMgogABAAHAAAAEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVs ZW5ndGgEAAQAAwADAAMAAgAEAAQAAwACAAEABAADAAIABAADAAMAAgAGAAMABAADAAIAAwADAAMA AwADAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avr/AAAAAAAAkAEAAAAAAEAAIkFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAhwAAAAyCiAAaQAOAAAAQXNzaWdubWVudCBpbiAEAAMAAwACAAMAAwAGAAMAAwACAAIAAgAD AAIABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+v8AAAAAAACQAQAAAAAAQAAiQXJpYWwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIA AAACPQAAADIKKwAaACQAAABXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MGAAMA AwADAAIAAwAEAAMAAgADAAIABAAFAAEAAgADAAMABAADAAIABQADAAIAAQAEAAMAAQACAAUAAwAC AAQAAwADAAMAAwAEAAAALgEAAAQAAAAtAQQABAAAAPABAwADAAAAAACwDgAAAAAAAAAAAAAAAAMA CQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgBAAAABwAAAAAABAgJ BBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGUAAAAEAAAAAgAAABwB AAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5rIFBM SSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDxoAAAAkAAAABgAAAAkECQQBAAAA BwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGYAAAAE AAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRo ZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDzIAAAAYAAAABgAA AAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAA qg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcAAAAEAAAAAgAAAB4BAAAAAAAAAACfDwQAAAAA AAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBUTFYAAKEPFAAAABwAAAAAAAAAAAAc AAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAA AAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAATmV4 dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPDAAAAAsAAAAGAAAACQQECBAA nw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFjY29yZGluZyB0byB0aGUgZmVlZGJhY2sgZnJv bSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QNS2VlcCB1cGdyYWRpbmcgd2hlbiBJVFUtVCBk ZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50IGluZm9ybWF0aW9uDUNvbW1lbnRzIGFyZSBh bHdheXMgYXBwcmVjaWF0ZWQAAKEPMgAAAIsAAAAAAAAAAAAgAAAAAAAAIAAAMgAbAAAAAABhAAsA AAALAJAAAAAABEEAAAQLAAsAAACqDxoAAACqAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A8A84 AAAAAADzAxQAAAAGAAAAAAAAAAAAAAAAAQAAAAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEAAAAA AAAAAOoDAAAAAA8A7gMXCgAAAgDvAxgAAAABAAAADRUAAAAAAAAHAACAAAAAAAcACzAPAAwELgkA AA8AAvAmCQAAQAcI8AgAAAAEAAAA+m0DAA8AA/C+CAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAABsAwAFAAAADwAE8HgAAAASAArwCAAAAAJsAwAgAgAAYwAL8CQAAAAE AAAAAAB/AAAABACAAJQFhha/AQAAAQD/AQAAAQABAwIAAwAAABDwCAAAAK0AIAFgFTwCDwAR8BAA AAAAAMMLCAAAAAAAAAANAIYWDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwKAEAABIACvAIAAAAB2wD AAAKAADzAAvwWgAAAH8AAAAEAIAAvEg3FoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEB BAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEA AEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgA AAD4CNgM4hVJDg8ADfBgAAAAAACfDwQAAAAEAAAAAAChDygAAAABAAAAAACzIAoAAwDYAAYAAAAA ATIABwABAAAAAQBDAAEABAAEAA0AAACqDw4AAAABAAAABwAAAAAABAgJBAAApg8GAAAAAQAAAPkB DwAE8NYGAAASAArwCAAAAPptAwAACgAAEwEL8GYAAAB/AAAABACAAHi1hhaBAGA1AQCCALCaAACD AGA1AQCEALCaAAC/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAA AwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAagIJAlkVNg0PAA3wAgYAAAAAnw8EAAAA BAAAAAAAoA++BAAARgB1AGwAbAAgAG4AYQBtAGUAGv8gAEQAeQBuAGEAbQBpAGMAIABJAG0AcABh AGkAcgBtAGUAbgB0ACAAQwBvAG4AcwB0AHIAYQBpAG4AdAAgAE4AZQB0AHcAbwByAGsAIABmAG8A cgAgAFQAcgBhAG4AcwBwAGEAcgBlAG4AdAAgAE0AZQBzAGgAIABPAHAAdABpAGMAYQBsACAATgBl AHQAdwBvAHIAawBzACAADQBQAGUAcgBpAG8AZAAa/zIAMAAwADgALgAxAF7/MgAwADEAMAAuADcA DQBQAGEAcgB0AG4AZQByAHMAGv9BAEQAVgBBACgARABFACkALAAgAEEAbABjAGEAdABlAGwALQBM AHUAYwBlAG4AdAAgACgARgBSACkALAAgAEUAQwBJACAAKABJAEwAKQAsACAASAB1AGEAdwBlAGkA IAAoAEQARQApACwAIABEAFQAQQBHACAAKABEAEUAKQAsACAAQQBJAFQAIAAoAEcAUgApACwAIABD AHIAZQBhAHQAZQAtAE4AZQB0ACAAKABJAFQAKQAsACAARQBOAFMAVAAgACgARgBSACkALAAgAEkA QgBCAFQAIAAoAEIARQApACwAIABSAEEAQwBUAEkAIAAoAEcAUgApACwAIABVAEUAcwBzAGUAeAAg ACgAVQBLACkALAAgAFUAUABDACAAKABFAFMAKQAgAGEAbgBkACAASgBDAFAAIAAoAEYAUgApAA0A TwBiAGoAZQBjAHQAaQB2AGUAGv9UAGgAZQAgAGQAZQB2AGUAbABvAHAAbQBlAG4AdAAgAG8AZgAg AGEAIABkAHkAbgBhAG0AaQBjACAAbgBlAHQAdwBvAHIAawAgAHAAbABhAG4AbgBpAG4AZwAgAHQA bwBvAGwAIAByAGUAcwBpAGQAaQBuAGcAIABpAG4AIAB0AGgAZQAgAGMAbwByAGUAIABuAGUAdAB3 AG8AcgBrACAAbgBvAGQAZQBzACAAdABoAGEAdAAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBzACAA cgBlAGEAbAAtAHQAaQBtAGUAIABtAGUAYQBzAHUAcgBlAG0AZQBuAHQAcwAgAG8AZgAgAG8AcAB0 AGkAYwBhAGwAIABsAGEAeQBlAHIAIABwAGUAcgBmAG8AcgBtAGEAbgBjAGUAIABpAG4AdABvACAA SQBBAC0AUgBXAEEAIABhAGwAZwBvAHIAaQB0AGgAbQBzACAAYQBuAGQAIABpAHMAIABpAG4AdABl AGcAcgBhAHQAZQBkACAAaQBuAHQAbwAgAGEAIAB1AG4AaQBmAGkAZQBkACAAYwBvAG4AdAByAG8A bAAgAHAAbABhAG4AZQANAE8AbgBlACAAbwBmACAAcAByAG8AagBlAGMAdAAgAG8AYgBqAGUAYwB0 AGkAdgBlAHMAIAAtACAAUAByAG8AdABvAGMAbwBsACAAZQB4AHQAZQBuAHMAaQBvAG4AcwAgAHQA bwAgAGUAbgBhAGIAbABlACAAYQBuACAASQBtAHAAYQBpAHIAbQBlAG4AdAAgAEEAdwBhAHIAZQAt AGMAbwBuAHQAcgBvAGwAIABwAGwAYQBuAGUAIAAAAKEPRAAAAAMCAAAAALMgCgADANgABgAAAAAB MgAHAF0AAAAAACEgAAABAAAAAP8UAAMCAAAAACIACAAUAF0AAAAAACQACAAAAP/+AACqD84AAAAJ AAAABgAAAAkEBAgCAAAABwAAAAAABAgJBFMAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEBgAAAAYA AAAJBAQIAQAAAAcAAAAAAAQICQQPAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBH4AAAAGAAAACQQE CAYAAAAHAAAAAwAJBAQIJgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQTiAAAABgAAAAkEBAhbAAAA BgAAAAkIAAABAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8GAAAAAQAAAPkBDwAE8EgAAAAS AArwCAAAAAFsAwAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCI E5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oB gLsdgQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAjBP/ ////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA+cEAAACAO8DGAAAAAEAAAAN DgAAAAAAAAcAAIAAAAAABwALMA8ADAT+AwAADwAC8PYDAACACAjwCAAAAAMAAAADCAQADwAD8I4D AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgEAAUAAAAPAATweAAA ABIACvAIAAAAAggEACACAABjAAvwJAAAAH8AAAAEAIAAlK6JFr8BAAABAP8BAAABAAEDAgADAIgD AAAAAAAAEPAIAAAAdwAgAWAVlwIPABHwEAAAAAAAwwsIAAAAAAAAAA0AiRYPAA3wDAAAAAAAng8E AAAAAAAAAA8ABPDWAgAAEgAK8AgAAAADCAQAAAoAAPMAC/BaAAAAfwAAAAQAgAAA84kWgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPICZAIsFdoKDwAN8A4CAAAAAJ8PBAAAAAQAAAAA AKgP5gAAAFR3byB0b3AtVExWcyBhcmUgZGVmaW5lZCB0byBkZXNjcmliZSBQTEkgKFBoeXNpY2Fs IExheWVyIEltcGFpcm1lbnRzKSBpbmZvcm1hdGlvbjoNTGluayBQTEkgVExWDURlc2NyaWJlcyB0 aGUgcGh5c2ljYWwgbGF5ZXIgaW1wYWlybWVudHMgcmVsYXRlZCB0byB0aGUgbGluaw1Ob2RlIFBM SSBUTFYNRGVzY3JpYmVzIHRoZSBwaHlzaWNhbCBsYXllciBpbXBhaXJtZW50cyByZWxhdGVkIHRv IHRoZSBub2RlAAChD8IAAABTAAAAAACyMAoAAgDYAAYAAAAAAYIAFAAHAA0AAAAAALMwCgADANgA BgAAAAABggAUAAcAPQAAAAEAMTAKAAEABgAAAAABggAUAAcADQAAAAAAszAKAAMA2AAGAAAAAAGC ABQABwA9AAAAAQAxMAoAAQAGAAAAAAGCABQABwBTAAAAAAAiAAgAFAANAAAAAAQiAAAECAAUAD0A AAAABCIAAAQIABQADQAAAAAIIgAACAgAFAA9AAAAAAwiAAAMCAAUAAAAqg8yAAAACAAAAAYAAAAJ CAQIBAAAAAcAAAADAAkIBAhHAAAABgAAAAkIBAiUAAAABgAAAAkEBAgAAKYPCAAAAAkAAAD5AW8A DwAE8EgAAAASAArwCAAAAAEIBAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADr LggAAAB1V8oBkDd4gQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAA AAAAAAAAjBP/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAByFxgAAAABABAA /iACAFYAEABHUAIAaAAQAGZaAgAAAPUPHAAAAB8BAACkGQAD2iACAFVfAgABAAAAaAAAAAEAxTEP AOgDMy8AAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABQAAAEUAAAABAAAAAAAAAQ8A 8gNqBAAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHkAMAAAAAtw9EAAAAQQByAGkAYQBsAAAATgBl AHcAIABSAG8AbQBhAG4AAABolhMAaJYTAOSEiBbwgxMAeDoLMPCDEwAAAAAADwDVBwAABiIQALcP RAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDw gxMAAAAAAA8A1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0A ZQBkAGkAdQBtAAAAEwB4Ogsw8IMTAAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAAdABpAGcAZQBy AE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVB4YABgJAALcP RAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDw gxMAAAAAAA8A1QcAAAQiUAC3D0QAAABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIA ZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4AZwBkAGkAbgBn AHMAAAB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVBwIABgJwALcP RAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDw gxMAAAAAAA8A1QcAAAYigAC3D0QAAACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwA aQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUAdABpAGcAZQBy AE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABBSgALcP RAAAAFQAaQBtAGUAcwAAAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDw gxMAAAAAAA8A1QcAAAQksAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAEIA bwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAACAAAABQAAACl DxoAAAAAALOoLgADAPwABgAAAAABAQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAA BQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAA AAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsE HhIAAA8AAPAWEgAAAAAG8CAIAAAECAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAAPwAAAAsAAAAI AAAADAAAAAQAAAAAAAAAEAAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQA AAAAAAAADQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAA AAAAAAUAAAAAAAAABAAAAAAAAAAhAAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAA AAAABQAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAA AAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAAAAAGAAAAAAAA AAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAA BwAAAAAAAAAHAAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAE AAAAAAAAAAQAAAA/AAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABPAAAADAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAACwAAAAAAAAAEAAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAAYwAAAAYAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAGsA AAAEAAAAAAAAACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEAAAAIAAAAAAAA ALUAAAAAAAAABgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAA BAAAAAAAAAAhAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA8gAAAAAAAADj AAAAAAAAAF0AAAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAB8AAAABAAA AH0AAABBAAAAfgAAAHEBAAAAAAAABgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAAAIEAAADqAgAA gwAAAL0AAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAAnwAB8IwBAABi AAfwJAAAAAYGBYs1H73H+Fqm86dQG2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/AkAAAABQXY8+ME Auku2OPtcJjJPSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/ AAZXAAABAAAAIeEAAAAAAABiAAfwJAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMAAAEAAAAnOAEA AAAAAGIAB/AkAAAABgY86hloAaVPVtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAAYgAH8CQAAAAG BrjpaHIX9gtc+PzUZOyCabb/ALxWBQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1c2pAoLp3dnMu cUO2Ff8ASQIAAAEAAABf2AYAAAAAADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk/wCdAgAAAQAA AKjaBgAAAAAAMgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0GAAAAAAADCAvw AAMAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAP AAwB9AAAEA0BAAAAIA4BAAAAIIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIZB AAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAA AJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkB AAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAA AMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4B AAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMA AAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8C AAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkG AIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUC AAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAA AM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gC AAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAA AH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAwZQEAfwEAAEAA ngH/////nwH/////oAEAAAAgocEAAAAAogH/////owH/////pAEAAAAgpcEAAAAApgH/////pwH/ ////vwEAACAA2QH/////2gH/////2wEAAAAg3MEAAAAA3QH/////3gH/////3wEAAAAg4MEAAAAA 4QH/////4gH//////wEAAMAAEgL/////EwL/////FAIAAAAgFcIAAAAAFgL/////FwL/////GAIA AAAgGcIAAAAAGgL/////GwL/////iQL/////igL/////iwIAAAAgjMIAAAAAjQL/////jwMAAAAA kAMCAAAAkQMAAAAAkgMCAAAAvwMAggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAgRAUAAAAARUUA AAAARsUAAAAARwUAAAAASAUAAAAASQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUAAAAATgUAAAAA T8UAAAAAUAUAAAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAAWQX/////WgX/ ////WwUAAAAgXMUAAAAAXQX/////XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/////fwUGAE4A gAUAAAAAgQUAAAEAggX///8AgwUAAAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAAiAUAAAAAiQUA AAAAigUAAAAAiwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUAAAAAkgUBAAAA kwUBAAAAlAUBAAAAlQUBAAAAlwUCAAAAmQX/////mgX/////mwUAAAAgnMUAAAAAnQX/////ngX/ ////nwUAAAAgoMUAAAAAoQX/////ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX///8AwwUAAAAg xAUAAAAAxUUAAAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAAzAUAAAgAzQUA AAAAzgUAAAAAz8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUBAAAA1wUCAAAA 2QX/////2gX/////2wUAAAAg3MUAAAAA3QX/////3gX/////3wUAAAAg4MUAAAAA4QX/////4gX/ /////wUGAE4AAAYAAAAAAQYAAAEAAgb///8AAwYAAAAgBAYAAAAABUYAAAAABsYAAAAABwYAAAAA CAYAAAAACQYAAAAACgYAAAAACwY1JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAAEAYAAAAAEQYA AAAAEgYBAAAAEwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAAGQb/////Ggb/////GwYAAAAgHMYAAAAA HQb/////Hgb/////HwYAAAAgIMYAAAAAIQb/////Igb/////PwYGAE4AQAYAAAAAQQYAAAEAQgb/ //8AQwYAAAAgRAYAAAAARUYAAAAARsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYAAAAASwY1JQAA TAYAAAgATQYAAAAATgYAAAAAT8YAAAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAAVAYBAAAAVQYB AAAAVwYCAAAAWQb/////Wgb/////WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYAAAAgYMYAAAAA YQb/////Ygb/////fwYGAA4AgAAa8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA/wAAmcwAAGaZ AEAAHvEQAAAABAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAAAAAAAAABAACA AAAAAAAA8wMUAAAAJgAAAAQAAAAAAAAAAgAAgAAAAAAAAPMDFAAAADMAAAAEAAAAAAAAAAYAAIAA AAAAAADzAxQAAAAxAAAABAAAAAAAAAAEAACAAAAAAAAA8wMUAAAAPAAAAAAAAAAAAAAABwAAgAAA AAAPANAHPQwAAB8AFAQcAAAAAAAVBBQAAADQGM0EAMqaO0613DYAypo7AQIAAA8A+gN3AAAAAAD+ AwMAAAABAQAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAAAAAAA/CWIFgiEEwB4OgswAAAAAAAAAADu /P//Cv///wAAEwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMIAAAAAQAAAAkC AAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAA AGQAAAACAAAANIQTAPz4CjBolhMAAAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTMgsAAA8AihNoAAAA AAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAA AAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAPAIoT+AgAAAAA ug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoA QQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABv AGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoA AQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB DwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAA AAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEPAIoTaAEAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNIAQAADwDW BzABAAAAALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwAwhBMA 6IITAHg6CzDoghMAAAAAAA8A1geAAAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGEiAAtw9EAAAAi1tTTwAA ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDW B4YABgIwALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA 6IITAHg6CzDoghMAAAAAAA8A1gcAAAYiAAANBAgAAABwtQAAcLUAAA8AihNKAAAAAAC6Dw4AAABf AF8AXwBQAFAAVAA5AAAAixMsAAAALwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAAAAMAAACoAwAA AwADAAIP//8/ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDwDxoLAAAA APMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD3kAAABPU1BGIEV4dGVu c2lvbnMgaW4gU3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5n dGggQXNzaWdubWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgAACh DyYAAAB6AAAAAAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAAqg8yAAAARQAAAAYA AAAJBAkEAQAAAAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAUAAAAA AKgPnwAAAENDQU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0cmljaHQsIE5ldGhlcmxhbmRzIA0NZHJh ZnQtYWdyYXotY2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9zcGYtMDAudHh0DQ1GZXJuYW5kbyBBZ3Jh eiAoYWdyYXpAdHNjLnVwYy5lZHUpDVlhYmluIFllICh5YWJpbi55ZUBodWF3ZWkuY29tKQAAoQ8+ AAAAoAAAAAAAABAAAHgALwAAAAAABgASAAAAAAUuAAAAAAACABgAAQAAAAEABgABABIAAAD//kIA AAAAAAIAEgAAAKoPPgAAABUAAAAGAAAACQQECBgAAAAGAAAACQQECDAAAAAGAAAACQQECAEAAAAG AAAACQgECEIAAAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhYCzAAAN8P CAAAABUAAAAtAAAAAADzAxQAAABTAAAABAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8P AAAAQWNrbm93bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAkAAAAqg8aAAAADwAA AAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkE AADzAxQAAABWAAAABAAAAAEAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAQmFja2dyb3Vu ZAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAA AAAECAkEAADzAxQAAABoAAAABAAAAAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAT2Jq ZWN0aXZlIAAAoQ8cAAAACwAAAAAAAAAAAAkAAAAAAAIAJAACAAAAAAAAAAAAqg8aAAAACgAAAAYA AAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADz AxQAAABiAAAABAAAAAIAAAAZAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8MAAAATmV3IFBMSSBUTFYg AAChDxwAAAANAAAAAAAAAAAACwAAAAAAAgAkAAIAAAAAAAAAAACqDzIAAAADAAAABgAAAAkEBAgI AAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAA AQAAAAcAAAAAAAQICQQAAPMDFAAAAFcAAAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAAAAAAAACo DyAAAABUaGUgY29tcG9zaXRpb24gb2YgTGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8A AAAAAAIAJAACAAAAAAAAAAAAqg8mAAAAHwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAA AAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAABAAAAAIA AAAaAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5vZGUgUExJ IFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMAAAAGAAAA CQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACf DwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAAGwEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPHgAAAFNvbWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExWcwAAoQ8U AAAAHwAAAAAAAAAAAB8AAAAAAAIAJAAAAKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAAAwAJBAkE AQAAAAcAAAADAAkEBAgNAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAECAkEEACf DwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAAHAEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsgUExJIFRM VgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEAAAAHAAAA AAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAAAAQAAAAC AAAAHQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIE5v ZGUgUExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAGAAAACQQJ BAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4A AAABAAAABwAAAAAABAgJBAAA8wMUAAAAZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPGwAAAEFuIEV4YW1wbGUgb2YgY29tcG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAAABwAAAAA AAIAJAAAAKoPDAAAABwAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQAAPMDFAAAAEQAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABOZXh0IFN0 ZXBzAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQIEACfDwQA AAABAAAAAACoD6oAAABSZWZpbmUgaXQgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBmcm9tIHRo ZSBtZWV0aW5nIG9yIG1haWxpbmcgbGlzdA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1UIGRlZmlu ZWQgdGhlIHN0YW5kYXJkIGltcGFpcm1lbnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJlIGFsd2F5 cyBhcHByZWNpYXRlZAAAoQ8yAAAAiwAAAAAAAAAAACAAAAAAAAAgAAAyABsAAAAAAGEACwAAAAsA kAAAAAAEQQAABAsACwAAAKoPGgAAAKoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAA APMDFAAAAAYAAAAAAAAAAAAAAAABAAAAAAAAAADzAxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA 6gMAAAAADwDuA1cKAAACAO8DGAAAAAEAAAANFQAAAAAAAAcAAIAAAAAABwALMA8ADARuCQAADwAC 8GYJAABABwjwCAAAAAQAAAD6bQMADwAD8P4IAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAA AAAAAAIACvAIAAAAAGwDAAUAAAAPAATweAAAABIACvAIAAAAAmwDACACAABjAAvwJAAAAAQAAAAA AH8AAAAEAIAAlAWGFr8BAAABAP8BAAABAAEDAgADAAAAEPAIAAAArQAgAWAVPAIPABHwEAAAAAAA wwsIAAAAAAAAAA0AhhYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPAoAQAAEgAK8AgAAAAHbAMAAAoA APMAC/BaAAAAfwAAAAQAgAC8SDcWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAI gwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/ AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPgI 2AziFUkODwAN8GAAAAAAAJ8PBAAAAAQAAAAAAKEPKAAAAAEAAAAAALMgCgADANgABgAAAAABMgAH AAEAAAABAEMAAQAEAAQADQAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAACmDwYAAAABAAAA+QEPAATw FgcAABIACvAIAAAA+m0DAAAKAAATAQvwZgAAAH8AAAAEAIAAeLWGFoEAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAL8AAgAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABqAgkCWRUcDg8ADfBCBgAAAACfDwQAAAAEAAAA AACgD/wEAABGAHUAbABsACAAbgBhAG0AZQAa/yAARAB5AG4AYQBtAGkAYwAgAEkAbQBwAGEAaQBy AG0AZQBuAHQAIABDAG8AbgBzAHQAcgBhAGkAbgB0ACAATgBlAHQAdwBvAHIAawAgAGYAbwByACAA VAByAGEAbgBzAHAAYQByAGUAbgB0ACAATQBlAHMAaAAgAE8AcAB0AGkAYwBhAGwAIABOAGUAdAB3 AG8AcgBrAHMAIAANAFAAZQByAGkAbwBkABr/MgAwADAAOAAuADEAXv8yADAAMQAwAC4ANwANAFAA YQByAHQAbgBlAHIAcwAa/0EARABWAEEAKABEAEUAKQAsACAAQQBsAGMAYQB0AGUAbAAtAEwAdQBj AGUAbgB0ACAAKABGAFIAKQAsACAARQBDAEkAIAAoAEkATAApACwAIABIAHUAYQB3AGUAaQAgACgA RABFACkALAAgAEQAVABBAEcAIAAoAEQARQApACwAIABBAEkAVAAgACgARwBSACkALAAgAEMAcgBl AGEAdABlAC0ATgBlAHQAIAAoAEkAVAApACwAIABFAE4AUwBUACAAKABGAFIAKQAsACAASQBCAEIA VAAgACgAQgBFACkALAAgAFIAQQBDAFQASQAgACgARwBSACkALAAgAFUARQBzAHMAZQB4ACAAKABV AEsAKQAsACAAVQBQAEMAIAAoAEUAUwApACAAYQBuAGQAIABKAEMAUAAgACgARgBSACkADQBPAGIA agBlAGMAdABpAHYAZQAa/1QAaABlACAAZABlAHYAZQBsAG8AcABtAGUAbgB0ACAAbwBmACAAYQAg AGQAeQBuAGEAbQBpAGMAIABuAGUAdAB3AG8AcgBrACAAcABsAGEAbgBuAGkAbgBnACAAdABvAG8A bAAgAHIAZQBzAGkAZABpAG4AZwAgAGkAbgAgAHQAaABlACAAYwBvAHIAZQAgAG4AZQB0AHcAbwBy AGsAIABuAG8AZABlAHMAIAB0AGgAYQB0ACAAaQBuAGMAbwByAHAAbwByAGEAdABlAHMAIAByAGUA YQBsAC0AdABpAG0AZQAgAG0AZQBhAHMAdQByAGUAbQBlAG4AdABzACAAbwBmACAAbwBwAHQAaQBj AGEAbAAgAGwAYQB5AGUAcgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQAgAGkAbgB0AG8AIABJAEEA LQBSAFcAQQAgAGEAbABnAG8AcgBpAHQAaABtAHMAIABhAG4AZAAgAGkAcwAgAGkAbgB0AGUAZwBy AGEAdABlAGQAIABpAG4AdABvACAAYQAgAHUAbgBpAGYAaQBlAGQAIABjAG8AbgB0AHIAbwBsACAA cABsAGEAbgBlAA0ATwBuAGUAIABvAGYAIABwAHIAbwBqAGUAYwB0ACAAbwBiAGoAZQBjAHQAaQB2 AGUAcwAgAC0AIABQAHIAbwB0AG8AYwBvAGwAIABlAHgAdABlAG4AcwBpAG8AbgBzACAAdABvACAA ZQBuAGEAYgBsAGUAIABhAG4AIABJAG0AcABhAGkAcgBtAGUAbgB0ACAAQQB3AGEAcgBlAC0AYwBv AG4AdAByAG8AbAAgAHAAbABhAG4AZQAsACAAdwBoAGkAYwBoACAAaQBzACAAcgBlAGwAYQB0AGUA ZAAgAHQAbwAgAEkARQBUAEYAIABzAGMAbwBwAGUAAAChD0QAAAADAgAAAACzIAoAAwDYAAYAAAAA ATIABwB8AAAAAAAhIAAAAQAAAAD/FAADAgAAAAAiAAgAFAB8AAAAAAAkAAgAAAD//gAAqg/QAAAA CQAAAAYAAAAJBAQIAgAAAAcAAAAAAAQICQRTAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAYAAAAG AAAACQQECAEAAAAHAAAAAAAECAkEDwAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQR+AAAABgAAAAkE BAgGAAAABwAAAAMACQQECCYAAAAGAAAACQQECAEAAAAHAAAAAAAECAkE4gAAAAYAAAAJBAQIWwAA AAYAAAAJCAAAIAAAAAcAAAAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8GAAAAAQAAAPkBDwAE8EgA AAASAArwCAAAAAFsAwAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAA DwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1 V8oBgLsdgQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA jBP/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA9sEAAACAO8DGAAAAAEA AAANDgAAAAAAAAcAAIAAAAAABwALMA8ADATyAwAADwAC8OoDAACACAjwCAAAAAMAAAADCAQADwAD 8IIDAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgEAAUAAAAPAATw eAAAABIACvAIAAAAAggEACACAABjAAvwJAAAAH8AAAAEAIAAlK6JFr8BAAABAP8BAAABAAEDAgAD AIgDAAAAAAAAEPAIAAAAdwAgAWAVlwIPABHwEAAAAAAAwwsIAAAAAAAAAA0AiRYPAA3wDAAAAAAA ng8EAAAAAAAAAA8ABPDKAgAAEgAK8AgAAAADCAQAAAoAAPMAC/BaAAAAfwAAAAQAgAAA84kWgQBg NQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4A AQICAAAIPwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPICZAIsFdoKDwAN8AICAAAAAJ8PBAAAAAQA AAAAAKgP9gAAAFNob3cgdGhlIHJlc3VsdCBvZiBESUNPTkVUIHByb2plY3QgUHJvdG9jb2wgZXh0 ZW5zaW9ucyB0byBlbmFibGUgYW4gSW1wYWlybWVudCBBd2FyZS1jb250cm9sIHBsYW5lDUxpbmsg UExJIFRMVg1EZXNjcmliZXMgdGhlIHBoeXNpY2FsIGxheWVyIGltcGFpcm1lbnRzIHJlbGF0ZWQg dG8gdGhlIGxpbmsNTm9kZSBQTEkgVExWDURlc2NyaWJlcyB0aGUgcGh5c2ljYWwgbGF5ZXIgaW1w YWlybWVudHMgcmVsYXRlZCB0byB0aGUgbm9kZQAAoQ+0AAAAcAAAAAAAszAKAAMA2AAGAAAAAAGC ABQABwA9AAAAAQAxMAoAAQAGAAAAAAGCABQABwANAAAAAACzMAoAAwDYAAYAAAAAAYIAFAAHAD0A AAABADEwCgABAAYAAAAAAYIAFAAHACMAAAAAACIACAAUAD8AAAAAACYACAAUAAAA//4OAAAAAAAi AAgAFAA9AAAAAAAiAAgAFAANAAAAAAQiAAAECAAUAD0AAAAACCIAAAgIABQAAACqDyQAAAAiAAAA BgAAAAkEBAhAAAAABgAAAAkIAACVAAAABgAAAAkEBAgAAKYPCAAAAAkAAAD5AW8ADwAE8EgAAAAS AArwCAAAAAEIBAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCI E5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oB kDd4gQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAjBP/ ////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAByFxgAAAABABAAmV8CAFYAEADU jgIAaAAQADOZAgAAAPUPHAAAABEBAACkGQADdV8CABaeAgABAAAAaAAAAAEAxTEPAOgDMy8AAAEA 6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABQAAAEUAAAABAAAAAAAAAQ8A8gNqBAAALwDI DwwAAAAwANIPBAAAAAAAAAAPANUHkAMAAAAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8A bQBhAG4AAABolhMAaJYTAOSEiBbwgxMAeDoLMPCDEwAAAAAADwDVBwAABiIQALcPRAAAAE0AUwAg AFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A 1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBt AAAAEwB4Ogsw8IMTAAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVB4YABgJAALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAQiUAC3D0QAAABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABh AHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAB4AHQA IABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVBwIABgJwALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAYigAC3D0QAAACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAA AHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABBSgALcPRAAAAFQAaQBt AGUAcwAAAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAQksAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAEIAbwBsAGQAAAAA AHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAACAAAABQAAAClDxoAAAAAALOo LgADAPwABgAAAAABAQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAi IAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEHhIAAA8AAPAW EgAAAAAG8CAIAAAECAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAAPwAAAAsAAAAIAAAADAAAAAQA AAAAAAAAEAAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAA AAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAA AAAABAAAAAAAAAAhAAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABQAAAAAA AAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAHAAAAAAAA AAcAAAAAAAAABwAAAAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAA BgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAH AAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAQA AAA/AAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABPAAAADAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACwAAAAAAAAAEAAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAAYwAAAAYAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAGsAAAAEAAAAAAAA ACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEAAAAIAAAAAAAAALUAAAAAAAAA BgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAh AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA8gAAAAAAAADjAAAAAAAAAF0A AAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAB8AAAABAAAAH0AAABBAAAA fgAAAHEBAAAAAAAABgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAAAIEAAADqAgAAgwAAAL0AAAAA AAAABgAAAAAAAAAGAAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAAnwAB8IwBAABiAAfwJAAAAAYG BYs1H73H+Fqm86dQG2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/AkAAAABQXY8+MEAuku2OPtcJjJ PSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/AAZXAAABAAAA IeEAAAAAAABiAAfwJAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMAAAEAAAAnOAEAAAAAAGIAB/Ak AAAABgY86hloAaVPVtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAAYgAH8CQAAAAGBrjpaHIX9gtc +PzUZOyCabb/ALxWBQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1c2pAoLp3dnMucUO2Ff8ASQIA AAEAAABf2AYAAAAAADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk/wCdAgAAAQAAAKjaBgAAAAAA MgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0GAAAAAAADCAvwAAMAAIEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAPAAwB9AAAEA0B AAAAIA4BAAAAIIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAA AIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEB AAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAA AJsBAAAAAJwBAwAAQL8BDAAeAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbB AAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAA ANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcC AAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAA ABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC 9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAA AMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9AC AAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcA ANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQD fL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAwZQEAfwEAAEAAngH/////nwH/ ////oAEAAAAgocEAAAAAogH/////owH/////pAEAAAAgpcEAAAAApgH/////pwH/////vwEAACAA 2QH/////2gH/////2wEAAAAg3MEAAAAA3QH/////3gH/////3wEAAAAg4MEAAAAA4QH/////4gH/ /////wEAAMAAEgL/////EwL/////FAIAAAAgFcIAAAAAFgL/////FwL/////GAIAAAAgGcIAAAAA GgL/////GwL/////iQL/////igL/////iwIAAAAgjMIAAAAAjQL/////jwMAAAAAkAMCAAAAkQMA AAAAkgMCAAAAvwMAggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAgRAUAAAAARUUAAAAARsUAAAAA RwUAAAAASAUAAAAASQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUAAAAATgUAAAAAT8UAAAAAUAUA AAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAAWQX/////WgX/////WwUAAAAg XMUAAAAAXQX/////XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/////fwUGAE4AgAUAAAAAgQUA AAEAggX///8AgwUAAAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAAiAUAAAAAiQUAAAAAigUAAAAA iwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUAAAAAkgUBAAAAkwUBAAAAlAUB AAAAlQUBAAAAlwUCAAAAmQX/////mgX/////mwUAAAAgnMUAAAAAnQX/////ngX/////nwUAAAAg oMUAAAAAoQX/////ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX///8AwwUAAAAgxAUAAAAAxUUA AAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAAzAUAAAgAzQUAAAAAzgUAAAAA z8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUBAAAA1wUCAAAA2QX/////2gX/ ////2wUAAAAg3MUAAAAA3QX/////3gX/////3wUAAAAg4MUAAAAA4QX/////4gX//////wUGAE4A AAYAAAAAAQYAAAEAAgb///8AAwYAAAAgBAYAAAAABUYAAAAABsYAAAAABwYAAAAACAYAAAAACQYA AAAACgYAAAAACwY1JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAAEAYAAAAAEQYAAAAAEgYBAAAA EwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAAGQb/////Ggb/////GwYAAAAgHMYAAAAAHQb/////Hgb/ ////HwYAAAAgIMYAAAAAIQb/////Igb/////PwYGAE4AQAYAAAAAQQYAAAEAQgb///8AQwYAAAAg RAYAAAAARUYAAAAARsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYAAAAASwY1JQAATAYAAAgATQYA AAAATgYAAAAAT8YAAAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAAVAYBAAAAVQYBAAAAVwYCAAAA WQb/////Wgb/////WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYAAAAgYMYAAAAAYQb/////Ygb/ ////fwYGAA4AgAAa8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA/wAAmcwAAGaZAEAAHvEQAAAA BAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAAAAAAAAABAACAAAAAAAAA8wMU AAAAJgAAAAQAAAAAAAAAAgAAgAAAAAAAAPMDFAAAADMAAAAEAAAAAAAAAAYAAIAAAAAAAADzAxQA AAAxAAAABAAAAAAAAAAEAACAAAAAAAAA8wMUAAAAPAAAAAAAAAAAAAAABwAAgAAAAAAPANAHPQwA AB8AFAQcAAAAAAAVBBQAAADQGM0EAMqaO0613DYAypo7AQIAAA8A+gN3AAAAAAD+AwMAAAABAQAA AP0DNAAAAEIAAABkAAAAQgAAAGQAAAAAAAAA/CWIFgiEEwB4OgswAAAAAAAAAADu/P//Cv///wAA EwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMIAAAAAQAAAAkCAAAfAP8DFAAA AAIAAAQMAAAAAAAAAAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAAACAAAA NIQTAPz4CjBolhMAAAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTMgsAAA8AihNoAAAAAAC6DxQAAABf AF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgC AAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAPAIoT+AgAAAAAug8WAAAAXwBf AF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoA QQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABv AGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoA AQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAE AAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQA AAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBs AAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAA aAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAA AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAbEEACAAAQ AK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAA AAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAA AQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAED AAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAA AAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5 AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEA AAAaAAEPAIoTaAEAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNIAQAADwDWBzABAAAAALcP RAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDo ghMAAAAAAA8A1geAAAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGiW EwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGEiAAtw9EAAAAi1tTTwAAZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWB4YABgIwALcP RAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDo ghMAAAAAAA8A1gcAAAYiAAANBAgAAABwtQAAcLUAAA8AihNKAAAAAAC6Dw4AAABfAF8AXwBQAFAA VAA5AAAAixMsAAAALwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAAAAMAAACoAwAAAwADAAIP//8/ ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDwDxoLAAAAAPMDFAAAAAMA AAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD3kAAABPU1BGIEV4dGVuc2lvbnMgaW4g U3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5ndGggQXNzaWdu bWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgAAChDyYAAAB6AAAA AAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAAqg8yAAAARQAAAAYAAAAJBAkEAQAA AAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAUAAAAAAKgPnwAAAEND QU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0cmljaHQsIE5ldGhlcmxhbmRzIA0NZHJhZnQtYWdyYXot Y2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9zcGYtMDAudHh0DQ1GZXJuYW5kbyBBZ3JheiAoYWdyYXpA dHNjLnVwYy5lZHUpDVlhYmluIFllICh5YWJpbi55ZUBodWF3ZWkuY29tKQAAoQ8+AAAAoAAAAAAA ABAAAHgALwAAAAAABgASAAAAAAUuAAAAAAACABgAAQAAAAEABgABABIAAAD//kIAAAAAAAIAEgAA AKoPPgAAABUAAAAGAAAACQQECBgAAAAGAAAACQQECDAAAAAGAAAACQQECAEAAAAGAAAACQgECEIA AAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhYCzAAAN8PCAAAABUAAAAt AAAAAADzAxQAAABTAAAABAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8PAAAAQWNrbm93 bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAkAAAAqg8aAAAADwAAAAYAAAAJBAQI AQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABW AAAABAAAAAEAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAQmFja2dyb3VuZAAAoQ8UAAAA CwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEAADz AxQAAABoAAAABAAAAAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAT2JqZWN0aXZlIAAA oQ8cAAAACwAAAAAAAAAAAAkAAAAAAAIAJAACAAAAAAAAAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAA AAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABiAAAA BAAAAAIAAAAZAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8MAAAATmV3IFBMSSBUTFYgAAChDxwAAAAN AAAAAAAAAAAACwAAAAAAAgAkAAIAAAAAAAAAAACqDzIAAAADAAAABgAAAAkEBAgIAAAABgAAAAkE CQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAA AAQICQQAAPMDFAAAAFcAAAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABUaGUg Y29tcG9zaXRpb24gb2YgTGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIAJAAC AAAAAAAAAAAAqg8mAAAAHwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8P BAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAABAAAAAIAAAAaAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5vZGUgUExJIFRMViAAAKEP HAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMAAAAGAAAACQQJBAQAAAAG AAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAAGwEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPHgAAAFNvbWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExWcwAAoQ8UAAAAHwAAAAAA AAAAAB8AAAAAAAIAJAAAAKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAAAwAJBAkEAQAAAAcAAAAD AAkEBAgNAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAAHAEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsgUExJIFRMVgAAoQ8UAAAA JQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACf DwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAAAAQAAAACAAAAHQEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIE5vZGUgUExJIFRM VgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAGAAAACQQJBAQAAAAGAAAA CQQECAgAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGwAAAEFu IEV4YW1wbGUgb2YgY29tcG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAAABwAAAAAAAIAJAAAAKoP DAAAABwAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AEQAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABOZXh0IFN0ZXBzAAChDxQA AAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACo D6oAAABSZWZpbmUgaXQgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBtZWV0aW5n IG9yIG1haWxpbmcgbGlzdA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1UIGRlZmluZWQgdGhlIHN0 YW5kYXJkIGltcGFpcm1lbnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJlIGFsd2F5cyBhcHByZWNp YXRlZAAAoQ8yAAAAiwAAAAAAAAAAACAAAAAAAAAgAAAyABsAAAAAAGEACwAAAAsAkAAAAAAEQQAA BAsACwAAAKoPGgAAAKoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAAAPMDFAAAAAYA AAAAAAAAAAAAAAABAAAAAAAAAADzAxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA6gMAAAAADwDu A28KAAACAO8DGAAAAAEAAAANFQAAAAAAAAcAAIAAAAAABwALMA8ADASGCQAADwAC8H4JAABABwjw CAAAAAQAAAD6bQMADwAD8BYJAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAAGwDAAUAAAAPAATweAAAABIACvAIAAAAAmwDACACAABjAAvwJAAAAAQAAAAAAH8AAAAEAIAA lAWGFr8BAAABAP8BAAABAAEDAgADAAAAEPAIAAAArQAgAWAVPAIPABHwEAAAAAAAwwsIAAAAAAAA AA0AhhYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPAoAQAAEgAK8AgAAAAHbAMAAAoAAPMAC/BaAAAA fwAAAAQAgAC8SDcWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEM AB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAA wAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPgI2AziFUkODwAN 8GAAAAAAAJ8PBAAAAAQAAAAAAKEPKAAAAAEAAAAAALMgCgADANgABgAAAAABMgAHAAEAAAABAEMA AQAEAAQADQAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAACmDwYAAAABAAAA+QEPAATwLgcAABIACvAI AAAA+m0DAAAKAAATAQvwZgAAAH8AAAAEAIAAeLWGFoEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8A AgAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4A PwYGAE4AfwYGAA4AAAAQ8AgAAABqAgkCWRUcDg8ADfBaBgAAAACfDwQAAAAEAAAAAACgDwgFAABG AHUAbABsACAAbgBhAG0AZQAa/yAARAB5AG4AYQBtAGkAYwAgAEkAbQBwAGEAaQByAG0AZQBuAHQA IABDAG8AbgBzAHQAcgBhAGkAbgB0ACAATgBlAHQAdwBvAHIAawAgAGYAbwByACAAVAByAGEAbgBz AHAAYQByAGUAbgB0ACAATQBlAHMAaAAgAE8AcAB0AGkAYwBhAGwAIABOAGUAdAB3AG8AcgBrAHMA IAANAFAAZQByAGkAbwBkABr/MgAwADAAOAAuADEAXv8yADAAMQAwAC4ANwANAFAAYQByAHQAbgBl AHIAcwAa/0EARABWAEEAKABEAEUAKQAsACAAQQBsAGMAYQB0AGUAbAAtAEwAdQBjAGUAbgB0ACAA KABGAFIAKQAsACAARQBDAEkAIAAoAEkATAApACwAIABIAHUAYQB3AGUAaQAgACgARABFACkALAAg AEQAVABBAEcAIAAoAEQARQApACwAIABBAEkAVAAgACgARwBSACkALAAgAEMAcgBlAGEAdABlAC0A TgBlAHQAIAAoAEkAVAApACwAIABFAE4AUwBUACAAKABGAFIAKQAsACAASQBCAEIAVAAgACgAQgBF ACkALAAgAFIAQQBDAFQASQAgACgARwBSACkALAAgAFUARQBzAHMAZQB4ACAAKABVAEsAKQAsACAA VQBQAEMAIAAoAEUAUwApACAAYQBuAGQAIABKAEMAUAAgACgARgBSACkADQBPAGIAagBlAGMAdABp AHYAZQAa/1QAaABlACAAZABlAHYAZQBsAG8AcABtAGUAbgB0ACAAbwBmACAAYQAgAGQAeQBuAGEA bQBpAGMAIABuAGUAdAB3AG8AcgBrACAAcABsAGEAbgBuAGkAbgBnACAAdABvAG8AbAAgAHIAZQBz AGkAZABpAG4AZwAgAGkAbgAgAHQAaABlACAAYwBvAHIAZQAgAG4AZQB0AHcAbwByAGsAIABuAG8A ZABlAHMAIAB0AGgAYQB0ACAAaQBuAGMAbwByAHAAbwByAGEAdABlAHMAIAByAGUAYQBsAC0AdABp AG0AZQAgAG0AZQBhAHMAdQByAGUAbQBlAG4AdABzACAAbwBmACAAbwBwAHQAaQBjAGEAbAAgAGwA YQB5AGUAcgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQAgAGkAbgB0AG8AIABJAEEALQBSAFcAQQAg AGEAbABnAG8AcgBpAHQAaABtAHMAIABhAG4AZAAgAGkAcwAgAGkAbgB0AGUAZwByAGEAdABlAGQA IABpAG4AdABvACAAYQAgAHUAbgBpAGYAaQBlAGQAIABjAG8AbgB0AHIAbwBsACAAcABsAGEAbgBl AA0ATwBuAGUAIABvAGYAIABwAHIAbwBqAGUAYwB0ACAAbwBiAGoAZQBjAHQAaQB2AGUAcwAgAC0A IABQAHIAbwB0AG8AYwBvAGwAIABlAHgAdABlAG4AcwBpAG8AbgBzACAAdABvACAAZQBuAGEAYgBs AGUAIABhAG4AIABJAG0AcABhAGkAcgBtAGUAbgB0ACAAQQB3AGEAcgBlAC0AYwBvAG4AdAByAG8A bAAgAHAAbABhAG4AZQAsACAAdwBoAGkAYwBoACAAaQBzACAAcgBlAGwAYQB0AGUAZAAgAHQAbwAg AEkARQBUAEYAIABDAEMAQQBNAFAAIABzAGMAbwBwAGUAAAChD0QAAAADAgAAAACzIAoAAwDYAAYA AAAAATIABwCCAAAAAAAhIAAAAQAAAAD/FAADAgAAAAAiAAgAFACCAAAAAAAkAAgAAAD//gAAqg/c AAAACQAAAAYAAAAJBAQIAgAAAAcAAAAAAAQICQRTAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAYA AAAGAAAACQQECAEAAAAHAAAAAAAECAkEDwAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQR+AAAABgAA AAkEBAgGAAAABwAAAAMACQQECCYAAAAGAAAACQQECAEAAAAHAAAAAAAECAkE4gAAAAYAAAAJBAQI WwAAAAYAAAAJCAAAGwAAAAYAAAAJBAQICwAAAAcAAAAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8G AAAAAQAAAPkBDwAE8EgAAAASAArwCAAAAAFsAwAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixNpAAAAAADrLggAAAB1V8oBgLsdgQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAAAiRb/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAABy FxAAAAABABAAWp4CAFYAEACVzQIAAAD1DxwAAAARAQAApBkAAzaeAgAM2AIAAQAAAGgAAAABAMUx DwDoAzMvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAABFAAAAAQAAAAAAAAEP APIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5ADAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4A ZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A1QcAAAYiEAC3 D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw 8IMTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABN AGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVBwAABCIwALcPRAAAANGeU08AAHQAaQBnAGUA cgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QeGAAYCQAC3 D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw 8IMTAAAAAAAPANUHAAAEIlAAtw9EAAAATlOHZcZ+0Z4AAGcAZQByAE4AZQB4AHQAIABMAFQAIABS AGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVB4YABgJgALcPRAAAAFcAaQBuAGcAZABpAG4A ZwBzAAAAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcCAAYCcAC3 D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw 8IMTAAAAAAAPANUHAAAGIoAAtw9EAAAAi1tTTwAAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABM AGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAADwDVB4YABgKQALcPRAAAAEYAcgB1AHQAaQBnAGUA cgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQUoAC3 D0QAAABUAGkAbQBlAHMAAABlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw 8IMTAAAAAAAPANUHAAAEJLAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABC AG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABhIAAKQPDAAAAIAAYgAAAAgAAAAUAAAA pQ8aAAAAAACzqC4AAwD8AAYAAAAAAQEAMgD5AQcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BB4SAAAPAADwFhIAAAAABvAgCAAABAgEAAMBAABFAQAAFQAAAAAAAAAPAAAAAgAAAD8AAAALAAAA CAAAAAwAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAE AAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAgA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABQAA AAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAACAAAACSAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAA AAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAA AAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAC0AAABDAAAAAAAAAAQAAAAAAAAABgAAAAAA AAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAA AAcAAAAAAAAABwAAAAAAAAAGAAAAAAAAAEIAAAAAAAAAGQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAA BAAAAAAAAAAEAAAAPwAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAA0AAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAATwAAAAwAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAAAABAAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABZAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAAAAAAD8AAAAAAAAAC8AAABiAAAABAAAAGMAAAAGAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABr AAAABAAAAAAAAAAmAAAAAAAAACUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAABxAAAACAAAAAAA AAC1AAAAAAAAAAYAAAB0AAAA+wEAAHUAAABeAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAFAAAAAAAA AAQAAAAAAAAAIQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAPIAAAAAAAAA 4wAAAAAAAABdAAAAAAAAAKwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAfAAAAAQA AAB9AAAAQQAAAH4AAABxAQAAAAAAAAYAAAAAAAAABgAAAIEAAAAABAAAAAAAAAYAAACBAAAA6gIA AIMAAAC9AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAhwAAABoAAACIAAAABAAAAJ8AAfCMAQAA YgAH8CQAAAAGBgWLNR+9x/hapvOnUBtimEv/ANMqAAABAAAAAAAAAAAAAABSAAfwJAAAAAUF2PPj BALpLtjj7XCYyT0iFf8ATrYAAAEAAADTKgAAAAAAAFIAB/AkAAAABQVuXl4RjS68ttrj/Ic/k8hg /wAGVwAAAQAAACHhAAAAAAAAYgAH8CQAAAAGBisdnFFBlozbe/74GKTQUnn/AKszAAABAAAAJzgB AAAAAABiAAfwJAAAAAYGPOoZaAGlT1bU1/i7k1DQSf8A0RUAAAEAAADSawEAAAAAAGIAB/AkAAAA Bga46WhyF/YLXPj81GTsgmm2/wC8VgUAAQAAAKOBAQAAAAAAMgAH8CQAAAADBO7btXNqQKC6d3Zz LnFDthX/AEkCAAABAAAAX9gGAAAAAAAyAAfwJAAAAAMEQOvptYDGQz8Z0JsMOdBLJP8AnQIAAAEA AACo2gYAAAAAADIAB/AkAAAAAwSqrbsIEBgFJFUCqAz3dvkF/wBLAgAAAQAAAEXdBgAAAAAAAwgL 8AADAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAACIAAAAAACJAAAAAAC/AAIA DwAMAfQAABANAQAAACAOAQAAACCAAQAAAACBAQQAAAiCAQAAAQCDAQAAAAiEAQAAAQCFAQAAACCG QQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAA AACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZ AQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDAAQEAAAjBAQAAAQDCAf///wDDAQAAACDEAQAA AADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADO AQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgCAsvLywADAgAAACAEAgAAAQAFAjhj AAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAP AgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5 BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAAAADF AgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCA AADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8///Y AgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAA AAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAABzDSLxCgUAAIwAAQAAAI0AMGUBAH8BAABA AJ4B/////58B/////6ABAAAAIKHBAAAAAKIB/////6MB/////6QBAAAAIKXBAAAAAKYB/////6cB /////78BAAAgANkB/////9oB/////9sBAAAAINzBAAAAAN0B/////94B/////98BAAAAIODBAAAA AOEB/////+IB//////8BAADAABIC/////xMC/////xQCAAAAIBXCAAAAABYC/////xcC/////xgC AAAAIBnCAAAAABoC/////xsC/////4kC/////4oC/////4sCAAAAIIzCAAAAAI0C/////48DAAAA AJADAgAAAJEDAAAAAJIDAgAAAL8DAIIAgkAFAAAAAEEFAAABAEIF////AEMFAAAAIEQFAAAAAEVF AAAAAEbFAAAAAEcFAAAAAEgFAAAAAEkFAAAAAEoFAAAAAEsFNSUAAEwFAAAIAE0FAAAAAE4FAAAA AE/FAAAAAFAFAAAAAFEFAAAAAFIFAQAAAFMFAQAAAFQFAQAAAFUFAQAAAFcFAgAAAFkF/////1oF /////1sFAAAAIFzFAAAAAF0F/////14F/////18FAAAAIGDFAAAAAGEF/////2IF/////38FBgBO AIAFAAAAAIEFAAABAIIF////AIMFAAAAIIQFAAAAAIVFAAAAAIbFAAAAAIcFAAAAAIgFAAAAAIkF AAAAAIoFAAAAAIsFNSUAAIwFAAAIAI0FAAAAAI4FAAAAAI/FAAAAAJAFAAAAAJEFAAAAAJIFAQAA AJMFAQAAAJQFAQAAAJUFAQAAAJcFAgAAAJkF/////5oF/////5sFAAAAIJzFAAAAAJ0F/////54F /////58FAAAAIKDFAAAAAKEF/////6IF/////78FBgBOAMAFAAAAAMEFAAABAMIF////AMMFAAAA IMQFAAAAAMVFAAAAAMbFAAAAAMcFAAAAAMgFAAAAAMkFAAAAAMoFAAAAAMsFNSUAAMwFAAAIAM0F AAAAAM4FAAAAAM/FAAAAANAFAAAAANEFAAAAANIFAQAAANMFAQAAANQFAQAAANUFAQAAANcFAgAA ANkF/////9oF/////9sFAAAAINzFAAAAAN0F/////94F/////98FAAAAIODFAAAAAOEF/////+IF //////8FBgBOAAAGAAAAAAEGAAABAAIG////AAMGAAAAIAQGAAAAAAVGAAAAAAbGAAAAAAcGAAAA AAgGAAAAAAkGAAAAAAoGAAAAAAsGNSUAAAwGAAAIAA0GAAAAAA4GAAAAAA/GAAAAABAGAAAAABEG AAAAABIGAQAAABMGAQAAABQGAQAAABUGAQAAABcGAgAAABkG/////xoG/////xsGAAAAIBzGAAAA AB0G/////x4G/////x8GAAAAICDGAAAAACEG/////yIG/////z8GBgBOAEAGAAAAAEEGAAABAEIG ////AEMGAAAAIEQGAAAAAEVGAAAAAEbGAAAAAEcGAAAAAEgGAAAAAEkGAAAAAEoGAAAAAEsGNSUA AEwGAAAIAE0GAAAAAE4GAAAAAE/GAAAAAFAGAAAAAFEGAAAAAFIGAQAAAFMGAQAAAFQGAQAAAFUG AQAAAFcGAgAAAFkG/////1oG/////1sGAAAAIFzGAAAAAF0G/////14G/////18GAAAAIGDGAAAA AGEG/////2IG/////38GBgAOAIAAGvEgAAAA/wAAAN3d3QDq6uoA//9mAP+ZAAAAAP8AAJnMAABm mQBAAB7xEAAAAAQAAAj/mQAAAAAAAPcAABAfAPAPjAAAAAAA8wMUAAAAHwAAAAQAAAAAAAAAAQAA gAAAAAAAAPMDFAAAACYAAAAEAAAAAAAAAAIAAIAAAAAAAADzAxQAAAAzAAAABAAAAAAAAAAGAACA AAAAAAAA8wMUAAAAMQAAAAQAAAAAAAAABAAAgAAAAAAAAPMDFAAAADwAAAAAAAAAAAAAAAcAAIAA AAAADwDQBz0MAAAfABQEHAAAAAAAFQQUAAAA0BjNBADKmjtOtdw2AMqaOwECAAAPAPoDdwAAAAAA /gMDAAAAAQEAAAD9AzQAAABCAAAAZAAAAEIAAABk/f///wIFAAADBQAABAUAAAUFAAAGBQAABwUA AAgFAAAJBQAACgUAAAsFAAAMBQAADQUAAA4FAAAPBQAAEAUAABEFAAASBQAAEwUAABQFAAAVBQAA FgUAABcFAAAYBQAAGQUAABoFAAAbBQAAHAUAAB0FAAAeBQAAHwUAACAFAAAhBQAAIgUAACMFAAAk BQAAJQUAACYFAAAnBQAAKAUAACkFAAAqBQAAKwUAACwFAAAtBQAALgUAAC8FAAAwBQAAMQUAADIF AAAzBQAANAUAADUFAAA2BQAANwUAADgFAAA5BQAAOgUAADsFAAA8BQAAPQUAAD4FAAA/BQAAQAUA AEEFAABCBQAAQwUAAEQFAABFBQAARgUAAEcFAABIBQAASQUAAEoFAABLBQAATAUAAE0FAABOBQAA TwUAAFAFAABRBQAAUgUAAFMFAABUBQAAVQUAAFYFAABXBQAAWAUAAFkFAABaBQAAWwUAAFwFAABd BQAAXgUAAF8FAABgBQAAYQUAAGIFAABjBQAAZAUAAGUFAABmBQAAZwUAAGgFAABpBQAAagUAAGsF AABsBQAAbQUAAG4FAABvBQAAcAUAAHEFAAByBQAAcwUAAHQFAAB1BQAAdgUAAHcFAAB4BQAAeQUA AHoFAAB7BQAAfAUAAH0FAAB+BQAAgAUAAP3///8AAAAAAAAA/CWIFgiEEwB4OgswAAAAAAAAAADu /P//Cv///wAAEwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMIAAAAAQAAAAkC AAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAA AGQAAAACAAAANIQTAPz4CjBolhMAAAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTMgsAAA8AihNoAAAA AAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAA AAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAPAIoT+AgAAAAA ug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoA QQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABv AGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoA AQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB DwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAA AAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEPAIoTaAEAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNIAQAADwDW BzABAAAAALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwAwhBMA 6IITAHg6CzDoghMAAAAAAA8A1geAAAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGEiAAtw9EAAAAi1tTTwAA ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDW B4YABgIwALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA 6IITAHg6CzDoghMAAAAAAA8A1gcAAAYiAAANBAgAAABwtQAAcLUAAA8AihNKAAAAAAC6Dw4AAABf AF8AXwBQAFAAVAA5AAAAixMsAAAALwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAAAAMAAACoAwAA AwADAAIP//8/ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDwDxoLAAAA APMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD3kAAABPU1BGIEV4dGVu c2lvbnMgaW4gU3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5n dGggQXNzaWdubWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgAACh DyYAAAB6AAAAAAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAAqg8yAAAARQAAAAYA AAAJBAkEAQAAAAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAUAAAAA AKgPnwAAAENDQU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0cmljaHQsIE5ldGhlcmxhbmRzIA0NZHJh ZnQtYWdyYXotY2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9zcGYtMDAudHh0DQ1GZXJuYW5kbyBBZ3Jh eiAoYWdyYXpAdHNjLnVwYy5lZHUpDVlhYmluIFllICh5YWJpbi55ZUBodWF3ZWkuY29tKQAAoQ8+ AAAAoAAAAAAAABAAAHgALwAAAAAABgASAAAAAAUuAAAAAAACABgAAQAAAAEABgABABIAAAD//kIA AAAAAAIAEgAAAKoPPgAAABUAAAAGAAAACQQECBgAAAAGAAAACQQECDAAAAAGAAAACQQECAEAAAAG AAAACQgECEIAAAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhYCzAAAN8P CAAAABUAAAAtAAAAAADzAxQAAABTAAAABAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8P AAAAQWNrbm93bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAkAAAAqg8aAAAADwAA AAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkE AADzAxQAAABWAAAABAAAAAEAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAQmFja2dyb3Vu ZAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAA AAAECAkEAADzAxQAAABoAAAABAAAAAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAT2Jq ZWN0aXZlIAAAoQ8cAAAACwAAAAAAAAAAAAkAAAAAAAIAJAACAAAAAAAAAAAAqg8aAAAACgAAAAYA AAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADz AxQAAABiAAAABAAAAAIAAAAZAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8MAAAATmV3IFBMSSBUTFYg AAChDxwAAAANAAAAAAAAAAAACwAAAAAAAgAkAAIAAAAAAAAAAACqDzIAAAADAAAABgAAAAkEBAgI AAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAA AQAAAAcAAAAAAAQICQQAAPMDFAAAAFcAAAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAAAAAAAACo DyAAAABUaGUgY29tcG9zaXRpb24gb2YgTGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8A AAAAAAIAJAACAAAAAAAAAAAAqg8mAAAAHwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAA AAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAABAAAAAIA AAAaAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5vZGUgUExJ IFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMAAAAGAAAA CQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACf DwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAAGwEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPHgAAAFNvbWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExWcwAAoQ8U AAAAHwAAAAAAAAAAAB8AAAAAAAIAJAAAAKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAAAwAJBAkE AQAAAAcAAAADAAkEBAgNAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAECAkEEACf DwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAAHAEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsgUExJIFRM VgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEAAAAHAAAA AAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAAAAQAAAAC AAAAHQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIE5v ZGUgUExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAGAAAACQQJ BAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4A AAABAAAABwAAAAAABAgJBAAA8wMUAAAAZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPGwAAAEFuIEV4YW1wbGUgb2YgY29tcG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAAABwAAAAA AAIAJAAAAKoPDAAAABwAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQAAPMDFAAAAEQAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABOZXh0IFN0 ZXBzAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQIEACfDwQA AAABAAAAAACoD6oAAABSZWZpbmUgaXQgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBmcm9tIHRo ZSBtZWV0aW5nIG9yIG1haWxpbmcgbGlzdA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1UIGRlZmlu ZWQgdGhlIHN0YW5kYXJkIGltcGFpcm1lbnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJlIGFsd2F5 cyBhcHByZWNpYXRlZAAAoQ8yAAAAiwAAAAAAAAAAACAAAAAAAAAgAAAyABsAAAAAAGEACwAAAAsA kAAAAAAEQQAABAsACwAAAKoPGgAAAKoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAA APMDFAAAAAYAAAAAAAAAAAAAAAABAAAAAAAAAADzAxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA 6gMAAAAADwDuA0MGAAACAO8DGAAAAAEAAAANDgAAAAAAAAcAAIAAAAAABwALMA8ADARaBQAADwAC 8FIFAACACAjwCAAAAAMAAAADCAQADwAD8OoEAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAA AAAAAAIACvAIAAAAAAgEAAUAAAAPAATweAAAABIACvAIAAAAAggEACACAABjAAvwJAAAAH8AAAAE AIAAlK6JFr8BAAABAP8BAAABAAEDAgADAIgDAAAAAAAAEPAIAAAAdwAgAWAVlwIPABHwEAAAAAAA wwsIAAAAAAAAAA0AiRYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPAyBAAAEgAK8AgAAAADCAQAAAoA APMAC/BaAAAAfwAAAAQAgAAA84kWgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAI gwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/ AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPIC ZAIsFdoKDwAN8GoDAAAAAJ8PBAAAAAQAAAAAAKAPRgIAAFMAaABvAHcAIAB0AGgAZQAgAHIAZQBz AHUAbAB0ACAAbwBmACAAIAAcIFAAcgBvAHQAbwBjAG8AbAAgAGUAeAB0AGUAbgBzAGkAbwBuAHMA IAB0AG8AIABlAG4AYQBiAGwAZQAgAGEAbgAgAEkAbQBwAGEAaQByAG0AZQBuAHQAIABBAHcAYQBy AGUALQBjAG8AbgB0AHIAbwBsACAAcABsAGEAbgBlAB0gIABpAG4AIABEAEkAQwBPAE4ARQBUACAA cAByAG8AagBlAGMAdAAgAGEAbgBkACAAcAByAG8AdgBpAGQAZQAgAGEAbgAgAGkAbgBwAHUAdAAg AGYAbwByACAAQwBDAEEATQBQACAAaQBuACAASQBFAFQARgANAEwAaQBuAGsAIABQAEwASQAgAFQA TABWAA0ARABlAHMAYwByAGkAYgBlAHMAIAB0AGgAZQAgAHAAaAB5AHMAaQBjAGEAbAAgAGwAYQB5 AGUAcgAgAGkAbQBwAGEAaQByAG0AZQBuAHQAcwAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIAB0AGgA ZQAgAGwAaQBuAGsADQBOAG8AZABlACAAUABMAEkAIABUAEwAVgANAEQAZQBzAGMAcgBpAGIAZQBz ACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwAIABsAGEAeQBlAHIAIABpAG0AcABhAGkAcgBtAGUA bgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABvACAAdABoAGUAIABuAG8AZABlAAAAoQ+YAAAAnQAA AAAAszAKAAMA2AAGAAAAAAGCABQABwA9AAAAAQAxMAoAAQAGAAAAAAGCABQABwANAAAAAACzMAoA AwDYAAYAAAAAAYIAFAAHAD0AAAABADEwCgABAAYAAAAAAYIAFAAHAJ0AAAAAACIACAAUAD0AAAAA ACIACAAUAA0AAAAABCIAAAQIABQAPQAAAAAIIgAACAgAFAAAAKoPWAAAABUAAAAGAAAACQQECD8A AAAGAAAACQgAABUAAAAGAAAACQgECAMAAAAHAAAAAAAJBAQIEgAAAAYAAAAJBAQIAwAAAAcAAAAA AAkEBAijAAAABgAAAAkEBAgAAKYPCAAAAAkAAAD5AW8ADwAE8EgAAAASAArwCAAAAAEIBAAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oBkDd4gQAAACsEAAAAAAAA AB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAiRb/////EgAAAA8APfENAAAA QAFC8QUAAAABCQAAAA8AAisAAAAAAAByFxAAAAABABAASNgCAGgAEACDBwMAAAD1DxwAAAAfAQAA pBkAAyTYAgDODQMAAQAAAGgAAAABAMUxDwDoAzMvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAF AAAACgAAAAUAAABFAAAAAQAAAAAAAAEPAPIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5AD AAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMT AHg6CzDwgxMAAAAAAA8A1QcAAAYiEAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEA bgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUAdABp AGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVBwAA BCIwALcPRAAAANGeU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAAT AHg6CzDwgxMAAAAAAA8A1QeGAAYCQAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwA VAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEIlAAtw9EAAAATlOHZcZ+0Z4A AGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVB4YA BgJgALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAA AHg6CzDwgxMAAAAAAA8A1QcCAAYCcAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwA VAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGIoAAtw9EAAAAi1tTTwAAdABp AGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAADwDVB4YA BgKQALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAA AHg6CzDwgxMAAAAAAA8A1QcAAAQUoAC3D0QAAABUAGkAbQBlAHMAAABlAHIATgBlAHgAdAAgAEwA VAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEJLAAtw9EAAAAVABpAG0AZQBz ACAATgBlAHcAIABSAG8AbQBhAG4AAABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAA BhIAAKQPDAAAAIAAYgAAAAgAAAAUAAAApQ8aAAAAAACzqC4AAwD8AAYAAAAAAQEAMgD5AQcAAAAA AKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEAC AAAAAAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUA AGADYAMAAAAAAAUAAIAEgAQAAAAADwALBB4SAAAPAADwFhIAAAAABvAgCAAABAgEAAMBAABFAQAA FQAAAAAAAAAPAAAAAgAAAD8AAAALAAAACAAAAAwAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAAAAAT AAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQA AAAAAAAABwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAA AAAAAAAJAAAAAAAAAAkAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAACAAAACSAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAC0A AABDAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAA AAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAAAAAAAEIAAAAAAAAA GQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAAPwAAAAkAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAGAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAA AAAABAAAAAAAAAAEAAAATwAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAA AABAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAE AAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABZAAAABwAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAAAAAAD8AAAA AAAAAC8AAABiAAAABAAAAGMAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAABrAAAABAAAAAAAAAAmAAAAAAAAACUAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAcAAABxAAAACAAAAAAAAAC1AAAAAAAAAAYAAAB0AAAA+wEAAHUAAABeAAAAAAAA AAgAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAPIAAAAAAAAA4wAAAAAAAABdAAAAAAAAAKwAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAACAAAAAAAAAAEAAAAfAAAAAQAAAB9AAAAQQAAAH4AAABxAQAAAAAAAAYAAAAAAAAABgAA AIEAAAAABAAAAAAAAAYAAACBAAAA6gIAAIMAAAC9AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAA hwAAABoAAACIAAAABAAAAJ8AAfCMAQAAYgAH8CQAAAAGBgWLNR+9x/hapvOnUBtimEv/ANMqAAAB AAAAAAAAAAAAAABSAAfwJAAAAAUF2PPjBALpLtjj7XCYyT0iFf8ATrYAAAEAAADTKgAAAAAAAFIA B/AkAAAABQVuXl4RjS68ttrj/Ic/k8hg/wAGVwAAAQAAACHhAAAAAAAAYgAH8CQAAAAGBisdnFFB lozbe/74GKTQUnn/AKszAAABAAAAJzgBAAAAAABiAAfwJAAAAAYGPOoZaAGlT1bU1/i7k1DQSf8A 0RUAAAEAAADSawEAAAAAAGIAB/AkAAAABga46WhyF/YLXPj81GTsgmm2/wC8VgUAAQAAAKOBAQAA AAAAMgAH8CQAAAADBO7btXNqQKC6d3ZzLnFDthX/AEkCAAABAAAAX9gGAAAAAAAyAAfwJAAAAAME QOvptYDGQz8Z0JsMOdBLJP8AnQIAAAEAAACo2gYAAAAAADIAB/AkAAAAAwSqrbsIEBgFJFUCqAz3 dvkF/wBLAgAAAQAAAEXdBgAAAAAAAwgL8AADAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIA AACHAAEAAACIAAAAAACJAAAAAAC/AAIADwAMAfQAABANAQAAACAOAQAAACCAAQAAAACBAQQAAAiC AQAAAQCDAQAAAAiEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAA AACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACV AQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDAAQEA AAjBAQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADK AQAAAADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIA AAgCAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAAL AgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAA AQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADB AgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1 AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADU AgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gp AQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAABz DSLxCgUAAIwAAQAAAI0AMGUBAH8BAABAAJ4B/////58B/////6ABAAAAIKHBAAAAAKIB/////6MB /////6QBAAAAIKXBAAAAAKYB/////6cB/////78BAAAgANkB/////9oB/////9sBAAAAINzBAAAA AN0B/////94B/////98BAAAAIODBAAAAAOEB/////+IB//////8BAADAABIC/////xMC/////xQC AAAAIBXCAAAAABYC/////xcC/////xgCAAAAIBnCAAAAABoC/////xsC/////4kC/////4oC//// /4sCAAAAIIzCAAAAAI0C/////48DAAAAAJADAgAAAJEDAAAAAJIDAgAAAL8DAIIAgkAFAAAAAEEF AAABAEIF////AEMFAAAAIEQFAAAAAEVFAAAAAEbFAAAAAEcFAAAAAEgFAAAAAEkFAAAAAEoFAAAA AEsFNSUAAEwFAAAIAE0FAAAAAE4FAAAAAE/FAAAAAFAFAAAAAFEFAAAAAFIFAQAAAFMFAQAAAFQF AQAAAFUFAQAAAFcFAgAAAFkF/////1oF/////1sFAAAAIFzFAAAAAF0F/////14F/////18FAAAA IGDFAAAAAGEF/////2IF/////38FBgBOAIAFAAAAAIEFAAABAIIF////AIMFAAAAIIQFAAAAAIVF AAAAAIbFAAAAAIcFAAAAAIgFAAAAAIkFAAAAAIoFAAAAAIsFNSUAAIwFAAAIAI0FAAAAAI4FAAAA AI/FAAAAAJAFAAAAAJEFAAAAAJIFAQAAAJMFAQAAAJQFAQAAAJUFAQAAAJcFAgAAAJkF/////5oF /////5sFAAAAIJzFAAAAAJ0F/////54F/////58FAAAAIKDFAAAAAKEF/////6IF/////78FBgBO AMAFAAAAAMEFAAABAMIF////AMMFAAAAIMQFAAAAAMVFAAAAAMbFAAAAAMcFAAAAAMgFAAAAAMkF AAAAAMoFAAAAAMsFNSUAAMwFAAAIAM0FAAAAAM4FAAAAAM/FAAAAANAFAAAAANEFAAAAANIFAQAA ANMFAQAAANQFAQAAANUFAQAAANcFAgAAANkF/////9oF/////9sFAAAAINzFAAAAAN0F/////94F /////98FAAAAIODFAAAAAOEF/////+IF//////8FBgBOAAAGAAAAAAEGAAABAAIG////AAMGAAAA IAQGAAAAAAVGAAAAAAbGAAAAAAcGAAAAAAgGAAAAAAkGAAAAAAoGAAAAAAsGNSUAAAwGAAAIAA0G AAAAAA4GAAAAAA/GAAAAABAGAAAAABEGAAAAABIGAQAAABMGAQAAABQGAQAAABUGAQAAABcGAgAA ABkG/////xoG/////xsGAAAAIBzGAAAAAB0G/////x4G/////x8GAAAAICDGAAAAACEG/////yIG /////z8GBgBOAEAGAAAAAEEGAAABAEIG////AEMGAAAAIEQGAAAAAEVGAAAAAEbGAAAAAEcGAAAA AEgGAAAAAEkGAAAAAEoGAAAAAEsGNSUAAEwGAAAIAE0GAAAAAE4GAAAAAE/GAAAAAFAGAAAAAFEG AAAAAFIGAQAAAFMGAQAAAFQGAQAAAFUGAQAAAFcGAgAAAFkG/////1oG/////1sGAAAAIFzGAAAA AF0G/////14G/////18GAAAAIGDGAAAAAGEG/////2IG/////38GBgAOAIAAGvEgAAAA/wAAAN3d 3QDq6uoA//9mAP+ZAAAAAP8AAJnMAABmmQBAAB7xEAAAAAQAAAj/mQAAAAAAAPcAABAfAPAPjAAA AAAA8wMUAAAAHwAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAACYAAAAEAAAAAAAAAAIAAIAAAAAA AADzAxQAAAAzAAAABAAAAAAAAAAGAACAAAAAAAAA8wMUAAAAMQAAAAQAAAAAAAAABAAAgAAAAAAA APMDFAAAADwAAAAAAAAAAAAAAAcAAIAAAAAADwDQBz0MAAAfABQEHAAAAAAAFQQUAAAA0BjNBADK mjtOtdw2AMqaOwECAAAPAPoDdwAAAAAA/gMDAAAAAQEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAA AAAAAPwliBYIhBMAeDoLMAAAAAAAAAAA7vz//wr///8AABMAcAD7AwgAAAAAAAAAPAIAAHAA+wMI AAAAAAAAABwOAABwAPsDCAAAAAEAAAAJAgAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8A EwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAAgAAADSEEwD8+AowaJYTAAAAAAAAAAAAAAAA AAAAAAAAARMADwCIEzILAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsT RAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAACI 2QAAAAAAAAAAAACAAgHgDwCKE/gIAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT 0ggAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAA AQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAED AAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAA AAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5 AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEA AAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAI AAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAA AAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBp AGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIA YQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAI DAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAA AAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAA AAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAA CAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIA AAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAA AAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAA aG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAAD AAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQA GAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAA ABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAA AQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABg AAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYA TQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAA FAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAAB AAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAA AAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBN AG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAA BgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBAAgAAEACvDwgAAAAAAQAABQAAAAAAGRAoAgAA AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAA AAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAA AAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAAB BQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAA AAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYA AAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwCKE2gBAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTSAEAAA8A1gcwAQAAAAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBj AAAAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHgAAGIhAAtw9EAAAA VABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAA AAAADwDWBwAABhIgALcPRAAAAItbU08AAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiW EwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1geGAAYCMAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAg AFIAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGIgAADQQIAAAA cLUAAHC1AAAPAIoTSgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTLAAAAC8AyA8MAAAAMADS DwQAAAAAAAAAAAB7FxAAAAADAAAAqAMAAAMAAwACD///PwDZDwwAAAAAANoPBAAAAAAAIwBPANkP DAAAAAAA2g8EAAAADQA9AA8A8A8aCwAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8E AAAABgAAAAAAqA95AAAAT1NQRiBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW1wYWlybWVudCBB d2FyZSBSb3V0aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQgaW4gV2F2ZWxlbmd0aCBTd2l0 Y2hlZCBPcHRpY2FsIE5ldHdvcmtzIAAAoQ8mAAAAegAAAAAAAAAAAHgAAAAAAAIAHAABAAAAAAAA AAEAAAAAAAIAKAAAAKoPMgAAAEUAAAAGAAAACQQJBAEAAAAGAAAACQQECDMAAAAGAAAACQQJBAEA AAAHAAAAAAAECAkEEACfDwQAAAAFAAAAAACoD58AAABDQ0FNUCBXRywgSUVURiA3OHRoLCBNYWFz dHJpY2h0LCBOZXRoZXJsYW5kcyANDWRyYWZ0LWFncmF6LWNjYW1wLXdzb24taW1wYWlybWVudC1v c3BmLTAwLnR4dA0NRmVybmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMuZWR1KQ1ZYWJpbiBZZSAo eWFiaW4ueWVAaHVhd2VpLmNvbSkAAKEPPgAAAKAAAAAAAAAQAAB4AC8AAAAAAAYAEgAAAAAFLgAA AAAAAgAYAAEAAAABAAYAAQASAAAA//5CAAAAAAACABIAAACqDz4AAAAVAAAABgAAAAkEBAgYAAAA BgAAAAkEBAgwAAAABgAAAAkEBAgBAAAABgAAAAkIBAhCAAAABwAAAAAADAQECA8A8g8YAAAAAADz DxAAAAAAAAAAAAAAAAAAAAAIWAswAADfDwgAAAAVAAAALQAAAAAA8wMUAAAAUwAAAAQAAAACAAAA DgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAEFja25vd2xlZGdtZW50cwAAoQ8UAAAAEAAAAAAA AAAAABAAAAAAAAIAJAAAAKoPGgAAAA8AAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAAB AAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVgAAAAQAAAABAAAAEQEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQAAACq DxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAA8wMUAAAAaAAAAAQAAAACAAAAHwEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE9iamVjdGl2ZSAAAKEPHAAAAAsAAAAAAAAAAAAJAAAAAAAC ACQAAgAAAAAAAAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYgAAAAQAAAACAAAAGQEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPDAAAAE5ldyBQTEkgVExWIAAAoQ8cAAAADQAAAAAAAAAAAAsAAAAAAAIAJAACAAAA AAAAAAAAqg8yAAAAAwAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAA AAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABXAAAABAAAAAIA AAASAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExpbmsgUExJ IFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAAAB8AAAAGAAAA CQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAYwAAAAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRo ZSBjb21wb3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAk AAIAAAAAAAAAAACqDz4AAAATAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAA BgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQA APMDFAAAAGQAAAAEAAAAAgAAABsBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABTb21lIHN1Yi1U TFZzIGFuZCBzdWItc3ViLVRMVnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQAAACqD1AAAAAJ AAAABgAAAAkEBAgDAAAABwAAAAMACQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQIBAAAAAcA AAADAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQA APMDFAAAAGUAAAAEAAAAAgAAABwBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIg VHlwZXMgZm9yIHRoZSBMaW5rIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACq DxoAAAAkAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAGYAAAAEAAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQ YXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAA AAACACQAAACqDzIAAAAYAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABwAA AAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcAAAAEAAAA AgAAAB4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBU TFYAAKEPFAAAABwAAAAAAAAAAAAcAAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8KAAAATmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAA AKoPDAAAAAsAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFjY29yZGlu ZyB0byB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QNS2VlcCB1 cGdyYWRpbmcgd2hlbiBJVFUtVCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50IGluZm9y bWF0aW9uDUNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEPMgAAAIsAAAAAAAAAAAAg AAAAAAAAIAAAMgAbAAAAAABhAAsAAAALAJAAAAAABEEAAAQLAAsAAACqDxoAAACqAAAABgAAAAkE BAgBAAAABwAAAAAABAgJBC8A8A84AAAAAADzAxQAAAAGAAAAAAAAAAAAAAAAAQAAAAAAAAAA8wMU AAAATQAAAAAAAAAAAAAACAEAAAAAAAAAAOoDAAAAAA8A7gMLBQAAAgDvAxgAAAABAAAADQ4AAAAA AAAHAACAAAAAAAcACzAPAAwEIgQAAA8AAvAaBAAAgAgI8AgAAAADAAAAAwgEAA8AA/CyAwAADwAE 8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIBAAFAAAADwAE8HgAAAASAArw CAAAAAIIBAAgAgAAYwAL8CQAAAB/AAAABACAAJSuiRa/AQAAAQD/AQAAAQABAwIAAwCIAwAAAAAA ABDwCAAAAHcAIAFgFZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAIkWDwAN8AwAAAAAAJ4PBAAAAAAA AAAPAATw+gIAABIACvAIAAAAAwgEAAAKAADzAAvwWgAAAH8AAAAEAIAAAPOJFoEAYDUBAIIAsJoA AIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8C AAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUG AE4APwYGAE4AfwYGAA4AAAAQ8AgAAADyAmQCLBXaCg8ADfAyAgAAAACfDwQAAAAEAAAAAACgD44B AABCAGEAcwBlAGQAIABvAG4AIAB0AGgAZQAgAHIAZQBzAHUAbAB0ACAAbwBmACAAIAAcIFAAcgBv AHQAbwBjAG8AbAAgAGUAeAB0AGUAbgBzAGkAbwBuAHMAIAB0AG8AIABlAG4AYQBiAGwAZQAgAGEA bgAgAEkAbQBwAGEAaQByAG0AZQBuAHQAIABBAHcAYQByAGUALQBjAG8AbgB0AHIAbwBsACAAcABs AGEAbgBlAB0gIABpAG4AIABEAEkAQwBPAE4ARQBUACAAcAByAG8AagBlAGMAdAANAEQAZQBmAGkA bgBlACAAZQB4AHQAZQBuAHMAaQBvAG4AcwAgAHQAbwAgAHQAaABlACAATwBTAFAARgAgAHIAbwB1 AHQAaQBuAGcAIABwAHIAbwB0AG8AYwBvAGwAIABpAG4AIABzAHUAcABwAG8AcgB0ACAAbwBmACAA aQBtAHAAYQBpAHIAbQBlAG4AdAAgAGEAdwBhAHIAZQAgAFIAVwBBACAAaQBuACAAVwBTAE8ATgBz AAAAoQ8mAAAAyAAAAAAAszAKAAMA2AAGAAAAAAGCABQABwDIAAAAAAAiAAgAFAAAAKoPSgAAABkA AAAGAAAACQQECD8AAAAGAAAACQgAABQAAAAGAAAACQgECD4AAAAGAAAACQQECB0AAAAHAAAAAAAJ BAQIAQAAAAYAAAAJBAQIAACmDwgAAAAJAAAA+QFvAA8ABPBIAAAAEgAK8AgAAAABCAQAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAZA3eIEAAAArBAAAAAAAAAAf AETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAIkW/////xIAAAAPAD3xDQAAAEAB QvEFAAAAAQkAAAAPAAIrAAAAAAAAchcQAAAAAQAQAAoOAwBoABAART0DAAAA9Q8cAAAAHwEAAKQZ AAPmDQMAWEIDAAEAAABoAAAAAQDFMQ8A6AN0LwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAA AAoAAAAFAAAARQAAAAEAAAAAAAABDwDyA2oEAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QeQAwAA AAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMA5ISIFvCDEwB4 Ogsw8IMTAAAAAAAPANUHAAAGIhAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4A AABolhMAaJYTAOSEiBbwgxMAeDoLMPCDEwAAAAAADwDVB4AABiIgALcPRAAAAEYAcgB1AHQAaQBn AGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QcAAAQi MAC3D0QAAADRnlNPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4 Ogsw8IMTAAAAAAAPANUHhgAGAkAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQA IABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVBwAABCJQALcPRAAAAE5Th2XGftGeAABn AGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QeGAAYC YAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4 Ogsw8IMTAAAAAAAPANUHAgAGAnAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQA IABMAGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABiKAALcPRAAAAItbU08AAHQAaQBn AGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDwgxMAAAAAAA8A1QeGAAYC kAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4 Ogsw8IMTAAAAAAAPANUHAAAEFKAAtw9EAAAAVABpAG0AZQBzAAAAZQByAE4AZQB4AHQAIABMAFQA IABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABCSwALcPRAAAAFQAaQBtAGUAcwAg AE4AZQB3ACAAUgBvAG0AYQBuAAAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAYS AACkDwwAAACAAGIAAAAIAAAAFAAAAKUPGgAAAAAAs6guAAMA/AAGAAAAAAEBADIA+QEHAAAAAACp DwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAA AAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABg A2ADAAAAAAAFAACABIAEAAAAAA8ACwQeEgAADwAA8BYSAAAAAAbwIAgAAAQIBAADAQAARQEAABUA AAAAAAAADwAAAAIAAAA/AAAACwAAAAgAAAAMAAAABAAAAAAAAAAQAAAAAAAAAAQAAAAAAAAAEwAA AAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAANAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAA AAAAAAcAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAA AAAACQAAAAAAAAAJAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAgAAAAkgAAAAAA AAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAFAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYAAAAtAAAA QwAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAG AAAAAAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAAAAAABCAAAAAAAAABkA AAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABAAAAD8AAAAJAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABgAAAAAAAAANAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAA AAQAAAAAAAAABAAAAE8AAAAMAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAkAAAAAAAAA QAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAMAAAAAAAAABAAA AAAAAAADAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAWQAAAAcAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAQAAAAAAAAA/AAAAAAA AAAvAAAAYgAAAAQAAABjAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAawAAAAQAAAAAAAAAJgAAAAAAAAAlAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAHAAAAcQAAAAgAAAAAAAAAtQAAAAAAAAAGAAAAdAAAAPsBAAB1AAAAXgAAAAAAAAAI AAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAADyAAAAAAAAAOMAAAAAAAAAXQAAAAAAAACsAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAgAAAAAAAAABAAAAHwAAAAEAAAAfQAAAEEAAAB+AAAAcQEAAAAAAAAGAAAAAAAAAAYAAACB AAAAAAQAAAAAAAAGAAAAgQAAAOoCAACDAAAAvQAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAIcA AAAaAAAAiAAAAAQAAACfAAHwjAEAAGIAB/AkAAAABgYFizUfvcf4Wqbzp1AbYphL/wDTKgAAAQAA AAAAAAAAAAAAUgAH8CQAAAAFBdjz4wQC6S7Y4+1wmMk9IhX/AE62AAABAAAA0yoAAAAAAABSAAfw JAAAAAUFbl5eEY0uvLba4/yHP5PIYP8ABlcAAAEAAAAh4QAAAAAAAGIAB/AkAAAABgYrHZxRQZaM 23v++Bik0FJ5/wCrMwAAAQAAACc4AQAAAAAAYgAH8CQAAAAGBjzqGWgBpU9W1Nf4u5NQ0En/ANEV AAABAAAA0msBAAAAAABiAAfwJAAAAAYGuOlochf2C1z4/NRk7IJptv8AvFYFAAEAAACjgQEAAAAA ADIAB/AkAAAAAwTu27VzakCgund2cy5xQ7YV/wBJAgAAAQAAAF/YBgAAAAAAMgAH8CQAAAADBEDr 6bWAxkM/GdCbDDnQSyT/AJ0CAAABAAAAqNoGAAAAAAAyAAfwJAAAAAMEqq27CBAYBSRVAqgM93b5 Bf8ASwIAAAEAAABF3QYAAAAAAAMIC/AAAwAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAA hwABAAAAiAAAAAAAiQAAAAAAvwACAA8ADAH0AAAQDQEAAAAgDgEAAAAggAEAAAAAgQEEAAAIggEA AAEAgwEAAAAIhAEAAAEAhQEAAAAghkEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAA jAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEA AAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEMAB4AwAEBAAAI wQEAAAEAwgH///8AwwEAAAAgxAEAAAAAxUEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEA AAAAywE1JQAAzAEAAAgAzQEAAAAAzgEAAAAAz8EAAAAA1wECAAAA/wEOAA4AAAIAAAAAAQICAAAI AgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIA AAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEA ggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIA AAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAA ywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIA AAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEA QgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAcw0i 8QoFAACMAAEAAACNADBlAQB/AQAAQACeAf////+fAf////+gAQAAACChwQAAAACiAf////+jAf// //+kAQAAACClwQAAAACmAf////+nAf////+/AQAAIADZAf/////aAf/////bAQAAACDcwQAAAADd Af/////eAf/////fAQAAACDgwQAAAADhAf/////iAf//////AQAAwAASAv////8TAv////8UAgAA ACAVwgAAAAAWAv////8XAv////8YAgAAACAZwgAAAAAaAv////8bAv////+JAv////+KAv////+L AgAAACCMwgAAAACNAv////+PAwAAAACQAwIAAACRAwAAAACSAwIAAAC/AwCCAIJABQAAAABBBQAA AQBCBf///wBDBQAAACBEBQAAAABFRQAAAABGxQAAAABHBQAAAABIBQAAAABJBQAAAABKBQAAAABL BTUlAABMBQAACABNBQAAAABOBQAAAABPxQAAAABQBQAAAABRBQAAAABSBQEAAABTBQEAAABUBQEA AABVBQEAAABXBQIAAABZBf////9aBf////9bBQAAACBcxQAAAABdBf////9eBf////9fBQAAACBg xQAAAABhBf////9iBf////9/BQYATgCABQAAAACBBQAAAQCCBf///wCDBQAAACCEBQAAAACFRQAA AACGxQAAAACHBQAAAACIBQAAAACJBQAAAACKBQAAAACLBTUlAACMBQAACACNBQAAAACOBQAAAACP xQAAAACQBQAAAACRBQAAAACSBQEAAACTBQEAAACUBQEAAACVBQEAAACXBQIAAACZBf////+aBf// //+bBQAAACCcxQAAAACdBf////+eBf////+fBQAAACCgxQAAAAChBf////+iBf////+/BQYATgDA BQAAAADBBQAAAQDCBf///wDDBQAAACDEBQAAAADFRQAAAADGxQAAAADHBQAAAADIBQAAAADJBQAA AADKBQAAAADLBTUlAADMBQAACADNBQAAAADOBQAAAADPxQAAAADQBQAAAADRBQAAAADSBQEAAADT BQEAAADUBQEAAADVBQEAAADXBQIAAADZBf/////aBf/////bBQAAACDcxQAAAADdBf/////eBf// ///fBQAAACDgxQAAAADhBf/////iBf//////BQYATgAABgAAAAABBgAAAQACBv///wADBgAAACAE BgAAAAAFRgAAAAAGxgAAAAAHBgAAAAAIBgAAAAAJBgAAAAAKBgAAAAALBjUlAAAMBgAACAANBgAA AAAOBgAAAAAPxgAAAAAQBgAAAAARBgAAAAASBgEAAAATBgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZ Bv////8aBv////8bBgAAACAcxgAAAAAdBv////8eBv////8fBgAAACAgxgAAAAAhBv////8iBv// //8/BgYATgBABgAAAABBBgAAAQBCBv///wBDBgAAACBEBgAAAABFRgAAAABGxgAAAABHBgAAAABI BgAAAABJBgAAAABKBgAAAABLBjUlAABMBgAACABNBgAAAABOBgAAAABPxgAAAABQBgAAAABRBgAA AABSBgEAAABTBgEAAABUBgEAAABVBgEAAABXBgIAAABZBv////9aBv////9bBgAAACBcxgAAAABd Bv////9eBv////9fBgAAACBgxgAAAABhBv////9iBv////9/BgYADgCAABrxIAAAAP8AAADd3d0A 6urqAP//ZgD/mQAAAAD/AACZzAAAZpkAQAAe8RAAAAAEAAAI/5kAAAAAAAD3AAAQHwDwD4wAAAAA APMDFAAAAB8AAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAmAAAABAAAAAAAAAACAACAAAAAAAAA 8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMDFAAAADEAAAAEAAAAAAAAAAQAAIAAAAAAAADz AxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ac9DAAAHwAUBBwAAAAAABUEFAAAANAYzQQAypo7 TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEBAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAAA AAD8JYgWCIQTAHg6CzAAAAAAAAAAAO78//8K////AAATAHAA+wMIAAAAAAAAADwCAABwAPsDCAAA AAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABME PAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAA0hBMA/PgKMGiWEwAAAAAAAAAAAAAAAAAA AAAAAAETAA8AiBMyCwAADwCKE2gAAAAAALoPFAAAAF8AXwBfAFAAUABUADIAMAAwADEAAACLE0QA AAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAAAAAAiNkA AAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABfAF8AXwBQAFAAVABNAGEAYwAxADEAAACLE9II AABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAA CgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBw AG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAA GgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAA AAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAAB BAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBh AGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEA cABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwB AAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAAB AAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAA AAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgA AAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAA AQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAAB DAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAA AAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhu YW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAA AAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgA AAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAU AAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEA AAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAA AAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0A bwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAG AAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQBAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIAABAArw8IAAAAAAEAAAUAAAAAABkQKAIAAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AihNoAQAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAA AG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWB4AABiIQALcPRAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAA AA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMA MIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHhgAGAjAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABS AG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWBwAABiIAAA0ECAAAAHC1 AABwtQAADwCKE0oAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLEywAAAAvAMgPDAAAADAA0g8E AAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg///z8A2Q8MAAAAAADaDwQAAAAAACMATwDZDwwA AAAAANoPBAAAAA0APQAPAPAPWwsAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAA AAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEltcGFpcm1lbnQgQXdh cmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25tZW50IGluIFdhdmVsZW5ndGggU3dpdGNo ZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoAAAAAAAAAAAB4AAAAAAACABwAAQAAAAAAAAAB AAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQBAAAABgAAAAkEBAgzAAAABgAAAAkECQQBAAAA BwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAAQ0NBTVAgV0csIElFVEYgNzh0aCwgTWFhc3Ry aWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jhei1jY2FtcC13c29uLWltcGFpcm1lbnQtb3Nw Zi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3JhekB0c2MudXBjLmVkdSkNWWFiaW4gWWUgKHlh YmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAAAAAAEAAAeAAvAAAAAAAGABIAAAAABS4AAAAA AAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgASAAAAqg8+AAAAFQAAAAYAAAAJBAQIGAAAAAYA AAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQIQgAAAAcAAAAAAAwEBAgPAPIPGAAAAAAA8w8Q AAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAAAC0AAAAAAPMDFAAAAFMAAAAEAAAAAgAAAA4B AAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tub3dsZWRnbWVudHMAAKEPFAAAABAAAAAAAAAA AAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAA AAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFYAAAAEAAAAAQAAABEBAAAAAAAAAACfDwQA AAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8a AAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAPMDFAAAAGgAAAAEAAAAAgAAAB8BAAAAAAAA AACfDwQAAAAAAAAAAACoDwoAAABPYmplY3RpdmUgAAChDxwAAAALAAAAAAAAAAAACQAAAAAAAgAk AAIAAAAAAAAAAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAA qg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIAAAAEAAAAAgAAABkBAAAAAAAAAACfDwQAAAAA AAAAAACoDyUAAABPU1BGIHJvdXRpbmcgZm9yIElBLVJXQSAtTmV3IFBMSSBUTFYgAAChDyoAAAAm AAAAAAAAAAAAFwAAAAAAQwALAAsAJAANAAAAAAACACQAAgAAAAAAAAAAAKoPTAAAABEAAAAGAAAA CQgECAYAAAAHAAAAAAAJCAQIBQAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAA AAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABXAAAA BAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExp bmsgUExJIFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAAAB8A AAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAAB AAAABwAAAAAABAgJBAAA8wMUAAAAYwAAAAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP IAAAAFRoZSBjb21wb3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAA AAAAAgAkAAIAAAAAAAAAAACqDz4AAAATAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkE CQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAA AAQICQQAAPMDFAAAAGQAAAAEAAAAAgAAABsBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABTb21l IHN1Yi1UTFZzIGFuZCBzdWItc3ViLVRMVnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQAAACq D1AAAAAJAAAABgAAAAkEBAgDAAAABwAAAAMACQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQI BAAAAAcAAAADAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAA AAQICQQAAPMDFAAAAGUAAAAEAAAAAgAAABwBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJh bWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5rIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAAC ACQAAACqDxoAAAAkAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAA AQAAAAcAAAAAAAQICQQAAPMDFAAAAGYAAAAEAAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACo DyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAA AAAlAAAAAAACACQAAACqDzIAAAAYAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcA AAAEAAAAAgAAAB4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBv bmVudCBUTFYAAKEPFAAAABwAAAAAAAAAAAAcAAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQ AJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAATmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAA AAIAJAAAAKoPDAAAAAsAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFj Y29yZGluZyB0byB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QN S2VlcCB1cGdyYWRpbmcgd2hlbiBJVFUtVCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50 IGluZm9ybWF0aW9uDUNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEPMgAAAIsAAAAA AAAAAAAgAAAAAAAAIAAAMgAbAAAAAABhAAsAAAALAJAAAAAABEEAAAQLAAsAAACqDxoAAACqAAAA BgAAAAkEBAgBAAAABwAAAAAABAgJBC8A8A84AAAAAADzAxQAAAAGAAAAAAAAAAAAAAAAAQAAAAAA AAAA8wMUAAAATQAAAAAAAAAAAAAACAEAAAAAAAAAAOoDAAAAAA8A7gMLBQAAAgDvAxgAAAABAAAA DQ4AAAAAAAAHAACAAAAAAAcACzAPAAwEIgQAAA8AAvAaBAAAgAgI8AgAAAADAAAAAwgEAA8AA/Cy AwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIBAAFAAAADwAE8HgA AAASAArwCAAAAAIIBAAgAgAAYwAL8CQAAAB/AAAABACAAJSuiRa/AQAAAQD/AQAAAQABAwIAAwCI AwAAAAAAABDwCAAAAHcAIAFgFZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAIkWDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATw+gIAABIACvAIAAAAAwgEAAAKAADzAAvwWgAAAH8AAAAEAIAAAPOJFoEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADyAmQCLBXaCg8ADfAyAgAAAACfDwQAAAAEAAAA AACgD44BAABCAGEAcwBlAGQAIABvAG4AIAB0AGgAZQAgAHIAZQBzAHUAbAB0ACAAbwBmACAAIAAc IFAAcgBvAHQAbwBjAG8AbAAgAGUAeAB0AGUAbgBzAGkAbwBuAHMAIAB0AG8AIABlAG4AYQBiAGwA ZQAgAGEAbgAgAEkAbQBwAGEAaQByAG0AZQBuAHQAIABBAHcAYQByAGUALQBjAG8AbgB0AHIAbwBs ACAAcABsAGEAbgBlAB0gIABpAG4AIABEAEkAQwBPAE4ARQBUACAAcAByAG8AagBlAGMAdAANAEQA ZQBmAGkAbgBlACAAZQB4AHQAZQBuAHMAaQBvAG4AcwAgAHQAbwAgAHQAaABlACAATwBTAFAARgAg AHIAbwB1AHQAaQBuAGcAIABwAHIAbwB0AG8AYwBvAGwAIABpAG4AIABzAHUAcABwAG8AcgB0ACAA bwBmACAAaQBtAHAAYQBpAHIAbQBlAG4AdAAgAGEAdwBhAHIAZQAgAFIAVwBBACAAaQBuACAAVwBT AE8ATgBzAAAAoQ8mAAAAyAAAAAAAszAKAAMA2AAGAAAAAAGCABQABwDIAAAAAAAiAAgAHAAAAKoP SgAAABkAAAAGAAAACQQECD8AAAAGAAAACQgAABQAAAAGAAAACQgECFYAAAAGAAAACQQECAUAAAAH AAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwgAAAAJAAAA+QFvAA8ABPBIAAAAEgAK8AgAAAABCAQA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAZA3eIEAAAArBAAA AAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAIkW/////xIAAAAPAD3x DQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gPnBAAAAgDvAxgAAAABAAAADQ4AAAAAAAAHAACA AAAAAAcACzAPAAwE/gMAAA8AAvD2AwAAwAcI8AgAAAADAAAAA9QDAA8AA/COAwAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADUAwAFAAAADwAE8HgAAAASAArwCAAAAALU AwAgAgAAYwAL8CQAAAB/AAAABACAAMQlYRO/AQAAAQD/AQAAAQABAwIAAwCIAwAAAAAAABDwCAAA AHcAIAFgFZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAGETDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATw 1gIAABIACvAIAAAAA9QDAAAKAADzAAvwWgAAAH8AAAAEAIAAAIWvD4EAYDUBAIIAsJoAAIMAYDUB AIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAH8D AAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAQ8AgAAADyAmQCLBXaCg8ADfAOAgAAAACfDwQAAAAEAAAAAACoD+YAAABUd28g dG9wLVRMVnMgYXJlIGRlZmluZWQgdG8gZGVzY3JpYmUgUExJIChQaHlzaWNhbCBMYXllciBJbXBh aXJtZW50cykgaW5mb3JtYXRpb246DUxpbmsgUExJIFRMVg1EZXNjcmliZXMgdGhlIHBoeXNpY2Fs IGxheWVyIGltcGFpcm1lbnRzIHJlbGF0ZWQgdG8gdGhlIGxpbmsNTm9kZSBQTEkgVExWDURlc2Ny aWJlcyB0aGUgcGh5c2ljYWwgbGF5ZXIgaW1wYWlybWVudHMgcmVsYXRlZCB0byB0aGUgbm9kZQAA oQ/CAAAAUwAAAAAAsjAKAAIA2AAGAAAAAAGCABQABwANAAAAAACzMAoAAwDYAAYAAAAAAYIAFAAH AD0AAAABADEwCgABAAYAAAAAAYIAFAAHAA0AAAAAALMwCgADANgABgAAAAABggAUAAcAPQAAAAEA MTAKAAEABgAAAAABggAUAAcAUwAAAAAAIgAIABQADQAAAAAEIgAABAgAFAA9AAAAAAQiAAAECAAU AA0AAAAACCIAAAgIABQAPQAAAAAMIgAADAgAFAAAAKoPMgAAAAgAAAAGAAAACQgECAQAAAAHAAAA AwAJCAQIRwAAAAYAAAAJCAQIlAAAAAYAAAAJBAQIAACmDwgAAAAJAAAA+QFvAA8ABPBIAAAAEgAK 8AgAAAAB1AMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBOR AAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAZA3 eIEAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAIkW//// /xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchcYAAAAAQAQAJRCAwBiABAAI3cD AGgAEAAQcgMAAAD1DxwAAAAZAQAApBkAA3BCAwASfAMAAQAAAGgAAAABAMUxDwDoA2YvAAABAOkD KAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAABFAAAAAQAAAAAAAAEPAPIDagQAAC8AyA8M AAAAMADSDwQAAAAAAAAADwDVB5ADAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0A YQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A1QcAAAYiEAC3D0QAAABNAFMAIABQ AEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUH gAAGIiAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAA ABMAeDoLMPCDEwAAAAAADwDVBwAABCIwALcPRAAAANGeU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAA TABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QeGAAYCQAC3D0QAAABGAHIAdQB0 AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUH AAAEIlAAtw9EAAAATlOHZcZ+0Z4AAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQBy AAAAeDoLMPCDEwAAAAAADwDVB4YABgJgALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAeAB0ACAA TABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcCAAYCcAC3D0QAAABGAHIAdQB0 AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUH AAAGIoAAtw9EAAAAi1tTTwAAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAABy AAAAeDoLMPCDEwAAAAAADwDVB4YABgKQALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAA TABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQUoAC3D0QAAABUAGkAbQBl AHMAAABlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUH AAAEJLAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABCAG8AbABkAAAAAABy AAAAeDoLMPCDEwAAAAAADwDVBwAABhIAAKQPDAAAAIAAYgAAAAgAAAAUAAAApQ8aAAAAAACzqC4A AwD8AAYAAAAAAQEAMgD5AQcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAA AGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAAAUAACAB IAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBB4SAAAPAADwFhIA AAAABvAgCAAABAgEAAMBAABFAQAAFQAAAAAAAAAPAAAAAgAAAD8AAAALAAAACAAAAAwAAAAEAAAA AAAAABAAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAA0AAAAA AAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABQAAAAAAAAAFAAAAAAAA AAQAAAAAAAAAIQAAACAAAACSAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAUAAAAAAAAA BwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABwAAAAAAAAAH AAAAAAAAAAcAAAAAAAAABgAAAC0AAABDAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYA AAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAcAAAAAAAAABwAA AAAAAAAGAAAAAAAAAEIAAAAAAAAAGQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAA PwAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAATwAAAAwAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAACQAAAAAAAABAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAABZAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAsAAAAAAAAABAAAAAAAAAD8AAAAAAAAAC8AAABiAAAABAAAAGMAAAAGAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABrAAAABAAAAAAAAAAm AAAAAAAAACUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAABxAAAACAAAAAAAAAC1AAAAAAAAAAYA AAB0AAAA+wEAAHUAAABeAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAPIAAAAAAAAA4wAAAAAAAABdAAAA AAAAAKwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAfAAAAAQAAAB9AAAAQQAAAH4A AABxAQAAAAAAAAYAAAAAAAAABgAAAIEAAAAABAAAAAAAAAYAAACBAAAA6gIAAIMAAAC9AAAAAAAA AAYAAAAAAAAABgAAAAAAAAAEAAAAhwAAABoAAACIAAAABAAAAJ8AAfCMAQAAYgAH8CQAAAAGBgWL NR+9x/hapvOnUBtimEv/ANMqAAABAAAAAAAAAAAAAABSAAfwJAAAAAUF2PPjBALpLtjj7XCYyT0i Ff8ATrYAAAEAAADTKgAAAAAAAFIAB/AkAAAABQVuXl4RjS68ttrj/Ic/k8hg/wAGVwAAAQAAACHh AAAAAAAAYgAH8CQAAAAGBisdnFFBlozbe/74GKTQUnn/AKszAAABAAAAJzgBAAAAAABiAAfwJAAA AAYGPOoZaAGlT1bU1/i7k1DQSf8A0RUAAAEAAADSawEAAAAAAGIAB/AkAAAABga46WhyF/YLXPj8 1GTsgmm2/wC8VgUAAQAAAKOBAQAAAAAAMgAH8CQAAAADBO7btXNqQKC6d3ZzLnFDthX/AEkCAAAB AAAAX9gGAAAAAAAyAAfwJAAAAAMEQOvptYDGQz8Z0JsMOdBLJP8AnQIAAAEAAACo2gYAAAAAADIA B/AkAAAAAwSqrbsIEBgFJFUCqAz3dvkF/wBLAgAAAQAAAEXdBgAAAAAAAwgL8AADAACBAGA1AQCC ALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAACIAAAAAACJAAAAAAC/AAIADwAMAfQAABANAQAA ACAOAQAAACCAAQAAAACBAQQAAAiCAQAAAQCDAQAAAAiEAQAAAQCFAQAAACCGQQAAAACHwQAAAACI AQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAA AACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACb AQAAAACcAQMAAEC/AQwAHgDAAQEAAAjBAQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAA AADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADX AQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgCAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAA AAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAAR AgAAAAA/AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcA ABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADH AgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAA ef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADa AnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+ AQCFAwAAAACGA3y+AQCHAwAAAABzDSLxCgUAAIwAAQAAAI0AMGUBAH8BAABAAJ4B/////58B//// /6ABAAAAIKHBAAAAAKIB/////6MB/////6QBAAAAIKXBAAAAAKYB/////6cB/////78BAAAgANkB /////9oB/////9sBAAAAINzBAAAAAN0B/////94B/////98BAAAAIODBAAAAAOEB/////+IB//// //8BAADAABIC/////xMC/////xQCAAAAIBXCAAAAABYC/////xcC/////xgCAAAAIBnCAAAAABoC /////xsC/////4kC/////4oC/////4sCAAAAIIzCAAAAAI0C/////48DAAAAAJADAgAAAJEDAAAA AJIDAgAAAL8DAIIAgkAFAAAAAEEFAAABAEIF////AEMFAAAAIEQFAAAAAEVFAAAAAEbFAAAAAEcF AAAAAEgFAAAAAEkFAAAAAEoFAAAAAEsFNSUAAEwFAAAIAE0FAAAAAE4FAAAAAE/FAAAAAFAFAAAA AFEFAAAAAFIFAQAAAFMFAQAAAFQFAQAAAFUFAQAAAFcFAgAAAFkF/////1oF/////1sFAAAAIFzF AAAAAF0F/////14F/////18FAAAAIGDFAAAAAGEF/////2IF/////38FBgBOAIAFAAAAAIEFAAAB AIIF////AIMFAAAAIIQFAAAAAIVFAAAAAIbFAAAAAIcFAAAAAIgFAAAAAIkFAAAAAIoFAAAAAIsF NSUAAIwFAAAIAI0FAAAAAI4FAAAAAI/FAAAAAJAFAAAAAJEFAAAAAJIFAQAAAJMFAQAAAJQFAQAA AJUFAQAAAJcFAgAAAJkF/////5oF/////5sFAAAAIJzFAAAAAJ0F/////54F/////58FAAAAIKDF AAAAAKEF/////6IF/////78FBgBOAMAFAAAAAMEFAAABAMIF////AMMFAAAAIMQFAAAAAMVFAAAA AMbFAAAAAMcFAAAAAMgFAAAAAMkFAAAAAMoFAAAAAMsFNSUAAMwFAAAIAM0FAAAAAM4FAAAAAM/F AAAAANAFAAAAANEFAAAAANIFAQAAANMFAQAAANQFAQAAANUFAQAAANcFAgAAANkF/////9oF//// /9sFAAAAINzFAAAAAN0F/////94F/////98FAAAAIODFAAAAAOEF/////+IF//////8FBgBOAAAG AAAAAAEGAAABAAIG////AAMGAAAAIAQGAAAAAAVGAAAAAAbGAAAAAAcGAAAAAAgGAAAAAAkGAAAA AAoGAAAAAAsGNSUAAAwGAAAIAA0GAAAAAA4GAAAAAA/GAAAAABAGAAAAABEGAAAAABIGAQAAABMG AQAAABQGAQAAABUGAQAAABcGAgAAABkG/////xoG/////xsGAAAAIBzGAAAAAB0G/////x4G//// /x8GAAAAICDGAAAAACEG/////yIG/////z8GBgBOAEAGAAAAAEEGAAABAEIG////AEMGAAAAIEQG AAAAAEVGAAAAAEbGAAAAAEcGAAAAAEgGAAAAAEkGAAAAAEoGAAAAAEsGNSUAAEwGAAAIAE0GAAAA AE4GAAAAAE/GAAAAAFAGAAAAAFEGAAAAAFIGAQAAAFMGAQAAAFQGAQAAAFUGAQAAAFcGAgAAAFkG /////1oG/////1sGAAAAIFzGAAAAAF0G/////14G/////18GAAAAIGDGAAAAAGEG/////2IG//// /38GBgAOAIAAGvEgAAAA/wAAAN3d3QDq6uoA//9mAP+ZAAAAAP8AAJnMAABmmQBAAB7xEAAAAAQA AAj/mQAAAAAAAPcAABAfAPAPjAAAAAAA8wMUAAAAHwAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAA ACYAAAAEAAAAAAAAAAIAAIAAAAAAAADzAxQAAAAzAAAABAAAAAAAAAAGAACAAAAAAAAA8wMUAAAA MQAAAAQAAAAAAAAABAAAgAAAAAAAAPMDFAAAADwAAAAAAAAAAAAAAAcAAIAAAAAADwDQBz0MAAAf ABQEHAAAAAAAFQQUAAAA0BjNBADKmjtOtdw2AMqaOwECAAAPAPoDdwAAAAAA/gMDAAAAAQEAAAD9 AzQAAABCAAAAZAAAAEIAAABkAAAAAAAAAPwliBYIhBMAeDoLMAAAAAAAAAAA7vz//wr///8AABMA cAD7AwgAAAAAAAAAPAIAAHAA+wMIAAAAAAAAABwOAABwAPsDCAAAAAEAAAAJAgAAHwD/AxQAAAAC AAAEDAAAAAAAAAAAAAAAAgAAAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAAgAAADSE EwD8+AowaJYTAAAAAAAAAAAAAAAAAAAAAAAAARMADwCIEzILAAAPAIoTaAAAAAAAug8UAAAAXwBf AF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAA AAEBAAEBAAABAQEAAQAAAAAAAACI2QAAAAAAAAAAAACAAgHgDwCKE/gIAAAAALoPFgAAAF8AXwBf AFAAUABUAE0AYQBjADEAMQAAAIsT0ggAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAA ABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAA AQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABg AAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYA TQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQA AAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0 AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAA AAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAA AAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAA AAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAA AAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAA VAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEA cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBAAgAAEACv DwgAAAAAAQAABQAAAAAAGRAoAgAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAAB AAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEA AAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAA AAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAA ZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAA AA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAA CgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBw AG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAA GgABDwCKE2gBAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTSAEAAA8A1gcwAQAAAAC3D0QA AABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IIT AAAAAAAPANYHgAAGIhAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABolhMA aJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWBwAABhIgALcPRAAAAItbU08AAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1geGAAYCMAC3D0QA AABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IIT AAAAAAAPANYHAAAGIgAADQQIAAAAcLUAAHC1AAAPAIoTSgAAAAAAug8OAAAAXwBfAF8AUABQAFQA OQAAAIsTLAAAAC8AyA8MAAAAMADSDwQAAAAAAAAAAAB7FxAAAAADAAAAqAMAAAMAAwACD///PwDZ DwwAAAAAANoPBAAAAAAAIwBPANkPDAAAAAAA2g8EAAAADQA9AA8A8A9NCwAAAADzAxQAAAADAAAA BAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA95AAAAT1NQRiBFeHRlbnNpb25zIGluIFN1 cHBvcnQgb2YgSW1wYWlybWVudCBBd2FyZSBSb3V0aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1l bnQgaW4gV2F2ZWxlbmd0aCBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmtzIAAAoQ8mAAAAegAAAAAA AAAAAHgAAAAAAAIAHAABAAAAAAAAAAEAAAAAAAIAKAAAAKoPMgAAAEUAAAAGAAAACQQJBAEAAAAG AAAACQQECDMAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAAFAAAAAACoD58AAABDQ0FN UCBXRywgSUVURiA3OHRoLCBNYWFzdHJpY2h0LCBOZXRoZXJsYW5kcyANDWRyYWZ0LWFncmF6LWNj YW1wLXdzb24taW1wYWlybWVudC1vc3BmLTAwLnR4dA0NRmVybmFuZG8gQWdyYXogKGFncmF6QHRz Yy51cGMuZWR1KQ1ZYWJpbiBZZSAoeWFiaW4ueWVAaHVhd2VpLmNvbSkAAKEPPgAAAKAAAAAAAAAQ AAB4AC8AAAAAAAYAEgAAAAAFLgAAAAAAAgAYAAEAAAABAAYAAQASAAAA//5CAAAAAAACABIAAACq Dz4AAAAVAAAABgAAAAkEBAgYAAAABgAAAAkEBAgwAAAABgAAAAkEBAgBAAAABgAAAAkIBAhCAAAA BwAAAAAADAQECA8A8g8YAAAAAADzDxAAAAAAAAAAAAAAAAAAAAAIWAswAADfDwgAAAAVAAAALQAA AAAA8wMUAAAAUwAAAAQAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAEFja25vd2xl ZGdtZW50cwAAoQ8UAAAAEAAAAAAAAAAAABAAAAAAAAIAJAAAAKoPGgAAAA8AAAAGAAAACQQECAEA AAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVgAA AAQAAAABAAAAEQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPFAAAAAsA AAAAAAAAAAALAAAAAAACACQAAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAA8wMU AAAAaAAAAAQAAAACAAAAHwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE9iamVjdGl2ZSAAAKEP HAAAAAsAAAAAAAAAAAAJAAAAAAACACQAAgAAAAAAAAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAH AAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYgAAAAQA AAACAAAAGQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJQAAAE9TUEYgcm91dGluZyBmb3IgSUEtUldB IC1OZXcgUExJIFRMViAAAKEPKgAAACYAAAAAAAAAAAAXAAAAAABDAAsACwAkAA0AAAAAAAIAJAAC AAAAAAAAAAAAqg8+AAAAFwAAAAYAAAAJCAQIBQAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYA AAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADz AxQAAABXAAAABAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0 aW9uIG9mIExpbmsgUExJIFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAA AKoPJgAAAB8AAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYwAAAAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPIAAAAFRoZSBjb21wb3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAAChDxwAAAAhAAAA AAAAAAAAHwAAAAAAAgAkAAIAAAAAAAAAAACqDz4AAAATAAAABgAAAAkECQQEAAAABgAAAAkEBAgI AAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAA AQAAAAcAAAAAAAQICQQAAPMDFAAAAGQAAAAEAAAAAgAAABsBAAAAAAAAAACfDwQAAAAAAAAAAACo Dx4AAABTb21lIHN1Yi1UTFZzIGFuZCBzdWItc3ViLVRMVnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAA AAACACQAAACqD1AAAAAJAAAABgAAAAkEBAgDAAAABwAAAAMACQQJBAEAAAAHAAAAAwAJBAQIDQAA AAYAAAAJBAQIBAAAAAcAAAADAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAA AQAAAAcAAAAAAAQICQQAAPMDFAAAAGUAAAAEAAAAAgAAABwBAAAAAAAAAACfDwQAAAAAAAAAAACo DyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5rIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAA AAAlAAAAAAACACQAAACqDxoAAAAkAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAA AAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGYAAAAEAAAAAgAAAB0BAAAAAAAAAACfDwQA AAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAA ACUAAAAAAAAAAAAlAAAAAAACACQAAACqDzIAAAAYAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAA BgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQA APMDFAAAAGcAAAAEAAAAAgAAAB4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABBbiBFeGFtcGxl IG9mIGNvbXBvbmVudCBUTFYAAKEPFAAAABwAAAAAAAAAAAAcAAAAAAACACQAAACqDwwAAAAcAAAA BgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABEAAAAAAAA AAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAATmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAA AAAAAAsAAAAAAAIAJAAAAKoPDAAAAAsAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVm aW5lIGl0IGFjY29yZGluZyB0byB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBvciBtYWls aW5nIGxpc3QNS2VlcCB1cGdyYWRpbmcgd2hlbiBJVFUtVCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBp bXBhaXJtZW50IGluZm9ybWF0aW9uDUNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEP MgAAAIsAAAAAAAAAAAAgAAAAAAAAIAAAMgAbAAAAAABhAAsAAAALAJAAAAAABEEAAAQLAAsAAACq DxoAAACqAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A8A84AAAAAADzAxQAAAAGAAAAAAAAAAAA AAAAAQAAAAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEAAAAAAAAAAOoDAAAAAA8A7gPnBAAAAgDv AxgAAAABAAAADQ4AAAAAAAAHAACAAAAAAAcACzAPAAwE/gMAAA8AAvD2AwAAwAcI8AgAAAADAAAA A9QDAA8AA/COAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADUAwAF AAAADwAE8HgAAAASAArwCAAAAALUAwAgAgAAYwAL8CQAAAB/AAAABACAAMQlYRO/AQAAAQD/AQAA AQABAwIAAwCIAwAAAAAAABDwCAAAAHcA3AEcFpcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAGETDwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATw1gIAABIACvAIAAAAA9QDAAAKAADzAAvwWgAAAH8AAAAEAIAA AIWvD4EAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADyAmQCLBXaCg8ADfAOAgAAAACf DwQAAAAEAAAAAACoD+YAAABUd28gdG9wLVRMVnMgYXJlIGRlZmluZWQgdG8gZGVzY3JpYmUgUExJ IChQaHlzaWNhbCBMYXllciBJbXBhaXJtZW50cykgaW5mb3JtYXRpb246DUxpbmsgUExJIFRMVg1E ZXNjcmliZXMgdGhlIHBoeXNpY2FsIGxheWVyIGltcGFpcm1lbnRzIHJlbGF0ZWQgdG8gdGhlIGxp bmsNTm9kZSBQTEkgVExWDURlc2NyaWJlcyB0aGUgcGh5c2ljYWwgbGF5ZXIgaW1wYWlybWVudHMg cmVsYXRlZCB0byB0aGUgbm9kZQAAoQ/CAAAAUwAAAAAAsjAKAAIA2AAGAAAAAAGCABQABwANAAAA AACzMAoAAwDYAAYAAAAAAYIAFAAHAD0AAAABADEwCgABAAYAAAAAAYIAFAAHAA0AAAAAALMwCgAD ANgABgAAAAABggAUAAcAPQAAAAEAMTAKAAEABgAAAAABggAUAAcAUwAAAAAAIgAIABQADQAAAAAE IgAABAgAFAA9AAAAAAQiAAAECAAUAA0AAAAACCIAAAgIABQAPQAAAAAMIgAADAgAFAAAAKoPMgAA AAgAAAAGAAAACQgECAQAAAAHAAAAAwAJCAQIRwAAAAYAAAAJCAQIlAAAAAYAAAAJBAQIAACmDwgA AAAJAAAA+QFvAA8ABPBIAAAAEgAK8AgAAAAB1AMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA u+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA AIsTaQAAAAAA6y4IAAAAdVfKAZA3eIEAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMA AAAAAAAAAAAAAAAAAAAAAIkW/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAA chcQAAAAAQAQAFZ8AwBiABAAxKsDAAAA9Q8cAAAAGQEAAKQZAAMyfAMAs7ADAAEAAABoAAAAAQDF MQ8A6ANmLwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAFAAAARQAAAAEAAAAAAAAB DwDyA2oEAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QeQAwAAAAC3D0QAAABBAHIAaQBhAGwAAABO AGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHAAAGIhAA tw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABolhMAaJYTAOSEiBbwgxMAeDoL MPCDEwAAAAAADwDVB4AABiIgALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAA TQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QcAAAQiMAC3D0QAAADRnlNPAAB0AGkAZwBl AHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw8IMTAAAAAAAPANUHhgAGAkAA tw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoL MPCDEwAAAAAADwDVBwAABCJQALcPRAAAAE5Th2XGftGeAABnAGUAcgBOAGUAeAB0ACAATABUACAA UgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QeGAAYCYAC3D0QAAABXAGkAbgBnAGQAaQBu AGcAcwAAAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHAgAGAnAA tw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoL MPCDEwAAAAAADwDVBwAABiKAALcPRAAAAItbU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAA TABpAGcAaAB0AAAAcgAAAHg6CzDwgxMAAAAAAA8A1QeGAAYCkAC3D0QAAABGAHIAdQB0AGkAZwBl AHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEFKAA tw9EAAAAVABpAG0AZQBzAAAAZQByAE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoL MPCDEwAAAAAADwDVBwAABCSwALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA QgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAYSAACkDwwAAACAAGIAAAAIAAAAFAAA AKUPGgAAAAAAs6guAAMA/AAGAAAAAAEBADIA+QEHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24A AAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8Y AAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8A CwQeEgAADwAA8BYSAAAAAAbwIAgAAAQIBAADAQAARQEAABUAAAAAAAAADwAAAAIAAAA/AAAACwAA AAgAAAAMAAAABAAAAAAAAAAQAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAABMAAAAAAAAA BAAAAAAAAAANAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAI AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAUA AAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAgAAAAkgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAA AAAAAAAFAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAA AAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYAAAAtAAAAQwAAAAAAAAAEAAAAAAAAAAYAAAAA AAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAA AAAHAAAAAAAAAAcAAAAAAAAABgAAAAAAAABCAAAAAAAAABkAAAAAAAAABAAAAAAAAAAKAAAAAAAA AAQAAAAAAAAABAAAAD8AAAAJAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAANAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAE8AAAAMAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAkAAAAAAAAAQAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAMAAAAAAAAABAAAAAAAAAADAAAAAAAAAAMAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAWQAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAALAAAAAAAAAAQAAAAAAAAA/AAAAAAAAAAvAAAAYgAAAAQAAABjAAAABgAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA awAAAAQAAAAAAAAAJgAAAAAAAAAlAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAcQAAAAgAAAAA AAAAtQAAAAAAAAAGAAAAdAAAAPsBAAB1AAAAXgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABQAAAAAA AAAEAAAAAAAAACEAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAADyAAAAAAAA AOMAAAAAAAAAXQAAAAAAAACsAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAHwAAAAE AAAAfQAAAEEAAAB+AAAAcQEAAAAAAAAGAAAAAAAAAAYAAACBAAAAAAQAAAAAAAAGAAAAgQAAAOoC AACDAAAAvQAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAIcAAAAaAAAAiAAAAAQAAACfAAHwjAEA AGIAB/AkAAAABgYFizUfvcf4Wqbzp1AbYphL/wDTKgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBdjz 4wQC6S7Y4+1wmMk9IhX/AE62AAABAAAA0yoAAAAAAABSAAfwJAAAAAUFbl5eEY0uvLba4/yHP5PI YP8ABlcAAAEAAAAh4QAAAAAAAGIAB/AkAAAABgYrHZxRQZaM23v++Bik0FJ5/wCrMwAAAQAAACc4 AQAAAAAAYgAH8CQAAAAGBjzqGWgBpU9W1Nf4u5NQ0En/ANEVAAABAAAA0msBAAAAAABiAAfwJAAA AAYGuOlochf2C1z4/NRk7IJptv8AvFYFAAEAAACjgQEAAAAAADIAB/AkAAAAAwTu27VzakCgund2 cy5xQ7YV/wBJAgAAAQAAAF/YBgAAAAAAMgAH8CQAAAADBEDr6bWAxkM/GdCbDDnQSyT/AJ0CAAAB AAAAqNoGAAAAAAAyAAfwJAAAAAMEqq27CBAYBSRVAqgM93b5Bf8ASwIAAAEAAABF3QYAAAAAAAMI C/AAAwAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAiAAAAAAAiQAAAAAAvwAC AA8ADAH0AAAQDQEAAAAgDgEAAAAggAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAg hkEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEA AAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAA mQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEMAB4AwAEBAAAIwQEAAAEAwgH///8AwwEAAAAgxAEA AAAAxUEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAA zgEAAAAAz8EAAAAA1wECAAAA/wEOAA4AAAIAAAAAAQICAAAIAgLLy8sAAwIAAAAgBAIAAAEABQI4 YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIAAAAA DwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw +QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAA xQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIA gAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP// 2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMA AAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAcw0i8QoFAACMAAEAAACNADBlAQB/AQAA QACeAf////+fAf////+gAQAAACChwQAAAACiAf////+jAf////+kAQAAACClwQAAAACmAf////+n Af////+/AQAAIADZAf/////aAf/////bAQAAACDcwQAAAADdAf/////eAf/////fAQAAACDgwQAA AADhAf/////iAf//////AQAAwAASAv////8TAv////8UAgAAACAVwgAAAAAWAv////8XAv////8Y AgAAACAZwgAAAAAaAv////8bAv////+JAv////+KAv////+LAgAAACCMwgAAAACNAv////+PAwAA AACQAwIAAACRAwAAAACSAwIAAAC/AwCCAIJABQAAAABBBQAAAQBCBf///wBDBQAAACBEBQAAAABF RQAAAABGxQAAAABHBQAAAABIBQAAAABJBQAAAABKBQAAAABLBTUlAABMBQAACABNBQAAAABOBQAA AABPxQAAAABQBQAAAABRBQAAAABSBQEAAABTBQEAAABUBQEAAABVBQEAAABXBQIAAABZBf////9a Bf////9bBQAAACBcxQAAAABdBf////9eBf////9fBQAAACBgxQAAAABhBf////9iBf////9/BQYA TgCABQAAAACBBQAAAQCCBf///wCDBQAAACCEBQAAAACFRQAAAACGxQAAAACHBQAAAACIBQAAAACJ BQAAAACKBQAAAACLBTUlAACMBQAACACNBQAAAACOBQAAAACPxQAAAACQBQAAAACRBQAAAACSBQEA AACTBQEAAACUBQEAAACVBQEAAACXBQIAAACZBf////+aBf////+bBQAAACCcxQAAAACdBf////+e Bf////+fBQAAACCgxQAAAAChBf////+iBf////+/BQYATgDABQAAAADBBQAAAQDCBf///wDDBQAA ACDEBQAAAADFRQAAAADGxQAAAADHBQAAAADIBQAAAADJBQAAAADKBQAAAADLBTUlAADMBQAACADN BQAAAADOBQAAAADPxQAAAADQBQAAAADRBQAAAADSBQEAAADTBQEAAADUBQEAAADVBQEAAADXBQIA AADZBf/////aBf/////bBQAAACDcxQAAAADdBf/////eBf/////fBQAAACDgxQAAAADhBf/////i Bf//////BQYATgAABgAAAAABBgAAAQACBv///wADBgAAACAEBgAAAAAFRgAAAAAGxgAAAAAHBgAA AAAIBgAAAAAJBgAAAAAKBgAAAAALBjUlAAAMBgAACAANBgAAAAAOBgAAAAAPxgAAAAAQBgAAAAAR BgAAAAASBgEAAAATBgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZBv////8aBv////8bBgAAACAcxgAA AAAdBv////8eBv////8fBgAAACAgxgAAAAAhBv////8iBv////8/BgYATgBABgAAAABBBgAAAQBC Bv///wBDBgAAACBEBgAAAABFRgAAAABGxgAAAABHBgAAAABIBgAAAABJBgAAAABKBgAAAABLBjUl AABMBgAACABNBgAAAABOBgAAAABPxgAAAABQBgAAAABRBgAAAABSBgEAAABTBgEAAABUBgEAAABV BgEAAABXBgIAAABZBv////9aBv////9bBgAAACBcxgAAAABdBv////9eBv////9fBgAAACBgxgAA AABhBv////9iBv////9/BgYADgCAABrxIAAAAP8AAADd3d0A6urqAP//ZgD/mQAAAAD/AACZzAAA ZpkAQAAe8RAAAAAEAAAI/5kAAAAAAAD3AAAQHwDwD4wAAAAAAPMDFAAAAB8AAAAEAAAAAAAAAAEA AIAAAAAAAADzAxQAAAAmAAAABAAAAAAAAAACAACAAAAAAAAA8wMUAAAAMwAAAAQAAAAAAAAABgAA gAAAAAAAAPMDFAAAADEAAAAEAAAAAAAAAAQAAIAAAAAAAADzAxQAAAA8AAAAAAAAAAAAAAAHAACA AAAAAA8A0Ac9DAAAHwAUBBwAAAAAABUEFAAAANAYzQQAypo7TrXcNgDKmjsBAgAADwD6A3cAAAAA AP4DAwAAAAEBAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAAAAAD8JYgWCIQTAHg6CzAAAAAAAAAA AO78//+4////AAATAHAA+wMIAAAAAAAAADwCAABwAPsDCAAAAAAAAAAcDgAAcAD7AwgAAAABAAAA CQIAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABk AAAAZAAAAAIAAAA0hBMA/PgKMGiWEwAAAAAAAAAAAAAAAAAAAAAAAAETAA8AiBMyCwAADwCKE2gA AAAAALoPFAAAAF8AXwBfAFAAUABUADIAMAAwADEAAACLE0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAA AAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAAAAAAiNkAAAAAAAAAAAAAgAIB4A8AihP4CAAA AAC6DxYAAABfAF8AXwBQAFAAVABNAGEAYwAxADEAAACLE9IIAABAABoQZgUAAAUAAAAACAwBAAAA AAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAA AAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAAB BQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAA AAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYA AAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAA AAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAAB AQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1k AAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAA AAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAA AQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAA IAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAA AAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIA AAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBu AG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAA AAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAAB AAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEA AAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAA AAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAA ZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAA AA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAA CgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBw AG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAA GgABAAAcEBQBAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAA AOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAA AQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAK AEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAA bwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAa AAEPABsQQAIAABAArw8IAAAAAAEAAAUAAAAAABkQKAIAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAA FAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAAB AAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAA AAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBN AG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAA BgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAAB AAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIA AAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAA AAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQA eQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAA AAQAAAAOAAkAEQAAABoAAQ8AihNoAQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE0gBAAAP ANYHMAEAAAAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABolhMAaJYTADCE EwDoghMAeDoLMOiCEwAAAAAADwDWB4AABiIQALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1gcAAAYSIAC3D0QAAACLW1NP AABlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAP ANYHhgAGAjAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCE EwDoghMAeDoLMOiCEwAAAAAADwDWBwAABiIAAA0ECAAAAHC1AABwtQAADwCKE0oAAAAAALoPDgAA AF8AXwBfAFAAUABUADkAAACLEywAAAAvAMgPDAAAADAA0g8EAAAAAAAAAAAAexcQAAAAAwAAAKgD AAADAAMAAg///z8A2Q8MAAAAAADaDwQAAAAAACMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPTQsA AAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0 ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxl bmd0aCBBc3NpZ25tZW50IGluIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAA AKEPJgAAAHoAAAAAAAAAAAB4AAAAAAACABwAAQAAAAAAAAABAAAAAAACACgAAACqDzIAAABFAAAA BgAAAAkECQQBAAAABgAAAAkEBAgzAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAABQAA AAAAqA+fAAAAQ0NBTVAgV0csIElFVEYgNzh0aCwgTWFhc3RyaWNodCwgTmV0aGVybGFuZHMgDQ1k cmFmdC1hZ3Jhei1jY2FtcC13c29uLWltcGFpcm1lbnQtb3NwZi0wMC50eHQNDUZlcm5hbmRvIEFn cmF6IChhZ3JhekB0c2MudXBjLmVkdSkNWWFiaW4gWWUgKHlhYmluLnllQGh1YXdlaS5jb20pAACh Dz4AAACgAAAAAAAAEAAAeAAvAAAAAAAGABIAAAAABS4AAAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+ QgAAAAAAAgASAAAAqg8+AAAAFQAAAAYAAAAJBAQIGAAAAAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAA AAYAAAAJCAQIQgAAAAcAAAAAAAwEBAgPAPIPGAAAAAAA8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA 3w8IAAAAFQAAAC0AAAAAAPMDFAAAAFMAAAAEAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACo Dw8AAABBY2tub3dsZWRnbWVudHMAAKEPFAAAABAAAAAAAAAAAAAQAAAAAAACACQAAACqDxoAAAAP AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQAAPMDFAAAAFYAAAAEAAAAAQAAABEBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABCYWNrZ3Jv dW5kAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAAAAcA AAAAAAQICQQAAPMDFAAAAGgAAAAEAAAAAgAAAB8BAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABP YmplY3RpdmUgAAChDxwAAAALAAAAAAAAAAAACQAAAAAAAgAkAAIAAAAAAAAAAACqDxoAAAAKAAAA BgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQA APMDFAAAAGIAAAAEAAAAAgAAABkBAAAAAAAAAACfDwQAAAAAAAAAAACoDyUAAABPU1BGIHJvdXRp bmcgZm9yIElBLVJXQSAtTmV3IFBMSSBUTFYgAAChDyoAAAAmAAAAAAAAAAAAFwAAAAAAQwALAAsA JAANAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABcAAAAGAAAACQgECAUAAAAGAAAACQQECAgAAAAG AAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAA BwAAAAAABAgJBAAA8wMUAAAAVwAAAAQAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAA AFRoZSBjb21wb3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAA AgAkAAIAAAAAAAAAAACqDyYAAAAfAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJ BBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoB AAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExW IAAAoQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkE BAAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8eAAAAU29tZSBzdWItVExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAf AAAAAAAAAAAAHwAAAAAAAgAkAAAAqg9QAAAACQAAAAYAAAAJBAQIAwAAAAcAAAADAAkECQQBAAAA BwAAAAMACQQECA0AAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABlAAAABAAAAAIAAAAcAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTGluayBQTEkgVExWAACh DxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8aAAAAJAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQI CQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABmAAAABAAAAAIAAAAd AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQ TEkgVExWAAChDxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAA AAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEA AAAHAAAAAAAECAkEAADzAxQAAABnAAAABAAAAAIAAAAeAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8b AAAAQW4gRXhhbXBsZSBvZiBjb21wb25lbnQgVExWAAChDxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAk AAAAqg8MAAAAHAAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA 8wMUAAAARAAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMA AKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQAAACqDwwAAAALAAAABgAAAAkEBAgQAJ8PBAAAAAEA AAAAAKgPqgAAAFJlZmluZSBpdCBhY2NvcmRpbmcgdG8gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1l ZXRpbmcgb3IgbWFpbGluZyBsaXN0DUtlZXAgdXBncmFkaW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0 aGUgc3RhbmRhcmQgaW1wYWlybWVudCBpbmZvcm1hdGlvbg1Db21tZW50cyBhcmUgYWx3YXlzIGFw cHJlY2lhdGVkAAChDzIAAACLAAAAAAAAAAAAIAAAAAAAACAAADIAGwAAAAAAYQALAAAACwCQAAAA AARBAAAECwALAAAAqg8aAAAAqgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQvAPAPOAAAAAAA8wMU AAAABgAAAAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAE0AAAAAAAAAAAAAAAgBAAAAAAAAAADqAwAA AAAPAO4DRwsAAAIA7wMYAAAAAQAAAA0OAAAAAAAABwAAgAAAAAAHAAswDwAMBF4KAAAPAALwVgoA AMAHCPAIAAAAAwAAAAPUAwAPAAPw7gkAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAA1AMABQAAAA8ABPB4AAAAEgAK8AgAAAAC1AMAIAIAAGMAC/AkAAAAfwAAAAQAgADE JWETvwEAAAEA/wEAAAEAAQMCAAMAiAMAAAAAAAAQ8AgAAAB3ANwBHBaXAg8AEfAQAAAAAADDCwgA AAAAAAAADQBhEw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8DYJAAASAArwCAAAAAPUAwAACgAA8wAL 8FoAAAB/AAAABACAAACFrw+BAGA1AQCCALCaAACDAGA1AQCEALCaAAC/AAAADwCBAQQAAAiDAQAA AAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAAAH8BAABAAL8BAABg AP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA8gJkAiwV 2goPABHwxgAAAA8AiBO+AAAADwCKE7YAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE5gAAAAA AKwPkAAAAAAAAAAAAAAAAAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfCgBwAAAACfDwQAAAAEAAAA AACgD9oEAABJAG4AIABHAE0AUABMAFMALQBiAGEAcwBlAGQAIABXAFMATwBOACAAbgBlAHQAdwBv AHIAawBzACwAIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAaQBuAGYAbwByAG0AYQB0AGkA bwBuACAAbgBlAGUAZAAgAHQAbwAgAGIAZQAgAGYAbABvAG8AZABlAGQAIAB0AGgAcgBvAHUAZwBo ACAAcgBvAHUAdABpAG4AZwA6AA0ATgBvAHIAbQBhAGwAIAByAG8AdQB0AGkAbgBnACAAaQBuAGYA bwA6ACAAZABlAHMAYwByAGkAYgBlAGQAIABpAG4AIABbAFIARgBDACAAMwA2ADMAMABdACAAYQBu AGQAIABbAFIARgBDACAANAAyADAAMwBdAC4ADQBOAG8AZABlACAASQBEACwAIABMAGkAbgBrACAA SQBEACwAIABBAGQAbQBpAG4AaQBzAHQAcgBhAHQAaQB2AGUAIABHAHIAbwB1AHAADQBJAFMAQwBE ACwAIABQAHIAbwB0AGUAYwB0AGkAbwBuACwAIABTAFIATABHACwAIABUAEUAIABtAGUAdAByAGkA YwAsACAAJiANAA0AVwBTAE8ATgAgAHMAcABlAGMAaQBhAGwAIABpAG4AZgBvADoAIABkAGUAcwBj AHIAaQBiAGUAZAAgAGkAbgAgAFsAXQANAFMAdwBpAHQAYwBoACAAQwBvAG4AbgBlAGMAdABpAHYA aQB0AHkAIABNAGEAdAByAGkAeAAsACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAEMAbwBuAHYAZQBy AHQAZQByACAAUABvAG8AbAAgAGkAbgBmAG8ALAAgAFcAYQB2AGUAbABlAG4AZwB0AGgAIABBAHYA YQBpAGwAYQBiAGkAbABpAHQAeQAsACAAIABQAG8AcgB0ACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAg AFIAZQBzAHQAcgBpAGMAdABpAG8AbgAsACAAZQB0AGMALAAuAA0ADQANAA0ADQBUAHcAbwAgAHQA bwBwAC0AVABMAFYAcwAgAGEAcgBlACAAZABlAGYAaQBuAGUAZAAgAHQAbwAgAGQAZQBzAGMAcgBp AGIAZQAgAFAATABJACAAKABQAGgAeQBzAGkAYwBhAGwAIABMAGEAeQBlAHIAIABJAG0AcABhAGkA cgBtAGUAbgB0AHMAKQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgA6AA0ATABpAG4AawAgAFAATABJ ACAAVABMAFYAIAANAEQAZQBzAGMAcgBpAGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwA IABsAGEAeQBlAHIAIABpAG0AcABhAGkAcgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABv ACAAdABoAGUAIABsAGkAbgBrAA0ATgBvAGQAZQAgAFAATABJACAAVABMAFYADQBEAGUAcwBjAHIA aQBiAGUAcwAgAHQAaABlACAAcABoAHkAcwBpAGMAYQBsACAAbABhAHkAZQByACAAaQBtAHAAYQBp AHIAbQBlAG4AdABzACAAcgBlAGwAYQB0AGUAZAAgAHQAbwAgAHQAaABlACAAbgBvAGQAZQAAAKEP GgIAAFwAAAAAALIwCgACANgABgAAAAABggAUAAcAPQAAAAAAIQAKAAEAAAAAAQcATAAAAAEAoQAK AAEALQAAAAABBwABAAAAAQCgAAoALQAAAAABBwAjAAAAAAAhAAoAAQAAAAABBwB5AAAAAQChAAoA AQAtAAAAAAEHAAEAAAABAKEACgABAC0AAAAAAQcAAQAAAAEAsygKAAMA/AAGAAAAAAEBADIABwAB AAAAAQChAAoAAQAtAAAAAAEHAFQAAAAAALIwCgACANgABgAAAAABggAUAAcADgAAAAAAszAKAAMA 2AAGAAAAAAGCABQABwA9AAAAAQAxMAoAAQAGAAAAAAGCABQABwANAAAAAACzMAoAAwDYAAYAAAAA AYIAFAAHAD0AAAABADEwCgABAAYAAAAAAYIAFAAHAFwAAAAAACIACAAUABMAAAAABGcAAAQLAAgA CwAWAAAA//4qAAAAAARnAAAECwAIAAsAFgAAAAADTAAAAAAIYwAACAsACAALABYAAQAAAAAMYwAA DAsACAALABYAIwAAAAAQZwAAEAsACAALABYAAAD//nkAAAAAFGMAABQLAAgACwAWAAIAAAAAFCYA ABQIABQAmWYz/gEAAAAAGCAAABgIAFQAAAAAHCAAABwIAA4AAAAAICAAACAIAD0AAAAAICIAACAI ABQADQAAAAAkIAAAJAgAPQAAAAAoIgAAKAgAFAAAAKoPcAAAAG8AAAAGAAAACQQECCoAAAAGAAAA CQgECFoAAAAGAAAACQQECBUAAAAHAAAAAAAJBAQIfAAAAAYAAAAJBAQICgAAAAYAAAAJCAQIBAAA AAcAAAADAAkIBAhHAAAABgAAAAkIBAiVAAAABgAAAAkEBAgAAKYPEAAAAPkAAAD5ASABQAJgA4AE oAUPAATwSAAAABIACvAIAAAAAdQDAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAA AOsuCAAAAHVXygGQN3iBAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAACJFv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXEAAAAAEA EADvsAMAYgAQAF3gAwAAAPUPHAAAABkBAACkGQADy7ADAKzrAwABAAAAaAAAAAEAxTEPAOgDZi8A AAEA6QMoAAAAgBYAAOAQAACBBQAAggUAAIMFAACEBQAAhQUAAIYFAACHBQAAiAUAAIkFAACKBQAA iwUAAIwFAACNBQAAjgUAAI8FAACQBQAAkQUAAJIFAACTBQAAlAUAAJUFAACWBQAAlwUAAJgFAACZ BQAAmgUAAJsFAACcBQAAnQUAAJ4FAACfBQAAoAUAAKEFAACiBQAAowUAAKQFAAClBQAApgUAAKcF AACoBQAAqQUAAKoFAACrBQAArAUAAK0FAACuBQAArwUAALAFAACxBQAAsgUAALMFAAC0BQAAtQUA ALYFAAC3BQAAuAUAALkFAAC6BQAAuwUAALwFAAC9BQAAvgUAAL8FAADABQAAwQUAAMIFAADDBQAA xAUAAMUFAADGBQAAxwUAAMgFAADJBQAAygUAAMsFAADMBQAAzQUAAM4FAADPBQAA0AUAANEFAADS BQAA0wUAANQFAADVBQAA1gUAANcFAADYBQAA2QUAANoFAADbBQAA3AUAAN0FAADeBQAA3wUAAOAF AADhBQAA4gUAAOMFAADkBQAA5QUAAOYFAADnBQAA6AUAAOkFAADqBQAA6wUAAOwFAADtBQAA7gUA AO8FAADwBQAA8QUAAPIFAADzBQAA9AUAAPUFAAD2BQAA9wUAAPgFAAD5BQAA+gUAAPsFAAD8BQAA /QUAAP4FAAD/BQAAAQYAAOAQAACAFgAABQAAAAoAAAAFAAAARQAAAAEAAAAAAAABDwDyA2oEAAAv AMgPDAAAADAA0g8EAAAAAAAAAA8A1QeQAwAAAAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIA bwBtAGEAbgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHAAAGIhAAtw9EAAAATQBT ACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABolhMAaJYTAOSEiBbwgxMAeDoLMPCDEwAAAAAA DwDVB4AABiIgALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1 AG0AAAATAHg6CzDwgxMAAAAAAA8A1QcAAAQiMAC3D0QAAADRnlNPAAB0AGkAZwBlAHIATgBlAHgA dAAgAEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw8IMTAAAAAAAPANUHhgAGAkAAtw9EAAAARgBy AHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAA DwDVBwAABCJQALcPRAAAAE5Th2XGftGeAABnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBs AGEAcgAAAHg6CzDwgxMAAAAAAA8A1QeGAAYCYAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAHgA dAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHAgAGAnAAtw9EAAAARgBy AHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAA DwDVBwAABiKAALcPRAAAAItbU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0 AAAAcgAAAHg6CzDwgxMAAAAAAA8A1QeGAAYCkAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgA dAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEFKAAtw9EAAAAVABp AG0AZQBzAAAAZQByAE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAA DwDVBwAABCSwALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAQgBvAGwAZAAA AAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAYSAACkDwwAAACAAGIAAAAIAAAAFAAAAKUPGgAAAAAA s6guAAMA/AAGAAAAAAEBADIA+QEHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAA ACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAAAF AAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQeEgAADwAA 8BYSAAAAAAbwIAgAAAQIBAADAQAARQEAABUAAAAAAAAADwAAAAIAAAA/AAAACwAAAAgAAAAMAAAA BAAAAAAAAAAQAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAAN AAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAUAAAAAAAAABQAA AAAAAAAEAAAAAAAAACEAAAAgAAAAkgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAFAAAA AAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAcAAAAA AAAABwAAAAAAAAAHAAAAAAAAAAYAAAAtAAAAQwAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAA AAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAA AAcAAAAAAAAABgAAAAAAAABCAAAAAAAAABkAAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAA BAAAAD8AAAAJAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAANAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAE8AAAAMAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAkAAAAAAAAAQAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAMAAAAAAAAABAAAAAAAAAADAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAWQAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAALAAAAAAAAAAQAAAAAAAAA/AAAAAAAAAAvAAAAYgAAAAQAAABjAAAABgAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAawAAAAQAAAAA AAAAJgAAAAAAAAAlAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAcQAAAAgAAAAAAAAAtQAAAAAA AAAGAAAAdAAAAPsBAAB1AAAAXgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAA ACEAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAADyAAAAAAAAAOMAAAAAAAAA XQAAAAAAAACsAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAHwAAAAEAAAAfQAAAEEA AAB+AAAAcQEAAAAAAAAGAAAAAAAAAAYAAACBAAAAAAQAAAAAAAAGAAAAgQAAAOoCAACDAAAAvQAA AAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAIcAAAAaAAAAiAAAAAQAAACfAAHwjAEAAGIAB/AkAAAA BgYFizUfvcf4Wqbzp1AbYphL/wDTKgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBdjz4wQC6S7Y4+1w mMk9IhX/AE62AAABAAAA0yoAAAAAAABSAAfwJAAAAAUFbl5eEY0uvLba4/yHP5PIYP8ABlcAAAEA AAAh4QAAAAAAAGIAB/AkAAAABgYrHZxRQZaM23v++Bik0FJ5/wCrMwAAAQAAACc4AQAAAAAAYgAH 8CQAAAAGBjzqGWgBpU9W1Nf4u5NQ0En/ANEVAAABAAAA0msBAAAAAABiAAfwJAAAAAYGuOlochf2 C1z4/NRk7IJptv8AvFYFAAEAAACjgQEAAAAAADIAB/AkAAAAAwTu27VzakCgund2cy5xQ7YV/wBJ AgAAAQAAAF/YBgAAAAAAMgAH8CQAAAADBEDr6bWAxkM/GdCbDDnQSyT/AJ0CAAABAAAAqNoGAAAA AAAyAAfwJAAAAAMEqq27CBAYBSRVAqgM93b5Bf8ASwIAAAEAAABF3QYAAAAAAAMIC/AAAwAAgQBg NQEAggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAiAAAAAAAiQAAAAAAvwACAA8ADAH0AAAQ DQEAAAAgDgEAAAAggAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghkEAAAAAh8EA AAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAA kQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEA AAAAmwEAAAAAnAEDAABAvwEMAB4AwAEBAAAIwQEAAAEAwgH///8AwwEAAAAgxAEAAAAAxUEAAAAA xsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEAAAAAz8EA AAAA1wECAAAA/wEOAA4AAAIAAAAAAQICAAAIAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAA BwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIA AAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAA hwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIA AAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP// 0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQ JwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8A hAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAcw0i8QoFAACMAAEAAACNADBlAQB/AQAAQACeAf////+f Af////+gAQAAACChwQAAAACiAf////+jAf////+kAQAAACClwQAAAACmAf////+nAf////+/AQAA IADZAf/////aAf/////bAQAAACDcwQAAAADdAf/////eAf/////fAQAAACDgwQAAAADhAf/////i Af//////AQAAwAASAv////8TAv////8UAgAAACAVwgAAAAAWAv////8XAv////8YAgAAACAZwgAA AAAaAv////8bAv////+JAv////+KAv////+LAgAAACCMwgAAAACNAv////+PAwAAAACQAwIAAACR AwAAAACSAwIAAAC/AwCCAIJABQAAAABBBQAAAQBCBf///wBDBQAAACBEBQAAAABFRQAAAABGxQAA AABHBQAAAABIBQAAAABJBQAAAABKBQAAAABLBTUlAABMBQAACABNBQAAAABOBQAAAABPxQAAAABQ BQAAAABRBQAAAABSBQEAAABTBQEAAABUBQEAAABVBQEAAABXBQIAAABZBf////9aBf////9bBQAA ACBcxQAAAABdBf////9eBf////9fBQAAACBgxQAAAABhBf////9iBf////9/BQYATgCABQAAAACB BQAAAQCCBf///wCDBQAAACCEBQAAAACFRQAAAACGxQAAAACHBQAAAACIBQAAAACJBQAAAACKBQAA AACLBTUlAACMBQAACACNBQAAAACOBQAAAACPxQAAAACQBQAAAACRBQAAAACSBQEAAACTBQEAAACU BQEAAACVBQEAAACXBQIAAACZBf////+aBf////+bBQAAACCcxQAAAACdBf////+eBf////+fBQAA ACCgxQAAAAChBf////+iBf////+/BQYATgDABQAAAADBBQAAAQDCBf///wDDBQAAACDEBQAAAADF RQAAAADGxQAAAADHBQAAAADIBQAAAADJBQAAAADKBQAAAADLBTUlAADMBQAACADNBQAAAADOBQAA AADPxQAAAADQBQAAAADRBQAAAADSBQEAAADTBQEAAADUBQEAAADVBQEAAADXBQIAAADZBf/////a Bf/////bBQAAACDcxQAAAADdBf/////eBf/////fBQAAACDgxQAAAADhBf/////iBf//////BQYA TgAABgAAAAABBgAAAQACBv///wADBgAAACAEBgAAAAAFRgAAAAAGxgAAAAAHBgAAAAAIBgAAAAAJ BgAAAAAKBgAAAAALBjUlAAAMBgAACAANBgAAAAAOBgAAAAAPxgAAAAAQBgAAAAARBgAAAAASBgEA AAATBgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZBv////8aBv////8bBgAAACAcxgAAAAAdBv////8e Bv////8fBgAAACAgxgAAAAAhBv////8iBv////8/BgYATgBABgAAAABBBgAAAQBCBv///wBDBgAA ACBEBgAAAABFRgAAAABGxgAAAABHBgAAAABIBgAAAABJBgAAAABKBgAAAABLBjUlAABMBgAACABN BgAAAABOBgAAAABPxgAAAABQBgAAAABRBgAAAABSBgEAAABTBgEAAABUBgEAAABVBgEAAABXBgIA AABZBv////9aBv////9bBgAAACBcxgAAAABdBv////9eBv////9fBgAAACBgxgAAAABhBv////9i Bv////9/BgYADgCAABrxIAAAAP8AAADd3d0A6urqAP//ZgD/mQAAAAD/AACZzAAAZpkAQAAe8RAA AAAEAAAI/5kAAAAAAAD3AAAQHwDwD4wAAAAAAPMDFAAAAB8AAAAEAAAAAAAAAAEAAIAAAAAAAADz AxQAAAAmAAAABAAAAAAAAAACAACAAAAAAAAA8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMD FAAAADEAAAAEAAAAAAAAAAQAAIAAAAAAAADzAxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ac9 DAAAHwAUBBwAAAAAABUEFAAAANAYzQQAypo7TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEB AAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAAAAAD8JYgWCIQTAHg6CzAAAAAAAAAAAO78//+4//// AAATAHAA+wMIAAAAAAAAADwCAABwAPsDCAAAAAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMU AAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIA AAA0hBMA/PgKMGiWEwAAAAAAAAAAAAAAAAAAAAAAAAETAA8AiBMyCwAADwCKE2gAAAAAALoPFAAA AF8AXwBfAFAAUABUADIAMAAwADEAAACLE0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAA WAIAAAABAQABAQAAAQEBAAEAAAAAAAAAiNkAAAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABf AF8AXwBQAFAAVABNAGEAYwAxADEAAACLE9IIAABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAA AAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAAB AQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1k AAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAA AAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAA AQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAA IAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAA AAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIA AAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBu AG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAA AAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAAB AAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEA AAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAA AAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAA ZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAA AA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAA CgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBw AG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAA GgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAA AAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAAB BAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBh AGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEA cABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQB AAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAA BAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEE AAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEA bAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBw AGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIA ABAArw8IAAAAAAEAAAUAAAAAABkQKAIAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAAB AAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIA AAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAA AAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQA eQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAA AAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAA AAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAA AQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAA AAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABU AHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkA EQAAABoAAQ8AihNoAQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAA tw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoL MOiCEwAAAAAADwDWB4AABiIQALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA aJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABO AGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHhgAGAjAA tw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoL MOiCEwAAAAAADwDWBwAABiIAAA0ECAAAAHC1AABwtQAADwCKE0oAAAAAALoPDgAAAF8AXwBfAFAA UABUADkAAACLEywAAAAvAMgPDAAAADAA0g8EAAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg// /z8A2Q8MAAAAAADaDwQAAAAAACMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPTQsAAAAA8wMUAAAA AwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBp biBTdXBwb3J0IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3Np Z25tZW50IGluIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoA AAAAAAAAAAB4AAAAAAACABwAAQAAAAAAAAABAAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQB AAAABgAAAAkEBAgzAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAA Q0NBTVAgV0csIElFVEYgNzh0aCwgTWFhc3RyaWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jh ei1jY2FtcC13c29uLWltcGFpcm1lbnQtb3NwZi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3Jh ekB0c2MudXBjLmVkdSkNWWFiaW4gWWUgKHlhYmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAA AAAAEAAAeAAvAAAAAAAGABIAAAAABS4AAAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgAS AAAAqg8+AAAAFQAAAAYAAAAJBAQIGAAAAAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQI QgAAAAcAAAAAAAwEBAgPAPIPGAAAAAAA8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAA AC0AAAAAAPMDFAAAAFMAAAAEAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tu b3dsZWRnbWVudHMAAKEPFAAAABAAAAAAAAAAAAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkE BAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AFYAAAAEAAAAAQAAABEBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQA AAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQA APMDFAAAAGgAAAAEAAAAAgAAAB8BAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABPYmplY3RpdmUg AAChDxwAAAALAAAAAAAAAAAACQAAAAAAAgAkAAIAAAAAAAAAAACqDxoAAAAKAAAABgAAAAkEBAgB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIA AAAEAAAAAgAAABkBAAAAAAAAAACfDwQAAAAAAAAAAACoDyUAAABPU1BGIHJvdXRpbmcgZm9yIElB LVJXQSAtTmV3IFBMSSBUTFYgAAChDyoAAAAmAAAAAAAAAAAAFwAAAAAAQwALAAsAJAANAAAAAAAC ACQAAgAAAAAAAAAAAKoPPgAAABcAAAAGAAAACQgECAUAAAAGAAAACQQECAgAAAAGAAAACQQJBAEA AAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJ BAAA8wMUAAAAVwAAAAQAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21w b3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAA AAAAAACqDyYAAAAfAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAA AQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAAAAAAAACf DwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAAoQ8cAAAA IQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAAAAYAAAAJ BAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8eAAAAU29tZSBzdWItVExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAAAAAAAAAA HwAAAAAAAgAkAAAAqg9QAAAACQAAAAYAAAAJBAQIAwAAAAcAAAADAAkECQQBAAAABwAAAAMACQQE CA0AAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABlAAAABAAAAAIAAAAcAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTGluayBQTEkgVExWAAChDxQAAAAlAAAA AAAAAAAAJQAAAAAAAgAkAAAAqg8aAAAAJAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABmAAAABAAAAAIAAAAdAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQTEkgVExWAACh DxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAAAAYAAAAJBAQI CAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAE CAkEAADzAxQAAABnAAAABAAAAAIAAAAeAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAAQW4gRXhh bXBsZSBvZiBjb21wb25lbnQgVExWAAChDxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAkAAAAqg8MAAAA HAAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAARAAA AAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMAAKEPFAAAAAsA AAAAAAAAAAALAAAAAAACACQAAACqDwwAAAALAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKgPqgAA AFJlZmluZSBpdCBhY2NvcmRpbmcgdG8gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcgb3Ig bWFpbGluZyBsaXN0DUtlZXAgdXBncmFkaW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0aGUgc3RhbmRh cmQgaW1wYWlybWVudCBpbmZvcm1hdGlvbg1Db21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lhdGVk AAChDzIAAACLAAAAAAAAAAAAIAAAAAAAACAAADIAGwAAAAAAYQALAAAACwCQAAAAAARBAAAECwAL AAAAqg8aAAAAqgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQvAPAPOAAAAAAA8wMUAAAABgAAAAAA AAAAAAAAAAEAAAAAAAAAAPMDFAAAAE0AAAAAAAAAAAAAAAgBAAAAAAAAAADqAwAAAAAPAO4DRQsA AAIA7wMYAAAAAQAAAA0OAAAAAAAABwAAgAAAAAAHAAswDwAMBFwKAAAPAALwVAoAAMAHCPAIAAAA AwAAAAPUAwAPAAPw7AkAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA 1AMABQAAAA8ABPB4AAAAEgAK8AgAAAAC1AMAIAIAAGMAC/AkAAAAfwAAAAQAgADEJWETvwEAAAEA /wEAAAEAAQMCAAMAiAMAAAAAAAAQ8AgAAAB3ANwBHBaXAg8AEfAQAAAAAADDCwgAAAAAAAAADQBh Ew8ADfAMAAAAAACeDwQAAAAAAAAADwAE8DQJAAASAArwCAAAAAPUAwAACgAA8wAL8FoAAAB/AAAA BACAAACFrw+BAGA1AQCCALCaAACDAGA1AQCEALCaAAC/AAAADwCBAQQAAAiDAQAAAAi/AQwAHgDA AQEAAAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAAAH8BAABAAL8BAABgAP8BAADAAL8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA8gJkAiwV2goPABHwzAAA AA8AiBPEAAAADwCKE7wAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE54AAAAAAKwPlgAAAAAA AAAAAAAAAAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMBAAwAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfCYBwAAAACfDwQAAAAEAAAAAACg DxQFAABJAG4AIABHAE0AUABMAFMALQBiAGEAcwBlAGQAIABXAFMATwBOACAAbgBlAHQAdwBvAHIA awBzACwAIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAaQBuAGYAbwByAG0AYQB0AGkAbwBu ACAAbgBlAGUAZAAgAHQAbwAgAGIAZQAgAGYAbABvAG8AZABlAGQAIAB0AGgAcgBvAHUAZwBoACAA cgBvAHUAdABpAG4AZwA6AA0ATgBvAHIAbQBhAGwAIAByAG8AdQB0AGkAbgBnACAAaQBuAGYAbwA6 ACAAZABlAHMAYwByAGkAYgBlAGQAIABpAG4AIABbAFIARgBDACAAMwA2ADMAMABdACAAYQBuAGQA IABbAFIARgBDACAANAAyADAAMwBdAC4ADQBOAG8AZABlACAASQBEACwAIABMAGkAbgBrACAASQBE ACwAIABBAGQAbQBpAG4AaQBzAHQAcgBhAHQAaQB2AGUAIABHAHIAbwB1AHAADQBJAFMAQwBEACwA IABQAHIAbwB0AGUAYwB0AGkAbwBuACwAIABTAFIATABHACwAIABUAEUAIABtAGUAdAByAGkAYwAs ACAAJiANAFcAUwBPAE4AIABzAHAAZQBjAGkAYQBsACAAaQBuAGYAbwA6ACAAZABlAHMAYwByAGkA YgBlAGQAIABpAG4AIABbAF0ADQBTAHcAaQB0AGMAaAAgAEMAbwBuAG4AZQBjAHQAaQB2AGkAdAB5 ACAATQBhAHQAcgBpAHgALAAgAFcAYQB2AGUAbABlAG4AZwB0AGgAIABDAG8AbgB2AGUAcgB0AGUA cgAgAFAAbwBvAGwAIABpAG4AZgBvACwAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAQQB2AGEAaQBs AGEAYgBpAGwAaQB0AHkALAAgACAAUABvAHIAdAAgAFcAYQB2AGUAbABlAG4AZwB0AGgAIABSAGUA cwB0AHIAaQBjAHQAaQBvAG4ALAAgAGUAdABjACwALgANAEkAbQBwAGEAaQByAG0AZQBuAHQAIABp AG4AZgBvADoAIABkAGUAcwBjAHIAaQBiAGUAZAAgAGkAbgAgAFsAXQANAA0AVAB3AG8AIAB0AG8A cAAtAFQATABWAHMAIABhAHIAZQAgAGQAZQBmAGkAbgBlAGQAIAB0AG8AIABkAGUAcwBjAHIAaQBi AGUAIABQAEwASQAgACgAUABoAHkAcwBpAGMAYQBsACAATABhAHkAZQByACAASQBtAHAAYQBpAHIA bQBlAG4AdABzACkAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AOgANAEwAaQBuAGsAIABQAEwASQAg AFQATABWACAADQBEAGUAcwBjAHIAaQBiAGUAcwAgAHQAaABlACAAcABoAHkAcwBpAGMAYQBsACAA bABhAHkAZQByACAAaQBtAHAAYQBpAHIAbQBlAG4AdABzACAAcgBlAGwAYQB0AGUAZAAgAHQAbwAg AHQAaABlACAAbABpAG4AawANAE4AbwBkAGUAIABQAEwASQAgAFQATABWAA0ARABlAHMAYwByAGkA YgBlAHMAIAB0AGgAZQAgAHAAaAB5AHMAaQBjAGEAbAAgAGwAYQB5AGUAcgAgAGkAbQBwAGEAaQBy AG0AZQBuAHQAcwAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIAB0AGgAZQAgAG4AbwBkAGUAAAChD+QB AABcAAAAAACyMAoAAgDYAAYAAAAAAYIAFAAHAD0AAAAAACEACgABAAAAAAEHAEwAAAABAKEACgAB AC0AAAAAAQcAIwAAAAAAIQAKAAEAAAAAAQcAeQAAAAEAoQAKAAEALQAAAAABBwAhAAAAAAAhAAoA AQAAAAABBwABAAAAAQChAAoAAQAtAAAAAAEHAFMAAAAAALIwCgACANgABgAAAAABggAUAAcADgAA AAAAszAKAAMA2AAGAAAAAAGCABQABwA9AAAAAQAxMAoAAQAGAAAAAAGCABQABwANAAAAAACzMAoA AwDYAAYAAAAAAYIAFAAHAD0AAAABADEwCgABAAYAAAAAAYIAFAAHAFwAAAAAACIACAAUABMAAAAA BGcAAAQLAAgACwAWAAAA//4qAAAAAARnAAAECwAIAAsAFgAAAAADTAAAAAAIYwAACAsACAALABYA IwAAAAAMZwAADAsACAALABYAAAD//nkAAAAAEGMAABALAAgACwAWACEAAAAAFCYAABQIABQAAAD/ /gEAAAAAGCAAABgIAFMAAAAAHGcAABwLAAgACwAWAAAA//4OAAAAACAgAAAgCAA9AAAAACAiAAAg CAAUAA0AAAAAJCAAACQIAD0AAAAAKCIAACgIABQAAACqD2QAAABvAAAABgAAAAkEBAgqAAAABgAA AAkIBAjoAAAABgAAAAkEBAghAAAABwAAAAAACQQECAkAAAAGAAAACQgECAQAAAAHAAAAAwAJCAQI RwAAAAYAAAAJCAQIlQAAAAYAAAAJBAQIAACmDxAAAAD5AAAA+QEgAUACYAOABKAFDwAE8EgAAAAS AArwCAAAAAHUAwAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCI E5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oB kDd4gQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAiRb/ ////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAByFxAAAAABABAA6OsDAGIAEABW GwQAAAD1DxwAAAAZAQAApBkAA8TrAwCjJgQAAQAAAGgAAAABAMUxDwDoA2YvAAABAOkDKAAAAIAW AADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAABFAAAAAQAAAAAAAAEPAPIDagQAAC8AyA8MAAAAMADS DwQAAAAAAAAADwDVB5ADAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAA aJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A1QcAAAYiEAC3D0QAAABNAFMAIABQAEcAbwB0 AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHgAAGIiAA tw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoL MPCDEwAAAAAADwDVBwAABCIwALcPRAAAANGeU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAA TQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QeGAAYCQAC3D0QAAABGAHIAdQB0AGkAZwBl AHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEIlAA tw9EAAAATlOHZcZ+0Z4AAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoL MPCDEwAAAAAADwDVB4YABgJgALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAeAB0ACAATABUACAA UgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcCAAYCcAC3D0QAAABGAHIAdQB0AGkAZwBl AHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGIoAA tw9EAAAAi1tTTwAAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoL MPCDEwAAAAAADwDVB4YABgKQALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAA QgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQUoAC3D0QAAABUAGkAbQBlAHMAAABl AHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEJLAA tw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABCAG8AbABkAAAAAAByAAAAeDoL MPCDEwAAAAAADwDVBwAABhIAAKQPDAAAAIAAYgAAAAgAAAAUAAAApQ8aAAAAAACzqC4AAwD8AAYA AAAAAQEAMgD5AQcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA AAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAAAUAACABIAEAAAAA AAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBB4SAAAPAADwFhIAAAAABvAg CAAABAgEAAMBAABFAQAAFQAAAAAAAAAPAAAAAgAAAD8AAAALAAAACAAAAAwAAAAEAAAAAAAAABAA AAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAA0AAAAAAAAABAAA AAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAA AAAAIQAAACAAAACSAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAUAAAAAAAAABwAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABwAAAAAAAAAHAAAAAAAA AAcAAAAAAAAABgAAAC0AAABDAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAA BgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAG AAAAAAAAAEIAAAAAAAAAGQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAAPwAAAAkA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAATwAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAACQAAAAAAAABAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAAAwAAAAAAAAAEAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAABZAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAA AAAABAAAAAAAAAD8AAAAAAAAAC8AAABiAAAABAAAAGMAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABrAAAABAAAAAAAAAAmAAAAAAAA ACUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAABxAAAACAAAAAAAAAC1AAAAAAAAAAYAAAB0AAAA +wEAAHUAAABeAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAPIAAAAAAAAA4wAAAAAAAABdAAAAAAAAAKwA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAfAAAAAQAAAB9AAAAQQAAAH4AAABxAQAA AAAAAAYAAAAAAAAABgAAAIEAAAAABAAAAAAAAAYAAACBAAAA6gIAAIMAAAC9AAAAAAAAAAYAAAAA AAAABgAAAAAAAAAEAAAAhwAAABoAAACIAAAABAAAAJ8AAfCMAQAAYgAH8CQAAAAGBgWLNR+9x/ha pvOnUBtimEv/ANMqAAABAAAAAAAAAAAAAABSAAfwJAAAAAUF2PPjBALpLtjj7XCYyT0iFf8ATrYA AAEAAADTKgAAAAAAAFIAB/AkAAAABQVuXl4RjS68ttrj/Ic/k8hg/wAGVwAAAQAAACHhAAAAAAAA YgAH8CQAAAAGBisdnFFBlozbe/74GKTQUnn/AKszAAABAAAAJzgBAAAAAABiAAfwJAAAAAYGPOoZ aAGlT1bU1/i7k1DQSf8A0RUAAAEAAADSawEAAAAAAGIAB/AkAAAABga46WhyF/YLXPj81GTsgmm2 /wC8VgUAAQAAAKOBAQAAAAAAMgAH8CQAAAADBO7btXNqQKC6d3ZzLnFDthX/AEkCAAABAAAAX9gG AAAAAAAyAAfwJAAAAAMEQOvptYDGQz8Z0JsMOdBLJP8AnQIAAAEAAACo2gYAAAAAADIAB/AkAAAA AwSqrbsIEBgFJFUCqAz3dvkF/wBLAgAAAQAAAEXdBgAAAAAAAwgL8AADAACBAGA1AQCCALCaAACD AGA1AQCEALCaAACFAAIAAACHAAEAAACIAAAAAACJAAAAAAC/AAIADwAMAfQAABANAQAAACAOAQAA ACCAAQAAAACBAQQAAAiCAQAAAQCDAQAAAAiEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJ AQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAA AACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACc AQMAAEC/AQwAHgDAAQEAAAjBAQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAA AADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/ AQ4ADgAAAgAAAAABAgIAAAgCAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAA AAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/ AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAA ACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADI AgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIA AADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/ AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAA AACGA3y+AQCHAwAAAABzDSLxCgUAAIwAAQAAAI0AMGUBAH8BAABAAJ4B/////58B/////6ABAAAA IKHBAAAAAKIB/////6MB/////6QBAAAAIKXBAAAAAKYB/////6cB/////78BAAAgANkB/////9oB /////9sBAAAAINzBAAAAAN0B/////94B/////98BAAAAIODBAAAAAOEB/////+IB//////8BAADA ABIC/////xMC/////xQCAAAAIBXCAAAAABYC/////xcC/////xgCAAAAIBnCAAAAABoC/////xsC /////4kC/////4oC/////4sCAAAAIIzCAAAAAI0C/////48DAAAAAJADAgAAAJEDAAAAAJIDAgAA AL8DAIIAgkAFAAAAAEEFAAABAEIF////AEMFAAAAIEQFAAAAAEVFAAAAAEbFAAAAAEcFAAAAAEgF AAAAAEkFAAAAAEoFAAAAAEsFNSUAAEwFAAAIAE0FAAAAAE4FAAAAAE/FAAAAAFAFAAAAAFEFAAAA AFIFAQAAAFMFAQAAAFQFAQAAAFUFAQAAAFcFAgAAAFkF/////1oF/////1sFAAAAIFzFAAAAAF0F /////14F/////18FAAAAIGDFAAAAAGEF/////2IF/////38FBgBOAIAFAAAAAIEFAAABAIIF//// AIMFAAAAIIQFAAAAAIVFAAAAAIbFAAAAAIcFAAAAAIgFAAAAAIkFAAAAAIoFAAAAAIsFNSUAAIwF AAAIAI0FAAAAAI4FAAAAAI/FAAAAAJAFAAAAAJEFAAAAAJIFAQAAAJMFAQAAAJQFAQAAAJUFAQAA AJcFAgAAAJkF/////5oF/////5sFAAAAIJzFAAAAAJ0F/////54F/////58FAAAAIKDFAAAAAKEF /////6IF/////78FBgBOAMAFAAAAAMEFAAABAMIF////AMMFAAAAIMQFAAAAAMVFAAAAAMbFAAAA AMcFAAAAAMgFAAAAAMkFAAAAAMoFAAAAAMsFNSUAAMwFAAAIAM0FAAAAAM4FAAAAAM/FAAAAANAF AAAAANEFAAAAANIFAQAAANMFAQAAANQFAQAAANUFAQAAANcFAgAAANkF/////9oF/////9sFAAAA INzFAAAAAN0F/////94F/////98FAAAAIODFAAAAAOEF/////+IF//////8FBgBOAAAGAAAAAAEG AAABAAIG////AAMGAAAAIAQGAAAAAAVGAAAAAAbGAAAAAAcGAAAAAAgGAAAAAAkGAAAAAAoGAAAA AAsGNSUAAAwGAAAIAA0GAAAAAA4GAAAAAA/GAAAAABAGAAAAABEGAAAAABIGAQAAABMGAQAAABQG AQAAABUGAQAAABcGAgAAABkG/////xoG/////xsGAAAAIBzGAAAAAB0G/////x4G/////x8GAAAA ICDGAAAAACEG/////yIG/////z8GBgBOAEAGAAAAAEEGAAABAEIG////AEMGAAAAIEQGAAAAAEVG AAAAAEbGAAAAAEcGAAAAAEgGAAAAAEkGAAAAAEoGAAAAAEsGNSUAAEwGAAAIAE0GAAAAAE4GAAAA AE/GAAAAAFAGAAAAAFEGAAAAAFIGAQAAAFMGAQAAAFQGAQAAAFUGAQAAAFcGAgAAAFkG/////1oG /////1sGAAAAIFzGAAAAAF0G/////14G/////18GAAAAIGDGAAAAAGEG/////2IG/////38GBgAO AIAAGvEgAAAA/wAAAN3d3QDq6uoA//9mAP+ZAAAAAP8AAJnMAABmmQBAAB7xEAAAAAQAAAj/mQAA AAAAAPcAABAfAPAPjAAAAAAA8wMUAAAAHwAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAACYAAAAE AAAAAAAAAAIAAIAAAAAAAADzAxQAAAAzAAAABAAAAAAAAAAGAACAAAAAAAAA8wMUAAAAMQAAAAQA AAAAAAAABAAAgAAAAAAAAPMDFAAAADwAAAAAAAAAAAAAAAcAAIAAAAAADwDQBz0MAAAfABQEHAAA AAAAFQQUAAAA0BjNBADKmjtOtdw2AMqaOwECAAAPAPoDdwAAAAAA/gMDAAAAAQEAAAD9AzQAAABC AAAAZAAAAEIAAABkAAAAAAAAAPwliBYIhBMAeDoLMAAAAAAAAAAA7vz//7j///8AABMAcAD7AwgA AAAAAAAAPAIAAHAA+wMIAAAAAAAAABwOAABwAPsDCAAAAAEAAAAJAgAAHwD/AxQAAAACAAAEDAAA AAAAAAAAAAAAAgAAAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAAgAAADSEEwD8+Aow aJYTAAAAAAAAAAAAAAAAAAAAAAAAARMADwCIEzILAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQ AFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEB AAABAQEAAQAAAAAAAACI2QAAAAAAAAAAAACAAgHgDwCKE/gIAAAAALoPFgAAAF8AXwBfAFAAUABU AE0AYQBjADEAMQAAAIsT0ggAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAg AAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAA AAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAA AAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4A bwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAA AAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEA AAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAA AAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAA AwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABl ACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAA DgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAA AOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAA AQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAK AEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAA bwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAa AAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAA BAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEE AAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEA bAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBw AGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEA AAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEA AAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA AAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAA AAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAAB BgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAA AAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAA AAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAA AQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAA AAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEG AAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBAAgAAEACvDwgAAAAA AQAABQAAAAAAGRAoAgAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAA AAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAAB AwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAA AAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQA eQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQAR AAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAA CAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAA AAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIA aQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwBy AGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwCK E2gBAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTSAEAAA8A1gcwAQAAAAC3D0QAAABNAFMA IABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAP ANYHgAAGIhAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCE EwDoghMAeDoLMOiCEwAAAAAADwDWBwAABhIgALcPRAAAAItbU08AAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAAAA8A1geGAAYCMAC3D0QAAABBAHIA aQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAP ANYHAAAGIgAADQQIAAAAcLUAAHC1AAAPAIoTSgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsT LAAAAC8AyA8MAAAAMADSDwQAAAAAAAAAAAB7FxAAAAADAAAAqAMAAAMAAwACD///PwDZDwwAAAAA ANoPBAAAAAAAIwBPANkPDAAAAAAA2g8EAAAADQA9AA8A8A9NCwAAAADzAxQAAAADAAAABAAAAAIA AAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA95AAAAT1NQRiBFeHRlbnNpb25zIGluIFN1cHBvcnQg b2YgSW1wYWlybWVudCBBd2FyZSBSb3V0aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQgaW4g V2F2ZWxlbmd0aCBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmtzIAAAoQ8mAAAAegAAAAAAAAAAAHgA AAAAAAIAHAABAAAAAAAAAAEAAAAAAAIAKAAAAKoPMgAAAEUAAAAGAAAACQQJBAEAAAAGAAAACQQE CDMAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAAFAAAAAACoD58AAABDQ0FNUCBXRywg SUVURiA3OHRoLCBNYWFzdHJpY2h0LCBOZXRoZXJsYW5kcyANDWRyYWZ0LWFncmF6LWNjYW1wLXdz b24taW1wYWlybWVudC1vc3BmLTAwLnR4dA0NRmVybmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMu ZWR1KQ1ZYWJpbiBZZSAoeWFiaW4ueWVAaHVhd2VpLmNvbSkAAKEPPgAAAKAAAAAAAAAQAAB4AC8A AAAAAAYAEgAAAAAFLgAAAAAAAgAYAAEAAAABAAYAAQASAAAA//5CAAAAAAACABIAAACqDz4AAAAV AAAABgAAAAkEBAgYAAAABgAAAAkEBAgwAAAABgAAAAkEBAgBAAAABgAAAAkIBAhCAAAABwAAAAAA DAQECA8A8g8YAAAAAADzDxAAAAAAAAAAAAAAAAAAAAAIWAswAADfDwgAAAAVAAAALQAAAAAA8wMU AAAAUwAAAAQAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAEFja25vd2xlZGdtZW50 cwAAoQ8UAAAAEAAAAAAAAAAAABAAAAAAAAIAJAAAAKoPGgAAAA8AAAAGAAAACQQECAEAAAAHAAAA AAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVgAAAAQAAAAB AAAAEQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPFAAAAAsAAAAAAAAA AAALAAAAAAACACQAAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAA8wMUAAAAaAAA AAQAAAACAAAAHwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE9iamVjdGl2ZSAAAKEPHAAAAAsA AAAAAAAAAAAJAAAAAAACACQAAgAAAAAAAAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAE CAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYgAAAAQAAAACAAAA GQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJQAAAE9TUEYgcm91dGluZyBmb3IgSUEtUldBIC1OZXcg UExJIFRMViAAAKEPKgAAACYAAAAAAAAAAAAXAAAAAABDAAsACwAkAA0AAAAAAAIAJAACAAAAAAAA AAAAqg8+AAAAFwAAAAYAAAAJCAQIBQAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQI AQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABX AAAABAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9m IExpbmsgUExJIFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAA AB8AAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4A AAABAAAABwAAAAAABAgJBAAA8wMUAAAAYwAAAAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPIAAAAFRoZSBjb21wb3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAA HwAAAAAAAgAkAAIAAAAAAAAAAACqDz4AAAATAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAA AAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAGQAAAAEAAAAAgAAABsBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABT b21lIHN1Yi1UTFZzIGFuZCBzdWItc3ViLVRMVnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQA AACqD1AAAAAJAAAABgAAAAkEBAgDAAAABwAAAAMACQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJ BAQIBAAAAAcAAAADAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAGUAAAAEAAAAAgAAABwBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQ YXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5rIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAA AAACACQAAACqDxoAAAAkAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8O AAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGYAAAAEAAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAA AACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAA AAAAAAAlAAAAAAACACQAAACqDzIAAAAYAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkE CQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AGcAAAAEAAAAAgAAAB4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNv bXBvbmVudCBUTFYAAKEPFAAAABwAAAAAAAAAAAAcAAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkE BAgQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAI AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAATmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsA AAAAAAIAJAAAAKoPDAAAAAsAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0 IGFjY29yZGluZyB0byB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxp c3QNS2VlcCB1cGdyYWRpbmcgd2hlbiBJVFUtVCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJt ZW50IGluZm9ybWF0aW9uDUNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEPMgAAAIsA AAAAAAAAAAAgAAAAAAAAIAAAMgAbAAAAAABhAAsAAAALAJAAAAAABEEAAAQLAAsAAACqDxoAAACq AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A8A84AAAAAADzAxQAAAAGAAAAAAAAAAAAAAAAAQAA AAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEAAAAAAAAAAOoDAAAAAA8A7gNXCwAAAgDvAxgAAAAB AAAADQ4AAAAAAAAHAACAAAAAAAcACzAPAAwEbgoAAA8AAvBmCgAAwAcI8AgAAAADAAAAA9QDAA8A A/D+CQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADUAwAFAAAADwAE 8HgAAAASAArwCAAAAALUAwAgAgAAYwAL8CQAAAB/AAAABACAAMQlYRO/AQAAAQD/AQAAAQABAwIA AwCIAwAAAAAAABDwCAAAAHcA3AEcFpcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAGETDwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwRgkAABIACvAIAAAAA9QDAAAKAADzAAvwWgAAAH8AAAAEAIAAAIWvD4EA YDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAO AAECAgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADyAmQCLBXaCg8AEfDAAAAADwCIE7gAAAAP AIoTsAAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTkgAAAAAArA+KAAAAAAAAAAAAAAAAAAAA AAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADwAN8LYHAAAAAJ8PBAAAAAQAAAAAAKAPHgUAAEkAbgAgAEcATQBQAEwAUwAt AGIAYQBzAGUAZAAgAFcAUwBPAE4AIABuAGUAdAB3AG8AcgBrAHMALAAgAHQAaABlACAAZgBvAGwA bABvAHcAaQBuAGcAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABuAGUAZQBkACAAdABvACAAYgBl ACAAZgBsAG8AbwBkAGUAZAAgAHQAaAByAG8AdQBnAGgAIAByAG8AdQB0AGkAbgBnADoADQBOAG8A cgBtAGEAbAAgAHIAbwB1AHQAaQBuAGcAIABpAG4AZgBvADoAIABkAGUAcwBjAHIAaQBiAGUAZAAg AGkAbgAgAFsAUgBGAEMAIAAzADYAMwAwAF0AIABhAG4AZAAgAFsAUgBGAEMAIAA0ADIAMAAzAF0A LgANAE4AbwBkAGUAIABJAEQALAAgAEwAaQBuAGsAIABJAEQALAAgAEEAZABtAGkAbgBpAHMAdABy AGEAdABpAHYAZQAgAEcAcgBvAHUAcAAsACAASQBTAEMARAAsACAAUAByAG8AdABlAGMAdABpAG8A bgAsACAAUwBSAEwARwAsACAAVABFACAAbQBlAHQAcgBpAGMALAAgACYgDQBXAFMATwBOACAAcwBw AGUAYwBpAGEAbAAgAGkAbgBmAG8AOgAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAAWwBdAA0A UwB3AGkAdABjAGgAIABDAG8AbgBuAGUAYwB0AGkAdgBpAHQAeQAgAE0AYQB0AHIAaQB4ACwAIABX AGEAdgBlAGwAZQBuAGcAdABoACAAQwBvAG4AdgBlAHIAdABlAHIAIABQAG8AbwBsACAAaQBuAGYA bwAsACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAEEAdgBhAGkAbABhAGIAaQBsAGkAdAB5ACwAIAAg AFAAbwByAHQAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAUgBlAHMAdAByAGkAYwB0AGkAbwBuACwA IABlAHQAYwAsAC4ADQBJAG0AcABhAGkAcgBtAGUAbgB0ACAAaQBuAGYAbwA6ACAAdABoAGkAcwAg AGQAcgBhAGYAdAAgAGkAbgB2AG8AbAB2AGUAZAANAAkAVAB3AG8AIAB0AG8AcAAtAFQATABWAHMA IABhAHIAZQAgAGQAZQBmAGkAbgBlAGQAIAB0AG8AIABkAGUAcwBjAHIAaQBiAGUAIABQAEwASQAg ACgAUABoAHkAcwBpAGMAYQBsACAATABhAHkAZQByACAASQBtAHAAYQBpAHIAbQBlAG4AdABzACkA IABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AOgANAEwAaQBuAGsAIABQAEwASQAgAFQATABWACAADQBE AGUAcwBjAHIAaQBiAGUAcwAgAHQAaABlACAAcABoAHkAcwBpAGMAYQBsACAAbABhAHkAZQByACAA aQBtAHAAYQBpAHIAbQBlAG4AdABzACAAcgBlAGwAYQB0AGUAZAAgAHQAbwAgAHQAaABlACAAbABp AG4AawANAE4AbwBkAGUAIABQAEwASQAgAFQATABWAA0ARABlAHMAYwByAGkAYgBlAHMAIAB0AGgA ZQAgAHAAaAB5AHMAaQBjAGEAbAAgAGwAYQB5AGUAcgAgAGkAbQBwAGEAaQByAG0AZQBuAHQAcwAg AHIAZQBsAGEAdABlAGQAIAB0AG8AIAB0AGgAZQAgAG4AbwBkAGUAAAChD+wBAABcAAAAAACyMAoA AgDYAAYAAAAAAYIAFAAHAD0AAAAAACEACgABAAAAAAEHAE0AAAABAPsACgALAGwABgBBAAAAAAEH ACMAAAAAACEACgABAAAAAAEHAHkAAAABAPsACgALAGwABgA3AAAAAAEHACUAAAAAACEACgABAAAA AAEHAFQAAAAAALIwCgACANgABgAAAAABggAUAAcADgAAAAAAsyAKAAMA2AAGAAAAAAEUAAcAPQAA AAEAMSAKAAEABgAAAAABFAAHAA0AAAAAALMgCgADANgABgAAAAABFAAHAD0AAAABADEgCgABAAYA AAAAARQABwBcAAAAAAAiAAgAFAATAAAAAARnAAAECwAIAAsAFgAAAP/+KgAAAAAEZwAABAsACAAL ABYAAAAAA00AAAAACGMAAAgLAAgACwAWACMAAAAADGcAAAwLAAgACwAWAAAA//55AAAAABBjAAAQ CwAIAAsAFgAkAAAAABQmAAAUCAAUAAAA//4BAAAAABQgAAAUCABUAAAAABhnAAAYCwAIAAsAFgAA AP/+DAAAAAAcYwAAHAsACAALABYAAgAAAAAcIAAAHAgAPQAAAAAcYwAAHAsACAALABYADQAAAAAg YwAAIAsACAALABYAPQAAAAAkIgAAJAgAFAAAAKoPcAAAAG8AAAAGAAAACQQECCoAAAAGAAAACQgE CCEAAAAGAAAACQQECAsAAAAHAAAAAAAJBAQI4QAAAAYAAAAJBAQICgAAAAYAAAAJCAQIBAAAAAcA AAADAAkIBAhHAAAABgAAAAkIBAiVAAAABgAAAAkEBAgAAKYPEAAAAPkAAAD5ASABQAJgA4AEoAUP AATwSAAAABIACvAIAAAAAdQDAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu CAAAAHVXygGQN3iBAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAACJFv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXEAAAAAEAEADf JgQAYgAQAE1WBAAAAPUPHAAAABkBAACkGQADuyYEAKxhBAABAAAAaAAAAAEAxTEPAOgDti8AAAEA 6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABQAAAEUAAAABAAAAAAAAAQ8A8gNqBAAALwDI DwwAAAAwANIPBAAAAAAAAAAPANUHkAMAAAAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8A bQBhAG4AAABolhMAaJYTAOSEiBbwgxMAeDoLMPCDEwAAAAAADwDVBwAABiIQALcPRAAAAE0AUwAg AFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A 1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBt AAAAEwB4Ogsw8IMTAAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVB4YABgJAALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAQiUAC3D0QAAABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABh AHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAB4AHQA IABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVBwIABgJwALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAYigAC3D0QAAACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAA AHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABBSgALcPRAAAAFQAaQBt AGUAcwAAAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAQksAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAEIAbwBsAGQAAAAA AHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAACAAAABQAAAClDxoAAAAAALOo LgADAPwABgAAAAABAQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAi IAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEHhIAAA8AAPAW EgAAAAAG8CAIAAAECAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAAPwAAAAsAAAAIAAAADAAAAAQA AAAAAAAAEAAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAA AAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAA AAAABAAAAAAAAAAhAAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABQAAAAAA AAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAHAAAAAAAA AAcAAAAAAAAABwAAAAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAA BgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAH AAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAQA AAA/AAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABPAAAADAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACwAAAAAAAAAEAAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAAYwAAAAYAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAGsAAAAEAAAAAAAA ACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEAAAAIAAAAAAAAALUAAAAAAAAA BgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAh AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA8gAAAAAAAADjAAAAAAAAAF0A AAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAB8AAAABAAAAH0AAABBAAAA fgAAAHEBAAAAAAAABgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAAAIEAAADqAgAAgwAAAL0AAAAA AAAABgAAAAAAAAAGAAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAAnwAB8IwBAABiAAfwJAAAAAYG BYs1H73H+Fqm86dQG2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/AkAAAABQXY8+MEAuku2OPtcJjJ PSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/AAZXAAABAAAA IeEAAAAAAABiAAfwJAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMAAAEAAAAnOAEAAAAAAGIAB/Ak AAAABgY86hloAaVPVtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAAYgAH8CQAAAAGBrjpaHIX9gtc +PzUZOyCabb/ALxWBQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1c2pAoLp3dnMucUO2Ff8ASQIA AAEAAABf2AYAAAAAADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk/wCdAgAAAQAAAKjaBgAAAAAA MgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0GAAAAAAADCAvwAAMAAIEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAPAAwB9AAAEA0B AAAAIA4BAAAAIIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAA AIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEB AAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAA AJsBAAAAAJwBAwAAQL8BDAAeAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbB AAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAA ANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcC AAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAA ABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC 9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAA AMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9AC AAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcA ANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQD fL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAwZQEAfwEAAEAAngH/////nwH/ ////oAEAAAAgocEAAAAAogH/////owH/////pAEAAAAgpcEAAAAApgH/////pwH/////vwEAACAA 2QH/////2gH/////2wEAAAAg3MEAAAAA3QH/////3gH/////3wEAAAAg4MEAAAAA4QH/////4gH/ /////wEAAMAAEgL/////EwL/////FAIAAAAgFcIAAAAAFgL/////FwL/////GAIAAAAgGcIAAAAA GgL/////GwL/////iQL/////igL/////iwIAAAAgjMIAAAAAjQL/////jwMAAAAAkAMCAAAAkQMA AAAAkgMCAAAAvwMAggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAgRAUAAAAARUUAAAAARsUAAAAA RwUAAAAASAUAAAAASQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUAAAAATgUAAAAAT8UAAAAAUAUA AAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAAWQX/////WgX/////WwUAAAAg XMUAAAAAXQX/////XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/////fwUGAE4AgAUAAAAAgQUA AAEAggX///8AgwUAAAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAAiAUAAAAAiQUAAAAAigUAAAAA iwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUAAAAAkgUBAAAAkwUBAAAAlAUB AAAAlQUBAAAAlwUCAAAAmQX/////mgX/////mwUAAAAgnMUAAAAAnQX/////ngX/////nwUAAAAg oMUAAAAAoQX/////ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX///8AwwUAAAAgxAUAAAAAxUUA AAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAAzAUAAAgAzQUAAAAAzgUAAAAA z8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUBAAAA1wUCAAAA2QX/////2gX/ ////2wUAAAAg3MUAAAAA3QX/////3gX/////3wUAAAAg4MUAAAAA4QX/////4gX//////wUGAE4A AAYAAAAAAQYAAAEAAgb///8AAwYAAAAgBAYAAAAABUYAAAAABsYAAAAABwYAAAAACAYAAAAACQYA AAAACgYAAAAACwY1JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAAEAYAAAAAEQYAAAAAEgYBAAAA EwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAAGQb/////Ggb/////GwYAAAAgHMYAAAAAHQb/////Hgb/ ////HwYAAAAgIMYAAAAAIQb/////Igb/////PwYGAE4AQAYAAAAAQQYAAAEAQgb///8AQwYAAAAg RAYAAAAARUYAAAAARsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYAAAAASwY1JQAATAYAAAgATQYA AAAATgYAAAAAT8YAAAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAAVAYBAAAAVQYBAAAAVwYCAAAA WQb/////Wgb/////WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYAAAAgYMYAAAAAYQb/////Ygb/ ////fwYGAA4AgAAa8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA/wAAmcwAAGaZAEAAHvEQAAAA BAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAAAAAAAAABAACAAAAAAAAA8wMU AAAAJgAAAAQAAAAAAAAAAgAAgAAAAAAAAPMDFAAAADMAAAAEAAAAAAAAAAYAAIAAAAAAAADzAxQA AAAxAAAABAAAAAAAAAAEAACAAAAAAAAA8wMUAAAAPAAAAAAAAAAAAAAABwAAgAAAAAAPANAHeQwA AB8AFAQcAAAAAAAVBBQAAADQGM0EAMqaO0613DYAypo7AQIAAA8A+gN3AAAAAAD+AwMAAAABAQAA AP0DNAAAAEIAAABkAAAAQgAAAGQAAAAAAAAA/CWIFgiEEwB4OgswAAAAAAAAAADu/P//Cv///wAA EwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMIAAAAAQAAAAkCAAAfAP8DFAAA AAIAAAQMAAAAAAAAAAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAAACAAAA NIQTAPz4CjBolhMAAAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTbgsAAA8AihNoAAAAAAC6DxQAAABf AF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgC AAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAPAIoT+AgAAAAAug8WAAAAXwBf AF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoA QQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABv AGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoA AQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAE AAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQA AAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBs AAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAA aAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAA AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAbEEACAAAQ AK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAA AAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAA AQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAED AAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAA AAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5 AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEA AAAaAAEPAIoTaAEAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNIAQAADwDWBzABAAAAALcP RAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDo ghMAAAAAAA8A1geAAAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGiW EwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGEiAAtw9EAAAAi1tTTwAAZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWB4YABgIwALcP RAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDo ghMAAAAAAA8A1gcAAAYiAAANBAgAAABwtQAAcLUAAA8AihOGAAAAAAC6Dw4AAABfAF8AXwBQAFAA VAA5AAAAixNoAAAALwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAAAAMAAACoAwAAAwADAAIP//8P AK4PNAAAABAArw8IAAAACAEAAAEAAAAAAKwPHAAAAAAAAAIAAAAAAAAAAAAAAAAAAgAAAAAAAAAA AAA/ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDwD2ELAAAAAPMDFAAA AAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD3kAAABPU1BGIEV4dGVuc2lvbnMg aW4gU3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5ndGggQXNz aWdubWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgAAChDyYAAAB6 AAAAAAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAAqg8yAAAARQAAAAYAAAAJBAkE AQAAAAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAUAAAAAAKgPnwAA AENDQU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0cmljaHQsIE5ldGhlcmxhbmRzIA0NZHJhZnQtYWdy YXotY2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9zcGYtMDAudHh0DQ1GZXJuYW5kbyBBZ3JheiAoYWdy YXpAdHNjLnVwYy5lZHUpDVlhYmluIFllICh5YWJpbi55ZUBodWF3ZWkuY29tKQAAoQ8+AAAAoAAA AAAAABAAAHgALwAAAAAABgASAAAAAAUuAAAAAAACABgAAQAAAAEABgABABIAAAD//kIAAAAAAAIA EgAAAKoPPgAAABUAAAAGAAAACQQECBgAAAAGAAAACQQECDAAAAAGAAAACQQECAEAAAAGAAAACQgE CEIAAAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhYCzAAAN8PCAAAABUA AAAtAAAAAADzAxQAAABTAAAABAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8PAAAAQWNr bm93bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAkAAAAqg8aAAAADwAAAAYAAAAJ BAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQA AABWAAAABAAAAAEAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAQmFja2dyb3VuZAAAoQ8U AAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkE AADzAxQAAABoAAAABAAAAAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAAT2JqZWN0aXZl IAAAoQ8cAAAACwAAAAAAAAAAAAkAAAAAAAIAJAACAAAAAAAAAAAAqg8aAAAACgAAAAYAAAAJBAQI AQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABi AAAABAAAAAIAAAAZAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAAT1NQRiByb3V0aW5nIGZvciBJ QS1SV0EgLU5ldyBQTEkgVExWIAAAoQ8qAAAAJgAAAAAAAAAAABcAAAAAAEMACwALACQADQAAAAAA AgAkAAIAAAAAAAAAAACqDz4AAAAXAAAABgAAAAkIBAgFAAAABgAAAAkEBAgIAAAABgAAAAkECQQB AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQAAPMDFAAAAFcAAAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABUaGUgY29t cG9zaXRpb24gb2YgTGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIAJAACAAAA AAAAAAAAqg8mAAAAHwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAABAAAAAIAAAAaAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5vZGUgUExJIFRMViAAAKEPHAAA ACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMAAAAGAAAACQQJBAQAAAAGAAAA CQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACq Dw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAAGwEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPHgAAAFNvbWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExWcwAAoQ8UAAAAHwAAAAAAAAAA AB8AAAAAAAIAJAAAAKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAAAwAJBAkEAQAAAAcAAAADAAkE BAgNAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACq Dw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAAHAEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsgUExJIFRMVgAAoQ8UAAAAJQAA AAAAAAAAACUAAAAAAAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQA AAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAAAAQAAAACAAAAHQEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIE5vZGUgUExJIFRMVgAA oQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAGAAAACQQJBAQAAAAGAAAACQQE CAgAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAA BAgJBAAA8wMUAAAAZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGwAAAEFuIEV4 YW1wbGUgb2YgY29tcG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAAABwAAAAAAAIAJAAAAKoPDAAA ABwAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAEQA AAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABOZXh0IFN0ZXBzAAChDxQAAAAL AAAAAAAAAAAACwAAAAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACoD6oA AABSZWZpbmUgaXQgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBtZWV0aW5nIG9y IG1haWxpbmcgbGlzdA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1UIGRlZmluZWQgdGhlIHN0YW5k YXJkIGltcGFpcm1lbnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJlIGFsd2F5cyBhcHByZWNpYXRl ZAAAoQ9GAAAAiwAAAAAAsgAAAAMA2AAGAAAAAAEgAAAAAACyIAAAAwDYAAYAAAAAATIAGwAAAAAA YQALAAAACwCQAAAAAARBAAAECwALAAAAqg8aAAAAqgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQv APAPOAAAAAAA8wMUAAAABgAAAAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAE0AAAAAAAAAAAAAAAgB AAAAAAAAAADqAwAAAAAPAO4D9QoAAAIA7wMYAAAAAQAAAA0OAAAAAAAABwAAgAAAAAAHAAswDwAM BAwKAAAPAALwBAoAAMAHCPAIAAAAAwAAAAPUAwAPAAPwnAkAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAA1AMABQAAAA8ABPB4AAAAEgAK8AgAAAAC1AMAIAIAAGMAC/Ak AAAAfwAAAAQAgADEJWETvwEAAAEA/wEAAAEAAQMCAAMAiAMAAAAAAAAQ8AgAAAB3ANwBHBaXAg8A EfAQAAAAAADDCwgAAAAAAAAADQBhEw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8OQIAAASAArwCAAA AAPUAwAACgAA8wAL8FoAAAB/AAAABACAAACFrw+BAGA1AQCCALCaAACDAGA1AQCEALCaAAC/AAAA DwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAA AH8BAABAAL8BAABgAP8BAADAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAA8gJkAiwV2goPABHwtAAAAA8AiBOsAAAADwCKE6QAAAAAALoPDgAAAF8AXwBfAFAAUABU ADkAAACLE4YAAAAAAKwPfgAAAAAAAAAAAAAAAAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMBAAwAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ADfBgBwAAAACfDwQAAAAEAAAAAACgDx4F AABJAG4AIABHAE0AUABMAFMALQBiAGEAcwBlAGQAIABXAFMATwBOACAAbgBlAHQAdwBvAHIAawBz ACwAIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAA bgBlAGUAZAAgAHQAbwAgAGIAZQAgAGYAbABvAG8AZABlAGQAIAB0AGgAcgBvAHUAZwBoACAAcgBv AHUAdABpAG4AZwA6AA0ATgBvAHIAbQBhAGwAIAByAG8AdQB0AGkAbgBnACAAaQBuAGYAbwA6ACAA ZABlAHMAYwByAGkAYgBlAGQAIABpAG4AIABbAFIARgBDACAAMwA2ADMAMABdACAAYQBuAGQAIABb AFIARgBDACAANAAyADAAMwBdAC4ADQBOAG8AZABlACAASQBEACwAIABMAGkAbgBrACAASQBEACwA IABBAGQAbQBpAG4AaQBzAHQAcgBhAHQAaQB2AGUAIABHAHIAbwB1AHAALAAgAEkAUwBDAEQALAAg AFAAcgBvAHQAZQBjAHQAaQBvAG4ALAAgAFMAUgBMAEcALAAgAFQARQAgAG0AZQB0AHIAaQBjACwA IAAmIA0AVwBTAE8ATgAgAHMAcABlAGMAaQBhAGwAIABpAG4AZgBvADoAIABkAGUAcwBjAHIAaQBi AGUAZAAgAGkAbgAgAFsAXQANAFMAdwBpAHQAYwBoACAAQwBvAG4AbgBlAGMAdABpAHYAaQB0AHkA IABNAGEAdAByAGkAeAAsACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAEMAbwBuAHYAZQByAHQAZQBy ACAAUABvAG8AbAAgAGkAbgBmAG8ALAAgAFcAYQB2AGUAbABlAG4AZwB0AGgAIABBAHYAYQBpAGwA YQBiAGkAbABpAHQAeQAsACAAIABQAG8AcgB0ACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAFIAZQBz AHQAcgBpAGMAdABpAG8AbgAsACAAZQB0AGMALAAuAA0ASQBtAHAAYQBpAHIAbQBlAG4AdAAgAGkA bgBmAG8AOgAgAHQAaABpAHMAIABkAHIAYQBmAHQAIABpAG4AdgBvAGwAdgBlAGQADQAJAFQAdwBv ACAAdABvAHAALQBUAEwAVgBzACAAYQByAGUAIABkAGUAZgBpAG4AZQBkACAAdABvACAAZABlAHMA YwByAGkAYgBlACAAUABMAEkAIAAoAFAAaAB5AHMAaQBjAGEAbAAgAEwAYQB5AGUAcgAgAEkAbQBw AGEAaQByAG0AZQBuAHQAcwApACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuADoADQBMAGkAbgBrACAA UABMAEkAIABUAEwAVgAgAC0ARABlAHMAYwByAGkAYgBlAHMAIAB0AGgAZQAgAHAAaAB5AHMAaQBj AGEAbAAgAGwAYQB5AGUAcgAgAGkAbQBwAGEAaQByAG0AZQBuAHQAcwAgAHIAZQBsAGEAdABlAGQA IAB0AG8AIAB0AGgAZQAgAGwAaQBuAGsADQBOAG8AZABlACAAUABMAEkAIABUAEwAVgANAEQAZQBz AGMAcgBpAGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwAIABsAGEAeQBlAHIAIABpAG0A cABhAGkAcgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABvACAAdABoAGUAIABuAG8AZABl AAAAoQ+wAQAAXAAAAAAAsjAKAAIA2AAGAAAAAAGCABQABwA9AAAAAAAhAAoAAQAAAAABBwBNAAAA AQD7AAoACwBsAAYANwAAAAABBwAjAAAAAAAhAAoAAQAAAAABBwB5AAAAAQD7AAoACwBsAAYANwAA AAABBwAlAAAAAAAhAAoAAQAAAAABBwBUAAAAAACyMAoAAgDYAAYAAAAAAYIAFAAHAEsAAAAAAPsA CgALAGwABgA3AAAAAAEHAA0AAAAAALMgCgADANgABgAAAAABFAAHAD0AAAABADEgCgABAAYAAAAA ARQABwBcAAAAAAAiAAgAFAAUAAAAAARjAAAECwAIAAsAFgApAAAAAARnAAAECwAIAAsAFgAAAAAD TQAAAAAIYwAACAsACAALABYAIwAAAAAMYwAADAsACAALABYAeQAAAAAQYwAAEAsACAALABYAJAAA AAAUJgAAFAgAFAAAAP/+AQAAAAAUIAAAFAgAAQAAAAAYZwAAGAsACAALABYAAAD//p4AAAAAGGMA ABgLAAgACwAWAA0AAAAAHGMAABwLAAgACwAWAD0AAAAAICIAACAIABQAAACqD1YAAABvAAAABgAA AAkEBAgqAAAABgAAAAkIBAgNAQAABgAAAAkEBAgKAAAABgAAAAkIBAgEAAAABwAAAAMACQgECEcA AAAGAAAACQgECJUAAAAGAAAACQQECAAApg8QAAAA+QAAAPkBIAFAAmADgASgBQ8ABPBIAAAAEgAK 8AgAAAAB1AMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBOR AAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAZA3 eIEAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAIkW//// /xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gN9AgAAAgDvAxgAAAABAAAADQ4A AAAAAAAHAACACAEAAAcACzAPAAwElAEAAA8AAvCMAQAAIAYI8AgAAAADAAAAAyQDAA8AA/AkAQAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAwAFAAAADwAE8HIAAAAS AArwCAAAAAIkAwAgAgAAUwAL8B4AAAB/AAAABACAADjGhha/AQAAAQD/AQAAAQABAwIAAwAAABDw CAAAAK0AIAFgFTwCDwAR8BAAAAAAAMMLCAAAAAAAAAANAIYWDwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwcgAAABIACvAIAAAAAyQDACACAABTAAvwHgAAAH8AAAAEAIAAlMaGFr8BAAABAP8BAAABAAED AwADAAAAEPAIAAAA1QMwAocVlgwPABHwEAAAAAAAwwsIAAAAAQAAAA4AhhYPAA3wDAAAAAAAng8E AAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABJAMAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sA lAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+Dj ADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT aQAAAAAA6y4IAAAAXQTKAXB+UuEAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAA AAAAAAAAAAAAAAAAAIkW/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchcY AAAAAQAQAOhhBABEABAAo5wEAGIAEACmkQQAAAD1DxwAAAAIAQAApBkAA8RhBAAonwQAAQAAAGgA AAABAMUxDwDoA7YvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAABFAAAAAQAA AAAAAAEPAPIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5ADAAAAALcPRAAAAEEAcgBpAGEA bAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A1QcA AAYiEAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMA5ISIFvCD EwB4Ogsw8IMTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABM AFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVBwAABCIwALcPRAAAANGeU08AAHQA aQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A1QeG AAYCQAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIA AAB4Ogsw8IMTAAAAAAAPANUHAAAEIlAAtw9EAAAATlOHZcZ+0Z4AAGcAZQByAE4AZQB4AHQAIABM AFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVB4YABgJgALcPRAAAAFcAaQBuAGcA ZABpAG4AZwBzAAAAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcC AAYCcAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIA AAB4Ogsw8IMTAAAAAAAPANUHAAAGIoAAtw9EAAAAi1tTTwAAdABpAGcAZQByAE4AZQB4AHQAIABM AFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAADwDVB4YABgKQALcPRAAAAEYAcgB1AHQA aQBnAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcA AAQUoAC3D0QAAABUAGkAbQBlAHMAAABlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAAAHIA AAB4Ogsw8IMTAAAAAAAPANUHAAAEJLAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBh AG4AAABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABhIAAKQPDAAAAIAAYgAAAAgA AAAUAAAApQ8aAAAAAACzqC4AAwD8AAYAAAAAAQEAMgD5AQcAAAAAAKkPCgAAAAcAAAACAAkEAABA AKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEA AAD//xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQA AAAADwALBB4SAAAPAADwFhIAAAAABvAgCAAABAgEAAMBAABFAQAAFQAAAAAAAAAPAAAAAgAAAD8A AAALAAAACAAAAAwAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAAEwAA AAAAAAAEAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAA AAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkAAAAA AAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAACAAAACSAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAIAAAAAAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAC0AAABDAAAAAAAAAAQAAAAAAAAA BgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAG AAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAAAAAAAEIAAAAAAAAAGQAAAAAAAAAEAAAAAAAAAAoA AAAAAAAABAAAAAAAAAAEAAAAPwAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAA0AAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAATwAA AAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAAAABAAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAMAAAAAAAAAAwAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABZAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAAAAAAD8AAAAAAAAAC8AAABiAAAABAAAAGMA AAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAABrAAAABAAAAAAAAAAmAAAAAAAAACUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAABxAAAA CAAAAAAAAAC1AAAAAAAAAAYAAAB0AAAA+wEAAHUAAABeAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAF AAAAAAAAAAQAAAAAAAAAIQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAPIA AAAAAAAA4wAAAAAAAABdAAAAAAAAAKwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAA fAAAAAQAAAB9AAAAQQAAAH4AAABxAQAAAAAAAAYAAAAAAAAABgAAAIEAAAAABAAAAAAAAAYAAACB AAAA6gIAAIMAAAC9AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAhwAAABoAAACIAAAABAAAAJ8A AfCMAQAAYgAH8CQAAAAGBgWLNR+9x/hapvOnUBtimEv/ANMqAAABAAAAAAAAAAAAAABSAAfwJAAA AAUF2PPjBALpLtjj7XCYyT0iFf8ATrYAAAEAAADTKgAAAAAAAFIAB/AkAAAABQVuXl4RjS68ttrj /Ic/k8hg/wAGVwAAAQAAACHhAAAAAAAAYgAH8CQAAAAGBisdnFFBlozbe/74GKTQUnn/AKszAAAB AAAAJzgBAAAAAABiAAfwJAAAAAYGPOoZaAGlT1bU1/i7k1DQSf8A0RUAAAEAAADSawEAAAAAAGIA B/AkAAAABga46WhyF/YLXPj81GTsgmm2/wC8VgUAAQAAAKOBAQAAAAAAMgAH8CQAAAADBO7btXNq QKC6d3ZzLnFDthX/AEkCAAABAAAAX9gGAAAAAAAyAAfwJAAAAAMEQOvptYDGQz8Z0JsMOdBLJP8A nQIAAAEAAACo2gYAAAAAADIAB/AkAAAAAwSqrbsIEBgFJFUCqAz3dvkF/wBLAgAAAQAAAEXdBgAA AAAAAwgL8AADAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAACIAAAAAACJAAAA AAC/AAIADwAMAfQAABANAQAAACAOAQAAACCAAQAAAACBAQQAAAiCAQAAAQCDAQAAAAiEAQAAAQCF AQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAA AACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACY AQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDAAQEAAAjBAQAAAQDCAf///wDDAQAA ACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADN AQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgCAsvLywADAgAAACAEAgAA AQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAO AgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAA AACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADE AgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBU iQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADX ArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+ AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAABzDSLxCgUAAIwAAQAAAI0AMGUB AH8BAABAAJ4B/////58B/////6ABAAAAIKHBAAAAAKIB/////6MB/////6QBAAAAIKXBAAAAAKYB /////6cB/////78BAAAgANkB/////9oB/////9sBAAAAINzBAAAAAN0B/////94B/////98BAAAA IODBAAAAAOEB/////+IB//////8BAADAABIC/////xMC/////xQCAAAAIBXCAAAAABYC/////xcC /////xgCAAAAIBnCAAAAABoC/////xsC/////4kC/////4oC/////4sCAAAAIIzCAAAAAI0C//// /48DAAAAAJADAgAAAJEDAAAAAJIDAgAAAL8DAIIAgkAFAAAAAEEFAAABAEIF////AEMFAAAAIEQF AAAAAEVFAAAAAEbFAAAAAEcFAAAAAEgFAAAAAEkFAAAAAEoFAAAAAEsFNSUAAEwFAAAIAE0FAAAA AE4FAAAAAE/FAAAAAFAFAAAAAFEFAAAAAFIFAQAAAFMFAQAAAFQFAQAAAFUFAQAAAFcFAgAAAFkF /////1oF/////1sFAAAAIFzFAAAAAF0F/////14F/////18FAAAAIGDFAAAAAGEF/////2IF//// /38FBgBOAIAFAAAAAIEFAAABAIIF////AIMFAAAAIIQFAAAAAIVFAAAAAIbFAAAAAIcFAAAAAIgF AAAAAIkFAAAAAIoFAAAAAIsFNSUAAIwFAAAIAI0FAAAAAI4FAAAAAI/FAAAAAJAFAAAAAJEFAAAA AJIFAQAAAJMFAQAAAJQFAQAAAJUFAQAAAJcFAgAAAJkF/////5oF/////5sFAAAAIJzFAAAAAJ0F /////54F/////58FAAAAIKDFAAAAAKEF/////6IF/////78FBgBOAMAFAAAAAMEFAAABAMIF//// AMMFAAAAIMQFAAAAAMVFAAAAAMbFAAAAAMcFAAAAAMgFAAAAAMkFAAAAAMoFAAAAAMsFNSUAAMwF AAAIAM0FAAAAAM4FAAAAAM/FAAAAANAFAAAAANEFAAAAANIFAQAAANMFAQAAANQFAQAAANUFAQAA ANcFAgAAANkF/////9oF/////9sFAAAAINzFAAAAAN0F/////94F/////98FAAAAIODFAAAAAOEF /////+IF//////8FBgBOAAAGAAAAAAEGAAABAAIG////AAMGAAAAIAQGAAAAAAVGAAAAAAbGAAAA AAcGAAAAAAgGAAAAAAkGAAAAAAoGAAAAAAsGNSUAAAwGAAAIAA0GAAAAAA4GAAAAAA/GAAAAABAG AAAAABEGAAAAABIGAQAAABMGAQAAABQGAQAAABUGAQAAABcGAgAAABkG/////xoG/////xsGAAAA IBzGAAAAAB0G/////x4G/////x8GAAAAICDGAAAAACEG/////yIG/////z8GBgBOAEAGAAAAAEEG AAABAEIG////AEMGAAAAIEQGAAAAAEVGAAAAAEbGAAAAAEcGAAAAAEgGAAAAAEkGAAAAAEoGAAAA AEsGNSUAAEwGAAAIAE0GAAAAAE4GAAAAAE/GAAAAAFAGAAAAAFEGAAAAAFIGAQAAAFMGAQAAAFQG AQAAAFUGAQAAAFcGAgAAAFkG/////1oG/////1sGAAAAIFzGAAAAAF0G/////14G/////18GAAAA IGDGAAAAAGEG/////2IG/////38GBgAOAIAAGvEgAAAA/wAAAN3d3QDq6uoA//9mAP+ZAAAAAP8A AJnMAABmmQBAAB7xEAAAAAQAAAj/mQAAAAAAAPcAABAfAPAPjAAAAAAA8wMUAAAAHwAAAAQAAAAA AAAAAQAAgAAAAAAAAPMDFAAAACYAAAAEAAAAAAAAAAIAAIAAAAAAAADzAxQAAAAzAAAABAAAAAAA AAAGAACAAAAAAAAA8wMUAAAAMQAAAAQAAAAAAAAABAAAgAAAAAAAAPMDFAAAADwAAAAAAAAAAAAA AAcAAIAAAAAADwDQB3kMAAAfABQEHAAAAAAAFQQUAAAA0BjNBADKmjtOtdw2AMqaOwECAAAPAPoD dwAAAAAA/gMDAAAAAQEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAAAAAAPwliBYIhBMAeDoLMAAA AAAAAAAA7vz//wr///8AABMAcAD7AwgAAAAAAAAAPAIAAHAA+wMIAAAAAAAAABwOAABwAPsDCAAA AAEAAAAJAgAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8AEwQ8AAAAAAD9AzQAAABkAAAA ZAAAAGQAAABkAAAAAgAAADSEEwD8+AowaJYTAAAAAAAAAAAAAAAAAAAAAAAAARMADwCIE24LAAAP AIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJFzQA AAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAACI2QAAAAAAAAAAAACAAgHgDwCK E/gIAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0ggAAEAAGhBmBQAABQAAAAAI DAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAA AAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAA AAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAA CAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIA AAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAA AAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAA aG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAAD AAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQA GAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAA ABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAA AQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABg AAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYA TQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQA AAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0 AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAA AAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAA AAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAA AAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAA AAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAA VAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAA AAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAA AQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAA AAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABU AHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkA EQAAABoAAQ8AGxBAAgAAEACvDwgAAAAAAQAABQAAAAAAGRAoAgAAAAAACAwBAAAAAAACAAABDAAA AAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAAB AQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1k AAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAA AAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAA AQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAA IAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAA AAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIA AAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBu AG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAA AAAAAAAABAAAAA4ACQARAAAAGgABDwCKE2gBAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT SAEAAA8A1gcwAQAAAAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBo lhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHgAAGIhAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcA IABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWBwAABhIgALcPRAAA AItbU08AAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMA AAAAAA8A1geGAAYCMAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBo lhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGIgAADQQIAAAAcLUAAHC1AAAPAIoThgAAAAAA ug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTaAAAAC8AyA8MAAAAMADSDwQAAAAAAAAAAAB7FxAAAAAD AAAAqAMAAAMAAwACD///DwCuDzQAAAAQAK8PCAAAAAgBAAABAAAAAACsDxwAAAAAAAACAAAAAAAA AAAAAAAAAAIAAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAAIwBPANkPDAAAAAAA2g8EAAAADQA9 AA8A8A9hCwAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA95AAAA T1NQRiBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW1wYWlybWVudCBBd2FyZSBSb3V0aW5nIGFu ZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQgaW4gV2F2ZWxlbmd0aCBTd2l0Y2hlZCBPcHRpY2FsIE5l dHdvcmtzIAAAoQ8mAAAAegAAAAAAAAAAAHgAAAAAAAIAHAABAAAAAAAAAAEAAAAAAAIAKAAAAKoP MgAAAEUAAAAGAAAACQQJBAEAAAAGAAAACQQECDMAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACf DwQAAAAFAAAAAACoD58AAABDQ0FNUCBXRywgSUVURiA3OHRoLCBNYWFzdHJpY2h0LCBOZXRoZXJs YW5kcyANDWRyYWZ0LWFncmF6LWNjYW1wLXdzb24taW1wYWlybWVudC1vc3BmLTAwLnR4dA0NRmVy bmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMuZWR1KQ1ZYWJpbiBZZSAoeWFiaW4ueWVAaHVhd2Vp LmNvbSkAAKEPPgAAAKAAAAAAAAAQAAB4AC8AAAAAAAYAEgAAAAAFLgAAAAAAAgAYAAEAAAABAAYA AQASAAAA//5CAAAAAAACABIAAACqDz4AAAAVAAAABgAAAAkEBAgYAAAABgAAAAkEBAgwAAAABgAA AAkEBAgBAAAABgAAAAkIBAhCAAAABwAAAAAADAQECA8A8g8YAAAAAADzDxAAAAAAAAAAAAAAAAAA AAAIWAswAADfDwgAAAAVAAAALQAAAAAA8wMUAAAAUwAAAAQAAAACAAAADgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPDwAAAEFja25vd2xlZGdtZW50cwAAoQ8UAAAAEAAAAAAAAAAAABAAAAAAAAIAJAAA AKoPGgAAAA8AAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAA BwAAAAAABAgJBAAA8wMUAAAAVgAAAAQAAAABAAAAEQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAA AEJhY2tncm91bmQAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQAAACqDxoAAAAKAAAABgAAAAkE BAgBAAAABwAAAAAABAgJBAAA8wMUAAAAaAAAAAQAAAACAAAAHwEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPCgAAAE9iamVjdGl2ZSAAAKEPHAAAAAsAAAAAAAAAAAAJAAAAAAACACQAAgAAAAAAAAAAAKoP GgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAYgAAAAQAAAACAAAAGQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJQAAAE9T UEYgcm91dGluZyBmb3IgSUEtUldBIC1OZXcgUExJIFRMViAAAKEPKgAAACYAAAAAAAAAAAAXAAAA AABDAAsACwAkAA0AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAFwAAAAYAAAAJCAQIBQAAAAYAAAAJ BAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABXAAAABAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExpbmsgUExJIFRMViAAAKEPHAAAACEAAAAAAAAA AAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAAAB8AAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAH AAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYwAAAAQA AAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21wb3NpdGlvbiBvZiBOb2Rl IFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAAAAAAAACqDz4AAAATAAAA BgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJ BBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGQAAAAEAAAAAgAAABsB AAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABTb21lIHN1Yi1UTFZzIGFuZCBzdWItc3ViLVRMVnMA AKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQAAACqD1AAAAAJAAAABgAAAAkEBAgDAAAABwAAAAMA CQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgBAAAABwAAAAAABAgJ BBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGUAAAAEAAAAAgAAABwB AAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5rIFBM SSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDxoAAAAkAAAABgAAAAkECQQBAAAA BwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGYAAAAE AAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRo ZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDzIAAAAYAAAABgAA AAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAA qg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcAAAAEAAAAAgAAAB4BAAAAAAAAAACfDwQAAAAA AAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBUTFYAAKEPFAAAABwAAAAAAAAAAAAc AAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAA AAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAATmV4 dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPDAAAAAsAAAAGAAAACQQECBAA nw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFjY29yZGluZyB0byB0aGUgZmVlZGJhY2sgZnJv bSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QNS2VlcCB1cGdyYWRpbmcgd2hlbiBJVFUtVCBk ZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50IGluZm9ybWF0aW9uDUNvbW1lbnRzIGFyZSBh bHdheXMgYXBwcmVjaWF0ZWQAAKEPRgAAAIsAAAAAALIAAAADANgABgAAAAABIAAAAAAAsiAAAAMA 2AAGAAAAAAEyABsAAAAAAGEACwAAAAsAkAAAAAAEQQAABAsACwAAAKoPGgAAAKoAAAAGAAAACQQE CAEAAAAHAAAAAAAECAkELwDwDzgAAAAAAPMDFAAAAAYAAAAAAAAAAAAAAAABAAAAAAAAAADzAxQA AABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA6gMAAAAADwDuA9cKAAACAO8DGAAAAAEAAAANDgAAAAAA AAcAAIAAAAAABwALMA8ADATuCQAADwAC8OYJAADABwjwCAAAAAMAAAAD1AMADwAD8H4JAAAPAATw KAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAANQDAAUAAAAPAATweAAAABIACvAI AAAAAtQDACACAABjAAvwJAAAAH8AAAAEAIAAxCVhE78BAAABAP8BAAABAAEDAgADAIgDAAAAAAAA EPAIAAAAdwDcARwWlwIPABHwEAAAAAAAwwsIAAAAAAAAAA0AYRMPAA3wDAAAAAAAng8EAAAAAAAA AA8ABPDGCAAAEgAK8AgAAAAD1AMAAAoAAPMAC/BaAAAAfwAAAAQAgAAAha8PgQBgNQEAggCwmgAA gwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIA AAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYA TgA/BgYATgB/BgYADgAAABDwCAAAAPICZAIsFdoKDwAR8KgAAAAPAIgToAAAAA8AihOYAAAAAAC6 Dw4AAABfAF8AXwBQAFAAVAA5AAAAixN6AAAAAACsD3IAAAAAAAAAAAAAAAAAAAAAAAADAQAMAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAQAMAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAQAM AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3wTgcAAAAAnw8EAAAABAAAAAAA oA8cBQAASQBuACAARwBNAFAATABTAC0AYgBhAHMAZQBkACAAVwBTAE8ATgAgAG4AZQB0AHcAbwBy AGsAcwAsACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGkAbgBmAG8AcgBtAGEAdABpAG8A bgAgAG4AZQBlAGQAIAB0AG8AIABiAGUAIABmAGwAbwBvAGQAZQBkACAAdABoAHIAbwB1AGcAaAAg AHIAbwB1AHQAaQBuAGcAOgANAE4AbwByAG0AYQBsACAAcgBvAHUAdABpAG4AZwAgAGkAbgBmAG8A OgAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAAWwBSAEYAQwAgADMANgAzADAAXQAgAGEAbgBk ACAAWwBSAEYAQwAgADQAMgAwADMAXQAuAA0ATgBvAGQAZQAgAEkARAAsACAATABpAG4AawAgAEkA RAAsACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AGkAdgBlACAARwByAG8AdQBwACwAIABJAFMAQwBE ACwAIABQAHIAbwB0AGUAYwB0AGkAbwBuACwAIABTAFIATABHACwAIABUAEUAIABtAGUAdAByAGkA YwAsACAAJiANAFcAUwBPAE4AIABzAHAAZQBjAGkAYQBsACAAaQBuAGYAbwA6ACAAZABlAHMAYwBy AGkAYgBlAGQAIABpAG4AIABbAF0ADQBTAHcAaQB0AGMAaAAgAEMAbwBuAG4AZQBjAHQAaQB2AGkA dAB5ACAATQBhAHQAcgBpAHgALAAgAFcAYQB2AGUAbABlAG4AZwB0AGgAIABDAG8AbgB2AGUAcgB0 AGUAcgAgAFAAbwBvAGwAIABpAG4AZgBvACwAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAQQB2AGEA aQBsAGEAYgBpAGwAaQB0AHkALAAgACAAUABvAHIAdAAgAFcAYQB2AGUAbABlAG4AZwB0AGgAIABS AGUAcwB0AHIAaQBjAHQAaQBvAG4ALAAgAC4ALgAuAA0ASQBtAHAAYQBpAHIAbQBlAG4AdAAgAGkA bgBmAG8AOgAgAHQAaABpAHMAIABkAHIAYQBmAHQAIABpAG4AdgBvAGwAdgBlAGQADQAJAFQAdwBv ACAAdABvAHAALQBUAEwAVgBzACAAYQByAGUAIABkAGUAZgBpAG4AZQBkACAAdABvACAAZABlAHMA YwByAGkAYgBlACAAUABMAEkAIAAoAFAAaAB5AHMAaQBjAGEAbAAgAEwAYQB5AGUAcgAgAEkAbQBw AGEAaQByAG0AZQBuAHQAcwApACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuADoADQBMAGkAbgBrACAA UABMAEkAIABUAEwAVgAgAC0ARABlAHMAYwByAGkAYgBlAHMAIAB0AGgAZQAgAHAAaAB5AHMAaQBj AGEAbAAgAGwAYQB5AGUAcgAgAGkAbQBwAGEAaQByAG0AZQBuAHQAcwAgAHIAZQBsAGEAdABlAGQA IAB0AG8AIAB0AGgAZQAgAGwAaQBuAGsADQBOAG8AZABlACAAUABMAEkAIABUAEwAVgAgAC0ARABl AHMAYwByAGkAYgBlAHMAIAB0AGgAZQAgAHAAaAB5AHMAaQBjAGEAbAAgAGwAYQB5AGUAcgAgAGkA bQBwAGEAaQByAG0AZQBuAHQAcwAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIAB0AGgAZQAgAG4AbwBk AGUAAAChD4ABAABcAAAAAACyMAoAAgDYAAYAAAAAAYIAFAAHAD0AAAAAACEACgABAAAAAAEHAE0A AAABAPsACgALAGwABgA3AAAAAAEHACMAAAAAACEACgABAAAAAAEHAHcAAAABAPsACgALAGwABgA3 AAAAAAEHACUAAAAAACEACgABAAAAAAEHAFQAAAAAALIgCgACANgABgAAAAABFAAHAJYAAAABAPsA CgALAGwABgA3AAAAAAEHAFwAAAAAACIACAAUABQAAAAABGMAAAQLAAgACwAWACkAAAAABGcAAAQL AAgACwAWAAAAAANNAAAAAAhjAAAICwAIAAsAFgAjAAAAAAxjAAAMCwAIAAsAFgB3AAAAABBjAAAQ CwAIAAsAFgAkAAAAABQmAAAUCAAUAAAA//4BAAAAABQgAAAUCAABAAAAABhnAAAYCwAIAAsAFgAA AP/+UwAAAAAYYwAAGAsACAALABYAWQAAAAAcYwAAHAsACAALABYAPQAAAAAcIgAAHAgAFAAAAKoP cAAAAG8AAAAGAAAACQQECCoAAAAGAAAACQgECNYAAAAGAAAACQQECBAAAAAHAAAAAAAJBAQIJQAA AAYAAAAJBAQICgAAAAYAAAAJCAQIBAAAAAcAAAADAAkIBAhHAAAABgAAAAkIBAiWAAAABgAAAAkE BAgAAKYPFgAAAPkcAAD5ASAB+gHIA6gCWQU5BOoGygUPAATwSAAAABIACvAIAAAAAdQDAAAMAACD AAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6 DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAHVXygGQN3iBAAAAKwQAAAAAAAAA HwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAACJFv////8SAAAADwA98Q0AAABA AULxBQAAAAEJAAAADwACKwAAAAAAAHIXEAAAAAEAEABsnwQAYgAQACrPBAAAAPUPHAAAABkBAACk GQADSJ8EAAnaBAABAAAAaAAAAAEAxTEPAOgDti8AAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUA AAAKAAAABQAAAEUAAAABAAAAAAAAAQ8A8gNqBAAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHkAMA AAAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTAOSEiBbwgxMA eDoLMPCDEwAAAAAADwDVBwAABiIQALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBu AAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkA ZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw8IMTAAAAAAAPANUHAAAE IjAAtw9EAAAA0Z5TTwAAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMA eDoLMPCDEwAAAAAADwDVB4YABgJAALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABU ACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQiUAC3D0QAAABOU4dlxn7RngAA ZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAG AmAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAA eDoLMPCDEwAAAAAADwDVBwIABgJwALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABU ACAATABpAGcAaAB0AAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAYigAC3D0QAAACLW1NPAAB0AGkA ZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHhgAG ApAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAA eDoLMPCDEwAAAAAADwDVBwAABBSgALcPRAAAAFQAaQBtAGUAcwAAAGUAcgBOAGUAeAB0ACAATABU ACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A1QcAAAQksAC3D0QAAABUAGkAbQBlAHMA IABOAGUAdwAgAFIAbwBtAGEAbgAAAEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAG EgAApA8MAAAAgABiAAAACAAAABQAAAClDxoAAAAAALOoLgADAPwABgAAAAABAQAyAPkBBwAAAAAA qQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIA AAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAA YANgAwAAAAAABQAAgASABAAAAAAPAAsEHhIAAA8AAPAWEgAAAAAG8CAIAAAECAQAAwEAAEUBAAAV AAAAAAAAAA8AAAACAAAAPwAAAAsAAAAIAAAADAAAAAQAAAAAAAAAEAAAAAAAAAAEAAAAAAAAABMA AAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAA AAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAA AAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAhAAAAIAAAAJIAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAALQAA AEMAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAA BgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZ AAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAQAAAA/AAAACQAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAYAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAA AAAEAAAAAAAAAAQAAABPAAAADAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAJAAAAAAAA AEAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQA AAAAAAAAAwAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAFkAAAAHAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAEAAAAAAAAAPwAAAAA AAAALwAAAGIAAAAEAAAAYwAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAGsAAAAEAAAAAAAAACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABwAAAHEAAAAIAAAAAAAAALUAAAAAAAAABgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAA CAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAhAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAA8gAAAAAAAADjAAAAAAAAAF0AAAAAAAAArAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAIAAAAAAAAAAQAAAB8AAAABAAAAH0AAABBAAAAfgAAAHEBAAAAAAAABgAAAAAAAAAGAAAA gQAAAAAEAAAAAAAABgAAAIEAAADqAgAAgwAAAL0AAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAACH AAAAGgAAAIgAAAAEAAAAnwAB8IwBAABiAAfwJAAAAAYGBYs1H73H+Fqm86dQG2KYS/8A0yoAAAEA AAAAAAAAAAAAAFIAB/AkAAAABQXY8+MEAuku2OPtcJjJPSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH 8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/AAZXAAABAAAAIeEAAAAAAABiAAfwJAAAAAYGKx2cUUGW jNt7/vgYpNBSef8AqzMAAAEAAAAnOAEAAAAAAGIAB/AkAAAABgY86hloAaVPVtTX+LuTUNBJ/wDR FQAAAQAAANJrAQAAAAAAYgAH8CQAAAAGBrjpaHIX9gtc+PzUZOyCabb/ALxWBQABAAAAo4EBAAAA AAAyAAfwJAAAAAME7tu1c2pAoLp3dnMucUO2Ff8ASQIAAAEAAABf2AYAAAAAADIAB/AkAAAAAwRA 6+m1gMZDPxnQmww50Esk/wCdAgAAAQAAAKjaBgAAAAAAMgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2 +QX/AEsCAAABAAAARd0GAAAAAAADCAvwAAMAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAA AIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAPAAwB9AAAEA0BAAAAIA4BAAAAIIABAAAAAIEBBAAACIIB AAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAA AIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUB AAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABAQAA CMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoB AAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAA CAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsC AAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAAB AIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMEC AAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUA AMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQC AAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkB AEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMN IvEKBQAAjAABAAAAjQAwZQEAfwEAAEAAngH/////nwH/////oAEAAAAgocEAAAAAogH/////owH/ //90AAUAAADLzszlABUAAABGcnV0aWdlck5leHQgTFQgQm9sZAAGAAAAVGltZXMAEAAAAFRpbWVz IE5ldyBSb21hbgAIAAAAZGVmYXVsdAARAAAAMl/X1Lao0uXJ6LzGt72wuAARAAAAMV/X1Lao0uXJ 6LzGt72wuAANAAAAxKzIz8novMbEo7DlAHoAAABPU1BGIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBv ZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcgYW5kIFdhdmVsZW5ndGggQXNzaWdubWVudCBpbiBX YXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgABAAAABBY2tub3dsZWRnbWVudHMA CwAAAEJhY2tncm91bmQACwAAAE9iamVjdGl2ZSAAJgAAAE9TUEYgcm91dGluZyBmb3IgSUEtUldB IC1OZXcgUExJIFRMViAAIQAAAFRoZSBjb21wb3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgACEAAABU aGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAfAAAAU29tZSBzdWItVExWcyBhbmQgc3Vi LXN1Yi1UTFZzACUAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5rIFBMSSBUTFYAJQAAAFBh cv+kAQAAACClwQAAAACmAf////+nAf////+/AQAAIADZAf/////aAf/////bAQAAACDcwQAAAADd Af/////eAf/////fAQAAACDgwQAAAADhAf/////iAf//////AQAAwAASAv////8TAv////8UAgAA ACAVwgAAAAAWAv////8XAv////8YAgAAACAZwgAAAAAaAv////8bAv////+JAv////+KAv////+L AgAAACCMwgAAAACNAv////+PAwAAAACQAwIAAACRAwAAAACSAwIAAAC/AwCCAIJABQAAAABBBQAA AQBCBf///wBDBQAAACBEBQAAAABFRQAAAABGxQAAAABHBQAAAABIBQAAAABJBQAAAABKBQAAAABL BTUlAABMBQAACABNBQAAAABOBQAAAABPxQAAAABQBQAAAABRBQAAAABSBQEAAABTBQEAAABUBQEA AABVBQEAAABXBQIAAABZBf////9aBf////9bBQAAACBcxQAAAABdBf////9eBf////9fBQAAACBg xQAAAABhBf////9iBf////9/BQYATgCABQAAAACBBQAAAQCCBf///wCDBQAAACCEBQAAAACFRQAA AACGxQAAAACHBQAAAACIBQAAAACJBQAAAACKBQAAAACLBTUlAACMBQAACACNBQAAAACOBQAAAACP xQAAAACQBQAAAACRBQAAAACSBQEAAACTBQEAAACUBQEAAACVBQEAAACXBQIAAACZBf////+aBf// //+bBQAAACCcxQAAAACdBf////+eBf////+fBQAAACCgxQAAAAChBf////+iBf////+/BQYATgDA BQAAAADBBQAAAQDCBf///wDDBQAAACDEBQAAAADFRQAAAADGxQAAAADHBQAAAADIBQAAAADJBQAA AADKBQAAAADLBTUlAADMBQAACADNBQAAAADOBQAAAADPxQAAAADQBQAAAADRBQAAAADSBQEAAADT BQEAAADUBQEAAADVBQEAAADXBQIAAADZBf/////aBf/////bBQAAACDcxQAAAADdBf/////eBf// ///fBQAAACDgxQAAAADhBf/////iBf//////BQYATgAABgAAAAABBgAAAQACBv///wADBgAAACAE BgAAAAAFRgAAAAAGxgAAAAAHBgAAAAAIBgAAAAAJBgAAAAAKBgAAAAALBjUlAAAMBgAACAANBgAA AAAOBgAAAAAPxgAAAAAQBgAAAAARBgAAAAASBgEAAAATBgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZ Bv////8aBv////8bBgAAACAcxgAAAAAdBv////8eBv////8fBgAAACAgxgAAAAAhBv////8iBv// //8/BgYATgBABgAAAABBBgAAAQBCBv///wBDBgAAACBEBgAAAABFRgAAAABGxgAAAABHBgAAAABI BgAAAABJBgAAAABKBgAAAABLBjUlAABMBgAACABNBgAAAABOBgAAAABPxgAAAABQBgAAAABRBgAA AABSBgEAAABTBgEAAABUBgEAAABVBgEAAABXBgIAAABZBv////9aBv////9bBgAAACBcxgAAAABd Bv////9eBv////9fBgAAACBgxgAAAABhBv////9iBv////9/BgYADgCAABrxIAAAAP8AAADd3d0A 6urqAP//ZgD/mQAAAAD/AACZzAAAZpkAQAAe8RAAAAAEAAAI/5kAAAAAAAD3AAAQHwDwD4wAAAAA APMDFAAAAB8AAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAmAAAABAAAAAAAAAACAACAAAAAAAAA 8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMDFAAAADEAAAAEAAAAAAAAAAQAAIAAAAAAAADz AxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ad5DAAAHwAUBBwAAAAAABUEFAAAANAYzQQAypo7 TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEBAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAAA AAD8JYgWCIQTAHg6CzAAAAAAAAAAAO78//8K////AAATAHAA+wMIAAAAAAAAADwCAABwAPsDCAAA AAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABME PAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAA0hBMA/PgKMGiWEwAAAAAAAAAAAAAAAAAA AAAAAAETAA8AiBNuCwAADwCKE2gAAAAAALoPFAAAAF8AXwBfAFAAUABUADIAMAAwADEAAACLE0QA AAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAAAAAAiNkA AAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABfAF8AXwBQAFAAVABNAGEAYwAxADEAAACLE9II AABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAA CgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBw AG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAA GgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAA AAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAAB BAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBh AGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEA cABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwB AAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAAB AAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAA AAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgA AAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAA AQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAAB DAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAA AAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhu YW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAA AAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgA AAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAU AAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEA AAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAA AAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0A bwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAG AAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQBAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIAABAArw8IAAAAAAEAAAUAAAAAABkQKAIAAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AihNoAQAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAA AG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWB4AABiIQALcPRAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDoghMAAAAA AA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMA MIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHhgAGAjAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABS AG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWBwAABiIAAA0ECAAAAHC1 AABwtQAADwCKE4YAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE2gAAAAvAMgPDAAAADAA0g8E AAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg///w8Arg80AAAAEACvDwgAAAAIAQAAAQAAAAAA rA8cAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAD8A2Q8MAAAAAADaDwQAAAAAACMATwDZ DwwAAAAAANoPBAAAAA0APQAPAPAPYQsAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8P BAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEltcGFpcm1lbnQg QXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25tZW50IGluIFdhdmVsZW5ndGggU3dp dGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoAAAAAAAAAAAB4AAAAAAACABwAAQAAAAAA AAABAAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQBAAAABgAAAAkEBAgzAAAABgAAAAkECQQB AAAABwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAAQ0NBTVAgV0csIElFVEYgNzh0aCwgTWFh c3RyaWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jhei1jY2FtcC13c29uLWltcGFpcm1lbnQt b3NwZi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3JhekB0c2MudXBjLmVkdSkNWWFiaW4gWWUg KHlhYmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAAAAAAEAAAeAAvAAAAAAAGABIAAAAABS4A AAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgASAAAAqg8+AAAAFQAAAAYAAAAJBAQIGAAA AAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQIQgAAAAcAAAAAAAwEBAgPAPIPGAAAAAAA 8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAAAC0AAAAAAPMDFAAAAFMAAAAEAAAAAgAA AA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tub3dsZWRnbWVudHMAAKEPFAAAABAAAAAA AAAAAAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAA AQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFYAAAAEAAAAAQAAABEBAAAAAAAAAACf DwQAAAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAA qg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAPMDFAAAAGgAAAAEAAAAAgAAAB8BAAAA AAAAAACfDwQAAAAAAAAAAACoDwoAAABPYmplY3RpdmUgAAChDxwAAAALAAAAAAAAAAAACQAAAAAA AgAkAAIAAAAAAAAAAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAA AAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIAAAAEAAAAAgAAABkBAAAAAAAAAACfDwQA AAAAAAAAAACoDyUAAABPU1BGIHJvdXRpbmcgZm9yIElBLVJXQSAtTmV3IFBMSSBUTFYgAAChDyoA AAAmAAAAAAAAAAAAFwAAAAAAQwALAAsAJAANAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABcAAAAG AAAACQgECAUAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkE EACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVwAAAAQAAAACAAAAEgEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21wb3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYg AAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAAAAAAAACqDyYAAAAfAAAABgAAAAkECQQB AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABUaGUgY29t cG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIAJAACAAAA AAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJ BAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQA AABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAAU29tZSBzdWItVExWcyBh bmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAAAAAAAAAAHwAAAAAAAgAkAAAAqg9QAAAACQAAAAYA AAAJBAQIAwAAAAcAAAADAAkECQQBAAAABwAAAAMACQQECA0AAAAGAAAACQQECAQAAAAHAAAAAwAJ BAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQA AABlAAAABAAAAAIAAAAcAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVz IGZvciB0aGUgTGluayBQTEkgVExWAAChDxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8aAAAA JAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAE CAkEAADzAxQAAABmAAAABAAAAAIAAAAdAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1l dGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQTEkgVExWAAChDxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAk AAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQI CQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABnAAAABAAAAAIAAAAe AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAAQW4gRXhhbXBsZSBvZiBjb21wb25lbnQgVExWAACh DxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAkAAAAqg8MAAAAHAAAAAYAAAAJBAQIEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAARAAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPCgAAAE5leHQgU3RlcHMAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQAAACqDwwA AAALAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKgPqgAAAFJlZmluZSBpdCBhY2NvcmRpbmcgdG8g dGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcgb3IgbWFpbGluZyBsaXN0DUtlZXAgdXBncmFk aW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0aGUgc3RhbmRhcmQgaW1wYWlybWVudCBpbmZvcm1hdGlv bg1Db21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lhdGVkAAChD0YAAACLAAAAAACyAAAAAwDYAAYA AAAAASAAAAAAALIgAAADANgABgAAAAABMgAbAAAAAABhAAsAAAALAJAAAAAABEEAAAQLAAsAAACq DxoAAACqAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A8A84AAAAAADzAxQAAAAGAAAAAAAAAAAA AAAAAQAAAAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEAAAAAAAAAAOoDAAAAAA8A7gPFCgAAAgDv AxgAAAABAAAADQ4AAAAAAAAHAACAAAAAAAcACzAPAAwE3AkAAA8AAvDUCQAAwAcI8AgAAAADAAAA A9QDAA8AA/BsCQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADUAwAF AAAADwAE8HgAAAASAArwCAAAAALUAwAgAgAAYwAL8CQAAAB/AAAABACAAMQlYRO/AQAAAQD/AQAA AQABAwIAAwCIAwAAAAAAABDwCAAAAHcA3AEcFpcCDwAR8BAAAAAAAMMLCAAAAAAAAAANAGETDwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATwtAgAABIACvAIAAAAA9QDAAAKAADzAAvwWgAAAH8AAAAEAIAA AIWvD4EAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAAvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADyAmQCLBXaCg8AEfCoAAAADwCI E6AAAAAPAIoTmAAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTegAAAAAArA9yAAAAAAAAAAAA AAAAAAAAAAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwEADAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAN8DwH AAAAAJ8PBAAAAAQAAAAAAKAPCgUAAEkAbgAgAEcATQBQAEwAUwAtAGIAYQBzAGUAZAAgAFcAUwBP AE4AIABuAGUAdAB3AG8AcgBrAHMALAAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcAIABpAG4A ZgBvAHIAbQBhAHQAaQBvAG4AIABuAGUAZQBkACAAdABvACAAYgBlACAAZgBsAG8AbwBkAGUAZAAg AHQAaAByAG8AdQBnAGgAIAByAG8AdQB0AGkAbgBnADoADQBOAG8AcgBtAGEAbAAgAHIAbwB1AHQA aQBuAGcAIABpAG4AZgBvADoAIABkAGUAcwBjAHIAaQBiAGUAZAAgAGkAbgAgAFsAUgBGAEMAIAAz ADYAMwAwAF0AIABhAG4AZAAgAFsAUgBGAEMAIAA0ADIAMAAzAF0ALgANAE4AbwBkAGUAIABJAEQA LAAgAEwAaQBuAGsAIABJAEQALAAgAEEAZABtAGkAbgBpAHMAdAByAGEAdABpAHYAZQAgAEcAcgBv AHUAcAAsACAASQBTAEMARAAsACAAUAByAG8AdABlAGMAdABpAG8AbgAsACAAUwBSAEwARwAsACAA VABFACAAbQBlAHQAcgBpAGMALAAgACYgDQBSAFcAQQAgAGkAbgBmAG8AOgAgAGQAZQBzAGMAcgBp AGIAZQBkACAAaQBuACAAWwBdAA0AUwB3AGkAdABjAGgAIABDAG8AbgBuAGUAYwB0AGkAdgBpAHQA eQAgAE0AYQB0AHIAaQB4ACwAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAQwBvAG4AdgBlAHIAdABl AHIAIABQAG8AbwBsACAAaQBuAGYAbwAsACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAEEAdgBhAGkA bABhAGIAaQBsAGkAdAB5ACwAIAAgAFAAbwByAHQAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAUgBl AHMAdAByAGkAYwB0AGkAbwBuACwAIAAuAC4ALgANAEkAbQBwAGEAaQByAG0AZQBuAHQAIABpAG4A ZgBvADoAIAB0AGgAaQBzACAAZAByAGEAZgB0ACAAaQBuAHYAbwBsAHYAZQBkAA0ACQBUAHcAbwAg AHQAbwBwAC0AVABMAFYAcwAgAGEAcgBlACAAZABlAGYAaQBuAGUAZAAgAHQAbwAgAGQAZQBzAGMA cgBpAGIAZQAgAFAATABJACAAKABQAGgAeQBzAGkAYwBhAGwAIABMAGEAeQBlAHIAIABJAG0AcABh AGkAcgBtAGUAbgB0AHMAKQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgA6AA0ATABpAG4AawAgAFAA TABJACAAVABMAFYAIAAtAEQAZQBzAGMAcgBpAGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBh AGwAIABsAGEAeQBlAHIAIABpAG0AcABhAGkAcgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAA dABvACAAdABoAGUAIABsAGkAbgBrAA0ATgBvAGQAZQAgAFAATABJACAAVABMAFYAIAAtAEQAZQBz AGMAcgBpAGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwAIABsAGEAeQBlAHIAIABpAG0A cABhAGkAcgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABvACAAdABoAGUAIABuAG8AZABl AAAAoQ+AAQAAXAAAAAAAsjAKAAIA2AAGAAAAAAGCABQABwA9AAAAAAAhAAoAAQAAAAABBwBNAAAA AQD7AAoACwBsAAYANwAAAAABBwAaAAAAAAAhAAoAAQAAAAABBwB3AAAAAQD7AAoACwBsAAYANwAA AAABBwAlAAAAAAAhAAoAAQAAAAABBwBUAAAAAACyIAoAAgDYAAYAAAAAARQABwCWAAAAAQD7AAoA CwBsAAYANwAAAAABBwBcAAAAAAAiAAgAFAAUAAAAAARjAAAECwAIAAsAFgApAAAAAARnAAAECwAI AAsAFgAAAAADTQAAAAAIYwAACAsACAALABYAGgAAAAAMYwAADAsACAALABYAdwAAAAAQYwAAEAsA CAALABYAJAAAAAAUJgAAFAgAFAAAAP/+AQAAAAAUIAAAFAgAAQAAAAAYZwAAGAsACAALABYAAAD/ /lMAAAAAGGMAABgLAAgACwAWAFkAAAAAHGMAABwLAAgACwAWAD0AAAAAHCIAABwIABQAAACqD3AA AABvAAAABgAAAAkEBAgqAAAABgAAAAkIBAhNAAAABgAAAAkEBAgIAAAABwAAAAAACQQECK0AAAAG AAAACQQECAoAAAAGAAAACQgECAQAAAAHAAAAAwAJCAQIRwAAAAYAAAAJCAQIlgAAAAYAAAAJBAQI AACmDxYAAAD5HAAA+QEgAfoByAOoAlkFOQTqBsoFDwAE8EgAAAASAArwCAAAAAHUAwAADAAAgwAL 8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oBkDd4gQAAACsEAAAAAAAAAB8A RPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAiRb/////EgAAAA8APfENAAAAQAFC 8QUAAAABCQAAAA8AAisAAAAAAAByFxAAAAABABAARdoEAGIAEAADCgUAAAD1DxwAAAAZAQAApBkA AyHaBADQFAUAAQAAAGgAAAABAMUxDwDoA7YvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAA CgAAAAUAAABFAAAAAQAAAAAAAAEPAPIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5ADAAAA ALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6 CzDwgxMAAAAAAA8A1QcAAAYiEAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAA AGiWEwBolhMA5ISIFvCDEwB4Ogsw8IMTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUAdABpAGcA ZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVBwAABCIw ALcPRAAAANGeU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6 CzDwgxMAAAAAAA8A1QeGAAYCQAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAg AFIAZQBnAHUAbABhAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEIlAAtw9EAAAATlOHZcZ+0Z4AAGcA ZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVB4YABgJg ALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6 CzDwgxMAAAAAAA8A1QcCAAYCcAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAg AEwAaQBnAGgAdAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGIoAAtw9EAAAAi1tTTwAAdABpAGcA ZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAADwDVB4YABgKQ ALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6 CzDwgxMAAAAAAA8A1QcAAAQUoAC3D0QAAABUAGkAbQBlAHMAAABlAHIATgBlAHgAdAAgAEwAVAAg AEIAbwBsAGQAAAAAAHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEJLAAtw9EAAAAVABpAG0AZQBzACAA TgBlAHcAIABSAG8AbQBhAG4AAABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABhIA AKQPDAAAAIAAYgAAAAgAAAAUAAAApQ8aAAAAAACzqC4AAwD8AAYAAAAAAQEAMgD5AQcAAAAAAKkP CgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAA AAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAADwALBB4SAAAPAADwFhIAAAAABvAgCAAABAgEAAMBAABFAQAAFQAA AAAAAAAPAAAAAgAAAD8AAAALAAAACAAAAAwAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAAAAATAAAA AAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAA AAAABwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAA AAAJAAAAAAAAAAkAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAACAAAACSAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAC0AAABD AAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYA AAAAAAAABAAAAAAAAAAGAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAAAAAAAEIAAAAAAAAAGQAA AAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAAPwAAAAkAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAGAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAA BAAAAAAAAAAEAAAATwAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAAAABA AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAA AAAAAAMAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABZAAAABwAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAAAAAAD8AAAAAAAA AC8AAABiAAAABAAAAGMAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAABrAAAABAAAAAAAAAAmAAAAAAAAACUAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAcAAABxAAAACAAAAAAAAAC1AAAAAAAAAAYAAAB0AAAA+wEAAHUAAABeAAAAAAAAAAgA AAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAPIAAAAAAAAA4wAAAAAAAABdAAAAAAAAAKwAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACAAAAAAAAAAEAAAAfAAAAAQAAAB9AAAAQQAAAH4AAABxAQAAAAAAAAYAAAAAAAAABgAAAIEA AAAABAAAAAAAAAYAAACBAAAA6gIAAIMAAAC9AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAhwAA ABoAAACIAAAABAAAAJ8AAfCMAQAAYgAH8CQAAAAGBgWLNR+9x/hapvOnUBtimEv/ANMqAAABAAAA AAAAAAAAAABSAAfwJAAAAAUF2PPjBALpLtjj7XCYyT0iFf8ATrYAAAEAAADTKgAAAAAAAFIAB/Ak AAAABQVuXl4RjS68ttrj/Ic/k8hg/wAGVwAAAQAAACHhAAAAAAAAYgAH8CQAAAAGBisdnFFBlozb e/74GKTQUnn/AKszAAABAAAAJzgBAAAAAABiAAfwJAAAAAYGPOoZaAGlT1bU1/i7k1DQSf8A0RUA AAEAAADSawEAAAAAAGIAB/AkAAAABga46WhyF/YLXPj81GTsgmm2/wC8VgUAAQAAAKOBAQAAAAAA MgAH8CQAAAADBO7btXNqQKC6d3ZzLnFDthX/AEkCAAABAAAAX9gGAAAAAAAyAAfwJAAAAAMEQOvp tYDGQz8Z0JsMOdBLJP8AnQIAAAEAAACo2gYAAAAAADIAB/AkAAAAAwSqrbsIEBgFJFUCqAz3dvkF /wBLAgAAAQAAAEXdBgAAAAAAAwgL8AADAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACH AAEAAACIAAAAAACJAAAAAAC/AAIADwAMAfQAABANAQAAACAOAQAAACCAAQAAAACBAQQAAAiCAQAA AQCDAQAAAAiEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACM AQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAA AACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDAAQEAAAjB AQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAA AADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgC AsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAA AAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAAAQCC AgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAA AADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADL AtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAA AADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBC AwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAABzDSLx CgUAAIwAAQAAAI0AMGUBAH8BAABAAJ4B/////58B/////6ABAAAAIKHBAAAAAKIB/////6MB//// /6QBAAAAIKXBAAAAAKYB/////6cB/////78BAAAgANkB/////9oB/////9sBAAAAINzBAAAAAN0B /////94B/////98BAAAAIODBAAAAAOEB/////+IB//////8BAADAABIC/////xMC/////xQCAAAA IBXCAAAAABYC/////xcC/////xgCAAAAIBnCAAAAABoC/////xsC/////4kC/////4oC/////4sC AAAAIIzCAAAAAI0C/////48DAAAAAJADAgAAAJEDAAAAAJIDAgAAAL8DAIIAgkAFAAAAAEEFAAAB AEIF////AEMFAAAAIEQFAAAAAEVFAAAAAEbFAAAAAEcFAAAAAEgFAAAAAEkFAAAAAEoFAAAAAEsF NSUAAEwFAAAIAE0FAAAAAE4FAAAAAE/FAAAAAFAFAAAAAFEFAAAAAFIFAQAAAFMFAQAAAFQFAQAA AFUFAQAAAFcFAgAAAFkF/////1oF/////1sFAAAAIFzFAAAAAF0F/////14F/////18FAAAAIGDF AAAAAGEF/////2IF/////38FBgBOAIAFAAAAAIEFAAABAIIF////AIMFAAAAIIQFAAAAAIVFAAAA AIbFAAAAAIcFAAAAAIgFAAAAAIkFAAAAAIoFAAAAAIsFNSUAAIwFAAAIAI0FAAAAAI4FAAAAAI/F AAAAAJAFAAAAAJEFAAAAAJIFAQAAAJMFAQAAAJQFAQAAAJUFAQAAAJcFAgAAAJkF/////5oF//// /5sFAAAAIJzFAAAAAJ0F/////54F/////58FAAAAIKDFAAAAAKEF/////6IF/////78FBgBOAMAF AAAAAMEFAAABAMIF////AMMFAAAAIMQFAAAAAMVFAAAAAMbFAAAAAMcFAAAAAMgFAAAAAMkFAAAA AMoFAAAAAMsFNSUAAMwFAAAIAM0FAAAAAM4FAAAAAM/FAAAAANAFAAAAANEFAAAAANIFAQAAANMF AQAAANQFAQAAANUFAQAAANcFAgAAANkF/////9oF/////9sFAAAAINzFAAAAAN0F/////94F//// /98FAAAAIODFAAAAAOEF/////+IF//////8FBgBOAAAGAAAAAAEGAAABAAIG////AAMGAAAAIAQG AAAAAAVGAAAAAAbGAAAAAAcGAAAAAAgGAAAAAAkGAAAAAAoGAAAAAAsGNSUAAAwGAAAIAA0GAAAA AA4GAAAAAA/GAAAAABAGAAAAABEGAAAAABIGAQAAABMGAQAAABQGAQAAABUGAQAAABcGAgAAABkG /////xoG/////xsGAAAAIBzGAAAAAB0G/////x4G/////x8GAAAAICDGAAAAACEG/////yIG//// /z8GBgBOAEAGAAAAAEEGAAABAEIG////AEMGAAAAIEQGAAAAAEVGAAAAAEbGAAAAAEcGAAAAAEgG AAAAAEkGAAAAAEoGAAAAAEsGNSUAAEwGAAAIAE0GAAAAAE4GAAAAAE/GAAAAAFAGAAAAAFEGAAAA AFIGAQAAAFMGAQAAAFQGAQAAAFUGAQAAAFcGAgAAAFkG/////1oG/////1sGAAAAIFzGAAAAAF0G /////14G/////18GAAAAIGDGAAAAAGEG/////2IG/////38GBgAOAIAAGvEgAAAA/wAAAN3d3QDq 6uoA//9mAP+ZAAAAAP8AAJnMAABmmQBAAB7xEAAAAAQAAAj/mQAAAAAAAPcAABAfAPAPjAAAAAAA 8wMUAAAAHwAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAACYAAAAEAAAAAAAAAAIAAIAAAAAAAADz AxQAAAAzAAAABAAAAAAAAAAGAACAAAAAAAAA8wMUAAAAMQAAAAQAAAAAAAAABAAAgAAAAAAAAPMD FAAAADwAAAAAAAAAAAAAAAcAAIAAAAAADwDQB3kMAAAfABQEHAAAAAAAFQQUAAAA0BjNBADKmjtO tdw2AMqaOwECAAAPAPoDdwAAAAAA/gMDAAAAAQEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAAAAA APwliBYIhBMAeDoLMAAAAAAAAAAA7vz//zT///8AABMAcAD7AwgAAAAAAAAAPAIAAHAA+wMIAAAA AAAAABwOAABwAPsDCAAAAAEAAAAJAgAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8AEwQ8 AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAAgAAADSEEwD8+AowaJYTAAAAAAAAAAAAAAAAAAAA AAAAARMADwCIE24LAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAA AA8AiBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAACI2QAA AAAAAAAAAACAAgHgDwCKE/gIAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0ggA AEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAA AOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAA AQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAK AEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAA bwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAa AAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAA BAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEE AAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEA bAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBw AGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEA AAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEA AAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA AAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAA AAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAAB BgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEM AAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAA AAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5h bWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAA AAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAA AAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAA ACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAA AAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAAC AAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8A bgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAA AAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBAAgAAEACvDwgAAAAAAQAABQAAAAAAGRAoAgAAAAAA CAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAA AAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEA AAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAA AAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkA AAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAAC AAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEA AAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAA AGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAA AwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAE ABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwCKE2gBAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTSAEAAA8A1gcwAQAAAAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAA bwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHgAAGIhAAtw9EAAAAVABp AG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAA DwDWBwAABhIgALcPRAAAAItbU08AAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAw hBMA6IITAHg6CzDoghMAAAAAAA8A1geGAAYCMAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIA bwBtAGEAbgAAAGiWEwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGIgAADQQIAAAAcLUA AHC1AAAPAIoThgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTaAAAAC8AyA8MAAAAMADSDwQA AAAAAAAAAAB7FxAAAAADAAAAqAMAAAMAAwACD///DwCuDzQAAAAQAK8PCAAAAAgBAAABAAAAAACs DxwAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAAIwBPANkP DAAAAAAA2g8EAAAADQA9AA8A8A9hCwAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8E AAAABgAAAAAAqA95AAAAT1NQRiBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW1wYWlybWVudCBB d2FyZSBSb3V0aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQgaW4gV2F2ZWxlbmd0aCBTd2l0 Y2hlZCBPcHRpY2FsIE5ldHdvcmtzIAAAoQ8mAAAAegAAAAAAAAAAAHgAAAAAAAIAHAABAAAAAAAA AAEAAAAAAAIAKAAAAKoPMgAAAEUAAAAGAAAACQQJBAEAAAAGAAAACQQECDMAAAAGAAAACQQJBAEA AAAHAAAAAAAECAkEEACfDwQAAAAFAAAAAACoD58AAABDQ0FNUCBXRywgSUVURiA3OHRoLCBNYWFz dHJpY2h0LCBOZXRoZXJsYW5kcyANDWRyYWZ0LWFncmF6LWNjYW1wLXdzb24taW1wYWlybWVudC1v c3BmLTAwLnR4dA0NRmVybmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMuZWR1KQ1ZYWJpbiBZZSAo eWFiaW4ueWVAaHVhd2VpLmNvbSkAAKEPPgAAAKAAAAAAAAAQAAB4AC8AAAAAAAYAEgAAAAAFLgAA AAAAAgAYAAEAAAABAAYAAQASAAAA//5CAAAAAAACABIAAACqDz4AAAAVAAAABgAAAAkEBAgYAAAA BgAAAAkEBAgwAAAABgAAAAkEBAgBAAAABgAAAAkIBAhCAAAABwAAAAAADAQECA8A8g8YAAAAAADz DxAAAAAAAAAAAAAAAAAAAAAIWAswAADfDwgAAAAVAAAALQAAAAAA8wMUAAAAUwAAAAQAAAACAAAA DgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAEFja25vd2xlZGdtZW50cwAAoQ8UAAAAEAAAAAAA AAAAABAAAAAAAAIAJAAAAKoPGgAAAA8AAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAAB AAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVgAAAAQAAAABAAAAEQEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQAAACq DxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAA8wMUAAAAaAAAAAQAAAACAAAAHwEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE9iamVjdGl2ZSAAAKEPHAAAAAsAAAAAAAAAAAAJAAAAAAAC ACQAAgAAAAAAAAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYgAAAAQAAAACAAAAGQEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPJQAAAE9TUEYgcm91dGluZyBmb3IgSUEtUldBIC1OZXcgUExJIFRMViAAAKEPKgAA ACYAAAAAAAAAAAAXAAAAAABDAAsACwAkAA0AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAFwAAAAYA AAAJCAQIBQAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQ AJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABXAAAABAAAAAIAAAASAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExpbmsgUExJIFRMViAA AKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAAAB8AAAAGAAAACQQJBAEA AAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJ BAAA8wMUAAAAYwAAAAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21w b3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAA AAAAAACqDz4AAAATAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABgAAAAkE BAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AGQAAAAEAAAAAgAAABsBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABTb21lIHN1Yi1UTFZzIGFu ZCBzdWItc3ViLVRMVnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQAAACqD1AAAAAJAAAABgAA AAkEBAgDAAAABwAAAAMACQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQIBAAAAAcAAAADAAkE BAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AGUAAAAEAAAAAgAAABwBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMg Zm9yIHRoZSBMaW5rIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDxoAAAAk AAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQI CQQAAPMDFAAAAGYAAAAEAAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0 ZXIgVHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQA AACqDzIAAAAYAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABwAAAAAABAgJ BBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcAAAAEAAAAAgAAAB4B AAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBUTFYAAKEP FAAAABwAAAAAAAAAAAAcAAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAA AKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8KAAAATmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPDAAA AAsAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFjY29yZGluZyB0byB0 aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QNS2VlcCB1cGdyYWRp bmcgd2hlbiBJVFUtVCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50IGluZm9ybWF0aW9u DUNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEPRgAAAIsAAAAAALIAAAADANgABgAA AAABIAAAAAAAsiAAAAMA2AAGAAAAAAEyABsAAAAAAGEACwAAAAsAkAAAAAAEQQAABAsACwAAAKoP GgAAAKoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAAAPMDFAAAAAYAAAAAAAAAAAAA AAABAAAAAAAAAADzAxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA6gMAAAAADwDuA2ULAAACAO8D GAAAAAEAAAANDgAAAAAAAAcAAIAAAAAABwALMA8ADAR8CgAADwAC8HQKAADABwjwCAAAAAMAAAAD 1AMADwAD8AwKAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAANQDAAUA AAAPAATweAAAABIACvAIAAAAAtQDACACAABjAAvwJAAAAH8AAAAEAIAAxCVhE78BAAABAP8BAAAB AAEDAgADAIgDAAAAAAAAEPAIAAAAdwDcARwWlwIPABHwEAAAAAAAwwsIAAAAAAAAAA0AYRMPAA3w DAAAAAAAng8EAAAAAAAAAA8ABPBUCQAAEgAK8AgAAAAD1AMAAAoAAPMAC/BaAAAAfwAAAAQAgAAA ha8PgQBgNQEAggCwmgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/ BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPICZAIsFdoKDwAR8KgAAAAPAIgT oAAAAA8AihOYAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixN6AAAAAACsD3IAAAAAAAAAAAAA AAAAAAAAAAADAQAMAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAQAMAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADAQAMAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3w3AcA AAAAnw8EAAAABAAAAAAAoA9WBQAASQBuACAARwBNAFAATABTAC0AYgBhAHMAZQBkACAAVwBTAE8A TgAgAG4AZQB0AHcAbwByAGsAcwAsACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGkAbgBm AG8AcgBtAGEAdABpAG8AbgAgAG4AZQBlAGQAIAB0AG8AIABiAGUAIABmAGwAbwBvAGQAZQBkACAA dABoAHIAbwB1AGcAaAAgAHIAbwB1AHQAaQBuAGcAOgANAE4AbwByAG0AYQBsACAAcgBvAHUAdABp AG4AZwAgAGkAbgBmAG8AOgAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAAWwBSAEYAQwAgADMA NgAzADAAXQAgAGEAbgBkACAAWwBSAEYAQwAgADQAMgAwADMAXQAuAA0ATgBvAGQAZQAgAEkARAAs ACAATABpAG4AawAgAEkARAAsACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AGkAdgBlACAARwByAG8A dQBwACwAIABJAFMAQwBEACwAIABQAHIAbwB0AGUAYwB0AGkAbwBuACwAIABTAFIATABHACwAIABU AEUAIABtAGUAdAByAGkAYwAsACAAJiANAFIAVwBBACAAaQBuAGYAbwA6ACAAZABlAHMAYwByAGkA YgBlAGQAIABpAG4AIABbAHIAdwBhAC0AaQBuAGYAbwBdACAALAAgAFsAcgB3AGEALQBlAG4AYwBv AGQAZQBdACAAYQBuAGQAIABbAHIAdwBhAC0AbwBzAHAAZgBdAA0AUwB3AGkAdABjAGgAIABDAG8A bgBuAGUAYwB0AGkAdgBpAHQAeQAgAE0AYQB0AHIAaQB4ACwAIABXAGEAdgBlAGwAZQBuAGcAdABo ACAAQwBvAG4AdgBlAHIAdABlAHIAIABQAG8AbwBsACAAaQBuAGYAbwAsACAAVwBhAHYAZQBsAGUA bgBnAHQAaAAgAEEAdgBhAGkAbABhAGIAaQBsAGkAdAB5ACwAIAAgAFAAbwByAHQAIABXAGEAdgBl AGwAZQBuAGcAdABoACAAUgBlAHMAdAByAGkAYwB0AGkAbwBuACwAIAAuAC4ALgANAEkAbQBwAGEA aQByAG0AZQBuAHQAIABpAG4AZgBvADoAIAB0AGgAaQBzACAAZAByAGEAZgB0ACAAaQBuAHYAbwBs AHYAZQBkAA0ACQBUAHcAbwAgAHQAbwBwAC0AVABMAFYAcwAgAGEAcgBlACAAZABlAGYAaQBuAGUA ZAAgAHQAbwAgAGQAZQBzAGMAcgBpAGIAZQAgAFAATABJACAAKABQAGgAeQBzAGkAYwBhAGwAIABM AGEAeQBlAHIAIABJAG0AcABhAGkAcgBtAGUAbgB0AHMAKQAgAGkAbgBmAG8AcgBtAGEAdABpAG8A bgA6AA0ATABpAG4AawAgAFAATABJACAAVABMAFYAIAAtAEQAZQBzAGMAcgBpAGIAZQBzACAAdABo AGUAIABwAGgAeQBzAGkAYwBhAGwAIABsAGEAeQBlAHIAIABpAG0AcABhAGkAcgBtAGUAbgB0AHMA IAByAGUAbABhAHQAZQBkACAAdABvACAAdABoAGUAIABsAGkAbgBrAA0ATgBvAGQAZQAgAFAATABJ ACAAVABMAFYAIAAtAEQAZQBzAGMAcgBpAGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwA IABsAGEAeQBlAHIAIABpAG0AcABhAGkAcgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABv ACAAdABoAGUAIABuAG8AZABlAAAAoQ+gAQAAXAAAAAAAsjAKAAIA2AAGAAAAAAGCABQABwA9AAAA AAAhAAoAAQAAAAABBwBNAAAAAQD7AAoACwBsAAYANwAAAAABBwBAAAAAAAAhAAoAAQAAAAABBwB3 AAAAAQD7AAoACwBsAAYANwAAAAABBwAlAAAAAAAhAAoAAQAAAAABBwBUAAAAAACyIAoAAgDYAAYA AAAAARQABwCWAAAAAQD7AAoACwBsAAYANwAAAAABBwBcAAAAAAAiAAgAFAAUAAAAAARjAAAECwAI AAsAFgApAAAAAARnAAAECwAIAAsAFgAAAAADTQAAAAAIYwAACAsACAALABYAGAAAAAAMYwAADAsA CAALABYACAAAAAIMIgACDAgAFAAgAAAAAAxjAAAMCwAIAAsAFgB3AAAAABBjAAAQCwAIAAsAFgAk AAAAABQmAAAUCAAUAAAA//4BAAAAABQgAAAUCAABAAAAABhnAAAYCwAIAAsAFgAAAP/+UwAAAAAY YwAAGAsACAALABYAWQAAAAAcYwAAHAsACAALABYAPQAAAAAcIgAAHAgAFAAAAKoPpAAAAG8AAAAG AAAACQQECCoAAAAGAAAACQgECGUAAAAGAAAACQQECAMAAAAHAAAAAwAJBAQICgAAAAYAAAAJBAQI AwAAAAcAAAADAAkEBAgOAAAABgAAAAkEBAgJAAAABwAAAAAACQQECJwAAAAGAAAACQQECAoAAAAG AAAACQgECAQAAAAHAAAAAwAJCAQIRwAAAAYAAAAJCAQIlgAAAAYAAAAJBAQIAACmDxYAAAD5HAAA +QEgAfoByAOoAlkFOQTqBsoFDwAE8EgAAAASAArwCAAAAAHUAwAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQ AFQAMQAwAAAAixNpAAAAAADrLggAAAB1V8oBkDd4gQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAiRb/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8A AisAAAAAAAByFxAAAAABABAADBUFAGIAEADKRAUAAAD1DxwAAAAZAQAApBkAA+gUBQA3UAUAAQAA AGgAAAABAMUxDwDoA7YvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAABFAAAA AQAAAAAAAAEPAPIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5ADAAAAALcPRAAAAEEAcgBp AGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwDkhIgW8IMTAHg6CzDwgxMAAAAAAA8A 1QcAAAYiEAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiWEwBolhMA5ISI FvCDEwB4Ogsw8IMTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMPCDEwAAAAAADwDVBwAABCIwALcPRAAAANGeU08A AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDwgxMAAAAAAA8A 1QeGAAYCQAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABh AHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEIlAAtw9EAAAATlOHZcZ+0Z4AAGcAZQByAE4AZQB4AHQA IABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMPCDEwAAAAAADwDVB4YABgJgALcPRAAAAFcAaQBu AGcAZABpAG4AZwBzAAAAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDwgxMAAAAAAA8A 1QcCAAYCcAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAA AHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAGIoAAtw9EAAAAi1tTTwAAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMPCDEwAAAAAADwDVB4YABgKQALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDwgxMAAAAAAA8A 1QcAAAQUoAC3D0QAAABUAGkAbQBlAHMAAABlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAA AHIAAAB4Ogsw8IMTAAAAAAAPANUHAAAEJLAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8A bQBhAG4AAABCAG8AbABkAAAAAAByAAAAeDoLMPCDEwAAAAAADwDVBwAABhIAAKQPDAAAAIAAYgAA AAgAAAAUAAAApQ8aAAAAAACzqC4AAwD8AAYAAAAAAQEAMgD5AQcAAAAAAKkPCgAAAAcAAAACAAkE AABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAA AAEAAAD//xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAE gAQAAAAADwALBB4SAAAPAADwFhIAAAAABvAgCAAABAgEAAMBAABFAQAAFQAAAAAAAAAPAAAAAgAA AD8AAAALAAAACAAAAAwAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAA EwAAAAAAAAAEAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAE AAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkA AAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAACAAAACSAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAIAAAAAAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAC0AAABDAAAAAAAAAAQAAAAA AAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAA AAAGAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAAAAAAAEIAAAAAAAAAGQAAAAAAAAAEAAAAAAAA AAoAAAAAAAAABAAAAAAAAAAEAAAAPwAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAA0A AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAA TwAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAAAABAAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAMAAAAAAAAA AwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABZAAAABwAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAAAAAAD8AAAAAAAAAC8AAABiAAAABAAA AGMAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAABrAAAABAAAAAAAAAAmAAAAAAAAACUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAABx AAAACAAAAAAAAAC1AAAAAAAAAAYAAAB0AAAA+wEAAHUAAABeAAAAAAAAAAgAAAAAAAAABAAAAAAA AAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA APIAAAAAAAAA4wAAAAAAAABdAAAAAAAAAKwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAE AAAAfAAAAAQAAAB9AAAAQQAAAH4AAABxAQAAAAAAAAYAAAAAAAAABgAAAIEAAAAABAAAAAAAAAYA AACBAAAA6gIAAIMAAAC9AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAhwAAABoAAACIAAAABAAA AJ8AAfCMAQAAYgAH8CQAAAAGBgWLNR+9x/hapvOnUBtimEv/ANMqAAABAAAAAAAAAAAAAABSAAfw JAAAAAUF2PPjBALpLtjj7XCYyT0iFf8ATrYAAAEAAADTKgAAAAAAAFIAB/AkAAAABQVuXl4RjS68 ttrj/Ic/k8hg/wAGVwAAAQAAACHhAAAAAAAAYgAH8CQAAAAGBisdnFFBlozbe/74GKTQUnn/AKsz AAABAAAAJzgBAAAAAABiAAfwJAAAAAYGPOoZaAGlT1bU1/i7k1DQSf8A0RUAAAEAAADSawEAAAAA AGIAB/AkAAAABga46WhyF/YLXPj81GTsgmm2/wC8VgUAAQAAAKOBAQAAAAAAMgAH8CQAAAADBO7b tXNqQKC6d3ZzLnFDthX/AEkCAAABAAAAX9gGAAAAAAAyAAfwJAAAAAMEQOvptYDGQz8Z0JsMOdBL JP8AnQIAAAEAAACo2gYAAAAAADIAB/AkAAAAAwSqrbsIEBgFJFUCqAz3dvkF/wBLAgAAAQAAAEXd BgAAAAAAAwgL8AADAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACFAAIAAACHAAEAAACIAAAAAACJ AAAAAAC/AAIADwAMAfQAABANAQAAACAOAQAAACCAAQAAAACBAQQAAAiCAQAAAQCDAQAAAAiEAQAA AQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACO AQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAA AACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDAAQEAAAjBAQAAAQDCAf///wDD AQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAA CADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgCAsvLywADAgAAACAE AgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAA AAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACE AgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAA AADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/N AkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCU AADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABE A3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAABzDSLxCgUAAIwAAQAAAI0A MGUBAH8BAABAAJ4B/////58B/////6ABAAAAIKHBAAAAAKIB/////6MB/////6QBAAAAIKXBAAAA AKYB/////6cB/////78BAAAgANkB/////9oB/////9sBAAAAINzBAAAAAN0B/////94B/////98B AAAAIODBAAAAAOEB/////+IB//////8BAADAABIC/////xMC/////xQCAAAAIBXCAAAAABYC//// /xcC/////xgCAAAAIBnCAAAAABoC/////xsC/////4kC/////4oC/////4sCAAAAIIzCAAAAAI0C /////48DAAAAAJADAgAAAJEDAAAAAJIDAgAAAL8DAIIAgkAFAAAAAEEFAAABAEIF////AEMFAAAA IEQFAAAAAEVFAAAAAEbFAAAAAEcFAAAAAEgFAAAAAEkFAAAAAEoFAAAAAEsFNSUAAEwFAAAIAE0F AAAAAE4FAAAAAE/FAAAAAFAFAAAAAFEFAAAAAFIFAQAAAFMFAQAAAFQFAQAAAFUFAQAAAFcFAgAA AFkF/////1oF/////1sFAAAAIFzFAAAAAF0F/////14F/////18FAAAAIGDFAAAAAGEF/////2IF /////38FBgBOAIAFAAAAAIEFAAABAIIF////AIMFAAAAIIQFAAAAAIVFAAAAAIbFAAAAAIcFAAAA AIgFAAAAAIkFAAAAAIoFAAAAAIsFNSUAAIwFAAAIAI0FAAAAAI4FAAAAAI/FAAAAAJAFAAAAAJEF AAAAAJIFAQAAAJMFAQAAAJQFAQAAAJUFAQAAAJcFAgAAAJkF/////5oF/////5sFAAAAIJzFAAAA AJ0F/////54F/////58FAAAAIKDFAAAAAKEF/////6IF/////78FBgBOAMAFAAAAAMEFAAABAMIF ////AMMFAAAAIMQFAAAAAMVFAAAAAMbFAAAAAMcFAAAAAMgFAAAAAMkFAAAAAMoFAAAAAMsFNSUA AMwFAAAIAM0FAAAAAM4FAAAAAM/FAAAAANAFAAAAANEFAAAAANIFAQAAANMFAQAAANQFAQAAANUF AQAAANcFAgAAANkF/////9oF/////9sFAAAAINzFAAAAAN0F/////94F/////98FAAAAIODFAAAA AOEF/////+IF//////8FBgBOAAAGAAAAAAEGAAABAAIG////AAMGAAAAIAQGAAAAAAVGAAAAAAbG AAAAAAcGAAAAAAgGAAAAAAkGAAAAAAoGAAAAAAsGNSUAAAwGAAAIAA0GAAAAAA4GAAAAAA/GAAAA ABAGAAAAABEGAAAAABIGAQAAABMGAQAAABQGAQAAABUGAQAAABcGAgAAABkG/////xoG/////xsG AAAAIBzGAAAAAB0G/////x4G/////x8GAAAAICDGAAAAACEG/////yIG/////z8GBgBOAEAGAAAA AEEGAAABAEIG////AEMGAAAAIEQGAAAAAEVGAAAAAEbGAAAAAEcGAAAAAEgGAAAAAEkGAAAAAEoG AAAAAEsGNSUAAEwGAAAIAE0GAAAAAE4GAAAAAE/GAAAAAFAGAAAAAFEGAAAAAFIGAQAAAFMGAQAA AFQGAQAAAFUGAQAAAFcGAgAAAFkG/////1oG/////1sGAAAAIFzGAAAAAF0G/////14G/////18G AAAAIGDGAAAAAGEG/////2IG/////38GBgAOAIAAGvEgAAAA/wAAAN3d3QDq6uoA//9mAP+ZAAAA AP8AAJnMAABmmQBAAB7xEAAAAAQAAAj/mQAAAAAAAPcAABAfAPAPjAAAAAAA8wMUAAAAHwAAAAQA AAAAAAAAAQAAgAAAAAAAAPMDFAAAACYAAAAEAAAAAAAAAAIAAIAAAAAAAADzAxQAAAAzAAAABAAA AAAAAAAGAACAAAAAAAAA8wMUAAAAMQAAAAQAAAAAAAAABAAAgAAAAAAAAPMDFAAAADwAAAAAAAAA AAAAAAcAAIAAAAAADwDQB3kMAAAfABQEHAAAAAAAFQQUAAAA0BjNBADKmjtOtdw2AMqaOwECAAAP APoDdwAAAAAA/gMDAAAAAQEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAAAAAAPwliBYIhBMAeDoL MAAAAAAAAAAA7vz//wr///8AABMAcAD7AwgAAAAAAAAAPAIAAHAA+wMIAAAAAAAAABwOAABwAPsD CAAAAAEAAAAJAgAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8AEwQ8AAAAAAD9AzQAAABk AAAAZAAAAGQAAABkAAAAAgAAADSEEwD8+AowaJYTAAAAAAAAAAAAAAAAAAAAAAAAARMADwCIE24L AAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJ FzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAACI2QAAAAAAAAAAAACAAgHg DwCKE/gIAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0ggAAEAAGhBmBQAABQAA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQA AABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAA ACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAAB BwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAg AAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAA AAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAA AAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4A bwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAA AAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEA AAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAA AAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAA AwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABl ACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAA DgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQ8AGxBAAgAAEACvDwgAAAAAAQAABQAAAAAAGRAoAgAAAAAACAwBAAAAAAACAAAB DAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAA AAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhu YW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAA AAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgA AAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAU AAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEA AAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAA AAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0A bwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAG AAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwCKE2gBAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA AIsTSAEAAA8A1gcwAQAAAAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAGiW EwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHgAAGIhAAtw9EAAAAVABpAG0AZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAABolhMAaJYTADCEEwDoghMAeDoLMOiCEwAAAAAADwDWBwAABhIgALcP RAAAAItbU08AAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAwhBMA6IITAHg6CzDo ghMAAAAAAA8A1geGAAYCMAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAGiW EwBolhMAMIQTAOiCEwB4Ogsw6IITAAAAAAAPANYHAAAGIgAADQQIAAAAcLUAAHC1AAAPAIoThgAA AAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTaAAAAC8AyA8MAAAAMADSDwQAAAAAAAAAAAB7FxAA AAADAAAAqAMAAAMAAwACD///DwCuDzQAAAAQAK8PCAAAAAgBAAABAAAAAACsDxwAAAAAAAACAAAA AAAAAAAAAAAAAAIAAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAAIwBPANkPDAAAAAAA2g8EAAAA DQA9AA8A8A9hCwAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA95 AAAAT1NQRiBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW1wYWlybWVudCBBd2FyZSBSb3V0aW5n IGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQgaW4gV2F2ZWxlbmd0aCBTd2l0Y2hlZCBPcHRpY2Fs IE5ldHdvcmtzIAAAoQ8mAAAAegAAAAAAAAAAAHgAAAAAAAIAHAABAAAAAAAAAAEAAAAAAAIAKAAA AKoPMgAAAEUAAAAGAAAACQQJBAEAAAAGAAAACQQECDMAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkE EACfDwQAAAAFAAAAAACoD58AAABDQ0FNUCBXRywgSUVURiA3OHRoLCBNYWFzdHJpY2h0LCBOZXRo ZXJsYW5kcyANDWRyYWZ0LWFncmF6LWNjYW1wLXdzb24taW1wYWlybWVudC1vc3BmLTAwLnR4dA0N RmVybmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMuZWR1KQ1ZYWJpbiBZZSAoeWFiaW4ueWVAaHVh d2VpLmNvbSkAAKEPPgAAAKAAAAAAAAAQAAB4AC8AAAAAAAYAEgAAAAAFLgAAAAAAAgAYAAEAAAAB AAYAAQASAAAA//5CAAAAAAACABIAAACqDz4AAAAVAAAABgAAAAkEBAgYAAAABgAAAAkEBAgwAAAA BgAAAAkEBAgBAAAABgAAAAkIBAhCAAAABwAAAAAADAQECA8A8g8YAAAAAADzDxAAAAAAAAAAAAAA AAAAAAAIWAswAADfDwgAAAAVAAAALQAAAAAA8wMUAAAAUwAAAAQAAAACAAAADgEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPDwAAAEFja25vd2xlZGdtZW50cwAAoQ8UAAAAEAAAAAAAAAAAABAAAAAAAAIA JAAAAKoPGgAAAA8AAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAAB AAAABwAAAAAABAgJBAAA8wMUAAAAVgAAAAQAAAABAAAAEQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP CgAAAEJhY2tncm91bmQAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQAAACqDxoAAAAKAAAABgAA AAkEBAgBAAAABwAAAAAABAgJBAAA8wMUAAAAaAAAAAQAAAACAAAAHwEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPCgAAAE9iamVjdGl2ZSAAAKEPHAAAAAsAAAAAAAAAAAAJAAAAAAACACQAAgAAAAAAAAAA AKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAA BwAAAAAABAgJBAAA8wMUAAAAYgAAAAQAAAACAAAAGQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJQAA AE9TUEYgcm91dGluZyBmb3IgSUEtUldBIC1OZXcgUExJIFRMViAAAKEPKgAAACYAAAAAAAAAAAAX AAAAAABDAAsACwAkAA0AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAFwAAAAYAAAAJCAQIBQAAAAYA AAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAA AKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABXAAAABAAAAAIAAAASAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExpbmsgUExJIFRMViAAAKEPHAAAACEAAAAA AAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAAAB8AAAAGAAAACQQJBAEAAAAGAAAACQQECAEA AAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYwAA AAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21wb3NpdGlvbiBvZiBO b2RlIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAAAAAAAACqDz4AAAAT AAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAA BAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGQAAAAEAAAAAgAA ABsBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABTb21lIHN1Yi1UTFZzIGFuZCBzdWItc3ViLVRM VnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQAAACqD1AAAAAJAAAABgAAAAkEBAgDAAAABwAA AAMACQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgBAAAABwAAAAAA BAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGUAAAAEAAAAAgAA ABwBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBMaW5r IFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDxoAAAAkAAAABgAAAAkECQQB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGYA AAAEAAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIgVHlwZXMgZm9y IHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACqDzIAAAAYAAAA BgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAA AAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcAAAAEAAAAAgAAAB4BAAAAAAAAAACfDwQA AAAAAAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBUTFYAAKEPFAAAABwAAAAAAAAA AAAcAAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAH AAAAAAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8KAAAA TmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPDAAAAAsAAAAGAAAACQQE CBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFjY29yZGluZyB0byB0aGUgZmVlZGJhY2sg ZnJvbSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QNS2VlcCB1cGdyYWRpbmcgd2hlbiBJVFUt VCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50IGluZm9ybWF0aW9uDUNvbW1lbnRzIGFy ZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEPRgAAAIsAAAAAALIAAAADANgABgAAAAABIAAAAAAAsiAA AAMA2AAGAAAAAAEyABsAAAAAAGEACwAAAAsAkAAAAAAEQQAABAsACwAAAKoPGgAAAKoAAAAGAAAA CQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAAAPMDFAAAAAYAAAAAAAAAAAAAAAABAAAAAAAAAADz AxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA6gMAAAAADwDuA0sLAAACAO8DGAAAAAEAAAANDgAA AAAAAAcAAIAAAAAABwALMA8ADARiCgAADwAC8FoKAADABwjwCAAAAAMAAAAD1AMADwAD8PIJAAAP AATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAANQDAAUAAAAPAATweAAAABIA CvAIAAAAAtQDACACAABjAAvwJAAAAH8AAAAEAIAAxCVhE78BAAABAP8BAAABAAEDAgADAIgDAAAA AAAAEPAIAAAAdwDcARwWlwIPABHwEAAAAAAAwwsIAAAAAAAAAA0AYRMPAA3wDAAAAAAAng8EAAAA AAAAAA8ABPA6CQAAEgAK8AgAAAAD1AMAAAoAAPMAC/BaAAAAfwAAAAQAgAAAha8PgQBgNQEAggCw mgAAgwBgNQEAhACwmgAAvwAAAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAI PwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAYAD/AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAABDwCAAAAPICZALiFRwODwAR8KgAAAAPAIgToAAAAA8AihOYAAAA AAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixN6AAAAAACsD3IAAAAAAAAAAAAAAAAAAAAAAAADAQAM AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAQAMAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD AQAMAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAA3wwgcAAAAAnw8EAAAABAAA AAAAoA9KBQAASQBuACAARwBNAFAATABTAC0AYgBhAHMAZQBkACAAVwBTAE8ATgAgAG4AZQB0AHcA bwByAGsAcwAsACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGkAbgBmAG8AcgBtAGEAdABp AG8AbgAgAG4AZQBlAGQAIAB0AG8AIABiAGUAIABmAGwAbwBvAGQAZQBkACAAdABoAHIAbwB1AGcA aAAgAHIAbwB1AHQAaQBuAGcAOgANAE4AbwByAG0AYQBsACAAcgBvAHUAdABpAG4AZwAgAGkAbgBm AG8AOgAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAAWwBSAEYAQwAgADMANgAzADAAXQAgAGEA bgBkACAAWwBSAEYAQwAgADQAMgAwADMAXQAuAA0ATgBvAGQAZQAgAEkARAAsACAATABpAG4AawAg AEkARAAsACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AGkAdgBlACAARwByAG8AdQBwACwAIABJAFMA QwBEACwAIABQAHIAbwB0AGUAYwB0AGkAbwBuACwAIABUAEUAIABtAGUAdAByAGkAYwAsACAAJiAN AFIAVwBBACAAaQBuAGYAbwA6ACAAZABlAHMAYwByAGkAYgBlAGQAIABpAG4AIABbAHIAdwBhAC0A aQBuAGYAbwBdACAALAAgAFsAcgB3AGEALQBlAG4AYwBvAGQAZQBdACAAYQBuAGQAIABbAHIAdwBh AC0AbwBzAHAAZgBdAA0AUwB3AGkAdABjAGgAIABDAG8AbgBuAGUAYwB0AGkAdgBpAHQAeQAgAE0A YQB0AHIAaQB4ACwAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAQwBvAG4AdgBlAHIAdABlAHIAIABQ AG8AbwBsACAAaQBuAGYAbwAsACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAEEAdgBhAGkAbABhAGIA aQBsAGkAdAB5ACwAIAAgAFAAbwByAHQAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAUgBlAHMAdABy AGkAYwB0AGkAbwBuACwAIAAuAC4ALgANAEkAbQBwAGEAaQByAG0AZQBuAHQAIABpAG4AZgBvADoA IAB0AGgAaQBzACAAZAByAGEAZgB0ACAAaQBuAHYAbwBsAHYAZQBkAA0ACQBUAHcAbwAgAHQAbwBw AC0AVABMAFYAcwAgAGEAcgBlACAAZABlAGYAaQBuAGUAZAAgAHQAbwAgAGQAZQBzAGMAcgBpAGIA ZQAgAFAATABJACAAKABQAGgAeQBzAGkAYwBhAGwAIABMAGEAeQBlAHIAIABJAG0AcABhAGkAcgBt AGUAbgB0AHMAKQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgA6AA0ATABpAG4AawAgAFAATABJACAA VABMAFYAIAAtAEQAZQBzAGMAcgBpAGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwAIABs AGEAeQBlAHIAIABpAG0AcABhAGkAcgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABvACAA dABoAGUAIABsAGkAbgBrAA0ATgBvAGQAZQAgAFAATABJACAAVABMAFYAIAAtAEQAZQBzAGMAcgBp AGIAZQBzACAAdABoAGUAIABwAGgAeQBzAGkAYwBhAGwAIABsAGEAeQBlAHIAIABpAG0AcABhAGkA cgBtAGUAbgB0AHMAIAByAGUAbABhAHQAZQBkACAAdABvACAAdABoAGUAIABuAG8AZABlAAAAoQ+S AQAAXAAAAAAAsjAKAAIA2AAGAAAAAAGCABQABwA9AAAAAAAhAAoAAQAAAAABBwBHAAAAAQD7AAoA CwBsAAYANwAAAAABBwBAAAAAAAAhAAoAAQAAAAABBwB3AAAAAQD7AAoACwBsAAYANwAAAAABBwAl AAAAAAAhAAoAAQAAAAABBwBUAAAAAACyIAoAAgDYAAYAAAAAARQABwCWAAAAAQD7AAoACwBsAAYA NwAAAAABBwBcAAAAAAAiAAgAFAAUAAAAAARjAAAECwAIAAsAEgApAAAAAARnAAAECwAIAAsAEgAA AAADRwAAAAAIYwAACAsACAALABIAGAAAAAAMYwAADAsACAALABIACAAAAAIMIgACDAgAEgAgAAAA AAxjAAAMCwAIAAsAEgB3AAAAABBjAAAQCwAIAAsAEgAkAAAAABQmAAAUCAAUAAAA//4BAAAAABQg AAAUCAABAAAAABhnAAAYCwAIAAsAFgAAAP/+UwAAAAAYYwAAGAsACAALABYAlgAAAAAcYwAAHAsA CAALABYAAACqD6QAAABvAAAABgAAAAkEBAgqAAAABgAAAAkIBAhfAAAABgAAAAkEBAgDAAAABwAA AAMACQQECAoAAAAGAAAACQQECAMAAAAHAAAAAwAJBAQIDgAAAAYAAAAJBAQICAAAAAcAAAADAAkE BAidAAAABgAAAAkEBAgKAAAABgAAAAkIBAgEAAAABwAAAAMACQgECEcAAAAGAAAACQgECJYAAAAG AAAACQQECAAApg8WAAAA+RwAAPkBIAH6AcgDqAJZBTkE6gbKBQ8ABPBIAAAAEgAK8AgAAAAB1AMA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAdVfKAZA3eIEAAAArBAAA AAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAIkW/////xIAAAAPAD3x DQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchcQAAAAAQAQAHNQBQBiABAAMYAFAAAA9Q8cAAAA GQEAAKQZAANPUAUAhIsFAAEAAABoAAAAAQDFMQ8A6AO2LwAAAQDpAygAAACAFgAA4BAAAOAQAACA FgAABQAAAAoAAAAFAAAARQAAAAEAAAAAAAABDwDyA2oEAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A 1QeQAwAAAAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAFSpEwBUqRMA5ISI FtyWEwB4Ogsw3JYTAAAAAAAPANUHAAAGIhAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8A bQBhAG4AAABUqRMAVKkTAOSEiBbclhMAeDoLMNyWEwAAAAAADwDVB4AABiIgALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0AAAATAHg6CzDclhMAAAAAAA8A 1QcAAAQiMAC3D0QAAADRnlNPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBt AAAAEwB4Ogsw3JYTAAAAAAAPANUHhgAGAkAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMNyWEwAAAAAADwDVBwAABCJQALcPRAAAAE5Th2XG ftGeAABnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDclhMAAAAAAA8A 1QeGAAYCYAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABh AHIAAAB4Ogsw3JYTAAAAAAAPANUHAgAGAnAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMNyWEwAAAAAADwDVBwAABiKAALcPRAAAAItbU08A AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDclhMAAAAAAA8A 1QeGAAYCkAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEIAbwBsAGQAAAAA AHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAEFKAAtw9EAAAAVABpAG0AZQBzAAAAZQByAE4AZQB4AHQA IABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMNyWEwAAAAAADwDVBwAABCSwALcPRAAAAFQAaQBt AGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAQgBvAGwAZAAAAAAAcgAAAHg6CzDclhMAAAAAAA8A 1QcAAAYSAACkDwwAAACAAGIAAAAIAAAAFAAAAKUPGgAAAAAAs6guAAMA/AAGAAAAAAEBADIA+QEH AAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAA AABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQeEgAADwAA8BYSAAAAAAbwIAgAAAQIBAADAQAA RQEAABUAAAAAAAAADwAAAAIAAAA/AAAACwAAAAgAAAAMAAAABAAAAAAAAAAQAAAAAAAAAAQAAAAA AAAAEwAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAANAAAAAAAAAAQAAAAAAAAACgAAAAAA AAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAA AAQAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAgAAAA kgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAFAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYA AAAtAAAAQwAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAA AAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAAAAAABCAAAA AAAAABkAAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABAAAAD8AAAAJAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABgAAAAAAAAANAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAH AAAAAAAAAAQAAAAAAAAABAAAAE8AAAAMAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAkA AAAAAAAAQAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAMAAAAA AAAABAAAAAAAAAADAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAWQAA AAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAQAAAAAAAAA /AAAAAAAAAAvAAAAYgAAAAQAAABjAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAawAAAAQAAAAAAAAAJgAAAAAAAAAlAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAHAAAAcQAAAAgAAAAAAAAAtQAAAAAAAAAGAAAAdAAAAPsBAAB1AAAAXgAA AAAAAAAIAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAADyAAAAAAAAAOMAAAAAAAAAXQAAAAAAAACsAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAgAAAAAAAAABAAAAHwAAAAEAAAAfQAAAEEAAAB+AAAAcQEAAAAAAAAGAAAAAAAA AAYAAACBAAAAAAQAAAAAAAAGAAAAgQAAAOoCAACDAAAAvQAAAAAAAAAGAAAAAAAAAAYAAAAAAAAA BAAAAIcAAAAaAAAAiAAAAAQAAACfAAHwjAEAAGIAB/AkAAAABgYFizUfvcf4Wqbzp1AbYphL/wDT KgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBdjz4wQC6S7Y4+1wmMk9IhX/AE62AAABAAAA0yoAAAAA AABSAAfwJAAAAAUFbl5eEY0uvLba4/yHP5PIYP8ABlcAAAEAAAAh4QAAAAAAAGIAB/AkAAAABgYr HZxRQZaM23v++Bik0FJ5/wCrMwAAAQAAACc4AQAAAAAAYgAH8CQAAAAGBjzqGWgBpU9W1Nf4u5NQ 0En/ANEVAAABAAAA0msBAAAAAABiAAfwJAAAAAYGuOlochf2C1z4/NRk7IJptv8AvFYFAAEAAACj gQEAAAAAADIAB/AkAAAAAwTu27VzakCgund2cy5xQ7YV/wBJAgAAAQAAAF/YBgAAAAAAMgAH8CQA AAADBEDr6bWAxkM/GdCbDDnQSyT/AJ0CAAABAAAAqNoGAAAAAAAyAAfwJAAAAAMEqq27CBAYBSRV AqgM93b5Bf8ASwIAAAEAAABF3QYAAAAAAAMIC/AAAwAAgQBgNQEAggCwmgAAgwBgNQEAhACwmgAA hQACAAAAhwABAAAAiAAAAAAAiQAAAAAAvwACAA8ADAH0AAAQDQEAAAAgDgEAAAAggAEAAAAAgQEE AAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghkEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAA iwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEA AAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEMAB4A wAEBAAAIwQEAAAEAwgH///8AwwEAAAAgxAEAAAAAxUEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEA AAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEAAAAAz8EAAAAA1wECAAAA/wEOAA4AAAIAAAAA AQICAAAIAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIA AAAACwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAA gQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIA AAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAA ygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQ wwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAA QQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMA AAAAcw0i8QoFAACMAAEAAACNADBlAQB/AQAAQACeAf////+fAf////+gAQAAACChwQAAAACiAf// //+jAf////+kAQAAACClwQAAAACmAf////+nAf////+/AQAAIADZAf/////aAf/////bAQAAACDc wQAAAADdAf/////eAf/////fAQAAACDgwQAAAADhAf/////iAf//////AQAAwAASAv////8TAv// //8UAgAAACAVwgAAAAAWAv////8XAv////8YAgAAACAZwgAAAAAaAv////8bAv////+JAv////+K Av////+LAgAAACCMwgAAAACNAv////+PAwAAAACQAwIAAACRAwAAAACSAwIAAAC/AwCCAIJABQAA AABBBQAAAQBCBf///wBDBQAAACBEBQAAAABFRQAAAABGxQAAAABHBQAAAABIBQAAAABJBQAAAABK BQAAAABLBTUlAABMBQAACABNBQAAAABOBQAAAABPxQAAAABQBQAAAABRBQAAAABSBQEAAABTBQEA AABUBQEAAABVBQEAAABXBQIAAABZBf////9aBf////9bBQAAACBcxQAAAABdBf////9eBf////9f BQAAACBgxQAAAABhBf////9iBf////9/BQYATgCABQAAAACBBQAAAQCCBf///wCDBQAAACCEBQAA AACFRQAAAACGxQAAAACHBQAAAACIBQAAAACJBQAAAACKBQAAAACLBTUlAACMBQAACACNBQAAAACO BQAAAACPxQAAAACQBQAAAACRBQAAAACSBQEAAACTBQEAAACUBQEAAACVBQEAAACXBQIAAACZBf// //+aBf////+bBQAAACCcxQAAAACdBf////+eBf////+fBQAAACCgxQAAAAChBf////+iBf////+/ BQYATgDABQAAAADBBQAAAQDCBf///wDDBQAAACDEBQAAAADFRQAAAADGxQAAAADHBQAAAADIBQAA AADJBQAAAADKBQAAAADLBTUlAADMBQAACADNBQAAAADOBQAAAADPxQAAAADQBQAAAADRBQAAAADS BQEAAADTBQEAAADUBQEAAADVBQEAAADXBQIAAADZBf/////aBf/////bBQAAACDcxQAAAADdBf// ///eBf/////fBQAAACDgxQAAAADhBf/////iBf//////BQYATgAABgAAAAABBgAAAQACBv///wAD BgAAACAEBgAAAAAFRgAAAAAGxgAAAAAHBgAAAAAIBgAAAAAJBgAAAAAKBgAAAAALBjUlAAAMBgAA CAANBgAAAAAOBgAAAAAPxgAAAAAQBgAAAAARBgAAAAASBgEAAAATBgEAAAAUBgEAAAAVBgEAAAAX BgIAAAAZBv////8aBv////8bBgAAACAcxgAAAAAdBv////8eBv////8fBgAAACAgxgAAAAAhBv// //8iBv////8/BgYATgBABgAAAABBBgAAAQBCBv///wBDBgAAACBEBgAAAABFRgAAAABGxgAAAABH BgAAAABIBgAAAABJBgAAAABKBgAAAABLBjUlAABMBgAACABNBgAAAABOBgAAAABPxgAAAABQBgAA AABRBgAAAABSBgEAAABTBgEAAABUBgEAAABVBgEAAABXBgIAAABZBv////9aBv////9bBgAAACBc xgAAAABdBv////9eBv////9fBgAAACBgxgAAAABhBv////9iBv////9/BgYADgCAABrxIAAAAP8A AADd3d0A6urqAP//ZgD/mQAAAAD/AACZzAAAZpkAQAAe8RAAAAAEAAAI/5kAAAAAAAD3AAAQHwDw D4wAAAAAAPMDFAAAAB8AAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAmAAAABAAAAAAAAAACAACA AAAAAAAA8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMDFAAAADEAAAAEAAAAAAAAAAQAAIAA AAAAAADzAxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ad5DAAAHwAUBBwAAAAAABUEFAAAANAY zQQAypo7TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEBAAAA/QM0AAAAQgAAAGQAAABCAAAA ZAAAAAAAAAD8JYgW9JYTAHg6CzAAAAAAAAAAAO78//8K////AAATAHAA+wMIAAAAAAAAADwCAABw APsDCAAAAAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIA AAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAAglxMA/PgKMFSpEwAAAAAAAAAA AAAAAAAAAAAAAAETAA8AiBNuCwAADwCKE2gAAAAAALoPFAAAAF8AXwBfAFAAUABUADIAMAAwADEA AACLE0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAA AAAAiNkAAAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABfAF8AXwBQAFAAVABNAGEAYwAxADEA AACLE9IIAABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAA AAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAA AAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAAB BQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAA AAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYA AAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAA AAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAAB AQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1k AAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAA AAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAA AQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQBAAAAAAAIDAEAAAAAAAIAAAEMAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQA AABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAA ACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAAB BwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIAABAArw8IAAAAAAEAAAUAAAAAABkQ KAIAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgM AQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAA AQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAA AAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAI AAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAA AAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AihNoAQAAAAC6DxAA AABfAF8AXwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAAtw9EAAAATQBTACAAUABHAG8AdABo AGkAYwAAAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSVEwAAAAAADwDWB4AABiIQALcP RAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkTAFSpEwAclxMA1JUTAHg6CzDU lRMAAAAAAA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAFSp EwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHhgAGAjAAtw9EAAAAQQByAGkAYQBsAAAATgBl AHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSVEwAAAAAADwDWBwAABiIAAA0E CAAAAHC1AABwtQAADwCKE4YAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE2gAAAAvAMgPDAAA ADAA0g8EAAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg///w8Arg80AAAAEACvDwgAAAAIAQAA AQAAAAAArA8cAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAD8A2Q8MAAAAAADaDwQAAAAA ACMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPYQsAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAA AAAAAJ8PBAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEltcGFp cm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25tZW50IGluIFdhdmVsZW5n dGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoAAAAAAAAAAAB4AAAAAAACABwA AQAAAAAAAAABAAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQBAAAABgAAAAkEBAgzAAAABgAA AAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAAQ0NBTVAgV0csIElFVEYgNzh0 aCwgTWFhc3RyaWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jhei1jY2FtcC13c29uLWltcGFp cm1lbnQtb3NwZi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3JhekB0c2MudXBjLmVkdSkNWWFi aW4gWWUgKHlhYmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAAAAAAEAAAeAAvAAAAAAAGABIA AAAABS4AAAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgASAAAAqg8+AAAAFQAAAAYAAAAJ BAQIGAAAAAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQIQgAAAAcAAAAAAAwEBAgPAPIP GAAAAAAA8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAAAC0AAAAAAPMDFAAAAFMAAAAE AAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tub3dsZWRnbWVudHMAAKEPFAAA ABAAAAAAAAAAAAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAA nw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFYAAAAEAAAAAQAAABEBAAAA AAAAAACfDwQAAAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQAAAALAAAAAAAAAAAACwAAAAAA AgAkAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAPMDFAAAAGgAAAAEAAAAAgAA AB8BAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABPYmplY3RpdmUgAAChDxwAAAALAAAAAAAAAAAA CQAAAAAAAgAkAAIAAAAAAAAAAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8E AAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIAAAAEAAAAAgAAABkBAAAAAAAA AACfDwQAAAAAAAAAAACoDyUAAABPU1BGIHJvdXRpbmcgZm9yIElBLVJXQSAtTmV3IFBMSSBUTFYg AAChDyoAAAAmAAAAAAAAAAAAFwAAAAAAQwALAAsAJAANAAAAAAACACQAAgAAAAAAAAAAAKoPPgAA ABcAAAAGAAAACQgECAUAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAA AAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVwAAAAQAAAAC AAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21wb3NpdGlvbiBvZiBMaW5rIFBM SSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAAAAAAAACqDyYAAAAfAAAABgAA AAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABU aGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAAoQ8cAAAAIQAAAAAAAAAAAB8AAAAAAAIA JAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAA AAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkE AADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAAU29tZSBzdWIt VExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAAAAAAAAAAHwAAAAAAAgAkAAAAqg9QAAAA CQAAAAYAAAAJBAQIAwAAAAcAAAADAAkECQQBAAAABwAAAAMACQQECA0AAAAGAAAACQQECAQAAAAH AAAAAwAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkE AADzAxQAAABlAAAABAAAAAIAAAAcAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVy IFR5cGVzIGZvciB0aGUgTGluayBQTEkgVExWAAChDxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAA qg8aAAAAJAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAH AAAAAAAECAkEAADzAxQAAABmAAAABAAAAAIAAAAdAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAA UGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQTEkgVExWAAChDxQAAAAlAAAAAAAAAAAAJQAA AAAAAgAkAAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAcA AAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABnAAAABAAA AAIAAAAeAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAAQW4gRXhhbXBsZSBvZiBjb21wb25lbnQg VExWAAChDxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAkAAAAqg8MAAAAHAAAAAYAAAAJBAQIEACfDwQA AAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAARAAAAAAAAAACAAAACAEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACACQA AACqDwwAAAALAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKgPqgAAAFJlZmluZSBpdCBhY2NvcmRp bmcgdG8gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcgb3IgbWFpbGluZyBsaXN0DUtlZXAg dXBncmFkaW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0aGUgc3RhbmRhcmQgaW1wYWlybWVudCBpbmZv cm1hdGlvbg1Db21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lhdGVkAAChD0YAAACLAAAAAACyAAAA AwDYAAYAAAAAASAAAAAAALIgAAADANgABgAAAAABMgAbAAAAAABhAAsAAAALAJAAAAAABEEAAAQL AAsAAACqDxoAAACqAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A8A84AAAAAADzAxQAAAAGAAAA AAAAAAAAAAAAAQAAAAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEAAAAAAAAAAOoDAAAAAA8A7gNL CwAAAgDvAxgAAAABAAAADQ4AAAAAAAAHAACAAAAAAAcACzAPAAwEYgoAAA8AAvBaCgAAwAcI8AgA AAADAAAAA9QDAA8AA/DyCQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AADUAwAFAAAADwAE8HgAAAASAArwCAAAAALUAwAgAgAAYwAL8CQAAAB/AAAABACAAMQlYRO/AQAA AQD/AQAAAQABAwIAAwCIAwAAAAAAABDwCAAAAHcA3AEcFpcCDwAR8BAAAAAAAMMLCAAAAAAAAAAN AGETDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwOgkAABIACvAIAAAAA9QDAAAKAADzAAvwWgAAAH8A AAAEAIAAAIWvD4EAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAe AMABAQAACP8BBgAOAAECAgAACD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAAGAA/wEAAMAA vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADFAmQC4hXvDQ8AEfCo AAAADwCIE6AAAAAPAIoTmAAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTegAAAAAArA9yAAAA AAAAAAAAAAAAAAAAAAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwEADAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwEADAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwAN8MIHAAAAAJ8PBAAAAAQAAAAAAKAPSgUAAEkAbgAgAEcATQBQAEwAUwAtAGIAYQBzAGUAZAAg AFcAUwBPAE4AIABuAGUAdAB3AG8AcgBrAHMALAAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcA IABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABuAGUAZQBkACAAdABvACAAYgBlACAAZgBsAG8AbwBk AGUAZAAgAHQAaAByAG8AdQBnAGgAIAByAG8AdQB0AGkAbgBnADoADQBOAG8AcgBtAGEAbAAgAHIA bwB1AHQAaQBuAGcAIABpAG4AZgBvADoAIABkAGUAcwBjAHIAaQBiAGUAZAAgAGkAbgAgAFsAUgBG AEMAIAAzADYAMwAwAF0AIABhAG4AZAAgAFsAUgBGAEMAIAA0ADIAMAAzAF0ALgANAE4AbwBkAGUA IABJAEQALAAgAEwAaQBuAGsAIABJAEQALAAgAEEAZABtAGkAbgBpAHMAdAByAGEAdABpAHYAZQAg AEcAcgBvAHUAcAAsACAASQBTAEMARAAsACAAUAByAG8AdABlAGMAdABpAG8AbgAsACAAVABFACAA bQBlAHQAcgBpAGMALAAgACYgDQBSAFcAQQAgAGkAbgBmAG8AOgAgAGQAZQBzAGMAcgBpAGIAZQBk ACAAaQBuACAAWwByAHcAYQAtAGkAbgBmAG8AXQAgACwAIABbAHIAdwBhAC0AZQBuAGMAbwBkAGUA XQAgAGEAbgBkACAAWwByAHcAYQAtAG8AcwBwAGYAXQANAFMAdwBpAHQAYwBoACAAQwBvAG4AbgBl AGMAdABpAHYAaQB0AHkAIABNAGEAdAByAGkAeAAsACAAVwBhAHYAZQBsAGUAbgBnAHQAaAAgAEMA bwBuAHYAZQByAHQAZQByACAAUABvAG8AbAAgAGkAbgBmAG8ALAAgAFcAYQB2AGUAbABlAG4AZwB0 AGgAIABBAHYAYQBpAGwAYQBiAGkAbABpAHQAeQAsACAAIABQAG8AcgB0ACAAVwBhAHYAZQBsAGUA bgBnAHQAaAAgAFIAZQBzAHQAcgBpAGMAdABpAG8AbgAsACAALgAuAC4ADQBJAG0AcABhAGkAcgBt AGUAbgB0ACAAaQBuAGYAbwA6ACAAdABoAGkAcwAgAGQAcgBhAGYAdAAgAGkAbgB2AG8AbAB2AGUA ZAANAAkAVAB3AG8AIAB0AG8AcAAtAFQATABWAHMAIABhAHIAZQAgAGQAZQBmAGkAbgBlAGQAIAB0 AG8AIABkAGUAcwBjAHIAaQBiAGUAIABQAEwASQAgACgAUABoAHkAcwBpAGMAYQBsACAATABhAHkA ZQByACAASQBtAHAAYQBpAHIAbQBlAG4AdABzACkAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AOgAN AEwAaQBuAGsAIABQAEwASQAgAFQATABWACAALQBEAGUAcwBjAHIAaQBiAGUAcwAgAHQAaABlACAA cABoAHkAcwBpAGMAYQBsACAAbABhAHkAZQByACAAaQBtAHAAYQBpAHIAbQBlAG4AdABzACAAcgBl AGwAYQB0AGUAZAAgAHQAbwAgAHQAaABlACAAbABpAG4AawANAE4AbwBkAGUAIABQAEwASQAgAFQA TABWACAALQBEAGUAcwBjAHIAaQBiAGUAcwAgAHQAaABlACAAcABoAHkAcwBpAGMAYQBsACAAbABh AHkAZQByACAAaQBtAHAAYQBpAHIAbQBlAG4AdABzACAAcgBlAGwAYQB0AGUAZAAgAHQAbwAgAHQA aABlACAAbgBvAGQAZQAAAKEPkgEAAFwAAAAAALIwCgACANgABgAAAAABggAUAAcAPQAAAAAAIQAK AAEAAAAAAQcARwAAAAEA+wAKAAsAbAAGADcAAAAAAQcAQAAAAAAAIQAKAAEAAAAAAQcAdwAAAAEA +wAKAAsAbAAGADcAAAAAAQcAJQAAAAAAIQAKAAEAAAAAAQcAVAAAAAAAsiAKAAIA2AAGAAAAAAEU AAcAlgAAAAEA+wAKAAsAbAAGADcAAAAAAQcAXAAAAAAAIgAIABQAFAAAAAAEYwAABAsACAALABIA KQAAAAAEZwAABAsACAALABIAAAAAA0cAAAAACGMAAAgLAAgACwASABgAAAAADGMAAAwLAAgACwAS AAgAAAACDCIAAgwIABIAIAAAAAAMYwAADAsACAALABIAdwAAAAAQYwAAEAsACAALABIAJAAAAAAU JgAAFAgAFAAAAP/+AQAAAAAUIAAAFAgAAQAAAAAYZwAAGAsACAALABYAAAD//lMAAAAAGGMAABgL AAgACwAWAJYAAAAAHGMAABwLAAgACwAWAAAAqg+kAAAAbwAAAAYAAAAJBAQIKgAAAAYAAAAJCAQI XwAAAAYAAAAJBAQIAwAAAAcAAAADAAkEBAgKAAAABgAAAAkEBAgDAAAABwAAAAMACQQECA4AAAAG AAAACQQECAgAAAAHAAAAAwAJBAQInQAAAAYAAAAJBAQICgAAAAYAAAAJCAQIBAAAAAcAAAADAAkI BAhHAAAABgAAAAkIBAiWAAAABgAAAAkEBAgAAKYPFgAAAPkcAAD5ASAB+gHIA6gCWQU5BOoGygUP AATwSAAAABIACvAIAAAAAdQDAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu CAAAAHVXygGQN3iBAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAACJFv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXEAAAAAEAEADA iwUAYgAQAH67BQAAAPUPHAAAAAABAACkGQADnIsFANHGBQABAAAAaAAAAAEAxTEPAOgDti8AAAEA 6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABQAAAEUAAAABAAAAAAAAAQ8A8gNqBAAALwDI DwwAAAAwANIPBAAAAAAAAAAPANUHkAMAAAAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8A bQBhAG4AAABUqRMAVKkTAOSEiBbclhMAeDoLMNyWEwAAAAAADwDVBwAABiIQALcPRAAAAE0AUwAg AFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAVKkTAFSpEwDkhIgW3JYTAHg6CzDclhMAAAAAAA8A 1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAE0AZQBkAGkAdQBt AAAAEwB4Ogsw3JYTAAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMNyWEwAAAAAADwDVB4YABgJAALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEAcgAAAHg6CzDclhMAAAAAAA8A 1QcAAAQiUAC3D0QAAABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAgAEwAVAAgAFIAZQBnAHUAbABh AHIAAAB4Ogsw3JYTAAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAB4AHQA IABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMNyWEwAAAAAADwDVBwIABgJwALcPRAAAAEYAcgB1 AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAAcgAAAHg6CzDclhMAAAAAAA8A 1QcAAAYigAC3D0QAAACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAgAEwAVAAgAEwAaQBnAGgAdAAA AHIAAAB4Ogsw3JYTAAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUAdABpAGcAZQByAE4AZQB4AHQA IABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMNyWEwAAAAAADwDVBwAABBSgALcPRAAAAFQAaQBt AGUAcwAAAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAAcgAAAHg6CzDclhMAAAAAAA8A 1QcAAAQksAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAEIAbwBsAGQAAAAA AHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAACAAAABQAAAClDxoAAAAAALOo LgADAPwABgAAAAABAQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAi IAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEHhIAAA8AAPAW EgAAAAAG8CAIAAAECAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAAPwAAAAsAAAAIAAAADAAAAAQA AAAAAAAAEAAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAA AAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAA AAAABAAAAAAAAAAhAAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABQAAAAAA AAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAHAAAAAAAA AAcAAAAAAAAABwAAAAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAA BgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAH AAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAQA AAA/AAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABPAAAADAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACwAAAAAAAAAEAAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAAYwAAAAYAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAGsAAAAEAAAAAAAA ACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEAAAAIAAAAAAAAALUAAAAAAAAA BgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAh AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA8gAAAAAAAADjAAAAAAAAAF0A AAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAB8AAAABAAAAH0AAABBAAAA fgAAAHEBAAAAAAAABgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAAAIEAAADqAgAAgwAAAL0AAAAA AAAABgAAAAAAAAAGAAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAAnwAB8IwBAABiAAfwJAAAAAYG BYs1H73H+Fqm86dQG2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/AkAAAABQXY8+MEAuku2OPtcJjJ PSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry22uP8hz+TyGD/AAZXAAABAAAA IeEAAAAAAABiAAfwJAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMAAAEAAAAnOAEAAAAAAGIAB/Ak AAAABgY86hloAaVPVtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAAYgAH8CQAAAAGBrjpaHIX9gtc +PzUZOyCabb/ALxWBQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1c2pAoLp3dnMucUO2Ff8ASQIA AAEAAABf2AYAAAAAADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk/wCdAgAAAQAAAKjaBgAAAAAA MgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0GAAAAAAADCAvwAAMAAIEAYDUB AIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAgAPAAwB9AAAEA0B AAAAIA4BAAAAIIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAA AIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEB AAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAA AJsBAAAAAJwBAwAAQL8BDAAeAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbB AAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAA ANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcC AAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAA ABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC 9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAA AMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9AC AAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcA ANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQD fL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAwZQEAfwEAAEAAngH/////nwH/ ////oAEAAAAgocEAAAAAogH/////owH/////pAEAAAAgpcEAAAAApgH/////pwH/////vwEAACAA 2QH/////2gH/////2wEAAAAg3MEAAAAA3QH/////3gH/////3wEAAAAg4MEAAAAA4QH/////4gH/ /////wEAAMAAEgL/////EwL/////FAIAAAAgFcIAAAAAFgL/////FwL/////GAIAAAAgGcIAAAAA GgL/////GwL/////iQL/////igL/////iwIAAAAgjMIAAAAAjQL/////jwMAAAAAkAMCAAAAkQMA AAAAkgMCAAAAvwMAggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAgRAUAAAAARUUAAAAARsUAAAAA RwUAAAAASAUAAAAASQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUAAAAATgUAAAAAT8UAAAAAUAUA AAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAAWQX/////WgX/////WwUAAAAg XMUAAAAAXQX/////XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/////fwUGAE4AgAUAAAAAgQUA AAEAggX///8AgwUAAAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAAiAUAAAAAiQUAAAAAigUAAAAA iwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUAAAAAkgUBAAAAkwUBAAAAlAUB AAAAlQUBAAAAlwUCAAAAmQX/////mgX/////mwUAAAAgnMUAAAAAnQX/////ngX/////nwUAAAAg oMUAAAAAoQX/////ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX///8AwwUAAAAgxAUAAAAAxUUA AAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAAzAUAAAgAzQUAAAAAzgUAAAAA z8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUBAAAA1wUCAAAA2QX/////2gX/ ////2wUAAAAg3MUAAAAA3QX/////3gX/////3wUAAAAg4MUAAAAA4QX/////4gX//////wUGAE4A AAYAAAAAAQYAAAEAAgb///8AAwYAAAAgBAYAAAAABUYAAAAABsYAAAAABwYAAAAACAYAAAAACQYA AAAACgYAAAAACwY1JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAAEAYAAAAAEQYAAAAAEgYBAAAA EwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAAGQb/////Ggb/////GwYAAAAgHMYAAAAAHQb/////Hgb/ ////HwYAAAAgIMYAAAAAIQb/////Igb/////PwYGAE4AQAYAAAAAQQYAAAEAQgb///8AQwYAAAAg RAYAAAAARUYAAAAARsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYAAAAASwY1JQAATAYAAAgATQYA AAAATgYAAAAAT8YAAAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAAVAYBAAAAVQYBAAAAVwYCAAAA WQb/////Wgb/////WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYAAAAgYMYAAAAAYQb/////Ygb/ ////fwYGAA4AgAAa8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA/wAAmcwAAGaZAEAAHvEQAAAA BAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAAAAAAAAABAACAAAAA7wYAAAIG AAADBgAABAYAAAUGAAAGBgAABwYAAAgGAAAJBgAACgYAAAsGAAAMBgAADQYAAA4GAAAPBgAAEAYA ABEGAAASBgAAEwYAABQGAAAVBgAAFgYAABcGAAAYBgAAGQYAABoGAAAbBgAAHAYAAB0GAAAeBgAA HwYAACAGAAAhBgAAIgYAACMGAAAkBgAAJQYAACYGAAAnBgAAKAYAACkGAAAqBgAAKwYAACwGAAAt BgAALgYAAC8GAAAwBgAAMQYAADIGAAAzBgAANAYAADUGAAA2BgAANwYAADgGAAA5BgAAOgYAADsG AAA8BgAAPQYAAD4GAAA/BgAAQAYAAEEGAABCBgAAQwYAAEQGAABFBgAARgYAAEcGAABIBgAASQYA AEoGAABLBgAATAYAAE0GAABOBgAATwYAAFAGAABRBgAAUgYAAFMGAABUBgAAVQYAAFYGAABXBgAA WAYAAFkGAABaBgAAWwYAAFwGAABdBgAAXgYAAF8GAABgBgAAYQYAAGIGAABjBgAAZAYAAGUGAABm BgAAZwYAAGgGAABpBgAAagYAAGsGAABsBgAAbQYAAG4GAABvBgAAcAYAAHEGAAByBgAAcwYAAHQG AAB1BgAAdgYAAHcGAAB4BgAAeQYAAHsGAAD9////fAYAAH0GAAB+BgAAfwYAAIAGAAAAAADzAxQA AAAmAAAABAAAAAAAAAACAACAAAAAAAAA8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMDFAAA ADEAAAAEAAAAAAAAAAQAAIAAAAAAAADzAxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ad5DAAA HwAUBBwAAAAAABUEFAAAANAYzQQAypo7TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEBAAAA /QM0AAAAQgAAAGQAAABCAAAAZAAAAAAAAAD8JYgW9JYTAHg6CzAAAAAAAAAAAO78//8K////AAAT AHAA+wMIAAAAAAAAADwCAABwAPsDCAAAAAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMUAAAA AgAABAwAAAAAAAAAAAAAAAIAAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAAg lxMA/PgKMFSpEwAAAAAAAAAAAAAAAAAAAAAAAAETAA8AiBNuCwAADwCKE2gAAAAAALoPFAAAAF8A XwBfAFAAUABUADIAMAAwADEAAACLE0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIA AAABAQABAQAAAQEBAAEAAAAAAAAAiNkAAAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABfAF8A XwBQAFAAVABNAGEAYwAxADEAAACLE9IIAABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAAAAAA AAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAA AAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAA YAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAm AE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcA AAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAA AAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAAB AgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAE AAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8A dAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAA AAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQBAAAA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIAABAA rw8IAAAAAAEAAAUAAAAAABkQKAIAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAA AQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAAB AAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAA AAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBw AGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQA AAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA ABoAAQ8AihNoAQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAAtw9E AAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWB4AABiIQALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAAFSpEwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHhgAGAjAAtw9E AAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWBwAABiIAAA0ECAAAAHC1AABwtQAADwCKE4YAAAAAALoPDgAAAF8AXwBfAFAAUABU ADkAAACLE2gAAAAvAMgPDAAAADAA0g8EAAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg///w8A rg80AAAAEACvDwgAAAAIAQAAAQAAAAAArA8cAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAA AD8A2Q8MAAAAAADaDwQAAAAAACMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPYQsAAAAA8wMUAAAA AwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBp biBTdXBwb3J0IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3Np Z25tZW50IGluIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoA AAAAAAAAAAB4AAAAAAACABwAAQAAAAAAAAABAAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQB AAAABgAAAAkEBAgzAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAA Q0NBTVAgV0csIElFVEYgNzh0aCwgTWFhc3RyaWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jh ei1jY2FtcC13c29uLWltcGFpcm1lbnQtb3NwZi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3Jh ekB0c2MudXBjLmVkdSkNWWFiaW4gWWUgKHlhYmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAA AAAAEAAAeAAvAAAAAAAGABIAAAAABS4AAAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgAS AAAAqg8+AAAAFQAAAAYAAAAJBAQIGAAAAAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQI QgAAAAcAAAAAAAwEBAgPAPIPGAAAAAAA8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAA AC0AAAAAAPMDFAAAAFMAAAAEAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tu b3dsZWRnbWVudHMAAKEPFAAAABAAAAAAAAAAAAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkE BAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AFYAAAAEAAAAAQAAABEBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQA AAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQA APMDFAAAAGgAAAAEAAAAAgAAAB8BAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABPYmplY3RpdmUg AAChDxwAAAALAAAAAAAAAAAACQAAAAAAAgAkAAIAAAAAAAAAAACqDxoAAAAKAAAABgAAAAkEBAgB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIA AAAEAAAAAgAAABkBAAAAAAAAAACfDwQAAAAAAAAAAACoDyUAAABPU1BGIHJvdXRpbmcgZm9yIElB LVJXQSAtTmV3IFBMSSBUTFYgAAChDyoAAAAmAAAAAAAAAAAAFwAAAAAAQwALAAsAJAANAAAAAAAC ACQAAgAAAAAAAAAAAKoPPgAAABcAAAAGAAAACQgECAUAAAAGAAAACQQECAgAAAAGAAAACQQJBAEA AAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJ BAAA8wMUAAAAVwAAAAQAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21w b3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAA AAAAAACqDyYAAAAfAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAA AQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAAAAAAAACf DwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAAoQ8cAAAA IQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAAAAYAAAAJ BAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8eAAAAU29tZSBzdWItVExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAAAAAAAAAA HwAAAAAAAgAkAAAAqg9QAAAACQAAAAYAAAAJBAQIAwAAAAcAAAADAAkECQQBAAAABwAAAAMACQQE CA0AAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABlAAAABAAAAAIAAAAcAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTGluayBQTEkgVExWAAChDxQAAAAlAAAA AAAAAAAAJQAAAAAAAgAkAAAAqg8aAAAAJAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABmAAAABAAAAAIAAAAdAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQTEkgVExWAACh DxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAAAAYAAAAJBAQI CAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAE CAkEAADzAxQAAABnAAAABAAAAAIAAAAeAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAAQW4gRXhh bXBsZSBvZiBjb21wb25lbnQgVExWAAChDxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAkAAAAqg8MAAAA HAAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAARAAA AAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMAAKEPFAAAAAsA AAAAAAAAAAALAAAAAAACACQAAACqDwwAAAALAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKgPqgAA AFJlZmluZSBpdCBhY2NvcmRpbmcgdG8gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcgb3Ig bWFpbGluZyBsaXN0DUtlZXAgdXBncmFkaW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0aGUgc3RhbmRh cmQgaW1wYWlybWVudCBpbmZvcm1hdGlvbg1Db21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lhdGVk AAChD0YAAACLAAAAAACyAAAAAwDYAAYAAAAAASAAAAAAALIgAAADANgABgAAAAABMgAbAAAAAABh AAsAAAALAJAAAAAABEEAAAQLAAsAAACqDxoAAACqAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A 8A84AAAAAADzAxQAAAAGAAAAAAAAAAAAAAAAAQAAAAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEA AAAAAAAAAOoDAAAAAAAAchcIAAAAAQAQAA3HBQAAAPUPHAAAAAABAACkGQAD6cYFAMv2BQABAAAA aAAAAAEAxTEPAOgDti8AAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABQAAAEUAAAAB AAAAAAAAAQ8A8gNqBAAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHkAMAAAAAtw9EAAAAQQByAGkA YQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAOSEiBbclhMAeDoLMNyWEwAAAAAADwDV BwAABiIQALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAVKkTAFSpEwDkhIgW 3JYTAHg6CzDclhMAAAAAAA8A1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw3JYTAAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMNyWEwAAAAAADwDV B4YABgJAALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAQiUAC3D0QAAABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAg AEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw3JYTAAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4A ZwBkAGkAbgBnAHMAAAB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMNyWEwAAAAAADwDV BwIABgJwALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAYigAC3D0QAAACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMNyWEwAAAAAADwDV BwAABBSgALcPRAAAAFQAaQBtAGUAcwAAAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAQksAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAAEIAbwBsAGQAAAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAA CAAAABQAAAClDxoAAAAAALOoLgADAPwABgAAAAABAQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQA AEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA AQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAAAPAAsEHhIAAA8AAPAWEgAAAAAG8CAIAAAECAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAA PwAAAAsAAAAIAAAADAAAAAQAAAAAAAAAEAAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAAT AAAAAAAAAAQAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQA AAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAA AAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAhAAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAgAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAA AAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAA AAYAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAA CgAAAAAAAAAEAAAAAAAAAAQAAAA/AAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABP AAAADAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAD AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAEAAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAA YwAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAGsAAAAEAAAAAAAAACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEA AAAIAAAAAAAAALUAAAAAAAAABgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAA AAUAAAAAAAAABAAAAAAAAAAhAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA 8gAAAAAAAADjAAAAAAAAAF0AAAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQA AAB8AAAABAAAAH0AAABBAAAAfgAAAHEBAAAAAAAABgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAA AIEAAADqAgAAgwAAAL0AAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAA nwAB8IwBAABiAAfwJAAAAAYGBYs1H73H+Fqm86dQG2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/Ak AAAABQXY8+MEAuku2OPtcJjJPSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry2 2uP8hz+TyGD/AAZXAAABAAAAIeEAAAAAAABiAAfwJAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMA AAEAAAAnOAEAAAAAAGIAB/AkAAAABgY86hloAaVPVtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAA YgAH8CQAAAAGBrjpaHIX9gtc+PzUZOyCabb/ALxWBQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1 c2pAoLp3dnMucUO2Ff8ASQIAAAEAAABf2AYAAAAAADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk /wCdAgAAAQAAAKjaBgAAAAAAMgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0G AAAAAAADCAvwAAMAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkA AAAAAL8AAgAPAAwB9AAAEA0BAAAAIA4BAAAAIIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAAB AIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4B AAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAA AJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABAQAACMEBAAABAMIB////AMMB AAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAI AM0BAAAAAM4BAAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQC AAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAA AA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQC AAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAA AMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80C QFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQA ANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQD fL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAw ZQEAfwEAAEAAngH/////nwH/////oAEAAAAgocEAAAAAogH/////owH/////pAEAAAAgpcEAAAAA pgH/////pwH/////vwEAACAA2QH/////2gH/////2wEAAAAg3MEAAAAA3QH/////3gH/////3wEA AAAg4MEAAAAA4QH/////4gH//////wEAAMAAEgL/////EwL/////FAIAAAAgFcIAAAAAFgL///// FwL/////GAIAAAAgGcIAAAAAGgL/////GwL/////iQL/////igL/////iwIAAAAgjMIAAAAAjQL/ ////jwMAAAAAkAMCAAAAkQMAAAAAkgMCAAAAvwMAggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAg RAUAAAAARUUAAAAARsUAAAAARwUAAAAASAUAAAAASQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUA AAAATgUAAAAAT8UAAAAAUAUAAAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAA WQX/////WgX/////WwUAAAAgXMUAAAAAXQX/////XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/ ////fwUGAE4AgAUAAAAAgQUAAAEAggX///8AgwUAAAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAA iAUAAAAAiQUAAAAAigUAAAAAiwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUA AAAAkgUBAAAAkwUBAAAAlAUBAAAAlQUBAAAAlwUCAAAAmQX/////mgX/////mwUAAAAgnMUAAAAA nQX/////ngX/////nwUAAAAgoMUAAAAAoQX/////ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX/ //8AwwUAAAAgxAUAAAAAxUUAAAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAA zAUAAAgAzQUAAAAAzgUAAAAAz8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUB AAAA1wUCAAAA2QX/////2gX/////2wUAAAAg3MUAAAAA3QX/////3gX/////3wUAAAAg4MUAAAAA 4QX/////4gX//////wUGAE4AAAYAAAAAAQYAAAEAAgb///8AAwYAAAAgBAYAAAAABUYAAAAABsYA AAAABwYAAAAACAYAAAAACQYAAAAACgYAAAAACwY1JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAA EAYAAAAAEQYAAAAAEgYBAAAAEwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAAGQb/////Ggb/////GwYA AAAgHMYAAAAAHQb/////Hgb/////HwYAAAAgIMYAAAAAIQb/////Igb/////PwYGAE4AQAYAAAAA QQYAAAEAQgb///8AQwYAAAAgRAYAAAAARUYAAAAARsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYA AAAASwY1JQAATAYAAAgATQYAAAAATgYAAAAAT8YAAAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAA VAYBAAAAVQYBAAAAVwYCAAAAWQb/////Wgb/////WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYA AAAgYMYAAAAAYQb/////Ygb/////fwYGAA4AgAAa8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA /wAAmcwAAGaZAEAAHvEQAAAABAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAA AAAAAAABAACAAAAAAAAA8wMUAAAAJgAAAAQAAAAAAAAAAgAAgAAAAAAAAPMDFAAAADMAAAAEAAAA AAAAAAYAAIAAAAAAAADzAxQAAAAxAAAABAAAAAAAAAAEAACAAAAAAAAA8wMUAAAAPAAAAAAAAAAA AAAABwAAgAAAAAAPANAHeQwAAB8AFAQcAAAAAAAVBBQAAADQGM0EAMqaO0613DYAypo7AQIAAA8A +gN3AAAAAAD+AwMAAAABAQAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAAAAAAA/CWIFvSWEwB4Ogsw AAAAAAAAAADu/P//Cv///wAAEwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMI AAAAAQAAAAkCAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQA AABkAAAAZAAAAGQAAAACAAAAIJcTAPz4CjBUqRMAAAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTbgsA AA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkX NAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAP AIoT+AgAAAAAug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABDwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEM AAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAA AAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5h bWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAA AAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAA AAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIoTaAEAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixNIAQAADwDWBzABAAAAALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1geAAAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAAFSpEwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHAAAGEiAAtw9E AAAAi1tTTwAAZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWB4YABgIwALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1gcAAAYiAAANBAgAAABwtQAAcLUAAA8AihOGAAAA AAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixNoAAAALwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAA AAMAAACoAwAAAwADAAIP//8PAK4PNAAAABAArw8IAAAACAEAAAEAAAAAAKwPHAAAAAAAAAIAAAAA AAAAAAAAAAAAAgAAAAAAAAAAAAA/ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8MAAAAAADaDwQAAAAN AD0ADwDwD2ELAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD3kA AABPU1BGIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcg YW5kIFdhdmVsZW5ndGggQXNzaWdubWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwg TmV0d29ya3MgAAChDyYAAAB6AAAAAAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAA qg8yAAAARQAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQ AJ8PBAAAAAUAAAAAAKgPnwAAAENDQU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0cmljaHQsIE5ldGhl cmxhbmRzIA0NZHJhZnQtYWdyYXotY2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9zcGYtMDAudHh0DQ1G ZXJuYW5kbyBBZ3JheiAoYWdyYXpAdHNjLnVwYy5lZHUpDVlhYmluIFllICh5YWJpbi55ZUBodWF3 ZWkuY29tKQAAoQ8+AAAAoAAAAAAAABAAAHgALwAAAAAABgASAAAAAAUuAAAAAAACABgAAQAAAAEA BgABABIAAAD//kIAAAAAAAIAEgAAAKoPPgAAABUAAAAGAAAACQQECBgAAAAGAAAACQQECDAAAAAG AAAACQQECAEAAAAGAAAACQgECEIAAAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAA AAAAAAhYCzAAAN8PCAAAABUAAAAtAAAAAADzAxQAAABTAAAABAAAAAIAAAAOAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8PAAAAQWNrbm93bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAk AAAAqg8aAAAADwAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEA AAAHAAAAAAAECAkEAADzAxQAAABWAAAABAAAAAEAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8K AAAAQmFja2dyb3VuZAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAA CQQECAEAAAAHAAAAAAAECAkEAADzAxQAAABoAAAABAAAAAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8KAAAAT2JqZWN0aXZlIAAAoQ8cAAAACwAAAAAAAAAAAAkAAAAAAAIAJAACAAAAAAAAAAAA qg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAH AAAAAAAECAkEAADzAxQAAABiAAAABAAAAAIAAAAZAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAA T1NQRiByb3V0aW5nIGZvciBJQS1SV0EgLU5ldyBQTEkgVExWIAAAoQ8qAAAAJgAAAAAAAAAAABcA AAAAAEMACwALACQADQAAAAAAAgAkAAIAAAAAAAAAAACqDz4AAAAXAAAABgAAAAkIBAgFAAAABgAA AAkEBAgIAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAA qg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFcAAAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAA AAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAA AAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8mAAAAHwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAA AAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAA BAAAAAIAAAAaAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5v ZGUgUExJIFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMA AAAGAAAACQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAE CAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAA GwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHgAAAFNvbWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExW cwAAoQ8UAAAAHwAAAAAAAAAAAB8AAAAAAAIAJAAAAKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAA AwAJBAkEAQAAAAcAAAADAAkEBAgNAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAE CAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAA HAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsg UExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEA AAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAA AAQAAAACAAAAHQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3Ig dGhlIE5vZGUgUExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAG AAAACQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPGwAAAEFuIEV4YW1wbGUgb2YgY29tcG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAA ABwAAAAAAAIAJAAAAKoPDAAAABwAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAEQAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABO ZXh0IFN0ZXBzAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQI EACfDwQAAAABAAAAAACoD6oAAABSZWZpbmUgaXQgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBm cm9tIHRoZSBtZWV0aW5nIG9yIG1haWxpbmcgbGlzdA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1U IGRlZmluZWQgdGhlIHN0YW5kYXJkIGltcGFpcm1lbnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJl IGFsd2F5cyBhcHByZWNpYXRlZAAAoQ9GAAAAiwAAAAAAsgAAAAMA2AAGAAAAAAEgAAAAAACyIAAA AwDYAAYAAAAAATIAGwAAAAAAYQALAAAACwCQAAAAAARBAAAECwALAAAAqg8aAAAAqgAAAAYAAAAJ BAQIAQAAAAcAAAAAAAQICQQvAPAPOAAAAAAA8wMUAAAABgAAAAAAAAAAAAAAAAEAAAAAAAAAAPMD FAAAAE0AAAAAAAAAAAAAAAgBAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEAD/9gUAAAD1DxwAAAAA AQAApBkAA9v2BQC9JgYAAQAAAGgAAAABAMUxDwDoA7YvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAW AAAFAAAACgAAAAUAAABFAAAAAQAAAAAAAAEPAPIDagQAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDV B5ADAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkTAFSpEwDkhIgW 3JYTAHg6CzDclhMAAAAAAA8A1QcAAAYiEAC3D0QAAABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBt AGEAbgAAAFSpEwBUqRMA5ISIFtyWEwB4Ogsw3JYTAAAAAAAPANUHgAAGIiAAtw9EAAAARgByAHUA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMNyWEwAAAAAADwDV BwAABCIwALcPRAAAANGeU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0A AAATAHg6CzDclhMAAAAAAA8A1QeGAAYCQAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAEIlAAtw9EAAAATlOHZcZ+ 0Z4AAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMNyWEwAAAAAADwDV B4YABgJgALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAeAB0ACAATABUACAAUgBlAGcAdQBsAGEA cgAAAHg6CzDclhMAAAAAAA8A1QcCAAYCcAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAGIoAAtw9EAAAAi1tTTwAA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMNyWEwAAAAAADwDV B4YABgKQALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAQUoAC3D0QAAABUAGkAbQBlAHMAAABlAHIATgBlAHgAdAAg AEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAEJLAAtw9EAAAAVABpAG0A ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABCAG8AbABkAAAAAAByAAAAeDoLMNyWEwAAAAAADwDV BwAABhIAAKQPDAAAAIAAYgAAAAgAAAAUAAAApQ8aAAAAAACzqC4AAwD8AAYAAAAAAQEAMgD5AQcA AAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAA AEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAA AAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBB4SAAAPAADwFhIAAAAABvAgCAAABAgEAAMBAABF AQAAFQAAAAAAAAAPAAAAAgAAAD8AAAALAAAACAAAAAwAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAA AAATAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAA AAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAA BAAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAACAAAACS AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAA AC0AAABDAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAA AAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAAAAAAAEIAAAAA AAAAGQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAAPwAAAAkAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAGAAAAAAAAAA0AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcA AAAAAAAABAAAAAAAAAAEAAAATwAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAA AAAAAABAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAwAAAAAA AAAEAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABZAAAA BwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAAAAAAD8 AAAAAAAAAC8AAABiAAAABAAAAGMAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAABrAAAABAAAAAAAAAAmAAAAAAAAACUAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAcAAABxAAAACAAAAAAAAAC1AAAAAAAAAAYAAAB0AAAA+wEAAHUAAABeAAAA AAAAAAgAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAPIAAAAAAAAA4wAAAAAAAABdAAAAAAAAAKwAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAACAAAAAAAAAAEAAAAfAAAAAQAAAB9AAAAQQAAAH4AAABxAQAAAAAAAAYAAAAAAAAA BgAAAIEAAAAABAAAAAAAAAYAAACBAAAA6gIAAIMAAAC9AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAE AAAAhwAAABoAAACIAAAABAAAAJ8AAfCMAQAAYgAH8CQAAAAGBgWLNR+9x/hapvOnUBtimEv/ANMq AAABAAAAAAAAAAAAAABSAAfwJAAAAAUF2PPjBALpLtjj7XCYyT0iFf8ATrYAAAEAAADTKgAAAAAA AFIAB/AkAAAABQVuXl4RjS68ttrj/Ic/k8hg/wAGVwAAAQAAACHhAAAAAAAAYgAH8CQAAAAGBisd nFFBlozbe/74GKTQUnn/AKszAAABAAAAJzgBAAAAAABiAAfwJAAAAAYGPOoZaAGlT1bU1/i7k1DQ Sf8A0RUAAAEAAADSawEAAAAAAGIAB/AkAAAABga46WhyF/YLXPj81GTsgmm2/wC8VgUAAQAAAKOB AQAAAAAAMgAH8CQAAAADBO7btXNqQKC6d3ZzLnFDthX/AEkCAAABAAAAX9gGAAAAAAAyAAfwJAAA AAMEQOvptYDGQz8Z0JsMOdBLJP8AnQIAAAEAAACo2gYAAAAAADIAB/AkAAAAAwSqrbsIEBgFJFUC qAz3dvkF/wBLAgAAAQAAAEXdBgAAAAAAAwgL8AADAACBAGA1AQCCALCaAACDAGA1AQCEALCaAACF AAIAAACHAAEAAACIAAAAAACJAAAAAAC/AAIADwAMAfQAABANAQAAACAOAQAAACCAAQAAAACBAQQA AAiCAQAAAQCDAQAAAAiEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACL AQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAA AACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDA AQEAAAjBAQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAA AADKAQAAAADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAAB AgIAAAgCAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAA AAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACB AgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAA AADBAgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADK AjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDD AADUAgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABB A6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAA AABzDSLxCgUAAIwAAQAAAI0AMGUBAH8BAABAAJ4B/////58B/////6ABAAAAIKHBAAAAAKIB//// /6MB/////6QBAAAAIKXBAAAAAKYB/////6cB/////78BAAAgANkB/////9oB/////9sBAAAAINzB AAAAAN0B/////94B/////98BAAAAIODBAAAAAOEB/////+IB//////8BAADAABIC/////xMC//// /xQCAAAAIBXCAAAAABYC/////xcC/////xgCAAAAIBnCAAAAABoC/////xsC/////4kC/////4oC /////4sCAAAAIIzCAAAAAI0C/////48DAAAAAJADAgAAAJEDAAAAAJIDAgAAAL8DAIIAgkAFAAAA AEEFAAABAEIF////AEMFAAAAIEQFAAAAAEVFAAAAAEbFAAAAAEcFAAAAAEgFAAAAAEkFAAAAAEoF AAAAAEsFNSUAAEwFAAAIAE0FAAAAAE4FAAAAAE/FAAAAAFAFAAAAAFEFAAAAAFIFAQAAAFMFAQAA AFQFAQAAAFUFAQAAAFcFAgAAAFkF/////1oF/////1sFAAAAIFzFAAAAAF0F/////14F/////18F AAAAIGDFAAAAAGEF/////2IF/////38FBgBOAIAFAAAAAIEFAAABAIIF////AIMFAAAAIIQFAAAA AIVFAAAAAIbFAAAAAIcFAAAAAIgFAAAAAIkFAAAAAIoFAAAAAIsFNSUAAIwFAAAIAI0FAAAAAI4F AAAAAI/FAAAAAJAFAAAAAJEFAAAAAJIFAQAAAJMFAQAAAJQFAQAAAJUFAQAAAJcFAgAAAJkF//// /5oF/////5sFAAAAIJzFAAAAAJ0F/////54F/////58FAAAAIKDFAAAAAKEF/////6IF/////78F BgBOAMAFAAAAAMEFAAABAMIF////AMMFAAAAIMQFAAAAAMVFAAAAAMbFAAAAAMcFAAAAAMgFAAAA AMkFAAAAAMoFAAAAAMsFNSUAAMwFAAAIAM0FAAAAAM4FAAAAAM/FAAAAANAFAAAAANEFAAAAANIF AQAAANMFAQAAANQFAQAAANUFAQAAANcFAgAAANkF/////9oF/////9sFAAAAINzFAAAAAN0F//// /94F/////98FAAAAIODFAAAAAOEF/////+IF//////8FBgBOAAAGAAAAAAEGAAABAAIG////AAMG AAAAIAQGAAAAAAVGAAAAAAbGAAAAAAcGAAAAAAgGAAAAAAkGAAAAAAoGAAAAAAsGNSUAAAwGAAAI AA0GAAAAAA4GAAAAAA/GAAAAABAGAAAAABEGAAAAABIGAQAAABMGAQAAABQGAQAAABUGAQAAABcG AgAAABkG/////xoG/////xsGAAAAIBzGAAAAAB0G/////x4G/////x8GAAAAICDGAAAAACEG//// /yIG/////z8GBgBOAEAGAAAAAEEGAAABAEIG////AEMGAAAAIEQGAAAAAEVGAAAAAEbGAAAAAEcG AAAAAEgGAAAAAEkGAAAAAEoGAAAAAEsGNSUAAEwGAAAIAE0GAAAAAE4GAAAAAE/GAAAAAFAGAAAA AFEGAAAAAFIGAQAAAFMGAQAAAFQGAQAAAFUGAQAAAFcGAgAAAFkG/////1oG/////1sGAAAAIFzG AAAAAF0G/////14G/////18GAAAAIGDGAAAAAGEG/////2IG/////38GBgAOAIAAGvEgAAAA/wAA AN3d3QDq6uoA//9mAP+ZAAAAAP8AAJnMAABmmQBAAB7xEAAAAAQAAAj/mQAAAAAAAPcAABAfAPAP jAAAAAAA8wMUAAAAHwAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAACYAAAAEAAAAAAAAAAIAAIAA AAAAAADzAxQAAAAzAAAABAAAAAAAAAAGAACAAAAAAAAA8wMUAAAAMQAAAAQAAAAAAAAABAAAgAAA AAAAAPMDFAAAADwAAAAAAAAAAAAAAAcAAIAAAAAADwDQB3kMAAAfABQEHAAAAAAAFQQUAAAA0BjN BADKmjtOtdw2AMqaOwECAAAPAPoDdwAAAAAA/gMDAAAAAQEAAAD9AzQAAABCAAAAZAAAAEIAAABk AAAAAAAAAPwliBb0lhMAeDoLMAAAAAAAAAAA7vz//wr///8AABMAcAD7AwgAAAAAAAAAPAIAAHAA +wMIAAAAAAAAABwOAABwAPsDCAAAAAEAAAAJAgAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAA AB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAAgAAACCXEwD8+AowVKkTAAAAAAAAAAAA AAAAAAAAAAAAARMADwCIE24LAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAA AIsTRAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAA AACI2QAAAAAAAAAAAACAAgHgDwCKE/gIAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAA AIsT0ggAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAA AAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAA AAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAA AAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAA VAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEA cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQA AABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAA ACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAAB BwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBAAgAAEACvDwgAAAAAAQAABQAAAAAAGRAo AgAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAA AAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAAB BAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBh AGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEA cABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwB AAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAAB AAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAA AAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgA AAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAA AQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwCKE2gBAAAAALoPEAAA AF8AXwBfAFAAUABUADEAMAAAAIsTSAEAAA8A1gcwAQAAAAC3D0QAAABNAFMAIABQAEcAbwB0AGgA aQBjAAAAbwBtAGEAbgAAAFSpEwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHgAAGIhAAtw9E AAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWBwAABhIgALcPRAAAAItbU08AAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1geGAAYCMAC3D0QAAABBAHIAaQBhAGwAAABOAGUA dwAgAFIAbwBtAGEAbgAAAFSpEwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHAAAGIgAADQQI AAAAcLUAAHC1AAAPAIoThgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTaAAAAC8AyA8MAAAA MADSDwQAAAAAAAAAAAB7FxAAAAADAAAAqAMAAAMAAwACD///DwCuDzQAAAAQAK8PCAAAAAgBAAAB AAAAAACsDxwAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAA IwBPANkPDAAAAAAA2g8EAAAADQA9AA8A8A9hCwAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAA AAAAnw8EAAAABgAAAAAAqA95AAAAT1NQRiBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW1wYWly bWVudCBBd2FyZSBSb3V0aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2lnbm1lbnQgaW4gV2F2ZWxlbmd0 aCBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmtzIAAAoQ8mAAAAegAAAAAAAAAAAHgAAAAAAAIAHAAB AAAAAAAAAAEAAAAAAAIAKAAAAKoPMgAAAEUAAAAGAAAACQQJBAEAAAAGAAAACQQECDMAAAAGAAAA CQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAAFAAAAAACoD58AAABDQ0FNUCBXRywgSUVURiA3OHRo LCBNYWFzdHJpY2h0LCBOZXRoZXJsYW5kcyANDWRyYWZ0LWFncmF6LWNjYW1wLXdzb24taW1wYWly bWVudC1vc3BmLTAwLnR4dA0NRmVybmFuZG8gQWdyYXogKGFncmF6QHRzYy51cGMuZWR1KQ1ZYWJp biBZZSAoeWFiaW4ueWVAaHVhd2VpLmNvbSkAAKEPPgAAAKAAAAAAAAAQAAB4AC8AAAAAAAYAEgAA AAAFLgAAAAAAAgAYAAEAAAABAAYAAQASAAAA//5CAAAAAAACABIAAACqDz4AAAAVAAAABgAAAAkE BAgYAAAABgAAAAkEBAgwAAAABgAAAAkEBAgBAAAABgAAAAkIBAhCAAAABwAAAAAADAQECA8A8g8Y AAAAAADzDxAAAAAAAAAAAAAAAAAAAAAIWAswAADfDwgAAAAVAAAALQAAAAAA8wMUAAAAUwAAAAQA AAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAEFja25vd2xlZGdtZW50cwAAoQ8UAAAA EAAAAAAAAAAAABAAAAAAAAIAJAAAAKoPGgAAAA8AAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACf DwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAVgAAAAQAAAABAAAAEQEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAAC ACQAAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAA8wMUAAAAaAAAAAQAAAACAAAA HwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE9iamVjdGl2ZSAAAKEPHAAAAAsAAAAAAAAAAAAJ AAAAAAACACQAAgAAAAAAAAAAAKoPGgAAAAoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQA AAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAYgAAAAQAAAACAAAAGQEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPJQAAAE9TUEYgcm91dGluZyBmb3IgSUEtUldBIC1OZXcgUExJIFRMViAA AKEPKgAAACYAAAAAAAAAAAAXAAAAAABDAAsACwAkAA0AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAA FwAAAAYAAAAJCAQIBQAAAAYAAAAJBAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAA AAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABXAAAABAAAAAIA AAASAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIExpbmsgUExJ IFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPJgAAAB8AAAAGAAAA CQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAA AAAABAgJBAAA8wMUAAAAYwAAAAQAAAACAAAAGgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRo ZSBjb21wb3NpdGlvbiBvZiBOb2RlIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAk AAIAAAAAAAAAAACqDz4AAAATAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAA BgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQA APMDFAAAAGQAAAAEAAAAAgAAABsBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABTb21lIHN1Yi1U TFZzIGFuZCBzdWItc3ViLVRMVnMAAKEPFAAAAB8AAAAAAAAAAAAfAAAAAAACACQAAACqD1AAAAAJ AAAABgAAAAkEBAgDAAAABwAAAAMACQQJBAEAAAAHAAAAAwAJBAQIDQAAAAYAAAAJBAQIBAAAAAcA AAADAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQA APMDFAAAAGUAAAAEAAAAAgAAABwBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQYXJhbWV0ZXIg VHlwZXMgZm9yIHRoZSBMaW5rIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAAAAACACQAAACq DxoAAAAkAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAGYAAAAEAAAAAgAAAB0BAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABQ YXJhbWV0ZXIgVHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAAKEPFAAAACUAAAAAAAAAAAAlAAAA AAACACQAAACqDzIAAAAYAAAABgAAAAkECQQEAAAABgAAAAkEBAgIAAAABgAAAAkECQQBAAAABwAA AAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGcAAAAEAAAA AgAAAB4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBU TFYAAKEPFAAAABwAAAAAAAAAAAAcAAAAAAACACQAAACqDwwAAAAcAAAABgAAAAkEBAgQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABEAAAAAAAAAAIAAAAIAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8KAAAATmV4dCBTdGVwcwAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAA AKoPDAAAAAsAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqA+qAAAAUmVmaW5lIGl0IGFjY29yZGlu ZyB0byB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgbWVldGluZyBvciBtYWlsaW5nIGxpc3QNS2VlcCB1 cGdyYWRpbmcgd2hlbiBJVFUtVCBkZWZpbmVkIHRoZSBzdGFuZGFyZCBpbXBhaXJtZW50IGluZm9y bWF0aW9uDUNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQAAKEPRgAAAIsAAAAAALIAAAAD ANgABgAAAAABIAAAAAAAsiAAAAMA2AAGAAAAAAEyABsAAAAAAGEACwAAAAsAkAAAAAAEQQAABAsA CwAAAKoPGgAAAKoAAAAGAAAACQQECAEAAAAHAAAAAAAECAkELwDwDzgAAAAAAPMDFAAAAAYAAAAA AAAAAAAAAAABAAAAAAAAAADzAxQAAABNAAAAAAAAAAAAAAAIAQAAAAAAAAAA6gMAAAAAAAByFwgA AAABABAA8SYGAAAA9Q8cAAAAAAEAAKQZAAPNJgYAr1YGAAEAAABoAAAAAQDFMQ8A6AO2LwAAAQDp AygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAFAAAARQAAAAEAAAAAAAABDwDyA2oEAAAvAMgP DAAAADAA0g8EAAAAAAAAAA8A1QeQAwAAAAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBt AGEAbgAAAFSpEwBUqRMA5ISIFtyWEwB4Ogsw3JYTAAAAAAAPANUHAAAGIhAAtw9EAAAATQBTACAA UABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABUqRMAVKkTAOSEiBbclhMAeDoLMNyWEwAAAAAADwDV B4AABiIgALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATQBlAGQAaQB1AG0A AAATAHg6CzDclhMAAAAAAA8A1QcAAAQiMAC3D0QAAADRnlNPAAB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw3JYTAAAAAAAPANUHhgAGAkAAtw9EAAAARgByAHUA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMNyWEwAAAAAADwDV BwAABCJQALcPRAAAAE5Th2XGftGeAABnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEA cgAAAHg6CzDclhMAAAAAAA8A1QeGAAYCYAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAHgAdAAg AEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw3JYTAAAAAAAPANUHAgAGAnAAtw9EAAAARgByAHUA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABMAGkAZwBoAHQAAAByAAAAeDoLMNyWEwAAAAAADwDV BwAABiKAALcPRAAAAItbU08AAHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAA cgAAAHg6CzDclhMAAAAAAA8A1QeGAAYCkAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAEIAbwBsAGQAAAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAEFKAAtw9EAAAAVABpAG0A ZQBzAAAAZQByAE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMNyWEwAAAAAADwDV BwAABCSwALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAQgBvAGwAZAAAAAAA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAYSAACkDwwAAACAAGIAAAAIAAAAFAAAAKUPGgAAAAAAs6gu AAMA/AAGAAAAAAEBADIA+QEHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIg AABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAAAFAAAg ASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQeEgAADwAA8BYS AAAAAAbwIAgAAAQIBAADAQAARQEAABUAAAAAAAAADwAAAAIAAAA/AAAACwAAAAgAAAAMAAAABAAA AAAAAAAQAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAANAAAA AAAAAAQAAAAAAAAACgAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAUAAAAAAAAABQAAAAAA AAAEAAAAAAAAACEAAAAgAAAAkgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAFAAAAAAAA AAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAcAAAAAAAAA BwAAAAAAAAAHAAAAAAAAAAYAAAAtAAAAQwAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAG AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAAAAcA AAAAAAAABgAAAAAAAABCAAAAAAAAABkAAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABAAA AD8AAAAJAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAANAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAE8AAAAMAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAkAAAAAAAAAQAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAMAAAAAAAAABAAAAAAAAAADAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAWQAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAALAAAAAAAAAAQAAAAAAAAA/AAAAAAAAAAvAAAAYgAAAAQAAABjAAAABgAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAawAAAAQAAAAAAAAA JgAAAAAAAAAlAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAcQAAAAgAAAAAAAAAtQAAAAAAAAAG AAAAdAAAAPsBAAB1AAAAXgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACEA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAADyAAAAAAAAAOMAAAAAAAAAXQAA AAAAAACsAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAHwAAAAEAAAAfQAAAEEAAAB+ AAAAcQEAAAAAAAAGAAAAAAAAAAYAAACBAAAAAAQAAAAAAAAGAAAAgQAAAOoCAACDAAAAvQAAAAAA AAAGAAAAAAAAAAYAAAAAAAAABAAAAIcAAAAaAAAAiAAAAAQAAACfAAHwjAEAAGIAB/AkAAAABgYF izUfvcf4Wqbzp1AbYphL/wDTKgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBdjz4wQC6S7Y4+1wmMk9 IhX/AE62AAABAAAA0yoAAAAAAABSAAfwJAAAAAUFbl5eEY0uvLba4/yHP5PIYP8ABlcAAAEAAAAh 4QAAAAAAAGIAB/AkAAAABgYrHZxRQZaM23v++Bik0FJ5/wCrMwAAAQAAACc4AQAAAAAAYgAH8CQA AAAGBjzqGWgBpU9W1Nf4u5NQ0En/ANEVAAABAAAA0msBAAAAAABiAAfwJAAAAAYGuOlochf2C1z4 /NRk7IJptv8AvFYFAAEAAACjgQEAAAAAADIAB/AkAAAAAwTu27VzakCgund2cy5xQ7YV/wBJAgAA AQAAAF/YBgAAAAAAMgAH8CQAAAADBEDr6bWAxkM/GdCbDDnQSyT/AJ0CAAABAAAAqNoGAAAAAAAy AAfwJAAAAAMEqq27CBAYBSRVAqgM93b5Bf8ASwIAAAEAAABF3QYAAAAAAAMIC/AAAwAAgQBgNQEA ggCwmgAAgwBgNQEAhACwmgAAhQACAAAAhwABAAAAiAAAAAAAiQAAAAAAvwACAA8ADAH0AAAQDQEA AAAgDgEAAAAggAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghkEAAAAAh8EAAAAA iAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEA AAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAA mwEAAAAAnAEDAABAvwEMAB4AwAEBAAAIwQEAAAEAwgH///8AwwEAAAAgxAEAAAAAxUEAAAAAxsEA AAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEAAAAAz8EAAAAA 1wECAAAA/wEOAA4AAAIAAAAAAQICAAAIAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIA AAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAA EQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3 AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAA xwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIA AHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA 2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8 vgEAhQMAAAAAhgN8vgEAhwMAAAAAcw0i8QoFAACMAAEAAACNADBlAQB/AQAAQACeAf////+fAf// //+gAQAAACChwQAAAACiAf////+jAf////+kAQAAACClwQAAAACmAf////+nAf////+/AQAAIADZ Af/////aAf/////bAQAAACDcwQAAAADdAf/////eAf/////fAQAAACDgwQAAAADhAf/////iAf// ////AQAAwAASAv////8TAv////8UAgAAACAVwgAAAAAWAv////8XAv////8YAgAAACAZwgAAAAAa Av////8bAv////+JAv////+KAv////+LAgAAACCMwgAAAACNAv////+PAwAAAACQAwIAAACRAwAA AACSAwIAAAC/AwCCAIJABQAAAABBBQAAAQBCBf///wBDBQAAACBEBQAAAABFRQAAAABGxQAAAABH BQAAAABIBQAAAABJBQAAAABKBQAAAABLBTUlAABMBQAACABNBQAAAABOBQAAAABPxQAAAABQBQAA AABRBQAAAABSBQEAAABTBQEAAABUBQEAAABVBQEAAABXBQIAAABZBf////9aBf////9bBQAAACBc xQAAAABdBf////9eBf////9fBQAAACBgxQAAAABhBf////9iBf////9/BQYATgCABQAAAACBBQAA AQCCBf///wCDBQAAACCEBQAAAACFRQAAAACGxQAAAACHBQAAAACIBQAAAACJBQAAAACKBQAAAACL BTUlAACMBQAACACNBQAAAACOBQAAAACPxQAAAACQBQAAAACRBQAAAACSBQEAAACTBQEAAACUBQEA AACVBQEAAACXBQIAAACZBf////+aBf////+bBQAAACCcxQAAAACdBf////+eBf////+fBQAAACCg xQAAAAChBf////+iBf////+/BQYATgDABQAAAADBBQAAAQDCBf///wDDBQAAACDEBQAAAADFRQAA AADGxQAAAADHBQAAAADIBQAAAADJBQAAAADKBQAAAADLBTUlAADMBQAACADNBQAAAADOBQAAAADP xQAAAADQBQAAAADRBQAAAADSBQEAAADTBQEAAADUBQEAAADVBQEAAADXBQIAAADZBf/////aBf// ///bBQAAACDcxQAAAADdBf/////eBf/////fBQAAACDgxQAAAADhBf/////iBf//////BQYATgAA BgAAAAABBgAAAQACBv///wADBgAAACAEBgAAAAAFRgAAAAAGxgAAAAAHBgAAAAAIBgAAAAAJBgAA AAAKBgAAAAALBjUlAAAMBgAACAANBgAAAAAOBgAAAAAPxgAAAAAQBgAAAAARBgAAAAASBgEAAAAT BgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZBv////8aBv////8bBgAAACAcxgAAAAAdBv////8eBv// //8fBgAAACAgxgAAAAAhBv////8iBv////8/BgYATgBABgAAAABBBgAAAQBCBv///wBDBgAAACBE BgAAAABFRgAAAABGxgAAAABHBgAAAABIBgAAAABJBgAAAABKBgAAAABLBjUlAABMBgAACABNBgAA AABOBgAAAABPxgAAAABQBgAAAABRBgAAAABSBgEAAABTBgEAAABUBgEAAABVBgEAAABXBgIAAABZ Bv////9aBv////9bBgAAACBcxgAAAABdBv////9eBv////9fBgAAACBgxgAAAABhBv////9iBv// //9/BgYADgCAABrxIAAAAP8AAADd3d0A6urqAP//ZgD/mQAAAAD/AACZzAAAZpkAQAAe8RAAAAAE AAAI/5kAAAAAAAD3AAAQHwDwD4wAAAAAAPMDFAAAAB8AAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQA AAAmAAAABAAAAAAAAAACAACAAAAAAAAA8wMUAAAAMwAAAAQAAAAAAAAABgAAgAAAAAAAAPMDFAAA ADEAAAAEAAAAAAAAAAQAAIAAAAAAAADzAxQAAAA8AAAAAAAAAAAAAAAHAACAAAAAAA8A0Ad5DAAA HwAUBBwAAAAAABUEFAAAANAYzQQAypo7TrXcNgDKmjsBAgAADwD6A3cAAAAAAP4DAwAAAAEBAAAA /QM0AAAAQgAAAGQAAABCAAAAZAAAAAAAAAD8JYgW9JYTAHg6CzAAAAAAAAAAAO78//8K////AAAT AHAA+wMIAAAAAAAAADwCAABwAPsDCAAAAAAAAAAcDgAAcAD7AwgAAAABAAAACQIAAB8A/wMUAAAA AgAABAwAAAAAAAAAAAAAAAIAAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAAg lxMA/PgKMFSpEwAAAAAAAAAAAAAAAAAAAAAAAAETAA8AiBNuCwAADwCKE2gAAAAAALoPFAAAAF8A XwBfAFAAUABUADIAMAAwADEAAACLE0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIA AAABAQABAQAAAQEBAAEAAAAAAAAAiNkAAAAAAAAAAAAAgAIB4A8AihP4CAAAAAC6DxYAAABfAF8A XwBQAFAAVABNAGEAYwAxADEAAACLE9IIAABAABoQZgUAAAUAAAAACAwBAAAAAAACAAABDAAAAAAA AAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAA AAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAA YAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAm AE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcA AAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAA AAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAAB AgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAE AAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8A dAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAA AAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB AAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwA AAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABo AHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAcEBQBAAAA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPABsQQAIAABAA rw8IAAAAAAEAAAUAAAAAABkQKAIAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAA AQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAAB AAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAA AAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBw AGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQA AAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA ABoAAQ8AihNoAQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE0gBAAAPANYHMAEAAAAAtw9E AAAATQBTACAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWB4AABiIQALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1gcAAAYSIAC3D0QAAACLW1NPAABlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAAFSpEwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHhgAGAjAAtw9E AAAAQQByAGkAYQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWBwAABiIAAA0ECAAAAHC1AABwtQAADwCKE4YAAAAAALoPDgAAAF8AXwBfAFAAUABU ADkAAACLE2gAAAAvAMgPDAAAADAA0g8EAAAAAAAAAAAAexcQAAAAAwAAAKgDAAADAAMAAg///w8A rg80AAAAEACvDwgAAAAIAQAAAQAAAAAArA8cAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAA AD8A2Q8MAAAAAADaDwQAAAAAACMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPYQsAAAAA8wMUAAAA AwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPeQAAAE9TUEYgRXh0ZW5zaW9ucyBp biBTdXBwb3J0IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3Np Z25tZW50IGluIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAAAKEPJgAAAHoA AAAAAAAAAAB4AAAAAAACABwAAQAAAAAAAAABAAAAAAACACgAAACqDzIAAABFAAAABgAAAAkECQQB AAAABgAAAAkEBAgzAAAABgAAAAkECQQBAAAABwAAAAAABAgJBBAAnw8EAAAABQAAAAAAqA+fAAAA Q0NBTVAgV0csIElFVEYgNzh0aCwgTWFhc3RyaWNodCwgTmV0aGVybGFuZHMgDQ1kcmFmdC1hZ3Jh ei1jY2FtcC13c29uLWltcGFpcm1lbnQtb3NwZi0wMC50eHQNDUZlcm5hbmRvIEFncmF6IChhZ3Jh ekB0c2MudXBjLmVkdSkNWWFiaW4gWWUgKHlhYmluLnllQGh1YXdlaS5jb20pAAChDz4AAACgAAAA AAAAEAAAeAAvAAAAAAAGABIAAAAABS4AAAAAAAIAGAABAAAAAQAGAAEAEgAAAP/+QgAAAAAAAgAS AAAAqg8+AAAAFQAAAAYAAAAJBAQIGAAAAAYAAAAJBAQIMAAAAAYAAAAJBAQIAQAAAAYAAAAJCAQI QgAAAAcAAAAAAAwEBAgPAPIPGAAAAAAA8w8QAAAAAAAAAAAAAAAAAAAACFgLMAAA3w8IAAAAFQAA AC0AAAAAAPMDFAAAAFMAAAAEAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABBY2tu b3dsZWRnbWVudHMAAKEPFAAAABAAAAAAAAAAAAAQAAAAAAACACQAAACqDxoAAAAPAAAABgAAAAkE BAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAA AFYAAAAEAAAAAQAAABEBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABCYWNrZ3JvdW5kAAChDxQA AAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQA APMDFAAAAGgAAAAEAAAAAgAAAB8BAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABPYmplY3RpdmUg AAChDxwAAAALAAAAAAAAAAAACQAAAAAAAgAkAAIAAAAAAAAAAACqDxoAAAAKAAAABgAAAAkEBAgB AAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGIA AAAEAAAAAgAAABkBAAAAAAAAAACfDwQAAAAAAAAAAACoDyUAAABPU1BGIHJvdXRpbmcgZm9yIElB LVJXQSAtTmV3IFBMSSBUTFYgAAChDyoAAAAmAAAAAAAAAAAAFwAAAAAAQwALAAsAJAANAAAAAAAC ACQAAgAAAAAAAAAAAKoPPgAAABcAAAAGAAAACQgECAUAAAAGAAAACQQECAgAAAAGAAAACQQJBAEA AAAGAAAACQQECAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJ BAAA8wMUAAAAVwAAAAQAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAFRoZSBjb21w b3NpdGlvbiBvZiBMaW5rIFBMSSBUTFYgAAChDxwAAAAhAAAAAAAAAAAAHwAAAAAAAgAkAAIAAAAA AAAAAACqDyYAAAAfAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAA AQAAAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAGMAAAAEAAAAAgAAABoBAAAAAAAAAACf DwQAAAAAAAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTm9kZSBQTEkgVExWIAAAoQ8cAAAA IQAAAAAAAAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8+AAAAEwAAAAYAAAAJBAkEBAAAAAYAAAAJ BAQICAAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABkAAAABAAAAAIAAAAbAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8eAAAAU29tZSBzdWItVExWcyBhbmQgc3ViLXN1Yi1UTFZzAAChDxQAAAAfAAAAAAAAAAAA HwAAAAAAAgAkAAAAqg9QAAAACQAAAAYAAAAJBAQIAwAAAAcAAAADAAkECQQBAAAABwAAAAMACQQE CA0AAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoP DgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABlAAAABAAAAAIAAAAcAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTGluayBQTEkgVExWAAChDxQAAAAlAAAA AAAAAAAAJQAAAAAAAgAkAAAAqg8aAAAAJAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAA AAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABmAAAABAAAAAIAAAAdAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8kAAAAUGFyYW1ldGVyIFR5cGVzIGZvciB0aGUgTm9kZSBQTEkgVExWAACh DxQAAAAlAAAAAAAAAAAAJQAAAAAAAgAkAAAAqg8yAAAAGAAAAAYAAAAJBAkEBAAAAAYAAAAJBAQI CAAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAE CAkEAADzAxQAAABnAAAABAAAAAIAAAAeAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAAQW4gRXhh bXBsZSBvZiBjb21wb25lbnQgVExWAAChDxQAAAAcAAAAAAAAAAAAHAAAAAAAAgAkAAAAqg8MAAAA HAAAAAYAAAAJBAQIEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAARAAA AAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMAAKEPFAAAAAsA AAAAAAAAAAALAAAAAAACACQAAACqDwwAAAALAAAABgAAAAkEBAgQAJ8PBAAAAAEAAAAAAKgPqgAA AFJlZmluZSBpdCBhY2NvcmRpbmcgdG8gdGhlIGZlZWRiYWNrIGZyb20gdGhlIG1lZXRpbmcgb3Ig bWFpbGluZyBsaXN0DUtlZXAgdXBncmFkaW5nIHdoZW4gSVRVLVQgZGVmaW5lZCB0aGUgc3RhbmRh cmQgaW1wYWlybWVudCBpbmZvcm1hdGlvbg1Db21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lhdGVk AAChD0YAAACLAAAAAACyAAAAAwDYAAYAAAAAASAAAAAAALIgAAADANgABgAAAAABMgAbAAAAAABh AAsAAAALAJAAAAAABEEAAAQLAAsAAACqDxoAAACqAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBC8A 8A84AAAAAADzAxQAAAAGAAAAAAAAAAAAAAAAAQAAAAAAAAAA8wMUAAAATQAAAAAAAAAAAAAACAEA AAAAAAAAAOoDAAAAAAAAchcIAAAAAQAQAONWBgAAAPUPHAAAAAABAACkGQADv1YGAKGGBgABAAAA aAAAAAEAxTEPAOgDti8AAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABQAAAEUAAAAB AAAAAAAAAQ8A8gNqBAAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHkAMAAAAAtw9EAAAAQQByAGkA YQBsAAAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAOSEiBbclhMAeDoLMNyWEwAAAAAADwDV BwAABiIQALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAVKkTAFSpEwDkhIgW 3JYTAHg6CzDclhMAAAAAAA8A1QeAAAYiIAC3D0QAAABGAHIAdQB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAE0AZQBkAGkAdQBtAAAAEwB4Ogsw3JYTAAAAAAAPANUHAAAEIjAAtw9EAAAA0Z5TTwAA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABNAGUAZABpAHUAbQAAABMAeDoLMNyWEwAAAAAADwDV B4YABgJAALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAAUgBlAGcAdQBsAGEA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAQiUAC3D0QAAABOU4dlxn7RngAAZwBlAHIATgBlAHgAdAAg AEwAVAAgAFIAZQBnAHUAbABhAHIAAAB4Ogsw3JYTAAAAAAAPANUHhgAGAmAAtw9EAAAAVwBpAG4A ZwBkAGkAbgBnAHMAAAB4AHQAIABMAFQAIABSAGUAZwB1AGwAYQByAAAAeDoLMNyWEwAAAAAADwDV BwIABgJwALcPRAAAAEYAcgB1AHQAaQBnAGUAcgBOAGUAeAB0ACAATABUACAATABpAGcAaAB0AAAA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAYigAC3D0QAAACLW1NPAAB0AGkAZwBlAHIATgBlAHgAdAAg AEwAVAAgAEwAaQBnAGgAdAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHhgAGApAAtw9EAAAARgByAHUA dABpAGcAZQByAE4AZQB4AHQAIABMAFQAIABCAG8AbABkAAAAAAByAAAAeDoLMNyWEwAAAAAADwDV BwAABBSgALcPRAAAAFQAaQBtAGUAcwAAAGUAcgBOAGUAeAB0ACAATABUACAAQgBvAGwAZAAAAAAA cgAAAHg6CzDclhMAAAAAAA8A1QcAAAQksAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAAEIAbwBsAGQAAAAAAHIAAAB4Ogsw3JYTAAAAAAAPANUHAAAGEgAApA8MAAAAgABiAAAA CAAAABQAAAClDxoAAAAAALOoLgADAPwABgAAAAABAQAyAPkBBwAAAAAAqQ8KAAAABwAAAAIACQQA AEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA AQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAAAPAAsEHhIAAA8AAPAWEgAAAAAG8CAIAAAECAQAAwEAAEUBAAAVAAAAAAAAAA8AAAACAAAA PwAAAAsAAAAIAAAADAAAAAQAAAAAAAAAEAAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAAT AAAAAAAAAAQAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQA AAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAA AAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAhAAAAIAAAAJIAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAgAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAGAAAALQAAAEMAAAAAAAAABAAAAAAA AAAGAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAA AAYAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAZAAAAAAAAAAQAAAAAAAAA CgAAAAAAAAAEAAAAAAAAAAQAAAA/AAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAADQAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAABP AAAADAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAJAAAAAAAAAEAAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAD AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAFkAAAAHAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAACwAAAAAAAAAEAAAAAAAAAPwAAAAAAAAALwAAAGIAAAAEAAAA YwAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAGsAAAAEAAAAAAAAACYAAAAAAAAAJQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAHEA AAAIAAAAAAAAALUAAAAAAAAABgAAAHQAAAD7AQAAdQAAAF4AAAAAAAAACAAAAAAAAAAEAAAAAAAA AAUAAAAAAAAABAAAAAAAAAAhAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA 8gAAAAAAAADjAAAAAAAAAF0AAAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAQA AAB8AAAABAAAAH0AAABBAAAAfgAAAHEBAAAAAAAABgAAAAAAAAAGAAAAgQAAAAAEAAAAAAAABgAA AIEAAADqAgAAgwAAAL0AAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAACHAAAAGgAAAIgAAAAEAAAA nwAB8IwBAABiAAfwJAAAAAYGBYs1H73H+Fqm86dQG2KYS/8A0yoAAAEAAAAAAAAAAAAAAFIAB/Ak AAAABQXY8+MEAuku2OPtcJjJPSIV/wBOtgAAAQAAANMqAAAAAAAAUgAH8CQAAAAFBW5eXhGNLry2 2uP8hz+TyGD/AAZXAAABAAAAIeEAAAAAAABiAAfwJAAAAAYGKx2cUUGWjNt7/vgYpNBSef8AqzMA AAEAAAAnOAEAAAAAAGIAB/AkAAAABgY86hloAaVPVtTX+LuTUNBJ/wDRFQAAAQAAANJrAQAAAAAA YgAH8CQAAAAGBrjpaHIX9gtc+PzUZOyCabb/ALxWBQABAAAAo4EBAAAAAAAyAAfwJAAAAAME7tu1 c2pAoLp3dnMucUO2Ff8ASQIAAAEAAABf2AYAAAAAADIAB/AkAAAAAwRA6+m1gMZDPxnQmww50Esk /wCdAgAAAQAAAKjaBgAAAAAAMgAH8CQAAAADBKqtuwgQGAUkVQKoDPd2+QX/AEsCAAABAAAARd0G AAAAAAADCAvwAAMAAIEAYDUBAIIAsJoAAIMAYDUBAIQAsJoAAIUAAgAAAIcAAQAAAIgAAAAAAIkA AAAAAL8AAgAPAAwB9AAAEA0BAAAAIA4BAAAAIIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAAB AIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4B AAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAA AJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABAQAACMEBAAABAMIB////AMMB AAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAI AM0BAAAAAM4BAAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQC AAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAA AA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQC AAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAA AMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80C QFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQA ANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQD fL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAHMNIvEKBQAAjAABAAAAjQAw ZQEAfwEAAEAAngH/////nwH/////oAEAAAAgocEAAAAAogH/////owH/////pAEAAAAgpcEAAAAA pgH/////pwH/////vwEAACAA2QH/////2gH/////2wEAAAAg3MEAAAAA3QH/////3gH/////3wEA AAAg4MEAAAAA4QH/////4gH//////wEAAMAAEgL/////EwL/////FAIAAAAgFcIAAAAAFgL///// FwL/////GAIAAAAgGcIAAAAAGgL/////GwL/////iQL/////igL/////iwIAAAAgjMIAAAAAjQL/ ////jwMAAAAAkAMCAAAAkQMAAAAAkgMCAAAAvwMAggCCQAUAAAAAQQUAAAEAQgX///8AQwUAAAAg RAUAAAAARUUAAAAARsUAAAAARwUAAAAASAUAAAAASQUAAAAASgUAAAAASwU1JQAATAUAAAgATQUA AAAATgUAAAAAT8UAAAAAUAUAAAAAUQUAAAAAUgUBAAAAUwUBAAAAVAUBAAAAVQUBAAAAVwUCAAAA WQX/////WgX/////WwUAAAAgXMUAAAAAXQX/////XgX/////XwUAAAAgYMUAAAAAYQX/////YgX/ ////fwUGAE4AgAUAAAAAgQUAAAEAggX///8AgwUAAAAghAUAAAAAhUUAAAAAhsUAAAAAhwUAAAAA iAUAAAAAiQUAAAAAigUAAAAAiwU1JQAAjAUAAAgAjQUAAAAAjgUAAAAAj8UAAAAAkAUAAAAAkQUA AAAAkgUBAAAAkwUBAAAAlAUBAAAAlQUBAAAAlwUCAAAAmQX/////mgX/////mwUAAAAgnMUAAAAA nQX/////ngX/////nwUAAAAgoMUAAAAAoQX/////ogX/////vwUGAE4AwAUAAAAAwQUAAAEAwgX/ //8AwwUAAAAgxAUAAAAAxUUAAAAAxsUAAAAAxwUAAAAAyAUAAAAAyQUAAAAAygUAAAAAywU1JQAA zAUAAAgAzQUAAAAAzgUAAAAAz8UAAAAA0AUAAAAA0QUAAAAA0gUBAAAA0wUBAAAA1AUBAAAA1QUB AAAA1wUCAAAA2QX/////2gX/////2wUAAAAg3MUAAAAA3QX/////3gX/////3wUAAAAg4MUAAAAA 4QX/////4gX//////wUGAE4AAAYAAAAAAQYAAAEAAgb///8AAwYAAAAgBAYAAAAABUYAAAAABsYA AAAABwYAAAAACAYAAAAACQYAAAAACgYAAAAACwY1JQAADAYAAAgADQYAAAAADgYAAAAAD8YAAAAA EAYAAAAAEQYAAAAAEgYBAAAAEwYBAAAAFAYBAAAAFQYBAAAAFwYCAAAAGQb/////Ggb/////GwYA AAAgHMYAAAAAHQb/////Hgb/////HwYAAAAgIMYAAAAAIQb/////Igb/////PwYGAE4AQAYAAAAA QQYAAAEAQgb///8AQwYAAAAgRAYAAAAARUYAAAAARsYAAAAARwYAAAAASAYAAAAASQYAAAAASgYA AAAASwY1JQAATAYAAAgATQYAAAAATgYAAAAAT8YAAAAAUAYAAAAAUQYAAAAAUgYBAAAAUwYBAAAA VAYBAAAAVQYBAAAAVwYCAAAAWQb/////Wgb/////WwYAAAAgXMYAAAAAXQb/////Xgb/////XwYA AAAgYMYAAAAAYQb/////Ygb/////fwYGAA4AgAAa8SAAAAD/AAAA3d3dAOrq6gD//2YA/5kAAAAA /wAAmcwAAGaZAEAAHvEQAAAABAAACP+ZAAAAAAAA9wAAEB8A8A+MAAAAAADzAxQAAAAfAAAABAAA AAAAAAABAACAAAAAAAAA8wMUAAAAJgAAAAQAAAAAAAAAAgAAgAAAAAAAAPMDFAAAADMAAAAEAAAA AAAAAAYAAIAAAAAAAADzAxQAAAAxAAAABAAAAAAAAAAEAACAAAAAAAAA8wMUAAAAPAAAAAAAAAAA AAAABwAAgAAAAAAPANAHeQwAAB8AFAQcAAAAAAAVBBQAAADQGM0EAMqaO0613DYAypo7AQIAAA8A +gN3AAAAAAD+AwMAAAABAQAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAAAAAAA/CWIFvSWEwB4Ogsw AAAAAAAAAADu/P//Cv///wAAEwBwAPsDCAAAAAAAAAA8AgAAcAD7AwgAAAAAAAAAHA4AAHAA+wMI AAAAAQAAAAkCAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwATBDwAAAAAAP0DNAAAAGQA AABkAAAAZAAAAGQAAAACAAAAIJcTAPz4CjBUqRMAAAAAAAAAAAAAAAAAAAAAAAABEwAPAIgTbgsA AA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkX NAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAP AIoT+AgAAAAAug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABDwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEM AAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAA AAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5h bWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAA AAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAA AAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIoTaAEAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixNIAQAADwDWBzABAAAAALcPRAAAAE0AUwAgAFAARwBvAHQAaABpAGMAAABvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1geAAAYiEAC3D0QAAABUAGkAbQBlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAAFSpEwBUqRMAHJcTANSVEwB4Ogsw1JUTAAAAAAAPANYHAAAGEiAAtw9E AAAAi1tTTwAAZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAByXEwDUlRMAeDoLMNSV EwAAAAAADwDWB4YABgIwALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBvAG0AYQBuAAAAVKkT AFSpEwAclxMA1JUTAHg6CzDUlRMAAAAAAA8A1gcAAAYiAAANBAgAAABwtQAAcLUAAA8AihOGAAAA AAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixNoAAAALwDIDwwAAAAwANIPBAAAAAAAAAAAAHsXEAAA AAMAAACoAwAAAwADAAIP//8PAK4PNAAAABAArw8IAAAACAEAAAEAAAAAAKwPHAAAAAAAAAIAAAAA AAAAAAAAAAAAAgAAAAAAAAAAAAA/ANkPDAAAAAAA2g8EAAAAAAAjAE8A2Q8MAAAAAADaDwQAAAAN AD0ADwDwD2ELAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD3kA AABPU1BGIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJbXBhaXJtZW50IEF3YXJlIFJvdXRpbmcg YW5kIFdhdmVsZW5ndGggQXNzaWdubWVudCBpbiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwg TmV0d29ya3MgAAChDyYAAAB6AAAAAAAAAAAAeAAAAAAAAgAcAAEAAAAAAAAAAQAAAAAAAgAoAAAA qg8yAAAARQAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIMwAAAAYAAAAJBAkEAQAAAAcAAAAAAAQICQQQ AJ8PBAAAAAUAAAAAAKgPnwAAAENDQU1QIFdHLCBJRVRGIDc4dGgsIE1hYXN0cmljaHQsIE5ldGhl cmxhbmRzIA0NZHJhZnQtYWdyYXotY2NhbXAtd3Nvbi1pbXBhaXJtZW50LW9zcGYtMDAudHh0DQ1G ZXJuYW5kbyBBZ3JheiAoYWdyYXpAdHNjLnVwYy5lZHUpDVlhYmluIFllICh5YWJpbi55ZUBodWF3 ZWkuY29tKQAAoQ8+AAAAoAAAAAAAABAAAHgALwAAAAAABgASAAAAAAUuAAAAAAACABgAAQAAAAEA BgABABIAAAD//kIAAAAAAAIAEgAAAKoPPgAAABUAAAAGAAAACQQECBgAAAAGAAAACQQECDAAAAAG AAAACQQECAEAAAAGAAAACQgECEIAAAAHAAAAAAAMBAQIDwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAA AAAAAAhYCzAAAN8PCAAAABUAAAAtAAAAAADzAxQAAABTAAAABAAAAAIAAAAOAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8PAAAAQWNrbm93bGVkZ21lbnRzAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAk AAAAqg8aAAAADwAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEA AAAHAAAAAAAECAkEAADzAxQAAABWAAAABAAAAAEAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8K AAAAQmFja2dyb3VuZAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIAJAAAAKoPGgAAAAoAAAAGAAAA CQQECAEAAAAHAAAAAAAECAkEAADzAxQAAABoAAAABAAAAAIAAAAfAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8KAAAAT2JqZWN0aXZlIAAAoQ8cAAAACwAAAAAAAAAAAAkAAAAAAAIAJAACAAAAAAAAAAAA qg8aAAAACgAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAH AAAAAAAECAkEAADzAxQAAABiAAAABAAAAAIAAAAZAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAA T1NQRiByb3V0aW5nIGZvciBJQS1SV0EgLU5ldyBQTEkgVExWIAAAoQ8qAAAAJgAAAAAAAAAAABcA AAAAAEMACwALACQADQAAAAAAAgAkAAIAAAAAAAAAAACqDz4AAAAXAAAABgAAAAkIBAgFAAAABgAA AAkEBAgIAAAABgAAAAkECQQBAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBBAAnw8EAAAAAQAAAAAA qg8OAAAAAQAAAAcAAAAAAAQICQQAAPMDFAAAAFcAAAAEAAAAAgAAABIBAAAAAAAAAACfDwQAAAAA AAAAAACoDyAAAABUaGUgY29tcG9zaXRpb24gb2YgTGluayBQTEkgVExWIAAAoQ8cAAAAIQAAAAAA AAAAAB8AAAAAAAIAJAACAAAAAAAAAAAAqg8mAAAAHwAAAAYAAAAJBAkEAQAAAAYAAAAJBAQIAQAA AAcAAAAAAAQICQQQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAECAkEAADzAxQAAABjAAAA BAAAAAIAAAAaAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAVGhlIGNvbXBvc2l0aW9uIG9mIE5v ZGUgUExJIFRMViAAAKEPHAAAACEAAAAAAAAAAAAfAAAAAAACACQAAgAAAAAAAAAAAKoPPgAAABMA AAAGAAAACQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAGAAAACQQECAEAAAAHAAAAAAAE CAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZAAAAAQAAAACAAAA GwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHgAAAFNvbWUgc3ViLVRMVnMgYW5kIHN1Yi1zdWItVExW cwAAoQ8UAAAAHwAAAAAAAAAAAB8AAAAAAAIAJAAAAKoPUAAAAAkAAAAGAAAACQQECAMAAAAHAAAA AwAJBAkEAQAAAAcAAAADAAkEBAgNAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAHAAAAAAAE CAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZQAAAAQAAAACAAAA HAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3IgdGhlIExpbmsg UExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPGgAAACQAAAAGAAAACQQJBAEA AAAHAAAAAAAECAkEEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZgAA AAQAAAACAAAAHQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAFBhcmFtZXRlciBUeXBlcyBmb3Ig dGhlIE5vZGUgUExJIFRMVgAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIAJAAAAKoPMgAAABgAAAAG AAAACQQJBAQAAAAGAAAACQQECAgAAAAGAAAACQQJBAEAAAAHAAAAAAAECAkEEACfDwQAAAABAAAA AACqDw4AAAABAAAABwAAAAAABAgJBAAA8wMUAAAAZwAAAAQAAAACAAAAHgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPGwAAAEFuIEV4YW1wbGUgb2YgY29tcG9uZW50IFRMVgAAoQ8UAAAAHAAAAAAAAAAA ABwAAAAAAAIAJAAAAKoPDAAAABwAAAAGAAAACQQECBAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcA AAAAAAQICQQAAPMDFAAAAEQAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABO ZXh0IFN0ZXBzAAChDxQAAAALAAAAAAAAAAAACwAAAAAAAgAkAAAAqg8MAAAACwAAAAYAAAAJBAQI EACfDwQAAAABAAAAAACoD6oAAABSZWZpbmUgaXQgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFjayBm cm9tIHRoZSBtZWV0aW5nIG9yIG1haWxpbmcgbGlzdA1LZWVwIHVwZ3JhZGluZyB3aGVuIElUVS1U IGRlZmluZWQgdGhlIHN0YW5kYXJkIGltcGFpcm1lbnQgaW5mb3JtYXRpb24NQ29tbWVudHMgYXJl IGFsd2F5cyBhcHByZWNpYXRlZAAAoQ9GAAAAiwAAAAAAsgAAAAMA2AAGAAAAAAEgAAAAAACyIAAA AwDYAAYAAAAAATIAGwAAAAAAYQALAAAACwCQAAAAAARBAAAECwALAAAAqg8aAAAAqgAAAAYAAAAJ BAQIAQAAAAcAAAAAAAQICQQvAPAPOAAAAAAA8wMUAAAABgAAAAAAAAAAAAAAAAEAAAAAAAAAAPMD FAAAAE0AAAAAAAAAAAAAAAgBAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEADVhgYAAAD1DxwAAAAA AQAApBkAA7GGBgCTtgYAAQAAAGgAAAABAMUxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAABAsr+aqKcsB pgQAAEAVAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH/////AgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAkN8GAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAAAA+AAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAUA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPQPAAAAAAAAgQYA AIIGAACDBgAAhAYAAIUGAACGBgAAhwYAAIgGAACJBgAAigYAAIsGAACMBgAAjQYAAI4GAACPBgAA kAYAAJEGAACSBgAAkwYAAJQGAACVBgAAlgYAAJcGAACYBgAAmQYAAJoGAACbBgAAnAYAAJ0GAACe BgAAnwYAAKAGAAChBgAAogYAAKMGAACkBgAApQYAAKYGAACnBgAAqAYAAKkGAACqBgAAqwYAAKwG AACtBgAArgYAAK8GAACwBgAAsQYAALIGAACzBgAAtAYAALUGAAC2BgAAtwYAALgGAAC5BgAAugYA ALsGAAC8BgAAvQYAAL4GAAC/BgAAwAYAAMEGAADCBgAAwwYAAMQGAADFBgAAxgYAAMcGAADIBgAA yQYAAMoGAADLBgAAzAYAAM0GAADOBgAAzwYAANAGAADRBgAA0gYAANMGAADUBgAA1QYAANYGAADX BgAA2AYAANkGAADaBgAA2wYAANwGAADdBgAA3gYAAN8GAADgBgAA4QYAAOIGAADjBgAA5AYAAOUG AADmBgAA5wYAAP7///+LBAAA/f////3////9/////v////7////9//////////////////////// //////////////////////////////////////////////////////////////////////////// AgYAAAMGAAAEBgAABQYAAAYGAAAHBgAACAYAAAkGAAAKBgAACwYAAAwGAAANBgAADgYAAA8GAAAQ BgAAEQYAABIGAAATBgAAFAYAABUGAAAWBgAAFwYAABgGAAAZBgAAGgYAABsGAAAcBgAAHQYAAB4G AAAfBgAAIAYAACEGAAAiBgAAIwYAACQGAAAlBgAAJgYAACcGAAAoBgAAKQYAACoGAAArBgAALAYA AC0GAAAuBgAALwYAADAGAAAxBgAAMgYAADMGAAA0BgAANQYAADYGAAA3BgAAOAYAADkGAAA6BgAA OwYAADwGAAA9BgAAPgYAAD8GAABABgAAQQYAAEIGAABDBgAARAYAAEUGAABGBgAARwYAAEgGAABJ BgAASgYAAEsGAABMBgAATQYAAE4GAABPBgAAUAYAAFEGAABSBgAAUwYAAFQGAABVBgAAVgYAAFcG AABYBgAAWQYAAFoGAABbBgAAXAYAAF0GAABeBgAAXwYAAGAGAABhBgAAYgYAAGMGAABkBgAAZQYA AGYGAABnBgAAaAYAAGkGAABqBgAAawYAAGwGAABtBgAAbgYAAG8GAABwBgAAcQYAAHIGAABzBgAA dAYAAHUGAAB2BgAAdwYAAHgGAAB5BgAAewYAAP////98BgAAfQYAAH4GAAB/BgAAgAYAAP3////9 /////f////3////9/////f////3////9/////////////////////v///40EAACOBAAAjwQAAJAE AACRBAAAkgQAAJMEAACUBAAAlQQAAJYEAACXBAAAmAQAAJkEAACaBAAAmwQAAJwEAACdBAAAngQA AJ8EAACgBAAAoQQAAKIEAACjBAAApAQAAGsEAAD/////pwQAAKgEAACpBAAAqgQAAKsEAACsBAAA rQQAAGgEAACvBAAAsAQAALEEAACyBAAAswQAALQEAAC1BAAAtgQAALcEAAC4BAAAuQQAALoEAAC7 BAAAvAQAAL0EAAC+BAAAvwQAAMAEAADBBAAAwgQAAMMEAADEBAAAxQQAAMYEAADHBAAAyAQAAMkE AADKBAAAywQAAMwEAADNBAAAzgQAAM8EAADQBAAA0QQAANIEAADTBAAA1AQAANUEAADWBAAA1wQA ANgEAADZBAAA2gQAANsEAADcBAAA3QQAAN4EAADfBAAA4AQAAOEEAADiBAAA4wQAAOQEAADlBAAA 5gQAAOcEAADoBAAA6QQAAOoEAADrBAAA7AQAAO0EAADuBAAA7wQAAPAEAADxBAAA8gQAAPMEAAD0 BAAA9QQAAPYEAAD3BAAA+AQAAPkEAAD6BAAA+wQAAPwEAAD9BAAA/gQAAP8EAAABBQAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAA HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAt AAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsA AAA8AAAAPQAAAD4AAAA/AAAA/v///0EAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAA AEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAAD+/////v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////9hbWV0ZXIg VHlwZXMgZm9yIHRoZSBOb2RlIFBMSSBUTFYAHAAAAEFuIEV4YW1wbGUgb2YgY29tcG9uZW50IFRM VgALAAAATmV4dCBTdGVwcwAMEAAABgAAAB4AAAALAAAA0tHTw7XE19bM5QADAAAADAAAAB4AAAAR AAAA0d3Kvs7EuOXJ6LzGxKOw5QADAAAABAAAAB4AAAALAAAAu8O1xsasserM4gADAAAADAAAAFAA AAADAAAAAAAAACAAAAABAAAAMgAAAAIAAAA6AAAAAQAAAAIAAAAGAAAAc2ZsYWcAAgAAAKgDAAAe AAAADAAAADEyNzgzODI0NDIAAAAAAAD2DyIAAAAUAAAAX8CR46O2BgAKAPQDAwAAACB5MDA5MDAw MTIIAAAAIAB5ADAAMAA5ADAAMAAwADEAMgAAbgAABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAA APsC+/8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIKRwAzAAEAAAAt/AIABAAAAC4BAAAE AAAALQEEAAQAAADwAQMAHAAAAPsC+/8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAEEAAACBAAA AwQAAAQEAAAFBAAABgQAAAcEAAAIBAAACQQAAAoEAAALBAAADAQAAA0EAAAOBAAADwQAABAEAAAR BAAAEgQAABMEAAAUBAAAFQQAABYEAAAXBAAAGAQAABkEAAAaBAAAGwQAABwEAAAdBAAAHgQAAB8E AAAgBAAAIQQAACIEAAAjBAAAJAQAACUEAAAmBAAAJwQAACgEAAApBAAAKgQAACsEAAAsBAAALQQA AC4EAAAvBAAAMAQAADEEAAAyBAAAMwQAADQEAAA1BAAANgQAADcEAAA4BAAAOQQAADoEAAA7BAAA PAQAAD0EAAA+BAAAPwQAAEAEAABBBAAAQgQAAEMEAABEBAAARQQAAEYEAABHBAAASAQAAEkEAABK BAAASwQAAEwEAABNBAAATgQAAE8EAABQBAAAUQQAAFIEAABTBAAAVAQAAFUEAABWBAAAVwQAAFgE AABZBAAAWgQAAFsEAABcBAAAXQQAAF4EAABfBAAAYAQAAGEEAABiBAAAYwQAAGQEAABlBAAAZgQA AGcEAACMBAAAaQQAAO0GAAD/////bAQAAG0EAABuBAAAbwQAAHAEAABxBAAAcgQAAHMEAAB0BAAA dQQAAHYEAAB3BAAAeAQAAHkEAAB6BAAAewQAAHwEAAB9BAAAfgQAAH8EAACuBAAAYW1ldGVyIFR5 cGVzIGZvciB0aGUgTm9kZSBQTEkgVExWABwAAABBbiBFeGFtcGxlIG9mIGNvbXBvbmVudCBUTFYA CwAAAE5leHQgU3RlcHMADBAAAAYAAAAeAAAACwAAANLR08O1xNfWzOUAAwAAAAwAAAAeAAAAEQAA ANHdyr7OxLjlyei8xsSjsOUAAwAAAAQAAAAeAAAACwAAALvDtcbGrLHqzOIAAwAAAAwAAABQAAAA AwAAAAAAAAAgAAAAAQAAADQAAAACAAAAPAAAAAEAAAACAAAABgAAAHNmbGFnAAIAAgAAAKgDAAAe AAAADAAAADEyNzgzODI0NDIAAAAA9g8iAAAAFAAAAF/AkeOjtgYACgD0AwMAAAAgeTAwOTAwMDEy CAAAACAAeQAwADAAOQAwADAAMAAxADIAAG4AAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7 Avv/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B AwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgkAAAAyCkcAMwABAAAALfwCAAQAAAAuAQAABAAA AC0BBAAEAAAA8AEDABwAAAD7Avv/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAAAAA= --Boundary_(ID_TI1Wen4c5+YJ8EMNrECadA)-- From wwwrun@core3.amsl.com Mon Jul 26 09:14:50 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AE5CF3A6C62; Mon, 26 Jul 2010 09:14:50 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net, dbrungard@att.com, andrew.g.malis@verizon.com, matthew.bocci@alcatel-lucent.com, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100726161450.AE5CF3A6C62@core3.amsl.com> Date: Mon, 26 Jul 2010 09:14:50 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, pwe3@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, rcallon@juniper.net, paf@cisco.com Subject: [CCAMP] Updated Liaison Statement, "LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02]" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:14:51 -0000 Title: LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] Submission Date: 2010-07-23 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=938 Please reply by 2010-08-16 From: Greg Jones(ITU-T SG 15) To: IETF MPLS, CCAMP and PWE3 WGs(lberger@labn.net,dbrungard@att.com,andrew.g.malis@verizon.com,matthew.bocci@alcatel-lucent.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org pwe3@ietf.org ccamp@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Kam.Lam@alcatel-lucent.com Purpose: For action Body: Attachment(s): LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1087.pdf) LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1089.pdf) From curtis@occnc.com Mon Jul 26 09:20:04 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34543A6ABB for ; Mon, 26 Jul 2010 09:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjm2MTUV7WB0 for ; Mon, 26 Jul 2010 09:20:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 040513A6908 for ; Mon, 26 Jul 2010 09:19:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6QGKKh4029675; Mon, 26 Jul 2010 12:20:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201007261620.o6QGKKh4029675@harbor.orleans.occnc.com> To: John E Drake From: Curtis Villamizar In-reply-to: Your message of "Thu, 22 Jul 2010 10:21:01 PDT." <5E893DB832F57341992548CDBB3331639844B32D16@EMBX01-HQ.jnpr.net> Date: Mon, 26 Jul 2010 12:20:20 -0400 Sender: curtis@occnc.com Cc: Snigdho Bardalai , "ccamp@ietf.org" , Igor Bryskin Subject: Re: [CCAMP] R: R: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:20:04 -0000 In message <5E893DB832F57341992548CDBB3331639844B32D16@EMBX01-HQ.jnpr.net> John E Drake writes: > > Hi, > > I have a suggestion. > > Why don't we allow a node to optionally advertise the unreserved bandwidth for each of the component links in a bundle? This is a general, non-OTN, solution to this specific problem and it is backwards compatible. > > Thanks, > > John John, That is worse. What we are arguing about is whether we can reduce the number of ICSD. If we reduce to one ICSD per advertisement and have one advertisement per component link, we have increased the number of ICSD in total if number of components is >> number of switching types. Curtis > > -----Original Message----- > > From: John E Drake > > Sent: Thursday, July 22, 2010 8:24 AM > > To: 'curtis@occnc.com'; BELOTTI, SERGIO (SERGIO) > > Cc: Daniele Ceccarelli; ccamp@ietf.org; Snigdho Bardalai; Igor Bryskin > > Subject: RE: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > framework-01.txt > > > > Curtis, > > > > As I said last week, I think the existing RFC 4202/4203 design works > > just fine for unbundled links. > > > > For bundled links, due to bin packing, it is asserted that if one > > advertised unreserved bandwidth by what I have been calling service > > type (which in the OTN case equates to ODUj client rate), one can get a > > more accurate understanding of the state of the bundled link wrt the > > number of LSPs that could be established at each of the ODUj client > > rates available at the time of advertisement. > > > > So, I think there are two questions. 1) Do we want to advertise > > unreserved bandwidth by service type, and if so, do we want to > > advertise it for all links or only for bundled links? > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, July 21, 2010 1:25 PM > > > To: BELOTTI, SERGIO (SERGIO) > > > Cc: curtis@occnc.com; Daniele Ceccarelli; ccamp@ietf.org; Snigdho > > > Bardalai; Igor Bryskin; John E Drake > > > Subject: Re: R: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > In message > > > > m.alcatel-lucent.com> > > > "BELOTTI, SERGIO (SERGIO)" writes: > > > > > > > > Hi Curtis, > > > > > > > > Thanks for your comment. > > > > As pointed out by Daniele you're right but the missing information > > > > here is the real spatial allocation that raised in importance above > > > > all in case of link bundling unless you constrain the capability in > > 1 > > > > component link per TE-link, that would reduce value of this very > > > > important feature for scalability. > > > > > > > > > Maybe I'm missing something (again). If so, please point out what I > > > missed. > > > > > > In link bundling the min LSP BW is the smallest LSP or TDM container > > > supported. Any multiple of the min LSP is allowed. The max LSP BW > > is > > > the largest LSP that can be accommodated (per priority). The max > > > reservable BW (not max LSP bw) is the total size of the bundle, > > > ignoring any reservations, and the reservable BW (in the Link TLV in > > > RFC 3630) indicates how much capacity is still left. > > > > > > For bundles as per RFC 4201: > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > > Bandwidth. For an unbundled link, the Maximum Bandwidth is > > > defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a > > > bundled link at priority p is defined to be the maximum of the > > > Maximum LSP Bandwidth at priority p of all of its component > > links. > > > The details of how Maximum LSP Bandwidth is carried in IS-IS is > > > given in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth > > > is carried in OSPF is given in [GMPLS-OSPF]. > > > > > > This is consistent with RFC 4203 "Max LSP Bandwidth at priority N" > > > being reported in the ISCD. > > > > > > 3.8. Unreserved Bandwidth > > > > > > The unreserved bandwidth of a bundled link at priority p is the > > > sum of the unreserved bandwidths at priority p of all the > > > component links associated with the bundled link. > > > > > > This goes in the Link TLV in the Unreserved Bandwidth sub-TLV defined > > > in RFC 3630. > > > > > > That seems to me to completely cover link bundling with no > > constraints > > > on its capability and no need for one TE-link (FA) per compoent link. > > > > > > > > > > About the last part > > > > > > > > [BTW- Lets please not talk about "ignorance and misunderstanding". > > > > This is not simple obvious stuff and maybe none of us individually > > > > knows everything about everything. Myself (all too obviously > > > > sometimes) included.] > > > > > > > > I'm completely agree with you. > > > > I know all that is not simple and obvious stuff for everyone. > > > > My only two cents is just to highlight it is not always possible > > > > justify that different solution for SDH control plane with respect > > > > what defined in RFC 4202/4203 are deployed, with a bad reading of > > > > these RFCs. > > > > > > > > > We are defining new OTN functionality so software will need to > > > change. If prior SONET implementations didn't get it right that is > > no > > > reason to not get it right in defining the OTN extensions. > > > > > > > > > > Best Regards > > > > > > > > Sergio > > > > > > > > > Curtis > > > > > > > > > > Sergio Belotti > > > > > > > > System Architecture > > > > Optics Division-Terrestrial Optics Unit > > > > ALCATEL-LUCENT > > > > > > > > +39 039 6863033 > > > > +39 039 6863590 > > > > > > > > > > > > -----Messaggio originale----- > > > > Da: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Inviato: mercoledì 21 luglio 2010 1.36 > > > > A: Igor Bryskin > > > > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); ccamp@ietf.org; Snigdho > > > Bardalai > > > > Oggetto: Re: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D7616E@atl-srv- > > > exgen.atl.advaoptical.com> > > > > Igor Bryskin writes: > > > > > > > > > > John, > > > > > > > > > > The point is that from ISCD you can not figure out how *many* > > LSPs > > > > > matching the ISCD you can accommodate on the link. Such > > information > > > is > > > > > important in case of con-current routing (e.g. restoration after > > > link > > > > > failure). > > > > > > > > > > Igor > > > > > > > > Igor, Sergio, > > > > > > > > RFC 4203 (in 1. Introduction) > > > > > > > > The TE LSA, which is an opaque LSA with area flooding scope > > > > [OSPF-TE], has only one top-level Type/Length/Value (TLV) > > triplet > > > > and has one or more nested sub-TLVs for extensibility. The > > > > top-level TLV can take one of two values (1) Router Address or > > (2) > > > > Link. In this document, we enhance the sub-TLVs for the Link > > TLV > > > > in support of GMPLS. Specifically, we add the following sub- > > TLVs > > > > to the Link TLV: > > > > > > > > [OSPF-TE] above is RFC 3630. > > > > > > > > RFC 3630 (in 2.4.2. Link TLV) > > > > > > > > The following sub-TLVs of the Link TLV are defined: > > > > > > > > 1 - Link type (1 octet) > > > > 2 - Link ID (4 octets) > > > > 3 - Local interface IP address (4 octets) > > > > 4 - Remote interface IP address (4 octets) > > > > 5 - Traffic engineering metric (4 octets) > > > > 6 - Maximum bandwidth (4 octets) > > > > 7 - Maximum reservable bandwidth (4 octets) > > > > 8 - Unreserved bandwidth (32 octets) > > > > 9 - Administrative group (4 octets) > > > > > > > > If you read on you find: > > > > > > > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > > > > bandwidth that may be reserved on this link, in this direction, > > in > > > > IEEE floating point format. Note that this may be greater than > > > the > > > > maximum bandwidth (in which case the link may be > > oversubscribed). > > > > > > > > and > > > > > > > > The Unreserved Bandwidth sub-TLV specifies the amount of > > bandwidth > > > > not yet reserved at each of the eight priority levels in IEEE > > > > floating point format. The values correspond to the bandwidth > > > that > > > > can be reserved with a setup priority of 0 through 7, arranged > > in > > > > increasing order with priority 0 occurring at the start of the > > > sub- > > > > TLV, and priority 7 at the end of the sub-TLV. [...] > > > > > > > > So the totals per link and per priority level are already there in > > > the > > > > base spec before the RFC 4203 *extensions* to RFC 3630 were added. > > > > > > > > That is how you figure out how many ODU0 you can add to your > > existing > > > > ODU2, and so on. > > > > > > > > [BTW- Lets please not talk about "ignorance and misunderstanding". > > > > This is not simple obvious stuff and maybe none of us individually > > > > knows everything about everything. Myself (all too obviously > > > > sometimes) included.] > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: John E Drake [mailto:jdrake@juniper.net] > > > > > Sent: Tuesday, July 20, 2010 1:13 PM > > > > > To: BELOTTI, SERGIO (SERGIO); Igor Bryskin > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > framework-01.txt > > > > > > > > > > >From RFC 4202: > > > > > > > > > > For a simple (unbundled) link the Maximum LSP Bandwidth at > > > priority p > > > > > is defined as the maximum bandwidth an LSP at priority p could > > > > > reserve. Maximum LSP Bandwidth for a bundled link is defined > > in > > > > > [LINK-BUNDLE]. > > > > > > > > > > The Minimum LSP Bandwidth specifies the minimum bandwidth an > > LSP > > > > > could reserve. > > > > > > > > > > Typical values for the Minimum LSP Bandwidth and for the > > Maximum > > > LSP > > > > > Bandwidth are enumerated in [GMPLS-SIG]. > > > > > > > > > > On an interface having Standard SDH multiplexing, an LSP at > > > priority > > > > > p could reserve any bandwidth allowed by the branch of the SDH > > > > > hierarchy, with the leaf and the root of the branch being > > > defined by > > > > > the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at > > > priority > > > > > p. > > > > > > > > > > On an interface having Arbitrary SDH multiplexing, an LSP at > > > priority > > > > > p could reserve any bandwidth between the Minimum LSP > > Bandwidth > > > and > > > > > the Maximum LSP Bandwidth at priority p, provided that the > > > bandwidth > > > > > reserved by the LSP is a multiple of the Minimum LSP > > Bandwidth. > > > > > > > > > > >From RFC 4201: > > > > > > > > > > 3.10. Maximum LSP Bandwidth > > > > > > > > > > The Maximum LSP Bandwidth takes the place of the Maximum > > > Bandwidth. > > > > > For an unbundled link, the Maximum Bandwidth is defined in > > > > > [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link > > at > > > > > priority p is defined to be the maximum of the Maximum LSP > > > Bandwidth > > > > > at priority p of all of its component links. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: John E Drake > > > > > > Sent: Tuesday, July 20, 2010 10:04 AM > > > > > > To: 'BELOTTI, SERGIO (SERGIO)'; Igor Bryskin > > > > > > Cc: ccamp@ietf.org; Snigdho Bardalai > > > > > > Subject: RE: [CCAMP] R: Comment on draft-ietf-ccamp-gmpls-g709- > > > > > > framework-01.txt > > > > > > > > > > > > Snipped.... > > > > > > > > > > > > > > > > > > > > I realized from someone in this thread (not from you) this > > was > > > due > > > > > > just > > > > > > > to ignorance and misunderstanding of RFC 4202/4203 bandwidth > > > > > > > advertisement for SDH . Anyway it is a fact that the > > > alternative > > > > > > format > > > > > > > is used in many implementations "in field" for SDH control > > > plane. > > > > > > > > > > > > > > > > > > > JD: As the person to whom I believe you are referring, I would > > > suggest > > > > > > that you actually read RFC 4202 and 4206. From acee.lindem@ericsson.com Tue Jul 27 07:26:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F1D3A6A38 for ; Tue, 27 Jul 2010 07:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zfeq8F8Tk3E for ; Tue, 27 Jul 2010 07:26:55 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8FAB13A6A6D for ; Tue, 27 Jul 2010 07:26:55 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o6REZsVc006657; Tue, 27 Jul 2010 09:35:55 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.34]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 27 Jul 2010 10:26:52 -0400 From: Acee Lindem To: Yabin Ye Date: Tue, 27 Jul 2010 10:26:49 -0400 Thread-Topic: [CCAMP] Ask for comments Thread-Index: Acstl8GaLIvBJxMRSTGQqhgjZ3vB9Q== Message-ID: References: <004701cb2cac$ff8674f0$6146c80a@china.huawei.com> In-Reply-To: <004701cb2cac$ff8674f0$6146c80a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?gb2312?B?TWljaKiobGUgV2lsbWV0?= , "ccamp@ietf.org" , "itom@ait.edu.gr" , Siamak Azodolmolky Subject: Re: [CCAMP] Ask for comments X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 14:26:56 -0000 SGkgWWFiaW4sDQoNCkkgaGF2ZSBhIGNvdXBsZSBjb21tZW50czoNCg0KICAgICAgIC0gRmlyc3Qs IHRoaXMgZG9jdW1lbnQgZXh0ZW5kcyBPU1BGIFRFIHJhdGhlciB0aGFuIHRoZSBPU1BGIHByb3Rv Y29sIGl0c2VsZi4NCiAgICAgICAtIFNlY29uZCwgdGhlIGRvY3VtZW50IHJlZmVycyB0byBQTEkg VEUgTFNBcyBhcyBpZiB0aGV5IHdlcmUgc2VwYXJhdGUgTFNBcy4gSG93ZXZlciwgSSBiZWxpZXZl IHRoZXNlIGFyZSBqdXN0IGFkZGl0aW9uYWwgVEUgTFNBcyBhcyBkZXNjcmliZWQgaW4gUkZDIDM2 MzAuDQogICAgICAgLSBTaW1pbGFybHksIHRoZSBkb2N1bWVudCByZWZlcnMgdG8gdGhlIHRvcC1s ZXZlbCBMaW5rIGFuZCBOb2RlIFRMVnMgYXMgaWYgdGhleSBhcmUgbmV3IFBMSSBUTFZzLiBIb3dl dmVyLCB0aGVzZSBhcmUgcmVmZXJlbmNlZCB3aXRoIHRoZSBzYW1lIGNvZGUgcG9pbnRzIGFzIHRo ZSBleGlzdGluZyBMaW5rIGFuZCBOb2RlIFRMVnMuIFRoZXkgd2lsbCBuZWVkIG5ldyB0eXBlcyBp ZiB5b3Ugd2FudCB0byByZWRlZmluZSB0aGVtIHdpdGggZGlmZmVyZW50IHNlbWFudGljcy4NCiAg ICAgICAtIFNhbWUgZm9yIHRoZSBSZW1vdGUgSW50ZXJmYWNlIElQIEFkZHJlc3MgU3ViLVRMViBh bmQgTG9jYWwgSW50ZXJmYWNlIElQIEFkZHJlc3MgU3ViLVRMVi4gVGhlc2UgYXJlIG5vdCBuZXcg U3ViLVRMVnMgYW5kIHByb2JhYmx5IGRvbid0IG5lZWQgdG8gYmUgZXZlbiBpZiBuZXcgdG9wLWxl dmVsIFBMSSBUTFZzIGFyZSByZXF1aXJlZC4NCg0KRnJvbSBhIGhpZ2gtbGV2ZWwsIGl0IHNlZW1z IHRoZSBvbmx5IG5ldyBUTFZzIHJlcXVpcmVkIGFyZSB0aGUgb25lcyBmb3IgUExJIGFuZCB0aGlz IGluZm9ybWF0aW9uIGNhbiBiZSBqdXN0IGFkdmVydGlzZWQgd2l0aCB0aGUgZXhpc3RpbmcgVEUg aW5mb3JtYXRpb24uIEhvd2V2ZXIsIGR1ZSB0byB0aGUgdm9sdW1lIGFuZCBmcmVxdWVuY3kgb2Yg Y2hhbmdlLCB5b3UgbWF5IHdhbnQgc2VwYXJhdGUgTFNBcy4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpP biBKdWwgMjYsIDIwMTAsIGF0IDY6MjYgQU0sIFlhYmluIFllIHdyb3RlOg0KDQpEZWFyIEFsbCwN Cg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBlbnRpdGxlZCChsE9TUEYgRXh0ZW5zaW9ucyBp biBTdXBwb3J0IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3Np Z25tZW50IGluIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAoV1NPTnMpobEu DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFncmF6LWNjYW1wLXdzb24taW1w YWlybWVudC1vc3BmLTAwDQoNClRoaXMgZG9jdW1lbnQgc3VnZ2VzdHMgdG8gZXh0ZW5kIHRoZSBP U1BGLVRFIHByb3RvY29scyBieSBpbmNsdWRpbmcgdGhlIHBoeXNpY2FsIGltcGFpcm1lbnRzIGlu IG9yZGVyIHRvIHN1cHBvcnQgR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNo aW5nIChHTVBMUykgYW5kIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSAgICBjb250cm9s IG9mIEltcGFpcm1lbnQgQXdhcmUgUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25tZW50IGlu IFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAoV1NPTnMpLg0KDQpEdWUgdG8g dXJnZW50IGlzc3Vlcywgd2UgYXJlIG5vdCBhYmxlIHRvIGF0dGVuZCB0aGUgbWVldGluZy4gQXR0 YWNoZWQgcGxlYXNlIGZpbmQgdGhlIHByZXNlbnRhdGlvbiwgYW5kIGtpbmRseSBsZXQgdXMga25v dyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMuDQoNCkJhY2tncm91bmQ6IFRoaXMgZHJhZnQgaXMg dGhlIG91dHB1dCBvZiBFVSBGUDcgZnVuZGVkIERJQ09ORVQgcHJvamVjdC4gTW9yZSBkZXRhaWxz IG9mIHRoaXMgcHJvamVjdCBjYW4gYmUgZm91bmQgYXQgaHR0cDovL3d3dy5kaWNvbmV0LmV1L2hv bWVwYWdlLmFzcA0KDQpUaGFua3MgYW5kIHJlZ2FyZHMsDQoNCllhYmluIFllDQoNCg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpZYWJp biBZZSDSttHHsfMNCkV1cm9wZWFuIFJlc2VhcmNoIENlbnRlcg0KSHVhd2VpIFRlY2hub2xvZ2ll cw0KUmllc3N0ci4gMjUNCjgwOTkyIE11bmljaA0KR2VybWFueQ0KVGVsOiArNDkgODkgMTU4IDgz NCA0MDc4DQpDZWxsOiArNDkgMTYyIDIwNDc1NzANCkZheDogKzQ5IDg5IDE1OCA4MzQgNDQ0Nw0K RS1tYWlsOiB5YWJpbi55ZUBodWF3ZWkuY29tPG1haWx0bzp5YWJpbi55ZUBodWF3ZWkuY29tPg0K d3d3Lmh1YXdlaS5jb208aHR0cDovL3d3dy5odWF3ZWkuY29tLz4NCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo8V1NPTiBpbXBhaXJt ZW50IG9zcGYgVjEucHB0PjxBVFQwMDAwMS4udHh0Pg0KDQo= From ietfc@btconnect.com Tue Jul 27 08:37:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652803A6A40; Tue, 27 Jul 2010 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg9pCcLyrUXf; Tue, 27 Jul 2010 08:37:04 -0700 (PDT) Received: from c2beaomr04.btconnect.com (c2beaomr04.btconnect.com [213.123.26.182]) by core3.amsl.com (Postfix) with ESMTP id AE6B43A68AB; Tue, 27 Jul 2010 08:37:03 -0700 (PDT) Received: from pc6 (host86-145-196-228.range86-145.btcentralplus.com [86.145.196.228]) by c2beaomr04.btconnect.com with SMTP id CHO87250; Tue, 27 Jul 2010 16:36:57 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C4EFD19.014A, actions=tag Message-ID: <01eb01cb2d98$974743a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: , , References: <20100723213112.22BA83A68D3@core3.amsl.com> Date: Tue, 27 Jul 2010 16:32:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr04.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B020A.4C4EFD2B.02EB,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: mpls@ietf.org, greg.jones@itu.int, ccamp@ietf.org, adrian.farrel@huawei.com, rcallon@juniper.net Subject: Re: [CCAMP] [mpls] New Liaison Statement, "LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02]" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 15:37:05 -0000 Greg Trimming the cc list a smidgeon ... I notice that the message to the CCAMP list gave the files as file1087.pdf and file1089.pdf whereas this has file1087.pdf and file1088.pdf, the last of which gives HTTP 404; am I right in thinking that this reference to file1088.pdf is in error? Tom Petch ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: ; ; ; ; ; Cc: ; ; ; ; ; ; ; ; ; ; ; ; Sent: Friday, July 23, 2010 11:30 PM Subject: [mpls] New Liaison Statement, "LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02]" > > Title: LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] > Submission Date: 2010-07-23 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=938 > Please reply by 2010-08-16 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS, CCAMP and PWE3 WGs(lberger@labn.net,dbrungard@att.com,andrew.g.malis@verizon.com,matthew.bocci@ alcatel-lucent.com,swallow@cisco.com,loa@pi.nu) > Cc: paf@cisco.com > stbryant@cisco.com > adrian.farrel@huawei.com > rcallon@juniper.net > mpls@ietf.org > pwe3@ietf.org > ccamp@ietf.org > yoichi.maeda@ntt-at.co.jp > steve.trowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Kam.Lam@alcatel-lucent.com > Purpose: For action > Body: > Attachment(s): > LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1087.pdf) > LS218 - Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02 [Ref # 036.02] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1088.pdf) > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From db3546@att.com Tue Jul 27 08:43:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647E83A69BC; Tue, 27 Jul 2010 08:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHOWhfYMGO-8; Tue, 27 Jul 2010 08:43:33 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 543613A680B; Tue, 27 Jul 2010 08:43:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1280245433!35772743!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5675 invoked from network); 27 Jul 2010 15:43:54 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jul 2010 15:43:54 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6RFhQnh027548; Tue, 27 Jul 2010 11:43:27 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6RFhO8c027520; Tue, 27 Jul 2010 11:43:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jul 2010 11:43:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt Thread-Index: Acsd5KjavXnp1fQlSf+BwrHsqstq4wA1mEKgA7ml5AA= From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" , , Cc: mpls-tp@ietf.org Subject: Re: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 15:43:34 -0000 The last call has ended. Authors, please address the comments and update the document. Thanks, CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs -----Original Message----- From: BRUNGARD, DEBORAH A (ATTLABS)=20 Sent: Thursday, July 08, 2010 12:40 PM To: CCAMP; pwe3@ietf.org; mpls@ietf.org Cc: mpls-tp@ietf.org Subject: FW: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt This WG Last Call will be extended to be a joint last call of the ccamp, pwe3, and mpls wgs and the end date extended to July 26th. Thanks, CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Wednesday, July 07, 2010 10:57 AM To: CCAMP; pwe3@ietf.org Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [CCAMP] Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt This begins a joint ccamp and pwe3 last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt: http://www.ietf.org/id/draft-ietf-ccamp-mpls-tp-cp-framework-02.txt The last call ends on July 21, 2010 at 24:00 UTC. Please send comments to the ccamp and pwe3 lists. Deborah and Andy and Matthew _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Wed Jul 28 05:47:20 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6400E28C0E8 for ; Wed, 28 Jul 2010 05:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxjSPaIWdQNb for ; Wed, 28 Jul 2010 05:47:16 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id B72D128C152 for ; Wed, 28 Jul 2010 05:47:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,274,1278288000"; d="scan'208,217";a="1326602528" Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 28 Jul 2010 12:47:37 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Wed, 28 Jul 2010 07:47:37 -0500 From: "Sadler, Jonathan B." To: "ccamp@ietf.org" Date: Wed, 28 Jul 2010 07:46:32 -0500 Thread-Topic: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-00 Thread-Index: AcsuUp939hT3HLL8Rru4Nxrw30R0eQ== Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2BCF33A0DDB1@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5292FFA96EC22A4386067E9DBCC0CD2BCF33A0DDB1EXNAPtellabsw_" MIME-Version: 1.0 Subject: [CCAMP] Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 12:47:20 -0000 --_000_5292FFA96EC22A4386067E9DBCC0CD2BCF33A0DDB1EXNAPtellabsw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Fatai and Dan, In this I-D, it looks like source node is specifying the specific technolog= y used in the lower layer connection (i.e. the connection from Node B to C)= . If Nodes B, E and C (as shown in Figures 2 and 3) are being provided by a s= eparate carrier, this amounts to the customer of the service provider telli= ng the service provider how to deliver their service. This is problematic = as the carrier may have different policy from the customer for how to deliv= er the service requested in the client layer. In this case, do you envisio= n the operator of Nodes B, E and C ignoring or refusing the service request= ? Also, how do you signal the specific adaptation method that should be used?= If the adaptations used in Node B and Node C don't match, then the lower = layer connection will not be useable by the client layer so coordination is= important. Finally, do you see this as being able to operate in a topology that has a = widely varying topography (i.e. transitions down through multiple lower lay= ers and doesn't make an assumption the layers are simply nested)? Thanks, Jonathan Sadler --_000_5292FFA96EC22A4386067E9DBCC0CD2BCF33A0DDB1EXNAPtellabsw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Fatai and Dan,

 

In this I-D, it looks like source node is specifying t= he specific technology used in the lower layer connection (i.e. the connection from Node B to C).

 

If Nodes B, E and C (as shown in Figures 2 and 3) are = being provided by a separate carrier, this amounts to the customer of the service provider telling the service provider how to deliver their service.  T= his is problematic as the carrier may have different policy from the customer f= or how to deliver the service requested in the client layer.  In this cas= e, do you envision the operator of Nodes B, E and C ignoring or refusing the service request?

 

Also, how do you signal the specific adaptation method= that should be used?  If the adaptations used in Node B and Node C don̵= 7;t match, then the lower layer connection will not be useable by the client la= yer so coordination is important.

 

Finally, do you see this as being able to operate in a topology that has a widely varying topography (i.e. transitions down throug= h multiple lower layers  and doesn’t make an assumption the layers= are simply nested)?

 

Thanks,

 

Jonathan  Sadler

--_000_5292FFA96EC22A4386067E9DBCC0CD2BCF33A0DDB1EXNAPtellabsw_-- From rbriscoe@jungle.bt.co.uk Tue Jul 27 09:42:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D8628B56A for ; Tue, 27 Jul 2010 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5baFNBCt1Ct for ; Tue, 27 Jul 2010 09:42:16 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 8321F3A67B7 for ; Tue, 27 Jul 2010 09:42:16 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 17:42:36 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 17:42:36 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1280248954729; Tue, 27 Jul 2010 17:42:34 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.62.89]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6RGgX3U004751; Tue, 27 Jul 2010 17:42:33 +0100 Message-Id: <201007271642.o6RGgX3U004751@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Jul 2010 17:42:33 +0100 To: "James M. Polk" , Michael Behringer , "Le FAUCHEUR, Francois" From: Bob Briscoe In-Reply-To: <7.1.0.9.2.20100725102528.059fb688@jungle.bt.co.uk> References: <201007141648.o6EGm5j1007861@sj-core-4.cisco.com> <7.1.0.9.2.20100725102528.059fb688@jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jul 2010 16:42:36.0196 (UTC) FILETIME=[B7D34E40:01CB2DAA] X-Mailman-Approved-At: Wed, 28 Jul 2010 08:06:47 -0700 Cc: ccamp@ietf.org, tsvwg IETF list Subject: Re: [CCAMP] (another) WGLC started for "RSVP Security Groupkeying" ID X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 16:42:24 -0000 James, Michael, Francois, Here's my review, I've only looked at the diffs from -05, which I already reviewed. So this review doesn't imply I've re-checked overall readability. S.4.1 "Static keys are preconfigured, either manually, or through a network management system, and not negotiated via a protocol." Delete: ", and not negotiated via a protocol" (the NMS uses a protocol and implying it somehow does not creates complacency - see next point). "The provisioning of static keys requires either manual operator intervention on each node, or a network management system performing the same task." Would it be worth pointing out (or is it obvious?) that, if an NMS is giving nodes static keys, it needs to regularly change the keys it uses to verify that it is talking with the nodes it thinks it is talking with? This recursion has to stop somewhere! S.4.2.1 It's interesting that the following has been deleted. "However, existing key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 [RFC4306] may not be appropriate in all environments because of the relative complexity of the protocols and related operations." Operational complexity is why Jonny can't encrypt, but we're not allowed to say why Jonny can't encrypt?! I would argue that something ought to remain of this sentiment, rather than deletion. Perhaps "Although it is recognised that existing key neg protocols RFC[...] are operationally complex to deploy, the security they provide compared to ad hoc manual alternatives is worth the effort invested." S.6.1 "A router implementing GDOI and the AH and/or ESP protocols is therefore able to implement this policy." The 'and/or' implies the ESP protocol alone could be enough. This needs to refer forward to the limitations of ESP discussed in Security Considerations. (except they aren't there any more - see next point) S.6.3. "In the case of ESP the new, outer IP header however is not cryptographically secured in this process. This has consequences when group keying is used; see the Security Considerations section for details." There is nothing about ESP in the Security Considerations section. And the re-routing attack previously described in Section "6.2. Using IPsec ESP" that I think this refers to has been deleted. Has this attack been proven to not exist, or was losing this text a mistake? S.6.5. " Tunnel mode with address preservation, in conjunction with group keying, allows the use of AH or ESP for protection of RSVP even in cases where non-RSVP nodes have to be traversed. This is because it allows routing of the IPsec protected packet through the non-RSVP nodes in the same way as if it was not IPsec protected. " If we still intend to talk about the reservation re-routing attack (see previous point), we also need to refer to it here (once we have reinstated the text that talks about it). Because a reservation can be redirected by a non-RSVP hop in the address-preserving case as in other cases using ESP. S.10.1 Another "Subverted Nodes" attack occurs to me that uses the weakness of ESP vs AH. Using a group key, a subverted node could turn round a PATH message back to the previous node that the subverted node received it from, thus pretending the PATH had traversed the rest of the path when in fact the subverted node has just been holding on to it for a while. Thus the sending half of the nodes think the reservation has been set-up, while the receiving half never saw it. The point of mentioning these attacks is that, with group keying, a subverted node can change which direction it sends messages (sideways, backwards), not just subvert the messages it forwards. Nits ==== S.2 "If a group key is used, the authentication granularity becomes group membership, not (individual) peer authentication." You might want to make it clear that you are talking about a group of nodes not humans ('group membership' is ambiguous). But I'm not insisting - it's unlikely to be misunderstood. s/...whether authentication or encryption (or both) are used. /...whether authentication or encryption (or both) is used./ Change it back to the correct English: the verb shouldn't match the phrase in the parenthesis. S.2. Penultimate para: s/We note that if this handshake is taking place, /We note that if this handshake has taken place,/ S.3.1 s/INTEGITY /INTEGRITY/ S.6.3. "This has consequences when group keying is used; see the Security Considerations section for details." s/consequences/negative consequences/ S.6.5. "it is not possible to use tunnel-endpoint destination address" s/tunnel-endpoint /a tunnel-endpoint/ Bob At 10:27 25/07/2010, Bob Briscoe wrote: >James, > >I can try to have a look by the deadline. > > >Bob > >At 17:48 14/07/2010, James M. Polk wrote: >>TSVWG >> >>This is to let everyone know we've initiated a new WGLC for the >>"RSVP Security Groupkeying" ID here. >> >>http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/ >> >>This ID has had some significant modifications based on the SecDir >>review by Stephen Kent. Please reread this ID to verify these >>changes are appropriate, and do not introduce new issues or concerns. >> >>Once you have reviewed this version, please send a note to the list >>with an indication whether or not this doc should proceed to the >>IESG for RFC consideration. We chairs need to gauge WG interest >>before this (or any) document progresses towards publication. >> >>Because of the IETF meeting so close, this is an extended WGLC, >>lasting 4 weeks - ending August 11th, 2010. >> >>Please do review this document and let us/the list know what you think. >> >>James & Gorry >>TSVWG chairs > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From loa@pi.nu Thu Jul 29 01:11:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE6E3A68B5; Thu, 29 Jul 2010 01:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76mHVw5R9kJR; Thu, 29 Jul 2010 01:11:54 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 2B37F3A67D1; Thu, 29 Jul 2010 01:11:53 -0700 (PDT) Received: from [130.129.119.231] (dhcp-77e7.meeting.ietf.org [130.129.119.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 6FA39D404F; Thu, 29 Jul 2010 10:12:16 +0200 (CEST) Message-ID: <4C5137DE.6090504@pi.nu> Date: Thu, 29 Jul 2010 10:12:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: pwe3@ietf.org, CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Fwd: Liaison Statement: Re: Review of draft-ietf-mpls-tp-data-plane-03 (Ref #035.02) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:11:56 -0000 This liaison should have been copied to the pwe3 and ccamp lists also. /Loa -------- Original Message -------- Subject: Liaison Statement: Re: Review of draft-ietf-mpls-tp-data-plane-03 (Ref #035.02) Date: Tue, 27 Jul 2010 05:07:17 -0400 From: IETF Chair To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int CC: adrian.farrel@huawei.com, iesg@ietf.org, loa@pi.nu, malcolm.betts@zte.com.cn, mpls@ietf.org, paf@cisco.com, rcallon@juniper.net, stbryant@cisco.com, steve.trowbridge@alcatel-lucent.com, swallow@cisco.com, yoichi.maeda@ntt-at.co.jp, IETF Liaison Statements Thank you for your liaison COM15-LS207-E (ref 35.01) dated 24-June-2010 providing further review comments on draft-ietf-mpls-tp-data-plane. This document completed IETF last call on 14-June-2010 and received IETF consensus. The document was reviewed by the IESG on 17-June-2010 and received approval for publication subject to some minor modifications. Documents in the RFC Editor's queue are only open for minor editorial changes. We have examined the changes proposed by the ITU-T and have formed the following view: Proposed change on page 8: This change is of technical substance, and cannot be made to a document in the RFC Editor's Queue. Proposed change to Section 6: The terms "peer" and "neighbor" are well understood within the IETF and do not need further clarification. The proposed description of the application scenario constitutes a change of technical substance, and cannot be made to a document in the RFC Editor's Queue. If IETF contributors feel that there is an issue to be resolved, there are two processes that are available to make changes to published RFCs. One method is to submit an Erratum Notice using the IETF web pages (http://www.rfc-editor.org/errata.php). The other method is to produce a revision or modification to the published RFC by submitting an Internet-Draft and taking it through the IETF consensus process. Both methods are subject to review before approval. On behalf of the IESG, Russ Housley -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Thu Jul 29 01:13:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469003A69C7; Thu, 29 Jul 2010 01:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdud0OAVUBXn; Thu, 29 Jul 2010 01:13:09 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 31B953A67D1; Thu, 29 Jul 2010 01:13:09 -0700 (PDT) Received: from [130.129.119.231] (dhcp-77e7.meeting.ietf.org [130.129.119.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 4F472D404F; Thu, 29 Jul 2010 10:13:32 +0200 (CEST) Message-ID: <4C51382B.30800@pi.nu> Date: Thu, 29 Jul 2010 10:13:31 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: CCAMP , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Fwd: Liaison Statement: LS206 - Review of draft-ietf-mpls-tp-framework-12 (Ref #034.02) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:13:12 -0000 This liaison should have been copied to the pwe3 and ccamp lists also. /Loa -------- Original Message -------- Subject: Liaison Statement: LS206 - Review of draft-ietf-mpls-tp-framework-12 (Ref #034.02) Date: Tue, 27 Jul 2010 05:18:10 -0400 From: IETF Chair To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int CC: adrian.farrel@huawei.com, iesg@ietf.org, paf@cisco.com, loa@pi.nu, malcolm.betts@zte.com.cn, mpls@ietf.org, rcallon@juniper.net, swallow@cisco.com, stbryant@cisco.com, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, IETF Liaison Statements Thank you for your liaison COM15-LS206-E, Review of draft-ietf-mpls-tp-framework-12 (Ref #034.01) dated 24-June-2010. We regret that the ITU-T was unable to review draft-ietf-mpls-tp-framework-12 within the requested time. It should be noted that participants in SG15 had the same amount of time to review this document as other members of the MPLS-TP design community. The ITU-T participants were therefore afforded no less privilege in the review cycle than any other group of participants. This document completed IETF last call with IETF consensus on 21-April-2010. It was reviewed by the IESG on 20-May-2010 and was approved for publication as an RFC on 24-May-2010. In response to the requirements of the ITU-T, this document was expedited in the RFC Editor's queue and was published as RFC 5921. The text of the published RFC cannot be changed. We note that the ITU-T's requests (cf. COM15-LS205-E) to expedite the development of IETF solutions is not consistent with the request for additional review time. We suggest that the best way to expedite the MPLS-TP work is through a full involvement with the standards development process. This will facilitate earlier input to the documents and mean that the final review can be completed in the time available. We understand the requirements under Recommendation A.5 and we encourage ITU-T participants who are worried about the issues of referenced documents to become involved in the development of those documents earlier in the cycle and throughout the IETF process. This document completed IETF last call with IETF consensus on 21-April-2010. It was reviewed by the IESG on 20-May-2010 and was approved for publication as an RFC on 24-May-2010. In response to the requirements of the ITU-T, this document was expedited in the RFC Editor's queue and was published as RFC 5921. Obviously, the text of the published RFC cannot be changed. Regarding your requested changes these were evaluated and processed as follows: Section 3.4.3: The additional text that you propose is a duplication of the previous sentence where it already says that the UNI is between the CE and the MPLS-TP network. It was not considered appropriate to make such a change at this stage in the process. Figures 3 and 5: These changes are of technical substance and would have required IETF consensus to implement. They were not therefore accepted at this stage in the process. Section 3.4.5, page 32; Section 3.7, pages 36 and 37; Section 3.13, page 45; Section 3.13, page 46: These four cases were communicated informally to the responsible IETF Area Director during your plenary and were included as a late change by the RFC Editor as they were purely minor editorial in nature. Thus, they are already included in the published RFC. If IETF contributors feel that there is an issue to be resolved, there are two processes that are available to make changes to published RFCs. One method is to submit an Erratum Notice using the IETF web pages (http://www.rfc-editor.org/errata.php). The other method is to produce a revision or modification to the published RFC by submitting an Internet-Draft and taking it through the IETF consensus process. Both methods are subject to review before approval. On behalf of the IESG, Russ Housley -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Thu Jul 29 01:14:25 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301163A698F; Thu, 29 Jul 2010 01:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB9DhubHv7mG; Thu, 29 Jul 2010 01:14:23 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 1172B3A69AA; Thu, 29 Jul 2010 01:14:23 -0700 (PDT) Received: from [130.129.119.231] (dhcp-77e7.meeting.ietf.org [130.129.119.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 33EAAD404F; Thu, 29 Jul 2010 10:14:46 +0200 (CEST) Message-ID: <4C513875.2030005@pi.nu> Date: Thu, 29 Jul 2010 10:14:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: CCAMP , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Fwd: Liaison Statement: Re: LS205 - Considerations on the approach, to providing OAM for MPLS-TP (#37.02) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:14:25 -0000 All, this liaison should have been copied to the ccamp and pwe3 lists. /Loa -------- Original Message -------- Subject: Liaison Statement: Re: LS205 - Considerations on the approach,to providing OAM for MPLS-TP (#37.02) Date: Tue, 27 Jul 2010 05:31:38 -0400 From: IETF Chair To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int CC: adrian.farrel@huawei.com, iab@iab.org, iab-chair@iab.org, iesg@ietf.org, loa@pi.nu, malcolm.betts@zte.com.cn, mpls@ietf.org, paf@cisco.co, rcallon@juniper.net, swallow@cisco.com, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, IETF Liaison Statements Purpose: In response Thank you for your liaison COM15-LS205-E, Considerations on the approach to providing OAM for MPLS-TP. We agree that it is desirable to extend the OAM capabilities of the MPLS protocol suite to support the needs of the transport network operators in a timely manner. We hope that these requirements are correctly captured in RFC 5654 and RFC 5860 both of which completed the IETF consensus process and received substantial and constructive review by Study Group 15 of the ITU-T. As you appreciate, both the IETF and the ITU-T are contribution driven organizations. The IETF would therefore encourage the service providers who are requesting more rapid development of standards to participate more fully in the IETF standardization process. Your liaison references some interoperability tests. It is hard for us to evaluate the scope and validity of these tests for a number of reasons: - The specification of the protocols actually tested and the detailed results are confidential to the participants and not generally available. - We cannot assess which features documented in the referenced draft (draft-bhh-mpls-tp-oam-y1731) were tested and which were not tested. - The current revision of draft-bhh-mpls-tp-oam-y1731 does not provide full details of the protocol mechanisms of all of the features it describes. - The test description refers to the unpublished G.8114 (2008), which we understand does not have ITU-T consensus. With regard to the specific technical proposal outlined in the liaison, the IETF process is available to investigate the approaches to the design of an enhanced MPLS OAM to satisfy the needs of network operators, including of course the transport network operators. Such ideas must comply with previously agreed requirements unless new requirements are brought forward and agreed by consensus in both the IETF and the ITU-T. All new approaches are subject to technical discussion within the IETF and will be reviewed by IETF consensus. Proponents of alternative solutions are encouraged to discuss them on the appropriate IETF mailing lists and to attempt to persuade the community of the technical merit of their proposals. The IETF looks forward to working cooperatively with the ITU-T to develop MPLS-TP OAM solution components in a timely manner that meets the needs of network operators wishing to deploy MPLS technology. On behalf of the IESG, Russ Housley -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Thu Jul 29 01:16:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B09E28C0FF; Thu, 29 Jul 2010 01:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cau6gSly9+TP; Thu, 29 Jul 2010 01:15:59 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id EE48528C0DF; Thu, 29 Jul 2010 01:15:58 -0700 (PDT) Received: from [130.129.119.231] (dhcp-77e7.meeting.ietf.org [130.129.119.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B0E1BD404F; Thu, 29 Jul 2010 10:16:21 +0200 (CEST) Message-ID: <4C5138D5.7030905@pi.nu> Date: Thu, 29 Jul 2010 10:16:21 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: pwe3@ietf.org, CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Fwd: Liaison Statement: Re: L211 - Request for the roadmap of MPLS-TP OAM (#038.01) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:16:07 -0000 All, this liaison should have been copied to the ccamp and pwe3 lists. /Loa -------- Original Message -------- Subject: Liaison Statement: Re: L211 - Request for the roadmap of MPLS-TP OAM (#038.01) Date: Tue, 27 Jul 2010 06:19:42 -0400 From: IETF Chair To: tsbsg15@itu.int, greg.jones@itu.int, hhelvoort@huawei.com CC: adrian.farrel@huawei.com, iab@iab.org, iab-chair@iab.org, iesg@ietf.org, loa@pi.nu, mpls@ietf.org, mpls-tp@ietf.org, paf@cisco.co, swallow@cisco.com, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, IETF Liaison Statements Purpose: In response Thank you for your liaison COM15-LS211-E "Request for the roadmap of MPLS-TP OAM (#038.01)" dated 24-June-2010. Like the ITU-T, the IETF is a contribution-driven organization that relies on the voluntary effort of its members. The specific order and the time of delivery is dependent on the timeliness of the input received and the level of contribution. We divide the work into four broad topic areas. Work has started on all four areas, and given the constraints stated above we are unable to impose a priority on the contributors. The first area is linear protection, and the working group has drafts on this topic. The second area is the OAM. The list of drafts are currently found in draft-ietf-mpls-tp-oam-analysis, and this set of drafts cover the required OAM functionality as documented in RFC 5860. The third area is extensions for the MPLS control plane for MPLS-TP networks, and the control plane framework is under way and extensions to RSVP-TE for OAM parameters have been defined. The fourth area covers the rest of the work items, including ring protection. In order to accelerate the progress and meet the operators' urgent requirements for MPLS-TP OAM, it is suggested the ITU-T encourages the service providers who are requesting more rapid development of standards to participate more fully in the IETF standardization process, as jointly agreed upon. The IETF looks forward to working cooperatively with the ITU-T to develop MPLS-TP OAM solution components in a timely manner that meet the needs of network operators wishing to deploy MPLS technology. On behalf of the IESG, Russ Housley -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From zhangfatai@huawei.com Thu Jul 29 03:32:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DC628C11C for ; Thu, 29 Jul 2010 03:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFA7Vjzza1LF for ; Thu, 29 Jul 2010 03:32:37 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 70FB128C131 for ; Thu, 29 Jul 2010 03:31:38 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6B00CD9EL6V3@usaga03-in.huawei.com> for ccamp@ietf.org; Thu, 29 Jul 2010 05:31:54 -0500 (CDT) Received: from zhang (dhcp-749a.meeting.ietf.org [130.129.116.154]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6B00GBWEL4ZG@usaga03-in.huawei.com> for ccamp@ietf.org; Thu, 29 Jul 2010 05:31:54 -0500 (CDT) Date: Thu, 29 Jul 2010 18:31:47 +0800 From: Fatai Zhang To: "Sadler, Jonathan B." , ccamp@ietf.org Message-id: <002c01cb2f09$4042ec90$9a748182@zhang> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_eYP2fjTYNQSvavrHthyaag)" X-Priority: 3 X-MSMail-priority: Normal References: <5292FFA96EC22A4386067E9DBCC0CD2BCF33A0DDB1@EX-NAP.tellabs-west.tellabsinc.net> Subject: Re: [CCAMP] Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 10:32:38 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eYP2fjTYNQSvavrHthyaag) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Jonathan, Thanks for your comments. Please see in-line below. Thanks Fatai Zhang Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28973234 Fax: +86-755-28972935 ----- Original Message ----- From: Sadler, Jonathan B. To: ccamp@ietf.org Sent: Wednesday, July 28, 2010 8:46 PM Subject: [CCAMP] Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-00 Hello Fatai and Dan, In this I-D, it looks like source node is specifying the specific technology used in the lower layer connection (i.e. the connection from Node B to C). If Nodes B, E and C (as shown in Figures 2 and 3) are being provided by a separate carrier, this amounts to the customer of the service provider telling the service provider how to deliver their service. This is problematic as the carrier may have different policy from the customer for how to deliver the service requested in the client layer. In this case, do you envision the operator of Nodes B, E and C ignoring or refusing the service request? Also, how do you signal the specific adaptation method that should be used? If the adaptations used in Node B and Node C don't match, then the lower layer connection will not be useable by the client layer so coordination is important. [Fatai] These questions can be more generic to all the MLN control(e.g, [MLN-EXT]draft and other RFCs), not specific to this draft. Usually, multi-layer for one carrier is more typical for MLN control. In this case, the head node(e.g., it gets the policy from operator or centralized PCE for multi-layers) may prefer to use one specific ISC or granularity for the FA-LSP, so the head node should be capable of indicating this information in the signaling. Finally, do you see this as being able to operate in a topology that has a widely varying topography (i.e. transitions down through multiple lower layers and doesn't make an assumption the layers are simply nested)? [Fatai] In this case, obviously, the recursive procedures can be used. Thanks, Jonathan Sadler ------------------------------------------------------------------------------ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_eYP2fjTYNQSvavrHthyaag) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02REEz LTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0KInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9IA0K InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVldCIg eG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4bWxu czpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHht bG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpxID0g DQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0YyA9 IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5TOkQg PSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVw bC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50 L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5wYXNz cG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6ZHMg PSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSANCiJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5z OmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6eHNp ID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnVk Y3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5z OnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRj L3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6bWRz c2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2Rp Z2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzID0g DQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlv bnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2ludC93 ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1s bnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vd2Vi c2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2UiIA0K WE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+PEhF QUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9aXNvLTg4NTktMSI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjM2OTgi IG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYW1i cmlhIE1hdGg7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCkBw YWdlIFdvcmRTZWN0aW9uMSB7c2l6ZTogOC41aW4gMTEuMGluOyBtYXJnaW46IDEuMGluIDEuMGlu IDEuMGluIDEuMGluOyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMXB0OyBNQVJHSU46 IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIg0KfQ0KTEku TXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDExcHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQt RkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05U LVNJWkU6IDExcHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIs InNhbnMtc2VyaWYiDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsg ew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXBy aW9yaXR5OiA5OQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5Nc29IeXBlcmxp bmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7 IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglDT0xPUjog d2luZG93dGV4dDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IG1zby1zdHls ZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQouTXNvQ2hwRGVmYXVsdCB7DQoJRk9OVC1TSVpF OiAxMHB0OyBtc28tc3R5bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5Xb3JkU2VjdGlvbjEg ew0KCXBhZ2U6IFdvcmRTZWN0aW9uMQ0KfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVT IHZMaW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzs+SGkgSm9uYXRoYW4sPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzs+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PlBsZWFzZSBzZWUgaW4tbGluZSBiZWxvdy48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0zPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+ DQo8RElWPjxCUj5UaGFua3M8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 PjwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj5GYXRhaSBaaGFuZzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPkFkdmFuY2VkIFRlY2hub2xvZ3kgRGVwYXJ0bWVudDxCUj5XaXJlbGluZSBOZXR3b3Jr aW5nIEJ1c2luZXNzIA0KVW5pdDxCUj5IdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTFRELjxCUj5I dWF3ZWkgQmFzZSwgQmFudGlhbiwgDQpMb25nZ2FuZyw8QlI+U2hlbnpoZW4gNTE4MTI5IFAuUi5D aGluYTxCUj5UZWw6ICs4Ni03NTUtMjg5NzMyMzQ8QlI+RmF4OiANCis4Ni03NTUtMjg5NzI5MzU8 QlI+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJ TkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHgg c29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYg c3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBm b250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1Kb25hdGhhbi5TYWRs ZXJAdGVsbGFicy5jb20gDQogIGhyZWY9Im1haWx0bzpKb25hdGhhbi5TYWRsZXJAdGVsbGFicy5j b20iPlNhZGxlciwgSm9uYXRoYW4gQi48L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1jY2FtcEBpZXRmLm9yZyAN CiAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvQT4gPC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4g V2VkbmVzZGF5LCBKdWx5IDI4LCAyMDEwIDg6NDYgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9O VDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBbQ0NBTVBdIENvbW1lbnRz IG9uIA0KICBkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1oLWxzcC1tbG4tMDA8L0RJVj4NCiAgPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJViBj bGFzcz1Xb3JkU2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD5IZWxsbyBGYXRhaSBhbmQg RGFuLDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD5JbiB0aGlzIEktRCwgaXQgbG9va3MgbGlrZSBz b3VyY2Ugbm9kZSBpcyBzcGVjaWZ5aW5nIHRoZSANCiAgc3BlY2lmaWMgdGVjaG5vbG9neSB1c2Vk IGluIHRoZSBsb3dlciBsYXllciBjb25uZWN0aW9uIChpLmUuIHRoZSBjb25uZWN0aW9uIA0KICBm cm9tIE5vZGUgQiB0byBDKS48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+SWYgTm9kZXMgQiwgRSBh bmQgQyAoYXMgc2hvd24gaW4gRmlndXJlcyAyIGFuZCAzKSBhcmUgYmVpbmcgDQogIHByb3ZpZGVk IGJ5IGEgc2VwYXJhdGUgY2FycmllciwgdGhpcyBhbW91bnRzIHRvIHRoZSBjdXN0b21lciBvZiB0 aGUgc2VydmljZSANCiAgcHJvdmlkZXIgdGVsbGluZyB0aGUgc2VydmljZSBwcm92aWRlciBob3cg dG8gZGVsaXZlciB0aGVpciBzZXJ2aWNlLiZuYnNwOyBUaGlzIA0KICBpcyBwcm9ibGVtYXRpYyBh cyB0aGUgY2FycmllciBtYXkgaGF2ZSBkaWZmZXJlbnQgcG9saWN5IGZyb20gdGhlIGN1c3RvbWVy IGZvciANCiAgaG93IHRvIGRlbGl2ZXIgdGhlIHNlcnZpY2UgcmVxdWVzdGVkIGluIHRoZSBjbGll bnQgbGF5ZXIuJm5ic3A7IEluIHRoaXMgY2FzZSwgDQogIGRvIHlvdSBlbnZpc2lvbiB0aGUgb3Bl cmF0b3Igb2YgTm9kZXMgQiwgRSBhbmQgQyBpZ25vcmluZyBvciByZWZ1c2luZyB0aGUgDQogIHNl cnZpY2UgcmVxdWVzdD88L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3OyBzaXplPTM+PC9GT05UPjwvbzpwPiZuYnNwOzwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPkFsc28sIGhvdyBkbyB5b3Ugc2lnbmFsIHRoZSBzcGVjaWZpYyBhZGFwdGF0 aW9uIG1ldGhvZCB0aGF0IA0KICBzaG91bGQgYmUgdXNlZD8gJm5ic3A7SWYgdGhlIGFkYXB0YXRp b25zIHVzZWQgaW4gTm9kZSBCIGFuZCBOb2RlIEMgZG9uknQgDQogIG1hdGNoLCB0aGVuIHRoZSBs b3dlciBsYXllciBjb25uZWN0aW9uIHdpbGwgbm90IGJlIHVzZWFibGUgYnkgdGhlIGNsaWVudCBs YXllciANCiAgc28gY29vcmRpbmF0aW9uIGlzIGltcG9ydGFudC48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0zPjwvRk9OVD4mbmJzcDs8 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3OyBzaXplPTM+W0ZhdGFpXSBUaGVzZSANCiAgcXVlc3Rpb25zIGNhbiBi ZSBtb3JlIGdlbmVyaWMgdG8gYWxsIHRoZSBNTE4gY29udHJvbChlLmcsIFtNTE4tRVhUXWRyYWZ0 IGFuZCANCiAgb3RoZXIgUkZDcyksIG5vdCBzcGVjaWZpYyB0byB0aGlzIGRyYWZ0LiBVc3VhbGx5 LCBtdWx0aS1sYXllciBmb3Igb25lIGNhcnJpZXIgDQogIGlzJm5ic3A7bW9yZSB0eXBpY2FsIGZv ciBNTE4gY29udHJvbC48L0ZPTlQ+Jm5ic3A7PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNp emU9Mz5JbiB0aGlzIA0KICBjYXNlLCB0aGUgaGVhZCBub2RlKGUuZy4sIGl0IGdldHMgdGhlIHBv bGljeSBmcm9tIG9wZXJhdG9yIG9yIGNlbnRyYWxpemVkIFBDRSANCiAgZm9yIG11bHRpLWxheWVy cykgbWF5IHByZWZlciB0byB1c2Ugb25lIHNwZWNpZmljIElTQyBvciBncmFudWxhcml0eSBmb3Ig dGhlIA0KICBGQS1MU1AsIHNvIHRoZSBoZWFkIG5vZGUgc2hvdWxkIGJlIGNhcGFibGUgb2YgaW5k aWNhdGluZyB0aGlzIGluZm9ybWF0aW9uIGluIA0KICB0aGUgc2lnbmFsaW5nLjwvRk9OVD48L0ZP TlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkZpbmFsbHksIGRvIHlvdSBzZWUgdGhpcyBhcyBi ZWluZyBhYmxlIHRvIG9wZXJhdGUgaW4gYSANCiAgdG9wb2xvZ3kgdGhhdCBoYXMgYSB3aWRlbHkg dmFyeWluZyB0b3BvZ3JhcGh5IChpLmUuIHRyYW5zaXRpb25zIGRvd24gdGhyb3VnaCANCiAgbXVs dGlwbGUgbG93ZXIgbGF5ZXJzICZuYnNwO2FuZCBkb2VzbpJ0IG1ha2UgYW4gYXNzdW1wdGlvbiB0 aGUgbGF5ZXJzIGFyZSANCiAgc2ltcGx5IG5lc3RlZCk/PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mz48L0ZPTlQ+Jm5ic3A7PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxGT05UIGNv bG9yPSMwMDAwZmYgc2l6ZT0zPltGYXRhaV0mbmJzcDtJbiANCiAgdGhpcyBjYXNlLCBvYnZpb3Vz bHksIHRoZSByZWN1cnNpdmUgcHJvY2VkdXJlcyBjYW4gYmUgdXNlZC48L0ZPTlQ+PC9GT05UPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTM+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rcyw8bzpwPjwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+Sm9uYXRoYW4mbmJzcDsgU2FkbGVyPG86cD48L286cD48L1A+PC9E SVY+DQogIDxQPjwvUD48Rk9OVCBmYWNlPUNhbGlicmk+PC9GT05UPg0KICA8SFI+DQoNCiAgPFA+ PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkND QU1QIG1haWxpbmcgDQogIGxpc3Q8QlI+Q0NBTVBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRN TD4NCg== --Boundary_(ID_eYP2fjTYNQSvavrHthyaag)--