From lizhong.jin@nsn.com Mon Aug 3 22:34:37 2009 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 BA70F3A6F68 for ; Mon, 3 Aug 2009 22:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 25phf4YWKFfr for ; Mon, 3 Aug 2009 22:34:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 884CF3A6F69 for ; Mon, 3 Aug 2009 22:34:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n745WOm1027213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2009 07:32:24 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n745WNCv030421; Tue, 4 Aug 2009 07:32:23 +0200 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 07:32:22 +0200 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, 4 Aug 2009 13:32:20 +0800 Message-ID: <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion about the GMPLS Signaling Extension Thread-Index: AcoQ+PzvN8qQDMzjS7qJ/zkmnXvkKgDD5t0g References: From: "Jin, Lizhong (NSN - CN/Shanghai)" To: X-OriginalArrivalTime: 04 Aug 2009 05:32:22.0826 (UTC) FILETIME=[F15140A0:01CA14C4] Cc: zhangguoying@mail.ritt.com.cn, xuyunbin@mail.ritt.com.cn Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 04 Aug 2009 05:34:38 -0000 Hi Fatai and all: I agree with the issues of excessive number of labels if using the same label concept of RFC4328. By using bit map for label encoding is a good idea. And from my understanding, draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit map idea if Fatai agree. For backward compatibility, we can not assume that RFC4328 is not deployed unless we can provide some kind of survey report. So currently the right assumption is that RFC4328 has been deployed, and backward compatibity should be considered. Best Regards Lizhong Jin ---------------------------------------------------------------------- Message: 1 Date: Thu, 30 Jul 2009 11:33:56 +0200 From: "BELOTTI SERGIO" Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension forEvolutive OTN To: "Fatai" , , , , , , , Cc: ccamp@ietf.org Message-ID: =09 <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com > =09 Content-Type: text/plain; charset=3D"iso-8859-1" Dear Fatai and all, =20 We agree on the major points raised by Fatai as general issue to be solved in the context of extension needed to cope with new containers defined in ITU q11 context, in addition to handling ODU multiplexing scenarios in existing OTN. There are two basic points that brings to the need to update the RFC4328 anyway. =20 1) the present RFC does not permit the link based negotiation for time slot allocation . No information about tributary port numbers is present and only in case we have "single layer" , no multiplexing LO --> HO you can apply . So this is a lack against the original G.709 even without considering G.709 Am3 . =20 2) Scalability: The extension required in the context of new OTN with the introduction of ODU0, ODU4, and above all ODUflex , required a real modifications of the structure of the label to avoid real big size of number of labels to transmit offloading signalling session. Extension based on RFC4328 logic do not scale when ODU-flex is used. Large ODU flex containers will generate an excessive number of labels (in principle up to 80 per link) causing problems with the size of the RSVP-TE message. =20 This two points together call to the need to change something in RFC. Backward compatibility aspects, present in all the drafts, are surely to be considered and if there are single layer systems deployed using RFC4328 this should be grandfathered. =20 Best Regards =20 Sergio =20 =20 Sergio Belotti =20 CTO Optics Division Alcatel-Lucent =20 +39 039 6863033 +39 039 6863590 =20 ________________________________ Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fatai Inviato: mercoled? 29 luglio 2009 18.33 A: fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com; daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn Cc: ccamp@ietf.org Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension forEvolutive OTN =20 Hi all, =20 To support the current verison of G.709, we think the label format defined in RFC4328 need to be re-defined anyway. The new OTN label format should support the whole ODU sets, not only the ODU1, 2, and 3, but also ODU0, ODU4, even ODUFlex. The following three aspects should be considered carefully: =20 1) The extensibility of the label format is the first thing we should consider. With the development of OTN technology, RFC4328 label format style needs to be extended to support the new bitrate ODU (eg. ODU5, 6...). By the end, we may need keep extending the label formats. Managing lots of label format may cause big trouble, so we need one-shot label format for the evolving OTN. =20 =20 2) Scalability is another key issue. RFC4328 style format may result in big size of the total labels, which definitely increase the burden of the signaling. An efficient approach is needed to carry the same label information but with less amount of the data, bitmap style is the right way to go. =20 3) For backward compatibility, if there are no implementations for RFC4328 (or if there are no deployments it is desirable to deprecate even if it is uncomfortable for existing implementations), it is very safe to deprecate the old definition, and an extensible, efficient and scalable solution could be helpful. The label defined in draft-zhang does not overwrite RFC4328, it can allow the old definition to continue to exist. =20 Hope this can clarify your concern. =20 Authors of draft-zhang =20 =20 =20 ----- Original Message -----=20 From: fu.xihua@zte.com.cn=20 To: dbrungard@att.com ; lberger@labn.net ; zhangfatai@huawei.com ; diego.caviglia@ericsson.com ; daniele.ceccarelli@ericsson.com=20 Cc: ccamp@ietf.org=20 Sent: Tuesday, July 28, 2009 5:33 PM Subject: Discussion about the GMPLS Signaling Extension for Evolutive OTN =20 =09 Hi Fatai and All,=20 =09 We have presented the following two document in the CCAMP morning session. But we have no more time to further discuss GMPLS extension for evolutive OTN=20 draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt =20 draft-zhang-ccamp-gmpls-evolving-g709-01.txt =20 =09 We have a couple of comments and questions for the draft-zhang.=20 (1) draft-zhang defined the extensions including what has been done in RFC4328 (i.e., ODU1, ODU2 and ODU3).=20 draft-ceccarellifuxh defined new Gneralized Label only for new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, ODU3e1, ODU3e2, ODUflex and ODU4).=20 draft-ceccarellifuxh is only a supplement of RFC4328.=20 How can we used RFC4328 and draft-zhang ? =20 Any way, if we need to update an previous RFC, we should assume that it has been deployed, not asking if someone did or not.=20 =09 (2) Do you really want to remove NMC from the Traffic Parameters?=20 If you do that, I think we have to abandon RFC4328.=20 =09 (3) The compatibility consideration in draft-zhang.=20 We don't think the extensions in draft-zhang can coexist with RFC4328.=20 You point out "we can just do some translation or mapping in the new nodes".=20 But before the translation or mapping, you have to know the Generalized Label Format. =20 We concern about: =20 i) How does one node know the Generalized Label format, especially for ODU1, ODU2 and ODU3 base on your solution? =20 It may depend on the capability of the adjacent network element.=20 ii) But how can the control plane know the adjacent network element's capability without discovery mechanism?=20 You should know that GMPLS signaling extension should be independent on the discovery mechanism and the configuration of management plane.=20 iii) The control plane don't need to know the G.709(2003/03) or G.709 Amendment3 network element?=20 =20 In a word, we think it can not do the translation and mapping. So we can not get the compatibility with RFC4328 in draft-zhang.=20 =09 (4) The Generalized Label in draft-zhang=20 - managing a variable length label could be a mess.=20 - draft-zhang uses a first part of the label which has fixed values and then a variable number of bit that is the bitmap.=20 The bitmap can be long from 0 to 80 bits depending on the signal type.=20 - the value of the bitmap is not independent but depends on the values of two previous fields (ODUk and ODUj) and becomes reserved in case of K=3DJ=20 - a bitmap label have not been used nor in SDH and not in WSON where a fixed label (4 bytes) is used.=20 =09 Xihua Fu=20 ZTE=20 =09 =09 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp End of CCAMP Digest, Vol 14, Issue 26 ************************************* From diego.caviglia@ericsson.com Thu Aug 6 03:20:12 2009 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 591253A6CC4 for ; Thu, 6 Aug 2009 03:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 Bvo1wdUnSmit for ; Thu, 6 Aug 2009 03:20:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E04DA3A6C24 for ; Thu, 6 Aug 2009 03:18:59 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-78-4a7aae155c61 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 03.64.15141.51EAA7A4; Thu, 6 Aug 2009 12:19:01 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:19:01 +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_01CA167F.50E79ABF" Date: Thu, 6 Aug 2009 12:15:42 +0200 Message-ID: In-Reply-To: <200908042202560621383@mail.ritt.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Discussion about the GMPLS Signaling Extension thread-index: AcoVDEsBs1KpbiS5SxWW1hJ/AeJ/4ABcbsNw References: , <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> From: "Diego Caviglia" To: "zhangguoying" , "Jin, Lizhong (NSN - CN/Shanghai)" , X-OriginalArrivalTime: 06 Aug 2009 10:19:01.0125 (UTC) FILETIME=[5120EB50:01CA167F] X-Brightmail-Tracker: AAAAAA== Cc: xuyunbin@mail.ritt.com.cn Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 06 Aug 2009 10:20:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA167F.50E79ABF Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi All, I agree with Zhang, we need to face out if there 4328 = implementation up and running in real networks that can be impacted by a = major label format change, I think this can be managed by Lou and Deb. =20 >From technical point of view, even if I=A1=AFm one of the authors of the = draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt, I have to = admit that the solution proposed by Fatai is a good one and I have no = problem in working with him to harmonize the two documents to provide an = unified ID. =20 Hope this helps in speeding up this work =20 BR =20 D =20 =20 =20 __________________________________________ Diego Caviglia Strategic Product Manager Broadband Networks, PL Broadband Optical Network=20 Ericsson Telecomunicazioni S.p.A. (TEI) Via A. Negrone 1/A Office: +39 010 600 = 3736 16153, Genova, Italy Fax: +39 010 600 3577 Block E Level 4 Mobile: +39 335 = 7181762 www.ericsson.com = diego.caviglia@ericsson.com This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. ________________________________ ________________________________ From: zhangguoying [mailto:zhangguoying@mail.ritt.com.cn]=20 Sent: marted=A8=AC 4 agosto 2009 16.03 To: Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org Cc: zhangfatai@huawei.com; fu.xihua@zte.com.cn; dbrungard@att.com; = lberger@labn.net; Diego Caviglia; Daniele Ceccarelli; = xuyunbin@mail.ritt.com.cn Subject: Re: RE: Discussion about the GMPLS Signaling Extension =20 Hi all, =20 As many experts have explained, the label encoding with bit map in = draft-zhang is surely a better way to achieve extensibility and = scalability of OTN lable. =20 =20 The main issue that bit map label format might have is the backword = compatibility. I think we might need to start an survey among the OTN = service providers in the mailing list, and see if there are any OTN = networks deployed with GMPLS RFC4328 lable format.=20 =20 If there're no real deployment, we don't need to consider the = compatability problem; =20 If there're some deployment, compatability problem need to be solved . = An easy way might be adding an label version bit in the label format, or = some other solutions may be searched out. =20 =20 best regards, Guoying Zhang =20 =20 =20 2009-08-04=20 ________________________________ zhangguoying=20 ________________________________ =B7=A2=BC=FE=C8=CB=A3=BA Jin, Lizhong (NSN - CN/Shanghai)=20 =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-08-04 13:34:24=20 =CA=D5=BC=FE=C8=CB=A3=BA ccamp@ietf.org=20 =B3=AD=CB=CD=A3=BA zhangfatai@huawei.com; fu.xihua@zte.com.cn; = dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com; = daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; = xuyunbin@mail.ritt.com.cn=20 =D6=F7=CC=E2=A3=BA RE: Discussion about the GMPLS Signaling Extension=20 Hi Fatai and all: I agree with the issues of excessive number of labels if using the same label concept of RFC4328. By using bit map for label encoding is a good idea. And from my understanding, draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit map idea if Fatai agree. =20 For backward compatibility, we can not assume that RFC4328 is not deployed unless we can provide some kind of survey report. So currently the right assumption is that RFC4328 has been deployed, and backward compatibity should be considered. =20 Best Regards Lizhong Jin =20 ---------------------------------------------------------------------- =20 Message: 1 Date: Thu, 30 Jul 2009 11:33:56 +0200 From: "BELOTTI SERGIO" Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension forEvolutive OTN To: "Fatai" , , , , , , , Cc: ccamp@ietf.org Message-ID: <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com >=20 Content-Type: text/plain; charset=3D"iso-8859-1" =20 Dear Fatai and all, =20 =20 =20 We agree on the major points raised by Fatai as general issue to be solved in the context of extension needed to cope with new containers defined in ITU q11 context, in addition to handling ODU multiplexing scenarios in existing OTN. =20 There are two basic points that brings to the need to update the RFC4328 anyway. =20 =20 =20 1) the present RFC does not permit the link based negotiation for time slot allocation . No information about tributary port numbers is present and only in case we have "single layer" , no multiplexing LO -- > HO you can apply . So this is a lack against the original G.709 even without considering G.709 Am3 . =20 =20 =20 2) Scalability: The extension required in the context of new OTN with the introduction of ODU0, ODU4, and above all ODUflex , required a real modifications of the structure of the label to avoid real big size of number of labels to transmit offloading signalling session. Extension based on RFC4328 logic do not scale when ODU-flex is used. Large ODU flex containers will generate =20 an excessive number of labels (in principle up to 80 per link) causing problems with the size of the RSVP-TE message. =20 =20 =20 This two points together call to the need to change something in RFC. =20 Backward compatibility aspects, present in all the drafts, are surely to be considered and if there are single layer systems deployed using RFC4328 this should be grandfathered. =20 =20 =20 Best Regards =20 =20 =20 Sergio =20 =20 =20 =20 =20 Sergio Belotti =20 =20 =20 CTO Optics Division =20 Alcatel-Lucent =20 =20 =20 +39 039 6863033 =20 +39 039 6863590 =20 =20 =20 ________________________________ =20 Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fatai Inviato: mercoled? 29 luglio 2009 18.33 A: fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com; daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn Cc: ccamp@ietf.org Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension forEvolutive OTN =20 =20 =20 Hi all, =20 =20 =20 To support the current verison of G.709, we think the label format defined in RFC4328 need to be re-defined anyway. The new OTN label format should support the whole ODU sets, not only the ODU1, 2, and 3, but also ODU0, ODU4, even ODUFlex. The following three aspects should be considered carefully: =20 =20 =20 1) The extensibility of the label format is the first thing we should consider. With the development of OTN technology, RFC4328 label format style needs to be extended to support the new bitrate ODU (eg. ODU5, 6...). By the end, we may need keep extending the label formats. Managing lots of label format may cause big trouble, so we need one-shot label format for the evolving OTN. =20 =20 =20 =20 2) Scalability is another key issue. RFC4328 style format may result in big size of the total labels, which definitely increase the burden of the signaling. An efficient approach is needed to carry the same label information but with less amount of the data, bitmap style is the right way to go. =20 =20 =20 3) For backward compatibility, if there are no implementations for RFC4328 (or if there are no deployments it is desirable to deprecate even if it is uncomfortable for existing implementations), it is very safe to deprecate the old definition, and an extensible, efficient and scalable solution could be helpful. The label defined in draft-zhang does not overwrite RFC4328, it can allow the old definition to continue to exist. =20 =20 =20 Hope this can clarify your concern. =20 =20 =20 Authors of draft-zhang =20 =20 =20 =20 =20 =20 =20 ----- Original Message -----=20 =20 From: fu.xihua@zte.com.cn=20 =20 To: dbrungard@att.com ; lberger@labn.net ; zhangfatai@huawei.com ; diego.caviglia@ericsson.com ; daniele.ceccarelli@ericsson.com=20 =20 Cc: ccamp@ietf.org=20 =20 Sent: Tuesday, July 28, 2009 5:33 PM =20 Subject: Discussion about the GMPLS Signaling Extension for Evolutive OTN =20 =20 =20 Hi Fatai and All,=20 We have presented the following two document in the CCAMP morning session. But we have no more time to further discuss GMPLS extension for evolutive OTN=20 draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt =20 draft-zhang-ccamp-gmpls-evolving-g709-01.txt =20 We have a couple of comments and questions for the draft-zhang.=20 (1) draft-zhang defined the extensions including what has been done in RFC4328 (i.e., ODU1, ODU2 and ODU3).=20 draft-ceccarellifuxh defined new Gneralized Label only for new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, ODU3e1, ODU3e2, ODUflex and ODU4).=20 draft-ceccarellifuxh is only a supplement of RFC4328.=20 How can we used RFC4328 and draft-zhang ? =20 Any way, if we need to update an previous RFC, we should assume that it has been deployed, not asking if someone did or not.=20 (2) Do you really want to remove NMC from the Traffic Parameters?=20 If you do that, I think we have to abandon RFC4328.=20 (3) The compatibility consideration in draft-zhang.=20 We don't think the extensions in draft-zhang can coexist with RFC4328.=20 You point out "we can just do some translation or mapping in the new nodes".=20 But before the translation or mapping, you have to know the Generalized Label Format. =20 We concern about: =20 i) How does one node know the Generalized Label format, especially for ODU1, ODU2 and ODU3 base on your solution? =20 It may depend on the capability of the adjacent network element.=20 ii) But how can the control plane know the adjacent network element's capability without discovery mechanism?=20 You should know that GMPLS signaling extension should be independent on the discovery mechanism and the configuration of management plane.=20 iii) The control plane don't need to know the G.709(2003/03) or G.709 Amendment3 network element?=20 =20 In a word, we think it can not do the translation and mapping. So we can not get the compatibility with RFC4328 in draft-zhang.=20 (4) The Generalized Label in draft-zhang=20 - managing a variable length label could be a mess.=20 - draft-zhang uses a first part of the label which has fixed values and then a variable number of bit that is the bitmap.=20 The bitmap can be long from 0 to 80 bits depending on the signal type.=20 - the value of the bitmap is not independent but depends on the values of two previous fields (ODUk and ODUj) and becomes reserved in case of K=3DJ=20 - a bitmap label have not been used nor in SDH and not in WSON where a fixed label (4 bytes) is used.=20 Xihua Fu=20 ZTE=20 =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: =20 ------------------------------ =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 =20 End of CCAMP Digest, Vol 14, Issue 26 ************************************* ------_=_NextPart_001_01CA167F.50E79ABF Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = All,

      =     I agree with Zhang, we need = to face out if there 4328 implementation up and running in real networks that = can be impacted by a major label format change, I think this can be managed by = Lou and Deb.

 

From technical point of view, = even if I=A1=AFm one of the authors of the = draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt, I have to admit that the solution proposed by Fatai is a good one and I = have no problem in working with him to harmonize the two documents to provide an unified ID.

 

Hope this helps in speeding up = this work

 

BR

 

D

 

 

 

___________________________________= _______<= /b>

Diego Caviglia

Strategic Product = Manager

Broadband = Networks, PL Broadband Optical = Network 

<= font size=3D1 color=3Dnavy face=3D"Times New Roman">Ericsson Telecomunicazioni S.p.A. = (TEI)

Via A. Negrone = 1/A           &nbs= p;            = ;         Office:  +39 010 600 3736

16153, Genova, = Italy           &n= bsp;           &nb= sp;       Fax: +39 010 600 3577

Block E = Level 4          &= nbsp;           &n= bsp;           &nb= sp;     Mobile: +39 335 7181762

www.ericsson.com   =             &= nbsp;           &n= bsp; diego.caviglia@ericsson.com<= o:p>

This communication is confidential and = intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to = you in error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you.

From: zhangguoying [mailto:zhangguoying@mail.ritt.com.cn]
Sent: marted=A8=AC 4 = agosto 2009 16.03
To: Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org
Cc: = zhangfatai@huawei.com; fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net; Diego = Caviglia; Daniele Ceccarelli; xuyunbin@mail.ritt.com.cn
Subject: Re: RE: = Discussion about the GMPLS Signaling Extension

 

Hi all,

 

As many experts have explained, the label encoding with bit map in = draft-zhang is  surely a better way to = achieve extensibility and scalability of OTN lable.  

 

The main issue that bit map label format might have is the backword compatibility. I think we might need to start an survey among the OTN service providers in the mailing list,  and see if there are any OTN networks deployed with GMPLS RFC4328 lable format.

 

If there're no real deployment, we don't need to consider the = compatability problem;

 

If there're some deployment, compatability problem need to be solved . = An easy way might be adding an label version = bit in the label format, or some other solutions may be searched = out.

 

 

best regards,

Guoying Zhang

 

 

 

2009-08-04 <= /p>

zhangguoying <= /p>

=B7=A2=BC=FE=C8=CB=A3=BA Jin, Lizhong (NSN - CN/Shanghai)

=B7=A2=CB=CD=CA=B1=BC=E4=A3= =BA 2009-08-04  13:34:24

=CA=D5=BC=FE=C8=CB=A3=BA ccamp@ietf.org

=B3=AD=CB=CD=A3=BA zhangfatai@huawei.com; fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com; = daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn =

=D6=F7=CC=E2=A3=BA RE: Discussion about the GMPLS Signaling Extension =

Hi Fatai and&nbs= p;all:

I agree with&nbs= p;the issues of excessive number of labels&= nbsp;if using the same

label concept of=  RFC4328. By using bit map for label&n= bsp;encoding is a good

idea. And from&n= bsp;my understanding,

draft-ceccarellifuxh-ccamp= -gmpls-ext-for-evol-otn-00 can merge this bit

map idea if = ;Fatai agree.

 

For backward com= patibility, we can not assume that RFC4328&= nbsp;is not

deployed unless = we can provide some kind of survey rep= ort. So currently

the right assump= tion is that RFC4328 has been deployed,&nbs= p;and backward

compatibity should&nb= sp;be considered.

 

Best Regards

Lizhong Jin

 

--------------------------= --------------------------------------------

=

 

Message: 1=

Date: Thu, 30&nb= sp;Jul 2009 11:33:56 +0200

From: "BELOTTI&n= bsp;SERGIO"  <Sergio.Belotti@alcatel-lucent.it >

Subject: [CCAMP] = ;R: Discussion about the GMPLS Signaling Ex= tension

forEvolutive OTN=

To: "Fatai"=   <zhangfatai@huawei.com >,  <fu.xihua@zte.com.cn = >,

<dbrungard@att.com >,  <lberger@labn.net >,

<diego.caviglia@ericsso= n.com >,

<daniele.ceccarelli@eri= csson.com >,

<zhangguoying@mail.ritt= .com.cn >,

<xuyunbin@mail.ritt.com= .cn >

Cc: ccamp@ietf.org

Message-ID:

<3F44186D7141E247972EAC= 6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com

> 

Content-Type: text/pl= ain; charset=3D"iso-8859-1"

 

Dear Fatai and&n= bsp;all,

 

 

 

We agree on = ;the major points raised by Fatai as g= eneral issue to be

solved in the&nb= sp;context of extension needed to cope with=  new containers

defined in ITU&n= bsp; q11 context, in addition to handling&n= bsp;ODU multiplexing

scenarios in exi= sting OTN.

 

There are two&nb= sp;basic points that brings to the need&nbs= p;to update the RFC4328

anyway.<= /font>

 

 

 

1) the present&n= bsp;RFC does not permit the link based = ;negotiation  for time

slot allocation = . No information about tributary port numbe= rs is present

and only in = ;case we have "single layer" , no=  multiplexing LO -- > HO you

can apply . = ;So this is a lack against the origina= l G.709 even without

considering G.709&nbs= p;Am3 .

 

 

 

2) Scalability: = The extension required in the context of&nb= sp;new OTN with

the introduction = ;of ODU0, ODU4, and above all ODUflex = , required a real

modifications of = ;the structure of the label to avoid r= eal big size of

number of labels=  to transmit offloading signalling session. = ;Extension

based on RFC4328=  logic do not scale when ODU-flex is&n= bsp;used. Large ODU

flex containers = will generate

 

an excessive num= ber of labels (in principle up to 80&n= bsp;per link) causing

problems with th= e size of the RSVP-TE message.=

 

 

 

This two points&= nbsp;together call to the need to change&nb= sp;something in RFC.

 

Backward compatibilit= y aspects, present in all the drafts, = are surely to

be considered an= d if there are single layer systems de= ployed using

RFC4328 this sho= uld be grandfathered.

 

 

 

Best Regards

 

 

 

Sergio

 

 

 

 

 

Sergio Belotti

 

 

 

CTO Optics Divis= ion

 

Alcatel-Lucent<= /span>

 

 

 

+39 039 6863033<= o:p>

 

+39 039 6863590<= o:p>

 

 

 

__________________________= ______

 

Da: ccamp-bounces@iet= f.org [mailto:ccamp-bounces@ietf.org] Per conto di

Fatai

Inviato: mercoled?&nb= sp;29 luglio 2009 18.33

A: fu.xihua@zte.com.c= n; dbrungard@att.com; lberger@labn.net;

diego.caviglia@ericsson.co= m; daniele.ceccarelli@ericsson.com;

zhangguoying@mail.ritt.com= .cn; xuyunbin@mail.ritt.com.cn

Cc: ccamp@ietf.org

Oggetto: Re: [CC= AMP] Discussion about the GMPLS Signaling E= xtension

forEvolutive OTN=

 

 

 

Hi all,

 

 

 

To support the&n= bsp;current verison of G.709, we think the&= nbsp;label format

defined in RFC43= 28 need to be re-defined anyway. The n= ew OTN label

format should su= pport the whole ODU sets, not only the=  ODU1, 2, and 3,

but also ODU0,&n= bsp;ODU4, even ODUFlex. The following three = ;aspects should be

considered carefully:=

 

 

 

1) The extensibi= lity of the label format is the first&= nbsp;thing we should

consider. With t= he development of OTN technology, RFC4328 l= abel format

style needs to&n= bsp;be extended to support the new bitrate&= nbsp;ODU (eg. ODU5,

6...). By the&nb= sp;end, we may need keep extending the = ;label formats.

Managing lots of=  label format may cause big trouble, s= o we need one-shot

label format for=  the evolving OTN.  

 

 

 

2) Scalability i= s another key issue. RFC4328 style format&n= bsp;may result in

big size of = ;the total labels, which definitely increase&nbs= p;the burden of

the signaling. A= n efficient approach is needed to carry&nbs= p;the same label

information but = with less amount of the data, bitmap s= tyle is the right

way to go.<= /o:p>

 

 

 

3) For backward&= nbsp;compatibility, if there are no implementati= ons for

RFC4328 (or if&n= bsp;there are no deployments it is desirabl= e to deprecate

even if it = is uncomfortable for existing implementations), = it is very

safe to deprecat= e the old definition, and an extensible,&nb= sp;efficient and

scalable solution&nbs= p;could be helpful. The label defined in&nb= sp;draft-zhang

does not overwri= te RFC4328, it can allow the old defin= ition to continue

to exist.<= /span>

 

 

 

Hope this can&nb= sp;clarify your concern.

 

 

 

Authors of draft= -zhang

 

 

 

 

 

 

 

----- Original M= essage ----- 

 

From: fu.xihua@zte.co= m.cn 

 

To: dbrungard@att.com=  ; lberger@labn.net ; zhangfatai@huawei.com

; diego.caviglia@eric= sson.com ; daniele.ceccarelli@ericsson.com 

 

Cc: ccamp@ietf.org&nb= sp;

 

Sent: Tuesday, J= uly 28, 2009 5:33 PM

 

Subject: Discussion&n= bsp;about the GMPLS Signaling Extension for=

Evolutive OTN

 

 

 

Hi Fatai and&nbs= p;All, 

We have presente= d the following two document  in the&n= bsp;CCAMP

morning session. = ;But we have no more time to further&n= bsp;discuss GMPLS

extension for ev= olutive OTN 

draft-ceccarellifuxh-ccamp= -gmpls-ext-for-evol-otn-00.txt

l-otn-00 >  

draft-zhang-ccamp-gmpls-ev= olving-g709-01.txt

>  

We have a c= ouple of comments and questions for the&nbs= p;draft-zhang. 

(1) draft-zhang = defined the extensions including what has b= een

done in RFC4328&= nbsp;(i.e., ODU1, ODU2 and ODU3). 

    &n= bsp; draft-ceccarellifuxh defined new Gneralized = ;Label only for

new application = (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G&= nbsp;ODU3, ODU2e,

ODU3e1, ODU3e2, = ODUflex and ODU4). 

    &n= bsp; draft-ceccarellifuxh is only a supplement&n= bsp;of RFC4328. 

    &n= bsp; How can we used RFC4328 and draft= -zhang ?       =

    &n= bsp; Any way, if we need to update&nbs= p;an previous RFC, we should=

assume that it&n= bsp;has been deployed, not asking if someon= e did or not. 

(2) Do you = really want to remove NMC from the Tra= ffic

Parameters? 

    &n= bsp; If you do that, I think we h= ave to abandon RFC4328. 

=

(3) The compatib= ility consideration in draft-zhang. 

   We = don't think the extensions in draft-zhang c= an coexist with

RFC4328. <= /span>

   You = ;point out "we can just do some t= ranslation or mapping in

the new nodes&qu= ot;. 

   But = ;before the translation or mapping, you hav= e to know the

Generalized Label&nbs= p;Format.   

   We = concern about:   

   i) =  How does one node know the Generalize= d Label format,

especially for O= DU1, ODU2 and ODU3 base on your soluti= on?     

    &n= bsp;   It may depend on the capab= ility of the adjacent network

element. <= /span>

   ii) = ;But how can the control plane know th= e adjacent network

element's capability&= nbsp;without discovery mechanism? 

    &n= bsp;  You should know that GMPLS signa= ling extension should be

independent on t= he discovery mechanism and the configuration&nbs= p;of

management plane.&nbs= p;

   iii)&nbs= p;The control plane don't need to know = ;the G.709(2003/03)

or G.709 Amendme= nt3 network element? 

    &n= bsp; 

    &n= bsp;In a word, we think it can not&nbs= p;do the translation and

mapping. So we&n= bsp;can not get the compatibility with RFC4= 328 in

draft-zhang. 

 (4) The Ge= neralized Label in draft-zhang 

    -&= nbsp;managing a variable length label could = ;be a mess. 

    -&= nbsp;draft-zhang uses a first part of the&n= bsp;label which has fixed

values and then&= nbsp;a variable number of bit that is = the bitmap. 

    &n= bsp;  The bitmap can be long from = ;0 to 80 bits depending on the

signal type. 

    -&= nbsp;the value of the bitmap is not in= dependent but depends on

the values of&nb= sp;two previous fields (ODUk and ODUj) and&= nbsp;becomes reserved

in case of = K=3DJ 

    -&= nbsp;a bitmap label have not been used = ;nor in SDH and not in<= /p>

WSON where a&nbs= p;fixed label (4 bytes) is used. 

Xihua Fu 

ZTE 

 

-------------- next&n= bsp;part --------------

An HTML attachme= nt was scrubbed...

URL:

4/attachment.htm >

 

--------------------------= ----

 

__________________________= _____________________

CCAMP mailing li= st

CCAMP@ietf.org<= /span>

https://www.ietf.org/mailm= an/listinfo/ccamp

 

 

End of CCAMP&nbs= p;Digest, Vol 14, Issue 26

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

------_=_NextPart_001_01CA167F.50E79ABF-- From daniel@olddog.co.uk Thu Aug 6 09:40:48 2009 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 0D4803A6DFF for ; Thu, 6 Aug 2009 09:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_20=-0.74, 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 NFpOjlP9Xttk for ; Thu, 6 Aug 2009 09:40:45 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 197293A6E3C for ; Thu, 6 Aug 2009 09:40:30 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n76GeI9s009762; Thu, 6 Aug 2009 17:40:18 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n76GeHUe009753; Thu, 6 Aug 2009 17:40:18 +0100 From: "Daniel King" To: References: <015f01ca106a$329035d0$14168182@zhang> <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com> Date: Thu, 6 Aug 2009 17:40:18 +0100 Message-ID: <003501ca16b4$958cd6c0$c0a68440$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoQaj8gWxIxSHM9QgaQCD2mljYSnwAia/AgAW/aczA= Content-Language: en-gb Subject: [CCAMP] IETF-75 Draft CCAMP Minutes 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, 06 Aug 2009 16:40:48 -0000 Hello CCAMP'rs, The draft minutes for our IETF-75 meeting have been uploaded to: http://www.ietf.org/proceedings/75/minutes/ccamp.html Please suggest any corrections by August 21, 2009. Br, Dan. From gregb@grotto-networking.com Fri Aug 7 09:54:41 2009 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 0018F28C195 for ; Fri, 7 Aug 2009 09:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.748, 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 RsBVDfUZsB5e for ; Fri, 7 Aug 2009 09:54:39 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 7B11928C1F7 for ; Fri, 7 Aug 2009 09:54:17 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n77Grln4093637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Aug 2009 09:53:48 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4A7C5C1B.2060506@grotto-networking.com> Date: Fri, 07 Aug 2009 09:53:47 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Giovanni Martinelli References: <4A6FDE8D.8030802@grotto-networking.com> <4A736B58.60302@cisco.com> In-Reply-To: <4A736B58.60302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] WSON Impairment scenarios -- control plane perspective... 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, 07 Aug 2009 16:54:41 -0000 Hi Giovanni, I'm not sure about the terminology either. At IETF we tent use the term opaque, at ITU-T SG15 Q6 they use the term "black links". Whatever we end up using we need to define it clearly. See comments on your comments below. Cheers Greg Giovanni Martinelli wrote: > Hi Greg, > > thx for the text, very useful. Few initial comments hoping discussion > will continue with other contribution as well. > > first a terminology consideration about opaque, Don't have a better > suggestion right now but not sure the term usage. "Opaque" is the > path validation procedure (if any) respect to the control plane? > > plus few others comments inline > > > > Greg Bernstein wrote: >> Hi folks, there seemed to be some questions about where we could get >> started with WSON impairments. On reviewing the Impairment Framework >> draft, it seems like we've got a lot of bases covered but we aren't >> explicit about one could get started dealing with optical impairments. >> >> Below is a short analysis with somewhat "loose" language. Some of >> this could potentially be useful in a liaison to ITU-T Q6. >> >> Comments welcome. >> >> Greg B. >> >> >> *Impairment Estimation Categories and the Control Plane* >> >> >> Opaque WSON with respect to Impairments >> >> In this case we are given a list of qualified paths between a desired >> source and destination of a connection. These paths may come with >> wavelength restrictions due to impairments (not related to wavelength >> availability in RWA process). >> >> We do not know anything about how these viable paths are computed. We >> don't know and shouldn't care if the impairments are linear or >> non-linear. >> >> We are assured that if we select one of these paths and assign a >> wavelength to it then the establishment of this connection will not >> impact previously established connections in the network. >> Example usage: a single vendor supplies WDM line systems and ROADMs. >> We wish to use a GMPLS control plane and perhaps PCE based >> optimization but not all paths through the network are viable due to >> impairments. >> >> ITU-T Q6 implications: My guess it that the Q6 folks would not care >> about this case since this doesn't really call for standardization of >> impairment parameters or procedures. >> >> CCAMP implications: This seems like a very practical case for the >> control plane. We would only want to standardize the way in which we >> obtain the list of qualified paths. */No impairment information model >> is needed here/*. An architecture reflecting this option is already >> in the Impairment Framework draft. >> > Agree with all the above. The only point is that probably the fact of > having a set of qualified path does not preclude the need of having > impairment considerations as well (sort of mixed solutions). > > I mean, your text above does not preclude it but I want just to make > the point clear. --> I'm not quite sure of your "mixed" scenario here. How would a "mixed scenario" work? > > >> Partially Opaque WSON >> >> In this case the impairment behavior of certain elements of the WSON >> can be suitably modeled via standardized techniques, e.g., G.680 >> while other parts of the WSON are not. The entity responsible for >> these other parts of the WSON imports the characteristics of these >> "open" elements and uses them as part of a viable path computation >> process, the details of which are opaque to the control plane. >> >> We are assured that if we select one of these paths and assign a >> wavelength to it then the establishment of this connection will not >> impact previously established connections in the network. >> > I would apply here the same as below "this is beyond a purview of a > standard organization to specify". --> There are some aspects of this scenario that are amenable to standards other are not. There is can be an info model for the portion modeled by standards, along with a standard way of conveying that information to the "opaque system" that performs the computations. > >> Example usage: The characteristics of the WDM line systems are not >> specified, but well characterized ROADMs are used in the WSON. The >> WDM line system vendor uses these characteristics in its >> internal/proprietary viable path computations. >> >> Q6 and CCAMP implications: here we would be using a standardize >> information model for the "open" WSON network elements. How the other >> "opaque" network elements are characterized and how viable path >> computation is carried out is out of scope of either SDO. Such an >> approach takes advantage of standardized impairment models where it can. >> > just to clarify "standardized impairment model", are you referring to > G.680 or something else? --> Yes, G.680 and related specifications. Currently G.680 models ROADMs but not line systems so this scenario is compatible with G.680 as it stands today. > > >> Implications for CCAMP would be an impairment information model and >> an interface for requesting/receiving qualified paths. An >> architecture that can support this case is already contained in the >> WSON impairment framework draft. >> >> >> Linearly Approximated Open WSON Impairment Model >> >> In this case the impairment aspects of the WSON can be well >> approximated by standardized (or to be standardized) "linear" models >> such as those found in G.680. From these models the viability of >> paths can be evaluated. >> >> We are assured that if we select one of these paths and assign a >> wavelength to it then the establishment of this connection will not >> impact previously established connections in the network. >> Implications for Q6: Current impairment models such as recent version >> of G.680 do not include models for WDM line systems. >> > why this? Isn't a line system a de-generated case of an ROADM (1 > ingress, 1 egress)? ---> Probably better directed at Q6 than me. I pretty much agree with you. I just know what the current version of G.680 says :-( . > > thx > G > >> Implications for CCAMP: An impairment information model is needed. >> Distributed impairment validation (via signaling) could be possible. >> >> General comments: it would seem to be the responsibility of the WSON >> network designer to insure that the network is operating in a >> "region" where these linear approximations for impairments are valid. >> This seems beyond the purview of a standards organization to specify. >> >> An architecture to accommodate this case is contained in the WSON >> impairment framework draft. >> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From root@core3.amsl.com Mon Aug 10 15:15:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A9743A6AF1; Mon, 10 Aug 2009 15:15: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: <20090810221501.4A9743A6AF1@core3.amsl.com> Date: Mon, 10 Aug 2009 15:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-07.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, 10 Aug 2009 22:15:01 -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 : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Le Roux Filename : draft-ietf-ccamp-gmpls-mln-extensions-07.txt Pages : 22 Date : 2009-8-10 There are specific requirements for the support of networks comprising Label Switching Routers (LSR) participating in different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi- Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-07.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-mln-extensions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-8-10151135.I-D@ietf.org> --NextPart-- From lizhong.jin@nsn.com Tue Aug 11 19:41:14 2009 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 BBE823A67A3 for ; Tue, 11 Aug 2009 19:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 HVa5A8J4v8N0 for ; Tue, 11 Aug 2009 19:41:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4DD733A6782 for ; Tue, 11 Aug 2009 19:41:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7C2dHNl028337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 04:39:17 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7C2dG9h014566; Wed, 12 Aug 2009 04:39:16 +0200 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 04:39:16 +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_01CA1AF6.11989E38" Date: Wed, 12 Aug 2009 10:39:06 +0800 Message-ID: <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> In-Reply-To: <200908042202560621383@mail.ritt.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Discussion about the GMPLS Signaling Extension Thread-Index: AcoVDE7r/XREM+C5QNShZ+v6Ch70egF6KWug References: , <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> From: "Jin, Lizhong (NSN - CN/Shanghai)" To: "ext zhangguoying" , X-OriginalArrivalTime: 12 Aug 2009 02:39:16.0679 (UTC) FILETIME=[15FEFD70:01CA1AF6] Cc: xuyunbin@mail.ritt.com.cn Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 12 Aug 2009 02:41:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1AF6.11989E38 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all: What I need to clarify from my side is that abandoning a RFC is not = preferred in any case. If we can develop a backward solution by merging = draft-ceccarellifuxh and draft-zhang, why don't we go in this way. =20 BR Lizhong Jin ________________________________ From: ext zhangguoying [mailto:zhangguoying@mail.ritt.com.cn]=20 Sent: Tuesday, August 04, 2009 22:03 To: Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org Cc: zhangfatai@huawei.com; fu.xihua@zte.com.cn; dbrungard@att.com; = lberger@labn.net; diego.caviglia@ericsson.com; = daniele.ceccarelli@ericsson.com; xuyunbin@mail.ritt.com.cn Subject: Re: RE: Discussion about the GMPLS Signaling Extension Hi all, =20 As many experts have explained, the label encoding with bit map in = draft-zhang is surely a better way to achieve extensibility and = scalability of OTN lable. =20 =20 The main issue that bit map label format might have is the backword = compatibility. I think we might need to start an survey among the OTN = service providers in the mailing list, and see if there are any OTN = networks deployed with GMPLS RFC4328 lable format.=20 =20 If there're no real deployment, we don't need to consider the = compatability problem; =20 If there're some deployment, compatability problem need to be solved . = An easy way might be adding an label version bit in the label format, or = some other solutions may be searched out. =20 =20 best regards, Guoying Zhang =20 =20 =20 2009-08-04=20 ________________________________ zhangguoying=20 ________________________________ =B7=A2=BC=FE=C8=CB=A3=BA Jin, Lizhong (NSN - CN/Shanghai)=20 =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-08-04 13:34:24=20 =CA=D5=BC=FE=C8=CB=A3=BA ccamp@ietf.org=20 =B3=AD=CB=CD=A3=BA zhangfatai@huawei.com; fu.xihua@zte.com.cn; = dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com; = daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; = xuyunbin@mail.ritt.com.cn=20 =D6=F7=CC=E2=A3=BA RE: Discussion about the GMPLS Signaling Extension=20 Hi Fatai and all: I agree with the issues of excessive number of labels if using the same label concept of RFC4328. By using bit map for label encoding is a good idea. And from my understanding, draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit map idea if Fatai agree. =20 For backward compatibility, we can not assume that RFC4328 is not deployed unless we can provide some kind of survey report. So currently the right assumption is that RFC4328 has been deployed, and backward compatibity should be considered. =20 Best Regards Lizhong Jin =20 ---------------------------------------------------------------------- =20 Message: 1 Date: Thu, 30 Jul 2009 11:33:56 +0200 From: "BELOTTI SERGIO" Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension forEvolutive OTN To: "Fatai" , , , , , , , Cc: ccamp@ietf.org Message-ID: <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com > Content-Type: text/plain; charset=3D"iso-8859-1" =20 Dear Fatai and all, =20 =20 =20 We agree on the major points raised by Fatai as general issue to be solved in the context of extension needed to cope with new containers defined in ITU q11 context, in addition to handling ODU multiplexing scenarios in existing OTN. =20 There are two basic points that brings to the need to update the RFC4328 anyway. =20 =20 =20 1) the present RFC does not permit the link based negotiation for time slot allocation . No information about tributary port numbers is present and only in case we have "single layer" , no multiplexing LO -- > HO you can apply . So this is a lack against the original G.709 even without considering G.709 Am3 . =20 =20 =20 2) Scalability: The extension required in the context of new OTN with the introduction of ODU0, ODU4, and above all ODUflex , required a real modifications of the structure of the label to avoid real big size of number of labels to transmit offloading signalling session. Extension based on RFC4328 logic do not scale when ODU-flex is used. Large ODU flex containers will generate =20 an excessive number of labels (in principle up to 80 per link) causing problems with the size of the RSVP-TE message. =20 =20 =20 This two points together call to the need to change something in RFC. =20 Backward compatibility aspects, present in all the drafts, are surely to be considered and if there are single layer systems deployed using RFC4328 this should be grandfathered. =20 =20 =20 Best Regards =20 =20 =20 Sergio =20 =20 =20 =20 =20 Sergio Belotti =20 =20 =20 CTO Optics Division =20 Alcatel-Lucent =20 =20 =20 +39 039 6863033 =20 +39 039 6863590 =20 =20 =20 ________________________________ =20 Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fatai Inviato: mercoled? 29 luglio 2009 18.33 A: fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com; daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn Cc: ccamp@ietf.org Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension forEvolutive OTN =20 =20 =20 Hi all, =20 =20 =20 To support the current verison of G.709, we think the label format defined in RFC4328 need to be re-defined anyway. The new OTN label format should support the whole ODU sets, not only the ODU1, 2, and 3, but also ODU0, ODU4, even ODUFlex. The following three aspects should be considered carefully: =20 =20 =20 1) The extensibility of the label format is the first thing we should consider. With the development of OTN technology, RFC4328 label format style needs to be extended to support the new bitrate ODU (eg. ODU5, 6...). By the end, we may need keep extending the label formats. Managing lots of label format may cause big trouble, so we need one-shot label format for the evolving OTN. =20 =20 =20 =20 2) Scalability is another key issue. RFC4328 style format may result in big size of the total labels, which definitely increase the burden of the signaling. An efficient approach is needed to carry the same label information but with less amount of the data, bitmap style is the right way to go. =20 =20 =20 3) For backward compatibility, if there are no implementations for RFC4328 (or if there are no deployments it is desirable to deprecate even if it is uncomfortable for existing implementations), it is very safe to deprecate the old definition, and an extensible, efficient and scalable solution could be helpful. The label defined in draft-zhang does not overwrite RFC4328, it can allow the old definition to continue to exist. =20 =20 =20 Hope this can clarify your concern. =20 =20 =20 Authors of draft-zhang =20 =20 =20 =20 =20 =20 =20 ----- Original Message -----=20 =20 From: fu.xihua@zte.com.cn=20 =20 To: dbrungard@att.com ; lberger@labn.net ; zhangfatai@huawei.com ; diego.caviglia@ericsson.com ; daniele.ceccarelli@ericsson.com=20 =20 Cc: ccamp@ietf.org=20 =20 Sent: Tuesday, July 28, 2009 5:33 PM =20 Subject: Discussion about the GMPLS Signaling Extension for Evolutive OTN =20 =20 =20 Hi Fatai and All,=20 We have presented the following two document in the CCAMP morning session. But we have no more time to further discuss GMPLS extension for evolutive OTN=20 draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt =20 draft-zhang-ccamp-gmpls-evolving-g709-01.txt =20 We have a couple of comments and questions for the draft-zhang.=20 (1) draft-zhang defined the extensions including what has been done in RFC4328 (i.e., ODU1, ODU2 and ODU3).=20 draft-ceccarellifuxh defined new Gneralized Label only for new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, ODU3e1, ODU3e2, ODUflex and ODU4).=20 draft-ceccarellifuxh is only a supplement of RFC4328.=20 How can we used RFC4328 and draft-zhang ? =20 Any way, if we need to update an previous RFC, we should assume that it has been deployed, not asking if someone did or not.=20 (2) Do you really want to remove NMC from the Traffic Parameters?=20 If you do that, I think we have to abandon RFC4328.=20 (3) The compatibility consideration in draft-zhang.=20 We don't think the extensions in draft-zhang can coexist with RFC4328.=20 You point out "we can just do some translation or mapping in the new nodes".=20 But before the translation or mapping, you have to know the Generalized Label Format. =20 We concern about: =20 i) How does one node know the Generalized Label format, especially for ODU1, ODU2 and ODU3 base on your solution? =20 It may depend on the capability of the adjacent network element.=20 ii) But how can the control plane know the adjacent network element's capability without discovery mechanism?=20 You should know that GMPLS signaling extension should be independent on the discovery mechanism and the configuration of management plane.=20 iii) The control plane don't need to know the G.709(2003/03) or G.709 Amendment3 network element?=20 =20 In a word, we think it can not do the translation and mapping. So we can not get the compatibility with RFC4328 in draft-zhang.=20 (4) The Generalized Label in draft-zhang=20 - managing a variable length label could be a mess.=20 - draft-zhang uses a first part of the label which has fixed values and then a variable number of bit that is the bitmap.=20 The bitmap can be long from 0 to 80 bits depending on the signal type.=20 - the value of the bitmap is not independent but depends on the values of two previous fields (ODUk and ODUj) and becomes reserved in case of K=3DJ=20 - a bitmap label have not been used nor in SDH and not in WSON where a fixed label (4 bytes) is used.=20 Xihua Fu=20 ZTE=20 =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: =20 ------------------------------ =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 =20 End of CCAMP Digest, Vol 14, Issue 26 ************************************* ------_=_NextPart_001_01CA1AF6.11989E38 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi=20 all:
What I need to clarify from my = side is=20 that abandoning a RFC is not preferred in any case. If we can develop a = backward=20 solution by merging draft-ceccarellifuxh and draft-zhang, why don't we = go in=20 this way.
 
BR
Lizhong Jin

From: ext zhangguoying=20 [mailto:zhangguoying@mail.ritt.com.cn]
Sent: Tuesday, August = 04, 2009=20 22:03
To: Jin, Lizhong (NSN - CN/Shanghai);=20 ccamp@ietf.org
Cc: zhangfatai@huawei.com; fu.xihua@zte.com.cn; = dbrungard@att.com; lberger@labn.net; diego.caviglia@ericsson.com;=20 daniele.ceccarelli@ericsson.com; = xuyunbin@mail.ritt.com.cn
Subject:=20 Re: RE: Discussion about the GMPLS Signaling = Extension

Hi all,
 
As many experts have explained, the label = encoding with=20 bit map in draft-zhang is  surely a better way to=20 achieve extensibility and scalability of OTN=20 lable.  
 
The main = issue that bit=20 map label format might have is the backword=20 compatibility. I think we might need to start an = survey=20 among the OTN service providers in the mailing list,  and see if = there are=20 any OTN networks deployed with GMPLS RFC4328 lable format. =
 
If there're no real = deployment,=20 we don't need to consider the compatability problem;
 
If=20 there're some deployment, compatability problem need to be solved . = An easy=20 way might be adding an label version bit in the = label=20 format, or some other solutions may be searched = out.
 
 
best regards,
Guoying Zhang
 
 
 
2009-08-04
zhangguoying=20
=B7=A2=BC=FE=C8=CB=A3=BA Jin, = Lizhong (NSN - CN/Shanghai)=20
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA = 2009-08-04  13:34:24=20
=CA=D5=BC=FE=C8=CB=A3=BA = ccamp@ietf.org
=B3=AD=CB=CD=A3=BA = zhangfatai@huawei.com;=20 fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net;=20 diego.caviglia@ericsson.com; daniele.ceccarelli@ericsson.com;=20 zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn
=D6=F7=CC=E2=A3=BA RE: = Discussion about the GMPLS=20 Signaling Extension
Hi Fatai and all:
I agree with the issues of excessive&n= bsp;number of labels if using the same
label concept of RFC4328. By using bit=  map for label encoding is a good
idea. And from my understanding,
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can m= erge this bit
map idea if Fatai agree.
 
For backward compatibility, we can not = ;assume that RFC4328 is not
deployed unless we can provide some ki= nd of survey report. So currently
the right assumption is that RFC4328 h= as been deployed, and backward
compatibity should be considered.
 
Best Regards
Lizhong Jin
 
--------------------------------------------------------------------= --
 
Message: 1
Date: Thu, 30 Jul 2009 11:33:56 +0200<= /DIV>
From: "BELOTTI SERGIO"  = <Sergio.Belotti@alcatel-lucent.it=20 >
Subject: [CCAMP] R: Discussion about the&nb= sp;GMPLS Signaling Extension
forEvolutive OTN
To: "Fatai"  <zhangfatai@huawei.com >, =20 <fu.xihua@zte.com.cn >,
<dbrungard@att.com >,  <lberger@labn.net >,
<diego.caviglia@ericsson.com >,
<daniele.ceccarelli@ericsson.com >,
<zhangguoying@mail.ritt.com.cn >,
<xuyunbin@mail.ritt.com.cn >
Cc: ccamp@ietf.org
Message-ID:
<3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alca= tel.com
>
Content-Type: text/plain; charset=3D"iso-8859-1"
 
Dear Fatai and all,
 
 
 
We agree on the major points raised&nb= sp;by Fatai as general issue to be
solved in the context of extension nee= ded to cope with new containers
defined in ITU  q11 context, in a= ddition to handling ODU multiplexing
scenarios in existing OTN.
 
There are two basic points that brings=  to the need to update the RFC4328
anyway.
 
 
 
1) the present RFC does not permit&nbs= p;the link based negotiation  for time
slot allocation . No information about = ;tributary port numbers is present
and only in case we have "single = layer" , no multiplexing LO --=20 > HO you
can apply . So this is a lack&nbs= p;against the original G.709 even without
considering G.709 Am3 .
 
 
 
2) Scalability: The extension required in&n= bsp;the context of new OTN with
the introduction of ODU0, ODU4, and ab= ove all ODUflex , required a real
modifications of the structure of the = label to avoid real big size of
number of labels to transmit offloading&nbs= p;signalling session. Extension
based on RFC4328 logic do not scale&nb= sp;when ODU-flex is used. Large ODU
flex containers will generate
 
an excessive number of labels (in prin= ciple up to 80 per link) causing
problems with the size of the RSVP-TE&= nbsp;message.
 
 
 
This two points together call to the&n= bsp;need to change something in RFC.
 
Backward compatibility aspects, present in = all the drafts, are surely to
be considered and if there are single&= nbsp;layer systems deployed using
RFC4328 this should be grandfathered.
 
 
 
Best Regards
 
 
 
Sergio
 
 
 
 
 
Sergio Belotti
 
 
 
CTO Optics Division
 
Alcatel-Lucent
 
 
 
+39 039 6863033
 
+39 039 6863590
 
 
 
________________________________
 
Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=  Per conto di
Fatai
Inviato: mercoled? 29 luglio 2009 18.33
A: fu.xihua@zte.com.cn; dbrungard@att.com; lberger@la= bn.net;
diego.caviglia@ericsson.com; daniele.ceccarelli@ericsson.com;
zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn
Cc: ccamp@ietf.org
Oggetto: Re: [CCAMP] Discussion about the&n= bsp;GMPLS Signaling Extension
forEvolutive OTN
 
 
 
Hi all,
 
 
 
To support the current verison of G.70= 9, we think the label format
defined in RFC4328 need to be re-defin= ed anyway. The new OTN label
format should support the whole ODU se= ts, not only the ODU1, 2, and 3,
=
but also ODU0, ODU4, even ODUFlex. The=  following three aspects should be
considered carefully:
 
 
 
1) The extensibility of the label form= at is the first thing we should
consider. With the development of OTN = technology, RFC4328 label format
style needs to be extended to support&= nbsp;the new bitrate ODU (eg. ODU5,
6...). By the end, we may need ke= ep extending the label formats.
Managing lots of label format may caus= e big trouble, so we need one-shot
label format for the evolving OTN. &nb= sp;
 
 
 
2) Scalability is another key issue. R= FC4328 style format may result in
big size of the total labels, which&nb= sp;definitely increase the burden of
the signaling. An efficient approach is&nbs= p;needed to carry the same label
information but with less amount of th= e data, bitmap style is the right
way to go.
 
 
 
3) For backward compatibility, if there&nbs= p;are no implementations for
RFC4328 (or if there are no deployment= s it is desirable to deprecate
even if it is uncomfortable for existi= ng implementations), it is very
safe to deprecate the old definition, = and an extensible, efficient and
scalable solution could be helpful. The&nbs= p;label defined in draft-zhang
does not overwrite RFC4328, it can all= ow the old definition to continue
to exist.
 
 
 
Hope this can clarify your concern.
 
 
 
Authors of draft-zhang
 
 
 
 
 
 
 
----- Original Message ----- 
 
From: fu.xihua@zte.com.cn 
 
To: dbrungard@att.com ; lberger@labn.net ; = zhangfatai@huawei.com
; diego.caviglia@ericsson.com ; daniele.ceccarelli@er= icsson.com 
 
Cc: ccamp@ietf.org 
 
Sent: Tuesday, July 28, 2009 5:33 PM
 
Subject: Discussion about the GMPLS Signali= ng Extension for
Evolutive OTN
 
 
 
Hi Fatai and All, 
We have presented the following two do= cument  in the CCAMP
morning session. But we have no more&n= bsp;time to further discuss GMPLS
extension for evolutive OTN 
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt
<http://tools.ietf.org/html/draft-ceccarellifuxh-ccamp-gmpls-ext-f= or-evo
l-otn-00 >  
draft-zhang-ccamp-gmpls-evolving-g709-01.txt
<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-= 01.txt
>  
We have a couple of comments and = questions for the draft-zhang. 
(1) draft-zhang defined the extensions incl= uding what has been
done in RFC4328 (i.e., ODU1, ODU2 and&= nbsp;ODU3). 
      draft-ceccarellifuxh define= d new Gneralized Label only for
new application (i.e., ODU0, 1.25G ODU1,&nb= sp;1.25G ODU2, 1.25G ODU3, ODU2e,
ODU3e1, ODU3e2, ODUflex and ODU4). 
      draft-ceccarellifuxh is&nbs= p;only a supplement of RFC4328. 
      How can we used&n= bsp;RFC4328 and draft-zhang ?     = ;  
      Any way, if we&nb= sp;need to update an previous RFC, we = should
assume that it has been deployed, not&= nbsp;asking if someone did or not. 
(2) Do you really want to remove = NMC from the Traffic
Parameters? 
      If you do that,&n= bsp;I think we have to abandon RFC4328.&nbs= p;
(3) The compatibility consideration in draf= t-zhang. 
   We don't think the extensions&= nbsp;in draft-zhang can coexist with
RFC4328. 
   You point out "we can jus= t do some translation or mapping in
the new nodes". 
   But before the translation or&= nbsp;mapping, you have to know the
Generalized Label Format.   
   We concern about:   
   i)  How does one node&nbs= p;know the Generalized Label format,
especially for ODU1, ODU2 and ODU3 bas= e on your solution?     
        It may dep= end on the capability of the adjacent = network
element. 
   ii) But how can the contr= ol plane know the adjacent network
element's capability without discovery mechanism= ? 
       You should know&= nbsp;that GMPLS signaling extension should be
independent on the discovery mechanism and&= nbsp;the configuration of
management plane. 
   iii) The control plane don't&n= bsp;need to know the G.709(2003/03)
or G.709 Amendment3 network element? 
=
      
     In a word, we thin= k it can not do the translation and
mapping. So we can not get the co= mpatibility with RFC4328 in
draft-zhang. 
 (4) The Generalized Label in draft-zh= ang 
    - managing a variable le= ngth label could be a mess. 
    - draft-zhang uses a fir= st part of the label which has fixed
values and then a variable number of&n= bsp;bit that is the bitmap. 
       The bitmap can&n= bsp;be long from 0 to 80 bits dependin= g on the
signal type. 
    - the value of the = bitmap is not independent but depends on
the values of two previous fields (ODU= k and ODUj) and becomes reserved
in case of K=3DJ 
    - a bitmap label have&nb= sp;not been used nor in SDH and not&nb= sp;in
WSON where a fixed label (4 bytes)&nbs= p;is used. 
Xihua Fu 
ZTE 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/ccamp/attachments/20090730/b= fcec50
4/attachment.htm >
 
------------------------------
 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
 
 
End of CCAMP Digest, Vol 14, Issue&nbs= p;26
*************************************
------_=_NextPart_001_01CA1AF6.11989E38-- From giomarti@cisco.com Wed Aug 12 06:20:35 2009 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 1CEE03A6B7E for ; Wed, 12 Aug 2009 06:20:35 -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 iXj4RAgc+e4e for ; Wed, 12 Aug 2009 06:20:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 491253A6974 for ; Wed, 12 Aug 2009 06:20:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAAKtdgkqQ/uCLe2dsb2JhbACaVgEBFiQGnWiIKzUJkFQFgkyBTYIs X-IronPort-AV: E=Sophos;i="4.43,367,1246838400"; d="scan'208";a="46971144" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Aug 2009 13:19:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7CDJ4qI007170; Wed, 12 Aug 2009 15:19:04 +0200 Received: from [144.254.166.73] (mnza1-dhcp-vl301-144-254-166-73.cisco.com [144.254.166.73]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7CDJ3Ag018414; Wed, 12 Aug 2009 13:19:03 GMT Message-ID: <4A82C14C.1000904@cisco.com> Date: Wed, 12 Aug 2009 15:19:08 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Greg Bernstein References: <4A6FDE8D.8030802@grotto-networking.com> <4A736B58.60302@cisco.com> <4A7C5C1B.2060506@grotto-networking.com> In-Reply-To: <4A7C5C1B.2060506@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7969; t=1250083144; x=1250947144; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20WSON=20Impairment=20scenarios =20--=20control=20plane=20perspective... |Sender:=20; bh=QHfv8Z7TzZ7EuUUosZVQvpYtkvs31a3dbIW4U9t7MIM=; b=Xe/YMZG8rR8qnu+K2qnTtjLdq8F6MkOCIoO7X9H2kCW/HylMYDEJO43ZhY a8SLrFA7Ph6qcdRHVZPYgXmzvQVlJhbT6EkeCkNGzvLxo2u2fo6pRZvybqgf I1cYblEbbp; Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ccamp@ietf.org Subject: Re: [CCAMP] WSON Impairment scenarios -- control plane perspective... 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, 12 Aug 2009 13:20:35 -0000 Hi, thx for your reply Greg Bernstein wrote: > > Hi Giovanni, I'm not sure about the terminology either. At IETF we tent > use the term opaque, at ITU-T SG15 Q6 they use the term "black links". > Whatever we end up using we need to define it clearly. > ok, let see if anyone has comments > See comments on > your comments below. > > Cheers > > Greg > > Giovanni Martinelli wrote: > > Hi Greg, > > > > thx for the text, very useful. Few initial comments hoping discussion > > will continue with other contribution as well. > > > > first a terminology consideration about opaque, Don't have a better > > suggestion right now but not sure the term usage. "Opaque" is the > > path validation procedure (if any) respect to the control plane? > > > > plus few others comments inline > > > > > > > > Greg Bernstein wrote: > >> Hi folks, there seemed to be some questions about where we could get > >> started with WSON impairments. On reviewing the Impairment Framework > >> draft, it seems like we've got a lot of bases covered but we aren't > >> explicit about one could get started dealing with optical impairments. > >> > >> Below is a short analysis with somewhat "loose" language. Some of > >> this could potentially be useful in a liaison to ITU-T Q6. > >> > >> Comments welcome. > >> > >> Greg B. > >> > >> > >> *Impairment Estimation Categories and the Control Plane* > >> > >> > >> Opaque WSON with respect to Impairments > >> > >> In this case we are given a list of qualified paths between a desired > >> source and destination of a connection. These paths may come with > >> wavelength restrictions due to impairments (not related to wavelength > >> availability in RWA process). > >> > >> We do not know anything about how these viable paths are computed. We > >> don't know and shouldn't care if the impairments are linear or > >> non-linear. > >> > >> We are assured that if we select one of these paths and assign a > >> wavelength to it then the establishment of this connection will not > >> impact previously established connections in the network. > >> Example usage: a single vendor supplies WDM line systems and ROADMs. > >> We wish to use a GMPLS control plane and perhaps PCE based > >> optimization but not all paths through the network are viable due to > >> impairments. > >> > >> ITU-T Q6 implications: My guess it that the Q6 folks would not care > >> about this case since this doesn't really call for standardization of > >> impairment parameters or procedures. > >> > >> CCAMP implications: This seems like a very practical case for the > >> control plane. We would only want to standardize the way in which we > >> obtain the list of qualified paths. */No impairment information model > >> is needed here/*. An architecture reflecting this option is already > >> in the Impairment Framework draft. > >> > > Agree with all the above. The only point is that probably the fact of > > having a set of qualified path does not preclude the need of having > > impairment considerations as well (sort of mixed solutions). > > > > I mean, your text above does not preclude it but I want just to make > > the point clear. > --> I'm not quite sure of your "mixed" scenario here. How would a > "mixed scenario" work? > Well in principle yes could work: you have some path fully designed off line and while network evolve you may need to add other lightpath(s). How to deal with this I suppose is a network operator choice and I would not preclude it. > > > > > >> Partially Opaque WSON > >> > >> In this case the impairment behavior of certain elements of the WSON > >> can be suitably modeled via standardized techniques, e.g., G.680 > >> while other parts of the WSON are not. The entity responsible for > >> these other parts of the WSON imports the characteristics of these > >> "open" elements and uses them as part of a viable path computation > >> process, the details of which are opaque to the control plane. > >> > >> We are assured that if we select one of these paths and assign a > >> wavelength to it then the establishment of this connection will not > >> impact previously established connections in the network. > >> > > I would apply here the same as below "this is beyond a purview of a > > standard organization to specify". > --> There are some aspects of this scenario that are amenable to > standards other are not. There is can be an info model for the portion > modeled by standards, along with a standard way of conveying that > information to the "opaque system" that performs the computations. > > > >> Example usage: The characteristics of the WDM line systems are not > >> specified, but well characterized ROADMs are used in the WSON. The > >> WDM line system vendor uses these characteristics in its > >> internal/proprietary viable path computations. > >> > >> Q6 and CCAMP implications: here we would be using a standardize > >> information model for the "open" WSON network elements. How the other > >> "opaque" network elements are characterized and how viable path > >> computation is carried out is out of scope of either SDO. Such an > >> approach takes advantage of standardized impairment models where it > can. > >> > > just to clarify "standardized impairment model", are you referring to > > G.680 or something else? > --> Yes, G.680 and related specifications. Currently G.680 models ROADMs > but not line systems so this scenario is compatible with G.680 as it > stands today. > ok > > > > > > >> Implications for CCAMP would be an impairment information model and > >> an interface for requesting/receiving qualified paths. An > >> architecture that can support this case is already contained in the > >> WSON impairment framework draft. > >> > >> > >> Linearly Approximated Open WSON Impairment Model > >> > >> In this case the impairment aspects of the WSON can be well > >> approximated by standardized (or to be standardized) "linear" models > >> such as those found in G.680. From these models the viability of > >> paths can be evaluated. > >> > >> We are assured that if we select one of these paths and assign a > >> wavelength to it then the establishment of this connection will not > >> impact previously established connections in the network. > >> Implications for Q6: Current impairment models such as recent version > >> of G.680 do not include models for WDM line systems. > >> > > why this? Isn't a line system a de-generated case of an ROADM (1 > > ingress, 1 egress)? > ---> Probably better directed at Q6 than me. I pretty much agree with > you. I just know what the current version of G.680 says :-( . > fair enough, but yes probably worth clarify it with Q6 Cheers G > > > > thx > > G > > > >> Implications for CCAMP: An impairment information model is needed. > >> Distributed impairment validation (via signaling) could be possible. > >> > >> General comments: it would seem to be the responsibility of the WSON > >> network designer to insure that the network is operating in a > >> "region" where these linear approximations for impairments are valid. > >> This seems beyond the purview of a standards organization to specify. > >> > >> An architecture to accommodate this case is contained in the WSON > >> impairment framework draft. > >> > >> > >> -- > >> =================================================== > >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > >> > > > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > From gregb@grotto-networking.com Wed Aug 12 09:58:45 2009 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 705933A6C63 for ; Wed, 12 Aug 2009 09:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.499, 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 QJstMth5UThi for ; Wed, 12 Aug 2009 09:58:44 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id BDBEC3A6C46 for ; Wed, 12 Aug 2009 09:58:44 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n7CGSFUH045065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Aug 2009 09:28:16 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4A82EDA2.5010706@grotto-networking.com> Date: Wed, 12 Aug 2009 09:28:18 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] WSON Impairments liaison to ITU-T Q6? 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, 12 Aug 2009 16:58:45 -0000 Hi Deborah, Lou and CCAMPers interested in WSON and impairments. We had a number of questions come up in Stockholm that probably are better answered by Q6. For example: there are a multitude of optical parameters present in various ITU-T drafts including G.680 is there some reduced essential subset that Q6 would recommend for approximate linear path qualification? On the other side of things we had some discussions on the various roles the control plane can take with respect to impairment (see lengthy CCAMP e-mail from me dated 7/28/2009). Do we need to help the chairs prepare a liaison to Q6? If so what content can we include? Cheers Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From frederick.bedford@gmail.com Thu Aug 13 12:10:08 2009 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 522633A6CBF for ; Thu, 13 Aug 2009 12:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_CHARSET_FARAWAY=2.45] 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 pN83Vzd4bzeG for ; Thu, 13 Aug 2009 12:10:05 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id AFC603A6D07 for ; Thu, 13 Aug 2009 12:10:05 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so251624rvb.49 for ; Thu, 13 Aug 2009 12:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+WOhHUnIjEPlvPA0/JDJKFs6t5Rfz7pPRciPb/kj3us=; b=jZOr/EgIY0vnxw44boyryrSyLfvp4I9RAi/BaxhVfLtme1GdXiyMh6FGMkpwEXPKLg R4GYDl1UjNBCSU2WabHjfVebB9zWEUYJv14j2IjCWK1Bv9Uo4cTnUGKsytxjzIGhdSXk 7YQQLdRvKklN2YBLI4ONXvWrP01LUZcdAZD0Y= 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=DuD0lStHE7+dta6OliLWisFFE9BOZPS/o/l7Jvb8BgswZEB1NQIjW+heDVBXtVTl1U F+v+1oWsfuN1M5GNpXNv8AGYgETEKRZiyOQ8Ve5CiJMkjrt+emEFjdbfUQnRs7ICtbIU 7XZGY0P5tW2J2pdNsq47bTW0tV6r9xRvVIc24= MIME-Version: 1.0 Received: by 10.140.207.2 with SMTP id e2mr643046rvg.58.1250190591201; Thu, 13 Aug 2009 12:09:51 -0700 (PDT) In-Reply-To: <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> References: <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> Date: Fri, 14 Aug 2009 03:09:51 +0800 Message-ID: <26bbdc380908131209x31719bedw6dcd55c1dd47844@mail.gmail.com> From: Frederick Robinson To: "Jin, Lizhong (NSN - CN/Shanghai)" Content-Type: multipart/alternative; boundary=000e0cd250881711ab04710aae05 Cc: ccamp@ietf.org, ext zhangguoying , xuyunbin@mail.ritt.com.cn Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 13 Aug 2009 19:10:08 -0000 --000e0cd250881711ab04710aae05 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi all: I Agree with Lizhong. We took several years to standardize the GMPLS extension for ODU1, ODU2 and ODU3. Technology of OTN is developing. We also need some time to standardize the extension for the new application. We can not forbid vendor/carrier to deploy the OTN based on RFC4328 at any time. We should keep them from waiting for the new extension. Further more, any extension can not completely promise to fit any new application in the future. So we have to deal with it step by step. There is some backward compatibility considerations and solution in draft-ceccarellifuxh. There is also a extensible lable format in draft-zhang. Why should we take a long time to survey it among the OTN service providers. Two documents should be merged a= s soon as possible. Bedford ** 2009/8/12 Jin, Lizhong (NSN - CN/Shanghai) > Hi all: > What I need to clarify from my side is that abandoning a RFC is not > preferred in any case. If we can develop a backward solution by merging > draft-ceccarellifuxh and draft-zhang, why don't we go in this way. > > BR > Lizhong Jin > > ------------------------------ > *From:* ext zhangguoying [mailto:zhangguoying@mail.ritt.com.cn] > *Sent:* Tuesday, August 04, 2009 22:03 > *To:* Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org > *Cc:* zhangfatai@huawei.com; fu.xihua@zte.com.cn; dbrungard@att.com; > lberger@labn.net; diego.caviglia@ericsson.com; > daniele.ceccarelli@ericsson.com; xuyunbin@mail.ritt.com.cn > *Subject:* Re: RE: Discussion about the GMPLS Signaling Extension > > Hi all, > > As many experts have explained, the label encoding with bit map in > draft-zhang is surely a better way to achieve extensibility and scalabil= ity > of OTN lable. > > The main issue that bit map label format might have is the backword > compatibility. I think we might need to start an survey among the OTN > service providers in the mailing list, and see if there are any OTN > networks deployed with GMPLS RFC4328 lable format. > > If there're no real deployment, we don't need to consider the compatabili= ty > problem; > > If there're some deployment, compatability problem need to be solved . An > easy way might be adding an label version bit in the label format, or som= e > other solutions may be searched out. > > > best regards, > Guoying Zhang > > > > 2009-08-04 > ------------------------------ > zhangguoying > ------------------------------ > *=B7=A2=BC=FE=C8=CB=A3=BA* Jin, Lizhong (NSN - CN/Shanghai) > *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2009-08-04 13:34:24 > *=CA=D5=BC=FE=C8=CB=A3=BA* ccamp@ietf.org > *=B3=AD=CB=CD=A3=BA* zhangfatai@huawei.com; fu.xihua@zte.com.cn; dbrungar= d@att.com; > lberger@labn.net; diego.caviglia@ericsson.com; > daniele.ceccarelli@ericsson.com; zhangguoying@mail.ritt.com.cn; > xuyunbin@mail.ritt.com.cn > *=D6=F7=CC=E2=A3=BA* RE: Discussion about the GMPLS Signaling Extension > Hi Fatai and all: > I agree with the issues of excessive number of labels if using the same > label concept of RFC4328. By using bit map for label encoding is a good > idea. And from my understanding, > draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit > map idea if Fatai agree. > > For backward compatibility, we can not assume that RFC4328 is not > deployed unless we can provide some kind of survey report. So currently > the right assumption is that RFC4328 has been deployed, and backward > compatibity should be considered. > > Best Regards > Lizhong Jin > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 30 Jul 2009 11:33:56 +0200 > From: "BELOTTI SERGIO" > Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension > forEvolutive OTN > To: "Fatai" , , > , , > , > , > , > > Cc: ccamp@ietf.org > Message-ID: > <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com > > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Dear Fatai and all, > > > > We agree on the major points raised by Fatai as general issue to be > solved in the context of extension needed to cope with new containers > defined in ITU q11 context, in addition to handling ODU multiplexing > scenarios in existing OTN. > > There are two basic points that brings to the need to update the RFC4328 > anyway. > > > > 1) the present RFC does not permit the link based negotiation for time > slot allocation . No information about tributary port numbers is present > and only in case we have "single layer" , no multiplexing LO -- > HO you > can apply . So this is a lack against the original G.709 even without > considering G.709 Am3 . > > > > 2) Scalability: The extension required in the context of new OTN with > the introduction of ODU0, ODU4, and above all ODUflex , required a real > modifications of the structure of the label to avoid real big size of > number of labels to transmit offloading signalling session. Extension > based on RFC4328 logic do not scale when ODU-flex is used. Large ODU > flex containers will generate > > an excessive number of labels (in principle up to 80 per link) causing > problems with the size of the RSVP-TE message. > > > > This two points together call to the need to change something in RFC. > > Backward compatibility aspects, present in all the drafts, are surely to > be considered and if there are single layer systems deployed using > RFC4328 this should be grandfathered. > > > > Best Regards > > > > Sergio > > > > > > Sergio Belotti > > > > CTO Optics Division > > Alcatel-Lucent > > > > +39 039 6863033 > > +39 039 6863590 > > > > ________________________________ > > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di > Fatai > Inviato: mercoled? 29 luglio 2009 18.33 > A: fu.xihua@zte.com.cn; dbrungard@att.com; lberger@labn.net; > diego.caviglia@ericsson.com; daniele.ceccarelli@ericsson.com; > zhangguoying@mail.ritt.com.cn; xuyunbin@mail.ritt.com.cn > Cc: ccamp@ietf.org > Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension > forEvolutive OTN > > > > Hi all, > > > > To support the current verison of G.709, we think the label format > defined in RFC4328 need to be re-defined anyway. The new OTN label > format should support the whole ODU sets, not only the ODU1, 2, and 3, > but also ODU0, ODU4, even ODUFlex. The following three aspects should be > considered carefully: > > > > 1) The extensibility of the label format is the first thing we should > consider. With the development of OTN technology, RFC4328 label format > style needs to be extended to support the new bitrate ODU (eg. ODU5, > 6...). By the end, we may need keep extending the label formats. > Managing lots of label format may cause big trouble, so we need one-shot > label format for the evolving OTN. > > > > 2) Scalability is another key issue. RFC4328 style format may result in > big size of the total labels, which definitely increase the burden of > the signaling. An efficient approach is needed to carry the same label > information but with less amount of the data, bitmap style is the right > way to go. > > > > 3) For backward compatibility, if there are no implementations for > RFC4328 (or if there are no deployments it is desirable to deprecate > even if it is uncomfortable for existing implementations), it is very > safe to deprecate the old definition, and an extensible, efficient and > scalable solution could be helpful. The label defined in draft-zhang > does not overwrite RFC4328, it can allow the old definition to continue > to exist. > > > > Hope this can clarify your concern. > > > > Authors of draft-zhang > > > > > > > > ----- Original Message ----- > > From: fu.xihua@zte.com.cn > > To: dbrungard@att.com ; lberger@labn.net ; zhangfatai@huawei.com > ; diego.caviglia@ericsson.com ; daniele.ceccarelli@ericsson.com > > Cc: ccamp@ietf.org > > Sent: Tuesday, July 28, 2009 5:33 PM > > Subject: Discussion about the GMPLS Signaling Extension for > Evolutive OTN > > > > Hi Fatai and All, > We have presented the following two document in the CCAMP > morning session. But we have no more time to further discuss GMPLS > extension for evolutive OTN > draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt > l-otn-00 > > draft-zhang-ccamp-gmpls-evolving-g709-01.txt > > > We have a couple of comments and questions for the draft-zhang. > (1) draft-zhang defined the extensions including what has been > done in RFC4328 (i.e., ODU1, ODU2 and ODU3). > draft-ceccarellifuxh defined new Gneralized Label only for > new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, > ODU3e1, ODU3e2, ODUflex and ODU4). > draft-ceccarellifuxh is only a supplement of RFC4328. > How can we used RFC4328 and draft-zhang ? > Any way, if we need to update an previous RFC, we should > assume that it has been deployed, not asking if someone did or not. > (2) Do you really want to remove NMC from the Traffic > Parameters? > If you do that, I think we have to abandon RFC4328. > (3) The compatibility consideration in draft-zhang. > We don't think the extensions in draft-zhang can coexist with > RFC4328. > You point out "we can just do some translation or mapping in > the new nodes". > But before the translation or mapping, you have to know the > Generalized Label Format. > We concern about: > i) How does one node know the Generalized Label format, > especially for ODU1, ODU2 and ODU3 base on your solution? > It may depend on the capability of the adjacent network > element. > ii) But how can the control plane know the adjacent network > element's capability without discovery mechanism? > You should know that GMPLS signaling extension should be > independent on the discovery mechanism and the configuration of > management plane. > iii) The control plane don't need to know the G.709(2003/03) > or G.709 Amendment3 network element? > > In a word, we think it can not do the translation and > mapping. So we can not get the compatibility with RFC4328 in > draft-zhang. > (4) The Generalized Label in draft-zhang > - managing a variable length label could be a mess. > - draft-zhang uses a first part of the label which has fixed > values and then a variable number of bit that is the bitmap. > The bitmap can be long from 0 to 80 bits depending on the > signal type. > - the value of the bitmap is not independent but depends on > the values of two previous fields (ODUk and ODUj) and becomes reserved > in case of K=3DJ > - a bitmap label have not been used nor in SDH and not in > WSON where a fixed label (4 bytes) is used. > Xihua Fu > ZTE > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 4/attachment.htm > > > ------------------------------ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > End of CCAMP Digest, Vol 14, Issue 26 > ************************************* > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > --000e0cd250881711ab04710aae05 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi all:

I Agree with Lizhong.

We took several years to stand= ardize the GMPLS extension for ODU1, ODU2 and ODU3.
Technology of OTN i= s developing. We also need some time to standardize the extension for the n= ew application. We can not forbid vendor/carrier to deploy the OTN based on= RFC4328 at any time. We should keep them from waiting for the new extensio= n. Further more, any extension can not completely promise to fit any new ap= plication in the future. So we have to deal with it step by step. There is some backward compatibility considerations and= solution in draft-ceccarellifuxh. There is also a extensible= lable format in draft-zhang. Why should we take a long time to survey it a= mong the OTN service providers. Two documents should be merged as soon as p= ossible.

Bedford


2009/8/12 Jin, Liz= hong (NSN - CN/Shanghai) <lizhong.jin@nsn.com>
Hi=20 all:
What I need to clarify from my side is=20 that abandoning a RFC is not preferred in any case. If we can develop a bac= kward=20 solution by merging draft-ceccarellifuxh and draft-zhang, why don't we = go in=20 this way.
 
BR
Lizhong Jin

From: ext zhangguoying=20 [mailto:= zhangguoying@mail.ritt.com.cn]
Sent: Tuesday, August 04, 200= 9=20 22:03

To: Jin, Lizhong (NSN - CN/Shanghai);=20 ccamp@ietf.org
<= /div>Cc: = zhangfatai@huawei.com; fu.xihua@zte.com.cn;=20 dbrungard@att.com; lberger@labn.net; diego.= caviglia@ericsson.com;=20 daniel= e.ceccarelli@ericsson.com; xuyunbin@mail.ritt.com.cn

Su= bject:=20 Re: RE: Discussion about the GMPLS Signaling Extension

=
Hi all,
 
As many experts have explained, the label enco= ding with=20 bit map in draft-zhang is  surely a better way to=20 achieve extensibility and scalability of OTN=20 lable.  
 
The main issue that=  bit=20 map label format might have is the backword=20 compatibility. I think we might need to start an survey= =20 among the OTN service providers in the mailing list,  and see if there= are=20 any OTN networks deployed with GMPLS RFC4328 lable format.
 
If there're no real deplo= yment,=20 we don't need to consider the compatability problem;
 
If=20 there're some deployment, compatability problem need to be solved = . An easy=20 way might be adding an label version bit in the la= bel=20 format, or some other solutions may be searched out.
 
 
best regards,
Guoying Zhang
 
 
 
2009-08-04
zhangguoying=20
=B7=A2=BC=FE=C8=CB=A3=BA Jin, Lizhong (N= SN - CN/Shanghai)=20
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-08-0= 4  13:34:24=20
=CA=D5=BC=FE=C8=CB=A3=BA ccamp@ietf.org
=D6=F7=CC=E2=A3=BA RE: Discussion about = the GMPLS=20 Signaling Extension
Hi Fatai and all:
I agree with the issues of excessive&nbs= p;number of labels if using the same
label concept of RFC4328. By using bit&n= bsp;map for label encoding is a good
idea. And from my understanding,
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can mer= ge this bit
map idea if Fatai agree.
 
For backward compatibility, we can not a= ssume that RFC4328 is not
deployed unless we can provide some kind=  of survey report. So currently
the right assumption is that RFC4328 has=  been deployed, and backward
compatibity should be considered.
 
Best Regards
Lizhong Jin
 
----------------------------------------------------------------------=
 
Message: 1
Date: Thu, 30 Jul 2009 11:33:56 +0200
From: "BELOTTI SERGIO"  <Sergio.Belotti@alcatel= -lucent.it=20 >
Subject: [CCAMP] R: Discussion about the = ;GMPLS Signaling Extension
forEvolutive OTN
To: "Fatai"  <zhangfatai@huawei.com >, =20 <fu.xihua@zte.c= om.cn >,
Message-ID:
>
Content-Type: text/plain; charset=3D"iso-8859-1"
 
Dear Fatai and all,
 
 
 
We agree on the major points raised = ;by Fatai as general issue to be
solved in the context of extension neede= d to cope with new containers
defined in ITU  q11 context, in add= ition to handling ODU multiplexing
scenarios in existing OTN.
 
There are two basic points that brings&n= bsp;to the need to update the RFC4328
anyway.
 
 
 
1) the present RFC does not permit = the link based negotiation  for time
slot allocation . No information about t= ributary port numbers is present
and only in case we have "single&nb= sp;layer" , no multiplexing LO --=20 > HO you
can apply . So this is a lack = against the original G.709 even without
considering G.709 Am3 .
 
 
 
2) Scalability: The extension required in&nbs= p;the context of new OTN with
the introduction of ODU0, ODU4, and abov= e all ODUflex , required a real
modifications of the structure of the la= bel to avoid real big size of
number of labels to transmit offloading = signalling session. Extension
based on RFC4328 logic do not scale = ;when ODU-flex is used. Large ODU
flex containers will generate
 
an excessive number of labels (in princi= ple up to 80 per link) causing
problems with the size of the RSVP-TE&nb= sp;message.
 
 
 
This two points together call to the&nbs= p;need to change something in RFC.
 
Backward compatibility aspects, present in al= l the drafts, are surely to
be considered and if there are single&nb= sp;layer systems deployed using
RFC4328 this should be grandfathered.
 
 
 
Best Regards
 
 
 
Sergio
 
 
 
 
 
Sergio Belotti
 
 
 
CTO Optics Division
 
Alcatel-Lucent
 
 
 
+39 039 6863033
 
+39 039 6863590
 
 
 
________________________________
 
Da: c= camp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto&nbs= p;di
Fatai
Inviato: mercoled? 29 luglio 2009 18.33
Oggetto: Re: [CCAMP] Discussion about the&nbs= p;GMPLS Signaling Extension
forEvolutive OTN
 
 
 
Hi all,
 
 
 
To support the current verison of G.709,=  we think the label format
defined in RFC4328 need to be re-defined=  anyway. The new OTN label
format should support the whole ODU sets= , not only the ODU1, 2, and 3,
but also ODU0, ODU4, even ODUFlex. The&n= bsp;following three aspects should be
considered carefully:
 
 
 
1) The extensibility of the label format=  is the first thing we should
consider. With the development of OTN te= chnology, RFC4328 label format
style needs to be extended to support&nb= sp;the new bitrate ODU (eg. ODU5,
6...). By the end, we may need keep=  extending the label formats.
Managing lots of label format may cause&= nbsp;big trouble, so we need one-shot
label format for the evolving OTN.  = ;
 
 
 
2) Scalability is another key issue. RFC= 4328 style format may result in
big size of the total labels, which = ;definitely increase the burden of
the signaling. An efficient approach is = needed to carry the same label
information but with less amount of the&= nbsp;data, bitmap style is the right
way to go.
 
 
 
3) For backward compatibility, if there = are no implementations for
RFC4328 (or if there are no deployments&= nbsp;it is desirable to deprecate
even if it is uncomfortable for existing=  implementations), it is very
safe to deprecate the old definition, an= d an extensible, efficient and
scalable solution could be helpful. The = label defined in draft-zhang
does not overwrite RFC4328, it can allow=  the old definition to continue
to exist.
 
 
 
Hope this can clarify your concern.
 
 
 
Authors of draft-zhang
 
 
 
 
 
 
 
----- Original Message ----- 
 
 
 
 
Sent: Tuesday, July 28, 2009 5:33 PM
 
Subject: Discussion about the GMPLS Signaling=  Extension for
Evolutive OTN
 
 
 
Hi Fatai and All, 
We have presented the following two docu= ment  in the CCAMP
morning session. But we have no more&nbs= p;time to further discuss GMPLS
extension for evolutive OTN 
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt
l-otn-00 >  
draft-zhang-ccamp-gmpls-evolving-g709-01.txt
>  
We have a couple of comments and qu= estions for the draft-zhang. 
(1) draft-zhang defined the extensions includ= ing what has been
done in RFC4328 (i.e., ODU1, ODU2 and&nb= sp;ODU3). 
      draft-ceccarellifuxh defined&= nbsp;new Gneralized Label only for
new application (i.e., ODU0, 1.25G ODU1, = ;1.25G ODU2, 1.25G ODU3, ODU2e,
ODU3e1, ODU3e2, ODUflex and ODU4). 
      draft-ceccarellifuxh is = only a supplement of RFC4328. 
      How can we used&nbs= p;RFC4328 and draft-zhang ?     &nb= sp; 
      Any way, if we = ;need to update an previous RFC, we shou= ld
assume that it has been deployed, not&nb= sp;asking if someone did or not. 
(2) Do you really want to remove NM= C from the Traffic
Parameters? 
      If you do that,&nbs= p;I think we have to abandon RFC4328. 
(3) The compatibility consideration in draft-= zhang. 
   We don't think the extension= s in draft-zhang can coexist with
RFC4328. 
   You point out "we can = just do some translation or mapping in
the new nodes". 
   But before the translation or&nb= sp;mapping, you have to know the
Generalized Label Format.   
   We concern about:   
   i)  How does one node = know the Generalized Label format,
especially for ODU1, ODU2 and ODU3 base&= nbsp;on your solution?     
        It may depen= d on the capability of the adjacent netw= ork
element. 
   ii) But how can the control=  plane know the adjacent network
element's capability without discovery mechani= sm? 
       You should know&nb= sp;that GMPLS signaling extension should be
independent on the discovery mechanism and&nb= sp;the configuration of
management plane. 
   iii) The control plane don't=  need to know the G.709(2003/03)
or G.709 Amendment3 network element? 
      
     In a word, we think&= nbsp;it can not do the translation and
mapping. So we can not get the comp= atibility with RFC4328 in
draft-zhang. 
 (4) The Generalized Label in draft-zhan= g 
    - managing a variable leng= th label could be a mess. 
    - draft-zhang uses a first=  part of the label which has fixed
values and then a variable number of&nbs= p;bit that is the bitmap. 
       The bitmap can&nbs= p;be long from 0 to 80 bits depending&nb= sp;on the
signal type. 
    - the value of the bi= tmap is not independent but depends on
the values of two previous fields (ODUk&= nbsp;and ODUj) and becomes reserved
in case of K=3DJ 
    - a bitmap label have = ;not been used nor in SDH and not i= n
WSON where a fixed label (4 bytes) = is used. 
Xihua Fu 
ZTE 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
4/attachment.htm >
 
------------------------------
 
_______________________________________________
CCAMP mailing list
 
 
End of CCAMP Digest, Vol 14, Issue = 26
*************************************

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp


--000e0cd250881711ab04710aae05-- From zhangfatai@huawei.com Thu Aug 13 19:07:43 2009 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 F01A33A68B9 for ; Thu, 13 Aug 2009 19:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.309 X-Spam-Level: **** X-Spam-Status: No, score=4.309 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 QuiumlU4r0wV for ; Thu, 13 Aug 2009 19:07:41 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A12C23A6CD2 for ; Thu, 13 Aug 2009 19:07:40 -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 <0KOC00KLMGKK87@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 14 Aug 2009 10:07:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC002G1GKKVT@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 14 Aug 2009 10:07:32 +0800 (CST) Received: from z41162b ([10.70.76.91]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOC00NIFGKK3K@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 14 Aug 2009 10:07:32 +0800 (CST) Date: Fri, 14 Aug 2009 10:07:31 +0800 From: Fatai Zhang To: Frederick Robinson , "Jin, Lizhong (NSN - CN/Shanghai)" Message-id: <008901ca1c83$fba46930$5b4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_qv5TSn5u376u96JQb/zV7g)" X-Priority: 3 X-MSMail-priority: Normal References: <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> <26bbdc380908131209x31719bedw6dcd55c1dd47844@mail.gmail.com> Cc: ccamp@ietf.org, ext zhangguoying , xuyunbin@mail.ritt.com.cn Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 14 Aug 2009 02:07:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_qv5TSn5u376u96JQb/zV7g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgYWxsLA0KDQpJZiB0aGVyZSBhcmUgbm8gaW1wbGVtZW50YXRpb25zIGZvciBSRkM0MzI4IGlu IHRoZSBpbmR1c3RyeSwgZG8geW91IHJlYWxseSB0aGluayB0aGF0IHdlIG5lZWQgdHdvIHRvdGFs bHkgZGlmZmVyZW50IGxhYmVsIGZvcm1hdHMgYW5kIGludGVudGlvbmFsbHkgaW50cm9kdWNlIHRo ZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5ID8gRG8gd2UgcmVhbGx5IGxpa2UgdHJvdWJsZSB2ZXJ5 IG11Y2ggPyANCg0KV2UgYWx3YXlzIGFkbWl0IHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkgaWYgdGhlcmUgYXJlIGRlcGxveW1lbnRzIGZvciBSRkM0MzI4Lg0K DQpJIHRoaW5rIGlmIHdlIHJlYWxseSBuZWVkIHRvIGNvbnNpZGVyIGJhY2t3YXJkIGNvbXBhdGli aWxpdHksIHdlIHNob3VsZCBmb2N1cyBvbiBob3cgdG8gcmVzb2x2ZSBpdCwgYnV0IG5vdCBmb2N1 cyBvbiBtZXJnaW5nIHR3byBkb2N1bWVudHMsIGJlY2F1c2UgdGhlIGxhYmVsIGZvcm1hdHMgaW4g dHdvIGRvY3VtZW50cyBhcmUgdmVyeSBkaWZmZXJlbnQgYW5kIHRoZSBzb2x1dGlvbnMgZm9yIHRo ZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IG1heSBhbHNvIGJlIGRpZmZlcmVudC4NCg0KDQoNCg0K VGhhbmtzDQoNCkZhdGFpDQogDQpBZHZhbmNlZCBUZWNobm9sb2d5IERlcGFydG1lbnQNCldpcmVs aW5lIE5ldHdvcmtpbmcgQnVzaW5lc3MgVW5pdA0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIExU RC4NCkh1YXdlaSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZywNClNoZW56aGVuIDUxODEyOSBQLlIu Q2hpbmENClRlbDogKzg2LTc1NS0yODk3MjkxMg0KRmF4OiArODYtNzU1LTI4OTcyOTM1DQogIC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEZyZWRlcmljayBSb2JpbnNvbiAN CiAgVG86IEppbiwgTGl6aG9uZyAoTlNOIC0gQ04vU2hhbmdoYWkpIA0KICBDYzogY2NhbXBAaWV0 Zi5vcmcgOyBleHQgemhhbmdndW95aW5nIDsgeHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbiANCiAg U2VudDogRnJpZGF5LCBBdWd1c3QgMTQsIDIwMDkgMzowOSBBTQ0KICBTdWJqZWN0OiBSZTogW0ND QU1QXSBEaXNjdXNzaW9uIGFib3V0IHRoZSBHTVBMUyBTaWduYWxpbmcgRXh0ZW5zaW9uDQoNCg0K ICBIaSBhbGw6DQoNCiAgSSBBZ3JlZSB3aXRoIExpemhvbmcuIA0KDQogIFdlIHRvb2sgc2V2ZXJh bCB5ZWFycyB0byBzdGFuZGFyZGl6ZSB0aGUgR01QTFMgZXh0ZW5zaW9uIGZvciBPRFUxLCBPRFUy IGFuZCBPRFUzLiANCiAgVGVjaG5vbG9neSBvZiBPVE4gaXMgZGV2ZWxvcGluZy4gV2UgYWxzbyBu ZWVkIHNvbWUgdGltZSB0byBzdGFuZGFyZGl6ZSB0aGUgZXh0ZW5zaW9uIGZvciB0aGUgbmV3IGFw cGxpY2F0aW9uLiBXZSBjYW4gbm90IGZvcmJpZCB2ZW5kb3IvY2FycmllciB0byBkZXBsb3kgdGhl IE9UTiBiYXNlZCBvbiBSRkM0MzI4IGF0IGFueSB0aW1lLiBXZSBzaG91bGQga2VlcCB0aGVtIGZy b20gd2FpdGluZyBmb3IgdGhlIG5ldyBleHRlbnNpb24uIEZ1cnRoZXIgbW9yZSwgYW55IGV4dGVu c2lvbiBjYW4gbm90IGNvbXBsZXRlbHkgcHJvbWlzZSB0byBmaXQgYW55IG5ldyBhcHBsaWNhdGlv biBpbiB0aGUgZnV0dXJlLiBTbyB3ZSBoYXZlIHRvIGRlYWwgd2l0aCBpdCBzdGVwIGJ5IHN0ZXAu IFRoZXJlIGlzIHNvbWUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBjb25zaWRlcmF0aW9ucyBhbmQg c29sdXRpb24gaW4gZHJhZnQtY2VjY2FyZWxsaWZ1eGguIFRoZXJlIGlzIGFsc28gYSBleHRlbnNp YmxlIGxhYmxlIGZvcm1hdCBpbiBkcmFmdC16aGFuZy4gV2h5IHNob3VsZCB3ZSB0YWtlIGEgbG9u ZyB0aW1lIHRvIHN1cnZleSBpdCBhbW9uZyB0aGUgT1ROIHNlcnZpY2UgcHJvdmlkZXJzLiBUd28g ZG9jdW1lbnRzIHNob3VsZCBiZSBtZXJnZWQgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KICBCZWRm b3JkDQoNCg0KDQogIDIwMDkvOC8xMiBKaW4sIExpemhvbmcgKE5TTiAtIENOL1NoYW5naGFpKSA8 bGl6aG9uZy5qaW5AbnNuLmNvbT4NCg0KICAgIEhpIGFsbDoNCiAgICBXaGF0IEkgbmVlZCB0byBj bGFyaWZ5IGZyb20gbXkgc2lkZSBpcyB0aGF0IGFiYW5kb25pbmcgYSBSRkMgaXMgbm90IHByZWZl cnJlZCBpbiBhbnkgY2FzZS4gSWYgd2UgY2FuIGRldmVsb3AgYSBiYWNrd2FyZCBzb2x1dGlvbiBi eSBtZXJnaW5nIGRyYWZ0LWNlY2NhcmVsbGlmdXhoIGFuZCBkcmFmdC16aGFuZywgd2h5IGRvbid0 IHdlIGdvIGluIHRoaXMgd2F5Lg0KDQogICAgQlINCiAgICBMaXpob25nIEppbg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgIEZyb206IGV4dCB6aGFuZ2d1b3lpbmcgW21haWx0bzp6aGFu Z2d1b3lpbmdAbWFpbC5yaXR0LmNvbS5jbl0gDQogICAgU2VudDogVHVlc2RheSwgQXVndXN0IDA0 LCAyMDA5IDIyOjAzDQoNCiAgICBUbzogSmluLCBMaXpob25nIChOU04gLSBDTi9TaGFuZ2hhaSk7 IGNjYW1wQGlldGYub3JnDQoNCiAgICBDYzogemhhbmdmYXRhaUBodWF3ZWkuY29tOyBmdS54aWh1 YUB6dGUuY29tLmNuOyBkYnJ1bmdhcmRAYXR0LmNvbTsgbGJlcmdlckBsYWJuLm5ldDsgZGllZ28u Y2F2aWdsaWFAZXJpY3Nzb24uY29tOyBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tOyB4 dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuDQoNCiAgICBTdWJqZWN0OiBSZTogUkU6IERpc2N1c3Np b24gYWJvdXQgdGhlIEdNUExTIFNpZ25hbGluZyBFeHRlbnNpb24NCg0KDQoNCiAgICBIaSBhbGws DQoNCiAgICBBcyBtYW55IGV4cGVydHMgaGF2ZSBleHBsYWluZWQsIHRoZSBsYWJlbCBlbmNvZGlu ZyB3aXRoIGJpdCBtYXAgaW4gZHJhZnQtemhhbmcgaXMgIHN1cmVseSBhIGJldHRlciB3YXkgdG8g YWNoaWV2ZSBleHRlbnNpYmlsaXR5IGFuZCBzY2FsYWJpbGl0eSBvZiBPVE4gbGFibGUuICANCg0K ICAgIFRoZSBtYWluIGlzc3VlIHRoYXQgYml0IG1hcCBsYWJlbCBmb3JtYXQgbWlnaHQgaGF2ZSBp cyB0aGUgYmFja3dvcmQgY29tcGF0aWJpbGl0eS4gSSB0aGluayB3ZSBtaWdodCBuZWVkIHRvIHN0 YXJ0IGFuIHN1cnZleSBhbW9uZyB0aGUgT1ROIHNlcnZpY2UgcHJvdmlkZXJzIGluIHRoZSBtYWls aW5nIGxpc3QsICBhbmQgc2VlIGlmIHRoZXJlIGFyZSBhbnkgT1ROIG5ldHdvcmtzIGRlcGxveWVk IHdpdGggR01QTFMgUkZDNDMyOCBsYWJsZSBmb3JtYXQuIA0KDQogICAgSWYgdGhlcmUncmUgbm8g cmVhbCBkZXBsb3ltZW50LCB3ZSBkb24ndCBuZWVkIHRvIGNvbnNpZGVyIHRoZSBjb21wYXRhYmls aXR5IHByb2JsZW07DQoNCiAgICBJZiB0aGVyZSdyZSBzb21lIGRlcGxveW1lbnQsIGNvbXBhdGFi aWxpdHkgcHJvYmxlbSBuZWVkIHRvIGJlIHNvbHZlZCAuIEFuIGVhc3kgd2F5IG1pZ2h0IGJlIGFk ZGluZyBhbiBsYWJlbCB2ZXJzaW9uIGJpdCBpbiB0aGUgbGFiZWwgZm9ybWF0LCBvciBzb21lIG90 aGVyIHNvbHV0aW9ucyBtYXkgYmUgc2VhcmNoZWQgb3V0Lg0KDQoNCiAgICBiZXN0IHJlZ2FyZHMs DQogICAgR3VveWluZyBaaGFuZw0KDQoNCg0KICAgIDIwMDktMDgtMDQgDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KICAgIHpoYW5nZ3VveWluZyANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQog ICAgt6K8/sjLo7ogSmluLCBMaXpob25nIChOU04gLSBDTi9TaGFuZ2hhaSkgDQogICAgt6LLzcqx vOSjuiAyMDA5LTA4LTA0ICAxMzozNDoyNCANCiAgICDK1bz+yMujuiBjY2FtcEBpZXRmLm9yZyAN CiAgICCzrcvNo7ogemhhbmdmYXRhaUBodWF3ZWkuY29tOyBmdS54aWh1YUB6dGUuY29tLmNuOyBk YnJ1bmdhcmRAYXR0LmNvbTsgbGJlcmdlckBsYWJuLm5ldDsgZGllZ28uY2F2aWdsaWFAZXJpY3Nz b24uY29tOyBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tOyB6aGFuZ2d1b3lpbmdAbWFp bC5yaXR0LmNvbS5jbjsgeHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbiANCiAgICDW98zio7ogUkU6 IERpc2N1c3Npb24gYWJvdXQgdGhlIEdNUExTIFNpZ25hbGluZyBFeHRlbnNpb24gDQogICAgSGkg RmF0YWkgYW5kIGFsbDoNCiAgICBJIGFncmVlIHdpdGggdGhlIGlzc3VlcyBvZiBleGNlc3NpdmUg bnVtYmVyIG9mIGxhYmVscyBpZiB1c2luZyB0aGUgc2FtZQ0KICAgIGxhYmVsIGNvbmNlcHQgb2Yg UkZDNDMyOC4gQnkgdXNpbmcgYml0IG1hcCBmb3IgbGFiZWwgZW5jb2RpbmcgaXMgYSBnb29kDQog ICAgaWRlYS4gQW5kIGZyb20gbXkgdW5kZXJzdGFuZGluZywNCiAgICBkcmFmdC1jZWNjYXJlbGxp ZnV4aC1jY2FtcC1nbXBscy1leHQtZm9yLWV2b2wtb3RuLTAwIGNhbiBtZXJnZSB0aGlzIGJpdA0K ICAgIG1hcCBpZGVhIGlmIEZhdGFpIGFncmVlLg0KDQogICAgRm9yIGJhY2t3YXJkIGNvbXBhdGli aWxpdHksIHdlIGNhbiBub3QgYXNzdW1lIHRoYXQgUkZDNDMyOCBpcyBub3QNCiAgICBkZXBsb3ll ZCB1bmxlc3Mgd2UgY2FuIHByb3ZpZGUgc29tZSBraW5kIG9mIHN1cnZleSByZXBvcnQuIFNvIGN1 cnJlbnRseQ0KICAgIHRoZSByaWdodCBhc3N1bXB0aW9uIGlzIHRoYXQgUkZDNDMyOCBoYXMgYmVl biBkZXBsb3llZCwgYW5kIGJhY2t3YXJkDQogICAgY29tcGF0aWJpdHkgc2hvdWxkIGJlIGNvbnNp ZGVyZWQuDQoNCiAgICBCZXN0IFJlZ2FyZHMNCiAgICBMaXpob25nIEppbg0KDQogICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQogICAgTWVzc2FnZTogMQ0KICAgIERhdGU6IFRodSwgMzAgSnVsIDIwMDkgMTE6 MzM6NTYgKzAyMDANCiAgICBGcm9tOiAiQkVMT1RUSSBTRVJHSU8iICA8U2VyZ2lvLkJlbG90dGlA YWxjYXRlbC1sdWNlbnQuaXQgPg0KICAgIFN1YmplY3Q6IFtDQ0FNUF0gUjogRGlzY3Vzc2lvbiBh Ym91dCB0aGUgR01QTFMgU2lnbmFsaW5nIEV4dGVuc2lvbg0KICAgIGZvckV2b2x1dGl2ZSBPVE4N CiAgICBUbzogIkZhdGFpIiAgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbSA+LCAgPGZ1LnhpaHVhQHp0 ZS5jb20uY24gPiwNCiAgICA8ZGJydW5nYXJkQGF0dC5jb20gPiwgIDxsYmVyZ2VyQGxhYm4ubmV0 ID4sDQogICAgPGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSA+LA0KICAgIDxkYW5pZWxlLmNl Y2NhcmVsbGlAZXJpY3Nzb24uY29tID4sDQogICAgPHpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29t LmNuID4sDQogICAgPHh1eXVuYmluQG1haWwucml0dC5jb20uY24gPg0KICAgIENjOiBjY2FtcEBp ZXRmLm9yZw0KICAgIE1lc3NhZ2UtSUQ6DQogICAgPDNGNDQxODZENzE0MUUyNDc5NzJFQUM2NjU1 QjBBMjkxMDFGQTdBNTZARlJWRUxTTUJTMjEuYWQyLmFkLmFsY2F0ZWwuY29tDQogICAgPg0KICAg IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0iaXNvLTg4NTktMSINCg0KICAgIERl YXIgRmF0YWkgYW5kIGFsbCwNCg0KDQoNCiAgICBXZSBhZ3JlZSBvbiB0aGUgbWFqb3IgcG9pbnRz IHJhaXNlZCBieSBGYXRhaSBhcyBnZW5lcmFsIGlzc3VlIHRvIGJlDQogICAgc29sdmVkIGluIHRo ZSBjb250ZXh0IG9mIGV4dGVuc2lvbiBuZWVkZWQgdG8gY29wZSB3aXRoIG5ldyBjb250YWluZXJz DQogICAgZGVmaW5lZCBpbiBJVFUgIHExMSBjb250ZXh0LCBpbiBhZGRpdGlvbiB0byBoYW5kbGlu ZyBPRFUgbXVsdGlwbGV4aW5nDQogICAgc2NlbmFyaW9zIGluIGV4aXN0aW5nIE9UTi4NCg0KICAg IFRoZXJlIGFyZSB0d28gYmFzaWMgcG9pbnRzIHRoYXQgYnJpbmdzIHRvIHRoZSBuZWVkIHRvIHVw ZGF0ZSB0aGUgUkZDNDMyOA0KICAgIGFueXdheS4NCg0KDQoNCiAgICAxKSB0aGUgcHJlc2VudCBS RkMgZG9lcyBub3QgcGVybWl0IHRoZSBsaW5rIGJhc2VkIG5lZ290aWF0aW9uICBmb3IgdGltZQ0K ICAgIHNsb3QgYWxsb2NhdGlvbiAuIE5vIGluZm9ybWF0aW9uIGFib3V0IHRyaWJ1dGFyeSBwb3J0 IG51bWJlcnMgaXMgcHJlc2VudA0KICAgIGFuZCBvbmx5IGluIGNhc2Ugd2UgaGF2ZSAic2luZ2xl IGxheWVyIiAsIG5vIG11bHRpcGxleGluZyBMTyAtLSA+IEhPIHlvdQ0KICAgIGNhbiBhcHBseSAu IFNvIHRoaXMgaXMgYSBsYWNrIGFnYWluc3QgdGhlIG9yaWdpbmFsIEcuNzA5IGV2ZW4gd2l0aG91 dA0KICAgIGNvbnNpZGVyaW5nIEcuNzA5IEFtMyAuDQoNCg0KDQogICAgMikgU2NhbGFiaWxpdHk6 IFRoZSBleHRlbnNpb24gcmVxdWlyZWQgaW4gdGhlIGNvbnRleHQgb2YgbmV3IE9UTiB3aXRoDQog ICAgdGhlIGludHJvZHVjdGlvbiBvZiBPRFUwLCBPRFU0LCBhbmQgYWJvdmUgYWxsIE9EVWZsZXgg LCByZXF1aXJlZCBhIHJlYWwNCiAgICBtb2RpZmljYXRpb25zIG9mIHRoZSBzdHJ1Y3R1cmUgb2Yg dGhlIGxhYmVsIHRvIGF2b2lkIHJlYWwgYmlnIHNpemUgb2YNCiAgICBudW1iZXIgb2YgbGFiZWxz IHRvIHRyYW5zbWl0IG9mZmxvYWRpbmcgc2lnbmFsbGluZyBzZXNzaW9uLiBFeHRlbnNpb24NCiAg ICBiYXNlZCBvbiBSRkM0MzI4IGxvZ2ljIGRvIG5vdCBzY2FsZSB3aGVuIE9EVS1mbGV4IGlzIHVz ZWQuIExhcmdlIE9EVQ0KICAgIGZsZXggY29udGFpbmVycyB3aWxsIGdlbmVyYXRlDQoNCiAgICBh biBleGNlc3NpdmUgbnVtYmVyIG9mIGxhYmVscyAoaW4gcHJpbmNpcGxlIHVwIHRvIDgwIHBlciBs aW5rKSBjYXVzaW5nDQogICAgcHJvYmxlbXMgd2l0aCB0aGUgc2l6ZSBvZiB0aGUgUlNWUC1URSBt ZXNzYWdlLg0KDQoNCg0KICAgIFRoaXMgdHdvIHBvaW50cyB0b2dldGhlciBjYWxsIHRvIHRoZSBu ZWVkIHRvIGNoYW5nZSBzb21ldGhpbmcgaW4gUkZDLg0KDQogICAgQmFja3dhcmQgY29tcGF0aWJp bGl0eSBhc3BlY3RzLCBwcmVzZW50IGluIGFsbCB0aGUgZHJhZnRzLCBhcmUgc3VyZWx5IHRvDQog ICAgYmUgY29uc2lkZXJlZCBhbmQgaWYgdGhlcmUgYXJlIHNpbmdsZSBsYXllciBzeXN0ZW1zIGRl cGxveWVkIHVzaW5nDQogICAgUkZDNDMyOCB0aGlzIHNob3VsZCBiZSBncmFuZGZhdGhlcmVkLg0K DQoNCg0KICAgIEJlc3QgUmVnYXJkcw0KDQoNCg0KICAgIFNlcmdpbw0KDQoNCg0KDQoNCiAgICBT ZXJnaW8gQmVsb3R0aQ0KDQoNCg0KICAgIENUTyBPcHRpY3MgRGl2aXNpb24NCg0KICAgIEFsY2F0 ZWwtTHVjZW50DQoNCg0KDQogICAgKzM5IDAzOSA2ODYzMDMzDQoNCiAgICArMzkgMDM5IDY4NjM1 OTANCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAgRGE6 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBQ ZXIgY29udG8gZGkNCiAgICBGYXRhaQ0KICAgIEludmlhdG86IG1lcmNvbGVkPyAyOSBsdWdsaW8g MjAwOSAxOC4zMw0KICAgIEE6IGZ1LnhpaHVhQHp0ZS5jb20uY247IGRicnVuZ2FyZEBhdHQuY29t OyBsYmVyZ2VyQGxhYm4ubmV0Ow0KICAgIGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTsgZGFu aWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTsNCiAgICB6aGFuZ2d1b3lpbmdAbWFpbC5yaXR0 LmNvbS5jbjsgeHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbg0KICAgIENjOiBjY2FtcEBpZXRmLm9y Zw0KICAgIE9nZ2V0dG86IFJlOiBbQ0NBTVBdIERpc2N1c3Npb24gYWJvdXQgdGhlIEdNUExTIFNp Z25hbGluZyBFeHRlbnNpb24NCiAgICBmb3JFdm9sdXRpdmUgT1RODQoNCg0KDQogICAgSGkgYWxs LA0KDQoNCg0KICAgIFRvIHN1cHBvcnQgdGhlIGN1cnJlbnQgdmVyaXNvbiBvZiBHLjcwOSwgd2Ug dGhpbmsgdGhlIGxhYmVsIGZvcm1hdA0KICAgIGRlZmluZWQgaW4gUkZDNDMyOCBuZWVkIHRvIGJl IHJlLWRlZmluZWQgYW55d2F5LiBUaGUgbmV3IE9UTiBsYWJlbA0KICAgIGZvcm1hdCBzaG91bGQg c3VwcG9ydCB0aGUgd2hvbGUgT0RVIHNldHMsIG5vdCBvbmx5IHRoZSBPRFUxLCAyLCBhbmQgMywN CiAgICBidXQgYWxzbyBPRFUwLCBPRFU0LCBldmVuIE9EVUZsZXguIFRoZSBmb2xsb3dpbmcgdGhy ZWUgYXNwZWN0cyBzaG91bGQgYmUNCiAgICBjb25zaWRlcmVkIGNhcmVmdWxseToNCg0KDQoNCiAg ICAxKSBUaGUgZXh0ZW5zaWJpbGl0eSBvZiB0aGUgbGFiZWwgZm9ybWF0IGlzIHRoZSBmaXJzdCB0 aGluZyB3ZSBzaG91bGQNCiAgICBjb25zaWRlci4gV2l0aCB0aGUgZGV2ZWxvcG1lbnQgb2YgT1RO IHRlY2hub2xvZ3ksIFJGQzQzMjggbGFiZWwgZm9ybWF0DQogICAgc3R5bGUgbmVlZHMgdG8gYmUg ZXh0ZW5kZWQgdG8gc3VwcG9ydCB0aGUgbmV3IGJpdHJhdGUgT0RVIChlZy4gT0RVNSwNCiAgICA2 Li4uKS4gQnkgdGhlIGVuZCwgd2UgbWF5IG5lZWQga2VlcCBleHRlbmRpbmcgdGhlIGxhYmVsIGZv cm1hdHMuDQogICAgTWFuYWdpbmcgbG90cyBvZiBsYWJlbCBmb3JtYXQgbWF5IGNhdXNlIGJpZyB0 cm91YmxlLCBzbyB3ZSBuZWVkIG9uZS1zaG90DQogICAgbGFiZWwgZm9ybWF0IGZvciB0aGUgZXZv bHZpbmcgT1ROLiAgDQoNCg0KDQogICAgMikgU2NhbGFiaWxpdHkgaXMgYW5vdGhlciBrZXkgaXNz dWUuIFJGQzQzMjggc3R5bGUgZm9ybWF0IG1heSByZXN1bHQgaW4NCiAgICBiaWcgc2l6ZSBvZiB0 aGUgdG90YWwgbGFiZWxzLCB3aGljaCBkZWZpbml0ZWx5IGluY3JlYXNlIHRoZSBidXJkZW4gb2YN CiAgICB0aGUgc2lnbmFsaW5nLiBBbiBlZmZpY2llbnQgYXBwcm9hY2ggaXMgbmVlZGVkIHRvIGNh cnJ5IHRoZSBzYW1lIGxhYmVsDQogICAgaW5mb3JtYXRpb24gYnV0IHdpdGggbGVzcyBhbW91bnQg b2YgdGhlIGRhdGEsIGJpdG1hcCBzdHlsZSBpcyB0aGUgcmlnaHQNCiAgICB3YXkgdG8gZ28uDQoN Cg0KDQogICAgMykgRm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGlmIHRoZXJlIGFyZSBubyBp bXBsZW1lbnRhdGlvbnMgZm9yDQogICAgUkZDNDMyOCAob3IgaWYgdGhlcmUgYXJlIG5vIGRlcGxv eW1lbnRzIGl0IGlzIGRlc2lyYWJsZSB0byBkZXByZWNhdGUNCiAgICBldmVuIGlmIGl0IGlzIHVu Y29tZm9ydGFibGUgZm9yIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyksIGl0IGlzIHZlcnkNCiAg ICBzYWZlIHRvIGRlcHJlY2F0ZSB0aGUgb2xkIGRlZmluaXRpb24sIGFuZCBhbiBleHRlbnNpYmxl LCBlZmZpY2llbnQgYW5kDQogICAgc2NhbGFibGUgc29sdXRpb24gY291bGQgYmUgaGVscGZ1bC4g VGhlIGxhYmVsIGRlZmluZWQgaW4gZHJhZnQtemhhbmcNCiAgICBkb2VzIG5vdCBvdmVyd3JpdGUg UkZDNDMyOCwgaXQgY2FuIGFsbG93IHRoZSBvbGQgZGVmaW5pdGlvbiB0byBjb250aW51ZQ0KICAg IHRvIGV4aXN0Lg0KDQoNCg0KICAgIEhvcGUgdGhpcyBjYW4gY2xhcmlmeSB5b3VyIGNvbmNlcm4u DQoNCg0KDQogICAgQXV0aG9ycyBvZiBkcmFmdC16aGFuZw0KDQoNCg0KDQoNCg0KDQogICAgLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCg0KICAgIEZyb206IGZ1LnhpaHVhQHp0ZS5jb20u Y24gDQoNCiAgICBUbzogZGJydW5nYXJkQGF0dC5jb20gOyBsYmVyZ2VyQGxhYm4ubmV0IDsgemhh bmdmYXRhaUBodWF3ZWkuY29tDQogICAgOyBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20gOyBk YW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIA0KDQogICAgQ2M6IGNjYW1wQGlldGYub3Jn IA0KDQogICAgU2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAwOSA1OjMzIFBNDQoNCiAgICBTdWJq ZWN0OiBEaXNjdXNzaW9uIGFib3V0IHRoZSBHTVBMUyBTaWduYWxpbmcgRXh0ZW5zaW9uIGZvcg0K ICAgIEV2b2x1dGl2ZSBPVE4NCg0KDQoNCiAgICBIaSBGYXRhaSBhbmQgQWxsLCANCiAgICBXZSBo YXZlIHByZXNlbnRlZCB0aGUgZm9sbG93aW5nIHR3byBkb2N1bWVudCAgaW4gdGhlIENDQU1QDQog ICAgbW9ybmluZyBzZXNzaW9uLiBCdXQgd2UgaGF2ZSBubyBtb3JlIHRpbWUgdG8gZnVydGhlciBk aXNjdXNzIEdNUExTDQogICAgZXh0ZW5zaW9uIGZvciBldm9sdXRpdmUgT1ROIA0KICAgIGRyYWZ0 LWNlY2NhcmVsbGlmdXhoLWNjYW1wLWdtcGxzLWV4dC1mb3ItZXZvbC1vdG4tMDAudHh0DQogICAg PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNlY2NhcmVsbGlmdXhoLWNjYW1wLWdt cGxzLWV4dC1mb3ItZXZvDQogICAgbC1vdG4tMDAgPiAgDQogICAgZHJhZnQtemhhbmctY2NhbXAt Z21wbHMtZXZvbHZpbmctZzcwOS0wMS50eHQNCiAgICA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMS50eHQNCiAgICA+ICAN CiAgICBXZSBoYXZlIGEgY291cGxlIG9mIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgZm9yIHRoZSBk cmFmdC16aGFuZy4gDQogICAgKDEpIGRyYWZ0LXpoYW5nIGRlZmluZWQgdGhlIGV4dGVuc2lvbnMg aW5jbHVkaW5nIHdoYXQgaGFzIGJlZW4NCiAgICBkb25lIGluIFJGQzQzMjggKGkuZS4sIE9EVTEs IE9EVTIgYW5kIE9EVTMpLiANCiAgICAgICAgICBkcmFmdC1jZWNjYXJlbGxpZnV4aCBkZWZpbmVk IG5ldyBHbmVyYWxpemVkIExhYmVsIG9ubHkgZm9yDQogICAgbmV3IGFwcGxpY2F0aW9uIChpLmUu LCBPRFUwLCAxLjI1RyBPRFUxLCAxLjI1RyBPRFUyLCAxLjI1RyBPRFUzLCBPRFUyZSwNCiAgICBP RFUzZTEsIE9EVTNlMiwgT0RVZmxleCBhbmQgT0RVNCkuIA0KICAgICAgICAgIGRyYWZ0LWNlY2Nh cmVsbGlmdXhoIGlzIG9ubHkgYSBzdXBwbGVtZW50IG9mIFJGQzQzMjguIA0KICAgICAgICAgIEhv dyBjYW4gd2UgdXNlZCBSRkM0MzI4IGFuZCBkcmFmdC16aGFuZyA/ICAgICAgIA0KICAgICAgICAg IEFueSB3YXksIGlmIHdlIG5lZWQgdG8gdXBkYXRlIGFuIHByZXZpb3VzIFJGQywgd2Ugc2hvdWxk DQogICAgYXNzdW1lIHRoYXQgaXQgaGFzIGJlZW4gZGVwbG95ZWQsIG5vdCBhc2tpbmcgaWYgc29t ZW9uZSBkaWQgb3Igbm90LiANCiAgICAoMikgRG8geW91IHJlYWxseSB3YW50IHRvIHJlbW92ZSBO TUMgZnJvbSB0aGUgVHJhZmZpYw0KICAgIFBhcmFtZXRlcnM/IA0KICAgICAgICAgIElmIHlvdSBk byB0aGF0LCBJIHRoaW5rIHdlIGhhdmUgdG8gYWJhbmRvbiBSRkM0MzI4LiANCiAgICAoMykgVGhl IGNvbXBhdGliaWxpdHkgY29uc2lkZXJhdGlvbiBpbiBkcmFmdC16aGFuZy4gDQogICAgICAgV2Ug ZG9uJ3QgdGhpbmsgdGhlIGV4dGVuc2lvbnMgaW4gZHJhZnQtemhhbmcgY2FuIGNvZXhpc3Qgd2l0 aA0KICAgIFJGQzQzMjguIA0KICAgICAgIFlvdSBwb2ludCBvdXQgIndlIGNhbiBqdXN0IGRvIHNv bWUgdHJhbnNsYXRpb24gb3IgbWFwcGluZyBpbg0KICAgIHRoZSBuZXcgbm9kZXMiLiANCiAgICAg ICBCdXQgYmVmb3JlIHRoZSB0cmFuc2xhdGlvbiBvciBtYXBwaW5nLCB5b3UgaGF2ZSB0byBrbm93 IHRoZQ0KICAgIEdlbmVyYWxpemVkIExhYmVsIEZvcm1hdC4gICANCiAgICAgICBXZSBjb25jZXJu IGFib3V0OiAgIA0KICAgICAgIGkpICBIb3cgZG9lcyBvbmUgbm9kZSBrbm93IHRoZSBHZW5lcmFs aXplZCBMYWJlbCBmb3JtYXQsDQogICAgZXNwZWNpYWxseSBmb3IgT0RVMSwgT0RVMiBhbmQgT0RV MyBiYXNlIG9uIHlvdXIgc29sdXRpb24/ICAgICANCiAgICAgICAgICAgIEl0IG1heSBkZXBlbmQg b24gdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGFkamFjZW50IG5ldHdvcmsNCiAgICBlbGVtZW50LiAN CiAgICAgICBpaSkgQnV0IGhvdyBjYW4gdGhlIGNvbnRyb2wgcGxhbmUga25vdyB0aGUgYWRqYWNl bnQgbmV0d29yaw0KICAgIGVsZW1lbnQncyBjYXBhYmlsaXR5IHdpdGhvdXQgZGlzY292ZXJ5IG1l Y2hhbmlzbT8gDQogICAgICAgICAgIFlvdSBzaG91bGQga25vdyB0aGF0IEdNUExTIHNpZ25hbGlu ZyBleHRlbnNpb24gc2hvdWxkIGJlDQogICAgaW5kZXBlbmRlbnQgb24gdGhlIGRpc2NvdmVyeSBt ZWNoYW5pc20gYW5kIHRoZSBjb25maWd1cmF0aW9uIG9mDQogICAgbWFuYWdlbWVudCBwbGFuZS4g DQogICAgICAgaWlpKSBUaGUgY29udHJvbCBwbGFuZSBkb24ndCBuZWVkIHRvIGtub3cgdGhlIEcu NzA5KDIwMDMvMDMpDQogICAgb3IgRy43MDkgQW1lbmRtZW50MyBuZXR3b3JrIGVsZW1lbnQ/IA0K ICAgICAgICAgIA0KICAgICAgICAgSW4gYSB3b3JkLCB3ZSB0aGluayBpdCBjYW4gbm90IGRvIHRo ZSB0cmFuc2xhdGlvbiBhbmQNCiAgICBtYXBwaW5nLiBTbyB3ZSBjYW4gbm90IGdldCB0aGUgY29t cGF0aWJpbGl0eSB3aXRoIFJGQzQzMjggaW4NCiAgICBkcmFmdC16aGFuZy4gDQogICAgICg0KSBU aGUgR2VuZXJhbGl6ZWQgTGFiZWwgaW4gZHJhZnQtemhhbmcgDQogICAgICAgIC0gbWFuYWdpbmcg YSB2YXJpYWJsZSBsZW5ndGggbGFiZWwgY291bGQgYmUgYSBtZXNzLiANCiAgICAgICAgLSBkcmFm dC16aGFuZyB1c2VzIGEgZmlyc3QgcGFydCBvZiB0aGUgbGFiZWwgd2hpY2ggaGFzIGZpeGVkDQog ICAgdmFsdWVzIGFuZCB0aGVuIGEgdmFyaWFibGUgbnVtYmVyIG9mIGJpdCB0aGF0IGlzIHRoZSBi aXRtYXAuIA0KICAgICAgICAgICBUaGUgYml0bWFwIGNhbiBiZSBsb25nIGZyb20gMCB0byA4MCBi aXRzIGRlcGVuZGluZyBvbiB0aGUNCiAgICBzaWduYWwgdHlwZS4gDQogICAgICAgIC0gdGhlIHZh bHVlIG9mIHRoZSBiaXRtYXAgaXMgbm90IGluZGVwZW5kZW50IGJ1dCBkZXBlbmRzIG9uDQogICAg dGhlIHZhbHVlcyBvZiB0d28gcHJldmlvdXMgZmllbGRzIChPRFVrIGFuZCBPRFVqKSBhbmQgYmVj b21lcyByZXNlcnZlZA0KICAgIGluIGNhc2Ugb2YgSz1KIA0KICAgICAgICAtIGEgYml0bWFwIGxh YmVsIGhhdmUgbm90IGJlZW4gdXNlZCBub3IgaW4gU0RIIGFuZCBub3QgaW4NCiAgICBXU09OIHdo ZXJlIGEgZml4ZWQgbGFiZWwgKDQgYnl0ZXMpIGlzIHVzZWQuIA0KICAgIFhpaHVhIEZ1IA0KICAg IFpURSANCg0KICAgIC0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQ0KICAg IEFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4NCiAgICBVUkw6DQogICAgPGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jY2FtcC9hdHRhY2htZW50cy8yMDA5MDcz MC9iZmNlYzUwDQogICAgNC9hdHRhY2htZW50Lmh0bSA+DQoNCiAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgQ0NBTVAgbWFpbGluZyBsaXN0DQogICAgQ0NBTVBAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KICAg IEVuZCBvZiBDQ0FNUCBEaWdlc3QsIFZvbCAxNCwgSXNzdWUgMjYNCiAgICAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIENDQU1QIG1haWxpbmcgbGlzdA0KICAgIENDQU1Q QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBDQ0FNUCBtYWlsaW5nIGxpc3QN CiAgQ0NBTVBAaWV0Zi5vcmcNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0K --Boundary_(ID_qv5TSn5u376u96JQb/zV7g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM1NjIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGkgYWxsLDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWw+SWYgdGhlcmUgYXJlIG5vIGltcGxlbWVudGF0aW9ucyBmb3IgUkZD NDMyOCBpbiB0aGUgDQppbmR1c3RyeSwgZG8geW91IHJlYWxseSB0aGluayB0aGF0IHdlIG5lZWQg dHdvIHRvdGFsbHkgZGlmZmVyZW50IGxhYmVsIGZvcm1hdHMgDQphbmQgaW50ZW50aW9uYWxseSBp bnRyb2R1Y2UgdGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgPyBEbyB3ZSByZWFsbHkgbGlrZSAN CnRyb3VibGUgdmVyeSBtdWNoID8gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5XZSBhbHdheXMgYWRt aXQgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgYmFja3dhcmQgDQpjb21wYXRpYmlsaXR5IGlmIHRo ZXJlIGFyZSBkZXBsb3ltZW50cyBmb3IgUkZDNDMyOC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkkg dGhpbmsgaWYgd2UgcmVhbGx5IG5lZWQgdG8gY29uc2lkZXIgYmFja3dhcmQgDQpjb21wYXRpYmls aXR5LCB3ZSBzaG91bGQgZm9jdXMgb24gaG93IHRvIHJlc29sdmUgaXQsIGJ1dCBub3QgZm9jdXMg b24gbWVyZ2luZyANCnR3byBkb2N1bWVudHMsIGJlY2F1c2UgdGhlIGxhYmVsIGZvcm1hdHMgaW4g dHdvIGRvY3VtZW50cyBhcmUgdmVyeSBkaWZmZXJlbnQgYW5kIA0KdGhlIHNvbHV0aW9ucyBmb3Ig dGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgbWF5IGFsc28gYmUgZGlmZmVyZW50LjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPlRoYW5rczwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+RmF0YWk8QlI+Jm5ic3A7PEJSPkFkdmFuY2VkIFRlY2hub2xvZ3kg RGVwYXJ0bWVudDxCUj5XaXJlbGluZSBOZXR3b3JraW5nIA0KQnVzaW5lc3MgVW5pdDxCUj5IdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTFRELjxCUj5IdWF3ZWkgQmFzZSwgQmFudGlhbiwgDQpMb25n Z2FuZyw8QlI+U2hlbnpoZW4gNTE4MTI5IFAuUi5DaGluYTxCUj5UZWw6ICs4Ni03NTUtMjg5NzI5 MTI8QlI+RmF4OiANCis4Ni03NTUtMjg5NzI5MzU8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9 IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7 IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8 RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5SI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IMvOzOU7 IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWZyZWRlcmljay5i ZWRmb3JkQGdtYWlsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmZyZWRlcmljay5iZWRmb3JkQGdtYWls LmNvbSI+RnJlZGVyaWNrIFJvYmluc29uPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0IMvOzOUiPjxCPlRvOjwvQj4gPEEgdGl0bGU9bGl6aG9uZy5qaW5AbnNuLmNvbSANCiAgaHJl Zj0ibWFpbHRvOmxpemhvbmcuamluQG5zbi5jb20iPkppbiwgTGl6aG9uZyAoTlNOIC0gQ04vU2hh bmdoYWkpPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUiPjxCPkNjOjwv Qj4gPEEgdGl0bGU9Y2NhbXBAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9y ZyI+Y2NhbXBAaWV0Zi5vcmc8L0E+IDsgPEEgDQogIHRpdGxlPXpoYW5nZ3VveWluZ0BtYWlsLnJp dHQuY29tLmNuIA0KICBocmVmPSJtYWlsdG86emhhbmdndW95aW5nQG1haWwucml0dC5jb20uY24i PmV4dCB6aGFuZ2d1b3lpbmc8L0E+IDsgPEEgDQogIHRpdGxlPXh1eXVuYmluQG1haWwucml0dC5j b20uY24gDQogIGhyZWY9Im1haWx0bzp4dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuIj54dXl1bmJp bkBtYWlsLnJpdHQuY29tLmNuPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvO zOUiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIEF1Z3VzdCAxNCwgMjAwOSAzOjA5IEFNPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtDQ0FNUF0g RGlzY3Vzc2lvbiBhYm91dCB0aGUgDQogIEdNUExTIFNpZ25hbGluZyBFeHRlbnNpb248L0RJVj4N CiAgPERJVj48QlI+PC9ESVY+SGkgYWxsOjxCUj48QlI+SSBBZ3JlZSB3aXRoIExpemhvbmcuIDxC Uj48QlI+V2UgdG9vayBzZXZlcmFsIA0KICB5ZWFycyB0byBzdGFuZGFyZGl6ZSB0aGUgR01QTFMg ZXh0ZW5zaW9uIGZvciBPRFUxLCBPRFUyIGFuZCBPRFUzLiANCiAgPEJSPlRlY2hub2xvZ3kgb2Yg T1ROIGlzIGRldmVsb3BpbmcuIFdlIGFsc28gbmVlZCBzb21lIHRpbWUgdG8gc3RhbmRhcmRpemUg dGhlIA0KICBleHRlbnNpb24gZm9yIHRoZSBuZXcgYXBwbGljYXRpb24uIFdlIGNhbiBub3QgZm9y YmlkIHZlbmRvci9jYXJyaWVyIHRvIGRlcGxveSANCiAgdGhlIE9UTiBiYXNlZCBvbiBSRkM0MzI4 IGF0IGFueSB0aW1lLiBXZSBzaG91bGQga2VlcCB0aGVtIGZyb20gd2FpdGluZyBmb3IgdGhlIA0K ICBuZXcgZXh0ZW5zaW9uLiBGdXJ0aGVyIG1vcmUsIGFueSBleHRlbnNpb24gY2FuIG5vdCBjb21w bGV0ZWx5IHByb21pc2UgdG8gZml0IA0KICBhbnkgbmV3IGFwcGxpY2F0aW9uIGluIHRoZSBmdXR1 cmUuIFNvIHdlIGhhdmUgdG8gZGVhbCB3aXRoIGl0IHN0ZXAgYnkgc3RlcC4gDQogIDxGT05UIHNp emU9KzA+PEZPTlQgZmFjZT1WZXJkYW5hPlRoZXJlIGlzIHNvbWUgYmFja3dhcmQgY29tcGF0aWJp bGl0eSANCiAgY29uc2lkZXJhdGlvbnMgYW5kIHNvbHV0aW9uIGluIGRyYWZ0LWNlY2NhcmVsbGlm dXhoPC9GT05UPjwvRk9OVD4uIFRoZXJlIGlzIA0KICBhbHNvIGEgZXh0ZW5zaWJsZSBsYWJsZSBm b3JtYXQgaW4gZHJhZnQtemhhbmcuIFdoeSBzaG91bGQgd2UgdGFrZSBhIGxvbmcgdGltZSANCiAg dG8gc3VydmV5IGl0IGFtb25nIHRoZSBPVE4gc2VydmljZSBwcm92aWRlcnMuIFR3byBkb2N1bWVu dHMgc2hvdWxkIGJlIG1lcmdlZCANCiAgYXMgc29vbiBhcyBwb3NzaWJsZS48QlI+PEJSPkJlZGZv cmQ8QlI+PEJSPjxCPjwvQj48QlI+DQogIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+MjAwOS84LzEy IEppbiwgTGl6aG9uZyAoTlNOIC0gQ04vU2hhbmdoYWkpIDxTUEFOIA0KICBkaXI9bHRyPiZsdDs8 QSANCiAgaHJlZj0ibWFpbHRvOmxpemhvbmcuamluQG5zbi5jb20iPmxpemhvbmcuamluQG5zbi5j b208L0E+Jmd0OzwvU1BBTj48QlI+DQogIDxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0K ICBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB0IDBwdCAwcHQgMC44ZXg7IEJP UkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZCI+DQogICAgPERJViBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYSI+DQogICAgPERJVj48U1BBTj48 Rk9OVCBmYWNlPXZlcmRhbmE+SGkgYWxsOjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj48 U1BBTj5XaGF0IEkgbmVlZCB0byBjbGFyaWZ5IGZyb20gbXkgc2lkZSZuYnNwO2lzIHRoYXQgYWJh bmRvbmluZyBhIFJGQyANCiAgICBpcyBub3QgcHJlZmVycmVkIGluIGFueSBjYXNlLiBJZiB3ZSBj YW4gZGV2ZWxvcCBhIGJhY2t3YXJkIHNvbHV0aW9uIGJ5IA0KICAgIG1lcmdpbmcgZHJhZnQtY2Vj Y2FyZWxsaWZ1eGggYW5kIGRyYWZ0LXpoYW5nLCB3aHkgZG9uJ3Qgd2UgZ28gaW4gdGhpcyANCiAg ICB3YXkuPC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4+PC9TUEFOPiZuYnNwOzwvRElWPg0K ICAgIDxESVY+PFNQQU4+PEZPTlQgZmFjZT12ZXJkYW5hPkJSPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgICA8RElWPjxTUEFOPkxpemhvbmcgSmluPC9TUEFOPjwvRElWPjxCUj4NCiAgICA8RElWIGxh bmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICAgIDxIUj4NCiAgICA8Rk9OVCBmYWNlPVRh aG9tYT48Qj5Gcm9tOjwvQj4gZXh0IHpoYW5nZ3VveWluZyBbbWFpbHRvOjxBIA0KICAgIGhyZWY9 Im1haWx0bzp6aGFuZ2d1b3lpbmdAbWFpbC5yaXR0LmNvbS5jbiIgDQogICAgdGFyZ2V0PV9ibGFu az56aGFuZ2d1b3lpbmdAbWFpbC5yaXR0LmNvbS5jbjwvQT5dIDxCUj48Qj5TZW50OjwvQj4gVHVl c2RheSwgDQogICAgQXVndXN0IDA0LCAyMDA5IDIyOjAzDQogICAgPERJViBjbGFzcz1pbT48QlI+ PEI+VG86PC9CPiBKaW4sIExpemhvbmcgKE5TTiAtIENOL1NoYW5naGFpKTsgPEEgDQogICAgaHJl Zj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiANCiAgICB0YXJnZXQ9X2JsYW5rPmNjYW1wQGlldGYu b3JnPC9BPjxCUj48L0RJVj48Qj5DYzo8L0I+IDxBIA0KICAgIGhyZWY9Im1haWx0bzp6aGFuZ2Zh dGFpQGh1YXdlaS5jb20iIHRhcmdldD1fYmxhbms+emhhbmdmYXRhaUBodWF3ZWkuY29tPC9BPjsg DQogICAgPEEgaHJlZj0ibWFpbHRvOmZ1LnhpaHVhQHp0ZS5jb20uY24iIHRhcmdldD1fYmxhbms+ ZnUueGlodWFAenRlLmNvbS5jbjwvQT47IA0KICAgIDxBIGhyZWY9Im1haWx0bzpkYnJ1bmdhcmRA YXR0LmNvbSIgdGFyZ2V0PV9ibGFuaz5kYnJ1bmdhcmRAYXR0LmNvbTwvQT47IDxBIA0KICAgIGhy ZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiB0YXJnZXQ9X2JsYW5rPmxiZXJnZXJAbGFibi5u ZXQ8L0E+OyA8QSANCiAgICBocmVmPSJtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29t IiANCiAgICB0YXJnZXQ9X2JsYW5rPmRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTwvQT47IDxB IA0KICAgIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIiANCiAg ICB0YXJnZXQ9X2JsYW5rPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L0E+OyA8QSAN CiAgICBocmVmPSJtYWlsdG86eHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbiIgDQogICAgdGFyZ2V0 PV9ibGFuaz54dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuPC9BPg0KICAgIDxESVYgY2xhc3M9aW0+ PEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogUkU6IERpc2N1c3Npb24gYWJvdXQgdGhlIEdNUExTIA0K ICAgIFNpZ25hbGluZyBFeHRlbnNpb248QlI+PC9ESVY+PC9GT05UPjxCUj48L0RJVj4NCiAgICA8 RElWIGNsYXNzPWltPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPVZlcmRh bmEgY29sb3I9IzAwMDA4MD4NCiAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAw MDgwPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+QXMgbWFueSBl eHBlcnRzIGhhdmUgZXhwbGFpbmVkLCB0aGUgbGFiZWwgZW5jb2RpbmcgDQogICAgd2l0aCBiaXQg bWFwIGluIGRyYWZ0LXpoYW5nIGlzJm5ic3A7IHN1cmVseSZuYnNwO2EgYmV0dGVyIHdheSB0byAN CiAgICBhY2hpZXZlJm5ic3A7ZXh0ZW5zaWJpbGl0eSZuYnNwO2FuZCZuYnNwO3NjYWxhYmlsaXR5 IG9mIE9UTiANCiAgICBsYWJsZS4mbmJzcDsmbmJzcDs8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZh Y2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwPlRoZSZuYnNwO21haW4gaXNzdWUmbmJzcDt0aGF0Jm5i c3A7Yml0IA0KICAgIG1hcCZuYnNwO2xhYmVsIGZvcm1hdCZuYnNwO21pZ2h0IGhhdmUmbmJzcDtp cyB0aGUmbmJzcDtiYWNrd29yZCANCiAgICBjb21wYXRpYmlsaXR5LiZuYnNwO0kmbmJzcDt0aGlu ayZuYnNwO3dlIG1pZ2h0IG5lZWQgdG8mbmJzcDtzdGFydCBhbiBzdXJ2ZXkgDQogICAgYW1vbmcg dGhlIE9UTiBzZXJ2aWNlIHByb3ZpZGVycyBpbiB0aGUgbWFpbGluZyBsaXN0LCZuYnNwOyBhbmQg c2VlIGlmIHRoZXJlIA0KICAgIGFyZSBhbnkgT1ROIG5ldHdvcmtzIGRlcGxveWVkIHdpdGggR01Q TFMgUkZDNDMyOCZuYnNwO2xhYmxlIGZvcm1hdC4gDQogICAgPC9GT05UPjwvRElWPg0KICAgIDxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0K ICAgIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODA+SWYgdGhlcmUncmUgbm8g cmVhbCBkZXBsb3ltZW50LCANCiAgICB3ZSZuYnNwO2Rvbid0IG5lZWQgdG8gY29uc2lkZXIgdGhl IGNvbXBhdGFiaWxpdHkgcHJvYmxlbTs8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgY29sb3I9IzAwMDA4MD48Rk9OVCBjb2xvcj0jMDAwMDAwPjxGT05UIA0KICAgIGNv bG9yPSMwMDAwODA+PC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MD48Rk9OVCBjb2xvcj0jMDAwMDAwPjxGT05U IA0KICAgIGNvbG9yPSMwMDAwODA+SWYgdGhlcmUncmUgc29tZSBkZXBsb3ltZW50LCBjb21wYXRh YmlsaXR5IHByb2JsZW0gbmVlZCB0byANCiAgICBiZSZuYnNwO3NvbHZlZCAuIEFuIGVhc3kgd2F5 Jm5ic3A7bWlnaHQgYmUmbmJzcDthZGRpbmcgDQogICAgYW4mbmJzcDtsYWJlbCZuYnNwO3ZlcnNp b24gYml0Jm5ic3A7aW4gdGhlIGxhYmVsIGZvcm1hdCwgb3Igc29tZSBvdGhlciANCiAgICBzb2x1 dGlvbnMgbWF5IGJlIHNlYXJjaGVkIG91dC48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAg ICA8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+ PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwPmJlc3QgcmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwPkd1b3lpbmcgWmhhbmc8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAg PERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQogICAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMD4yMDA5LTA4LTA0IDwv Rk9OVD48L0RJVj48Rk9OVCANCiAgICBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MD4NCiAgICA8 SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0K ICAgIDwvRk9OVD4NCiAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwPjxT UEFOPnpoYW5nZ3VveWluZzwvU1BBTj4gDQogICAgPC9GT05UPjwvRElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jMDAwMDgwPg0KICAgIDxIUj4NCiAgICA8L0ZPTlQ+DQogICAgPERJVj48Rk9O VCBmYWNlPVZlcmRhbmE+PEI+t6K8/sjLo7o8L0I+IEppbiwgTGl6aG9uZyAoTlNOIC0gQ04vU2hh bmdoYWkpIA0KICAgIDwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48 Qj63osvNyrG85KO6PC9CPiAyMDA5LTA4LTA0Jm5ic3A7IDEzOjM0OjI0IDwvRk9OVD48L0RJVj4N CiAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Qj7K1bz+yMujujwvQj4gPEEgaHJlZj0ibWFp bHRvOmNjYW1wQGlldGYub3JnIiANCiAgICB0YXJnZXQ9X2JsYW5rPmNjYW1wQGlldGYub3JnPC9B PiA8L0ZPTlQ+PC9ESVY+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEI+s63L zaO6PC9CPiA8QSBocmVmPSJtYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tIiANCiAgICB0YXJn ZXQ9X2JsYW5rPnpoYW5nZmF0YWlAaHVhd2VpLmNvbTwvQT47IDxBIA0KICAgIGhyZWY9Im1haWx0 bzpmdS54aWh1YUB6dGUuY29tLmNuIiB0YXJnZXQ9X2JsYW5rPmZ1LnhpaHVhQHp0ZS5jb20uY248 L0E+OyA8QSANCiAgICBocmVmPSJtYWlsdG86ZGJydW5nYXJkQGF0dC5jb20iIHRhcmdldD1fYmxh bms+ZGJydW5nYXJkQGF0dC5jb208L0E+OyA8QSANCiAgICBocmVmPSJtYWlsdG86bGJlcmdlckBs YWJuLm5ldCIgdGFyZ2V0PV9ibGFuaz5sYmVyZ2VyQGxhYm4ubmV0PC9BPjsgPEEgDQogICAgaHJl Zj0ibWFpbHRvOmRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSIgDQogICAgdGFyZ2V0PV9ibGFu az5kaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb208L0E+OyA8QSANCiAgICBocmVmPSJtYWlsdG86 ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSIgDQogICAgdGFyZ2V0PV9ibGFuaz5kYW5p ZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9BPjsgPEEgDQogICAgaHJlZj0ibWFpbHRvOnpo YW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuIiANCiAgICB0YXJnZXQ9X2JsYW5rPnpoYW5nZ3Vv eWluZ0BtYWlsLnJpdHQuY29tLmNuPC9BPjsgPEEgDQogICAgaHJlZj0ibWFpbHRvOnh1eXVuYmlu QG1haWwucml0dC5jb20uY24iIA0KICAgIHRhcmdldD1fYmxhbms+eHV5dW5iaW5AbWFpbC5yaXR0 LmNvbS5jbjwvQT4gPC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxC Ptb3zOKjujwvQj4gUkU6IERpc2N1c3Npb24gYWJvdXQgdGhlIEdNUExTIFNpZ25hbGluZyANCiAg ICBFeHRlbnNpb24gPC9GT05UPjwvRElWPg0KICAgIDxESVY+DQogICAgPERJVj48L0RJVj4NCiAg ICA8RElWIGNsYXNzPWg1Pg0KICAgIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjwvRk9OVD48L0RJ Vj4NCiAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYT4NCiAgICA8RElWPkhpJm5ic3A7RmF0YWkm bmJzcDthbmQmbmJzcDthbGw6PC9ESVY+DQogICAgPERJVj5JJm5ic3A7YWdyZWUmbmJzcDt3aXRo Jm5ic3A7dGhlJm5ic3A7aXNzdWVzJm5ic3A7b2YmbmJzcDtleGNlc3NpdmUmbmJzcDtudW1iZXIm bmJzcDtvZiZuYnNwO2xhYmVscyZuYnNwO2lmJm5ic3A7dXNpbmcmbmJzcDt0aGUmbmJzcDtzYW1l PC9ESVY+DQogICAgPERJVj5sYWJlbCZuYnNwO2NvbmNlcHQmbmJzcDtvZiZuYnNwO1JGQzQzMjgu Jm5ic3A7QnkmbmJzcDt1c2luZyZuYnNwO2JpdCZuYnNwO21hcCZuYnNwO2ZvciZuYnNwO2xhYmVs Jm5ic3A7ZW5jb2RpbmcmbmJzcDtpcyZuYnNwO2EmbmJzcDtnb29kPC9ESVY+DQogICAgPERJVj5p ZGVhLiZuYnNwO0FuZCZuYnNwO2Zyb20mbmJzcDtteSZuYnNwO3VuZGVyc3RhbmRpbmcsPC9ESVY+ DQogICAgPERJVj5kcmFmdC1jZWNjYXJlbGxpZnV4aC1jY2FtcC1nbXBscy1leHQtZm9yLWV2b2wt b3RuLTAwJm5ic3A7Y2FuJm5ic3A7bWVyZ2UmbmJzcDt0aGlzJm5ic3A7Yml0PC9ESVY+DQogICAg PERJVj5tYXAmbmJzcDtpZGVhJm5ic3A7aWYmbmJzcDtGYXRhaSZuYnNwO2FncmVlLjwvRElWPg0K ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj5Gb3ImbmJzcDtiYWNrd2FyZCZuYnNwO2Nv bXBhdGliaWxpdHksJm5ic3A7d2UmbmJzcDtjYW4mbmJzcDtub3QmbmJzcDthc3N1bWUmbmJzcDt0 aGF0Jm5ic3A7UkZDNDMyOCZuYnNwO2lzJm5ic3A7bm90PC9ESVY+DQogICAgPERJVj5kZXBsb3ll ZCZuYnNwO3VubGVzcyZuYnNwO3dlJm5ic3A7Y2FuJm5ic3A7cHJvdmlkZSZuYnNwO3NvbWUmbmJz cDtraW5kJm5ic3A7b2YmbmJzcDtzdXJ2ZXkmbmJzcDtyZXBvcnQuJm5ic3A7U28mbmJzcDtjdXJy ZW50bHk8L0RJVj4NCiAgICA8RElWPnRoZSZuYnNwO3JpZ2h0Jm5ic3A7YXNzdW1wdGlvbiZuYnNw O2lzJm5ic3A7dGhhdCZuYnNwO1JGQzQzMjgmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7ZGVwbG95 ZWQsJm5ic3A7YW5kJm5ic3A7YmFja3dhcmQ8L0RJVj4NCiAgICA8RElWPmNvbXBhdGliaXR5Jm5i c3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtjb25zaWRlcmVkLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgPERJVj5CZXN0Jm5ic3A7UmVnYXJkczwvRElWPg0KICAgIDxESVY+TGl6aG9u ZyZuYnNwO0ppbjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPk1lc3NhZ2U6Jm5i c3A7MTwvRElWPg0KICAgIDxESVY+RGF0ZTombmJzcDtUaHUsJm5ic3A7MzAmbmJzcDtKdWwmbmJz cDsyMDA5Jm5ic3A7MTE6MzM6NTYmbmJzcDsrMDIwMDwvRElWPg0KICAgIDxESVY+RnJvbTombmJz cDsiQkVMT1RUSSZuYnNwO1NFUkdJTyImbmJzcDsgJmx0OzxBIA0KICAgIGhyZWY9Im1haWx0bzpT ZXJnaW8uQmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5pdCIgDQogICAgdGFyZ2V0PV9ibGFuaz5TZXJn aW8uQmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5pdDwvQT4gJmd0OzwvRElWPg0KICAgIDxESVY+U3Vi amVjdDombmJzcDtbQ0NBTVBdJm5ic3A7UjombmJzcDtEaXNjdXNzaW9uJm5ic3A7YWJvdXQmbmJz cDt0aGUmbmJzcDtHTVBMUyZuYnNwO1NpZ25hbGluZyZuYnNwO0V4dGVuc2lvbjwvRElWPg0KICAg IDxESVY+Zm9yRXZvbHV0aXZlJm5ic3A7T1ROPC9ESVY+DQogICAgPERJVj5UbzombmJzcDsiRmF0 YWkiJm5ic3A7ICZsdDs8QSBocmVmPSJtYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tIiANCiAg ICB0YXJnZXQ9X2JsYW5rPnpoYW5nZmF0YWlAaHVhd2VpLmNvbTwvQT4gJmd0OywmbmJzcDsgJmx0 OzxBIA0KICAgIGhyZWY9Im1haWx0bzpmdS54aWh1YUB6dGUuY29tLmNuIiB0YXJnZXQ9X2JsYW5r PmZ1LnhpaHVhQHp0ZS5jb20uY248L0E+IA0KICAgICZndDssPC9ESVY+DQogICAgPERJVj4mbHQ7 PEEgaHJlZj0ibWFpbHRvOmRicnVuZ2FyZEBhdHQuY29tIiANCiAgICB0YXJnZXQ9X2JsYW5rPmRi cnVuZ2FyZEBhdHQuY29tPC9BPiAmZ3Q7LCZuYnNwOyAmbHQ7PEEgDQogICAgaHJlZj0ibWFpbHRv OmxiZXJnZXJAbGFibi5uZXQiIHRhcmdldD1fYmxhbms+bGJlcmdlckBsYWJuLm5ldDwvQT4gDQom Z3Q7LDwvRElWPg0KICAgIDxESVY+Jmx0OzxBIGhyZWY9Im1haWx0bzpkaWVnby5jYXZpZ2xpYUBl cmljc3Nvbi5jb20iIA0KICAgIHRhcmdldD1fYmxhbms+ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24u Y29tPC9BPiAmZ3Q7LDwvRElWPg0KICAgIDxESVY+Jmx0OzxBIGhyZWY9Im1haWx0bzpkYW5pZWxl LmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIiANCiAgICB0YXJnZXQ9X2JsYW5rPmRhbmllbGUuY2Vj Y2FyZWxsaUBlcmljc3Nvbi5jb208L0E+ICZndDssPC9ESVY+DQogICAgPERJVj4mbHQ7PEEgaHJl Zj0ibWFpbHRvOnpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuIiANCiAgICB0YXJnZXQ9X2Js YW5rPnpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuPC9BPiAmZ3Q7LDwvRElWPg0KICAgIDxE SVY+Jmx0OzxBIGhyZWY9Im1haWx0bzp4dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuIiANCiAgICB0 YXJnZXQ9X2JsYW5rPnh1eXVuYmluQG1haWwucml0dC5jb20uY248L0E+ICZndDs8L0RJVj4NCiAg ICA8RElWPkNjOiZuYnNwOzxBIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyIgDQogICAgdGFy Z2V0PV9ibGFuaz5jY2FtcEBpZXRmLm9yZzwvQT48L0RJVj4NCiAgICA8RElWPk1lc3NhZ2UtSUQ6 PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWPiZsdDs8QSANCiAgICBocmVmPSJtYWls dG86M0Y0NDE4NkQ3MTQxRTI0Nzk3MkVBQzY2NTVCMEEyOTEwMUZBN0E1NkBGUlZFTFNNQlMyMS5h ZDIuYWQuYWxjYXRlbC5jb20iIA0KICAgIHRhcmdldD1fYmxhbms+M0Y0NDE4NkQ3MTQxRTI0Nzk3 MkVBQzY2NTVCMEEyOTEwMUZBN0E1NkBGUlZFTFNNQlMyMS5hZDIuYWQuYWxjYXRlbC5jb208L0E+ PC9ESVY+DQogICAgPERJVj4mZ3Q7PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWPkNv bnRlbnQtVHlwZTombmJzcDt0ZXh0L3BsYWluOyZuYnNwO2NoYXJzZXQ9Imlzby04ODU5LTEiPC9E SVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPkRlYXImbmJzcDtGYXRhaSZuYnNw O2FuZCZuYnNwO2FsbCw8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5i c3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPldlJm5ic3A7YWdyZWUm bmJzcDtvbiZuYnNwO3RoZSZuYnNwO21ham9yJm5ic3A7cG9pbnRzJm5ic3A7cmFpc2VkJm5ic3A7 YnkmbmJzcDtGYXRhaSZuYnNwO2FzJm5ic3A7Z2VuZXJhbCZuYnNwO2lzc3VlJm5ic3A7dG8mbmJz cDtiZTwvRElWPg0KICAgIDxESVY+c29sdmVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtjb250ZXh0 Jm5ic3A7b2YmbmJzcDtleHRlbnNpb24mbmJzcDtuZWVkZWQmbmJzcDt0byZuYnNwO2NvcGUmbmJz cDt3aXRoJm5ic3A7bmV3Jm5ic3A7Y29udGFpbmVyczwvRElWPg0KICAgIDxESVY+ZGVmaW5lZCZu YnNwO2luJm5ic3A7SVRVJm5ic3A7Jm5ic3A7cTExJm5ic3A7Y29udGV4dCwmbmJzcDtpbiZuYnNw O2FkZGl0aW9uJm5ic3A7dG8mbmJzcDtoYW5kbGluZyZuYnNwO09EVSZuYnNwO211bHRpcGxleGlu ZzwvRElWPg0KICAgIDxESVY+c2NlbmFyaW9zJm5ic3A7aW4mbmJzcDtleGlzdGluZyZuYnNwO09U Ti48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+VGhlcmUmbmJzcDthcmUm bmJzcDt0d28mbmJzcDtiYXNpYyZuYnNwO3BvaW50cyZuYnNwO3RoYXQmbmJzcDticmluZ3MmbmJz cDt0byZuYnNwO3RoZSZuYnNwO25lZWQmbmJzcDt0byZuYnNwO3VwZGF0ZSZuYnNwO3RoZSZuYnNw O1JGQzQzMjg8L0RJVj4NCiAgICA8RElWPmFueXdheS48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwv RElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8 RElWPjEpJm5ic3A7dGhlJm5ic3A7cHJlc2VudCZuYnNwO1JGQyZuYnNwO2RvZXMmbmJzcDtub3Qm bmJzcDtwZXJtaXQmbmJzcDt0aGUmbmJzcDtsaW5rJm5ic3A7YmFzZWQmbmJzcDtuZWdvdGlhdGlv biZuYnNwOyZuYnNwO2ZvciZuYnNwO3RpbWU8L0RJVj4NCiAgICA8RElWPnNsb3QmbmJzcDthbGxv Y2F0aW9uJm5ic3A7LiZuYnNwO05vJm5ic3A7aW5mb3JtYXRpb24mbmJzcDthYm91dCZuYnNwO3Ry aWJ1dGFyeSZuYnNwO3BvcnQmbmJzcDtudW1iZXJzJm5ic3A7aXMmbmJzcDtwcmVzZW50PC9ESVY+ DQogICAgPERJVj5hbmQmbmJzcDtvbmx5Jm5ic3A7aW4mbmJzcDtjYXNlJm5ic3A7d2UmbmJzcDto YXZlJm5ic3A7InNpbmdsZSZuYnNwO2xheWVyIiZuYnNwOywmbmJzcDtubyZuYnNwO211bHRpcGxl eGluZyZuYnNwO0xPJm5ic3A7LS0gDQogICAgJmd0OyZuYnNwO0hPJm5ic3A7eW91PC9ESVY+DQog ICAgPERJVj5jYW4mbmJzcDthcHBseSZuYnNwOy4mbmJzcDtTbyZuYnNwO3RoaXMmbmJzcDtpcyZu YnNwO2EmbmJzcDtsYWNrJm5ic3A7YWdhaW5zdCZuYnNwO3RoZSZuYnNwO29yaWdpbmFsJm5ic3A7 Ry43MDkmbmJzcDtldmVuJm5ic3A7d2l0aG91dDwvRElWPg0KICAgIDxESVY+Y29uc2lkZXJpbmcm bmJzcDtHLjcwOSZuYnNwO0FtMyZuYnNwOy48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0K ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjIp Jm5ic3A7U2NhbGFiaWxpdHk6Jm5ic3A7VGhlJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7cmVxdWlyZWQm bmJzcDtpbiZuYnNwO3RoZSZuYnNwO2NvbnRleHQmbmJzcDtvZiZuYnNwO25ldyZuYnNwO09UTiZu YnNwO3dpdGg8L0RJVj4NCiAgICA8RElWPnRoZSZuYnNwO2ludHJvZHVjdGlvbiZuYnNwO29mJm5i c3A7T0RVMCwmbmJzcDtPRFU0LCZuYnNwO2FuZCZuYnNwO2Fib3ZlJm5ic3A7YWxsJm5ic3A7T0RV ZmxleCZuYnNwOywmbmJzcDtyZXF1aXJlZCZuYnNwO2EmbmJzcDtyZWFsPC9ESVY+DQogICAgPERJ Vj5tb2RpZmljYXRpb25zJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzdHJ1Y3R1cmUmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2xhYmVsJm5ic3A7dG8mbmJzcDthdm9pZCZuYnNwO3JlYWwmbmJzcDtiaWcm bmJzcDtzaXplJm5ic3A7b2Y8L0RJVj4NCiAgICA8RElWPm51bWJlciZuYnNwO29mJm5ic3A7bGFi ZWxzJm5ic3A7dG8mbmJzcDt0cmFuc21pdCZuYnNwO29mZmxvYWRpbmcmbmJzcDtzaWduYWxsaW5n Jm5ic3A7c2Vzc2lvbi4mbmJzcDtFeHRlbnNpb248L0RJVj4NCiAgICA8RElWPmJhc2VkJm5ic3A7 b24mbmJzcDtSRkM0MzI4Jm5ic3A7bG9naWMmbmJzcDtkbyZuYnNwO25vdCZuYnNwO3NjYWxlJm5i c3A7d2hlbiZuYnNwO09EVS1mbGV4Jm5ic3A7aXMmbmJzcDt1c2VkLiZuYnNwO0xhcmdlJm5ic3A7 T0RVPC9ESVY+DQogICAgPERJVj5mbGV4Jm5ic3A7Y29udGFpbmVycyZuYnNwO3dpbGwmbmJzcDtn ZW5lcmF0ZTwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj5hbiZuYnNwO2V4 Y2Vzc2l2ZSZuYnNwO251bWJlciZuYnNwO29mJm5ic3A7bGFiZWxzJm5ic3A7KGluJm5ic3A7cHJp bmNpcGxlJm5ic3A7dXAmbmJzcDt0byZuYnNwOzgwJm5ic3A7cGVyJm5ic3A7bGluaykmbmJzcDtj YXVzaW5nPC9ESVY+DQogICAgPERJVj5wcm9ibGVtcyZuYnNwO3dpdGgmbmJzcDt0aGUmbmJzcDtz aXplJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtSU1ZQLVRFJm5ic3A7bWVzc2FnZS48L0RJVj4NCiAg ICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJz cDs8L0RJVj4NCiAgICA8RElWPlRoaXMmbmJzcDt0d28mbmJzcDtwb2ludHMmbmJzcDt0b2dldGhl ciZuYnNwO2NhbGwmbmJzcDt0byZuYnNwO3RoZSZuYnNwO25lZWQmbmJzcDt0byZuYnNwO2NoYW5n ZSZuYnNwO3NvbWV0aGluZyZuYnNwO2luJm5ic3A7UkZDLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgPERJVj5CYWNrd2FyZCZuYnNwO2NvbXBhdGliaWxpdHkmbmJzcDthc3BlY3Rz LCZuYnNwO3ByZXNlbnQmbmJzcDtpbiZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO2RyYWZ0cywmbmJz cDthcmUmbmJzcDtzdXJlbHkmbmJzcDt0bzwvRElWPg0KICAgIDxESVY+YmUmbmJzcDtjb25zaWRl cmVkJm5ic3A7YW5kJm5ic3A7aWYmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNwO3NpbmdsZSZuYnNw O2xheWVyJm5ic3A7c3lzdGVtcyZuYnNwO2RlcGxveWVkJm5ic3A7dXNpbmc8L0RJVj4NCiAgICA8 RElWPlJGQzQzMjgmbmJzcDt0aGlzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtncmFuZGZhdGhl cmVkLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4N CiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+QmVzdCZuYnNwO1JlZ2FyZHM8L0RJVj4N CiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4m bmJzcDs8L0RJVj4NCiAgICA8RElWPlNlcmdpbzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+ DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+ Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPlNlcmdpbyZuYnNw O0JlbG90dGk8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9E SVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPkNUTyZuYnNwO09wdGljcyZuYnNw O0RpdmlzaW9uPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPkFsY2F0ZWwt THVjZW50PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4rMzkmbmJzcDswMzkmbmJzcDs2ODYz MDMzPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiszOSZuYnNwOzAzOSZu YnNwOzY4NjM1OTA8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPkRh OiZuYnNwOzxBIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIiANCiAgICB0YXJn ZXQ9X2JsYW5rPmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L0E+Jm5ic3A7W21haWx0bzo8QSANCiAg ICBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyIgDQogICAgdGFyZ2V0PV9ibGFu az5jY2FtcC1ib3VuY2VzQGlldGYub3JnPC9BPl0mbmJzcDtQZXImbmJzcDtjb250byZuYnNwO2Rp PC9ESVY+DQogICAgPERJVj5GYXRhaTwvRElWPg0KICAgIDxESVY+SW52aWF0bzombmJzcDttZXJj b2xlZD8mbmJzcDsyOSZuYnNwO2x1Z2xpbyZuYnNwOzIwMDkmbmJzcDsxOC4zMzwvRElWPg0KICAg IDxESVY+QTombmJzcDs8QSBocmVmPSJtYWlsdG86ZnUueGlodWFAenRlLmNvbS5jbiIgDQogICAg dGFyZ2V0PV9ibGFuaz5mdS54aWh1YUB6dGUuY29tLmNuPC9BPjsmbmJzcDs8QSANCiAgICBocmVm PSJtYWlsdG86ZGJydW5nYXJkQGF0dC5jb20iIHRhcmdldD1fYmxhbms+ZGJydW5nYXJkQGF0dC5j b208L0E+OyZuYnNwOzxBIA0KICAgIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiB0YXJn ZXQ9X2JsYW5rPmxiZXJnZXJAbGFibi5uZXQ8L0E+OzwvRElWPg0KICAgIDxESVY+PEEgaHJlZj0i bWFpbHRvOmRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSIgDQogICAgdGFyZ2V0PV9ibGFuaz5k aWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb208L0E+OyZuYnNwOzxBIA0KICAgIGhyZWY9Im1haWx0 bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIiANCiAgICB0YXJnZXQ9X2JsYW5rPmRh bmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L0E+OzwvRElWPg0KICAgIDxESVY+PEEgaHJl Zj0ibWFpbHRvOnpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuIiANCiAgICB0YXJnZXQ9X2Js YW5rPnpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuPC9BPjsmbmJzcDs8QSANCiAgICBocmVm PSJtYWlsdG86eHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbiIgDQogICAgdGFyZ2V0PV9ibGFuaz54 dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuPC9BPjwvRElWPg0KICAgIDxESVY+Q2M6Jm5ic3A7PEEg aHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIiANCiAgICB0YXJnZXQ9X2JsYW5rPmNjYW1wQGll dGYub3JnPC9BPjwvRElWPg0KICAgIDxESVY+T2dnZXR0bzombmJzcDtSZTombmJzcDtbQ0NBTVBd Jm5ic3A7RGlzY3Vzc2lvbiZuYnNwO2Fib3V0Jm5ic3A7dGhlJm5ic3A7R01QTFMmbmJzcDtTaWdu YWxpbmcmbmJzcDtFeHRlbnNpb248L0RJVj4NCiAgICA8RElWPmZvckV2b2x1dGl2ZSZuYnNwO09U TjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAg ICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+SGkmbmJzcDthbGwsPC9ESVY+DQogICAgPERJ Vj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9E SVY+DQogICAgPERJVj5UbyZuYnNwO3N1cHBvcnQmbmJzcDt0aGUmbmJzcDtjdXJyZW50Jm5ic3A7 dmVyaXNvbiZuYnNwO29mJm5ic3A7Ry43MDksJm5ic3A7d2UmbmJzcDt0aGluayZuYnNwO3RoZSZu YnNwO2xhYmVsJm5ic3A7Zm9ybWF0PC9ESVY+DQogICAgPERJVj5kZWZpbmVkJm5ic3A7aW4mbmJz cDtSRkM0MzI4Jm5ic3A7bmVlZCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtyZS1kZWZpbmVkJm5ic3A7 YW55d2F5LiZuYnNwO1RoZSZuYnNwO25ldyZuYnNwO09UTiZuYnNwO2xhYmVsPC9ESVY+DQogICAg PERJVj5mb3JtYXQmbmJzcDtzaG91bGQmbmJzcDtzdXBwb3J0Jm5ic3A7dGhlJm5ic3A7d2hvbGUm bmJzcDtPRFUmbmJzcDtzZXRzLCZuYnNwO25vdCZuYnNwO29ubHkmbmJzcDt0aGUmbmJzcDtPRFUx LCZuYnNwOzIsJm5ic3A7YW5kJm5ic3A7Myw8L0RJVj4NCiAgICA8RElWPmJ1dCZuYnNwO2Fsc28m bmJzcDtPRFUwLCZuYnNwO09EVTQsJm5ic3A7ZXZlbiZuYnNwO09EVUZsZXguJm5ic3A7VGhlJm5i c3A7Zm9sbG93aW5nJm5ic3A7dGhyZWUmbmJzcDthc3BlY3RzJm5ic3A7c2hvdWxkJm5ic3A7YmU8 L0RJVj4NCiAgICA8RElWPmNvbnNpZGVyZWQmbmJzcDtjYXJlZnVsbHk6PC9ESVY+DQogICAgPERJ Vj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9E SVY+DQogICAgPERJVj4xKSZuYnNwO1RoZSZuYnNwO2V4dGVuc2liaWxpdHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2xhYmVsJm5ic3A7Zm9ybWF0Jm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtmaXJzdCZu YnNwO3RoaW5nJm5ic3A7d2UmbmJzcDtzaG91bGQ8L0RJVj4NCiAgICA8RElWPmNvbnNpZGVyLiZu YnNwO1dpdGgmbmJzcDt0aGUmbmJzcDtkZXZlbG9wbWVudCZuYnNwO29mJm5ic3A7T1ROJm5ic3A7 dGVjaG5vbG9neSwmbmJzcDtSRkM0MzI4Jm5ic3A7bGFiZWwmbmJzcDtmb3JtYXQ8L0RJVj4NCiAg ICA8RElWPnN0eWxlJm5ic3A7bmVlZHMmbmJzcDt0byZuYnNwO2JlJm5ic3A7ZXh0ZW5kZWQmbmJz cDt0byZuYnNwO3N1cHBvcnQmbmJzcDt0aGUmbmJzcDtuZXcmbmJzcDtiaXRyYXRlJm5ic3A7T0RV Jm5ic3A7KGVnLiZuYnNwO09EVTUsPC9ESVY+DQogICAgPERJVj42Li4uKS4mbmJzcDtCeSZuYnNw O3RoZSZuYnNwO2VuZCwmbmJzcDt3ZSZuYnNwO21heSZuYnNwO25lZWQmbmJzcDtrZWVwJm5ic3A7 ZXh0ZW5kaW5nJm5ic3A7dGhlJm5ic3A7bGFiZWwmbmJzcDtmb3JtYXRzLjwvRElWPg0KICAgIDxE SVY+TWFuYWdpbmcmbmJzcDtsb3RzJm5ic3A7b2YmbmJzcDtsYWJlbCZuYnNwO2Zvcm1hdCZuYnNw O21heSZuYnNwO2NhdXNlJm5ic3A7YmlnJm5ic3A7dHJvdWJsZSwmbmJzcDtzbyZuYnNwO3dlJm5i c3A7bmVlZCZuYnNwO29uZS1zaG90PC9ESVY+DQogICAgPERJVj5sYWJlbCZuYnNwO2Zvcm1hdCZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO2V2b2x2aW5nJm5ic3A7T1ROLiZuYnNwOyZuYnNwOzwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElW PiZuYnNwOzwvRElWPg0KICAgIDxESVY+MikmbmJzcDtTY2FsYWJpbGl0eSZuYnNwO2lzJm5ic3A7 YW5vdGhlciZuYnNwO2tleSZuYnNwO2lzc3VlLiZuYnNwO1JGQzQzMjgmbmJzcDtzdHlsZSZuYnNw O2Zvcm1hdCZuYnNwO21heSZuYnNwO3Jlc3VsdCZuYnNwO2luPC9ESVY+DQogICAgPERJVj5iaWcm bmJzcDtzaXplJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt0b3RhbCZuYnNwO2xhYmVscywmbmJzcDt3 aGljaCZuYnNwO2RlZmluaXRlbHkmbmJzcDtpbmNyZWFzZSZuYnNwO3RoZSZuYnNwO2J1cmRlbiZu YnNwO29mPC9ESVY+DQogICAgPERJVj50aGUmbmJzcDtzaWduYWxpbmcuJm5ic3A7QW4mbmJzcDtl ZmZpY2llbnQmbmJzcDthcHByb2FjaCZuYnNwO2lzJm5ic3A7bmVlZGVkJm5ic3A7dG8mbmJzcDtj YXJyeSZuYnNwO3RoZSZuYnNwO3NhbWUmbmJzcDtsYWJlbDwvRElWPg0KICAgIDxESVY+aW5mb3Jt YXRpb24mbmJzcDtidXQmbmJzcDt3aXRoJm5ic3A7bGVzcyZuYnNwO2Ftb3VudCZuYnNwO29mJm5i c3A7dGhlJm5ic3A7ZGF0YSwmbmJzcDtiaXRtYXAmbmJzcDtzdHlsZSZuYnNwO2lzJm5ic3A7dGhl Jm5ic3A7cmlnaHQ8L0RJVj4NCiAgICA8RElWPndheSZuYnNwO3RvJm5ic3A7Z28uPC9ESVY+DQog ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5i c3A7PC9ESVY+DQogICAgPERJVj4zKSZuYnNwO0ZvciZuYnNwO2JhY2t3YXJkJm5ic3A7Y29tcGF0 aWJpbGl0eSwmbmJzcDtpZiZuYnNwO3RoZXJlJm5ic3A7YXJlJm5ic3A7bm8mbmJzcDtpbXBsZW1l bnRhdGlvbnMmbmJzcDtmb3I8L0RJVj4NCiAgICA8RElWPlJGQzQzMjgmbmJzcDsob3ImbmJzcDtp ZiZuYnNwO3RoZXJlJm5ic3A7YXJlJm5ic3A7bm8mbmJzcDtkZXBsb3ltZW50cyZuYnNwO2l0Jm5i c3A7aXMmbmJzcDtkZXNpcmFibGUmbmJzcDt0byZuYnNwO2RlcHJlY2F0ZTwvRElWPg0KICAgIDxE SVY+ZXZlbiZuYnNwO2lmJm5ic3A7aXQmbmJzcDtpcyZuYnNwO3VuY29tZm9ydGFibGUmbmJzcDtm b3ImbmJzcDtleGlzdGluZyZuYnNwO2ltcGxlbWVudGF0aW9ucyksJm5ic3A7aXQmbmJzcDtpcyZu YnNwO3Zlcnk8L0RJVj4NCiAgICA8RElWPnNhZmUmbmJzcDt0byZuYnNwO2RlcHJlY2F0ZSZuYnNw O3RoZSZuYnNwO29sZCZuYnNwO2RlZmluaXRpb24sJm5ic3A7YW5kJm5ic3A7YW4mbmJzcDtleHRl bnNpYmxlLCZuYnNwO2VmZmljaWVudCZuYnNwO2FuZDwvRElWPg0KICAgIDxESVY+c2NhbGFibGUm bmJzcDtzb2x1dGlvbiZuYnNwO2NvdWxkJm5ic3A7YmUmbmJzcDtoZWxwZnVsLiZuYnNwO1RoZSZu YnNwO2xhYmVsJm5ic3A7ZGVmaW5lZCZuYnNwO2luJm5ic3A7ZHJhZnQtemhhbmc8L0RJVj4NCiAg ICA8RElWPmRvZXMmbmJzcDtub3QmbmJzcDtvdmVyd3JpdGUmbmJzcDtSRkM0MzI4LCZuYnNwO2l0 Jm5ic3A7Y2FuJm5ic3A7YWxsb3cmbmJzcDt0aGUmbmJzcDtvbGQmbmJzcDtkZWZpbml0aW9uJm5i c3A7dG8mbmJzcDtjb250aW51ZTwvRElWPg0KICAgIDxESVY+dG8mbmJzcDtleGlzdC48L0RJVj4N CiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4m bmJzcDs8L0RJVj4NCiAgICA8RElWPkhvcGUmbmJzcDt0aGlzJm5ic3A7Y2FuJm5ic3A7Y2xhcmlm eSZuYnNwO3lvdXImbmJzcDtjb25jZXJuLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQog ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+QXV0 aG9ycyZuYnNwO29mJm5ic3A7ZHJhZnQtemhhbmc8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElW PiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJ Vj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+LS0tLS0mbmJzcDtPcmlnaW5hbCZu YnNwO01lc3NhZ2UmbmJzcDstLS0tLSZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+ DQogICAgPERJVj5Gcm9tOiZuYnNwOzxBIGhyZWY9Im1haWx0bzpmdS54aWh1YUB6dGUuY29tLmNu IiANCiAgICB0YXJnZXQ9X2JsYW5rPmZ1LnhpaHVhQHp0ZS5jb20uY248L0E+Jm5ic3A7PC9ESVY+ DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPlRvOiZuYnNwOzxBIGhyZWY9Im1haWx0 bzpkYnJ1bmdhcmRAYXR0LmNvbSIgDQogICAgdGFyZ2V0PV9ibGFuaz5kYnJ1bmdhcmRAYXR0LmNv bTwvQT4mbmJzcDs7Jm5ic3A7PEEgDQogICAgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQi IA0KICAgIHRhcmdldD1fYmxhbms+bGJlcmdlckBsYWJuLm5ldDwvQT4mbmJzcDs7Jm5ic3A7PEEg DQogICAgaHJlZj0ibWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbSIgDQogICAgdGFyZ2V0PV9i bGFuaz56aGFuZ2ZhdGFpQGh1YXdlaS5jb208L0E+PC9ESVY+DQogICAgPERJVj47Jm5ic3A7PEEg aHJlZj0ibWFpbHRvOmRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSIgDQogICAgdGFyZ2V0PV9i bGFuaz5kaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb208L0E+Jm5ic3A7OyZuYnNwOzxBIA0KICAg IGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIiANCiAgICB0YXJn ZXQ9X2JsYW5rPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L0E+Jm5ic3A7PC9ESVY+ DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPkNjOiZuYnNwOzxBIGhyZWY9Im1haWx0 bzpjY2FtcEBpZXRmLm9yZyIgDQogICAgdGFyZ2V0PV9ibGFuaz5jY2FtcEBpZXRmLm9yZzwvQT4m bmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+U2VudDombmJzcDtU dWVzZGF5LCZuYnNwO0p1bHkmbmJzcDsyOCwmbmJzcDsyMDA5Jm5ic3A7NTozMyZuYnNwO1BNPC9E SVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPlN1YmplY3Q6Jm5ic3A7RGlzY3Vz c2lvbiZuYnNwO2Fib3V0Jm5ic3A7dGhlJm5ic3A7R01QTFMmbmJzcDtTaWduYWxpbmcmbmJzcDtF eHRlbnNpb24mbmJzcDtmb3I8L0RJVj4NCiAgICA8RElWPkV2b2x1dGl2ZSZuYnNwO09UTjwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElW PiZuYnNwOzwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJVj5IaSZuYnNwO0ZhdGFpJm5i c3A7YW5kJm5ic3A7QWxsLCZuYnNwOzwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJVj5X ZSZuYnNwO2hhdmUmbmJzcDtwcmVzZW50ZWQmbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmcmbmJzcDt0 d28mbmJzcDtkb2N1bWVudCZuYnNwOyZuYnNwO2luJm5ic3A7dGhlJm5ic3A7Q0NBTVA8L0RJVj4N CiAgICA8RElWPm1vcm5pbmcmbmJzcDtzZXNzaW9uLiZuYnNwO0J1dCZuYnNwO3dlJm5ic3A7aGF2 ZSZuYnNwO25vJm5ic3A7bW9yZSZuYnNwO3RpbWUmbmJzcDt0byZuYnNwO2Z1cnRoZXImbmJzcDtk aXNjdXNzJm5ic3A7R01QTFM8L0RJVj4NCiAgICA8RElWPmV4dGVuc2lvbiZuYnNwO2ZvciZuYnNw O2V2b2x1dGl2ZSZuYnNwO09UTiZuYnNwOzwvRElWPg0KICAgIDxESVY+ZHJhZnQtY2VjY2FyZWxs aWZ1eGgtY2NhbXAtZ21wbHMtZXh0LWZvci1ldm9sLW90bi0wMC50eHQ8L0RJVj4NCiAgICA8RElW PiZsdDs8QSANCiAgICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jZWNj YXJlbGxpZnV4aC1jY2FtcC1nbXBscy1leHQtZm9yLWV2byIgDQogICAgdGFyZ2V0PV9ibGFuaz5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jZWNjYXJlbGxpZnV4aC1jY2FtcC1nbXBs cy1leHQtZm9yLWV2bzwvQT48L0RJVj4NCiAgICA8RElWPmwtb3RuLTAwICZndDsmbmJzcDsmbmJz cDs8L0RJVj4NCiAgICA8RElWPmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDkt MDEudHh0PC9ESVY+DQogICAgPERJVj4mbHQ7PEEgDQogICAgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMS50eHQi IA0KICAgIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMS50eHQ8L0E+PC9ESVY+DQogICAgPERJVj4m Z3Q7Jm5ic3A7Jm5ic3A7PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWPldlJm5ic3A7 aGF2ZSZuYnNwO2EmbmJzcDtjb3VwbGUmbmJzcDtvZiZuYnNwO2NvbW1lbnRzJm5ic3A7YW5kJm5i c3A7cXVlc3Rpb25zJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZHJhZnQtemhhbmcuJm5ic3A7PC9E SVY+DQogICAgPERJVj4oMSkmbmJzcDtkcmFmdC16aGFuZyZuYnNwO2RlZmluZWQmbmJzcDt0aGUm bmJzcDtleHRlbnNpb25zJm5ic3A7aW5jbHVkaW5nJm5ic3A7d2hhdCZuYnNwO2hhcyZuYnNwO2Jl ZW48L0RJVj4NCiAgICA8RElWPmRvbmUmbmJzcDtpbiZuYnNwO1JGQzQzMjgmbmJzcDsoaS5lLiwm bmJzcDtPRFUxLCZuYnNwO09EVTImbmJzcDthbmQmbmJzcDtPRFUzKS4mbmJzcDs8L0RJVj4NCiAg ICA8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWNlY2NhcmVs bGlmdXhoJm5ic3A7ZGVmaW5lZCZuYnNwO25ldyZuYnNwO0duZXJhbGl6ZWQmbmJzcDtMYWJlbCZu YnNwO29ubHkmbmJzcDtmb3I8L0RJVj4NCiAgICA8RElWPm5ldyZuYnNwO2FwcGxpY2F0aW9uJm5i c3A7KGkuZS4sJm5ic3A7T0RVMCwmbmJzcDsxLjI1RyZuYnNwO09EVTEsJm5ic3A7MS4yNUcmbmJz cDtPRFUyLCZuYnNwOzEuMjVHJm5ic3A7T0RVMywmbmJzcDtPRFUyZSw8L0RJVj4NCiAgICA8RElW Pk9EVTNlMSwmbmJzcDtPRFUzZTIsJm5ic3A7T0RVZmxleCZuYnNwO2FuZCZuYnNwO09EVTQpLiZu YnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZHJhZnQtY2VjY2FyZWxsaWZ1eGgmbmJzcDtpcyZuYnNwO29ubHkmbmJzcDthJm5ic3A7c3VwcGxl bWVudCZuYnNwO29mJm5ic3A7UkZDNDMyOC4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hvdyZuYnNwO2NhbiZuYnNwO3dlJm5ic3A7dXNl ZCZuYnNwO1JGQzQzMjgmbmJzcDthbmQmbmJzcDtkcmFmdC16aGFuZyZuYnNwOz8mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FueSZuYnNwO3dheSwmbmJzcDtpZiZuYnNwO3dl Jm5ic3A7bmVlZCZuYnNwO3RvJm5ic3A7dXBkYXRlJm5ic3A7YW4mbmJzcDtwcmV2aW91cyZuYnNw O1JGQywmbmJzcDt3ZSZuYnNwO3Nob3VsZDwvRElWPg0KICAgIDxESVY+YXNzdW1lJm5ic3A7dGhh dCZuYnNwO2l0Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO2RlcGxveWVkLCZuYnNwO25vdCZuYnNw O2Fza2luZyZuYnNwO2lmJm5ic3A7c29tZW9uZSZuYnNwO2RpZCZuYnNwO29yJm5ic3A7bm90LiZu YnNwOzwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJVj4oMikmbmJzcDtEbyZuYnNwO3lv dSZuYnNwO3JlYWxseSZuYnNwO3dhbnQmbmJzcDt0byZuYnNwO3JlbW92ZSZuYnNwO05NQyZuYnNw O2Zyb20mbmJzcDt0aGUmbmJzcDtUcmFmZmljPC9ESVY+DQogICAgPERJVj5QYXJhbWV0ZXJzPyZu YnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtkbyZuYnNwO3RoYXQsJm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7d2Um bmJzcDtoYXZlJm5ic3A7dG8mbmJzcDthYmFuZG9uJm5ic3A7UkZDNDMyOC4mbmJzcDs8L0RJVj4N CiAgICA8RElWPjwvRElWPg0KICAgIDxESVY+KDMpJm5ic3A7VGhlJm5ic3A7Y29tcGF0aWJpbGl0 eSZuYnNwO2NvbnNpZGVyYXRpb24mbmJzcDtpbiZuYnNwO2RyYWZ0LXpoYW5nLiZuYnNwOzwvRElW Pg0KICAgIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7V2UmbmJzcDtkb24ndCZuYnNwO3RoaW5rJm5i c3A7dGhlJm5ic3A7ZXh0ZW5zaW9ucyZuYnNwO2luJm5ic3A7ZHJhZnQtemhhbmcmbmJzcDtjYW4m bmJzcDtjb2V4aXN0Jm5ic3A7d2l0aDwvRElWPg0KICAgIDxESVY+UkZDNDMyOC4mbmJzcDs8L0RJ Vj4NCiAgICA8RElWPiZuYnNwOyZuYnNwOyZuYnNwO1lvdSZuYnNwO3BvaW50Jm5ic3A7b3V0Jm5i c3A7IndlJm5ic3A7Y2FuJm5ic3A7anVzdCZuYnNwO2RvJm5ic3A7c29tZSZuYnNwO3RyYW5zbGF0 aW9uJm5ic3A7b3ImbmJzcDttYXBwaW5nJm5ic3A7aW48L0RJVj4NCiAgICA8RElWPnRoZSZuYnNw O25ldyZuYnNwO25vZGVzIi4mbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOyZuYnNwOyZuYnNw O0J1dCZuYnNwO2JlZm9yZSZuYnNwO3RoZSZuYnNwO3RyYW5zbGF0aW9uJm5ic3A7b3ImbmJzcDtt YXBwaW5nLCZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDt0byZuYnNwO2tub3cmbmJzcDt0aGU8L0RJ Vj4NCiAgICA8RElWPkdlbmVyYWxpemVkJm5ic3A7TGFiZWwmbmJzcDtGb3JtYXQuJm5ic3A7Jm5i c3A7Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtXZSZuYnNwO2NvbmNl cm4mbmJzcDthYm91dDombmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOyZu YnNwOyZuYnNwO2kpJm5ic3A7Jm5ic3A7SG93Jm5ic3A7ZG9lcyZuYnNwO29uZSZuYnNwO25vZGUm bmJzcDtrbm93Jm5ic3A7dGhlJm5ic3A7R2VuZXJhbGl6ZWQmbmJzcDtMYWJlbCZuYnNwO2Zvcm1h dCw8L0RJVj4NCiAgICA8RElWPmVzcGVjaWFsbHkmbmJzcDtmb3ImbmJzcDtPRFUxLCZuYnNwO09E VTImbmJzcDthbmQmbmJzcDtPRFUzJm5ic3A7YmFzZSZuYnNwO29uJm5ic3A7eW91ciZuYnNwO3Nv bHV0aW9uPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SXQmbmJzcDttYXkm bmJzcDtkZXBlbmQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2NhcGFiaWxpdHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2FkamFjZW50Jm5ic3A7bmV0d29yazwvRElWPg0KICAgIDxESVY+ZWxlbWVudC4m bmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOyZuYnNwOyZuYnNwO2lpKSZuYnNwO0J1dCZuYnNw O2hvdyZuYnNwO2NhbiZuYnNwO3RoZSZuYnNwO2NvbnRyb2wmbmJzcDtwbGFuZSZuYnNwO2tub3cm bmJzcDt0aGUmbmJzcDthZGphY2VudCZuYnNwO25ldHdvcms8L0RJVj4NCiAgICA8RElWPmVsZW1l bnQncyZuYnNwO2NhcGFiaWxpdHkmbmJzcDt3aXRob3V0Jm5ic3A7ZGlzY292ZXJ5Jm5ic3A7bWVj aGFuaXNtPyZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7WW91Jm5ic3A7c2hvdWxkJm5ic3A7a25vdyZuYnNwO3RoYXQmbmJzcDtH TVBMUyZuYnNwO3NpZ25hbGluZyZuYnNwO2V4dGVuc2lvbiZuYnNwO3Nob3VsZCZuYnNwO2JlPC9E SVY+DQogICAgPERJVj5pbmRlcGVuZGVudCZuYnNwO29uJm5ic3A7dGhlJm5ic3A7ZGlzY292ZXJ5 Jm5ic3A7bWVjaGFuaXNtJm5ic3A7YW5kJm5ic3A7dGhlJm5ic3A7Y29uZmlndXJhdGlvbiZuYnNw O29mPC9ESVY+DQogICAgPERJVj5tYW5hZ2VtZW50Jm5ic3A7cGxhbmUuJm5ic3A7PC9ESVY+DQog ICAgPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtpaWkpJm5ic3A7VGhlJm5ic3A7Y29udHJvbCZuYnNw O3BsYW5lJm5ic3A7ZG9uJ3QmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDtrbm93Jm5ic3A7dGhlJm5i c3A7Ry43MDkoMjAwMy8wMyk8L0RJVj4NCiAgICA8RElWPm9yJm5ic3A7Ry43MDkmbmJzcDtBbWVu ZG1lbnQzJm5ic3A7bmV0d29yayZuYnNwO2VsZW1lbnQ/Jm5ic3A7PC9ESVY+DQogICAgPERJVj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0luJm5ic3A7YSZuYnNwO3dvcmQsJm5ic3A7d2UmbmJz cDt0aGluayZuYnNwO2l0Jm5ic3A7Y2FuJm5ic3A7bm90Jm5ic3A7ZG8mbmJzcDt0aGUmbmJzcDt0 cmFuc2xhdGlvbiZuYnNwO2FuZDwvRElWPg0KICAgIDxESVY+bWFwcGluZy4mbmJzcDtTbyZuYnNw O3dlJm5ic3A7Y2FuJm5ic3A7bm90Jm5ic3A7Z2V0Jm5ic3A7dGhlJm5ic3A7Y29tcGF0aWJpbGl0 eSZuYnNwO3dpdGgmbmJzcDtSRkM0MzI4Jm5ic3A7aW48L0RJVj4NCiAgICA8RElWPmRyYWZ0LXpo YW5nLiZuYnNwOzwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJVj4mbmJzcDsoNCkmbmJz cDtUaGUmbmJzcDtHZW5lcmFsaXplZCZuYnNwO0xhYmVsJm5ic3A7aW4mbmJzcDtkcmFmdC16aGFu ZyZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO21h bmFnaW5nJm5ic3A7YSZuYnNwO3ZhcmlhYmxlJm5ic3A7bGVuZ3RoJm5ic3A7bGFiZWwmbmJzcDtj b3VsZCZuYnNwO2JlJm5ic3A7YSZuYnNwO21lc3MuJm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7ZHJhZnQtemhhbmcmbmJzcDt1c2VzJm5ic3A7YSZu YnNwO2ZpcnN0Jm5ic3A7cGFydCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bGFiZWwmbmJzcDt3aGlj aCZuYnNwO2hhcyZuYnNwO2ZpeGVkPC9ESVY+DQogICAgPERJVj52YWx1ZXMmbmJzcDthbmQmbmJz cDt0aGVuJm5ic3A7YSZuYnNwO3ZhcmlhYmxlJm5ic3A7bnVtYmVyJm5ic3A7b2YmbmJzcDtiaXQm bmJzcDt0aGF0Jm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtiaXRtYXAuJm5ic3A7PC9ESVY+DQogICAg PERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUmbmJzcDti aXRtYXAmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO2xvbmcmbmJzcDtmcm9tJm5ic3A7MCZuYnNwO3Rv Jm5ic3A7ODAmbmJzcDtiaXRzJm5ic3A7ZGVwZW5kaW5nJm5ic3A7b24mbmJzcDt0aGU8L0RJVj4N CiAgICA8RElWPnNpZ25hbCZuYnNwO3R5cGUuJm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7dGhlJm5ic3A7dmFsdWUmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2JpdG1hcCZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7aW5kZXBlbmRlbnQmbmJzcDtidXQmbmJz cDtkZXBlbmRzJm5ic3A7b248L0RJVj4NCiAgICA8RElWPnRoZSZuYnNwO3ZhbHVlcyZuYnNwO29m Jm5ic3A7dHdvJm5ic3A7cHJldmlvdXMmbmJzcDtmaWVsZHMmbmJzcDsoT0RVayZuYnNwO2FuZCZu YnNwO09EVWopJm5ic3A7YW5kJm5ic3A7YmVjb21lcyZuYnNwO3Jlc2VydmVkPC9ESVY+DQogICAg PERJVj5pbiZuYnNwO2Nhc2UmbmJzcDtvZiZuYnNwO0s9SiZuYnNwOzwvRElWPg0KICAgIDxESVY+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO2EmbmJzcDtiaXRtYXAmbmJzcDtsYWJlbCZu YnNwO2hhdmUmbmJzcDtub3QmbmJzcDtiZWVuJm5ic3A7dXNlZCZuYnNwO25vciZuYnNwO2luJm5i c3A7U0RIJm5ic3A7YW5kJm5ic3A7bm90Jm5ic3A7aW48L0RJVj4NCiAgICA8RElWPldTT04mbmJz cDt3aGVyZSZuYnNwO2EmbmJzcDtmaXhlZCZuYnNwO2xhYmVsJm5ic3A7KDQmbmJzcDtieXRlcykm bmJzcDtpcyZuYnNwO3VzZWQuJm5ic3A7PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElW PlhpaHVhJm5ic3A7RnUmbmJzcDs8L0RJVj4NCiAgICA8RElWPlpURSZuYnNwOzwvRElWPg0KICAg IDxESVY+PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAg IDxESVY+LS0tLS0tLS0tLS0tLS0mbmJzcDtuZXh0Jm5ic3A7cGFydCZuYnNwOy0tLS0tLS0tLS0t LS0tPC9ESVY+DQogICAgPERJVj5BbiZuYnNwO0hUTUwmbmJzcDthdHRhY2htZW50Jm5ic3A7d2Fz Jm5ic3A7c2NydWJiZWQuLi48L0RJVj4NCiAgICA8RElWPlVSTDo8L0RJVj4NCiAgICA8RElWPiZs dDs8QSANCiAgICBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2Nh bXAvYXR0YWNobWVudHMvMjAwOTA3MzAvYmZjZWM1MCIgDQogICAgdGFyZ2V0PV9ibGFuaz5odHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2NhbXAvYXR0YWNobWVudHMvMjAwOTA3 MzAvYmZjZWM1MDwvQT48L0RJVj4NCiAgICA8RElWPjQvYXR0YWNobWVudC5odG0gJmd0OzwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCiAgICA8RElWPkND QU1QJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCiAgICA8RElWPjxBIGhyZWY9Im1haWx0 bzpDQ0FNUEBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5DQ0FNUEBpZXRmLm9yZzwvQT48L0RJVj4N CiAgICA8RElWPjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXAiIA0KICAgIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcDwvQT48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+ Jm5ic3A7PC9ESVY+DQogICAgPERJVj5FbmQmbmJzcDtvZiZuYnNwO0NDQU1QJm5ic3A7RGlnZXN0 LCZuYnNwO1ZvbCZuYnNwOzE0LCZuYnNwO0lzc3VlJm5ic3A7MjY8L0RJVj4NCiAgICA8RElWPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L0RJVj48L0ZPTlQ+PC9ESVY+PC9E SVY+PC9ESVY+PC9ESVY+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPEJSPkNDQU1QIA0KICAgIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86 Q0NBTVBAaWV0Zi5vcmciPkNDQU1QQGlldGYub3JnPC9BPjxCUj48QSANCiAgICBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wIiANCiAgICB0YXJnZXQ9X2Js YW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L0E+PEJSPjxC Uj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPg0KICA8UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5DQ0FNUCBtYWls aW5nIA0KICBsaXN0PEJSPkNDQU1QQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXA8QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_qv5TSn5u376u96JQb/zV7g)-- From root@core3.amsl.com Fri Aug 14 01:00:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A6B743A67B6; Fri, 14 Aug 2009 01: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: <20090814080001.A6B743A67B6@core3.amsl.com> Date: Fri, 14 Aug 2009 01:00:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-confirm-data-channel-status-06.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, 14 Aug 2009 08:00:01 -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 : Data Channel Status Confirmation Extensions for the Link Management Protocol Author(s) : D. Li, et al. Filename : draft-ietf-ccamp-confirm-data-channel-status-06.txt Pages : 16 Date : 2009-08-14 This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. Li Expires February 2010 [page 1] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 Conventions used in this document 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-06.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-confirm-data-channel-status-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-14005341.I-D@ietf.org> --NextPart-- From danli@huawei.com Fri Aug 14 01:14:26 2009 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 D398A3A6A63 for ; Fri, 14 Aug 2009 01:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, 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 ABXKlrlhIlAH for ; Fri, 14 Aug 2009 01:14:24 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 27C9B3A6A5A for ; Fri, 14 Aug 2009 01:14:08 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC00H12X9FC6@szxga02-in.huawei.com> for ccamp@ietf.org; Fri, 14 Aug 2009 16:08:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC00C5HX9FLJ@szxga02-in.huawei.com> for ccamp@ietf.org; Fri, 14 Aug 2009 16:08:03 +0800 (CST) Received: from l37133a ([10.70.77.54]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOC00MT7X9FI4@szxml04-in.huawei.com> for ccamp@ietf.org; Fri, 14 Aug 2009 16:08:03 +0800 (CST) Date: Fri, 14 Aug 2009 16:08:03 +0800 From: Dan Li To: ccamp@ietf.org Message-id: <012101ca1cb6$58fe3200$364d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/mixed; boundary="Boundary_(ID_2wugI3PSf5qGZyp7KuU+Hg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-confirm-data-channel-status-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: Fri, 14 Aug 2009 08:14:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_2wugI3PSf5qGZyp7KuU+Hg) Content-type: multipart/alternative; boundary="Boundary_(ID_SEwamcmwGw31t4KmGAVzGA)" --Boundary_(ID_SEwamcmwGw31t4KmGAVzGA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi All, We have uploaded a new version (06) of draft-ietf-ccamp-data-channel-status, the only changes are following: 1) According to the result of discussion in IETF 75th meeting, the clarification "To use this mechanisms all nodes MUST have the extensions described in this document for compatibility." is added in section 4.4. 2) We also aware of the assignment about the number of message types. The "Trace Message" occupied the type number from 21 to 31, so we suggest that 32 to 34 could be used for data channel confirmation messages. Changes are in section 7.1. To CCAMP co-chairs: We think this document is ready to move forward. Thanks, Dan ----- Original Message ----- From: IETF I-D Submission Tool To: danli@huawei.com Cc: xuhuiying@huawei.com ; zhangfatai@huawei.com ; snigdho.bardalai@us.fujitsu.com ; julien.meuric@orange-ftgroup.com ; diego.caviglia@ericsson.com Sent: Friday, August 14, 2009 3:53 PM Subject: New Version Notification for draft-ietf-ccamp-confirm-data-channel-status-06 A new version of I-D, draft-ietf-ccamp-confirm-data-channel-status-06.txt has been successfuly submitted by Dan Li and posted to the IETF repository. Filename: draft-ietf-ccamp-confirm-data-channel-status Revision: 06 Title: Data Channel Status Confirmation Extensions for the Link Management Protocol Creation_date: 2009-08-14 WG ID: ccamp Number_of_pages: 16 Abstract: This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. Li Expires February 2010 [page 1] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 Conventions used in this document 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 [RFC2119]. The IETF Secretariat. --Boundary_(ID_SEwamcmwGw31t4KmGAVzGA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzU2MiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZM+SGkgQWxsLDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPeWui+S9kz5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gKDA2 KSBvZiANCmRyYWZ0LWlldGYtY2NhbXAtZGF0YS1jaGFubmVsLXN0YXR1cywgdGhlIG9ubHkgY2hh bmdlcyBhcmUgDQpmb2xsb3dpbmc6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9 kz4xKSBBY2NvcmRpbmcgdG8gdGhlIHJlc3VsdCBvZiBkaXNjdXNzaW9uIGluIElFVEYgNzV0aCAN Cm1lZXRpbmcsIHRoZSBjbGFyaWZpY2F0aW9uICJUbyB1c2UgdGhpcyBtZWNoYW5pc21zIGFsbCBu b2RlcyBNVVNUIGhhdmUmbmJzcDt0aGUgDQpleHRlbnNpb25zIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50IGZvciBjb21wYXRpYmlsaXR5LiIgaXMgYWRkZWQgaW4gc2VjdGlvbiANCjQuNC48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPjIpIFdlIGFsc28gYXdhcmUmbmJzcDtv ZiB0aGUgYXNzaWdubWVudCBhYm91dCB0aGUgbnVtYmVyIG9mIA0KbWVzc2FnZSB0eXBlcy4gVGhl ICJUcmFjZSBNZXNzYWdlIiBvY2N1cGllZCB0aGUgdHlwZSBudW1iZXIgZnJvbSAyMSB0byAzMSwg c28gd2UgDQpzdWdnZXN0IHRoYXQgMzIgdG8gMzQgY291bGQgYmUgdXNlZCBmb3IgZGF0YSBjaGFu bmVsIGNvbmZpcm1hdGlvbiBtZXNzYWdlcy4gDQpDaGFuZ2VzIGFyZSBpbiBzZWN0aW9uIDcuMS48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT3lrovkvZM+VG8gQ0NBTVAgY28tY2hhaXJzOiBXZSB0aGluayB0aGlz IGRvY3VtZW50IGlzIHJlYWR5IHRvIG1vdmUgDQpmb3J3YXJkLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWu i+S9kz5UaGFua3MsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kz48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPkRhbjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQo8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+ RnJvbTo8L0I+IDxBIA0KdGl0bGU9aWRzdWJtaXNzaW9uQGlldGYub3JnIGhyZWY9Im1haWx0bzpp ZHN1Ym1pc3Npb25AaWV0Zi5vcmciPklFVEYgSS1EIA0KU3VibWlzc2lvbiBUb29sPC9BPiA8L0RJ Vj4NCjxESVY+PEI+VG86PC9CPiA8QSB0aXRsZT1kYW5saUBodWF3ZWkuY29tIA0KaHJlZj0ibWFp bHRvOmRhbmxpQGh1YXdlaS5jb20iPmRhbmxpQGh1YXdlaS5jb208L0E+IDwvRElWPg0KPERJVj48 Qj5DYzo8L0I+IDxBIHRpdGxlPXh1aHVpeWluZ0BodWF3ZWkuY29tIA0KaHJlZj0ibWFpbHRvOnh1 aHVpeWluZ0BodWF3ZWkuY29tIj54dWh1aXlpbmdAaHVhd2VpLmNvbTwvQT4gOyA8QSANCnRpdGxl PXpoYW5nZmF0YWlAaHVhd2VpLmNvbSANCmhyZWY9Im1haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5j b20iPnpoYW5nZmF0YWlAaHVhd2VpLmNvbTwvQT4gOyA8QSANCnRpdGxlPXNuaWdkaG8uYmFyZGFs YWlAdXMuZnVqaXRzdS5jb20gDQpocmVmPSJtYWlsdG86c25pZ2Roby5iYXJkYWxhaUB1cy5mdWpp dHN1LmNvbSI+c25pZ2Roby5iYXJkYWxhaUB1cy5mdWppdHN1LmNvbTwvQT4gDQo7IDxBIHRpdGxl PWp1bGllbi5tZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tIA0KaHJlZj0ibWFpbHRvOmp1bGllbi5t ZXVyaWNAb3JhbmdlLWZ0Z3JvdXAuY29tIj5qdWxpZW4ubWV1cmljQG9yYW5nZS1mdGdyb3VwLmNv bTwvQT4gDQo7IDxBIHRpdGxlPWRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbSANCmhyZWY9Im1h aWx0bzpkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20iPmRpZWdvLmNhdmlnbGlhQGVyaWNzc29u LmNvbTwvQT4gPC9ESVY+DQo8RElWPjxCPlNlbnQ6PC9CPiBGcmlkYXksIEF1Z3VzdCAxNCwgMjAw OSAzOjUzIFBNPC9ESVY+DQo8RElWPjxCPlN1YmplY3Q6PC9CPiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIA0KZHJhZnQtaWV0Zi1jY2FtcC1jb25maXJtLWRhdGEtY2hhbm5lbC1zdGF0dXMt MDY8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPjxCUj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwg DQpkcmFmdC1pZXRmLWNjYW1wLWNvbmZpcm0tZGF0YS1jaGFubmVsLXN0YXR1cy0wNi50eHQgaGFz IGJlZW4gc3VjY2Vzc2Z1bHkgDQpzdWJtaXR0ZWQgYnkgRGFuIExpIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS48QlI+PEJSPkZpbGVuYW1lOiANCmRyYWZ0LWlldGYtY2NhbXAtY29u ZmlybS1kYXRhLWNoYW5uZWwtc3RhdHVzPEJSPlJldmlzaW9uOiAwNjxCUj5UaXRsZTogRGF0YSAN CkNoYW5uZWwgU3RhdHVzIENvbmZpcm1hdGlvbiBFeHRlbnNpb25zIGZvciB0aGUgTGluayBNYW5h Z2VtZW50IA0KUHJvdG9jb2w8QlI+Q3JlYXRpb25fZGF0ZTogMjAwOS0wOC0xNDxCUj5XRyBJRDog Y2NhbXA8QlI+TnVtYmVyX29mX3BhZ2VzOiANCjE2PEJSPjxCUj5BYnN0cmFjdDo8QlI+VGhpcyBk b2N1bWVudCBkZWZpbmVzIHNpbXBsZSBhZGRpdGlvbnMgdG8gdGhlIExpbmsgDQpNYW5hZ2VtZW50 IDxCUj5Qcm90b2NvbCAoTE1QKSB0byBwcm92aWRlIGEgY29udHJvbCBwbGFuZSB0b29sIHRoYXQg Y2FuIGFzc2lzdCBpbiANCjxCUj50aGUgbG9jYXRpb24gb2Ygc3RyYW5kZWQgcmVzb3VyY2VzIGJ5 IGFsbG93aW5nIGFkamFjZW50IExTUnMgdG8gPEJSPmNvbmZpcm0gDQpkYXRhIGNoYW5uZWwgc3Rh dHVzZXMsIGFuZCBwcm92aWRlcyB0cmlnZ2VycyBmb3Igbm90aWZ5aW5nIDxCUj50aGUgbWFuYWdl bWVudCANCnBsYW5lIGlmIGFueSBkaXNjcmVwYW5jaWVzIGFyZSBmb3VuZC4gQXMgTE1QIGlzIDxC Uj5hbHJlYWR5IHVzZWQgdG8gdmVyaWZ5IGRhdGEgDQpwbGFuZSBjb25uZWN0aXZpdHksIGl0IGlz IGNvbnNpZGVyZWQgdG8gPEJSPmJlIGFuIGFwcHJvcHJpYXRlIGNhbmRpZGF0ZSB0byANCnN1cHBv cnQgdGhpcyBmZWF0dXJlLiANCjxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPiZuYnNwOzxCUj5MaTxC Uj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj5FeHBpcmVzIEZlYnJ1YXJ5IA0KMjAxMDxCUj48QlI+ PEJSPjxCUj48QlI+Jm5ic3A7IFtwYWdlIDFdIA0KPEJSPjxCUj5kcmFmdC1pZXRmLWNjYW1wLWNv bmZpcm0tZGF0YS1jaGFubmVsLXN0YXR1cy0wNi50eHQ8QlI+PEJSPjxCUj5BdWd1c3QgDQoyMDA5 IDxCUj4mbmJzcDs8QlI+PEJSPkNvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCA8QlI+ PEJSPlRoZSBrZXkgd29yZHMgDQoiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLCA8QlI+IlNIT1VMRCIsICJTSE9VTEQgDQpOT1QiLCAiUkVDT01NRU5E RUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyA8QlI+ZG9jdW1lbnQgYXJlIHRvIGJl IA0KaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIA0KW1JGQzIxMTldLjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+PEJSPjxCUj5UaGUgSUVURiBTZWNyZXRhcmlhdC48 QlI+PEJSPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_SEwamcmwGw31t4KmGAVzGA)-- --Boundary_(ID_2wugI3PSf5qGZyp7KuU+Hg) Content-type: text/plain; name=draft-ietf-ccamp-confirm-data-channel-status-06.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-ccamp-confirm-data-channel-status-06.txt Network Working Group D. Li Internet Draft H. Xu Category: Standards Track Huawei S. Bardalai Fujitsu J. Meuric France Telecom D. Caviglia Ericsson Expires: February 2010 August 14, 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol draft-ietf-ccamp-confirm-data-channel-status-06.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. Li Expires February 2010 [Page 1] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. Problem Explanation..........................................4 2.1. Mismatch Caused by Manual Configuration.................4 2.2. Mismatch Caused by LSP Deletion.........................5 2.3. Failed Resources........................................5 3. Motivation...................................................6 4. Extensions to LMP............................................7 4.1. Confirm Data Channel Status Messages....................7 4.1.1. ConfirmDataChannelStatus Messages..................7 4.1.2. ConfirmDataChannelStatusAck Messages...............8 4.1.3. ConfirmDataChannelStatusNack Messages..............8 4.2. Data Channel Status Subobject...........................9 4.3. Message Construction...................................10 4.4. Backward Compatibility.................................10 5. Procedures..................................................10 6. Security Considerations.....................................11 7. IANA Considerations.........................................12 7.1. LMP Message Types......................................12 7.2. LMP Data Link Object Subobject.........................12 8. Acknowledgments.............................................12 9. References..................................................13 9.1. Normative References...................................13 9.2. Informative References.................................13 10. Authors' Addresses.........................................13 11. Full Copyright Statement...................................15 12. Intellectual Property Statement............................15 13. Disclaimer of Validity.....................................16 1. Introduction Generalized Multiprotocol Label Switching (GMPLS) networks are constructed from Traffic Engineering (TE) links connecting Label Switching Routers (LSRs). The TE links are constructed from a set of data channels. In this context, a data channel corresponds to a resource label in a non-packet technology (such as a timeslot or a lambda). Li Expires February 2010 [Page 2] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 A data channel status mismatch exists if the LSR at one end of a TE link believes that the data channel is assigned to carry data, but the LSR at the other end does not. The term "ready to carry data" means cross-connected or bound to an end-point for the receipt or delivery of data. Data channel mismatches cannot be detected from the TE information advertised by the routing protocols [RFC4203], [RFC4205]. The existence of some data channel mismatch problems may be detected by a mismatch in the advertised bandwidths where bidirectional TE links and bidirectional services are in use, but where unidirectional services exist, or where multiple data channel mismatches occur, it is not possible to detect such errors through the routing protocol- advertised TE information. In any case, there is no mechanism to isolate the mismatches by determining which data channels are at fault. If a data channel mismatch exists, any attempt to use the data channel for a new LSP will fail. One end of the TE link may attempt to assign the TE link for use, but the other end will report the data channel as unavailable when the control plane or management plane attempts to assign it to an LSP. Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up. When many LSPs are to be set up, and when there are many data channel mismatches, such inefficiencies become significant. It is desirable to avoid the additional signaling overhead, and to report the problems to the management plane so that they can be resolved to improve the efficiency of LSP setup. Correspondingly, such a mismatch situation may give rise to misconnections in the data plane especially when LSPs are set up using management plane operations. Resources (data channels) that are in a mismatched state are often described as "stranded resources". They are not in use for any LSP, but they cannot be assigned for use by a new LSP because they appear to be in use. Although it is theoretically possible for management plane applications to audit all network resources to locate stranded resources and to release them, this process is rarely performed because of the difficulty of coordinating different Element Management Systems (EMSs), and the associated risks of accidentally releasing in-use resources. It is desirable to have a control plane mechanism that detects and reports stranded resources. Li Expires February 2010 [Page 3] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. 2. Problem Explanation Examples of data channel mismatches are described in the following three scenarios. In all of the scenarios, the specific channel resource of a data link will be unavailable because of the data channel status mismatch, and this channel resource will be wasted. Furthermore, a data channel status mismatch may reduce the possibility of successful LSP establishment, because a data channel status mismatch may result in failure when establishing an LSP. So it is desirable to confirm the data channel statuses as early as possible. 2.1. Mismatch Caused by Manual Configuration The operator may have configured a cross-connect at only one end of a TE link using an EMS. The resource at one end of the data channel is allocated, but the corresponding resource is still available at the other end of the same data channel. In this case, the data channel may appear to be available for use by the control plane when viewed from one end of the TE link, but will be considered to be unavailable by the other end of the TE link. Alternatively, the available end of the data channel may be cross-connected by the management plane and a misconnection may result from the fact that the other end of the data channel is already cross-connected. Figure 1 shows a data channel between nodes A and B. The resource at A's end of the TE link is allocated through manual configuration, while the resource at B's end of the TE link available, so the data channel status is mismatched. allocated available +-+------------+-+ A |x| | | B +-+------------+-+ data channel Li Expires February 2010 [Page 4] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 Figure 1. Mismatch caused by manual configuration 2.2. Mismatch Caused by LSP Deletion The channel status of a data link may become mismatched during the LSP deletion process. If the LSP deletion process is aborted in the middle of the process (perhaps because of a temporary control plane failure), the cross-connect at the upstream node may be removed while the downstream node still keeps its cross-connect, if the LSP deletion was initiated by the source node. For example, in Figure 2 an LSP traverses nodes A, B, and C. Node B resets abnormally when the LSP is being deleted. This results in the cross-connects of node A and C being removed, but the cross-connect of node B still being in use. So the data channel statuses between nodes A and B, and between nodes B and C are both mismatched. <---------LSP---------> +-+-------+-+-------+-+ | | |X| | | +-+-------+-+-------+-+ A B C Figure 2. Mismatch caused by LSP deletion In [RFC2205] and [RFC3209], a soft state mechanism was defined to prevent state discrepancies between LSRs. RSVP-TE restart processes ([RFC3473], [RFC5063]) have been defined: adjacent LSRs may resynchronize their control plane state to reinstate information about LSPs that have persisted in the data plane. Both mechanisms aim at keeping state consistency among nodes and allow LSRs to detect mismatched data plane states. The data plane handling of such mismatched state can be treated as a local policy decision. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use. In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures. 2.3. Failed Resources Even if the situation is not common, it might happen that a termination point of a TE-link is seen as failed by one end, while on the other end it is seen as OK. This problem may arise due to Li Expires February 2010 [Page 5] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 some failure either in the hardware or in the status detection of the termination point. This mismatch in the termination point status can lead to failure in case of bidirectional LSP set-up. Good Failed +-+------------+-+ A | | |X| B +-+------------+-+ data channel Path Message with Upstream Label----> Figure 3. Mismatch caused by resource failure In this case upstream node chooses to use termination point A in order to receive traffic from downstream node. From the upstream node's point of view, the resource is available thus usable; however, in the downstream node, the corresponding termination point (resource B) is broken. This leads to a set-up failure. 3. Motivation The requirement does not come from a lack in GMPLS specifications themselves but rather from operational concerns because, in most cases, GMPLS-controlled networks will co-exist with legacy networks and legacy procedures. The protocol extensions defined in this document are intended to detect data plane problems resulting from mis-use or mis- configurations triggered by user error, or resulting from failure to clean up the data plane after control plane disconnection. It is anticipated that human mistake is probably the major source of errors to deal with. It is not the intention to provide a protocol mechanism to deal with broken implementations. The procedures defined in this document are designed to be operated on a periodic or on-demand basis. It is NOT RECOMMENDED that the procedures be used to provide a continuous and on-line monitoring process. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. Li Expires February 2010 [Page 6] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 4. Extensions to LMP A control plane tool to detect and isolate data channel mismatches is provided in this document by simple additions to the Link Management Protocol (LMP) [RFC4204]. It can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses. Outline procedures are described in this section. More detailed procedures are found in Section 5. 4.1. Confirm Data Channel Status Messages Extensions to LMP to confirm a data channel status are described below. In order to confirm a data channel status, the new LMP messages are sent between adjacent nodes periodically or driven by some event (such as an operator command, a configurable timer, or the rejection of an LSP setup message because of an unavailable resource). The new LMP messages run over the control channel, encapsulated in UDP with an LMP port number and IP addressing as defined in Link Management Protocol (LMP) [RFC4204]. Three new messages are defined to check data channel status. Message Type numbers are found in Section 7.1. If the message is a Confirm Data Channel Status message, and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the message SHOULD be treated as being out-of-order. 4.1.1. ConfirmDataChannelStatus Messages The ConfirmDataChannelStatus message is used to tell the remote end of the data channel what the status of the local end of the data channel is, and to ask the remote end to report its data channel. The message may report on (and request information about) more than one data channel. ::= [...] When a node receives the ConfirmDataChannelStatus message, and the data channel status confirmation procedure is supported at the node, the node compares its own data channel statuses with all of the data channel statuses sent by the remote end in the ConfirmDataChannelStatus message. If a data channel status mismatch Li Expires February 2010 [Page 7] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 is found, this mismatch result is expected to be reported to the management plane for further action. Management plane reporting procedures and actions are outside the scope of this document. 4.1.2. ConfirmDataChannelStatusAck Messages The ConfirmDataChannelStatusAck message is sent back to the node which originated the ConfirmDataChannelStatus message to return the requested data channel statuses. When the ConfirmDataChannelStatusAck message is received, the node compares the received data channel statuses at the remote end with those at the local end (the same operation as performed by the receiver of the ConfirmDataChannelStatus message). If a data channel status mismatch is found, the mismatch result is expected to be reported to the management plane for further action. ::= [...] The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being acknowledged. Note that the ConfirmDataChannelStatusAck message is used both when the data channel statuses match and when they do not match. 4.1.3. ConfirmDataChannelStatusNack Messages When a node receives the ConfirmDataChannelStatus message, if the data channel status confirmation procedure is not supported but the message is recognized, a ConfirmDataChannelStatusNack message containing an ERROR_CODE indicating "Channel Status Confirmation Procedure not supported" MUST be sent. If the data channel status confirmation procedure is supported, but the node is unable to begin the procedure, a ConfirmDataChannelStatusNack message containing an ERROR_CODE indicating "Unwilling to Confirm" MUST be sent. If a ConfirmDataChannelStatusNack message is received with such an ERROR_CODE, the node which originated the ConfirmDataChannelStatus message MAY schedule the ConfirmDataChannelStatus message retransmission after a configured time. A default value of 10 minutes is suggested for this timer. Li Expires February 2010 [Page 8] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 ::= [] The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being rejected. 4.2. Data Channel Status Subobject A new Data Channel Status subobject type is introduced to the DATA LINK object to hold the data channel status and Data Channel Identification. See Section 7.2 for the Subobject Type value. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Data Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Data Channel ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Channel Status: This is a series of bit flags to indicate the status of the data channel. The following values are defined. 0x0000 : The channel is available/free. 0x0001 : The channel is unavailable/in-use. Data Channel ID This identifies the data channel. The length of this field can be deduced from the Length field in the subobject. Note that all subobjects must be padded to a four byte boundary with trailing zeros. If such padding is required, the Length field MUST indicate the length of the subobject up to, but not including, the first byte of padding. Thus, the amount of padding is deduced and not represented in the Length field. Note that the Data Channel ID is given in the context of the sender of the ConfirmChannelStatus message. Li Expires February 2010 [Page 9] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 The data-channel ID must be encoded as a label value. Based on the type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology used will be different. For SONET/SDH the label value is encoded as per RFC4606. 4.3. Message Construction Data_Link Class is included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck messages, which is defined in section 13.12 in [RFC4204]. The status of the TE link end MUST be carried by the Data Channel Status subobject which is defined in section 4.2 of this document. The new subobject MUST be part of Data_Link Class. In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD be used to identify each timeslot of the data link. 4.4. Backward Compatibility Some nodes running in the network may only support the LMP Message Type from 1 to 20, which are already defined in [RFC4204]. The three new types of LMP message (Message Type from 21 to 23) defined in this document can not be recognized by these nodes. The unknown message behavior is not being specified in [RFC4204], it's suggested to discard the unknown message silently. This document's defined mechanisms presume a certain non-standard behavior of existing/non- document supporting nodes. To use this mechanisms all nodes MUST have the extensions described in this document for compatibility. 5. Procedures The data channel status confirmation related LMP messages MAY be sent between adjacent nodes which are triggered by timer periodically or driven by some events to confirm the channel status for the data links. It's a local police decision to start the data channel status confirmation process. The procedure is described below: . The SENDER constructs a ConfirmDataChannelStatus message which MUST contain one or more DATA_LINK objects. DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object MUST contain one or more Data Channel Status subobjects. The Data Channel ID field in the Data Channel Status subobject MUST indicate which data channel needs to be confirmed, and MUST report the data channel status at the SENDER. The ConfirmDataChannelStatus message is sent to the RECEIVER. Li Expires February 2010 [Page 10] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 . The RECEIVER MUST extract the data channel statuses from the ConfirmDataChannelStatus message, and SHOULD compare these with its data channel statuses for the reported data channels. If a data channel status mismatch is found, the mismatch result SHOULD be reported to the management plane for further action. The RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message which MUST carry all the local end statuses of the requested data channels to the SENDER. . If the RECEIVER is not able to support or to begin the confirmation procedure, the ConfirmDataChannelStatusNack message MUST be responded with the ERROR_CODE which indicates the reason of rejection. . When the SENDER receives the response ConfirmDataChannelStatusAck message, and MUST compare the received data channel statuses at the remote end with the data channel statuses at the local end. If a data channel status mismatch is found, the mismatch result SHOULD be reported to the management plane for further action. The data channel status mismatch issue identified by LMP may be automatically resolved by RSVP restart. For example, the restarting node may also have damaged its data plane. This leaves the data channels mismatched. But RSVP restart will re-install the data plane state in the restarting node. The issue may also be resolved via RSVP soft state timeout. If the ConfirmDataChannelStatus message is not recognized by the RECEIVER, the RECEIVER ignores this message, and will not send out an acknowledgment message to the SENDER. Due to message loss problem, the SENDER may not be able to receive the acknowledgment message. ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable transmission mechanisms. If after the retry limit is reached, a ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack message is not received by the SENDER, the SENDER SHOULD terminate the data channel confirmation procedure. 6. Security Considerations [RFC4204] describes how LMP messages between peers can be secured, and these measures are equally applicable to the new messages defined in this document. Li Expires February 2010 [Page 11] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 The operation of the procedures described in this document does not of themselves constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane and so the use of the LMP security measures are RECOMMENDED. Note that operating the procedures described in this document may provide a useful additional security measure to verify that data channels have not been illicitly modified. 7. IANA Considerations 7.1. LMP Message Types IANA maintains the "Link Management Protocol (LMP)" registry which has a subregistry called "LMP Message Type". IANA is requested to make three new allocations from this registry as follows. The message type values are suggested and to be confirmed by IANA. Value Description ------ --------------------------------- 32 ConfirmDataChannelStatus 33 ConfirmDataChannelStatusAck 34 ConfirmDataChannelStatusNack 7.2. LMP Data Link Object Subobject IANA maintains the "Link Management Protocol (LMP)" registry which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the DATA_LINK object, and there is a further embedded registry called "DATA_LINK Sub-object Class name space". IANA is requested to make the following allocation from this embedded registry. The value shown is suggested and to be confirmed by IANA. Value Description ------ --------------------------------- 9 Data Channel Status 8. Acknowledgments We would like to thank Adrian Farrel, Dimitri Papadimitriou, Lou Berger for their useful comments. Li Expires February 2010 [Page 12] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. 9.2. Informative References [RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP Graceful Restart", RFC 5063, September 2007 [RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) ", RFC 4203, October 2005 [RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) ", RFC 4205, October 2005 10. Authors' Addresses Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129 China Phone: +86 755-289-70230 Email: danli@huawei.com Li Expires February 2010 [Page 13] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 Huiying Xu Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129 China Phone: +86 755-289-72910 Email: xuhuiying@huawei.com Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129 China Phone: +86 755-289-72912 Email: zhangfatai@huawei.com Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway, Richardson, Texas 75082, USA Phone: +1 972 479 2951 Email: snigdho.bardalai@us.fujitsu.com Julien Meuric France Telecom Orange Labs 2, avenue Pierre Marzin 22307 Lannion Cedex, France Phone: +33 2 96 05 28 28 Email: julien.meuric@orange-ftgroup.com Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736 Email: diego.caviglia@ericsson.com Li Expires February 2010 [Page 14] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 11. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 12. Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Li Expires February 2010 [Page 15] draft-ietf-ccamp-confirm-data-channel-status-06.txt August 2009 13. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Li Expires February 2010 [Page 16] --Boundary_(ID_2wugI3PSf5qGZyp7KuU+Hg)-- From zhangguoying@mail.ritt.com.cn Tue Aug 4 07:06:18 2009 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 EA0AB3A6920 for ; Tue, 4 Aug 2009 07:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.756 X-Spam-Level: *** X-Spam-Status: No, score=3.756 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 haDDdRqBvSWX for ; Tue, 4 Aug 2009 07:06:17 -0700 (PDT) Received: from smtp.ritt.com.cn (unknown [211.167.85.58]) by core3.amsl.com (Postfix) with SMTP id 63C903A67D0 for ; Tue, 4 Aug 2009 07:06:15 -0700 (PDT) X-MAILFROM: X-RCPTTO: X-FROMIP: 211.167.85.39 X-EQManager-Scaned: 1 X-Received: unknown,211.167.85.39,20090804215742 Received: from unknown (HELO mai.ritt.com.cn) (211.167.85.39) by localhost with SMTP; 4 Aug 2009 13:57:42 -0000 Received: from gyzhang ([114.243.191.214]) by mai.ritt.com.cn (VisNetic.MailServer.v8.3.5.0) with ASMTP id LWG92154; Tue, 4 Aug 2009 22:02:54 +0800 Date: Tue, 4 Aug 2009 22:02:56 +0800 From: "zhangguoying" To: "Jin, Lizhong (NSN - CN/Shanghai)" , "ccamp@ietf.org" References: , <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> Message-ID: <200908042202560621383@mail.ritt.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon210161456336_=====" X-Mailman-Approved-At: Fri, 14 Aug 2009 08:04:26 -0700 Cc: "xuyunbin@mail.ritt.com.cn" Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 04 Aug 2009 14:06:19 -0000 This is a multi-part message in MIME format. --=====003_Dragon210161456336_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBcyBtYW55IGV4cGVydHMgaGF2ZSBleHBsYWluZWQsIHRoZSBsYWJlbCBlbmNv ZGluZyB3aXRoIGJpdCBtYXAgaW4gZHJhZnQtemhhbmcgaXMgIHN1cmVseSBhIGJldHRlciB3YXkg dG8gYWNoaWV2ZSBleHRlbnNpYmlsaXR5IGFuZCBzY2FsYWJpbGl0eSBvZiBPVE4gbGFibGUuICAN Cg0KVGhlIG1haW4gaXNzdWUgdGhhdCBiaXQgbWFwIGxhYmVsIGZvcm1hdCBtaWdodCBoYXZlIGlz IHRoZSBiYWNrd29yZCBjb21wYXRpYmlsaXR5LiBJIHRoaW5rIHdlIG1pZ2h0IG5lZWQgdG8gc3Rh cnQgYW4gc3VydmV5IGFtb25nIHRoZSBPVE4gc2VydmljZSBwcm92aWRlcnMgaW4gdGhlIG1haWxp bmcgbGlzdCwgIGFuZCBzZWUgaWYgdGhlcmUgYXJlIGFueSBPVE4gbmV0d29ya3MgZGVwbG95ZWQg d2l0aCBHTVBMUyBSRkM0MzI4IGxhYmxlIGZvcm1hdC4gDQoNCklmIHRoZXJlJ3JlIG5vIHJlYWwg ZGVwbG95bWVudCwgd2UgZG9uJ3QgbmVlZCB0byBjb25zaWRlciB0aGUgY29tcGF0YWJpbGl0eSBw cm9ibGVtOw0KDQpJZiB0aGVyZSdyZSBzb21lIGRlcGxveW1lbnQsIGNvbXBhdGFiaWxpdHkgcHJv YmxlbSBuZWVkIHRvIGJlIHNvbHZlZCAuIEFuIGVhc3kgd2F5IG1pZ2h0IGJlIGFkZGluZyBhbiBs YWJlbCB2ZXJzaW9uIGJpdCBpbiB0aGUgbGFiZWwgZm9ybWF0LCBvciBzb21lIG90aGVyIHNvbHV0 aW9ucyBtYXkgYmUgc2VhcmNoZWQgb3V0Lg0KDQoNCmJlc3QgcmVnYXJkcywNCkd1b3lpbmcgWmhh bmcNCg0KDQoNCjIwMDktMDgtMDQgDQoNCg0KDQp6aGFuZ2d1b3lpbmcgDQoNCg0KDQq3orz+yMuj uiBKaW4sIExpemhvbmcgKE5TTiAtIENOL1NoYW5naGFpKSANCreiy83Ksbzko7ogMjAwOS0wOC0w NCAgMTM6MzQ6MjQgDQrK1bz+yMujuiBjY2FtcEBpZXRmLm9yZyANCrOty82juiB6aGFuZ2ZhdGFp QGh1YXdlaS5jb207IGZ1LnhpaHVhQHp0ZS5jb20uY247IGRicnVuZ2FyZEBhdHQuY29tOyBsYmVy Z2VyQGxhYm4ubmV0OyBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IGRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb207IHpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuOyB4dXl1bmJp bkBtYWlsLnJpdHQuY29tLmNuIA0K1vfM4qO6IFJFOiBEaXNjdXNzaW9uIGFib3V0IHRoZSBHTVBM UyBTaWduYWxpbmcgRXh0ZW5zaW9uIA0KIA0KSGkgRmF0YWkgYW5kIGFsbDoNCkkgYWdyZWUgd2l0 aCB0aGUgaXNzdWVzIG9mIGV4Y2Vzc2l2ZSBudW1iZXIgb2YgbGFiZWxzIGlmIHVzaW5nIHRoZSBz YW1lDQpsYWJlbCBjb25jZXB0IG9mIFJGQzQzMjguIEJ5IHVzaW5nIGJpdCBtYXAgZm9yIGxhYmVs IGVuY29kaW5nIGlzIGEgZ29vZA0KaWRlYS4gQW5kIGZyb20gbXkgdW5kZXJzdGFuZGluZywNCmRy YWZ0LWNlY2NhcmVsbGlmdXhoLWNjYW1wLWdtcGxzLWV4dC1mb3ItZXZvbC1vdG4tMDAgY2FuIG1l cmdlIHRoaXMgYml0DQptYXAgaWRlYSBpZiBGYXRhaSBhZ3JlZS4NCg0KRm9yIGJhY2t3YXJkIGNv bXBhdGliaWxpdHksIHdlIGNhbiBub3QgYXNzdW1lIHRoYXQgUkZDNDMyOCBpcyBub3QNCmRlcGxv eWVkIHVubGVzcyB3ZSBjYW4gcHJvdmlkZSBzb21lIGtpbmQgb2Ygc3VydmV5IHJlcG9ydC4gU28g Y3VycmVudGx5DQp0aGUgcmlnaHQgYXNzdW1wdGlvbiBpcyB0aGF0IFJGQzQzMjggaGFzIGJlZW4g ZGVwbG95ZWQsIGFuZCBiYWNrd2FyZA0KY29tcGF0aWJpdHkgc2hvdWxkIGJlIGNvbnNpZGVyZWQu DQoNCkJlc3QgUmVnYXJkcw0KTGl6aG9uZyBKaW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdl OiAxDQpEYXRlOiBUaHUsIDMwIEp1bCAyMDA5IDExOjMzOjU2ICswMjAwDQpGcm9tOiAiQkVMT1RU SSBTRVJHSU8iICA8U2VyZ2lvLkJlbG90dGlAYWxjYXRlbC1sdWNlbnQuaXQgPg0KU3ViamVjdDog W0NDQU1QXSBSOiBEaXNjdXNzaW9uIGFib3V0IHRoZSBHTVBMUyBTaWduYWxpbmcgRXh0ZW5zaW9u DQpmb3JFdm9sdXRpdmUgT1RODQpUbzogIkZhdGFpIiAgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbSA+ LCAgPGZ1LnhpaHVhQHp0ZS5jb20uY24gPiwNCjxkYnJ1bmdhcmRAYXR0LmNvbSA+LCAgPGxiZXJn ZXJAbGFibi5uZXQgPiwNCjxkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20gPiwNCjxkYW5pZWxl LmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tID4sDQo8emhhbmdndW95aW5nQG1haWwucml0dC5jb20u Y24gPiwNCjx4dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuID4NCkNjOiBjY2FtcEBpZXRmLm9yZw0K TWVzc2FnZS1JRDoNCjwzRjQ0MTg2RDcxNDFFMjQ3OTcyRUFDNjY1NUIwQTI5MTAxRkE3QTU2QEZS VkVMU01CUzIxLmFkMi5hZC5hbGNhdGVsLmNvbQ0KPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWlu OyBjaGFyc2V0PSJpc28tODg1OS0xIg0KDQpEZWFyIEZhdGFpIGFuZCBhbGwsDQoNCg0KDQpXZSBh Z3JlZSBvbiB0aGUgbWFqb3IgcG9pbnRzIHJhaXNlZCBieSBGYXRhaSBhcyBnZW5lcmFsIGlzc3Vl IHRvIGJlDQpzb2x2ZWQgaW4gdGhlIGNvbnRleHQgb2YgZXh0ZW5zaW9uIG5lZWRlZCB0byBjb3Bl IHdpdGggbmV3IGNvbnRhaW5lcnMNCmRlZmluZWQgaW4gSVRVICBxMTEgY29udGV4dCwgaW4gYWRk aXRpb24gdG8gaGFuZGxpbmcgT0RVIG11bHRpcGxleGluZw0Kc2NlbmFyaW9zIGluIGV4aXN0aW5n IE9UTi4NCg0KVGhlcmUgYXJlIHR3byBiYXNpYyBwb2ludHMgdGhhdCBicmluZ3MgdG8gdGhlIG5l ZWQgdG8gdXBkYXRlIHRoZSBSRkM0MzI4DQphbnl3YXkuDQoNCg0KDQoxKSB0aGUgcHJlc2VudCBS RkMgZG9lcyBub3QgcGVybWl0IHRoZSBsaW5rIGJhc2VkIG5lZ290aWF0aW9uICBmb3IgdGltZQ0K c2xvdCBhbGxvY2F0aW9uIC4gTm8gaW5mb3JtYXRpb24gYWJvdXQgdHJpYnV0YXJ5IHBvcnQgbnVt YmVycyBpcyBwcmVzZW50DQphbmQgb25seSBpbiBjYXNlIHdlIGhhdmUgInNpbmdsZSBsYXllciIg LCBubyBtdWx0aXBsZXhpbmcgTE8gLS0gPiBITyB5b3UNCmNhbiBhcHBseSAuIFNvIHRoaXMgaXMg YSBsYWNrIGFnYWluc3QgdGhlIG9yaWdpbmFsIEcuNzA5IGV2ZW4gd2l0aG91dA0KY29uc2lkZXJp bmcgRy43MDkgQW0zIC4NCg0KDQoNCjIpIFNjYWxhYmlsaXR5OiBUaGUgZXh0ZW5zaW9uIHJlcXVp cmVkIGluIHRoZSBjb250ZXh0IG9mIG5ldyBPVE4gd2l0aA0KdGhlIGludHJvZHVjdGlvbiBvZiBP RFUwLCBPRFU0LCBhbmQgYWJvdmUgYWxsIE9EVWZsZXggLCByZXF1aXJlZCBhIHJlYWwNCm1vZGlm aWNhdGlvbnMgb2YgdGhlIHN0cnVjdHVyZSBvZiB0aGUgbGFiZWwgdG8gYXZvaWQgcmVhbCBiaWcg c2l6ZSBvZg0KbnVtYmVyIG9mIGxhYmVscyB0byB0cmFuc21pdCBvZmZsb2FkaW5nIHNpZ25hbGxp bmcgc2Vzc2lvbi4gRXh0ZW5zaW9uDQpiYXNlZCBvbiBSRkM0MzI4IGxvZ2ljIGRvIG5vdCBzY2Fs ZSB3aGVuIE9EVS1mbGV4IGlzIHVzZWQuIExhcmdlIE9EVQ0KZmxleCBjb250YWluZXJzIHdpbGwg Z2VuZXJhdGUNCg0KYW4gZXhjZXNzaXZlIG51bWJlciBvZiBsYWJlbHMgKGluIHByaW5jaXBsZSB1 cCB0byA4MCBwZXIgbGluaykgY2F1c2luZw0KcHJvYmxlbXMgd2l0aCB0aGUgc2l6ZSBvZiB0aGUg UlNWUC1URSBtZXNzYWdlLg0KDQoNCg0KVGhpcyB0d28gcG9pbnRzIHRvZ2V0aGVyIGNhbGwgdG8g dGhlIG5lZWQgdG8gY2hhbmdlIHNvbWV0aGluZyBpbiBSRkMuDQoNCkJhY2t3YXJkIGNvbXBhdGli aWxpdHkgYXNwZWN0cywgcHJlc2VudCBpbiBhbGwgdGhlIGRyYWZ0cywgYXJlIHN1cmVseSB0bw0K YmUgY29uc2lkZXJlZCBhbmQgaWYgdGhlcmUgYXJlIHNpbmdsZSBsYXllciBzeXN0ZW1zIGRlcGxv eWVkIHVzaW5nDQpSRkM0MzI4IHRoaXMgc2hvdWxkIGJlIGdyYW5kZmF0aGVyZWQuDQoNCg0KDQpC ZXN0IFJlZ2FyZHMNCg0KDQoNClNlcmdpbw0KDQoNCg0KDQoNClNlcmdpbyBCZWxvdHRpDQoNCg0K DQpDVE8gT3B0aWNzIERpdmlzaW9uDQoNCkFsY2F0ZWwtTHVjZW50DQoNCg0KDQorMzkgMDM5IDY4 NjMwMzMNCg0KKzM5IDAzOSA2ODYzNTkwDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpEYTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmddIFBlciBjb250byBkaQ0KRmF0YWkNCkludmlhdG86IG1lcmNvbGVkPyAyOSBs dWdsaW8gMjAwOSAxOC4zMw0KQTogZnUueGlodWFAenRlLmNvbS5jbjsgZGJydW5nYXJkQGF0dC5j b207IGxiZXJnZXJAbGFibi5uZXQ7DQpkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IGRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb207DQp6aGFuZ2d1b3lpbmdAbWFpbC5yaXR0LmNvbS5j bjsgeHV5dW5iaW5AbWFpbC5yaXR0LmNvbS5jbg0KQ2M6IGNjYW1wQGlldGYub3JnDQpPZ2dldHRv OiBSZTogW0NDQU1QXSBEaXNjdXNzaW9uIGFib3V0IHRoZSBHTVBMUyBTaWduYWxpbmcgRXh0ZW5z aW9uDQpmb3JFdm9sdXRpdmUgT1RODQoNCg0KDQpIaSBhbGwsDQoNCg0KDQpUbyBzdXBwb3J0IHRo ZSBjdXJyZW50IHZlcmlzb24gb2YgRy43MDksIHdlIHRoaW5rIHRoZSBsYWJlbCBmb3JtYXQNCmRl ZmluZWQgaW4gUkZDNDMyOCBuZWVkIHRvIGJlIHJlLWRlZmluZWQgYW55d2F5LiBUaGUgbmV3IE9U TiBsYWJlbA0KZm9ybWF0IHNob3VsZCBzdXBwb3J0IHRoZSB3aG9sZSBPRFUgc2V0cywgbm90IG9u bHkgdGhlIE9EVTEsIDIsIGFuZCAzLA0KYnV0IGFsc28gT0RVMCwgT0RVNCwgZXZlbiBPRFVGbGV4 LiBUaGUgZm9sbG93aW5nIHRocmVlIGFzcGVjdHMgc2hvdWxkIGJlDQpjb25zaWRlcmVkIGNhcmVm dWxseToNCg0KDQoNCjEpIFRoZSBleHRlbnNpYmlsaXR5IG9mIHRoZSBsYWJlbCBmb3JtYXQgaXMg dGhlIGZpcnN0IHRoaW5nIHdlIHNob3VsZA0KY29uc2lkZXIuIFdpdGggdGhlIGRldmVsb3BtZW50 IG9mIE9UTiB0ZWNobm9sb2d5LCBSRkM0MzI4IGxhYmVsIGZvcm1hdA0Kc3R5bGUgbmVlZHMgdG8g YmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCB0aGUgbmV3IGJpdHJhdGUgT0RVIChlZy4gT0RVNSwNCjYu Li4pLiBCeSB0aGUgZW5kLCB3ZSBtYXkgbmVlZCBrZWVwIGV4dGVuZGluZyB0aGUgbGFiZWwgZm9y bWF0cy4NCk1hbmFnaW5nIGxvdHMgb2YgbGFiZWwgZm9ybWF0IG1heSBjYXVzZSBiaWcgdHJvdWJs ZSwgc28gd2UgbmVlZCBvbmUtc2hvdA0KbGFiZWwgZm9ybWF0IGZvciB0aGUgZXZvbHZpbmcgT1RO LiAgDQoNCg0KDQoyKSBTY2FsYWJpbGl0eSBpcyBhbm90aGVyIGtleSBpc3N1ZS4gUkZDNDMyOCBz dHlsZSBmb3JtYXQgbWF5IHJlc3VsdCBpbg0KYmlnIHNpemUgb2YgdGhlIHRvdGFsIGxhYmVscywg d2hpY2ggZGVmaW5pdGVseSBpbmNyZWFzZSB0aGUgYnVyZGVuIG9mDQp0aGUgc2lnbmFsaW5nLiBB biBlZmZpY2llbnQgYXBwcm9hY2ggaXMgbmVlZGVkIHRvIGNhcnJ5IHRoZSBzYW1lIGxhYmVsDQpp bmZvcm1hdGlvbiBidXQgd2l0aCBsZXNzIGFtb3VudCBvZiB0aGUgZGF0YSwgYml0bWFwIHN0eWxl IGlzIHRoZSByaWdodA0Kd2F5IHRvIGdvLg0KDQoNCg0KMykgRm9yIGJhY2t3YXJkIGNvbXBhdGli aWxpdHksIGlmIHRoZXJlIGFyZSBubyBpbXBsZW1lbnRhdGlvbnMgZm9yDQpSRkM0MzI4IChvciBp ZiB0aGVyZSBhcmUgbm8gZGVwbG95bWVudHMgaXQgaXMgZGVzaXJhYmxlIHRvIGRlcHJlY2F0ZQ0K ZXZlbiBpZiBpdCBpcyB1bmNvbWZvcnRhYmxlIGZvciBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMp LCBpdCBpcyB2ZXJ5DQpzYWZlIHRvIGRlcHJlY2F0ZSB0aGUgb2xkIGRlZmluaXRpb24sIGFuZCBh biBleHRlbnNpYmxlLCBlZmZpY2llbnQgYW5kDQpzY2FsYWJsZSBzb2x1dGlvbiBjb3VsZCBiZSBo ZWxwZnVsLiBUaGUgbGFiZWwgZGVmaW5lZCBpbiBkcmFmdC16aGFuZw0KZG9lcyBub3Qgb3Zlcndy aXRlIFJGQzQzMjgsIGl0IGNhbiBhbGxvdyB0aGUgb2xkIGRlZmluaXRpb24gdG8gY29udGludWUN CnRvIGV4aXN0Lg0KDQoNCg0KSG9wZSB0aGlzIGNhbiBjbGFyaWZ5IHlvdXIgY29uY2Vybi4NCg0K DQoNCkF1dGhvcnMgb2YgZHJhZnQtemhhbmcNCg0KDQoNCg0KDQoNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCg0KRnJvbTogZnUueGlodWFAenRlLmNvbS5jbiANCg0KVG86IGRicnVu Z2FyZEBhdHQuY29tIDsgbGJlcmdlckBsYWJuLm5ldCA7IHpoYW5nZmF0YWlAaHVhd2VpLmNvbQ0K OyBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb20gOyBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tIA0KDQpDYzogY2NhbXBAaWV0Zi5vcmcgDQoNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjgs IDIwMDkgNTozMyBQTQ0KDQpTdWJqZWN0OiBEaXNjdXNzaW9uIGFib3V0IHRoZSBHTVBMUyBTaWdu YWxpbmcgRXh0ZW5zaW9uIGZvcg0KRXZvbHV0aXZlIE9UTg0KDQoNCg0KSGkgRmF0YWkgYW5kIEFs bCwgDQpXZSBoYXZlIHByZXNlbnRlZCB0aGUgZm9sbG93aW5nIHR3byBkb2N1bWVudCAgaW4gdGhl IENDQU1QDQptb3JuaW5nIHNlc3Npb24uIEJ1dCB3ZSBoYXZlIG5vIG1vcmUgdGltZSB0byBmdXJ0 aGVyIGRpc2N1c3MgR01QTFMNCmV4dGVuc2lvbiBmb3IgZXZvbHV0aXZlIE9UTiANCmRyYWZ0LWNl Y2NhcmVsbGlmdXhoLWNjYW1wLWdtcGxzLWV4dC1mb3ItZXZvbC1vdG4tMDAudHh0DQo8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2VjY2FyZWxsaWZ1eGgtY2NhbXAtZ21wbHMtZXh0 LWZvci1ldm8NCmwtb3RuLTAwID4gIA0KZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmct ZzcwOS0wMS50eHQNCjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2Ft cC1nbXBscy1ldm9sdmluZy1nNzA5LTAxLnR4dA0KPiAgDQpXZSBoYXZlIGEgY291cGxlIG9mIGNv bW1lbnRzIGFuZCBxdWVzdGlvbnMgZm9yIHRoZSBkcmFmdC16aGFuZy4gDQooMSkgZHJhZnQtemhh bmcgZGVmaW5lZCB0aGUgZXh0ZW5zaW9ucyBpbmNsdWRpbmcgd2hhdCBoYXMgYmVlbg0KZG9uZSBp biBSRkM0MzI4IChpLmUuLCBPRFUxLCBPRFUyIGFuZCBPRFUzKS4gDQogICAgICBkcmFmdC1jZWNj YXJlbGxpZnV4aCBkZWZpbmVkIG5ldyBHbmVyYWxpemVkIExhYmVsIG9ubHkgZm9yDQpuZXcgYXBw bGljYXRpb24gKGkuZS4sIE9EVTAsIDEuMjVHIE9EVTEsIDEuMjVHIE9EVTIsIDEuMjVHIE9EVTMs IE9EVTJlLA0KT0RVM2UxLCBPRFUzZTIsIE9EVWZsZXggYW5kIE9EVTQpLiANCiAgICAgIGRyYWZ0 LWNlY2NhcmVsbGlmdXhoIGlzIG9ubHkgYSBzdXBwbGVtZW50IG9mIFJGQzQzMjguIA0KICAgICAg SG93IGNhbiB3ZSB1c2VkIFJGQzQzMjggYW5kIGRyYWZ0LXpoYW5nID8gICAgICAgDQogICAgICBB bnkgd2F5LCBpZiB3ZSBuZWVkIHRvIHVwZGF0ZSBhbiBwcmV2aW91cyBSRkMsIHdlIHNob3VsZA0K YXNzdW1lIHRoYXQgaXQgaGFzIGJlZW4gZGVwbG95ZWQsIG5vdCBhc2tpbmcgaWYgc29tZW9uZSBk aWQgb3Igbm90LiANCigyKSBEbyB5b3UgcmVhbGx5IHdhbnQgdG8gcmVtb3ZlIE5NQyBmcm9tIHRo ZSBUcmFmZmljDQpQYXJhbWV0ZXJzPyANCiAgICAgIElmIHlvdSBkbyB0aGF0LCBJIHRoaW5rIHdl IGhhdmUgdG8gYWJhbmRvbiBSRkM0MzI4LiANCigzKSBUaGUgY29tcGF0aWJpbGl0eSBjb25zaWRl cmF0aW9uIGluIGRyYWZ0LXpoYW5nLiANCiAgIFdlIGRvbid0IHRoaW5rIHRoZSBleHRlbnNpb25z IGluIGRyYWZ0LXpoYW5nIGNhbiBjb2V4aXN0IHdpdGgNClJGQzQzMjguIA0KICAgWW91IHBvaW50 IG91dCAid2UgY2FuIGp1c3QgZG8gc29tZSB0cmFuc2xhdGlvbiBvciBtYXBwaW5nIGluDQp0aGUg bmV3IG5vZGVzIi4gDQogICBCdXQgYmVmb3JlIHRoZSB0cmFuc2xhdGlvbiBvciBtYXBwaW5nLCB5 b3UgaGF2ZSB0byBrbm93IHRoZQ0KR2VuZXJhbGl6ZWQgTGFiZWwgRm9ybWF0LiAgIA0KICAgV2Ug Y29uY2VybiBhYm91dDogICANCiAgIGkpICBIb3cgZG9lcyBvbmUgbm9kZSBrbm93IHRoZSBHZW5l cmFsaXplZCBMYWJlbCBmb3JtYXQsDQplc3BlY2lhbGx5IGZvciBPRFUxLCBPRFUyIGFuZCBPRFUz IGJhc2Ugb24geW91ciBzb2x1dGlvbj8gICAgIA0KICAgICAgICBJdCBtYXkgZGVwZW5kIG9uIHRo ZSBjYXBhYmlsaXR5IG9mIHRoZSBhZGphY2VudCBuZXR3b3JrDQplbGVtZW50LiANCiAgIGlpKSBC dXQgaG93IGNhbiB0aGUgY29udHJvbCBwbGFuZSBrbm93IHRoZSBhZGphY2VudCBuZXR3b3JrDQpl bGVtZW50J3MgY2FwYWJpbGl0eSB3aXRob3V0IGRpc2NvdmVyeSBtZWNoYW5pc20/IA0KICAgICAg IFlvdSBzaG91bGQga25vdyB0aGF0IEdNUExTIHNpZ25hbGluZyBleHRlbnNpb24gc2hvdWxkIGJl DQppbmRlcGVuZGVudCBvbiB0aGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBhbmQgdGhlIGNvbmZpZ3Vy YXRpb24gb2YNCm1hbmFnZW1lbnQgcGxhbmUuIA0KICAgaWlpKSBUaGUgY29udHJvbCBwbGFuZSBk b24ndCBuZWVkIHRvIGtub3cgdGhlIEcuNzA5KDIwMDMvMDMpDQpvciBHLjcwOSBBbWVuZG1lbnQz IG5ldHdvcmsgZWxlbWVudD8gDQogICAgICANCiAgICAgSW4gYSB3b3JkLCB3ZSB0aGluayBpdCBj YW4gbm90IGRvIHRoZSB0cmFuc2xhdGlvbiBhbmQNCm1hcHBpbmcuIFNvIHdlIGNhbiBub3QgZ2V0 IHRoZSBjb21wYXRpYmlsaXR5IHdpdGggUkZDNDMyOCBpbg0KZHJhZnQtemhhbmcuIA0KICg0KSBU aGUgR2VuZXJhbGl6ZWQgTGFiZWwgaW4gZHJhZnQtemhhbmcgDQogICAgLSBtYW5hZ2luZyBhIHZh cmlhYmxlIGxlbmd0aCBsYWJlbCBjb3VsZCBiZSBhIG1lc3MuIA0KICAgIC0gZHJhZnQtemhhbmcg dXNlcyBhIGZpcnN0IHBhcnQgb2YgdGhlIGxhYmVsIHdoaWNoIGhhcyBmaXhlZA0KdmFsdWVzIGFu ZCB0aGVuIGEgdmFyaWFibGUgbnVtYmVyIG9mIGJpdCB0aGF0IGlzIHRoZSBiaXRtYXAuIA0KICAg ICAgIFRoZSBiaXRtYXAgY2FuIGJlIGxvbmcgZnJvbSAwIHRvIDgwIGJpdHMgZGVwZW5kaW5nIG9u IHRoZQ0Kc2lnbmFsIHR5cGUuIA0KICAgIC0gdGhlIHZhbHVlIG9mIHRoZSBiaXRtYXAgaXMgbm90 IGluZGVwZW5kZW50IGJ1dCBkZXBlbmRzIG9uDQp0aGUgdmFsdWVzIG9mIHR3byBwcmV2aW91cyBm aWVsZHMgKE9EVWsgYW5kIE9EVWopIGFuZCBiZWNvbWVzIHJlc2VydmVkDQppbiBjYXNlIG9mIEs9 SiANCiAgICAtIGEgYml0bWFwIGxhYmVsIGhhdmUgbm90IGJlZW4gdXNlZCBub3IgaW4gU0RIIGFu ZCBub3QgaW4NCldTT04gd2hlcmUgYSBmaXhlZCBsYWJlbCAoNCBieXRlcykgaXMgdXNlZC4gDQpY aWh1YSBGdSANClpURSANCg0KLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0t DQpBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uDQpVUkw6DQo8aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NjYW1wL2F0dGFjaG1lbnRzLzIwMDkwNzMwL2JmY2Vj NTANCjQvYXR0YWNobWVudC5odG0gPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1Q IG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2NhbXANCg0KDQpFbmQgb2YgQ0NBTVAgRGlnZXN0LCBWb2wgMTQsIElzc3Vl IDI2DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --=====003_Dragon210161456336_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE2NzA1IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpF OiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtV0VJR0hUOiBub3JtYWw7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBub3JtYWw7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hIj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGkgYWxsLDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMw MDAwODA+QXMgbWFueSBleHBlcnRzIGhhdmUgZXhwbGFpbmVkLCB0aGUgbGFiZWwgZW5jb2Rpbmcg d2l0aCANCmJpdCBtYXAgaW4gZHJhZnQtemhhbmcgaXMmbmJzcDsgc3VyZWx5Jm5ic3A7YSBiZXR0 ZXIgd2F5IHRvIA0KYWNoaWV2ZSZuYnNwO2V4dGVuc2liaWxpdHkmbmJzcDthbmQmbmJzcDtzY2Fs YWJpbGl0eSBvZiBPVE4gDQpsYWJsZS4mbmJzcDsmbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+VGhlJm5ic3A7bWFpbiANCmlzc3VlJm5ic3A7dGhh dCZuYnNwO2JpdCBtYXAmbmJzcDtsYWJlbCBmb3JtYXQmbmJzcDttaWdodCBoYXZlJm5ic3A7aXMg DQp0aGUmbmJzcDtiYWNrd29yZCBjb21wYXRpYmlsaXR5LiZuYnNwO0kmbmJzcDt0aGluayZuYnNw O3dlIG1pZ2h0IG5lZWQgDQp0byZuYnNwO3N0YXJ0IGFuIHN1cnZleSBhbW9uZyB0aGUgT1ROIHNl cnZpY2UgcHJvdmlkZXJzIGluIHRoZSBtYWlsaW5nIA0KbGlzdCwmbmJzcDsgYW5kIHNlZSBpZiB0 aGVyZSBhcmUgYW55IE9UTiBuZXR3b3JrcyBkZXBsb3llZCB3aXRoIEdNUExTIA0KUkZDNDMyOCZu YnNwO2xhYmxlIGZvcm1hdC4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg Y29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SWYgdGhlcmUncmUgbm8gcmVhbCBkZXBsb3lt ZW50LCANCndlJm5ic3A7ZG9uJ3QgbmVlZCB0byBjb25zaWRlciB0aGUgY29tcGF0YWJpbGl0eSBw cm9ibGVtOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAw ODAgc2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAwMDA+PEZPTlQgDQpjb2xvcj0jMDAwMDgwPjwvRk9O VD48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29s b3I9IzAwMDA4MCBzaXplPTI+PEZPTlQgY29sb3I9IzAwMDAwMD48Rk9OVCANCmNvbG9yPSMwMDAw ODA+SWYgdGhlcmUncmUgc29tZSBkZXBsb3ltZW50LCBjb21wYXRhYmlsaXR5IHByb2JsZW0gbmVl ZCB0byANCmJlJm5ic3A7c29sdmVkIC4gQW4gZWFzeSB3YXkmbmJzcDttaWdodCBiZSZuYnNwO2Fk ZGluZyANCmFuJm5ic3A7bGFiZWwmbmJzcDt2ZXJzaW9uIGJpdCZuYnNwO2luIHRoZSBsYWJlbCBm b3JtYXQsIG9yIHNvbWUgb3RoZXIgc29sdXRpb25zIA0KbWF5IGJlIHNlYXJjaGVkIG91dC48L0ZP TlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPmJlc3QgcmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwODA+R3VveWluZyBaaGFuZzwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXpl PTI+MjAwOS0wOC0wNCA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAw MDA4MCBzaXplPTI+DQo8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWdu PWxlZnQgU0laRT0yPg0KPC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2Mw YzBjMCBzaXplPTI+PFNQQU4+emhhbmdndW95aW5nPC9TUEFOPiANCjwvRk9OVD48L0RJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz63orz+yMujujwvU1RST05HPiBKaW4s IExpemhvbmcgKE5TTiAtIA0KQ04vU2hhbmdoYWkpIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPreiy83Ksbzko7o8L1NUUk9ORz4gMjAwOS0wOC0w NCZuYnNwOyAxMzozNDoyNCANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h IHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IGNjYW1wQGlldGYub3JnIA0KPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9T VFJPTkc+IHpoYW5nZmF0YWlAaHVhd2VpLmNvbTsgDQpmdS54aWh1YUB6dGUuY29tLmNuOyBkYnJ1 bmdhcmRAYXR0LmNvbTsgbGJlcmdlckBsYWJuLm5ldDsgDQpkaWVnby5jYXZpZ2xpYUBlcmljc3Nv bi5jb207IGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb207IA0KemhhbmdndW95aW5nQG1h aWwucml0dC5jb20uY247IHh1eXVuYmluQG1haWwucml0dC5jb20uY24gPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IFJF OiBEaXNjdXNzaW9uIGFib3V0IHRoZSANCkdNUExTIFNpZ25hbGluZyBFeHRlbnNpb24gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPkhpJm5ic3A7RmF0YWkmbmJzcDth bmQmbmJzcDthbGw6PC9ESVY+DQo8RElWPkkmbmJzcDthZ3JlZSZuYnNwO3dpdGgmbmJzcDt0aGUm bmJzcDtpc3N1ZXMmbmJzcDtvZiZuYnNwO2V4Y2Vzc2l2ZSZuYnNwO251bWJlciZuYnNwO29mJm5i c3A7bGFiZWxzJm5ic3A7aWYmbmJzcDt1c2luZyZuYnNwO3RoZSZuYnNwO3NhbWU8L0RJVj4NCjxE SVY+bGFiZWwmbmJzcDtjb25jZXB0Jm5ic3A7b2YmbmJzcDtSRkM0MzI4LiZuYnNwO0J5Jm5ic3A7 dXNpbmcmbmJzcDtiaXQmbmJzcDttYXAmbmJzcDtmb3ImbmJzcDtsYWJlbCZuYnNwO2VuY29kaW5n Jm5ic3A7aXMmbmJzcDthJm5ic3A7Z29vZDwvRElWPg0KPERJVj5pZGVhLiZuYnNwO0FuZCZuYnNw O2Zyb20mbmJzcDtteSZuYnNwO3VuZGVyc3RhbmRpbmcsPC9ESVY+DQo8RElWPmRyYWZ0LWNlY2Nh cmVsbGlmdXhoLWNjYW1wLWdtcGxzLWV4dC1mb3ItZXZvbC1vdG4tMDAmbmJzcDtjYW4mbmJzcDtt ZXJnZSZuYnNwO3RoaXMmbmJzcDtiaXQ8L0RJVj4NCjxESVY+bWFwJm5ic3A7aWRlYSZuYnNwO2lm Jm5ic3A7RmF0YWkmbmJzcDthZ3JlZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkZv ciZuYnNwO2JhY2t3YXJkJm5ic3A7Y29tcGF0aWJpbGl0eSwmbmJzcDt3ZSZuYnNwO2NhbiZuYnNw O25vdCZuYnNwO2Fzc3VtZSZuYnNwO3RoYXQmbmJzcDtSRkM0MzI4Jm5ic3A7aXMmbmJzcDtub3Q8 L0RJVj4NCjxESVY+ZGVwbG95ZWQmbmJzcDt1bmxlc3MmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO3By b3ZpZGUmbmJzcDtzb21lJm5ic3A7a2luZCZuYnNwO29mJm5ic3A7c3VydmV5Jm5ic3A7cmVwb3J0 LiZuYnNwO1NvJm5ic3A7Y3VycmVudGx5PC9ESVY+DQo8RElWPnRoZSZuYnNwO3JpZ2h0Jm5ic3A7 YXNzdW1wdGlvbiZuYnNwO2lzJm5ic3A7dGhhdCZuYnNwO1JGQzQzMjgmbmJzcDtoYXMmbmJzcDti ZWVuJm5ic3A7ZGVwbG95ZWQsJm5ic3A7YW5kJm5ic3A7YmFja3dhcmQ8L0RJVj4NCjxESVY+Y29t cGF0aWJpdHkmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO2NvbnNpZGVyZWQuPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5CZXN0Jm5ic3A7UmVnYXJkczwvRElWPg0KPERJVj5MaXpob25n Jm5ic3A7SmluPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5NZXNzYWdlOiZuYnNwOzE8L0RJVj4NCjxESVY+ RGF0ZTombmJzcDtUaHUsJm5ic3A7MzAmbmJzcDtKdWwmbmJzcDsyMDA5Jm5ic3A7MTE6MzM6NTYm bmJzcDsrMDIwMDwvRElWPg0KPERJVj5Gcm9tOiZuYnNwOyJCRUxPVFRJJm5ic3A7U0VSR0lPIiZu YnNwOyAmbHQ7U2VyZ2lvLkJlbG90dGlAYWxjYXRlbC1sdWNlbnQuaXQgDQomZ3Q7PC9ESVY+DQo8 RElWPlN1YmplY3Q6Jm5ic3A7W0NDQU1QXSZuYnNwO1I6Jm5ic3A7RGlzY3Vzc2lvbiZuYnNwO2Fi b3V0Jm5ic3A7dGhlJm5ic3A7R01QTFMmbmJzcDtTaWduYWxpbmcmbmJzcDtFeHRlbnNpb248L0RJ Vj4NCjxESVY+Zm9yRXZvbHV0aXZlJm5ic3A7T1ROPC9ESVY+DQo8RElWPlRvOiZuYnNwOyJGYXRh aSImbmJzcDsgJmx0O3poYW5nZmF0YWlAaHVhd2VpLmNvbSAmZ3Q7LCZuYnNwOyANCiZsdDtmdS54 aWh1YUB6dGUuY29tLmNuICZndDssPC9ESVY+DQo8RElWPiZsdDtkYnJ1bmdhcmRAYXR0LmNvbSAm Z3Q7LCZuYnNwOyAmbHQ7bGJlcmdlckBsYWJuLm5ldCAmZ3Q7LDwvRElWPg0KPERJVj4mbHQ7ZGll Z28uY2F2aWdsaWFAZXJpY3Nzb24uY29tICZndDssPC9ESVY+DQo8RElWPiZsdDtkYW5pZWxlLmNl Y2NhcmVsbGlAZXJpY3Nzb24uY29tICZndDssPC9ESVY+DQo8RElWPiZsdDt6aGFuZ2d1b3lpbmdA bWFpbC5yaXR0LmNvbS5jbiAmZ3Q7LDwvRElWPg0KPERJVj4mbHQ7eHV5dW5iaW5AbWFpbC5yaXR0 LmNvbS5jbiAmZ3Q7PC9ESVY+DQo8RElWPkNjOiZuYnNwO2NjYW1wQGlldGYub3JnPC9ESVY+DQo8 RElWPk1lc3NhZ2UtSUQ6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbHQ7M0Y0NDE4NkQ3MTQx RTI0Nzk3MkVBQzY2NTVCMEEyOTEwMUZBN0E1NkBGUlZFTFNNQlMyMS5hZDIuYWQuYWxjYXRlbC5j b208L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Q29udGVudC1UeXBl OiZuYnNwO3RleHQvcGxhaW47Jm5ic3A7Y2hhcnNldD0iaXNvLTg4NTktMSI8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPkRlYXImbmJzcDtGYXRhaSZuYnNwO2FuZCZuYnNwO2FsbCw8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+V2UmbmJzcDthZ3JlZSZuYnNwO29uJm5ic3A7dGhlJm5ic3A7bWFqb3ImbmJzcDtw b2ludHMmbmJzcDtyYWlzZWQmbmJzcDtieSZuYnNwO0ZhdGFpJm5ic3A7YXMmbmJzcDtnZW5lcmFs Jm5ic3A7aXNzdWUmbmJzcDt0byZuYnNwO2JlPC9ESVY+DQo8RElWPnNvbHZlZCZuYnNwO2luJm5i c3A7dGhlJm5ic3A7Y29udGV4dCZuYnNwO29mJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7bmVlZGVkJm5i c3A7dG8mbmJzcDtjb3BlJm5ic3A7d2l0aCZuYnNwO25ldyZuYnNwO2NvbnRhaW5lcnM8L0RJVj4N CjxESVY+ZGVmaW5lZCZuYnNwO2luJm5ic3A7SVRVJm5ic3A7Jm5ic3A7cTExJm5ic3A7Y29udGV4 dCwmbmJzcDtpbiZuYnNwO2FkZGl0aW9uJm5ic3A7dG8mbmJzcDtoYW5kbGluZyZuYnNwO09EVSZu YnNwO211bHRpcGxleGluZzwvRElWPg0KPERJVj5zY2VuYXJpb3MmbmJzcDtpbiZuYnNwO2V4aXN0 aW5nJm5ic3A7T1ROLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlcmUmbmJzcDth cmUmbmJzcDt0d28mbmJzcDtiYXNpYyZuYnNwO3BvaW50cyZuYnNwO3RoYXQmbmJzcDticmluZ3Mm bmJzcDt0byZuYnNwO3RoZSZuYnNwO25lZWQmbmJzcDt0byZuYnNwO3VwZGF0ZSZuYnNwO3RoZSZu YnNwO1JGQzQzMjg8L0RJVj4NCjxESVY+YW55d2F5LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4xKSZuYnNwO3RoZSZu YnNwO3ByZXNlbnQmbmJzcDtSRkMmbmJzcDtkb2VzJm5ic3A7bm90Jm5ic3A7cGVybWl0Jm5ic3A7 dGhlJm5ic3A7bGluayZuYnNwO2Jhc2VkJm5ic3A7bmVnb3RpYXRpb24mbmJzcDsmbmJzcDtmb3Im bmJzcDt0aW1lPC9ESVY+DQo8RElWPnNsb3QmbmJzcDthbGxvY2F0aW9uJm5ic3A7LiZuYnNwO05v Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDthYm91dCZuYnNwO3RyaWJ1dGFyeSZuYnNwO3BvcnQmbmJz cDtudW1iZXJzJm5ic3A7aXMmbmJzcDtwcmVzZW50PC9ESVY+DQo8RElWPmFuZCZuYnNwO29ubHkm bmJzcDtpbiZuYnNwO2Nhc2UmbmJzcDt3ZSZuYnNwO2hhdmUmbmJzcDsic2luZ2xlJm5ic3A7bGF5 ZXIiJm5ic3A7LCZuYnNwO25vJm5ic3A7bXVsdGlwbGV4aW5nJm5ic3A7TE8mbmJzcDstLSANCiZn dDsmbmJzcDtITyZuYnNwO3lvdTwvRElWPg0KPERJVj5jYW4mbmJzcDthcHBseSZuYnNwOy4mbmJz cDtTbyZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO2EmbmJzcDtsYWNrJm5ic3A7YWdhaW5zdCZuYnNw O3RoZSZuYnNwO29yaWdpbmFsJm5ic3A7Ry43MDkmbmJzcDtldmVuJm5ic3A7d2l0aG91dDwvRElW Pg0KPERJVj5jb25zaWRlcmluZyZuYnNwO0cuNzA5Jm5ic3A7QW0zJm5ic3A7LjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj4yKSZuYnNwO1NjYWxhYmlsaXR5OiZuYnNwO1RoZSZuYnNwO2V4dGVuc2lvbiZuYnNwO3JlcXVp cmVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtjb250ZXh0Jm5ic3A7b2YmbmJzcDtuZXcmbmJzcDtP VE4mbmJzcDt3aXRoPC9ESVY+DQo8RElWPnRoZSZuYnNwO2ludHJvZHVjdGlvbiZuYnNwO29mJm5i c3A7T0RVMCwmbmJzcDtPRFU0LCZuYnNwO2FuZCZuYnNwO2Fib3ZlJm5ic3A7YWxsJm5ic3A7T0RV ZmxleCZuYnNwOywmbmJzcDtyZXF1aXJlZCZuYnNwO2EmbmJzcDtyZWFsPC9ESVY+DQo8RElWPm1v ZGlmaWNhdGlvbnMmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3N0cnVjdHVyZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7bGFiZWwmbmJzcDt0byZuYnNwO2F2b2lkJm5ic3A7cmVhbCZuYnNwO2JpZyZuYnNw O3NpemUmbmJzcDtvZjwvRElWPg0KPERJVj5udW1iZXImbmJzcDtvZiZuYnNwO2xhYmVscyZuYnNw O3RvJm5ic3A7dHJhbnNtaXQmbmJzcDtvZmZsb2FkaW5nJm5ic3A7c2lnbmFsbGluZyZuYnNwO3Nl c3Npb24uJm5ic3A7RXh0ZW5zaW9uPC9ESVY+DQo8RElWPmJhc2VkJm5ic3A7b24mbmJzcDtSRkM0 MzI4Jm5ic3A7bG9naWMmbmJzcDtkbyZuYnNwO25vdCZuYnNwO3NjYWxlJm5ic3A7d2hlbiZuYnNw O09EVS1mbGV4Jm5ic3A7aXMmbmJzcDt1c2VkLiZuYnNwO0xhcmdlJm5ic3A7T0RVPC9ESVY+DQo8 RElWPmZsZXgmbmJzcDtjb250YWluZXJzJm5ic3A7d2lsbCZuYnNwO2dlbmVyYXRlPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5hbiZuYnNwO2V4Y2Vzc2l2ZSZuYnNwO251bWJlciZuYnNw O29mJm5ic3A7bGFiZWxzJm5ic3A7KGluJm5ic3A7cHJpbmNpcGxlJm5ic3A7dXAmbmJzcDt0byZu YnNwOzgwJm5ic3A7cGVyJm5ic3A7bGluaykmbmJzcDtjYXVzaW5nPC9ESVY+DQo8RElWPnByb2Js ZW1zJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO3NpemUmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO1JT VlAtVEUmbmJzcDttZXNzYWdlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGlzJm5ic3A7dHdvJm5ic3A7cG9pbnRz Jm5ic3A7dG9nZXRoZXImbmJzcDtjYWxsJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtuZWVkJm5ic3A7 dG8mbmJzcDtjaGFuZ2UmbmJzcDtzb21ldGhpbmcmbmJzcDtpbiZuYnNwO1JGQy48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJhY2t3YXJkJm5ic3A7Y29tcGF0aWJpbGl0eSZuYnNwO2Fz cGVjdHMsJm5ic3A7cHJlc2VudCZuYnNwO2luJm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7ZHJhZnRz LCZuYnNwO2FyZSZuYnNwO3N1cmVseSZuYnNwO3RvPC9ESVY+DQo8RElWPmJlJm5ic3A7Y29uc2lk ZXJlZCZuYnNwO2FuZCZuYnNwO2lmJm5ic3A7dGhlcmUmbmJzcDthcmUmbmJzcDtzaW5nbGUmbmJz cDtsYXllciZuYnNwO3N5c3RlbXMmbmJzcDtkZXBsb3llZCZuYnNwO3VzaW5nPC9ESVY+DQo8RElW PlJGQzQzMjgmbmJzcDt0aGlzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtncmFuZGZhdGhlcmVk LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5CZXN0Jm5ic3A7UmVnYXJkczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5TZXJnaW88L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5TZXJnaW8mbmJzcDtC ZWxvdHRpPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPkNUTyZuYnNwO09wdGljcyZuYnNwO0RpdmlzaW9uPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5BbGNhdGVsLUx1Y2VudDwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4rMzkmbmJz cDswMzkmbmJzcDs2ODYzMDMzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4rMzkmbmJz cDswMzkmbmJzcDs2ODYzNTkwPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5EYTombmJzcDtjY2FtcC1ib3Vu Y2VzQGlldGYub3JnJm5ic3A7W21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSZuYnNwO1Bl ciZuYnNwO2NvbnRvJm5ic3A7ZGk8L0RJVj4NCjxESVY+RmF0YWk8L0RJVj4NCjxESVY+SW52aWF0 bzombmJzcDttZXJjb2xlZD8mbmJzcDsyOSZuYnNwO2x1Z2xpbyZuYnNwOzIwMDkmbmJzcDsxOC4z MzwvRElWPg0KPERJVj5BOiZuYnNwO2Z1LnhpaHVhQHp0ZS5jb20uY247Jm5ic3A7ZGJydW5nYXJk QGF0dC5jb207Jm5ic3A7bGJlcmdlckBsYWJuLm5ldDs8L0RJVj4NCjxESVY+ZGllZ28uY2F2aWds aWFAZXJpY3Nzb24uY29tOyZuYnNwO2RhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb207PC9E SVY+DQo8RElWPnpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuOyZuYnNwO3h1eXVuYmluQG1h aWwucml0dC5jb20uY248L0RJVj4NCjxESVY+Q2M6Jm5ic3A7Y2NhbXBAaWV0Zi5vcmc8L0RJVj4N CjxESVY+T2dnZXR0bzombmJzcDtSZTombmJzcDtbQ0NBTVBdJm5ic3A7RGlzY3Vzc2lvbiZuYnNw O2Fib3V0Jm5ic3A7dGhlJm5ic3A7R01QTFMmbmJzcDtTaWduYWxpbmcmbmJzcDtFeHRlbnNpb248 L0RJVj4NCjxESVY+Zm9yRXZvbHV0aXZlJm5ic3A7T1ROPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkhpJm5ic3A7YWxs LDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5UbyZuYnNwO3N1cHBvcnQmbmJzcDt0aGUmbmJzcDtjdXJyZW50Jm5ic3A7 dmVyaXNvbiZuYnNwO29mJm5ic3A7Ry43MDksJm5ic3A7d2UmbmJzcDt0aGluayZuYnNwO3RoZSZu YnNwO2xhYmVsJm5ic3A7Zm9ybWF0PC9ESVY+DQo8RElWPmRlZmluZWQmbmJzcDtpbiZuYnNwO1JG QzQzMjgmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDtiZSZuYnNwO3JlLWRlZmluZWQmbmJzcDthbnl3 YXkuJm5ic3A7VGhlJm5ic3A7bmV3Jm5ic3A7T1ROJm5ic3A7bGFiZWw8L0RJVj4NCjxESVY+Zm9y bWF0Jm5ic3A7c2hvdWxkJm5ic3A7c3VwcG9ydCZuYnNwO3RoZSZuYnNwO3dob2xlJm5ic3A7T0RV Jm5ic3A7c2V0cywmbmJzcDtub3QmbmJzcDtvbmx5Jm5ic3A7dGhlJm5ic3A7T0RVMSwmbmJzcDsy LCZuYnNwO2FuZCZuYnNwOzMsPC9ESVY+DQo8RElWPmJ1dCZuYnNwO2Fsc28mbmJzcDtPRFUwLCZu YnNwO09EVTQsJm5ic3A7ZXZlbiZuYnNwO09EVUZsZXguJm5ic3A7VGhlJm5ic3A7Zm9sbG93aW5n Jm5ic3A7dGhyZWUmbmJzcDthc3BlY3RzJm5ic3A7c2hvdWxkJm5ic3A7YmU8L0RJVj4NCjxESVY+ Y29uc2lkZXJlZCZuYnNwO2NhcmVmdWxseTo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+MSkmbmJzcDtUaGUmbmJzcDtl eHRlbnNpYmlsaXR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtsYWJlbCZuYnNwO2Zvcm1hdCZuYnNw O2lzJm5ic3A7dGhlJm5ic3A7Zmlyc3QmbmJzcDt0aGluZyZuYnNwO3dlJm5ic3A7c2hvdWxkPC9E SVY+DQo8RElWPmNvbnNpZGVyLiZuYnNwO1dpdGgmbmJzcDt0aGUmbmJzcDtkZXZlbG9wbWVudCZu YnNwO29mJm5ic3A7T1ROJm5ic3A7dGVjaG5vbG9neSwmbmJzcDtSRkM0MzI4Jm5ic3A7bGFiZWwm bmJzcDtmb3JtYXQ8L0RJVj4NCjxESVY+c3R5bGUmbmJzcDtuZWVkcyZuYnNwO3RvJm5ic3A7YmUm bmJzcDtleHRlbmRlZCZuYnNwO3RvJm5ic3A7c3VwcG9ydCZuYnNwO3RoZSZuYnNwO25ldyZuYnNw O2JpdHJhdGUmbmJzcDtPRFUmbmJzcDsoZWcuJm5ic3A7T0RVNSw8L0RJVj4NCjxESVY+Ni4uLiku Jm5ic3A7QnkmbmJzcDt0aGUmbmJzcDtlbmQsJm5ic3A7d2UmbmJzcDttYXkmbmJzcDtuZWVkJm5i c3A7a2VlcCZuYnNwO2V4dGVuZGluZyZuYnNwO3RoZSZuYnNwO2xhYmVsJm5ic3A7Zm9ybWF0cy48 L0RJVj4NCjxESVY+TWFuYWdpbmcmbmJzcDtsb3RzJm5ic3A7b2YmbmJzcDtsYWJlbCZuYnNwO2Zv cm1hdCZuYnNwO21heSZuYnNwO2NhdXNlJm5ic3A7YmlnJm5ic3A7dHJvdWJsZSwmbmJzcDtzbyZu YnNwO3dlJm5ic3A7bmVlZCZuYnNwO29uZS1zaG90PC9ESVY+DQo8RElWPmxhYmVsJm5ic3A7Zm9y bWF0Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZXZvbHZpbmcmbmJzcDtPVE4uJm5ic3A7Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjIpJm5ic3A7U2NhbGFiaWxpdHkmbmJzcDtpcyZuYnNwO2Fub3RoZXImbmJz cDtrZXkmbmJzcDtpc3N1ZS4mbmJzcDtSRkM0MzI4Jm5ic3A7c3R5bGUmbmJzcDtmb3JtYXQmbmJz cDttYXkmbmJzcDtyZXN1bHQmbmJzcDtpbjwvRElWPg0KPERJVj5iaWcmbmJzcDtzaXplJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDt0b3RhbCZuYnNwO2xhYmVscywmbmJzcDt3aGljaCZuYnNwO2RlZmlu aXRlbHkmbmJzcDtpbmNyZWFzZSZuYnNwO3RoZSZuYnNwO2J1cmRlbiZuYnNwO29mPC9ESVY+DQo8 RElWPnRoZSZuYnNwO3NpZ25hbGluZy4mbmJzcDtBbiZuYnNwO2VmZmljaWVudCZuYnNwO2FwcHJv YWNoJm5ic3A7aXMmbmJzcDtuZWVkZWQmbmJzcDt0byZuYnNwO2NhcnJ5Jm5ic3A7dGhlJm5ic3A7 c2FtZSZuYnNwO2xhYmVsPC9ESVY+DQo8RElWPmluZm9ybWF0aW9uJm5ic3A7YnV0Jm5ic3A7d2l0 aCZuYnNwO2xlc3MmbmJzcDthbW91bnQmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2RhdGEsJm5ic3A7 Yml0bWFwJm5ic3A7c3R5bGUmbmJzcDtpcyZuYnNwO3RoZSZuYnNwO3JpZ2h0PC9ESVY+DQo8RElW PndheSZuYnNwO3RvJm5ic3A7Z28uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjMpJm5ic3A7Rm9yJm5ic3A7YmFja3dh cmQmbmJzcDtjb21wYXRpYmlsaXR5LCZuYnNwO2lmJm5ic3A7dGhlcmUmbmJzcDthcmUmbmJzcDtu byZuYnNwO2ltcGxlbWVudGF0aW9ucyZuYnNwO2ZvcjwvRElWPg0KPERJVj5SRkM0MzI4Jm5ic3A7 KG9yJm5ic3A7aWYmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNwO25vJm5ic3A7ZGVwbG95bWVudHMm bmJzcDtpdCZuYnNwO2lzJm5ic3A7ZGVzaXJhYmxlJm5ic3A7dG8mbmJzcDtkZXByZWNhdGU8L0RJ Vj4NCjxESVY+ZXZlbiZuYnNwO2lmJm5ic3A7aXQmbmJzcDtpcyZuYnNwO3VuY29tZm9ydGFibGUm bmJzcDtmb3ImbmJzcDtleGlzdGluZyZuYnNwO2ltcGxlbWVudGF0aW9ucyksJm5ic3A7aXQmbmJz cDtpcyZuYnNwO3Zlcnk8L0RJVj4NCjxESVY+c2FmZSZuYnNwO3RvJm5ic3A7ZGVwcmVjYXRlJm5i c3A7dGhlJm5ic3A7b2xkJm5ic3A7ZGVmaW5pdGlvbiwmbmJzcDthbmQmbmJzcDthbiZuYnNwO2V4 dGVuc2libGUsJm5ic3A7ZWZmaWNpZW50Jm5ic3A7YW5kPC9ESVY+DQo8RElWPnNjYWxhYmxlJm5i c3A7c29sdXRpb24mbmJzcDtjb3VsZCZuYnNwO2JlJm5ic3A7aGVscGZ1bC4mbmJzcDtUaGUmbmJz cDtsYWJlbCZuYnNwO2RlZmluZWQmbmJzcDtpbiZuYnNwO2RyYWZ0LXpoYW5nPC9ESVY+DQo8RElW PmRvZXMmbmJzcDtub3QmbmJzcDtvdmVyd3JpdGUmbmJzcDtSRkM0MzI4LCZuYnNwO2l0Jm5ic3A7 Y2FuJm5ic3A7YWxsb3cmbmJzcDt0aGUmbmJzcDtvbGQmbmJzcDtkZWZpbml0aW9uJm5ic3A7dG8m bmJzcDtjb250aW51ZTwvRElWPg0KPERJVj50byZuYnNwO2V4aXN0LjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Ib3Bl Jm5ic3A7dGhpcyZuYnNwO2NhbiZuYnNwO2NsYXJpZnkmbmJzcDt5b3VyJm5ic3A7Y29uY2Vybi48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+QXV0aG9ycyZuYnNwO29mJm5ic3A7ZHJhZnQtemhhbmc8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0tJm5ic3A7T3JpZ2luYWwmbmJzcDtNZXNzYWdlJm5ic3A7 LS0tLS0mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkZyb206Jm5ic3A7ZnUu eGlodWFAenRlLmNvbS5jbiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VG86 Jm5ic3A7ZGJydW5nYXJkQGF0dC5jb20mbmJzcDs7Jm5ic3A7bGJlcmdlckBsYWJuLm5ldCZuYnNw OzsmbmJzcDt6aGFuZ2ZhdGFpQGh1YXdlaS5jb208L0RJVj4NCjxESVY+OyZuYnNwO2RpZWdvLmNh dmlnbGlhQGVyaWNzc29uLmNvbSZuYnNwOzsmbmJzcDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5DYzombmJzcDtjY2Ft cEBpZXRmLm9yZyZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+U2VudDombmJz cDtUdWVzZGF5LCZuYnNwO0p1bHkmbmJzcDsyOCwmbmJzcDsyMDA5Jm5ic3A7NTozMyZuYnNwO1BN PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5TdWJqZWN0OiZuYnNwO0Rpc2N1c3Npb24m bmJzcDthYm91dCZuYnNwO3RoZSZuYnNwO0dNUExTJm5ic3A7U2lnbmFsaW5nJm5ic3A7RXh0ZW5z aW9uJm5ic3A7Zm9yPC9ESVY+DQo8RElWPkV2b2x1dGl2ZSZuYnNwO09UTjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+SGkmbmJzcDtGYXRhaSZuYnNwO2FuZCZuYnNwO0FsbCwmbmJzcDs8L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPldlJm5ic3A7aGF2ZSZuYnNwO3ByZXNlbnRlZCZuYnNwO3RoZSZu YnNwO2ZvbGxvd2luZyZuYnNwO3R3byZuYnNwO2RvY3VtZW50Jm5ic3A7Jm5ic3A7aW4mbmJzcDt0 aGUmbmJzcDtDQ0FNUDwvRElWPg0KPERJVj5tb3JuaW5nJm5ic3A7c2Vzc2lvbi4mbmJzcDtCdXQm bmJzcDt3ZSZuYnNwO2hhdmUmbmJzcDtubyZuYnNwO21vcmUmbmJzcDt0aW1lJm5ic3A7dG8mbmJz cDtmdXJ0aGVyJm5ic3A7ZGlzY3VzcyZuYnNwO0dNUExTPC9ESVY+DQo8RElWPmV4dGVuc2lvbiZu YnNwO2ZvciZuYnNwO2V2b2x1dGl2ZSZuYnNwO09UTiZuYnNwOzwvRElWPg0KPERJVj5kcmFmdC1j ZWNjYXJlbGxpZnV4aC1jY2FtcC1nbXBscy1leHQtZm9yLWV2b2wtb3RuLTAwLnR4dDwvRElWPg0K PERJVj4mbHQ7PEEgDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jZWNj YXJlbGxpZnV4aC1jY2FtcC1nbXBscy1leHQtZm9yLWV2byI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtY2VjY2FyZWxsaWZ1eGgtY2NhbXAtZ21wbHMtZXh0LWZvci1ldm88L0E+PC9E SVY+DQo8RElWPmwtb3RuLTAwICZndDsmbmJzcDsmbmJzcDs8L0RJVj4NCjxESVY+ZHJhZnQtemhh bmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMS50eHQ8L0RJVj4NCjxESVY+Jmx0OzxBIA0K aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMt ZXZvbHZpbmctZzcwOS0wMS50eHQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDEudHh0PC9BPjwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5XZSZuYnNwO2hhdmUmbmJzcDth Jm5ic3A7Y291cGxlJm5ic3A7b2YmbmJzcDtjb21tZW50cyZuYnNwO2FuZCZuYnNwO3F1ZXN0aW9u cyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2RyYWZ0LXpoYW5nLiZuYnNwOzwvRElWPg0KPERJVj4o MSkmbmJzcDtkcmFmdC16aGFuZyZuYnNwO2RlZmluZWQmbmJzcDt0aGUmbmJzcDtleHRlbnNpb25z Jm5ic3A7aW5jbHVkaW5nJm5ic3A7d2hhdCZuYnNwO2hhcyZuYnNwO2JlZW48L0RJVj4NCjxESVY+ ZG9uZSZuYnNwO2luJm5ic3A7UkZDNDMyOCZuYnNwOyhpLmUuLCZuYnNwO09EVTEsJm5ic3A7T0RV MiZuYnNwO2FuZCZuYnNwO09EVTMpLiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtkcmFmdC1jZWNjYXJlbGxpZnV4aCZuYnNwO2RlZmluZWQmbmJz cDtuZXcmbmJzcDtHbmVyYWxpemVkJm5ic3A7TGFiZWwmbmJzcDtvbmx5Jm5ic3A7Zm9yPC9ESVY+ DQo8RElWPm5ldyZuYnNwO2FwcGxpY2F0aW9uJm5ic3A7KGkuZS4sJm5ic3A7T0RVMCwmbmJzcDsx LjI1RyZuYnNwO09EVTEsJm5ic3A7MS4yNUcmbmJzcDtPRFUyLCZuYnNwOzEuMjVHJm5ic3A7T0RV MywmbmJzcDtPRFUyZSw8L0RJVj4NCjxESVY+T0RVM2UxLCZuYnNwO09EVTNlMiwmbmJzcDtPRFVm bGV4Jm5ic3A7YW5kJm5ic3A7T0RVNCkuJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWNlY2NhcmVsbGlmdXhoJm5ic3A7aXMmbmJzcDtv bmx5Jm5ic3A7YSZuYnNwO3N1cHBsZW1lbnQmbmJzcDtvZiZuYnNwO1JGQzQzMjguJm5ic3A7PC9E SVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hvdyZuYnNwO2Nh biZuYnNwO3dlJm5ic3A7dXNlZCZuYnNwO1JGQzQzMjgmbmJzcDthbmQmbmJzcDtkcmFmdC16aGFu ZyZuYnNwOz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QW55Jm5ic3A7d2F5LCZu YnNwO2lmJm5ic3A7d2UmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDt1cGRhdGUmbmJzcDthbiZuYnNw O3ByZXZpb3VzJm5ic3A7UkZDLCZuYnNwO3dlJm5ic3A7c2hvdWxkPC9ESVY+DQo8RElWPmFzc3Vt ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtkZXBsb3llZCwmbmJz cDtub3QmbmJzcDthc2tpbmcmbmJzcDtpZiZuYnNwO3NvbWVvbmUmbmJzcDtkaWQmbmJzcDtvciZu YnNwO25vdC4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPigyKSZuYnNwO0RvJm5ic3A7 eW91Jm5ic3A7cmVhbGx5Jm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7cmVtb3ZlJm5ic3A7Tk1DJm5i c3A7ZnJvbSZuYnNwO3RoZSZuYnNwO1RyYWZmaWM8L0RJVj4NCjxESVY+UGFyYW1ldGVycz8mbmJz cDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYmbmJz cDt5b3UmbmJzcDtkbyZuYnNwO3RoYXQsJm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7d2UmbmJzcDto YXZlJm5ic3A7dG8mbmJzcDthYmFuZG9uJm5ic3A7UkZDNDMyOC4mbmJzcDs8L0RJVj4NCjxESVY+ PC9ESVY+DQo8RElWPigzKSZuYnNwO1RoZSZuYnNwO2NvbXBhdGliaWxpdHkmbmJzcDtjb25zaWRl cmF0aW9uJm5ic3A7aW4mbmJzcDtkcmFmdC16aGFuZy4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7V2UmbmJzcDtkb24ndCZuYnNwO3RoaW5rJm5ic3A7dGhlJm5ic3A7ZXh0ZW5z aW9ucyZuYnNwO2luJm5ic3A7ZHJhZnQtemhhbmcmbmJzcDtjYW4mbmJzcDtjb2V4aXN0Jm5ic3A7 d2l0aDwvRElWPg0KPERJVj5SRkM0MzI4LiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDtZb3UmbmJzcDtwb2ludCZuYnNwO291dCZuYnNwOyJ3ZSZuYnNwO2NhbiZuYnNwO2p1c3Qm bmJzcDtkbyZuYnNwO3NvbWUmbmJzcDt0cmFuc2xhdGlvbiZuYnNwO29yJm5ic3A7bWFwcGluZyZu YnNwO2luPC9ESVY+DQo8RElWPnRoZSZuYnNwO25ldyZuYnNwO25vZGVzIi4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7QnV0Jm5ic3A7YmVmb3JlJm5ic3A7dGhlJm5ic3A7dHJh bnNsYXRpb24mbmJzcDtvciZuYnNwO21hcHBpbmcsJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Rv Jm5ic3A7a25vdyZuYnNwO3RoZTwvRElWPg0KPERJVj5HZW5lcmFsaXplZCZuYnNwO0xhYmVsJm5i c3A7Rm9ybWF0LiZuYnNwOyZuYnNwOyZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJz cDtXZSZuYnNwO2NvbmNlcm4mbmJzcDthYm91dDombmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7aSkmbmJzcDsmbmJzcDtIb3cmbmJzcDtkb2VzJm5ic3A7b25l Jm5ic3A7bm9kZSZuYnNwO2tub3cmbmJzcDt0aGUmbmJzcDtHZW5lcmFsaXplZCZuYnNwO0xhYmVs Jm5ic3A7Zm9ybWF0LDwvRElWPg0KPERJVj5lc3BlY2lhbGx5Jm5ic3A7Zm9yJm5ic3A7T0RVMSwm bmJzcDtPRFUyJm5ic3A7YW5kJm5ic3A7T0RVMyZuYnNwO2Jhc2UmbmJzcDtvbiZuYnNwO3lvdXIm bmJzcDtzb2x1dGlvbj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SXQmbmJzcDtt YXkmbmJzcDtkZXBlbmQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2NhcGFiaWxpdHkmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2FkamFjZW50Jm5ic3A7bmV0d29yazwvRElWPg0KPERJVj5lbGVtZW50LiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtpaSkmbmJzcDtCdXQmbmJzcDtob3cm bmJzcDtjYW4mbmJzcDt0aGUmbmJzcDtjb250cm9sJm5ic3A7cGxhbmUmbmJzcDtrbm93Jm5ic3A7 dGhlJm5ic3A7YWRqYWNlbnQmbmJzcDtuZXR3b3JrPC9ESVY+DQo8RElWPmVsZW1lbnQncyZuYnNw O2NhcGFiaWxpdHkmbmJzcDt3aXRob3V0Jm5ic3A7ZGlzY292ZXJ5Jm5ic3A7bWVjaGFuaXNtPyZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtZb3UmbmJzcDtzaG91bGQmbmJzcDtrbm93Jm5ic3A7dGhhdCZuYnNwO0dNUExTJm5ic3A7c2ln bmFsaW5nJm5ic3A7ZXh0ZW5zaW9uJm5ic3A7c2hvdWxkJm5ic3A7YmU8L0RJVj4NCjxESVY+aW5k ZXBlbmRlbnQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2Rpc2NvdmVyeSZuYnNwO21lY2hhbmlzbSZu YnNwO2FuZCZuYnNwO3RoZSZuYnNwO2NvbmZpZ3VyYXRpb24mbmJzcDtvZjwvRElWPg0KPERJVj5t YW5hZ2VtZW50Jm5ic3A7cGxhbmUuJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNw O2lpaSkmbmJzcDtUaGUmbmJzcDtjb250cm9sJm5ic3A7cGxhbmUmbmJzcDtkb24ndCZuYnNwO25l ZWQmbmJzcDt0byZuYnNwO2tub3cmbmJzcDt0aGUmbmJzcDtHLjcwOSgyMDAzLzAzKTwvRElWPg0K PERJVj5vciZuYnNwO0cuNzA5Jm5ic3A7QW1lbmRtZW50MyZuYnNwO25ldHdvcmsmbmJzcDtlbGVt ZW50PyZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4mbmJzcDthJm5i c3A7d29yZCwmbmJzcDt3ZSZuYnNwO3RoaW5rJm5ic3A7aXQmbmJzcDtjYW4mbmJzcDtub3QmbmJz cDtkbyZuYnNwO3RoZSZuYnNwO3RyYW5zbGF0aW9uJm5ic3A7YW5kPC9ESVY+DQo8RElWPm1hcHBp bmcuJm5ic3A7U28mbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO25vdCZuYnNwO2dldCZuYnNwO3RoZSZu YnNwO2NvbXBhdGliaWxpdHkmbmJzcDt3aXRoJm5ic3A7UkZDNDMyOCZuYnNwO2luPC9ESVY+DQo8 RElWPmRyYWZ0LXpoYW5nLiZuYnNwOzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7KDQp Jm5ic3A7VGhlJm5ic3A7R2VuZXJhbGl6ZWQmbmJzcDtMYWJlbCZuYnNwO2luJm5ic3A7ZHJhZnQt emhhbmcmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO21h bmFnaW5nJm5ic3A7YSZuYnNwO3ZhcmlhYmxlJm5ic3A7bGVuZ3RoJm5ic3A7bGFiZWwmbmJzcDtj b3VsZCZuYnNwO2JlJm5ic3A7YSZuYnNwO21lc3MuJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtkcmFmdC16aGFuZyZuYnNwO3VzZXMmbmJzcDthJm5ic3A7 Zmlyc3QmbmJzcDtwYXJ0Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtsYWJlbCZuYnNwO3doaWNoJm5i c3A7aGFzJm5ic3A7Zml4ZWQ8L0RJVj4NCjxESVY+dmFsdWVzJm5ic3A7YW5kJm5ic3A7dGhlbiZu YnNwO2EmbmJzcDt2YXJpYWJsZSZuYnNwO251bWJlciZuYnNwO29mJm5ic3A7Yml0Jm5ic3A7dGhh dCZuYnNwO2lzJm5ic3A7dGhlJm5ic3A7Yml0bWFwLiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUmbmJzcDtiaXRtYXAmbmJzcDtj YW4mbmJzcDtiZSZuYnNwO2xvbmcmbmJzcDtmcm9tJm5ic3A7MCZuYnNwO3RvJm5ic3A7ODAmbmJz cDtiaXRzJm5ic3A7ZGVwZW5kaW5nJm5ic3A7b24mbmJzcDt0aGU8L0RJVj4NCjxESVY+c2lnbmFs Jm5ic3A7dHlwZS4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZu YnNwO3RoZSZuYnNwO3ZhbHVlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtiaXRtYXAmbmJzcDtpcyZu YnNwO25vdCZuYnNwO2luZGVwZW5kZW50Jm5ic3A7YnV0Jm5ic3A7ZGVwZW5kcyZuYnNwO29uPC9E SVY+DQo8RElWPnRoZSZuYnNwO3ZhbHVlcyZuYnNwO29mJm5ic3A7dHdvJm5ic3A7cHJldmlvdXMm bmJzcDtmaWVsZHMmbmJzcDsoT0RVayZuYnNwO2FuZCZuYnNwO09EVWopJm5ic3A7YW5kJm5ic3A7 YmVjb21lcyZuYnNwO3Jlc2VydmVkPC9ESVY+DQo8RElWPmluJm5ic3A7Y2FzZSZuYnNwO29mJm5i c3A7Sz1KJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDth Jm5ic3A7Yml0bWFwJm5ic3A7bGFiZWwmbmJzcDtoYXZlJm5ic3A7bm90Jm5ic3A7YmVlbiZuYnNw O3VzZWQmbmJzcDtub3ImbmJzcDtpbiZuYnNwO1NESCZuYnNwO2FuZCZuYnNwO25vdCZuYnNwO2lu PC9ESVY+DQo8RElWPldTT04mbmJzcDt3aGVyZSZuYnNwO2EmbmJzcDtmaXhlZCZuYnNwO2xhYmVs Jm5ic3A7KDQmbmJzcDtieXRlcykmbmJzcDtpcyZuYnNwO3VzZWQuJm5ic3A7PC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj5YaWh1YSZuYnNwO0Z1Jm5ic3A7PC9ESVY+DQo8RElWPlpURSZuYnNwOzwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4t LS0tLS0tLS0tLS0tLSZuYnNwO25leHQmbmJzcDtwYXJ0Jm5ic3A7LS0tLS0tLS0tLS0tLS08L0RJ Vj4NCjxESVY+QW4mbmJzcDtIVE1MJm5ic3A7YXR0YWNobWVudCZuYnNwO3dhcyZuYnNwO3NjcnVi YmVkLi4uPC9ESVY+DQo8RElWPlVSTDo8L0RJVj4NCjxESVY+Jmx0OzxBIA0KaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NjYW1wL2F0dGFjaG1lbnRzLzIwMDkwNzMw L2JmY2VjNTAiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jY2FtcC9hdHRh Y2htZW50cy8yMDA5MDczMC9iZmNlYzUwPC9BPjwvRElWPg0KPERJVj40L2F0dGFjaG1lbnQuaHRt ICZndDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+Q0NBTVAmbmJzcDtt YWlsaW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj5DQ0FNUEBpZXRmLm9yZzwvRElWPg0KPERJVj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+RW5kJm5ic3A7b2YmbmJzcDtDQ0FN UCZuYnNwO0RpZ2VzdCwmbmJzcDtWb2wmbmJzcDsxNCwmbmJzcDtJc3N1ZSZuYnNwOzI2PC9ESVY+ DQo8RElWPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L0RJVj48L0ZPTlQ+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon210161456336_=====-- From lberger@labn.net Fri Aug 14 08:20:42 2009 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 1A3BB3A6B5F for ; Fri, 14 Aug 2009 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=-1.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, MIME_CHARSET_FARAWAY=2.45] 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 JDEDohsiGhWl for ; Fri, 14 Aug 2009 08:20:40 -0700 (PDT) Received: from outbound-mail-152.bluehost.com (outbound-mail-152.bluehost.com [67.222.39.32]) by core3.amsl.com (Postfix) with SMTP id 210183A6860 for ; Fri, 14 Aug 2009 08:20:40 -0700 (PDT) Received: (qmail 3938 invoked by uid 0); 14 Aug 2009 15:20:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 14 Aug 2009 15:20:41 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=a2i15Uks5OrYynBc/Nx7PIf7gntNQfd0NTx4VTIK8vQuJxztf+xkZX5ZlqqrKiaFwcyczKltkevs1GX6gkyHdvU3MdygDtfDWtIHWvU0vToX1rGdtN5RmheZRD68G3nI; 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 1Mbya8-0004gx-Pm; Fri, 14 Aug 2009 09:20:41 -0600 Message-ID: <4A8580CF.3060507@labn.net> Date: Fri, 14 Aug 2009 11:20:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Fatai Zhang References: <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> <26bbdc380908131209x31719bedw6dcd55c1dd47844@mail.gmail.com> <008901ca1c83$fba46930$5b4c460a@china.huawei.com> In-Reply-To: <008901ca1c83$fba46930$5b4c460a@china.huawei.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=GB2312 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: xuyunbin@mail.ritt.com.cn, ccamp@ietf.org, ext zhangguoying , "Jin, Lizhong \(NSN - CN/Shanghai\)" Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 14 Aug 2009 15:20:42 -0000 Fatai, I think the discussion on this topic is quite useful and I don't want to limit it. That said, I personally think that compatibility (or coexistence) with existing standards track RFCs is very important, and that deprecation or replacement is a step that should only be taken as an exception and not the norm. Lou On 8/13/2009 10:07 PM, Fatai Zhang wrote: > Hi all, > > If there are no implementations for RFC4328 in the industry, do you > really think that we need two totally different label formats and > intentionally introduce the backward compatibility ? Do we really like > trouble very much ? > > We always admit that we should consider backward compatibility if there > are deployments for RFC4328. > > I think if we really need to consider backward compatibility, we should > focus on how to resolve it, but not focus on merging two documents, > because the label formats in two documents are very different and the > solutions for the backward compatibility may also be different. > > > > > Thanks > > Fatai > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 > > ----- Original Message ----- > *From:* Frederick Robinson > *To:* Jin, Lizhong (NSN - CN/Shanghai) > *Cc:* ccamp@ietf.org ; ext zhangguoying > ; xuyunbin@mail.ritt.com.cn > > *Sent:* Friday, August 14, 2009 3:09 AM > *Subject:* Re: [CCAMP] Discussion about the GMPLS Signaling Extension > > Hi all: > > I Agree with Lizhong. > > We took several years to standardize the GMPLS extension for ODU1, > ODU2 and ODU3. > Technology of OTN is developing. We also need some time to > standardize the extension for the new application. We can not forbid > vendor/carrier to deploy the OTN based on RFC4328 at any time. We > should keep them from waiting for the new extension. Further more, > any extension can not completely promise to fit any new application > in the future. So we have to deal with it step by step. There is > some backward compatibility considerations and solution in > draft-ceccarellifuxh. There is also a extensible lable format in > draft-zhang. Why should we take a long time to survey it among the > OTN service providers. Two documents should be merged as soon as > possible. > > Bedford > > ** > 2009/8/12 Jin, Lizhong (NSN - CN/Shanghai) > > > Hi all: > What I need to clarify from my side is that abandoning a RFC is > not preferred in any case. If we can develop a backward solution > by merging draft-ceccarellifuxh and draft-zhang, why don't we go > in this way. > > BR > Lizhong Jin > > ------------------------------------------------------------------------ > *From:* ext zhangguoying [mailto:zhangguoying@mail.ritt.com.cn > ] > *Sent:* Tuesday, August 04, 2009 22:03 > > *To:* Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org > > *Cc:* zhangfatai@huawei.com ; > fu.xihua@zte.com.cn ; > dbrungard@att.com ; lberger@labn.net > ; diego.caviglia@ericsson.com > ; > daniele.ceccarelli@ericsson.com > ; > xuyunbin@mail.ritt.com.cn > > *Subject:* Re: RE: Discussion about the GMPLS Signaling Extension > > Hi all, > > As many experts have explained, the label encoding with bit map > in draft-zhang is surely a better way to > achieve extensibility and scalability of OTN lable. > > The main issue that bit map label format might have is > the backword compatibility. I think we might need to start an > survey among the OTN service providers in the mailing list, and > see if there are any OTN networks deployed with GMPLS > RFC4328 lable format. > > If there're no real deployment, we don't need to consider the > compatability problem; > > If there're some deployment, compatability problem need to > be solved . An easy way might be adding an label version bit in > the label format, or some other solutions may be searched out. > > > best regards, > Guoying Zhang > > > > 2009-08-04 > ------------------------------------------------------------------------ > zhangguoying > ------------------------------------------------------------------------ > *·¢¼þÈË£º* Jin, Lizhong (NSN - CN/Shanghai) > *·¢ËÍʱ¼ä£º* 2009-08-04 13:34:24 > *ÊÕ¼þÈË£º* ccamp@ietf.org > *³­ËÍ£º* zhangfatai@huawei.com ; > fu.xihua@zte.com.cn ; > dbrungard@att.com ; lberger@labn.net > ; diego.caviglia@ericsson.com > ; > daniele.ceccarelli@ericsson.com > ; > zhangguoying@mail.ritt.com.cn > ; > xuyunbin@mail.ritt.com.cn > *Ö÷Ì⣺* RE: Discussion about the GMPLS Signaling Extension > Hi Fatai and all: > I agree with the issues of excessive number of labels if using the same > label concept of RFC4328. By using bit map for label encoding is a good > idea. And from my understanding, > draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit > map idea if Fatai agree. > > For backward compatibility, we can not assume that RFC4328 is not > deployed unless we can provide some kind of survey report. So currently > the right assumption is that RFC4328 has been deployed, and backward > compatibity should be considered. > > Best Regards > Lizhong Jin > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 30 Jul 2009 11:33:56 +0200 > From: "BELOTTI SERGIO" > > Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension > forEvolutive OTN > To: "Fatai" >, >, > >, > >, > >, > >, > >, > > > Cc: ccamp@ietf.org > Message-ID: > <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com > > > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fatai and all, > > > > We agree on the major points raised by Fatai as general issue to be > solved in the context of extension needed to cope with new containers > defined in ITU q11 context, in addition to handling ODU multiplexing > scenarios in existing OTN. > > There are two basic points that brings to the need to update the RFC4328 > anyway. > > > > 1) the present RFC does not permit the link based negotiation for time > slot allocation . No information about tributary port numbers is present > and only in case we have "single layer" , no multiplexing LO -- > > HO you > can apply . So this is a lack against the original G.709 even without > considering G.709 Am3 . > > > > 2) Scalability: The extension required in the context of new OTN with > the introduction of ODU0, ODU4, and above all ODUflex , required a real > modifications of the structure of the label to avoid real big size of > number of labels to transmit offloading signalling session. Extension > based on RFC4328 logic do not scale when ODU-flex is used. Large ODU > flex containers will generate > > an excessive number of labels (in principle up to 80 per link) causing > problems with the size of the RSVP-TE message. > > > > This two points together call to the need to change something in RFC. > > Backward compatibility aspects, present in all the drafts, are surely to > be considered and if there are single layer systems deployed using > RFC4328 this should be grandfathered. > > > > Best Regards > > > > Sergio > > > > > > Sergio Belotti > > > > CTO Optics Division > > Alcatel-Lucent > > > > +39 039 6863033 > > +39 039 6863590 > > > > ________________________________ > > Da: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org > ] Per conto di > Fatai > Inviato: mercoled? 29 luglio 2009 18.33 > A: fu.xihua@zte.com.cn > ; dbrungard@att.com > ; lberger@labn.net > ; > diego.caviglia@ericsson.com > ; daniele.ceccarelli@ericsson.com > ; > zhangguoying@mail.ritt.com.cn > ; xuyunbin@mail.ritt.com.cn > Cc: ccamp@ietf.org > Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension > forEvolutive OTN > > > > Hi all, > > > > To support the current verison of G.709, we think the label format > defined in RFC4328 need to be re-defined anyway. The new OTN label > format should support the whole ODU sets, not only the ODU1, 2, and 3, > but also ODU0, ODU4, even ODUFlex. The following three aspects should be > considered carefully: > > > > 1) The extensibility of the label format is the first thing we should > consider. With the development of OTN technology, RFC4328 label format > style needs to be extended to support the new bitrate ODU (eg. ODU5, > 6...). By the end, we may need keep extending the label formats. > Managing lots of label format may cause big trouble, so we need one-shot > label format for the evolving OTN. > > > > 2) Scalability is another key issue. RFC4328 style format may result in > big size of the total labels, which definitely increase the burden of > the signaling. An efficient approach is needed to carry the same label > information but with less amount of the data, bitmap style is the right > way to go. > > > > 3) For backward compatibility, if there are no implementations for > RFC4328 (or if there are no deployments it is desirable to deprecate > even if it is uncomfortable for existing implementations), it is very > safe to deprecate the old definition, and an extensible, efficient and > scalable solution could be helpful. The label defined in draft-zhang > does not overwrite RFC4328, it can allow the old definition to continue > to exist. > > > > Hope this can clarify your concern. > > > > Authors of draft-zhang > > > > > > > > ----- Original Message ----- > > From: fu.xihua@zte.com.cn > > To: dbrungard@att.com > ; lberger@labn.net > ; zhangfatai@huawei.com > > ; diego.caviglia@ericsson.com > ; daniele.ceccarelli@ericsson.com > > > Cc: ccamp@ietf.org > > Sent: Tuesday, July 28, 2009 5:33 PM > > Subject: Discussion about the GMPLS Signaling Extension for > Evolutive OTN > > > > Hi Fatai and All, > We have presented the following two document in the CCAMP > morning session. But we have no more time to further discuss GMPLS > extension for evolutive OTN > draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt > l-otn-00 > > draft-zhang-ccamp-gmpls-evolving-g709-01.txt > > > We have a couple of comments and questions for the draft-zhang. > (1) draft-zhang defined the extensions including what has been > done in RFC4328 (i.e., ODU1, ODU2 and ODU3). > draft-ceccarellifuxh defined new Gneralized Label only for > new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, > ODU3e1, ODU3e2, ODUflex and ODU4). > draft-ceccarellifuxh is only a supplement of RFC4328. > How can we used RFC4328 and draft-zhang ? > Any way, if we need to update an previous RFC, we should > assume that it has been deployed, not asking if someone did or not. > (2) Do you really want to remove NMC from the Traffic > Parameters? > If you do that, I think we have to abandon RFC4328. > (3) The compatibility consideration in draft-zhang. > We don't think the extensions in draft-zhang can coexist with > RFC4328. > You point out "we can just do some translation or mapping in > the new nodes". > But before the translation or mapping, you have to know the > Generalized Label Format. > We concern about: > i) How does one node know the Generalized Label format, > especially for ODU1, ODU2 and ODU3 base on your solution? > It may depend on the capability of the adjacent network > element. > ii) But how can the control plane know the adjacent network > element's capability without discovery mechanism? > You should know that GMPLS signaling extension should be > independent on the discovery mechanism and the configuration of > management plane. > iii) The control plane don't need to know the G.709(2003/03) > or G.709 Amendment3 network element? > > In a word, we think it can not do the translation and > mapping. So we can not get the compatibility with RFC4328 in > draft-zhang. > (4) The Generalized Label in draft-zhang > - managing a variable length label could be a mess. > - draft-zhang uses a first part of the label which has fixed > values and then a variable number of bit that is the bitmap. > The bitmap can be long from 0 to 80 bits depending on the > signal type. > - the value of the bitmap is not independent but depends on > the values of two previous fields (ODUk and ODUj) and becomes reserved > in case of K=J > - a bitmap label have not been used nor in SDH and not in > WSON where a fixed label (4 bytes) is used. > Xihua Fu > ZTE > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 4/attachment.htm > > > ------------------------------ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > End of CCAMP Digest, Vol 14, Issue 26 > ************************************* > > _______________________________________________ > 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 daniel@olddog.co.uk Fri Aug 14 14:46:55 2009 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 391153A6D9F for ; Fri, 14 Aug 2009 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_52=0.6, MIME_CHARSET_FARAWAY=2.45] 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 R-8fYVyT1DZ1 for ; Fri, 14 Aug 2009 14:46:53 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id CC25428C1C5 for ; Fri, 14 Aug 2009 14:46:52 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n7ELkJ1q012795; Fri, 14 Aug 2009 22:46:20 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n7ELkHdq012789; Fri, 14 Aug 2009 22:46:18 +0100 From: "Daniel King" To: "'Lou Berger'" , "'Fatai Zhang'" References: <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> <26bbdc380908131209x31719bedw6dcd55c1dd47844@mail.gmail.com> <008901ca1c83$fba46930$5b4c460a@china.huawei.com> <4A8580CF.3060507@labn.net> In-Reply-To: <4A8580CF.3060507@labn.net> Date: Fri, 14 Aug 2009 22:46:18 +0100 Message-ID: <003001ca1d28$a8998090$f9cc81b0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoc8t2pvwogR+8xTEm7uP4aXrZlZQAM37rQ Content-Language: en-gb Cc: 'ext zhangguoying' , ccamp@ietf.org, xuyunbin@mail.ritt.com.cn, "'Jin, Lizhong \(NSN - CN/Shanghai\)'" Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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, 14 Aug 2009 21:46:55 -0000 Hi Lou, et al.=20 I have been following the discussion. A while ago in the L3VPN WG we ran = an anonymous survey regarding the actual and planned deployment of MVPNs. = Now putting my CCAMP WG Secretary hat on. I am wondering if it is worth = doing something similar for this particular discussion?=20 If the chairs are willing, I could carry out a quick RFC4328 survey. We could poll the WG and ascertain the number of RFC4328 deployments. = Vendors could also acknowledge if they have hardware capable of supporting = RFC4328 as well. Survey responses would be sent directly to me. I would = guarantee to keep the vendor and operator information confidential. Once I have = compiled the results, I would report back the anonymous results. Br, Dan.=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Lou Berger Sent: 14 August 2009 16:21 To: Fatai Zhang Cc: xuyunbin@mail.ritt.com.cn; ccamp@ietf.org; ext zhangguoying; Jin, Lizhong (NSN - CN/Shanghai) Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension Fatai, I think the discussion on this topic is quite useful and I don't want to limit it. That said, I personally think that compatibility (or coexistence) with existing standards track RFCs is very important, and that deprecation or replacement is a step that should only be taken as an exception and not the norm. Lou On 8/13/2009 10:07 PM, Fatai Zhang wrote: > Hi all, > =20 > If there are no implementations for RFC4328 in the industry, do you > really think that we need two totally different label formats and > intentionally introduce the backward compatibility ? Do we really like > trouble very much ? > =20 > We always admit that we should consider backward compatibility if = there > are deployments for RFC4328. > =20 > I think if we really need to consider backward compatibility, we = should > focus on how to resolve it, but not focus on merging two documents, > because the label formats in two documents are very different and the > solutions for the backward compatibility may also be different. > =20 > =20 > =20 > =20 > Thanks > =20 > Fatai > =20 > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 >=20 > ----- Original Message ----- > *From:* Frederick Robinson > *To:* Jin, Lizhong (NSN - CN/Shanghai) = > *Cc:* ccamp@ietf.org ; ext zhangguoying > ; xuyunbin@mail.ritt.com.cn > > *Sent:* Friday, August 14, 2009 3:09 AM > *Subject:* Re: [CCAMP] Discussion about the GMPLS Signaling = Extension >=20 > Hi all: >=20 > I Agree with Lizhong. >=20 > We took several years to standardize the GMPLS extension for ODU1, > ODU2 and ODU3. > Technology of OTN is developing. We also need some time to > standardize the extension for the new application. We can not = forbid > vendor/carrier to deploy the OTN based on RFC4328 at any time. We > should keep them from waiting for the new extension. Further more, > any extension can not completely promise to fit any new = application > in the future. So we have to deal with it step by step. There is > some backward compatibility considerations and solution in > draft-ceccarellifuxh. There is also a extensible lable format in > draft-zhang. Why should we take a long time to survey it among the > OTN service providers. Two documents should be merged as soon as > possible. >=20 > Bedford >=20 > ** > 2009/8/12 Jin, Lizhong (NSN - CN/Shanghai) > >=20 > Hi all: > What I need to clarify from my side is that abandoning a RFC = is > not preferred in any case. If we can develop a backward = solution > by merging draft-ceccarellifuxh and draft-zhang, why don't we = go > in this way. > =20 > BR > Lizhong Jin >=20 > ------------------------------------------------------------------------ > *From:* ext zhangguoying [mailto:zhangguoying@mail.ritt.com.cn > ] > *Sent:* Tuesday, August 04, 2009 22:03 >=20 > *To:* Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org > > *Cc:* zhangfatai@huawei.com ; > fu.xihua@zte.com.cn ; > dbrungard@att.com ; lberger@labn.net > ; diego.caviglia@ericsson.com > ; > daniele.ceccarelli@ericsson.com > ; > xuyunbin@mail.ritt.com.cn >=20 > *Subject:* Re: RE: Discussion about the GMPLS Signaling = Extension >=20 > Hi all, > =20 > As many experts have explained, the label encoding with bit = map > in draft-zhang is surely a better way to > achieve extensibility and scalability of OTN lable. =20 > =20 > The main issue that bit map label format might have is > the backword compatibility. I think we might need to start an > survey among the OTN service providers in the mailing list, = and > see if there are any OTN networks deployed with GMPLS > RFC4328 lable format. > =20 > If there're no real deployment, we don't need to consider the > compatability problem; > =20 > If there're some deployment, compatability problem need to > be solved . An easy way might be adding an label version bit = in > the label format, or some other solutions may be searched out. > =20 > =20 > best regards, > Guoying Zhang > =20 > =20 > =20 > 2009-08-04 > ------------------------------------------------------------------------ > zhangguoying > ------------------------------------------------------------------------ > *=B7=A2=BC=FE=C8=CB=A3=BA* Jin, Lizhong (NSN - CN/Shanghai) > *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2009-08-04 13:34:24 > *=CA=D5=BC=FE=C8=CB=A3=BA* ccamp@ietf.org = > *=B3=AD=CB=CD=A3=BA* zhangfatai@huawei.com = ; > fu.xihua@zte.com.cn ; > dbrungard@att.com ; lberger@labn.net > ; diego.caviglia@ericsson.com > ; > daniele.ceccarelli@ericsson.com > ; > zhangguoying@mail.ritt.com.cn > ; > xuyunbin@mail.ritt.com.cn > *=D6=F7=CC=E2=A3=BA* RE: Discussion about the GMPLS Signaling = Extension > Hi Fatai and all: > I agree with the issues of excessive number of labels if using = the same > label concept of RFC4328. By using bit map for label encoding = is a good > idea. And from my understanding, > draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit > map idea if Fatai agree. > =20 > For backward compatibility, we can not assume that RFC4328 is = not > deployed unless we can provide some kind of survey report. So currently > the right assumption is that RFC4328 has been deployed, and backward > compatibity should be considered. > =20 > Best Regards > Lizhong Jin > =20 > ---------------------------------------------------------------------- > =20 > Message: 1 > Date: Thu, 30 Jul 2009 11:33:56 +0200 > From: "BELOTTI SERGIO" > > Subject: [CCAMP] R: Discussion about the GMPLS Signaling = Extension > forEvolutive OTN > To: "Fatai" >, >, > >,=20 > >, > >, > >, > >, > = > > Cc: ccamp@ietf.org > Message-ID: > <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com > > > > Content-Type: text/plain; charset=3D"iso-8859-1" > =20 > Dear Fatai and all, > =20 > =20 > =20 > We agree on the major points raised by Fatai as general issue = to be > solved in the context of extension needed to cope with new containers > defined in ITU q11 context, in addition to handling ODU multiplexing > scenarios in existing OTN. > =20 > There are two basic points that brings to the need to update = the RFC4328 > anyway. > =20 > =20 > =20 > 1) the present RFC does not permit the link based negotiation = for time > slot allocation . No information about tributary port numbers = is present > and only in case we have "single layer" , no multiplexing LO = -- > > HO you > can apply . So this is a lack against the original G.709 even without > considering G.709 Am3 . > =20 > =20 > =20 > 2) Scalability: The extension required in the context of new = OTN with > the introduction of ODU0, ODU4, and above all ODUflex , = required a real > modifications of the structure of the label to avoid real big = size of > number of labels to transmit offloading signalling session. Extension > based on RFC4328 logic do not scale when ODU-flex is used. = Large ODU > flex containers will generate > =20 > an excessive number of labels (in principle up to 80 per link) causing > problems with the size of the RSVP-TE message. > =20 > =20 > =20 > This two points together call to the need to change something = in RFC. > =20 > Backward compatibility aspects, present in all the drafts, are surely to > be considered and if there are single layer systems deployed = using > RFC4328 this should be grandfathered. > =20 > =20 > =20 > Best Regards > =20 > =20 > =20 > Sergio > =20 > =20 > =20 > =20 > =20 > Sergio Belotti > =20 > =20 > =20 > CTO Optics Division > =20 > Alcatel-Lucent > =20 > =20 > =20 > +39 039 6863033 > =20 > +39 039 6863590 > =20 > =20 > =20 > ________________________________ > =20 > Da: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org > ] Per conto di > Fatai > Inviato: mercoled? 29 luglio 2009 18.33 > A: fu.xihua@zte.com.cn > ; dbrungard@att.com > ; lberger@labn.net > ; > diego.caviglia@ericsson.com > ; = daniele.ceccarelli@ericsson. com > ; > zhangguoying@mail.ritt.com.cn > ; = xuyunbin@mail.ritt.com.cn > Cc: ccamp@ietf.org > Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension > forEvolutive OTN > =20 > =20 > =20 > Hi all, > =20 > =20 > =20 > To support the current verison of G.709, we think the label = format > defined in RFC4328 need to be re-defined anyway. The new OTN = label > format should support the whole ODU sets, not only the ODU1, = 2, and 3, > but also ODU0, ODU4, even ODUFlex. The following three aspects should be > considered carefully: > =20 > =20 > =20 > 1) The extensibility of the label format is the first thing we should > consider. With the development of OTN technology, RFC4328 = label format > style needs to be extended to support the new bitrate ODU (eg. ODU5, > 6...). By the end, we may need keep extending the label = formats. > Managing lots of label format may cause big trouble, so we = need one-shot > label format for the evolving OTN. =20 > =20 > =20 > =20 > 2) Scalability is another key issue. RFC4328 style format may result in > big size of the total labels, which definitely increase the = burden of > the signaling. An efficient approach is needed to carry the = same label > information but with less amount of the data, bitmap style is = the right > way to go. > =20 > =20 > =20 > 3) For backward compatibility, if there are no implementations = for > RFC4328 (or if there are no deployments it is desirable to deprecate > even if it is uncomfortable for existing implementations), it = is very > safe to deprecate the old definition, and an extensible, = efficient and > scalable solution could be helpful. The label defined in draft-zhang > does not overwrite RFC4328, it can allow the old definition to continue > to exist. > =20 > =20 > =20 > Hope this can clarify your concern. > =20 > =20 > =20 > Authors of draft-zhang > =20 > =20 > =20 > =20 > =20 > =20 > =20 > ----- Original Message -----=20 > =20 > From: fu.xihua@zte.com.cn =20 > =20 > To: dbrungard@att.com > ; lberger@labn.net > ; zhangfatai@huawei.com > > ; diego.caviglia@ericsson.com > ; daniele.ceccarelli@ericsson.com > =20 > =20 > Cc: ccamp@ietf.org =20 > =20 > Sent: Tuesday, July 28, 2009 5:33 PM > =20 > Subject: Discussion about the GMPLS Signaling Extension for > Evolutive OTN > =20 > =20 > =20 > Hi Fatai and All,=20 > We have presented the following two document in the CCAMP > morning session. But we have no more time to further discuss = GMPLS > extension for evolutive OTN=20 > draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt > l-otn-00 > =20 > draft-zhang-ccamp-gmpls-evolving-g709-01.txt > > =20 > We have a couple of comments and questions for the = draft-zhang.=20 > (1) draft-zhang defined the extensions including what has been > done in RFC4328 (i.e., ODU1, ODU2 and ODU3).=20 > draft-ceccarellifuxh defined new Gneralized Label only = for > new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G = ODU3, ODU2e, > ODU3e1, ODU3e2, ODUflex and ODU4).=20 > draft-ceccarellifuxh is only a supplement of RFC4328.=20 > How can we used RFC4328 and draft-zhang ? =20 > Any way, if we need to update an previous RFC, we should > assume that it has been deployed, not asking if someone did or not.=20 > (2) Do you really want to remove NMC from the Traffic > Parameters?=20 > If you do that, I think we have to abandon RFC4328.=20 > (3) The compatibility consideration in draft-zhang.=20 > We don't think the extensions in draft-zhang can coexist = with > RFC4328.=20 > You point out "we can just do some translation or mapping = in > the new nodes".=20 > But before the translation or mapping, you have to know the > Generalized Label Format. =20 > We concern about: =20 > i) How does one node know the Generalized Label format, > especially for ODU1, ODU2 and ODU3 base on your solution? =20 > It may depend on the capability of the adjacent = network > element.=20 > ii) But how can the control plane know the adjacent network > element's capability without discovery mechanism?=20 > You should know that GMPLS signaling extension should = be > independent on the discovery mechanism and the configuration = of > management plane.=20 > iii) The control plane don't need to know the = G.709(2003/03) > or G.709 Amendment3 network element?=20 > =20 > In a word, we think it can not do the translation and > mapping. So we can not get the compatibility with RFC4328 in > draft-zhang.=20 > (4) The Generalized Label in draft-zhang=20 > - managing a variable length label could be a mess.=20 > - draft-zhang uses a first part of the label which has = fixed > values and then a variable number of bit that is the bitmap.=20 > The bitmap can be long from 0 to 80 bits depending on = the > signal type.=20 > - the value of the bitmap is not independent but depends = on > the values of two previous fields (ODUk and ODUj) and becomes reserved > in case of K=3DJ=20 > - a bitmap label have not been used nor in SDH and not in > WSON where a fixed label (4 bytes) is used.=20 > Xihua Fu=20 > ZTE=20 > =20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 4/attachment.htm > > =20 > ------------------------------ > =20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > =20 > =20 > End of CCAMP Digest, Vol 14, Issue 26 > ************************************* >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > 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 Sat Aug 15 04:17:58 2009 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 5D17428C0DE for ; Sat, 15 Aug 2009 04:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_52=0.6, MIME_CHARSET_FARAWAY=2.45] 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 br9CB2EVKXGF for ; Sat, 15 Aug 2009 04:17:56 -0700 (PDT) Received: from outbound-mail-316.bluehost.com (outbound-mail-316.bluehost.com [67.222.54.9]) by core3.amsl.com (Postfix) with SMTP id 71D8928C1E4 for ; Sat, 15 Aug 2009 04:17:56 -0700 (PDT) Received: (qmail 9404 invoked by uid 0); 15 Aug 2009 11:18:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 15 Aug 2009 11:18:00 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ouikfoWGzwa93SOOHF7OBioxIik5mh+6lZw6Ly4Ee4tBSl5YBh+h+D5YFGb7egN6Rz2xoyoNiW51GkJsF7zeAuv+Kwc152a3MmYYFGg17fv0BmTUzvS4JIzdP2PT4oJX; 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 1McHGq-000643-7U; Sat, 15 Aug 2009 05:18:00 -0600 Message-ID: <4A869971.306@labn.net> Date: Sat, 15 Aug 2009 07:18:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Daniel King References: <328B9F5068825A48A4B8422A350B90478ADEF6@CNBEEXC006.nsn-intra.net> <200908042202560621383@mail.ritt.com.cn> <328B9F5068825A48A4B8422A350B90478FDD26@CNBEEXC006.nsn-intra.net> <26bbdc380908131209x31719bedw6dcd55c1dd47844@mail.gmail.com> <008901ca1c83$fba46930$5b4c460a@china.huawei.com> <4A8580CF.3060507@labn.net> <003001ca1d28$a8998090$f9cc81b0$@co.uk> In-Reply-To: <003001ca1d28$a8998090$f9cc81b0$@co.uk> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=GB2312 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: 'ext zhangguoying' , ccamp@ietf.org, xuyunbin@mail.ritt.com.cn, "'Jin, Lizhong \(NSN - CN/Shanghai\)'" Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension 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: Sat, 15 Aug 2009 11:17:58 -0000 Dan, There's lots of reasons to run surveys, notably implementation status as a draft progresses. As some may recall, I've run a few myself. Given that we're talking about deprecating an RFC that was published 3+ years ago based on a draft that became a WG document 7+ years ago *without* strong technical justification or WG consensus, I think such a survey is at best premature. The WG still needs to fully discusses this topic, and adopt a draft solution. If at this point the consensus of the WG is that the best course of action is to deprecate, then I fully agree. It will be worth conducting such a survey. But I believe we're not yet at this point. Lou On 8/14/2009 5:46 PM, Daniel King wrote: > Hi Lou, et al. > > I have been following the discussion. A while ago in the L3VPN WG we ran an > anonymous survey regarding the actual and planned deployment of MVPNs. Now > putting my CCAMP WG Secretary hat on. I am wondering if it is worth doing > something similar for this particular discussion? > > If the chairs are willing, I could carry out a quick RFC4328 survey. We > could poll the WG and ascertain the number of RFC4328 deployments. Vendors > could also acknowledge if they have hardware capable of supporting RFC4328 > as well. Survey responses would be sent directly to me. I would guarantee to > keep the vendor and operator information confidential. Once I have compiled > the results, I would report back the anonymous results. > > Br, Dan. > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: 14 August 2009 16:21 > To: Fatai Zhang > Cc: xuyunbin@mail.ritt.com.cn; ccamp@ietf.org; ext zhangguoying; Jin, > Lizhong (NSN - CN/Shanghai) > Subject: Re: [CCAMP] Discussion about the GMPLS Signaling Extension > > Fatai, > I think the discussion on this topic is quite useful and I don't > want > to limit it. That said, I personally think that compatibility (or > coexistence) with existing standards track RFCs is very important, and > that deprecation or replacement is a step that should only be taken as > an exception and not the norm. > > Lou > > On 8/13/2009 10:07 PM, Fatai Zhang wrote: >> Hi all, >> >> If there are no implementations for RFC4328 in the industry, do you >> really think that we need two totally different label formats and >> intentionally introduce the backward compatibility ? Do we really like >> trouble very much ? >> >> We always admit that we should consider backward compatibility if there >> are deployments for RFC4328. >> >> I think if we really need to consider backward compatibility, we should >> focus on how to resolve it, but not focus on merging two documents, >> because the label formats in two documents are very different and the >> solutions for the backward compatibility may also be different. >> >> >> >> >> Thanks >> >> Fatai >> >> Advanced Technology Department >> Wireline Networking Business Unit >> Huawei Technologies Co., LTD. >> Huawei Base, Bantian, Longgang, >> Shenzhen 518129 P.R.China >> Tel: +86-755-28972912 >> Fax: +86-755-28972935 >> >> ----- Original Message ----- >> *From:* Frederick Robinson >> *To:* Jin, Lizhong (NSN - CN/Shanghai) >> *Cc:* ccamp@ietf.org ; ext zhangguoying >> ; xuyunbin@mail.ritt.com.cn >> >> *Sent:* Friday, August 14, 2009 3:09 AM >> *Subject:* Re: [CCAMP] Discussion about the GMPLS Signaling Extension >> >> Hi all: >> >> I Agree with Lizhong. >> >> We took several years to standardize the GMPLS extension for ODU1, >> ODU2 and ODU3. >> Technology of OTN is developing. We also need some time to >> standardize the extension for the new application. We can not forbid >> vendor/carrier to deploy the OTN based on RFC4328 at any time. We >> should keep them from waiting for the new extension. Further more, >> any extension can not completely promise to fit any new application >> in the future. So we have to deal with it step by step. There is >> some backward compatibility considerations and solution in >> draft-ceccarellifuxh. There is also a extensible lable format in >> draft-zhang. Why should we take a long time to survey it among the >> OTN service providers. Two documents should be merged as soon as >> possible. >> >> Bedford >> >> ** >> 2009/8/12 Jin, Lizhong (NSN - CN/Shanghai) > > >> >> Hi all: >> What I need to clarify from my side is that abandoning a RFC is >> not preferred in any case. If we can develop a backward solution >> by merging draft-ceccarellifuxh and draft-zhang, why don't we go >> in this way. >> >> BR >> Lizhong Jin >> >> > ------------------------------------------------------------------------ >> *From:* ext zhangguoying [mailto:zhangguoying@mail.ritt.com.cn >> ] >> *Sent:* Tuesday, August 04, 2009 22:03 >> >> *To:* Jin, Lizhong (NSN - CN/Shanghai); ccamp@ietf.org >> >> *Cc:* zhangfatai@huawei.com ; >> fu.xihua@zte.com.cn ; >> dbrungard@att.com ; lberger@labn.net >> ; diego.caviglia@ericsson.com >> ; >> daniele.ceccarelli@ericsson.com >> ; >> xuyunbin@mail.ritt.com.cn >> >> *Subject:* Re: RE: Discussion about the GMPLS Signaling Extension >> >> Hi all, >> >> As many experts have explained, the label encoding with bit map >> in draft-zhang is surely a better way to >> achieve extensibility and scalability of OTN lable. >> >> The main issue that bit map label format might have is >> the backword compatibility. I think we might need to start an >> survey among the OTN service providers in the mailing list, and >> see if there are any OTN networks deployed with GMPLS >> RFC4328 lable format. >> >> If there're no real deployment, we don't need to consider the >> compatability problem; >> >> If there're some deployment, compatability problem need to >> be solved . An easy way might be adding an label version bit in >> the label format, or some other solutions may be searched out. >> >> >> best regards, >> Guoying Zhang >> >> >> >> 2009-08-04 >> > ------------------------------------------------------------------------ >> zhangguoying >> > ------------------------------------------------------------------------ >> *·¢¼þÈË£º* Jin, Lizhong (NSN - CN/Shanghai) >> *·¢ËÍʱ¼ä£º* 2009-08-04 13:34:24 >> *ÊÕ¼þÈË£º* ccamp@ietf.org >> *³­ËÍ£º* zhangfatai@huawei.com ; >> fu.xihua@zte.com.cn ; >> dbrungard@att.com ; lberger@labn.net >> ; diego.caviglia@ericsson.com >> ; >> daniele.ceccarelli@ericsson.com >> ; >> zhangguoying@mail.ritt.com.cn >> ; >> xuyunbin@mail.ritt.com.cn >> *Ö÷Ì⣺* RE: Discussion about the GMPLS Signaling Extension >> Hi Fatai and all: >> I agree with the issues of excessive number of labels if using the > same >> label concept of RFC4328. By using bit map for label encoding is a > good >> idea. And from my understanding, >> draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge > this bit >> map idea if Fatai agree. >> >> For backward compatibility, we can not assume that RFC4328 is not >> deployed unless we can provide some kind of survey report. So > currently >> the right assumption is that RFC4328 has been deployed, and > backward >> compatibity should be considered. >> >> Best Regards >> Lizhong Jin >> >> > ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 30 Jul 2009 11:33:56 +0200 >> From: "BELOTTI SERGIO" > > >> Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension >> forEvolutive OTN >> To: "Fatai" > >, > >, >> >, >> >, >> >> , >> > >, >> > >, >> > >> Cc: ccamp@ietf.org >> Message-ID: >> > <3F44186D7141E247972EAC6655B0A29101FA7A56@FRVELSMBS21.ad2.ad.alcatel.com > com> >> > >> Content-Type: text/plain; charset="iso-8859-1" >> >> Dear Fatai and all, >> >> >> >> We agree on the major points raised by Fatai as general issue to > be >> solved in the context of extension needed to cope with new > containers >> defined in ITU q11 context, in addition to handling ODU > multiplexing >> scenarios in existing OTN. >> >> There are two basic points that brings to the need to update the > RFC4328 >> anyway. >> >> >> >> 1) the present RFC does not permit the link based negotiation for > time >> slot allocation . No information about tributary port numbers is > present >> and only in case we have "single layer" , no multiplexing LO -- >> > HO you >> can apply . So this is a lack against the original G.709 even > without >> considering G.709 Am3 . >> >> >> >> 2) Scalability: The extension required in the context of new OTN > with >> the introduction of ODU0, ODU4, and above all ODUflex , required a > real >> modifications of the structure of the label to avoid real big size > of >> number of labels to transmit offloading signalling session. > Extension >> based on RFC4328 logic do not scale when ODU-flex is used. Large > ODU >> flex containers will generate >> >> an excessive number of labels (in principle up to 80 per link) > causing >> problems with the size of the RSVP-TE message. >> >> >> >> This two points together call to the need to change something in > RFC. >> >> Backward compatibility aspects, present in all the drafts, are > surely to >> be considered and if there are single layer systems deployed using >> RFC4328 this should be grandfathered. >> >> >> >> Best Regards >> >> >> >> Sergio >> >> >> >> >> >> Sergio Belotti >> >> >> >> CTO Optics Division >> >> Alcatel-Lucent >> >> >> >> +39 039 6863033 >> >> +39 039 6863590 >> >> >> >> ________________________________ >> >> Da: ccamp-bounces@ietf.org >> [mailto:ccamp-bounces@ietf.org >> ] Per conto di >> Fatai >> Inviato: mercoled? 29 luglio 2009 18.33 >> A: fu.xihua@zte.com.cn >> ; dbrungard@att.com >> ; lberger@labn.net >> ; >> diego.caviglia@ericsson.com >> ; daniele.ceccarelli@ericsson. > com >> ; >> zhangguoying@mail.ritt.com.cn >> ; xuyunbin@mail.ritt.com.cn > >> Cc: ccamp@ietf.org >> Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling > Extension >> forEvolutive OTN >> >> >> >> Hi all, >> >> >> >> To support the current verison of G.709, we think the label format >> defined in RFC4328 need to be re-defined anyway. The new OTN label >> format should support the whole ODU sets, not only the ODU1, 2, > and 3, >> but also ODU0, ODU4, even ODUFlex. The following three aspects > should be >> considered carefully: >> >> >> >> 1) The extensibility of the label format is the first thing we > should >> consider. With the development of OTN technology, RFC4328 label > format >> style needs to be extended to support the new bitrate ODU (eg. > ODU5, >> 6...). By the end, we may need keep extending the label formats. >> Managing lots of label format may cause big trouble, so we need > one-shot >> label format for the evolving OTN. >> >> >> >> 2) Scalability is another key issue. RFC4328 style format may > result in >> big size of the total labels, which definitely increase the burden > of >> the signaling. An efficient approach is needed to carry the same > label >> information but with less amount of the data, bitmap style is the > right >> way to go. >> >> >> >> 3) For backward compatibility, if there are no implementations for >> RFC4328 (or if there are no deployments it is desirable to > deprecate >> even if it is uncomfortable for existing implementations), it is > very >> safe to deprecate the old definition, and an extensible, efficient > and >> scalable solution could be helpful. The label defined in > draft-zhang >> does not overwrite RFC4328, it can allow the old definition to > continue >> to exist. >> >> >> >> Hope this can clarify your concern. >> >> >> >> Authors of draft-zhang >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> From: fu.xihua@zte.com.cn >> >> To: dbrungard@att.com >> ; lberger@labn.net >> ; zhangfatai@huawei.com >> >> ; diego.caviglia@ericsson.com >> ; > daniele.ceccarelli@ericsson.com >> >> >> Cc: ccamp@ietf.org >> >> Sent: Tuesday, July 28, 2009 5:33 PM >> >> Subject: Discussion about the GMPLS Signaling Extension for >> Evolutive OTN >> >> >> >> Hi Fatai and All, >> We have presented the following two document in the CCAMP >> morning session. But we have no more time to further discuss GMPLS >> extension for evolutive OTN >> draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt >> > > l-otn-00 > >> draft-zhang-ccamp-gmpls-evolving-g709-01.txt >> > > > >> We have a couple of comments and questions for the draft-zhang. >> (1) draft-zhang defined the extensions including what has been >> done in RFC4328 (i.e., ODU1, ODU2 and ODU3). >> draft-ceccarellifuxh defined new Gneralized Label only for >> new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, > ODU2e, >> ODU3e1, ODU3e2, ODUflex and ODU4). >> draft-ceccarellifuxh is only a supplement of RFC4328. >> How can we used RFC4328 and draft-zhang ? >> Any way, if we need to update an previous RFC, we should >> assume that it has been deployed, not asking if someone did or > not. >> (2) Do you really want to remove NMC from the Traffic >> Parameters? >> If you do that, I think we have to abandon RFC4328. >> (3) The compatibility consideration in draft-zhang. >> We don't think the extensions in draft-zhang can coexist with >> RFC4328. >> You point out "we can just do some translation or mapping in >> the new nodes". >> But before the translation or mapping, you have to know the >> Generalized Label Format. >> We concern about: >> i) How does one node know the Generalized Label format, >> especially for ODU1, ODU2 and ODU3 base on your solution? >> It may depend on the capability of the adjacent network >> element. >> ii) But how can the control plane know the adjacent network >> element's capability without discovery mechanism? >> You should know that GMPLS signaling extension should be >> independent on the discovery mechanism and the configuration of >> management plane. >> iii) The control plane don't need to know the G.709(2003/03) >> or G.709 Amendment3 network element? >> >> In a word, we think it can not do the translation and >> mapping. So we can not get the compatibility with RFC4328 in >> draft-zhang. >> (4) The Generalized Label in draft-zhang >> - managing a variable length label could be a mess. >> - draft-zhang uses a first part of the label which has fixed >> values and then a variable number of bit that is the bitmap. >> The bitmap can be long from 0 to 80 bits depending on the >> signal type. >> - the value of the bitmap is not independent but depends on >> the values of two previous fields (ODUk and ODUj) and becomes > reserved >> in case of K=J >> - a bitmap label have not been used nor in SDH and not in >> WSON where a fixed label (4 bytes) is used. >> Xihua Fu >> ZTE >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > > 4/attachment.htm > >> >> ------------------------------ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> End of CCAMP Digest, Vol 14, Issue 26 >> ************************************* >> >> _______________________________________________ >> 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 Tue Aug 18 13:30:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C95113A6C9B; Tue, 18 Aug 2009 13:30: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: <20090818203001.C95113A6C9B@core3.amsl.com> Date: Tue, 18 Aug 2009 13:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-09.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, 18 Aug 2009 20:30:01 -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 : OSPFv2 Routing Protocols Extensions for ASON Routing Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt Pages : 29 Date : 2009-8-16 The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-09.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-ason-routing-ospf-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-8-18132504.I-D@ietf.org> --NextPart-- From lberger@labn.net Tue Aug 18 17:39:25 2009 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 511D23A681C for ; Tue, 18 Aug 2009 17:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.677, 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 1Or9+PheUrWg for ; Tue, 18 Aug 2009 17:39:24 -0700 (PDT) Received: from outbound-mail-319.bluehost.com (outbound-mail-319.bluehost.com [67.222.54.251]) by core3.amsl.com (Postfix) with SMTP id 10DB03A6CF8 for ; Tue, 18 Aug 2009 17:39:17 -0700 (PDT) Received: (qmail 24660 invoked by uid 0); 19 Aug 2009 00:39:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 19 Aug 2009 00:39:16 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Z2551FsB2I4U2csvanpEkY/rJHT3pEgqzv0kR28T8pyjK97K59wglmuBiCgnboVjMTwwR8G6elUa4HtM9QkWYOiWk+3sHqB0xIz7S9V4X2dCrs3Dk3eijCAk7tBiO96L; 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 1MdZCu-0001Kv-8S; Tue, 18 Aug 2009 18:39:16 -0600 Message-ID: <4A8B4A14.1060006@labn.net> Date: Tue, 18 Aug 2009 20:40:52 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Rschrage , zhangguoying@mail.ritt.com.cn References: <4A6C1B70.6040503@ripe.net> <4A6ED756.3070609@ripe.net> <4A6EF5F6.6040201@labn.net> <006001ca1ffe$b55d3820$2017a860$@net> In-Reply-To: <006001ca1ffe$b55d3820$2017a860$@net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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, 'Henk Uijterwaal' , 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 00:39:25 -0000 Reinhard, Thank you very much for the comments. draft-ietf-ccamp-lsp-dppm Authors, Please address the comments/discussion points raised. Lou On 8/18/2009 8:23 AM, Rschrage wrote: > Hello, > > sorry for late response- > > Nevertheless here is a first edition of my revision of doc > draft-ietf-ccamp-lsp-dppm-06. > > The doc has been saved in Word 2003 format to easily track changes. > I am using Kaspersky Anti Virus 2010 software so I trust there should be no > unpleasant surprises when downloading the attached word doc. > > > I thought it would be advisable to first address the suggested comments and > questions upto and including the uni-directional LSP setup delay metric and > after that to continue with the bi-directional and sample definitions as > covered in the doc. > > Please let me have your thoughts on this. > > Many thanks. > Reinhard Schrage > Tel: +49 (0) 5137 909540 > Mobile: +49 (0) 172 26.36.046 > reinhard@schrageconsult.com > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Lou > Berger > Sent: Dienstag, 28. Juli 2009 14:59 > To: Henk Uijterwaal > Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; > sunwq@mit.edu; IETF IPPM WG > Subject: Re: [ippm] [Fwd: IPPM expert review request] > > Hank/Reinhard, > > Thank you very much for undertaking this review. Please cc > ccamp@ietf.org on any comments you may have. > > Lou > > On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >> Lou, others, >> >>> We received the request for a review of a document currently under >>> discussion in the CCAMP WG, please see below. Is there anybody who >>> has time to do this review in the near future? >> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do this. >> >> Reinhard: please post anything you find to both the list and the authors. >> And thank you for doing this. >> >> Henk >> >>> Matt & Henk >>> >>> -------- Original Message -------- >>> Subject: IPPM expert review request >>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>> From: Lou Berger >>> To: ippm-chairs@tools.ietf.org >>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>> zhangguoying >>> >>> Hi, >>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>> review >>> a draft that is progressing through the CCAMP WG. This work applies >>> IPPM approaches to GMPLS. The document we'd like reviewed is >>> available at: >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>> >>> Is this acceptable? Can you undertake this review? Alternatively, we >>> can just last call the document in your WG (it has already passed CCAMP >>> WG LC). >>> >>> Thank you, >>> Lou (and Deborah) >>> >>> >> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From lberger@labn.net Tue Aug 18 18:09:46 2009 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 2D6853A6987 for ; Tue, 18 Aug 2009 18:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.564, 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 oe8i2ZSe8XGY for ; Tue, 18 Aug 2009 18:09:45 -0700 (PDT) Received: from outbound-mail-145.bluehost.com (outbound-mail-145.bluehost.com [67.222.38.35]) by core3.amsl.com (Postfix) with SMTP id 4FA8A3A6BE0 for ; Tue, 18 Aug 2009 18:09:45 -0700 (PDT) Received: (qmail 21357 invoked by uid 0); 19 Aug 2009 01:09:50 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 19 Aug 2009 01:09:50 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Dso40kVYERXgoxN4ycnvaEv6GA/lK+fVHj+uUC/kGIFKchQYCNldfUPr3tVxSoml6q6HlZiM8FEJzS/YRperh3ZOT2m9gvr8JYF+I9AEXc/cbmDHYKxBgtdK3kQ5JEIu; 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 1MdZgU-0002I1-FX for ccamp@ietf.org; Tue, 18 Aug 2009 19:09:50 -0600 Message-ID: <4A8B513F.3010908@labn.net> Date: Tue, 18 Aug 2009 21:11:27 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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] 2nd Working group last call: draft-ietf-ccamp-pc-spc-rsvpte-ext 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, 19 Aug 2009 01:09:46 -0000 This email begins a two week working group last call on draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt http://tools.ietf.org/html/draft-ietf-ccamp-pc-spc-rsvpte-ext-03 Please send your comments to the list or the authors before the last call closes on September 1, 2009. As discussed in Stockholm, we are holding an additional last call on this draft due to the changes made as a result of the previous Last Call. (For slides from Stockholm see http://tools.ietf.org/agenda/75/slides/ccamp-4.ppt) From lberger@labn.net Tue Aug 18 18:09:46 2009 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 8828A3A6987 for ; Tue, 18 Aug 2009 18:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.521, 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 1obEZQl2pndH for ; Tue, 18 Aug 2009 18:09:42 -0700 (PDT) Received: from outbound-mail-06.bluehost.com (outbound-mail-06.bluehost.com [69.89.17.206]) by core3.amsl.com (Postfix) with SMTP id C93A13A6C0C for ; Tue, 18 Aug 2009 18:09:42 -0700 (PDT) Received: (qmail 23002 invoked by uid 0); 19 Aug 2009 01:09:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 19 Aug 2009 01:09:48 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=buTTv8pTvgVtU/greJpUFJn0K/zb466Z2KpOGN4DV77gScsiiS9a1+NZduH6mHSLBAAEfK9a6S1YI2NGSWYUM/uWaMs+m0KvqAnn4064m3XPTuRcizJJYnZIUdw+kHw+; 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 1MdZgR-0002HD-TA for ccamp@ietf.org; Tue, 18 Aug 2009 19:09:48 -0600 Message-ID: <4A8B513C.2040308@labn.net> Date: Tue, 18 Aug 2009 21:11:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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] 2nd Working group last call: draft-ietf-ccamp-confirm-data-channel-status 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, 19 Aug 2009 01:09:46 -0000 This email begins a two week working group last call on draft-ietf-ccamp-confirm-data-channel-status-06.txt http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-06 Please send your comments to the list or the authors before the last call closes on September 1, 2009. As discussed in Stockholm, we are holding an additional last call on this draft due to the changes made as a result of the previous Last Call. (For slides from Stockholm see http://tools.ietf.org/agenda/75/slides/ccamp-3.ppt) From sunwq@MIT.EDU Tue Aug 18 23:50:22 2009 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 EE9B83A6A1F; Tue, 18 Aug 2009 23:50:22 -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, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 An8QD4SsyGAe; Tue, 18 Aug 2009 23:50:21 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 81FB03A6802; Tue, 18 Aug 2009 23:50:21 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7J6nXxl019707; Wed, 19 Aug 2009 02:49:33 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7J6n3Xm017804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 02:49:11 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Rschrage" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <4A6C1B70.6040503@ripe.net> <4A6ED756.3070609@ripe.net> <4A6EF5F6.6040201@labn.net> <006001ca1ffe$b55d3820$2017a860$@net> In-Reply-To: <006001ca1ffe$b55d3820$2017a860$@net> Date: Wed, 19 Aug 2009 14:48:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 06:50:23 -0000 Hi Reinhard, Many thanks for doing the careful review. We appreciate your many wording suggestions. We will go through these one by one and adopt those we feel appropriate. In this email I will not list all the comments since these will not lead to major technical changes. Below I try to respond to the points you raised in the revision. RS1. This would imply that the metric may produce a range of several values at one time with the minimum value to be taken from that range. I believe what the authors are trying to say is, that the LSP Setup Delay Metric provides a lower bound on all possible LSP Delay Metrics of actually instantiated LSPs, or in other words: an actual LSP Delay Metric cannot get smaller than an LSP Setup Delay Metric. [sunwq] This point is raised regarding the motivation of the sigleton definition of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying to say that the minimum value of this metric reflects the (likely) single lsp setup delay when the control plane is lightly loaded. The formal definition of the minimum value is in "14.1 The minimum of metric" In fact we have inherited this from the IPPM documents (see RFC 2681, page 2 section 1.1 bullet 3). RS2. How? Should there be a methodology be defined for this? [sunwq] This point is raised regarding the sentense in our methodologies sections - "Make sure that the network has enough resource to set up the requested LSP." We have assumed that test personnel should have adequate expertise in allocating enough resources for the testing. The allocation of resources for the testing purpose can be very test specific and we believe it is quite outside the scope of this document. RS3. Too vague? As both timestamps are to be taken on the same ingress node, they should be taken at the same application/network level. [sunwq] This point is raised regarding the sentense "If the corresponding RESV message arrives within a reasonable period of time, take the timestamp (T2) as soon as possible upon receipt of the message." Yes, ideally the timestamp should be taken immediately after the reception of the RESV message. The wording "as soon as possible" is used to allow for some flexibility when RESV message needs to be propagated to certain modules where timestamp-taking is most appropriate. And again, this text is inherited from the IPPM documents (see RFC 2681 page 7, bullet 3). Thanks again and looking forward to your further comments and revisions. Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Rschrage" Sent: Tuesday, August 18, 2009 8:23 PM To: "'Lou Berger'" ; "'Henk Uijterwaal'" Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" ; ; "'IETF IPPM WG'" ; Subject: RE: [ippm] [Fwd: IPPM expert review request] > Hello, > > sorry for late response- > > Nevertheless here is a first edition of my revision of doc > draft-ietf-ccamp-lsp-dppm-06. > > The doc has been saved in Word 2003 format to easily track changes. > I am using Kaspersky Anti Virus 2010 software so I trust there should be > no > unpleasant surprises when downloading the attached word doc. > > > I thought it would be advisable to first address the suggested comments > and > questions upto and including the uni-directional LSP setup delay metric > and > after that to continue with the bi-directional and sample definitions as > covered in the doc. > > Please let me have your thoughts on this. > > Many thanks. > Reinhard Schrage > Tel: +49 (0) 5137 909540 > Mobile: +49 (0) 172 26.36.046 > reinhard@schrageconsult.com > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Lou > Berger > Sent: Dienstag, 28. Juli 2009 14:59 > To: Henk Uijterwaal > Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; > sunwq@mit.edu; IETF IPPM WG > Subject: Re: [ippm] [Fwd: IPPM expert review request] > > Hank/Reinhard, > > Thank you very much for undertaking this review. Please cc > ccamp@ietf.org on any comments you may have. > > Lou > > On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >> Lou, others, >> >>> We received the request for a review of a document currently under >>> discussion in the CCAMP WG, please see below. Is there anybody who >>> has time to do this review in the near future? >> >> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do this. >> >> Reinhard: please post anything you find to both the list and the authors. >> And thank you for doing this. >> >> Henk >> >>> >>> Matt & Henk >>> >>> -------- Original Message -------- >>> Subject: IPPM expert review request >>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>> From: Lou Berger >>> To: ippm-chairs@tools.ietf.org >>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>> zhangguoying >>> >>> Hi, >>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>> review >>> a draft that is progressing through the CCAMP WG. This work applies >>> IPPM approaches to GMPLS. The document we'd like reviewed is >>> available at: >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>> >>> Is this acceptable? Can you undertake this review? Alternatively, we >>> can just last call the document in your WG (it has already passed CCAMP >>> WG LC). >>> >>> Thank you, >>> Lou (and Deborah) >>> >>> >> >> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From sunwq@MIT.EDU Wed Aug 19 00:28:33 2009 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 EAF263A6CB8; Wed, 19 Aug 2009 00:28:33 -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=[AWL=0.001, 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 jlISNNqdazFq; Wed, 19 Aug 2009 00:28:32 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 605243A6CA8; Wed, 19 Aug 2009 00:28:32 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7J7SUeE029858; Wed, 19 Aug 2009 03:28:30 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7J7SKno019461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 03:28:23 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Rschrage" , "'Lou Berger'" , "'Henk Uijterwaal'" Date: Wed, 19 Aug 2009 15:28:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 07:28:34 -0000 More responses below: RS4. Should be more specific as to why this metric is no simple function of single uni-directional LSP Setup Delay metric, i.e. why can it not be deduced from single LSP Setup Delay? [sunwq] This point is raised regarding the sentence "The time needed to setup a large number of LSPs during a short time period can not be deduced by single LSP setup delay." One reason is that when a large number of LSPs in being setup during a short period of time, the control plane may be crowded or even overwhelmed by the large number of signaling and routing messages. This may significantly slow down the processing of a particular signaling message, which will results in longer LSP provisioning delays. Are you suggesting that we add similar explanations to the document? We'd love to do that if you feel it is necessary. RS5. The current definition only addresses multiple uni-directional LSP setups between two nodes ID0 and ID1. What about the the case when ID0 is to setup multiple uni-directional LSP setups to different egress nodes ID1, ID2, ID3,.,IDN? [sunwq] Yes, it is a useful case. Likewise you would expect a case to establish a varied number of (instead of one) LSPs to a set of destinations. Our suggestion is that this case is approached by integrating the defined methodologies of single/multiple LSPs provisioning delay, in the form of a particular testing case, rather than a formal testing methodology. This is in fact a trade-off between complexity and accuracy. Best regards, Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Weiqiang Sun" Sent: Wednesday, August 19, 2009 2:48 PM To: "Rschrage" ; "'Lou Berger'" ; "'Henk Uijterwaal'" Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" ; "'IETF IPPM WG'" ; Subject: Re: [ippm] [Fwd: IPPM expert review request] > Hi Reinhard, > > Many thanks for doing the careful review. We appreciate your many wording > suggestions. We will go through these one by one and adopt those we feel > appropriate. In this email I will not list all the comments since these > will not lead to major technical changes. > > Below I try to respond to the points you raised in the revision. > > RS1. > This would imply that the metric may produce a range of several values at > one time with the minimum value to be taken from that range. > I believe what the authors are trying to say is, that the LSP Setup Delay > Metric provides a lower bound on all possible LSP Delay Metrics of > actually instantiated LSPs, or in other words: an actual LSP Delay Metric > cannot get smaller than an LSP Setup Delay Metric. > [sunwq] > This point is raised regarding the motivation of the sigleton definition > of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying > to say that the minimum value of this metric reflects the (likely) single > lsp setup delay when the control plane is lightly loaded. The formal > definition of the minimum value is in "14.1 The minimum of metric" > In fact we have inherited this from the IPPM documents (see RFC 2681, page > 2 section 1.1 bullet 3). > > RS2. > How? Should there be a methodology be defined for this? > [sunwq] > This point is raised regarding the sentense in our methodologies > sections - "Make sure that the network has enough resource to set up the > requested LSP." > We have assumed that test personnel should have adequate expertise in > allocating enough resources for the testing. The allocation of resources > for the testing purpose can be very test specific and we believe it is > quite outside the scope of this document. > > RS3. > Too vague? As both timestamps are to be taken on the same ingress node, > they should be taken at the same application/network level. > [sunwq] > This point is raised regarding the sentense "If the corresponding RESV > message arrives within a reasonable period of time, take the timestamp > (T2) as soon as possible upon receipt of the message." > Yes, ideally the timestamp should be taken immediately after the reception > of the RESV message. The wording "as soon as possible" is used to allow > for some flexibility when RESV message needs to be propagated to certain > modules where timestamp-taking is most appropriate. > And again, this text is inherited from the IPPM documents (see RFC 2681 > page 7, bullet 3). > > Thanks again and looking forward to your further comments and revisions. > > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Rschrage" > Sent: Tuesday, August 18, 2009 8:23 PM > To: "'Lou Berger'" ; "'Henk Uijterwaal'" > Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" > ; ; "'IETF IPPM WG'" ; > > Subject: RE: [ippm] [Fwd: IPPM expert review request] > >> Hello, >> >> sorry for late response- >> >> Nevertheless here is a first edition of my revision of doc >> draft-ietf-ccamp-lsp-dppm-06. >> >> The doc has been saved in Word 2003 format to easily track changes. >> I am using Kaspersky Anti Virus 2010 software so I trust there should be >> no >> unpleasant surprises when downloading the attached word doc. >> >> >> I thought it would be advisable to first address the suggested comments >> and >> questions upto and including the uni-directional LSP setup delay metric >> and >> after that to continue with the bi-directional and sample definitions as >> covered in the doc. >> >> Please let me have your thoughts on this. >> >> Many thanks. >> Reinhard Schrage >> Tel: +49 (0) 5137 909540 >> Mobile: +49 (0) 172 26.36.046 >> reinhard@schrageconsult.com >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Lou >> Berger >> Sent: Dienstag, 28. Juli 2009 14:59 >> To: Henk Uijterwaal >> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >> sunwq@mit.edu; IETF IPPM WG >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >> Hank/Reinhard, >> >> Thank you very much for undertaking this review. Please cc >> ccamp@ietf.org on any comments you may have. >> >> Lou >> >> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>> Lou, others, >>> >>>> We received the request for a review of a document currently under >>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>> has time to do this review in the near future? >>> >>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>> this. >>> >>> Reinhard: please post anything you find to both the list and the >>> authors. >>> And thank you for doing this. >>> >>> Henk >>> >>>> >>>> Matt & Henk >>>> >>>> -------- Original Message -------- >>>> Subject: IPPM expert review request >>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>> From: Lou Berger >>>> To: ippm-chairs@tools.ietf.org >>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>> zhangguoying >>>> >>>> Hi, >>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>> review >>>> a draft that is progressing through the CCAMP WG. This work applies >>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>> available at: >>>> >>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>> >>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>> can just last call the document in your WG (it has already passed CCAMP >>>> WG LC). >>>> >>>> Thank you, >>>> Lou (and Deborah) >>>> >>>> >>> >>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> From rschrage@schrageconsult.net Wed Aug 19 06:58:24 2009 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 B743128C19E; Wed, 19 Aug 2009 06:58:24 -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 SF0hhXnVzJkw; Wed, 19 Aug 2009 06:58:24 -0700 (PDT) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) by core3.amsl.com (Postfix) with ESMTP id 0ECB53A69DF; Wed, 19 Aug 2009 06:58:22 -0700 (PDT) Received: from fwd03.aul.t-online.de by mailout02.t-online.de with smtp id 1Mdlg3-0002fI-00; Wed, 19 Aug 2009 15:58:11 +0200 Received: from ReinhardLaptop (VyHZ26ZZotacvgPGWasZO6Wef9RzK+mYl-iBIZyFaXtke6QFKvAHBytFLSIJvLZCZJaS8fxHVt@[91.4.36.209]) by fwd03.webpage.t-com.de with esmtp id 1MdlfY-0oGvMe0; Wed, 19 Aug 2009 15:57:40 +0200 From: "Rschrage" To: "'Weiqiang Sun'" , "'Lou Berger'" , "'Henk Uijterwaal'" References: In-Reply-To: Date: Wed, 19 Aug 2009 15:57:38 +0200 Message-ID: <000c01ca20d5$03aeca30$0b0c5e90$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01CA20E5.C7379A30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcogwU+dvlizutOpTeeFdomY4IPOowAEsEmw Content-Language: de X-ID: VyHZ26ZZotacvgPGWasZO6Wef9RzK+mYl-iBIZyFaXtke6QFKvAHBytFLSIJvLZCZJaS8fxHVt X-TOI-MSGID: a06558e2-86e5-46fa-9af3-d3744be5bade X-Mailman-Approved-At: Wed, 19 Aug 2009 07:58:55 -0700 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 14:29:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CA20E5.C7379A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, pls find attached a further updated edition of previous revised doc draft-ietf-ccamp-lsp-dppm-06. I believe this is as far as we can go for the moment before a mutual satisfactory understanding has been reached and a new draft has been issued by the authors. Again, pls feel free to comment. Many thanks. Brgds. Reinhard Schrage Tel: +49 (0) 5137 909540 Mobile: +49 (0) 172 26.36.046 reinhard@schrageconsult.com -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Weiqiang Sun Sent: Mittwoch, 19. August 2009 09:28 To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, ATTLABS'; 'IETF IPPM WG' Subject: Re: [ippm] [Fwd: IPPM expert review request] More responses below: RS4. Should be more specific as to why this metric is no simple function of single uni-directional LSP Setup Delay metric, i.e. why can it not be deduced from single LSP Setup Delay? [sunwq] This point is raised regarding the sentence "The time needed to setup a large number of LSPs during a short time period can not be deduced by single LSP setup delay." One reason is that when a large number of LSPs in being setup during a short period of time, the control plane may be crowded or even overwhelmed by the large number of signaling and routing messages. This may significantly slow down the processing of a particular signaling message, which will results in longer LSP provisioning delays. Are you suggesting that we add similar explanations to the document? We'd love to do that if you feel it is necessary. RS5. The current definition only addresses multiple uni-directional LSP setups between two nodes ID0 and ID1. What about the the case when ID0 is to setup multiple uni-directional LSP setups to different egress nodes ID1, ID2, ID3,.,IDN? [sunwq] Yes, it is a useful case. Likewise you would expect a case to establish a varied number of (instead of one) LSPs to a set of destinations. Our suggestion is that this case is approached by integrating the defined methodologies of single/multiple LSPs provisioning delay, in the form of a particular testing case, rather than a formal testing methodology. This is in fact a trade-off between complexity and accuracy. Best regards, Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Weiqiang Sun" Sent: Wednesday, August 19, 2009 2:48 PM To: "Rschrage" ; "'Lou Berger'" ; "'Henk Uijterwaal'" Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" ; "'IETF IPPM WG'" ; Subject: Re: [ippm] [Fwd: IPPM expert review request] > Hi Reinhard, > > Many thanks for doing the careful review. We appreciate your many wording > suggestions. We will go through these one by one and adopt those we feel > appropriate. In this email I will not list all the comments since these > will not lead to major technical changes. > > Below I try to respond to the points you raised in the revision. > > RS1. > This would imply that the metric may produce a range of several values at > one time with the minimum value to be taken from that range. > I believe what the authors are trying to say is, that the LSP Setup Delay > Metric provides a lower bound on all possible LSP Delay Metrics of > actually instantiated LSPs, or in other words: an actual LSP Delay Metric > cannot get smaller than an LSP Setup Delay Metric. > [sunwq] > This point is raised regarding the motivation of the sigleton definition > of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying > to say that the minimum value of this metric reflects the (likely) single > lsp setup delay when the control plane is lightly loaded. The formal > definition of the minimum value is in "14.1 The minimum of metric" > In fact we have inherited this from the IPPM documents (see RFC 2681, page > 2 section 1.1 bullet 3). > > RS2. > How? Should there be a methodology be defined for this? > [sunwq] > This point is raised regarding the sentense in our methodologies > sections - "Make sure that the network has enough resource to set up the > requested LSP." > We have assumed that test personnel should have adequate expertise in > allocating enough resources for the testing. The allocation of resources > for the testing purpose can be very test specific and we believe it is > quite outside the scope of this document. > > RS3. > Too vague? As both timestamps are to be taken on the same ingress node, > they should be taken at the same application/network level. > [sunwq] > This point is raised regarding the sentense "If the corresponding RESV > message arrives within a reasonable period of time, take the timestamp > (T2) as soon as possible upon receipt of the message." > Yes, ideally the timestamp should be taken immediately after the reception > of the RESV message. The wording "as soon as possible" is used to allow > for some flexibility when RESV message needs to be propagated to certain > modules where timestamp-taking is most appropriate. > And again, this text is inherited from the IPPM documents (see RFC 2681 > page 7, bullet 3). > > Thanks again and looking forward to your further comments and revisions. > > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Rschrage" > Sent: Tuesday, August 18, 2009 8:23 PM > To: "'Lou Berger'" ; "'Henk Uijterwaal'" > Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" > ; ; "'IETF IPPM WG'" ; > > Subject: RE: [ippm] [Fwd: IPPM expert review request] > >> Hello, >> >> sorry for late response- >> >> Nevertheless here is a first edition of my revision of doc >> draft-ietf-ccamp-lsp-dppm-06. >> >> The doc has been saved in Word 2003 format to easily track changes. >> I am using Kaspersky Anti Virus 2010 software so I trust there should be >> no >> unpleasant surprises when downloading the attached word doc. >> >> >> I thought it would be advisable to first address the suggested comments >> and >> questions upto and including the uni-directional LSP setup delay metric >> and >> after that to continue with the bi-directional and sample definitions as >> covered in the doc. >> >> Please let me have your thoughts on this. >> >> Many thanks. >> Reinhard Schrage >> Tel: +49 (0) 5137 909540 >> Mobile: +49 (0) 172 26.36.046 >> reinhard@schrageconsult.com >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Lou >> Berger >> Sent: Dienstag, 28. Juli 2009 14:59 >> To: Henk Uijterwaal >> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >> sunwq@mit.edu; IETF IPPM WG >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >> Hank/Reinhard, >> >> Thank you very much for undertaking this review. Please cc >> ccamp@ietf.org on any comments you may have. >> >> Lou >> >> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>> Lou, others, >>> >>>> We received the request for a review of a document currently under >>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>> has time to do this review in the near future? >>> >>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>> this. >>> >>> Reinhard: please post anything you find to both the list and the >>> authors. >>> And thank you for doing this. >>> >>> Henk >>> >>>> >>>> Matt & Henk >>>> >>>> -------- Original Message -------- >>>> Subject: IPPM expert review request >>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>> From: Lou Berger >>>> To: ippm-chairs@tools.ietf.org >>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>> zhangguoying >>>> >>>> Hi, >>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>> review >>>> a draft that is progressing through the CCAMP WG. This work applies >>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>> available at: >>>> >>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>> >>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>> can just last call the document in your WG (it has already passed CCAMP >>>> WG LC). >>>> >>>> Thank you, >>>> Lou (and Deborah) >>>> >>>> >>> >>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm ------=_NextPart_000_000D_01CA20E5.C7379A30 Content-Type: application/msword; name="draft-ietf-ccamp-lsp-dppm-06 Revised 1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-ccamp-lsp-dppm-06 Revised 1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAcAEAAAAAAAAA EAAAcwEAAAEAAAD+////AAAAAG0BAABuAQAAbwEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAA4AJBAAA8BK/AAAAAAAAEAAAAAAACAAAhmUBAA4AYmpiauvI68gAAAAAAAAAAAAAAAAAAAAA AAAJBBYAOEICAImiAACJogAA31QBAAAAAAAAAAAAAAAAAKYIAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAABoIAAAAAAAAGggAAF0V AAAAAAAAXRUAAAAAAABvFQAAnAEAAOMXAAA4AAAAGxgAABQAAAAAAAAAAAAAAP////8AAAAALxgA AAAAAAAvGAAAAAAAAC8YAAAAAAAALxgAAGQAAACTGAAAFAMAAC8YAAAAAAAAO18AAOABAACnGwAA AAAAAKcbAAAAAAAApxsAAAAAAACnGwAAAAAAAKcbAAAAAAAAghwAAAAAAACCHAAAAAAAAIIcAAAA AAAAnF4AAAIAAACeXgAAAAAAAJ5eAAAAAAAAnl4AAAAAAACeXgAAAAAAAJ5eAAAAAAAAnl4AACQA AAAbYQAAogIAAL1jAABKAAAAwl4AABUAAAAAAAAAAAAAAAAAAAAAAAAAXRUAABIAAACCHAAAlgAA AAAAAAAAAAAAAAAAAAAAAACCHAAAAAAAAIIcAAAAAAAAGB0AAGQAAAB8HQAANAAAAMJeAAAAAAAA AAAAAAAAAABdFQAAAAAAAF0VAAAAAAAApxsAAAAAAAAAAAAAAAAAAKcbAADbAAAA114AACgAAAAY XgAAAAAAABheAAAAAAAAGF4AAAAAAACwHQAAcBIAAF0VAAAAAAAApxsAAAAAAABdFQAAAAAAAKcb AAAAAAAAnF4AAAAAAAAAAAAAAAAAABheAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAghwAAAAAAACcXgAAAAAAAAAAAAAAAAAAGF4AAAAAAAAAAAAA AAAAABheAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGF4AAAAAAACnGwAAAAAAAP////8AAAAAYI7V/dMg ygEAAAAAAAAAAC8YAAAAAAAAIDAAAMQtAAAYXgAAAAAAAAAAAAAAAAAAiF4AABQAAAD/XgAAPAAA ADtfAAAAAAAAGF4AAAAAAAAHZAAAAAAAAORdAAA0AAAAB2QAAAAAAAAYXgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAdkAAAAAAAAAAAAAAAAAAALFwAA2AAAABheAABwAAAAghwAAAAAAACCHAAAAAAAABhe AAAAAAAAghwAAAAAAACCHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAghwA AAAAAACCHAAAAAAAAIIcAAAAAAAAwl4AAAAAAADCXgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGF4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIIcAAAA AAAAghwAAAAAAACCHAAAAAAAADtfAAAAAAAAghwAAAAAAACCHAAAAAAAAIIcAAAAAAAAghwAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAdkAAAAAAAAghwAAAAAAACC HAAAAAAAAIIcAAAAAAAAghwAAAAAAACCHAAAAAAAAIIcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACCHAAAAAAAAIIcAAAAAAAAghwA AAAAAAAaCAAACQwAACMUAAA6AQAABQASAQAABwQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NDU5l dHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgVy4gU3VuLCBFZC4NSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTSlRVDUludGVuZGVkIHN0YXR1czogU3RhbmRhcmRz IFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcuIFpoYW5nLCBFZC4NRXhwaXJlczog SmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBDQVRSDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEp1bHkgOSwgMjAwOQ0NDSBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIER5bmFt aWMgUHJvdmlzaW9uaW5nIFBlcmZvcm1hbmNlIE1ldHJpY3MgaW4NICAgICAgICAgICAgICAgICAg ICAgICBHZW5lcmFsaXplZCBNUExTIE5ldHdvcmtzDSAgICAgICAgICAgICAgICAgICAgZHJhZnQt aWV0Zi1jY2FtcC1sc3AtZHBwbS0wNi50eHQNDVN0YXR1cyBvZiB0aGlzIE1lbW8NDSAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQ0gICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhpcyBkb2N1bWVu dCBtYXkgY29udGFpbiBtYXRlcmlhbA0gICBmcm9tIElFVEYgRG9jdW1lbnRzIG9yIElFVEYgQ29u dHJpYnV0aW9ucyBwdWJsaXNoZWQgb3IgbWFkZSBwdWJsaWNseQ0gICBhdmFpbGFibGUgYmVmb3Jl IE5vdmVtYmVyIDEwLCAyMDA4LiAgVGhlIHBlcnNvbihzKSBjb250cm9sbGluZyB0aGUNICAgY29w eXJpZ2h0IGluIHNvbWUgb2YgdGhpcyBtYXRlcmlhbCBtYXkgbm90IGhhdmUgZ3JhbnRlZCB0aGUg SUVURg0gICBUcnVzdCB0aGUgcmlnaHQgdG8gYWxsb3cgbW9kaWZpY2F0aW9ucyBvZiBzdWNoIG1h dGVyaWFsIG91dHNpZGUgdGhlDSAgIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MuICBXaXRob3V0IG9i dGFpbmluZyBhbiBhZGVxdWF0ZSBsaWNlbnNlIGZyb20NICAgdGhlIHBlcnNvbihzKSBjb250cm9s bGluZyB0aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJpYWxzLCB0aGlzDSAgIGRvY3VtZW50IG1h eSBub3QgYmUgbW9kaWZpZWQgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2VzcywgYW5k DSAgIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5IG5vdCBiZSBjcmVhdGVkIG91dHNpZGUgdGhl IElFVEYgU3RhbmRhcmRzDSAgIFByb2Nlc3MsIGV4Y2VwdCB0byBmb3JtYXQgaXQgZm9yIHB1Ymxp Y2F0aW9uIGFzIGFuIFJGQyBvciB0bw0gICB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3Ro ZXIgdGhhbiBFbmdsaXNoLg0NICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBh cmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0gICBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NICAgRHJh ZnRzLg0NICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXggbW9udGhzDSAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DSAgIHRpbWUuICBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDSAgIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINDSAgIFRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0gICBo dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQ0gICBUaGUgbGlzdCBv ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DSAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQ0gICBUaGlzIEludGVybmV0LURyYWZ0 IHdpbGwgZXhwaXJlIG9uIEphbnVhcnkgMTAsIDIwMTAuDQ1Db3B5cmlnaHQgTm90aWNlDQ0gICBD b3B5cmlnaHQgKGMpIDIwMDkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGUNICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQ0NDVN1biAm IFpoYW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAg ICBbUGFnZSAxXQ0NDUludGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExT IE5ldHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0NDSAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNICAgUHJvdmlzaW9ucyBSZWxh dGluZyB0byBJRVRGIERvY3VtZW50cyBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNICAgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudCAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKS4NICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5 IGRlc2NyaWJlIHlvdXIgcmlnaHRzDSAgIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0IHRv IHRoaXMgZG9jdW1lbnQuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAg ICAgICAgICAgICAgW1BhZ2UgMl0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQ TSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ1BYnN0cmFjdA0NICAgR2Vu ZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykgaXMgb25lIG9m IHRoZSBtb3N0DSAgIHByb21pc2luZyBjYW5kaWRhdGUgdGVjaG5vbG9naWVzIGZvciBmdXR1cmUg ZGF0YSB0cmFuc21pc3Npb24NICAgbmV0d29yay4gIEdNUExTIGhhcyBiZWVuIGRldmVsb3BlZCB0 byBjb250cm9sIGFuZCBvcGVyYXRlIGRpZmZlcmVudA0gICBraW5kcyBvZiBuZXR3b3JrIGVsZW1l bnRzLCBzdWNoIGFzIGNvbnZlbnRpb25hbCByb3V0ZXJzLCBzd2l0Y2hlcywNICAgRGVuc2UgV2F2 ZWxlbmd0aCBEaXZpc2lvbiBNdWx0aXBsZXhpbmcgKERXRE0pIHN5c3RlbXMsIEFkZC0gRHJvcA0g ICBNdWx0aXBsZXhlcnMgKEFETXMpLCBwaG90b25pYyBjcm9zcy1jb25uZWN0cyAoUFhDcyksIG9w dGljYWwgY3Jvc3MtDSAgIGNvbm5lY3RzIChPWENzKSwgZXRjLiAgRHluYW1pYyBwcm92aXNpb25p bmcgYWJpbGl0eSBvZiB0aGVzZQ0gICBwaHlzaWNhbGx5IGRpdmVyc2UgZGV2aWNlcyBkaWZmZXJz IGZyb20gZWFjaCBvdGhlciBkcmFzdGljYWxseS4gIEF0DSAgIHRoZSBzYW1lIHRpbWUsIHRoZSBu ZWVkIGZvciBkeW5hbWljYWxseSBwcm92aXNpb25lZCBjb25uZWN0aW9ucyBpcw0gICBpbmNyZWFz aW5nIGJlY2F1c2Ugb3B0aWNhbCBuZXR3b3JrcyBhcmUgYmVpbmcgZGVwbG95ZWQgaW4gbWV0cm8N ICAgYXJlYXMuICBBcyBkaWZmZXJlbnQgYXBwbGljYXRpb25zIGhhdmUgdmFyaWVkIHJlcXVpcmVt ZW50cyBpbiB0aGUNICAgcHJvdmlzaW9uaW5nIHBlcmZvcm1hbmNlIG9mIG9wdGljYWwgbmV0d29y a3MsIGl0IGlzIGltcGVyYXRpdmUgdG8NICAgZGVmaW5lIHN0YW5kYXJkaXplZCBtZXRyaWNzIGFu ZCBwcm9jZWR1cmVzIHN1Y2ggdGhhdCB0aGUgcGVyZm9ybWFuY2UNICAgb2YgbmV0d29ya3MgYW5k IGFwcGxpY2F0aW9uIG5lZWRzIGNhbiBiZSBtYXBwZWQgdG8gZWFjaCBvdGhlci4NDSAgIFRoaXMg ZG9jdW1lbnQgcHJvdmlkZXMgYSBzZXJpZXMgb2YgcGVyZm9ybWFuY2UgbWV0cmljcyB0byBldmFs dWF0ZQ0gICB0aGUgZHluYW1pYyBMU1AgcHJvdmlzaW9uaW5nIHBlcmZvcm1hbmNlIGluIEdNUExT IG5ldHdvcmtzLA0gICBzcGVjaWZpY2FsbHkgdGhlIGR5bmFtaWMgTFNQIHNldHVwL3JlbGVhc2Ug cGVyZm9ybWFuY2UuICBUaGVzZQ0gICBtZXRyaWNzIGNhbiBkZXBpY3QgdGhlIGZlYXR1cmVzIG9m IEdNUExTIG5ldHdvcmtzIGluIExTUCBkeW5hbWljDSAgIHByb3Zpc2lvbmluZy4gIFRoZXkgY2Fu IGFsc28gYmUgdXNlZCBpbiBvcGVyYXRpb25hbCBuZXR3b3JrcyBmb3INICAgY2FycmllcnMgdG8g bW9uaXRvciB0aGUgY29udHJvbCBwbGFuZSBwZXJmb3JtYW5jZSBpbiByZWFsdGltZS4NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAzXQ0NDUludGVybmV0LURyYWZ0ICAg ICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0N DVRhYmxlIG9mIENvbnRlbnRzDQ0gICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNDSAgIDIuICBDb252ZW50aW9ucyBV c2VkIGluIFRoaXMgRG9jdW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0NICAg My4gIE92ZXJ2aWV3IG9mIFBlcmZvcm1hbmNlIE1ldHJpY3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA5DQ0gICA0LiAgQSBTaW5nbGV0b24gRGVmaW5pdGlvbiBmb3IgU2luZ2xlIFVu aS1kaXJlY3Rpb25hbCBMU1ANICAgICAgIFNldHVwIERlbGF5ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDSAgICAgNC4xLiAgTW90aXZhdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0gICAgIDQu Mi4gIE1ldHJpYyBOYW1lICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTANICAgICA0LjMuICBNZXRyaWMgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDSAgICAgNC40LiAgTWV0cmljIFVuaXRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0gICAgIDQuNS4gIERlZmlu aXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEN ICAgICA0LjYuICBEaXNjdXNzaW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDExDSAgICAgNC43LiAgTWV0aG9kb2xvZ2llcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0NICAgNS4gIEEgU2luZ2xldG9uIERlZmlu aXRpb24gZm9yIG11bHRpcGxlIFVuaS1kaXJlY3Rpb25hbCBMU1ANICAgICAgIFNldHVwIERlbGF5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDSAg ICAgNS4xLiAgTW90aXZhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMw0gICAgIDUuMi4gIE1ldHJpYyBOYW1lICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNICAgICA1LjMuICBNZXRyaWMgUGFyYW1ldGVy cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDSAgICAgNS40LiAg TWV0cmljIFVuaXRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMw0gICAgIDUuNS4gIERlZmluaXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTMNICAgICA1LjYuICBEaXNjdXNzaW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DSAgICAgNS43LiAgTWV0aG9kb2xv Z2llcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0NICAg Ni4gIEEgU2luZ2xldG9uIERlZmluaXRpb24gZm9yIFNpbmdsZSBCaS1kaXJlY3Rpb25hbCAgTFNQ DSAgICAgICBTZXR1cCBEZWxheSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNg0gICAgIDYuMS4gIE1vdGl2YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNICAgICA2LjIuICBNZXRyaWMgTmFtZSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DSAgICAgNi4z LiAgTWV0cmljIFBhcmFtZXRlcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNw0gICAgIDYuNC4gIE1ldHJpYyBVbml0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNICAgICA2LjUuICBEZWZpbml0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DSAgICAgNi42LiAgRGlzY3Vz c2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0g ICAgIDYuNy4gIE1ldGhvZG9sb2dpZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTgNDSAgIDcuICBBIFNpbmdsZXRvbiBEZWZpbml0aW9uIGZvciBtdWx0aXBs ZSBCaS1kaXJlY3Rpb25hbCAgTFNQcw0gICAgICAgU2V0dXAgRGVsYXkgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNICAgICA3LjEuICBNb3RpdmF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DSAg ICAgNy4yLiAgTWV0cmljIE5hbWUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxOQ0gICAgIDcuMy4gIE1ldHJpYyBQYXJhbWV0ZXJzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNICAgICA3LjQuICBNZXRyaWMgVW5pdHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DSAgICAgNy41LiAg RGVmaW5pdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxOQ0gICAgIDcuNi4gIERpc2N1c3Npb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjANICAgICA3LjcuICBNZXRob2RvbG9naWVzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIxDQ0NDQ1TdW4gJiBaaGFuZyAgICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNF0N DQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAg ICAgICAgICBKdWx5IDIwMDkNDQ0gICA4LiAgQSBTaW5nbGV0b24gRGVmaW5pdGlvbiBmb3IgTFNQ IEdyYWNlZnVsIFJlbGVhc2UgRGVsYXkgIC4gLiAuIC4gMjINICAgICA4LjEuICBNb3RpdmF0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDSAgICAg OC4yLiAgTWV0cmljIE5hbWUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyMg0gICAgIDguMy4gIE1ldHJpYyBQYXJhbWV0ZXJzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINICAgICA4LjQuICBNZXRyaWMgVW5pdHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDSAgICAgOC41LiAgRGVm aW5pdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAy Mg0gICAgIDguNi4gIERpc2N1c3Npb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjMNICAgICA4LjcuICBNZXRob2RvbG9naWVzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0DQ0gICA5LiAgQSBEZWZpbml0aW9uIGZv ciBTYW1wbGVzIG9mIFNpbmdsZSBVbmktZGlyZWN0aW9uYWwgTFNQDSAgICAgICBTZXR1cCBEZWxh eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNg0g ICAgIDkuMS4gIE1ldHJpYyBOYW1lICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjYNICAgICA5LjIuICBNZXRyaWMgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DSAgICAgOS4zLiAgTWV0cmljIFVuaXRzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNg0gICAgIDkuNC4g IERlZmluaXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjYNICAgICA5LjUuICBEaXNjdXNzaW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDI3DSAgICAgOS42LiAgTWV0aG9kb2xvZ2llcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNw0gICAgIDkuNy4gIFR5cGljYWwg dGVzdGluZyBjYXNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcNICAg ICAgIDkuNy4xLiAgV2l0aCBubyBMU1AgaW4gdGhlIE5ldHdvcmsgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI4DSAgICAgICA5LjcuMi4gIFdpdGggYSBudW1iZXIgb2YgTFNQcyBpbiB0aGUg TmV0d29yayAuIC4gLiAuIC4gLiAuIC4gLiAyOA0NICAgMTAuIEEgRGVmaW5pdGlvbiBmb3IgU2Ft cGxlcyBvZiBNdWx0aXBsZSBVbmktZGlyZWN0aW9uYWwgTFNQcw0gICAgICAgU2V0dXAgRGVsYXkg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkNICAg ICAxMC4xLiBNZXRyaWMgTmFtZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI5DSAgICAgMTAuMi4gTWV0cmljIFBhcmFtZXRlcnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQ0gICAgIDEwLjMuIE1ldHJpYyBVbml0cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkNICAgICAxMC40LiBE ZWZpbml0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDI5DSAgICAgMTAuNS4gRGlzY3Vzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzMA0gICAgIDEwLjYuIE1ldGhvZG9sb2dpZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzANICAgICAxMC43LiBUeXBpY2FsIHRl c3RpbmcgY2FzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMwDSAgICAg ICAxMC43LjEuIFdpdGggTm8gTFNQIGluIHRoZSBOZXR3b3JrIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzMQ0gICAgICAgMTAuNy4yLiBXaXRoIGEgTnVtYmVyIG9mIExTUHMgaW4gdGhlIE5l dHdvcmsgLiAuIC4gLiAuIC4gLiAuIC4gMzENDSAgIDExLiBBIERlZmluaXRpb24gZm9yIFNhbXBs ZXMgb2YgU2luZ2xlIEJpLWRpcmVjdGlvbmFsICBMU1ANICAgICAgIFNldHVwIERlbGF5ICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyDSAgICAgMTEu MS4gTWV0cmljIE5hbWUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzMg0gICAgIDExLjIuIE1ldHJpYyBQYXJhbWV0ZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMzINICAgICAxMS4zLiBNZXRyaWMgVW5pdHMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyDSAgICAgMTEuNC4gRGVmaW5p dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMg0g ICAgIDExLjUuIERpc2N1c3Npb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzMNICAgICAxMS42LiBNZXRob2RvbG9naWVzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMzDSAgICAgMTEuNy4gVHlwaWNhbCB0ZXN0aW5n IGNhc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNA0gICAgICAgMTEu Ny4xLiBXaXRoIE5vIExTUCBpbiB0aGUgTmV0d29yayAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzQNICAgICAgIDExLjcuMi4gV2l0aCBhIE51bWJlciBvZiBMU1BzIGluIHRoZSBOZXR3b3Jr IC4gLiAuIC4gLiAuIC4gLiAuIDM0DQ0gICAxMi4gQSBEZWZpbml0aW9uIGZvciBTYW1wbGVzIG9m IE11bHRpcGxlIEJpLWRpcmVjdGlvbmFsICBMU1BzDSAgICAgICBTZXR1cCBEZWxheSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQ0gICAgIDEyLjEu IE1ldHJpYyBOYW1lICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzUNDQ0NU3VuICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEw ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1p YyBQUE0gaW4gR01QTFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NICAgICAxMi4yLiBN ZXRyaWMgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM1DSAgICAgMTIuMy4gTWV0cmljIFVuaXRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzNQ0gICAgIDEyLjQuIERlZmluaXRpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzUNICAgICAxMi41LiBEaXNjdXNzaW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2DSAgICAg MTIuNi4gTWV0aG9kb2xvZ2llcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzNg0gICAgIDEyLjcuIFR5cGljYWwgdGVzdGluZyBjYXNlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNICAgICAgIDEyLjcuMS4gV2l0aCBObyBMU1AgaW4g dGhlIE5ldHdvcmsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3DSAgICAgICAxMi43LjIu IFdpdGggYSBOdW1iZXIgb2YgTFNQcyBpbiB0aGUgTmV0d29yayAuIC4gLiAuIC4gLiAuIC4gLiAz Nw0NICAgMTMuIEEgRGVmaW5pdGlvbiBmb3IgU2FtcGxlcyBvZiBMU1AgR3JhY2VmdWwgUmVsZWFz ZSBEZWxheSAuIC4gLiAuIDM4DSAgICAgMTMuMS4gTWV0cmljIE5hbWUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOA0gICAgIDEzLjIuIE1ldHJpYyBQYXJh bWV0ZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzgNICAgICAx My4zLiBNZXRyaWMgVW5pdHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDM4DSAgICAgMTMuNC4gRGVmaW5pdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOA0gICAgIDEzLjUuIERpc2N1c3Npb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzgNICAgICAxMy42LiBNZXRo b2RvbG9naWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM5 DQ0gICAxNC4gU29tZSBTdGF0aXN0aWNzIERlZmluaXRpb25zIGZvciBNZXRyaWNzIHRvIFJlcG9y dCAgLiAuIC4gLiAuIC4gNDANICAgICAxNC4xLiBUaGUgTWluaW11bSBvZiBNZXRyaWMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwDSAgICAgMTQuMi4gVGhlIE1lZGlhbiBv ZiBNZXRyaWMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MA0gICAgIDE0 LjMuIFRoZSBwZXJjZW50aWxlIG9mIE1ldHJpYyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNDANICAgICAxNC40LiBGYWlsdXJlIHN0YXRpc3RpY3Mgb2YgTWV0cmljIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwDSAgICAgICAxNC40LjEuIEZhaWx1cmUgQ291bnQgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MQ0gICAgICAgMTQuNC4yLiBG YWlsdXJlIFJhdGlvICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDEN DSAgIDE1LiBEaXNjdXNzaW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA0Mg0NICAgMTYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQzDQ0gICAxNy4gSUFOQSBDb25zaWRlcmF0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQNDSAgIDE4 LiBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA0NQ0NICAgMTkuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ2DSAgICAgMTkuMS4gTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Ng0gICAgIDE5LjIuIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDYNDSAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0OA0NDQ0NDQ0NDQ0NDQ0NU3VuICYgWmhhbmcgICAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDZdDQ0NSW50ZXJu ZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMgTmV0d29ya3MgICAgICAgICAg SnVseSAyMDA5DQ0NMS4gIEludHJvZHVjdGlvbg0NICAgR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9j b2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykgaXMgb25lIG9mIHRoZSBtb3N0DSAgIHByb21pc2lu ZyBjb250cm9sIHBsYW5lIHNvbHV0aW9ucyBmb3IgZnV0dXJlIHRyYW5zcG9ydCBhbmQgc2Vydmlj ZQ0gICBuZXR3b3JrLiAgR01QTFMgaGFzIGJlZW4gZGV2ZWxvcGVkIHRvIGNvbnRyb2wgYW5kIG9w ZXJhdGUgZGlmZmVyZW50DSAgIGtpbmRzIG9mIG5ldHdvcmsgZWxlbWVudHMsIHN1Y2ggYXMgY29u dmVudGlvbmFsIHJvdXRlcnMsIHN3aXRjaGVzLA0gICBEZW5zZSBXYXZlbGVuZ3RoIERpdmlzaW9u IE11bHRpcGxleGluZyAoRFdETSkgc3lzdGVtcywgQWRkLURyb3ANICAgTXVsdGlwbGV4b3JzIChB RE1zKSwgcGhvdG9uaWMgY3Jvc3MtY29ubmVjdHMgKFBYQ3MpLCBvcHRpY2FsIGNyb3NzLQ0gICBj b25uZWN0cyAoT1hDcyksIGV0Yy4gIER5bmFtaWMgcHJvdmlzaW9uaW5nIGFiaWxpdHkgb2YgdGhl c2UNICAgcGh5c2ljYWxseSBkaXZlcnNlIGRldmljZXMgZGlmZmVycyBmcm9tIGVhY2ggb3RoZXIg ZHJhc3RpY2FsbHkuDQ0gICBUaGUgaW50cm9kdWN0aW9uIG9mIGEgY29udHJvbCBwbGFuZSBpbnRv IG9wdGljYWwgY2lyY3VpdCBzd2l0Y2hpbmcNICAgbmV0d29ya3MgcHJvdmlkZXMgdGhlIGJhc2lz IGZvciBhdXRvbWF0aW5nIGF1dG9tYXRlcyB0aGUgcHJvdmlzaW9uaW5nIG9mIGNvbm5lY3Rpb25z IGFuZCBkcmFzdGljYWxseQ0gICByZWR1Y2VzIGNvbm5lY3Rpb24gcHJvdmlzaW9uIGRlbGF5LiAg QXMgbW9yZSBhbmQgbW9yZSBzZXJ2aWNlcyBhbmQNICAgYXBwbGljYXRpb25zIGFyZSBzZWVraW5n IHRvIHVzZSBHTVBMUyBjb250cm9sbGVkIG5ldHdvcmtzIGFzIHRoZWlyDSAgIHVuZGVybHlpbmcg dHJhbnNwb3J0IG5ldHdvcmssIGFuZCBpbmNyZWFzaW5nbHkgaW4gYSBkeW5hbWljIHdheSwgdGhl DSAgIG5lZWQgaXMgZ3Jvd2luZyBmb3IgbWVhc3VyaW5nIGFuZCBjaGFyYWN0ZXJpemluZyB0aGUg cGVyZm9ybWFuY2Ugb2YNICAgTFNQIHByb3Zpc2lvbmluZyBpbiBHTVBMUyBuZXR3b3Jrcywgc3Vj aCB0aGF0IHJlcXVpcmVtZW50IGZyb20NICAgYXBwbGljYXRpb25zIGFuZCB0aGUgcHJvdmlzaW9u aW5nIGNhcGFiaWxpdHkgb2YgdGhlIG5ldHdvcmsgY2FuIGJlDSAgIG1hcHBlZCB0byBlYWNoIG90 aGVyLg0NICAgVGhpcyBkcmFmdCBkZWZpbmVzIHBlcmZvcm1hbmNlIG1ldHJpY3MgYW5kIG1ldGhv ZG9sb2dpZXMgdGhhdCBjYW4gYmUNICAgdXNlZCB0byBkZXBpY3QgdGhlIGR5bmFtaWMgTFNQIHBy b3Zpc2lvbmluZyBwZXJmb3JtYW5jZSBvZiBHTVBMUw0gICBuZXR3b3JrcywgbW9yZSBzcGVjaWZp Y2FsbHksIHBlcmZvcm1hbmNlIG9mIHRoZSBzaWduYWxpbmcgcHJvdG9jb2wuDSAgIFRoZSBtZXRy aWNzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gb24gdGhlIG9uZSBoYW5kIGJlIHVzZWQg dG8NICAgZGVwaWN0IHRoZSBhdmVyYWdlIHBlcmZvcm1hbmNlIG9mIEdNUExTIGltcGxlbWVudGF0 aW9ucy4gIE9uIHRoZQ0gICBvdGhlciBoYW5kLCBpdCBjYW4gYWxzbyBiZSB1c2VkIGluIG9wZXJh dGlvbmFsIGVudmlyb25tZW50cyBmb3INICAgY2FycmllcnMgdG8gbW9uaXRvciB0aGUgY29udHJv bCBwbGFuZSBvcGVyYXRpb24gaW4gcmVhbC10aW1lLiAgRm9yDSAgIGV4YW1wbGUsIGEgbmV3IG9i amVjdCBjYW4gYmUgYWRkZWQgdG8gR01QTFMgVEUgU1REIE1JQiBbUkZDNDgwMl0gc28NICAgdGhh dCB0aGUgY3VycmVudCBhbmQgcGFzdCBjb250cm9sIHBsYW5lIHBlcmZvcm1hbmNlIGNhbiBiZSBt b25pdG9yZWQNICAgdGhyb3VnaCBuZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVtcy4gIFRoZSBleHRl bnNpb24gb2YgVEUtTUlCIHRvDSAgIHN1cHBvcnQgdGhlIGRlZmluZWQgbWV0cmljcyBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NU3VuICYg WmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAg IFtQYWdlIDddDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMg TmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NMi4gIENvbnZlbnRpb25zIFVzZWQgaW4gVGhp cyBEb2N1bWVudA0NICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJF RCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD T01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0gICBkb2N1bWVudCBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA4XQ0NDUludGVy bmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAgICAg IEp1bHkgMjAwOQ0NDTMuICBPdmVydmlldyBvZiBQZXJmb3JtYW5jZSBNZXRyaWNzDQ0gICBJbiB0 aGlzIG1lbW8sIHRvIGRlcGljdCB0aGUgZHluYW1pYyBMU1AgcHJvdmlzaW9uaW5nIHBlcmZvcm1h bmNlIG9mIGENICAgR01QTFMgbmV0d29yaywgd2UgZGVmaW5lIDMgcGVyZm9ybWFuY2UgbWV0cmlj czogdW5pLWRpcmVjdGlvbmFsIExTUA0gICBzZXR1cCBkZWxheSwgYmktZGlyZWN0aW9uYWwgTFNQ IHNldHVwIGRlbGF5LCBhbmQgTFNQIGdyYWNlZnVsIHJlbGVhc2UNICAgZGVsYXkuICBUaGUgbGF0 ZW5jeSBvZiB0aGUgTFNQIHNldHVwL3JlbGVhc2Ugc2lnbmFsIGlzIGNvbmNlcHR1YWxseSBzaW1p bGFyIHRvIHRoZQ0gICBSb3VuZC10cmlwIERlbGF5IGluIElQIG5ldHdvcmtzLiAgVGhpcyBlbmFi bGVzIHVzIHRvIHJlZmVyIHRvU28gd2UgcmVmZXIgdGhlIHN0cnVjdHVyZXMgYW5kDSAgIG5vdGlv bnMgaW50cm9kdWNlZCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBJUFBNIEZyYW1ld29yayBkb2N1bWVu dCwNICAgW1JGQzIzMzBdIFtSRkMyNjc5XSBbUkZDMjY4MV0uICBUaGUgcmVhZGVyIGlzIGFzc3Vt ZWQgdG8gYmUgZmFtaWxpYXINICAgd2l0aCB0aGUgbm90aW9ucyBpbiB0aG9zZSBkb2N1bWVudHMu DQ0gICBOb3RlIHRoYXQgZGF0YSBwYXRoIHJlbGF0ZWQgbWV0cmljcywgZm9yIGV4YW1wbGUsIHRo ZSB0aW1lIGJldHdlZW4NICAgdGhlIHJlY2VwdGlvbiBvZiBSRVNWIG1lc3NhZ2UgYnkgaW5ncmVz cyBub2RlIGFuZCBmb3J3YXJkIGRhdGEgcGF0aA0gICBiZWNvbWVzIG9wZXJhdGlvbmFsLCBhcmUg ZGVmaW5lZCBpbiBhbm90aGVyIGRvY3VtZW50DSAgIFtJLUQuc3VuLWNjYW1wLWRwbV0uICBBbiBp bXBsZW1lbnRhdGlvbiBNQVkgY2hvb3NlIHdoZXRoZXIgdG8NICAgaW1wbGVtZW50IG1ldHJpY3Mg aW4gdGhlIHR3byBkb2N1bWVudHMgdG9nZXRoZXIuICBIb3dldmVyLCBpdCBpcw0gICBSRUNPTU1F TkRFRCB0aGF0IGJvdGggbWVhc3VyZW1lbnRzIGFyZSBwZXJmb3JtZWQgdG8gY29tcGxlbWVudCBl YWNoDSAgIG90aGVyLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1TdW4gJiBaaGFu ZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICAgW1Bh Z2UgOV0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3 b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ00LiAgQSBTaW5nbGV0b24gRGVmaW5pdGlvbiBmb3Ig U2luZ2xlIFVuaS1kaXJlY3Rpb25hbCBMU1AgU2V0dXAgRGVsYXkNDSAgIFRoaXMgcGFydCBkZWZp bmVzIGEgbWV0cmljIGZvciBzaW5nbGUgdW5pLWRpcmVjdGlvbmFsIExhYmVsIFN3aXRjaGVkDSAg IFBhdGggc2V0dXAgZGVsYXkgYWNyb3NzIGEgR01QTFMgbmV0d29yay4NDTQuMS4gIE1vdGl2YXRp b24NDSAgIFNpbmdsZSB1bmktZGlyZWN0aW9uYWwgTGFiZWwgU3dpdGNoZWQgUGF0aCBzZXR1cCBk ZWxheSBpcyB1c2VmdWwgZm9yDSAgIHNldmVyYWwgcmVhc29uczoNDSAgIG8gIFNpbmdsZSBMU1Ag c2V0dXAgZGVsYXkgaXMgYW4gaW1wb3J0YW50IG1ldHJpYyB0aGF0IGRlcGljdHMgdGhlDSAgICAg IHByb3Zpc2lvbmluZyBwZXJmb3JtYW5jZSBvZiBhIEdNUExTIG5ldHdvcmsuICBMb25nZXIgTFNQ IHNldHVwDSAgICAgIGRlbGF5IHdpbGwgbW9zdCBsaWtlbHkgaW5jdXIgaGlnaGVyIG92ZXJoZWFk IGZvciB0aGUgcmVxdWVzdGluZyBhcHBsaWNhdGlvbiwNICAgICAgZXNwZWNpYWxseSB3aGVuIHRo ZSBMU1AgZHVyYXRpb24gaXRzZWxmIGlzIGNvbXBhcmFibGUgdG8gdGhlIExTUCBzZXR1cA0gICAg ICBkZWxheS4NDSAgIG8gIFRoZSBtaW5pbXVtIHZhbHVlIG9mIHRoaXMgbWV0cmljIAVwcm92aWRl cyBhbiBpbmRpY2F0aW9uIG9mIHRoZQ0gICAgICBkZWxheSB0aGF0IHdpbGwgbGlrZWx5IGJlIGV4 cGVyaWVuY2VkIHdoZW4gdGhlIExTUCB0cmF2ZXJzZWQgdGhlDSAgICAgIHNob3J0ZXN0IHJvdXRl IGF0IHRoZSBsaWdodGVzdCBsb2FkIGluIHRoZSBjb250cm9sIHBsYW5lLiAgQXMgdGhlDSAgICAg IGRlbGF5IGl0c2VsZiBjb25zaXN0cyBvZiBzZXZlcmFsIGNvbXBvbmVudHMsIHN1Y2ggYXMgbGlu aw0gICAgICBwcm9wYWdhdGlvbiBkZWxheSBhbmQgbm9kYWwgcHJvY2Vzc2luZyBkZWxheSwgdGhp cyBtZXRyaWMgYWxzbw0gICAgICByZWZsZWN0cyB0aGUgc3RhdHVzIG9mIGNvbnRyb2wgcGxhbmUu ICBGb3IgZXhhbXBsZSwgZm9yIExTUHMNICAgICAgdHJhdmVyc2luZyB0aGUgc2FtZSByb3V0ZSwg bG9uZ2VyIHNldHVwIGRlbGF5cyBtYXkgc3VnZ2VzdA0gICAgICBjb25nZXN0aW9uIGluIHRoZSBj b250cm9sIGNoYW5uZWwgb3IgaGlnaCBjb250cm9sIGVsZW1lbnQgbG9hZC4NICAgICAgRm9yIHRo aXMgcmVhc29uLCB0aGlzIG1ldHJpYyBpcyB1c2VmdWwgZm9yIHRlc3RpbmcgYW5kIGRpYWdub3N0 aWMNICAgICAgcHVycG9zZXMuDQ0gICBvICBUaGUgb2JzZXJ2ZWQgdmFyaWFuY2UgaW4gYSBzYW1w bGUgb2YgTFNQIHNldHVwIGRlbGF5IG1ldHJpYyB2YWx1ZXMgdmFyaWFuY2VtYXkgc2VydmUgYXMg YW4gZWFybHkgaW5kaWNhdG9yIG9uIHRoZSBmZWFzaWJpbGl0eSBvZiBzdXBwb3J0IG9mIGFwcGxp Y2F0aW9ucyB0aGF0IGhhdmUgc3RyaW5nZW50IHNldHVwIGRlbGF5IHJlcXVpcmVtZW50cy4gDSBo YXMgZGlmZmVyZW50IGltcGFjdCBvbiBhcHBsaWNhdGlvbnMuDSAgICAgIEVycmF0aWMgdmFyaWF0 aW9uIGluIExTUCBzZXR1cCBkZWxheSBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gc3VwcG9ydA0gICAg ICBhcHBsaWNhdGlvbnMgdGhhdCBoYXZlIHN0cmluZ2VudCBzZXR1cCBkZWxheSByZXF1aXJlbWVu dC4NDSAgIFRoZSBtZWFzdXJlbWVudCBvZiBzaW5nbGUgdW5pLWRpcmVjdGlvbmFsIExTUCBzZXR1 cCBkZWxheSBpbnN0ZWFkIG9mDSAgIGJpLWRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBpcyBt b3RpdmF0ZWQgYnkgdGhlIGZvbGxvd2luZyBmYWN0b3JzOg0NICAgbyAgU29tZSBhcHBsaWNhdGlv bnMgbWF5IHVzZSBvbmx5IHVuaS1kaXJlY3Rpb25hbCBMU1BzIHJhdGhlciB0aGFuDSAgICAgIGJp LWRpcmVjdGlvbmFsIG9uZXMuICBGb3IgZXhhbXBsZSwgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNl cyB3aXRoDSAgICAgIG11bHRpY2FzdGluZyBtYXkgdXNlIG9ubHkgdW5pLWRpcmVjdGlvbmFsIExT UHMuDQ00LjIuICBNZXRyaWMgTmFtZQ0NICAgc2luZ2xlIHVuaS1kaXJlY3Rpb25hbCBMU1Agc2V0 dXAgZGVsYXkNDTQuMy4gIE1ldHJpYyBQYXJhbWV0ZXJzDQ0gICBvICBJRDAsIHRoZSBpbmdyZXNz IExTUiBJRA0NICAgbyAgSUQxLCB0aGUgZWdyZXNzIExTUiBJRA0NDQ0NU3VuICYgWmhhbmcgICAg ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMTBd DQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMgTmV0d29ya3Mg ICAgICAgICAgSnVseSAyMDA5DQ0NICAgbyAgVCwgYSB0aW1lIHdoZW4gdGhlIHNldHVwIGlzIGF0 dGVtcHRlZA0NNC40LiAgTWV0cmljIFVuaXRzDQ0gICBUaGUgdmFsdWUgb2Ygc2luZ2xlIHVuaS1k aXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgaXMgZWl0aGVyIGEgcmVhbA0gICBudW1iZXIsIG9y IGFuIHVuZGVmaW5lZCBudW1iZXIgb2YgbWlsbGlzZWNvbmRzLg0NNC41LiAgRGVmaW5pdGlvbg0N ICAgVGhlIHNpbmdsZSB1bmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5IGZyb20gdGhlIGlu Z3Jlc3Mgbm9kZSBJRDANICAgdG8gdGhlIGVncmVzcyBub2RlIElEMSBbUkZDMzk0NV0gYXQgVCBp cyBkVCBpcyBkZWZpbmVkIGFzIHRoZSBldmVudCBtZWFucyB0aGF0IGluZ3Jlc3Mgbm9kZQ0gICBJ RDAgaGFzIHNlbnQgc2VuZHMgdGhlIGZpcnN0IGJpdCBvZiBhIFBBVEggbWVzc2FnZSBwYWNrZXQg dG8gZWdyZXNzIG5vZGUgSUQxDSAgIGF0IHdpcmUtdGltZSBULCBhbmQgaGFzIHJlY2VpdmVkIHRo YXQgdGhlIGluZ3Jlc3Mgbm9kZSBJRDAgcmVjZWl2ZWQgdGhlIGxhc3QgYml0DSAgIG9mIHRoZSBj b3JyZXNwb25kaW5ncmVzcG9uZGluZyBSRVNWIG1lc3NhZ2UgcGFja2V0IGZyb20gdGhlIGVncmVz cyBub2RlIElEMSBhdCB3aXJlLQ0gICB0aW1lIFQrZFQgaW4gdGhlIHVuaS1kaXJlY3Rpb25hbCBM U1Agc2V0dXAgY2FzZS4NDSAgIFRoZSBzaW5nbGUgdW5pLWRpcmVjdGlvbmFsIExTUCBzZXR1cCBk ZWxheSBmcm9tIHRoZSBpbmdyZXNzIG5vZGUgSUQwDSAgIHRvIHRoZSBlZ3Jlc3Mgbm9kZSBJRDEg YXQgVCBpcyB1bmRlZmluZWQsIGlzIGRlZmluZWQgYXMgdGhlIGV2ZW50bWVhbnMgdGhhdCBpbmdy ZXNzIG5vZGUgSUQwDSAgIGhhcyBzZW50IHNlbmRzIHRoZSBmaXJzdCBiaXQgb2YgUEFUSCBtZXNz YWdlIHBhY2tldCB0byBlZ3Jlc3Mgbm9kZSBJRDEgYXQNICAgd2lyZS10aW1lIFQgYW5kIGhhcyBu b3QgcmVjZWl2ZWQgYSBjb3JyZXNwb25kaW5nIFJFU1YgbWVzc2FnZSBmcm9tIGVncmVzcyBub2Rl IElEMSB3aXRoaW4gYSByZWFzb25hYmxlIHBlcmlvZCBvZiB0aW1lLiANdGhhdCBpbmdyZXNzIG5v ZGUgSUQwIGRvZXMgbm90IHJlY2VpdmUgdGhlDSAgIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdl IHdpdGhpbiBhIHJlYXNvbmFibGUgcGVyaW9kIG9mIHRpbWUuDQ0gICBUaGUgdW5kZWZpbmVkIHZh bHVlIG9mIHRoaXMgbWV0cmljIGluZGljYXRlcyBhbiBldmVudCBvZiBTaW5nbGUgVW5pLQ0gICBk aXJlY3Rpb25hbCBMU1AgU2V0dXAgRmFpbHVyZSwgYW5kIHdvdWxkIGJlIHVzZWQgdG8gcmVwb3J0 IGEgY291bnQgb3INICAgYW4gcGVyY2VudGFnZSBvZiBTaW5nbGUgVW5pLWRpcmVjdGlvbmFsIExT UCBTZXR1cCBmYWlsdXJlcy4gIFNlZQ0gICBzZWN0aW9uIFNlY3Rpb24gMTQuNCBmb3IgZGVmaW5p dGlvbnMgb2YgTFNQIHNldHVwL3JlbGVhc2UgZmFpbHVyZXMuDQ00LjYuICBEaXNjdXNzaW9uDQ0g ICBUaGUgZm9sbG93aW5nIGlzc3VlcyBhcmUgbGlrZWx5IHRvIGNvbWUgdXAgaW4gcHJhY3RpY2U6 DQ0gICBvICBUaGUgYWNjdXJhY3kgb2YgdW5pLWRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBh dCB0aW1lIFQgZGVwZW5kcw0gICAgICBvbiB0aGUgY2xvY2sgcmVzb2x1dGlvbiBpbiB0aGUgaW5n cmVzcyBub2RlOyBidXQgc3luY2hyb25pemF0aW9uDSAgICAgIGJldHdlZW4gdGhlIGluZ3Jlc3Mg bm9kZSBhbmQgZWdyZXNzIG5vZGUgaXMgbm90IHJlcXVpcmVkIHNpbmNlDSAgICAgIHVuaS1kaXJl Y3Rpb25hbCBMU1Agc2V0dXAgdXNlcyB0d28td2F5IHNpZ25hbGluZy4NDSAgIG8gIEEgZ2l2ZW4g bWV0aG9kb2xvZ3kgd2lsbCBoYXZlIHRvIGluY2x1ZGUgYSB3YXkgdG8gZGV0ZXJtaW5lDSAgICAg IHdoZXRoZXIgYSBsYXRlbmN5IHZhbHVlIGlzIGluZmluaXRlIG9yIHdoZXRoZXIgaXQgaXMgbWVy ZWx5IHZlcnkNICAgICAgbGFyZ2UuICBTaW1wbGUgdXBwZXIgYm91bmRzIE1BWSBiZSB1c2VkLiAg QnV0IEdNUExTIG5ldHdvcmtzIG1heQ0gICAgICBhY2NvbW1vZGF0ZSBtYW55IGtpbmRzIG9mIGRl dmljZXMuICBGb3IgZXhhbXBsZSwgc29tZSBwaG90b25pYw0gICAgICBjcm9zcy1jb25uZWN0cyAo UFhDcykgaGF2ZSB0byBtb3ZlIG1pY3JvIG1pcnJvcnMuICBUaGlzIHBoeXNpY2FsDSAgICAgIG1v dGlvbiBtYXkgdGFrZSBzZXZlcmFsIG1pbGxpc2Vjb25kcy4gIEJ1dCB0aGUgY29tbW9uIGVsZWN0 cm9uaWMNICAgICAgc3dpdGNoZXMgY2FuIGZpbmlzaCB0aGUgbm9kYWwgcHJvY2Vzc2luZyB3aXRo aW4gc2V2ZXJhbA0gICAgICBtaWNyb3NlY29uZHMuICBTbyB0aGUgdW5pLWRpcmVjdGlvbmFsIExT UCBzZXR1cCBkZWxheSB2YXJpZXMNICAgICAgZHJhc3RpY2FsbHkgZnJvbSBvbmUgbmV0d29yayB0 byBhbm90aGVyLiAgSW4gcHJhY3RpY2UsIHRoZSB1cHBlcg0gICAgICBib3VuZCBzaG91bGQgYmUg Y2hvc2VuIGNhcmVmdWxseSBhbmQgdGhlIHZhbHVlIE1VU1QgYmUgcmVwb3J0ZWQuDQ0NDQ0NU3Vu ICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAg ICAgW1BhZ2UgMTFdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01Q TFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NICAgbyAgSWYgYW4gaW5ncmVzcyBub2Rl IHNlbmRzIG91dCB0aGUgUEFUSCBtZXNzYWdlIHRvIHNldCB1cCBhbiBMU1AsIGJ1dA0gICAgICBu ZXZlciByZWNlaXZlcyB0aGUgY29ycmVzcG9uZGluZyBSRVNWIG1lc3NhZ2UsIHRoZSB1bmktZGly ZWN0aW9uYWwgTFNQDSAgICAgIHNldHVwIGRlbGF5IG1ldHJpYyBNVVNUIGJlIHNldCB0byB1bmRl ZmluZWQuDQ0gICBvICBJZiB0aGUgaW5ncmVzcyBub2RlIHNlbmRzIG91dCB0aGUgUEFUSCBtZXNz YWdlIHRvIHNldCB1cCBhbiBMU1AsIGJ1dA0gICAgICByZWNlaXZlcyBhIFBhdGhFcnIgbWVzc2Fn ZSwgdGhlIHVuaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgbWV0cmljIE1VU1QgYmUNICAg ICAgc2V0IHRvIHVuZGVmaW5lZC4gIFRoZXJlIGFyZSBtYW55IHBvc3NpYmxlIHJlYXNvbnMgZm9y IHRoaXMgY2FzZS4NICAgICAgRm9yIGV4YW1wbGUsIHRoZSBQQVRIIG1lc3NhZ2UgaGFzIGludmFs aWQgcGFyYW1ldGVycyBvciB0aGUNICAgICAgbmV0d29yayBkb2VzIG5vdCBoYXZlIGVub3VnaCBy ZXNvdXJjZSB0byBzZXQgdXAgdGhlIHJlcXVlc3RlZCBMU1AsDSAgICAgIGV0Yy4NDTQuNy4gIE1l dGhvZG9sb2dpZXMNDSAgIEdlbmVyYWxseSB0aGUgbWV0aG9kb2xvZ3kgd291bGQgcHJvY2VlZCBh cyBmb2xsb3dzOg0NICAgbyAgTWFrZSBzdXJlIHRoYXQgdGhlIG5ldHdvcmsgaGFzIGVub3VnaCBy ZXNvdXJjZSB0byBzZXQgdXAgdGhlDSAgICAgIHJlcXVlc3RlZCBMU1AuDQUNICAgbyAgQXQgdGhl IGluZ3Jlc3Mgbm9kZSwgZm9ybSB0aGUgUEFUSCBtZXNzYWdlIGFjY29yZGluZyB0byB0aGUgTFNQ DSAgICAgIHJlcXVpcmVtZW50cy4gIEEgdGltZXN0YW1wIChUMSkgbWF5IGJlIHN0b3JlZCBsb2Nh bGx5IG9uIHRoZQ0gICAgICBpbmdyZXNzIG5vZGUgd2hlbiB0aGUgUEFUSCBtZXNzYWdlIHBhY2tl dCBpcyBzZW50IHRvd2FyZHMgdGhlDSAgICAgIGVncmVzcyBub2RlLg0NICAgbyAgSWYgdGhlIGNv cnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlIGFycml2ZXMgd2l0aGluIGEgcmVhc29uYWJsZQ0gICAg ICBwZXJpb2Qgb2YgdGltZSwgdGFrZSB0aGUgdGltZXN0YW1wIChUMikgYXMgc29vbiBhcyBwb3Nz aWJsZSAFdXBvbg0gICAgICByZWNlaXB0IG9mIHRoZSBtZXNzYWdlLiAgQnkgc3VidHJhY3Rpbmcg dGhlIHR3byB0aW1lc3RhbXBzLCBhbg0gICAgICBlc3RpbWF0ZSBvZiB1bmktZGlyZWN0aW9uYWwg TFNQIHNldHVwIGRlbGF5IChUMiAtVDEpIGNhbiBiZQ0gICAgICBjb21wdXRlZC4NDSAgIG8gIElm IHRoZSBjb3JyZXNwb25kaW5nIFJFU1YgbWVzc2FnZSBmYWlscyB0byBhcnJpdmUgd2l0aGluIGEN ICAgICAgcmVhc29uYWJsZSBwZXJpb2Qgb2YgdGltZSwgdGhlIHVuaS1kaXJlY3Rpb25hbCBMU1Ag c2V0dXAgZGVsYXkgaXMNICAgICAgZGVlbWVkIHRvIGJlIHVuZGVmaW5lZC4gIE5vdGUgdGhhdCB0 aGUgJ3JlYXNvbmFibGUnIHRocmVzaG9sZCBpcyBhDSAgICAgIHBhcmFtZXRlciBvZiB0aGUgbWV0 aG9kb2xvZ3kuDQ0gICBvICBJZiB0aGUgY29ycmVzcG9uZGluZyByZXNwb25zZSBtZXNzYWdlIGlz IFBhdGhFcnIsIHRoZSB1bmktDSAgICAgIGRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBpcyBk ZWVtZWQgdG8gYmUgdW5kZWZpbmVkLg0NDQ0NDQ0NDQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAxMl0NDQ1J bnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAg ICAgICBKdWx5IDIwMDkNDQ01LiAgQSBTaW5nbGV0b24gRGVmaW5pdGlvbiBmb3IgbXVsdGlwbGUg VW5pLWRpcmVjdGlvbmFsIExTUCBTZXR1cCBEZWxheQ0NICAgVGhpcyBwYXJ0IGRlZmluZXMgYSBt ZXRyaWMgZm9yIG11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBMYWJlbA0gICBTd2l0Y2hlZCBQYXRo cyBzZXR1cCBkZWxheSBhY3Jvc3MgYSBHTVBMUyBuZXR3b3JrLg0NNS4xLiAgTW90aXZhdGlvbg0N ICAgTXVsdGlwbGUgdW5pLWRpcmVjdGlvbmFsIExhYmVsIFN3aXRjaGVkIFBhdGhzIHNldHVwIGRl bGF5IGlzIHVzZWZ1bA0gICBmb3Igc2V2ZXJhbCByZWFzb25zOg0NICAgbyAgDVVwb24gdHJhZmZp YyBpbnRlcnJ1cHRpb24gY2F1c2VkIGJ5IG5ldHdvcmsgZmFpbHVyZSBvciBuZXR3b3JrDSAgICAg IHVwZ3JhZGUsIGNDYXJyaWVycyBtYXkgcmVxdWlyZSBhIGxhcmdlIG51bWJlciBvZiBMU1BzIGJl IHNldCB1cA0gICAgICBkdXJpbmcgYSBzaG9ydCB0aW1lIHBlcmlvZC4gVGhpcyByZXF1ZXN0IG1h eSBhcmlzZSBlLmcuIGFzIGEgY29uc2VxdWVuY2UgdG8gaW50ZXJydXB0aW9ucyBvbiBlc3RhYmxp c2hlZCBMU1BzIG9yIG90aGVyIG5ldHdvcmsgZmFpbHVyZXMuDQ0gICBvICBUaGUgdGltZSBuZWVk ZWQgdG8gc2V0dXAgYSBsYXJnZSBudW1iZXIgb2YgTFNQcyBkdXJpbmcgYSBzaG9ydA0gICAgICB0 aW1lIHBlcmlvZCBjYW4gbm90IGJlIGRlZHVjZWQgYnlmcm9tIHNpbmdsZSBMU1Agc2V0dXAgZGVs YXkuDQUNNS4yLiAgTWV0cmljIE5hbWUNDSAgIE11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBMU1Bz IHNldHVwIGRlbGF5DQ01LjMuICBNZXRyaWMgUGFyYW1ldGVycw0NICAgbyAgSUQwLCB0aGUgaW5n cmVzcyBMU1IgSUQNDSAgIG8gIElEMSwgdGhlIGVncmVzcyBMU1IgSUQNDSAgIG8gIExhbWJkYV9t LCBhIHJhdGUgaW4gcmVjaXByb2NhbCBtaWxsaXNlY29uZHMNDSAgIG8gIFgsIHRoZSBudW1iZXIg b2YgTFNQcyB0byBzZXR1cA0NICAgbyAgVCwgYSB0aW1lIHdoZW4gdGhlIGZpcnN0IHNldHVwIGlz IGF0dGVtcHRlZA0NNS40LiAgTWV0cmljIFVuaXRzDQ0gICBUaGUgdmFsdWUgb2YgbXVsdGlwbGUg dW5pLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAgZGVsYXkgaXMgZWl0aGVyIGENICAgcmVhbCBudW1i ZXIsIG9yIGFuIHVuZGVmaW5lZCBudW1iZXIgb2YgbWlsbGlzZWNvbmRzLg0NNS41LiAgRGVmaW5p dGlvbg0NICAgR2l2ZW4gTGFtYmRhX20gYW5kIFgsIHRoZSBtdWx0aXBsZSB1bmktZGlyZWN0aW9u YWwgTFNQcyBzZXR1cCBkZWxheQ0gICBmcm9tIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIGVncmVz cyBub2RlIFtSRkMzOTQ1XSBhdCBUIGlzIGRUIGlzIG1lYW5zZGVmaW5lZCBhczoNDSAgIG8gIGlu Z3Jlc3Mgbm9kZSBJRDAgaGFzIHNlbnRzZW5kcyB0aGUgZmlyc3QgYml0IG9mIHRoZSBmaXJzdCBQ QVRIIG1lc3NhZ2UNICAgICAgcGFja2V0IHRvIGVncmVzcyBub2RlIElEMSBhdCB3aXJlLXRpbWUg VA0NICAgbyAgYWxsIHN1YnNlcXVlbnQgKFgtMSkgUEFUSCBtZXNzYWdlcyBoYXZlIGJlZW4gYXJl IHNlbnQgYWNjb3JkaW5nIHRvIHRoZQ0gICAgICBzcGVjaWZpZWQgUG9pc3NvbiBwcm9jZXNzIHdp dGggYXJyaXZhbCByYXRlIExhbWJkYV9tDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAgIEV4cGly ZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0NDUludGVybmV0LURy YWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAgICAgIEp1bHkg MjAwOQ0NDSAgIG8gIGluZ3Jlc3Mgbm9kZSBJRDAgaGFzIHJlY2VpdmVkcmVjZWl2ZXMgYWxsIGNv cnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlIHBhY2tldHMNICAgICAgZnJvbSBlZ3Jlc3Mgbm9kZSBJ RDEsIGFuZA0NICAgbyAgaW5ncmVzcyBub2RlIElEMCBoYXMgcmVjZWl2ZWRyZWNlaXZlcyB0aGUg bGFzdCBSRVNWIG1lc3NhZ2UgcGFja2V0IGF0IHdpcmUtDSAgICAgIHRpbWUgVCtkVA0NICAgVGhl IG11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBMU1BzIHNldHVwIGRlbGF5IGF0IFQgaXMgdW5kZWZp bmVkLA0gICBpcyBkZWZpbmVkIGFzIHRoZSBldmVudG1lYW5zIHRoYXQgaW5ncmVzcyBub2RlIElE MCBoYXMgc2VudHNlbmRzIGFsbCB0aGUgUEFUSCBtZXNzYWdlcyB0b3dhcmRzIHRoZQ0gICBlZ3Jl c3Mgbm9kZSBJRDEgYW5kIHRoZSBmaXJzdCBiaXQgb2YgdGhlIGZpcnN0IFBBVEggbWVzc2FnZSBw YWNrZXQgaGFzIGJlZW5pcw0gICBzZW50IGF0IHdpcmUtdGltZSBUIGFuZCB0aGF0IGluZ3Jlc3Mg bm9kZSBJRDAgZGlkZG9lcyBub3QgcmVjZWl2ZSB0aGUNICAgb25lIG9yIG1vcmUgb2YgdGhlIGNv cnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlcyB3aXRoaW4gYSByZWFzb25hYmxlDSAgIHBlcmlvZCBv ZiB0aW1lLg0NICAgVGhlIHVuZGVmaW5lZCB2YWx1ZSBvZiB0aGlzIG1ldHJpYyBpbmRpY2F0ZXMg YW4gZXZlbnQgb2YgTXVsdGlwbGUNICAgVW5pLWRpcmVjdGlvbmFsIExTUCBTZXR1cCBGYWlsdXJl LCBhbmQgd291bGQgYmUgdXNlZCB0byByZXBvcnQgYQ0gICBjb3VudCBvciBhbiBwZXJjZW50YWdl IG9mIE11bHRpcGxlIFVuaS1kaXJlY3Rpb25hbCBMU1AgU2V0dXANICAgZmFpbHVyZXMuICBTZWUg c2VjdGlvbiBTZWN0aW9uIDE0LjQgZm9yIGRlZmluaXRpb25zIG9mIExTUCBzZXR1cC8NICAgcmVs ZWFzZSBmYWlsdXJlcy4NDTUuNi4gIERpc2N1c3Npb24FDQ0gICBUaGUgZm9sbG93aW5nIGlzc3Vl cyBhcmUgbGlrZWx5IHRvIGNvbWUgdXAgaW4gcHJhY3RpY2U6DQ0gICBvICBUaGUgYWNjdXJhY3kg b2YgbXVsdGlwbGUgdW5pLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAgZGVsYXkgYXQgdGltZQ0gICAg ICBUIGRlcGVuZHMgb24gdGhlIGNsb2NrIHJlc29sdXRpb24gaW4gdGhlIGluZ3Jlc3Mgbm9kZTsg YnV0DSAgICAgIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBpbmdyZXNzIG5vZGUgYW5kIGVn cmVzcyBub2RlIGlzIG5vdA0gICAgICByZXF1aXJlZCBzaW5jZSB1bmktZGlyZWN0aW9uYWwgTFNQ IHNldHVwIHVzZXMgdHdvLXdheSBzaWduYWxpbmcuDQ0gICBvICBBIGdpdmVuIG1ldGhvZG9sb2d5 IHdpbGwgaGF2ZSB0byBpbmNsdWRlIGEgd2F5IHRvIGRldGVybWluZQ0gICAgICB3aGV0aGVyIGEg bGF0ZW5jeSB2YWx1ZSBpcyBpbmZpbml0ZSBvciB3aGV0aGVyIGl0IGlzIG1lcmVseSB2ZXJ5DSAg ICAgIGxhcmdlLiAgU2ltcGxlIHVwcGVyIGJvdW5kcyBNQVkgYmUgdXNlZC4gIEJ1dCBHTVBMUyBu ZXR3b3JrcyBtYXkNICAgICAgYWNjb21tb2RhdGUgbWFueSBraW5kcyBvZiBkZXZpY2VzLiAgRm9y IGV4YW1wbGUsIHNvbWUgcGhvdG9uaWMNICAgICAgY3Jvc3MtY29ubmVjdHMgKFBYQ3MpIGhhdmUg dG8gbW92ZSBtaWNybyBtaXJyb3JzLiAgVGhpcyBwaHlzaWNhbA0gICAgICBtb3Rpb24gbWF5IHRh a2Ugc2V2ZXJhbCBtaWxsaXNlY29uZHMuICBCdXQgZWxlY3Ryb25pYyBzd2l0Y2hlcyBjYW4NICAg ICAgZmluaXNoIHRoZSBub2RhbCBwcm9jZXNzaW5nIHdpdGhpbiBzZXZlcmFsIG1pY3Jvc2Vjb25k cy4gIFNvIHRoZQ0gICAgICBtdWx0aXBsZSB1bmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5 IHZhcmllcyBkcmFzdGljYWxseSBmcm9tDSAgICAgIG9uZSBuZXR3b3JrIHRvIGFub3RoZXIuICBJ biBwcmFjdGljZSwgdGhlIHVwcGVyIGJvdW5kIHNob3VsZCBiZQ0gICAgICBjaG9zZW4gY2FyZWZ1 bGx5IGFuZCB0aGUgdmFsdWUgTVVTVCBiZSByZXBvcnRlZC4NDSAgIG8gIElmIGluZ3Jlc3Mgbm9k ZSBzZW5kcyBvdXQgdGhlIG11bHRpcGxlIFBBVEggbWVzc2FnZXMgdG8gc2V0IHVwIHRoZQ0gICAg ICBMU1BzLCBidXQgbmV2ZXIgcmVjZWl2ZXMgb25lIG9yIG1vcmUgb2YgdGhlIGNvcnJlc3BvbmRp bmcgUkVTVg0gICAgICBtZXNzYWdlcywgbXVsdGlwbGUgdW5pLWRpcmVjdGlvbmFsIExTUCBzZXR1 cCBkZWxheSBNVVNUIGJlIHNldCB0bw0gICAgICB1bmRlZmluZWQuDQ0gICBvICBJZiBpbmdyZXNz IG5vZGUgc2VuZHMgb3V0IHRoZSBQQVRIIG1lc3NhZ2VzIHRvIHNldCB1cCB0aGUgTFNQcyBidXQN ICAgICAgcmVjZWl2ZXMgb25lIG9yIG1vcmUgUGF0aEVyciBtZXNzYWdlcywgbXVsdGlwbGUgdW5p LWRpcmVjdGlvbmFsDSAgICAgIExTUHMgc2V0dXAgZGVsYXkgTVVTVCBiZSBzZXQgdG8gdW5kZWZp bmVkLiAgVGhlcmUgYXJlIG1hbnkNICAgICAgcG9zc2libGUgcmVhc29ucyBmb3IgdGhpcyBjYXNl LiAgRm9yIGV4YW1wbGUsIG9uZSBvZiB0aGUgUEFUSA0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAxNF0NDQ1JbnRl cm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAg ICBKdWx5IDIwMDkNDQ0gICAgICBtZXNzYWdlcyBoYXMgaW52YWxpZCBwYXJhbWV0ZXJzIG9yIHRo ZSBuZXR3b3JrIGhhcyBub3QgZW5vdWdoDSAgICAgIHJlc291cmNlIHRvIHNldCB1cCB0aGUgcmVx dWVzdGVkIExTUHMsIGV0Yy4NDSAgIG8gIFRoZSBhcnJpdmFsIHJhdGUgb2YgdGhlIFBvaXNzb24g cHJvY2VzcyBMYW1iZGFfbSBzaG91bGQgYmUgY2hvc2VuDSAgICAgIGNhcmVmdWxseSBzdWNoIHRo YXQgaW4gdGhlIG9uZSBoYW5kIHRoZSBjb250cm9sIHBsYW5lIGlzIG5vdA0gICAgICBvdmVyYnVy ZGVuZWQuICBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIGFycml2YWwgcmF0ZSBpcyBsYXJnZSBlbm91 Z2gNICAgICAgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIGFwcGxpY2F0aW9ucyBvciBzZXJ2 aWNlcy4NDTUuNy4gIE1ldGhvZG9sb2dpZXMNDSAgIEdlbmVyYWxseSB0aGUgbWV0aG9kb2xvZ3kg d291bGQgcHJvY2VlZCBhcyBmb2xsb3dzOg0NICAgbyAgTWFrZSBzdXJlIHRoYXQgdGhlIG5ldHdv cmsgaGFzIGVub3VnaCByZXNvdXJjZSB0byBzZXQgdXAgdGhlDSAgICAgIHJlcXVlc3RlZCBMU1Bz Lg0NICAgbyAgQXQgdGhlIGluZ3Jlc3Mgbm9kZSwgZm9ybSB0aGUgUEFUSCBtZXNzYWdlcyBhY2Nv cmRpbmcgdG8gdGhlIExTUHMnDSAgICAgIHJlcXVpcmVtZW50cy4NDSAgIG8gIEF0IHRoZSBpbmdy ZXNzIG5vZGUsIHNlbGVjdCB0aGUgdGltZSBmb3IgZWFjaCBvZiB0aGUgUEFUSCBtZXNzYWdlcw0g ICAgICBhY2NvcmRpbmcgdG8gdGhlIHNwZWNpZmllZCBQb2lzc29uIHByb2Nlc3MuDQ0gICBvICBB dCB0aGUgaW5ncmVzcyBub2RlLCBzZW5kIG91dCB0aGUgUEFUSCBtZXNzYWdlcyBhY2NvcmRpbmcg dG8gdGhlDSAgICAgIHNlbGVjdGVkIHRpbWUuDQ0gICBvICBTdG9yZSBhIHRpbWVzdGFtcCAoVDEp IGxvY2FsbHkgb24gdGhlIGluZ3Jlc3Mgbm9kZSB3aGVuIHRoZSBmaXJzdA0gICAgICBQQVRIIG1l c3NhZ2UgcGFja2V0IGlzIHNlbnQgdG93YXJkcyB0aGUgZWdyZXNzIG5vZGUuDQ0gICBvICBJZiBh bGwgb2YgdGhlIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlcyBhcnJpdmUgd2l0aGluIGENICAg ICAgcmVhc29uYWJsZSBwZXJpb2Qgb2YgdGltZSwgdGFrZSB0aGUgZmluYWwgdGltZXN0YW1wIChU MikgYXMgc29vbg0gICAgICBhcyBwb3NzaWJsZSB1cG9uIHRoZSByZWNlaXB0IG9mIGFsbCB0aGUg bWVzc2FnZXMuICBCeSBzdWJ0cmFjdGluZw0gICAgICB0aGUgdHdvIHRpbWVzdGFtcHMsIGFuIGVz dGltYXRlIG9mIG11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBMU1BzDSAgICAgIHNldHVwIGRlbGF5 IChUMiAtVDEpIGNhbiBiZSBjb21wdXRlZC4NDSAgIG8gIElmIG9uZSBvciBtb3JlIG9mIHRoZSBj b3JyZXNwb25kaW5nIFJFU1YgbWVzc2FnZXMgZmFpbCB0byBhcnJpdmUNICAgICAgd2l0aGluIGEg cmVhc29uYWJsZSBwZXJpb2Qgb2YgdGltZSwgdGhlIG11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbA0g ICAgICBMU1BzIHNldHVwIGRlbGF5IGlzIGRlZW1lZCB0byBiZSB1bmRlZmluZWQuICBOb3RlIHRo YXQgdGhlDSAgICAgICdyZWFzb25hYmxlJyB0aHJlc2hvbGQgaXMgYSBwYXJhbWV0ZXIgb2YgdGhl IG1ldGhvZG9sb2d5Lg0NICAgbyAgSWYgb25lIG9yIG1vcmUgb2YgdGhlIGNvcnJlc3BvbmRpbmcg cmVzcG9uc2UgbWVzc2FnZXMgYXJlIFBhdGhFcnIsDSAgICAgIHRoZSBtdWx0aXBsZSB1bmktZGly ZWN0aW9uYWwgTFNQcyBzZXR1cCBkZWxheSBpcyBkZWVtZWQgdG8gYmUNICAgICAgdW5kZWZpbmVk Lg0NDQ0NDQ0NDQ0NU3VuICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAy MDEwICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHlu YW1pYyBQUE0gaW4gR01QTFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NNi4gIEEgU2lu Z2xldG9uIERlZmluaXRpb24gZm9yIFNpbmdsZSBCaS1kaXJlY3Rpb25hbCAgTFNQIFNldHVwIERl bGF5BQ0NICAgR01QTFMgYWxsb3dzIGVzdGFibGlzaG1lbnQgb2YgYmktZGlyZWN0aW9uYWwgc3lt bWV0cmljIExTUHMgKG5vdCBvZg0gICBhc3ltbWV0cmljIExTUHMpLiAgVGhpcyBwYXJ0IGRlZmlu ZXMgYSBtZXRyaWMgZm9yIHNpbmdsZSBiaS0NICAgZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5 IGFjcm9zcyBhIEdNUExTIG5ldHdvcmsuDQ02LjEuICBNb3RpdmF0aW9uDQ0gICBTaW5nbGUgYmkt ZGlyZWN0aW9uYWwgTGFiZWwgU3dpdGNoZWQgUGF0aCBzZXR1cCBkZWxheSBpcyB1c2VmdWwgZm9y DSAgIHNldmVyYWwgcmVhc29uczoNDSAgIG8gIExTUCBzZXR1cCBkZWxheSBpcyBhbiBpbXBvcnRh bnQgbWV0cmljIHRoYXQgZGVwaWN0cyB0aGUNICAgICAgcHJvdmlzaW9uaW5nIHBlcmZvcm1hbmNl IG9mIGEgR01QTFMgbmV0d29yay4gIExvbmdlciBMU1Agc2V0dXANICAgICAgZGVsYXkgd2lsbCBp bmN1ciBoaWdoZXIgb3ZlcmhlYWQgZm9yIHRoZSByZXF1ZXN0aW5nIGFwcGxpY2F0aW9uLA0gICAg ICBlc3BlY2lhbGx5IHdoZW4gdGhlIExTUCBkdXJhdGlvbiBpcyBjb21wYXJhYmxlIHRvIHRoZSBM U1Agc2V0dXANICAgICAgZGVsYXkuICBUaHVzLCBtZWFzdXJpbmcgdGhlIHNldHVwIGRlbGF5IGlz IGltcG9ydGFudCBmb3INICAgICAgYXBwbGljYXRpb24gc2NoZWR1bGluZy4NDSAgIG8gIFRoZSBt aW5pbXVtIHZhbHVlIG9mIHRoaXMgbWV0cmljIHByb3ZpZGVzIGFuIGluZGljYXRpb24gb2YgdGhl DSAgICAgIGRlbGF5IHRoYXQgd2lsbCBsaWtlbHkgYmUgZXhwZXJpZW5jZWQgd2hlbiB0aGUgTFNQ IHRyYXZlcnNlZCB0aGUNICAgICAgc2hvcnRlc3Qgcm91dGUgYXQgdGhlIGxpZ2h0ZXN0IGxvYWQg aW4gdGhlIGNvbnRyb2wgcGxhbmUuICBBcyB0aGUNICAgICAgZGVsYXkgaXRzZWxmIGNvbnNpc3Rz IG9mIHNldmVyYWwgY29tcG9uZW50cywgc3VjaCBhcyBsaW5rDSAgICAgIHByb3BhZ2F0aW9uIGRl bGF5IGFuZCBub2RhbCBwcm9jZXNzaW5nIGRlbGF5LCB0aGlzIG1ldHJpYyBhbHNvDSAgICAgIHJl ZmxlY3RzIHRoZSBzdGF0dXMgb2YgY29udHJvbCBwbGFuZS4gIEZvciBleGFtcGxlLCBmb3IgTFNQ cw0gICAgICB0cmF2ZXJzaW5nIHRoZSBzYW1lIHJvdXRlLCBsb25nZXIgc2V0dXAgZGVsYXlzIG1h eSBzdWdnZXN0DSAgICAgIGNvbmdlc3Rpb24gaW4gdGhlIGNvbnRyb2wgY2hhbm5lbCBvciBoaWdo IGNvbnRyb2wgZWxlbWVudCBsb2FkLg0gICAgICBGb3IgdGhpcyByZWFzb24sIHRoaXMgbWV0cmlj IGlzIHVzZWZ1bCBmb3IgdGVzdGluZyBhbmQgZGlhZ25vc3RpYw0gICAgICBwdXJwb3Nlcy4NDSAg IG8gIExTUCBzZXR1cCBkZWxheSB2YXJpYW5jZSBoYXMgZGlmZmVyZW50IGltcGFjdCBvbiBhcHBs aWNhdGlvbnMuDSAgICAgIEVycmF0aWMgdmFyaWF0aW9uIGluIExTUCBzZXR1cCBkZWxheSBtYWtl cyBpdCBkaWZmaWN1bHQgdG8gc3VwcG9ydA0gICAgICBhcHBsaWNhdGlvbnMgdGhhdCBoYXZlIHN0 cmluZ2VudCBzZXR1cCBkZWxheSByZXF1aXJlbWVudC4NDSAgIFRoZSBtZWFzdXJlbWVudCBvZiBz aW5nbGUgYmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5IGluc3RlYWQgb2YNICAgdW5pLWRp cmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBpcyBtb3RpdmF0ZWQgYnkgdGhlIGZvbGxvd2luZw0g ICBmYWN0b3JzOg0NICAgbyAgQmktZGlyZWN0aW9uYWwgTFNQcyBhcmUgc2VlbiBhcyBhIHJlcXVp cmVtZW50IGZvciBtYW55IEdNUExTDSAgICAgIG5ldHdvcmtzLiAgSXRzIHByb3Zpc2lvbmluZyBw ZXJmb3JtYW5jZSBpcyBpbXBvcnRhbnQgdG8NICAgICAgYXBwbGljYXRpb25zIHRoYXQgZ2VuZXJh dGUgYmktZGlyZWN0aW9uYWwgdHJhZmZpYy4NDTYuMi4gIE1ldHJpYyBOYW1lDQ0gICBTaW5nbGUg YmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5DQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAxNl0NDQ1J bnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAg ICAgICBKdWx5IDIwMDkNDQ02LjMuICBNZXRyaWMgUGFyYW1ldGVycw0NICAgbyAgSUQwLCB0aGUg aW5ncmVzcyBMU1IgSUQNDSAgIG8gIElEMSwgdGhlIGVncmVzcyBMU1IgSUQNDSAgIG8gIFQsIGEg dGltZSB3aGVuIHRoZSBzZXR1cCBpcyBhdHRlbXB0ZWQNDTYuNC4gIE1ldHJpYyBVbml0cw0NICAg VGhlIHZhbHVlIG9mIHNpbmdsZSBiaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgaXMgZWl0 aGVyIGEgcmVhbA0gICBudW1iZXIsIG9yIGFuIHVuZGVmaW5lZCBudW1iZXIgb2YgbWlsbGlzZWNv bmRzLg0NNi41LiAgRGVmaW5pdGlvbg0NICAgRm9yIGEgcmVhbCBudW1iZXIgZFQsIHRoZSBzaW5n bGUgYmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5IGZyb20NICAgaW5ncmVzcyBub2RlIElE MCB0byBlZ3Jlc3Mgbm9kZSBJRDEgYXQgVCBpcyBkVCwgbWVhbnMgdGhhdCBpbmdyZXNzDSAgIG5v ZGUgSUQwIHNlbmRzIG91dCB0aGUgZmlyc3QgYml0IG9mIGEgUEFUSCBtZXNzYWdlIGluY2x1ZGlu ZyBhbg0gICBVcHN0cmVhbSBMYWJlbCBbUkZDMzQ3M10gaGVhZGluZyBmb3IgZWdyZXNzIG5vZGUg SUQxIGF0IHdpcmUtdGltZSBULA0gICBlZ3Jlc3Mgbm9kZSBJRDEgcmVjZWl2ZXMgdGhhdCBwYWNr ZXQsIHRoZW4gaW1tZWRpYXRlbHkgc2VuZHMgYSBSRVNWDSAgIG1lc3NhZ2UgcGFja2V0IGJhY2sg dG8gaW5ncmVzcyBub2RlIElEMCwgYW5kIHRoYXQgaW5ncmVzcyBub2RlIElEMA0gICByZWNlaXZl cyB0aGUgbGFzdCBiaXQgb2YgdGhlIFJFU1YgbWVzc2FnZSBwYWNrZXQgYXQgd2lyZS10aW1lIFQr ZFQuDQ0gICBUaGUgc2luZ2xlIGJpLWRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBmcm9tIGlu Z3Jlc3Mgbm9kZSBJRDAgdG8NICAgZWdyZXNzIG5vZGUgSUQxIGF0IFQgaXMgdW5kZWZpbmVkLCBt ZWFucyB0aGF0IGluZ3Jlc3Mgbm9kZSBJRDAgc2VuZHMNICAgdGhlIGZpcnN0IGJpdCBvZiBQQVRI IG1lc3NhZ2UgdG8gZWdyZXNzIG5vZGUgSUQxIGF0IHdpcmUtdGltZSBUIGFuZA0gICB0aGF0IGlu Z3Jlc3Mgbm9kZSBJRDAgZG9lcyBub3QgcmVjZWl2ZSB0aGF0IHJlc3BvbnNlIHBhY2tldCB3aXRo aW4gYQ0gICByZWFzb25hYmxlIHBlcmlvZCBvZiB0aW1lLg0NICAgVGhlIHVuZGVmaW5lZCB2YWx1 ZSBvZiB0aGlzIG1ldHJpYyBpbmRpY2F0ZXMgYW4gZXZlbnQgb2YgU2luZ2xlIEJpLQ0gICBkaXJl Y3Rpb25hbCBMU1AgU2V0dXAgRmFpbHVyZSwgYW5kIHdvdWxkIGJlIHVzZWQgdG8gcmVwb3J0IGEg Y291bnQgb3INICAgYW4gcGVyY2VudGFnZSBvZiBTaW5nbGUgQmktZGlyZWN0aW9uYWwgTFNQIFNl dHVwIGZhaWx1cmVzLiAgU2VlDSAgIHNlY3Rpb24gU2VjdGlvbiAxNC40IGZvciBkZWZpbml0aW9u cyBvZiBMU1Agc2V0dXAvcmVsZWFzZSBmYWlsdXJlcy4NDTYuNi4gIERpc2N1c3Npb24NDSAgIFRo ZSBmb2xsb3dpbmcgaXNzdWVzIGFyZSBsaWtlbHkgdG8gY29tZSB1cCBpbiBwcmFjdGljZToNDSAg IG8gIFRoZSBhY2N1cmFjeSBvZiBzaW5nbGUgYmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5 IGRlcGVuZHMgb24NICAgICAgdGhlIGNsb2NrIHJlc29sdXRpb24gaW4gdGhlIGluZ3Jlc3Mgbm9k ZTsgYnV0IHN5bmNocm9uaXphdGlvbg0gICAgICBiZXR3ZWVuIHRoZSBpbmdyZXNzIG5vZGUgYW5k IGVncmVzcyBub2RlIGlzIG5vdCByZXF1aXJlZCBzaW5jZQ0gICAgICBzaW5nbGUgYmktZGlyZWN0 aW9uYWwgTFNQIHNldHVwIHVzZXMgdHdvLXdheSBzaWduYWxpbmcuDQ0gICBvICBBIGdpdmVuIG1l dGhvZG9sb2d5IHdpbGwgaGF2ZSB0byBpbmNsdWRlIGEgd2F5IHRvIGRldGVybWluZQ0gICAgICB3 aGV0aGVyIGEgbGF0ZW5jeSB2YWx1ZSBpcyBpbmZpbml0ZSBvciB3aGV0aGVyIGl0IGlzIG1lcmVs eSB2ZXJ5DSAgICAgIGxhcmdlLiAgU2ltcGxlIHVwcGVyIGJvdW5kcyBNQVkgYmUgdXNlZC4gIEJ1 dCBHTVBMUyBuZXR3b3JrcyBtYXkNICAgICAgYWNjb21tb2RhdGUgbWFueSBraW5kcyBvZiBkZXZp Y2VzLiAgRm9yIGV4YW1wbGUsIHNvbWUgcGhvdG9uaWMNICAgICAgY3Jvc3MtY29ubmVjdHMgKFBY Q3MpIGhhdmUgdG8gbW92ZSBtaWNybyBtaXJyb3JzLiAgVGhpcyBwaHlzaWNhbA0NDQ1TdW4gJiBa aGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBb UGFnZSAxN10NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBO ZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0gICAgICBtb3Rpb24gbWF5IHRha2Ugc2V2ZXJh bCBtaWxsaXNlY29uZHMuICBCdXQgZWxlY3Ryb25pYyBzd2l0Y2hlcyBjYW4NICAgICAgZmluaXNo IHRoZSBub2RhbCBwcm9jZXNzaW5nIHdpdGhpbiBzZXZlcmFsIG1pY3Jvc2Vjb25kcy4gIFNvIHRo ZQ0gICAgICBiaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgdmFyaWVzIGRyYXN0aWNhbGx5 IGZyb20gb25lIG5ldHdvcmsNICAgICAgdG8gYW5vdGhlci4gIEluIHRoZSBwcm9jZXNzIG9mIGJp LWRpcmVjdGlvbmFsIExTUCBzZXR1cCwgaWYgdGhlDSAgICAgIGRvd25zdHJlYW0gbm9kZSBvdmVy cmlkZXMgdGhlIGxhYmVsIHN1Z2dlc3RlZCBieSB0aGUgdXBzdHJlYW0NICAgICAgbm9kZSwgdGhl IHNldHVwIGRlbGF5IG1heSBhbHNvIGluY3JlYXNlLiAgVGh1cywgaW4gcHJhY3RpY2UsIHRoZQ0g ICAgICB1cHBlciBib3VuZCBzaG91bGQgYmUgY2hvc2VuIGNhcmVmdWxseSBhbmQgdGhlIHZhbHVl IE1VU1QgYmUNICAgICAgcmVwb3J0ZWQuDQ0gICBvICBJZiB0aGUgaW5ncmVzcyBub2RlIHNlbmRz IG91dCB0aGUgUEFUSCBtZXNzYWdlIHRvIHNldCB1cCB0aGUgTFNQLA0gICAgICBidXQgbmV2ZXIg cmVjZWl2ZXMgdGhlIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlLCBzaW5nbGUgYmktDSAgICAg IGRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBNVVNUIGJlIHNldCB0byB1bmRlZmluZWQuDQ0g ICBvICBJZiB0aGUgaW5ncmVzcyBub2RlIHNlbmRzIG91dCB0aGUgUEFUSCBtZXNzYWdlIHRvIHNl dCB1cCB0aGUgTFNQLA0gICAgICBidXQgcmVjZWl2ZXMgUGF0aEVyciBtZXNzYWdlLCBzaW5nbGUg YmktZGlyZWN0aW9uYWwgTFNQIHNldHVwDSAgICAgIGRlbGF5IE1VU1QgYmUgc2V0IHRvIHVuZGVm aW5lZC4gIFRoZXJlIGFyZSBtYW55IHBvc3NpYmxlIHJlYXNvbnMNICAgICAgZm9yIHRoaXMgY2Fz ZS4gIEZvciBleGFtcGxlLCB0aGUgUEFUSCBtZXNzYWdlIGhhcyBpbnZhbGlkDSAgICAgIHBhcmFt ZXRlcnMgb3IgdGhlIG5ldHdvcmsgaGFzIG5vdCBlbm91Z2ggcmVzb3VyY2UgdG8gc2V0IHVwIHRo ZQ0gICAgICByZXF1ZXN0ZWQgTFNQLg0NNi43LiAgTWV0aG9kb2xvZ2llcw0NICAgR2VuZXJhbGx5 IHRoZSBtZXRob2RvbG9neSB3b3VsZCBwcm9jZWVkIGFzIGZvbGxvd3M6DQ0gICBvICBNYWtlIHN1 cmUgdGhhdCB0aGUgbmV0d29yayBoYXMgZW5vdWdoIHJlc291cmNlIHRvIHNldCB1cCB0aGUNICAg ICAgcmVxdWVzdGVkIExTUC4NDSAgIG8gIEF0IHRoZSBpbmdyZXNzIG5vZGUsIGZvcm0gdGhlIFBB VEggbWVzc2FnZSAoaW5jbHVkaW5nIHRoZSBVcHN0cmVhbQ0gICAgICBMYWJlbCBvciBzdWdnZXN0 ZWQgbGFiZWwpIGFjY29yZGluZyB0byB0aGUgTFNQIHJlcXVpcmVtZW50cy4gIEENICAgICAgdGlt ZXN0YW1wIChUMSkgbWF5IGJlIHN0b3JlZCBsb2NhbGx5IG9uIHRoZSBpbmdyZXNzIG5vZGUgd2hl biB0aGUNICAgICAgUEFUSCBtZXNzYWdlIHBhY2tldCBpcyBzZW50IHRvd2FyZHMgdGhlIGVncmVz cyBub2RlLg0NICAgbyAgSWYgdGhlIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlIGFycml2ZXMg d2l0aGluIGEgcmVhc29uYWJsZQ0gICAgICBwZXJpb2Qgb2YgdGltZSwgdGFrZSB0aGUgZmluYWwg dGltZXN0YW1wIChUMikgYXMgc29vbiBhcyBwb3NzaWJsZQ0gICAgICB1cG9uIHRoZSByZWNlaXB0 IG9mIHRoZSBtZXNzYWdlLiAgQnkgc3VidHJhY3RpbmcgdGhlIHR3bw0gICAgICB0aW1lc3RhbXBz LCBhbiBlc3RpbWF0ZSBvZiBiaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgKFQyIC1UMSkN ICAgICAgY2FuIGJlIGNvbXB1dGVkLg0NICAgbyAgSWYgdGhlIGNvcnJlc3BvbmRpbmcgUkVTViBt ZXNzYWdlIGZhaWxzIHRvIGFycml2ZSB3aXRoaW4gYQ0gICAgICByZWFzb25hYmxlIHBlcmlvZCBv ZiB0aW1lLCB0aGUgc2luZ2xlIGJpLWRpcmVjdGlvbmFsIExTUCBzZXR1cA0gICAgICBkZWxheSBp cyBkZWVtZWQgdG8gYmUgdW5kZWZpbmVkLiAgTm90ZSB0aGF0IHRoZSAncmVhc29uYWJsZScNICAg ICAgdGhyZXNob2xkIGlzIGEgcGFyYW1ldGVyIG9mIHRoZSBtZXRob2RvbG9neS4NDSAgIG8gIElm IHRoZSBjb3JyZXNwb25kaW5nIHJlc3BvbnNlIG1lc3NhZ2UgaXMgUGF0aEVyciwgdGhlIHNpbmds ZSBiaS0NICAgICAgZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5IGlzIGRlZW1lZCB0byBiZSB1 bmRlZmluZWQuDQ0NDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAx MCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0NDUludGVybmV0LURyYWZ0ICAgICAgTFNQ IER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0NDTcuICBB IFNpbmdsZXRvbiBEZWZpbml0aW9uIGZvciBtdWx0aXBsZSBCaS1kaXJlY3Rpb25hbCAgTFNQcyBT ZXR1cCBEZWxheQ0NICAgVGhpcyBwYXJ0IGRlZmluZXMgYSBtZXRyaWMgZm9yIG11bHRpcGxlIGJp LWRpcmVjdGlvbmFsIExTUHMgc2V0dXANICAgZGVsYXkgYWNyb3NzIGEgR01QTFMgbmV0d29yay4N DTcuMS4gIE1vdGl2YXRpb24NDSAgIG11bHRpcGxlIGJpLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAg ZGVsYXkgaXMgdXNlZnVsIGZvciBzZXZlcmFsDSAgIHJlYXNvbnM6DQ0gICBvICBVcG9uIHRyYWZm aWMgaW50ZXJydXB0aW9uIGNhdXNlZCBieSBuZXR3b3JrIGZhaWx1cmUgb3IgbmV0d29yaw0gICAg ICB1cGdyYWRlLCBjYXJyaWVycyBtYXkgcmVxdWlyZSBhIGxhcmdlIG51bWJlciBvZiBMU1BzIGJl IHNldCB1cA0gICAgICBkdXJpbmcgYSBzaG9ydCB0aW1lIHBlcmlvZA0NICAgbyAgVGhlIHRpbWUg bmVlZGVkIHRvIHNldHVwIGEgbGFyZ2UgbnVtYmVyIG9mIExTUHMgZHVyaW5nIGEgc2hvcnQNICAg ICAgdGltZSBwZXJpb2QgY2FuIG5vdCBiZSBkZWR1Y2VkIGJ5IHNpbmdsZSBMU1Agc2V0dXAgZGVs YXkNDTcuMi4gIE1ldHJpYyBOYW1lDQ0gICBNdWx0aXBsZSBiaS1kaXJlY3Rpb25hbCBMU1BzIHNl dHVwIGRlbGF5DQ03LjMuICBNZXRyaWMgUGFyYW1ldGVycw0NICAgbyAgSUQwLCB0aGUgaW5ncmVz cyBMU1IgSUQNDSAgIG8gIElEMSwgdGhlIGVncmVzcyBMU1IgSUQNDSAgIG8gIExhbWJkYV9tLCBh IHJhdGUgaW4gcmVjaXByb2NhbCBtaWxsaXNlY29uZHMNDSAgIG8gIFgsIHRoZSBudW1iZXIgb2Yg TFNQcyB0byBzZXR1cA0NICAgbyAgVCwgYSB0aW1lIHdoZW4gdGhlIGZpcnN0IHNldHVwIGlzIGF0 dGVtcHRlZA0NNy40LiAgTWV0cmljIFVuaXRzDQ0gICBUaGUgdmFsdWUgb2YgbXVsdGlwbGUgYmkt ZGlyZWN0aW9uYWwgTFNQcyBzZXR1cCBkZWxheSBpcyBlaXRoZXIgYQ0gICByZWFsIG51bWJlciwg b3IgYW4gdW5kZWZpbmVkIG51bWJlciBvZiBtaWxsaXNlY29uZHMuDQ03LjUuICBEZWZpbml0aW9u DQ0gICBHaXZlbiBMYW1iZGFfbSBhbmQgWCwgZm9yIGEgcmVhbCBudW1iZXIgZFQsIHRoZSBtdWx0 aXBsZSBiaS0NICAgZGlyZWN0aW9uYWwgTFNQcyBzZXR1cCBkZWxheSBmcm9tIGluZ3Jlc3Mgbm9k ZSB0byBlZ3Jlc3Mgbm9kZSBhdCBUIGlzDSAgIGRULCBtZWFucyB0aGF0Og0NICAgbyAgaW5ncmVz cyBub2RlIElEMCBzZW5kcyB0aGUgZmlyc3QgYml0IG9mIHRoZSBmaXJzdCBQQVRIIG1lc3NhZ2UN ICAgICAgaGVhZGluZyBmb3IgZWdyZXNzIG5vZGUgSUQxIGF0IHdpcmUtdGltZSBUDQ0NDQ0NU3Vu ICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAg ICAgW1BhZ2UgMTldDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01Q TFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NICAgbyAgYWxsIHN1YnNlcXVlbnQgKFgt MSkgUEFUSCBtZXNzYWdlcyBhcmUgc2VudCBhY2NvcmRpbmcgdG8gdGhlDSAgICAgIHNwZWNpZmll ZCBQb2lzc29uIHByb2Nlc3Mgd2l0aCBhcnJpdmFsIHJhdGUgTGFtYmRhX20NDSAgIG8gIGluZ3Jl c3Mgbm9kZSBJRDEgcmVjZWl2ZXMgYWxsIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlIHBhY2tl dHMNICAgICAgZnJvbSBlZ3Jlc3Mgbm9kZSBJRDEsIGFuZA0NICAgbyAgaW5ncmVzcyBub2RlIElE MCByZWNlaXZlcyB0aGUgbGFzdCBSRVNWIG1lc3NhZ2UgcGFja2V0IGF0IHdpcmUtDSAgICAgIHRp bWUgVCtkVA0NICAgVGhlIG11bHRpcGxlIGJpLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAgZGVsYXkg ZnJvbSBpbmdyZXNzIG5vZGUgdG8NICAgZWdyZXNzIG5vZGUgYXQgVCBpcyB1bmRlZmluZWQsIG1l YW5zIHRoYXQgaW5ncmVzcyBub2RlIHNlbmRzIGFsbCB0aGUNICAgUEFUSCBtZXNzYWdlcyB0byBl Z3Jlc3Mgbm9kZSBhbmQgdGhhdCB0aGUgaW5ncmVzcyBub2RlIGZhaWxzIHRvDSAgIHJlY2VpdmUg b25lIG9yIG1vcmUgb2YgdGhlIHJlc3BvbnNlIFJFU1YgbWVzc2FnZXMgd2l0aGluIGEgcmVhc29u YWJsZQ0gICBwZXJpb2Qgb2YgdGltZS4NDSAgIFRoZSB1bmRlZmluZWQgdmFsdWUgb2YgdGhpcyBt ZXRyaWMgaW5kaWNhdGVzIGFuIGV2ZW50IG9mIE11bHRpcGxlIEJpLQ0gICBkaXJlY3Rpb25hbCBM U1AgU2V0dXAgRmFpbHVyZSwgYW5kIHdvdWxkIGJlIHVzZWQgdG8gcmVwb3J0IGEgY291bnQgb3IN ICAgYW4gcGVyY2VudGFnZSBvZiBNdWx0aXBsZSBCaS1kaXJlY3Rpb25hbCBMU1AgU2V0dXAgZmFp bHVyZXMuICBTZWUNICAgc2VjdGlvbiBTZWN0aW9uIDE0LjQgZm9yIGRlZmluaXRpb25zIG9mIExT UCBzZXR1cC9yZWxlYXNlIGZhaWx1cmVzLg0NNy42LiAgRGlzY3Vzc2lvbg0NICAgVGhlIGZvbGxv d2luZyBpc3N1ZXMgYXJlIGxpa2VseSB0byBjb21lIHVwIGluIHByYWN0aWNlOg0NICAgbyAgVGhl IGFjY3VyYWN5IG9mIG11bHRpcGxlIGJpLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAgZGVsYXkgZGVw ZW5kcw0gICAgICBvbiB0aGUgY2xvY2sgcmVzb2x1dGlvbiBpbiB0aGUgaW5ncmVzcyBub2RlOyBi dXQgc3luY2hyb25pemF0aW9uDSAgICAgIGJldHdlZW4gdGhlIGluZ3Jlc3Mgbm9kZSBhbmQgZWdy ZXNzIG5vZGUgaXMgbm90IHJlcXVpcmVkIHNpbmNlIGJpLQ0gICAgICBkaXJlY3Rpb25hbCBMU1Ag c2V0dXAgdXNlcyB0d28td2F5IHNpZ25hbGluZy4NDSAgIG8gIEEgZ2l2ZW4gbWV0aG9kb2xvZ3kg d2lsbCBoYXZlIHRvIGluY2x1ZGUgYSB3YXkgdG8gZGV0ZXJtaW5lDSAgICAgIHdoZXRoZXIgYSBs YXRlbmN5IHZhbHVlIGlzIGluZmluaXRlIG9yIHdoZXRoZXIgaXQgaXMgbWVyZWx5IHZlcnkNICAg ICAgbGFyZ2UuICBTaW1wbGUgdXBwZXIgYm91bmRzIE1BWSBiZSB1c2VkLiAgQnV0IEdNUExTIG5l dHdvcmtzIG1heQ0gICAgICBhY2NvbW1vZGF0ZSBtYW55IGtpbmRzIG9mIGRldmljZXMuICBGb3Ig ZXhhbXBsZSwgc29tZSBwaG90b25pYw0gICAgICBjcm9zcy1jb25uZWN0cyAoUFhDcykgaGF2ZSB0 byBtb3ZlIG1pY3JvIG1pcnJvcnMuICBUaGlzIHBoeXNpY2FsDSAgICAgIG1vdGlvbiBtYXkgdGFr ZSBzZXZlcmFsIG1pbGxpc2Vjb25kcy4gIEJ1dCBlbGVjdHJvbmljIHN3aXRjaGVzIGNhbg0gICAg ICBmaW5pc2ggdGhlIG5vZGFsIHByb2Nlc3Mgd2l0aGluIHNldmVyYWwgbWljcm9zZWNvbmRzLiAg U28gdGhlDSAgICAgIG11bHRpcGxlIGJpLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAgZGVsYXkgdmFy aWVzIGRyYXN0aWNhbGx5IGZyb20gYQ0gICAgICBuZXR3b3JrIHRvIGFub3RoZXIuICBJbiB0aGUg cHJvY2VzcyBvZiBtdWx0aXBsZSBiaS1kaXJlY3Rpb25hbA0gICAgICBMU1BzIHNldHVwLCBpZiB0 aGUgZG93bnN0cmVhbSBub2RlIG92ZXJyaWRlcyB0aGUgbGFiZWwgc3VnZ2VzdGVkDSAgICAgIGJ5 IHRoZSB1cHN0cmVhbSBub2RlLCB0aGUgc2V0dXAgZGVsYXkgbWF5IGFsc28gaW5jcmVhc2UuICBU aHVzLCBpbg0gICAgICBwcmFjdGljZSwgdGhlIHVwcGVyIGJvdW5kIHNob3VsZCBiZSBjaG9zZW4g Y2FyZWZ1bGx5IGFuZCB0aGUgdmFsdWUNICAgICAgTVVTVCBiZSByZXBvcnRlZC4NDSAgIG8gIElm IHRoZSBpbmdyZXNzIG5vZGUgc2VuZHMgb3V0IHRoZSBQQVRIIG1lc3NhZ2VzIHRvIHNldCB1cCB0 aGUNICAgICAgTFNQcywgYnV0IG5ldmVyIHJlY2VpdmVzIGFsbCB0aGUgY29ycmVzcG9uZGluZyBS RVNWIG1lc3NhZ2VzLCB0aGUNICAgICAgbXVsdGlwbGUgYmktZGlyZWN0aW9uYWwgTFNQcyBzZXR1 cCBkZWxheSBNVVNUIGJlIHNldCB0byB1bmRlZmluZWQuDQ0NDQ0NU3VuICYgWmhhbmcgICAgICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQ0N SW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMgTmV0d29ya3MgICAg ICAgICAgSnVseSAyMDA5DQ0NICAgbyAgSWYgdGhlIGluZ3Jlc3Mgbm9kZSBzZW5kcyBvdXQgdGhl IFBBVEggbWVzc2FnZXMgdG8gc2V0IHVwIHRoZQ0gICAgICBMU1BzLCBidXQgcmVjZWl2ZXMgb25l IG9yIG1vcmUgcmVzcG9uZGluZyBQYXRoRXJyIG1lc3NhZ2VzLCB0aGUNICAgICAgbXVsdGlwbGUg YmktZGlyZWN0aW9uYWwgTFNQcyBzZXR1cCBkZWxheSBNVVNUIGJlIHNldCB0byB1bmRlZmluZWQu DSAgICAgIFRoZXJlIGFyZSBtYW55IHBvc3NpYmxlIHJlYXNvbnMgZm9yIHRoaXMgY2FzZS4gIEZv ciBleGFtcGxlLCBvbmUNICAgICAgb3IgbW9yZSBvZiB0aGUgUEFUSCBtZXNzYWdlcyBoYXZlIGlu dmFsaWQgcGFyYW1ldGVycyBvciB0aGUNICAgICAgbmV0d29yayBoYXMgbm90IGVub3VnaCByZXNv dXJjZSB0byBzZXQgdXAgdGhlIHJlcXVlc3RlZCBMU1BzLg0NICAgbyAgVGhlIGFycml2YWwgcmF0 ZSBvZiB0aGUgUG9pc3NvbiBwcm9jZXNzIExhbWJkYV9tIHNob3VsZCBiZQ0gICAgICBjYXJlZnVs bHkgY2hvc2VuIHN1Y2ggdGhhdCBvbiB0aGUgb25lIGhhbmQgdGhlIGNvbnRyb2wgcGxhbmUgaXMN ICAgICAgbm90IG92ZXJidXJkZW5lZC4gIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgYXJyaXZhbCBy YXRlIGlzIGxhcmdlDSAgICAgIGVub3VnaCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgYXBw bGljYXRpb25zIG9yIHNlcnZpY2VzBQUuDQ03LjcuICBNZXRob2RvbG9naWVzDQ0gICBHZW5lcmFs bHkgdGhlIG1ldGhvZG9sb2d5IHdvdWxkIHByb2NlZWQgYXMgZm9sbG93czoNDSAgIG8gIE1ha2Ug c3VyZSB0aGF0IHRoZSBuZXR3b3JrIGhhcyBlbm91Z2ggcmVzb3VyY2UgdG8gc2V0IHVwIHRoZQ0g ICAgICByZXF1ZXN0ZWQgTFNQcy4NDSAgIG8gIEF0IHRoZSBpbmdyZXNzIG5vZGUsIGZvcm0gdGhl IFBBVEggbWVzc2FnZXMgKGluY2x1ZGluZyB0aGUNICAgICAgVXBzdHJlYW0gTGFiZWwgb3Igc3Vn Z2VzdGVkIGxhYmVsKSBhY2NvcmRpbmcgdG8gdGhlIExTUHMnDSAgICAgIHJlcXVpcmVtZW50cy4N DSAgIG8gIEF0IHRoZSBpbmdyZXNzIG5vZGUsIHNlbGVjdCB0aGUgdGltZSBmb3IgZWFjaCBvZiB0 aGUgUEFUSCBtZXNzYWdlcw0gICAgICBhY2NvcmRpbmcgdG8gdGhlIHNwZWNpZmllZCBQb2lzc29u IHByb2Nlc3MuDQ0gICBvICBBdCB0aGUgaW5ncmVzcyBub2RlLCBzZW5kIG91dCB0aGUgUEFUSCBt ZXNzYWdlcyBhY2NvcmRpbmcgdG8gdGhlDSAgICAgIHNlbGVjdGVkIHRpbWUuDQ0gICBvICBTdG9y ZSBhIHRpbWVzdGFtcCAoVDEpIGxvY2FsbHkgaW4gdGhlIGluZ3Jlc3Mgbm9kZSB3aGVuIHRoZSBm aXJzdA0gICAgICBQQVRIIG1lc3NhZ2UgcGFja2V0IGlzIHNlbnQgdG93YXJkcyB0aGUgZWdyZXNz IG5vZGUuDQ0gICBvICBJZiBhbGwgb2YgdGhlIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlcyBh cnJpdmUgd2l0aGluIGENICAgICAgcmVhc29uYWJsZSBwZXJpb2Qgb2YgdGltZSwgdGFrZSB0aGUg ZmluYWwgdGltZXN0YW1wIChUMikgYXMgc29vbg0gICAgICBhcyBwb3NzaWJsZSB1cG9uIHRoZSBy ZWNlaXB0IG9mIGFsbCB0aGUgbWVzc2FnZXMuICBCeSBzdWJ0cmFjdGluZw0gICAgICB0aGUgdHdv IHRpbWVzdGFtcHMsIGFuIGVzdGltYXRlIG9mIG11bHRpcGxlIGJpLWRpcmVjdGlvbmFsIExTUHMN ICAgICAgc2V0dXAgZGVsYXkgKFQyIC1UMSkgY2FuIGJlIGNvbXB1dGVkLg0NICAgbyAgSWYgb25l IG9yIG1vcmUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlcyBmYWlsIHRvIGFycml2 ZQ0gICAgICB3aXRoaW4gYSByZWFzb25hYmxlIHBlcmlvZCBvZiB0aW1lLCB0aGUgbXVsdGlwbGUg YmktZGlyZWN0aW9uYWwNICAgICAgTFNQcyBzZXR1cCBkZWxheSBpcyBkZWVtZWQgdG8gYmUgdW5k ZWZpbmVkLiAgTm90ZSB0aGF0IHRoZQ0gICAgICAncmVhc29uYWJsZScgdGhyZXNob2xkIGlzIGEg cGFyYW1ldGVyIG9mIHRoZSBtZXRob2RvbG9neS4NDSAgIG8gIElmIG9uZSBvciBtb3JlIG9mIHRo ZSBjb3JyZXNwb25kaW5nIHJlc3BvbnNlIG1lc3NhZ2VzIGFyZSBQYXRoRXJyLA0gICAgICB0aGUg bXVsdGlwbGUgYmktZGlyZWN0aW9uYWwgTFNQcyBzZXR1cCBkZWxheSBpcyBkZWVtZWQgdG8gYmUN ICAgICAgdW5kZWZpbmVkLg0NDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDIxXQ0NDUludGVybmV0LURyYWZ0ICAg ICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0N DTguICBBIFNpbmdsZXRvbiBEZWZpbml0aW9uIGZvciBMU1AgR3JhY2VmdWwgUmVsZWFzZSBEZWxh eQ0NICAgVGhlcmUgYXJlIHR3byBkaWZmZXJlbnQga2luZHMgb2YgTFNQIHJlbGVhc2UgbWVjaGFu aXNtcyBpbiBHTVBMUw0gICBuZXR3b3JrczogZ3JhY2VmdWwgcmVsZWFzZSBhbmQgZm9yY2VmdWwg cmVsZWFzZS4gIFRoaXMgZG9jdW1lbnQgZG9lcw0gICBub3QgdGFrZSBmb3JjZWZ1bCBMU1AgcmVs ZWFzZSBwcm9jZWR1cmUgaW50byBhY2NvdW50Lg0NOC4xLiAgTW90aXZhdGlvbg0NICAgTFNQIGdy YWNlZnVsIHJlbGVhc2UgZGVsYXkgaXMgdXNlZnVsIGZvciBzZXZlcmFsIHJlYXNvbnM6DQ0gICBv ICBUaGUgTFNQIGdyYWNlZnVsIHJlbGVhc2UgZGVsYXkgaXMgcGFydCBvZiB0aGUgdG90YWwgY29z dCBvZg0gICAgICBkeW5hbWljIExTUCBwcm92aXNpb25pbmcuICBGb3Igc29tZSBzaG9ydCBkdXJh dGlvbiBhcHBsaWNhdGlvbnMsDSAgICAgIHRoZSBMU1AgcmVsZWFzZSB0aW1lIGNhbiBub3QgYmUg aWdub3JlZA0NICAgbyAgVGhlIExTUCBncmFjZWZ1bCByZWxlYXNlIHByb2NlZHVyZSBpcyBtb3Jl IHByZWZlcnJlZCBpbiBhIEdNUExTDSAgICAgIGNvbnRyb2xsZWQgbmV0d29yaywgcGFydGljdWxh cmx5IHRoZSBvcHRpY2FsIG5ldHdvcmtzLiAgU2luY2UgaXQNICAgICAgZG9lc24ndCB0cmlnZ2Vy IHJlc3RvcmF0aW9uL3Byb3RlY3Rpb24sIGl0IGlzICJhbGFybS1mcmVlDSAgICAgIGNvbm5lY3Rp b24gZGVsZXRpb24iIGluIFtSRkM0MjA4XS4NDTguMi4gIE1ldHJpYyBOYW1lDQ0gICBMU1AgZ3Jh Y2VmdWwgcmVsZWFzZSBkZWxheQ0NOC4zLiAgTWV0cmljIFBhcmFtZXRlcnMNDSAgIG8gIElEMCwg dGhlIGluZ3Jlc3MgTFNSIElEDQ0gICBvICBJRDEsIHRoZSBlZ3Jlc3MgTFNSIElEDQ0gICBvICBU LCBhIHRpbWUgd2hlbiB0aGUgcmVsZWFzZSBpcyBhdHRlbXB0ZWQNDTguNC4gIE1ldHJpYyBVbml0 cw0NICAgVGhlIHZhbHVlIG9mIExTUCBncmFjZWZ1bCByZWxlYXNlIGRlbGF5IGlzIGVpdGhlciBh IHJlYWwgbnVtYmVyLCBvcg0gICBhbiB1bmRlZmluZWQgbnVtYmVyIG9mIG1pbGxpc2Vjb25kcy4N DTguNS4gIERlZmluaXRpb24NDSAgIFRoZXJlIGFyZSB0d28gZGlmZmVyZW50IExTUCBncmFjZWZ1 bCByZWxlYXNlIHByb2NlZHVyZXMsIG9uZSBpcw0gICBpbml0aWF0ZWQgYnkgdGhlIGluZ3Jlc3Mg bm9kZSwgYW5kIGFub3RoZXIgaXMgaW5pdGlhdGVkIGJ5IHRoZSBlZ3Jlc3MNICAgbm9kZS4gIFRo ZSB0d28gcHJvY2VkdXJlcyBhcmUgZGVwaWN0ZWQgaW4gW1JGQzM0NzNdLiAgV2UgZGVmaW5lIHRo ZQ0gICBncmFjZWZ1bCBMU1AgcmVsZWFzZSBkZWxheSBmb3IgdGhlc2UgdHdvIHByb2NlZHVyZXMg c2VwYXJhdGVseS4NDSAgIEZvciBhIHJlYWwgbnVtYmVyIGRULCB0aGUgTFNQIGdyYWNlZnVsIHJl bGVhc2UgZGVsYXkgZnJvbSBpbmdyZXNzDSAgIG5vZGUgSUQwIHRvIGVncmVzcyBub2RlIElEMSBh dCBUIGlzIGRULCBtZWFucyB0aGF0IGluZ3Jlc3Mgbm9kZSBJRDANICAgc2VuZHMgdGhlIGZpcnN0 IGJpdCBvZiBhIFBBVEggbWVzc2FnZSBpbmNsdWRpbmcgQWRtaW4gU3RhdHVzIE9iamVjdA0gICB3 aXRoIHRoZSBSZWZsZWN0IChSKSBhbmQgRGVsZXRlIChEKSBiaXRzIHNldCB0byB0aGUgZWdyZXNz IG5vZGUgYXQNICAgd2lyZS10aW1lIFQsIHRoYXQgdGhlIGVncmVzcyBub2RlIElEMSByZWNlaXZl cyB0aGF0IHBhY2tldCwgdGhlbg0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEph bnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAyMl0NDQ1JbnRlcm5ldC1EcmFmdCAg ICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkN DQ0gICBpbW1lZGlhdGVseSBzZW5kcyBhIFJFU1YgbWVzc2FnZSBpbmNsdWRpbmcgQWRtaW4gU3Rh dHVzIE9iamVjdCB3aXRoDSAgIHRoZSBEZWxldGUgKEQpIGJpdCBzZXQgYmFjayB0byB0aGUgaW5n cmVzcyBub2RlLiAgVGhlIGluZ3Jlc3Mgbm9kZQ0gICBJRDAgc2VuZHMgb3V0IFBhdGhUZWFyIGRv d25zdHJlYW0gdG8gcmVtb3ZlIHRoZSBMU1AsIGFuZCBlZ3Jlc3Mgbm9kZQ0gICBJRDEgcmVjZWl2 ZXMgdGhlIGxhc3QgYml0IG9mIFBhdGhUZWFyIHBhY2tldCBhdCB3aXJlLXRpbWUgVCtkVC4NDSAg IEFsc28gYXMgYW4gb3B0aW9uLCB1cG9uIHJlY2VpcHQgb2YgdGhlIFBBVEggbWVzc2FnZSBpbmNs dWRpbmcgQWRtaW4NICAgU3RhdHVzIE9iamVjdCB3aXRoIHRoZSBSZWZsZWN0IChSKSBhbmQgRGVs ZXRlIChEKSBiaXRzIHNldCwgdGhlDSAgIGVncmVzcyBub2RlIElEMSBtYXkgcmVzcG9uZCB3aXRo IFBhdGhFcnIgbWVzc2FnZSB3aXRoIHRoZQ0gICBQYXRoX1N0YXRlX1JlbW92ZWQgZmxhZyBzZXQu DQ0gICBUaGUgTFNQIGdyYWNlZnVsIHJlbGVhc2UgZGVsYXkgZnJvbSBpbmdyZXNzIG5vZGUgSUQw IHRvIGVncmVzcyBub2RlDSAgIElEMSBhdCBUIGlzIHVuZGVmaW5lZCwgbWVhbnMgdGhhdCBpbmdy ZXNzIG5vZGUgSUQwIHNlbmRzIHRoZSBmaXJzdA0gICBiaXQgb2YgUEFUSCBtZXNzYWdlIHRvIGVn cmVzcyBub2RlIElEMSBhdCB3aXJlLXRpbWUgVCBhbmQgdGhhdA0gICAoZWl0aGVyIGVncmVzcyBu b2RlIGRvZXMgbm90IHJlY2VpdmUgdGhlIFBBVEggcGFja2V0LCBlZ3Jlc3Mgbm9kZQ0gICBkb2Vz IG5vdCBzZW5kIGNvcnJlc3BvbmRpbmcgUkVTViBtZXNzYWdlIHBhY2tldCBpbiByZXNwb25zZSwg b3INICAgaW5ncmVzcyBub2RlIGRvZXMgbm90IHJlY2VpdmUgdGhhdCBSRVNWIHBhY2tldCwgYW5k KSB0aGUgZWdyZXNzIG5vZGUNICAgSUQxIGRvZXMgbm90IHJlY2VpdmUgdGhlIFBhdGhUZWFyIHdp dGhpbiBhIHJlYXNvbmFibGUgcGVyaW9kIG9mIHRpbWUuDQ0gICBUaGUgTFNQIGdyYWNlZnVsIHJl bGVhc2UgZGVsYXkgZnJvbSBlZ3Jlc3Mgbm9kZSBJRDEgdG8gaW5ncmVzcyBub2RlDSAgIElEMCBh dCBUIGlzIGRULCBtZWFucyB0aGF0IGVncmVzcyBub2RlIElEMSBzZW5kcyB0aGUgZmlyc3QgYml0 IG9mIGENICAgUkVTViBtZXNzYWdlIGluY2x1ZGluZyBBZG1pbiBTdGF0dXMgT2JqZWN0IHdpdGgg c2V0dGluZyB0aGUgUmVmbGVjdA0gICAoUikgYW5kIERlbGV0ZSAoRCkgYml0cyB0byBpbmdyZXNz IG5vZGUgYXQgd2lyZS10aW1lIFQuIFRoZSBpbmdyZXNzDSAgIG5vZGUgSUQwIHNlbmRzIG91dCBQ YXRoVGVhciBkb3duc3RyZWFtIHRvIHJlbW92ZSB0aGUgTFNQLCBhbmQgZWdyZXNzDSAgIG5vZGUg SUQxIHJlY2VpdmVzIHRoZSBsYXN0IGJpdCBvZiBQYXRoVGVhciBwYWNrZXQgYXQgd2lyZS10aW1l IFQrZFQuDQ0gICBUaGUgTFNQIGdyYWNlZnVsIHJlbGVhc2UgZGVsYXkgZnJvbSBlZ3Jlc3Mgbm9k ZSBJRDEgdG8gaW5ncmVzcyBub2RlDSAgIElEMCBhdCBUIGlzIHVuZGVmaW5lZCwgbWVhbnMgdGhh dCBlZ3Jlc3Mgbm9kZSBJRDEgc2VuZHMgdGhlIGZpcnN0IGJpdA0gICBvZiBSRVNWIG1lc3NhZ2Ug aW5jbHVkaW5nIEFkbWluIFN0YXR1cyBPYmplY3Qgd2l0aCBzZXR0aW5nIHRoZQ0gICBSZWZsZWN0 IChSKSBhbmQgRGVsZXRlIChEKSBiaXRzIHRvIGluZ3Jlc3Mgbm9kZSBJRDAgYXQgd2lyZS10aW1l IFQNICAgYW5kIHRoYXQgKGVpdGhlciBpbmdyZXNzIG5vZGUgZG9lcyBub3QgcmVjZWl2ZSB0aGUg UkVTViBwYWNrZXQsIG9yDSAgIGluZ3Jlc3Mgbm9kZSBkb2VzIG5vdCBzZW5kIFBhdGhUZWFyIG1l c3NhZ2UgcGFja2V0IGluIHJlc3BvbnNlLCBhbmQpDSAgIHRoZSBlZ3Jlc3Mgbm9kZSBJRDEgZG9l cyBub3QgcmVjZWl2ZSB0aGUgUGF0aFRlYXIgd2l0aGluIGEgcmVhc29uYWJsZQ0gICBwZXJpb2Qg b2YgdGltZS4NDSAgIFRoZSB1bmRlZmluZWQgdmFsdWUgb2YgdGhpcyBtZXRyaWMgaW5kaWNhdGVz IGFuIGV2ZW50IG9mIExTUCBHcmFjZWZ1bA0gICBSZWxlYXNlIEZhaWx1cmUsIGFuZCB3b3VsZCBi ZSB1c2VkIHRvIHJlcG9ydCBhIGNvdW50IG9yIGFuIHBlcmNlbnRhZ2UNICAgb2YgTFNQIEdyYWNl ZnVsIFJlbGVhc2UgZmFpbHVyZXMuICBTZWUgc2VjdGlvbiBTZWN0aW9uIDE0LjQgZm9yDSAgIGRl ZmluaXRpb25zIG9mIExTUCBzZXR1cC9yZWxlYXNlIGZhaWx1cmVzLg0NOC42LiAgRGlzY3Vzc2lv bg0NICAgVGhlIGZvbGxvd2luZyBpc3N1ZXMgYXJlIGxpa2VseSB0byBjb21lIHVwIGluIHByYWN0 aWNlOg0NICAgbyAgSW4gdGhlIGZpcnN0IChzZWNvbmQpIGNpcmN1bXN0YW5jZSwgdGhlIGFjY3Vy YWN5IG9mIExTUCBncmFjZWZ1bA0gICAgICByZWxlYXNlIGRlbGF5IGF0IHRpbWUgVCBkZXBlbmRz IG9uIHRoZSBjbG9jayByZXNvbHV0aW9uIGluIHRoZQ0gICAgICBpbmdyZXNzIChlZ3Jlc3MpIG5v ZGUuICBJbiB0aGUgZmlyc3QgY2lyY3Vtc3RhbmNlLCBzeW5jaHJvbml6YXRpb24NICAgICAgYmV0 d2VlbiB0aGUgaW5ncmVzcyBub2RlIGFuZCBlZ3Jlc3Mgbm9kZSBpcyByZXF1aXJlZDsgYnV0IG5v dCBpbg0gICAgICB0aGUgc2Vjb25kIGNpcmN1bXN0YW5jZTsNDQ0NU3VuICYgWmhhbmcgICAgICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQ0N SW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMgTmV0d29ya3MgICAg ICAgICAgSnVseSAyMDA5DQ0NICAgbyAgQSBnaXZlbiBtZXRob2RvbG9neSBoYXMgdG8gaW5jbHVk ZSBhIHdheSB0byBkZXRlcm1pbmUgd2hldGhlciBhDSAgICAgIGxhdGVuY3kgdmFsdWUgaXMgaW5m aW5pdGUgb3Igd2hldGhlciBpdCBpcyBtZXJlbHkgdmVyeSBsYXJnZS4NICAgICAgU2ltcGxlIHVw cGVyIGJvdW5kcyBNQVkgYmUgdXNlZC4gIEJ1dCB0aGUgdXBwZXIgYm91bmQgc2hvdWxkIGJlDSAg ICAgIGNob3NlbiBjYXJlZnVsbHkgaW4gcHJhY3RpY2UgYW5kIHRoZSB2YWx1ZSBNVVNUIGJlIHJl cG9ydGVkOw0NICAgbyAgSW4gdGhlIGZpcnN0IGNpcmN1bXN0YW5jZSwgaWYgdGhlIGluZ3Jlc3Mg bm9kZSBzZW5kcyBvdXQgUEFUSA0gICAgICBtZXNzYWdlIGluY2x1ZGluZyBBZG1pbiBTdGF0dXMg T2JqZWN0IHdpdGggdGhlIFJlZmxlY3QgKFIpIGFuZA0gICAgICBEZWxldGUgKEQpIGJpdHMgc2V0 IHRvIGluaXRpYXRlIExTUCBncmFjZWZ1bCByZWxlYXNlLCBidXQgdGhlDSAgICAgIGVncmVzcyBu b2RlIG5ldmVyIHJlY2VpdmVzIHRoZSBjb3JyZXNwb25kaW5nIFBhdGhUZWFyIG1lc3NhZ2UsIExT UA0gICAgICBncmFjZWZ1bCByZWxlYXNlIGRlbGF5IE1VU1QgYmUgc2V0IHRvIHVuZGVmaW5lZC4N DSAgIG8gIEluIHRoZSBzZWNvbmQgY2lyY3Vtc3RhbmNlLCBpZiB0aGUgZWdyZXNzIG5vZGUgc2Vu ZHMgb3V0IHRoZSBSRVNWDSAgICAgIG1lc3NhZ2UgaW5jbHVkaW5nIEFkbWluIFN0YXR1cyBPYmpl Y3Qgd2l0aCB0aGUgUmVmbGVjdCAoUikgYW5kDSAgICAgIERlbGV0ZSAoRCkgYml0cyBzZXQgdG8g aW5pdGlhdGUgTFNQIGdyYWNlZnVsIHJlbGVhc2UsIGJ1dCBuZXZlcg0gICAgICByZWNlaXZlcyB0 aGUgY29ycmVzcG9uZGluZyBQYXRoVGVhciBtZXNzYWdlLCBMU1AgZ3JhY2VmdWwgcmVsZWFzZQ0g ICAgICBkZWxheSBNVVNUIGJlIHNldCB0byB1bmRlZmluZWQuDQ04LjcuICBNZXRob2RvbG9naWVz DQ0gICBJbiB0aGUgZmlyc3QgY2lyY3Vtc3RhbmNlLCB0aGUgbWV0aG9kb2xvZ3kgbWF5IHByb2Nl ZWQgYXMgZm9sbG93czoNDSAgIG8gIE1ha2Ugc3VyZSB0aGUgTFNQIHRvIGJlIGRlbGV0ZWQgaXMg c2V0IHVwOw0NICAgbyAgQXQgdGhlIGluZ3Jlc3Mgbm9kZSwgZm9ybSB0aGUgUEFUSCBtZXNzYWdl IGluY2x1ZGluZyBBZG1pbiBTdGF0dXMNICAgICAgT2JqZWN0IHdpdGggdGhlIFJlZmxlY3QgKFIp IGFuZCBEZWxldGUgKEQpIGJpdHMgc2V0LiAgQSB0aW1lc3RhbXANICAgICAgKFQxKSBtYXkgYmUg c3RvcmVkIGxvY2FsbHkgb24gdGhlIGluZ3Jlc3Mgbm9kZSB3aGVuIHRoZSBQQVRIDSAgICAgIG1l c3NhZ2UgcGFja2V0IGlzIHNlbnQgdG93YXJkcyB0aGUgZWdyZXNzIG5vZGU7DQ0gICBvICBVcG9u IHJlY2VpdmluZyB0aGUgUEFUSCBtZXNzYWdlIGluY2x1ZGluZyBBZG1pbiBTdGF0dXMgT2JqZWN0 IHdpdGgNICAgICAgdGhlIFJlZmxlY3QgKFIpIGFuZCBEZWxldGUgKEQpIGJpdHMgc2V0LCB0aGUg ZWdyZXNzIG5vZGUgc2VuZHMgYQ0gICAgICBSRVNWIG1lc3NhZ2UgaW5jbHVkaW5nIEFkbWluIFN0 YXR1cyBPYmplY3Qgd2l0aCB0aGUgRGVsZXRlIChEKSBhbmQNICAgICAgUmVmbGVjdCAoUikgYml0 cyBzZXQuICBBbHRlcm5hdGl2ZWx5LCB0aGUgZWdyZXNzIG5vZGUgc2VuZHMgYQ0gICAgICBQYXRo RXJyIG1lc3NhZ2Ugd2l0aCB0aGUgUGF0aF9TdGF0ZV9SZW1vdmVkIGZsYWcgc2V0IHVwc3RyZWFt Ow0NICAgbyAgV2hlbiB0aGUgaW5ncmVzcyBub2RlIHJlY2VpdmUgdGhlIFJFU1YgbWVzc2FnZSBv ciB0aGUgUGF0aEVycg0gICAgICBtZXNzYWdlLCBpdCBzZW5kcyBhIFBhdGhUZWFyIG1lc3NhZ2Ug dG8gcmVtb3ZlIHRoZSBMU1A7DQ0gICBvICBUaGUgZWdyZXNzIG5vZGUgdGFrZXMgYSB0aW1lc3Rh bXAgKFQyKSBvbmNlIGl0IHJlY2VpdmVzIHRoZSBsYXN0DSAgICAgIGJpdCBvZiB0aGUgUGF0aFRl YXIgbWVzc2FnZS4gIFRoZSBMU1AgZ3JhY2VmdWwgcmVsZWFzZSBkZWxheSBpcw0gICAgICB0aGVu IChUMi1UMSkuDQ0gICBvICBJZiB0aGUgaW5ncmVzcyBub2RlIHNlbmRzIHRoZSBQQVRIIG1lc3Nh Z2UgZG93bnN0cmVhbSwgYnV0IHRoZQ0gICAgICBlZ3Jlc3Mgbm9kZSBmYWlscyB0byByZWNlaXZl IHRoZSBQYXRoVGVhciBtZXNzYWdlIHdpdGhpbiBhDSAgICAgIHJlYXNvbmFibGUgcGVyaW9kIG9m IHRpbWUsIHRoZSBMU1AgZ3JhY2VmdWwgcmVsZWFzZSBkZWxheSBpcw0gICAgICBkZWVtZWQgdG8g YmUgdW5kZWZpbmVkLiAgTm90ZSB0aGF0IHRoZSAncmVhc29uYWJsZScgdGhyZXNob2xkIGlzIGEN ICAgICAgcGFyYW1ldGVyIG9mIHRoZSBtZXRob2RvbG9neS4NDSAgIEluIHRoZSBzZWNvbmQgY2ly Y3Vtc3RhbmNlLCB0aGUgbWV0aG9kb2xvZ3kgd291bGQgcHJvY2VlZCBhcyBmb2xsb3dzOg0NDQ1T dW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAg ICAgICBbUGFnZSAyNF0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBH TVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0gICBvICBNYWtlIHN1cmUgdGhlIExT UCB0byBiZSBkZWxldGVkIGlzIHNldCB1cDsNDSAgIG8gIE9uIHRoZSBlZ3Jlc3Mgbm9kZSwgZm9y bSB0aGUgUkVTViBtZXNzYWdlIGluY2x1ZGluZyBBZG1pbiBTdGF0dXMNICAgICAgT2JqZWN0IHdp dGggdGhlIFJlZmxlY3QgKFIpIGFuZCBEZWxldGUgKEQpIGJpdHMgc2V0LiAgQSB0aW1lc3RhbXAN ICAgICAgbWF5IGJlIHN0b3JlZCBsb2NhbGx5IG9uIHRoZSBlZ3Jlc3Mgbm9kZSB3aGVuIHRoZSBS RVNWIG1lc3NhZ2UNICAgICAgcGFja2V0IGlzIHNlbnQgdG93YXJkcyB0aGUgaW5ncmVzcyBub2Rl Ow0NICAgbyAgVXBvbiByZWNlaXZpbmcgdGhlIEFkbWluIFN0YXR1cyBPYmplY3Qgd2l0aCB0aGUg UmVmbGVjdCAoUikgYW5kDSAgICAgIERlbGV0ZSAoRCkgYml0cyBzZXQgaW4gdGhlIFJFU1YgbWVz c2FnZSwgdGhlIGluZ3Jlc3Mgbm9kZSBzZW5kcyBhDSAgICAgIFBhdGhUZWFyIG1lc3NhZ2UgZG93 bnN0cmVhbSB0byByZW1vdmUgdGhlIExTUDsNDSAgIG8gIEVncmVzcyBub2RlIHRha2VzIGEgdGlt ZXN0YW1wIChUMikgb25jZSBpdCByZWNlaXZlcyB0aGUgbGFzdCBiaXQNICAgICAgb2YgdGhlIFBh dGhUZWFyIG1lc3NhZ2UuICBUaGUgTFNQIGdyYWNlZnVsIHJlbGVhc2UgZGVsYXkgaXMgdGhlbg0g ICAgICAoVDItVDEpLg0NICAgbyAgSWYgdGhlIGVncmVzcyBub2RlIHNlbmRzIHRoZSBSRVNWIG1l c3NhZ2UgdXBzdHJlYW0sIGJ1dCBpdCBmYWlscw0gICAgICB0byByZWNlaXZlIHRoZSBQYXRoVGVh ciBtZXNzYWdlIHdpdGhpbiBhIHJlYXNvbmFibGUgcGVyaW9kIG9mDSAgICAgIHRpbWUsIHRoZSBM U1AgZ3JhY2VmdWwgcmVsZWFzZSBkZWxheSBpcyBkZWVtZWQgdG8gYmUgdW5kZWZpbmVkLg0gICAg ICBOb3RlIHRoYXQgdGhlICdyZWFzb25hYmxlJyB0aHJlc2hvbGQgaXMgYSBwYXJhbWV0ZXIgb2Yg dGhlDSAgICAgIG1ldGhvZG9sb2d5Lg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NU3Vu ICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAg ICAgW1BhZ2UgMjVdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01Q TFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NOS4gIEEgRGVmaW5pdGlvbiBmb3IgU2Ft cGxlcyBvZiBTaW5nbGUgVW5pLWRpcmVjdGlvbmFsIExTUCBTZXR1cCBEZWxheQ0NICAgSW4gU2Vj dGlvbiA0LCB3ZSBoYXZlIGRlZmluZWQgdGhlIHNpbmdsZXRvbiBtZXRyaWMgb2YgU2luZ2xlIHVu aS0NICAgZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5LiAgTm93IHdlIGRlZmluZSBob3cgdG8g Z2V0IG9uZSBwYXJ0aWN1bGFyDSAgIHNhbXBsZSBvZiBTaW5nbGUgdW5pLWRpcmVjdGlvbmFsIExT UCBzZXR1cCBkZWxheS4gIFNhbXBsaW5nIGlzIHRvDSAgIHNlbGVjdCBhIHBhcnRpY3VsYXIgcG9y dGlvbiBvZiBzaW5nbGV0b24gdmFsdWVzIG9mIHRoZSBnaXZlbg0gICBwYXJhbWV0ZXJzLiAgTGlr ZSBpbiBbUkZDMjMzMF0sIHdlIHVzZSBQb2lzc29uIHNhbXBsaW5nIGFzIGFuDSAgIGV4YW1wbGUu DQ05LjEuICBNZXRyaWMgTmFtZQ0NICAgU2luZ2xlIHVuaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAg ZGVsYXkgc2FtcGxlDQ05LjIuICBNZXRyaWMgUGFyYW1ldGVycw0NICAgbyAgSUQwLCB0aGUgaW5n cmVzcyBMU1IgSUQNDSAgIG8gIElEMSwgdGhlIGVncmVzcyBMU1IgSUQNDSAgIG8gIFQwLCBhIHRp bWUNDSAgIG8gIFRmLCBhIHRpbWUNDSAgIG8gIExhbWJkYSwgYSByYXRlIGluIHRoZSByZWNpcHJv Y2FsIG1pbGxpc2Vjb25kcw0NICAgbyAgVGgsIExTUCBob2xkaW5nIHRpbWUNDSAgIG8gIFRkLCB0 aGUgbWF4aW11bSB3YWl0aW5nIHRpbWUgZm9yIHN1Y2Nlc3NmdWwgc2V0dXANDTkuMy4gIE1ldHJp YyBVbml0cw0NICAgQSBzZXF1ZW5jZSBvZiBwYWlyczsgdGhlIGVsZW1lbnRzIG9mIGVhY2ggcGFp ciBhcmU6DQ0gICBvICBULCBhIHRpbWUgd2hlbiBzZXR1cCBpcyBhdHRlbXB0ZWQNDSAgIG8gIGRU LCBlaXRoZXIgYSByZWFsIG51bWJlciBvciBhbiB1bmRlZmluZWQgbnVtYmVyIG9mIG1pbGxpc2Vj b25kcy4NDTkuNC4gIERlZmluaXRpb24NDSAgIEdpdmVuIFQwLCBUZiwgYW5kIGxhbWJkYSwgY29t cHV0ZSBhIHBzZXVkby1yYW5kb20gUG9pc3NvbiBwcm9jZXNzDSAgIGJlZ2lubmluZyBhdCBvciBi ZWZvcmUgVDAsIHdpdGggYXZlcmFnZSBhcnJpdmFsIHJhdGUgbGFtYmRhLCBhbmQNICAgZW5kaW5n IGF0IG9yIGFmdGVyIFRmLiAgVGhvc2UgdGltZSB2YWx1ZXMgZ3JlYXRlciB0aGFuIG9yIGVxdWFs IHRvIFQwDSAgIGFuZCBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gVGYgYXJlIHRoZW4gc2VsZWN0ZWQu ICBBdCBlYWNoIG9mIHRoZSB0aW1lc3RpbWUgcG9pbnRzDSAgIGluIHRoaXMgcHJvY2Vzcywgd2Ug b2J0YWluIHRoZSB2YWx1ZSBvZiB1bmktZGlyZWN0aW9uYWwgTFNQIHNldHVwDSAgIGRlbGF5IHNh bXBsZSBhdCB0aGlzIHRpbWUuICBUaGUgdmFsdWUgb2YgdGhlIHNhbXBsZSBpcyB0aGUgc2VxdWVu Y2UNICAgbWFkZSB1cCBvZiB0aGUgcmVzdWx0aW5nIDx0aW1lLCBMU1Agc2V0dXAgZGVsYXk+IHBh aXJzBS4gIElmIHRoZXJlIGFyZQ0gICBubyBzdWNoIHBhaXJzLCB0aGUgc2VxdWVuY2UgaXMgb2Yg bGVuZ3RoIHplcm8gYW5kIHRoZSBzYW1wbGUgaXMgc2FpZA0gICB0byBiZSBlbXB0eS4NDQ0NU3Vu ICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAg ICAgW1BhZ2UgMjZdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01Q TFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NOS41LiAgRGlzY3Vzc2lvbg0NICAgVGhl IHBhcmFtZXRlciBsYW1iZGEgc2hvdWxkIGJlIGNhcmVmdWxseSBjaG9zZW4uICBJZiB0aGUgcmF0 ZSBpcyB0b28NICAgaGlnaCwgdG9vIGZyZXF1ZW50IExTUCBzZXR1cC9yZWxlYXNlIHByb2NlZHVy ZSB3aWxsIHJlc3VsdCBpbiBoaWdoDSAgIG92ZXJoZWFkIGluIHRoZSBjb250cm9sIHBsYW5lLiAg SW4gdHVybiwgdGhlIGhpZ2ggb3ZlcmhlYWQgd2lsbA0gICBpbmNyZWFzZSB1bmktZGlyZWN0aW9u YWwgTFNQIHNldHVwIGRlbGF5LiAgT24gdGhlIG90aGVyIGhhbmQgaWYgdGhlDSAgIHJhdGUgaXMg dG9vIGxvdywgdGhlIHNhbXBsZSBjb3VsZCBub3QgY29tcGxldGVseSByZWZsZWN0IHRoZSBkeW5h bWljDSAgIHByb3Zpc2lvbmluZyBwZXJmb3JtYW5jZSBvZiB0aGUgR01QTFMgbmV0d29yay4gIFRo ZSBhcHByb3ByaWF0ZQ0gICBsYW1iZGEgdmFsdWUgZGVwZW5kcyBvbiB0aGUgZ2l2ZW4gbmV0d29y ay4NDSAgIFRoZSBwYXJhbWV0ZXJzIFRkIHNob3VsZCBiZSBjYXJlZnVsbHkgY2hvc2VuLiAgRGlm ZmVyZW50IHN3aXRjaGluZw0gICB0ZWNobm9sb2dpZXMgbWF5IHZhcnkgc2lnbmlmaWNhbnRseSBp biBwZXJmb3JtaW5nIGEgY3Jvc3MtY29ubmVjdA0gICBvcGVyYXRpb24uICBBdCB0aGUgc2FtZSB0 aW1lLCB0aGUgdGltZSBuZWVkZWQgaW4gc2V0dGluZyB1cCBhbiBMU1ANICAgdW5kZXIgZGlmZmVy ZW50IHRyYWZmaWMgbWF5IGFsc28gdmFyeSBzaWduaWZpY2FudGx5Lg0NICAgSW4gdGhlIGNhc2Ug b2YgYWN0aXZlIG1lYXN1cmVtZW50LCB0aGUgcGFyYW1ldGVycyBUaCBzaG91bGQgYmUNICAgY2Fy ZWZ1bGx5IGNob3Nlbi4gIFRoZSBjb21iaW5hdGlvbiBvZiBsYW1iZGEgYW5kIFRoIHJlZmxlY3Rz IHRoZSBsb2FkDSAgIG9mIHRoZSBuZXR3b3JrLiAgVGhlIHNlbGVjdGlvbiBvZiBUaCBzaG91bGQg dGFrZSBpbnRvIGFjY291bnQgdGhhdA0gICB0aGUgbmV0d29yayBoYXMgc3VmZmljaWVudCByZXNv dXJjZSB0byBwZXJmb3JtIHN1YnNlcXVlbnQgdGVzdHMuICBUaGUNICAgdmFsdWUgb2YgVGggTUFZ IGJlIGNvbnN0YW50IGR1cmluZyBvbmUgc2FtcGxpbmcgcHJvY2VzcyBmb3INICAgc2ltcGxpY2l0 eSBjb25zaWRlcmF0aW9ucy4NDSAgIE5vdGUgdGhhdCBmb3Igb25saW5lIG9yIHBhc3NpdmUgbWVh c3VyZW1lbnRzLCB0aGUgYXJyaXZhbCByYXRlIGFuZA0gICBMU1AgaG9sZGluZyB0aW1lIGFyZSBk ZXRlcm1pbmVkIGJ5IGFjdHVhbCB0cmFmZmljLCBoZW5jZSBpbiB0aGlzIGNhc2UNICAgTGFtYmRh IGFuZCBUaCBhcmUgbm90IGlucHV0IHBhcmFtZXRlcnMuDQ05LjYuICBNZXRob2RvbG9naWVzDQ0g ICBvICBTZWxlY3QgdGhlIHRpbWVzIHVzaW5nIHRoZSBzcGVjaWZpZWQgUG9pc3NvbiBhcnJpdmFs IHByb2Nlc3MsIGFuZA0NICAgbyAgU2V0IHVwIHRoZSBMU1AgYXMgdGhlIG1ldGhvZG9sb2d5IGZv ciB0aGUgc2luZ2xldG9uIHVuaS0NICAgICAgZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5LCBh bmQgb2J0YWluIHRoZSB2YWx1ZSBvZiB1bmktDSAgICAgIGRpcmVjdGlvbmFsIExTUCBzZXR1cCBk ZWxheQ0NICAgbyAgUmVsZWFzZSB0aGUgTFNQIGFmdGVyIFRoLCBhbmQgd2FpdCBmb3IgdGhlIG5l eHQgUG9pc3NvbiBhcnJpdmFsDSAgICAgIGV2ZW50DQ0gICBOb3RlIHRoYXQ6IGl0IGlzIHBvc3Np YmxlIHRoYXQgYmVmb3JlIHRoZSBwcmV2aW91cyBMU1AgcmVsZWFzZQ0gICBwcm9jZWR1cmUgY29t cGxldGVzLCB0aGUgbmV4dCBQb2lzc29uIGFycml2YWwgZXZlbnQgYXJyaXZlcyBhbmQgdGhlDSAg IExTUCBzZXR1cCBwcm9jZWR1cmUgaXMgaW5pdGlhdGVkLiAgSWYgdGhlcmUgaXMgcmVzb3VyY2Ug Y29udGVudGlvbg0gICBiZXR3ZWVuIHRoZSB0d28gTFNQcywgdGhlIExTUCBzZXR1cCBtYXkgZmFp bC4gIFdheXMgdG8gYXZvaWQgc3VjaA0gICBjb250ZW50aW9uIGFyZSBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50Lg0NOS43LiAgVHlwaWNhbCB0ZXN0aW5nIGNhc2VzDQ0NDQ0NDQ1T dW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAg ICAgICBbUGFnZSAyN10NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBH TVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ05LjcuMS4gIFdpdGggbm8gTFNQIGlu IHRoZSBOZXR3b3JrDQ05LjcuMS4xLiAgTW90aXZhdGlvbg0NICAgU2luZ2xlIHVuaS1kaXJlY3Rp b25hbCBMU1Agc2V0dXAgZGVsYXkgd2l0aCBubyBMU1AgaW4gdGhlIG5ldHdvcmsgaXMNICAgaW1w b3J0YW50IGJlY2F1c2UgdGhpcyByZWZsZWN0cyB0aGUgaW5oZXJlbnQgZGVsYXkgb2YgYW4gUlNW UC1URQ0gICBpbXBsZW1lbnRhdGlvbi4gIFRoZSBtaW5pbXVtIHZhbHVlIHByb3ZpZGVzIGFuIGlu ZGljYXRpb24gb2YgdGhlDSAgIGRlbGF5IHRoYXQgd2lsbCBsaWtlbHkgYmUgZXhwZXJpZW5jZWQg d2hlbiBhbiBMU1AgdHJhdmVyc2VzIHRoZQ0gICBzaG9ydGVzdCByb3V0ZSB3aXRoIHRoZSBsaWdo dGVzdCBsb2FkIGluIHRoZSBjb250cm9sIHBsYW5lLg0NOS43LjEuMi4gIE1ldGhvZG9sb2dpZXMN DSAgIE1ha2Ugc3VyZSB0aGF0IHRoZXJlIGlzIG5vIExTUCBpbiB0aGUgbmV0d29yaywgYW5kIHBy b2NlZWQgd2l0aCB0aGUNICAgbWV0aG9kb2xvZ2llcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA5LjYu DQ05LjcuMi4gIFdpdGggYSBudW1iZXIgb2YgTFNQcyBpbiB0aGUgTmV0d29yaw0NOS43LjIuMS4g IE1vdGl2YXRpb24NDSAgIFNpbmdsZSB1bmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5IHdp dGggYSBudW1iZXIgb2YgTFNQcyBpbiB0aGUNICAgbmV0d29yayBpcyBpbXBvcnRhbnQgYmVjYXVz ZSBpdCByZWZsZWN0cyB0aGUgcGVyZm9ybWFuY2Ugb2YgYW4NICAgb3BlcmF0aW9uYWwgbmV0d29y ayB3aXRoIGNvbnNpZGVyYWJsZSBsb2FkLiAgVGhpcyBkZWxheSBtYXkgdmFyeQ0gICBzaWduaWZp Y2FudGx5IGFzIHRoZSBudW1iZXIgb2YgZXhpc3RpbmcgTFNQcyB2YXJ5LiAgSXQgY2FuIGJlIHVz ZWQgYXMNICAgYSBzY2FsYWJpbGl0eSBtZXRyaWMgb2YgYW4gUlNWUC1URSBpbXBsZW1lbnRhdGlv bi4NDTkuNy4yLjIuICBNZXRob2RvbG9naWVzDQ0gICBTZXR1cCB0aGUgcmVxdWlyZWQgbnVtYmVy IG9mIExTUHMsIGFuZCB3YWl0IHVudGlsIHRoZSBuZXR3b3JrIHJlYWNoZXMNICAgYSBzdGFibGUg c3RhdGUsIHRoZW4gcHJvY2VlZCB3aXRoIHRoZSBtZXRob2RvbG9naWVzIGRlc2NyaWJlZCBpbg0g ICBTZWN0aW9uIDkuNi4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NU3VuICYgWmhhbmcgICAgICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMjhdDQ0NSW50 ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMgTmV0d29ya3MgICAgICAg ICAgSnVseSAyMDA5DQ0NMTAuICBBIERlZmluaXRpb24gZm9yIFNhbXBsZXMgb2YgTXVsdGlwbGUg VW5pLWRpcmVjdGlvbmFsIExTUHMgU2V0dXANICAgICBEZWxheQ0NICAgSW4gU2VjdGlvbiA1LCB3 ZSBoYXZlIGRlZmluZWQgdGhlIHNpbmdsZXRvbiBtZXRyaWMgb2YgbXVsdGlwbGUgdW5pLQ0gICBk aXJlY3Rpb25hbCBMU1BzIHNldHVwIGRlbGF5LiAgTm93IHdlIGRlZmluZSBob3cgdG8gZ2V0IG9u ZQ0gICBwYXJ0aWN1bGFyIHNhbXBsZSBvZiBtdWx0aXBsZSB1bmktZGlyZWN0aW9uYWwgTFNQIHNl dHVwIGRlbGF5Lg0gICBTYW1wbGluZyBpcyB0byBzZWxlY3QgYSBwYXJ0aWN1bGFyIHBvdGlvbiBv ZiBzaW5nbGV0b24gdmFsdWVzIG9mIHRoZQ0gICBnaXZlbiBwYXJhbWV0ZXJzLiAgTGlrZSBpbiBb UkZDMjMzMF0sIHdlIHVzZSBQb2lzc29uIHNhbXBsaW5nIGFzIGFuDSAgIGV4YW1wbGUuDQ0xMC4x LiAgTWV0cmljIE5hbWUNDSAgIE11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBMU1BzIHNldHVwIGRl bGF5IHNhbXBsZQ0NMTAuMi4gIE1ldHJpYyBQYXJhbWV0ZXJzDQ0gICBvICBJRDAsIHRoZSBpbmdy ZXNzIExTUiBJRA0NICAgbyAgSUQxLCB0aGUgZWdyZXNzIExTUiBJRA0NICAgbyAgVDAsIGEgdGlt ZQ0NICAgbyAgVGYsIGEgdGltZQ0NICAgbyAgTGFtYmRhX20sIGEgcmF0ZSBpbiB0aGUgcmVjaXBy b2NhbCBtaWxsaXNlY29uZHMNDSAgIG8gIExhbWJkYSwgYSByYXRlIGluIHRoZSByZWNpcHJvY2Fs IG1pbGxpc2Vjb25kcw0NICAgbyAgWCwgdGhlIG51bWJlciBvZiBMU1BzIHRvIHNldHVwDQ0gICBv ICBUaCwgTFNQIGhvbGRpbmcgdGltZQ0NICAgbyAgVGQsIHRoZSBtYXhpbXVtIHdhaXRpbmcgdGlt ZSBmb3Igc3VjY2Vzc2Z1bCBtdWx0aXBsZSB1bmktDSAgICAgIGRpcmVjdGlvbmFsIExTUHMgc2V0 dXANDTEwLjMuICBNZXRyaWMgVW5pdHMNDSAgIEEgc2VxdWVuY2Ugb2YgcGFpcnM7IHRoZSBlbGVt ZW50cyBvZiBlYWNoIHBhaXIgYXJlOg0NICAgbyAgVCwgYSB0aW1lIHdoZW4gdGhlIGZpcnN0IHNl dHVwIGlzIGF0dGVtcHRlZA0NICAgbyAgZFQsIGVpdGhlciBhIHJlYWwgbnVtYmVyIG9yIGFuIHVu ZGVmaW5lZCBudW1iZXIgb2YgbWlsbGlzZWNvbmRzLg0NMTAuNC4gIERlZmluaXRpb24NDSAgIEdp dmVuIFQwLCBUZiwgYW5kIGxhbWJkYSwgY29tcHV0ZSBhIHBzZXVkby1yYW5kb20gUG9pc3NvbiBw cm9jZXNzDSAgIGJlZ2lubmluZyBhdCBvciBiZWZvcmUgVDAsIHdpdGggYXZlcmFnZSBhcnJpdmFs IHJhdGUgbGFtYmRhLCBhbmQNICAgZW5kaW5nIGF0IG9yIGFmdGVyIFRmLiAgVGhvc2UgdGltZSB2 YWx1ZXMgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIFQwDQ0NDVN1biAmIFpoYW5nICAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDI5XQ0NDUlu dGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAg ICAgIEp1bHkgMjAwOQ0NDSAgIGFuZCBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gVGYgYXJlIHRoZW4g c2VsZWN0ZWQuICBBdCBlYWNoIG9mIHRoZSB0aW1lDSAgIGluIHRoaXMgcHJvY2Vzcywgd2Ugb2J0 YWluIHRoZSB2YWx1ZSBvZiBtdWx0aXBsZSB1bmktZGlyZWN0aW9uYWwgTFNQDSAgIHNldHVwIGRl bGF5IHNhbXBsZSBhdCB0aGlzIHRpbWUuICBUaGUgdmFsdWUgb2YgdGhlIHNhbXBsZSBpcyB0aGUN ICAgc2VxdWVuY2UgbWFkZSB1cCBvZiB0aGUgcmVzdWx0aW5nIDx0aW1lLCBzZXR1cCBkZWxheT4g cGFpcnMuICBJZg0gICB0aGVyZSBhcmUgbm8gc3VjaCBwYWlycywgdGhlIHNlcXVlbmNlIGlzIG9m IGxlbmd0aCB6ZXJvIGFuZCB0aGUNICAgc2FtcGxlIGlzIHNhaWQgdG8gYmUgZW1wdHkuDQ0xMC41 LiAgRGlzY3Vzc2lvbg0NICAgVGhlIHBhcmFtZXRlciBsYW1iZGEgaXMgdXNlZCBhcyBhcnJpdmFs IHJhdGUgb2YgImJhdGN0aCB1bmktDSAgIGRpcmVjdGlvbmFsIExTUHMgc2V0dXAiIG9wZXJhdGlv bi4gIEl0IHJlZ3VsYXRlcyB0aGUgaW50ZXJ2YWwgaW4NICAgYmV0d2VlbiBlYWNoIGJhdGNoIG9w ZXJhdGlvbi4gIFRoZSBwYXJhbWV0ZXIgbGFtYmRhX20gaXMgdXNlZCB3aXRoaW4NICAgZWFjaCBi YXRjaCBvcGVyYXRpb24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuDQ0gICBUaGUgcGFyYW1l dGVycyBsYW1iZGEgYW5kIGxhbWJkYV9tIHNob3VsZCBiZSBjYXJlZnVsbHkgY2hvc2VuBS4gIElm DSAgIHRoZSByYXRlIGlzIHRvbyBoaWdoLCB0b28gZnJlcXVlbnQgTFNQIHNldHVwL3JlbGVhc2Ug cHJvY2VkdXJlIHdpbGwNICAgcmVzdWx0IGluIGhpZ2ggb3ZlcmhlYWQgaW4gdGhlIGNvbnRyb2wg cGxhbmUuICBJbiB0dXJuLCB0aGUgaGlnaA0gICBvdmVyaGVhZCB3aWxsIGluY3JlYXNlIHVuaS1k aXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkuICBPbiB0aGUgb3RoZXINICAgaGFuZCBpZiB0aGUg cmF0ZSBpcyB0b28gbG93LCB0aGUgc2FtcGxlIGNvdWxkIG5vdCBjb21wbGV0ZWx5IHJlZmxlY3QN ICAgdGhlIGR5bmFtaWMgcHJvdmlzaW9uaW5nIHBlcmZvcm1hbmNlIG9mIHRoZSBHTVBMUyBuZXR3 b3JrLiAgVGhlDSAgIGFwcHJvcHJpYXRlIGxhbWJkYSBhbmQgbGFtYmRhX20gdmFsdWUgZGVwZW5k cyBvbiB0aGUgZ2l2ZW4gbmV0d29yay4NDSAgIFRoZSBwYXJhbWV0ZXJzIFRkIHNob3VsZCBiZSBj YXJlZnVsbHkgY2hvc2VuLiAgRGlmZmVyZW50IHN3aXRjaGluZw0gICB0ZWNobm9sb2dpZXMgbWF5 IHZhcnkgc2lnbmlmaWNhbnRseSBpbiBwZXJmb3JtaW5nIGEgY3Jvc3MtY29ubmVjdA0gICBvcGVy YXRpb24uICBBdCB0aGUgc2FtZSB0aW1lLCB0aGUgdGltZSBuZWVkZWQgaW4gc2V0dGluZyB1cCBh biBMU1ANICAgdW5kZXIgZGlmZmVyZW50IHRyYWZmaWMgbWF5IGFsc28gdmFyeSBzaWduaWZpY2Fu dGx5Lg0NMTAuNi4gIE1ldGhvZG9sb2dpZXMNDSAgIG8gIFNlbGVjdCB0aGUgdGltZXMgdXNpbmcg dGhlIHNwZWNpZmllZCBQb2lzc29uIGFycml2YWwgcHJvY2VzcywgYW5kDQ0gICBvICBTZXQgdXAg dGhlIExTUCBhcyB0aGUgbWV0aG9kb2xvZ3kgZm9yIHRoZSBzaW5nbGV0b24gbXVsdGlwbGUgdW5p LQ0gICAgICBkaXJlY3Rpb25hbCBMU1BzIHNldHVwIGRlbGF5LCBhbmQgb2J0YWluIHRoZSB2YWx1 ZSBvZiBtdWx0aXBsZQ0gICAgICB1bmktZGlyZWN0aW9uYWwgTFNQcyBzZXR1cCBkZWxheQ0NICAg byAgUmVsZWFzZSB0aGUgTFNQIGFmdGVyIFRoLCBhbmQgd2FpdCBmb3IgdGhlIG5leHQgUG9pc3Nv biBhcnJpdmFsDSAgICAgIGV2ZW50DQ0gICBOb3RlIHRoYXQ6IGl0IGlzIHBvc3NpYmxlIHRoYXQg YmVmb3JlIHRoZSBwcmV2aW91cyBMU1AgcmVsZWFzZQ0gICBwcm9jZWR1cmUgY29tcGxldGVzLCB0 aGUgbmV4dCBQb2lzc29uIGFycml2YWwgZXZlbnQgYXJyaXZlcyBhbmQgdGhlDSAgIExTUCBzZXR1 cCBwcm9jZWR1cmUgaXMgaW5pdGlhdGVkLiAgSWYgdGhlcmUgaXMgcmVzb3VyY2UgY29udGVudGlv bg0gICBiZXR3ZWVuIHRoZSB0d28gTFNQcywgdGhlIExTUCBzZXR1cCBtYXkgZmFpbC4gIFdheXMg dG8gYXZvaWQgc3VjaA0gICBjb250ZW50aW9uIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0NMTAuNy4gIFR5cGljYWwgdGVzdGluZyBjYXNlcw0NDQ0NDQ1TdW4gJiBaaGFu ZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFn ZSAzMF0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3 b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0xMC43LjEuICBXaXRoIE5vIExTUCBpbiB0aGUgTmV0 d29yaw0NMTAuNy4xLjEuICBNb3RpdmF0aW9uDQ0gICBNdWx0aXBsZSB1bmktZGlyZWN0aW9uYWwg TFNQIHNldHVwIGRlbGF5IHdpdGggbm8gTFNQIGluIHRoZSBuZXR3b3JrDSAgIGlzIGltcG9ydGFu dCBiZWNhdXNlIHRoaXMgcmVmbGVjdHMgdGhlIGluaGVyZW50IGRlbGF5IG9mIGFuIFJTVlAtVEUN ICAgaW1wbGVtZW50YXRpb24uICBUaGUgbWluaW11bSB2YWx1ZSBwcm92aWRlcyBhbiBpbmRpY2F0 aW9uIG9mIHRoZQ0gICBkZWxheSB0aGF0IHdpbGwgbGlrZWx5IGJlIGV4cGVyaWVuY2VkIHdoZW4g TFNQcyB0cmF2ZXJzZSB0aGUgc2hvcnRlc3QNICAgcm91dGUgd2l0aCB0aGUgbGlnaHRlc3QgbG9h ZCBpbiB0aGUgY29udHJvbCBwbGFuZS4NDTEwLjcuMS4yLiAgTWV0aG9kb2xvZ2llcw0NICAgTWFr ZSBzdXJlIHRoYXQgdGhlcmUgaXMgbm8gTFNQIGluIHRoZSBuZXR3b3JrLCBhbmQgcHJvY2VlZCB3 aXRoIHRoZQ0gICBtZXRob2RvbG9naWVzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEwLjYuDQ0xMC43 LjIuICBXaXRoIGEgTnVtYmVyIG9mIExTUHMgaW4gdGhlIE5ldHdvcmsNDTEwLjcuMi4xLiAgTW90 aXZhdGlvbg0NICAgTXVsdGlwbGUgdW5pLWRpcmVjdGlvbmFsIExTUHMgc2V0dXAgZGVsYXkgd2l0 aCBhIG51bWJlciBvZiBMU1BzIGluDSAgIHRoZSBuZXR3b3JrIGlzIGltcG9ydGFudCBiZWNhdXNl IGl0IHJlZmxlY3RzIHRoZSBwZXJmb3JtYW5jZSBvZiBhbg0gICBvcGVyYXRpb25hbCBuZXR3b3Jr IHdpdGggY29uc2lkZXJhYmxlIGxvYWQuICBUaGlzIGRlbGF5IGNhbiB2YXJ5DSAgIHNpZ25pZmlj YW50bHkgYXMgdGhlIG51bWJlciBvZiBleGlzdGluZyBMU1BzIHZhcnkuICBJdCBjYW4gYmUgdXNl ZCBhcw0gICBhIHNjYWxhYmlsaXR5IG1ldHJpYyBvZiBhbiBSU1ZQLVRFIGltcGxlbWVudGF0aW9u Lg0NMTAuNy4yLjIuICBNZXRob2RvbG9naWVzDQ0gICBTZXR1cCB0aGUgcmVxdWlyZWQgbnVtYmVy IG9mIExTUHMsIGFuZCB3YWl0IHVudGlsIHRoZSBuZXR3b3JrIHJlYWNoZXMNICAgYSBzdGFibGUg c3RhdGUsIHRoZW4gcHJvY2VlZCB3aXRoIHRoZSBtZXRob2RvbG9naWVzIGRlc2NyaWJlZCBpbg0g ICBTZWN0aW9uIDEwLjYuLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAzMV0NDQ1J bnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAg ICAgICBKdWx5IDIwMDkNDQ0xMS4gIEEgRGVmaW5pdGlvbiBmb3IgU2FtcGxlcyBvZiBTaW5nbGUg QmktZGlyZWN0aW9uYWwgIExTUCBTZXR1cCBEZWxheQ0NICAgSW4gU2VjdGlvbiA2LCB3ZSBoYXZl IGRlZmluZWQgdGhlIHNpbmdsZXRvbiBtZXRyaWMgb2YgU2luZ2xlIEJpLQ0gICBkaXJlY3Rpb25h bCBMU1Agc2V0dXAgZGVsYXkuICBOb3cgd2UgZGVmaW5lIGhvdyB0byBnZXQgb25lIHBhcnRpY3Vs YXINICAgc2FtcGxlIG9mIFNpbmdsZSBCaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkuICBT YW1wbGluZyBpcyB0bw0gICBzZWxlY3QgYSBwYXJ0aWN1bGFyIHBvdGlvbiBvZiBzaW5nbGV0b24g dmFsdWVzIG9mIHRoZSBnaXZlbg0gICBwYXJhbWV0ZXJzLiAgTGlrZSBpbiBbUkZDMjMzMF0sIHdl IHVzZSBQb2lzc29uIHNhbXBsaW5nIGFzIGFuDSAgIGV4YW1wbGUuDQ0xMS4xLiAgTWV0cmljIE5h bWUNDSAgIFNpbmdsZSBCaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgc2FtcGxlIHdpdGgg bm8gTFNQIGluIHRoZQ0gICBuZXR3b3JrDQ0xMS4yLiAgTWV0cmljIFBhcmFtZXRlcnMNDSAgIG8g IElEMCwgdGhlIGluZ3Jlc3MgTFNSIElEDQ0gICBvICBJRDEsIHRoZSBlZ3Jlc3MgTFNSIElEDQ0g ICBvICBUMCwgYSB0aW1lDQ0gICBvICBUZiwgYSB0aW1lDQ0gICBvICBMYW1iZGEsIGEgcmF0ZSBp biB0aGUgcmVjaXByb2NhbCBtaWxsaXNlY29uZHMNDSAgIG8gIFRoLCBMU1AgaG9sZGluZyB0aW1l DQ0gICBvICBUZCwgdGhlIG1heGltdW0gd2FpdGluZyB0aW1lIGZvciBzdWNjZXNzZnVsIHNldHVw DQ0xMS4zLiAgTWV0cmljIFVuaXRzDQ0gICBBIHNlcXVlbmNlIG9mIHBhaXJzOyB0aGUgZWxlbWVu dHMgb2YgZWFjaCBwYWlyIGFyZToNDSAgIG8gIFQsIGEgdGltZSB3aGVuIHNldHVwIGlzIGF0dGVt cHRlZA0NICAgbyAgZFQsIGVpdGhlciBhIHJlYWwgbnVtYmVyIG9yIGFuIHVuZGVmaW5lZCBudW1i ZXIgb2YgbWlsbGlzZWNvbmRzLg0NMTEuNC4gIERlZmluaXRpb24NDSAgIEdpdmVuIFQwLCBUZiwg YW5kIGxhbWJkYSwgY29tcHV0ZSBhIHBzZXVkby1yYW5kb20gUG9pc3NvbiBwcm9jZXNzDSAgIGJl Z2lubmluZyBhdCBvciBiZWZvcmUgVDAsIHdpdGggYXZlcmFnZSBhcnJpdmFsIHJhdGUgbGFtYmRh LCBhbmQNICAgZW5kaW5nIGF0IG9yIGFmdGVyIFRmLiAgVGhvc2UgdGltZSB2YWx1ZXMgZ3JlYXRl ciB0aGFuIG9yIGVxdWFsIHRvIFQwDSAgIGFuZCBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gVGYgYXJl IHRoZW4gc2VsZWN0ZWQuICBBdCBlYWNoIG9mIHRoZSB0aW1lcw0gICBpbiB0aGlzIHByb2Nlc3Ms IHdlIG9idGFpbiB0aGUgdmFsdWUgb2YgQmktZGlyZWN0aW9uYWwgTFNQIHNldHVwDSAgIGRlbGF5 IHNhbXBsZSBhdCB0aGlzIHRpbWUuICBUaGUgdmFsdWUgb2YgdGhlIHNhbXBsZSBpcyB0aGUgc2Vx dWVuY2UNICAgbWFkZSB1cCBvZiB0aGUgcmVzdWx0aW5nIDx0aW1lLCBMU1Agc2V0dXAgZGVsYXk+ IHBhaXJzLiAgSWYgdGhlcmUgYXJlDSAgIG5vIHN1Y2ggcGFpcnMsIHRoZSBzZXF1ZW5jZSBpcyBv ZiBsZW5ndGggemVybyBhbmQgdGhlIHNhbXBsZSBpcyBzYWlkDQ0NDVN1biAmIFpoYW5nICAgICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDMyXQ0N DUludGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAg ICAgICAgIEp1bHkgMjAwOQ0NDSAgIHRvIGJlIGVtcHR5Lg0NMTEuNS4gIERpc2N1c3Npb24NDSAg IFRoZSBwYXJhbWV0ZXJzIGxhbWJkYSBzaG91bGQgYmUgY2FyZWZ1bGx5IGNob3Nlbi4gIElmIHRo ZSByYXRlIGlzIHRvbw0gICBoaWdoLCB0b28gZnJlcXVlbnQgTFNQIHNldHVwL3JlbGVhc2UgcHJv Y2VkdXJlIHdpbGwgcmVzdWx0IGluIGhpZ2gNICAgb3ZlcmhlYWQgaW4gdGhlIGNvbnRyb2wgcGxh bmUuICBJbiB0dXJuLCB0aGUgaGlnaCBvdmVyaGVhZCB3aWxsDSAgIGluY3JlYXNlIEJpLWRpcmVj dGlvbmFsIExTUCBzZXR1cCBkZWxheS4gIE9uIHRoZSBvdGhlciBoYW5kIGlmIHRoZQ0gICByYXRl IGlzIHRvbyBsb3csIHRoZSBzYW1wbGUgY291bGQgbm90IGNvbXBsZXRlbHkgcmVmbGVjdCB0aGUg ZHluYW1pYw0gICBwcm92aXNpb25pbmcgcGVyZm9ybWFuY2Ugb2YgdGhlIEdNUExTIG5ldHdvcmsu ICBUaGUgYXBwcm9wcmlhdGUNICAgbGFtYmRhIHZhbHVlIGRlcGVuZHMgb24gdGhlIGdpdmVuIG5l dHdvcmsuDQ0gICBUaGUgcGFyYW1ldGVycyBUZCBzaG91bGQgYmUgY2FyZWZ1bGx5IGNob3Nlbi4g IERpZmZlcmVudCBzd2l0Y2hpbmcNICAgdGVjaG5vbG9naWVzIG1heSB2YXJ5IHNpZ25pZmljYW50 bHkgaW4gcGVyZm9ybWluZyBhIGNyb3NzLWNvbm5lY3QNICAgb3BlcmF0aW9uLiAgQXQgdGhlIHNh bWUgdGltZSwgdGhlIHRpbWUgbmVlZGVkIGluIHNldHRpbmcgdXAgYW4gTFNQDSAgIHVuZGVyIGRp ZmZlcmVudCB0cmFmZmljIG1heSBhbHNvIHZhcnkgc2lnbmlmaWNhbnRseS4NDSAgIEluIHRoZSBj YXNlIG9mIGFjdGl2ZSBtZWFzdXJlbWVudCwgdGhlIHBhcmFtZXRlcnMgVGggc2hvdWxkIGJlDSAg IGNhcmVmdWxseSBjaG9zZW4uICBUaGUgY29tYmluYXRpb24gb2YgbGFtYmRhIGFuZCBUaCByZWZs ZWN0cyB0aGUgbG9hZA0gICBvZiB0aGUgbmV0d29yay4gIFRoZSBzZWxlY3Rpb24gb2YgVGggU0hP VUxEIHRha2UgaW50byBhY2NvdW50IHRoYXQNICAgdGhlIG5ldHdvcmsgaGFzIHN1ZmZpY2llbnQg cmVzb3VyY2UgdG8gcGVyZm9ybSBzdWJzZXF1ZW50IHRlc3RzLiAgVGhlDSAgIHZhbHVlIG9mIFRo IE1BWSBiZSBjb25zdGFudCBkdXJpbmcgb25lIHNhbXBsaW5nIHByb2Nlc3MgZm9yDSAgIHNpbXBs aWNpdHkgY29uc2lkZXJhdGlvbnMuDQ0gICBOb3RlIHRoYXQgZm9yIG9ubGluZSBvciBwYXNzaXZl IG1lYXN1cmVtZW50cywgdGhlIGFycml2YWwgcmF0ZSBhbmQNICAgdGhlIExTUCBob2xkaW5nIHRp bWUgYXJlIGRldGVybWluZWQgYnkgYWN0dWFsIHRyYWZmaWMsIGhlbmNlIGluIHRoaXMNICAgY2Fz ZSBMYW1iZGEgYW5kIFRoIGFyZSBub3QgYW4gaW5wdXQgcGFyYW1ldGVyLg0NMTEuNi4gIE1ldGhv ZG9sb2dpZXMNDSAgIG8gIFNlbGVjdCB0aGUgdGltZXMgdXNpbmcgdGhlIHNwZWNpZmllZCBQb2lz c29uIGFycml2YWwgcHJvY2VzcywgYW5kDQ0gICBvICBTZXQgdXAgdGhlIExTUCBhcyB0aGUgbWV0 aG9kb2xvZ3kgZm9yIHRoZSBzaW5nbGV0b24gYmktZGlyZWN0aW9uYWwNICAgICAgTFNQIHNldHVw IGRlbGF5LCBhbmQgb2J0YWluIHRoZSB2YWx1ZSBvZiBiaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAN ICAgICAgZGVsYXkNDSAgIG8gIFJlbGVhc2UgdGhlIExTUCBhZnRlciBUaCwgYW5kIHdhaXQgZm9y IHRoZSBuZXh0IFBvaXNzb24gYXJyaXZhbA0gICAgICBldmVudA0NICAgTm90ZSB0aGF0OiBpdCBp cyBwb3NzaWJsZSB0aGF0IGJlZm9yZSB0aGUgcHJldmlvdXMgTFNQIHJlbGVhc2UNICAgcHJvY2Vk dXJlIGNvbXBsZXRlcywgdGhlIG5leHQgUG9pc3NvbiBhcnJpdmFsIGV2ZW50IGFycml2ZXMgYW5k IHRoZQ0gICBMU1Agc2V0dXAgcHJvY2VkdXJlIGlzIGluaXRpYXRlZC4gIElmIHRoZXJlIGlzIHJl c291cmNlIGNvbnRlbnRpb24NICAgYmV0d2VlbiB0aGUgdHdvIExTUHMsIHRoZSBMU1Agc2V0dXAg bWF5IGZhaWwuICBXYXlzIHRvIGF2b2lkIHN1Y2gNICAgY29udGVudGlvbiBhcmUgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NDQ0NDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDMzXQ0NDUludGVy bmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtzICAgICAgICAg IEp1bHkgMjAwOQ0NDTExLjcuICBUeXBpY2FsIHRlc3RpbmcgY2FzZXMNDTExLjcuMS4gIFdpdGgg Tm8gTFNQIGluIHRoZSBOZXR3b3JrDQ0xMS43LjEuMS4gIE1vdGl2YXRpb24NDSAgIFNpbmdsZSBi aS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkgd2l0aCBubyBMU1AgaW4gdGhlIG5ldHdvcmsg aXMNICAgaW1wb3J0YW50IGJlY2F1c2UgdGhpcyByZWZsZWN0cyB0aGUgaW5oZXJlbnQgZGVsYXkg b2YgYW4gUlNWUC1URQ0gICBpbXBsZW1lbnRhdGlvbi4gIFRoZSBtaW5pbXVtIHZhbHVlIHByb3Zp ZGVzIGFuIGluZGljYXRpb24gb2YgdGhlDSAgIGRlbGF5IHRoYXQgd2lsbCBsaWtlbHkgYmUgZXhw ZXJpZW5jZWQgd2hlbiBhbiBMU1AgdHJhdmVyc2VzIHRoZQ0gICBzaG9ydGVzdCByb3V0ZSB3aXRo IHRoZSBsaWdodGVzdCBsb2FkIGluIHRoZSBjb250cm9sIHBsYW5lLg0NMTEuNy4xLjIuICBNZXRo b2RvbG9naWVzDQ0gICBNYWtlIHN1cmUgdGhhdCB0aGVyZSBpcyBubyBMU1AgaW4gdGhlIG5ldHdv cmssIGFuZCBwcm9jZWVkIHdpdGggdGhlDSAgIG1ldGhvZG9sb2dpZXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMTEuNi4NDTExLjcuMi4gIFdpdGggYSBOdW1iZXIgb2YgTFNQcyBpbiB0aGUgTmV0d29y aw0NMTEuNy4yLjEuICBNb3RpdmF0aW9uDQ0gICBTaW5nbGUgYmktZGlyZWN0aW9uYWwgTFNQIHNl dHVwIGRlbGF5IHdpdGggYSBudW1iZXIgb2YgTFNQcyBpbiB0aGUNICAgbmV0d29yayBpcyBpbXBv cnRhbnQgYmVjYXVzZSBpdCByZWZsZWN0cyB0aGUgcGVyZm9ybWFuY2Ugb2YgYW4NICAgb3BlcmF0 aW9uYWwgbmV0d29yayB3aXRoIGNvbnNpZGVyYWJsZSBsb2FkLiAgVGhpcyBkZWxheSBjYW4gdmFy eQ0gICBzaWduaWZpY2FudGx5IGFzIHRoZSBudW1iZXIgb2YgZXhpc3RpbmcgTFNQcyB2YXJpZXMu ICBJdCBjYW4gYmUgdXNlZA0gICBhcyBhIHNjYWxhYmlsaXR5IG1ldHJpYyBvZiBhbiBSU1ZQLVRF IGltcGxlbWVudGF0aW9uLg0NMTEuNy4yLjIuICBNZXRob2RvbG9naWVzDQ0gICBTZXR1cCB0aGUg cmVxdWlyZWQgbnVtYmVyIG9mIExTUHMsIGFuZCB3YWl0IHVudGlsIHRoZSBuZXR3b3JrIHJlYWNo ZXMNICAgYSBzdGFibGUgc3RhdGUsIHRoZW4gcHJvY2VlZCB3aXRoIHRoZSBtZXRob2RvbG9naWVz IGRlc2NyaWJlZCBpbg0gICBTZWN0aW9uIDExLjYuIC4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDVN1biAm IFpoYW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAg IFtQYWdlIDM0XQ0NDUludGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExT IE5ldHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0NDTEyLiAgQSBEZWZpbml0aW9uIGZvciBTYW1w bGVzIG9mIE11bHRpcGxlIEJpLWRpcmVjdGlvbmFsICBMU1BzIFNldHVwDSAgICAgRGVsYXkNDSAg IEluIFNlY3Rpb24gNywgd2UgaGF2ZSBkZWZpbmVkIHRoZSBzaW5nbGV0b24gbWV0cmljIG9mIG11 bHRpcGxlIGJpLQ0gICBkaXJlY3Rpb25hbCBMU1BzIHNldHVwIGRlbGF5LiAgTm93IHdlIGRlZmlu ZSBob3cgdG8gZ2V0IG9uZQ0gICBwYXJ0aWN1bGFyIHNhbXBsZSBvZiBtdWx0aXBsZSBiaS1kaXJl Y3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkuDSAgIFNhbXBsaW5nIGlzIHRvIHNlbGVjdCBhIHBhcnRp Y3VsYXIgcG90aW9uIG9mIHNpbmdsZXRvbiB2YWx1ZXMgb2YgdGhlDSAgIGdpdmVuIHBhcmFtZXRl cnMuICBMaWtlIGluIFtSRkMyMzMwXSwgd2UgdXNlIFBvaXNzb24gc2FtcGxpbmcgYXMgYW4NICAg ZXhhbXBsZS4NDTEyLjEuICBNZXRyaWMgTmFtZQ0NICAgTXVsdGlwbGUgYmktZGlyZWN0aW9uYWwg TFNQcyBzZXR1cCBkZWxheSBzYW1wbGUNDTEyLjIuICBNZXRyaWMgUGFyYW1ldGVycw0NICAgbyAg SUQwLCB0aGUgaW5ncmVzcyBMU1IgSUQNDSAgIG8gIElEMSwgdGhlIGVncmVzcyBMU1IgSUQNDSAg IG8gIFQwLCBhIHRpbWUNDSAgIG8gIFRmLCBhIHRpbWUNDSAgIG8gIExhbWJkYV9tLCBhIHJhdGUg aW4gdGhlIHJlY2lwcm9jYWwgbWlsbGlzZWNvbmRzDQ0gICBvICBMYW1iZGEsIGEgcmF0ZSBpbiB0 aGUgcmVjaXByb2NhbCBtaWxsaXNlY29uZHMNDSAgIG8gIFgsIHRoZSBudW1iZXIgb2YgTFNQcyB0 byBzZXR1cA0NICAgbyAgVGgsIExTUCBob2xkaW5nIHRpbWUNDSAgIG8gIFRkLCB0aGUgbWF4aW11 bSB3YWl0aW5nIHRpbWUgZm9yIHN1Y2Nlc3NmdWwgbXVsdGlwbGUgdW5pLQ0gICAgICBkaXJlY3Rp b25hbCBMU1BzIHNldHVwDQ0xMi4zLiAgTWV0cmljIFVuaXRzDQ0gICBBIHNlcXVlbmNlIG9mIHBh aXJzOyB0aGUgZWxlbWVudHMgb2YgZWFjaCBwYWlyIGFyZToNDSAgIG8gIFQsIGEgdGltZSB3aGVu IHRoZSBmaXJzdCBzZXR1cCBpcyBhdHRlbXB0ZWQNDSAgIG8gIGRULCBlaXRoZXIgYSByZWFsIG51 bWJlciBvciBhbiB1bmRlZmluZWQgbnVtYmVyIG9mIG1pbGxpc2Vjb25kcy4NDTEyLjQuICBEZWZp bml0aW9uDQ0gICBHaXZlbiBUMCwgVGYsIGFuZCBsYW1iZGEsIGNvbXB1dGUgYSBwc2V1ZG8tcmFu ZG9tIFBvaXNzb24gcHJvY2Vzcw0gICBiZWdpbm5pbmcgYXQgb3IgYmVmb3JlIFQwLCB3aXRoIGF2 ZXJhZ2UgYXJyaXZhbCByYXRlIGxhbWJkYSwgYW5kDSAgIGVuZGluZyBhdCBvciBhZnRlciBUZi4g IFRob3NlIHRpbWUgdmFsdWVzIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byBUMA0NDQ1TdW4gJiBa aGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBb UGFnZSAzNV0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBO ZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0gICBhbmQgbGVzcyB0aGFuIG9yIGVxdWFsIHRv IFRmIGFyZSB0aGVuIHNlbGVjdGVkLiAgQXQgZWFjaCBvZiB0aGUgdGltZXMNICAgaW4gdGhpcyBw cm9jZXNzLCB3ZSBvYnRhaW4gdGhlIHZhbHVlIG9mIG11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBM U1ANICAgc2V0dXAgZGVsYXkgc2FtcGxlIGF0IHRoaXMgdGltZS4gIFRoZSB2YWx1ZSBvZiB0aGUg c2FtcGxlIGlzIHRoZQ0gICBzZXF1ZW5jZSBtYWRlIHVwIG9mIHRoZSByZXN1bHRpbmcgPHRpbWUs IHNldHVwIGRlbGF5PiBwYWlycy4gIElmDSAgIHRoZXJlIGFyZSBubyBzdWNoIHBhaXJzLCB0aGUg c2VxdWVuY2UgaXMgb2YgbGVuZ3RoIHplcm8gYW5kIHRoZQ0gICBzYW1wbGUgaXMgc2FpZCB0byBi ZSBlbXB0eS4NDTEyLjUuICBEaXNjdXNzaW9uDQ0gICBUaGUgcGFyYW1ldGVyIGxhbWJkYSBpcyB1 c2VkIGFzIGFycml2YWwgcmF0ZSBvZiAiYmFjdGggYmktZGlyZWN0aW9uYWwNICAgTFNQcyBzZXR1 cCIgb3BlcmF0aW9uLiAgSXQgcmVndWxhdGVzIHRoZSBpbnRlcnZhbCBpbiBiZXR3ZWVuIGVhY2gN ICAgYmF0Y2ggb3BlcmF0aW9uLiAgVGhlIHBhcmFtZXRlciBsYW1iZGFfbSBpcyB1c2VkIHdpdGhp biBlYWNoIGJhdGNoDSAgIG9wZXJhdGlvbiwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4NDSAg IFRoZSBwYXJhbWV0ZXJzIGxhbWJkYSBhbmQgbGFtYmRhX20gc2hvdWxkIGJlIGNhcmVmdWxseSBj aG9zZW4uICBJZg0gICB0aGUgcmF0ZSBpcyB0b28gaGlnaCwgdG9vIGZyZXF1ZW50IExTUCBzZXR1 cC9yZWxlYXNlIHByb2NlZHVyZSB3aWxsDSAgIHJlc3VsdCBpbiBoaWdoIG92ZXJoZWFkIGluIHRo ZSBjb250cm9sIHBsYW5lLiAgSW4gdHVybiwgdGhlIGhpZ2gNICAgb3ZlcmhlYWQgd2lsbCBpbmNy ZWFzZSB1bmktZGlyZWN0aW9uYWwgTFNQIHNldHVwIGRlbGF5LiAgT24gdGhlIG90aGVyDSAgIGhh bmQgaWYgdGhlIHJhdGUgaXMgdG9vIGxvdywgdGhlIHNhbXBsZSBjb3VsZCBub3QgY29tcGxldGVs eSByZWZsZWN0DSAgIHRoZSBkeW5hbWljIHByb3Zpc2lvbmluZyBwZXJmb3JtYW5jZSBvZiB0aGUg R01QTFMgbmV0d29yay4gIFRoZQ0gICBhcHByb3ByaWF0ZSBsYW1iZGEgYW5kIGxhbWJkYV9tIHZh bHVlIGRlcGVuZHMgb24gdGhlIGdpdmVuIG5ldHdvcmsuDQ0gICBUaGUgcGFyYW1ldGVycyBUZCBz aG91bGQgYmUgY2FyZWZ1bGx5IGNob3Nlbi4gIERpZmZlcmVudCBzd2l0Y2hpbmcNICAgdGVjaG5v bG9naWVzIG1heSB2YXJ5IHNpZ25pZmljYW50bHkgaW4gcGVyZm9ybWluZyBhIGNyb3NzLWNvbm5l Y3QNICAgb3BlcmF0aW9uLiAgQXQgdGhlIHNhbWUgdGltZSwgdGhlIHRpbWUgbmVlZGVkIGluIHNl dHRpbmcgdXAgYW4gTFNQDSAgIHVuZGVyIGRpZmZlcmVudCB0cmFmZmljIG1heSBhbHNvIHZhcnkg c2lnbmlmaWNhbnRseS4NDTEyLjYuICBNZXRob2RvbG9naWVzDQ0gICBvICBTZWxlY3QgdGhlIHRp bWVzIHVzaW5nIHRoZSBzcGVjaWZpZWQgUG9pc3NvbiBhcnJpdmFsIHByb2Nlc3MsIGFuZA0NICAg byAgU2V0IHVwIHRoZSBMU1AgYXMgdGhlIG1ldGhvZG9sb2d5IGZvciB0aGUgc2luZ2xldG9uIG11 bHRpcGxlIGJpLQ0gICAgICBkaXJlY3Rpb25hbCBMU1BzIHNldHVwIGRlbGF5LCBhbmQgb2J0YWlu IHRoZSB2YWx1ZSBvZiBtdWx0aXBsZQ0gICAgICB1bmktZGlyZWN0aW9uYWwgTFNQcyBzZXR1cCBk ZWxheQ0NICAgbyAgUmVsZWFzZSB0aGUgTFNQIGFmdGVyIFRoLCBhbmQgd2FpdCBmb3IgdGhlIG5l eHQgUG9pc3NvbiBhcnJpdmFsDSAgICAgIGV2ZW50DQ0gICBOb3RlIHRoYXQ6IGl0IGlzIHBvc3Np YmxlIHRoYXQgYmVmb3JlIHRoZSBwcmV2aW91cyBMU1AgcmVsZWFzZQ0gICBwcm9jZWR1cmUgY29t cGxldGVzLCB0aGUgbmV4dCBQb2lzc29uIGFycml2YWwgZXZlbnQgYXJyaXZlcyBhbmQgdGhlDSAg IExTUCBzZXR1cCBwcm9jZWR1cmUgaXMgaW5pdGlhdGVkLiAgSWYgdGhlcmUgaXMgcmVzb3VyY2Ug Y29udGVudGlvbg0gICBiZXR3ZWVuIHRoZSB0d28gTFNQcywgdGhlIExTUCBzZXR1cCBtYXkgZmFp bC4gIFdheXMgdG8gYXZvaWQgc3VjaA0gICBjb250ZW50aW9uIGFyZSBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50Lg0NMTIuNy4gIFR5cGljYWwgdGVzdGluZyBjYXNlcw0NDQ0NDQ1T dW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAg ICAgICBbUGFnZSAzNl0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBH TVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0xMi43LjEuICBXaXRoIE5vIExTUCBp biB0aGUgTmV0d29yaw0NMTIuNy4xLjEuICBNb3RpdmF0aW9uDQ0gICBNdWx0aXBsZSBiaS1kaXJl Y3Rpb25hbCBMU1BzIHNldHVwIGRlbGF5IHdpdGggbm8gTFNQIGluIHRoZSBuZXR3b3JrDSAgIGlz IGltcG9ydGFudCBiZWNhdXNlIHRoaXMgcmVmbGVjdHMgdGhlIGluaGVyZW50IGRlbGF5IG9mIGFu IFJTVlAtVEUNICAgaW1wbGVtZW50YXRpb24uICBUaGUgbWluaW11bSB2YWx1ZSBwcm92aWRlcyBh biBpbmRpY2F0aW9uIG9mIHRoZQ0gICBkZWxheSB0aGF0IHdpbGwgbGlrZWx5IGJlIGV4cGVyaWVu Y2VkIHdoZW4gYW4gTFNQcyB0cmF2ZXJzZSB0aGUNICAgc2hvcnRlc3Qgcm91dGUgd2l0aCB0aGUg bGlnaHRlc3QgbG9hZCBpbiB0aGUgY29udHJvbCBwbGFuZS4NDTEyLjcuMS4yLiAgTWV0aG9kb2xv Z2llcw0NICAgTWFrZSBzdXJlIHRoYXQgdGhlcmUgaXMgbm8gTFNQIGluIHRoZSBuZXR3b3JrLCBh bmQgcHJvY2VlZCB3aXRoIHRoZQ0gICBtZXRob2RvbG9naWVzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDEwLjYuDQ0xMi43LjIuICBXaXRoIGEgTnVtYmVyIG9mIExTUHMgaW4gdGhlIE5ldHdvcmsNDTEy LjcuMi4xLiAgTW90aXZhdGlvbg0NICAgbXVsdGlwbGUgYmktZGlyZWN0aW9uYWwgTFNQcyBzZXR1 cCBkZWxheSB3aXRoIGEgbnVtYmVyIG9mIExTUHMgaW4gdGhlDSAgIG5ldHdvcmsgaXMgaW1wb3J0 YW50IGJlY2F1c2UgaXQgcmVmbGVjdHMgdGhlIHBlcmZvcm1hbmNlIG9mIGFuDSAgIG9wZXJhdGlv bmFsIG5ldHdvcmsgd2l0aCBjb25zaWRlcmFibGUgbG9hZC4gIFRoaXMgZGVsYXkgbWF5IHZhcnkN ICAgc2lnbmlmaWNhbnRseSBhcyB0aGUgbnVtYmVyIG9mIGV4aXN0aW5nIExTUHMgdmFyeS4gIEl0 IG1heSBiZSB1c2VkIGFzDSAgIGEgc2NhbGFiaWxpdHkgbWV0cmljIG9mIGFuIFJTVlAtVEUgaW1w bGVtZW50YXRpb24uDQ0xMi43LjIuMi4gIE1ldGhvZG9sb2dpZXMNDSAgIFNldHVwIHRoZSByZXF1 aXJlZCBudW1iZXIgb2YgTFNQcywgYW5kIHdhaXQgdW50aWwgdGhlIG5ldHdvcmsgcmVhY2hlcw0g ICBhIHN0YWJsZSBzdGF0ZSwgdGhlbiBwcm9jZWVkIHdpdGggdGhlIG1ldGhvZG9sb2dpZXMgZGVz Y3JpYmVkIGluDSAgIFNlY3Rpb24gMTIuNi4uDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDVN1biAmIFpo YW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQ YWdlIDM3XQ0NDUludGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5l dHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0NDTEzLiAgQSBEZWZpbml0aW9uIGZvciBTYW1wbGVz IG9mIExTUCBHcmFjZWZ1bCBSZWxlYXNlIERlbGF5DQ0gICBJbiBTZWN0aW9uIDgsIHdlIGhhdmUg ZGVmaW5lZCB0aGUgc2luZ2xldG9uIG1ldHJpYyBvZiBMU1AgZ3JhY2VmdWwNICAgcmVsZWFzZSBk ZWxheS4gIE5vdyB3ZSBkZWZpbmUgaG93IHRvIGdldCBvbmUgcGFydGljdWxhciBzYW1wbGUgb2Yg TFNQDSAgIGdyYWNlZnVsIHJlbGVhc2UgZGVsYXkuICBXZSBhbHNvIHVzZSBQb2lzc29uIHNhbXBs aW5nIGFzIGFuIGV4YW1wbGUuDQ0xMy4xLiAgTWV0cmljIE5hbWUNDSAgIExTUCBncmFjZWZ1bCBy ZWxlYXNlIGRlbGF5IHNhbXBsZQ0NMTMuMi4gIE1ldHJpYyBQYXJhbWV0ZXJzDQ0gICBvICBJRDAs IHRoZSBpbmdyZXNzIExTUiBJRA0NICAgbyAgSUQxLCB0aGUgZWdyZXNzIExTUiBJRA0NICAgbyAg VDAsIGEgdGltZQ0NICAgbyAgVGYsIGEgdGltZQ0NICAgbyAgTGFtYmRhLCBhIHJhdGUgaW4gcmVj aXByb2NhbCBtaWxsaXNlY29uZHMNDSAgIG8gIFRkLCB0aGUgbWF4aW11bSB3YWl0aW5nIHRpbWUg Zm9yIHN1Y2Nlc3NmdWwgTFNQIHJlbGVhc2UNDTEzLjMuICBNZXRyaWMgVW5pdHMNDSAgIEEgc2Vx dWVuY2Ugb2YgcGFpcnM7IHRoZSBlbGVtZW50cyBvZiBlYWNoIHBhaXIgYXJlOg0NICAgbyAgVCwg YSB0aW1lLCBhbmQNDSAgIG8gIGRULCBlaXRoZXIgYSByZWFsIG51bWJlciBvciBhbiB1bmRlZmlu ZWQgbnVtYmVyIG9mIG1pbGxpc2Vjb25kcy4NDTEzLjQuICBEZWZpbml0aW9uDQ0gICBHaXZlbiBU MCwgVGYsIGFuZCBsYW1iZGEsIHdlIGNvbXB1dGUgYSBwc2V1ZG8tcmFuZG9tIFBvaXNzb24gcHJv Y2Vzcw0gICBiZWdpbm5pbmcgYXQgb3IgYmVmb3JlIFQwLCB3aXRoIGF2ZXJhZ2UgYXJyaXZhbCBy YXRlIGxhbWJkYSwgYW5kDSAgIGVuZGluZyBhdCBvciBhZnRlciBUZi4gIFRob3NlIHRpbWUgdmFs dWVzIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byBUMA0gICBhbmQgbGVzcyB0aGFuIG9yIGVxdWFs IHRvIFRmIGFyZSB0aGVuIHNlbGVjdGVkLiAgQXQgZWFjaCBvZiB0aGUgdGltZXMNICAgaW4gdGhp cyBwcm9jZXNzLCB3ZSBvYnRhaW4gdGhlIHZhbHVlIG9mIExTUCBncmFjZWZ1bCByZWxlYXNlIGRl bGF5DSAgIHNhbXBsZSBhdCB0aGlzIHRpbWUuICBUaGUgdmFsdWUgb2YgdGhlIHNhbXBsZSBpcyB0 aGUgc2VxdWVuY2UgbWFkZSB1cA0gICBvZiB0aGUgcmVzdWx0aW5nIDx0aW1lLCBMU1AgZ3JhY2Vm dWwgZGVsYXk+IHBhaXJzLiAgSWYgdGhlcmUgYXJlIG5vDSAgIHN1Y2ggcGFpcnMsIHRoZSBzZXF1 ZW5jZSBpcyBvZiBsZW5ndGggemVybyBhbmQgdGhlIHNhbXBsZSBpcyBzYWlkIHRvDSAgIGJlIGVt cHR5Lg0NMTMuNS4gIERpc2N1c3Npb24NDSAgIFRoZSBwYXJhbWV0ZXIgbGFtYmRhIHNob3VsZCBi ZSBjYXJlZnVsbHkgY2hvc2VuLiAgSWYgdGhlIHJhdGUgaXMgdG9vDSAgIGxhcmdlLCB0b28gZnJl cXVlbnQgTFNQIHNldHVwL3JlbGVhc2UgcHJvY2VkdXJlIHdpbGwgcmVzdWx0IGluIGhpZ2gNDQ0N U3VuICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAg ICAgICAgW1BhZ2UgMzhdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4g R01QTFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NICAgb3ZlcmhlYWQgaW4gdGhlIGNv bnRyb2wgcGxhbmUuICBJbiB0dXJuLCB0aGUgaGlnaCBvdmVyaGVhZCB3aWxsDSAgIGluY3JlYXNl IHVuaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXAgZGVsYXkuICBPbiB0aGUgb3RoZXIgaGFuZCBpZiB0 aGUNICAgcmF0ZSBpcyB0b28gc21hbGwsIHRoZSBzYW1wbGUgY291bGQgbm90IGNvbXBsZXRlbHkg cmVmbGVjdCB0aGUNICAgZHluYW1pYyBwcm92aXNpb25pbmcgcGVyZm9ybWFuY2Ugb2YgdGhlIEdN UExTIG5ldHdvcmsuICBUaGUNICAgYXBwcm9wcmlhdGUgbGFtYmRhIHZhbHVlIGRlcGVuZHMgb24g dGhlIGdpdmVuIG5ldHdvcmsuDQ0xMy42LiAgTWV0aG9kb2xvZ2llcw0NICAgR2VuZXJhbGx5IHRo ZSBtZXRob2RvbG9neSB3b3VsZCBwcm9jZWVkIGFzIGZvbGxvd3M6DQ0gICBvICBTZXR1cCB0aGUg TFNQIHRvIGJlIGRlbGV0ZWQNDSAgIG8gIFNlbGVjdCB0aGUgdGltZXMgdXNpbmcgdGhlIHNwZWNp ZmllZCBQb2lzc29uIGFycml2YWwgcHJvY2VzcywgYW5kDQ0gICBvICBSZWxlYXNlIHRoZSBMU1Ag YXMgdGhlIG1ldGhvZG9sb2d5IGZvciB0aGUgc2luZ2xldG9uIExTUCBncmFjZWZ1bA0gICAgICBy ZWxlYXNlIGRlbGF5LCBhbmQgb2J0YWluIHRoZSB2YWx1ZSBvZiBMU1AgZ3JhY2VmdWwgcmVsZWFz ZSBkZWxheQ0NICAgbyAgU2V0dXAgdGhlIExTUCwgYW5kIHJlc3RhcnQgdGhlIFBvaXNzb24gYXJy aXZhbCBwcm9jZXNzLCB3YWl0IGZvcg0gICAgICB0aGUgbmV4dCBQb2lzc29uIGFycml2YWwgZXZl bnQNDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAzOV0NDQ1JbnRl cm5ldC1EcmFmdCAgICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAg ICBKdWx5IDIwMDkNDQ0xNC4gIFNvbWUgU3RhdGlzdGljcyBEZWZpbml0aW9ucyBmb3IgTWV0cmlj cyB0byBSZXBvcnQNDSAgIEdpdmVuIHRoZSBzYW1wbGVzIG9mIHRoZSBwZXJmb3JtYW5jZSBtZXRy aWMsIHdlIG5vdyBvZmZlciBzZXZlcmFsDSAgIHN0YXRpc3RpY3Mgb2YgdGhlc2Ugc2FtcGxlcyB0 byByZXBvcnQuICBGcm9tIHRoZXNlIHN0YXRpc3RpY3MsIHdlIGNhbg0gICBkcmF3IHNvbWUgdXNl ZnVsIGNvbmNsdXNpb25zIG9mIGEgR01QTFMgbmV0d29yay4gIFRoZSB2YWx1ZSBvZiB0aGVzZQ0g ICBtZXRyaWNzIGlzIGVpdGhlciBhIHJlYWwgbnVtYmVyLCBvciBhbiB1bmRlZmluZWQgbnVtYmVy IG9mDSAgIG1pbGxpc2Vjb25kcy4gIEluIHRoZSBmb2xsb3dpbmcgZGlzY3Vzc2lvbiwgd2Ugb25s eSBjb25zaWRlciB0aGUNICAgZmluaXRlIHZhbHVlcy4NDTE0LjEuICBUaGUgTWluaW11bSBvZiBN ZXRyaWMNDSAgIFRoZSBtaW5pbXVtIG9mIG1ldHJpYyBpcyB0aGUgbWluaW11bSBvZiBhbGwgdGhl IGRUIHZhbHVlcyBpbiB0aGUNICAgc2FtcGxlLiAgSW4gY29tcHV0aW5nIHRoaXMsIHVuZGVmaW5l ZCB2YWx1ZXMgU0hPVUxEIGJlIHRyZWF0ZWQgYXMNICAgaW5maW5pdGVseSBsYXJnZS4gIE5vdGUg dGhhdCB0aGlzIG1lYW5zIHRoYXQgdGhlIG1pbmltdW0gY291bGQgdGh1cw0gICBiZSB1bmRlZmlu ZWQgaWYgYWxsIHRoZSBkVCB2YWx1ZXMgYXJlIHVuZGVmaW5lZC4gIEluIGFkZGl0aW9uLCB0aGUN ICAgbWV0cmljIG1pbmltdW0gU0hPVUxEIGJlIHNldCB0byB1bmRlZmluZWQgaWYgdGhlIHNhbXBs ZSBpcyBlbXB0eS4NDTE0LjIuICBUaGUgTWVkaWFuIG9mIE1ldHJpYw0NICAgTWV0cmljIG1lZGlh biBpcyB0aGUgbWVkaWFuIG9mIHRoZSBkVCB2YWx1ZXMgaW4gdGhlIGdpdmVuIHNhbXBsZS4gIElu DSAgIGNvbXB1dGluZyB0aGUgbWVkaWFuLCB0aGUgdW5kZWZpbmVkIHZhbHVlcyBNVVNUIE5PVCBi ZSBjb3VudGVkIGluLg0NMTQuMy4gIFRoZSBwZXJjZW50aWxlIG9mIE1ldHJpYw0NICAgR2l2ZW4g YSBtZXRyaWMgYW5kIGEgcGVyY2VudCBYIGJldHdlZW4gMCUgYW5kIDEwMCUsIHRoZSBYdGgNICAg cGVyY2VudGlsZSBvZiBhbGwgdGhlIGRUIHZhbHVlcyBpbiB0aGUgc2FtcGxlBS4gIEluIGFkZGl0 aW9uLCB0aGUNICAgcGVyY2VudGlsZSBpcyB1bmRlZmluZWQgaWYgdGhlIHNhbXBsZSBpcyBlbXB0 eS4NDSAgIEV4YW1wbGU6IHN1cHBvc2Ugd2UgdGFrZSBhIHNhbXBsZSBhbmQgdGhlIHJlc3VsdHMg YXJlOiBTdHJlYW0xID0gPA0gICA8VDEsIDEwMCBtc2VjPiwgPFQyLCAxMTAgbXNlYz4sIDxUMywg dW5kZWZpbmVkPiwgPFQ0LCA5MCBtc2VjPiwgPFQ1LA0gICA1MDAgbXNlYz4gPg0NICAgVGhlbiB0 aGUgNTB0aCBwZXJjZW50aWxlIHdvdWxkIGJlIDExMCBtc2VjLCBzaW5jZSA5MCBtc2VjIGFuZCAx MDANICAgbXNlYyBhcmUgc21hbGxlciwgYW5kIDExMCBhbmQgNTAwIG1zZWMgYXJlIGxhcmdlciAo dW5kZWZpbmVkIHZhbHVlcw0gICBhcmUgbm90IGNvdW50ZWQgaW4pLgUNDTE0LjQuICBGYWlsdXJl IHN0YXRpc3RpY3Mgb2YgTWV0cmljDQ0gICBJbiB0aGUgcHJvY2VzcyBvZiBMU1Agc2V0dXAvcmVs ZWFzZSwgaXQgbWF5IGZhaWwgZHVlIHRvIHZhcmlvdXMNICAgcmVhc29ucy4gIEZvciBleGFtcGxl LCBzZXR1cC9yZWxlYXNlIG1heSBmYWlsIHdoZW4gdGhlIGNvbnRyb2wgcGxhbmUNICAgaXMgb3Zl cmJ1cmRlbmVkIG9yIHdoZW4gdGhlcmUgaXMgcmVzb3VyY2Ugc2hvcnRhZ2UgaW4gb25lIG9mIHRo ZQ0gICBpbnRlcm1lZGlhdGUgbm9kZXMuICBTaW5jZSB0aGUgc2V0dXAvcmVsZWFzZSBmYWlsdXJl IG1heSBoYXZlDSAgIHNpZ25pZmljYW50IGltcGFjdCBvbiBuZXR3b3JrIG9wZXJhdGlvbiwgaXQg aXMgd29ydGh3aGlsZSB0byByZXBvcnQNICAgZWFjaCBmYWlsdXJlIGNhc2VzLCBzbyB0aGF0IGFw cHJvcHJpYXRlIG9wZXJhdGlvbnMgY2FuIGJlIHBlcmZvcm1lZA0gICB0byBjaGVjayB0aGUgcG9z c2libGUgaW1wbGVtZW50YXRpb24sY29uZmlndXJhdGlvbiBvciBvdGhlcg0gICBkZWZpY2llbmNp ZXMuDQ0gICBGaXZlIHR5cGVzIG9mIGZhaWx1cmUgZXZlbnRzIGFyZSBkZWZpbmVkIGluIHByZXZp b3VzIHNlY3Rpb25zOg0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSA0MF0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExT UCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0gICBv ICBTaW5nbGUgVW5pLWRpcmVjdGlvbmFsIExTUCBTZXR1cCBGYWlsdXJlDQ0gICBvICBNdWx0aXBs ZSBVbmktZGlyZWN0aW9uYWwgTFNQIFNldHVwIEZhaWx1cmUNDSAgIG8gIFNpbmdsZSBCaS1kaXJl Y3Rpb25hbCBMU1AgU2V0dXAgRmFpbHVyZQ0NICAgbyAgTXVsdGlwbGUgQmktZGlyZWN0aW9uYWwg TFNQIFNldHVwIEZhaWx1cmUNDSAgIG8gIExTUCBncmFjZWZ1bCByZWxlYXNlIGZhaWx1cmUNDSAg IEdpdmVuIHRoZSBzYW1wbGVzIG9mIHRoZSBwZXJmb3JtYW5jZSBtZXRyaWMsIHdlIG5vdyBvZmZl ciB0d28NICAgc3RhdGlzdGljcyBvZiBmYWlsdXJlIGV2ZW50cyBvZiB0aGVzZSBzYW1wbGVzIHRv IHJlcG9ydC4NDTE0LjQuMS4gIEZhaWx1cmUgQ291bnQNDSAgIEZhaWx1cmUgQ291bnQgaXMgZGVm aW5lZCBhcyB0aGUgbnVtYmVyIG9mIHRoZSB1bmRlZmluZWQgdmFsdWUgb2YgdGhlDSAgIGNvcnJl c3BvbmRpbmcgcGVyZm9ybWFuY2UgbWV0cmljIChmYWlsdXJlIGV2ZW50cykgaW4gYSBzYW1wbGUu ICBUaGUNICAgdW5pdCBvZiBGYWlsdXJlIENvdW50IGlzIG51bWVyaWNhbC4NDTE0LjQuMi4gIEZh aWx1cmUgUmF0aW8NDSAgIEZhaWx1cmUgUmF0aW8gaXMgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIG51 bWJlciBvZiBmYWlsdXJlIGV2ZW50cyB0bw0gICB0aGUgdG90YWwgbnVtYmVyIG9mIHJlcXVlc3Rz IGluIGEgc2FtcGxlLiAgVGhlIGNhbGN1bGF0aW9uIGZvcg0gICBGYWlsdXJlIFJhdGlvIGlzIGRl ZmluZWQgYXMgZm9sbG93czoNDSAgIFggdHlwZSBmYWlsdXJlIHJhdGlvID0gTnVtYmVyIG9mIFgg dHlwZSBmYWlsdXJlIGV2ZW50cy8oTnVtYmVyIG9mDSAgIHZhbGlkIFggdHlwZSBtZXRyaWMgdmFs dWVzICsgTnVtYmVyIG9mIFggdHlwZSBmYWlsdXJlIGV2ZW50cykgKiAxMDAlLg0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTAs IDIwMTAgICAgICAgICAgICAgICBbUGFnZSA0MV0NDQ1JbnRlcm5ldC1EcmFmdCAgICAgIExTUCBE eW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0xNS4gIERp c2N1c3Npb24NDSAgIEl0IGlzIHdvcnRod2hpbGUgdG8gcG9pbnQgb3V0IHRoYXQ6DQ0gICBvICBU aGUgdW5pLWRpcmVjdGlvbmFsL2JpLWRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBpcyBvbmUg aW5ncmVzcy0NICAgICAgZWdyZXNzIHJvdW5kIHRyaXAgdGltZSBwbHVzIHByb2Nlc3NpbmcgdGlt ZS4gIEJ1dCBpbiB0aGlzDSAgICAgIGRvY3VtZW50LCB1bmktZGlyZWN0aW9uYWwvYmktZGlyZWN0 aW9uYWwgTFNQIHNldHVwIGRlbGF5IGhhcyBub3QNICAgICAgdGFrZW4gdGhlIHByb2Nlc3Npbmcg dGltZSBpbiB0aGUgZW5kIG5vZGVzIChpbmdyZXNzIG9yL2FuZCBlZ3Jlc3MpDSAgICAgIGludG8g YWNjb3VudC4gIFRoZSB0aW1lc3RhbXAgVDIgaXMgdGFrZW4gYWZ0ZXIgdGhlIGVuZHBvaW50IG5v ZGUNICAgICAgcmVjZWl2ZXMgaXQuICBBY3R1YWxseSwgdGhlIGxhc3Qgbm9kZSBoYXMgdG8gdGFr ZSBzb21lIHRpbWUgdG8NICAgICAgcHJvY2VzcyBsb2NhbCBwcm9jZWR1cmUuICBTaW1pbGFybHks IGluIHRoZSBMU1AgZ3JhY2VmdWwgcmVsZWFzZQ0gICAgICBkZWxheSwgdGhlIG1lbW8gaGFzIG5v dCBjb25zaWRlcmVkIHRoZSBwcm9jZXNzaW5nIHRpbWUgaW4gdGhlIGVuZA0gICAgICBub2RlLg0N ICAgbyAgVGhpcyBkb2N1bWVudCBhc3N1bWVzIHRoYXQgdGhlIGNvcnJlY3QgcHJvY2VkdXJlcyBm b3IgaW5zdGFsbGluZw0gICAgICB0aGUgZGF0YSBwbGFuZSBhcmUgZm9sbG93ZWQgYXMgZGVzY3Jp YmVkIGluIFtSRkMzMjA5XSwgW1JGQzM0NzFdLA0gICAgICBhbmQgW1JGQzM0NzNdLiAgVGhhdCBp cywgYnkgdGhlIHRpbWUgdGhlIGVncmVzcyByZWNlaXZlcyBhbmQNICAgICAgcHJvY2Vzc2VzIGEg UGF0aCBtZXNzYWdlLCBpdCBpcyBzYWZlIGZvciB0aGUgZWdyZXNzIHRvIHRyYW5zbWl0DSAgICAg IGRhdGEgb24gdGhlIHJldmVyc2UgcGF0aCwgYW5kIGJ5IHRoZSB0aW1lIHRoZSBpbmdyZXNzIHJl Y2VpdmVzIGFuZA0gICAgICBwcm9jZXNzZXMgYSBSRVNWIG1lc3NhZ2UgaXQgaXMgc2FmZSBmb3Ig dGhlIGluZ3Jlc3MgdG8gdHJhbnNtaXQNICAgICAgZGF0YSBvbiB0aGUgZm9yd2FyZCBwYXRoLiAg U2VlDSAgICAgIFtJLUQuc2hpb21vdG8tY2NhbXAtc3dpdGNoLXByb2dyYW1taW5nXSBmb3IgZGV0 YWlsZWQgZXhwbGFuYXRpb25zLg0gICAgICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGluY2x1ZGUg YW55IHZlcmlmaWNhdGlvbiB0aGF0IHRoZQ0gICAgICBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGNv bnRyb2wgcGxhbmUgc29mdHdhcmUgYXJlIGNvbmZvcm1hbnQsDSAgICAgIGFsdGhvdWdoIHN1Y2gg dGVzdHMgTUFZIGJlIGNvbnN0cnVjdGVkIHdpdGggdGhlIHVzZSBvZiBzdWl0YWJsZQ0gICAgICBz aWduYWwgZ2VuZXJhdGlvbiB0ZXN0IGVxdWlwbWVudC4gIEluIFtJLUQuc3VuLWNjYW1wLWRwbV0s IHdlDSAgICAgIGRlZmluZWQgYSBzZXJpZXMgb2YgbWV0cmljcyB0byBkbyBzdWNoIHZlcmlmaWNh dGlvbnMuICBIb3dldmVyLCBpdA0gICAgICBpcyBSRUNPTU1FTkRFRCB0aGF0IGJvdGggdGhlIG1l YXN1cmVtZW50cyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQNICAgICAgYW5kIHRoZSBtZWFzdXJl bWVudHMgZGVmaW5lZCBpbiBbSS1ELnN1bi1jY2FtcC1kcG1dIGFyZSBwZXJmb3JtZWQNICAgICAg dG8gY29tcGxlbWVudCBlYWNoIG90aGVyLg0NICAgbyAgTm90ZSB0aGF0LCBpbiBpbXBsZW1lbnRp bmcgdGhlIHRlc3RzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGENICAgICAgdGVzdGVyIHNo b3VsZCBiZSBzdXJlIHRvIG1lYXN1cmUgdGhlIHRpbWUgdGFrZW4gZm9yIHRoZSBjb250cm9sDSAg ICAgIHBsYW5lIG1lc3NhZ2VzIGluY2x1ZGluZyB0aGUgcHJvY2Vzc2luZyBvZiB0aG9zZSBtZXNz YWdlcyBieSB0aGUNICAgICAgbm9kZXMgdW5kZXIgdGVzdC4NDSAgIG8gIEJpLWRpcmVjdGlvbmFs IExTUHMgbWF5IGJlIHNldHVwIHVzaW5nIHRocmVlIHdheSBzaWduYWxsaW5nLCB3aGVyZQ0gICAg ICB0aGUgaW5pdGlhdGluZyBub2RlIHdpbGwgc2VuZCBhIFJFU1ZfQ09ORiBtZXNzYWdlIGRvd25z dGVhbSB1cG9uDSAgICAgIHJlY2VpdmluZyB0aGUgUkVTViBtZXNzYWdlLiAgVGhlIFJFU1ZfQ09O RiBtZXNzYWdlIGlzIHVzZWQgdG8NICAgICAgbm90aWZ5IHRoZSB0ZXJtaW5hdGUgbm9kZSB0aGF0 IGl0IGNhbiB0cmFuc2ZlciBkYXRhIHVwc3RyZWFtLg0gICAgICBBY3R1YWxseSwgYm90aCBkaXJl Y3Rpb24gc2hvdWxkIGJlIHJlYWR5IHRvIHRyYW5zZmVyIGRhdGEgd2hlbiB0aGUNICAgICAgUkVT ViBtZXNzYWdlIGlzIHJlY2VpdmVkIGJ5IHRoZSBpbml0aWF0ZSBub2RlLiAgVGhlcmVmb3JlLCB0 aGUgYmktDSAgICAgIGRpcmVjdGlvbmFsIExTUCBzZXR1cCBkZWxheSBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgZG9lcyBub3QgdGFrZQ0gICAgICB0aGUgY29uZmlybWF0aW9uIHByb2NlZHVyZSBp bnRvIGFjY291bnQuDQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEphbnVh cnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSA0Ml0NDQ1JbnRlcm5ldC1EcmFmdCAgICAg IExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkNDQ0x Ni4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQ0gICBTYW1wbGVzIG9mIHRoZSBtZXRyaWNzIGNh biBiZSBvYnRhaW5lZCBpbiBlaXRoZXIgYWN0aXZlIG9yIHBhc3NpdmUNICAgbWFubmVycy4NDSAg IEluIGFjdGl2ZSBtZWFzdXJlbWVudCwgaW5ncmVzcyBub2RlcyBpbmplY3QgcHJvYmluZyBtZXNz YWdlcyBpbnRvIHRoZQ0gICBjb250cm9sIHBsYW5lLiAgVGhlIG1lYXN1cmVtZW50IHBhcmFtZXRl cnMgbXVzdCBiZSBjYXJlZnVsbHkgc2VsZWN0ZWQNICAgc28gdGhhdCB0aGUgbWVhc3VyZW1lbnRz IGluamVjdCB0cml2aWFsIGFtb3VudHMgb2YgYWRkaXRpb25hbCB0cmFmZmljDSAgIGludG8gdGhl IG5ldHdvcmtzIHRoZXkgbWVhc3VyZS4gIElmIHRoZXkgaW5qZWN0ICJ0b28gbXVjaCIgdHJhZmZp YywNICAgdGhleSBjYW4gc2tldyB0aGUgcmVzdWx0cyBvZiB0aGUgbWVhc3VyZW1lbnQsIGFuZCBp biBleHRyZW1lIGNhc2VzDSAgIGNhdXNlIGNvbmdlc3Rpb24gYW5kIGRlbmlhbCBvZiBzZXJ2aWNl Lg0NICAgV2hlbiBzYW1wbGVzIG9mIHRoZSBtZXRyaWNzIGFyZSBjb2xsZWN0ZWQgaW4gYSBwYXNz aXZlIG1hbm5lciwgZS5nLiwNICAgYnkgbW9uaXRvcmluZyB0aGUgb3BlcmF0aW9ucyBvbiByZWFs LWxpZmUgTFNQcywgdGhlIGltcGxlbWVudGF0aW9uIG9mDSAgIHRoZSBtb25pdG9yaW5nIGFuZCBy ZXBvcnRpbmcgbWVjaGFuaXNtIG11c3QgYmUgY2FyZWZ1bCBzbyB0aGF0IHRoZXkNICAgd2lsbCBu b3QgYmUgdXNlZCB0byBhdHRhY2sgdGhlIGNvbnRyb2wgcGxhbmUuDQ0gICBCZXNpZGVzLCB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcGVydGFpbmluZyB0byB0aGUgb3JpZ2luYWwgUlNWUA0g ICBwcm90b2NvbCBbUkZDMjIwNV0gYW5kIGl0cyBURSBleHRlbnNpb25zIFtSRkMzMjA5XSBhbHNv IHJlbWFpbg0gICByZWxldmFudC4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDVN1biAm IFpoYW5nICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAg IFtQYWdlIDQzXQ0NDUludGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExT IE5ldHdvcmtzICAgICAgICAgIEp1bHkgMjAwOQ0NDTE3LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0N ICAgVGhpcyBkb2N1bWVudCBtYWtlcyBubyByZXF1ZXN0cyBmb3IgSUFOQSBhY3Rpb24uDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDVN1biAmIFpoYW5nICAg ICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDQ0 XQ0NDUludGVybmV0LURyYWZ0ICAgICAgTFNQIER5bmFtaWMgUFBNIGluIEdNUExTIE5ldHdvcmtz ICAgICAgICAgIEp1bHkgMjAwOQ0NDTE4LiAgQWNrbm93bGVkZ2VtZW50cw0NICAgV2Ugd2lzaCB0 byB0aGFuayBEYW4gTGksIEZhbmcgTGl1IChDaHJpc3RpbmUpLCBaYWZhciBBbGksIE1vbmlxdWUN ICAgTW9ycm93LCBBbCBNb3J0b24sIEhlbmsgVWlqdGVyd2FhbCwgQWRyaWFuIEZhcnJlbCwgRGVi b3JhaCBCcnVuZ2FyZCwNICAgTG91IEJlcmdlciwgVGhvbWFzIEQuIE5hZGVhdSBmb3IgdGhlaXIg Y29tbWVudHMgYW5kIGhlbHBzLg0NICAgVGhpcyBkb2N1bWVudCBjb250YWlucyBpZGVhcyBhcyB3 ZWxsIGFzIHRleHQgdGhhdCBoYXZlIGFwcGVhcmVkIGluDSAgIGV4aXN0aW5nIElFVEYgZG9jdW1l bnRzLiAgVGhlIGF1dGhvcnMgd2lzaCB0byB0aGFuayBHLiBBbG1lcywgUy4NICAgS2FsaWRpbmRp IGFuZCBNLiBaZWthdXNrYXMuDQ0gICBXZSBhbHNvIHdpc2ggdG8gdGhhbmsgV2Vpc2hlbmcgSHUs IFlhb2h1aSBKaW4gYW5kIFdlaSBHdW8gaW4gdGhlDSAgIHN0YXRlIGtleSBsYWJvcmF0b3J5IG9m IGFkdmFuY2VkIG9wdGljYWwgY29tbXVuaWNhdGlvbiBzeXN0ZW1zIGFuZA0gICBuZXR3b3JrcyBm b3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLiAgV2UgYWxzbyB3aXNoIHRvIHRoYW5rIHRoZQ0gICBz dXBwb3J0IGZyb20gTlNGQyBhbmQgODYzIHByb2dyYW0gb2YgQ2hpbmEuDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICBFeHBpcmVzIEph bnVhcnkgMTAsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSA0NV0NDQ1JbnRlcm5ldC1EcmFmdCAg ICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICAgICBKdWx5IDIwMDkN DQ0xOS4gIFJlZmVyZW5jZXMNDTE5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0NICAgW1JGQzIx MTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUN ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJj aCAxOTk3Lg0NICAgW1JGQzIyMDVdICBCcmFkZW4sIEIuLCBaaGFuZywgTC4sIEJlcnNvbiwgUy4s IEhlcnpvZywgUy4sIGFuZCBTLg0gICAgICAgICAgICAgIEphbWluLCAiUmVzb3VyY2UgUmVTZXJW YXRpb24gUHJvdG9jb2wgKFJTVlApIC0tIFZlcnNpb24gMQ0gICAgICAgICAgICAgIEZ1bmN0aW9u YWwgU3BlY2lmaWNhdGlvbiIsIFJGQyAyMjA1LCBTZXB0ZW1iZXIgMTk5Ny4NDSAgIFtSRkMyNjc5 XSAgQWxtZXMsIEcuLCBLYWxpZGluZGksIFMuLCBhbmQgTS4gWmVrYXVza2FzLCAiQSBPbmUtd2F5 DSAgICAgICAgICAgICAgRGVsYXkgTWV0cmljIGZvciBJUFBNIiwgUkZDIDI2NzksIFNlcHRlbWJl ciAxOTk5Lg0NICAgW1JGQzI2ODFdICBBbG1lcywgRy4sIEthbGlkaW5kaSwgUy4sIGFuZCBNLiBa ZWthdXNrYXMsICJBIFJvdW5kLXRyaXANICAgICAgICAgICAgICBEZWxheSBNZXRyaWMgZm9yIElQ UE0iLCBSRkMgMjY4MSwgU2VwdGVtYmVyIDE5OTkuDQ0gICBbUkZDMzIwOV0gIEF3ZHVjaGUsIEQu LCBCZXJnZXIsIEwuLCBHYW4sIEQuLCBMaSwgVC4sIFNyaW5pdmFzYW4sIFYuLA0gICAgICAgICAg ICAgIGFuZCBHLiBTd2FsbG93LCAiUlNWUC1URTogRXh0ZW5zaW9ucyB0byBSU1ZQIGZvciBMU1AN ICAgICAgICAgICAgICBUdW5uZWxzIiwgUkZDIDMyMDksIERlY2VtYmVyIDIwMDEuDQ0gICBbUkZD MzQ3MV0gIEJlcmdlciwgTC4sICJHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0 Y2hpbmcNICAgICAgICAgICAgICAoR01QTFMpIFNpZ25hbGluZyBGdW5jdGlvbmFsIERlc2NyaXB0 aW9uIiwgUkZDIDM0NzEsDSAgICAgICAgICAgICAgSmFudWFyeSAyMDAzLg0NICAgW1JGQzM0NzNd ICBCZXJnZXIsIEwuLCAiR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5n DSAgICAgICAgICAgICAgKEdNUExTKSBTaWduYWxpbmcgUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJv dG9jb2wtVHJhZmZpYw0gICAgICAgICAgICAgIEVuZ2luZWVyaW5nIChSU1ZQLVRFKSBFeHRlbnNp b25zIiwgUkZDIDM0NzMsIEphbnVhcnkgMjAwMy4NDSAgIFtSRkMzOTQ1XSAgTWFubmllLCBFLiwg IkdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZw0gICAgICAgICAgICAg IChHTVBMUykgQXJjaGl0ZWN0dXJlIiwgUkZDIDM5NDUsIE9jdG9iZXIgMjAwNC4NDSAgIFtSRkM0 MjA4XSAgU3dhbGxvdywgRy4sIERyYWtlLCBKLiwgSXNoaW1hdHN1LCBILiwgYW5kIFkuIFJla2h0 ZXIsDSAgICAgICAgICAgICAgIkdlbmVyYWxpemVkIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNo aW5nIChHTVBMUykgVXNlci0NICAgICAgICAgICAgICBOZXR3b3JrIEludGVyZmFjZSAoVU5JKTog UmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtDSAgICAgICAgICAgICAgVHJhZmZpYyBFbmdp bmVlcmluZyAoUlNWUC1URSkgU3VwcG9ydCBmb3IgdGhlIE92ZXJsYXkNICAgICAgICAgICAgICBN b2RlbCIsIFJGQyA0MjA4LCBPY3RvYmVyIDIwMDUuDQ0gICBbUkZDNDgwMl0gIE5hZGVhdSwgVC4g YW5kIEEuIEZhcnJlbCwgIkdlbmVyYWxpemVkIE11bHRpcHJvdG9jb2wgTGFiZWwNICAgICAgICAg ICAgICBTd2l0Y2hpbmcgKEdNUExTKSBUcmFmZmljIEVuZ2luZWVyaW5nIE1hbmFnZW1lbnQNICAg ICAgICAgICAgICBJbmZvcm1hdGlvbiBCYXNlIiwgUkZDIDQ4MDIsIEZlYnJ1YXJ5IDIwMDcuDQ0x OS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0NICAgW0ktRC5zaGlvbW90by1jY2FtcC1zd2l0 Y2gtcHJvZ3JhbW1pbmddDSAgICAgICAgICAgICAgU2hpb21vdG8sIEsuIGFuZCBBLiBGYXJyZWws ICJBZHZpY2Ugb24gV2hlbiBJdCBpcyBTYWZlIHRvDSAgICAgICAgICAgICAgU3RhcnQgU2VuZGlu ZyBEYXRhIG9uIExhYmVsIFN3aXRjaGVkIFBhdGhzICBFc3RhYmxpc2hlZA0gICAgICAgICAgICAg IFVzaW5nIFJTVlAtVEUiLCBkcmFmdC1zaGlvbW90by1jY2FtcC1zd2l0Y2gtcHJvZ3JhbW1pbmct MDANDQ0NU3VuICYgWmhhbmcgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAg ICAgICAgICAgICAgW1BhZ2UgNDZdDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQ UE0gaW4gR01QTFMgTmV0d29ya3MgICAgICAgICAgSnVseSAyMDA5DQ0NICAgICAgICAgICAgICAo d29yayBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5IDIwMDkuDQ0gICBbSS1ELnN1bi1jY2FtcC1kcG1d DSAgICAgICAgICAgICAgU3VuLCBXLiwgWmhhbmcsIEcuLCBHYW8sIEouLCBYaWUsIEcuLCBQYXBu ZWphLCBSLiwgR3UsIEIuLA0gICAgICAgICAgICAgIFdlaSwgWC4sIE90YW5pLCBULiwgYW5kIFIu IEppbmcsICJMYWJlbCBTd2l0Y2hlZCBQYXRoDSAgICAgICAgICAgICAgKExTUCkgRGF0YSBQYXRo IERlbGF5IE1ldHJpYyBpbiBHZW5lcmFsaXplZCBNUExTLyAgTVBMUy1URQ0gICAgICAgICAgICAg IE5ldHdvcmtzIiwgZHJhZnQtc3VuLWNjYW1wLWRwbS0wMCAod29yayBpbiBwcm9ncmVzcyksDSAg ICAgICAgICAgICAgSnVuZSAyMDA5Lg0NICAgW1JGQzIzMzBdICBQYXhzb24sIFYuLCBBbG1lcywg Ry4sIE1haGRhdmksIEouLCBhbmQgTS4gTWF0aGlzLA0gICAgICAgICAgICAgICJGcmFtZXdvcmsg Zm9yIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MiLCBSRkMgMjMzMCwNICAgICAgICAgICAgICBNYXkg MTk5OC4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NU3VuICYgWmhhbmcg ICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEwLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2Ug NDddDQ0NSW50ZXJuZXQtRHJhZnQgICAgICBMU1AgRHluYW1pYyBQUE0gaW4gR01QTFMgTmV0d29y a3MgICAgICAgICAgSnVseSAyMDA5DQ0NQXV0aG9ycycgQWRkcmVzc2VzDQ0gICBXZWlxaWFuZyBT dW4NICAgU2hhbmdoYWkgSmlhbyBUb25nIFVuaXZlcnNpdHkNICAgODAwIERvbmdjaHVhbiBSb2Fk DSAgIFNoYW5naGFpICAyMDAyNDANICAgQ04NDSAgIFBob25lOiArODYgMjEgMzQyMCA1MzU5DSAg IEVtYWlsOiBzdW53cUBtaXQuZWR1DQ0NICAgR3VveWluZyBaaGFuZw0gICBDaGluYSBBY2FkZW15 IG9mIFRlbGVjb21tdW5pY2F0aW9uIFJlc2VhcmNoLE1JSVQsQ2hpbmEuDSAgIE5vLjExIFl1ZVRh biBTb3V0aCBTdHJlZXQNICAgQmVpamluZyAgMTAwMDQ1DSAgIENODQ0gICBQaG9uZTogKzg2IDEw NjgwOTQyNzINICAgRW1haWw6IHpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuDQ0NICAgSmlh bmh1YSBHYW8NICAgSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIExURC4NICAgQ04NDSAgIFBob25l OiArODYgNzU1IDI4OTczMjM3DSAgIEVtYWlsOiBnamhoaXRAaHVhd2VpLmNvbQ0NDSAgIEd1b3d1 IFhpZQ0gICBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEsIFJpdmVyc2lkZQ0gICA5MDAgVW5pdmVy c2l0eSBBdmUuDSAgIFJpdmVyc2lkZSwgQ0EgOTI1MjENICAgVVNBDQ0gICBQaG9uZTogKzEgOTUx IDIzNyA4ODI1DSAgIEVtYWlsOiB4aWVnQGNzLnVjci5lZHUNDQ0gICBSYWppdiBQYXBuZWphDSAg IElzb2NvcmUNICAgMTIzNTkgU3VucmlzZSBWYWxsZXkgRHJpdmUsIFNURSAxMDANICAgUmVzdG9u LCBWQSAgMjAxOTANICAgVVNBDQ0gICBQaG9uZTogKzEgNzAzIDg2MCA5MjczDSAgIEVtYWlsOiBy cGFwbmVqYUBpc29jb3JlLmNvbQ0NDQ1TdW4gJiBaaGFuZyAgICAgICAgICAgICAgIEV4cGlyZXMg SmFudWFyeSAzLCAyMDEwICAgICAgICAgICAgICBbUGFnZSA0OF0NDQ1JbnRlcm5ldC1EcmFmdCAg ICAgIExTUCBEeW5hbWljIFBQTSBpbiBHTVBMUyBOZXR3b3JrcyAgICAgICBKYW51YXJ5IDIwMDkN DQ0gICBCaW4gR3UNICAgSVhJQQ0gICBPcmllbnRhbCBLZW56byBQbGF6YSA4TSw0OCBEb25nemhp bWVuIFdhaSBTdHJlZXQsRG9uZ2NoZW5nIERpc3RyaWN0DSAgIEJlaWppbmcgIDIwMDI0MA0gICBD Tg0NICAgUGhvbmU6ICs4NiAxMzYxMTU5MDc2Ng0gICBFbWFpbDogQkd1QGl4aWFjb20uY29tDQ0N ICAgWHVlcWluIFdlaQ0gICBGaWJlcmhvbWUgVGVsZWNvbW11bmljYWl0b24gVGVjaG5vbG9neSBD by4sTHRkLg0gICBXdWhhbg0gICBDTg0NICAgUGhvbmU6ICs4NiAxMzg3MTEyNzg4Mg0gICBFbWFp bDogeHF3ZWlAZmliZXJob21lLmNvbS5jbg0NDSAgIFRvbW9oaXJvIE90YW5pDSAgIEtEREkgUiZE IExhYm9yYXRvcmllcywgSW5jLg0gICAyLTEtMTUgT2hhcmEgS2FtaWZ1a3Vva2EgU2FpdGFtYQ0g ICAzNTYtODUwMg0gICBKYXBhbg0NICAgUGhvbmU6ICs4MS00OS0yNzgtNzM1Nw0gICBFbWFpbDog b3RhbmlAa2RkaWxhYnMuanANDQ0gICBSdWlxdWFuIEppbmcNICAgQ2hpbmEgVGVsZWNvbSBCZWlq aW5nIFJlc2VhcmNoIEluc3RpdHV0ZQ0gICAxMTggWGl6aGltZW53YWkgQXZlbnVlDSAgIEJlaWpp bmcgIDEwMDAzNQ0gICBDTg0NICAgUGhvbmU6ICs4Ni0xMC01ODU1MjAwMA0gICBFbWFpbDogamlu Z3JxQGN0YnJpLmNvbS5jbg0NDQ0NDQ0NDQ0NDQ0NDVN1biAmIFpoYW5nICAgICAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDMsIDIwMTAgICAgICAgICAgICAgIFtQYWdlIDQ5XQ0NBVRoaXMgd291 bGQgaW1wbHkgdGhhdCB0aGUgbWV0cmljIG1heSBwcm9kdWNlIGEgcmFuZ2Ugb2Ygc2V2ZXJhbCB2 YWx1ZXMgYXQgb25lIHRpbWUgd2l0aCB0aGUgbWluaW11bSB2YWx1ZSB0byBiZSB0YWtlbiBmcm9t IHRoYXQgcmFuZ2UuDUkgYmVsaWV2ZSB3aGF0IHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8gc2F5 IGlzLCB0aGF0IHRoZSBMU1AgU2V0dXAgRGVsYXkgTWV0cmljIHByb3ZpZGVzIGEgbG93ZXIgYm91 bmQgb24gYWxsIHBvc3NpYmxlIExTUCBEZWxheSBNZXRyaWNzIG9mIGFjdHVhbGx5IGluc3RhbnRp YXRlZCBMU1BzLCBvciBpbiBvdGhlciB3b3JkczogYW4gYWN0dWFsIExTUCBEZWxheSBNZXRyaWMg Y2Fubm90IGdldCBzbWFsbGVyIHRoYW4gYW4gTFNQIFNldHVwIERlbGF5IE1ldHJpYy4NBUhvdz8g U2hvdWxkIHRoZXJlIGJlIGEgbWV0aG9kb2xvZ3kgYmUgZGVmaW5lZCBmb3IgdGhpcz8NBVRvbyB2 YWd1ZT8gQXMgYm90aCB0aW1lc3RhbXBzIGFyZSB0byBiZSB0YWtlbiBvbiB0aGUgc2FtZSBpbmdy ZXNzIG5vZGUsIHRoZXkgc2hvdWxkIGJlIHRha2VuIGF0IHRoZSBzYW1lIGFwcGxpY2F0aW9uL25l dHdvcmsgbGV2ZWwuDQVTaG91bGQgYmUgbW9yZSBzcGVjaWZpYyBhcyB0byB3aHkgdGhpcyBtZXRy aWMgaXMgbm8gc2ltcGxlIGZ1bmN0aW9uIG9mIHNpbmdsZSB1bmktZGlyZWN0aW9uYWwgTFNQIFNl dHVwIERlbGF5IG1ldHJpYywgaS5lLiB3aHkgY2FuIGl0IG5vdCBiZSBkZWR1Y2VkIGZyb20gc2lu Z2xlIExTUCBTZXR1cCBEZWxheT8NBVR0aGUgY3VycmVudCBkZWZpbml0aW9uIG9ubHkgYWRkcmVz c2VzIG11bHRpcGxlIHVuaS1kaXJlY3Rpb25hbCBMU1Agc2V0dXBzIGJldHdlZW4gdHdvIG5vZGVz IElEMCBhbmQgSUQxLiBXaGF0IGFib3V0IHRoZSB0aGUgY2FzZSB3aGVuIElEMCBpcyB0byBzZXR1 cCBtdWx0aXBsZSB1bmktZGlyZWN0aW9uYWwgTFNQIHNldHVwcyB0byBkaWZmZXJlbnQgZWdyZXNz IG5vZGVzIElEMSwgSUQyLCBJRDMshSxJRE4/DQVCZWZvcmUgY29udGludWluZyBkb2MgcmV2aXNp b24gYW55IGZ1cnRoZXIgaXQgbWlnaHQgYmUgYWR2aXNhYmxlIHRvIGZpcnN0IGFkZHJlc3MgdGhl IG1hcmtlZCBwb2ludHMgYW5kIHF1ZXN0aW9ucyBpbiB0aGUgZmlyc3QgcGFydCBvZiB0aGlzIGRv Y3VtZW50Lg0FSXMgdGhlcmUgYW55IGhlbHAgb3Igc3VnZ2VzdGlvbiBvbiBob3cgdG8gYWN0dWFs bHkgY29tcHV0ZSBhIHVzYWJsZSBMYW1iZGFfbT8NBUhvdyB0byBjb21wYXJlIG1ldHJpY3MgdGhh dCBoYXZlIGJlZW4gZ2VuZXJhdGVkIGJ5IHR3byBkaWZmZXJlbnQgUG9pc3NvbiBwcm9jZXNzZXMs IGkuZS4gZS5nLiB0d28gZGlmZmVyZW50IGFycml2YWwgcmF0ZXM/DQVUaGVzZSBzYW1wbGUgdHVw bGVzIGFyZSBkZXBlbmRlbnQgb24gdGhlIGFycml2YWwgcmF0ZSBMYW1iZGFfbS4gSG93IHRvIGRl ZHVjdCB0aGlzIGlucHV0IHBhcmFtZXRlciBmcm9tIGEgcmVzdWx0aW5nIHNhbXBsZT8NRm9yIGlu c3RhbmNlLCBpZiB0d28gcmVzdWx0IHNhbXBsZSBzZXRzIGFyZSBnaXZlbiwgaG93IGNhbiB3ZSBi ZSBzdXJlIHRoYXQgdGhleSBjYW4gYmUgY29tcGFyZWQ/DQVBIHN1cGVycG9zaXRpb24gb2YgdHdv IGRpZmZlcmVudCBQb2lzc29uIHByb2Nlc3NlcyBpcyBiZWluZyB1c2VkIGhlcmUuDUhvdyBkbyB5 b3UgbWFwIHRoZSByZXN1bHRpbmcgUkVTViBtZXNzYWdlcyB0byB0aGUgY29ycmVjdCBwcm9jZXNz LCBpLmUuIGhvdyB0byBkaWZmZXJlbnRpYXRlIGUuZy4gYSBsYXRlIFJFU1YgbWVzc2FnZSByZXN1 bHRpbmcgZnJvbSB0aGlyZCBQQVRIIG1lc3NhZ2UgaW4gZm91cnRoIGludm9jYXRpb24gZnJvbSBh biBlYXJseSBSRVNWIG1lc3NhZ2Ugc29saWNpdGVkIGJ5IGZpcnN0IFBBVEggbWVzc2FnZSBpbiBm b3VydGggaW52b2NhdGlvbj8NBT8/Pz8NBUFzIHN0aXB1bGF0ZWQgaW4gUkZDMjMzMCB0aGUgRURG IGlzIGRlZmluZWQgYXMgYSBmdW5jdGlvbiBGKHgpIHdoaWNoIGZvciBhbnkgeCBnaXZlcyB0aGUg ZnJhY3Rpb25hbCBwcm9wb3J0aW9uIG9mdCBoZSB0b3RhbCBtZWFzdXJlbWVudHMgdGhhdCB3ZXJl IDw9IHguIChzZWUgUkZDMjMzMCAxMS4zIHAyNikNSGVuY2UgRig5MCk9MC4yNSwgRigxMDApPTAu NSxGKDExMCk9MC43NSwgRig1MDApPTEgYW5kIHRoZXJlZm9yZSB0aGUgNTB0aCBwZXJjZW50aWxl IGlzIGRlZmluZWQgYXMgMTAwIGFzIG9wcG9zZWQgdG8gMTEwLg0NDQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAMIAAAO PgAAMD4AADo+AAC+RgAAy0YAAP9GAAAaRwAAJUcAAAZMAAASTAAAbkwAAHVMAADKTAAAy0wAACZP AABLTwAAW08AAPPizq7imuKGZuJS4lLiROIw4gAAJwEIgQRIAQAFaCGM2CYWaKMvCQBPSgMAUUoD AF5KAwBtSAkIc0gJCBsDagAAAAAWaIBZdAAwShMAT0oEAFFKBABVCAEnAQiBBEgBAAVosovYJhZo 6G67AE9KAwBRSgMAXkoDAG1ICQhzSAkIPwAIgRVo6hGLABZokS5UABdo6G67AE9KAwBRSgMAXkoD AGNIAQBkaAAAAABkaAAAAABkaLGL2CZtSAkIc0gJCCcBCIEESAEABWixi9gmFmjobrsAT0oDAFFK AwBeSgMAbUgJCHNICQgnAQiBBEgBAAVosIvYJhZo6G67AE9KAwBRSgMAXkoDAG1ICQhzSAkIPwAI gRVo6hGLABZokS5UABdo6G67AE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAAAABkaK+L2CZtSAkI c0gJCCcBCIEESAEABWivi9gmFmjobrsAT0oDAFFKAwBeSgMAbUgJCHNICQggFWjqEYsAFmiRLlQA T0oDAFFKAwBeSgMAbUgJCHNICQgAGBVoh2XtABZokS5UAE9KAwBRSgMAXkoDABIACAAAAQgAAAII AAADCAAATQgAAJYIAADgCAAAKQkAAHIJAABzCQAAdAkAALsJAADsCQAAIQoAACIKAAA2CgAANwoA AIAKAADICgAAEAsAAFYLAACaCwAA4QsAACgMAABrDAAAswwAAPsMAAA7DQAAbg0AAG8NAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHW8NAAC0DQAA+A0A ADsOAABGDgAARw4AAJAOAADYDgAAGg8AAFgPAABZDwAAkw8AAMIPAADDDwAABxAAACsQAAAsEAAA ZBAAAGUQAAB2EAAAdxAAALoQAADlEAAA5hAAAOcQAADoEAAAMREAADIRAAAzEQAAfBEAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdfBEAAH0RAAB+EQAA vxEAAAESAABJEgAAkhIAAMUSAADGEgAAxxIAAMgSAADJEgAAyhIAAMsSAADMEgAAzRIAAM4SAADP EgAA0BIAANESAADSEgAA0xIAANQSAADVEgAA1hIAANcSAADYEgAA2RIAANoSAADbEgAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB3bEgAA3BIAAN0SAADe EgAA3xIAAOASAADhEgAA4hIAAOMSAADkEgAA5RIAAOYSAADnEgAA6BIAAOkSAADqEgAA6xIAAOwS AADtEgAA7hIAAO8SAADwEgAA8RIAAPISAADzEgAAPBMAAD0TAAA+EwAAhxMAAIgTAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHYgTAACJEwAAkhMAAJMT AADcEwAAHRQAAGQUAACqFAAA7hQAADUVAAB1FQAAvBUAAAIWAABFFgAAihYAAM8WAAAXFwAAWRcA AFoXAACgFwAA3xcAACEYAABlGAAAqRgAAOsYAADsGAAA7RgAAO4YAADvGAAA8BgAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd8BgAAPEYAADyGAAA8xgA APQYAAD1GAAA9hgAAPcYAAD4GAAA+RgAAPoYAAD7GAAA/BgAAP0YAAD+GAAA/xgAAAAZAAABGQAA AhkAAAMZAAAEGQAABRkAAAYZAAAHGQAAUBkAAFEZAABSGQAAmxkAAJwZAACdGQAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB2dGQAArxkAALAZAAD5GQAA +hkAAEMaAABEGgAAjRoAAI4aAADLGgAAFBsAAF0bAACmGwAA7xsAADgcAACBHAAAyhwAABMdAAAU HQAAUx0AAJwdAADlHQAALh4AAHceAADAHgAACR8AAFIfAACbHwAAnB8AANkfAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHdkfAAAiIAAAayAAALQgAAD9 IAAARiEAAI8hAADYIQAAISIAACIiAABiIgAAqyIAAPQiAAA9IwAAhiMAAM8jAAAYJAAAYSQAAKok AACrJAAArCQAAK0kAACuJAAA9yQAAPgkAAD5JAAAQiUAAEMlAABEJQAAjSUAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdjSUAANYlAAAfJgAAaCYAALEm AAD6JgAAQycAAIwnAACNJwAAyycAABQoAABdKAAApigAAO8oAAA4KQAAgSkAAMopAAATKgAAXCoA AKUqAACmKgAA5yoAADArAAB5KwAAwisAAAssAABULAAAnSwAAOYsAAAvLQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB0vLQAAeC0AAMEtAADCLQAAAC4A AEkuAACSLgAA2y4AACQvAABtLwAAti8AAP8vAABIMAAAkTAAANowAADbMAAAHDEAAGUxAACuMQAA rzEAALAxAACxMQAA+jEAAPsxAAD8MQAARTIAAEYyAABHMgAAkDIAANkyAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHdkyAAAiMwAAazMAALQzAAD9MwAA RjQAAI80AACQNAAA2TQAACI1AABrNQAAtDUAAP01AABGNgAAjzYAAJA2AADZNgAAIjcAAGs3AAC0 NwAA/TcAAEY4AACPOAAAkDgAANk4AADaOAAAIzkAACQ5AABtOQAAbjkAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdbjkAALc5AAC4OQAAAToAAEo6AACT OgAAlDoAAN06AADeOgAA3zoAAOA6AADhOgAA4joAAOM6AADkOgAA5ToAAOY6AADnOgAA6DoAAOk6 AADqOgAAMzsAADQ7AAA1OwAAfjsAAH87AACAOwAAkTsAAJI7AADbOwAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB3bOwAAITwAAGg8AACuPAAA8TwAADg9 AAB4PQAAuz0AALw9AAACPgAAaj4AALA+AAD2PgAAPj8AAIU/AADHPwAADUAAACZAAAAnQAAAb0AA ALNAAAD6QAAAQUEAAIVBAADIQQAADkIAAFVCAACdQgAA4EIAACZDAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHSZDAAAnQwAAKEMAAClDAAAqQwAAK0MA ACxDAAAtQwAALkMAAC9DAAAwQwAAMUMAADJDAAAzQwAANEMAADVDAAA2QwAAN0MAADhDAAA5QwAA gkMAAINDAACEQwAAzUMAAM5DAADPQwAA9UMAAPZDAAA9RAAAhUQAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdhUQAAMJEAADDRAAAxEQAAMVEAADGRAAA x0QAAMhEAADJRAAAykQAAMtEAADMRAAAzUQAAM5EAADPRAAA0EQAANFEAADSRAAA00QAANREAADV RAAA1kQAANdEAADYRAAA2UQAANpEAADbRAAA3EQAAN1EAADeRAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB3eRAAA30QAAOBEAADhRAAA4kQAAONEAADk RAAA5UQAAOZEAADnRAAA6EQAAOlEAADqRAAA60QAAOxEAADtRAAA7kQAAO9EAADwRAAAOUUAADpF AAA7RQAAhEUAAIVFAACGRQAAqkUAAKtFAAD0RQAAO0YAAIRGAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHYRGAADaRgAAOUcAAH1HAADFRwAA7UcAAO5H AAA0SAAAe0gAALNIAAD0SAAAOEkAAH9JAACJSQAAikkAAItJAACMSQAAjUkAAI5JAACPSQAAkEkA AJFJAACSSQAAk0kAAJRJAACVSQAAlkkAAJdJAACYSQAAmUkAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdmUkAAJpJAACbSQAAnEkAAJ1JAACeSQAAn0kA AKBJAAChSQAAokkAAKNJAACkSQAApUkAAKZJAACnSQAAqEkAAKlJAACqSQAA80kAAPRJAAD1SQAA PkoAAD9KAABASgAAhkoAAIdKAADPSgAA+0oAAPxKAAANSwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB0NSwAADksAAFZLAABqSwAAa0sAALBLAAD1SwAA SEwAAJVMAACiTAAAo0wAAOlMAAAwTQAAeE0AALhNAAD9TQAAQE4AAIFOAADHTgAAD08AAB9PAAAg TwAA7k8AABVQAABeUAAAnlAAAJ9QAADnUAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAALDwBnZKMvCQBvxgcBAQAm jNgmZCYBAAQPAGdkoy8JAAAEDwBnZIdl7QAAG1tPAABpTwAAcU8AAOxPAADuTwAAnVAAACVUAAAp VAAAQFQAAERUAABpVAAAgVQAAOvLt519bExsTGw4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAQiBBEgBAAVoLozYJhZo/kwYAE9KAwBRSgMAXkoD AG1ICQhzSAkIPwAIgRVo6hGLABZokS5UABdo/kwYAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAA AABkaC2M2CZtSAkIc0gJCCAVaOoRiwAWaJEuVABPSgMAUUoDAF5KAwBtSAkIc0gJCAA/AAiBFWjq EYsAFmiRLlQAF2ijLwkAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRoJozYJm1ICQhzSAkI MwEIgQRIAQAFaCaM2CYVaOoRiwAWaKMvCQAXaKMvCQBPSgMAUUoDAF5KAwBtSAkIc0gJCCcBCIEE SAEABWgljNgmFmijLwkAT0oDAFFKAwBeSgMAbUgJCHNICQg/AAiBFWjqEYsAFmiRLlQAF2ijLwkA T0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRoIozYJm1ICQhzSAkIJwEIgQRIAQAFaCKM2CYW aKMvCQBPSgMAUUoDAF5KAwBtSAkIc0gJCAAL51AAADBRAAAxUQAAd1EAAL9RAAD1UQAA9lEAAAhS AAAJUgAAM1IAADRSAABMUgAATVIAAGtSAABsUgAAiVIAAIpSAACLUgAAjFIAAI1SAADWUgAA11IA ANhSAAAhUwAAIlMAACNTAABPUwAAUFMAAGNTAABkUwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB1kUwAArFMAAN9TAADgUwAA8VMAAPJTAAA6VAAAmVQA AOlUAAA9VQAAlVUAAMlVAADKVQAAElYAAHJWAAC/VgAAOlcAAGVXAACnVwAAqFcAAPBXAAA5WAAA fVgAAMRYAADFWAAA1lgAANdYAAASWQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAOoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAALDwBnZP5MGABvxgcBAQAxjNgm ZCYBAAQPAGdk/kwYAAAEDwBnZIdl7QAAG4FUAACHVAAAoFQAAKlUAACvVAAAAFUAAAZVAAAHVQAA DVUAADBVAABDVQAAVFUAAF5VAAB4VQAAfFUAAKFVAADfzrqazrqGumbOUmbOMs4AAAAAAAAAAAAA AAAAAAAAAAAAAAA/AAiBFWjqEYsAFmiRLlQAF2j+TBgAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRo AAAAAGRoLIzYJm1ICQhzSAkIJwEIgQRIAQAFaCuM2CYWaKMvCQBPSgMAUUoDAF5KAwBtSAkIc0gJ CD8ACIEVaOoRiwAWaJEuVAAXaKMvCQBPSgMAUUoDAF5KAwBjSAEAZGgAAAAAZGgAAAAAZGgrjNgm bUgJCHNICQgnAQiBBEgBAAVoLIzYJhZo/kwYAE9KAwBRSgMAXkoDAG1ICQhzSAkIPwAIgRVo6hGL ABZokS5UABdooy8JAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAAAABkaCqM2CZtSAkIc0gJCCcB CIEESAEABWgqjNgmFmijLwkAT0oDAFFKAwBeSgMAbUgJCHNICQggFWjqEYsAFmiRLlQAT0oDAFFK AwBeSgMAbUgJCHNICQgAPwAIgRVo6hGLABZokS5UABdo/kwYAE9KAwBRSgMAXkoDAGNIAQBkaAAA AABkaAAAAABkaC6M2CZtSAkIc0gJCAAPoVUAAMdVAAA/VgAAVlYAAFtWAAB1VgAAflYAAIRWAADS VgAAAFcAABVXAAA4VwAAOlcAAKZXAAB2XQAAeV0AAKtdAACuXQAA7F0AAN/OuprOuprOuoa6bEzO OM44zgAAAAAAAAAAAAAAAAAAAAAAACcBCIEESAEABWg1jNgmFmi8UukAT0oDAFFKAwBeSgMAbUgJ CHNICQg/AAiBFWjqEYsAFmiRLlQAF2j+TBgAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRo MYzYJm1ICQhzSAkIMwEIgQRIAQAFaDGM2CYVaOoRiwAWaP5MGAAXaP5MGABPSgMAUUoDAF5KAwBt SAkIc0gJCCcBCIEESAEABWgxjNgmFmj+TBgAT0oDAFFKAwBeSgMAbUgJCHNICQg/AAiBFWjqEYsA FmiRLlQAF2j+TBgAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRoMIzYJm1ICQhzSAkIJwEI gQRIAQAFaDCM2CYWaP5MGABPSgMAUUoDAF5KAwBtSAkIc0gJCCAVaOoRiwAWaJEuVABPSgMAUUoD AF5KAwBtSAkIc0gJCAA/AAiBFWjqEYsAFmiRLlQAF2j+TBgAT0oDAFFKAwBeSgMAY0gBAGRoAAAA AGRoAAAAAGRoL4zYJm1ICQhzSAkIABISWQAAE1kAAFtZAACiWQAA51kAAB9aAAAgWgAAYloAAKla AADwWgAANVsAAHxbAADDWwAAAVwAAERcAACLXAAA0lwAANNcAADUXAAA1VwAANZcAADXXAAAIF0A ACFdAAAiXQAAa10AAGxdAABtXQAAt10AAAReAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZIdl7QAAHexdAADwXQAAFl4AAB1eAABBXgAARV4AAHdeAAB6XgAAfV4A AH5eAACSXgAAlF4AAKVeAACpXgAAyV4AANBeAABcYAAAXWAAALVgAAC2YAAAxWEAAMZhAAC2ZQAA t2UAAAZmAAAHZgAAXWYAAOvaxtrG2sbaxtrG2sbaxtq42pjauNp+XkraAAAAAAAAAAAAAAAAAAAn AQiBBEgBAAVoQ4zYJhZoZG5yAE9KAwBRSgMAXkoDAG1ICQhzSAkIPwAIgRVo6hGLABZokS5UABdo ZG5yAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAAAABkaEOM2CZtSAkIc0gJCDMBCIEESAEABWhD jNgmFWjqEYsAFmhkbnIAF2hkbnIAT0oDAFFKAwBeSgMAbUgJCHNICQg/AAiBFWjqEYsAFmiRLlQA F2hkbnIAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRoOIzYJm1ICQhzSAkIGwNqAAAAABZo ZG5yADBKEwBPSgQAUUoEAFUIAScBCIEESAEABWg2jNgmFmhkbnIAT0oDAFFKAwBeSgMAbUgJCHNI CQggFWjqEYsAFmiRLlQAT0oDAFFKAwBeSgMAbUgJCHNICQgAJwEIgQRIAQAFaDWM2CYWaGRucgBP SgMAUUoDAF5KAwBtSAkIc0gJCAAaBF4AADdeAAA4XgAAg14AANheAAAgXwAAYl8AAKtfAAC2XwAA t18AAMtfAADMXwAAA2AAAARgAABHYAAAXGAAAF5gAACkYAAA52AAACthAAA+YQAAP2EAAINhAADL YQAAEGIAAFJiAABiYgAAY2IAAKRiAADsYgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2SHZe0AAB3sYgAANWMAAFljAABaYwAAm2MAANhjAADZYwAA2mMAANtjAADc YwAA3WMAAN5jAADfYwAA4GMAAOFjAADiYwAA42MAAORjAADlYwAA5mMAAOdjAAAwZAAAMWQAADJk AAB7ZAAAfGQAAH1kAADFZAAAxmQAAAdlAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAAAAAAAEDwBnZIdl7QAAHQdlAAA9ZQAAPmUAAE9lAABQZQAAl2UAAK9lAACwZQAAt2UAAPZl AAA8ZgAAy2YAAMxmAAARZwAAVWcAAFdnAABpZwAAamcAAJdnAACYZwAAsGcAALFnAADPZwAA0GcA AO1nAADuZwAAIGgAACFoAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAOoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAsPAGdkZG5yAG/GBwEBAEOM2CZkJgEABA8A Z2RkbnIAAAQPAGdkh2XtAAAbXWYAAF5mAAB1ZgAAemYAAI5mAADBZgAAyGYAAMlmAADKZgAAJmcA ACdnAAA2ZwAAOGcAADxnAABVZwAAVmcAAKdpAACqaQAA69fr18PXw+uykrJyXrJQsjwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwEIgQRIAQAFaF2T2EYWaEc0pQBPSgMAUUoDAF5KAwBt SAkIc0gJCBsDagAAAAAWaEc0pQAwShMAT0oEAFFKBABVCAEnAQiBBEgBAAVoWZPYRhZoRzSlAE9K AwBRSgMAXkoDAG1ICQhzSAkIPwAIgRVo6hGLABZokS5UABdoRzSlAE9KAwBRSgMAXkoDAGNIAQBk aAAAAABkaAAAAABkaFmT2EZtSAkIc0gJCD8ACIEVaOoRiwAWaJEuVAAXaMMANABPSgMAUUoDAF5K AwBjSAEAZGgAAAAAZGgAAAAAZGhGjNgmbUgJCHNICQggFWjqEYsAFmiRLlQAT0oDAFFKAwBeSgMA bUgJCHNICQgAJwEIgQRIAQAFaESM2CYWaMMANABPSgMAUUoDAF5KAwBtSAkIc0gJCCcBCIEESAEA BWhDjNgmFmhkbnIAT0oDAFFKAwBeSgMAbUgJCHNICQgnAQiBBEgBAAVoRYzYJhZowwA0AE9KAwBR SgMAXkoDAG1ICQhzSAkIABEhaAAARmgAAEdoAAB5aAAAemgAAI1oAACOaAAA1GgAAAxpAAANaQAA HmkAAB9pAABmaQAAu2kAALxpAAAJagAAOGoAADlqAACGagAAwWoAAMJqAADDagAAxGoAAA1rAAAO awAAD2sAAFhrAABZawAAWmsAAK1rAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZIdl7QAAHappAACvaQAAuWkAANNpAADbaQAA4GkAAGJqAABsagAAcGoAAHFrAAB9 awAAhWsAAN/LuqaGunJSuj4eAD8ACIEVaOoRiwAWaJEuVAAXaClddwBPSgMAUUoDAF5KAwBjSAEA ZGgAAAAAZGgAAAAAZGhek9hGbUgJCHNICQgnAQiBBEgBAAVoXpPYRhZoKV13AE9KAwBRSgMAXkoD AG1ICQhzSAkIPwAIgRVo6hGLABZokS5UABdoRzSlAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAA AABkaF6T2EZtSAkIc0gJCCcBCIEESAEABWhdk9hGFmhHNKUAT0oDAFFKAwBeSgMAbUgJCHNICQg/ AAiBFWjqEYsAFmiRLlQAF2hHNKUAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRoXJPYRm1I CQhzSAkIJwEIgQRIAQAFaFyT2EYWaEc0pQBPSgMAUUoDAF5KAwBtSAkIc0gJCCAVaOoRiwAWaJEu VABPSgMAUUoDAF5KAwBtSAkIc0gJCAAnAQiBBEgBAAVoWpPYRhZoRzSlAE9KAwBRSgMAXkoDAG1I CQhzSAkIPwAIgRVo6hGLABZokS5UABdoRzSlAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAAAABk aFqT2EZtSAkIc0gJCAALrWsAAM1rAADOawAAIGwAADBsAAAxbAAAdWwAANtsAAAsbQAAdW0AALtt AADObQAAz20AABRuAABYbgAAmG4AAN1uAADybgAA824AAAVvAAAGbwAAQW8AAEJvAACKbwAAy28A ABFwAABYcAAAWXAAAJtwAADicAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2SHZe0AAB2FawAA5WsAAPFrAAD5awAAeGwAAI9sAACUbAAAq2wAALNsAAC4bAAAvWwA AMFsAADVbAAA1mwAANdsAADabAAAIW0AACltAAArbQAAR20AAExtAABdbQAAYG0AAGRtAABxbQAA dG0AAANvAADv27vvp4fvp4fvh++n74fvc1PvU+9zU+9T7wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAPwAIgRVo6hGLABZokS5UABdoKV13AE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAA AABkaGGT2EZtSAkIc0gJCCcBCIEESAEABWhhk9hGFmgpXXcAT0oDAFFKAwBeSgMAbUgJCHNICQg/ AAiBFWjqEYsAFmiRLlQAF2gpXXcAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRoYJPYRm1I CQhzSAkIJwEIgQRIAQAFaGCT2EYWaClddwBPSgMAUUoDAF5KAwBtSAkIc0gJCD8ACIEVaOoRiwAW aJEuVAAXaClddwBPSgMAUUoDAF5KAwBjSAEAZGgAAAAAZGgAAAAAZGhfk9hGbUgJCHNICQgnAQiB BEgBAAVoX5PYRhZoKV13AE9KAwBRSgMAXkoDAG1ICQhzSAkIIBVo6hGLABZokS5UAE9KAwBRSgMA XkoDAG1ICQhzSAkIGgNvAAAEbwAAX30AAGB9AACHqQAAiakAAEzRAABN0QAA7tQAAPPUAAD41AAA /dQAAP7UAADE1QAAxdUAANjrAADZ6wAA2usAAPHg0uDE4LDgkHxofOBa4EbgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwEIgQRIAQAFaJmb2GYWaIZU JwBPSgMAUUoDAF5KAwBtSAkIc0gJCBsDagAAAAAWaC8hvAAwShMAT0oEAFFKBABVCAEnAQiBBEgB AAVokpvYZhZoLyG8AE9KAwBRSgMAXkoDAG1ICQhzSAkIJwEIgQRIAQAFaI2b2GYWaC8hvABPSgMA UUoDAF5KAwBtSAkIc0gJCD8ACIEVaOoRiwAWaJEuVAAXaC8hvABPSgMAUUoDAF5KAwBjSAEAZGgA AAAAZGgAAAAAZGiNm9hmbUgJCHNICQgnAQiBBEgBAAVoipvYZhZoUlF5AE9KAwBRSgMAXkoDAG1I CQhzSAkIGwNqAAAAABZoUlF5ADBKEwBPSgQAUUoEAFUIARsDagAAAAAWaLtxxQAwShMAT0oEAFFK BABVCAEgFWjqEYsAFmiRLlQAT0oDAFFKAwBeSgMAbUgJCHNICQgAGwNqAAAAABZoKV13ADBKEwBP SgQAUUoEAFUIAQAR4nAAAClxAABucQAAtXEAAP5xAABFcgAAjHIAANJyAAAJcwAACnMAAFNzAACY cwAA4HMAAPFzAADycwAAO3QAAIF0AADCdAAABnUAAAd1AAAIdQAACXUAAFJ1AABTdQAAVHUAAJ11 AACedQAAn3UAAON1AAAVdgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAA BA8AZ2SHZe0AAB0VdgAAFnYAAF52AAChdgAA6nYAACZ3AAAndwAAO3cAADx3AABzdwAAdHcAALd3 AADNdwAAzncAABd4AAAreAAALHgAAHV4AACneAAAqHgAAO94AAAEeQAABXkAAE15AACIeQAAiXkA AMl5AAAQegAAWHoAAJ96AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZIdl7QAAHZ96AADLegAAzHoAABN7AABaewAAm3sAANt7AADcewAAJXwAAGl8AAB6fAAAe3wA AHx8AAB9fAAAfnwAAH98AACAfAAAgXwAAIJ8AACDfAAAhHwAAM18AADOfAAAz3wAABh9AAAZfQAA Gn0AAGF9AABifQAAqX0AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQP AGdkh2XtAAAdqX0AAOl9AAAgfgAAIX4AADJ+AAAzfgAAen4AAI5+AACPfgAAzX4AABJ/AABZfwAA n38AAN5/AAD8fwAA/X8AAEKAAACJgAAA0YAAABGBAABWgQAAmYEAANqBAAAgggAAaIIAAHiCAAB5 ggAAvoIAAAeDAABHgwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2SHZe0AAB1HgwAASIMAAI+DAADQgwAA3IMAAN2DAAAghAAAXoQAAJeEAACYhAAAqoQAAKuEAADU hAAA1YQAANaEAADXhAAA2IQAANmEAADahAAA24QAACSFAAAlhQAAJoUAAG+FAABwhQAAcYUAAImF AACKhQAAqIUAAKmFAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBn ZIdl7QAAHamFAADGhQAAx4UAAPOFAAD0hQAAB4YAAAiGAABPhgAAgoYAAIOGAACUhgAAlYYAAN2G AAAjhwAAZocAAK6HAAD1hwAAO4gAAIKIAACDiAAAyYgAABGJAABYiQAAoIkAAL6JAAC/iQAABooA AE+KAACSigAA2YoAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk h2XtAAAd2YoAANqKAADrigAA7IoAACeLAAAoiwAAb4sAALOLAAD4iwAANowAADeMAAB5jAAAwIwA AAeNAABMjQAAk40AAJSNAACVjQAAlo0AAN+NAADgjQAA4Y0AACqOAAArjgAALI4AAHWOAAC8jgAA BY8AAEuPAACPjwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SH Ze0AAB2PjwAA1o8AABmQAAApkAAAKpAAAHKQAAC2kAAA8pAAAPOQAAA7kQAAf5EAAMaRAAAGkgAA TJIAAGGSAABikgAAdpIAAHeSAACukgAAr5IAAPKSAAAHkwAACJMAAFGTAACXkwAA35MAABqUAAAb lAAAX5QAAKeUAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl 7QAAHaeUAADmlAAAL5UAAEaVAABHlQAAiJUAAM2VAAAQlgAAQ5YAAESWAACLlgAAyJYAAMmWAADK lgAAy5YAAMyWAADNlgAAzpYAABeXAAAYlwAAGZcAAGKXAABjlwAAZJcAAK2XAACulwAA85cAABSY AAAVmAAAJpgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2Xt AAAdJpgAACeYAABpmAAAdZgAAHaYAAC7mAAAAJkAACGZAAAimQAAZ5kAAKaZAACnmQAAuZkAALqZ AADmmQAA55kAAP+ZAAAAmgAAHpoAAB+aAAA8mgAAPZoAAG+aAABwmgAAlZoAAJaaAADImgAAyZoA ANyaAADdmgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0A AB3dmgAAIpsAAFqbAABbmwAAbJsAAG2bAACtmwAA9psAAAmcAAAKnAAAT5wAAICcAACBnAAAgpwA AIOcAACEnAAAhZwAAM6cAADPnAAA0JwAABmdAAAanQAAG50AAF6dAACZnQAAmp0AAOGdAAABngAA Ap4AAEieAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAA HUieAABYngAAWZ4AAJ6eAADmngAAKZ8AAHKfAACFnwAAhp8AAM+fAAAYoAAAXaAAAKSgAACloAAA tqAAALegAADyoAAA86AAADqhAACBoQAAyqEAAP6hAAD/oQAAQaIAAIiiAADPogAAFKMAAFujAACk owAA6KMAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd 6KMAADGkAAB2pAAAvaQAAAalAABPpQAAZ6UAAGilAACspQAA9KUAAD2mAAA+pgAAP6YAAECmAABB pgAAQqYAAIumAACMpgAAjaYAANamAADXpgAA2KYAABynAABipwAAq6cAAPKnAAA0qAAAeKgAAHmo AAC6qAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB26 qAAAAKkAAEapAACLqQAAjKkAAKCpAAChqQAA2KkAANmpAAAcqgAAMqoAADOqAAB0qgAAtKoAAMiq AADJqgAAEqsAAESrAABFqwAAjKsAAKGrAACiqwAA6qsAACWsAAAmrAAAZqwAAK2sAAD1rAAAO60A AGetAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHWet AABorQAAr60AAPWtAAA2rgAAdq4AAHeuAADArgAAA68AABSvAAAVrwAAFq8AABevAAAYrwAAGa8A AGKvAABjrwAAZK8AAK2vAACurwAAr68AAOmvAADqrwAALrAAAHawAACvsAAAsLAAAMGwAADCsAAA /7AAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd/7AA AACxAABCsQAAibEAALexAAC4sQAA/rEAAEWyAACFsgAArrIAAK+yAADBsgAAwrIAAOCyAADhsgAA +bIAAPqyAAAYswAAGbMAADazAAA3swAAZbMAAGazAAB5swAAerMAAMGzAADpswAA6rMAAPuzAAD8 swAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB38swAA P7QAAIi0AADPtAAAErUAABO1AABYtQAAn7UAAOa1AAAstgAAcLYAAHG2AABytgAAc7YAALy2AAC9 tgAAvrYAAAe3AAAItwAACbcAAFC3AACWtwAA3rcAACG4AAAiuAAAabgAAKy4AADpuAAACbkAAAq5 AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHQq5AABR uQAAl7kAANm5AAAeugAAYboAAKm6AADyugAA87oAADq7AACBuwAAyLsAAA+8AABXvAAAn7wAAKC8 AADnvAAAML0AAHK9AAC4vQAA/r0AAEa+AACPvgAAor4AAKO+AADsvgAANb8AAHi/AACmvwAAp78A APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdp78AALi/ AAC5vwAA9L8AAPW/AAA8wAAAgcAAAMrAAAARwQAAMMEAADHBAAAywQAAM8EAAHzBAAB9wQAAfsEA AMfBAADIwQAAycEAAA/CAABTwgAAmcIAANzCAADdwgAAIcMAAGbDAACqwwAA88MAACrEAAArxAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB0rxAAAc8QA ALjEAAD+xAAARsUAAGzFAABtxQAAgcUAAILFAADIxQAAycUAAPrFAAD7xQAAQ8YAAIvGAADOxgAA BMcAAAXHAABOxwAAlccAAN7HAAAiyAAAZ8gAAGjIAACsyAAA6sgAAOvIAAAyyQAAeMkAAIzJAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHYzJAACNyQAA 0skAABPKAABWygAAn8oAAMPKAADEygAADcsAAA7LAAAPywAAEMsAAFnLAABaywAAW8sAAKTLAACl ywAApssAANfLAADYywAAH8wAAGfMAACszAAA28wAANzMAAAizQAAas0AAJ/NAACgzQAA580AAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd580AAC7OAAA9 zgAAPs4AAIXOAADJzgAAD88AAFDPAABjzwAAZM8AAGXPAABmzwAAZ88AAGjPAABpzwAAas8AAGvP AABszwAAbc8AAG7PAABvzwAAcM8AAHHPAAByzwAAc88AAHTPAAB1zwAAds8AAHfPAAB4zwAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB14zwAAec8AAHrP AAB7zwAAfM8AAH3PAAB+zwAAf88AAIDPAACBzwAAgs8AAMvPAADMzwAAzc8AABbQAAAX0AAAGNAA AF/QAABg0AAApdAAAO7QAAAz0QAAc9EAALTRAADA0QAAwdEAANPRAADU0QAABdIAAAbSAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHQbSAAAe0gAAH9IA AD3SAAA+0gAAW9IAAFzSAABt0gAAbtIAAH/SAACA0gAAtNIAALXSAADQ0gAA0dIAAAnTAAAK0wAA HdMAAB7TAABV0wAAVtMAAH7TAAB/0wAAxtMAAMfTAADY0wAA2dMAAB7UAABi1AAAq9QAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdq9QAAP/UAABE1QAA i9UAANXVAAAd1gAALdYAAC7WAAAv1gAAMNYAAHnWAAB61gAAe9YAAMTWAADF1gAAxtYAANfWAADY 1gAAINcAAGbXAACp1wAA8NcAADjYAAB72AAAqdgAAKrYAADw2AAANdkAAHvZAACz2QAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB2z2QAAtNkAAPbZAAA/ 2gAAhdoAAM7aAAAN2wAAK9sAACzbAABy2wAAu9sAAObbAADn2wAA+9sAAPzbAABE3AAARdwAAITc AADE3AAA5twAAOfcAAAt3QAAOd0AADrdAAB83QAAw90AAAneAABO3gAAhN4AAIXeAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHYXeAACh3gAAot4AAKPe AACk3gAApd4AAKbeAACn3gAAqN4AAPHeAADy3gAA894AADzfAAA93wAAPt8AAGHfAABi3wAAd98A AHjfAADA3wAABOAAAEjgAACL4AAAyuAAAMvgAADj4AAA5OAAACvhAABW4QAAV+EAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdV+EAAIThAACF4QAAmuEA AJvhAADi4QAAJOIAAGjiAACx4gAA5+IAAOjiAAAA4wAAAeMAAErjAACO4wAAnuMAAJ/jAACg4wAA oeMAAKLjAACj4wAApOMAAKXjAACm4wAAp+MAAKjjAACp4wAAquMAAKvjAACs4wAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB2s4wAAreMAAK7jAACv4wAA sOMAALHjAACy4wAAs+MAAPzjAAD94wAA/uMAAEfkAABI5AAASeQAAI7kAACZ5AAAmuQAAOHkAAAg 5QAAYuUAAKrlAADx5QAA/eUAAP7lAAAR5gAAEuYAAEbmAABH5gAAYOYAAGHmAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHWHmAAB/5gAAgOYAAJ3mAACe 5gAAr+YAALDmAADB5gAAwuYAAPjmAAD55gAALecAAC7nAABT5wAAVOcAAG/nAABw5wAAsOcAAM3n AADO5wAA4ucAAOPnAAAa6AAAG+gAAE3oAABO6AAAlegAAJboAACo6AAAqegAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdqegAAO7oAAAy6QAAe+kAAHzp AAB96QAAfukAAMfpAADI6QAAyekAABLqAAAT6gAAFOoAAFzqAACk6gAA6OoAACzrAABv6wAAjusA AI/rAACh6wAAousAAOLrAAAm7AAAbuwAAKLsAACj7AAA6uwAADHtAAB17QAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB3a6wAA2+sAAOPsAADk7AAAxS4B AMYuAQBXLwEAny8BAE8wAQBQMAEAJEsBAHNLAQADTQEAVk0BANZTAQAfVAEA3lwBAN9cAQDgXAEA DV0BABhdAQAtXQEAll0BANBdAQDRXQEA310BAP1dAQAKXgEAcF4BAHFeAQByXgEA387AzrLOpc6X zqXOpc6lzoZ8cWlxaWFZYVlhWXFPAAAAABMDagAAAAAWaGRucgAwShMAVQgBDhZoigwCAG1ICQhz SAkIAA4WaEExswBtSAkIc0gJCAAOFmiAWXQAbUgJCHNICQgAFBVogFl0ABZogFl0AG1ICQhzSAkI ABMDagAAAAAWaIBZdAAwShMAVQgBIBVo6hGLABZoh2XtAE9KAwBRSgMAXkoDAG1ICQhzSAkIABsD agAAAAAWaDAalgAwShMAT0oEAFFKBABVCAEYFWiHZe0AFmiRLlQAT0oDAFFKAwBeSgMAABsDagAA AAAWaD9VXQAwShMAT0oEAFFKBABVCAEbA2oAAAAAFmiGVCcAMEoTAE9KBABRSgQAVQgBIBVo6hGL ABZokS5UAE9KAwBRSgMAXkoDAG1ICQhzSAkIAD8ACIEVaOoRiwAWaJEuVAAXaIZUJwBPSgMAUUoD AF5KAwBjSAEAZGgAAAAAZGgAAAAAZGiZm9hmbUgJCHNICQgAHnXtAAC+7QAABu4AAEnuAACQ7gAA ke4AANfuAAAc7wAAYu8AAJrvAACb7wAAsO8AALHvAAD57wAA+u8AAELwAACH8AAArvAAAK/wAAD1 8AAAAfEAAALxAABE8QAAi/EAANHxAAAW8gAATPIAAE3yAABq8gAAa/IAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAda/IAAGzyAABt8gAAbvIAAG/yAABw 8gAAufIAALryAAC78gAABPMAAAXzAAAG8wAAKvMAACvzAABB8wAAQvMAAInzAADQ8wAAFPQAAF30 AACT9AAAlPQAAK30AACu9AAA9fQAACH1AAAi9QAAUPUAAFH1AABn9QAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB1n9QAAaPUAAK71AAD09QAAOPYAAIH2 AAC39gAAuPYAANH2AADS9gAAG/cAAF/3AABx9wAAcvcAAHP3AAB09wAAdfcAAHb3AAB39wAAePcA AHn3AAB69wAAe/cAAHz3AAB99wAAfvcAAH/3AACA9wAAgfcAAIL3AAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHYL3AACD9wAAhPcAAIX3AACG9wAAz/cA AND3AADR9wAAGvgAABv4AAAc+AAAZPgAAGX4AACp+AAA8vgAADb5AAB1+QAAtvkAAML5AADD+QAA 1vkAANf5AAAa+gAAJfoAACb6AAA/+gAAQPoAAF76AABf+gAAfPoAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdfPoAAH36AACO+gAAj/oAAKD6AACh+gAA 1foAANb6AADx+gAA8voAACr7AAAr+wAAP/sAAED7AAB3+wAAePsAAKD7AACh+wAA6PsAAOn7AAD7 +wAA/PsAAEH8AACF/AAAzvwAABf9AABb/QAAov0AAOv9AAAz/gAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB0z/gAANP4AADX+AAA2/gAAf/4AAID+AACB /gAAyv4AAMv+AADM/gAA3P4AAN3+AADv/gAA8P4AADn/AAB//wAAwv8AAAgAAQBQAAEAkwABAMEA AQDCAAEACAEBAE0BAQCTAQEAywEBAMwBAQAOAgEAVwIBAJ0CAQD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHZ0CAQDmAgEAJQMBAEMDAQBEAwEAigMBANID AQAEBAEABQQBABoEAQAbBAEAYwQBAGQEAQCtBAEA9QQBAAEFAQACBQEASAUBAFQFAQBVBQEAlwUB AN4FAQAkBgEAaQYBAJ8GAQCgBgEAoQYBAKIGAQCjBgEApAYBAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAdpAYBAKUGAQCmBgEA7wYBAPAGAQDxBgEAOgcB ADsHAQA8BwEAWQcBAFoHAQB+BwEAfwcBAJUHAQCWBwEA3QcBACEIAQBlCAEAqAgBAOcIAQDoCAEA AQkBAAIJAQBJCQEAdQkBAHYJAQCkCQEApQkBALsJAQC8CQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB28CQEAAgoBAEQKAQCICgEA0AoBAAkLAQAKCwEA IwsBACQLAQBtCwEAsQsBAMQLAQDFCwEAxgsBAMcLAQDICwEAyQsBAMoLAQDLCwEAzAsBAM0LAQDO CwEAzwsBANALAQDRCwEA0gsBANMLAQDUCwEA1QsBANYLAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHdYLAQDXCwEAIAwBACEMAQAiDAEAawwBAGwMAQBt DAEAsgwBAL0MAQC+DAEABA0BAEMNAQCEDQEAzA0BABMOAQAfDgEAIA4BADMOAQA0DgEAZw4BAGgO AQCBDgEAgg4BAKAOAQChDgEAvg4BAL8OAQDQDgEA0Q4BAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd0Q4BAOIOAQDjDgEAGQ8BABoPAQBODwEATw8BAHQP AQB1DwEAkA8BAJEPAQDRDwEA7g8BAO8PAQADEAEABBABADsQAQA8EAEAbhABAG8QAQC2EAEAtxAB AMkQAQDKEAEADxEBAFMRAQCcEQEAnREBAJ4RAQCfEQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB2fEQEA6BEBAOkRAQDqEQEAMxIBADQSAQA1EgEAfhIB AMYSAQAKEwEAThMBAJETAQCwEwEAsRMBAMMTAQDEEwEADRQBAFIUAQCYFAEAwRQBAMIUAQAIFQEA TxUBAJMVAQDcFQEAJBYBAGcWAQCuFgEArxYBAPUWAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAAHfUWAQA6FwEAgBcBALgXAQC5FwEAzhcBAM8XAQAXGAEA GBgBAF8YAQCkGAEAyxgBAMwYAQASGQEAHhkBAB8ZAQBhGQEAqBkBAO4ZAQAzGgEAaRoBAGoaAQCH GgEAiBoBAIkaAQCKGgEAixoBAIwaAQCNGgEA1hoBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd1hoBANcaAQDYGgEAIRsBACIbAQAjGwEARxsBAEgbAQBe GwEAXxsBAKYbAQDtGwEAMRwBAHQcAQCzHAEAtBwBAM0cAQDOHAEAFR0BAEEdAQBCHQEAcB0BAHEd AQCHHQEAiB0BANEdAQATHgEAVx4BAKAeAQDWHgEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAAAAAAABA8AZ2SHZe0AAB3WHgEA1x4BAPAeAQDxHgEAOh8BAH4fAQCQHwEAkR8BAJIf AQCTHwEAlB8BAJUfAQCWHwEAlx8BAJgfAQCZHwEAmh8BAJsfAQCcHwEAnR8BAJ4fAQCfHwEAoB8B AKEfAQCiHwEAox8BAKQfAQClHwEA7h8BAO8fAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZIdl7QAAHe8fAQDwHwEAOSABADogAQA7IAEAdyABAHggAQC+IAEAByEB AE8hAQBQIQEAYyEBAGQhAQCJIQEAiiEBAKMhAQCkIQEAwiEBAMMhAQDgIQEA4SEBAPIhAQDzIQEA BCIBAAUiAQA1IgEANiIBAHQiAQB1IgEAiSIBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAAAAAAAAQPAGdkh2XtAAAdiSIBAIoiAQDBIgEAwiIBANciAQDYIgEAHyMBACAjAQAyIwEA MyMBAHsjAQC/IwEACCQBAFEkAQCXJAEA4CQBACclAQBvJQEAfCUBAH0lAQCPJQEAkCUBANglAQAf JgEAICYBACEmAQAiJgEAayYBAGwmAQBtJgEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2SHZe0AAB1tJgEAtiYBALcmAQC4JgEA+yYBAEInAQCEJwEAwycBAP0nAQD+ JwEAEygBABQoAQBLKAEATCgBAG4oAQBvKAEAtygBALgoAQAAKQEASCkBAEkpAQCQKQEAtSkBALYp AQC3KQEAuCkBALkpAQC6KQEAuykBALwpAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAAAAAAAEDwBnZIdl7QAAHbwpAQC9KQEAvikBAL8pAQDAKQEAwSkBAMIpAQDDKQEAxCkBAMUp AQDGKQEAxykBAMgpAQDJKQEAyikBAMspAQDMKQEAzSkBAM4pAQDPKQEA0CkBANEpAQDSKQEA0ykB ANQpAQDVKQEAHioBAB8qAQAgKgEAaSoBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkh2XtAAAdaSoBAGoqAQBrKgEAoioBAKMqAQDoKgEAMSsBAHkrAQC3KwEA+ysB AA0sAQAOLAEAKywBACwsAQBwLAEAtSwBAPwsAQBCLQEAhy0BAIgtAQCkLQEApS0BAO4tAQA0LgEA NS4BAFUuAQBWLgEAlS4BANouAQANLwEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAAAAAAABA8AZ2SHZe0AAB0NLwEADi8BAFQvAQCcLwEAqy8BAKwvAQDxLwEAODABAFEwAQBSMAEA djABAHcwAQC6MAEAAjEBAEYxAQCHMQEAzjEBABUyAQBUMgEAZTIBAGYyAQCoMgEAqTIBAKoyAQCr MgEA9DIBAPUyAQD2MgEAPzMBAEAzAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZIdl7QAAHUAzAQBBMwEAcDMBAHEzAQCiMwEAozMBANEzAQDSMwEAAjQBAAM0AQAm NAEAJzQBAGg0AQCkNAEApTQBALw0AQC9NAEABTUBAEw1AQBzNQEAdDUBAIs1AQCMNQEA0jUBABQ2 AQA8NgEAPTYBAII2AQDLNgEAzDYBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA AAAAAAQPAGdkh2XtAAAdzDYBAM02AQDONgEAzzYBANA2AQDRNgEA0jYBANM2AQDUNgEA1TYBANY2 AQDXNgEA2DYBANk2AQDaNgEA2zYBANw2AQDdNgEA3jYBAN82AQDgNgEA4TYBAOI2AQDjNgEALDcB AC03AQAuNwEAdzcBAHg3AQB5NwEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2SHZe0AAB15NwEAiTcBAIo3AQCxNwEAsjcBAPs3AQA7OAEAgjgBAMs4AQASOQEAVzkB AJ45AQDmOQEA8jkBAPM5AQA6OgEAgjoBAMU6AQALOwEAVDsBAJo7AQC/OwEACDwBAEc8AQCLPAEA 0TwBABU9AQBePQEApz0BAO89AQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAA AAAEDwBnZIdl7QAAHe89AQAPPgEAED4BAFg+AQCePgEA5T4BAP0+AQD+PgEARz8BAI4/AQDSPwEA FkABAF9AAQCoQAEA8UABACBBAQAhQQEAIkEBACNBAQAkQQEAJUEBACZBAQAnQQEAcEEBAHFBAQBy QQEAu0EBALxBAQC9QQEA2kEBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkh2XtAAAd2kEBANtBAQAhQgEALUIBAC5CAQB3QgEAwEIBAAlDAQBQQwEAlkMBAMFDAQDC QwEACkQBAFNEAQCaRAEAy0QBAMxEAQAURQEAVkUBAGNFAQBkRQEAZUUBAGZFAQBnRQEAaEUBAGlF AQBqRQEAa0UBAGxFAQBtRQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAA BA8AZ2SHZe0AAB1tRQEAbkUBAG9FAQBwRQEAcUUBAHJFAQBzRQEAdEUBAHVFAQB2RQEAd0UBAHhF AQB5RQEAekUBAHtFAQB8RQEAfUUBAH5FAQB/RQEAgEUBAIFFAQCCRQEAy0UBAMxFAQDNRQEAFkYB ABdGAQAYRgEAMUYBADJGAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZIdl7QAAHTJGAQBmRgEAZ0YBAGhGAQBpRgEAakYBAGtGAQBsRgEAbUYBAG5GAQBvRgEAcEYB AHFGAQByRgEAc0YBAHRGAQB1RgEAdkYBAHdGAQB4RgEAeUYBAHpGAQB7RgEAfEYBAH1GAQB+RgEA f0YBAIBGAQCBRgEAgkYBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQP AGdkh2XtAAAdgkYBAINGAQCERgEAhUYBAIZGAQCHRgEAiEYBAIlGAQCKRgEAi0YBAIxGAQCNRgEA jkYBAI9GAQCQRgEAkUYBAJJGAQCTRgEAlEYBAJVGAQCWRgEA30YBAOBGAQDhRgEAKkcBACtHAQAs RwEAQkcBAENHAQCIRwEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2SHZe0AAB2IRwEA0EcBAA5IAQAPSAEAVUgBAJlIAQC4SAEAuUgBAP1IAQBDSQEAhUkBALRJAQC1 SQEAtkkBALdJAQC4SQEAuUkBALpJAQC7SQEAvEkBAL1JAQC+SQEAv0kBAMBJAQDBSQEAwkkBAMNJ AQDESQEAxUkBAMZJAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBn ZIdl7QAAHcZJAQDHSQEAyEkBAMlJAQDKSQEAy0kBAMxJAQDNSQEAzkkBAM9JAQDQSQEA0UkBANJJ AQDTSQEA1EkBANVJAQDWSQEA10kBANhJAQDZSQEAIkoBACNKAQAkSgEAbUoBAG5KAQBvSgEAf0oB AIBKAQCcSgEAnUoBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk h2XtAAAdnUoBAN9KAQAgSwEAIUsBAGVLAQCtSwEA8EsBAPFLAQA2TAEAdkwBAHdMAQC/TAEA/0wB AABNAQBITQEAi00BALxNAQC9TQEAA04BAEZOAQBiTgEAY04BAKlOAQDvTgEAOE8BADlPAQB/TwEA vE8BAL1PAQACUAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SH Ze0AAB0CUAEASVABAI9QAQDTUAEAAVEBAAJRAQBLUQEAilEBAMRRAQDFUQEA41EBAORRAQAPUgEA V1IBAJ1SAQDmUgEA51IBAOhSAQDpUgEAMlMBADNTAQA0UwEAfVMBAH5TAQB/UwEAsFMBALFTAQDI UwEAEVQBAFVUAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl 7QAAHVVUAQCeVAEA4lQBAPtUAQD8VAEAPVUBAH1VAQCVVQEAllUBAJdVAQCYVQEAmVUBAJpVAQCb VQEAnFUBAJ1VAQCeVQEAn1UBAKBVAQChVQEAolUBAKNVAQCkVQEApVUBAKZVAQCnVQEAqFUBAKlV AQCqVQEAq1UBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2Xt AAAdq1UBAKxVAQCtVQEArlUBAK9VAQCwVQEAsVUBALJVAQCzVQEAtFUBALVVAQC2VQEAt1UBALhV AQC5VQEAulUBALtVAQC8VQEABVYBAAZWAQAHVgEAUFYBAFFWAQBSVgEAZVYBAGZWAQB2VgEAl1YB AK1WAQDBVgEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0A AB3BVgEAx1YBAMhWAQDjVgEA+1YBAPxWAQD9VgEADlcBAElXAQBmVwEAeVcBAH9XAQCAVwEAmVcB AMFXAQDCVwEAw1cBANJXAQDzVwEA+VcBAPpXAQAVWAEAMVgBADJYAQAzWAEAQFgBAGdYAQB+WAEA lVgBAJxYAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZIdl7QAA HZxYAQCdWAEAt1gBANFYAQDSWAEA01gBAORYAQDvWAEAFlkBACtZAQAyWQEAM1kBAE1ZAQBsWQEA bVkBAG5ZAQBvWQEAuFkBALlZAQC6WQEAA1oBAARaAQAFWgEAD1oBABdaAQBeWgEAcVoBAHdaAQB4 WgEAkloBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkh2XtAAAd kloBAKxaAQCtWgEArloBALxaAQDvWgEA+FoBAP5aAQD/WgEAGVsBADpbAQA7WwEAPFsBAE5bAQBt WwEAkVsBAJ1bAQCmWwEAp1sBAMFbAQDdWwEA3lsBAN9bAQDvWwEAG1wBADVcAQBIXAEATlwBAE9c AQBpXAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAB1p XAEAh1wBAIhcAQCJXAEAilwBAItcAQCMXAEAjVwBAI5cAQCPXAEAkFwBAJFcAQCSXAEAk1wBAJRc AQCVXAEA3lwBAN9cAQBnXQEAcV4BAKpeAQAvXwEA4l8BAM1gAQBkYQEAs2EBAC9iAQCsYgEADWMB APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAAEDwBnZIdl7QAAHHJe AQCYXgEAqV4BAKpeAQCrXgEAz14BANBeAQAfXwEAJ18BAC9fAQAwXwEApF8BAKVfAQCmXwEA4V8B AOJfAQDjXwEATWABAMxgAQDNYAEAzmABAGRhAQBlYQEAqWEBAKphAQCsYQEAsGEBALNhAQC0YQEA DWIBAC5iAQAvYgEAMGIBAHBiAQD17fXj9dv17fXRxr7Gvsa0qaGpl4yCd293b3eCd293ZVoAAAAA AAAAAAAAABQVaC8hvAAWaC8hvABtSAkIc0gJCAATA2oAAAAAFmgvIbwAMEoTAFUIAQ4WaFJReQBt SAkIc0gJCAAUFWhSUXkAFmhSUXkAbUgJCHNICQgAEwNqAAAAABZoUlF5ADBKEwBVCAEUFWi7ccUA Fmi7ccUAbUgJCHNICQgAEwNqAAAAABZou3HFADBKEwBVCAEOFmgpXXcAbUgJCHNICQgAFBVoKV13 ABZoKV13AG1ICQhzSAkIABMDagAAAAAWaClddwAwShMAVQgBDhZoRzSlAG1ICQhzSAkIABQVaEc0 pQAWaEc0pQBtSAkIc0gJCAATA2oAAAAAFmhHNKUAMEoTAFUIAQ4WaAN0XgBtSAkIc0gJCAATA2oA AAAAFmhkbnIAMEoTAFUIAQ4WaGRucgBtSAkIc0gJCAAUFWhkbnIAFmhkbnIAbUgJCHNICQghcGIB AAtjAQAMYwEADWMBAA5jAQA1YwEAUmQBAFNkAQBUZAEAWWQBAFpkAQDzZAEAUWUBAFNlAQCDZQEA hGUBAIVlAQCGZQEA+PDl29Dw0MbCuK2lmaWtlYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBVo6hGLABZoh2XtAE9KAwBRSgMAXkoD AG1ICQhzSAkIAAYWaDAalgAAFxVoMBqWABZoMBqWAEgqAW1ICQhzSAkIDhZoMBqWAG1ICQhzSAkI ABQVaDAalgAWaDAalgBtSAkIc0gJCAATA2oAAAAAFmgwGpYAMEoTAFUIAQYWaD9VXQAAEwNqAAAA ABZoP1VdADBKEwBVCAEUFWiGVCcAFmiGVCcAbUgJCHNICQgAEwNqAAAAABZohlQnADBKEwBVCAEU FWgvIbwAFmgvIbwAbUgJCHNICQgADhZohlQnAG1ICQhzSAkIAA4WaC8hvABtSAkIc0gJCBENYwEA VWMBAFNkAQBZZAEACmUBAIRlAQCFZQEAhmUBAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8AZ2SHZe0AAAEAAAABFAAABzYAJlAB ADGQaAE6cOoRiwAfsNAvILDgPSGwNgUisDcFI5CJBSSQUwMlsAAAF7DEAhiwxAIMkMQCAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoEGAASAAEACwEPAAcA BAAEAAQAAAAEAAgAAACYAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAA dgIAAHYCAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA+AgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAqAAAADYGAAA2BgAAFgAAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAAuAAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAAGgBAABIAQAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACw AwAANgYAADIGAAAYAAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAE AABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAyBgAAKAIAANgBAADoAQAAIAQA ADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAA MAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAw BAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAE AABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQA AEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAA QAQAAFAEAABgBAAAcAQAAIAEAACQBAAAOAEAAFgBAAD4AQAACAIAABgCAABWAgAAfgIAACAAAABP SgQAUEoEAFFKBABfSAEEbUgHBG5IBwRzSAcEdEgHBAAAAABKAABg8f8CAEoADBAAAPwIcwAAAAYA TgBvAHIAbQBhAGwAAAAMAAAAEmQUAQEAFKTIABgAQ0oWAF9IAQRhShYAbUgHBHNIBwR0SAkEAAAA AAAAAAAAAAAAAAAAAAAARABBYPL/oQBEAAwNAAAAAAAAEAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMHQAAAAAAADAGDABUAGEAYgBs AGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACgA ayD0/8EAKAAADQAAAAAAADAGBwBOAG8AIABMAGkAcwB0AAAAAgAMAAAAAABKAFpAAQDyAEoADAwQ AIdl7QAwBgoAUABsAGEAaQBuACAAVABlAHgAdAAAAAwADwASZPAAAQAUpAAAEABDShUAT0oFAFFK BQBhShUARgD+D6IAAQFGAAwADwCHZe0AMAYPAFAAbABhAGkAbgAgAFQAZQB4AHQAIABDAGgAYQBy AAAAEABDShUAT0oFAFFKBQBhShUAUgCZAAEAEgFSAAwNEgDobrsAMAYMAEIAYQBsAGwAbwBvAG4A IABUAGUAeAB0AAAADAARABJk8AABABSkAAAUAENKEABPSgYAUUoGAF5KBgBhShAAUgD+D6IAIQFS AAwBEQDobrsAMAYRAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0ACAAQwBoAGEAcgAAABgAQ0oQAE9K BgBRSgYAXkoGAGFKEAB0SAkEQgAnQKIAMQFCAAwNAACAWXQAMAYRAEMAbwBtAG0AZQBuAHQAIABS AGUAZgBlAHIAZQBuAGMAZQAAAAgAQ0oQAGFKEAA8AB5AAQBCATwADA0VAIBZdAAwBgwAQwBvAG0A bQBlAG4AdAAgAFQAZQB4AHQAAAACABQACABDShQAYUoUAD4A/g+iAFEBPgAMARQAgFl0ADAGEQBD AG8AbQBtAGUAbgB0ACAAVABlAHgAdAAgAEMAaABhAHIAAAAEAHRICQRAAGoAQQFCAUAADA0XAIBZ dAAwBg8AQwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAAAACABYABgA1CIFcCIFGAP4PUgFx AUYADAEWAIBZdAAwBhQAQwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAIABDAGgAYQByAAAA BgA1CAFcCAFQSwMEFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1s rJHLasMwEEX3hf6D0LbYcroopdjOokl3fSzSDxjksS1qj4Q0Ccnfd+y4ULoILXQjEGLOmXtVro/j oA4Yk/NU6VVeaIVkfeOoq/T77im71yoxUAODJ6z0CZNe19dX5e4UMCmZplTpnjk8GJNsjyOk3Ack eWl9HIHlGjsTwH5Ah+a2KO6M9cRInPHE0HX5KgtE16B6g8gvMIrHsKDw+/kMJICYC1irxzNhWqLS EMLgLLBEMAdqfugz37bOYuPtfhRpPoMX2M0EM79cYPU/6i/nBlvYD6y2R+niXH/EIf0t21JrLpNz /tS7kC4YLpe3tGHmv60/AQAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxz Ly5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+ rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8 Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp 5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAA dGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5wa Qceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNR fSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAA IQCWta3ilgYAAFAbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2 Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVY XpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHe tY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU 4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTb q5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZW ljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5m t7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf 46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccP nh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/8 9uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0p Zpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7 ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaL tmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q 8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjt cVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLr xxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gpl V/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw 654mEsqMdChRyiUc7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFau ZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+ki GeGAZD7Ses/7qG6clMeKuQmA2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqy pJycLEFHba/VXG56yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJO HUiFVFtYRjY0zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5R RAyi4AiN2ETsY3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg 3krigW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4 i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QO CRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV 7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7 ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1O YxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyY PIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1l L19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUN Nj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeR SyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z /TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIKK vBP6AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAUAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5h Z2VyLnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAWAAAAAAAAAAAAAAAAANECAAB0aGVt ZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAA AAAAmwkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAF AF0BAACWCgAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9u ZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1h dHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIi IHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJh Y2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2Nl bnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPggAUgBlAGkAbgBoAGEAcgBk AMpEAABcWAAAxVkAAFVfAAADZwAAX3UAAIehAACIoQAAxM0AAOPkAADFJgEATygBAIZdAQACAFIA UwAAAAAAAAAAAAAAAAAAAAAAAAAAAKnxMw4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAPMJNA4C AFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAE0KNA4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAANkp NQ4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAEssNQ4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAA AD40NQ4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAJ+ENg4CAFIAUwAAAAAAAAAAAAAAAAAAAAAA AAAAAASFNg4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAJCINg4CAFIAUwAAAAAAAAAAAAAAAAAA AAAAAAAAAEWKNg4CAFIAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAEaMNg4CAFIAUwAAAAAAAAAAAAAA AAAAAAAAAAAAAHabNg7di9gmAAAAAAAAAAAAAAAAAAA4jNgmAAAAAAAAAAAAAAAAAABTk9hGAAAA AAAAAAAAAAAAAABak9hGAAAAAAAAAAAAAAAAAABkk9hGAAAAAAAAAAAAAAAAAACJk9hGAAAAAAAA AAAAAAAAAACEm9hmAAAAAAAAAAAAAAAAAACGm9hmAAAAAAAAAAAAAAAAAACZm9hmAAAAAAAAAAAA AAAAAAChm9hmAAAAAAAAAAAAAAAAAACjm9hmAAAAAAAAAAAAAAAAAADxm9hmAAAAAAAAAAAAAAAA AAAAAAAAkgEAAMsBAABQAgAAAwMAAO4DAACFBAAA1AQAAFAFAAAuBgAAdAcAAHoHAAClCAAAqAgA AAAAAACGXQEADAAAQgIAAAD/////AAgAAFtPAACBVAAAoVUAAOxdAABdZgAAqmkAAIVrAAADbwAA 2usAAHJeAQBwYgEAhmUBALMAAADHAAAAygAAAMsAAADNAAAA0QAAANMAAADVAAAA1gAAAPYAAAAe AQAAHwEAAAAIAABvDQAAfBEAANsSAACIEwAA8BgAAJ0ZAADZHwAAjSUAAC8tAADZMgAAbjkAANs7 AAAmQwAAhUQAAN5EAACERgAAmUkAAA1LAADnUAAAZFMAABJZAAAEXgAA7GIAAAdlAAAhaAAArWsA AOJwAAAVdgAAn3oAAKl9AABHgwAAqYUAANmKAACPjwAAp5QAACaYAADdmgAASJ4AAOijAAC6qAAA Z60AAP+wAAD8swAACrkAAKe/AAArxAAAjMkAAOfNAAB4zwAABtIAAKvUAACz2QAAhd4AAFfhAACs 4wAAYeYAAKnoAAB17QAAa/IAAGf1AACC9wAAfPoAADP+AACdAgEApAYBALwJAQDWCwEA0Q4BAJ8R AQD1FgEA1hoBANYeAQDvHwEAiSIBAG0mAQC8KQEAaSoBAA0vAQBAMwEAzDYBAHk3AQDvPQEA2kEB AG1FAQAyRgEAgkYBAIhHAQDGSQEAnUoBAAJQAQBVVAEAq1UBAMFWAQCcWAEAkloBAGlcAQANYwEA hmUBALQAAAC1AAAAtgAAALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADB AAAAwgAAAMMAAADEAAAAxQAAAMYAAADIAAAAyQAAAMwAAADOAAAAzwAAANAAAADSAAAA1AAAANcA AADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAA AOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA 9AAAAPUAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA/gAAAP8AAAAAAQAAAQEAAAIBAAAD AQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4BAAAPAQAAEAEAABEB AAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAAHAEAAB0BAAAgAQAADwAA 8DgAAAAAAAbwGAAAAAIIAAACAAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA 9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/Ae AAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8MAAoAAAAAAanx Mw7/////AAAAAfMJNA7/////AAAAAU0KNA7/////AAAAAdkpNQ7/////AAAAAUssNQ7/////AAAA AT40NQ7/////AAAAAZ+ENg7/////AAAAAQSFNg7/////AAAAAZCINg7/////AAAAAUWKNg7///// AAAAAUaMNg7/////AAAAAXabNg7/////qUQAAApYAACxWQAA0l4AAPlmAAAadQAAf6AAAH+hAABj zQAApuQAAFkmAQARJwEA4VQBAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkA AAAKAAAACwAAAMpEAABcWAAAxVkAAFVfAAADZwAAX3UAAIehAACIoQAAxM0AAOPkAADFJgEATygB AOFUAQAAAAAAtAYAAL0GAAD/DAAAAw0AAB8NAAAjDQAAQg0AAEYNAADhEAAA6RAAALcSAAC6EgAA PxUAAEIVAABdGgAAYRoAALcfAAC6HwAAfCIAAIAiAADSIgAA1SIAAOIiAADmIgAAmCUAAJwlAACx KAAAtSgAABcpAAAbKQAAZiwAAGosAAACNQAABjUAACI1AAAmNQAARTUAAEk1AADmOAAA7zgAACc+ AAAqPgAAuUAAAMhAAABmQgAAaUIAALBCAACzQgAAGEMAABtDAAA7RgAAP0YAALxIAAC/SAAAVkkA AFlJAABmSQAAakkAAN9JAADiSQAA70kAAPNJAAATSgAAFkoAAHtLAAB+SwAAAEwAAANMAABmTAAA aEwAAJ1NAAChTQAA2E0AANtNAADrTwAA7k8AAFRQAABXUAAAiFAAAI9QAAApUQAALFEAAO1RAADw UQAAFFIAAB1SAABLUwAAT1MAAB1UAAAgVAAA8FUAAPNVAACUVgAAm1YAAKlWAACsVgAAIloAACVa AADJWgAAzFoAAIlbAACQWwAAllsAAJlbAAClXAAAqFwAAPFcAAD0XAAAXF0AAF9dAAAtXgAAMV4A AKteAACvXgAA/V4AAAFfAAB2XwAAeV8AAIZfAACKXwAA9F8AAPxfAAA4YAAAPGAAAKdgAACqYAAA t2AAALtgAAAoYQAAMGEAAEVhAABIYQAAVWEAAFlhAACkYQAApmEAALhiAADAYgAAK2QAAC9kAABB ZAAARGQAAFFkAABVZAAAF2YAABpmAAB+ZgAAgWYAALJmAAC5ZgAAYWcAAGRnAABxZwAAdWcAACZo AAApaAAATWgAAFZoAACEaQAAiGkAAFRqAABXagAAWWsAAF1rAACxawAAtGsAADJsAAA2bAAAVmwA AF1sAABxbAAAdGwAAIdsAACLbAAACm4AAA5uAABEbgAATG4AAMdvAADLbwAAEXAAABVwAACKcgAA jXIAAJpyAACecgAASnMAAE1zAABgcwAAZHMAABx0AAAjdAAAOHQAADt0AABIdAAATHQAAJx1AACg dQAAt3UAALt1AACUeQAAmHkAAJJ7AACVewAA8nsAAPZ7AACqfgAArH4AAAx/AAAOfwAAfIAAAICA AACdggAApIIAACuEAAA0hAAAYoUAAGaFAABOiQAAVYkAAHOOAAB6jgAAnI8AAKCPAADojwAA7I8A AEKQAABGkAAA8ZAAAPWQAABTkQAAV5EAANWRAADZkQAAQ5IAAEuSAACHkgAAi5IAAAWTAAAJkwAA dpMAAH6TAACYkwAAmpMAALyTAADAkwAA+ZMAAPuTAACQlQAAmJUAAFOWAABXlgAAeJYAAHyWAABo mAAAb5gAACGZAAAlmQAA85kAAPyZAAAqmwAALpsAAAacAAAKnAAAfJwAAICcAACynQAAtp0AABKe AAAWngAAIp8AACafAABMnwAAU58AAICfAACEnwAAcqAAAHagAACnoAAAr6AAACyiAAAwogAArqIA ALKiAAA2pQAAOqUAAPulAAD/pQAAt6YAAL6mAADipgAA5qYAACitAAAqrQAAf60AAIGtAACnrwAA r68AAP6vAAAGsAAAG7AAAB+wAADQsAAA17AAAOywAAD+sAAAxbIAAM2yAABJswAAS7MAACW0AAAt tAAAfLQAAIS0AACZtAAAnbQAABy2AAAktgAAcrYAAHq2AABntwAAbrcAAN27AADluwAAH70AACe9 AAAowAAAL8AAAEHAAABTwAAApMAAAKvAAADGwAAAzsAAAEPBAABLwQAA+cEAAAHCAABwxQAAeMUA APTFAAD8xQAAmsYAAKLGAAA/yAAAQsgAAKDIAACjyAAAAskAAAXJAADeyQAA4ckAAHTKAAB2ygAA u8oAAL3KAACFywAAh8sAAObLAADoywAAeMwAAHrMAADIzAAAyswAACrNAAAtzQAAtc8AALjPAADp 0QAA69EAACrSAAAs0gAAZNIAAGbSAADa0gAA3NIAAMnTAADL0wAAf9QAAILUAAC/1AAAwtQAAAPV AAAF1QAAHNYAACDWAACC1wAAhdcAAHDZAAB02QAApdkAAKjZAADW2QAA2tkAAJPaAACX2gAAIdsA ACXbAABz3AAAdtwAAIPcAACH3AAA3NwAAN/cAADw3AAA9NwAAEHdAABE3QAAHt4AACHeAAAu3gAA Mt4AALbeAAC43gAAyN4AANDeAABF3wAASd8AAFrfAABc3wAAq98AAK7fAADC3wAAxt8AAFTgAABW 4AAAtuAAALjgAABI4QAASuEAADHiAAAz4gAAkOIAAJPiAADd4wAA4OMAAPHjAAD14wAAVuQAAF7k AADA5AAAyOQAAI/lAACS5QAAY+YAAGvmAAA96AAAQOgAAFToAABY6AAAjegAAJDoAACd6AAAoegA AMvoAADN6AAA5OkAAOjpAABO6wAAUesAAELsAABG7AAAPO0AAEDtAAB07QAAd+0AAITtAACI7QAA pu0AAKrtAABj7gAAZ+4AAPLuAAD27gAAlfIAAJfyAADc8gAA3vIAAKfzAACp8wAACfQAAAv0AACb 9AAAnfQAAOv0AADt9AAAAfoAAAP6AABC+gAARPoAAHz6AAB++gAA8voAAPT6AADl+wAA5/sAAB79 AAAg/QAAN/4AADv+AACQAQEAlAEBAPYBAQD6AQEAswIBALcCAQBEAwEASAMBAKcEAQCrBAEAEwUB ABcFAQBPBgEAUwYBANcGAQDZBgEA6QYBAPEGAQBmBwEAagcBAHsHAQB9BwEAzAcBAM8HAQDjBwEA 5wcBAHUIAQB3CAEA1wgBANkIAQBpCQEAawkBAFIKAQBUCgEAsgoBALUKAQD4CwEA/QsBABAMAQAU DAEAdQwBAH0MAQDfDAEA5wwBAK0NAQCwDQEAgQ4BAIkOAQBxEAEAdRABAKoQAQCtEAEAuhABAL4Q AQDoEAEA6hABAAESAQAFEgEAehMBAH4TAQBiFAEAZhQBAFwVAQBgFQEAoxUBAKcVAQDFFQEAyRUB AIIWAQCGFgEAERcBABUXAQD5GQEA+xkBAN4aAQDgGgEAQBsBAEIbAQDVGwEA1xsBACUcAQAnHAEA Bx8BAAofAQBfJAEAYSQBABclAQAZJQEAyyUBAM0lAQCRJgEAlCYBAK4mAQCwJgEAYCcBAGQnAQBw JwEAdCcBAHwnAQCFJwEAkCcBAJQnAQCjJwEApycBANUnAQDZJwEA5CcBAOgnAQD0JwEA+CcBABYo AQAaKAEALioBAEoqAQBOKwEAUSsBAIArAQCDKwEAvC8BAL8vAQBLMAEATjABAMgzAQDrMwEAADUB AA81AQDQNQEA3zUBABM3AQAXNwEAfzcBAIg3AQA3PAEAOzwBAHU/AQB6PwEAtj8BALw/AQDGPwEA zj8BAI9AAQCUQAEAnEABAKVAAQDSQAEA2kABANtAAQDdQAEA30ABAOVAAQDyQAEA9UABAKtCAQCy QgEAzkIBANJCAQAvQwEANUMBAF5DAQBhQwEAc0MBAHhDAQCEQwEAj0MBAP9DAQAERAEACkQBABNE AQCFRAEAikQBAJBEAQCZRAEADkUBABVFAQAnRQEAKkUBABlGAQAiRgEAv0YBAMhGAQDSRgEA3UYB AEdHAQBNRwEA40cBAOxHAQD5RwEAAEgBAHlIAQCESAEAIkkBAChJAQDqSQEADUoBAB1KAQAlSgEA MUoBADdKAQC3SwEAxksBAPxLAQADTAEACUwBAAtMAQAoTAEALUwBAApNAQAQTQEAFk0BABtNAQAh TQEAKE0BAGlOAQBxTgEAnk4BAKdOAQAATwEAB08BADRPAQBHTwEAUk8BAFhPAQDGTwEAzU8BAM5P AQDRTwEA1U8BANtPAQA2UAEAO1ABADxQAQA/UAEA3FABAONQAQDnUAEA7lABAAxSAQAOUgEAI1IB AChSAQA1UgEAP1IBAEBSAQBDUgEARFIBAFRSAQCxUgEAt1IBAL9SAQDIUgEAyVIBANpSAQDmUgEA 7VIBAEhTAQBNUwEAd1MBAHxTAQB9UwEAiFMBAOJTAQDpUwEAIlQBAC1UAQDfVAEAClYBAA5WAQB+ VwEAgVcBAONXAQDnVwEAE1gBABZYAQBcWAEAX1gBAINYAQCGWAEAqVkBALFZAQA9WgEAQ1oBAGZa AQBuWgEAf10BAIJdAQCHXQEABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAbAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABsABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcABwAcAAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcAHAAHABwABwAEAAcAAAAAAJYA AADfAAAAAAIAACACAACDAgAAjQIAAMsCAADPAgAAEwMAABwDAABZAwAAYgMAAOQDAAD7AwAAKwQA AC4EAABuBAAAdgQAALYEAADABAAAPgUAAEcFAAC3BQAA7AUAAPsFAAAABgAAPgYAAEUGAACTBgAA lgYAANsGAADfBgAAHQcAACUHAAC9CAAAxQgAAAQKAAAPCgAAlQoAAJgKAADfCwAA6AsAACAMAAAn DAAAZwwAAGwMAAA4DQAAQA0AAHgNAACCDQAAvw0AAMINAAAFDgAADw4AAEgOAABNDgAAjQ4AAJkO AADSDgAA2A4AABoPAAAcDwAAow8AAKYPAADiDwAA7g8AACQQAAArEAAAaBAAAHQQAACsEAAAtBAA ABwTAAApEwAAZRMAAG4TAACuEwAAtxMAAPcTAAAAFAAAQBQAAE0UAACJFAAAlhQAANIUAADiFAAA PxUAAE4VAACkFQAAsRUAAO0VAAD2FQAANhYAAD8WAAB/FgAAiBYAAMgWAADVFgAAERcAAB4XAABa FwAAahcAAMgXAADYFwAAKhgAADcYAABzGAAAfBgAALwYAADFGAAABRkAAA4ZAABOGQAAWxkAAJcZ AACkGQAA4BkAAPAZAABQGgAAYRoAALMaAADAGgAA/BoAAAUbAABFGwAAThsAAI4bAACXGwAA1xsA AOQbAAAgHAAALRwAAGkcAAB5HAAAlR0AAKIdAADeHQAA5x0AACceAAAwHgAAcB4AAHkeAAC5HgAA xh4AAAIfAAAPHwAASx8AAFsfAAAcIAAAJSAAAGUgAABuIAAAriAAALcgAAD3IAAABCEAAEAhAABN IQAAiSEAAJkhAADSIQAA3CEAAB8iAAAmIgAAaCIAAG8iAADvJQAA/yUAAAopAAAbKQAA3jMAAOcz AAAkNAAAKzQAAGs0AABwNAAAOzUAAEM1AAB7NQAAhTUAAAU2AAANNgAAbTYAAHQ2AACzNgAAvzYA APk2AAADNwAAQTcAAEU3AADKNwAA1jcAABA4AAAWOAAAcjgAAHY4AAC2OAAAvjgAAEQ5AABKOQAA iDkAAI05AADLOQAA0zkAABE6AAAYOgAAWDoAAFw6AACgOgAApzoAAOM6AADqOgAAiDwAAJA8AAA+ PgAAQz4AAIc+AACMPgAA3T4AAP0+AAA8PwAAQz8AAMg/AADMPwAAN0AAADpAAAB+QAAAhUAAAMlA AADOQAAA90AAAABBAACCQQAAh0EAANJCAAD6QgAA/0IAAAxDAABZQwAAYEMAAG5DAAB3QwAAtkMA AMJDAAD7QwAAAEQAAE5EAABYRAAAm0QAAKBEAACmRAAArEQAAO9EAAD0RAAANkUAAD5FAAB+RQAA g0UAAL5FAADJRQAAA0YAAAtGAABGRgAAUEYAAIdGAACRRgAAFUcAAB1HAAAjRwAAKUcAAOpIAAD4 SAAANEkAADtJAAB9SQAAi0kAAMVJAADRSQAA+UkAAAJKAAAMSgAAEkoAADdKAABASgAAUEoAAFZK AABvSgAAdUoAACZLAAAqSwAAU0sAAFxLAACvSwAAtUsAAONLAADwSwAAPUwAAD9MAADsTAAA7kwA AEBNAABCTQAAmE0AAJxNAAAVTgAAF04AAHVOAAB4TgAAwk4AAMtOAADzTwAA/k8AADxQAAA+UAAA gFAAAIdQAADIUAAA1VAAABZRAAAcUQAAYVEAAGNRAACoUQAAr1EAAO1RAAD8UQAAI1IAACdSAABo UgAAb1IAAK9SAAC0UgAA9lIAAAFTAAA7UwAAQVMAAIJTAACIUwAAyVMAANFTAAAHVAAAE1QAAEpU AABVVAAAkVQAAJZUAABwVQAAdVUAAL1VAADCVQAAClYAAA9WAAA7VgAAQFYAAIlWAACRVgAA3lYA AOFWAABoVwAAb1cAALFXAAC0VwAAulcAAMpXAAAHWAAADlgAAE1YAABWWAAAYVgAAGZYAACqWAAA tVgAAO1YAAD0WAAAMVkAADdZAABCWQAAR1kAAIlZAACPWQAA0VkAANhZAAAWWgAAHloAAFhaAABg WgAAZloAAGtaAACqWgAAtFoAAPJaAAD4WgAAO1sAAERbAABdWwAAYlsAAKFbAACsWwAAmFwAAMRc AADxXAAAAF0AAApdAAA8XQAAQV0AAE5dAACaXQAAnV0AALNdAAC0XQAAQl4AAEheAADPXgAA1V4A ABdfAAAbXwAAWl8AAGNfAACbXwAApF8AALRfAAC6XwAA018AANlfAADxXwAA+l8AACRgAAAoYAAA SmAAAE5gAAB9YAAAhmAAANdgAADbYAAAEGEAAB1hAABpYQAAbWEAAL9hAADJYQAAD2IAABViAAA8 YgAAQmIAAIxiAACVYgAAXWMAAGdjAACzYwAAt2MAANFjAADbYwAAJmQAACpkAAB4ZAAAemQAAN5k AADkZAAAL2UAADNlAAB4ZQAAe2UAAL5lAADEZQAAW2YAAGBmAACbZgAAo2YAAOBmAADnZgAA9mYA AANnAABFZwAAS2cAANFnAADgZwAAF2gAAB9oAABcaAAAYGgAAKFoAACoaAAA6GgAAO1oAAAvaQAA OmkAAHRpAAB6aQAAu2kAAMFpAAAEagAACmoAAEtqAABTagAAkmoAAJVqAADYagAA3moAAA1rAAAS awAAnmsAAKZrAADmawAA72sAAPVrAAD6awAAQWwAAElsAADIbAAA0GwAAKVtAACtbQAA6W0AAPFt AAAZbgAAH24AAGRuAABtbgAAp24AALNuAADwbgAA8m4AACpvAAA6bwAAd28AAH5vAAC9bwAAxm8A ANFvAADWbwAAHXAAAClwAAAvcAAANHAAAHtwAACEcAAAq3AAALBwAAD1cAAA/XAAAAhxAAAQcQAA jHEAAJFxAADPcQAA2XEAABZyAAAYcgAAXnIAAGFyAAClcgAAqnIAAM9yAADUcgAAGXMAAB9zAACi cwAArHMAAN9zAADkcwAAK3QAAC50AABvdAAAeHQAAEN1AABTdQAArHUAALZ1AADsdQAA93UAACR2 AAAxdgAAfXYAAIR2AACSdgAAmHYAANN2AADfdgAAGHcAAB13AABfdwAAaXcAAKV3AACqdwAA5HcA AO93AAAAeAAABngAAEh4AABNeAAAj3gAAJd4AADXeAAA3HgAABd5AAAieQAAXHkAAGR5AACfeQAA qXkAAOB5AADqeQAAbnoAAHZ6AAB8egAAgnoAAA17AAAZewAAknsAAKF7AADTewAA2nsAAOB7AADl ewAAJnwAAC58AABkfAAAcHwAAJt8AACkfAAAdH0AAH19AACNfQAAk30AAKx9AACyfQAAyn0AAM59 AAD3fQAAAH4AAFJ+AABYfgAAhn4AAJN+AACqfgAArH4AAOB+AADnfgAAJn8AACp/AACxfwAAt38A APh/AAD/fwAAPoAAAEaAAADMgAAA0oAAABSBAAAXgQAAW4EAAF+BAACjgQAArYEAAAmCAAAUggAA UoIAAFSCAACVggAAnIIAAN2CAADqggAAK4MAADGDAAB1gwAAeIMAALmDAADAgwAA/oMAAASEAAA6 hAAAPoQAAH+EAACGhAAAxoQAAMuEAAANhQAAGIUAAFKFAABYhQAAMoYAADiGAAB7hgAAgYYAAMKG AADQhgAAC4cAAA2HAABRhwAAW4cAAJWHAACZhwAA3IcAAOGHAAAfiAAAJ4gAAC2IAAAyiAAAeIgA AHuIAAC8iAAAx4gAAPaIAAD7iAAAQYkAAESJAACFiQAAiokAAMyJAADPiQAADIoAABaKAABSigAA W4oAAGWKAAB1igAAsooAALmKAAD4igAAAYsAAAuLAAAQiwAAV4sAAJOLAACdiwAAposAAB6MAAAj jAAAZYwAAGuMAACtjAAAsYwAAOyMAAD2jAAANY0AADiNAABKjQAAT40AAI6NAACYjQAA040AANiN AAAWjgAAH44AAEeOAABMjgAAkY4AAJyOAACPjwAAoI8AAPaPAAD7jwAAGJAAACWQAAAqkAAAMpAA AGyQAABzkAAAeZAAAICQAADBkAAAyJAAAAaRAAAMkQAAJZEAACuRAABtkQAAcZEAAKqRAACzkQAA 6pEAAPORAAADkgAACZIAACKSAAAokgAAQJIAAEmSAABzkgAAd5IAAJmSAACdkgAAzJIAANWSAAAl kwAAKZMAAF6TAABrkwAAmJMAAJqTAACwkwAAu5MAAPmTAAD7kwAADZQAABeUAABVlAAAXJQAAB6V AAAklQAAZJUAAG2VAACdlQAAp5UAAOeVAADrlQAABZYAAA+WAABOlgAAUpYAAKGWAACnlgAALJcA ADOXAAB1lwAAe5cAANKXAADdlwAAG5gAAB2YAABgmAAAZ5gAAKiYAAC1mAAA9pgAAPyYAABAmQAA QpkAAIeZAACOmQAA0JkAANuZAAACmgAABpoAAEeaAABOmgAAjpoAAJOaAADVmgAA4JoAABqbAAAg mwAAYZsAAGebAACqmwAAsJsAAO6bAAD2mwAAN5wAAD6cAADDnAAAxZwAAAydAAAUnQAAVZ0AAGad AABrnQAAcJ0AAPqdAAACngAA254AAOCeAABonwAAcJ8AAPifAAD6nwAAOqAAAEGgAAB8oAAAgqAA AMCgAADJoAAABqEAAAmhAABMoQAAUqEAAI+hAACfoQAA3KEAAOOhAAAiogAAK6IAADaiAAA7ogAA uqIAAMaiAADMogAA0aIAABijAAAhowAASKMAAE2jAACSowAAmqMAAKWjAACtowAAKaQAAC6kAABs pAAAdqQAALOkAAC1pAAA+6QAAP6kAABBpQAARqUAAGulAABwpQAAtaUAALulAAA9pgAAR6YAAHqm AAB/pgAAxqYAAMmmAAAJpwAAEqcAADGoAAA5qAAAeagAAHyoAACzqAAAwKgAAAOpAAAJqQAASKkA AE+pAACPqQAAkqkAALupAADBqQAABKoAAA6qAABLqgAAUqoAAIuqAACVqgAAsqoAALuqAADkqgAA 7aoAAP2qAAADqwAAHKsAACKrAAA6qwAAPqsAAGmrAAByqwAAxKsAAMarAADtqwAA+qsAAEKsAABL rAAAi6wAAI+sAADSrAAA2qwAACitAAAqrQAAW60AAF+tAACirQAAp60AAOmtAADtrQAAL64AADiu AAAMrwAAF68AAFOvAABWrwAAHbAAACCwAACvsAAAtbAAAJqxAACdsQAA3bEAAOOxAAAhsgAAJbIA AGSyAABrsgAASbMAAEuzAADPswAA0rMAABK0AAAWtAAAWrQAAF60AAAztQAANbUAALu1AAC+tQAA AbYAAAi2AABJtgAATLYAAJK2AACYtgAAJ7cAACm3AAA4twAAOrcAAHu3AACGtwAAqrcAALe3AAD4 twAA/bcAAEK4AABJuAAAh7gAAI64AADQuAAA17gAABe5AAAauQAAzLkAANC5AAAVugAAHLoAAJ+6 AAClugAA4LoAAOW6AAAnuwAALrsAALC7AAC2uwAA+bsAAAG8AAAuvAAAM7wAAHm8AACAvAAABL0A AAy9AABMvQAAUb0AAHC9AACAvQAAzL0AANO9AAD+vQAAA74AANS+AADbvgAACL8AAA+/AABrwAAA csAAALLAAAC5wAAA7sAAAPTAAAA4wQAAO8EAAH7BAACCwQAAkMEAAJXBAADYwQAA3sEAABnCAAAj wgAAXMIAAGLCAAClwgAArsIAAKnDAACwwwAA28MAAODDAABtxAAAcMQAALLEAAC4xAAA38QAAObE AACjxQAArMUAAO3FAADvxQAANMYAADzGAABBxgAARsYAAIvGAACNxgAAz8YAANPGAABWxwAAYccA AKjIAACzyAAA8cgAAPfIAAA2yQAAPMkAAHbJAACAyQAAt8kAAL7JAADEyQAAzckAAAnKAAASygAA IsoAACjKAABBygAAR8oAAF/KAABkygAAccoAAHbKAACDygAAjMoAALjKAAC9ygAA1MoAANnKAAAN ywAAFssAAFnLAABdywAAgssAAIfLAADKywAA18sAACHMAAAqzAAAZcwAAGvMAACuzAAAscwAAALN AAAEzQAAR80AAEzNAACOzQAAks0AANjNAADazQAAIM4AACLOAADJzgAA1s4AACPPAAAnzwAAac8A AHHPAACszwAAtM8AAPPPAAD3zwAAO9AAAEfQAAB+0AAAhNAAAPPQAAD/0AAAONEAAEHRAAB+0QAA g9EAAPnRAAAC0gAAQtIAAETSAACI0gAAi9IAANHSAADW0gAAENMAABrTAADq0wAA+tMAAP/TAAAI 1AAASNQAAE7UAACK1AAAldQAAMrUAADV1AAA6tQAAPTUAAAz1QAAONUAAH/VAACI1QAADNYAABPW AABR1gAAW9YAAIjWAACS1gAAQ9cAAErXAABp1wAAdtcAAMPXAADM1wAAB9gAABXYAABL2AAAUNgA AI7YAACW2AAA0tgAAOLYAAAu2QAAO9kAAFzZAABj2QAAjNkAAJnZAADl2QAA7NkAACfaAAAy2gAA a9oAAHjaAAC02gAAtdoAAO/aAAD/2gAATdsAAE7bAACR2wAAndsAAGfcAACN3AAA5NwAAO/cAAAj 3QAALd0AAK3dAACy3QAA9N0AAPvdAAAC3gAAC94AAEveAABU3gAAZN4AAGreAACD3gAAid4AAKHe AACm3gAAs94AALjeAADF3gAAzt4AAPzeAAAF3wAAMd8AADXfAABX3wAAXN8AAHPfAAB43wAAtt8A AMHfAADS3wAA298AAB7gAAAi4AAAUeAAAFbgAACa4AAAp+AAAPHgAAD64AAANeEAADvhAAAX4gAA GuIAAF/iAABh4gAAp+IAAKziAADr4gAA8+IAAC/jAAA04wAAcuMAAHjjAACT4wAAoOMAAOXjAADw 4wAAKeQAADDkAABx5AAAdeQAAO3kAADw5AAANOUAADrlAAB45QAAgOUAAMHlAADF5QAACeYAAAzm AABM5gAAV+YAANrmAADm5gAAH+cAACjnAABl5wAAaucAAJ/nAACv5wAAtOcAAL3nAAD95wAAA+gA AEjoAABT6AAAjegAAJzoAACy6AAAvOgAAPvoAAAA6QAAR+kAAFDpAADU6QAA2+kAABnqAAAj6gAA UeoAAFvqAAAM6wAAE+sAADPrAABA6wAAjOsAAI7rAADT6wAA4esAABfsAAAc7AAAYOwAAGXsAACc 7AAArOwAAPjsAAAF7QAAKO0AAC/tAABZ7QAAZu0AALHtAAC07QAA9+0AAALuAAA77gAASO4AAITu AACF7gAAwO4AANDuAAAe7wAAH+8AAG7vAABw7wAAR/AAAFfwAACs8AAAt/AAAPXwAAD78AAAOfEA AD/xAAB48QAAgvEAALnxAADA8QAAx/EAANDxAAAd8gAAJPIAACryAAAz8gAAQ/IAAEnyAABi8gAA aPIAAIDyAACF8gAAkvIAAJfyAACk8gAArfIAANnyAADe8gAA9fIAAPryAAAv8wAAOPMAAHvzAAB/ 8wAApPMAAKnzAADt8wAA+vMAAET0AABN9AAAiPQAAI70AADR9AAA1PQAABr1AAAc9QAAXvUAAGP1 AACl9QAAqfUAAO71AADw9QAAz/YAANH2AADh9gAA7vYAADz3AABA9wAAgvcAAIr3AADF9wAAzfcA AAv4AAAP+AAAU/gAAF/4AACW+AAAnPgAAAv5AAAX+QAAUPkAAFn5AACW+QAAm/kAABH6AAAa+gAA WvoAAFz6AACg+gAAo/oAAOn6AADu+gAAKPsAADL7AACN+wAAkPsAANX7AADZ+wAACfwAABn8AAAe /AAAJ/wAAGf8AABt/AAA+/wAAAD9AAAF/QAAD/0AAE79AABT/QAAmv0AAKP9AAAn/gAALv4AAGz+ AAB2/gAAQP8AAEr/AABg/wAAZ/8AAIf/AACU/wAA4P8AAOn/AAAkAAEAMgABAGgAAQBtAAEAqwAB ALMAAQDwAAEAAAEBAEwBAQBZAQEAfAEBAIMBAQCtAQEAugEBAAUCAQAMAgEARwIBAFICAQCLAgEA mAIBANMCAQDVAgEAEgMBACIDAQBwAwEAcQMBALQDAQDBAwEAmgQBAKsEAQAHBQEAEgUBAEYFAQBQ BQEAzwUBANQFAQAWBgEAHQYBACQGAQAtBgEAbAYBAHUGAQCFBgEAiwYBAKQGAQCqBgEAwgYBAMcG AQDUBgEA2QYBAOYGAQDvBgEAHQcBACYHAQBSBwEAVgcBAHgHAQB9BwEAlAcBAJkHAQDXBwEA4gcB APMHAQD8BwEAPwgBAEMIAQByCAEAdwgBALsIAQDICAEAEgkBABsJAQBWCQEAXAkBADgKAQA7CgEA gQoBAIMKAQDJCgEAzgoBAA0LAQAVCwEAUQsBAFYLAQCUCwEAmgsBALULAQDCCwEAEAwBACYMAQBV DAEAWgwBAJsMAQCkDAEACw0BAA4NAQBSDQEAWA0BAJYNAQCeDQEA3w0BAOMNAQAnDgEAKg4BAGoO AQB1DgEA+A4BAAQPAQA9DwEARg8BAIMPAQCIDwEAvQ8BAM0PAQDSDwEA2w8BABsQAQAhEAEAZRAB AHAQAQCqEAEAuRABAM8QAQDZEAEAGBEBAB0RAQBkEQEAbREBAPERAQD4EQEANhIBAEASAQBuEgEA eBIBACkTAQAwEwEAUBMBAF0TAQCpEwEAqxMBAPATAQD+EwEANBQBADkUAQB3FAEAfxQBALwUAQDM FAEAGBUBACUVAQBIFQEATxUBAHkVAQCGFQEAixUBAJMVAQDUFQEA2xUBABYWAQAhFgEAWhYBAGcW AQCjFgEApBYBAN8WAQDvFgEAPRcBAD4XAQCNFwEAjxcBAMEYAQDIGAEAChkBABIZAQBUGQEAXRkB AI4ZAQCXGQEApxkBAK0ZAQDGGQEAzBkBAOQZAQDpGQEA9hkBAPsZAQAIGgEAERoBADkaAQA+GgEA eRoBAIIaAQDFGgEAyRoBANsaAQDgGgEAJBsBADEbAQB+GwEAhxsBAMIbAQDIGwEACxwBAA4cAQBU HAEAVhwBAJocAQCgHAEA4xwBAOUcAQAqHQEALh0BAHIdAQB0HQEAgR0BAI4dAQDbHQEA4B0BALse AQDDHgEA/h4BAAYfAQBFHwEASR8BAIcfAQCOHwEAxh8BANEfAQACIAEAEiABAE8gAQBXIAEAciAB AHsgAQC7IAEAxSABAAYhAQANIQEATCEBAFQhAQCWIQEAmSEBAOsiAQD1IgEANCMBADgjAQB8IwEA gyMBALojAQDGIwEA/iMBAAQkAQASJAEAGCQBAF8kAQBhJAEAcyQBAHkkAQC4JAEAwiQBAP8kAQAB JQEARSUBAEslAQCMJQEAkiUBAMslAQDNJQEA8SUBAPolAQA5JgEAPyYBAJgmAQCiJgEA3SYBAOcm AQD0JwEA+CcBADsoAQA+KAEAVigBAGAoAQC9KAEAxCgBAAUpAQAHKQEASSkBAFUpAQCKKQEAlSkB ANEpAQDVKQEAGCoBABoqAQBXKgEAYyoBAEQrAQBNKwEAdCsBAH8rAQCmKwEArysBANUrAQDgKwEA BiwBAAwsAQBrLAEAdSwBAKssAQC1LAEACC0BABUtAQBPLQEAUy0BAHotAQCELQEA1S0BANgtAQB2 LgEAeC4BAIUuAQCKLgEAtS8BALsvAQABMAEABzABAEEwAQBJMAEAiDABAI0wAQDRMAEA1TABABgx AQAgMQEAXTEBAGQxAQCkMQEAqTEBAOwxAQDwMQEA9jEBAP0xAQBAMgEAQzIBAIgyAQCLMgEAyzIB ANQyAQARMwEAFTMBAFozAQBjMwEAoDMBAKQzAQDFMwEABzQBAE00AQBcNAEAkTQBAJk0AQDXNAEA 3TQBABs1AQAiNQEAZDUBAGY1AQCtNQEAsDUBAPU1AQD3NQEAEzYBABo2AQBeNgEAZDYBAKQ2AQCp NgEA6zYBAPA2AQABNwEABjcBAE03AQBQNwEAlDcBAJ03AQDYNwEA3jcBAK44AQC5OAEA9zgBAPo4 AQAkOgEAKzoBAHo6AQCBOgEAwzoBAMU6AQAMOwEAEDsBAFM7AQBXOwEAmTsBAJ47AQAHPAEACTwB AA08AQAPPAEAVjwBAFk8AQCdPAEAoTwBABc9AQAfPQEAWT0BAGE9AQBYQAEAYEABAJxAAQC3QAEA AEEBAAVBAQBGQQEATkEBAIhBAQCPQQEAhEIBAJBCAQBWRQEAWUUBAMlJAQDXSQEAikoBAJxKAQCO SwEAkksBAJNMAQCaTAEAsE4BAMBOAQA8TwEAR08BAGlPAQB4TwEAzk8BANFPAQAMUgEADlIBADFS AQA0UgEAYVIBAHBSAQDpUgEA7VIBADhUAQBHVAEA31QBAMdYAQDLWAEAEF0BABJdAQCHXQEABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcABwAzAAcAMwAHAAAAAABxRQAAfkUAAN1mAADzZgAA31QBAFNcAQBYXAEA h10BAAcABQAHAAUABwAHAAUABwAWAAAABAAAAAgAAADlAAAAAAAAABUAAACKDAIAoy8JAP5MGACG VCcAwwA0AJEuVAA/VV0AA3ReAGRucgD8CHMAgFl0AClddwBSUXkA6hGLADAalgBHNKUAQTGzAOhu uwAvIbwAu3HFALxS6QCHZe0AAAAAAN9UAQDhVAEAAAAAAAEAAAD/QACAAQAAAAAAAAAAAABwTwIB AAEAAAAAAAAAAAAAAAAAAAAAAAIQAAAAAAAAAIZdAQBgAAAQAEAAAP//AgAAAAcAVQBuAGsAbgBv AHcAbgAIAFIAZQBpAG4AaABhAHIAZAD//wIACAAAAAAAAAAAAAAAAAAAAAAAAAABAP//AgAAAAAA AAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAIAAAARx6QAQAAAgIGAwUEBQIDBP8qAOBBeADACQAA AAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANR6QAQIABQUBAgEH BgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMy6QAQAAAgsGBAICAgIC BP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAD89kAEAAAIHAwkCAgUCBAT/KgDg Q3gAwAkAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA3LpABAAACDwUCAgIE AwIE/wIA4f+sAEAJAAAAAAAAAJ8BAAAAAAAAQwBhAGwAaQBiAHIAaQAAADk9kAEAAAILBgkCAgQD AgT/AgDh//wAQAkAAAAAAAAAnwEAAAAAAABDAG8AbgBzAG8AbABhAHMAAAA1LpABAAACCwYEAwUE BAIE/y4A4VtgAMApAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAABBHpABAAACBAUDBQQGAwIE 7wIAoOsgAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0AGgAAAAiAAQAcYiI GADwxAIAAKkBAAAAAK2L2Cbym9hmAAAAAAkAAAAAALEuAAAuJgEAMgCuAAAABAADkHMCAACxLgAA LiYBADIArgAAAHMCAAAAAAAAcQMA8BAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgWJBW4A tACBgjIwAAAAAAAAAAAAAAAAAAAxVAEAMVQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAABMoMRAPAQAAgA/P0BAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACEhYAAAAAAnw/w8BCCRQAAAAAAAADjYAAP///3////9/AAAA AP///3////9/////f/wIcwAABAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAACEEAAAAAAAAAAAAAAAA AAAAAAAAEBwAAAcAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAP//EgAAAAAAAAAAAAAAAAAA AAgAUgBlAGkAbgBoAGEAcgBkAAgAUgBlAGkAbgBoAGEAcgBkAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAGAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAEgBAAAPAAAAAQAAAIAAAAAC AAAAiAAAAAMAAACUAAAABAAAAKAAAAAFAAAAtAAAAAcAAADAAAAACAAAANAAAAAJAAAA5AAAABIA AADwAAAADAAAABABAAANAAAAHAEAAA4AAAAoAQAADwAAADABAAAQAAAAOAEAABMAAABAAQAAAgAA AOQEAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAADAAAAFJlaW5oYXJkAAAAAB4AAAAEAAAA AAAAAB4AAAAIAAAATm9ybWFsAAAeAAAADAAAAFJlaW5oYXJkAAAAAB4AAAAEAAAAOQAAAB4AAAAY AAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABuXog4H8oBQAAAAAC0xvHTIMoBAwAAADIA AAADAAAAsS4AAAMAAAAuJgEAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAA AAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADoAAAADAAAAAEAAABoAAAADwAAAHAAAAAF AAAAfAAAAAYAAACEAAAAEQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYA AAC0AAAADQAAALwAAAAMAAAAyQAAAAIAAADkBAAAHgAAAAQAAAAAAAAAAwAAAHMCAAADAAAArgAA AAMAAAAxVAEAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA AQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAV AAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAA ADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAA QAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABO AAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwA AABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAA AGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAA eQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACH AAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUA AACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAA AKQAAAClAAAApgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAA sgAAALMAAAC0AAAAtQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADA AAAAwQAAAMIAAADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4A AADPAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAA AN0AAADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA 6wAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5 AAAA+gAAAPsAAAD8AAAA/QAAAP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcB AAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEA ABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAAP7///8jAQAA JAEAACUBAAAmAQAAJwEAACgBAAApAQAA/v///ysBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEBAAAy AQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7AQAAPAEAAD0BAAA+AQAAPwEAAEAB AABBAQAAQgEAAEMBAABEAQAARQEAAEYBAABHAQAASAEAAEkBAABKAQAASwEAAEwBAABNAQAATgEA AE8BAABQAQAAUQEAAFIBAABTAQAAVAEAAFUBAABWAQAAVwEAAFgBAABZAQAAWgEAAFsBAABcAQAA /v///14BAABfAQAAYAEAAGEBAABiAQAAYwEAAGQBAAD+////ZgEAAGcBAABoAQAAaQEAAGoBAABr AQAAbAEAAP7////9/////f////3///9xAQAAcgEAAP7////+////dQEAAP7///////////////// ////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAABXX/dMgygF0AQAAAAMAAAAAAABEAGEAdABhAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIBAAAAEAAAAAAA ADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAOAAIAAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKgEAAAdkAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEKAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAOEICAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF0BAAAAEAAAAAAAAAUARABvAGMAdQBtAGUA bgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAA AP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZQEAAAAQAAAAAAAA TQBzAG8ARABhAHQAYQBTAHQAbwByAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAQD//////////wcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMC0zP3TIMoBYI7V/dMg ygEAAAAAAAAAAAAAAABIAEkAwwDEAN0AxwDOAFUAyABFAMYAygA0AMcAwADVADQAwwDcADAA1wBB AD0APQAAAAAAAAAAAAAAAAAAAAAAMgABAf//////////CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA wLTM/dMgygFgjtX90yDKAQAAAAAAAAAAAAAAAEkAdABlAG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB/////wkAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANoAAAAAAAAAUAByAG8AcABlAHIAdABp AGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAVQEAAAAAAAAB AEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAQIAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAoAAAB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA/v///wUAAAAGAAAABwAAAAgA AAAJAAAA/v///wsAAAD+//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////88YjpTb3VyY2VzIFNlbGVjdGVkU3R5bGU9IlxBUEEu WFNMIiBTdHlsZU5hbWU9IkFQQSIgeG1sbnM6Yj0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1h dHMub3JnL29mZmljZURvY3VtZW50LzIwMDYvYmlibGlvZ3JhcGh5IiB4bWxucz0iaHR0cDovL3Nj aGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL29mZmljZURvY3VtZW50LzIwMDYvYmlibGlvZ3JhcGh5 Ij48L2I6U291cmNlcz4NCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPD94 bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8ZHM6 ZGF0YXN0b3JlSXRlbSBkczppdGVtSUQ9IntGNkU0ODgxQy05NDdCLTQ5QTAtQUE3QS03ODM1N0Ez RjFBREN9IiB4bWxuczpkcz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL29mZmlj ZURvY3VtZW50LzIwMDYvY3VzdG9tWG1sIj48ZHM6c2NoZW1hUmVmcz48ZHM6c2NoZW1hUmVmIGRz OnVyaT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL29mZmljZURvY3VtZW50LzIw MDYvYmlibGlvZ3JhcGh5Ii8+PC9kczpzY2hlbWFSZWZzPjwvZHM6ZGF0YXN0b3JlSXRlbT4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAA AADAAAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgOTctMjAwMyBEb2N1bWVudAAKAAAA TVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_000D_01CA20E5.C7379A30-- From tom.nadeau@bt.com Wed Aug 19 08:18:29 2009 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 3459728C406; Wed, 19 Aug 2009 08:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 XsTm+t1DRddX; Wed, 19 Aug 2009 08:18:28 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 794373A6B5C; Wed, 19 Aug 2009 08:18:27 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.104]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 16:18:32 +0100 Received: from 217.32.164.180 ([217.32.164.180]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.149]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Aug 2009 15:18:31 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 19 Aug 2009 11:18:29 -0400 From: "Thomas D. Nadeau" To: Rschrage , 'Weiqiang Sun' , 'Lou Berger' , 'Henk Uijterwaal' Message-ID: Thread-Topic: [CCAMP] [ippm] [Fwd: IPPM expert review request] Thread-Index: AcogwU+dvlizutOpTeeFdomY4IPOowAEsEmwAAMPW+o= In-Reply-To: <000c01ca20d5$03aeca30$0b0c5e90$@net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 15:18:32.0043 (UTC) FILETIME=[500023B0:01CA20E0] Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 15:18:29 -0000 Lou, I'd like to ask a question about this draft. How does it relate to (or not) to any of the GMPLS MIBs? As you know, the MIBs contain performance counters. If these metrics present in this draft do not coincide with the MIBs, this will cause more work for implementations. In particular, the following statement in this document worries me: On the other hand, it can also be used in operational environments for carriers to monitor the control plane operation in real-time. For example, a new object can be added to GMPLS TE STD MIB [RFC4802] so that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the defined metrics is outside the scope of this document. Does the WG really want to progress a document that requires these changes? --Tom On 8/19/09 9:57 AM, "Rschrage" wrote: > Hi all, > > pls find attached a further updated edition of previous revised doc > draft-ietf-ccamp-lsp-dppm-06. > > I believe this is as far as we can go for the moment before a mutual > satisfactory understanding has been reached and a new draft has been issued > by the authors. > > Again, pls feel free to comment. > > Many thanks. > Brgds. > Reinhard Schrage > Tel: +49 (0) 5137 909540 > Mobile: +49 (0) 172 26.36.046 > reinhard@schrageconsult.com > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Weiqiang Sun > Sent: Mittwoch, 19. August 2009 09:28 > To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' > Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, > ATTLABS'; 'IETF IPPM WG' > Subject: Re: [ippm] [Fwd: IPPM expert review request] > > More responses below: > > RS4. > Should be more specific as to why this metric is no simple function of > single uni-directional LSP Setup Delay metric, i.e. why can it not be > deduced from single LSP Setup Delay? > [sunwq] > This point is raised regarding the sentence "The time needed to setup a > large number of LSPs during a short time period can not be deduced by single > > LSP setup delay." > One reason is that when a large number of LSPs in being setup during a short > > period of time, the control plane may be crowded or even overwhelmed by the > large number of signaling and routing messages. This may significantly slow > down the processing of a particular signaling message, which will results in > > longer LSP provisioning delays. > Are you suggesting that we add similar explanations to the document? We'd > love to do that if you feel it is necessary. > > RS5. > The current definition only addresses multiple uni-directional LSP setups > between two nodes ID0 and ID1. What about the the case when ID0 is to setup > multiple uni-directional LSP setups to different egress nodes ID1, ID2, > ID3,.,IDN? > [sunwq] > Yes, it is a useful case. Likewise you would expect a case to establish a > varied number of (instead of one) LSPs to a set of destinations. Our > suggestion is that this case is approached by integrating the defined > methodologies of single/multiple LSPs provisioning delay, in the form of a > particular testing case, rather than a formal testing methodology. This is > in fact a trade-off between complexity and accuracy. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Weiqiang Sun" > Sent: Wednesday, August 19, 2009 2:48 PM > To: "Rschrage" ; "'Lou Berger'" > ; "'Henk Uijterwaal'" > Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" > ; "'IETF IPPM WG'" ; > Subject: Re: [ippm] [Fwd: IPPM expert review request] > >> Hi Reinhard, >> >> Many thanks for doing the careful review. We appreciate your many wording >> suggestions. We will go through these one by one and adopt those we feel >> appropriate. In this email I will not list all the comments since these >> will not lead to major technical changes. >> >> Below I try to respond to the points you raised in the revision. >> >> RS1. >> This would imply that the metric may produce a range of several values at >> one time with the minimum value to be taken from that range. >> I believe what the authors are trying to say is, that the LSP Setup Delay >> Metric provides a lower bound on all possible LSP Delay Metrics of >> actually instantiated LSPs, or in other words: an actual LSP Delay Metric >> cannot get smaller than an LSP Setup Delay Metric. >> [sunwq] >> This point is raised regarding the motivation of the sigleton definition >> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying > >> to say that the minimum value of this metric reflects the (likely) single >> lsp setup delay when the control plane is lightly loaded. The formal >> definition of the minimum value is in "14.1 The minimum of metric" >> In fact we have inherited this from the IPPM documents (see RFC 2681, page > >> 2 section 1.1 bullet 3). >> >> RS2. >> How? Should there be a methodology be defined for this? >> [sunwq] >> This point is raised regarding the sentense in our methodologies >> sections - "Make sure that the network has enough resource to set up the >> requested LSP." >> We have assumed that test personnel should have adequate expertise in >> allocating enough resources for the testing. The allocation of resources >> for the testing purpose can be very test specific and we believe it is >> quite outside the scope of this document. >> >> RS3. >> Too vague? As both timestamps are to be taken on the same ingress node, >> they should be taken at the same application/network level. >> [sunwq] >> This point is raised regarding the sentense "If the corresponding RESV >> message arrives within a reasonable period of time, take the timestamp >> (T2) as soon as possible upon receipt of the message." >> Yes, ideally the timestamp should be taken immediately after the reception > >> of the RESV message. The wording "as soon as possible" is used to allow >> for some flexibility when RESV message needs to be propagated to certain >> modules where timestamp-taking is most appropriate. >> And again, this text is inherited from the IPPM documents (see RFC 2681 >> page 7, bullet 3). >> >> Thanks again and looking forward to your further comments and revisions. >> >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Rschrage" >> Sent: Tuesday, August 18, 2009 8:23 PM >> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; ; "'IETF IPPM WG'" ; >> >> Subject: RE: [ippm] [Fwd: IPPM expert review request] >> >>> Hello, >>> >>> sorry for late response- >>> >>> Nevertheless here is a first edition of my revision of doc >>> draft-ietf-ccamp-lsp-dppm-06. >>> >>> The doc has been saved in Word 2003 format to easily track changes. >>> I am using Kaspersky Anti Virus 2010 software so I trust there should be >>> no >>> unpleasant surprises when downloading the attached word doc. >>> >>> >>> I thought it would be advisable to first address the suggested comments >>> and >>> questions upto and including the uni-directional LSP setup delay metric >>> and >>> after that to continue with the bi-directional and sample definitions as >>> covered in the doc. >>> >>> Please let me have your thoughts on this. >>> >>> Many thanks. >>> Reinhard Schrage >>> Tel: +49 (0) 5137 909540 >>> Mobile: +49 (0) 172 26.36.046 >>> reinhard@schrageconsult.com >>> >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>> Lou >>> Berger >>> Sent: Dienstag, 28. Juli 2009 14:59 >>> To: Henk Uijterwaal >>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>> sunwq@mit.edu; IETF IPPM WG >>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>> >>> Hank/Reinhard, >>> >>> Thank you very much for undertaking this review. Please cc >>> ccamp@ietf.org on any comments you may have. >>> >>> Lou >>> >>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>> Lou, others, >>>> >>>>> We received the request for a review of a document currently under >>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>> has time to do this review in the near future? >>>> >>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>> this. >>>> >>>> Reinhard: please post anything you find to both the list and the >>>> authors. >>>> And thank you for doing this. >>>> >>>> Henk >>>> >>>>> >>>>> Matt & Henk >>>>> >>>>> -------- Original Message -------- >>>>> Subject: IPPM expert review request >>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>> From: Lou Berger >>>>> To: ippm-chairs@tools.ietf.org >>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>> zhangguoying >>>>> >>>>> Hi, >>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>> review >>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>> available at: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>> >>>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>>> can just last call the document in your WG (it has already passed CCAMP >>>>> WG LC). >>>>> >>>>> Thank you, >>>>> Lou (and Deborah) >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp -- Principal Architect - 21CN Networks From lberger@labn.net Wed Aug 19 09:19:26 2009 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 DBE1D3A6D1B for ; Wed, 19 Aug 2009 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.484, 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 aba1g-VzPe1n for ; Wed, 19 Aug 2009 09:19:26 -0700 (PDT) Received: from outbound-mail-126.bluehost.com (outbound-mail-126.bluehost.com [67.222.38.26]) by core3.amsl.com (Postfix) with SMTP id 62EEF3A6D3F for ; Wed, 19 Aug 2009 09:19:23 -0700 (PDT) Received: (qmail 15266 invoked by uid 0); 19 Aug 2009 16:19:27 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 19 Aug 2009 16:19:27 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=g9TUnunNhuFR5iYRnOz3X02WwnJENkBfhuGfVGHCyS7NSKWe9R81kA+CmBZ39rm75hlQ/zBACkK/JffBMRI02B8sVh8b5dWah3JMjJFhZtFlPwB3K5xAjul3Aa4fxDRk; 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 1Mdnsk-0007On-VO; Wed, 19 Aug 2009 10:19:27 -0600 Message-ID: <4A8C2648.9000002@labn.net> Date: Wed, 19 Aug 2009 12:20:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: "Thomas D. Nadeau" References: In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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: zhangguoying@mail.ritt.com.cn, Rschrage , 'IETF IPPM WG' , ccamp@ietf.org, 'Henk Uijterwaal' , 'Weiqiang Sun' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 16:19:26 -0000 Tom, This document covers evaluation metrics that you'd expect to see produced by a test tool rather than from the systems (DUTs) themselves. In short, no GMPLS network node is expected to implement this spec. WRT the quoted text. I viewed this as referring to a benchmarking tool that is deployed in an operational network. I can see how this can be misinterpreted and I have no objection to asking that the text be removed from the document. Will dropping this text address your concerns? Note that this document has been a WG document for well over a year and was first discussed in the WG ~2.5 years ago. Lou On 8/19/2009 11:18 AM, Thomas D. Nadeau wrote: > Lou, > > I'd like to ask a question about this draft. How does it relate to (or > not) to any of the GMPLS MIBs? As you know, the MIBs contain performance > counters. If these metrics present in this draft do not coincide with the > MIBs, this will cause more work for implementations. In particular, the > following statement in this document worries me: > > On the other hand, it can also be used in operational environments for > carriers to monitor the control plane operation in real-time. For > example, a new object can be added to GMPLS TE STD MIB [RFC4802] so > that the current and past control plane performance can be monitored > through network management systems. The extension of TE-MIB to > support the defined metrics is outside the scope of this document. > > > Does the WG really want to progress a document that requires these > changes? > > --Tom > > > > On 8/19/09 9:57 AM, "Rschrage" wrote: > >> Hi all, >> >> pls find attached a further updated edition of previous revised doc >> draft-ietf-ccamp-lsp-dppm-06. >> >> I believe this is as far as we can go for the moment before a mutual >> satisfactory understanding has been reached and a new draft has been issued >> by the authors. >> >> Again, pls feel free to comment. >> >> Many thanks. >> Brgds. >> Reinhard Schrage >> Tel: +49 (0) 5137 909540 >> Mobile: +49 (0) 172 26.36.046 >> reinhard@schrageconsult.com >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Weiqiang Sun >> Sent: Mittwoch, 19. August 2009 09:28 >> To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' >> Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, >> ATTLABS'; 'IETF IPPM WG' >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >> More responses below: >> >> RS4. >> Should be more specific as to why this metric is no simple function of >> single uni-directional LSP Setup Delay metric, i.e. why can it not be >> deduced from single LSP Setup Delay? >> [sunwq] >> This point is raised regarding the sentence "The time needed to setup a >> large number of LSPs during a short time period can not be deduced by single >> >> LSP setup delay." >> One reason is that when a large number of LSPs in being setup during a short >> >> period of time, the control plane may be crowded or even overwhelmed by the >> large number of signaling and routing messages. This may significantly slow >> down the processing of a particular signaling message, which will results in >> >> longer LSP provisioning delays. >> Are you suggesting that we add similar explanations to the document? We'd >> love to do that if you feel it is necessary. >> >> RS5. >> The current definition only addresses multiple uni-directional LSP setups >> between two nodes ID0 and ID1. What about the the case when ID0 is to setup >> multiple uni-directional LSP setups to different egress nodes ID1, ID2, >> ID3,.,IDN? >> [sunwq] >> Yes, it is a useful case. Likewise you would expect a case to establish a >> varied number of (instead of one) LSPs to a set of destinations. Our >> suggestion is that this case is approached by integrating the defined >> methodologies of single/multiple LSPs provisioning delay, in the form of a >> particular testing case, rather than a formal testing methodology. This is >> in fact a trade-off between complexity and accuracy. >> >> Best regards, >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Weiqiang Sun" >> Sent: Wednesday, August 19, 2009 2:48 PM >> To: "Rschrage" ; "'Lou Berger'" >> ; "'Henk Uijterwaal'" >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; "'IETF IPPM WG'" ; >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >>> Hi Reinhard, >>> >>> Many thanks for doing the careful review. We appreciate your many wording >>> suggestions. We will go through these one by one and adopt those we feel >>> appropriate. In this email I will not list all the comments since these >>> will not lead to major technical changes. >>> >>> Below I try to respond to the points you raised in the revision. >>> >>> RS1. >>> This would imply that the metric may produce a range of several values at >>> one time with the minimum value to be taken from that range. >>> I believe what the authors are trying to say is, that the LSP Setup Delay >>> Metric provides a lower bound on all possible LSP Delay Metrics of >>> actually instantiated LSPs, or in other words: an actual LSP Delay Metric >>> cannot get smaller than an LSP Setup Delay Metric. >>> [sunwq] >>> This point is raised regarding the motivation of the sigleton definition >>> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying >>> to say that the minimum value of this metric reflects the (likely) single >>> lsp setup delay when the control plane is lightly loaded. The formal >>> definition of the minimum value is in "14.1 The minimum of metric" >>> In fact we have inherited this from the IPPM documents (see RFC 2681, page >>> 2 section 1.1 bullet 3). >>> >>> RS2. >>> How? Should there be a methodology be defined for this? >>> [sunwq] >>> This point is raised regarding the sentense in our methodologies >>> sections - "Make sure that the network has enough resource to set up the >>> requested LSP." >>> We have assumed that test personnel should have adequate expertise in >>> allocating enough resources for the testing. The allocation of resources >>> for the testing purpose can be very test specific and we believe it is >>> quite outside the scope of this document. >>> >>> RS3. >>> Too vague? As both timestamps are to be taken on the same ingress node, >>> they should be taken at the same application/network level. >>> [sunwq] >>> This point is raised regarding the sentense "If the corresponding RESV >>> message arrives within a reasonable period of time, take the timestamp >>> (T2) as soon as possible upon receipt of the message." >>> Yes, ideally the timestamp should be taken immediately after the reception >>> of the RESV message. The wording "as soon as possible" is used to allow >>> for some flexibility when RESV message needs to be propagated to certain >>> modules where timestamp-taking is most appropriate. >>> And again, this text is inherited from the IPPM documents (see RFC 2681 >>> page 7, bullet 3). >>> >>> Thanks again and looking forward to your further comments and revisions. >>> >>> Weiqiang >>> >>> -- >>> Weiqiang Sun >>> Shanghai Jiao Tong University >>> http://front.sjtu.edu.cn/~sunwq/ >>> >>> -------------------------------------------------- >>> From: "Rschrage" >>> Sent: Tuesday, August 18, 2009 8:23 PM >>> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >>> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >>> ; ; "'IETF IPPM WG'" ; >>> >>> Subject: RE: [ippm] [Fwd: IPPM expert review request] >>> >>>> Hello, >>>> >>>> sorry for late response- >>>> >>>> Nevertheless here is a first edition of my revision of doc >>>> draft-ietf-ccamp-lsp-dppm-06. >>>> >>>> The doc has been saved in Word 2003 format to easily track changes. >>>> I am using Kaspersky Anti Virus 2010 software so I trust there should be >>>> no >>>> unpleasant surprises when downloading the attached word doc. >>>> >>>> >>>> I thought it would be advisable to first address the suggested comments >>>> and >>>> questions upto and including the uni-directional LSP setup delay metric >>>> and >>>> after that to continue with the bi-directional and sample definitions as >>>> covered in the doc. >>>> >>>> Please let me have your thoughts on this. >>>> >>>> Many thanks. >>>> Reinhard Schrage >>>> Tel: +49 (0) 5137 909540 >>>> Mobile: +49 (0) 172 26.36.046 >>>> reinhard@schrageconsult.com >>>> >>>> -----Original Message----- >>>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>>> Lou >>>> Berger >>>> Sent: Dienstag, 28. Juli 2009 14:59 >>>> To: Henk Uijterwaal >>>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>>> sunwq@mit.edu; IETF IPPM WG >>>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>>> >>>> Hank/Reinhard, >>>> >>>> Thank you very much for undertaking this review. Please cc >>>> ccamp@ietf.org on any comments you may have. >>>> >>>> Lou >>>> >>>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>>> Lou, others, >>>>> >>>>>> We received the request for a review of a document currently under >>>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>>> has time to do this review in the near future? >>>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>>> this. >>>>> >>>>> Reinhard: please post anything you find to both the list and the >>>>> authors. >>>>> And thank you for doing this. >>>>> >>>>> Henk >>>>> >>>>>> Matt & Henk >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: IPPM expert review request >>>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>>> From: Lou Berger >>>>>> To: ippm-chairs@tools.ietf.org >>>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>>> zhangguoying >>>>>> >>>>>> Hi, >>>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>>> review >>>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>>> available at: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>>> >>>>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>>>> can just last call the document in your WG (it has already passed CCAMP >>>>>> WG LC). >>>>>> >>>>>> Thank you, >>>>>> Lou (and Deborah) >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > From gregb@grotto-networking.com Wed Aug 19 09:22:26 2009 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 DA00F3A6A3C for ; Wed, 19 Aug 2009 09:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.373, 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 6Wx3csImUzML for ; Wed, 19 Aug 2009 09:22:25 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id D5B4C3A6B5B for ; Wed, 19 Aug 2009 09:22:25 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n7JGMRNm023549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Aug 2009 09:22:29 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4A8C26C4.3000502@grotto-networking.com> Date: Wed, 19 Aug 2009 09:22:28 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: CCAMP Content-Type: multipart/alternative; boundary="------------020301080208080700060405" Subject: [CCAMP] WSON Signals and NE Compatibility draft 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, 19 Aug 2009 16:22:26 -0000 This is a multi-part message in MIME format. --------------020301080208080700060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers interested in WSON. We've published a revised version of "WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS ", draft-bernstein-ccamp-wson-compatibility-00.txt. Note that we renamed the file to avoid confusion with a different draft. As discussed in Stockholm we are going to keep this separate from the RWA Framework draft and the WSON Impairments draft. The relationship between these drafts is as follows: 1. /WSON RWA Framework/ -- This document primarily covers the RWA problem and asymmetric switching systems. This draft assumes that all WSON signals are compatible with all WSON network elements and hence do not need to be characterized or checked against network elements for compatibility. No impairments. 2. /WSON Compatibility/ -- This draft allows the WSON to deal with multiple signal types and network devices such as hybrid electro-optic systems that are compatible with only a limited set of optical signals. Models the WSON signal in terms of basic parameters and network elements in terms of /compatibility/ with these signals. No impairments. (Not currently a Working Group draft, currently an individual submission, but would like to advance this to a WG draft rapidly). 3. WSON Impairments -- Recognizes the existence of impairments and that not all paths are viable. Can convey impairment parameters for links and network elements (nodes). */Example:/* How do these drafts relate to the use of regenerators? (a) Determining if an optional regenerator should be used is an /impairment/ consideration. (b) Determining if a regenerator can process a given signal is a /compatibility/ consideration. This includes the case of fixed (not optional) regenerators that are part of line systems. (c) Configuring a regenerator to deal with a particular signal type is a /compatibility/ consideration. (d) Path selection and wavelength conversion constraints of regenerators are considered by the /RWA Framework/. Questions and Comments are always welcome. Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------020301080208080700060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers interested in WSON. We've published a revised version of
"WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS", draft-bernstein-ccamp-wson-compatibility-00.txt. Note that we renamed the file to avoid confusion with a different draft.

As discussed in Stockholm we are going to keep this separate from the RWA Framework draft and the WSON Impairments draft.
The relationship between these drafts is as follows:

  1. WSON RWA Framework -- This document primarily covers the RWA problem and asymmetric switching systems. This draft assumes that all WSON signals are compatible with all WSON network elements and hence do not need to be characterized or checked against network elements for compatibility. No impairments.
  2. WSON Compatibility -- This draft allows the WSON to deal with multiple signal types and network devices such as hybrid electro-optic systems that are compatible with only a limited set of optical signals. Models the WSON signal in terms of basic parameters and network elements in terms of compatibility with these signals. No impairments. (Not currently a Working Group draft, currently an individual submission, but would like to advance this to a WG draft  rapidly).
  3. WSON Impairments -- Recognizes the existence of impairments and that not all paths are viable. Can convey impairment parameters for links and network elements (nodes).

 

Example:

How do these drafts relate to the use of regenerators?

(a)    Determining if an optional regenerator should be used is an impairment consideration.

(b)   Determining if a regenerator can process a given signal is a compatibility consideration. This includes the case of fixed (not optional) regenerators that are part of line systems.

(c)    Configuring a regenerator to deal with a particular signal type is a compatibility consideration.

(d)   Path selection and wavelength conversion constraints of regenerators are considered by the RWA Framework.

Questions and Comments are always welcome.

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------020301080208080700060405-- From tom.nadeau@bt.com Wed Aug 19 12:15:07 2009 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 CBC073A693F; Wed, 19 Aug 2009 12:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 rCDJcl+AR342; Wed, 19 Aug 2009 12:15:05 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 49E0C3A67F3; Wed, 19 Aug 2009 12:15:04 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.104]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 20:15:08 +0100 Received: from 217.32.164.181 ([217.32.164.181]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.150]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Aug 2009 19:15:08 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 19 Aug 2009 15:15:06 -0400 From: "Thomas D. Nadeau" To: Lou Berger Message-ID: Thread-Topic: [CCAMP] [ippm] [Fwd: IPPM expert review request] Thread-Index: AcohAVxCDlmyJZofI0exyOyPZQSTtg== In-Reply-To: <4A8C2648.9000002@labn.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 19:15:08.0996 (UTC) FILETIME=[5E0B4040:01CA2101] Cc: zhangguoying@mail.ritt.com.cn, Rschrage , 'IETF IPPM WG' , ccamp@ietf.org, 'Henk Uijterwaal' , 'Weiqiang Sun' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 19 Aug 2009 19:15:07 -0000 On 8/19/09 12:20 PM, "Lou Berger" wrote: > Tom, > This document covers evaluation metrics that you'd expect to see > produced by a test tool rather than from the systems (DUTs) themselves. > In short, no GMPLS network node is expected to implement this spec. > > WRT the quoted text. I viewed this as referring to a benchmarking tool > that is deployed in an operational network. I can see how this can be > misinterpreted and I have no objection to asking that the text be > removed from the document. > > Will dropping this text address your concerns? Yes and no. For the current document I think yes, but from a wider WG perspective, does the WG believe that MIBs can be used for the purposes of measuring metrics (say as the target for a tool like you refer to above)? Or does the WG feel new MIBs (or other APIs) should be developed to support such a tool? The worry I have, as an operator, is the introduction of such metrics without a standardized means of getting at them in devices. This will result in a hodgepodge of CLI-like mechanisms for anyone wishing to produce a measurement tool, thus increasing the costs to operators wishing to use said tools. > Note that this document has been a WG document for well over a year and > was first discussed in the WG ~2.5 years ago. That is a valid point, but as you know many documents unfortunately don't get the attention they deserve until a LC is issued. :( --Tom > Lou > > On 8/19/2009 11:18 AM, Thomas D. Nadeau wrote: >> Lou, >> >> I'd like to ask a question about this draft. How does it relate to (or >> not) to any of the GMPLS MIBs? As you know, the MIBs contain performance >> counters. If these metrics present in this draft do not coincide with the >> MIBs, this will cause more work for implementations. In particular, the >> following statement in this document worries me: >> >> On the other hand, it can also be used in operational environments for >> carriers to monitor the control plane operation in real-time. For >> example, a new object can be added to GMPLS TE STD MIB [RFC4802] so >> that the current and past control plane performance can be monitored >> through network management systems. The extension of TE-MIB to >> support the defined metrics is outside the scope of this document. >> >> >> Does the WG really want to progress a document that requires these >> changes? >> >> --Tom >> >> >> >> On 8/19/09 9:57 AM, "Rschrage" wrote: >> >>> Hi all, >>> >>> pls find attached a further updated edition of previous revised doc >>> draft-ietf-ccamp-lsp-dppm-06. >>> >>> I believe this is as far as we can go for the moment before a mutual >>> satisfactory understanding has been reached and a new draft has been issued >>> by the authors. >>> >>> Again, pls feel free to comment. >>> >>> Many thanks. >>> Brgds. >>> Reinhard Schrage >>> Tel: +49 (0) 5137 909540 >>> Mobile: +49 (0) 172 26.36.046 >>> reinhard@schrageconsult.com >>> >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>> Weiqiang Sun >>> Sent: Mittwoch, 19. August 2009 09:28 >>> To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' >>> Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, >>> ATTLABS'; 'IETF IPPM WG' >>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>> >>> More responses below: >>> >>> RS4. >>> Should be more specific as to why this metric is no simple function of >>> single uni-directional LSP Setup Delay metric, i.e. why can it not be >>> deduced from single LSP Setup Delay? >>> [sunwq] >>> This point is raised regarding the sentence "The time needed to setup a >>> large number of LSPs during a short time period can not be deduced by single >>> >>> LSP setup delay." >>> One reason is that when a large number of LSPs in being setup during a short >>> >>> period of time, the control plane may be crowded or even overwhelmed by the >>> large number of signaling and routing messages. This may significantly slow >>> down the processing of a particular signaling message, which will results in >>> >>> longer LSP provisioning delays. >>> Are you suggesting that we add similar explanations to the document? We'd >>> love to do that if you feel it is necessary. >>> >>> RS5. >>> The current definition only addresses multiple uni-directional LSP setups >>> between two nodes ID0 and ID1. What about the the case when ID0 is to setup >>> multiple uni-directional LSP setups to different egress nodes ID1, ID2, >>> ID3,.,IDN? >>> [sunwq] >>> Yes, it is a useful case. Likewise you would expect a case to establish a >>> varied number of (instead of one) LSPs to a set of destinations. Our >>> suggestion is that this case is approached by integrating the defined >>> methodologies of single/multiple LSPs provisioning delay, in the form of a >>> particular testing case, rather than a formal testing methodology. This is >>> in fact a trade-off between complexity and accuracy. >>> >>> Best regards, >>> Weiqiang >>> >>> -- >>> Weiqiang Sun >>> Shanghai Jiao Tong University >>> http://front.sjtu.edu.cn/~sunwq/ >>> >>> -------------------------------------------------- >>> From: "Weiqiang Sun" >>> Sent: Wednesday, August 19, 2009 2:48 PM >>> To: "Rschrage" ; "'Lou Berger'" >>> ; "'Henk Uijterwaal'" >>> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >>> ; "'IETF IPPM WG'" ; >>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>> >>>> Hi Reinhard, >>>> >>>> Many thanks for doing the careful review. We appreciate your many wording >>>> suggestions. We will go through these one by one and adopt those we feel >>>> appropriate. In this email I will not list all the comments since these >>>> will not lead to major technical changes. >>>> >>>> Below I try to respond to the points you raised in the revision. >>>> >>>> RS1. >>>> This would imply that the metric may produce a range of several values at >>>> one time with the minimum value to be taken from that range. >>>> I believe what the authors are trying to say is, that the LSP Setup Delay >>>> Metric provides a lower bound on all possible LSP Delay Metrics of >>>> actually instantiated LSPs, or in other words: an actual LSP Delay Metric >>>> cannot get smaller than an LSP Setup Delay Metric. >>>> [sunwq] >>>> This point is raised regarding the motivation of the sigleton definition >>>> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying >>>> to say that the minimum value of this metric reflects the (likely) single >>>> lsp setup delay when the control plane is lightly loaded. The formal >>>> definition of the minimum value is in "14.1 The minimum of metric" >>>> In fact we have inherited this from the IPPM documents (see RFC 2681, page >>>> 2 section 1.1 bullet 3). >>>> >>>> RS2. >>>> How? Should there be a methodology be defined for this? >>>> [sunwq] >>>> This point is raised regarding the sentense in our methodologies >>>> sections - "Make sure that the network has enough resource to set up the >>>> requested LSP." >>>> We have assumed that test personnel should have adequate expertise in >>>> allocating enough resources for the testing. The allocation of resources >>>> for the testing purpose can be very test specific and we believe it is >>>> quite outside the scope of this document. >>>> >>>> RS3. >>>> Too vague? As both timestamps are to be taken on the same ingress node, >>>> they should be taken at the same application/network level. >>>> [sunwq] >>>> This point is raised regarding the sentense "If the corresponding RESV >>>> message arrives within a reasonable period of time, take the timestamp >>>> (T2) as soon as possible upon receipt of the message." >>>> Yes, ideally the timestamp should be taken immediately after the reception >>>> of the RESV message. The wording "as soon as possible" is used to allow >>>> for some flexibility when RESV message needs to be propagated to certain >>>> modules where timestamp-taking is most appropriate. >>>> And again, this text is inherited from the IPPM documents (see RFC 2681 >>>> page 7, bullet 3). >>>> >>>> Thanks again and looking forward to your further comments and revisions. >>>> >>>> Weiqiang >>>> >>>> -- >>>> Weiqiang Sun >>>> Shanghai Jiao Tong University >>>> http://front.sjtu.edu.cn/~sunwq/ >>>> >>>> -------------------------------------------------- >>>> From: "Rschrage" >>>> Sent: Tuesday, August 18, 2009 8:23 PM >>>> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >>>> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >>>> ; ; "'IETF IPPM WG'" ; >>>> >>>> Subject: RE: [ippm] [Fwd: IPPM expert review request] >>>> >>>>> Hello, >>>>> >>>>> sorry for late response- >>>>> >>>>> Nevertheless here is a first edition of my revision of doc >>>>> draft-ietf-ccamp-lsp-dppm-06. >>>>> >>>>> The doc has been saved in Word 2003 format to easily track changes. >>>>> I am using Kaspersky Anti Virus 2010 software so I trust there should be >>>>> no >>>>> unpleasant surprises when downloading the attached word doc. >>>>> >>>>> >>>>> I thought it would be advisable to first address the suggested comments >>>>> and >>>>> questions upto and including the uni-directional LSP setup delay metric >>>>> and >>>>> after that to continue with the bi-directional and sample definitions as >>>>> covered in the doc. >>>>> >>>>> Please let me have your thoughts on this. >>>>> >>>>> Many thanks. >>>>> Reinhard Schrage >>>>> Tel: +49 (0) 5137 909540 >>>>> Mobile: +49 (0) 172 26.36.046 >>>>> reinhard@schrageconsult.com >>>>> >>>>> -----Original Message----- >>>>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>>>> Lou >>>>> Berger >>>>> Sent: Dienstag, 28. Juli 2009 14:59 >>>>> To: Henk Uijterwaal >>>>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>>>> sunwq@mit.edu; IETF IPPM WG >>>>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>>>> >>>>> Hank/Reinhard, >>>>> >>>>> Thank you very much for undertaking this review. Please cc >>>>> ccamp@ietf.org on any comments you may have. >>>>> >>>>> Lou >>>>> >>>>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>>>> Lou, others, >>>>>> >>>>>>> We received the request for a review of a document currently under >>>>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>>>> has time to do this review in the near future? >>>>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>>>> this. >>>>>> >>>>>> Reinhard: please post anything you find to both the list and the >>>>>> authors. >>>>>> And thank you for doing this. >>>>>> >>>>>> Henk >>>>>> >>>>>>> Matt & Henk >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: IPPM expert review request >>>>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>>>> From: Lou Berger >>>>>>> To: ippm-chairs@tools.ietf.org >>>>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>>>> zhangguoying >>>>>>> >>>>>>> Hi, >>>>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>>>> review >>>>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>>>> available at: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>>>> >>>>>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>>>>> can just last call the document in your WG (it has already passed CCAMP >>>>>>> WG LC). >>>>>>> >>>>>>> Thank you, >>>>>>> Lou (and Deborah) >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> ippm mailing list >>>>> ippm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ippm >>>>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> -- Principal Architect - 21CN Networks From web-usrn@ISI.EDU Thu Aug 20 15:19:45 2009 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 34C293A6D4F for ; Thu, 20 Aug 2009 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.037 X-Spam-Level: X-Spam-Status: No, score=-17.037 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 KG4ZV9HNz1o6 for ; Thu, 20 Aug 2009 15:19:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 19CE03A6D4A for ; Thu, 20 Aug 2009 15:19:40 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7KMIad3017946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Aug 2009 15:18:36 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n7KMIXCh017912; Thu, 20 Aug 2009 15:18:33 -0700 (PDT) Date: Thu, 20 Aug 2009 15:18:33 -0700 (PDT) Message-Id: <200908202218.n7KMIXCh017912@boreas.isi.edu> To: eric.mannie@perceval.net, dimitri.papadimitriou@alcatel.be, rcallon@juniper.net, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC4427 (1834) 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, 20 Aug 2009 22:19:45 -0000 The following errata report has been submitted for RFC4427, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4427&eid=1834 -------------------------------------- Type: Technical Reported by: Vishwas Manral Section: 4.6 Original Text ------------- E. M:N (M, N > 1, N >= M) type: A set of M specific recovery LSPs/spans protects a set of up to N specific working LSPs/spans. The two sets are explicitly identified. Extra traffic can be transported over the M recovery LSPs/spans when available. All the LSPs/spans must start and end at the same nodes. Corrected Text -------------- E. M:N (M, N > 1, N >= M > 1) type: A set of M specific recovery LSPs/spans protects a set of up to N specific working LSPs/spans. The two sets are explicitly identified. Extra traffic can be transported over the M recovery LSPs/spans when available. All the LSPs/spans must start and end at the same nodes. Notes ----- M > 1 is not specified Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4427 (draft-ietf-ccamp-gmpls-recovery-terminology-06) -------------------------------------- Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Publication Date : March 2006 Author(s) : E. Mannie, Ed., D. Papadimitriou, Ed. Category : INFORMATIONAL Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Thu Aug 20 16:04:27 2009 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 72B333A6ECC for ; Thu, 20 Aug 2009 16:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.046 X-Spam-Level: X-Spam-Status: No, score=-17.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 pjn+L8NvzR26 for ; Thu, 20 Aug 2009 16:04:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 421103A6C32 for ; Thu, 20 Aug 2009 16:03:54 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7KN30BO002306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Aug 2009 16:03:00 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n7KN2xcC002305; Thu, 20 Aug 2009 16:02:59 -0700 (PDT) Date: Thu, 20 Aug 2009 16:02:59 -0700 (PDT) Message-Id: <200908202302.n7KN2xcC002305@boreas.isi.edu> To: eric.mannie@perceval.net, dimitri.papadimitriou@alcatel.be, rcallon@juniper.net, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC4427 (1835) 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, 20 Aug 2009 23:04:27 -0000 The following errata report has been submitted for RFC4427, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4427&eid=1835 -------------------------------------- Type: Technical Reported by: Vishwas Manral Section: 6.3 Original Text ------------- 6.3. M:N (M, N > 1, N >= M) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic. Corrected Text -------------- 6.3. M:N (M, N > 1, N >= M > 1) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic. Notes ----- M > 1 is added Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4427 (draft-ietf-ccamp-gmpls-recovery-terminology-06) -------------------------------------- Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Publication Date : March 2006 Author(s) : E. Mannie, Ed., D. Papadimitriou, Ed. Category : INFORMATIONAL Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From sunwq@MIT.EDU Thu Aug 20 23:59:26 2009 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 3A6513A6CF0; Thu, 20 Aug 2009 23:59:26 -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=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 gr+FAioqN75q; Thu, 20 Aug 2009 23:59:24 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 3E92D3A6768; Thu, 20 Aug 2009 23:58:55 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7L6wpkM012509; Fri, 21 Aug 2009 02:58:51 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7L6wbUi008011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Aug 2009 02:58:41 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Rschrage" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <000c01ca20d5$03aeca30$0b0c5e90$@net> In-Reply-To: <000c01ca20d5$03aeca30$0b0c5e90$@net> Date: Fri, 21 Aug 2009 14:58:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 21 Aug 2009 06:59:26 -0000 Hi Reinhard, Thanks for sending this part. See below for my responses. [RS7] Is there any help or suggestion on how to actually compute a usable Lambda_m? [sunwq] No. Depending on the performance of the implementation, the lambda_m can be very different, even under the same topology. A proper value of Lambda_m can only be tuned in the testing. [RS8] How to compare metrics that have been generated by two different Poisson processes, i.e. e.g. two different arrival rates? [sunwq] No way. Do we need to do that anyway? [RS9] These sample tuples are dependent on the arrival rate Lambda_m. How to deduct this input parameter from a resulting sample? For instance, if two result sample sets are given, how can we be sure that they can be compared? [sunwq] My understanding of the sample is that it is a sequence of singleton values obtained under a set of parameters. The parameters, such as Lambda_m, are not visible in the sample. However, when reporting the sample, the parameters must also be reported. [RS10] A superposition of two different Poisson processes is being used here. How do you map the resulting RESV messages to the correct process, i.e. how to differentiate e.g. a late RESV message resulting from third PATH message in fourth invocation from an early RESV message solicited by first PATH message in fourth invocation? [sunwq] RESV messages can be differentiated by either MSG ID or non-overlapping LSP ID, or combined. The RSVP-TE protocol does that automatically. So I believe this is an RSVP-TE implementation issue, rather than a testing methodology issue. [RS11] ???? [sunwq] Well, the full text is like: "The percentile of Metric is defined as: given a metric and a percent X between 0% and 100%, the Xth percentile of all the dT values in the sample." Would it help a bit if sentence is replaced by the full text above? Please be noted that this text is inherited from the IPPM docs (See RFC 2681, page 16, 4.1). [RS12] As stipulated in RFC2330 the EDF is defined as a function F(x) which for any x gives the fractional proportion of the total measurements that were <= x. (see RFC2330 11.3 p26) Hence F(90)=0.25, F(100)=0.5,F(110)=0.75, F(500)=1 and therefore the 50th percentile is defined as 100 as opposed to 110. [sunwq] Yes you are right with regard to RFC 2330. But we have used exactly the same example as in RFC 2681 (page 16, section 4.1). The good thing is that the difference of the two calculations is very small when the number of measurement is large. Change needed? And I realized that the points you have raised covered the main part of the text. We would expect your further comments regarding our responses. Otherwise we will assume that you are happy with it and will proceed to change the text based on the revision you sent in your previous email :) Thank you again for your time in reviewing the draft so carefully. Best regards, Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Rschrage" Sent: Wednesday, August 19, 2009 9:57 PM To: "'Weiqiang Sun'" ; "'Lou Berger'" ; "'Henk Uijterwaal'" Cc: ; ; "'IETF IPPM WG'" Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] > Hi all, > > pls find attached a further updated edition of previous revised doc > draft-ietf-ccamp-lsp-dppm-06. > > I believe this is as far as we can go for the moment before a mutual > satisfactory understanding has been reached and a new draft has been > issued > by the authors. > > Again, pls feel free to comment. > > Many thanks. > Brgds. > Reinhard Schrage > Tel: +49 (0) 5137 909540 > Mobile: +49 (0) 172 26.36.046 > reinhard@schrageconsult.com > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Weiqiang Sun > Sent: Mittwoch, 19. August 2009 09:28 > To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' > Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, > ATTLABS'; 'IETF IPPM WG' > Subject: Re: [ippm] [Fwd: IPPM expert review request] > > More responses below: > > RS4. > Should be more specific as to why this metric is no simple function of > single uni-directional LSP Setup Delay metric, i.e. why can it not be > deduced from single LSP Setup Delay? > [sunwq] > This point is raised regarding the sentence "The time needed to setup a > large number of LSPs during a short time period can not be deduced by > single > > LSP setup delay." > One reason is that when a large number of LSPs in being setup during a > short > > period of time, the control plane may be crowded or even overwhelmed by > the > large number of signaling and routing messages. This may significantly > slow > down the processing of a particular signaling message, which will results > in > > longer LSP provisioning delays. > Are you suggesting that we add similar explanations to the document? We'd > love to do that if you feel it is necessary. > > RS5. > The current definition only addresses multiple uni-directional LSP setups > between two nodes ID0 and ID1. What about the the case when ID0 is to > setup > multiple uni-directional LSP setups to different egress nodes ID1, ID2, > ID3,.,IDN? > [sunwq] > Yes, it is a useful case. Likewise you would expect a case to establish a > varied number of (instead of one) LSPs to a set of destinations. Our > suggestion is that this case is approached by integrating the defined > methodologies of single/multiple LSPs provisioning delay, in the form of a > particular testing case, rather than a formal testing methodology. This is > in fact a trade-off between complexity and accuracy. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Weiqiang Sun" > Sent: Wednesday, August 19, 2009 2:48 PM > To: "Rschrage" ; "'Lou Berger'" > ; "'Henk Uijterwaal'" > Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" > ; "'IETF IPPM WG'" ; > Subject: Re: [ippm] [Fwd: IPPM expert review request] > >> Hi Reinhard, >> >> Many thanks for doing the careful review. We appreciate your many wording >> suggestions. We will go through these one by one and adopt those we feel >> appropriate. In this email I will not list all the comments since these >> will not lead to major technical changes. >> >> Below I try to respond to the points you raised in the revision. >> >> RS1. >> This would imply that the metric may produce a range of several values at >> one time with the minimum value to be taken from that range. >> I believe what the authors are trying to say is, that the LSP Setup Delay >> Metric provides a lower bound on all possible LSP Delay Metrics of >> actually instantiated LSPs, or in other words: an actual LSP Delay Metric >> cannot get smaller than an LSP Setup Delay Metric. >> [sunwq] >> This point is raised regarding the motivation of the sigleton definition >> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are >> trying > >> to say that the minimum value of this metric reflects the (likely) single >> lsp setup delay when the control plane is lightly loaded. The formal >> definition of the minimum value is in "14.1 The minimum of metric" >> In fact we have inherited this from the IPPM documents (see RFC 2681, >> page > >> 2 section 1.1 bullet 3). >> >> RS2. >> How? Should there be a methodology be defined for this? >> [sunwq] >> This point is raised regarding the sentense in our methodologies >> sections - "Make sure that the network has enough resource to set up the >> requested LSP." >> We have assumed that test personnel should have adequate expertise in >> allocating enough resources for the testing. The allocation of resources >> for the testing purpose can be very test specific and we believe it is >> quite outside the scope of this document. >> >> RS3. >> Too vague? As both timestamps are to be taken on the same ingress node, >> they should be taken at the same application/network level. >> [sunwq] >> This point is raised regarding the sentense "If the corresponding RESV >> message arrives within a reasonable period of time, take the timestamp >> (T2) as soon as possible upon receipt of the message." >> Yes, ideally the timestamp should be taken immediately after the >> reception > >> of the RESV message. The wording "as soon as possible" is used to allow >> for some flexibility when RESV message needs to be propagated to certain >> modules where timestamp-taking is most appropriate. >> And again, this text is inherited from the IPPM documents (see RFC 2681 >> page 7, bullet 3). >> >> Thanks again and looking forward to your further comments and revisions. >> >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Rschrage" >> Sent: Tuesday, August 18, 2009 8:23 PM >> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >> >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; ; "'IETF IPPM WG'" ; >> >> Subject: RE: [ippm] [Fwd: IPPM expert review request] >> >>> Hello, >>> >>> sorry for late response- >>> >>> Nevertheless here is a first edition of my revision of doc >>> draft-ietf-ccamp-lsp-dppm-06. >>> >>> The doc has been saved in Word 2003 format to easily track changes. >>> I am using Kaspersky Anti Virus 2010 software so I trust there should be >>> no >>> unpleasant surprises when downloading the attached word doc. >>> >>> >>> I thought it would be advisable to first address the suggested comments >>> and >>> questions upto and including the uni-directional LSP setup delay metric >>> and >>> after that to continue with the bi-directional and sample definitions as >>> covered in the doc. >>> >>> Please let me have your thoughts on this. >>> >>> Many thanks. >>> Reinhard Schrage >>> Tel: +49 (0) 5137 909540 >>> Mobile: +49 (0) 172 26.36.046 >>> reinhard@schrageconsult.com >>> >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>> Lou >>> Berger >>> Sent: Dienstag, 28. Juli 2009 14:59 >>> To: Henk Uijterwaal >>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>> sunwq@mit.edu; IETF IPPM WG >>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>> >>> Hank/Reinhard, >>> >>> Thank you very much for undertaking this review. Please cc >>> ccamp@ietf.org on any comments you may have. >>> >>> Lou >>> >>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>> Lou, others, >>>> >>>>> We received the request for a review of a document currently under >>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>> has time to do this review in the near future? >>>> >>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>> this. >>>> >>>> Reinhard: please post anything you find to both the list and the >>>> authors. >>>> And thank you for doing this. >>>> >>>> Henk >>>> >>>>> >>>>> Matt & Henk >>>>> >>>>> -------- Original Message -------- >>>>> Subject: IPPM expert review request >>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>> From: Lou Berger >>>>> To: ippm-chairs@tools.ietf.org >>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>> zhangguoying >>>>> >>>>> Hi, >>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>> review >>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>> available at: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>> >>>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>>> can just last call the document in your WG (it has already passed >>>>> CCAMP >>>>> WG LC). >>>>> >>>>> Thank you, >>>>> Lou (and Deborah) >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From eric.gray@ericsson.com Fri Aug 21 05:46:44 2009 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 1D9A73A6B2B for ; Fri, 21 Aug 2009 05:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ogQ75w7rniw5 for ; Fri, 21 Aug 2009 05:46:43 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 0BFD83A6845 for ; Fri, 21 Aug 2009 05:46:42 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n7LCkMDv023789; Fri, 21 Aug 2009 07:46:22 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 07:44:01 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 07:44:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 21 Aug 2009 08:44:00 -0400 From: Eric Gray To: RFC Errata System , "eric.mannie@perceval.net" , "dimitri.papadimitriou@alcatel.be" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "lberger@labn.net" , "dbrungard@att.com" Date: Fri, 21 Aug 2009 08:43:59 -0400 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4427 (1835) Thread-Index: Acoh6sA9I99s5nqeQm6r9SY9CVizUQAce7ow Message-ID: References: <200908202302.n7KN2xcC002305@boreas.isi.edu> In-Reply-To: <200908202302.n7KN2xcC002305@boreas.isi.edu> 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-OriginalArrivalTime: 21 Aug 2009 12:44:01.0566 (UTC) FILETIME=[0F311BE0:01CA225D] Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4427 (1835) 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, 21 Aug 2009 12:46:44 -0000 In this case, the additional "M > 1" is redundant, since the parenthesized statement starts by stating that _both_ M and N are reater than 1 - i.e. - "M, N > 1" equates to "M > 1, N > 1" The text referred to is correct as is. -- Eric=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= FC Errata System Sent: Thursday, August 20, 2009 7:03 PM To: eric.mannie@perceval.net; dimitri.papadimitriou@alcatel.be; rcallon@jun= iper.net; adrian.farrel@huawei.com; lberger@labn.net; dbrungard@att.com Cc: ccamp@ietf.org; rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC4427 (1835) The following errata report has been submitted for RFC4427, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Pr= otocol Label Switching (GMPLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4427&eid=3D1835 -------------------------------------- Type: Technical Reported by: Vishwas Manral Section: 6.3 Original Text ------------- 6.3. M:N (M, N > 1, N >=3D M) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic. Corrected Text -------------- 6.3. M:N (M, N > 1, N >=3D M > 1) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic. Notes ----- M > 1 is added Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC4427 (draft-ietf-ccamp-gmpls-recovery-terminology-06) -------------------------------------- Title : Recovery (Protection and Restoration) Terminology for= Generalized Multi-Protocol Label Switching (GMPLS) Publication Date : March 2006 Author(s) : E. Mannie, Ed., D. Papadimitriou, Ed. Category : INFORMATIONAL Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From vishwas.ietf@gmail.com Fri Aug 21 07:58:48 2009 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 EDFD728C1D2 for ; Fri, 21 Aug 2009 07:58:48 -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=0.121, 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 nlQdRmyP8IyD for ; Fri, 21 Aug 2009 07:58:47 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id AFAA128C1CB for ; Fri, 21 Aug 2009 07:58:47 -0700 (PDT) Received: by vws34 with SMTP id 34so707581vws.31 for ; Fri, 21 Aug 2009 07:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V7BkPgSYpf7Qb3VuFsS67fkTZdh6GNDBWSceSdyiwmk=; b=LwHFpXMyMxNCZdo14uIyoScvshBID+E90wyZgg1Q0qscBmomIqaeFTdCQlaH/syqa2 Ox0AM5M+pQDo7jLm872+vEOHC1jp0D0UgwRfLTJIdJ8mHEowEAePw4Uhtz9J8Cd6pU80 HljLglklhq6uJoNU9RCRWc8tRbOlX4uLqOGDI= 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=sxJJRnmTjgAGau+xligv3R9ELX4ps0v5+qZhjSU+kQTT2FAUjSAGjR+Wi8rgzuWVQ9 9UGw0myfY2f4CFP8ZgbK0Uw8lMmYbdtUCyD6DJPUwNbKZoHVQQe1i5szY5AAOg6vmLXf g13kmyM5sbEEEGhLkGeYC7smQlfFKl7IRretE= MIME-Version: 1.0 Received: by 10.150.56.21 with SMTP id e21mr1142906yba.219.1250866731282; Fri, 21 Aug 2009 07:58:51 -0700 (PDT) In-Reply-To: References: <200908202302.n7KN2xcC002305@boreas.isi.edu> Date: Fri, 21 Aug 2009 07:58:51 -0700 Message-ID: <77ead0ec0908210758v15c6828bsbfda4e6bec5c8d89@mail.gmail.com> From: Vishwas Manral To: Eric Gray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" , "dimitri.papadimitriou@alcatel.be" , "adrian.farrel@huawei.com" , "rcallon@juniper.net" , "eric.mannie@perceval.net" , RFC Errata System Subject: Re: [CCAMP] [Technical Errata Reported] RFC4427 (1835) 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, 21 Aug 2009 14:58:49 -0000 Hi Eric, Now I see it that way. However I got confused as "," is a seperator both for multiple conditions as well as multiple elements in a condition. The best way would be to put it would be only one condition (same for the other Errata): N >=3D M > 1. Thanks, Vishwas On Fri, Aug 21, 2009 at 5:43 AM, Eric Gray wrote: > In this case, the additional "M > 1" is redundant, since the parenthesize= d > statement starts by stating that _both_ M and N are reater than 1 - i.e. = - > "M, N > 1" equates to "M > 1, N > 1" > > The text referred to is correct as is. > > -- > Eric > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= RFC Errata System > Sent: Thursday, August 20, 2009 7:03 PM > To: eric.mannie@perceval.net; dimitri.papadimitriou@alcatel.be; rcallon@j= uniper.net; adrian.farrel@huawei.com; lberger@labn.net; dbrungard@att.com > Cc: ccamp@ietf.org; rfc-editor@rfc-editor.org > Subject: [CCAMP] [Technical Errata Reported] RFC4427 (1835) > > > The following errata report has been submitted for RFC4427, > "Recovery (Protection and Restoration) Terminology for Generalized Multi-= Protocol Label Switching (GMPLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4427&eid=3D1835 > > -------------------------------------- > Type: Technical > Reported by: Vishwas Manral > > Section: 6.3 > > Original Text > ------------- > 6.3. M:N (M, N > 1, N >=3D M) Protection > > > =A0 M:N protection has N working LSPs/spans carrying normal traffic and M > =A0 protection LSP/span that may carry extra-traffic. > > Corrected Text > -------------- > 6.3. M:N (M, N > 1, N >=3D M > 1) Protection > > > =A0 M:N protection has N working LSPs/spans carrying normal traffic and M > =A0 protection LSP/span that may carry extra-traffic. > > Notes > ----- > M > 1 is added > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4427 (draft-ietf-ccamp-gmpls-recovery-terminology-06) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Recovery (Protection and Restoration)= Terminology for Generalized Multi-Protocol Label Switching (GMPLS) > Publication Date =A0 =A0: March 2006 > Author(s) =A0 =A0 =A0 =A0 =A0 : E. Mannie, Ed., D. Papadimitriou, Ed. > Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Common Control and Measurement Plane > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > _______________________________________________ > 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 eric.gray@ericsson.com Fri Aug 21 14:38:38 2009 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 97B163A683E for ; Fri, 21 Aug 2009 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 DwMgClP4IN0H for ; Fri, 21 Aug 2009 14:38:37 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 67E473A682A for ; Fri, 21 Aug 2009 14:38:37 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7LLcYe4015009; Fri, 21 Aug 2009 16:38:34 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 16:36:58 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 16:36:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 21 Aug 2009 17:36:56 -0400 From: Eric Gray To: Vishwas Manral Date: Fri, 21 Aug 2009 17:36:55 -0400 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4427 (1835) Thread-Index: AcoilifEtUXCdQPqSNq5ZCms3kwBVgAEHKZQ Message-ID: References: <200908202302.n7KN2xcC002305@boreas.isi.edu> <77ead0ec0908210758v15c6828bsbfda4e6bec5c8d89@mail.gmail.com> In-Reply-To: <77ead0ec0908210758v15c6828bsbfda4e6bec5c8d89@mail.gmail.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-OriginalArrivalTime: 21 Aug 2009 21:36:58.0260 (UTC) FILETIME=[82C96540:01CA22A7] Cc: "ccamp@ietf.org" , "dimitri.papadimitriou@alcatel.be" , "adrian.farrel@huawei.com" , "rcallon@juniper.net" , "eric.mannie@perceval.net" , RFC Errata System Subject: Re: [CCAMP] [Technical Errata Reported] RFC4427 (1835) 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, 21 Aug 2009 21:38:38 -0000 Vishwas, The errata system is somewhat erratic. Changes that are not absolutely necessary tend to discredit/devalue the utility of the (already easy to ignore) errata process. If we had to make a change (to clarify what is understandably not very clear) it would be better to reduce the redundancy. I'd=20 offer as a possibly better "fix" - Replace "(M, N > 1, N >=3D M)" with "(N >=3D M > 1)" - which is what I think you're now suggesting as well. But that brings us back to the point - is this change really necessary at all? -- Eric -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Friday, August 21, 2009 10:59 AM To: Eric Gray Cc: RFC Errata System; eric.mannie@perceval.net; dimitri.papadimitriou@alca= tel.be; rcallon@juniper.net; adrian.farrel@huawei.com; lberger@labn.net; db= rungard@att.com; ccamp@ietf.org Subject: Re: [CCAMP] [Technical Errata Reported] RFC4427 (1835) Importance: High Hi Eric, Now I see it that way. However I got confused as "," is a seperator both for multiple conditions as well as multiple elements in a condition. The best way would be to put it would be only one condition (same for the other Errata): N >=3D M > 1. Thanks, Vishwas On Fri, Aug 21, 2009 at 5:43 AM, Eric Gray wrote: > In this case, the additional "M > 1" is redundant, since the parenthesize= d > statement starts by stating that _both_ M and N are reater than 1 - i.e. = - > "M, N > 1" equates to "M > 1, N > 1" > > The text referred to is correct as is. > > -- > Eric > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= RFC Errata System > Sent: Thursday, August 20, 2009 7:03 PM > To: eric.mannie@perceval.net; dimitri.papadimitriou@alcatel.be; rcallon@j= uniper.net; adrian.farrel@huawei.com; lberger@labn.net; dbrungard@att.com > Cc: ccamp@ietf.org; rfc-editor@rfc-editor.org > Subject: [CCAMP] [Technical Errata Reported] RFC4427 (1835) > > > The following errata report has been submitted for RFC4427, > "Recovery (Protection and Restoration) Terminology for Generalized Multi-= Protocol Label Switching (GMPLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4427&eid=3D1835 > > -------------------------------------- > Type: Technical > Reported by: Vishwas Manral > > Section: 6.3 > > Original Text > ------------- > 6.3. M:N (M, N > 1, N >=3D M) Protection > > > =A0 M:N protection has N working LSPs/spans carrying normal traffic and M > =A0 protection LSP/span that may carry extra-traffic. > > Corrected Text > -------------- > 6.3. M:N (M, N > 1, N >=3D M > 1) Protection > > > =A0 M:N protection has N working LSPs/spans carrying normal traffic and M > =A0 protection LSP/span that may carry extra-traffic. > > Notes > ----- > M > 1 is added > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4427 (draft-ietf-ccamp-gmpls-recovery-terminology-06) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Recovery (Protection and Restoration)= Terminology for Generalized Multi-Protocol Label Switching (GMPLS) > Publication Date =A0 =A0: March 2006 > Author(s) =A0 =A0 =A0 =A0 =A0 : E. Mannie, Ed., D. Papadimitriou, Ed. > Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Common Control and Measurement Plane > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > _______________________________________________ > 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 vishwas.ietf@gmail.com Fri Aug 21 15:25:16 2009 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 12A213A69EA for ; Fri, 21 Aug 2009 15:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 Yt7eKqd8Js+G for ; Fri, 21 Aug 2009 15:25:15 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id C66B03A6977 for ; Fri, 21 Aug 2009 15:25:12 -0700 (PDT) Received: by gxk17 with SMTP id 17so1453059gxk.19 for ; Fri, 21 Aug 2009 15:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Oc16dwbaCI5JwYHAtbJMTTcbyfG2U4wZ8fi3h3kQkTg=; b=no6hbVn1KrX/iVQtSeclPV3X8xcXBN430zP4iQBv/90Z4tpcrDcyaewV3CY4l91ZRl gn+pQFlXPAA5v2QvNqqOBcrlv67bMTZe0mE5ihxqJTYIM5UfqUQyb33QYzhbecVWQ+ho sqSwA805fGm5diT9fDi+o/PZR4AHGxRTkB7Yw= 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=D7IyQX4Q1bGozl2rXaYeF6ufCH2xL25tWO5zyq2is8wiO+EEcQ8hVhElSOxGtueyZ3 vVevZMEGISV8u7ZPuhGyX7WI/kmc4UKXZ20FVTGks+poUG5AABTVq0MIgbWEUBjqj+gH 2gUt+kif0kwCEZKIRMRJMertK3JWgMMsWEJAs= MIME-Version: 1.0 Received: by 10.150.237.3 with SMTP id k3mr3244322ybh.70.1250893515549; Fri, 21 Aug 2009 15:25:15 -0700 (PDT) In-Reply-To: References: <200908202302.n7KN2xcC002305@boreas.isi.edu> <77ead0ec0908210758v15c6828bsbfda4e6bec5c8d89@mail.gmail.com> Date: Fri, 21 Aug 2009 15:25:15 -0700 Message-ID: <77ead0ec0908211525w7bbd0c09tdc5a3b20d9398300@mail.gmail.com> From: Vishwas Manral To: Eric Gray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" , "dimitri.papadimitriou@alcatel.be" , "adrian.farrel@huawei.com" , "rcallon@juniper.net" , "eric.mannie@perceval.net" , RFC Errata System Subject: Re: [CCAMP] [Technical Errata Reported] RFC4427 (1835) 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, 21 Aug 2009 22:25:16 -0000 Hi Eric, Thats correct. I am ok with the suggestions you mention (which is what I am saying too). Thanks, Vishwas On Fri, Aug 21, 2009 at 2:36 PM, Eric Gray wrote: > Vishwas, > > =A0 =A0 =A0 =A0The errata system is somewhat erratic. =A0Changes that are= not > absolutely necessary tend to discredit/devalue the utility of the > (already easy to ignore) errata process. > > =A0 =A0 =A0 =A0If we had to make a change (to clarify what is understanda= bly > not very clear) it would be better to reduce the redundancy. =A0I'd > offer as a possibly better "fix" - > > =A0 =A0 =A0 =A0Replace "(M, N > 1, N >=3D M)" with "(N >=3D M > 1)" > > - which is what I think you're now suggesting as well. > > =A0 =A0 =A0 =A0But that brings us back to the point - is this change real= ly > necessary at all? > > -- > Eric > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Friday, August 21, 2009 10:59 AM > To: Eric Gray > Cc: RFC Errata System; eric.mannie@perceval.net; dimitri.papadimitriou@al= catel.be; rcallon@juniper.net; adrian.farrel@huawei.com; lberger@labn.net; = dbrungard@att.com; ccamp@ietf.org > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4427 (1835) > Importance: High > > Hi Eric, > > Now I see it that way. However I got confused as "," is a seperator > both for multiple conditions as well as multiple elements in a > condition. > > The best way would be to put it would be only one condition (same for > the other Errata): > > N >=3D M > 1. > > Thanks, > Vishwas > > On Fri, Aug 21, 2009 at 5:43 AM, Eric Gray wrote: >> In this case, the additional "M > 1" is redundant, since the parenthesiz= ed >> statement starts by stating that _both_ M and N are reater than 1 - i.e.= - >> "M, N > 1" equates to "M > 1, N > 1" >> >> The text referred to is correct as is. >> >> -- >> Eric >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf O= f RFC Errata System >> Sent: Thursday, August 20, 2009 7:03 PM >> To: eric.mannie@perceval.net; dimitri.papadimitriou@alcatel.be; rcallon@= juniper.net; adrian.farrel@huawei.com; lberger@labn.net; dbrungard@att.com >> Cc: ccamp@ietf.org; rfc-editor@rfc-editor.org >> Subject: [CCAMP] [Technical Errata Reported] RFC4427 (1835) >> >> >> The following errata report has been submitted for RFC4427, >> "Recovery (Protection and Restoration) Terminology for Generalized Multi= -Protocol Label Switching (GMPLS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4427&eid=3D1835 >> >> -------------------------------------- >> Type: Technical >> Reported by: Vishwas Manral >> >> Section: 6.3 >> >> Original Text >> ------------- >> 6.3. M:N (M, N > 1, N >=3D M) Protection >> >> >> =A0 M:N protection has N working LSPs/spans carrying normal traffic and = M >> =A0 protection LSP/span that may carry extra-traffic. >> >> Corrected Text >> -------------- >> 6.3. M:N (M, N > 1, N >=3D M > 1) Protection >> >> >> =A0 M:N protection has N working LSPs/spans carrying normal traffic and = M >> =A0 protection LSP/span that may carry extra-traffic. >> >> Notes >> ----- >> M > 1 is added >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4427 (draft-ietf-ccamp-gmpls-recovery-terminology-06) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Recovery (Protection and Restoration= ) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) >> Publication Date =A0 =A0: March 2006 >> Author(s) =A0 =A0 =A0 =A0 =A0 : E. Mannie, Ed., D. Papadimitriou, Ed. >> Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Common Control and Measurement Plane >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG >> _______________________________________________ >> 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 Mon Aug 24 08:06:53 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B76013A6E44; Mon, 24 Aug 2009 08:06:53 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090824150653.B76013A6E44@core3.amsl.com> Date: Mon, 24 Aug 2009 08:06:53 -0700 (PDT) X-Mailman-Approved-At: Mon, 24 Aug 2009 10:34:37 -0700 Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Document Action: 'OSPFv2 Routing Protocols Extensions for ASON Routing' to Experimental RFC 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, 24 Aug 2009 15:06:53 -0000 The IESG has approved the following document: - 'OSPFv2 Routing Protocols Extensions for ASON Routing ' as an Experimental RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt Technical Summary The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines to the OSPFv2 Link State Routing Protocol to meet the routing requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. Working Group Summary As noted above, although concerns were raised about the completeness of RFC 4258 that sets out the requirements, it has been agreed that this I-D should progress while work continues to revise that RFC. If changes or additions should be required as a result of the revision of RFC 4258, this work can be revised in the future. Document Quality There are no known implementations or planned implementations of this work. Personnel The Document Shepherd is Deborah Brungard. The Responsible AD is Adrian Farrel. From root@core3.amsl.com Tue Aug 25 19:15:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 81F8B3A685B; Tue, 25 Aug 2009 19:15: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: <20090826021501.81F8B3A685B@core3.amsl.com> Date: Tue, 25 Aug 2009 19:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-07.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, 26 Aug 2009 02:15:01 -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 : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-07.txt Pages : 49 Date : 2009-08-25 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-07.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-lsp-dppm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-25190442.I-D@ietf.org> --NextPart-- From sunwq@MIT.EDU Tue Aug 25 19:16:26 2009 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 F18ED28C2FF; Tue, 25 Aug 2009 19:16:25 -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=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 Nk+i0z23+Dpc; Tue, 25 Aug 2009 19:16:25 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id CB4BD28C286; Tue, 25 Aug 2009 19:16:22 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7Q2GP69014396; Tue, 25 Aug 2009 22:16:25 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7Q2GIe9021105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Aug 2009 22:16:21 -0400 (EDT) Message-ID: <88C49D23379F4FA998BF3D7B323F2873@mit.edu> From: "Weiqiang Sun" To: , "IPPM WG IETF" Date: Wed, 26 Aug 2009 10:16:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: Henk Uijterwaal , Rschrage Subject: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-lsp-dppm-07 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, 26 Aug 2009 02:16:26 -0000 Hi all, Thanks to Reinhard Schrage, we now have a better version of the DPPM draft uploaded. In this revision, no technical changes are made. And, as per Tom's comments, we have droped the following two sentenses. - They can also be used in operational networks for carriers to monitor the control plane performance in realtime. - On the other hand, it can also be used in operational environments for carriers to monitor the control plane operation in real-time. For example, a new object can be added to GMPLS TE STD MIB [RFC4802] so that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the defined metrics is outside the scope of this document. As the document has passed WGLC, we would like to pass it back to the hands of our chairs for further processing. Thanks and best regards, Weiqiang -------------------------------------------------- From: "IETF I-D Submission Tool" Sent: Wednesday, August 26, 2009 10:04 AM Subject: New Version Notification for draft-ietf-ccamp-lsp-dppm-07 > > A new version of I-D, draft-ietf-ccamp-lsp-dppm-07.txt has been > successfuly submitted by Weiqiang Sun and posted to the IETF repository. > > Filename: draft-ietf-ccamp-lsp-dppm > Revision: 07 > Title: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics > in Generalized MPLS Networks > Creation_date: 2009-08-26 > WG ID: ccamp > Number_of_pages: 49 > > Abstract: > Generalized Multi-Protocol Label Switching (GMPLS) is one of the most > promising candidate technologies for future data transmission > network. GMPLS has been developed to control and operate different > kinds of network elements, such as conventional routers, switches, > Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop > Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- > connects (OXCs), etc. Dynamic provisioning ability of these > physically diverse devices differs from each other drastically. At > the same time, the need for dynamically provisioned connections is > increasing because optical networks are being deployed in metro > areas. As different applications have varied requirements in the > provisioning performance of optical networks, it is imperative to > define standardized metrics and procedures such that the performance > of networks and application needs can be mapped to each other. > > This document provides a series of performance metrics to evaluate > the dynamic LSP provisioning performance in GMPLS networks, > specifically the dynamic LSP setup/release performance. These > metrics can depict the features of GMPLS networks in LSP dynamic > provisioning. > > > > The IETF Secretariat. > > > From sunwq@MIT.EDU Tue Aug 25 19:16:41 2009 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 0ED6128C286; Tue, 25 Aug 2009 19:16:41 -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=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 7-AIhMG69kXT; Tue, 25 Aug 2009 19:16:40 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id A286228C268; Tue, 25 Aug 2009 19:16:40 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7Q2GjVN014482; Tue, 25 Aug 2009 22:16:45 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7Q2Gdww021133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Aug 2009 22:16:42 -0400 (EDT) Message-ID: <81C7FCD19CB343E682C9FA0657369CF5@mit.edu> From: "Weiqiang Sun" To: , "IPPM WG IETF" Date: Wed, 26 Aug 2009 10:16:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: Henk Uijterwaal , Rschrage Subject: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-lsp-dppm-07 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, 26 Aug 2009 02:16:41 -0000 Hi all, Thanks to Reinhard Schrage, we now have a better version of the DPPM draft uploaded. In this revision, no technical changes are made. And, as per Tom's comments, we have droped the following two sentenses. - They can also be used in operational networks for carriers to monitor the control plane performance in realtime. - On the other hand, it can also be used in operational environments for carriers to monitor the control plane operation in real-time. For example, a new object can be added to GMPLS TE STD MIB [RFC4802] so that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the defined metrics is outside the scope of this document. As the document has passed WGLC, we would like to pass it back to the hands of our chairs for further processing. Thanks and best regards, Weiqiang -------------------------------------------------- From: "IETF I-D Submission Tool" Sent: Wednesday, August 26, 2009 10:04 AM Subject: New Version Notification for draft-ietf-ccamp-lsp-dppm-07 > > A new version of I-D, draft-ietf-ccamp-lsp-dppm-07.txt has been > successfuly submitted by Weiqiang Sun and posted to the IETF repository. > > Filename: draft-ietf-ccamp-lsp-dppm > Revision: 07 > Title: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics > in Generalized MPLS Networks > Creation_date: 2009-08-26 > WG ID: ccamp > Number_of_pages: 49 > > Abstract: > Generalized Multi-Protocol Label Switching (GMPLS) is one of the most > promising candidate technologies for future data transmission > network. GMPLS has been developed to control and operate different > kinds of network elements, such as conventional routers, switches, > Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop > Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- > connects (OXCs), etc. Dynamic provisioning ability of these > physically diverse devices differs from each other drastically. At > the same time, the need for dynamically provisioned connections is > increasing because optical networks are being deployed in metro > areas. As different applications have varied requirements in the > provisioning performance of optical networks, it is imperative to > define standardized metrics and procedures such that the performance > of networks and application needs can be mapped to each other. > > This document provides a series of performance metrics to evaluate > the dynamic LSP provisioning performance in GMPLS networks, > specifically the dynamic LSP setup/release performance. These > metrics can depict the features of GMPLS networks in LSP dynamic > provisioning. > > > > The IETF Secretariat. > > > From rschrage@schrageconsult.net Wed Aug 26 08:08:26 2009 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 E08623A67B5; Wed, 26 Aug 2009 08:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_05=-1.11, HELO_EQ_DE=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 n0owr7K3ceBc; Wed, 26 Aug 2009 08:08:25 -0700 (PDT) Received: from mailout01.t-online.de (mailout01.t-online.de [194.25.134.80]) by core3.amsl.com (Postfix) with ESMTP id 7C8093A6855; Wed, 26 Aug 2009 08:07:49 -0700 (PDT) Received: from fwd07.aul.t-online.de by mailout01.t-online.de with smtp id 1MgK3Q-0003XF-01; Wed, 26 Aug 2009 17:04:52 +0200 Received: from ReinhardLaptop (Vma7h-ZO8t6vTLQiDEh0AS1+N-LfkEt1D6k0j14InOfvdFxJAOUBXaKj8XttPNBopngKKmF4or@[91.4.15.102]) by fwd07.webpage.t-com.de with esmtp id 1MgK3H-1CJKRU0; Wed, 26 Aug 2009 17:04:43 +0200 From: "Rschrage" To: "'Weiqiang Sun'" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <000c01ca20d5$03aeca30$0b0c5e90$@net> In-Reply-To: Date: Wed, 26 Aug 2009 17:04:40 +0200 Message-ID: <002601ca265e$89ef67b0$9dce3710$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoiLU8i+Goh7BvoQc2nTr15mUzEYwEH1IVQ Content-Language: de X-ID: Vma7h-ZO8t6vTLQiDEh0AS1+N-LfkEt1D6k0j14InOfvdFxJAOUBXaKj8XttPNBopngKKmF4or X-TOI-MSGID: 43ecd652-f94b-4069-9fc0-65c75605c2a6 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 26 Aug 2009 15:08:27 -0000 Hi Weiqiang, sorry for late reply- My responses/comments follow below your points. We seem to be coming from different view points Brgds. Reinhard Schrage Tel: +49 (0) 5137 909540 Mobile: +49 (0) 172 26.36.046 reinhard@schrageconsult.com -----Original Message----- From: Weiqiang Sun [mailto:sunwq@MIT.EDU] Sent: Freitag, 21. August 2009 08:59 To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] Hi Reinhard, Thanks for sending this part. See below for my responses. [RS7] Is there any help or suggestion on how to actually compute a usable Lambda_m? [sunwq] No. Depending on the performance of the implementation, the lambda_m can be very different, even under the same topology. A proper value of Lambda_m can only be tuned in the testing. [RS7a] I am a bit at loss here. It was my understanding that you use a metric to measure certain network quantities, e.g. throughput, set up delays, etc. In a second step you'd use these measured metrics to determine whether the systems under test meet your previously expected or defined quality parameters. If not, you'd make changes to the components or network design, measure again, and compare the previous set of data to the one after the change and see whether you have improved and are moving into the right direction. You seem to be coming from the other end, i.e. tweak the input parameters to suit your system under test. [RS8] How to compare metrics that have been generated by two different Poisson processes, i.e. e.g. two different arrival rates? [sunwq] No way. Do we need to do that anyway? [RS8a] Pls also see my comments above. If you cannot compare two sets of measurements how will you then arrive at an objective study of the network components under test? [RS9] These sample tuples are dependent on the arrival rate Lambda_m. How to deduct this input parameter from a resulting sample? For instance, if two result sample sets are given, how can we be sure that they can be compared? [sunwq] My understanding of the sample is that it is a sequence of singleton values obtained under a set of parameters. The parameters, such as Lambda_m, are not visible in the sample. However, when reporting the sample, the parameters must also be reported. [RS9a] OK. Noted and understood. [RS10] A superposition of two different Poisson processes is being used here. How do you map the resulting RESV messages to the correct process, i.e. how to differentiate e.g. a late RESV message resulting from third PATH message in fourth invocation from an early RESV message solicited by first PATH message in fourth invocation? [sunwq] RESV messages can be differentiated by either MSG ID or non-overlapping LSP ID, or combined. The RSVP-TE protocol does that automatically. So I believe this is an RSVP-TE implementation issue, rather than a testing methodology issue. [RS10a] OK. Noted and understood. [RS11] ???? [sunwq] Well, the full text is like: "The percentile of Metric is defined as: given a metric and a percent X between 0% and 100%, the Xth percentile of all the dT values in the sample." Would it help a bit if sentence is replaced by the full text above? Please be noted that this text is inherited from the IPPM docs (See RFC 2681, page 16, 4.1). [RS11a] The way it was written in the doc it was just a fragment of a sentence. Unfortunately RFC 2681, page 16, 4.1. also does not give a proper definition, as it too is just a fragmented sentence. RFC 2330, p.26, 11.3 gives a better explanation, as: "We will use the term 'percentile' to refer to the smallest value of x for which the empirical distribution function is greater or equal a given percentage" [RS12] As stipulated in RFC2330 the EDF is defined as a function F(x) which for any x gives the fractional proportion of the total measurements that were <= x. (see RFC2330 11.3 p26) Hence F(90)=0.25, F(100)=0.5,F(110)=0.75, F(500)=1 and therefore the 50th percentile is defined as 100 as opposed to 110. [sunwq] Yes you are right with regard to RFC 2330. But we have used exactly the same example as in RFC 2681 (page 16, section 4.1). The good thing is that the difference of the two calculations is very small when the number of measurement is large. Change needed? [RS12a] As outlined above RFC 2330 as opposed to RFC2681 gives a proper definition of percentile. Therefore we should stick to RFC2330 and change accordingly. It should be noted though, that also RFC2330 defines percentile differently than it is done in the statistical literature, but we can live with this, as it makes the definition easier to apply to measurement samples. [------------------End of new comments---------------------] And I realized that the points you have raised covered the main part of the text. We would expect your further comments regarding our responses. Otherwise we will assume that you are happy with it and will proceed to change the text based on the revision you sent in your previous email :) Thank you again for your time in reviewing the draft so carefully. Best regards, Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Rschrage" Sent: Wednesday, August 19, 2009 9:57 PM To: "'Weiqiang Sun'" ; "'Lou Berger'" ; "'Henk Uijterwaal'" Cc: ; ; "'IETF IPPM WG'" Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] > Hi all, > > pls find attached a further updated edition of previous revised doc > draft-ietf-ccamp-lsp-dppm-06. > > I believe this is as far as we can go for the moment before a mutual > satisfactory understanding has been reached and a new draft has been > issued > by the authors. > > Again, pls feel free to comment. > > Many thanks. > Brgds. > Reinhard Schrage > Tel: +49 (0) 5137 909540 > Mobile: +49 (0) 172 26.36.046 > reinhard@schrageconsult.com > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Weiqiang Sun > Sent: Mittwoch, 19. August 2009 09:28 > To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' > Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, > ATTLABS'; 'IETF IPPM WG' > Subject: Re: [ippm] [Fwd: IPPM expert review request] > > More responses below: > > RS4. > Should be more specific as to why this metric is no simple function of > single uni-directional LSP Setup Delay metric, i.e. why can it not be > deduced from single LSP Setup Delay? > [sunwq] > This point is raised regarding the sentence "The time needed to setup a > large number of LSPs during a short time period can not be deduced by > single > > LSP setup delay." > One reason is that when a large number of LSPs in being setup during a > short > > period of time, the control plane may be crowded or even overwhelmed by > the > large number of signaling and routing messages. This may significantly > slow > down the processing of a particular signaling message, which will results > in > > longer LSP provisioning delays. > Are you suggesting that we add similar explanations to the document? We'd > love to do that if you feel it is necessary. > > RS5. > The current definition only addresses multiple uni-directional LSP setups > between two nodes ID0 and ID1. What about the the case when ID0 is to > setup > multiple uni-directional LSP setups to different egress nodes ID1, ID2, > ID3,.,IDN? > [sunwq] > Yes, it is a useful case. Likewise you would expect a case to establish a > varied number of (instead of one) LSPs to a set of destinations. Our > suggestion is that this case is approached by integrating the defined > methodologies of single/multiple LSPs provisioning delay, in the form of a > particular testing case, rather than a formal testing methodology. This is > in fact a trade-off between complexity and accuracy. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Weiqiang Sun" > Sent: Wednesday, August 19, 2009 2:48 PM > To: "Rschrage" ; "'Lou Berger'" > ; "'Henk Uijterwaal'" > Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" > ; "'IETF IPPM WG'" ; > Subject: Re: [ippm] [Fwd: IPPM expert review request] > >> Hi Reinhard, >> >> Many thanks for doing the careful review. We appreciate your many wording >> suggestions. We will go through these one by one and adopt those we feel >> appropriate. In this email I will not list all the comments since these >> will not lead to major technical changes. >> >> Below I try to respond to the points you raised in the revision. >> >> RS1. >> This would imply that the metric may produce a range of several values at >> one time with the minimum value to be taken from that range. >> I believe what the authors are trying to say is, that the LSP Setup Delay >> Metric provides a lower bound on all possible LSP Delay Metrics of >> actually instantiated LSPs, or in other words: an actual LSP Delay Metric >> cannot get smaller than an LSP Setup Delay Metric. >> [sunwq] >> This point is raised regarding the motivation of the sigleton definition >> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are >> trying > >> to say that the minimum value of this metric reflects the (likely) single >> lsp setup delay when the control plane is lightly loaded. The formal >> definition of the minimum value is in "14.1 The minimum of metric" >> In fact we have inherited this from the IPPM documents (see RFC 2681, >> page > >> 2 section 1.1 bullet 3). >> >> RS2. >> How? Should there be a methodology be defined for this? >> [sunwq] >> This point is raised regarding the sentense in our methodologies >> sections - "Make sure that the network has enough resource to set up the >> requested LSP." >> We have assumed that test personnel should have adequate expertise in >> allocating enough resources for the testing. The allocation of resources >> for the testing purpose can be very test specific and we believe it is >> quite outside the scope of this document. >> >> RS3. >> Too vague? As both timestamps are to be taken on the same ingress node, >> they should be taken at the same application/network level. >> [sunwq] >> This point is raised regarding the sentense "If the corresponding RESV >> message arrives within a reasonable period of time, take the timestamp >> (T2) as soon as possible upon receipt of the message." >> Yes, ideally the timestamp should be taken immediately after the >> reception > >> of the RESV message. The wording "as soon as possible" is used to allow >> for some flexibility when RESV message needs to be propagated to certain >> modules where timestamp-taking is most appropriate. >> And again, this text is inherited from the IPPM documents (see RFC 2681 >> page 7, bullet 3). >> >> Thanks again and looking forward to your further comments and revisions. >> >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Rschrage" >> Sent: Tuesday, August 18, 2009 8:23 PM >> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >> >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; ; "'IETF IPPM WG'" ; >> >> Subject: RE: [ippm] [Fwd: IPPM expert review request] >> >>> Hello, >>> >>> sorry for late response- >>> >>> Nevertheless here is a first edition of my revision of doc >>> draft-ietf-ccamp-lsp-dppm-06. >>> >>> The doc has been saved in Word 2003 format to easily track changes. >>> I am using Kaspersky Anti Virus 2010 software so I trust there should be >>> no >>> unpleasant surprises when downloading the attached word doc. >>> >>> >>> I thought it would be advisable to first address the suggested comments >>> and >>> questions upto and including the uni-directional LSP setup delay metric >>> and >>> after that to continue with the bi-directional and sample definitions as >>> covered in the doc. >>> >>> Please let me have your thoughts on this. >>> >>> Many thanks. >>> Reinhard Schrage >>> Tel: +49 (0) 5137 909540 >>> Mobile: +49 (0) 172 26.36.046 >>> reinhard@schrageconsult.com >>> >>> -----Original Message----- >>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>> Lou >>> Berger >>> Sent: Dienstag, 28. Juli 2009 14:59 >>> To: Henk Uijterwaal >>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>> sunwq@mit.edu; IETF IPPM WG >>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>> >>> Hank/Reinhard, >>> >>> Thank you very much for undertaking this review. Please cc >>> ccamp@ietf.org on any comments you may have. >>> >>> Lou >>> >>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>> Lou, others, >>>> >>>>> We received the request for a review of a document currently under >>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>> has time to do this review in the near future? >>>> >>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>> this. >>>> >>>> Reinhard: please post anything you find to both the list and the >>>> authors. >>>> And thank you for doing this. >>>> >>>> Henk >>>> >>>>> >>>>> Matt & Henk >>>>> >>>>> -------- Original Message -------- >>>>> Subject: IPPM expert review request >>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>> From: Lou Berger >>>>> To: ippm-chairs@tools.ietf.org >>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>> zhangguoying >>>>> >>>>> Hi, >>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>> review >>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>> available at: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>> >>>>> Is this acceptable? Can you undertake this review? Alternatively, we >>>>> can just last call the document in your WG (it has already passed >>>>> CCAMP >>>>> WG LC). >>>>> >>>>> Thank you, >>>>> Lou (and Deborah) >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From sunwq@MIT.EDU Wed Aug 26 23:25:50 2009 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 8F28C3A6B0C; Wed, 26 Aug 2009 23:25:50 -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=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 NGnHqhwALIls; Wed, 26 Aug 2009 23:25:48 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 785363A68B0; Wed, 26 Aug 2009 23:25:48 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7R6PmU2023792; Thu, 27 Aug 2009 02:25:49 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7R6Pe2s015961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 27 Aug 2009 02:25:44 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Rschrage" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <000c01ca20d5$03aeca30$0b0c5e90$@net> <002601ca265e$89ef67b0$9dce3710$@net> In-Reply-To: <002601ca265e$89ef67b0$9dce3710$@net> Date: Thu, 27 Aug 2009 14:25:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 27 Aug 2009 06:25:50 -0000 Hi Reinhard, Thanks for responding. Please see inline. > > Thanks for sending this part. See below for my responses. > > [RS7] > Is there any help or suggestion on how to actually compute a usable > Lambda_m? > [sunwq] > No. Depending on the performance of the implementation, the lambda_m can > be > very different, even under the same topology. A proper value of Lambda_m > can > only be tuned in the testing. > > [RS7a] > I am a bit at loss here. > > It was my understanding that you use a metric to measure certain network > quantities, e.g. throughput, set up delays, etc. > In a second step you'd use these measured metrics to determine whether the > systems under test meet your previously expected or defined quality > parameters. If not, you'd make changes to the components or network > design, > measure again, and compare the previous set of data to the one after the > change and see whether you have improved and are moving into the right > direction. > > You seem to be coming from the other end, i.e. tweak the input parameters > to > suit your system under test. [sunwq] OK, I get your point here. What you said is true. I had thought by saying ``a usable lambda_m", you are saying that a lambda_m that is *best achievable* by the DUT/SUT. If you are expecting certain performance from the DUT/SUT, then very likely you will have in mind an "expected" lambda_m, won't you? The methodology here does not suggest how to select lambda_m. This in fact can provide flexibility. Either the test will use an expected lambda_m, or tune the lambda_m that reflects the best system performance, depending on the purpose of the test. Does this make sense? > > [RS8] > How to compare metrics that have been generated by two different Poisson > processes, i.e. e.g. two different arrival rates? > [sunwq] > No way. Do we need to do that anyway? > > [RS8a] > Pls also see my comments above. > If you cannot compare two sets of measurements how will you then arrive at > an objective study of the network components under test? [sunwq] Maybe I misunderstood you again here. The Poisson arrival rate is an approximation of real traffic load. Of course it is worthwhile to find out how DUT/SUT performs when traffic load changes. But what else do you expect by comparing two data sets from different traffic load? Did I miss something here? > > > [RS9] > These sample tuples are dependent on the arrival rate Lambda_m. How to > deduct this input parameter from a resulting sample? > For instance, if two result sample sets are given, how can we be sure that > they can be compared? > [sunwq] > My understanding of the sample is that it is a sequence of singleton > values > obtained under a set of parameters. The parameters, such as Lambda_m, are > not visible in the sample. However, when reporting the sample, the > parameters must also be reported. > > [RS9a] > OK. Noted and understood. [sunwq] Great, thanks. > > > [RS10] > A superposition of two different Poisson processes is being used here. > How do you map the resulting RESV messages to the correct process, i.e. > how > to differentiate e.g. a late RESV message resulting from third PATH > message > in fourth invocation from an early RESV message solicited by first PATH > message in fourth invocation? > [sunwq] > RESV messages can be differentiated by either MSG ID or non-overlapping > LSP > ID, or combined. The RSVP-TE protocol does that automatically. So I > believe > this is an RSVP-TE implementation issue, rather than a testing methodology > issue. > > [RS10a] > OK. Noted and understood. [sunwq] Great, thanks. > > [RS11] > ???? > [sunwq] > Well, the full text is like: "The percentile of Metric is defined as: > given > a metric and a percent X between 0% and 100%, the Xth percentile of all > the > dT values in the sample." Would it help a bit if sentence is replaced by > the > > full text above? > Please be noted that this text is inherited from the IPPM docs (See RFC > 2681, page 16, 4.1). > > [RS11a] > The way it was written in the doc it was just a fragment of a sentence. > Unfortunately RFC 2681, page 16, 4.1. also does not give a proper > definition, as it too is just a fragmented sentence. > RFC 2330, p.26, 11.3 gives a better explanation, as: > "We will use the term 'percentile' to refer to the smallest value of x for > which the empirical distribution function is greater or equal a given > percentage" [sunwq] Well, to tell the truth I was troubled by this too. Later I realized that one reason that might lead to such a definition is that the authors of 2681 had assumed that ``percentile" is a ``well known" term, and does not inheriting its definition from RFC 2330. And quite surprisingly wikipedia says "there is no standard definition of percentile." But wikipedia also says ``however all definitions yield similar results when the number of observations is large." I will replace the original example with the following to avoid such a dilemma (of conflicting calculations in two RFCs). ============original text=============== Example: suppose we take a sample and the results are: Stream1 = < , , , , > Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110 and 500 msec are larger (undefined values are not counted in). ============end of original text======== ============new text=============== Example: suppose we take a sample and the results are: Stream1 = < , , , , , > Then the 60th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110, 350 and 500 msec are larger (undefined values are not counted in). A more detailed definition of percentile may be found in RFC 2330. ============end of new text======== > [RS12] > As stipulated in RFC2330 the EDF is defined as a function F(x) which for > any > > x gives the fractional proportion of the total measurements that were <= > x. > (see RFC2330 11.3 p26) > Hence F(90)=0.25, F(100)=0.5,F(110)=0.75, F(500)=1 and therefore the 50th > percentile is defined as 100 as opposed to 110. > [sunwq] > Yes you are right with regard to RFC 2330. But we have used exactly the > same > > example as in RFC 2681 (page 16, section 4.1). The good thing is that the > difference of the two calculations is very small when the number of > measurement is large. Change needed? > > [RS12a] > As outlined above RFC 2330 as opposed to RFC2681 gives a proper definition > of percentile. Therefore we should stick to RFC2330 and change > accordingly. > > It should be noted though, that also RFC2330 defines percentile > differently > than it is done in the statistical literature, but we can live with this, > as > it makes the definition easier to apply to measurement samples. Good point, thanks for explaining. I hope the change above is satisfactory for you. Thanks and best regards, Weiqiang > > [------------------End of new comments---------------------] > > > And I realized that the points you have raised covered the main part of > the > text. We would expect your further comments regarding our responses. > Otherwise we will assume that you are happy with it and will proceed to > change the text based on the revision you sent in your previous email :) > > Thank you again for your time in reviewing the draft so carefully. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Rschrage" > Sent: Wednesday, August 19, 2009 9:57 PM > To: "'Weiqiang Sun'" ; "'Lou Berger'" ; > "'Henk Uijterwaal'" > Cc: ; ; "'IETF IPPM WG'" > > Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] > >> Hi all, >> >> pls find attached a further updated edition of previous revised doc >> draft-ietf-ccamp-lsp-dppm-06. >> >> I believe this is as far as we can go for the moment before a mutual >> satisfactory understanding has been reached and a new draft has been >> issued >> by the authors. >> >> Again, pls feel free to comment. >> >> Many thanks. >> Brgds. >> Reinhard Schrage >> Tel: +49 (0) 5137 909540 >> Mobile: +49 (0) 172 26.36.046 >> reinhard@schrageconsult.com >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Weiqiang Sun >> Sent: Mittwoch, 19. August 2009 09:28 >> To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' >> Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, >> ATTLABS'; 'IETF IPPM WG' >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >> More responses below: >> >> RS4. >> Should be more specific as to why this metric is no simple function of >> single uni-directional LSP Setup Delay metric, i.e. why can it not be >> deduced from single LSP Setup Delay? >> [sunwq] >> This point is raised regarding the sentence "The time needed to setup a >> large number of LSPs during a short time period can not be deduced by >> single >> >> LSP setup delay." >> One reason is that when a large number of LSPs in being setup during a >> short >> >> period of time, the control plane may be crowded or even overwhelmed by >> the >> large number of signaling and routing messages. This may significantly >> slow >> down the processing of a particular signaling message, which will results >> in >> >> longer LSP provisioning delays. >> Are you suggesting that we add similar explanations to the document? We'd >> love to do that if you feel it is necessary. >> >> RS5. >> The current definition only addresses multiple uni-directional LSP setups >> between two nodes ID0 and ID1. What about the the case when ID0 is to >> setup >> multiple uni-directional LSP setups to different egress nodes ID1, ID2, >> ID3,.,IDN? >> [sunwq] >> Yes, it is a useful case. Likewise you would expect a case to establish a >> varied number of (instead of one) LSPs to a set of destinations. Our >> suggestion is that this case is approached by integrating the defined >> methodologies of single/multiple LSPs provisioning delay, in the form of >> a >> particular testing case, rather than a formal testing methodology. This >> is >> in fact a trade-off between complexity and accuracy. >> >> Best regards, >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Weiqiang Sun" >> Sent: Wednesday, August 19, 2009 2:48 PM >> To: "Rschrage" ; "'Lou Berger'" >> ; "'Henk Uijterwaal'" >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; "'IETF IPPM WG'" ; >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >>> Hi Reinhard, >>> >>> Many thanks for doing the careful review. We appreciate your many >>> wording >>> suggestions. We will go through these one by one and adopt those we feel >>> appropriate. In this email I will not list all the comments since these >>> will not lead to major technical changes. >>> >>> Below I try to respond to the points you raised in the revision. >>> >>> RS1. >>> This would imply that the metric may produce a range of several values >>> at >>> one time with the minimum value to be taken from that range. >>> I believe what the authors are trying to say is, that the LSP Setup >>> Delay >>> Metric provides a lower bound on all possible LSP Delay Metrics of >>> actually instantiated LSPs, or in other words: an actual LSP Delay >>> Metric >>> cannot get smaller than an LSP Setup Delay Metric. >>> [sunwq] >>> This point is raised regarding the motivation of the sigleton definition >>> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are >>> trying >> >>> to say that the minimum value of this metric reflects the (likely) >>> single >>> lsp setup delay when the control plane is lightly loaded. The formal >>> definition of the minimum value is in "14.1 The minimum of metric" >>> In fact we have inherited this from the IPPM documents (see RFC 2681, >>> page >> >>> 2 section 1.1 bullet 3). >>> >>> RS2. >>> How? Should there be a methodology be defined for this? >>> [sunwq] >>> This point is raised regarding the sentense in our methodologies >>> sections - "Make sure that the network has enough resource to set up the >>> requested LSP." >>> We have assumed that test personnel should have adequate expertise in >>> allocating enough resources for the testing. The allocation of resources >>> for the testing purpose can be very test specific and we believe it is >>> quite outside the scope of this document. >>> >>> RS3. >>> Too vague? As both timestamps are to be taken on the same ingress node, >>> they should be taken at the same application/network level. >>> [sunwq] >>> This point is raised regarding the sentense "If the corresponding RESV >>> message arrives within a reasonable period of time, take the timestamp >>> (T2) as soon as possible upon receipt of the message." >>> Yes, ideally the timestamp should be taken immediately after the >>> reception >> >>> of the RESV message. The wording "as soon as possible" is used to allow >>> for some flexibility when RESV message needs to be propagated to certain >>> modules where timestamp-taking is most appropriate. >>> And again, this text is inherited from the IPPM documents (see RFC 2681 >>> page 7, bullet 3). >>> >>> Thanks again and looking forward to your further comments and revisions. >>> >>> Weiqiang >>> >>> -- >>> Weiqiang Sun >>> Shanghai Jiao Tong University >>> http://front.sjtu.edu.cn/~sunwq/ >>> >>> -------------------------------------------------- >>> From: "Rschrage" >>> Sent: Tuesday, August 18, 2009 8:23 PM >>> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >>> >>> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >>> ; ; "'IETF IPPM WG'" ; >>> >>> Subject: RE: [ippm] [Fwd: IPPM expert review request] >>> >>>> Hello, >>>> >>>> sorry for late response- >>>> >>>> Nevertheless here is a first edition of my revision of doc >>>> draft-ietf-ccamp-lsp-dppm-06. >>>> >>>> The doc has been saved in Word 2003 format to easily track changes. >>>> I am using Kaspersky Anti Virus 2010 software so I trust there should >>>> be >>>> no >>>> unpleasant surprises when downloading the attached word doc. >>>> >>>> >>>> I thought it would be advisable to first address the suggested comments >>>> and >>>> questions upto and including the uni-directional LSP setup delay metric >>>> and >>>> after that to continue with the bi-directional and sample definitions >>>> as >>>> covered in the doc. >>>> >>>> Please let me have your thoughts on this. >>>> >>>> Many thanks. >>>> Reinhard Schrage >>>> Tel: +49 (0) 5137 909540 >>>> Mobile: +49 (0) 172 26.36.046 >>>> reinhard@schrageconsult.com >>>> >>>> -----Original Message----- >>>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>>> Lou >>>> Berger >>>> Sent: Dienstag, 28. Juli 2009 14:59 >>>> To: Henk Uijterwaal >>>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>>> sunwq@mit.edu; IETF IPPM WG >>>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>>> >>>> Hank/Reinhard, >>>> >>>> Thank you very much for undertaking this review. Please cc >>>> ccamp@ietf.org on any comments you may have. >>>> >>>> Lou >>>> >>>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>>> Lou, others, >>>>> >>>>>> We received the request for a review of a document currently under >>>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>>> has time to do this review in the near future? >>>>> >>>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>>> this. >>>>> >>>>> Reinhard: please post anything you find to both the list and the >>>>> authors. >>>>> And thank you for doing this. >>>>> >>>>> Henk >>>>> >>>>>> >>>>>> Matt & Henk >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: IPPM expert review request >>>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>>> From: Lou Berger >>>>>> To: ippm-chairs@tools.ietf.org >>>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>>> zhangguoying >>>>>> >>>>>> Hi, >>>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>>> review >>>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>>> available at: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>>> >>>>>> Is this acceptable? Can you undertake this review? Alternatively, >>>>>> we >>>>>> can just last call the document in your WG (it has already passed >>>>>> CCAMP >>>>>> WG LC). >>>>>> >>>>>> Thank you, >>>>>> Lou (and Deborah) >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > > > >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > From sunwq@MIT.EDU Wed Aug 26 23:26:13 2009 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 10E7928C130; Wed, 26 Aug 2009 23:26:13 -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=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 hlHWMtSMHljB; Wed, 26 Aug 2009 23:26:12 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id C4FEA28C114; Wed, 26 Aug 2009 23:26:12 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7R6QH83023861; Thu, 27 Aug 2009 02:26:17 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7R6QAoR015983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 27 Aug 2009 02:26:13 -0400 (EDT) Message-ID: <1B6858BC083442DE896FA785BC5BD5AE@mit.edu> From: "Weiqiang Sun" To: "Rschrage" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <000c01ca20d5$03aeca30$0b0c5e90$@net> <002601ca265e$89ef67b0$9dce3710$@net> In-Reply-To: <002601ca265e$89ef67b0$9dce3710$@net> Date: Thu, 27 Aug 2009 14:26:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 27 Aug 2009 06:26:13 -0000 Hi Reinhard, Thanks for responding. Please see inline. > > Thanks for sending this part. See below for my responses. > > [RS7] > Is there any help or suggestion on how to actually compute a usable > Lambda_m? > [sunwq] > No. Depending on the performance of the implementation, the lambda_m can > be > very different, even under the same topology. A proper value of Lambda_m > can > only be tuned in the testing. > > [RS7a] > I am a bit at loss here. > > It was my understanding that you use a metric to measure certain network > quantities, e.g. throughput, set up delays, etc. > In a second step you'd use these measured metrics to determine whether the > systems under test meet your previously expected or defined quality > parameters. If not, you'd make changes to the components or network > design, > measure again, and compare the previous set of data to the one after the > change and see whether you have improved and are moving into the right > direction. > > You seem to be coming from the other end, i.e. tweak the input parameters > to > suit your system under test. [sunwq] OK, I get your point here. What you said is true. I had thought by saying ``a usable lambda_m", you are saying that a lambda_m that is *best achievable* by the DUT/SUT. If you are expecting certain performance from the DUT/SUT, then very likely you will have in mind an "expected" lambda_m, won't you? The methodology here does not suggest how to select lambda_m. This in fact can provide flexibility. Either the test will use an expected lambda_m, or tune the lambda_m that reflects the best system performance, depending on the purpose of the test. Does this make sense? > > [RS8] > How to compare metrics that have been generated by two different Poisson > processes, i.e. e.g. two different arrival rates? > [sunwq] > No way. Do we need to do that anyway? > > [RS8a] > Pls also see my comments above. > If you cannot compare two sets of measurements how will you then arrive at > an objective study of the network components under test? [sunwq] Maybe I misunderstood you again here. The Poisson arrival rate is an approximation of real traffic load. Of course it is worthwhile to find out how DUT/SUT performs when traffic load changes. But what else do you expect by comparing two data sets from different traffic load? Did I miss something here? > > > [RS9] > These sample tuples are dependent on the arrival rate Lambda_m. How to > deduct this input parameter from a resulting sample? > For instance, if two result sample sets are given, how can we be sure that > they can be compared? > [sunwq] > My understanding of the sample is that it is a sequence of singleton > values > obtained under a set of parameters. The parameters, such as Lambda_m, are > not visible in the sample. However, when reporting the sample, the > parameters must also be reported. > > [RS9a] > OK. Noted and understood. [sunwq] Great, thanks. > > > [RS10] > A superposition of two different Poisson processes is being used here. > How do you map the resulting RESV messages to the correct process, i.e. > how > to differentiate e.g. a late RESV message resulting from third PATH > message > in fourth invocation from an early RESV message solicited by first PATH > message in fourth invocation? > [sunwq] > RESV messages can be differentiated by either MSG ID or non-overlapping > LSP > ID, or combined. The RSVP-TE protocol does that automatically. So I > believe > this is an RSVP-TE implementation issue, rather than a testing methodology > issue. > > [RS10a] > OK. Noted and understood. [sunwq] Great, thanks. > > [RS11] > ???? > [sunwq] > Well, the full text is like: "The percentile of Metric is defined as: > given > a metric and a percent X between 0% and 100%, the Xth percentile of all > the > dT values in the sample." Would it help a bit if sentence is replaced by > the > > full text above? > Please be noted that this text is inherited from the IPPM docs (See RFC > 2681, page 16, 4.1). > > [RS11a] > The way it was written in the doc it was just a fragment of a sentence. > Unfortunately RFC 2681, page 16, 4.1. also does not give a proper > definition, as it too is just a fragmented sentence. > RFC 2330, p.26, 11.3 gives a better explanation, as: > "We will use the term 'percentile' to refer to the smallest value of x for > which the empirical distribution function is greater or equal a given > percentage" [sunwq] Well, to tell the truth I was troubled by this too. Later I realized that one reason that might lead to such a definition is that the authors of 2681 had assumed that ``percentile" is a ``well known" term, and does not inheriting its definition from RFC 2330. And quite surprisingly wikipedia says "there is no standard definition of percentile." But wikipedia also says ``however all definitions yield similar results when the number of observations is large." I will replace the original example with the following to avoid such a dilemma (of conflicting calculations in two RFCs). ============original text=============== Example: suppose we take a sample and the results are: Stream1 = < , , , , > Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110 and 500 msec are larger (undefined values are not counted in). ============end of original text======== ============new text=============== Example: suppose we take a sample and the results are: Stream1 = < , , , , , > Then the 60th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110, 350 and 500 msec are larger (undefined values are not counted in). A more detailed definition of percentile may be found in RFC 2330. ============end of new text======== > [RS12] > As stipulated in RFC2330 the EDF is defined as a function F(x) which for > any > > x gives the fractional proportion of the total measurements that were <= > x. > (see RFC2330 11.3 p26) > Hence F(90)=0.25, F(100)=0.5,F(110)=0.75, F(500)=1 and therefore the 50th > percentile is defined as 100 as opposed to 110. > [sunwq] > Yes you are right with regard to RFC 2330. But we have used exactly the > same > > example as in RFC 2681 (page 16, section 4.1). The good thing is that the > difference of the two calculations is very small when the number of > measurement is large. Change needed? > > [RS12a] > As outlined above RFC 2330 as opposed to RFC2681 gives a proper definition > of percentile. Therefore we should stick to RFC2330 and change > accordingly. > > It should be noted though, that also RFC2330 defines percentile > differently > than it is done in the statistical literature, but we can live with this, > as > it makes the definition easier to apply to measurement samples. Good point, thanks for explaining. I hope the change above is satisfactory for you. Thanks and best regards, Weiqiang > > [------------------End of new comments---------------------] > > > And I realized that the points you have raised covered the main part of > the > text. We would expect your further comments regarding our responses. > Otherwise we will assume that you are happy with it and will proceed to > change the text based on the revision you sent in your previous email :) > > Thank you again for your time in reviewing the draft so carefully. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Rschrage" > Sent: Wednesday, August 19, 2009 9:57 PM > To: "'Weiqiang Sun'" ; "'Lou Berger'" ; > "'Henk Uijterwaal'" > Cc: ; ; "'IETF IPPM WG'" > > Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] > >> Hi all, >> >> pls find attached a further updated edition of previous revised doc >> draft-ietf-ccamp-lsp-dppm-06. >> >> I believe this is as far as we can go for the moment before a mutual >> satisfactory understanding has been reached and a new draft has been >> issued >> by the authors. >> >> Again, pls feel free to comment. >> >> Many thanks. >> Brgds. >> Reinhard Schrage >> Tel: +49 (0) 5137 909540 >> Mobile: +49 (0) 172 26.36.046 >> reinhard@schrageconsult.com >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Weiqiang Sun >> Sent: Mittwoch, 19. August 2009 09:28 >> To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' >> Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, >> ATTLABS'; 'IETF IPPM WG' >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >> More responses below: >> >> RS4. >> Should be more specific as to why this metric is no simple function of >> single uni-directional LSP Setup Delay metric, i.e. why can it not be >> deduced from single LSP Setup Delay? >> [sunwq] >> This point is raised regarding the sentence "The time needed to setup a >> large number of LSPs during a short time period can not be deduced by >> single >> >> LSP setup delay." >> One reason is that when a large number of LSPs in being setup during a >> short >> >> period of time, the control plane may be crowded or even overwhelmed by >> the >> large number of signaling and routing messages. This may significantly >> slow >> down the processing of a particular signaling message, which will results >> in >> >> longer LSP provisioning delays. >> Are you suggesting that we add similar explanations to the document? We'd >> love to do that if you feel it is necessary. >> >> RS5. >> The current definition only addresses multiple uni-directional LSP setups >> between two nodes ID0 and ID1. What about the the case when ID0 is to >> setup >> multiple uni-directional LSP setups to different egress nodes ID1, ID2, >> ID3,.,IDN? >> [sunwq] >> Yes, it is a useful case. Likewise you would expect a case to establish a >> varied number of (instead of one) LSPs to a set of destinations. Our >> suggestion is that this case is approached by integrating the defined >> methodologies of single/multiple LSPs provisioning delay, in the form of >> a >> particular testing case, rather than a formal testing methodology. This >> is >> in fact a trade-off between complexity and accuracy. >> >> Best regards, >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Weiqiang Sun" >> Sent: Wednesday, August 19, 2009 2:48 PM >> To: "Rschrage" ; "'Lou Berger'" >> ; "'Henk Uijterwaal'" >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; "'IETF IPPM WG'" ; >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >>> Hi Reinhard, >>> >>> Many thanks for doing the careful review. We appreciate your many >>> wording >>> suggestions. We will go through these one by one and adopt those we feel >>> appropriate. In this email I will not list all the comments since these >>> will not lead to major technical changes. >>> >>> Below I try to respond to the points you raised in the revision. >>> >>> RS1. >>> This would imply that the metric may produce a range of several values >>> at >>> one time with the minimum value to be taken from that range. >>> I believe what the authors are trying to say is, that the LSP Setup >>> Delay >>> Metric provides a lower bound on all possible LSP Delay Metrics of >>> actually instantiated LSPs, or in other words: an actual LSP Delay >>> Metric >>> cannot get smaller than an LSP Setup Delay Metric. >>> [sunwq] >>> This point is raised regarding the motivation of the sigleton definition >>> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are >>> trying >> >>> to say that the minimum value of this metric reflects the (likely) >>> single >>> lsp setup delay when the control plane is lightly loaded. The formal >>> definition of the minimum value is in "14.1 The minimum of metric" >>> In fact we have inherited this from the IPPM documents (see RFC 2681, >>> page >> >>> 2 section 1.1 bullet 3). >>> >>> RS2. >>> How? Should there be a methodology be defined for this? >>> [sunwq] >>> This point is raised regarding the sentense in our methodologies >>> sections - "Make sure that the network has enough resource to set up the >>> requested LSP." >>> We have assumed that test personnel should have adequate expertise in >>> allocating enough resources for the testing. The allocation of resources >>> for the testing purpose can be very test specific and we believe it is >>> quite outside the scope of this document. >>> >>> RS3. >>> Too vague? As both timestamps are to be taken on the same ingress node, >>> they should be taken at the same application/network level. >>> [sunwq] >>> This point is raised regarding the sentense "If the corresponding RESV >>> message arrives within a reasonable period of time, take the timestamp >>> (T2) as soon as possible upon receipt of the message." >>> Yes, ideally the timestamp should be taken immediately after the >>> reception >> >>> of the RESV message. The wording "as soon as possible" is used to allow >>> for some flexibility when RESV message needs to be propagated to certain >>> modules where timestamp-taking is most appropriate. >>> And again, this text is inherited from the IPPM documents (see RFC 2681 >>> page 7, bullet 3). >>> >>> Thanks again and looking forward to your further comments and revisions. >>> >>> Weiqiang >>> >>> -- >>> Weiqiang Sun >>> Shanghai Jiao Tong University >>> http://front.sjtu.edu.cn/~sunwq/ >>> >>> -------------------------------------------------- >>> From: "Rschrage" >>> Sent: Tuesday, August 18, 2009 8:23 PM >>> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >>> >>> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >>> ; ; "'IETF IPPM WG'" ; >>> >>> Subject: RE: [ippm] [Fwd: IPPM expert review request] >>> >>>> Hello, >>>> >>>> sorry for late response- >>>> >>>> Nevertheless here is a first edition of my revision of doc >>>> draft-ietf-ccamp-lsp-dppm-06. >>>> >>>> The doc has been saved in Word 2003 format to easily track changes. >>>> I am using Kaspersky Anti Virus 2010 software so I trust there should >>>> be >>>> no >>>> unpleasant surprises when downloading the attached word doc. >>>> >>>> >>>> I thought it would be advisable to first address the suggested comments >>>> and >>>> questions upto and including the uni-directional LSP setup delay metric >>>> and >>>> after that to continue with the bi-directional and sample definitions >>>> as >>>> covered in the doc. >>>> >>>> Please let me have your thoughts on this. >>>> >>>> Many thanks. >>>> Reinhard Schrage >>>> Tel: +49 (0) 5137 909540 >>>> Mobile: +49 (0) 172 26.36.046 >>>> reinhard@schrageconsult.com >>>> >>>> -----Original Message----- >>>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>>> Lou >>>> Berger >>>> Sent: Dienstag, 28. Juli 2009 14:59 >>>> To: Henk Uijterwaal >>>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>>> sunwq@mit.edu; IETF IPPM WG >>>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>>> >>>> Hank/Reinhard, >>>> >>>> Thank you very much for undertaking this review. Please cc >>>> ccamp@ietf.org on any comments you may have. >>>> >>>> Lou >>>> >>>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>>> Lou, others, >>>>> >>>>>> We received the request for a review of a document currently under >>>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>>> has time to do this review in the near future? >>>>> >>>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>>> this. >>>>> >>>>> Reinhard: please post anything you find to both the list and the >>>>> authors. >>>>> And thank you for doing this. >>>>> >>>>> Henk >>>>> >>>>>> >>>>>> Matt & Henk >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: IPPM expert review request >>>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>>> From: Lou Berger >>>>>> To: ippm-chairs@tools.ietf.org >>>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>>> zhangguoying >>>>>> >>>>>> Hi, >>>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>>> review >>>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>>> available at: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>>> >>>>>> Is this acceptable? Can you undertake this review? Alternatively, >>>>>> we >>>>>> can just last call the document in your WG (it has already passed >>>>>> CCAMP >>>>>> WG LC). >>>>>> >>>>>> Thank you, >>>>>> Lou (and Deborah) >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > > > >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > From loa@pi.nu Thu Aug 27 06:01:48 2009 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 16CAE28C418; Thu, 27 Aug 2009 06:01:48 -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=[AWL=0.000, 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 vCrWgTsL7eoJ; Thu, 27 Aug 2009 06:01:47 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 44E703A6C2D; Thu, 27 Aug 2009 06:01:47 -0700 (PDT) Received: from [192.36.158.118] (wdhcp-158-118.verkstad.net [192.36.158.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id D192BD4048; Thu, 27 Aug 2009 15:01:51 +0200 (CEST) Message-ID: <4A9683BB.5060201@pi.nu> Date: Thu, 27 Aug 2009 15:01:47 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, 'MPLS-TP ad hoc' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] working group last call on draft-ietf-mpls-tp-gach-dcn-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: Thu, 27 Aug 2009 13:01:48 -0000 All, this is to start a working group last call on draft-ietf-mpls-tp-gach-dcn-05.txt Please send your comments to the mpls-tp@ietf.org mailing list, i.e. do not simply "reply all" to this mail, but make sure it is directed to the correct mailing list. The working group last call en Sep 12, 2009. /Loa -- 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 lberger@labn.net Thu Aug 27 06:57:07 2009 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 D09DE3A6E0C for ; Thu, 27 Aug 2009 06:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BIZ=0.288, 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 JY040CR2jHmD for ; Thu, 27 Aug 2009 06:57:07 -0700 (PDT) Received: from dragon2.webhostserver.biz (dragon2.webhostserver.biz [67.228.160.67]) by core3.amsl.com (Postfix) with ESMTP id E5C4A3A699A for ; Thu, 27 Aug 2009 06:57:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:46910) by dragon2.webhostserver.biz with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MgfTU-0007zR-5l; Thu, 27 Aug 2009 08:57:12 -0500 Message-ID: <4A9690BB.3060704@labn.net> Date: Thu, 27 Aug 2009 09:57:15 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dragon2.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Subject: [CCAMP] [Fwd: Re: Fw: New Version Notification for draft-ietf-ccamp-lsp-dppm-07] 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, 27 Aug 2009 13:57:07 -0000 Looks like the LabN and IETF servers have decided to not talk to each other, so this message didn't make it to the list. Lou -------- Original Message -------- Subject: Re: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-lsp-dppm-07 Date: Wed, 26 Aug 2009 09:08:00 -0400 From: Lou Berger To: Weiqiang Sun CC: ccamp@ietf.org, IPPM WG IETF , Henk Uijterwaal , Rschrage Weiqiang, Thank you for the quick update! I believe Reinhard thought he might have some additional comments. Reinhard, Thank you again for your expert review. Can you confirm if the document has been fully reviewed? If it is not, can you give an estimate on how long you need to complete the review? Much thanks, Lou On 8/25/2009 10:16 PM, Weiqiang Sun wrote: > Hi all, > > Thanks to Reinhard Schrage, we now have a better version of the DPPM > draft uploaded. > In this revision, no technical changes are made. > > And, as per Tom's comments, we have droped the following two sentenses. > - They can also be used in operational networks for carriers to monitor > the control plane performance in realtime. > > - On the other hand, it can also be used in operational environments for > carriers to monitor the control plane operation in real-time. For > example, a new object can be added to GMPLS TE STD MIB [RFC4802] so > that the current and past control plane performance can be monitored > through network management systems. The extension of TE-MIB to > support the defined metrics is outside the scope of this document. > > As the document has passed WGLC, we would like to pass it back to the > hands of our chairs > for further processing. > > Thanks and best regards, > Weiqiang > > -------------------------------------------------- > From: "IETF I-D Submission Tool" > Sent: Wednesday, August 26, 2009 10:04 AM > Subject: New Version Notification for draft-ietf-ccamp-lsp-dppm-07 > >> >> A new version of I-D, draft-ietf-ccamp-lsp-dppm-07.txt has been >> successfuly submitted by Weiqiang Sun and posted to the IETF repository. >> >> Filename: draft-ietf-ccamp-lsp-dppm >> Revision: 07 >> Title: Label Switched Path (LSP) Dynamic Provisioning Performance >> Metrics in Generalized MPLS Networks >> Creation_date: 2009-08-26 >> WG ID: ccamp >> Number_of_pages: 49 >> >> Abstract: >> Generalized Multi-Protocol Label Switching (GMPLS) is one of the most >> promising candidate technologies for future data transmission >> network. GMPLS has been developed to control and operate different >> kinds of network elements, such as conventional routers, switches, >> Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop >> Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- >> connects (OXCs), etc. Dynamic provisioning ability of these >> physically diverse devices differs from each other drastically. At >> the same time, the need for dynamically provisioned connections is >> increasing because optical networks are being deployed in metro >> areas. As different applications have varied requirements in the >> provisioning performance of optical networks, it is imperative to >> define standardized metrics and procedures such that the performance >> of networks and application needs can be mapped to each other. >> >> This document provides a series of performance metrics to evaluate >> the dynamic LSP provisioning performance in GMPLS networks, >> specifically the dynamic LSP setup/release performance. These >> metrics can depict the features of GMPLS networks in LSP dynamic >> provisioning. >> >> >> >> The IETF Secretariat. >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From web-usrn@ISI.EDU Thu Aug 27 11:49:57 2009 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 B41673A70DD for ; Thu, 27 Aug 2009 11:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.762 X-Spam-Level: X-Spam-Status: No, score=-16.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 TBe1BCgDPXha for ; Thu, 27 Aug 2009 11:49:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id DAD6B3A6B93 for ; Thu, 27 Aug 2009 11:49:56 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7RImjIk006036; Thu, 27 Aug 2009 11:48:46 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n7RImiJK006025; Thu, 27 Aug 2009 11:48:44 -0700 (PDT) Date: Thu, 27 Aug 2009 11:48:44 -0700 (PDT) Message-Id: <200908271848.n7RImiJK006025@boreas.isi.edu> To: tnadeau@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ccamp@ietf.org, girishm@ipinfusion.com, rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC4803 (1841) 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, 27 Aug 2009 18:49:57 -0000 The following errata report has been submitted for RFC4803, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=1841 -------------------------------------- Type: Technical Reported by: Girish Mahanta Section: Section 7 Original Text ------------- gmplsOutSegmentTTLDecrement OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the amount by which to decrement the Time to Live (TTL) of any payload packets forwarded on this segment if per-hop decrementing is being done. A value of zero indicates that no decrement should be made or that per-hop decrementing is not in use. See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable of GMPLS-TE-STD-MIB for a value by which to decrement the TTL for the whole of a tunnel. This object cannot be modified if mplsOutSegmentRowStatus for the associated entry in the mplsOutSegmentTable is active(1)." REFERENCE "1. Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks, RFC 3443. 2. Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base, RFC 4802." DEFVAL { 0 } ::= { gmplsOutSegmentEntry 2 } Corrected Text -------------- gmplsOutSegmentTTLDecrement OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the amount by which to decrement the Time to Live (TTL) of any payload packets forwarded on this segment if per-hop decrementing is being done. A value of zero indicates that no decrement should be made or that per-hop decrementing is not in use. This object cannot be modified if mplsOutSegmentRowStatus for the associated entry in the mplsOutSegmentTable is active(1)." REFERENCE "1. Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks, RFC 3443." DEFVAL { 0 } ::= { gmplsOutSegmentEntry 2 } Notes ----- In gmplsOutSegmentTable for the object gmplsOutSegmentTTLDecrement there is no gmplsTunnelTTLDecrement object in the gmplsTunnelTable of GMPLS-TE-STD-MIB which is referenced. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) -------------------------------------- Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Publication Date : February 2007 Author(s) : T. Nadeau, Ed., A. Farrel, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From lberger@labn.net Thu Aug 27 12:31:34 2009 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 207C628C67C for ; Thu, 27 Aug 2009 12:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_40=-0.185, 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 413KNEAVCMDd for ; Thu, 27 Aug 2009 12:31:33 -0700 (PDT) Received: from outbound-mail-17.bluehost.com (outbound-mail-17.bluehost.com [69.89.20.232]) by core3.amsl.com (Postfix) with SMTP id 3BCE228C599 for ; Thu, 27 Aug 2009 12:31:33 -0700 (PDT) Received: (qmail 21863 invoked by uid 0); 27 Aug 2009 19:31:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 27 Aug 2009 19:31:40 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=W0h9fkMscq98225wOqybfuUO75aG8HMcfIHgB5SI38ILN0pr1vF6f8vKEF8KTEzBGw11225XLVLDwpGGDTdildbzs/7LdRKPbWJnmVUKIucpMm8PS5SXmztvRd6iSiLW; 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 1Mgkh1-0003n7-TF; Thu, 27 Aug 2009 13:31:32 -0600 Message-ID: <4A96DF17.2010800@labn.net> Date: Thu, 27 Aug 2009 15:31:35 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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] please ignore 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, 27 Aug 2009 19:31:34 -0000 A test message, please ignore. Thanks & my apologies. From ma-miyazawa@kddilabs.jp Fri Aug 28 03:40:47 2009 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 DB7AB3A6B4F for ; Fri, 28 Aug 2009 03:40:47 -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 3ajPu8tLzs0k for ; Fri, 28 Aug 2009 03:40:46 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id E85A93A6CD9 for ; Fri, 28 Aug 2009 03:40:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5444AEC8FD; Fri, 28 Aug 2009 19:40:47 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id A9F3DEC868; Fri, 28 Aug 2009 19:40:44 +0900 (JST) Received: from miyazawaPC (dhcp224.east-2f.cn.kddilabs.jp [172.19.125.224]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id C0840578111; Fri, 28 Aug 2009 19:40:41 +0900 (JST) From: "Masanori Miyazawa" To: "'Joan Cucchiara'" , "'Tomohiro Otani'" , , References: <49F8E7CA.6010902@labn.net> <00c601c9ca3e$347d4da0$6501a8c0@JoanPC> <49FAD79A.2090805@labn.net> <015c01c9d22e$13963730$6501a8c0@JoanPC> <4A40C6DD.2000002@labn.net> <00a401c9f4ce$aa644c70$6501a8c0@JoanPC> <4A422E0C.7090906@labn.net> <01d401c9f662$a5437820$6501a8c0@JoanPC> In-Reply-To: <01d401c9f662$a5437820$6501a8c0@JoanPC> Date: Fri, 28 Aug 2009 19:40:42 +0900 Message-ID: <003901ca27cb$fdec8120$f9c58360$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn2Yl6IoWqjHTP+TJucpI1X2iwRKAxZ4bRw Content-Language: ja X-Virus-Scanned: by amavisd-new Cc: "'Romascanu, Dan \(Dan\)'" , ccamp@ietf.org Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-5.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, 28 Aug 2009 10:40:47 -0000 Hi Joan, Thank you for your comments. We had finished update and modification according to your comments. Please see our answer to your comments as below and let us know if you have any question. Regards, Masanori > MIB Compiler output: > ======================= > > E: f(TED-MIB.my), (460,4) Index item "teLocalIntAddrIndex" must be > defined with syntax that includes a range > E: f(TED-MIB.my), (518,49) Index item "teRemoteIntAddrIndex" must be > defined with syntax that includes a range > E: f(TED-MIB.my), (579,53) Index item "teSwCapIndex" must be defined > with syntax that includes a range > E: f(TED-MIB.my), (765,53) Index item "teSrlgIndex" must be defined > with syntax that includes a range *** We modified "SYNTAX" of index to "Unsigned32 (1..4294967295)". > Line Severity Problem > 109 5 warning: index element `teAreaId' of row `tedEntry' should be > not-accessible in SMIv2 MIB > 5 warning: index element `teRouterId' of row `tedEntry' should > be not-accessible in SMIv2 MIB > 5 warning: index element `teLinkStateId' of row `tedEntry' > should be not-accessible in SMIv2 MIB > 926 5 warning: current group `tedNotificationGroup' is not referenced > in this module ***Using smiLint, we got 4 errors, however these index objects are needed to set MAX-ACCESS to "read-only" because these objects are used for value of notification. > General Discussion > ------------------ > * In what GMPLS WG document is this functionality defined? ***This functionality of traffic engineering database (TED) is defined in RFC3630 (Traffic Engineering (TE) Extensions to OSPF Version 2). And also, supporting IS-IS and GMPLS technologies as well as OSPF, this MIB is defined in RFC4203(OSPF Extensions in Support of Generalized Multi-Protocol Label Switching), RFC3784(IS-IS extensions for Traffic Engineering) and RFC4205 (Intermediate System to Intermediate System (IS-IS) Extensions in Support of Multi-Protocol Label Switching (GMPLS). > * The names in this MIB are not prefixed consistently. > Please see Appendix C of RFC4181. > > For example, TED-MIB is the MIB's name, and then TedEntry, but the > objects in this table are prefixed by "te" (but "ted" > would > be more consistent.) > ***The name of objects in Ted Table was changed from "te" to "ted". And also, for ensuring consistency, we also changed the table name as well as object name in teLocalIfAddrTable and teRemoteIfAddrTable,teSwCapTable and teSrlgTable. "teLocalIfAddrTable" -> "tedLocalIfAddrTable" "teRemoteIfAddrTable" -> "tedRemoteIfAddrTable" "teSwCapTable" -> "tedSwCapTable" "teSrlgTable" -> "tedSrlgTable" > The abbreviation for interface is "int" but would prefer either "if" > or "intf". *** We modified the abbreviation for interface from "int" to "if". > * With the exception of 2 objects, the MIB consists of read-only objects. > While this is fine in and of itself, there are several places in the > text that the authors warn that if local configuration is done then > routing needs to be triggered so the new configuration gets dispersed. > When looking at these MIB tables, is there any way to tell if the > information is currently in use or not? > *** In this mib, when information is not in use or not configured, there is no reply from SNMP agent, conversely, when information is in use, there is reply. > Specific Comments (in order of document) > ------------------------------------------ > > * Table of Contents > > s/Author's Address/Authors' Addresses/ *** Revised > > * TOC is missing "Informative References" entry. > *** Revised > > * 2. Introduction > > NIT: > s/related with/related to/ > > * In what GMPLS WG document is the functionality of TED defined? > > 4. Motivations > > * Why is ISIS not mentioned here? *** We added ISIS in chapter 4. > > 6. Example of TED MIB module usage > s/module usage/Module Usage/ *** Revised > * Second paragraph "TE MIB" > s/TE MIB/TED MIB/ *** Revised > The second paragraph is confusing. The Tables reflect information as > read only, yet, this paragraph discusses changing this information > locally (e.g. on a router) and then triggering routing to update this > information. > *** Revised > The example given is confusing. What are the index values supposed to be? > > > MIB MODULE > ------------- > > * Please differentiate values as XXX or YYY for the rfc editor. > > * as suggested by Appendix D of RFC4181 (Guidelines for MIB Documents) > the oid layout should be: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > > This OID layout is: > - tedMIB > \-v-0 tedNotifications > |-1 tedObjects > \-2 tedConformance > \-v-1 tedGroups > \-2 tedCompliances > > Groups and Compliances should be reversed. *** Revised > * Additionally there are extraneous sub-ids of tedScalars and > tedTables under the tedObjects branch. > While many older MIBs separated scalars and tables this way, this is > not needed and while fine for the MIB as it exists currently, if this > MIB is added to in the future (e.g. if an enterprise MIB developer > wants to add objects via his/her own enterprise MIB Module), then > keeping the separation of scalars > and tables may be a hinderance. I would ask that you remove > these sub-ids (tedScalars and tedTables) so that the oidtree will look > like: > > |-1 tedObjects > | \-1 tedNotificationEnabled, TruthValue[SNMPv2-TC], rw, current > | \-2 tedNotificationMaxRate, Unsigned32, rw, current > \-3 tedTable > | \---1 tedEntry, INDEX{ teAreaId,teRouterId,teLinkStateId } > | \-v-1 teAreaId, Unsigned32(1..4294967295), ro, current *** Revised > * tedNotificationEnabled > > Why is this object needed? Please answer the question wrt rfc3413. > > * tedNotificationMaxRate > > This one throttling mechanism is used to control 3 different notifications. > This might be okay, but that depends on the notifications and as they > are written now, they seem to be overlapping. For example, if a TED > is created then are 2 notifications sent (one for StatusChange and one > for Creation) or just one (for Creation)? *** If a TE information is created( or deleted) in a node, only one notification (Creation trap or Deletion trap) is sent to client. On the other hand, if TE information is changed, StatuChange is sent. > * teLinkInformationData > > The DESCRIPTION mentions the "teLinkTable of TE-LINK-STD-MIB", could > you please tell me what draft or rfc this is? ***This MIB has been defined by RFC4220. We had forgotten to describe the reference of this MIB into reference section. We added it. > What about OSPFv3 and other protocols that may be related to this MIB > (at some point?) Are you sure that this object is going to be useful > (even in the > short-term?) *** For the meantime, we think that this mib is available to support IPv6 as well as IPV4 for supporting inet-address-mib. > * Notifications > > The descriptions are very unclear. Under what circumstances are these > generated? Please be specific. > *** revised > * Conformance statements are missing the restrictions for IpAddress > and IpAddressType objects in this MIB. > Please correct this > > * ReadOnly Compliance is incorrect. There are 2 writable objects > which need to be given read-only conformance. > *** Revised > * 8. Security consideration > > s/consideration/Considerations/ > > - The first paragraph states there aren't any read-write objects but > this is not accurate. Please update. > *** Revised ---------------------------------------------------------------------------- ------- -----Original Message----- From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] Sent: Friday, June 26, 2009 10:33 PM To: Tomohiro Otani; ma-miyazawa@kddilabs.jp; tnadeau@bt.com; ke-kumaki@kddilabs.jp Cc: Romascanu, Dan (Dan); Brungard, Deborah A, ALABS; Lou Berger; ccamp@ietf.org Subject: MIB Dr. review of draft-ietf-gmpls-ted-mib-5.txt Hello, Very interesting MIB! A good deal of thought went into this. Thanks for that! First, the MIB compiler output will be given. Followed by a general discussion and then specific comments given which are in order of the document. Thanks, -Joan MIB Compiler output: ======================= smicngPRO ---------- * (NIT) Unable to abstract MIB Module using mstrip tool. E: f(TED-MIB.my), (460,4) Index item "teLocalIntAddrIndex" must be defined with syntax that includes a range E: f(TED-MIB.my), (518,49) Index item "teRemoteIntAddrIndex" must be defined with syntax that includes a range E: f(TED-MIB.my), (579,53) Index item "teSwCapIndex" must be defined with syntax that includes a range E: f(TED-MIB.my), (765,53) Index item "teSrlgIndex" must be defined with syntax that includes a range W: f(TED-MIB.my), (797,9) Variable "teAreaId" in notification "tedTeInfoStatusChange" is an index for a table W: f(TED-MIB.my), (797,19) Variable "teRouterId" in notification "tedTeInfoStatusChange" is an index for a table W: f(TED-MIB.my), (797,31) Variable "teLinkStateId" in notification "tedTeInfoStatusChange" is an index for a table W: f(TED-MIB.my), (809,9) Variable "teAreaId" in notification "tedTeCreation" is an index for a table W: f(TED-MIB.my), (809,19) Variable "teRouterId" in notification "tedTeCreation" is an index for a table W: f(TED-MIB.my), (809,31) Variable "teLinkStateId" in notification "tedTeCreation" is an index for a table W: f(TED-MIB.my), (819,9) Variable "teAreaId" in notification "tedTeDeletion" is an index for a table W: f(TED-MIB.my), (819,19) Variable "teRouterId" in notification "tedTeDeletion" is an index for a table W: f(TED-MIB.my), (819,31) Variable "teLinkStateId" in notification "tedTeDeletion" is an index for a table W: f(TED-MIB.my), (926,7) NOTIFICATION-GROUP "tedNotificationGroup" is not used in a MODULE-COMPLIANCE in current module smiLint ------------ Validation report File: TED-MIB.my Severity level requested: 6 Line Severity Problem 109 5 warning: index element `teAreaId' of row `tedEntry' should be not-accessible in SMIv2 MIB 5 warning: index element `teRouterId' of row `tedEntry' should be not-accessible in SMIv2 MIB 5 warning: index element `teLinkStateId' of row `tedEntry' should be not-accessible in SMIv2 MIB 926 5 warning: current group `tedNotificationGroup' is not referenced in this module General Discussion ------------------ * As an fyi, the OSPFv3 MIB (for IPv6) is "IESG Evaluation". * In what GMPLS WG document is this functionality defined? I see a lot of MIBs referenced in MPLS, OSPF, ISIS and GMPLS and also a lot of documents being referenced, but not a specific TED one. * The MIB objects themselves do not have any REFERENCE clauses and most of these probably should given the nature of this MIB (i.e. that it is pulling from so many different documents.) Please be specific in your REFERENCE clauses such as document, section, and sub-section, if appropriate. * The names in this MIB are not prefixed consistently. Please see Appendix C of RFC4181. For example, TED-MIB is the MIB's name, and then TedEntry, but the objects in this table are prefixed by "te" (but "ted" would be more consistent.) - The abbreviation for interface is "int" but would prefer either "if" or "intf". * With the exception of 2 objects, the MIB consists of read-only objects. While this is fine in and of itself, there are several places in the text that the authors warn that if local configuration is done then routing needs to be triggered so the new configuration gets dispersed. When looking at these MIB tables, is there any way to tell if the information is currently in use or not? Specific Comments (in order of document) ------------------------------------------ * Table of Contents s/Author's Address/Authors' Addresses/ * TOC is missing "Informative References" entry. * 2. Introduction NIT: s/related with/related to/ * In what GMPLS WG document is the functionality of TED defined? 4. Motivations * Why is ISIS not mentioned here? 6. Example of TED MIB module usage s/module usage/Module Usage/ * Second paragraph "TE MIB" s/TE MIB/TED MIB/ The second paragraph is confusing. The Tables reflect information as read only, yet, this paragraph discusses changing this information locally (e.g. on a router) and then triggering routing to update this information. The example given is confusing. What are the index values supposed to be? MIB MODULE ------------- * Please differentiate values as XXX or YYY for the rfc editor. * as suggested by Appendix D of RFC4181 (Guidelines for MIB Documents) the oid layout should be: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) This OID layout is: - tedMIB \-v-0 tedNotifications |-1 tedObjects \-2 tedConformance \-v-1 tedGroups \-2 tedCompliances Groups and Compliances should be reversed. * Additionally there are extraneous sub-ids of tedScalars and tedTables under the tedObjects branch. While many older MIBs separated scalars and tables this way, this is not needed and while fine for the MIB as it exists currently, if this MIB is added to in the future (e.g. if an enterprise MIB developer wants to add objects via his/her own enterprise MIB Module), then keeping the separation of scalars and tables may be a hinderance. I would ask that you remove these sub-ids (tedScalars and tedTables) so that the oidtree will look like: |-1 tedObjects | \-1 tedNotificationEnabled, TruthValue[SNMPv2-TC], rw, current | \-2 tedNotificationMaxRate, Unsigned32, rw, current \-3 tedTable | \---1 tedEntry, INDEX{ teAreaId,teRouterId,teLinkStateId } | \-v-1 teAreaId, Unsigned32(1..4294967295), ro, current etc. * tedNotificationEnabled Why is this object needed? Please answer the question wrt rfc3413. * tedNotificationMaxRate This one throttling mechanism is used to control 3 different notifications. This might be okay, but that depends on the notifications and as they are written now, they seem to be overlapping. For example, if a TED is created then are 2 notifications sent (one ofr StatusChange and one for Creation) or just one (for Creation)? * teLinkInformationData The DESCRIPTION mentions the "teLinkTable of TE-LINK-STD-MIB", could you please tell me what draft or rfc this is? What about OSPFv3 and other protocols that may be related to this MIB (at some point?) Are you sure that this object is going to be useful (even in the short-term?) * Notifications The descriptions are very unclear. Under what circumstances are these generated? Please be specific. * Conformance statements are missing the restrictions for IpAddress and IpAddressType objects in this MIB. Please correct this. * ReadOnly Compliance is incorrect. There are 2 writable objects which need to be given read-only conformance. * 8. Security consideration s/consideration/Considerations/ - The first paragraph states there aren't any read-write objects but this is not accurate. Please update. From lberger@labn.net Fri Aug 28 10:57:04 2009 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 4C8373A6EF5 for ; Fri, 28 Aug 2009 10:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.260, 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 cTWW4S6UKwTK for ; Fri, 28 Aug 2009 10:57:03 -0700 (PDT) Received: from outbound-mail-160.bluehost.com (outbound-mail-160.bluehost.com [67.222.39.40]) by core3.amsl.com (Postfix) with SMTP id 476273A6BAB for ; Fri, 28 Aug 2009 10:57:03 -0700 (PDT) Received: (qmail 13679 invoked by uid 0); 28 Aug 2009 17:57:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 28 Aug 2009 17:57:10 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=OmyDD2UCC7UX0uOhyAMrTk7JBmn/Xe1Lvf3moNhMihzsGRePdQ9PkCnFcW3tXgWIioi8Ufd6xiyINaBHW9Wuo1lYRTb+3GLZ+rQwklznSfkP1LB+9ZHgTeUXUTjT0tKu; 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 1Mh5hF-0007QC-VB; Fri, 28 Aug 2009 11:57:10 -0600 Message-ID: <4A981A7A.20803@labn.net> Date: Fri, 28 Aug 2009 13:57:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: RFC Errata System References: <200906230946.n5N9k39P004172@boreas.isi.edu> <4A40C14D.8080003@labn.net> In-Reply-To: <4A40C14D.8080003@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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: dimitri.papadimitriou@alcatel-lucent.be, dmcw@dataconnection.com, ccamp@ietf.org, IBryskin@advaoptical.com, adrian.farrel@huawei.com, rcallon@juniper.net Subject: Re: [CCAMP] [Technical Errata Reported] RFC4873 (1797) 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, 28 Aug 2009 17:57:04 -0000 As discussed in Stockholm the resolution of this Errata is as follows: 1) The Errata should be Approved 2) That the following be added to Errata As reported in the Errata, the segment-recording-desired flag is unassigned. The flag is unassigned and therefore cannot be used. As agreed to on the CCAMP mail list and the Stockholm (IETF 75) working group meeting the the collection of SRROs SHOULD be controlled based on the presence of an RRO in the message being processed. That is, the segment-recording-desired flag should be considered to be set when an RRO is present in the message being processed. I'll work with our AD to confirm that this makes it into the Erata system. Lou I'll coordinate with our AD to get the needed updates into the Errata. On 6/23/2009 7:49 AM, Lou Berger wrote: > As a co-author, I concur that this Errata is valid and should be > verified. As mentioned in the errata, the CCAMP WG will discuss this > issue and may request that additional text be added to the errata. > > Lou > > On 6/23/2009 5:46 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC4873, >> "GMPLS Segment Recovery". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4873&eid=1797 >> >> -------------------------------------- >> Type: Technical >> Reported by: David McWalter >> >> Section: 5.2 >> >> Original Text >> ------------- >> The collection of SRROs is controlled via the >> segment-recording-desired flag in the SESSION_ATTRIBUTE object. This >> flag MAY be set even when SEROs are not used. >> >> Corrected Text >> -------------- >> >> >> Notes >> ----- >> No request was made to IANA to assign a value for the segment-recording-desired flag. >> >> Possible solutions are under discussion on the ccamp list (22 June 2009) >> http://www.ietf.org/mail-archive/web/ccamp/current/msg10205.html >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4873 (draft-ietf-ccamp-gmpls-segment-recovery-03) >> -------------------------------------- >> Title : GMPLS Segment Recovery >> Publication Date : May 2007 >> Author(s) : L. Berger, I. Bryskin, D. Papadimitriou, A. Farrel >> Category : PROPOSED STANDARD >> Source : Common Control and Measurement Plane >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From jcucchiara@mindspring.com Fri Aug 28 18:39:27 2009 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 5908D3A6A89 for ; Fri, 28 Aug 2009 18:39:27 -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, STOX_REPLY_TYPE=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 1fvMqllJMUKT for ; Fri, 28 Aug 2009 18:39:25 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 55D553A68C5 for ; Fri, 28 Aug 2009 18:39:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EKCtaUqNEVcZ+YZ9rEAIvAB9VONpNxfVjP0ahPWEaMnrOZpwZL8TjmAXE/35nhyI; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.111.34] (helo=JoanPC) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MhCuY-0004Di-Uw; Fri, 28 Aug 2009 21:39:24 -0400 Message-ID: <036f01ca2849$86e070e0$6501a8c0@JoanPC> From: "Joan Cucchiara" To: "Masanori Miyazawa" , "'Tomohiro Otani'" , , References: <49F8E7CA.6010902@labn.net> <00c601c9ca3e$347d4da0$6501a8c0@JoanPC> <49FAD79A.2090805@labn.net> <015c01c9d22e$13963730$6501a8c0@JoanPC> <4A40C6DD.2000002@labn.net> <00a401c9f4ce$aa644c70$6501a8c0@JoanPC> <4A422E0C.7090906@labn.net> <01d401c9f662$a5437820$6501a8c0@JoanPC> <003901ca27cb$fdec8120$f9c58360$@jp> Date: Fri, 28 Aug 2009 21:39:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654be4eb234f678662e06cfbac43cccb3777c7233ee4b332ceb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.111.34 Cc: "'Romascanu, Dan \(Dan\)'" , ccamp@ietf.org Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-5.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: Sat, 29 Aug 2009 01:39:27 -0000 Hi Masanori, Thank you for the quick turn around to this document. Please see inline below. Thanks, -Joan ----- Original Message ----- From: "Masanori Miyazawa" To: "'Joan Cucchiara'" ; "'Tomohiro Otani'" ; ; Cc: "'Romascanu, Dan (Dan)'" ; "'Brungard, Deborah A, ALABS'" ; "'Lou Berger'" ; Sent: Friday, August 28, 2009 6:40 AM Subject: RE: MIB Dr. review of draft-ietf-gmpls-ted-mib-5.txt > Hi Joan, > > Thank you for your comments. > We had finished update and modification according to your comments. > > Please see our answer to your comments as below and let us know if you > have > any question. > > Regards, > Masanori > >> MIB Compiler output: >> ======================= >> >> E: f(TED-MIB.my), (460,4) Index item "teLocalIntAddrIndex" must be >> defined with syntax that includes a range >> E: f(TED-MIB.my), (518,49) Index item "teRemoteIntAddrIndex" must be >> defined with syntax that includes a range >> E: f(TED-MIB.my), (579,53) Index item "teSwCapIndex" must be defined >> with syntax that includes a range >> E: f(TED-MIB.my), (765,53) Index item "teSrlgIndex" must be defined >> with syntax that includes a range > > *** We modified "SYNTAX" of index to "Unsigned32 (1..4294967295)". > >> Line Severity Problem >> 109 5 warning: index element `teAreaId' of row `tedEntry' should be >> not-accessible in SMIv2 MIB >> 5 warning: index element `teRouterId' of row `tedEntry' should >> be not-accessible in SMIv2 MIB >> 5 warning: index element `teLinkStateId' of row `tedEntry' >> should be not-accessible in SMIv2 MIB >> 926 5 warning: current group `tedNotificationGroup' is not referenced >> in this module > > ***Using smiLint, we got 4 errors, however these index objects are needed > to > set MAX-ACCESS to "read-only" because these objects are used for value of > notification. > >> General Discussion >> ------------------ > >> * In what GMPLS WG document is this functionality defined? > > ***This functionality of traffic engineering database (TED) is defined in > RFC3630 (Traffic Engineering (TE) Extensions to OSPF Version 2). And also, > supporting IS-IS and GMPLS technologies as well as OSPF, this MIB is > defined > in RFC4203(OSPF Extensions in Support of Generalized Multi-Protocol Label > Switching), RFC3784(IS-IS extensions for Traffic Engineering) and RFC4205 > (Intermediate System to Intermediate System (IS-IS) Extensions in Support > of > Multi-Protocol Label Switching (GMPLS). > This MIB has gone through a WG Last Call, so was this MIB reviewed by these different working groups also? > >> * The names in this MIB are not prefixed consistently. >> Please see Appendix C of RFC4181. >> >> For example, TED-MIB is the MIB's name, and then TedEntry, but the >> objects in this table are prefixed by "te" (but "ted" >> would >> be more consistent.) >> > > ***The name of objects in Ted Table was changed from "te" to "ted". And > also, for ensuring consistency, we also changed the table name as well as > object name in teLocalIfAddrTable and teRemoteIfAddrTable,teSwCapTable and > teSrlgTable. > > "teLocalIfAddrTable" -> "tedLocalIfAddrTable" > "teRemoteIfAddrTable" -> "tedRemoteIfAddrTable" > "teSwCapTable" -> "tedSwCapTable" > "teSrlgTable" -> "tedSrlgTable" > > >> The abbreviation for interface is "int" but would prefer either "if" >> or "intf". > > *** We modified the abbreviation for interface from "int" to "if". > > >> * With the exception of 2 objects, the MIB consists of read-only objects. >> While this is fine in and of itself, there are several places in the >> text that the authors warn that if local configuration is done then >> routing needs to be triggered so the new configuration gets dispersed. >> When looking at these MIB tables, is there any way to tell if the >> information is currently in use or not? >> > *** In this mib, when information is not in use or not configured, there > is > no reply from SNMP agent, conversely, when information is in use, there is > reply. > From the perspective of an SNMP Manager, when an SNMP Agent doesn't respond this could mean that the network failed, or that the router that received the request was too busy so dropped the SNMP request, etc. The SNMP Manager makes the assumption that the agent never saw the request, and so usually re-issues the request. The SNMP Manager is not able to deduce information about the MIB data. So some thought needs to be given as to how to indicate the "state" of the data. Could one (or more) object(s) be designed to indicate what the state of the data is? Thanks, -Joan > >> Specific Comments (in order of document) >> ------------------------------------------ >> >> * Table of Contents >> >> s/Author's Address/Authors' Addresses/ > > *** Revised > >> >> * TOC is missing "Informative References" entry. >> > *** Revised > >> >> * 2. Introduction >> >> NIT: >> s/related with/related to/ >> >> * In what GMPLS WG document is the functionality of TED defined? >> >> 4. Motivations >> >> * Why is ISIS not mentioned here? > > *** We added ISIS in chapter 4. > >> >> 6. Example of TED MIB module usage >> s/module usage/Module Usage/ > > *** Revised > >> * Second paragraph "TE MIB" >> s/TE MIB/TED MIB/ > > *** Revised > >> The second paragraph is confusing. The Tables reflect information as >> read only, yet, this paragraph discusses changing this information >> locally (e.g. on a router) and then triggering routing to update this >> information. >> > > *** Revised > >> The example given is confusing. What are the index values supposed to be? >> >> >> MIB MODULE >> ------------- >> >> * Please differentiate values as XXX or YYY for the rfc editor. >> >> * as suggested by Appendix D of RFC4181 (Guidelines for MIB Documents) >> the oid layout should be: >> >> xxxMIB >> | >> +-- xxxNotifications(0) >> +-- xxxObjects(1) >> +-- xxxConformance(2) >> | >> +-- xxxCompliances(1) >> +-- xxxGroups(2) >> >> >> This OID layout is: >> - tedMIB >> \-v-0 tedNotifications >> |-1 tedObjects >> \-2 tedConformance >> \-v-1 tedGroups >> \-2 tedCompliances >> >> Groups and Compliances should be reversed. > > *** Revised > > >> * Additionally there are extraneous sub-ids of tedScalars and >> tedTables under the tedObjects branch. >> While many older MIBs separated scalars and tables this way, this is >> not needed and while fine for the MIB as it exists currently, if this >> MIB is added to in the future (e.g. if an enterprise MIB developer >> wants to add objects via his/her own enterprise MIB Module), then >> keeping the separation of scalars >> and tables may be a hinderance. I would ask that you remove >> these sub-ids (tedScalars and tedTables) so that the oidtree will look >> like: >> >> |-1 tedObjects >> | \-1 tedNotificationEnabled, TruthValue[SNMPv2-TC], rw, current >> | \-2 tedNotificationMaxRate, Unsigned32, rw, current >> \-3 tedTable >> | \---1 tedEntry, INDEX{ teAreaId,teRouterId,teLinkStateId } >> | \-v-1 teAreaId, Unsigned32(1..4294967295), ro, current > > *** Revised > > >> * tedNotificationEnabled >> >> Why is this object needed? Please answer the question wrt rfc3413. >> >> * tedNotificationMaxRate >> >> This one throttling mechanism is used to control 3 different > notifications. >> This might be okay, but that depends on the notifications and as they >> are written now, they seem to be overlapping. For example, if a TED >> is created then are 2 notifications sent (one for StatusChange and one >> for Creation) or just one (for Creation)? > > *** If a TE information is created( or deleted) in a node, only one > notification (Creation trap or Deletion trap) is sent to client. On the > other hand, if TE information is changed, StatuChange is sent. > > >> * teLinkInformationData >> >> The DESCRIPTION mentions the "teLinkTable of TE-LINK-STD-MIB", could >> you please tell me what draft or rfc this is? > > ***This MIB has been defined by RFC4220. We had forgotten to describe the > reference of this MIB into reference section. We added it. > >> What about OSPFv3 and other protocols that may be related to this MIB >> (at some point?) Are you sure that this object is going to be useful >> (even in the >> short-term?) > > *** For the meantime, we think that this mib is available to support IPv6 > as > well as IPV4 for supporting inet-address-mib. > > >> * Notifications >> >> The descriptions are very unclear. Under what circumstances are these >> generated? Please be specific. >> > *** revised > >> * Conformance statements are missing the restrictions for IpAddress >> and IpAddressType objects in this MIB. >> Please correct this >> >> * ReadOnly Compliance is incorrect. There are 2 writable objects >> which need to be given read-only conformance. >> > *** Revised > > >> * 8. Security consideration >> >> s/consideration/Considerations/ >> >> - The first paragraph states there aren't any read-write objects but >> this is not accurate. Please update. >> > *** Revised > > > ---------------------------------------------------------------------------- > ------- > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Friday, June 26, 2009 10:33 PM > To: Tomohiro Otani; ma-miyazawa@kddilabs.jp; tnadeau@bt.com; > ke-kumaki@kddilabs.jp > Cc: Romascanu, Dan (Dan); Brungard, Deborah A, ALABS; Lou Berger; > ccamp@ietf.org > Subject: MIB Dr. review of draft-ietf-gmpls-ted-mib-5.txt > > Hello, > > Very interesting MIB! A good deal of thought went into this. > Thanks for that! > > First, the MIB compiler output will be given. Followed by a > general discussion and then specific comments given which > are in order of the document. > > Thanks, > -Joan > > > > > MIB Compiler output: > ======================= > > smicngPRO > ---------- > > * (NIT) Unable to abstract MIB Module using mstrip tool. > > E: f(TED-MIB.my), (460,4) Index item "teLocalIntAddrIndex" must be defined > with syntax that includes a range > E: f(TED-MIB.my), (518,49) Index item "teRemoteIntAddrIndex" must be > defined > > with syntax that includes a range > E: f(TED-MIB.my), (579,53) Index item "teSwCapIndex" must be defined with > syntax that includes a range > E: f(TED-MIB.my), (765,53) Index item "teSrlgIndex" must be defined with > syntax that includes a range > W: f(TED-MIB.my), (797,9) Variable "teAreaId" in notification > "tedTeInfoStatusChange" is an index for a table > W: f(TED-MIB.my), (797,19) Variable "teRouterId" in notification > "tedTeInfoStatusChange" is an index for a table > W: f(TED-MIB.my), (797,31) Variable "teLinkStateId" in notification > "tedTeInfoStatusChange" is an index for a table > W: f(TED-MIB.my), (809,9) Variable "teAreaId" in notification > "tedTeCreation" is an index for a table > W: f(TED-MIB.my), (809,19) Variable "teRouterId" in notification > "tedTeCreation" is an index for a table > W: f(TED-MIB.my), (809,31) Variable "teLinkStateId" in notification > "tedTeCreation" is an index for a table > W: f(TED-MIB.my), (819,9) Variable "teAreaId" in notification > "tedTeDeletion" is an index for a table > W: f(TED-MIB.my), (819,19) Variable "teRouterId" in notification > "tedTeDeletion" is an index for a table > W: f(TED-MIB.my), (819,31) Variable "teLinkStateId" in notification > "tedTeDeletion" is an index for a table > W: f(TED-MIB.my), (926,7) NOTIFICATION-GROUP "tedNotificationGroup" is not > used in a MODULE-COMPLIANCE in current module > > > > > > smiLint > ------------ > > Validation report > File: TED-MIB.my > Severity level requested: 6 > > Line Severity Problem > 109 5 warning: index element `teAreaId' of row `tedEntry' should be > not-accessible in SMIv2 MIB > 5 warning: index element `teRouterId' of row `tedEntry' should be > not-accessible in SMIv2 MIB > 5 warning: index element `teLinkStateId' of row `tedEntry' should > be > > not-accessible in SMIv2 MIB > 926 5 warning: current group `tedNotificationGroup' is not referenced in > this module > > > > General Discussion > ------------------ > > * As an fyi, the OSPFv3 MIB (for IPv6) is "IESG Evaluation". > > * In what GMPLS WG document is this functionality defined? > > I see a lot of MIBs referenced in MPLS, OSPF, ISIS and GMPLS and > also a lot of documents being referenced, but not a specific TED one. > > > * The MIB objects themselves do not have any REFERENCE clauses and most of > these > probably should given the nature of this MIB (i.e. that it is pulling from > so many different documents.) Please be specific in your REFERENCE > clauses > such as document, section, and sub-section, if appropriate. > > * The names in this MIB are not prefixed consistently. > Please see Appendix C of RFC4181. > > For example, TED-MIB is the MIB's name, and then > TedEntry, but the objects in this table are prefixed by "te" (but "ted" > would > be more consistent.) > > - The abbreviation for interface is "int" but would prefer either "if" or > "intf". > > > * With the exception of 2 objects, the MIB consists of read-only objects. > While this is fine in and of itself, there are several places in the text > that the > authors warn that if local configuration is done then routing needs to be > triggered so the new configuration gets dispersed. When looking at these > MIB tables, is there any way to tell if the information is currently in > use > or not? > > > > Specific Comments (in order of document) > ------------------------------------------ > > * Table of Contents > > s/Author's Address/Authors' Addresses/ > > > * TOC is missing "Informative References" entry. > > > > * 2. Introduction > > NIT: > s/related with/related to/ > > * In what GMPLS WG document is the functionality of TED defined? > > 4. Motivations > > * Why is ISIS not mentioned here? > > > 6. Example of TED MIB module usage > s/module usage/Module Usage/ > > * Second paragraph "TE MIB" > s/TE MIB/TED MIB/ > > The second paragraph is confusing. The Tables reflect information as > read only, yet, this paragraph discusses changing this information > locally (e.g. on a router) and then triggering routing to update > this information. > > The example given is confusing. What are the index values supposed to be? > > > MIB MODULE > ------------- > > * Please differentiate values as XXX or YYY for the rfc editor. > > * as suggested by Appendix D of RFC4181 (Guidelines for MIB Documents) > the oid layout should be: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > > This OID layout is: > - tedMIB > \-v-0 tedNotifications > |-1 tedObjects > \-2 tedConformance > \-v-1 tedGroups > \-2 tedCompliances > > Groups and Compliances should be reversed. > > > * Additionally there are extraneous sub-ids > of tedScalars and tedTables under the tedObjects branch. > While many older MIBs separated scalars and tables this way, > this is not needed and while fine for the MIB as it exists > currently, if this MIB is added to in the future (e.g. if an > enterprise MIB developer wants to add objects via his/her own > enterprise MIB Module), then keeping the separation of scalars > and tables may be a hinderance. I would ask that you remove > these sub-ids (tedScalars and tedTables) so that the oidtree > will look like: > > |-1 tedObjects > | \-1 tedNotificationEnabled, TruthValue[SNMPv2-TC], rw, current > | \-2 tedNotificationMaxRate, Unsigned32, rw, current > \-3 tedTable > | \---1 tedEntry, INDEX{ teAreaId,teRouterId,teLinkStateId } > | \-v-1 teAreaId, Unsigned32(1..4294967295), ro, current > > etc. > > > * tedNotificationEnabled > > Why is this object needed? Please answer the question wrt rfc3413. > > > * tedNotificationMaxRate > > This one throttling mechanism is used to control 3 different > notifications. > This might be okay, but that depends on the notifications and as they are > written now, they seem to be overlapping. For example, if a TED is > created > then are 2 notifications sent (one ofr StatusChange and one for Creation) > or just one (for Creation)? > > > * teLinkInformationData > > The DESCRIPTION mentions the "teLinkTable of TE-LINK-STD-MIB", could you > please > tell me what draft or rfc this is? > > What about OSPFv3 and other protocols that may be related to this MIB (at > some point?) > Are you sure that this object is going to be useful (even in the > short-term?) > > > > > * Notifications > > The descriptions are very unclear. Under what circumstances are these > generated? Please be specific. > > * Conformance statements are missing the restrictions for > IpAddress and IpAddressType objects in this MIB. > Please correct this. > > > * ReadOnly Compliance is incorrect. There are 2 writable objects > which need to be given read-only conformance. > > > * 8. Security consideration > > s/consideration/Considerations/ > > - The first paragraph states there aren't any read-write objects but > this is not accurate. Please update. > > > > > > From wwwrun@core3.amsl.com Sun Aug 30 13:22:20 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C574B28C215; Sun, 30 Aug 2009 13:22:20 -0700 (PDT) From: Adrian Farrel(IETF Routing Area) To: Greg Jones Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090830202220.C574B28C215@core3.amsl.com> Date: Sun, 30 Aug 2009 13:22:20 -0700 (PDT) X-Mailman-Approved-At: Mon, 31 Aug 2009 05:16:30 -0700 Cc: CCAMP Working Group , Stephen Trowbridge , Patrik Fältström , Adrian Farrel , Ross Callon Subject: [CCAMP] New Liaison Statement, "ASON Routing in the IETF" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 20:22:20 -0000 Title: ASON Routing in the IETF Submission Date: 2009-08-30 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=566 From: Adrian Farrel(IETF Routing Area) To: ITU-T SG15 Q14(Greg Jones ) Cc: Kam Lam Stephen Trowbridge Patrik F�ltstr�m Ross Callon Deborah Brungard Lou Berger CCAMP Working Group Reponse Contact: Adrian Farrel Technical Contact: Deborah Brungard Lou Berger Purpose: For information Body: Dear Mr. Lam, May I take this opportunity to inform you and Question 14 of Study Group 15 of the progress of work within the IETF on ASON routing. _Requirements and Analysis_ As you are aware, the IETF has published two Request For Comment documents (RFCs) documenting the requirements for GMPLS routing for ASONs, and an evaluation of existing routing protocols against the ASON routing requirements. These are: - RFC 4258 "Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)," - RFC 4652 "Evaluation of existing Routing Protocols against ASON Routing Requirements" They are available for free download from http://www.ietf.org/rfc.html _Inclusion of Additional Requirements_ After repeated approaches from Study Group 15 saying that certain key routing requirements had been left out of RFC 4258 and that other requirements had been misrepresented, the IETF held an ad hoc face-to-face meeting during the 71st IETF in Philadelphia during the week of 10th March 2008. We discussed the content of the liaison and focussed in on the major points raised. We were helped in our analysis by experts from Q14/15 who traveled to form part of the group. The conclusion of the meeting was that it might be beneficial to revise RFC 4258 to be sure that it covers all of the requirements in the latest versions of the ITU-T Recommendations. To achieve this work, a design team was set up using three volunteers who were active in Study Group 15 and the Optical Interworking Forum and who were familiar with the content of G.7715 and G.7715.1. The team was chartered, and a mailing list was set up to allow open discussion of the issues. Unfortunately, the design team has been unable to deliver on its charter. A first version of a draft was posted in October 2008, but no further progress has been made. You are informed, therefore, that it is our intention to close this design team and shut the mailing list. The IETF welcomes further input on this topic which should be made in the form of Internet-Drafts with discussion on the mailing list of the CCAMP working group (https://www.ietf.org/mailman/listinfo/ccamp) _Protocol Extensions to OSPF_ The IETF's CCAMP working group produced initial work on protocol extensions to the OSPF routing protocol in support of ASON routing requirements. In order to facilitate the free work of the design team described above, CCAMP's work on OSPF was put on hold until the design team delivered on its charter. In the light of the failure of the lack of progress revising RFC 4258, it is not reasonable to hold up the work on OSPF any further. Consequently, an Internet-Draft ("OSPFv2 Routing Protocols Extensions for ASON Routing") has been advanced and approved by the IESG. This will be processed for publication as an RFC. Until the RFC Editor completes his tasks, the text of this work can be downloaded from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt The RFC will be published on the Experimental track. The IETF considers that significant modifications to Internet routing protocols need to be treated with great caution, and that the ASON routing extensions need to be the subject of experimentation in "walled gardens" in order to determine the stability of the protocol extensions before they are released for general use in the Internet. The IETF would welcome all reports of implementation, interoperability, and deployment experience of these protocol extensions. All comments should be sent to the CCAMP working group mailing list. Best Regards, Adrian Farrel IETF Routing Area Director Liaison to SG15 on the Optical Control Plane Attachment(s): No document has been attached From rschrage@schrageconsult.net Mon Aug 31 10:16:12 2009 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 1AFD828C3F8; Mon, 31 Aug 2009 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_50=0.001, HELO_EQ_DE=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 zjwrRP1VPV-9; Mon, 31 Aug 2009 10:16:09 -0700 (PDT) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) by core3.amsl.com (Postfix) with ESMTP id E92C528C3F5; Mon, 31 Aug 2009 10:16:08 -0700 (PDT) Received: from fwd01.aul.t-online.de by mailout02.t-online.de with smtp id 1MiAUM-0002W4-00; Mon, 31 Aug 2009 19:16:18 +0200 Received: from ReinhardLaptop (VsaCR2ZE8tlufNPs+o6Cf+xFmd7JKefroQbA5s72hpm2DCG0NeLEl5ougKMWWYSPuftLlAOZWk@[91.4.10.68]) by fwd01.webpage.t-com.de with esmtp id 1MiAUI-1tgvo00; Mon, 31 Aug 2009 19:16:14 +0200 From: "Rschrage" To: "'Weiqiang Sun'" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <000c01ca20d5$03aeca30$0b0c5e90$@net> <002601ca265e$89ef67b0$9dce3710$@net> <1B6858BC083442DE896FA785BC5BD5AE@mit.edu> In-Reply-To: <1B6858BC083442DE896FA785BC5BD5AE@mit.edu> Date: Mon, 31 Aug 2009 19:16:13 +0200 Message-ID: <000001ca2a5e$be74f9b0$3b5eed10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acom31nSOaQXUDITR5S7uRYd250DWQDfhWig Content-Language: de X-ID: VsaCR2ZE8tlufNPs+o6Cf+xFmd7JKefroQbA5s72hpm2DCG0NeLEl5ougKMWWYSPuftLlAOZWk X-TOI-MSGID: c7aaeffc-e3a0-4e9f-9841-9aae5d8eafa7 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 31 Aug 2009 17:16:12 -0000 Hi Weiqiang, thanks for commenting. My responses inline as usual; Brgds. Reinhard Schrage Tel: +49 (0) 5137 909540 Mobile: +49 (0) 172 26.36.046 reinhard@schrageconsult.com -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Weiqiang Sun Sent: Donnerstag, 27. August 2009 08:26 To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'IETF IPPM WG' Subject: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request] Hi Reinhard, Thanks for responding. Please see inline. > > Thanks for sending this part. See below for my responses. > > [RS7] > Is there any help or suggestion on how to actually compute a usable > Lambda_m? > [sunwq] > No. Depending on the performance of the implementation, the lambda_m can > be > very different, even under the same topology. A proper value of Lambda_m > can > only be tuned in the testing. > > [RS7a] > I am a bit at loss here. > > It was my understanding that you use a metric to measure certain network > quantities, e.g. throughput, set up delays, etc. > In a second step you'd use these measured metrics to determine whether the > systems under test meet your previously expected or defined quality > parameters. If not, you'd make changes to the components or network > design, > measure again, and compare the previous set of data to the one after the > change and see whether you have improved and are moving into the right > direction. > > You seem to be coming from the other end, i.e. tweak the input parameters > to > suit your system under test. [sunwq] OK, I get your point here. What you said is true. I had thought by saying ``a usable lambda_m", you are saying that a lambda_m that is *best achievable* by the DUT/SUT. If you are expecting certain performance from the DUT/SUT, then very likely you will have in mind an "expected" lambda_m, won't you? The methodology here does not suggest how to select lambda_m. This in fact can provide flexibility. Either the test will use an expected lambda_m, or tune the lambda_m that reflects the best system performance, depending on the purpose of the test. Does this make sense? [RS] OK - under the assumption of an experienced user. > > [RS8] > How to compare metrics that have been generated by two different Poisson > processes, i.e. e.g. two different arrival rates? > [sunwq] > No way. Do we need to do that anyway? > > [RS8a] > Pls also see my comments above. > If you cannot compare two sets of measurements how will you then arrive at > an objective study of the network components under test? [sunwq] Maybe I misunderstood you again here. The Poisson arrival rate is an approximation of real traffic load. Of course it is worthwhile to find out how DUT/SUT performs when traffic load changes. But what else do you expect by comparing two data sets from different traffic load? Did I miss something here? [RS] I was thinking along the lines of say starting with a reasonably large lambda_m, get the metric sample for that and then subsequently e.g. shortening lambda_m, comparing the resulting metric tuples. I was looking for a guideline on how to possibly compare these resulting tuples. As this is a stochastic process even shorter lambda_m values can still generate longer interarrival times (surely with lower probability but still possible). Makes sense? > > > [RS9] > These sample tuples are dependent on the arrival rate Lambda_m. How to > deduct this input parameter from a resulting sample? > For instance, if two result sample sets are given, how can we be sure that > they can be compared? > [sunwq] > My understanding of the sample is that it is a sequence of singleton > values > obtained under a set of parameters. The parameters, such as Lambda_m, are > not visible in the sample. However, when reporting the sample, the > parameters must also be reported. > > [RS9a] > OK. Noted and understood. [sunwq] Great, thanks. > > > [RS10] > A superposition of two different Poisson processes is being used here. > How do you map the resulting RESV messages to the correct process, i.e. > how > to differentiate e.g. a late RESV message resulting from third PATH > message > in fourth invocation from an early RESV message solicited by first PATH > message in fourth invocation? > [sunwq] > RESV messages can be differentiated by either MSG ID or non-overlapping > LSP > ID, or combined. The RSVP-TE protocol does that automatically. So I > believe > this is an RSVP-TE implementation issue, rather than a testing methodology > issue. > > [RS10a] > OK. Noted and understood. [sunwq] Great, thanks. > > [RS11] > ???? > [sunwq] > Well, the full text is like: "The percentile of Metric is defined as: > given > a metric and a percent X between 0% and 100%, the Xth percentile of all > the > dT values in the sample." Would it help a bit if sentence is replaced by > the > > full text above? > Please be noted that this text is inherited from the IPPM docs (See RFC > 2681, page 16, 4.1). > > [RS11a] > The way it was written in the doc it was just a fragment of a sentence. > Unfortunately RFC 2681, page 16, 4.1. also does not give a proper > definition, as it too is just a fragmented sentence. > RFC 2330, p.26, 11.3 gives a better explanation, as: > "We will use the term 'percentile' to refer to the smallest value of x for > which the empirical distribution function is greater or equal a given > percentage" [sunwq] Well, to tell the truth I was troubled by this too. Later I realized that one reason that might lead to such a definition is that the authors of 2681 had assumed that ``percentile" is a ``well known" term, and does not inheriting its definition from RFC 2330. And quite surprisingly wikipedia says "there is no standard definition of percentile." But wikipedia also says ``however all definitions yield similar results when the number of observations is large." I will replace the original example with the following to avoid such a dilemma (of conflicting calculations in two RFCs). ============original text=============== Example: suppose we take a sample and the results are: Stream1 = < , , , , > Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110 and 500 msec are larger (undefined values are not counted in). ============end of original text======== ============new text=============== Example: suppose we take a sample and the results are: Stream1 = < , , , , , > Then the 60th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110, 350 and 500 msec are larger (undefined values are not counted in). A more detailed definition of percentile may be found in RFC 2330. ============end of new text======== > [RS12] > As stipulated in RFC2330 the EDF is defined as a function F(x) which for > any > > x gives the fractional proportion of the total measurements that were <= > x. > (see RFC2330 11.3 p26) > Hence F(90)=0.25, F(100)=0.5,F(110)=0.75, F(500)=1 and therefore the 50th > percentile is defined as 100 as opposed to 110. > [sunwq] > Yes you are right with regard to RFC 2330. But we have used exactly the > same > > example as in RFC 2681 (page 16, section 4.1). The good thing is that the > difference of the two calculations is very small when the number of > measurement is large. Change needed? > > [RS12a] > As outlined above RFC 2330 as opposed to RFC2681 gives a proper definition > of percentile. Therefore we should stick to RFC2330 and change > accordingly. > > It should be noted though, that also RFC2330 defines percentile > differently > than it is done in the statistical literature, but we can live with this, > as > it makes the definition easier to apply to measurement samples. Good point, thanks for explaining. I hope the change above is satisfactory for you. [RS] OK then. Thanks and best regards, Weiqiang > > [------------------End of new comments---------------------] > > > And I realized that the points you have raised covered the main part of > the > text. We would expect your further comments regarding our responses. > Otherwise we will assume that you are happy with it and will proceed to > change the text based on the revision you sent in your previous email :) > > Thank you again for your time in reviewing the draft so carefully. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Rschrage" > Sent: Wednesday, August 19, 2009 9:57 PM > To: "'Weiqiang Sun'" ; "'Lou Berger'" ; > "'Henk Uijterwaal'" > Cc: ; ; "'IETF IPPM WG'" > > Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] > >> Hi all, >> >> pls find attached a further updated edition of previous revised doc >> draft-ietf-ccamp-lsp-dppm-06. >> >> I believe this is as far as we can go for the moment before a mutual >> satisfactory understanding has been reached and a new draft has been >> issued >> by the authors. >> >> Again, pls feel free to comment. >> >> Many thanks. >> Brgds. >> Reinhard Schrage >> Tel: +49 (0) 5137 909540 >> Mobile: +49 (0) 172 26.36.046 >> reinhard@schrageconsult.com >> >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >> Weiqiang Sun >> Sent: Mittwoch, 19. August 2009 09:28 >> To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' >> Cc: ccamp@ietf.org; zhangguoying@mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, >> ATTLABS'; 'IETF IPPM WG' >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >> More responses below: >> >> RS4. >> Should be more specific as to why this metric is no simple function of >> single uni-directional LSP Setup Delay metric, i.e. why can it not be >> deduced from single LSP Setup Delay? >> [sunwq] >> This point is raised regarding the sentence "The time needed to setup a >> large number of LSPs during a short time period can not be deduced by >> single >> >> LSP setup delay." >> One reason is that when a large number of LSPs in being setup during a >> short >> >> period of time, the control plane may be crowded or even overwhelmed by >> the >> large number of signaling and routing messages. This may significantly >> slow >> down the processing of a particular signaling message, which will results >> in >> >> longer LSP provisioning delays. >> Are you suggesting that we add similar explanations to the document? We'd >> love to do that if you feel it is necessary. >> >> RS5. >> The current definition only addresses multiple uni-directional LSP setups >> between two nodes ID0 and ID1. What about the the case when ID0 is to >> setup >> multiple uni-directional LSP setups to different egress nodes ID1, ID2, >> ID3,.,IDN? >> [sunwq] >> Yes, it is a useful case. Likewise you would expect a case to establish a >> varied number of (instead of one) LSPs to a set of destinations. Our >> suggestion is that this case is approached by integrating the defined >> methodologies of single/multiple LSPs provisioning delay, in the form of >> a >> particular testing case, rather than a formal testing methodology. This >> is >> in fact a trade-off between complexity and accuracy. >> >> Best regards, >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Weiqiang Sun" >> Sent: Wednesday, August 19, 2009 2:48 PM >> To: "Rschrage" ; "'Lou Berger'" >> ; "'Henk Uijterwaal'" >> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >> ; "'IETF IPPM WG'" ; >> Subject: Re: [ippm] [Fwd: IPPM expert review request] >> >>> Hi Reinhard, >>> >>> Many thanks for doing the careful review. We appreciate your many >>> wording >>> suggestions. We will go through these one by one and adopt those we feel >>> appropriate. In this email I will not list all the comments since these >>> will not lead to major technical changes. >>> >>> Below I try to respond to the points you raised in the revision. >>> >>> RS1. >>> This would imply that the metric may produce a range of several values >>> at >>> one time with the minimum value to be taken from that range. >>> I believe what the authors are trying to say is, that the LSP Setup >>> Delay >>> Metric provides a lower bound on all possible LSP Delay Metrics of >>> actually instantiated LSPs, or in other words: an actual LSP Delay >>> Metric >>> cannot get smaller than an LSP Setup Delay Metric. >>> [sunwq] >>> This point is raised regarding the motivation of the sigleton definition >>> of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are >>> trying >> >>> to say that the minimum value of this metric reflects the (likely) >>> single >>> lsp setup delay when the control plane is lightly loaded. The formal >>> definition of the minimum value is in "14.1 The minimum of metric" >>> In fact we have inherited this from the IPPM documents (see RFC 2681, >>> page >> >>> 2 section 1.1 bullet 3). >>> >>> RS2. >>> How? Should there be a methodology be defined for this? >>> [sunwq] >>> This point is raised regarding the sentense in our methodologies >>> sections - "Make sure that the network has enough resource to set up the >>> requested LSP." >>> We have assumed that test personnel should have adequate expertise in >>> allocating enough resources for the testing. The allocation of resources >>> for the testing purpose can be very test specific and we believe it is >>> quite outside the scope of this document. >>> >>> RS3. >>> Too vague? As both timestamps are to be taken on the same ingress node, >>> they should be taken at the same application/network level. >>> [sunwq] >>> This point is raised regarding the sentense "If the corresponding RESV >>> message arrives within a reasonable period of time, take the timestamp >>> (T2) as soon as possible upon receipt of the message." >>> Yes, ideally the timestamp should be taken immediately after the >>> reception >> >>> of the RESV message. The wording "as soon as possible" is used to allow >>> for some flexibility when RESV message needs to be propagated to certain >>> modules where timestamp-taking is most appropriate. >>> And again, this text is inherited from the IPPM documents (see RFC 2681 >>> page 7, bullet 3). >>> >>> Thanks again and looking forward to your further comments and revisions. >>> >>> Weiqiang >>> >>> -- >>> Weiqiang Sun >>> Shanghai Jiao Tong University >>> http://front.sjtu.edu.cn/~sunwq/ >>> >>> -------------------------------------------------- >>> From: "Rschrage" >>> Sent: Tuesday, August 18, 2009 8:23 PM >>> To: "'Lou Berger'" ; "'Henk Uijterwaal'" >>> >>> Cc: ; "'BRUNGARD, DEBORAH A, ATTLABS'" >>> ; ; "'IETF IPPM WG'" ; >>> >>> Subject: RE: [ippm] [Fwd: IPPM expert review request] >>> >>>> Hello, >>>> >>>> sorry for late response- >>>> >>>> Nevertheless here is a first edition of my revision of doc >>>> draft-ietf-ccamp-lsp-dppm-06. >>>> >>>> The doc has been saved in Word 2003 format to easily track changes. >>>> I am using Kaspersky Anti Virus 2010 software so I trust there should >>>> be >>>> no >>>> unpleasant surprises when downloading the attached word doc. >>>> >>>> >>>> I thought it would be advisable to first address the suggested comments >>>> and >>>> questions upto and including the uni-directional LSP setup delay metric >>>> and >>>> after that to continue with the bi-directional and sample definitions >>>> as >>>> covered in the doc. >>>> >>>> Please let me have your thoughts on this. >>>> >>>> Many thanks. >>>> Reinhard Schrage >>>> Tel: +49 (0) 5137 909540 >>>> Mobile: +49 (0) 172 26.36.046 >>>> reinhard@schrageconsult.com >>>> >>>> -----Original Message----- >>>> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of >>>> Lou >>>> Berger >>>> Sent: Dienstag, 28. Juli 2009 14:59 >>>> To: Henk Uijterwaal >>>> Cc: zhangguoying@mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; >>>> sunwq@mit.edu; IETF IPPM WG >>>> Subject: Re: [ippm] [Fwd: IPPM expert review request] >>>> >>>> Hank/Reinhard, >>>> >>>> Thank you very much for undertaking this review. Please cc >>>> ccamp@ietf.org on any comments you may have. >>>> >>>> Lou >>>> >>>> On 7/28/2009 6:47 AM, Henk Uijterwaal wrote: >>>>> Lou, others, >>>>> >>>>>> We received the request for a review of a document currently under >>>>>> discussion in the CCAMP WG, please see below. Is there anybody who >>>>>> has time to do this review in the near future? >>>>> >>>>> Reinhard Schrage (rschrage@schrageconsult.net) has voluntered to do >>>>> this. >>>>> >>>>> Reinhard: please post anything you find to both the list and the >>>>> authors. >>>>> And thank you for doing this. >>>>> >>>>> Henk >>>>> >>>>>> >>>>>> Matt & Henk >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: IPPM expert review request >>>>>> Date: Fri, 24 Jul 2009 15:57:41 -0400 >>>>>> From: Lou Berger >>>>>> To: ippm-chairs@tools.ietf.org >>>>>> CC: Brungard, Deborah A, ALABS , sunwq@mit.edu, >>>>>> zhangguoying >>>>>> >>>>>> Hi, >>>>>> We, the CCAMP WG chairs, would like to request that the IPPM WG >>>>>> review >>>>>> a draft that is progressing through the CCAMP WG. This work applies >>>>>> IPPM approaches to GMPLS. The document we'd like reviewed is >>>>>> available at: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 >>>>>> >>>>>> Is this acceptable? Can you undertake this review? Alternatively, >>>>>> we >>>>>> can just last call the document in your WG (it has already passed >>>>>> CCAMP >>>>>> WG LC). >>>>>> >>>>>> Thank you, >>>>>> Lou (and Deborah) >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > > > >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From tom.nadeau@bt.com Mon Aug 31 16:44:24 2009 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 5A92228C5F4 for ; Mon, 31 Aug 2009 16:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 uv-PCmFhYZp9 for ; Mon, 31 Aug 2009 16:44:23 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B8CBA28C5D5 for ; Mon, 31 Aug 2009 16:44:22 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.104]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 00:44:33 +0100 Received: from 217.32.164.178 ([217.32.164.178]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.147]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Aug 2009 23:44:32 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 31 Aug 2009 19:44:30 -0400 From: "Thomas D. Nadeau" To: RFC Errata System , , , , , , Message-ID: Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4803 (1841) Thread-Index: AcoqlPu1xLNCUnqRO0OHKis3L2wjlQ== In-Reply-To: <200908271848.n7RImiJK006025@boreas.isi.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3334592671_37518487" X-OriginalArrivalTime: 31 Aug 2009 23:44:33.0572 (UTC) FILETIME=[FDD6CE40:01CA2A94] Cc: ccamp@ietf.org, girishm@ipinfusion.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4803 (1841) 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, 31 Aug 2009 23:44:24 -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_3334592671_37518487 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree that there is an error in the original text. The proposed text for the fix is correct. --Tom On 8/27/09 2:48 PM, "RFC Errata System" wrote: > > The following errata report has been submitted for RFC4803, > "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router > (LSR) Management Information Base". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=1841 > > -------------------------------------- > Type: Technical > Reported by: Girish Mahanta > > Section: Section 7 > > Original Text > ------------- > gmplsOutSegmentTTLDecrement OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object indicates the amount by which to decrement the Time > to Live (TTL) of any payload packets forwarded on this segment if > per-hop decrementing is being done. > A value of zero indicates that no decrement should be made or > that per-hop decrementing is not in use. > See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable > of GMPLS-TE-STD-MIB for a value by which to decrement the TTL > for the whole of a tunnel. > This object cannot be modified if mplsOutSegmentRowStatus for > the associated entry in the mplsOutSegmentTable is active(1)." > REFERENCE > "1. Time To Live (TTL) Processing in Multi-Protocol Label > Switching (MPLS) Networks, RFC 3443. > 2. Generalized Multiprotocol Label Switching (GMPLS) Traffic > Engineering Management Information Base, RFC 4802." > DEFVAL { 0 } > ::= { gmplsOutSegmentEntry 2 } > > Corrected Text > -------------- > gmplsOutSegmentTTLDecrement OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object indicates the amount by which to decrement the Time > to Live (TTL) of any payload packets forwarded on this segment if > per-hop decrementing is being done. > A value of zero indicates that no decrement should be made or > that per-hop decrementing is not in use. > This object cannot be modified if mplsOutSegmentRowStatus for > the associated entry in the mplsOutSegmentTable is active(1)." > REFERENCE > "1. Time To Live (TTL) Processing in Multi-Protocol Label > Switching (MPLS) Networks, RFC 3443." > DEFVAL { 0 } > ::= { gmplsOutSegmentEntry 2 } > > Notes > ----- > In gmplsOutSegmentTable for the object gmplsOutSegmentTTLDecrement there is no > gmplsTunnelTTLDecrement object in the gmplsTunnelTable of GMPLS-TE-STD-MIB > which is referenced. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) > -------------------------------------- > Title : Generalized Multiprotocol Label Switching (GMPLS) Label > Switching Router (LSR) Management Information Base > Publication Date : February 2007 > Author(s) : T. Nadeau, Ed., A. Farrel, Ed. > Category : PROPOSED STANDARD > Source : Common Control and Measurement Plane > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp -- Principal Architect - 21CN Networks --B_3334592671_37518487 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [CCAMP] [Technical Errata Reported] RFC4803 (1841)
    I agree that there is an error in the original text= . The proposed text for the fix is correct.

    --Tom



On 8/27/09 2:48 PM, "RFC Errata System" <rfc-editor@rfc-editor.org> wrote:

>
> The following errata report has been submitted for RFC4803,
> "Generalized Multiprotocol Label Switching (GMPLS) Label Switchin= g Router
> (LSR) Management Information Base".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4803&eid=3D1841<= BR> >
> --------------------------------------
> Type: Technical
> Reported by: Girish Mahanta <giris= hm@ipinfusion.com>
>
> Section: Section 7
>
> Original Text
> -------------
> gmplsOutSegmentTTLDecrement OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This object indicates the amount by which to decrement the Time<= BR> > to Live (TTL) of any payload packets forwarded on this segment if
> per-hop decrementing is being done.
> A value of zero indicates that no decrement should be made or
> that per-hop decrementing is not in use.
> See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable
> of GMPLS-TE-STD-MIB for a value by which to decrement the TTL
> for the whole of a tunnel.
> This object cannot be modified if mplsOutSegmentRowStatus for
> the associated entry in the mplsOutSegmentTable is active(1)." > REFERENCE
> "1. Time To Live (TTL) Processing in Multi-Protocol Label
> Switching (MPLS) Networks, RFC 3443.
> 2. Generalized Multiprotocol Label Switching (GMPLS) Traffic
> Engineering Management Information Base, RFC 4802."
> DEFVAL { 0 }
> ::=3D { gmplsOutSegmentEntry 2 }
>
> Corrected Text
> --------------
> gmplsOutSegmentTTLDecrement OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This object indicates the amount by which to decrement the Time<= BR> > to Live (TTL) of any payload packets forwarded on this segment if
> per-hop decrementing is being done.
> A value of zero indicates that no decrement should be made or
> that per-hop decrementing is not in use.
> This object cannot be modified if mplsOutSegmentRowStatus for
> the associated entry in the mplsOutSegmentTable is active(1)." > REFERENCE
> "1. Time To Live (TTL) Processing in Multi-Protocol Label
> Switching (MPLS) Networks, RFC 3443."
> DEFVAL { 0 }
> ::=3D { gmplsOutSegmentEntry 2 }
>
> Notes
> -----
> In gmplsOutSegmentTable for the object gmplsOutSegmentTTLDecrement the= re is no
> gmplsTunnelTTLDecrement object in the gmplsTunnelTable of GMPLS-TE-STD= -MIB
> which is referenced.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= BR> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15)
> --------------------------------------
> Title           &nbs= p;   : Generalized Multiprotocol Label Switching (GMPLS) Labe= l
> Switching Router (LSR) Management Information Base
> Publication Date    : February 2007
> Author(s)           = : T. Nadeau, Ed., A. Farrel, Ed.
> Category           &= nbsp;: PROPOSED STANDARD
> Source           &nb= sp;  : Common Control and Measurement Plane
> Area            = ;    : Routing
> Stream           &nb= sp;  : IETF
> Verifying Party     : IESG
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf= .org/mailman/listinfo/ccamp

--
Principal Architect - 21CN Networks

 --B_3334592671_37518487-- From sunwq@MIT.EDU Mon Aug 31 18:58:33 2009 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 2B30F28C2B8; Mon, 31 Aug 2009 18:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=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 rqM+94trP2XF; Mon, 31 Aug 2009 18:58:32 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 31F0D3A6C43; Mon, 31 Aug 2009 18:58:32 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n811wd56017967; Mon, 31 Aug 2009 21:58:40 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n811wTs2009969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2009 21:58:34 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Rschrage" , "'Lou Berger'" , "'Henk Uijterwaal'" References: <000c01ca20d5$03aeca30$0b0c5e90$@net> <002601ca265e$89ef67b0$9dce3710$@net> <1B6858BC083442DE896FA785BC5BD5AE@mit.edu> <000001ca2a5e$be74f9b0$3b5eed10$@net> In-Reply-To: <000001ca2a5e$be74f9b0$3b5eed10$@net> Date: Tue, 1 Sep 2009 09:58:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org, zhangguoying@mail.ritt.com.cn, 'IETF IPPM WG' Subject: Re: [CCAMP] [ippm] [Fwd: IPPM expert review request] 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, 01 Sep 2009 01:58:33 -0000 Hi Reinhard, I appreciate your response. I am glad that we resolved all other concerns :). Please see one last comment below. >> [RS8] >> How to compare metrics that have been generated by two different Poisson >> processes, i.e. e.g. two different arrival rates? >> [sunwq] >> No way. Do we need to do that anyway? >> >> [RS8a] >> Pls also see my comments above. >> If you cannot compare two sets of measurements how will you then arrive >> at >> an objective study of the network components under test? > [sunwq] > Maybe I misunderstood you again here. The Poisson arrival rate is an > approximation of real traffic load. Of course it is worthwhile to find out > how DUT/SUT performs when traffic load changes. But what else do you > expect > by comparing two data sets from different traffic load? Did I miss > something > > here? > > [RS] > I was thinking along the lines of say starting with a reasonably large > lambda_m, get the metric sample for that and then subsequently e.g. > shortening lambda_m, comparing the resulting metric tuples. I was looking > for a guideline on how to possibly compare these resulting tuples. > As this is a stochastic process even shorter lambda_m values can still > generate longer interarrival times (surely with lower probability but > still > possible). Makes sense? Larger lambda_m represents higher arrival rate hence will result in shorter average inter-arrival delay. I guess what you want to say is that shorter lambda_m may generate shorter inter-arrival times. Yes it is true. But once we decided to get a ``sample", instead of a singleton value, then very likely we are interested in the system performance on average (and of course, in some other statistics of the sample), possibly averaged over a large number of singleton values. In this case each singleton value does not have much individual significance. This also can be explained by the fact the the processing of signaling messages on each NE are themselves random processes. When you generate the requests with constant inter-arrival time, you may still get singleton values that vary drastically. So it does not make sense to compare any two singleton values. However, once averaged over a large number of singleton values, the result is meaningful. And I believe the same thing happens in IP performance measurement. For example, in RFC 2681, Poisson process is suggested but no guideline of how to compare two samples is provided. It think it makes sense that the documents provides methodologies on how to perform a measurement, and leaves the task of interpreting the results to the testers, or the owners of DUT/SUTs. Hope this helps! Best, Weiqiang