From tom111.taylor@bell.net Thu Apr 1 06:31:55 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3B23A688A for ; Thu, 1 Apr 2010 06:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.934 X-Spam-Level: * X-Spam-Status: No, score=1.934 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MSGID_FROM_MTA_HEADER=0.803] 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 fbSXNOUe4L-8 for ; Thu, 1 Apr 2010 06:31:55 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by core3.amsl.com (Postfix) with ESMTP id D27213A67DF for ; Thu, 1 Apr 2010 06:31:54 -0700 (PDT) Received: from BLU0-SMTP92 ([65.55.111.72]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 06:32:27 -0700 X-Originating-IP: [74.12.183.53] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([74.12.183.53]) by BLU0-SMTP92.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 06:32:26 -0700 Date: Thu, 01 Apr 2010 09:32:24 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2010 13:32:26.0352 (UTC) FILETIME=[C4B28700:01CAD19F] Subject: [ANCP] Sub-TLVs and padding non-issue X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:31:55 -0000 In the multicast extensions document, we have an example of an embedded TLV that does not end on a 32-bit word boundary. The example is in Figure 17 (page 67-68). We chose to insert padding to round out the TLV to a word boundary, just as if it stood alone. In the base document, immediately below Figure 13 (page 30), it is stated that: "The value field in each TLV is padded to a 4-octet alignment." Finally, after bullet 5 on page 33 of the base document, it is stated that: "The general format of the sub-TLVs is identical to the general TLV format. The value field in each sub-TLV is padded to a 4-octet alignment." I was worried that the treatment of padding for sub-TLVs was different from that for TLVs. These quotations indicate that it is not. I believe this removes the last potential issue regarding the merger of sub-TLV types into the same registry as TLV types. There is no difference between a TLV and a sub-TLV, except that the latter happens to be embedded within another TLV. Tom Taylor From flefauch@cisco.com Thu Apr 1 07:02:05 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C513A682B for ; Thu, 1 Apr 2010 07:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=-4.540, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SARE_GIF_ATTACH=1.42] 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 Sixj799TkrRU for ; Thu, 1 Apr 2010 07:02:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A48153A680D for ; Thu, 1 Apr 2010 07:02:03 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-AV: E=Sophos;i="4.51,348,1267401600"; d="gif'147?scan'147,208,147";a="5078791" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2010 13:27:43 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o31E2XTH024919; Thu, 1 Apr 2010 14:02:34 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/mixed; boundary=Apple-Mail-206--234416916 From: Francois Le Faucheur In-Reply-To: <945527.34063.qm@web113808.mail.gq1.yahoo.com> Date: Thu, 1 Apr 2010 16:02:39 +0200 Message-Id: References: <945527.34063.qm@web113808.mail.gq1.yahoo.com> To: Sanjay Wadhwa X-Mailer: Apple Mail (2.1078) Cc: Kristian.Poscic@alcatel-lucent.com, ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 14:02:05 -0000 --Apple-Mail-206--234416916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sanjay, On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote: >=20 > [SW] The scenario above, where NAS sends the channel on MC-VLAN, = assumes NAS is doing bandwidth based AC. A channel join on AN may = trigger an AC request message to NAS, which should trigger a CAC = decision and QOS-adjust on NAS and a response back to AN (before AN can = perform replication). Do we need another bandwidth update message from = AN to NAS? In case AN sees a channel leave (and no new join for some = time) or a user switches from HD to SD, then AN may decide to notify NAS = of released bandwidth. I believe we are again covered by existing AC = request message from AN to NAS (described in multicast extensions = draft). If admission control is to be performed by NAS (ie Grey list multicast = flow), then I agree we are already covered by existing multicast = procedures because the NAS is always fully aware of currently admitted = multicast traffic on a given port. >=20 > On the other hand if we are assuming bandwidth delegation model and = autonomous AC on AN, That is indeed the case of interest, here. > then we are already covered via interaction related to bandwidth = delegation between AN and NAS. That was my initial reaction too. Indeed, I think it is possible to = stretch existing bandwidth delegation procedures to achieve this. = However this would result in sub-optimal handling of the new use case. Example call-Flow based on re-using existing bandwidth delegation = procedures: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D AN <---PORT_MNGT (Bw allocation=3D0Mb/s) --NAS ... (join from subscriber for 2Mb/s multicast flow) AN ---Bandwidth Realloc Request (2Mb/s)--> NAS (NAS = allocates 2Mb/s) AN <--------Bandwidth Transfer (2Mb/s)-------- NAS (AN starts replicating) ... (leave + join from subscriber for 4Mb/s multicast flow) AN ---Bandwidth Realloc Request (4Mb/s)--> NAS (NAS = allocates 4Mb/s total) AN <--------Bandwidth Transfer (4Mb/s)-------- NAS (AN starts replicating) Example call-Flow based on new "admitted bandwidth reporting" = procedures: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D AN <---PORT_MNGT (Bw allocation=3D4Mb/s) --NAS ... (join from subscriber for 2Mb/s multicast flow) (AN does admission control and starts replicating) AN ------Admitted Bandwidth Report(2Mb/s)---> NAS (leave + join from subscriber for 4Mb/s multicast flow) (AN does admission control and starts replicating) AN ------Admitted Bandwidth Report(4Mb/s)----> NAS So, the sub-optimalities of reusing existing bandwidth delegation = procedures include: *a* use of two messages instead of one, for every bandwidth = change *b* extra delay on AN (ie need to wait for ANCP round-trip = instead of immediately replicate) *c* unnecessary "bandwidth check" for "reallocation" on NAS I'd say these sub-optimalities justify a new procedures, but I'm willing = to be convinced otherwise. I suppose one could argue that in the majority of join/leave/join, the = bandwidth does not change (ie zapping among channels of same bandwidth), = so the sub-optimality *a* is only incurred in less common case (leaveSD, = joinHD). Thoughts everyone? Francois --Apple-Mail-206--234416916 Content-Disposition: inline; filename=logo.gif Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 --Apple-Mail-206--234416916 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com --Apple-Mail-206--234416916 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-206--234416916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-206--234416916-- From Kristian.Poscic@alcatel-lucent.com Thu Apr 1 13:27:30 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250E33A698D for ; Thu, 1 Apr 2010 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 fwYQST7rfdA7 for ; Thu, 1 Apr 2010 13:27:29 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 77BFB3A68E5 for ; Thu, 1 Apr 2010 13:27:28 -0700 (PDT) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o31KRxqp003332; Thu, 1 Apr 2010 15:27:59 -0500 (CDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.pdc.alcatel-lucent.com [172.22.216.13]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o31KRjpk017731; Thu, 1 Apr 2010 15:27:59 -0500 (CDT) Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 15:27:32 -0500 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.11]) by USDALSMBS03.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 15:26:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 15:26:17 -0500 Message-ID: <41B3B178A129B6458752EC1B4D14998C03BC24D3@USDALSMBS04.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcrRo/x6ZLoub3fVQlSGwGY1dV+/EQAMiYgg References: <945527.34063.qm@web113808.mail.gq1.yahoo.com> From: "POSCIC Kristian" To: "Francois Le Faucheur" , "Sanjay Wadhwa" X-OriginalArrivalTime: 01 Apr 2010 20:26:50.0924 (UTC) FILETIME=[A9231EC0:01CAD1D9] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:27:30 -0000 Hi everyone, *b* would be a big worry for me in this case. I was thinking about keeping the NAS free of AC.=20 Also, at the beginning I would give the AN (via Port Mgmt) some delegated b/w which would be fairly high, according to my policy rules as an operator. Then the AN would report the b/w usage (if there is any b/w change) to the NAS. Then I would have the NAS ask the AN for b/w reallocation. In other words, the NAS ask the AN to set the b/w admission threshold (delegated b/w) to some (possibly lower) value. If the AN has the b/w available, it'll do so and send the ACK back. If not, then it'll NACK it. It may make strange that the NAS is asking for the b/w reallocation when it is not doing any AC. But this is OK, since there can be some other external policy server that is also managing b/w and this external policy server may ask the NAS to see if the b/w is available (not necessarily through ANCP but through some other interfaces). The NAS in turn converts this request into ANCP and sends it to the AN since the AN has the knowledge of the multicast usage and AC. Does anyone know off-hand if it is possible to aggregate b/w reallocation requests for multiple Target TLVs in the same ANCP message? I can check myself, I was just wondering if someone knows off-hand. Thanks, kris=20 -----Original Message----- From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 Sent: Thursday, April 01, 2010 7:03 AM To: Sanjay Wadhwa Cc: Francois Le Faucheur; POSCIC Kristian; ancp@ietf.org Subject: Re:=20 Hi Sanjay, On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote: >=20 > [SW] The scenario above, where NAS sends the channel on MC-VLAN, assumes NAS is doing bandwidth based AC. A channel join on AN may trigger an AC request message to NAS, which should trigger a CAC decision and QOS-adjust on NAS and a response back to AN (before AN can perform replication). Do we need another bandwidth update message from AN to NAS? In case AN sees a channel leave (and no new join for some time) or a user switches from HD to SD, then AN may decide to notify NAS of released bandwidth. I believe we are again covered by existing AC request message from AN to NAS (described in multicast extensions draft). If admission control is to be performed by NAS (ie Grey list multicast flow), then I agree we are already covered by existing multicast procedures because the NAS is always fully aware of currently admitted multicast traffic on a given port. >=20 > On the other hand if we are assuming bandwidth delegation model and autonomous AC on AN, That is indeed the case of interest, here. > then we are already covered via interaction related to bandwidth delegation between AN and NAS. That was my initial reaction too. Indeed, I think it is possible to stretch existing bandwidth delegation procedures to achieve this. However this would result in sub-optimal handling of the new use case. Example call-Flow based on re-using existing bandwidth delegation procedures: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D AN <---PORT_MNGT (Bw allocation=3D0Mb/s) --NAS ... (join from subscriber for 2Mb/s multicast flow) AN ---Bandwidth Realloc Request (2Mb/s)--> NAS (NAS allocates 2Mb/s) AN <--------Bandwidth Transfer (2Mb/s)-------- NAS (AN starts replicating) ... (leave + join from subscriber for 4Mb/s multicast flow) AN ---Bandwidth Realloc Request (4Mb/s)--> NAS (NAS allocates 4Mb/s total) AN <--------Bandwidth Transfer (4Mb/s)-------- NAS (AN starts replicating) Example call-Flow based on new "admitted bandwidth reporting" procedures: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D AN <---PORT_MNGT (Bw allocation=3D4Mb/s) --NAS ... (join from subscriber for 2Mb/s multicast flow) (AN does admission control and starts replicating) AN ------Admitted Bandwidth Report(2Mb/s)---> NAS (leave + join from subscriber for 4Mb/s multicast flow) (AN does admission control and starts replicating) AN ------Admitted Bandwidth Report(4Mb/s)----> NAS So, the sub-optimalities of reusing existing bandwidth delegation procedures include: *a* use of two messages instead of one, for every bandwidth change *b* extra delay on AN (ie need to wait for ANCP round-trip instead of immediately replicate) *c* unnecessary "bandwidth check" for "reallocation" on NAS I'd say these sub-optimalities justify a new procedures, but I'm willing to be convinced otherwise. I suppose one could argue that in the majority of join/leave/join, the bandwidth does not change (ie zapping among channels of same bandwidth), so the sub-optimality *a* is only incurred in less common case (leaveSD, joinHD). Thoughts everyone? Francois From tom111.taylor@bell.net Thu Apr 1 19:13:30 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076283A69C2 for ; Thu, 1 Apr 2010 19:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.194 X-Spam-Level: ** X-Spam-Status: No, score=2.194 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_SORBS_WEB=0.619] 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 d-xnBk+pFsCM for ; Thu, 1 Apr 2010 19:13:29 -0700 (PDT) Received: from blu0-omc2-s2.blu0.hotmail.com (blu0-omc2-s2.blu0.hotmail.com [65.55.111.77]) by core3.amsl.com (Postfix) with ESMTP id 659AD3A6960 for ; Thu, 1 Apr 2010 19:13:27 -0700 (PDT) Received: from BLU0-SMTP47 ([65.55.111.73]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 19:14:00 -0700 X-Originating-IP: [74.12.183.53] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([74.12.183.53]) by BLU0-SMTP47.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 19:14:00 -0700 Date: Thu, 01 Apr 2010 22:13:56 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: POSCIC Kristian References: <945527.34063.qm@web113808.mail.gq1.yahoo.com> <41B3B178A129B6458752EC1B4D14998C03BC24D3@USDALSMBS04.ad3.ad.alcatel.com> In-Reply-To: <41B3B178A129B6458752EC1B4D14998C03BC24D3@USDALSMBS04.ad3.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2010 02:14:00.0242 (UTC) FILETIME=[2860D120:01CAD20A] Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 02:13:30 -0000 Can't do that until Target with multiple instances is defined. Even then, the question becomes one of whether you would give the same allocation to every port. POSCIC Kristian wrote: ... > > Does anyone know off-hand if it is possible to aggregate b/w > reallocation requests for multiple Target TLVs in the same ANCP message? > I can check myself, I was just wondering if someone knows off-hand. > > Thanks, > kris >... From Kristian.Poscic@alcatel-lucent.com Thu Apr 1 19:31:24 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8520C3A69C1 for ; Thu, 1 Apr 2010 19:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.575 X-Spam-Level: X-Spam-Status: No, score=0.575 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 0CBC3ywiKt0f for ; Thu, 1 Apr 2010 19:31:23 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 714443A6A5E for ; Thu, 1 Apr 2010 19:30:38 -0700 (PDT) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o322VATT016552; Thu, 1 Apr 2010 21:31:10 -0500 (CDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.pdc.alcatel-lucent.com [172.22.216.13]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o322V9vu021156; Thu, 1 Apr 2010 21:31:09 -0500 (CDT) Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 21:31:09 -0500 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.11]) by USDALSMBS01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 21:30:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 21:30:16 -0500 Message-ID: <41B3B178A129B6458752EC1B4D14998C03BC250B@USDALSMBS04.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] (no subject) Thread-Index: AcrSCins+LXFb6P4RqSqh/MG1VVNiAAAJF+g References: <945527.34063.qm@web113808.mail.gq1.yahoo.com> <41B3B178A129B6458752EC1B4D14998C03BC24D3@USDALSMBS04.ad3.ad.alcatel.com> From: "POSCIC Kristian" To: "Tom Taylor" X-OriginalArrivalTime: 02 Apr 2010 02:30:27.0460 (UTC) FILETIME=[74CE5440:01CAD20C] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 02:31:24 -0000 Tom - a different allocation to each Target TLV. For example in PON deployments. Multiple subscribers will reside on the same PON. So you would need to do the AC for a subscriber (one Target TLV) and then possibly per PON on which the subscriber resides (another TLV) and then possibly a third reallocation request for the uplink towards the NAS ( another Target TLV). All come down as one request to the OLT which is managing AC (all three entities are visible there - PON, subscriber(s) on the PON and the uplink towards the NAS).=20 I guess for this we can send three separate reallocation request messages that are contained in a single ANCP packet. A more optimal way would be to allow single reallocation request messages with (target, bw) pairs - but I don't even want to go there :). =20 Thanks, Kris=20 -----Original Message----- From: Tom Taylor [mailto:tom111.taylor@bell.net]=20 Sent: Thursday, April 01, 2010 7:14 PM To: POSCIC Kristian Cc: Francois Le Faucheur; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] (no subject) Can't do that until Target with multiple instances is defined. Even then, the=20 question becomes one of whether you would give the same allocation to every port. POSCIC Kristian wrote: ... >=20 > Does anyone know off-hand if it is possible to aggregate b/w > reallocation requests for multiple Target TLVs in the same ANCP message? > I can check myself, I was just wondering if someone knows off-hand. >=20 > Thanks, > kris=20 >... From swadhwa01@yahoo.com Fri Apr 2 21:35:42 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B27D3A6991 for ; Fri, 2 Apr 2010 21:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.648 X-Spam-Level: * X-Spam-Status: No, score=1.648 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 lnu+VdlYiHkC for ; Fri, 2 Apr 2010 21:35:40 -0700 (PDT) Received: from n1-vm0.bullet.mail.gq1.yahoo.com (n1-vm0.bullet.mail.gq1.yahoo.com [67.195.23.152]) by core3.amsl.com (Postfix) with SMTP id 373953A6863 for ; Fri, 2 Apr 2010 21:35:40 -0700 (PDT) Received: from [98.137.27.132] by n1.bullet.mail.gq1.yahoo.com with NNFMP; 03 Apr 2010 04:35:37 -0000 Received: from [98.137.27.222] by t4.bullet.mail.gq1.yahoo.com with NNFMP; 03 Apr 2010 04:35:37 -0000 Received: from [127.0.0.1] by omp132.mail.gq1.yahoo.com with NNFMP; 03 Apr 2010 04:35:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 14978.27572.bm@omp132.mail.gq1.yahoo.com Received: (qmail 20680 invoked by uid 60001); 3 Apr 2010 04:35:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270269336; bh=+Gb5X+XLHBCjpzr/ycZYDaqTEekWtIDaTVARHp28Jqc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CeA2wKPNz8pZPriK6hhf0YCnvK931RRy8XEc6/dNC8RyksUjwNN5ZlLWyt5Z/bAJddZ/BwKLL7weO4PRe/AInliE08ITu4um1T5frk7npB8WsC0PKl9RLTv6ihK+iBi+PdC6M6xFzKeFEiwljdxVyAY4lKK6G/oTNmJqNuEMOmg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yUdQcxuPv3bMALu6pN6/gAUh8t4GyqLOtyJVjm48dNHGRW2CCq98xyhOvYO29YhaxvXdnuZeMPog7ywgyevCqpWSpvRPhQ0XnBPpfLW9qii/i614mb2/YmQtjxXVAX2ZZgD9+jWn52F9cD8TWZCoGcdoU4+UBKQcVXn4FX0FT8U=; Message-ID: <813121.18910.qm@web113814.mail.gq1.yahoo.com> X-YMail-OSG: zlcPdOgVM1l_S9GhnlvCZBTEzNCX.5NKWaaC5qmX8UYXFsE ASVS1Pz8YGXmpXuzIlZtncjSVtlvBHFUxW5g3S.Lcn15qj92nAyc0bnhs7AJ 93t3AzGL9d2E60TZWyRcgamt0Ej4ZjvIWLksymM3RK998wPwo20ONxRev4jn 6fxIXsI.WWgjsl221ItS7m7d7JqMdRZ8hghk1sBH.TDTqyMewK5oF02K9FtC k.bFUp8JKa7PBRNaI9hWT0QmbGlFaJCXOa_s3aREwe8OIlrmP38TiiXi3kDL 856be3YK3XEKwnJDCS39ANI51Hr4WIJ4o_2bMXxgvl5AruEzTr0E9aQnS.Ws vvt78D81YH.l37gWV07AfNMSzT4luvXDuWhyfeQ-- Received: from [66.129.232.2] by web113814.mail.gq1.yahoo.com via HTTP; Fri, 02 Apr 2010 21:35:36 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Fri, 2 Apr 2010 21:35:36 -0700 (PDT) From: Sanjay Wadhwa To: Francois Le Faucheur In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1514962941-1270269336=:18910" Cc: Kristian.Poscic@alcatel-lucent.com, ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 04:35:42 -0000 --0-1514962941-1270269336=:18910 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Francois, Kris =C2=A0 What is needed depends on at least two key variables: =C2=A0 1. How dynamic do you want the per-subscriber bandwidth management a= cross different traffic types to be. This includes managed VOD, multicast a= nd best-effort traffic.=20 =C2=A0 2. Where do you want the unified bandwidth admission control across = multicast and managed VOD to happen (AN or NAS).=20 We can consider most optimal interactions based on the model chosen. Howeve= r, the protocol needs to allow all variations. Now, specific to your examples, you have assumed in bandwidth delegation mo= del that no minimal initial bandwidth is delegated to AN, which doesn't nee= d to be the case. In your second example you are allocating in initial amount of bandwidth de= legated to AN (perhaps due to dynamic updates of allocated b/w you assume i= t is ok). However, based on reported bandwidth utilization from AN, the NAS= could use the available bandwidth for unicast traffic (including best-effo= rt). Next time around when AN gets a request for higher bandwidth=C2=A0 mul= ticast channel, it can't assume bandwidth is available, and should update N= AS before replicating. I don't see specific advantage/optimality with the s= econd example. Based on Kris's questions I am extrapolating the model in question is the f= ollowing: =C2=A0 1. AN manages assigned video bandwidth and does unified bandwidth ad= mission control (AC) against it. =C2=A0 2. AN terminates per-subscriber multicast and replicates based on an= admission control decision. =C2=A0 3. When VOD request needs to be admitted, policy server through NAS = queries available bandwidth on the AN. This is a reverse AC request (from N= AS to AN for unicast video). If bandwidth is available, VOD flow is admitte= d by NAS. AN always has the latest view of available bandwidth. Making AC r= equest/response bidirectional and specifying bandwidth value in AC request = can accomodate this interaction. =C2=A0 4. AN notifies NAS of bandwidth allocations for multicast, so NAS ca= n adjust bandwidth for unicast (e.g. best-effort) traffic accordingly. Howe= ver, if AN needs to inform NAS to adjust bandwidth for unicast (best-effort= ) traffic lower (due to say a SD->HD multicast leave/join sequence), it doe= s need to send a request to NAS and ideally wait for a response before repl= icating. This round-trip is not avoidable if one wants the most =C2=A0=C2= =A0=C2=A0=C2=A0 dynamic/optimal bandwidth usage, where unicast best-effort = traffic could utilize unused available video bandwidth and get throttled do= wn when multicast needs the bandwidth (ofcourse this is dependent on how op= erator wants to manage subscriber's bandwdith). For this interaction either= a new "bandwidth reporitng" message or a sub-type of an existing message c= an be used. -Sanjay ps. The model where unified AC happens on NAS has its own benefits (e.g. si= mplicity), so not necessarily advocating the above model with AN based AC, = but we need to accommodate both. --- On Thu, 4/1/10, Francois Le Faucheur wrote: From: Francois Le Faucheur Subject: Re: To: "Sanjay Wadhwa" Cc: "Francois Le Faucheur" , Kristian.Poscic@alcatel-lu= cent.com, ancp@ietf.org Date: Thursday, April 1, 2010, 10:02 AM Hi Sanjay, On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote: >=20 > [SW] The scenario above, where NAS sends the channel on MC-VLAN, assumes = NAS is doing bandwidth based AC. A channel join on AN may trigger an AC req= uest message to NAS, which should trigger a CAC decision and QOS-adjust on = NAS and a response back to AN (before AN can perform replication). Do we ne= ed another bandwidth update message from AN to NAS? In case AN sees a chann= el leave (and no new join for some time) or a user switches from HD to SD, = then AN may decide to notify NAS of released bandwidth. I believe we are ag= ain covered by existing AC request message from AN to NAS (described in mul= ticast extensions draft). If admission control is to be performed by NAS (ie Grey list multicast flow= ), then I agree we are already covered by existing multicast procedures bec= ause the NAS is always fully aware of currently admitted multicast traffic = on a given port. >=20 >=C2=A0 On the other hand if we are assuming bandwidth delegation model and= autonomous AC on AN, That is indeed the case of interest, here. > then we are already covered via interaction related to bandwidth delegati= on between AN and NAS. That was my initial reaction too. Indeed, I think it is possible to stretch= existing bandwidth delegation procedures to achieve this. However this wou= ld result in sub-optimal handling of the new use case. Example call-Flow based on re-using existing bandwidth delegation procedure= s: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D AN <---PORT_MNGT (Bw allocation=3D0Mb/s) --NAS ... (join from subscriber for 2Mb/s multicast flow) AN ---Bandwidth Realloc Request (2Mb/s)--> NAS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0=C2=A0(NAS allocates 2Mb/s) AN <--------Bandwidth Transfer (2Mb/s)-------- NAS (AN starts replicating) ... (leave + join from subscriber for 4Mb/s multicast flow) AN ---Bandwidth Realloc Request (4Mb/s)--> NAS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0=C2=A0(NAS allocates 4Mb/s total) AN <--------Bandwidth Transfer (4Mb/s)-------- NAS (AN starts replicating) Example call-Flow based on new "admitted bandwidth reporting" procedures: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D AN <---PORT_MNGT (Bw allocation=3D4Mb/s) --NAS ... (join from subscriber for 2Mb/s multicast flow) (AN does admission control and starts replicating) AN ------Admitted Bandwidth Report(2Mb/s)---> NAS (leave + join from subscriber for 4Mb/s multicast flow) (AN does admission control and starts replicating) AN ------Admitted Bandwidth Report(4Mb/s)----> NAS So, the sub-optimalities of reusing existing bandwidth delegation procedure= s include: =C2=A0=C2=A0=C2=A0 *a* use of two messages instead of one, for every bandwi= dth change =C2=A0=C2=A0=C2=A0 *b* extra delay on AN (ie need to wait for ANCP round-tr= ip instead of immediately replicate) =C2=A0=C2=A0=C2=A0 *c* unnecessary "bandwidth check" for "reallocation" on = NAS I'd say these sub-optimalities justify a new procedures, but I'm willing to= be convinced otherwise. I suppose one could argue that in the majority of join/leave/join, the band= width does not change (ie zapping among channels of same bandwidth), so the= sub-optimality *a* is only incurred in less common case (leaveSD, joinHD). Thoughts everyone? Francois Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 limit=C3= =A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 = 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 561 RCS = Nanterre, Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =0A=0A=0A --0-1514962941-1270269336=:18910 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Francois, Kris
  What is needed de= pends on at least two key variables:
  1. How dynamic do you want t= he per-subscriber bandwidth management across different traffic types to be= . This includes managed VOD, multicast and best-effort traffic.
  = 2. Where do you want the unified bandwidth admission control across multica= st and managed VOD to happen (AN or NAS).
We can consider most optimal = interactions based on the model chosen. However, the protocol needs to allo= w all variations.

Now, specific to your examples, you have assumed i= n bandwidth delegation model that no minimal initial bandwidth is delegated= to AN, which doesn't need to be the case.
In your second example you ar= e allocating in initial amount of bandwidth delegated to AN (perhaps due to= dynamic updates of allocated b/w you assume it is ok). However, based on reported bandwidth utilization from AN, the NAS could use the available ba= ndwidth for unicast traffic (including best-effort). Next time around when = AN gets a request for higher bandwidth  multicast channel, it can't as= sume bandwidth is available, and should update NAS before replicating. I do= n't see specific advantage/optimality with the second example.

Based= on Kris's questions I am extrapolating the model in question is the follow= ing:

  1. AN manages assigned video bandwidth and does unified = bandwidth admission control (AC) against it.
  2. AN terminates per= -subscriber multicast and replicates based on an admission control decision= .
  3. When VOD request needs to be admitted, policy server through= NAS queries available bandwidth on the AN. This is a reverse AC request (f= rom NAS to AN for unicast video). If bandwidth is available, VOD flow is ad= mitted by NAS. AN always has the latest view of available bandwidth. Making AC request/response bidirectional and specifying bandwidth value in= AC request can accomodate this interaction.
  4. AN notifies NAS o= f bandwidth allocations for multicast, so NAS can adjust bandwidth for unic= ast (e.g. best-effort) traffic accordingly. However, if AN needs to inform = NAS to adjust bandwidth for unicast (best-effort) traffic lower (due to say= a SD->HD multicast leave/join sequence), it does need to send a request= to NAS and ideally wait for a response before replicating. This round-trip= is not avoidable if one wants the most      dynamic/op= timal bandwidth usage, where unicast best-effort traffic could utilize unus= ed available video bandwidth and get throttled down when multicast needs th= e bandwidth (ofcourse this is dependent on how operator wants to manage sub= scriber's bandwdith). For this interaction either a new "bandwidth reporitn= g" message or a sub-type of an existing message can be used.

-Sanjay

ps. The model where unified AC happens on NAS = has its own benefits (e.g. simplicity), so not necessarily advocating the a= bove model with AN based AC, but we need to accommodate both.


--= - On Thu, 4/1/10, Francois Le Faucheur <flefauch@cisco.com>= wrote:

From: Francois Le Faucheur <= flefauch@cisco.com>
Subject: Re:
To: "Sanjay Wadhwa" <swadhwa01= @yahoo.com>
Cc: "Francois Le Faucheur" <flefauch@cisco.com>, Kr= istian.Poscic@alcatel-lucent.com, ancp@ietf.org
Date: Thursday, April 1,= 2010, 10:02 AM

Hi Sanjay,

On 31 Mar= 2010, at 04:40, Sanjay Wadhwa wrote:
>
> [SW] The scenario ab= ove, where NAS sends the channel on MC-VLAN, assumes NAS is doing bandwidth= based AC. A channel join on AN may trigger an AC request message to NAS, which should trigger a CAC decision and QOS-adjust on NAS and a respo= nse back to AN (before AN can perform replication). Do we need another band= width update message from AN to NAS? In case AN sees a channel leave (and n= o new join for some time) or a user switches from HD to SD, then AN may dec= ide to notify NAS of released bandwidth. I believe we are again covered by = existing AC request message from AN to NAS (described in multicast extensio= ns draft).

If admission control is to be performed by NAS (ie Grey l= ist multicast flow), then I agree we are already covered by existing multic= ast procedures because the NAS is always fully aware of currently admitted = multicast traffic on a given port.

>
>  On the other = hand if we are assuming bandwidth delegation model and autonomous AC on AN,=

That is indeed the case of interest, here.

> then we are = already covered via interaction related to bandwidth delegation between AN and NAS.

That was my initial reaction too. Indeed, I thi= nk it is possible to stretch existing bandwidth delegation procedures to ac= hieve this. However this would result in sub-optimal handling of the new us= e case.

Example call-Flow based on re-using existing bandwidth deleg= ation procedures:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AN <---PORT_MNGT (Bw= allocation=3D0Mb/s) --NAS
...
(join from subscriber for 2Mb/s multic= ast flow)
AN ---Bandwidth Realloc Request (2Mb/s)--> NAS
  &n= bsp;                     =                      = ;                    &nbs= p; (NAS allocates 2Mb/s)
AN <--------Bandwidth Transfer (2Mb/s)-= ------- NAS
(AN starts replicating)
...
(leave + join from subscri= ber for 4Mb/s multicast flow)
AN ---Bandwidth Realloc Request (4Mb/s)--> NAS
      &nb= sp;                     &= nbsp;                    =                  (NAS al= locates 4Mb/s total)
AN <--------Bandwidth Transfer (4Mb/s)-------- N= AS
(AN starts replicating)


Example call-Flow based on new "ad= mitted bandwidth reporting" procedures:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AN &l= t;---PORT_MNGT (Bw allocation=3D4Mb/s) --NAS
...
(join from subscribe= r for 2Mb/s multicast flow)
(AN does admission control and starts replic= ating)
AN ------Admitted Bandwidth Report(2Mb/s)---> NAS
(leave + = join from subscriber for 4Mb/s multicast flow)
(AN does admission contro= l and starts replicating)
AN ------Admitted Bandwidth Report(4Mb/s)----&= gt; NAS


So, the sub-optimalities of reusing existing bandwidth delegation procedures inclu= de:
    *a* use of two messages instead of one, for every= bandwidth change
    *b* extra delay on AN (ie need to w= ait for ANCP round-trip instead of immediately replicate)
  &n= bsp; *c* unnecessary "bandwidth check" for "reallocation" on NAS

I'd= say these sub-optimalities justify a new procedures, but I'm willing to be= convinced otherwise.
I suppose one could argue that in the majority of = join/leave/join, the bandwidth does not change (ie zapping among channels o= f same bandwidth), so the sub-optimality *a* is only incurred in less commo= n case (leaveSD, joinHD).

Thoughts everyone?

Francois

=




Francois Le Faucheur
= Distinguished Engineer
Corporate Development
flefauch@cisco.com
Pho= ne: +33 49 723 2619
Mobile: +33 6 19 98 50 90



Cisco Syste= ms France
Greenside
400 Ave de Roumanille
06410 Sophia AntipolisFrance
Cisco.com




T= hink before you print.

This email may contain confidential and privi= leged material for the sole use of the intended recipient. Any review, use,= distribution or disclosure by others is strictly prohibited. If you are no= t the intended recipient (or authorized to receive for the recipient), plea= se contact the sender by reply email and delete all copies of this message.=

Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 l= imit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine = Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 5= 61 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
For corporate legal information go to:
http://www.cisco.com/web/about= /doing_business/legal/cri/index.html



=0A=0A --0-1514962941-1270269336=:18910-- From Kristian.Poscic@alcatel-lucent.com Sun Apr 4 00:02:43 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB01D3A68BA for ; Sun, 4 Apr 2010 00:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-82uwQpJPh6 for ; Sun, 4 Apr 2010 00:02:41 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 9390E3A63EC for ; Sun, 4 Apr 2010 00:02:40 -0700 (PDT) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o3472cQb008372; Sun, 4 Apr 2010 02:02:38 -0500 (CDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.pdc.alcatel-lucent.com [172.22.216.19]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o3472arA023672; Sun, 4 Apr 2010 02:02:36 -0500 (CDT) Received: from USDALSMBS02.ad3.ad.alcatel.com ([172.22.216.10]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 02:02:36 -0500 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.11]) by USDALSMBS02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 02:01:54 -0500 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_01CAD3C4.66C13EC9" Date: Sun, 4 Apr 2010 01:59:37 -0500 Message-ID: <41B3B178A129B6458752EC1B4D14998C03BC259E@USDALSMBS04.ad3.ad.alcatel.com> In-Reply-To: <813121.18910.qm@web113814.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcrS5xz0+4QyakGUS16w5dZoZKRy1gA23W8A References: <813121.18910.qm@web113814.mail.gq1.yahoo.com> From: "POSCIC Kristian" To: "Sanjay Wadhwa" , "Francois Le Faucheur" X-OriginalArrivalTime: 04 Apr 2010 07:01:54.0219 (UTC) FILETIME=[B54C07B0:01CAD3C4] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 07:02:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD3C4.66C13EC9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FuamF5IOKAkyANCg0KSW4gdGhlIG1vZGVsIHRoYXQgSSB3YXMgdGhpbmtpbmcsIHRoZSBz dGVwcyAzIGFuZCA0IGFyZSBsaXR0bGUgYml0IGRpZmZlcmVudDoNCg0KIA0KDQpWaWRlbyBiL3cg dGhhdCBjYW4gYmUgYWxsb2NhdGVkIGluIHRoZSBBTiBpcyBzaGFyZWQgYmV0d2VlbiB0aGUgbWNh c3QgYW5kIFZvRC4gDQoNCjMpIFBvbGljeSBzZXJ2ZXIgbWFrZXMgdGhlIFZPRCBkZWNpc2lvbi4g TkFTIGlzIHRyYW5zcGFyZW50IHRvIHRoaXMuIEl04oCZcyBhY3RpbmcganV0cyBhcyBhbiBpbnRl cm1lZGlhcnkgYmV0d2VlbiB0aGUgcG9saWN5IHNlcnZlciBhbmQgdGhlIEFOLg0KDQo0KSBJZiB0 aGUgYi93IGFza2VkIGJ5IHRoZSBwb2xpY3kgc2VydmVyIGlzIGF2YWlsYWJsZSBpbiB0aGUgQU4s IHRoZSBBTiB3aWxsIHNlbmQgYW4gQUNLIHdoaWNoIHdpbGwgYmUgY29udmV5ZWQgdG8gdGhlIHBv bGljeSBzZXJ2ZXIgdGhyb3VnaCB0aGUgTkFTLiBUaGUgcG9saWN5IHNlcnZlciB3aWxsIGFsbG93 IHRoZSBWT0QgZmxvdyBhbmQgdXBkYXRlIGlzIHJlc291cmNlIHJlc2VydmF0aW9uIHRhYmxlLiBO b3RoaW5nIGVsc2UgaXMgbmVlZGVkLiBUaGUgdW5pY2FzdCBWb0QgZmxvdyB3aWxsIGJlIGF1dG9t YXRpY2FsbHkgYWNjb3VudGVkIGZvciBpbiB0aGUgUW9TIGluIHRoZSBOQVMgYXMgaXQgaXMgZmxv d2luZyB0aHJvdWdoIHRoZSBzdWJzY3JpYmVyIHF1ZXVlcy4NCg0KIA0KDQpCL3cgdXNhZ2UgcmVw b3J0aW5nIGZyb20gdGhlIEFOIHRvIHRoZSBOQVMgaGFzIHRvIGRvIG9ubHkgd2l0aCB0aGUgbXVs dGljYXN0IEFDLg0KDQogDQoNCk9uZSBhbm90aGVyIG5vdGUsIHRoZSBBTkNQIGRyYWZ0IFRhcmdl dCBUTFYgZGVmaW5pdGlvbnMgYXJlIG1vc3RseSBmb2N1c2VkIG9uIERTTEFNIGVudmlyb25tZW50 cy4gQnV0IGluIHRoZSBQT04gZW52aXJvbm1lbnQsIGlmIHdlIG5lZWQgdG8gbWFuYWdlIGIvdyBw ZXIgUE9OLCB1cGxpbmsgYW5kIHRoZSBzdWJzY3JpYmVyLCB3ZeKAmWxsIG5lZWQgMyBUYXJnZXQg VExWcy4gTWF5YmUgdGhpcyB3aWxsIGJlIGRlZmluZWQgaW4gdGhlIGRyYWZ0IHRoYXQgeW91IGFy ZSB3b3JraW5nIG9uIChHUE9OKT8NCg0KIA0KDQpUaGFua3MsDQoNCmtyaXMgDQoNCiANCg0KRnJv bTogU2FuamF5IFdhZGh3YSBbbWFpbHRvOnN3YWRod2EwMUB5YWhvby5jb21dIA0KU2VudDogRnJp ZGF5LCBBcHJpbCAwMiwgMjAxMCA5OjM2IFBNDQpUbzogRnJhbmNvaXMgTGUgRmF1Y2hldXINCkNj OiBGcmFuY29pcyBMZSBGYXVjaGV1cjsgUE9TQ0lDIEtyaXN0aWFuOyBhbmNwQGlldGYub3JnDQpT dWJqZWN0OiBSZToNCg0KIA0KDQpIaSBGcmFuY29pcywgS3Jpcw0KICBXaGF0IGlzIG5lZWRlZCBk ZXBlbmRzIG9uIGF0IGxlYXN0IHR3byBrZXkgdmFyaWFibGVzOg0KICAxLiBIb3cgZHluYW1pYyBk byB5b3Ugd2FudCB0aGUgcGVyLXN1YnNjcmliZXIgYmFuZHdpZHRoIG1hbmFnZW1lbnQgYWNyb3Nz IGRpZmZlcmVudCB0cmFmZmljIHR5cGVzIHRvIGJlLiBUaGlzIGluY2x1ZGVzIG1hbmFnZWQgVk9E LCBtdWx0aWNhc3QgYW5kIGJlc3QtZWZmb3J0IHRyYWZmaWMuIA0KICAyLiBXaGVyZSBkbyB5b3Ug d2FudCB0aGUgdW5pZmllZCBiYW5kd2lkdGggYWRtaXNzaW9uIGNvbnRyb2wgYWNyb3NzIG11bHRp Y2FzdCBhbmQgbWFuYWdlZCBWT0QgdG8gaGFwcGVuIChBTiBvciBOQVMpLiANCldlIGNhbiBjb25z aWRlciBtb3N0IG9wdGltYWwgaW50ZXJhY3Rpb25zIGJhc2VkIG9uIHRoZSBtb2RlbCBjaG9zZW4u IEhvd2V2ZXIsIHRoZSBwcm90b2NvbCBuZWVkcyB0byBhbGxvdyBhbGwgdmFyaWF0aW9ucy4NCg0K Tm93LCBzcGVjaWZpYyB0byB5b3VyIGV4YW1wbGVzLCB5b3UgaGF2ZSBhc3N1bWVkIGluIGJhbmR3 aWR0aCBkZWxlZ2F0aW9uIG1vZGVsIHRoYXQgbm8gbWluaW1hbCBpbml0aWFsIGJhbmR3aWR0aCBp cyBkZWxlZ2F0ZWQgdG8gQU4sIHdoaWNoIGRvZXNuJ3QgbmVlZCB0byBiZSB0aGUgY2FzZS4NCklu IHlvdXIgc2Vjb25kIGV4YW1wbGUgeW91IGFyZSBhbGxvY2F0aW5nIGluIGluaXRpYWwgYW1vdW50 IG9mIGJhbmR3aWR0aCBkZWxlZ2F0ZWQgdG8gQU4gKHBlcmhhcHMgZHVlIHRvIGR5bmFtaWMgdXBk YXRlcyBvZiBhbGxvY2F0ZWQgYi93IHlvdSBhc3N1bWUgaXQgaXMgb2spLiBIb3dldmVyLCBiYXNl ZCBvbiByZXBvcnRlZCBiYW5kd2lkdGggdXRpbGl6YXRpb24gZnJvbSBBTiwgdGhlIE5BUyBjb3Vs ZCB1c2UgdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggZm9yIHVuaWNhc3QgdHJhZmZpYyAoaW5jbHVk aW5nIGJlc3QtZWZmb3J0KS4gTmV4dCB0aW1lIGFyb3VuZCB3aGVuIEFOIGdldHMgYSByZXF1ZXN0 IGZvciBoaWdoZXIgYmFuZHdpZHRoICBtdWx0aWNhc3QgY2hhbm5lbCwgaXQgY2FuJ3QgYXNzdW1l IGJhbmR3aWR0aCBpcyBhdmFpbGFibGUsIGFuZCBzaG91bGQgdXBkYXRlIE5BUyBiZWZvcmUgcmVw bGljYXRpbmcuIEkgZG9uJ3Qgc2VlIHNwZWNpZmljIGFkdmFudGFnZS9vcHRpbWFsaXR5IHdpdGgg dGhlIHNlY29uZCBleGFtcGxlLg0KDQpCYXNlZCBvbiBLcmlzJ3MgcXVlc3Rpb25zIEkgYW0gZXh0 cmFwb2xhdGluZyB0aGUgbW9kZWwgaW4gcXVlc3Rpb24gaXMgdGhlIGZvbGxvd2luZzoNCg0KICAx LiBBTiBtYW5hZ2VzIGFzc2lnbmVkIHZpZGVvIGJhbmR3aWR0aCBhbmQgZG9lcyB1bmlmaWVkIGJh bmR3aWR0aCBhZG1pc3Npb24gY29udHJvbCAoQUMpIGFnYWluc3QgaXQuDQogIDIuIEFOIHRlcm1p bmF0ZXMgcGVyLXN1YnNjcmliZXIgbXVsdGljYXN0IGFuZCByZXBsaWNhdGVzIGJhc2VkIG9uIGFu IGFkbWlzc2lvbiBjb250cm9sIGRlY2lzaW9uLg0KICAzLiBXaGVuIFZPRCByZXF1ZXN0IG5lZWRz IHRvIGJlIGFkbWl0dGVkLCBwb2xpY3kgc2VydmVyIHRocm91Z2ggTkFTIHF1ZXJpZXMgYXZhaWxh YmxlIGJhbmR3aWR0aCBvbiB0aGUgQU4uIFRoaXMgaXMgYSByZXZlcnNlIEFDIHJlcXVlc3QgKGZy b20gTkFTIHRvIEFOIGZvciB1bmljYXN0IHZpZGVvKS4gSWYgYmFuZHdpZHRoIGlzIGF2YWlsYWJs ZSwgVk9EIGZsb3cgaXMgYWRtaXR0ZWQgYnkgTkFTLiBBTiBhbHdheXMgaGFzIHRoZSBsYXRlc3Qg dmlldyBvZiBhdmFpbGFibGUgYmFuZHdpZHRoLiBNYWtpbmcgQUMgcmVxdWVzdC9yZXNwb25zZSBi aWRpcmVjdGlvbmFsIGFuZCBzcGVjaWZ5aW5nIGJhbmR3aWR0aCB2YWx1ZSBpbiBBQyByZXF1ZXN0 IGNhbiBhY2NvbW9kYXRlIHRoaXMgaW50ZXJhY3Rpb24uDQogIDQuIEFOIG5vdGlmaWVzIE5BUyBv ZiBiYW5kd2lkdGggYWxsb2NhdGlvbnMgZm9yIG11bHRpY2FzdCwgc28gTkFTIGNhbiBhZGp1c3Qg YmFuZHdpZHRoIGZvciB1bmljYXN0IChlLmcuIGJlc3QtZWZmb3J0KSB0cmFmZmljIGFjY29yZGlu Z2x5LiBIb3dldmVyLCBpZiBBTiBuZWVkcyB0byBpbmZvcm0gTkFTIHRvIGFkanVzdCBiYW5kd2lk dGggZm9yIHVuaWNhc3QgKGJlc3QtZWZmb3J0KSB0cmFmZmljIGxvd2VyIChkdWUgdG8gc2F5IGEg U0QtPkhEIG11bHRpY2FzdCBsZWF2ZS9qb2luIHNlcXVlbmNlKSwgaXQgZG9lcyBuZWVkIHRvIHNl bmQgYSByZXF1ZXN0IHRvIE5BUyBhbmQgaWRlYWxseSB3YWl0IGZvciBhIHJlc3BvbnNlIGJlZm9y ZSByZXBsaWNhdGluZy4gVGhpcyByb3VuZC10cmlwIGlzIG5vdCBhdm9pZGFibGUgaWYgb25lIHdh bnRzIHRoZSBtb3N0ICAgICAgZHluYW1pYy9vcHRpbWFsIGJhbmR3aWR0aCB1c2FnZSwgd2hlcmUg dW5pY2FzdCBiZXN0LWVmZm9ydCB0cmFmZmljIGNvdWxkIHV0aWxpemUgdW51c2VkIGF2YWlsYWJs ZSB2aWRlbyBiYW5kd2lkdGggYW5kIGdldCB0aHJvdHRsZWQgZG93biB3aGVuIG11bHRpY2FzdCBu ZWVkcyB0aGUgYmFuZHdpZHRoIChvZmNvdXJzZSB0aGlzIGlzIGRlcGVuZGVudCBvbiBob3cgb3Bl cmF0b3Igd2FudHMgdG8gbWFuYWdlIHN1YnNjcmliZXIncyBiYW5kd2RpdGgpLiBGb3IgdGhpcyBp bnRlcmFjdGlvbiBlaXRoZXIgYSBuZXcgImJhbmR3aWR0aCByZXBvcml0bmciIG1lc3NhZ2Ugb3Ig YSBzdWItdHlwZSBvZiBhbiBleGlzdGluZyBtZXNzYWdlIGNhbiBiZSB1c2VkLg0KDQotU2FuamF5 DQoNCnBzLiBUaGUgbW9kZWwgd2hlcmUgdW5pZmllZCBBQyBoYXBwZW5zIG9uIE5BUyBoYXMgaXRz IG93biBiZW5lZml0cyAoZS5nLiBzaW1wbGljaXR5KSwgc28gbm90IG5lY2Vzc2FyaWx5IGFkdm9j YXRpbmcgdGhlIGFib3ZlIG1vZGVsIHdpdGggQU4gYmFzZWQgQUMsIGJ1dCB3ZSBuZWVkIHRvIGFj Y29tbW9kYXRlIGJvdGguDQoNCg0KLS0tIE9uIFRodSwgNC8xLzEwLCBGcmFuY29pcyBMZSBGYXVj aGV1ciA8ZmxlZmF1Y2hAY2lzY28uY29tPiB3cm90ZToNCg0KDQpGcm9tOiBGcmFuY29pcyBMZSBG YXVjaGV1ciA8ZmxlZmF1Y2hAY2lzY28uY29tPg0KU3ViamVjdDogUmU6DQpUbzogIlNhbmpheSBX YWRod2EiIDxzd2FkaHdhMDFAeWFob28uY29tPg0KQ2M6ICJGcmFuY29pcyBMZSBGYXVjaGV1ciIg PGZsZWZhdWNoQGNpc2NvLmNvbT4sIEtyaXN0aWFuLlBvc2NpY0BhbGNhdGVsLWx1Y2VudC5jb20s IGFuY3BAaWV0Zi5vcmcNCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAxLCAyMDEwLCAxMDowMiBBTQ0K DQpIaSBTYW5qYXksDQoNCk9uIDMxIE1hciAyMDEwLCBhdCAwNDo0MCwgU2FuamF5IFdhZGh3YSB3 cm90ZToNCj4gDQo+IFtTV10gVGhlIHNjZW5hcmlvIGFib3ZlLCB3aGVyZSBOQVMgc2VuZHMgdGhl IGNoYW5uZWwgb24gTUMtVkxBTiwgYXNzdW1lcyBOQVMgaXMgZG9pbmcgYmFuZHdpZHRoIGJhc2Vk IEFDLiBBIGNoYW5uZWwgam9pbiBvbiBBTiBtYXkgdHJpZ2dlciBhbiBBQyByZXF1ZXN0IG1lc3Nh Z2UgdG8gTkFTLCB3aGljaCBzaG91bGQgdHJpZ2dlciBhIENBQyBkZWNpc2lvbiBhbmQgUU9TLWFk anVzdCBvbiBOQVMgYW5kIGEgcmVzcG9uc2UgYmFjayB0byBBTiAoYmVmb3JlIEFOIGNhbiBwZXJm b3JtIHJlcGxpY2F0aW9uKS4gRG8gd2UgbmVlZCBhbm90aGVyIGJhbmR3aWR0aCB1cGRhdGUgbWVz c2FnZSBmcm9tIEFOIHRvIE5BUz8gSW4gY2FzZSBBTiBzZWVzIGEgY2hhbm5lbCBsZWF2ZSAoYW5k IG5vIG5ldyBqb2luIGZvciBzb21lIHRpbWUpIG9yIGEgdXNlciBzd2l0Y2hlcyBmcm9tIEhEIHRv IFNELCB0aGVuIEFOIG1heSBkZWNpZGUgdG8gbm90aWZ5IE5BUyBvZiByZWxlYXNlZCBiYW5kd2lk dGguIEkgYmVsaWV2ZSB3ZSBhcmUgYWdhaW4gY292ZXJlZCBieSBleGlzdGluZyBBQyByZXF1ZXN0 IG1lc3NhZ2UgZnJvbSBBTiB0byBOQVMgKGRlc2NyaWJlZCBpbiBtdWx0aWNhc3QgZXh0ZW5zaW9u cyBkcmFmdCkuDQoNCklmIGFkbWlzc2lvbiBjb250cm9sIGlzIHRvIGJlIHBlcmZvcm1lZCBieSBO QVMgKGllIEdyZXkgbGlzdCBtdWx0aWNhc3QgZmxvdyksIHRoZW4gSSBhZ3JlZSB3ZSBhcmUgYWxy ZWFkeSBjb3ZlcmVkIGJ5IGV4aXN0aW5nIG11bHRpY2FzdCBwcm9jZWR1cmVzIGJlY2F1c2UgdGhl IE5BUyBpcyBhbHdheXMgZnVsbHkgYXdhcmUgb2YgY3VycmVudGx5IGFkbWl0dGVkIG11bHRpY2Fz dCB0cmFmZmljIG9uIGEgZ2l2ZW4gcG9ydC4NCg0KPiANCj4gIE9uIHRoZSBvdGhlciBoYW5kIGlm IHdlIGFyZSBhc3N1bWluZyBiYW5kd2lkdGggZGVsZWdhdGlvbiBtb2RlbCBhbmQgYXV0b25vbW91 cyBBQyBvbiBBTiwNCg0KVGhhdCBpcyBpbmRlZWQgdGhlIGNhc2Ugb2YgaW50ZXJlc3QsIGhlcmUu DQoNCj4gdGhlbiB3ZSBhcmUgYWxyZWFkeSBjb3ZlcmVkIHZpYSBpbnRlcmFjdGlvbiByZWxhdGVk IHRvIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIGJldHdlZW4gQU4gYW5kIE5BUy4NCg0KVGhhdCB3YXMg bXkgaW5pdGlhbCByZWFjdGlvbiB0b28uIEluZGVlZCwgSSB0aGluayBpdCBpcyBwb3NzaWJsZSB0 byBzdHJldGNoIGV4aXN0aW5nIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIHByb2NlZHVyZXMgdG8gYWNo aWV2ZSB0aGlzLiBIb3dldmVyIHRoaXMgd291bGQgcmVzdWx0IGluIHN1Yi1vcHRpbWFsIGhhbmRs aW5nIG9mIHRoZSBuZXcgdXNlIGNhc2UuDQoNCkV4YW1wbGUgY2FsbC1GbG93IGJhc2VkIG9uIHJl LXVzaW5nIGV4aXN0aW5nIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIHByb2NlZHVyZXM6DQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KQU4g PC0tLVBPUlRfTU5HVCAoQncgYWxsb2NhdGlvbj0wTWIvcykgLS1OQVMNCi4uLg0KKGpvaW4gZnJv bSBzdWJzY3JpYmVyIGZvciAyTWIvcyBtdWx0aWNhc3QgZmxvdykNCkFOIC0tLUJhbmR3aWR0aCBS ZWFsbG9jIFJlcXVlc3QgKDJNYi9zKS0tPiBOQVMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoTkFTIGFsbG9jYXRlcyAy TWIvcykNCkFOIDwtLS0tLS0tLUJhbmR3aWR0aCBUcmFuc2ZlciAoMk1iL3MpLS0tLS0tLS0gTkFT DQooQU4gc3RhcnRzIHJlcGxpY2F0aW5nKQ0KLi4uDQoobGVhdmUgKyBqb2luIGZyb20gc3Vic2Ny aWJlciBmb3IgNE1iL3MgbXVsdGljYXN0IGZsb3cpDQpBTiAtLS1CYW5kd2lkdGggUmVhbGxvYyBS ZXF1ZXN0ICg0TWIvcyktLT4gTkFTDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5BUyBhbGxvY2F0ZXMgNE1iL3MgdG90 YWwpDQpBTiA8LS0tLS0tLS1CYW5kd2lkdGggVHJhbnNmZXIgKDRNYi9zKS0tLS0tLS0tIE5BUw0K KEFOIHN0YXJ0cyByZXBsaWNhdGluZykNCg0KDQpFeGFtcGxlIGNhbGwtRmxvdyBiYXNlZCBvbiBu ZXcgImFkbWl0dGVkIGJhbmR3aWR0aCByZXBvcnRpbmciIHByb2NlZHVyZXM6DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkFOIDwtLS1Q T1JUX01OR1QgKEJ3IGFsbG9jYXRpb249NE1iL3MpIC0tTkFTDQouLi4NCihqb2luIGZyb20gc3Vi c2NyaWJlciBmb3IgMk1iL3MgbXVsdGljYXN0IGZsb3cpDQooQU4gZG9lcyBhZG1pc3Npb24gY29u dHJvbCBhbmQgc3RhcnRzIHJlcGxpY2F0aW5nKQ0KQU4gLS0tLS0tQWRtaXR0ZWQgQmFuZHdpZHRo IFJlcG9ydCgyTWIvcyktLS0+IE5BUw0KKGxlYXZlICsgam9pbiBmcm9tIHN1YnNjcmliZXIgZm9y IDRNYi9zIG11bHRpY2FzdCBmbG93KQ0KKEFOIGRvZXMgYWRtaXNzaW9uIGNvbnRyb2wgYW5kIHN0 YXJ0cyByZXBsaWNhdGluZykNCkFOIC0tLS0tLUFkbWl0dGVkIEJhbmR3aWR0aCBSZXBvcnQoNE1i L3MpLS0tLT4gTkFTDQoNCg0KU28sIHRoZSBzdWItb3B0aW1hbGl0aWVzIG9mIHJldXNpbmcgZXhp c3RpbmcgYmFuZHdpZHRoIGRlbGVnYXRpb24gcHJvY2VkdXJlcyBpbmNsdWRlOg0KICAgICphKiB1 c2Ugb2YgdHdvIG1lc3NhZ2VzIGluc3RlYWQgb2Ygb25lLCBmb3IgZXZlcnkgYmFuZHdpZHRoIGNo YW5nZQ0KICAgICpiKiBleHRyYSBkZWxheSBvbiBBTiAoaWUgbmVlZCB0byB3YWl0IGZvciBBTkNQ IHJvdW5kLXRyaXAgaW5zdGVhZCBvZiBpbW1lZGlhdGVseSByZXBsaWNhdGUpDQogICAgKmMqIHVu bmVjZXNzYXJ5ICJiYW5kd2lkdGggY2hlY2siIGZvciAicmVhbGxvY2F0aW9uIiBvbiBOQVMNCg0K SSdkIHNheSB0aGVzZSBzdWItb3B0aW1hbGl0aWVzIGp1c3RpZnkgYSBuZXcgcHJvY2VkdXJlcywg YnV0IEknbSB3aWxsaW5nIHRvIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuDQpJIHN1cHBvc2Ugb25l IGNvdWxkIGFyZ3VlIHRoYXQgaW4gdGhlIG1ham9yaXR5IG9mIGpvaW4vbGVhdmUvam9pbiwgdGhl IGJhbmR3aWR0aCBkb2VzIG5vdCBjaGFuZ2UgKGllIHphcHBpbmcgYW1vbmcgY2hhbm5lbHMgb2Yg c2FtZSBiYW5kd2lkdGgpLCBzbyB0aGUgc3ViLW9wdGltYWxpdHkgKmEqIGlzIG9ubHkgaW5jdXJy ZWQgaW4gbGVzcyBjb21tb24gY2FzZSAobGVhdmVTRCwgam9pbkhEKS4NCg0KVGhvdWdodHMgZXZl cnlvbmU/DQoNCkZyYW5jb2lzDQoNCg0KDQoNCg0KDQoNCkZyYW5jb2lzIExlIEZhdWNoZXVyDQpE aXN0aW5ndWlzaGVkIEVuZ2luZWVyDQpDb3Jwb3JhdGUgRGV2ZWxvcG1lbnQNCmZsZWZhdWNoQGNp c2NvLmNvbQ0KUGhvbmU6ICszMyA0OSA3MjMgMjYxOQ0KTW9iaWxlOiArMzMgNiAxOSA5OCA1MCA5 MA0KDQoNCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UNCkdyZWVuc2lkZQ0KNDAwIEF2ZSBkZSBSb3Vt YW5pbGxlDQowNjQxMCBTb3BoaWEgQW50aXBvbGlzDQpGcmFuY2UNCkNpc2NvLmNvbQ0KDQoNCg0K DQoNClRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuDQoNClRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlz Y2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUg cmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQg ZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLg0KDQpDaXNjbyBTeXN0ZW1zIEZyYW5j ZSwgU29jacOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZSBEZXNt b3VsaW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5 IGxlcyBNb3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJD UyBOYW50ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwg R2l2b25lLg0KDQpGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KaHR0cDov L3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5o dG1sDQoNCg0KDQogDQoNCg== ------_=_NextPart_001_01CAD3C4.66C13EC9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlv bjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9 RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5IaSBTYW5qYXkg4oCT IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5JbiB0aGUgbW9kZWwgdGhhdCBJIHdhcyB0aGlua2luZywgdGhlIHN0ZXBz IDMgYW5kIDQgYXJlIGxpdHRsZQ0KYml0IGRpZmZlcmVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPlZpZGVvIGIvdyB0aGF0IGNhbiBiZSBhbGxvY2F0ZWQgaW4gdGhlIEFOIGlzIHNo YXJlZCBiZXR3ZWVuIHRoZQ0KbWNhc3QgYW5kIFZvRC4gPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjMpIFBvbGljeSBz ZXJ2ZXIgbWFrZXMgdGhlIFZPRCBkZWNpc2lvbi4gTkFTIGlzIHRyYW5zcGFyZW50IHRvDQp0aGlz LiBJdOKAmXMgYWN0aW5nIGp1dHMgYXMgYW4gaW50ZXJtZWRpYXJ5IGJldHdlZW4gdGhlIHBvbGlj eSBzZXJ2ZXIgYW5kIHRoZSBBTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+NCkgSWYgdGhlIGIvdyBhc2tlZCBieSB0 aGUgcG9saWN5IHNlcnZlciBpcyBhdmFpbGFibGUgaW4gdGhlIEFOLA0KdGhlIEFOIHdpbGwgc2Vu ZCBhbiBBQ0sgd2hpY2ggd2lsbCBiZSBjb252ZXllZCB0byB0aGUgcG9saWN5IHNlcnZlciB0aHJv dWdoIHRoZQ0KTkFTLiBUaGUgcG9saWN5IHNlcnZlciB3aWxsIGFsbG93IHRoZSBWT0QgZmxvdyBh bmQgdXBkYXRlIGlzIHJlc291cmNlDQpyZXNlcnZhdGlvbiB0YWJsZS4gTm90aGluZyBlbHNlIGlz IG5lZWRlZC4gVGhlIHVuaWNhc3QgVm9EIGZsb3cgd2lsbCBiZQ0KYXV0b21hdGljYWxseSBhY2Nv dW50ZWQgZm9yIGluIHRoZSBRb1MgaW4gdGhlIE5BUyBhcyBpdCBpcyBmbG93aW5nIHRocm91Z2gg dGhlDQpzdWJzY3JpYmVyIHF1ZXVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkIv dyB1c2FnZSByZXBvcnRpbmcgZnJvbSB0aGUgQU4gdG8gdGhlIE5BUyBoYXMgdG8gZG8gb25seSB3 aXRoDQp0aGUgbXVsdGljYXN0IEFDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+T25l IGFub3RoZXIgbm90ZSwgdGhlIEFOQ1AgZHJhZnQgVGFyZ2V0IFRMViBkZWZpbml0aW9ucyBhcmUg bW9zdGx5DQpmb2N1c2VkIG9uIERTTEFNIGVudmlyb25tZW50cy4gQnV0IGluIHRoZSBQT04gZW52 aXJvbm1lbnQsIGlmIHdlIG5lZWQgdG8gbWFuYWdlDQpiL3cgcGVyIFBPTiwgdXBsaW5rIGFuZCB0 aGUgc3Vic2NyaWJlciwgd2XigJlsbCBuZWVkIDMgVGFyZ2V0IFRMVnMuIE1heWJlIHRoaXMgd2ls bA0KYmUgZGVmaW5lZCBpbiB0aGUgZHJhZnQgdGhhdCB5b3UgYXJlIHdvcmtpbmcgb24gKEdQT04p PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5rcmlz IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBTYW5qYXkgV2FkaHdhDQpbbWFpbHRvOnN3YWRod2EwMUB5YWhvby5j b21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDAyLCAyMDEwIDk6MzYgUE08YnI+ DQo8Yj5Ubzo8L2I+IEZyYW5jb2lzIExlIEZhdWNoZXVyPGJyPg0KPGI+Q2M6PC9iPiBGcmFuY29p cyBMZSBGYXVjaGV1cjsgUE9TQ0lDIEtyaXN0aWFuOyBhbmNwQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHRhYmxlIGNsYXNzPU1zb05vcm1h bFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MD4NCiA8dHI+DQogIDx0 ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+DQogIDxwIGNsYXNz PU1zb05vcm1hbD5IaSBGcmFuY29pcywgS3Jpczxicj4NCiAgJm5ic3A7IFdoYXQgaXMgbmVlZGVk IGRlcGVuZHMgb24gYXQgbGVhc3QgdHdvIGtleSB2YXJpYWJsZXM6PGJyPg0KICAmbmJzcDsgMS4g SG93IGR5bmFtaWMgZG8geW91IHdhbnQgdGhlIHBlci1zdWJzY3JpYmVyIGJhbmR3aWR0aCBtYW5h Z2VtZW50DQogIGFjcm9zcyBkaWZmZXJlbnQgdHJhZmZpYyB0eXBlcyB0byBiZS4gVGhpcyBpbmNs dWRlcyBtYW5hZ2VkIFZPRCwgbXVsdGljYXN0DQogIGFuZCBiZXN0LWVmZm9ydCB0cmFmZmljLiA8 YnI+DQogICZuYnNwOyAyLiBXaGVyZSBkbyB5b3Ugd2FudCB0aGUgdW5pZmllZCBiYW5kd2lkdGgg YWRtaXNzaW9uIGNvbnRyb2wgYWNyb3NzDQogIG11bHRpY2FzdCBhbmQgbWFuYWdlZCBWT0QgdG8g aGFwcGVuIChBTiBvciBOQVMpLiA8YnI+DQogIFdlIGNhbiBjb25zaWRlciBtb3N0IG9wdGltYWwg aW50ZXJhY3Rpb25zIGJhc2VkIG9uIHRoZSBtb2RlbCBjaG9zZW4uIEhvd2V2ZXIsDQogIHRoZSBw cm90b2NvbCBuZWVkcyB0byBhbGxvdyBhbGwgdmFyaWF0aW9ucy48YnI+DQogIDxicj4NCiAgTm93 LCBzcGVjaWZpYyB0byB5b3VyIGV4YW1wbGVzLCB5b3UgaGF2ZSBhc3N1bWVkIGluIGJhbmR3aWR0 aCBkZWxlZ2F0aW9uDQogIG1vZGVsIHRoYXQgbm8gbWluaW1hbCBpbml0aWFsIGJhbmR3aWR0aCBp cyBkZWxlZ2F0ZWQgdG8gQU4sIHdoaWNoIGRvZXNuJ3QNCiAgbmVlZCB0byBiZSB0aGUgY2FzZS48 YnI+DQogIEluIHlvdXIgc2Vjb25kIGV4YW1wbGUgeW91IGFyZSBhbGxvY2F0aW5nIGluIGluaXRp YWwgYW1vdW50IG9mIGJhbmR3aWR0aA0KICBkZWxlZ2F0ZWQgdG8gQU4gKHBlcmhhcHMgZHVlIHRv IGR5bmFtaWMgdXBkYXRlcyBvZiBhbGxvY2F0ZWQgYi93IHlvdSBhc3N1bWUNCiAgaXQgaXMgb2sp LiBIb3dldmVyLCBiYXNlZCBvbiByZXBvcnRlZCBiYW5kd2lkdGggdXRpbGl6YXRpb24gZnJvbSBB TiwgdGhlIE5BUw0KICBjb3VsZCB1c2UgdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggZm9yIHVuaWNh c3QgdHJhZmZpYyAoaW5jbHVkaW5nDQogIGJlc3QtZWZmb3J0KS4gTmV4dCB0aW1lIGFyb3VuZCB3 aGVuIEFOIGdldHMgYSByZXF1ZXN0IGZvciBoaWdoZXINCiAgYmFuZHdpZHRoJm5ic3A7IG11bHRp Y2FzdCBjaGFubmVsLCBpdCBjYW4ndCBhc3N1bWUgYmFuZHdpZHRoIGlzIGF2YWlsYWJsZSwNCiAg YW5kIHNob3VsZCB1cGRhdGUgTkFTIGJlZm9yZSByZXBsaWNhdGluZy4gSSBkb24ndCBzZWUgc3Bl Y2lmaWMNCiAgYWR2YW50YWdlL29wdGltYWxpdHkgd2l0aCB0aGUgc2Vjb25kIGV4YW1wbGUuPGJy Pg0KICA8YnI+DQogIEJhc2VkIG9uIEtyaXMncyBxdWVzdGlvbnMgSSBhbSBleHRyYXBvbGF0aW5n IHRoZSBtb2RlbCBpbiBxdWVzdGlvbiBpcyB0aGUNCiAgZm9sbG93aW5nOjxicj4NCiAgPGJyPg0K ICAmbmJzcDsgMS4gQU4gbWFuYWdlcyBhc3NpZ25lZCB2aWRlbyBiYW5kd2lkdGggYW5kIGRvZXMg dW5pZmllZCBiYW5kd2lkdGgNCiAgYWRtaXNzaW9uIGNvbnRyb2wgKEFDKSBhZ2FpbnN0IGl0Ljxi cj4NCiAgJm5ic3A7IDIuIEFOIHRlcm1pbmF0ZXMgcGVyLXN1YnNjcmliZXIgbXVsdGljYXN0IGFu ZCByZXBsaWNhdGVzIGJhc2VkIG9uIGFuDQogIGFkbWlzc2lvbiBjb250cm9sIGRlY2lzaW9uLjxi cj4NCiAgJm5ic3A7IDMuIFdoZW4gVk9EIHJlcXVlc3QgbmVlZHMgdG8gYmUgYWRtaXR0ZWQsIHBv bGljeSBzZXJ2ZXIgdGhyb3VnaCBOQVMNCiAgcXVlcmllcyBhdmFpbGFibGUgYmFuZHdpZHRoIG9u IHRoZSBBTi4gVGhpcyBpcyBhIHJldmVyc2UgQUMgcmVxdWVzdCAoZnJvbSBOQVMNCiAgdG8gQU4g Zm9yIHVuaWNhc3QgdmlkZW8pLiBJZiBiYW5kd2lkdGggaXMgYXZhaWxhYmxlLCBWT0QgZmxvdyBp cyBhZG1pdHRlZCBieQ0KICBOQVMuIEFOIGFsd2F5cyBoYXMgdGhlIGxhdGVzdCB2aWV3IG9mIGF2 YWlsYWJsZSBiYW5kd2lkdGguIE1ha2luZyBBQw0KICByZXF1ZXN0L3Jlc3BvbnNlIGJpZGlyZWN0 aW9uYWwgYW5kIHNwZWNpZnlpbmcgYmFuZHdpZHRoIHZhbHVlIGluIEFDIHJlcXVlc3QNCiAgY2Fu IGFjY29tb2RhdGUgdGhpcyBpbnRlcmFjdGlvbi48YnI+DQogICZuYnNwOyA0LiBBTiBub3RpZmll cyBOQVMgb2YgYmFuZHdpZHRoIGFsbG9jYXRpb25zIGZvciBtdWx0aWNhc3QsIHNvIE5BUyBjYW4N CiAgYWRqdXN0IGJhbmR3aWR0aCBmb3IgdW5pY2FzdCAoZS5nLiBiZXN0LWVmZm9ydCkgdHJhZmZp YyBhY2NvcmRpbmdseS4gSG93ZXZlciwNCiAgaWYgQU4gbmVlZHMgdG8gaW5mb3JtIE5BUyB0byBh ZGp1c3QgYmFuZHdpZHRoIGZvciB1bmljYXN0IChiZXN0LWVmZm9ydCkNCiAgdHJhZmZpYyBsb3dl ciAoZHVlIHRvIHNheSBhIFNELSZndDtIRCBtdWx0aWNhc3QgbGVhdmUvam9pbiBzZXF1ZW5jZSks IGl0IGRvZXMNCiAgbmVlZCB0byBzZW5kIGEgcmVxdWVzdCB0byBOQVMgYW5kIGlkZWFsbHkgd2Fp dCBmb3IgYSByZXNwb25zZSBiZWZvcmUNCiAgcmVwbGljYXRpbmcuIFRoaXMgcm91bmQtdHJpcCBp cyBub3QgYXZvaWRhYmxlIGlmIG9uZSB3YW50cyB0aGUgbW9zdCAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCiAgZHluYW1pYy9vcHRpbWFsIGJhbmR3aWR0aCB1c2FnZSwgd2hlcmUgdW5pY2FzdCBi ZXN0LWVmZm9ydCB0cmFmZmljIGNvdWxkDQogIHV0aWxpemUgdW51c2VkIGF2YWlsYWJsZSB2aWRl byBiYW5kd2lkdGggYW5kIGdldCB0aHJvdHRsZWQgZG93biB3aGVuDQogIG11bHRpY2FzdCBuZWVk cyB0aGUgYmFuZHdpZHRoIChvZmNvdXJzZSB0aGlzIGlzIGRlcGVuZGVudCBvbiBob3cgb3BlcmF0 b3INCiAgd2FudHMgdG8gbWFuYWdlIHN1YnNjcmliZXIncyBiYW5kd2RpdGgpLiBGb3IgdGhpcyBp bnRlcmFjdGlvbiBlaXRoZXIgYSBuZXcNCiAgJnF1b3Q7YmFuZHdpZHRoIHJlcG9yaXRuZyZxdW90 OyBtZXNzYWdlIG9yIGEgc3ViLXR5cGUgb2YgYW4gZXhpc3RpbmcgbWVzc2FnZQ0KICBjYW4gYmUg dXNlZC48YnI+DQogIDxicj4NCiAgLVNhbmpheTxicj4NCiAgPGJyPg0KICBwcy4gVGhlIG1vZGVs IHdoZXJlIHVuaWZpZWQgQUMgaGFwcGVucyBvbiBOQVMgaGFzIGl0cyBvd24gYmVuZWZpdHMgKGUu Zy4NCiAgc2ltcGxpY2l0eSksIHNvIG5vdCBuZWNlc3NhcmlseSBhZHZvY2F0aW5nIHRoZSBhYm92 ZSBtb2RlbCB3aXRoIEFOIGJhc2VkIEFDLA0KICBidXQgd2UgbmVlZCB0byBhY2NvbW1vZGF0ZSBi b3RoLjxicj4NCiAgPGJyPg0KICA8YnI+DQogIC0tLSBPbiA8Yj5UaHUsIDQvMS8xMCwgRnJhbmNv aXMgTGUgRmF1Y2hldXIgPGk+Jmx0O2ZsZWZhdWNoQGNpc2NvLmNvbSZndDs8L2k+PC9iPg0KICB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+PGJyPg0KICBGcm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1ciAmbHQ7Zmxl ZmF1Y2hAY2lzY28uY29tJmd0Ozxicj4NCiAgU3ViamVjdDogUmU6PGJyPg0KICBUbzogJnF1b3Q7 U2FuamF5IFdhZGh3YSZxdW90OyAmbHQ7c3dhZGh3YTAxQHlhaG9vLmNvbSZndDs8YnI+DQogIENj OiAmcXVvdDtGcmFuY29pcyBMZSBGYXVjaGV1ciZxdW90OyAmbHQ7ZmxlZmF1Y2hAY2lzY28uY29t Jmd0OywNCiAgS3Jpc3RpYW4uUG9zY2ljQGFsY2F0ZWwtbHVjZW50LmNvbSwgYW5jcEBpZXRmLm9y Zzxicj4NCiAgRGF0ZTogVGh1cnNkYXksIEFwcmlsIDEsIDIwMTAsIDEwOjAyIEFNPG86cD48L286 cD48L3A+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQnPkhpIFNhbmpheSw8YnI+DQogIDxicj4NCiAgT24gMzEgTWFyIDIwMTAsIGF0IDA0 OjQwLCBTYW5qYXkgV2FkaHdhIHdyb3RlOjxicj4NCiAgJmd0OyA8YnI+DQogICZndDsgW1NXXSBU aGUgc2NlbmFyaW8gYWJvdmUsIHdoZXJlIE5BUyBzZW5kcyB0aGUgY2hhbm5lbCBvbiBNQy1WTEFO LCBhc3N1bWVzDQogIE5BUyBpcyBkb2luZyBiYW5kd2lkdGggYmFzZWQgQUMuIEEgY2hhbm5lbCBq b2luIG9uIEFOIG1heSB0cmlnZ2VyIGFuIEFDDQogIHJlcXVlc3QgbWVzc2FnZSB0byBOQVMsIHdo aWNoIHNob3VsZCB0cmlnZ2VyIGEgQ0FDIGRlY2lzaW9uIGFuZCBRT1MtYWRqdXN0IG9uDQogIE5B UyBhbmQgYSByZXNwb25zZSBiYWNrIHRvIEFOIChiZWZvcmUgQU4gY2FuIHBlcmZvcm0gcmVwbGlj YXRpb24pLiBEbyB3ZSBuZWVkDQogIGFub3RoZXIgYmFuZHdpZHRoIHVwZGF0ZSBtZXNzYWdlIGZy b20gQU4gdG8gTkFTPyBJbiBjYXNlIEFOIHNlZXMgYSBjaGFubmVsDQogIGxlYXZlIChhbmQgbm8g bmV3IGpvaW4gZm9yIHNvbWUgdGltZSkgb3IgYSB1c2VyIHN3aXRjaGVzIGZyb20gSEQgdG8gU0Qs IHRoZW4NCiAgQU4gbWF5IGRlY2lkZSB0byBub3RpZnkgTkFTIG9mIHJlbGVhc2VkIGJhbmR3aWR0 aC4gSSBiZWxpZXZlIHdlIGFyZSBhZ2Fpbg0KICBjb3ZlcmVkIGJ5IGV4aXN0aW5nIEFDIHJlcXVl c3QgbWVzc2FnZSBmcm9tIEFOIHRvIE5BUyAoZGVzY3JpYmVkIGluIG11bHRpY2FzdA0KICBleHRl bnNpb25zIGRyYWZ0KS48YnI+DQogIDxicj4NCiAgSWYgYWRtaXNzaW9uIGNvbnRyb2wgaXMgdG8g YmUgcGVyZm9ybWVkIGJ5IE5BUyAoaWUgR3JleSBsaXN0IG11bHRpY2FzdCBmbG93KSwNCiAgdGhl biBJIGFncmVlIHdlIGFyZSBhbHJlYWR5IGNvdmVyZWQgYnkgZXhpc3RpbmcgbXVsdGljYXN0IHBy b2NlZHVyZXMgYmVjYXVzZQ0KICB0aGUgTkFTIGlzIGFsd2F5cyBmdWxseSBhd2FyZSBvZiBjdXJy ZW50bHkgYWRtaXR0ZWQgbXVsdGljYXN0IHRyYWZmaWMgb24gYQ0KICBnaXZlbiBwb3J0Ljxicj4N CiAgPGJyPg0KICAmZ3Q7IDxicj4NCiAgJmd0OyZuYnNwOyBPbiB0aGUgb3RoZXIgaGFuZCBpZiB3 ZSBhcmUgYXNzdW1pbmcgYmFuZHdpZHRoIGRlbGVnYXRpb24gbW9kZWwNCiAgYW5kIGF1dG9ub21v dXMgQUMgb24gQU4sPGJyPg0KICA8YnI+DQogIFRoYXQgaXMgaW5kZWVkIHRoZSBjYXNlIG9mIGlu dGVyZXN0LCBoZXJlLjxicj4NCiAgPGJyPg0KICAmZ3Q7IHRoZW4gd2UgYXJlIGFscmVhZHkgY292 ZXJlZCB2aWEgaW50ZXJhY3Rpb24gcmVsYXRlZCB0byBiYW5kd2lkdGgNCiAgZGVsZWdhdGlvbiBi ZXR3ZWVuIEFOIGFuZCBOQVMuPGJyPg0KICA8YnI+DQogIFRoYXQgd2FzIG15IGluaXRpYWwgcmVh Y3Rpb24gdG9vLiBJbmRlZWQsIEkgdGhpbmsgaXQgaXMgcG9zc2libGUgdG8gc3RyZXRjaA0KICBl eGlzdGluZyBiYW5kd2lkdGggZGVsZWdhdGlvbiBwcm9jZWR1cmVzIHRvIGFjaGlldmUgdGhpcy4g SG93ZXZlciB0aGlzIHdvdWxkDQogIHJlc3VsdCBpbiBzdWItb3B0aW1hbCBoYW5kbGluZyBvZiB0 aGUgbmV3IHVzZSBjYXNlLjxicj4NCiAgPGJyPg0KICBFeGFtcGxlIGNhbGwtRmxvdyBiYXNlZCBv biByZS11c2luZyBleGlzdGluZyBiYW5kd2lkdGggZGVsZWdhdGlvbiBwcm9jZWR1cmVzOjxicj4N CiAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQogIEFOICZsdDstLS1QT1JUX01OR1QgKEJ3IGFsbG9jYXRpb249ME1iL3MpIC0t TkFTPGJyPg0KICAuLi48YnI+DQogIChqb2luIGZyb20gc3Vic2NyaWJlciBmb3IgMk1iL3MgbXVs dGljYXN0IGZsb3cpPGJyPg0KICBBTiAtLS1CYW5kd2lkdGggUmVhbGxvYyBSZXF1ZXN0ICgyTWIv cyktLSZndDsgTkFTPGJyPg0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQogICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQogICZuYnNwOyZuYnNwOyZuYnNwOyhOQVMgYWxsb2NhdGVz IDJNYi9zKTxicj4NCiAgQU4gJmx0Oy0tLS0tLS0tQmFuZHdpZHRoIFRyYW5zZmVyICgyTWIvcykt LS0tLS0tLSBOQVM8YnI+DQogIChBTiBzdGFydHMgcmVwbGljYXRpbmcpPGJyPg0KICAuLi48YnI+ DQogIChsZWF2ZSArIGpvaW4gZnJvbSBzdWJzY3JpYmVyIGZvciA0TWIvcyBtdWx0aWNhc3QgZmxv dyk8YnI+DQogIEFOIC0tLUJhbmR3aWR0aCBSZWFsbG9jIFJlcXVlc3QgKDRNYi9zKS0tJmd0OyBO QVM8YnI+DQogICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KICAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7KE5BUyBhbGxvY2F0ZXMgNE1iL3MgdG90 YWwpPGJyPg0KICBBTiAmbHQ7LS0tLS0tLS1CYW5kd2lkdGggVHJhbnNmZXIgKDRNYi9zKS0tLS0t LS0tIE5BUzxicj4NCiAgKEFOIHN0YXJ0cyByZXBsaWNhdGluZyk8YnI+DQogIDxicj4NCiAgPGJy Pg0KICBFeGFtcGxlIGNhbGwtRmxvdyBiYXNlZCBvbiBuZXcgJnF1b3Q7YWRtaXR0ZWQgYmFuZHdp ZHRoIHJlcG9ydGluZyZxdW90Ow0KICBwcm9jZWR1cmVzOjxicj4NCiAgPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KICBBTiAmbHQ7 LS0tUE9SVF9NTkdUIChCdyBhbGxvY2F0aW9uPTRNYi9zKSAtLU5BUzxicj4NCiAgLi4uPGJyPg0K ICAoam9pbiBmcm9tIHN1YnNjcmliZXIgZm9yIDJNYi9zIG11bHRpY2FzdCBmbG93KTxicj4NCiAg KEFOIGRvZXMgYWRtaXNzaW9uIGNvbnRyb2wgYW5kIHN0YXJ0cyByZXBsaWNhdGluZyk8YnI+DQog IEFOIC0tLS0tLUFkbWl0dGVkIEJhbmR3aWR0aCBSZXBvcnQoMk1iL3MpLS0tJmd0OyBOQVM8YnI+ DQogIChsZWF2ZSArIGpvaW4gZnJvbSBzdWJzY3JpYmVyIGZvciA0TWIvcyBtdWx0aWNhc3QgZmxv dyk8YnI+DQogIChBTiBkb2VzIGFkbWlzc2lvbiBjb250cm9sIGFuZCBzdGFydHMgcmVwbGljYXRp bmcpPGJyPg0KICBBTiAtLS0tLS1BZG1pdHRlZCBCYW5kd2lkdGggUmVwb3J0KDRNYi9zKS0tLS0m Z3Q7IE5BUzxicj4NCiAgPGJyPg0KICA8YnI+DQogIFNvLCB0aGUgc3ViLW9wdGltYWxpdGllcyBv ZiByZXVzaW5nIGV4aXN0aW5nIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIHByb2NlZHVyZXMNCiAgaW5j bHVkZTo8YnI+DQogICZuYnNwOyZuYnNwOyZuYnNwOyAqYSogdXNlIG9mIHR3byBtZXNzYWdlcyBp bnN0ZWFkIG9mIG9uZSwgZm9yIGV2ZXJ5DQogIGJhbmR3aWR0aCBjaGFuZ2U8YnI+DQogICZuYnNw OyZuYnNwOyZuYnNwOyAqYiogZXh0cmEgZGVsYXkgb24gQU4gKGllIG5lZWQgdG8gd2FpdCBmb3Ig QU5DUCByb3VuZC10cmlwDQogIGluc3RlYWQgb2YgaW1tZWRpYXRlbHkgcmVwbGljYXRlKTxicj4N CiAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICpjKiB1bm5lY2Vzc2FyeSAmcXVvdDtiYW5kd2lkdGggY2hl Y2smcXVvdDsgZm9yDQogICZxdW90O3JlYWxsb2NhdGlvbiZxdW90OyBvbiBOQVM8YnI+DQogIDxi cj4NCiAgSSdkIHNheSB0aGVzZSBzdWItb3B0aW1hbGl0aWVzIGp1c3RpZnkgYSBuZXcgcHJvY2Vk dXJlcywgYnV0IEknbSB3aWxsaW5nIHRvDQogIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuPGJyPg0K ICBJIHN1cHBvc2Ugb25lIGNvdWxkIGFyZ3VlIHRoYXQgaW4gdGhlIG1ham9yaXR5IG9mIGpvaW4v bGVhdmUvam9pbiwgdGhlDQogIGJhbmR3aWR0aCBkb2VzIG5vdCBjaGFuZ2UgKGllIHphcHBpbmcg YW1vbmcgY2hhbm5lbHMgb2Ygc2FtZSBiYW5kd2lkdGgpLCBzbw0KICB0aGUgc3ViLW9wdGltYWxp dHkgKmEqIGlzIG9ubHkgaW5jdXJyZWQgaW4gbGVzcyBjb21tb24gY2FzZSAobGVhdmVTRCwNCiAg am9pbkhEKS48YnI+DQogIDxicj4NCiAgVGhvdWdodHMgZXZlcnlvbmU/PGJyPg0KICA8YnI+DQog IEZyYW5jb2lzPGJyPg0KICA8YnI+DQogIDxicj4NCiAgPGJyPg0KICA8bzpwPjwvbzpwPjwvcD4N CiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxicj4NCiAgPGJyPg0KICBGcmFuY29pcyBMZSBGYXVjaGV1cjxicj4NCiAg RGlzdGluZ3Vpc2hlZCBFbmdpbmVlcjxicj4NCiAgQ29ycG9yYXRlIERldmVsb3BtZW50PGJyPg0K ICA8YSBocmVmPSIvbWMvY29tcG9zZT90bz1mbGVmYXVjaEBjaXNjby5jb20iPmZsZWZhdWNoQGNp c2NvLmNvbTwvYT48YnI+DQogIFBob25lOiArMzMgNDkgNzIzIDI2MTk8YnI+DQogIE1vYmlsZTog KzMzIDYgMTkgOTggNTAgOTA8YnI+DQogIDxicj4NCiAgPGJyPg0KICA8YnI+DQogIENpc2NvIFN5 c3RlbXMgRnJhbmNlPGJyPg0KICBHcmVlbnNpZGU8YnI+DQogIDQwMCBBdmUgZGUgUm91bWFuaWxs ZTxicj4NCiAgMDY0MTAgU29waGlhIEFudGlwb2xpczxicj4NCiAgRnJhbmNlPGJyPg0KICBDaXNj by5jb208YnI+DQogIDxicj4NCiAgPGJyPg0KICA8bzpwPjwvbzpwPjwvcD4NCiAgPC9kaXY+DQog IDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn Pjxicj4NCiAgVGhpbmsgYmVmb3JlIHlvdSBwcmludC48YnI+DQogIDxicj4NCiAgVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZQ0KICBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5DQogIG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvcg0KICBhdXRo b3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5IHJlcGx5DQogIGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1l c3NhZ2UuPGJyPg0KICA8YnI+DQogIENpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6Ag cmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMNCiAg4oCTIElt bSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVh dXgsIEF1IGNhcGl0YWwNCiAgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJl LCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjDQogIE1pY2hlbCBHaXZvbmUu PGJyPg0KICA8YnI+DQogIEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJy Pg0KICA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5l c3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwiDQogIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmNp c2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWw8L2E+ PGJyPg0KICA8YnI+DQogIDxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPC90ZD4NCiA8L3Ry Pg0KPC90YWJsZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01CAD3C4.66C13EC9-- From swadhwa01@yahoo.com Sun Apr 4 20:06:19 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3491F3A67AC for ; Sun, 4 Apr 2010 20:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 L1j+0Us-mX+R for ; Sun, 4 Apr 2010 20:06:17 -0700 (PDT) Received: from n1-vm1.bullet.mail.gq1.yahoo.com (n1-vm1.bullet.mail.gq1.yahoo.com [67.195.23.153]) by core3.amsl.com (Postfix) with SMTP id E2C1A3A681B for ; Sun, 4 Apr 2010 20:06:16 -0700 (PDT) Received: from [67.195.9.82] by n1.bullet.mail.gq1.yahoo.com with NNFMP; 05 Apr 2010 03:06:13 -0000 Received: from [98.137.27.209] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 05 Apr 2010 03:06:13 -0000 Received: from [127.0.0.1] by omp119.mail.gq1.yahoo.com with NNFMP; 05 Apr 2010 03:06:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 40644.10072.bm@omp119.mail.gq1.yahoo.com Received: (qmail 94194 invoked by uid 60001); 5 Apr 2010 03:06:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270436772; bh=a7VemVf7P+iJPY7m7NJc+QowN8FJiB5VrPQOudLBUls=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=akzvogSFEanlhDLkslnyCJkTLas23OZ1qEvq3bSBlx8xFlrQMzRfPnJUFKit88T6VnWtOTP09Zr9ORe4QTqbhIrZFSZ4wkU0BjLZ4D57gPk26ipbGcuc9HxiBC2DumYCc1WUKESGhxswlC0uSjwhhXKi6PZ8CX8IY8e7zKKHL5s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h15DiruDsfBoSqwaajaCQkAHUQJ0M8LsLdnVxzGt079cKAMPlXJYBiz9cL+mUkKKi0WIof+lMwAmUZGIaLDcyu5sHo1O/hBoR1nFpRxIOCiRZoLSAYuGqwy0fI0J70VaYJTqXa0mEDgRfTX7n3sR8yIcRXuLJxOFLNeZ/jvOGYA=; Message-ID: <913921.93355.qm@web113806.mail.gq1.yahoo.com> X-YMail-OSG: a5DZr3wVM1myytyeFXbn2E6XB.zeZdKMsYp0FDppxxDA82k yI7dVS1KcoTCfwCWOHKVSygz5LLXfcU9hUefv_3pGmBzYG2gto_ZIHCQoMWm ZO9J1MXUy_hPaIYkFpTPg4zEWzHdHSWmdyEqHWUTmqP.cALBcRFGBYulaQzI A62WoGbd8WXU0SWIZ2ipOEoUBNtqWJ8vCdPslizyDSoo3r5EbQuc_IDSNbMm driT6Y5b5ZnnX7i1zssaFSj5KVCLsRi_B3N7BBGAy8FFalHjlVN1AsWqAdf1 J07QYsu.lZKvKO6Ii_.xRoosU3RkzMT2QZveN7FuVUnmTcKkhAtu6NljeceC icJ8s6AGPSXToF9P.zqobnFxSX7loCNzD7navNw-- Received: from [24.62.100.133] by web113806.mail.gq1.yahoo.com via HTTP; Sun, 04 Apr 2010 20:06:12 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Sun, 4 Apr 2010 20:06:12 -0700 (PDT) From: Sanjay Wadhwa To: Francois Le Faucheur , POSCIC Kristian In-Reply-To: <41B3B178A129B6458752EC1B4D14998C03BC259E@USDALSMBS04.ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-348633354-1270436772=:93355" Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 03:06:19 -0000 --0-348633354-1270436772=:93355 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kris =C2=A0 Please see inline [SW]. Thanks -Sanjay --- On Sun, 4/4/10, POSCIC Kristian wr= ote: From: POSCIC Kristian Subject: RE: To: "Sanjay Wadhwa" , "Francois Le Faucheur" Cc: "Francois Le Faucheur" , ancp@ietf.org Date: Sunday, April 4, 2010, 2:59 AM =0A=0A=0A =0A =0A=0A=0A=0A=0A=0A=0AHi Sanjay =E2=80=93 =0A=0AIn the model = that I was thinking, the steps 3 and 4 are little=0Abit different: =0A=0A = =C2=A0 =0A=0AVideo b/w that can be allocated in the AN is shared between th= e=0Amcast and VoD. =0A=0A3) Policy server makes the VOD decision. NAS is t= ransparent to=0Athis. It=E2=80=99s acting juts as an intermediary between t= he policy server and the AN. [SW] I implied the same in #3 below. Policy server queries AN via NAS (thro= ugh ANCP between NAS and AN). The decision to admit the VOD is being made o= n the AN=0Ain this model, as it is managing this shared b/w pool between VO= D and multicast, and is conveying back=0Athe response via ANCP to NAS (whic= h could then be conveyed via north-bound interface from NAS to=0Apolicy-ser= ver). Please let me know if this is different than what you are thinking. =0A =0A=0A4) If the b/w asked by the policy server is available in the AN,=0At= he AN will send an ACK which will be conveyed to the policy server through = the=0ANAS. The policy server will allow the VOD flow and update is resource= =0Areservation table. Nothing else is needed. The unicast VoD flow will be= =0Aautomatically accounted for in the QoS in the NAS as it is flowing throu= gh the=0Asubscriber queues. =0A=0A =C2=A0 =0A=0AB/w usage reporting from th= e AN to the NAS has to do only with=0Athe multicast AC. =0A=0A=C2=A0=20 [SW] In #4 below I am only talking about multicast and not VOD (please note= the channel change scenario mentioned=0Ain there). AN may want to optional= ly notify NAS of multicast, such that NAS can adjust unicast b/w lower due = to multicast being sent on MVLAN (as=0Amulticast bypasses normal QOS hierar= chy for the subscriber).=0AThe point I tried making is that AN will need to= hold off on=0Areplication till it gets an ACK back from NAS when notifying= it of=0AQOS-adjust. Original response from Francois seemed to imply no=0Ar= ound-trip was needed before AN starts replication (which I don't believe is= =0Athe case). =0A=0AOne another note, the ANCP draft Target TLV definitions are mostly= =0Afocused on DSLAM environments. But in the PON environment, if we need to= manage=0Ab/w per PON, uplink and the subscriber, we=E2=80=99ll need 3 Targ= et TLVs. Maybe this will=0Abe defined in the draft that you are working on = (GPON)? =0A=0A [SW] The target TLV is extensible. PON specific types as you mention need t= o be defined (to also include PON and uplink). The PON draft covers the mod= els and information exchanged at a=C2=A0 high level. The specific TLVs in t= he messages need to go in the protocol draft. I believe for the model discu= ssed here, you will also need Admission Control message (NAS to AN) extende= d for VOD (e.g to carry requested bandwidth).=20 Thanks -Sanjay =C2=A0 =0A=0A=0A=0AFrom: Sanjay Wadhwa=0A[mailto:swadhwa01@yahoo.com]=20 =0ASent: Friday, April 02, 2010 9:36 PM =0ATo: Francois Le Faucheur =0ACc: Francois Le Faucheur; POSCIC Kristian; ancp@ietf.org =0ASubject: Re: =0A=0A=0A=0A =C2=A0 =0A=0A=0A =0A =0A Hi Francois, Kris =0A =C2=A0 What is needed depends on at least two key variables: =0A =C2=A0 1. How dynamic do you want the per-subscriber bandwidth managem= ent=0A across different traffic types to be. This includes managed VOD, mu= lticast=0A and best-effort traffic.=20 =0A =C2=A0 2. Where do you want the unified bandwidth admission control ac= ross=0A multicast and managed VOD to happen (AN or NAS).=20 =0A We can consider most optimal interactions based on the model chosen. H= owever,=0A the protocol needs to allow all variations. =0A =20 =0A Now, specific to your examples, you have assumed in bandwidth delegati= on=0A model that no minimal initial bandwidth is delegated to AN, which do= esn't=0A need to be the case. =0A In your second example you are allocating in initial amount of bandwid= th=0A delegated to AN (perhaps due to dynamic updates of allocated b/w you= assume=0A it is ok). However, based on reported bandwidth utilization fro= m AN, the NAS=0A could use the available bandwidth for unicast traffic (in= cluding=0A best-effort). Next time around when AN gets a request for highe= r=0A bandwidth=C2=A0 multicast channel, it can't assume bandwidth is avail= able,=0A and should update NAS before replicating. I don't see specific=0A= advantage/optimality with the second example. =0A =20 =0A Based on Kris's questions I am extrapolating the model in question is = the=0A following: =0A =20 =0A =C2=A0 1. AN manages assigned video bandwidth and does unified bandwid= th=0A admission control (AC) against it. =0A =C2=A0 2. AN terminates per-subscriber multicast and replicates based = on an=0A admission control decision. =0A =C2=A0 3. When VOD request needs to be admitted, policy server through= NAS=0A queries available bandwidth on the AN. This is a reverse AC reques= t (from NAS=0A to AN for unicast video). If bandwidth is available, VOD fl= ow is admitted by=0A NAS. AN always has the latest view of available bandw= idth. Making AC=0A request/response bidirectional and specifying bandwidth= value in AC request=0A can accomodate this interaction. =0A =C2=A0 4. AN notifies NAS of bandwidth allocations for multicast, so N= AS can=0A adjust bandwidth for unicast (e.g. best-effort) traffic accordin= gly. However,=0A if AN needs to inform NAS to adjust bandwidth for unicast= (best-effort)=0A traffic lower (due to say a SD->HD multicast leave/join = sequence), it does=0A need to send a request to NAS and ideally wait for a= response before=0A replicating. This round-trip is not avoidable if one w= ants the most =C2=A0=C2=A0=C2=A0=C2=A0=0A dynamic/optimal bandwidth usage,= where unicast best-effort traffic could=0A utilize unused available video= bandwidth and get throttled down when=0A multicast needs the bandwidth (o= fcourse this is dependent on how operator=0A wants to manage subscriber's = bandwdith). For this interaction either a new=0A "bandwidth reporitng" mes= sage or a sub-type of an existing message=0A can be used. =0A =20 =0A -Sanjay =0A =20 =0A ps. The model where unified AC happens on NAS has its own benefits (e.= g.=0A simplicity), so not necessarily advocating the above model with AN b= ased AC,=0A but we need to accommodate both. =0A =20 =0A =20 =0A --- On Thu, 4/1/10, Francois Le Faucheur =0A wrot= e: =0A =20 =0A From: Francois Le Faucheur =0A Subject: Re: =0A To: "Sanjay Wadhwa" =0A Cc: "Francois Le Faucheur" ,=0A Kristian.Poscic@a= lcatel-lucent.com, ancp@ietf.org =0A Date: Thursday, April 1, 2010, 10:02 AM =0A =0A Hi Sanjay, =0A =20 =0A On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote: =0A >=20 =0A > [SW] The scenario above, where NAS sends the channel on MC-VLAN, ass= umes=0A NAS is doing bandwidth based AC. A channel join on AN may trigger = an AC=0A request message to NAS, which should trigger a CAC decision and Q= OS-adjust on=0A NAS and a response back to AN (before AN can perform repli= cation). Do we need=0A another bandwidth update message from AN to NAS? In= case AN sees a channel=0A leave (and no new join for some time) or a user= switches from HD to SD, then=0A AN may decide to notify NAS of released b= andwidth. I believe we are again=0A covered by existing AC request message= from AN to NAS (described in multicast=0A extensions draft). =0A =20 =0A If admission control is to be performed by NAS (ie Grey list multicast= flow),=0A then I agree we are already covered by existing multicast proce= dures because=0A the NAS is always fully aware of currently admitted multi= cast traffic on a=0A given port. =0A =20 =0A >=20 =0A >=C2=A0 On the other hand if we are assuming bandwidth delegation mode= l=0A and autonomous AC on AN, =0A =20 =0A That is indeed the case of interest, here. =0A =20 =0A > then we are already covered via interaction related to bandwidth=0A = delegation between AN and NAS. =0A =20 =0A That was my initial reaction too. Indeed, I think it is possible to st= retch=0A existing bandwidth delegation procedures to achieve this. However= this would=0A result in sub-optimal handling of the new use case. =0A =20 =0A Example call-Flow based on re-using existing bandwidth delegation proc= edures: =0A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =0A AN <---PORT_MNGT (Bw allocation=3D0Mb/s) --NAS =0A ... =0A (join from subscriber for 2Mb/s multicast flow) =0A AN ---Bandwidth Realloc Request (2Mb/s)--> NAS =0A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=0A =C2=A0=C2=A0=C2=A0(NAS allocates 2Mb/s) =0A AN <--------Bandwidth Transfer (2Mb/s)-------- NAS =0A (AN starts replicating) =0A ... =0A (leave + join from subscriber for 4Mb/s multicast flow) =0A AN ---Bandwidth Realloc Request (4Mb/s)--> NAS =0A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=0A =C2=A0=C2=A0=C2=A0(NAS allocates 4Mb/s total) =0A AN <--------Bandwidth Transfer (4Mb/s)-------- NAS =0A (AN starts replicating) =0A =20 =0A =20 =0A Example call-Flow based on new "admitted bandwidth reporting"=0A proc= edures: =0A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =0A AN <---PORT_MNGT (Bw allocation=3D4Mb/s) --NAS =0A ... =0A (join from subscriber for 2Mb/s multicast flow) =0A (AN does admission control and starts replicating) =0A AN ------Admitted Bandwidth Report(2Mb/s)---> NAS =0A (leave + join from subscriber for 4Mb/s multicast flow) =0A (AN does admission control and starts replicating) =0A AN ------Admitted Bandwidth Report(4Mb/s)----> NAS =0A =20 =0A =20 =0A So, the sub-optimalities of reusing existing bandwidth delegation proc= edures=0A include: =0A =C2=A0=C2=A0=C2=A0 *a* use of two messages instead of one, for every= =0A bandwidth change =0A =C2=A0=C2=A0=C2=A0 *b* extra delay on AN (ie need to wait for ANCP rou= nd-trip=0A instead of immediately replicate) =0A =C2=A0=C2=A0=C2=A0 *c* unnecessary "bandwidth check" for=0A "realloca= tion" on NAS =0A =20 =0A I'd say these sub-optimalities justify a new procedures, but I'm willi= ng to=0A be convinced otherwise. =0A I suppose one could argue that in the majority of join/leave/join, the= =0A bandwidth does not change (ie zapping among channels of same bandwidth= ), so=0A the sub-optimality *a* is only incurred in less common case (leav= eSD,=0A joinHD). =0A =20 =0A Thoughts everyone? =0A =20 =0A Francois =0A =20 =0A =20 =0A =20 =0A =0A =0A =0A =20 =0A =20 =0A Francois Le Faucheur =0A Distinguished Engineer =0A Corporate Development =0A flefauch@cisco.com =0A Phone: +33 49 723 2619 =0A Mobile: +33 6 19 98 50 90 =0A =20 =0A =20 =0A =20 =0A Cisco Systems France =0A Greenside =0A 400 Ave de Roumanille =0A 06410 Sophia Antipolis =0A France =0A Cisco.com =0A =20 =0A =20 =0A =0A =0A =0A =20 =0A Think before you print. =0A =20 =0A This email may contain confidential and privileged material for the so= le use=0A of the intended recipient. Any review, use, distribution or disc= losure by=0A others is strictly prohibited. If you are not the intended re= cipient (or=0A authorized to receive for the recipient), please contact th= e sender by reply=0A email and delete all copies of this message. =0A =20 =0A Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 limi= t=C3=A9e, Rue Camille Desmoulins=0A =E2=80=93 Imm Atlantis Zac Forum Seine= Ilot 7 92130 Issy les Moulineaux, Au capital=0A de 91.470 =E2=82=AC, 349 = 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc=0A Michel Givo= ne. =0A =20 =0A For corporate legal information go to: =0A http://www.cisco.com/web/about/doing_business/legal/cri/index.html =0A =20 =0A =0A =0A =0A =0A=0A=0A =C2=A0 =0A=0A=0A=0A =0A=0A=0A=0A=0A --0-348633354-1270436772=:93355 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Kris
  Please see inline [SW].
=
Thanks
-Sanjay

--- On Sun, 4/4/10, POSCIC Kristian <= Kristian.Poscic@alcatel-lucent.com> wrote:

From: POSCIC Kristian <Kristian.Poscic@alcatel-lucent.com>= ;
Subject: RE:
To: "Sanjay Wadhwa" <swadhwa01@yahoo.com>, "Fran= cois Le Faucheur" <flefauch@cisco.com>
Cc: "Francois Le Faucheur" = <flefauch@cisco.com>, ancp@ietf.org
Date: Sunday, April 4, 2010, 2= :59 AM

=0A=0A=0A =0A =0A=0A=0A
=0A=0A

Hi Sanjay =E2=80=93

=0A=0A<= p class=3D"MsoNormal">In the model that I was thinking,= the steps 3 and 4 are little=0Abit different:

=0A=0A

 

=0A=0A

Video b/w that can be allocated in the AN is share= d between the=0Amcast and VoD.

=0A=0A

3) Policy server makes the VOD decision. NAS is transparen= t to=0Athis. It=E2=80=99s acting juts as an intermediary between the policy= server and the AN.


[SW] I implied the same in #3 below. Po= licy server queries AN via NAS (through ANCP between NAS and AN). The decis= ion to admit the VOD is being made on the AN=0Ain this model, as it is mana= ging this shared b/w pool between VOD and multicast, and is conveying back= =0Athe response via ANCP to NAS (which could then be conveyed via north-bou= nd interface from NAS to=0Apolicy-server). Please let me know if this is di= fferent than what you are thinking.

=0A


=0A=0A

4) If the= b/w asked by the policy server is available in the AN,=0Athe AN will send = an ACK which will be conveyed to the policy server through the=0ANAS. The p= olicy server will allow the VOD flow and update is resource=0Areservation t= able. Nothing else is needed. The unicast VoD flow will be=0Aautomatically = accounted for in the QoS in the NAS as it is flowing through the=0Asubscrib= er queues.

=0A=0A

&nb= sp;

=0A=0A

B/w usage r= eporting from the AN to the NAS has to do only with=0Athe multicast AC.

=0A=0A

 
=

[SW] In #4 below I am only t= alking about multicast and not VOD (please note the channel change scenario= mentioned=0Ain there). AN may want to optionally notify NAS of multicast, = such that NAS can adjust unicast b/w lower due to multicast being sent on M= VLAN (as=0Amulticast bypasses normal QOS hierarchy for the subscriber).=0AT= he point I tried making is that AN will need to hold off on=0Areplication t= ill it gets an ACK back from NAS when notifying it of=0AQOS-adjust. Origina= l response from Francois seemed to imply no=0Around-trip was needed before = AN starts replication (which I don't believe is=0Athe case).

=0A=0A

One a= nother note, the ANCP draft Target TLV definitions are mostly=0Afocused on = DSLAM environments. But in the PON environment, if we need to manage=0Ab/w = per PON, uplink and the subscriber, we=E2=80=99ll need 3 Target TLVs. Maybe= this will=0Abe defined in the draft that you are working on (GPON)?=

=0A=0A


[SW] The target TLV is extensible. PON= specific types as you mention need to be defined (to also include PON and = uplink). The PON draft covers the models and information exchanged at a&nbs= p; high level. The specific TLVs in the messages need to go in the protocol= draft. I believe for the model discussed here, you will also need Admissio= n Control message (NAS to AN) extended for VOD (e.g to carry requested band= width).


Thanks

-Sanjay

  =0A=0A
=0A=0A

From: Sanjay Wadhwa= =0A[mailto:swadhwa01@yahoo.com]
=0ASent: Friday, April 02, 2010 = 9:36 PM
=0ATo: Francois Le Faucheur
=0ACc: Francois Le = Faucheur; POSCIC Kristian; ancp@ietf.org
=0ASubject: Re: =0A=0A

=0A=0A

 

=0A=0A=0A =0A =0A =0A=0A=0A

 

=0A=0A=0A=0A =0A=0A
=0A

Hi Francois, Kris
=0A   What is needed depends on at lea= st two key variables:
=0A   1. How dynamic do you want the per-sub= scriber bandwidth management=0A across different traffic types to be. This= includes managed VOD, multicast=0A and best-effort traffic.
=0A &nbs= p; 2. Where do you want the unified bandwidth admission control across=0A = multicast and managed VOD to happen (AN or NAS).
=0A We can consider m= ost optimal interactions based on the model chosen. However,=0A the protoc= ol needs to allow all variations.
=0A
=0A Now, specific to your ex= amples, you have assumed in bandwidth delegation=0A model that no minimal = initial bandwidth is delegated to AN, which doesn't=0A need to be the case= .
=0A In your second example you are allocating in initial amount of ba= ndwidth=0A delegated to AN (perhaps due to dynamic updates of allocated b/= w you assume=0A it is ok). However, based on reported bandwidth utilizatio= n from AN, the NAS=0A could use the available bandwidth for unicast traffi= c (including=0A best-effort). Next time around when AN gets a request for = higher=0A bandwidth  multicast channel, it can't assume bandwidth is = available,=0A and should update NAS before replicating. I don't see specif= ic=0A advantage/optimality with the second example.
=0A
=0A Based= on Kris's questions I am extrapolating the model in question is the=0A fo= llowing:
=0A
=0A   1. AN manages assigned video bandwidth and= does unified bandwidth=0A admission control (AC) against it.
=0A &nbs= p; 2. AN terminates per-subscriber multicast and replicates based on an=0A = admission control decision.
=0A   3. When VOD request needs to be= admitted, policy server through NAS=0A queries available bandwidth on the= AN. This is a reverse AC request (from NAS=0A to AN for unicast video). I= f bandwidth is available, VOD flow is admitted by=0A NAS. AN always has th= e latest view of available bandwidth. Making AC=0A request/response bidire= ctional and specifying bandwidth value in AC request=0A can accomodate thi= s interaction.
=0A   4. AN notifies NAS of bandwidth allocations f= or multicast, so NAS can=0A adjust bandwidth for unicast (e.g. best-effort= ) traffic accordingly. However,=0A if AN needs to inform NAS to adjust ban= dwidth for unicast (best-effort)=0A traffic lower (due to say a SD->HD = multicast leave/join sequence), it does=0A need to send a request to NAS a= nd ideally wait for a response before=0A replicating. This round-trip is n= ot avoidable if one wants the most     =0A dynamic/opt= imal bandwidth usage, where unicast best-effort traffic could=0A utilize u= nused available video bandwidth and get throttled down when=0A multicast n= eeds the bandwidth (ofcourse this is dependent on how operator=0A wants to= manage subscriber's bandwdith). For this interaction either a new=0A "ban= dwidth reporitng" message or a sub-type of an existing message=0A can be u= sed.
=0A
=0A -Sanjay
=0A
=0A ps. The model where unified = AC happens on NAS has its own benefits (e.g.=0A simplicity), so not necess= arily advocating the above model with AN based AC,=0A but we need to accom= modate both.
=0A
=0A
=0A --- On Thu, 4/1/10, Francois Le F= aucheur <flefauch@cisco.com>=0A wrote:

=0A


=0A From: Francois Le Fa= ucheur <flefauch@cisco.com>
=0A Subject: Re:
=0A To: "Sanjay = Wadhwa" <swadhwa01@yahoo.com>
=0A Cc: "Francois Le Faucheur" <= flefauch@cisco.com>,=0A Kristian.Poscic@alcatel-lucent.com, ancp@ietf.o= rg
=0A Date: Thursday, April 1, 2010, 10:02 AM

=0A
=0A

Hi Sanjay,
=0A
=0A= On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote:
=0A >
=0A >= [SW] The scenario above, where NAS sends the channel on MC-VLAN, assumes= =0A NAS is doing bandwidth based AC. A channel join on AN may trigger an A= C=0A request message to NAS, which should trigger a CAC decision and QOS-a= djust on=0A NAS and a response back to AN (before AN can perform replicati= on). Do we need=0A another bandwidth update message from AN to NAS? In cas= e AN sees a channel=0A leave (and no new join for some time) or a user swi= tches from HD to SD, then=0A AN may decide to notify NAS of released bandw= idth. I believe we are again=0A covered by existing AC request message fro= m AN to NAS (described in multicast=0A extensions draft).
=0A
=0A = If admission control is to be performed by NAS (ie Grey list multicast flo= w),=0A then I agree we are already covered by existing multicast procedure= s because=0A the NAS is always fully aware of currently admitted multicast= traffic on a=0A given port.
=0A
=0A >
=0A >  On = the other hand if we are assuming bandwidth delegation model=0A and autono= mous AC on AN,
=0A
=0A That is indeed the case of interest, here.<= br>=0A
=0A > then we are already covered via interaction related t= o bandwidth=0A delegation between AN and NAS.
=0A
=0A That was my= initial reaction too. Indeed, I think it is possible to stretch=0A existi= ng bandwidth delegation procedures to achieve this. However this would=0A = result in sub-optimal handling of the new use case.
=0A
=0A Exampl= e call-Flow based on re-using existing bandwidth delegation procedures:
= =0A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A AN <---PORT_MNGT (Bw allocatio= n=3D0Mb/s) --NAS
=0A ...
=0A (join from subscriber for 2Mb/s multic= ast flow)
=0A AN ---Bandwidth Realloc Request (2Mb/s)--> NAS
=0A =                     &nbs= p;=0A                    = ;  =0A                  =  =0A    (NAS allocates 2Mb/s)
=0A AN <--------= Bandwidth Transfer (2Mb/s)-------- NAS
=0A (AN starts replicating)
= =0A ...
=0A (leave + join from subscriber for 4Mb/s multicast flow)=0A AN ---Bandwidth Realloc Request (4Mb/s)--> NAS
=0A   &nbs= p;                  =0A  = ;                    =0A =                    =0A =    (NAS allocates 4Mb/s total)
=0A AN <--------Bandwi= dth Transfer (4Mb/s)-------- NAS
=0A (AN starts replicating)
=0A =0A
=0A Example call-Flow based on new "admitted bandwidth reportin= g"=0A procedures:
=0A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A AN <---PORT_MNG= T (Bw allocation=3D4Mb/s) --NAS
=0A ...
=0A (join from subscriber f= or 2Mb/s multicast flow)
=0A (AN does admission control and starts repl= icating)
=0A AN ------Admitted Bandwidth Report(2Mb/s)---> NAS
= =0A (leave + join from subscriber for 4Mb/s multicast flow)
=0A (AN do= es admission control and starts replicating)
=0A AN ------Admitted Band= width Report(4Mb/s)----> NAS
=0A
=0A
=0A So, the sub-optim= alities of reusing existing bandwidth delegation procedures=0A include:=0A     *a* use of two messages instead of one, for every= =0A bandwidth change
=0A     *b* extra delay on AN (ie = need to wait for ANCP round-trip=0A instead of immediately replicate)
= =0A     *c* unnecessary "bandwidth check" for=0A "realloca= tion" on NAS
=0A
=0A I'd say these sub-optimalities justify a new = procedures, but I'm willing to=0A be convinced otherwise.
=0A I suppos= e one could argue that in the majority of join/leave/join, the=0A bandwidt= h does not change (ie zapping among channels of same bandwidth), so=0A the= sub-optimality *a* is only incurred in less common case (leaveSD,=0A join= HD).
=0A
=0A Thoughts everyone?
=0A
=0A Francois
=0A =
=0A
=0A
=0A

=0A
=0A
=0A


=0A
=0A Francois Le Faucheur=
=0A Distinguished Engineer
=0A Corporate Development
=0A flefauch@cisco.com
=0A Phone: +33 49 723 2619
=0A= Mobile: +33 6 19 98 50 90
=0A
=0A
=0A
=0A Cisco System= s France
=0A Greenside
=0A 400 Ave de Roumanille
=0A 06410 Soph= ia Antipolis
=0A France
=0A Cisco.com
=0A
=0A
=0A =0A

=0A
=0A


=0A Think before you print.
=0A
=0A This email may con= tain confidential and privileged material for the sole use=0A of the inten= ded recipient. Any review, use, distribution or disclosure by=0A others is= strictly prohibited. If you are not the intended recipient (or=0A authori= zed to receive for the recipient), please contact the sender by reply=0A e= mail and delete all copies of this message.
=0A
=0A Cisco Systems = France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 limit=C3=A9e, Rue Camil= le Desmoulins=0A =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital=0A de 91.470 =E2=82=AC, 349 166 561 RCS Nanterr= e, Directeur de la publication: Jean-Luc=0A Michel Givone.
=0A
=0A= For corporate legal information go to:
=0A http://www.cisco.com/web/about/doing_business/legal/cri/index.= html
=0A
=0A

=0A
=0A

=0A=0A --0-348633354-1270436772=:93355-- From Kristian.Poscic@alcatel-lucent.com Sun Apr 4 21:45:40 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E268C3A688B for ; Sun, 4 Apr 2010 21:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tznszl6exIUi for ; Sun, 4 Apr 2010 21:45:38 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 68FAC3A6888 for ; Sun, 4 Apr 2010 21:45:38 -0700 (PDT) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id o354jAoO019072; Sun, 4 Apr 2010 23:45:10 -0500 (CDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.pdc.alcatel-lucent.com [172.22.216.19]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o354jAQt012528; Sun, 4 Apr 2010 23:45:10 -0500 (CDT) Received: from USDALSMBS02.ad3.ad.alcatel.com ([172.22.216.10]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 23:45:09 -0500 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.11]) by USDALSMBS02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 23:45:09 -0500 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_01CAD47A.C4E31939" Date: Sun, 4 Apr 2010 23:45:06 -0500 Message-ID: <41B3B178A129B6458752EC1B4D14998C03BC25A4@USDALSMBS04.ad3.ad.alcatel.com> In-Reply-To: <913921.93355.qm@web113806.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcrUbPSIn6wB31tdRhiG1JpJNCOuqgACz3nA References: <41B3B178A129B6458752EC1B4D14998C03BC259E@USDALSMBS04.ad3.ad.alcatel.com> <913921.93355.qm@web113806.mail.gq1.yahoo.com> From: "POSCIC Kristian" To: "Sanjay Wadhwa" , "Francois Le Faucheur" X-OriginalArrivalTime: 05 Apr 2010 04:45:09.0161 (UTC) FILETIME=[C51D4990:01CAD47A] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 04:45:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD47A.C4E31939 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FueWFqIOKAkyBwbGVhc2Ugc2VlIGlubGluZS4NCg0KVGhhbmtzLA0KDQpLcmlzDQoNCiAN Cg0KRnJvbTogU2FuamF5IFdhZGh3YSBbbWFpbHRvOnN3YWRod2EwMUB5YWhvby5jb21dIA0KU2Vu dDogU3VuZGF5LCBBcHJpbCAwNCwgMjAxMCA4OjA2IFBNDQpUbzogRnJhbmNvaXMgTGUgRmF1Y2hl dXI7IFBPU0NJQyBLcmlzdGlhbg0KQ2M6IEZyYW5jb2lzIExlIEZhdWNoZXVyOyBhbmNwQGlldGYu b3JnDQpTdWJqZWN0OiBSRToNCg0KIA0KDQpIaSBLcmlzDQogIFBsZWFzZSBzZWUgaW5saW5lIFtT V10uDQoNClRoYW5rcw0KLVNhbmpheQ0KDQotLS0gT24gU3VuLCA0LzQvMTAsIFBPU0NJQyBLcmlz dGlhbiA8S3Jpc3RpYW4uUG9zY2ljQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQoNCg0KRnJv bTogUE9TQ0lDIEtyaXN0aWFuIDxLcmlzdGlhbi5Qb3NjaWNAYWxjYXRlbC1sdWNlbnQuY29tPg0K U3ViamVjdDogUkU6DQpUbzogIlNhbmpheSBXYWRod2EiIDxzd2FkaHdhMDFAeWFob28uY29tPiwg IkZyYW5jb2lzIExlIEZhdWNoZXVyIiA8ZmxlZmF1Y2hAY2lzY28uY29tPg0KQ2M6ICJGcmFuY29p cyBMZSBGYXVjaGV1ciIgPGZsZWZhdWNoQGNpc2NvLmNvbT4sIGFuY3BAaWV0Zi5vcmcNCkRhdGU6 IFN1bmRheSwgQXByaWwgNCwgMjAxMCwgMjo1OSBBTQ0KDQpIaSBTYW5qYXkg4oCTIA0KDQpJbiB0 aGUgbW9kZWwgdGhhdCBJIHdhcyB0aGlua2luZywgdGhlIHN0ZXBzIDMgYW5kIDQgYXJlIGxpdHRs ZSBiaXQgZGlmZmVyZW50Og0KDQogDQoNClZpZGVvIGIvdyB0aGF0IGNhbiBiZSBhbGxvY2F0ZWQg aW4gdGhlIEFOIGlzIHNoYXJlZCBiZXR3ZWVuIHRoZSBtY2FzdCBhbmQgVm9ELiANCg0KMykgUG9s aWN5IHNlcnZlciBtYWtlcyB0aGUgVk9EIGRlY2lzaW9uLiBOQVMgaXMgdHJhbnNwYXJlbnQgdG8g dGhpcy4gSXTigJlzIGFjdGluZyBqdXRzIGFzIGFuIGludGVybWVkaWFyeSBiZXR3ZWVuIHRoZSBw b2xpY3kgc2VydmVyIGFuZCB0aGUgQU4uDQoNCiANCg0KW1NXXSBJIGltcGxpZWQgdGhlIHNhbWUg aW4gIzMgYmVsb3cuIFBvbGljeSBzZXJ2ZXIgcXVlcmllcyBBTiB2aWEgTkFTICh0aHJvdWdoIEFO Q1AgYmV0d2VlbiBOQVMgYW5kIEFOKS4gVGhlIGRlY2lzaW9uIHRvIGFkbWl0IHRoZSBWT0QgaXMg YmVpbmcgbWFkZSBvbiB0aGUgQU4gaW4gdGhpcyBtb2RlbCwgYXMgaXQgaXMgbWFuYWdpbmcgdGhp cyBzaGFyZWQgYi93IHBvb2wgYmV0d2VlbiBWT0QgYW5kIG11bHRpY2FzdCwgYW5kIGlzIGNvbnZl eWluZyBiYWNrIHRoZSByZXNwb25zZSB2aWEgQU5DUCB0byBOQVMgKHdoaWNoIGNvdWxkIHRoZW4g YmUgY29udmV5ZWQgdmlhIG5vcnRoLWJvdW5kIGludGVyZmFjZSBmcm9tIE5BUyB0byBwb2xpY3kt c2VydmVyKS4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgaXMgZGlmZmVyZW50IHRoYW4gd2hh dCB5b3UgYXJlIHRoaW5raW5nLg0KDQpbS3Jpc10gWWVzLCB3ZSBhcmUgb24gdGhlIHNhbWUgcGFn ZS4gSSB3YXMgY29uZnVzZWQgYnkgdGhpcyBzdGF0ZW1lbnQgaW4geW91ciBvcmlnaW5hbCBwb3N0 OiBJZiBiYW5kd2lkdGggaXMgYXZhaWxhYmxlLCBWT0QgZmxvdyBpcyBhZG1pdHRlZCBieSBOQVMu IA0KDQogDQoNCjQpIElmIHRoZSBiL3cgYXNrZWQgYnkgdGhlIHBvbGljeSBzZXJ2ZXIgaXMgYXZh aWxhYmxlIGluIHRoZSBBTiwgdGhlIEFOIHdpbGwgc2VuZCBhbiBBQ0sgd2hpY2ggd2lsbCBiZSBj b252ZXllZCB0byB0aGUgcG9saWN5IHNlcnZlciB0aHJvdWdoIHRoZSBOQVMuIFRoZSBwb2xpY3kg c2VydmVyIHdpbGwgYWxsb3cgdGhlIFZPRCBmbG93IGFuZCB1cGRhdGUgaXMgcmVzb3VyY2UgcmVz ZXJ2YXRpb24gdGFibGUuIE5vdGhpbmcgZWxzZSBpcyBuZWVkZWQuIFRoZSB1bmljYXN0IFZvRCBm bG93IHdpbGwgYmUgYXV0b21hdGljYWxseSBhY2NvdW50ZWQgZm9yIGluIHRoZSBRb1MgaW4gdGhl IE5BUyBhcyBpdCBpcyBmbG93aW5nIHRocm91Z2ggdGhlIHN1YnNjcmliZXIgcXVldWVzLg0KDQog DQoNCkIvdyB1c2FnZSByZXBvcnRpbmcgZnJvbSB0aGUgQU4gdG8gdGhlIE5BUyBoYXMgdG8gZG8g b25seSB3aXRoIHRoZSBtdWx0aWNhc3QgQUMuDQoNCiAgDQoNCltTV10gSW4gIzQgYmVsb3cgSSBh bSBvbmx5IHRhbGtpbmcgYWJvdXQgbXVsdGljYXN0IGFuZCBub3QgVk9EIChwbGVhc2Ugbm90ZSB0 aGUgY2hhbm5lbCBjaGFuZ2Ugc2NlbmFyaW8gbWVudGlvbmVkIGluIHRoZXJlKS4gQU4gbWF5IHdh bnQgdG8gb3B0aW9uYWxseSBub3RpZnkgTkFTIG9mIG11bHRpY2FzdCwgc3VjaCB0aGF0IE5BUyBj YW4gYWRqdXN0IHVuaWNhc3QgYi93IGxvd2VyIGR1ZSB0byBtdWx0aWNhc3QgYmVpbmcgc2VudCBv biBNVkxBTiAoYXMgbXVsdGljYXN0IGJ5cGFzc2VzIG5vcm1hbCBRT1MgaGllcmFyY2h5IGZvciB0 aGUgc3Vic2NyaWJlcikuIFRoZSBwb2ludCBJIHRyaWVkIG1ha2luZyBpcyB0aGF0IEFOIHdpbGwg bmVlZCB0byBob2xkIG9mZiBvbiByZXBsaWNhdGlvbiB0aWxsIGl0IGdldHMgYW4gQUNLIGJhY2sg ZnJvbSBOQVMgd2hlbiBub3RpZnlpbmcgaXQgb2YgUU9TLWFkanVzdC4gT3JpZ2luYWwgcmVzcG9u c2UgZnJvbSBGcmFuY29pcyBzZWVtZWQgdG8gaW1wbHkgbm8gcm91bmQtdHJpcCB3YXMgbmVlZGVk IGJlZm9yZSBBTiBzdGFydHMgcmVwbGljYXRpb24gKHdoaWNoIEkgZG9uJ3QgYmVsaWV2ZSBpcyB0 aGUgY2FzZSkuDQoNCltLcmlzXU9rLCAgSSB0aGluayB0aGlzIGlzIHdoZXJlIHRoZSBkaXNjb25u ZWN0IGlzLiBUaGlzIG5ldyBtZXNzYWdlIHRoYXQgaXMgYmVpbmcgcHJvcG9zZWQgdG8gdXBkYXRl IHRoZSBiL3cgdXNhZ2UgKG5vdCB0aGUgYWxsb2NhdGlvbikgaXMgc2VudCBmcm9tIHRoZSBBTiB0 byB0aGUgTkFTLiBUaGlzIHdpbGwgYmUgZG9uZSBvbmx5IGlmIHRoZXJlIGlzIGEgZGlmZmVyZW5j ZSBpbiBjaGFubmVsIGIvdyB1c2FnZS4gQmFzZWQgb24gdGhpcyBtZXNzYWdlLCB0aGUgTkFTIHdp bGwgYWRqdXN0IGl0cyBiL3cgZm9yIHVuaWNhc3QuIEZvciBleGFtcGxlLCBhIG5ldyBqb2luIGNv bWVzIGZvciBhICA1bWJwcyBjaGFubmVsLiBJZiB0aGlzIGNoYW5uZWwgaXMgYWRtaXR0ZWQgYnkg dGhlIEFOLCB0aGUgQU4gd2lsbCBzZW5kIGEgbmV3IGIvdyB1c2FnZSByZXBvcnQgKHRvdGFsIG5l dyBzdWIgdXNhZ2UgPSBvbGQgKyA1bWJwcykuIFRoZSBOQVMgd2lsbCBub3cga25vdyB0aGF0IHRo ZSBzdWJzY3JpYmVyIGlzIGdldHRpbmcgbW9yZSB2aWRlbyBiL3cgKG1jYXN0IGNoYW5uZWwgYnlw YXNzaW5nIHN1YnNjcmliZXLigJlzIFFvUyBoaWVyYXJjaHkpLiBTbyB0aGUgTlMgd2lsbCBsb3dl ciBpdHMgYWdncmVnYXRlIHJhdGUgZm9yIHRoZSBzdWJzY3JpYmVyIGZvciB0aGUgLTVNYnBzLiBX aXRoaW4gdGhpcyBuZXcgYWdncmVnYXRlIChtaW51cyA1bWJwcykgLCB2aWRlbyBzdGlsbCBoYXMg YSBoaWdoZXIgcHJpb3JpdHkgdGhhbiBIU0kgc28gdGhlIG9ubHkgYWZmZWN0ZWQgdHJhZmZpYyB3 aWxsIGJlIEhTSS4gIEZvciB0aGlzIEkgYWxzbyAoYXMgRnJhbmNvaXMpIGRvIG5vdCBiZWxpZXZl IHRoYXQgYW55IGZlZWRiYWNrIGlzIG5lY2Vzc2FyeSBiYWNrIGZyb20gdGhlIE5BUy4NCg0KT25l IGFub3RoZXIgbm90ZSwgdGhlIEFOQ1AgZHJhZnQgVGFyZ2V0IFRMViBkZWZpbml0aW9ucyBhcmUg bW9zdGx5IGZvY3VzZWQgb24gRFNMQU0gZW52aXJvbm1lbnRzLiBCdXQgaW4gdGhlIFBPTiBlbnZp cm9ubWVudCwgaWYgd2UgbmVlZCB0byBtYW5hZ2UgYi93IHBlciBQT04sIHVwbGluayBhbmQgdGhl IHN1YnNjcmliZXIsIHdl4oCZbGwgbmVlZCAzIFRhcmdldCBUTFZzLiBNYXliZSB0aGlzIHdpbGwg YmUgZGVmaW5lZCBpbiB0aGUgZHJhZnQgdGhhdCB5b3UgYXJlIHdvcmtpbmcgb24gKEdQT04pPw0K DQogDQoNCltTV10gVGhlIHRhcmdldCBUTFYgaXMgZXh0ZW5zaWJsZS4gUE9OIHNwZWNpZmljIHR5 cGVzIGFzIHlvdSBtZW50aW9uIG5lZWQgdG8gYmUgZGVmaW5lZCAodG8gYWxzbyBpbmNsdWRlIFBP TiBhbmQgdXBsaW5rKS4gVGhlIFBPTiBkcmFmdCBjb3ZlcnMgdGhlIG1vZGVscyBhbmQgaW5mb3Jt YXRpb24gZXhjaGFuZ2VkIGF0IGEgIGhpZ2ggbGV2ZWwuIFRoZSBzcGVjaWZpYyBUTFZzIGluIHRo ZSBtZXNzYWdlcyBuZWVkIHRvIGdvIGluIHRoZSBwcm90b2NvbCBkcmFmdC4gSSBiZWxpZXZlIGZv ciB0aGUgbW9kZWwgZGlzY3Vzc2VkIGhlcmUsIHlvdSB3aWxsIGFsc28gbmVlZCBBZG1pc3Npb24g Q29udHJvbCBtZXNzYWdlIChOQVMgdG8gQU4pIGV4dGVuZGVkIGZvciBWT0QgKGUuZyB0byBjYXJy eSByZXF1ZXN0ZWQgYmFuZHdpZHRoKS4gDQoNCiANCg0KVGhhbmtzDQoNCi1TYW5qYXkNCg0KICAN Cg0KRnJvbTogU2FuamF5IFdhZGh3YSBbbWFpbHRvOnN3YWRod2EwMUB5YWhvby5jb21dIA0KU2Vu dDogRnJpZGF5LCBBcHJpbCAwMiwgMjAxMCA5OjM2IFBNDQpUbzogRnJhbmNvaXMgTGUgRmF1Y2hl dXINCkNjOiBGcmFuY29pcyBMZSBGYXVjaGV1cjsgUE9TQ0lDIEtyaXN0aWFuOyBhbmNwQGlldGYu b3JnDQpTdWJqZWN0OiBSZToNCg0KIA0KDQpIaSBGcmFuY29pcywgS3Jpcw0KICBXaGF0IGlzIG5l ZWRlZCBkZXBlbmRzIG9uIGF0IGxlYXN0IHR3byBrZXkgdmFyaWFibGVzOg0KICAxLiBIb3cgZHlu YW1pYyBkbyB5b3Ugd2FudCB0aGUgcGVyLXN1YnNjcmliZXIgYmFuZHdpZHRoIG1hbmFnZW1lbnQg YWNyb3NzIGRpZmZlcmVudCB0cmFmZmljIHR5cGVzIHRvIGJlLiBUaGlzIGluY2x1ZGVzIG1hbmFn ZWQgVk9ELCBtdWx0aWNhc3QgYW5kIGJlc3QtZWZmb3J0IHRyYWZmaWMuIA0KICAyLiBXaGVyZSBk byB5b3Ugd2FudCB0aGUgdW5pZmllZCBiYW5kd2lkdGggYWRtaXNzaW9uIGNvbnRyb2wgYWNyb3Nz IG11bHRpY2FzdCBhbmQgbWFuYWdlZCBWT0QgdG8gaGFwcGVuIChBTiBvciBOQVMpLiANCldlIGNh biBjb25zaWRlciBtb3N0IG9wdGltYWwgaW50ZXJhY3Rpb25zIGJhc2VkIG9uIHRoZSBtb2RlbCBj aG9zZW4uIEhvd2V2ZXIsIHRoZSBwcm90b2NvbCBuZWVkcyB0byBhbGxvdyBhbGwgdmFyaWF0aW9u cy4NCg0KTm93LCBzcGVjaWZpYyB0byB5b3VyIGV4YW1wbGVzLCB5b3UgaGF2ZSBhc3N1bWVkIGlu IGJhbmR3aWR0aCBkZWxlZ2F0aW9uIG1vZGVsIHRoYXQgbm8gbWluaW1hbCBpbml0aWFsIGJhbmR3 aWR0aCBpcyBkZWxlZ2F0ZWQgdG8gQU4sIHdoaWNoIGRvZXNuJ3QgbmVlZCB0byBiZSB0aGUgY2Fz ZS4NCkluIHlvdXIgc2Vjb25kIGV4YW1wbGUgeW91IGFyZSBhbGxvY2F0aW5nIGluIGluaXRpYWwg YW1vdW50IG9mIGJhbmR3aWR0aCBkZWxlZ2F0ZWQgdG8gQU4gKHBlcmhhcHMgZHVlIHRvIGR5bmFt aWMgdXBkYXRlcyBvZiBhbGxvY2F0ZWQgYi93IHlvdSBhc3N1bWUgaXQgaXMgb2spLiBIb3dldmVy LCBiYXNlZCBvbiByZXBvcnRlZCBiYW5kd2lkdGggdXRpbGl6YXRpb24gZnJvbSBBTiwgdGhlIE5B UyBjb3VsZCB1c2UgdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggZm9yIHVuaWNhc3QgdHJhZmZpYyAo aW5jbHVkaW5nIGJlc3QtZWZmb3J0KS4gTmV4dCB0aW1lIGFyb3VuZCB3aGVuIEFOIGdldHMgYSBy ZXF1ZXN0IGZvciBoaWdoZXIgYmFuZHdpZHRoICBtdWx0aWNhc3QgY2hhbm5lbCwgaXQgY2FuJ3Qg YXNzdW1lIGJhbmR3aWR0aCBpcyBhdmFpbGFibGUsIGFuZCBzaG91bGQgdXBkYXRlIE5BUyBiZWZv cmUgcmVwbGljYXRpbmcuIEkgZG9uJ3Qgc2VlIHNwZWNpZmljIGFkdmFudGFnZS9vcHRpbWFsaXR5 IHdpdGggdGhlIHNlY29uZCBleGFtcGxlLg0KDQpCYXNlZCBvbiBLcmlzJ3MgcXVlc3Rpb25zIEkg YW0gZXh0cmFwb2xhdGluZyB0aGUgbW9kZWwgaW4gcXVlc3Rpb24gaXMgdGhlIGZvbGxvd2luZzoN Cg0KICAxLiBBTiBtYW5hZ2VzIGFzc2lnbmVkIHZpZGVvIGJhbmR3aWR0aCBhbmQgZG9lcyB1bmlm aWVkIGJhbmR3aWR0aCBhZG1pc3Npb24gY29udHJvbCAoQUMpIGFnYWluc3QgaXQuDQogIDIuIEFO IHRlcm1pbmF0ZXMgcGVyLXN1YnNjcmliZXIgbXVsdGljYXN0IGFuZCByZXBsaWNhdGVzIGJhc2Vk IG9uIGFuIGFkbWlzc2lvbiBjb250cm9sIGRlY2lzaW9uLg0KICAzLiBXaGVuIFZPRCByZXF1ZXN0 IG5lZWRzIHRvIGJlIGFkbWl0dGVkLCBwb2xpY3kgc2VydmVyIHRocm91Z2ggTkFTIHF1ZXJpZXMg YXZhaWxhYmxlIGJhbmR3aWR0aCBvbiB0aGUgQU4uIFRoaXMgaXMgYSByZXZlcnNlIEFDIHJlcXVl c3QgKGZyb20gTkFTIHRvIEFOIGZvciB1bmljYXN0IHZpZGVvKS4gSWYgYmFuZHdpZHRoIGlzIGF2 YWlsYWJsZSwgVk9EIGZsb3cgaXMgYWRtaXR0ZWQgYnkgTkFTLiBBTiBhbHdheXMgaGFzIHRoZSBs YXRlc3QgdmlldyBvZiBhdmFpbGFibGUgYmFuZHdpZHRoLiBNYWtpbmcgQUMgcmVxdWVzdC9yZXNw b25zZSBiaWRpcmVjdGlvbmFsIGFuZCBzcGVjaWZ5aW5nIGJhbmR3aWR0aCB2YWx1ZSBpbiBBQyBy ZXF1ZXN0IGNhbiBhY2NvbW9kYXRlIHRoaXMgaW50ZXJhY3Rpb24uDQogIDQuIEFOIG5vdGlmaWVz IE5BUyBvZiBiYW5kd2lkdGggYWxsb2NhdGlvbnMgZm9yIG11bHRpY2FzdCwgc28gTkFTIGNhbiBh ZGp1c3QgYmFuZHdpZHRoIGZvciB1bmljYXN0IChlLmcuIGJlc3QtZWZmb3J0KSB0cmFmZmljIGFj Y29yZGluZ2x5LiBIb3dldmVyLCBpZiBBTiBuZWVkcyB0byBpbmZvcm0gTkFTIHRvIGFkanVzdCBi YW5kd2lkdGggZm9yIHVuaWNhc3QgKGJlc3QtZWZmb3J0KSB0cmFmZmljIGxvd2VyIChkdWUgdG8g c2F5IGEgU0QtPkhEIG11bHRpY2FzdCBsZWF2ZS9qb2luIHNlcXVlbmNlKSwgaXQgZG9lcyBuZWVk IHRvIHNlbmQgYSByZXF1ZXN0IHRvIE5BUyBhbmQgaWRlYWxseSB3YWl0IGZvciBhIHJlc3BvbnNl IGJlZm9yZSByZXBsaWNhdGluZy4gVGhpcyByb3VuZC10cmlwIGlzIG5vdCBhdm9pZGFibGUgaWYg b25lIHdhbnRzIHRoZSBtb3N0ICAgICAgZHluYW1pYy9vcHRpbWFsIGJhbmR3aWR0aCB1c2FnZSwg d2hlcmUgdW5pY2FzdCBiZXN0LWVmZm9ydCB0cmFmZmljIGNvdWxkIHV0aWxpemUgdW51c2VkIGF2 YWlsYWJsZSB2aWRlbyBiYW5kd2lkdGggYW5kIGdldCB0aHJvdHRsZWQgZG93biB3aGVuIG11bHRp Y2FzdCBuZWVkcyB0aGUgYmFuZHdpZHRoIChvZmNvdXJzZSB0aGlzIGlzIGRlcGVuZGVudCBvbiBo b3cgb3BlcmF0b3Igd2FudHMgdG8gbWFuYWdlIHN1YnNjcmliZXIncyBiYW5kd2RpdGgpLiBGb3Ig dGhpcyBpbnRlcmFjdGlvbiBlaXRoZXIgYSBuZXcgImJhbmR3aWR0aCByZXBvcml0bmciIG1lc3Nh Z2Ugb3IgYSBzdWItdHlwZSBvZiBhbiBleGlzdGluZyBtZXNzYWdlIGNhbiBiZSB1c2VkLg0KDQot U2FuamF5DQoNCnBzLiBUaGUgbW9kZWwgd2hlcmUgdW5pZmllZCBBQyBoYXBwZW5zIG9uIE5BUyBo YXMgaXRzIG93biBiZW5lZml0cyAoZS5nLiBzaW1wbGljaXR5KSwgc28gbm90IG5lY2Vzc2FyaWx5 IGFkdm9jYXRpbmcgdGhlIGFib3ZlIG1vZGVsIHdpdGggQU4gYmFzZWQgQUMsIGJ1dCB3ZSBuZWVk IHRvIGFjY29tbW9kYXRlIGJvdGguDQoNCg0KLS0tIE9uIFRodSwgNC8xLzEwLCBGcmFuY29pcyBM ZSBGYXVjaGV1ciA8ZmxlZmF1Y2hAY2lzY28uY29tPiB3cm90ZToNCg0KDQpGcm9tOiBGcmFuY29p cyBMZSBGYXVjaGV1ciA8ZmxlZmF1Y2hAY2lzY28uY29tPg0KU3ViamVjdDogUmU6DQpUbzogIlNh bmpheSBXYWRod2EiIDxzd2FkaHdhMDFAeWFob28uY29tPg0KQ2M6ICJGcmFuY29pcyBMZSBGYXVj aGV1ciIgPGZsZWZhdWNoQGNpc2NvLmNvbT4sIEtyaXN0aWFuLlBvc2NpY0BhbGNhdGVsLWx1Y2Vu dC5jb20sIGFuY3BAaWV0Zi5vcmcNCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAxLCAyMDEwLCAxMDow MiBBTQ0KDQpIaSBTYW5qYXksDQoNCk9uIDMxIE1hciAyMDEwLCBhdCAwNDo0MCwgU2FuamF5IFdh ZGh3YSB3cm90ZToNCj4gDQo+IFtTV10gVGhlIHNjZW5hcmlvIGFib3ZlLCB3aGVyZSBOQVMgc2Vu ZHMgdGhlIGNoYW5uZWwgb24gTUMtVkxBTiwgYXNzdW1lcyBOQVMgaXMgZG9pbmcgYmFuZHdpZHRo IGJhc2VkIEFDLiBBIGNoYW5uZWwgam9pbiBvbiBBTiBtYXkgdHJpZ2dlciBhbiBBQyByZXF1ZXN0 IG1lc3NhZ2UgdG8gTkFTLCB3aGljaCBzaG91bGQgdHJpZ2dlciBhIENBQyBkZWNpc2lvbiBhbmQg UU9TLWFkanVzdCBvbiBOQVMgYW5kIGEgcmVzcG9uc2UgYmFjayB0byBBTiAoYmVmb3JlIEFOIGNh biBwZXJmb3JtIHJlcGxpY2F0aW9uKS4gRG8gd2UgbmVlZCBhbm90aGVyIGJhbmR3aWR0aCB1cGRh dGUgbWVzc2FnZSBmcm9tIEFOIHRvIE5BUz8gSW4gY2FzZSBBTiBzZWVzIGEgY2hhbm5lbCBsZWF2 ZSAoYW5kIG5vIG5ldyBqb2luIGZvciBzb21lIHRpbWUpIG9yIGEgdXNlciBzd2l0Y2hlcyBmcm9t IEhEIHRvIFNELCB0aGVuIEFOIG1heSBkZWNpZGUgdG8gbm90aWZ5IE5BUyBvZiByZWxlYXNlZCBi YW5kd2lkdGguIEkgYmVsaWV2ZSB3ZSBhcmUgYWdhaW4gY292ZXJlZCBieSBleGlzdGluZyBBQyBy ZXF1ZXN0IG1lc3NhZ2UgZnJvbSBBTiB0byBOQVMgKGRlc2NyaWJlZCBpbiBtdWx0aWNhc3QgZXh0 ZW5zaW9ucyBkcmFmdCkuDQoNCklmIGFkbWlzc2lvbiBjb250cm9sIGlzIHRvIGJlIHBlcmZvcm1l ZCBieSBOQVMgKGllIEdyZXkgbGlzdCBtdWx0aWNhc3QgZmxvdyksIHRoZW4gSSBhZ3JlZSB3ZSBh cmUgYWxyZWFkeSBjb3ZlcmVkIGJ5IGV4aXN0aW5nIG11bHRpY2FzdCBwcm9jZWR1cmVzIGJlY2F1 c2UgdGhlIE5BUyBpcyBhbHdheXMgZnVsbHkgYXdhcmUgb2YgY3VycmVudGx5IGFkbWl0dGVkIG11 bHRpY2FzdCB0cmFmZmljIG9uIGEgZ2l2ZW4gcG9ydC4NCg0KPiANCj4gIE9uIHRoZSBvdGhlciBo YW5kIGlmIHdlIGFyZSBhc3N1bWluZyBiYW5kd2lkdGggZGVsZWdhdGlvbiBtb2RlbCBhbmQgYXV0 b25vbW91cyBBQyBvbiBBTiwNCg0KVGhhdCBpcyBpbmRlZWQgdGhlIGNhc2Ugb2YgaW50ZXJlc3Qs IGhlcmUuDQoNCj4gdGhlbiB3ZSBhcmUgYWxyZWFkeSBjb3ZlcmVkIHZpYSBpbnRlcmFjdGlvbiBy ZWxhdGVkIHRvIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIGJldHdlZW4gQU4gYW5kIE5BUy4NCg0KVGhh dCB3YXMgbXkgaW5pdGlhbCByZWFjdGlvbiB0b28uIEluZGVlZCwgSSB0aGluayBpdCBpcyBwb3Nz aWJsZSB0byBzdHJldGNoIGV4aXN0aW5nIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIHByb2NlZHVyZXMg dG8gYWNoaWV2ZSB0aGlzLiBIb3dldmVyIHRoaXMgd291bGQgcmVzdWx0IGluIHN1Yi1vcHRpbWFs IGhhbmRsaW5nIG9mIHRoZSBuZXcgdXNlIGNhc2UuDQoNCkV4YW1wbGUgY2FsbC1GbG93IGJhc2Vk IG9uIHJlLXVzaW5nIGV4aXN0aW5nIGJhbmR3aWR0aCBkZWxlZ2F0aW9uIHByb2NlZHVyZXM6DQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KQU4gPC0tLVBPUlRfTU5HVCAoQncgYWxsb2NhdGlvbj0wTWIvcykgLS1OQVMNCi4uLg0KKGpv aW4gZnJvbSBzdWJzY3JpYmVyIGZvciAyTWIvcyBtdWx0aWNhc3QgZmxvdykNCkFOIC0tLUJhbmR3 aWR0aCBSZWFsbG9jIFJlcXVlc3QgKDJNYi9zKS0tPiBOQVMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoTkFTIGFsbG9j YXRlcyAyTWIvcykNCkFOIDwtLS0tLS0tLUJhbmR3aWR0aCBUcmFuc2ZlciAoMk1iL3MpLS0tLS0t LS0gTkFTDQooQU4gc3RhcnRzIHJlcGxpY2F0aW5nKQ0KLi4uDQoobGVhdmUgKyBqb2luIGZyb20g c3Vic2NyaWJlciBmb3IgNE1iL3MgbXVsdGljYXN0IGZsb3cpDQpBTiAtLS1CYW5kd2lkdGggUmVh bGxvYyBSZXF1ZXN0ICg0TWIvcyktLT4gTkFTDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5BUyBhbGxvY2F0ZXMgNE1i L3MgdG90YWwpDQpBTiA8LS0tLS0tLS1CYW5kd2lkdGggVHJhbnNmZXIgKDRNYi9zKS0tLS0tLS0t IE5BUw0KKEFOIHN0YXJ0cyByZXBsaWNhdGluZykNCg0KDQpFeGFtcGxlIGNhbGwtRmxvdyBiYXNl ZCBvbiBuZXcgImFkbWl0dGVkIGJhbmR3aWR0aCByZXBvcnRpbmciIHByb2NlZHVyZXM6DQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkFO IDwtLS1QT1JUX01OR1QgKEJ3IGFsbG9jYXRpb249NE1iL3MpIC0tTkFTDQouLi4NCihqb2luIGZy b20gc3Vic2NyaWJlciBmb3IgMk1iL3MgbXVsdGljYXN0IGZsb3cpDQooQU4gZG9lcyBhZG1pc3Np b24gY29udHJvbCBhbmQgc3RhcnRzIHJlcGxpY2F0aW5nKQ0KQU4gLS0tLS0tQWRtaXR0ZWQgQmFu ZHdpZHRoIFJlcG9ydCgyTWIvcyktLS0+IE5BUw0KKGxlYXZlICsgam9pbiBmcm9tIHN1YnNjcmli ZXIgZm9yIDRNYi9zIG11bHRpY2FzdCBmbG93KQ0KKEFOIGRvZXMgYWRtaXNzaW9uIGNvbnRyb2wg YW5kIHN0YXJ0cyByZXBsaWNhdGluZykNCkFOIC0tLS0tLUFkbWl0dGVkIEJhbmR3aWR0aCBSZXBv cnQoNE1iL3MpLS0tLT4gTkFTDQoNCg0KU28sIHRoZSBzdWItb3B0aW1hbGl0aWVzIG9mIHJldXNp bmcgZXhpc3RpbmcgYmFuZHdpZHRoIGRlbGVnYXRpb24gcHJvY2VkdXJlcyBpbmNsdWRlOg0KICAg ICphKiB1c2Ugb2YgdHdvIG1lc3NhZ2VzIGluc3RlYWQgb2Ygb25lLCBmb3IgZXZlcnkgYmFuZHdp ZHRoIGNoYW5nZQ0KICAgICpiKiBleHRyYSBkZWxheSBvbiBBTiAoaWUgbmVlZCB0byB3YWl0IGZv ciBBTkNQIHJvdW5kLXRyaXAgaW5zdGVhZCBvZiBpbW1lZGlhdGVseSByZXBsaWNhdGUpDQogICAg KmMqIHVubmVjZXNzYXJ5ICJiYW5kd2lkdGggY2hlY2siIGZvciAicmVhbGxvY2F0aW9uIiBvbiBO QVMNCg0KSSdkIHNheSB0aGVzZSBzdWItb3B0aW1hbGl0aWVzIGp1c3RpZnkgYSBuZXcgcHJvY2Vk dXJlcywgYnV0IEknbSB3aWxsaW5nIHRvIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuDQpJIHN1cHBv c2Ugb25lIGNvdWxkIGFyZ3VlIHRoYXQgaW4gdGhlIG1ham9yaXR5IG9mIGpvaW4vbGVhdmUvam9p biwgdGhlIGJhbmR3aWR0aCBkb2VzIG5vdCBjaGFuZ2UgKGllIHphcHBpbmcgYW1vbmcgY2hhbm5l bHMgb2Ygc2FtZSBiYW5kd2lkdGgpLCBzbyB0aGUgc3ViLW9wdGltYWxpdHkgKmEqIGlzIG9ubHkg aW5jdXJyZWQgaW4gbGVzcyBjb21tb24gY2FzZSAobGVhdmVTRCwgam9pbkhEKS4NCg0KVGhvdWdo dHMgZXZlcnlvbmU/DQoNCkZyYW5jb2lzDQoNCg0KDQoNCg0KDQpGcmFuY29pcyBMZSBGYXVjaGV1 cg0KRGlzdGluZ3Vpc2hlZCBFbmdpbmVlcg0KQ29ycG9yYXRlIERldmVsb3BtZW50DQpmbGVmYXVj aEBjaXNjby5jb20NClBob25lOiArMzMgNDkgNzIzIDI2MTkNCk1vYmlsZTogKzMzIDYgMTkgOTgg NTAgOTANCg0KDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlDQpHcmVlbnNpZGUNCjQwMCBBdmUgZGUg Um91bWFuaWxsZQ0KMDY0MTAgU29waGlhIEFudGlwb2xpcw0KRnJhbmNlDQpDaXNjby5jb20NCg0K DQoNCg0KVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCg0KVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRo ZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFu ZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQoNCkNpc2NvIFN5c3RlbXMgRnJh bmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERl c21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElz c3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEg UkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hl bCBHaXZvbmUuDQoNCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQpodHRw Oi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4 Lmh0bWwgPGh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdh bC9jcmkvaW5kZXguaHRtbD4gDQoNCiANCg0KIA0KDQo= ------_=_NextPart_001_01CAD47A.C4E31939 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0Kc3Bhbi5lbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxzdHlsZTE3 O30NCnNwYW4uZW1haWxzdHlsZTE3MQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMTcxOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxi b2R5IGxhbmc9RU4tVVMgbGluaz0iIzAwMDAwMCIgdmxpbms9IiMwMDAwMDAiPg0KDQo8ZGl2IGNs YXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPkhpIFNhbnlhaiDigJMgcGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+S3JpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBTYW5qYXkgV2FkaHdhDQpbbWFpbHRvOnN3 YWRod2EwMUB5YWhvby5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEFwcmlsIDA0LCAy MDEwIDg6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IEZyYW5jb2lzIExlIEZhdWNoZXVyOyBQT1NDSUMg S3Jpc3RpYW48YnI+DQo8Yj5DYzo8L2I+IEZyYW5jb2lzIExlIEZhdWNoZXVyOyBhbmNwQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHRhYmxl IGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9 MD4NCiA8dHI+DQogIDx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBp bic+DQogIDxwIGNsYXNzPU1zb05vcm1hbD5IaSBLcmlzPGJyPg0KICAmbmJzcDsgUGxlYXNlIHNl ZSBpbmxpbmUgW1NXXS48YnI+DQogIDxicj4NCiAgVGhhbmtzPGJyPg0KICAtU2FuamF5PGJyPg0K ICA8YnI+DQogIC0tLSBPbiA8Yj5TdW4sIDQvNC8xMCwgUE9TQ0lDIEtyaXN0aWFuIDxpPiZsdDtL cmlzdGlhbi5Qb3NjaWNAYWxjYXRlbC1sdWNlbnQuY29tJmd0OzwvaT48L2I+DQogIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48YnI+DQogIEZyb206IFBPU0NJQyBLcmlzdGlhbiAmbHQ7S3Jpc3RpYW4uUG9zY2lj QGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8YnI+DQogIFN1YmplY3Q6IFJFOjxicj4NCiAgVG86ICZx dW90O1NhbmpheSBXYWRod2EmcXVvdDsgJmx0O3N3YWRod2EwMUB5YWhvby5jb20mZ3Q7LCAmcXVv dDtGcmFuY29pcyBMZQ0KICBGYXVjaGV1ciZxdW90OyAmbHQ7ZmxlZmF1Y2hAY2lzY28uY29tJmd0 Ozxicj4NCiAgQ2M6ICZxdW90O0ZyYW5jb2lzIExlIEZhdWNoZXVyJnF1b3Q7ICZsdDtmbGVmYXVj aEBjaXNjby5jb20mZ3Q7LA0KICBhbmNwQGlldGYub3JnPGJyPg0KICBEYXRlOiBTdW5kYXksIEFw cmlsIDQsIDIwMTAsIDI6NTkgQU08bzpwPjwvbzpwPjwvcD4NCiAgPGRpdiBpZD15aXYxOTI4OTM3 NzEwPg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0KICBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5IaQ0KICBTYW5qYXkg4oCTIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4NCiAgdGhlIG1vZGVsIHRoYXQg SSB3YXMgdGhpbmtpbmcsIHRoZSBzdGVwcyAzIGFuZCA0IGFyZSBsaXR0bGUgYml0IGRpZmZlcmVu dDo8L3NwYW4+PG86cD48L286cD48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuDQog IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VmlkZW8NCiAgYi93IHRoYXQgY2Fu IGJlIGFsbG9jYXRlZCBpbiB0aGUgQU4gaXMgc2hhcmVkIGJldHdlZW4gdGhlIG1jYXN0IGFuZCBW b0QuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4N CiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+MykNCiAgUG9saWN5IHNlcnZlciBtYWtlcyB0aGUgVk9EIGRlY2lz aW9uLiBOQVMgaXMgdHJhbnNwYXJlbnQgdG8gdGhpcy4gSXTigJlzIGFjdGluZw0KICBqdXRzIGFz IGFuIGludGVybWVkaWFyeSBiZXR3ZWVuIHRoZSBwb2xpY3kgc2VydmVyIGFuZCB0aGUgQU4uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+W1NXXQ0KICBJIGltcGxpZWQgdGhlIHNh bWUgaW4gIzMgYmVsb3cuIFBvbGljeSBzZXJ2ZXIgcXVlcmllcyBBTiB2aWEgTkFTICh0aHJvdWdo DQogIEFOQ1AgYmV0d2VlbiBOQVMgYW5kIEFOKS4gVGhlIGRlY2lzaW9uIHRvIGFkbWl0IHRoZSBW T0QgaXMgYmVpbmcgbWFkZSBvbiB0aGUNCiAgQU4gaW4gdGhpcyBtb2RlbCwgYXMgaXQgaXMgbWFu YWdpbmcgdGhpcyBzaGFyZWQgYi93IHBvb2wgYmV0d2VlbiBWT0QgYW5kDQogIG11bHRpY2FzdCwg YW5kIGlzIGNvbnZleWluZyBiYWNrIHRoZSByZXNwb25zZSB2aWEgQU5DUCB0byBOQVMgKHdoaWNo IGNvdWxkDQogIHRoZW4gYmUgY29udmV5ZWQgdmlhIG5vcnRoLWJvdW5kIGludGVyZmFjZSBmcm9t IE5BUyB0byBwb2xpY3ktc2VydmVyKS4gUGxlYXNlDQogIGxldCBtZSBrbm93IGlmIHRoaXMgaXMg ZGlmZmVyZW50IHRoYW4gd2hhdCB5b3UgYXJlIHRoaW5raW5nLjxvOnA+PC9vOnA+PC9wPg0KICA8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48Yj48aT48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltLcmlz XQ0KICBZZXMsIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLiBJIHdhcyBjb25mdXNlZCBieSB0aGlz IHN0YXRlbWVudCBpbiB5b3VyDQogIG9yaWdpbmFsIHBvc3Q6PC9zcGFuPjwvaT48L2I+IElmIGJh bmR3aWR0aCBpcyBhdmFpbGFibGUsIFZPRCBmbG93IGlzIGFkbWl0dGVkDQogIGJ5IE5BUy4gPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCiAgY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KICA8cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjQpIElmDQogIHRoZSBiL3cgYXNrZWQgYnkgdGhlIHBv bGljeSBzZXJ2ZXIgaXMgYXZhaWxhYmxlIGluIHRoZSBBTiwgdGhlIEFOIHdpbGwgc2VuZA0KICBh biBBQ0sgd2hpY2ggd2lsbCBiZSBjb252ZXllZCB0byB0aGUgcG9saWN5IHNlcnZlciB0aHJvdWdo IHRoZSBOQVMuIFRoZQ0KICBwb2xpY3kgc2VydmVyIHdpbGwgYWxsb3cgdGhlIFZPRCBmbG93IGFu ZCB1cGRhdGUgaXMgcmVzb3VyY2UgcmVzZXJ2YXRpb24NCiAgdGFibGUuIE5vdGhpbmcgZWxzZSBp cyBuZWVkZWQuIFRoZSB1bmljYXN0IFZvRCBmbG93IHdpbGwgYmUgYXV0b21hdGljYWxseQ0KICBh Y2NvdW50ZWQgZm9yIGluIHRoZSBRb1MgaW4gdGhlIE5BUyBhcyBpdCBpcyBmbG93aW5nIHRocm91 Z2ggdGhlIHN1YnNjcmliZXINCiAgcXVldWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0KICBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5CL3cNCiAgdXNhZ2UgcmVwb3J0aW5nIGZyb20gdGhlIEFOIHRvIHRoZSBOQVMgaGFzIHRv IGRvIG9ubHkgd2l0aCB0aGUgbXVsdGljYXN0IEFDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAg PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7DQogIDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+W1NXXSBJbjxpPiA8L2k+IzQgYmVsb3cgSSBhbQ0KICBvbmx5IHRhbGtp bmcgYWJvdXQgbXVsdGljYXN0IGFuZCBub3QgVk9EIChwbGVhc2Ugbm90ZSB0aGUgY2hhbm5lbCBj aGFuZ2UNCiAgc2NlbmFyaW8gbWVudGlvbmVkIGluIHRoZXJlKS4gQU4gbWF5IHdhbnQgdG8gb3B0 aW9uYWxseSBub3RpZnkgTkFTIG9mDQogIG11bHRpY2FzdCwgc3VjaCB0aGF0IE5BUyBjYW4gYWRq dXN0IHVuaWNhc3QgYi93IGxvd2VyIGR1ZSB0byBtdWx0aWNhc3QgYmVpbmcNCiAgc2VudCBvbiBN VkxBTiAoYXMgbXVsdGljYXN0IGJ5cGFzc2VzIG5vcm1hbCBRT1MgaGllcmFyY2h5IGZvciB0aGUN CiAgc3Vic2NyaWJlcikuIFRoZSBwb2ludCBJIHRyaWVkIG1ha2luZyBpcyB0aGF0IEFOIHdpbGwg bmVlZCB0byBob2xkIG9mZiBvbg0KICByZXBsaWNhdGlvbiB0aWxsIGl0IGdldHMgYW4gQUNLIGJh Y2sgZnJvbSBOQVMgd2hlbiBub3RpZnlpbmcgaXQgb2YNCiAgUU9TLWFkanVzdC4gT3JpZ2luYWwg cmVzcG9uc2UgZnJvbSBGcmFuY29pcyBzZWVtZWQgdG8gaW1wbHkgbm8gcm91bmQtdHJpcCB3YXMN CiAgbmVlZGVkIGJlZm9yZSBBTiBzdGFydHMgcmVwbGljYXRpb24gKHdoaWNoIEkgZG9uJ3QgYmVs aWV2ZSBpcyB0aGUgY2FzZSkuPG86cD48L286cD48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQogIDExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPltLcmlzXU9rLCDCoEkgdGhpbmsNCiAgdGhpcyBpcyB3aGVyZSB0aGUgZGlzY29ubmVjdCBp cy4gVGhpcyBuZXcgbWVzc2FnZSB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIHRvDQogIHVwZGF0ZSB0 aGUgYi93IHVzYWdlIChub3QgdGhlIGFsbG9jYXRpb24pIGlzIHNlbnQgZnJvbSB0aGUgQU4gdG8g dGhlIE5BUy4NCiAgVGhpcyB3aWxsIGJlIGRvbmUgb25seSBpZiB0aGVyZSBpcyBhIGRpZmZlcmVu Y2UgaW4gY2hhbm5lbCBiL3cgdXNhZ2UuIEJhc2VkDQogIG9uIHRoaXMgbWVzc2FnZSwgdGhlIE5B UyB3aWxsIGFkanVzdCBpdHMgYi93IGZvciB1bmljYXN0LiBGb3IgZXhhbXBsZSwgYSBuZXcNCiAg am9pbiBjb21lcyBmb3IgYSDCoDVtYnBzIGNoYW5uZWwuIElmIHRoaXMgY2hhbm5lbCBpcyBhZG1p dHRlZCBieSB0aGUgQU4sIHRoZQ0KICBBTiB3aWxsIHNlbmQgYSBuZXcgYi93IHVzYWdlIHJlcG9y dCAodG90YWwgbmV3IHN1YiB1c2FnZSA9IG9sZCArIDVtYnBzKS4gVGhlDQogIE5BUyB3aWxsIG5v dyBrbm93IHRoYXQgdGhlIHN1YnNjcmliZXIgaXMgZ2V0dGluZyBtb3JlIHZpZGVvIGIvdyAobWNh c3QNCiAgY2hhbm5lbCBieXBhc3Npbmcgc3Vic2NyaWJlcuKAmXMgUW9TIGhpZXJhcmNoeSkuIFNv IHRoZSBOUyB3aWxsIGxvd2VyIGl0cyBhZ2dyZWdhdGUNCiAgcmF0ZSBmb3IgdGhlIHN1YnNjcmli ZXIgZm9yIHRoZSAtNU1icHMuIFdpdGhpbiB0aGlzIG5ldyBhZ2dyZWdhdGUgKG1pbnVzDQogIDVt YnBzKSAsIHZpZGVvIHN0aWxsIGhhcyBhIGhpZ2hlciBwcmlvcml0eSB0aGFuIEhTSSBzbyB0aGUg b25seSBhZmZlY3RlZA0KICB0cmFmZmljIHdpbGwgYmUgSFNJLiDCoEZvciB0aGlzIEkgYWxzbyAo YXMgRnJhbmNvaXMpIGRvIG5vdCBiZWxpZXZlIHRoYXQgYW55DQogIGZlZWRiYWNrIGlzIG5lY2Vz c2FyeSBiYWNrIGZyb20gdGhlIE5BUy48L3NwYW4+PC9pPjwvYj48c3Bhbg0KICBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+T25lDQogIGFub3RoZXIgbm90ZSwgdGhlIEFOQ1AgZHJhZnQg VGFyZ2V0IFRMViBkZWZpbml0aW9ucyBhcmUgbW9zdGx5IGZvY3VzZWQgb24NCiAgRFNMQU0gZW52 aXJvbm1lbnRzLiBCdXQgaW4gdGhlIFBPTiBlbnZpcm9ubWVudCwgaWYgd2UgbmVlZCB0byBtYW5h Z2UgYi93IHBlcg0KICBQT04sIHVwbGluayBhbmQgdGhlIHN1YnNjcmliZXIsIHdl4oCZbGwgbmVl ZCAzIFRhcmdldCBUTFZzLiBNYXliZSB0aGlzIHdpbGwgYmUNCiAgZGVmaW5lZCBpbiB0aGUgZHJh ZnQgdGhhdCB5b3UgYXJlIHdvcmtpbmcgb24gKEdQT04pPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PG86cD4mbmJzcDs8L286cD48L3A+DQogIDxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltTV10NCiAgVGhlIHRhcmdldCBU TFYgaXMgZXh0ZW5zaWJsZS4gUE9OIHNwZWNpZmljIHR5cGVzIGFzIHlvdSBtZW50aW9uIG5lZWQg dG8gYmUNCiAgZGVmaW5lZCAodG8gYWxzbyBpbmNsdWRlIFBPTiBhbmQgdXBsaW5rKS4gVGhlIFBP TiBkcmFmdCBjb3ZlcnMgdGhlIG1vZGVscyBhbmQNCiAgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGF0 IGEmbmJzcDsgaGlnaCBsZXZlbC4gVGhlIHNwZWNpZmljIFRMVnMgaW4gdGhlDQogIG1lc3NhZ2Vz IG5lZWQgdG8gZ28gaW4gdGhlIHByb3RvY29sIGRyYWZ0LiBJIGJlbGlldmUgZm9yIHRoZSBtb2Rl bCBkaXNjdXNzZWQNCiAgaGVyZSwgeW91IHdpbGwgYWxzbyBuZWVkIEFkbWlzc2lvbiBDb250cm9s IG1lc3NhZ2UgKE5BUyB0byBBTikgZXh0ZW5kZWQgZm9yDQogIFZPRCAoZS5nIHRvIGNhcnJ5IHJl cXVlc3RlZCBiYW5kd2lkdGgpLiA8L3NwYW4+PG86cD48L286cD48L3A+DQogIDxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5U aGFua3M8bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4NCiAgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPi1T YW5qYXk8L3NwYW4+PG86cD48L286cD48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsN CiAgY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCiAgPGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW47DQogIGJvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9y IC1tb3otdXNlLXRleHQtY29sb3InPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3Bhbg0K ICBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4gU2FuamF5IFdhZGh3YQ0KICBbbWFpbHRvOnN3 YWRod2EwMUB5YWhvby5jb21dIDxicj4NCiAgPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMDIs IDIwMTAgOTozNiBQTTxicj4NCiAgPGI+VG86PC9iPiBGcmFuY29pcyBMZSBGYXVjaGV1cjxicj4N CiAgPGI+Q2M6PC9iPiBGcmFuY29pcyBMZSBGYXVjaGV1cjsgUE9TQ0lDIEtyaXN0aWFuOyBhbmNw QGlldGYub3JnPGJyPg0KICA8Yj5TdWJqZWN0OjwvYj4gUmU6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KICA8L2Rpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ DQogIDx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNl bGxwYWRkaW5nPTA+DQogICA8dHI+DQogICAgPHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6 MGluIDBpbiAwaW4gMGluJz4NCiAgICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDoNCiAgICBhdXRvJz5IaSBGcmFu Y29pcywgS3Jpczxicj4NCiAgICAmbmJzcDsgV2hhdCBpcyBuZWVkZWQgZGVwZW5kcyBvbiBhdCBs ZWFzdCB0d28ga2V5IHZhcmlhYmxlczo8YnI+DQogICAgJm5ic3A7IDEuIEhvdyBkeW5hbWljIGRv IHlvdSB3YW50IHRoZSBwZXItc3Vic2NyaWJlciBiYW5kd2lkdGggbWFuYWdlbWVudA0KICAgIGFj cm9zcyBkaWZmZXJlbnQgdHJhZmZpYyB0eXBlcyB0byBiZS4gVGhpcyBpbmNsdWRlcyBtYW5hZ2Vk IFZPRCwgbXVsdGljYXN0DQogICAgYW5kIGJlc3QtZWZmb3J0IHRyYWZmaWMuIDxicj4NCiAgICAm bmJzcDsgMi4gV2hlcmUgZG8geW91IHdhbnQgdGhlIHVuaWZpZWQgYmFuZHdpZHRoIGFkbWlzc2lv biBjb250cm9sIGFjcm9zcw0KICAgIG11bHRpY2FzdCBhbmQgbWFuYWdlZCBWT0QgdG8gaGFwcGVu IChBTiBvciBOQVMpLiA8YnI+DQogICAgV2UgY2FuIGNvbnNpZGVyIG1vc3Qgb3B0aW1hbCBpbnRl cmFjdGlvbnMgYmFzZWQgb24gdGhlIG1vZGVsIGNob3Nlbi4NCiAgICBIb3dldmVyLCB0aGUgcHJv dG9jb2wgbmVlZHMgdG8gYWxsb3cgYWxsIHZhcmlhdGlvbnMuPGJyPg0KICAgIDxicj4NCiAgICBO b3csIHNwZWNpZmljIHRvIHlvdXIgZXhhbXBsZXMsIHlvdSBoYXZlIGFzc3VtZWQgaW4gYmFuZHdp ZHRoIGRlbGVnYXRpb24NCiAgICBtb2RlbCB0aGF0IG5vIG1pbmltYWwgaW5pdGlhbCBiYW5kd2lk dGggaXMgZGVsZWdhdGVkIHRvIEFOLCB3aGljaCBkb2Vzbid0DQogICAgbmVlZCB0byBiZSB0aGUg Y2FzZS48YnI+DQogICAgSW4geW91ciBzZWNvbmQgZXhhbXBsZSB5b3UgYXJlIGFsbG9jYXRpbmcg aW4gaW5pdGlhbCBhbW91bnQgb2YgYmFuZHdpZHRoDQogICAgZGVsZWdhdGVkIHRvIEFOIChwZXJo YXBzIGR1ZSB0byBkeW5hbWljIHVwZGF0ZXMgb2YgYWxsb2NhdGVkIGIvdyB5b3UgYXNzdW1lDQog ICAgaXQgaXMgb2spLiBIb3dldmVyLCBiYXNlZCBvbiByZXBvcnRlZCBiYW5kd2lkdGggdXRpbGl6 YXRpb24gZnJvbSBBTiwgdGhlDQogICAgTkFTIGNvdWxkIHVzZSB0aGUgYXZhaWxhYmxlIGJhbmR3 aWR0aCBmb3IgdW5pY2FzdCB0cmFmZmljIChpbmNsdWRpbmcNCiAgICBiZXN0LWVmZm9ydCkuIE5l eHQgdGltZSBhcm91bmQgd2hlbiBBTiBnZXRzIGEgcmVxdWVzdCBmb3IgaGlnaGVyDQogICAgYmFu ZHdpZHRoJm5ic3A7IG11bHRpY2FzdCBjaGFubmVsLCBpdCBjYW4ndCBhc3N1bWUgYmFuZHdpZHRo IGlzIGF2YWlsYWJsZSwNCiAgICBhbmQgc2hvdWxkIHVwZGF0ZSBOQVMgYmVmb3JlIHJlcGxpY2F0 aW5nLiBJIGRvbid0IHNlZSBzcGVjaWZpYw0KICAgIGFkdmFudGFnZS9vcHRpbWFsaXR5IHdpdGgg dGhlIHNlY29uZCBleGFtcGxlLjxicj4NCiAgICA8YnI+DQogICAgQmFzZWQgb24gS3JpcydzIHF1 ZXN0aW9ucyBJIGFtIGV4dHJhcG9sYXRpbmcgdGhlIG1vZGVsIGluIHF1ZXN0aW9uIGlzIHRoZQ0K ICAgIGZvbGxvd2luZzo8YnI+DQogICAgPGJyPg0KICAgICZuYnNwOyAxLiBBTiBtYW5hZ2VzIGFz c2lnbmVkIHZpZGVvIGJhbmR3aWR0aCBhbmQgZG9lcyB1bmlmaWVkIGJhbmR3aWR0aA0KICAgIGFk bWlzc2lvbiBjb250cm9sIChBQykgYWdhaW5zdCBpdC48YnI+DQogICAgJm5ic3A7IDIuIEFOIHRl cm1pbmF0ZXMgcGVyLXN1YnNjcmliZXIgbXVsdGljYXN0IGFuZCByZXBsaWNhdGVzIGJhc2VkIG9u IGFuDQogICAgYWRtaXNzaW9uIGNvbnRyb2wgZGVjaXNpb24uPGJyPg0KICAgICZuYnNwOyAzLiBX aGVuIFZPRCByZXF1ZXN0IG5lZWRzIHRvIGJlIGFkbWl0dGVkLCBwb2xpY3kgc2VydmVyIHRocm91 Z2ggTkFTDQogICAgcXVlcmllcyBhdmFpbGFibGUgYmFuZHdpZHRoIG9uIHRoZSBBTi4gVGhpcyBp cyBhIHJldmVyc2UgQUMgcmVxdWVzdCAoZnJvbQ0KICAgIE5BUyB0byBBTiBmb3IgdW5pY2FzdCB2 aWRlbykuIElmIGJhbmR3aWR0aCBpcyBhdmFpbGFibGUsIFZPRCBmbG93IGlzDQogICAgYWRtaXR0 ZWQgYnkgTkFTLiBBTiBhbHdheXMgaGFzIHRoZSBsYXRlc3QgdmlldyBvZiBhdmFpbGFibGUgYmFu ZHdpZHRoLg0KICAgIE1ha2luZyBBQyByZXF1ZXN0L3Jlc3BvbnNlIGJpZGlyZWN0aW9uYWwgYW5k IHNwZWNpZnlpbmcgYmFuZHdpZHRoIHZhbHVlIGluDQogICAgQUMgcmVxdWVzdCBjYW4gYWNjb21v ZGF0ZSB0aGlzIGludGVyYWN0aW9uLjxicj4NCiAgICAmbmJzcDsgNC4gQU4gbm90aWZpZXMgTkFT IG9mIGJhbmR3aWR0aCBhbGxvY2F0aW9ucyBmb3IgbXVsdGljYXN0LCBzbyBOQVMNCiAgICBjYW4g YWRqdXN0IGJhbmR3aWR0aCBmb3IgdW5pY2FzdCAoZS5nLiBiZXN0LWVmZm9ydCkgdHJhZmZpYyBh Y2NvcmRpbmdseS4NCiAgICBIb3dldmVyLCBpZiBBTiBuZWVkcyB0byBpbmZvcm0gTkFTIHRvIGFk anVzdCBiYW5kd2lkdGggZm9yIHVuaWNhc3QNCiAgICAoYmVzdC1lZmZvcnQpIHRyYWZmaWMgbG93 ZXIgKGR1ZSB0byBzYXkgYSBTRC0mZ3Q7SEQgbXVsdGljYXN0IGxlYXZlL2pvaW4NCiAgICBzZXF1 ZW5jZSksIGl0IGRvZXMgbmVlZCB0byBzZW5kIGEgcmVxdWVzdCB0byBOQVMgYW5kIGlkZWFsbHkg d2FpdCBmb3IgYQ0KICAgIHJlc3BvbnNlIGJlZm9yZSByZXBsaWNhdGluZy4gVGhpcyByb3VuZC10 cmlwIGlzIG5vdCBhdm9pZGFibGUgaWYgb25lIHdhbnRzDQogICAgdGhlIG1vc3QgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGR5bmFtaWMvb3B0aW1hbCBiYW5kd2lkdGggdXNhZ2UsIHdoZXJlDQog ICAgdW5pY2FzdCBiZXN0LWVmZm9ydCB0cmFmZmljIGNvdWxkIHV0aWxpemUgdW51c2VkIGF2YWls YWJsZSB2aWRlbyBiYW5kd2lkdGgNCiAgICBhbmQgZ2V0IHRocm90dGxlZCBkb3duIHdoZW4gbXVs dGljYXN0IG5lZWRzIHRoZSBiYW5kd2lkdGggKG9mY291cnNlIHRoaXMgaXMNCiAgICBkZXBlbmRl bnQgb24gaG93IG9wZXJhdG9yIHdhbnRzIHRvIG1hbmFnZSBzdWJzY3JpYmVyJ3MgYmFuZHdkaXRo KS4gRm9yIHRoaXMNCiAgICBpbnRlcmFjdGlvbiBlaXRoZXIgYSBuZXcgJnF1b3Q7YmFuZHdpZHRo IHJlcG9yaXRuZyZxdW90OyBtZXNzYWdlIG9yIGENCiAgICBzdWItdHlwZSBvZiBhbiBleGlzdGlu ZyBtZXNzYWdlIGNhbiBiZSB1c2VkLjxicj4NCiAgICA8YnI+DQogICAgLVNhbmpheTxicj4NCiAg ICA8YnI+DQogICAgcHMuIFRoZSBtb2RlbCB3aGVyZSB1bmlmaWVkIEFDIGhhcHBlbnMgb24gTkFT IGhhcyBpdHMgb3duIGJlbmVmaXRzIChlLmcuDQogICAgc2ltcGxpY2l0eSksIHNvIG5vdCBuZWNl c3NhcmlseSBhZHZvY2F0aW5nIHRoZSBhYm92ZSBtb2RlbCB3aXRoIEFOIGJhc2VkDQogICAgQUMs IGJ1dCB3ZSBuZWVkIHRvIGFjY29tbW9kYXRlIGJvdGguPGJyPg0KICAgIDxicj4NCiAgICA8YnI+ DQogICAgLS0tIE9uIDxiPlRodSwgNC8xLzEwLCBGcmFuY29pcyBMZSBGYXVjaGV1ciA8aT4mbHQ7 ZmxlZmF1Y2hAY2lzY28uY29tJmd0OzwvaT48L2I+DQogICAgd3JvdGU6PG86cD48L286cD48L3A+ DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KICAgIEZyb206IEZyYW5jb2lzIExlIEZhdWNoZXVy ICZsdDtmbGVmYXVjaEBjaXNjby5jb20mZ3Q7PGJyPg0KICAgIFN1YmplY3Q6IFJlOjxicj4NCiAg ICBUbzogJnF1b3Q7U2FuamF5IFdhZGh3YSZxdW90OyAmbHQ7c3dhZGh3YTAxQHlhaG9vLmNvbSZn dDs8YnI+DQogICAgQ2M6ICZxdW90O0ZyYW5jb2lzIExlIEZhdWNoZXVyJnF1b3Q7ICZsdDtmbGVm YXVjaEBjaXNjby5jb20mZ3Q7LA0KICAgIEtyaXN0aWFuLlBvc2NpY0BhbGNhdGVsLWx1Y2VudC5j b20sIGFuY3BAaWV0Zi5vcmc8YnI+DQogICAgRGF0ZTogVGh1cnNkYXksIEFwcmlsIDEsIDIwMTAs IDEwOjAyIEFNPG86cD48L286cD48L3A+DQogICAgPGRpdj4NCiAgICA8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz5I aQ0KICAgIFNhbmpheSw8YnI+DQogICAgPGJyPg0KICAgIE9uIDMxIE1hciAyMDEwLCBhdCAwNDo0 MCwgU2FuamF5IFdhZGh3YSB3cm90ZTo8YnI+DQogICAgJmd0OyA8YnI+DQogICAgJmd0OyBbU1dd IFRoZSBzY2VuYXJpbyBhYm92ZSwgd2hlcmUgTkFTIHNlbmRzIHRoZSBjaGFubmVsIG9uIE1DLVZM QU4sDQogICAgYXNzdW1lcyBOQVMgaXMgZG9pbmcgYmFuZHdpZHRoIGJhc2VkIEFDLiBBIGNoYW5u ZWwgam9pbiBvbiBBTiBtYXkgdHJpZ2dlcg0KICAgIGFuIEFDIHJlcXVlc3QgbWVzc2FnZSB0byBO QVMsIHdoaWNoIHNob3VsZCB0cmlnZ2VyIGEgQ0FDIGRlY2lzaW9uIGFuZA0KICAgIFFPUy1hZGp1 c3Qgb24gTkFTIGFuZCBhIHJlc3BvbnNlIGJhY2sgdG8gQU4gKGJlZm9yZSBBTiBjYW4gcGVyZm9y bQ0KICAgIHJlcGxpY2F0aW9uKS4gRG8gd2UgbmVlZCBhbm90aGVyIGJhbmR3aWR0aCB1cGRhdGUg bWVzc2FnZSBmcm9tIEFOIHRvIE5BUz8NCiAgICBJbiBjYXNlIEFOIHNlZXMgYSBjaGFubmVsIGxl YXZlIChhbmQgbm8gbmV3IGpvaW4gZm9yIHNvbWUgdGltZSkgb3IgYSB1c2VyDQogICAgc3dpdGNo ZXMgZnJvbSBIRCB0byBTRCwgdGhlbiBBTiBtYXkgZGVjaWRlIHRvIG5vdGlmeSBOQVMgb2YgcmVs ZWFzZWQNCiAgICBiYW5kd2lkdGguIEkgYmVsaWV2ZSB3ZSBhcmUgYWdhaW4gY292ZXJlZCBieSBl eGlzdGluZyBBQyByZXF1ZXN0IG1lc3NhZ2UNCiAgICBmcm9tIEFOIHRvIE5BUyAoZGVzY3JpYmVk IGluIG11bHRpY2FzdCBleHRlbnNpb25zIGRyYWZ0KS48YnI+DQogICAgPGJyPg0KICAgIElmIGFk bWlzc2lvbiBjb250cm9sIGlzIHRvIGJlIHBlcmZvcm1lZCBieSBOQVMgKGllIEdyZXkgbGlzdCBt dWx0aWNhc3QNCiAgICBmbG93KSwgdGhlbiBJIGFncmVlIHdlIGFyZSBhbHJlYWR5IGNvdmVyZWQg YnkgZXhpc3RpbmcgbXVsdGljYXN0IHByb2NlZHVyZXMNCiAgICBiZWNhdXNlIHRoZSBOQVMgaXMg YWx3YXlzIGZ1bGx5IGF3YXJlIG9mIGN1cnJlbnRseSBhZG1pdHRlZCBtdWx0aWNhc3QNCiAgICB0 cmFmZmljIG9uIGEgZ2l2ZW4gcG9ydC48YnI+DQogICAgPGJyPg0KICAgICZndDsgPGJyPg0KICAg ICZndDsmbmJzcDsgT24gdGhlIG90aGVyIGhhbmQgaWYgd2UgYXJlIGFzc3VtaW5nIGJhbmR3aWR0 aCBkZWxlZ2F0aW9uIG1vZGVsDQogICAgYW5kIGF1dG9ub21vdXMgQUMgb24gQU4sPGJyPg0KICAg IDxicj4NCiAgICBUaGF0IGlzIGluZGVlZCB0aGUgY2FzZSBvZiBpbnRlcmVzdCwgaGVyZS48YnI+ DQogICAgPGJyPg0KICAgICZndDsgdGhlbiB3ZSBhcmUgYWxyZWFkeSBjb3ZlcmVkIHZpYSBpbnRl cmFjdGlvbiByZWxhdGVkIHRvIGJhbmR3aWR0aA0KICAgIGRlbGVnYXRpb24gYmV0d2VlbiBBTiBh bmQgTkFTLjxicj4NCiAgICA8YnI+DQogICAgVGhhdCB3YXMgbXkgaW5pdGlhbCByZWFjdGlvbiB0 b28uIEluZGVlZCwgSSB0aGluayBpdCBpcyBwb3NzaWJsZSB0byBzdHJldGNoDQogICAgZXhpc3Rp bmcgYmFuZHdpZHRoIGRlbGVnYXRpb24gcHJvY2VkdXJlcyB0byBhY2hpZXZlIHRoaXMuIEhvd2V2 ZXIgdGhpcw0KICAgIHdvdWxkIHJlc3VsdCBpbiBzdWItb3B0aW1hbCBoYW5kbGluZyBvZiB0aGUg bmV3IHVzZSBjYXNlLjxicj4NCiAgICA8YnI+DQogICAgRXhhbXBsZSBjYWxsLUZsb3cgYmFzZWQg b24gcmUtdXNpbmcgZXhpc3RpbmcgYmFuZHdpZHRoIGRlbGVnYXRpb24NCiAgICBwcm9jZWR1cmVz Ojxicj4NCiAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxicj4NCiAgICBBTiAmbHQ7LS0tUE9SVF9NTkdUIChCdyBhbGxvY2F0aW9u PTBNYi9zKSAtLU5BUzxicj4NCiAgICAuLi48YnI+DQogICAgKGpvaW4gZnJvbSBzdWJzY3JpYmVy IGZvciAyTWIvcyBtdWx0aWNhc3QgZmxvdyk8YnI+DQogICAgQU4gLS0tQmFuZHdpZHRoIFJlYWxs b2MgUmVxdWVzdCAoMk1iL3MpLS0mZ3Q7IE5BUzxicj4NCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiAgICAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyhOQVMgYWxsb2NhdGVzIDJNYi9zKTxicj4NCiAgICBBTiAmbHQ7LS0tLS0tLS1C YW5kd2lkdGggVHJhbnNmZXIgKDJNYi9zKS0tLS0tLS0tIE5BUzxicj4NCiAgICAoQU4gc3RhcnRz IHJlcGxpY2F0aW5nKTxicj4NCiAgICAuLi48YnI+DQogICAgKGxlYXZlICsgam9pbiBmcm9tIHN1 YnNjcmliZXIgZm9yIDRNYi9zIG11bHRpY2FzdCBmbG93KTxicj4NCiAgICBBTiAtLS1CYW5kd2lk dGggUmVhbGxvYyBSZXF1ZXN0ICg0TWIvcyktLSZndDsgTkFTPGJyPg0KICAgICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KICAgICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7KE5BUyBhbGxvY2F0ZXMgNE1iL3MgdG90YWwpPGJyPg0KICAgIEFO ICZsdDstLS0tLS0tLUJhbmR3aWR0aCBUcmFuc2ZlciAoNE1iL3MpLS0tLS0tLS0gTkFTPGJyPg0K ICAgIChBTiBzdGFydHMgcmVwbGljYXRpbmcpPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAg RXhhbXBsZSBjYWxsLUZsb3cgYmFzZWQgb24gbmV3ICZxdW90O2FkbWl0dGVkIGJhbmR3aWR0aCBy ZXBvcnRpbmcmcXVvdDsNCiAgICBwcm9jZWR1cmVzOjxicj4NCiAgICA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogICAgQU4gJmx0 Oy0tLVBPUlRfTU5HVCAoQncgYWxsb2NhdGlvbj00TWIvcykgLS1OQVM8YnI+DQogICAgLi4uPGJy Pg0KICAgIChqb2luIGZyb20gc3Vic2NyaWJlciBmb3IgMk1iL3MgbXVsdGljYXN0IGZsb3cpPGJy Pg0KICAgIChBTiBkb2VzIGFkbWlzc2lvbiBjb250cm9sIGFuZCBzdGFydHMgcmVwbGljYXRpbmcp PGJyPg0KICAgIEFOIC0tLS0tLUFkbWl0dGVkIEJhbmR3aWR0aCBSZXBvcnQoMk1iL3MpLS0tJmd0 OyBOQVM8YnI+DQogICAgKGxlYXZlICsgam9pbiBmcm9tIHN1YnNjcmliZXIgZm9yIDRNYi9zIG11 bHRpY2FzdCBmbG93KTxicj4NCiAgICAoQU4gZG9lcyBhZG1pc3Npb24gY29udHJvbCBhbmQgc3Rh cnRzIHJlcGxpY2F0aW5nKTxicj4NCiAgICBBTiAtLS0tLS1BZG1pdHRlZCBCYW5kd2lkdGggUmVw b3J0KDRNYi9zKS0tLS0mZ3Q7IE5BUzxicj4NCiAgICA8YnI+DQogICAgPGJyPg0KICAgIFNvLCB0 aGUgc3ViLW9wdGltYWxpdGllcyBvZiByZXVzaW5nIGV4aXN0aW5nIGJhbmR3aWR0aCBkZWxlZ2F0 aW9uDQogICAgcHJvY2VkdXJlcyBpbmNsdWRlOjxicj4NCiAgICAmbmJzcDsmbmJzcDsmbmJzcDsg KmEqIHVzZSBvZiB0d28gbWVzc2FnZXMgaW5zdGVhZCBvZiBvbmUsIGZvciBldmVyeQ0KICAgIGJh bmR3aWR0aCBjaGFuZ2U8YnI+DQogICAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICpiKiBleHRyYSBkZWxh eSBvbiBBTiAoaWUgbmVlZCB0byB3YWl0IGZvciBBTkNQDQogICAgcm91bmQtdHJpcCBpbnN0ZWFk IG9mIGltbWVkaWF0ZWx5IHJlcGxpY2F0ZSk8YnI+DQogICAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICpj KiB1bm5lY2Vzc2FyeSAmcXVvdDtiYW5kd2lkdGggY2hlY2smcXVvdDsgZm9yDQogICAgJnF1b3Q7 cmVhbGxvY2F0aW9uJnF1b3Q7IG9uIE5BUzxicj4NCiAgICA8YnI+DQogICAgSSdkIHNheSB0aGVz ZSBzdWItb3B0aW1hbGl0aWVzIGp1c3RpZnkgYSBuZXcgcHJvY2VkdXJlcywgYnV0IEknbSB3aWxs aW5nIHRvDQogICAgYmUgY29udmluY2VkIG90aGVyd2lzZS48YnI+DQogICAgSSBzdXBwb3NlIG9u ZSBjb3VsZCBhcmd1ZSB0aGF0IGluIHRoZSBtYWpvcml0eSBvZiBqb2luL2xlYXZlL2pvaW4sIHRo ZQ0KICAgIGJhbmR3aWR0aCBkb2VzIG5vdCBjaGFuZ2UgKGllIHphcHBpbmcgYW1vbmcgY2hhbm5l bHMgb2Ygc2FtZSBiYW5kd2lkdGgpLCBzbw0KICAgIHRoZSBzdWItb3B0aW1hbGl0eSAqYSogaXMg b25seSBpbmN1cnJlZCBpbiBsZXNzIGNvbW1vbiBjYXNlIChsZWF2ZVNELA0KICAgIGpvaW5IRCku PGJyPg0KICAgIDxicj4NCiAgICBUaG91Z2h0cyBldmVyeW9uZT88YnI+DQogICAgPGJyPg0KICAg IEZyYW5jb2lzPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgPG86cD48L286cD48L3A+DQog ICAgPC9kaXY+DQogICAgPGRpdj4NCiAgICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+DQogICAgPGJyPg0K ICAgIEZyYW5jb2lzIExlIEZhdWNoZXVyPGJyPg0KICAgIERpc3Rpbmd1aXNoZWQgRW5naW5lZXI8 YnI+DQogICAgQ29ycG9yYXRlIERldmVsb3BtZW50PGJyPg0KICAgIGZsZWZhdWNoQGNpc2NvLmNv bTxicj4NCiAgICBQaG9uZTogKzMzIDQ5IDcyMyAyNjE5PGJyPg0KICAgIE1vYmlsZTogKzMzIDYg MTkgOTggNTAgOTA8YnI+DQogICAgPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgQ2lzY28g U3lzdGVtcyBGcmFuY2U8YnI+DQogICAgR3JlZW5zaWRlPGJyPg0KICAgIDQwMCBBdmUgZGUgUm91 bWFuaWxsZTxicj4NCiAgICAwNjQxMCBTb3BoaWEgQW50aXBvbGlzPGJyPg0KICAgIEZyYW5jZTxi cj4NCiAgICBDaXNjby5jb208YnI+DQogICAgPGJyPg0KICAgIDxvOnA+PC9vOnA+PC9wPg0KICAg IDwvZGl2Pg0KICAgIDxkaXY+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KICAgIFRoaW5rIGJl Zm9yZSB5b3UgcHJpbnQuPGJyPg0KICAgIDxicj4NCiAgICBUaGlzIGVtYWlsIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUNCiAgICB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRp b24gb3IgZGlzY2xvc3VyZQ0KICAgIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvcg0KICAgIGF1dGhvcml6ZWQg dG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIg YnkNCiAgICByZXBseSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdl Ljxicj4NCiAgICA8YnI+DQogICAgQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCBy ZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUNCiAgICBEZXNtb3VsaW5zIOKAkyBJ bW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5IGxlcyBNb3VsaW5l YXV4LA0KICAgIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRl cnJlLCBEaXJlY3RldXIgZGUgbGENCiAgICBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdp dm9uZS48YnI+DQogICAgPGJyPg0KICAgIEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24g Z28gdG86PGJyPg0KICAgIDxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9k b2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCINCiAgICB0YXJnZXQ9Il9ibGFuayI+ PHU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91 dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbDwvc3Bhbj48L3U+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogICA8L3RyPg0KICA8L3RhYmxlPg0K ICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICA8L2Rpdj4NCiAgPC9kaXY+DQogIDwvdGQ+DQogPC90cj4NCjwvdGFibGU+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CAD47A.C4E31939-- From fqhuang@huawei.com Tue Apr 6 00:38:25 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAC53A67D9 for ; Tue, 6 Apr 2010 00:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdnqlZOJmbj4 for ; Tue, 6 Apr 2010 00:38:24 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 633243A67A2 for ; Tue, 6 Apr 2010 00:38:24 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0G001DA2JWBR@szxga03-in.huawei.com> for ancp@ietf.org; Tue, 06 Apr 2010 15:38:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0G00FR92JVQ1@szxga03-in.huawei.com> for ancp@ietf.org; Tue, 06 Apr 2010 15:38:20 +0800 (CST) Received: from h36145c ([10.70.39.65]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0G006WN2JV5K@szxml04-in.huawei.com> for ancp@ietf.org; Tue, 06 Apr 2010 15:38:19 +0800 (CST) Date: Tue, 06 Apr 2010 15:38:19 +0800 From: Fortune HUANG In-reply-to: <41B3B178A129B6458752EC1B4D14998C03BC222F@USDALSMBS04.ad3.ad.alcatel.com> To: 'POSCIC Kristian' , 'Francois Le Faucheur' , ancp@ietf.org Message-id: <004901cad55c$20cd3f70$4127460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrQGh1M38gsCNu3REC569zE6sIvqAAQAMjQAT5aYTA= Subject: Re: [ANCP] "Admitted Bandwidth Reporting" multicast use case X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:38:25 -0000 Hi Kris, Hi Francois, I think this use case makes sense and I support working on it in the mc extension draft. " * the AN is allowed to make some judgment calls about when to report a changed admitted bandwidth. For example, when the AN receives the leave, the AN may want to wait a little before reporting the changed admitted bandwidth in case a join comes in (say because user is simply changing channel)." --[Fortune: Maybe there should be some configuratble policy about when to report the b/w, e.g. report immediately after the AC action, report after a configurable time after the AC action, or report periodically, etc.] "[Kris] Do we report the diff in b/w usage or the total b/w used value per access port? I think that the 'total usage' should be certainly a priority. Possibly you can include a flag that would indicate that a diff in b/w usage is reported. " -- [Fortune: I think we should report the 'total usage' in order to avoid confusions when resending the report. In case the 'total usage' is reported, the 'diff in b/w usage' would not be needed.] Best regards, Fortune -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of POSCIC Kristian Sent: Wednesday, March 31, 2010 7:46 AM To: Francois Le Faucheur; ancp@ietf.org Subject: Re: [ANCP] "Admitted Bandwidth Reporting" multicast use case Thanks Francois. This sums it up well. Some additional comments inline. -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Francois Le Faucheur Sent: Tuesday, March 30, 2010 8:03 AM To: ancp@ietf.org Subject: [ANCP] "Admitted Bandwidth Reporting" multicast use case Folks, Following up on this item. For memory, the draft minutes say: > Kris Poscic: Question regarding whether a use case of interest can be supported with defined mechanisms > use case is where AN does AC and does IGMP suppression. All I want to do is report bandwidth usage to NAS (eg so NAS adjusts Qos). I saw bandwidth allocation and query. but not quite the same thing. Can this use case be supported? > Francois: can possibly be emulated with Bandwidth Delegation capability > Chris: possibly but that would not be optimal > Francois: I can agree probably agree with that. Let's have a discussion off-line. We had a chat after the meeting and I also discussed this with Tom and then with Woj. There seems to be agreement that this is a valid use case worth addressing. We discussed an approach along the lines of: * define a new capability for "admitted bandwidth reporting" (actual name is TBD) * if the capability is negotiated, the AN MUST report to the NAS the new value of the bandwidth currently allocated/admitted by the AN on a given port whenever that value changes (eg the AN just admitted another multicast channel in the White List, or the user just jumped from and SD channel to a HD channel,..). * the AN is allowed to make some judgment calls about when to report a changed admitted bandwidth. For example, when the AN receives the leave, the AN may want to wait a little before reporting the changed admitted bandwidth in case a join comes in (say because user is simply changing channel). * on receipt of a new admitted bandwidth value, the NAS MAY adjust its QoS mechanisms accordingly (note that, when doing so, the NAS needs to take into account the rest of the video traffic that is not admitted by the AN such as unicast VoD traffic or NAS Initiated Multicast traffic. [Kris] Little more details for a possible use case: This feature will be primarily used when the multicast is sent from the NAS towards the AN over a common multicast VLAN. Since the subscriber QoS context in the NAS actually does not see this mcast traffic, (mcast traffic is sent over a separate common VLAN), QoS b/w adjustment needs to be made for the subscriber. Most likely, every other traffic that is flowing directly over subscribers queues in the NAS will be automatically included in the subscriber QoS. This would include any unicast video streams that are directly flowing over the subscriber queues. * the call flow to report a new admitted bandwidth value will only involve a message in the direction AN-->NAS. No response is needed from NAS (except in case of errored message as per usual ANCP procedures). * we'll look into whether the AN-->NAS message used for admitted bandwidth reporting should be a new message type or piggy-backed using an existing message (eg PortUp, Generic Response,..) [Kris] Do we report the diff in b/w usage or the total b/w used value per access port? I think that the 'total usage' should be certainly a priority. Possibly you can include a flag that would indicate that a diff in b/w usage is reported. * one question that needs more thoughts is combination of this new capability with various other multicast capabilities (eg what should be done when we have both this new capability and Grey List, since the NAS is already aware of all admitted multicast grey groups). I don't think any of that should be a show stopper, but it has to be carefully walked through. [Kris] This is my (maybe skewed :)) view on this: QoS B/W adjustment in the NAS can be done based on IGMPs received from the AN or based on this new model (proposed here) via ANCP. The latter would be normally the case in the absence of IGMP messages reaching the NAS (there are valid reasons to do this). Which option to chose is up to the operator and it is controlled in the NAS. The AN asking for the NAS for the resource admission via the grey lists should be orthogonal to b/w adjustment. Thanks again Francois. High level feedback is welcome on this before we start working out details. Oh, last thing, does anyone know whether this use case is already discussed in the Framework document? Thanks Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From flefauch@cisco.com Tue Apr 6 01:39:30 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307473A683C for ; Tue, 6 Apr 2010 01:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 CmeLTxD0-8A4 for ; Tue, 6 Apr 2010 01:39:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3BA573A6835 for ; Tue, 6 Apr 2010 01:39:26 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-AV: E=Sophos;i="4.51,371,1267401600"; d="gif'147?scan'147,208,217,147";a="5219182" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2010 08:04:09 +0000 Received: from ams-flefauch-8717.cisco.com (ams-flefauch-8717.cisco.com [10.55.161.200]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o368dL2u023590; Tue, 6 Apr 2010 08:39:22 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-36-178199344 From: Francois Le Faucheur In-Reply-To: <41B3B178A129B6458752EC1B4D14998C03BC25A4@USDALSMBS04.ad3.ad.alcatel.com> Date: Tue, 6 Apr 2010 10:39:35 +0200 Message-Id: <87BC6505-4E88-45B6-9279-9DBF9BF02B43@cisco.com> References: <41B3B178A129B6458752EC1B4D14998C03BC259E@USDALSMBS04.ad3.ad.alcatel.com> <913921.93355.qm@web113806.mail.gq1.yahoo.com> <41B3B178A129B6458752EC1B4D14998C03BC25A4@USDALSMBS04.ad3.ad.alcatel.com> To: POSCIC Kristian X-Mailer: Apple Mail (2.1078) Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:39:30 -0000 --Apple-Mail-36-178199344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > =20 > [SW] In #4 below I am only talking about multicast and not VOD (please = note the channel change scenario mentioned in there). AN may want to = optionally notify NAS of multicast, such that NAS can adjust unicast b/w = lower due to multicast being sent on MVLAN (as multicast bypasses normal = QOS hierarchy for the subscriber). The point I tried making is that AN = will need to hold off on replication till it gets an ACK back from NAS = when notifying it of QOS-adjust. Original response from Francois seemed = to imply no round-trip was needed before AN starts replication (which I = don't believe is the case). >=20 > [Kris]Ok, I think this is where the disconnect is. This new message = that is being proposed to update the b/w usage (not the allocation) is = sent from the AN to the NAS. This will be done only if there is a = difference in channel b/w usage. Based on this message, the NAS will = adjust its b/w for unicast. For example, a new join comes for a 5mbps = channel. If this channel is admitted by the AN, the AN will send a new = b/w usage report (total new sub usage =3D old + 5mbps). The NAS will now = know that the subscriber is getting more video b/w (mcast channel = bypassing subscriber=92s QoS hierarchy). So the NS will lower its = aggregate rate for the subscriber for the -5Mbps. Within this new = aggregate (minus 5mbps) , video still has a higher priority than HSI so = the only affected traffic will be HSI. For this I also (as Francois) do = not believe that any feedback is necessary back from the NAS. >=20 [FLF] Let's drill down on that one. In the case where the AN starts replication without waiting for any = "QoS-Adjust-response" from the NAS, there is a small window of time = (from time where replication starts on An to time when QoS-adjust is = effected on NAS following the "bandwidth-update") during which there may = be an excessive amount of traffic sent towards a given customer port (ie = high "new" multicast load + high "old" unicast load). However, I have = been assuming this is not an issue because: (i) the AN can still prioritize video (unicast & multicast) = over HSI, and (ii) it is only transient. This is why I feel OK with the "no round-trip" approach. Is it safe to assume the AN can always prioritize video over HSI during = the transient "congestion" period? Francois Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-36-178199344 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-37-178199344 --Apple-Mail-37-178199344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
 

[SW] In #4 below I am only = talking about multicast and not VOD (please note the channel change = scenario mentioned in there). AN may want to optionally notify NAS of = multicast, such that NAS can adjust unicast b/w lower due to multicast = being sent on MVLAN (as multicast bypasses normal QOS hierarchy for the = subscriber). The point I tried making is that AN will need to hold off = on replication till it gets an ACK back from NAS when notifying it of = QOS-adjust. Original response from Francois seemed to imply no = round-trip was needed before AN starts replication (which I don't = believe is the case).

[Kris]Ok,  I think this is = where the disconnect is. This new message that is being proposed to = update the b/w usage (not the allocation) is sent from the AN to the = NAS. This will be done only if there is a difference in channel b/w = usage. Based on this message, the NAS will adjust its b/w for unicast. = For example, a new join comes for a  5mbps channel. If this channel = is admitted by the AN, the AN will send a new b/w usage report (total = new sub usage =3D old + 5mbps). The NAS will now know that the = subscriber is getting more video b/w (mcast channel bypassing = subscriber=92s QoS hierarchy). So the NS will lower its aggregate rate = for the subscriber for the -5Mbps. Within this new aggregate (minus = 5mbps) , video still has a higher priority than HSI so the only affected = traffic will be HSI.  For this I also (as Francois) do not believe = that any feedback is necessary back from the NAS.

 (i) the AN can still = prioritize video (unicast & multicast) over HSI, and
(ii) it = is only transient.
This is why I feel OK with the "no = round-trip" approach.
Is it safe to assume the AN can always = prioritize video over HSI during the transient "congestion" = period?

Francois





Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 
 Think before you = print.
R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 --Apple-Mail-37-178199344 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-37-178199344-- --Apple-Mail-36-178199344-- From flefauch@cisco.com Tue Apr 6 01:43:39 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7243A6839 for ; Tue, 6 Apr 2010 01:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.878 X-Spam-Level: X-Spam-Status: No, score=-3.878 tagged_above=-999 required=5 tests=[AWL=5.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 7j-3K9baKOoh for ; Tue, 6 Apr 2010 01:43:37 -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 3688C3A683E for ; Tue, 6 Apr 2010 01:43:36 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-AV: E=Sophos;i="4.51,371,1267401600"; d="gif'147?scan'147,208,217,147";a="59013934" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2010 08:43:33 +0000 Received: from ams-flefauch-8717.cisco.com (ams-flefauch-8717.cisco.com [10.55.161.200]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o368hVKI024790; Tue, 6 Apr 2010 08:43:31 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-42-178449091 From: Francois Le Faucheur In-Reply-To: <004901cad55c$20cd3f70$4127460a@china.huawei.com> Date: Tue, 6 Apr 2010 10:43:45 +0200 Message-Id: <86C082F6-3C46-4DC6-A139-6DFD982C4781@cisco.com> References: <004901cad55c$20cd3f70$4127460a@china.huawei.com> To: Fortune HUANG X-Mailer: Apple Mail (2.1078) Cc: 'POSCIC Kristian' , ancp@ietf.org Subject: Re: [ANCP] "Admitted Bandwidth Reporting" multicast use case X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:43:39 -0000 --Apple-Mail-42-178449091 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 6 Apr 2010, at 09:38, Fortune HUANG wrote: > Hi Kris,=20 > Hi Francois, >=20 > I think this use case makes sense and I support working on it in the = mc > extension draft. good. >=20 > " * the AN is allowed to make some judgment calls about when to = report > a changed admitted bandwidth. For example, when the AN receives the = leave, > the AN may want to wait a little before reporting the changed admitted > bandwidth in case a join comes in (say because user is simply changing > channel)." =20 > --[Fortune: Maybe there should be some configuratble policy about when = to > report the b/w, e.g. report immediately after the AC action, report = after a > configurable time after the AC action, or report periodically, etc.] While we can give some example of reasonable things to do (such as what = you mention above), the details can probably be left to implementers = since that does not affect interoperability. Do you agree? =20 >=20 > "[Kris] Do we report the diff in b/w usage or the total b/w used value = per > access port? I think that the 'total usage' should be certainly a = priority. > Possibly you can include a flag that would indicate that a diff in b/w = usage > is reported. "=20 > -- [Fortune: I think we should report the 'total usage' in order to = avoid > confusions when resending the report. > In case the 'total usage' is reported, the 'diff in b/w usage' would = not > be needed.] I agree. Francois >=20 >=20 > Best regards, > Fortune >=20 >=20 > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of > POSCIC Kristian > Sent: Wednesday, March 31, 2010 7:46 AM > To: Francois Le Faucheur; ancp@ietf.org > Subject: Re: [ANCP] "Admitted Bandwidth Reporting" multicast use case >=20 > Thanks Francois.=20 > This sums it up well.=20 > Some additional comments inline. >=20 > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of > Francois Le Faucheur > Sent: Tuesday, March 30, 2010 8:03 AM > To: ancp@ietf.org > Subject: [ANCP] "Admitted Bandwidth Reporting" multicast use case >=20 > Folks, >=20 > Following up on this item. >=20 > For memory, the draft minutes say: >=20 >> Kris Poscic: Question regarding whether a use case of interest can be > supported with defined mechanisms >> use case is where AN does AC and does IGMP suppression. All I want to > do is report bandwidth usage to NAS (eg so NAS adjusts Qos). I saw = bandwidth > allocation and query. but not quite the same thing. Can this use case = be > supported? >> Francois: can possibly be emulated with Bandwidth Delegation > capability >> Chris: possibly but that would not be optimal >> Francois: I can agree probably agree with that. Let's have a > discussion off-line. >=20 > We had a chat after the meeting and I also discussed this with Tom and = then > with Woj. There seems to be agreement that this is a valid use case = worth > addressing. We discussed an approach along the lines of: > * define a new capability for "admitted bandwidth reporting" > (actual name is TBD) > * if the capability is negotiated, the AN MUST report to the NAS = the > new value of the bandwidth currently allocated/admitted by the AN on a = given > port whenever that value changes (eg the AN just admitted another = multicast > channel in the White List, or the user just jumped from and SD channel = to a > HD channel,..). > * the AN is allowed to make some judgment calls about when to = report > a changed admitted bandwidth. For example, when the AN receives the = leave, > the AN may want to wait a little before reporting the changed admitted > bandwidth in case a join comes in (say because user is simply changing > channel). > * on receipt of a new admitted bandwidth value, the NAS MAY = adjust > its QoS mechanisms accordingly (note that, when doing so, the NAS = needs to > take into account the rest of the video traffic that is not admitted = by the > AN such as unicast VoD traffic or NAS Initiated Multicast traffic. >=20 > [Kris] Little more details for a possible use case: This feature will = be > primarily used when the multicast is sent from the NAS towards the AN = over a > common multicast VLAN. Since the subscriber QoS context in the NAS = actually > does not see this mcast traffic, (mcast traffic is sent over a = separate > common VLAN), QoS b/w adjustment needs to be made for the subscriber. = Most > likely, every other traffic that is flowing directly over subscribers = queues > in the NAS will be automatically included in the subscriber QoS. This = would > include any unicast video streams that are directly flowing over the > subscriber queues. >=20 > * the call flow to report a new admitted bandwidth value will = only > involve a message in the direction AN-->NAS. No response is needed = from NAS > (except in case of errored message as per usual ANCP procedures). > * we'll look into whether the AN-->NAS message used for admitted > bandwidth reporting should be a new message type or piggy-backed using = an > existing message (eg PortUp, Generic Response,..) >=20 >=20 > [Kris] > Do we report the diff in b/w usage or the total b/w used value per = access > port? I think that the 'total usage' should be certainly a priority. > Possibly you can include a flag that would indicate that a diff in b/w = usage > is reported.=20 >=20 > * one question that needs more thoughts is combination of this = new > capability with various other multicast capabilities (eg what should = be done > when we have both this new capability and Grey List, since the NAS is > already aware of all admitted multicast grey groups). I don't think = any of > that should be a show stopper, but it has to be carefully walked = through. >=20 >=20 > [Kris] This is my (maybe skewed :)) view on this: QoS B/W adjustment = in the > NAS can be done based on IGMPs received from the AN or based on this = new > model (proposed here) via ANCP. The latter would be normally the case = in the > absence of IGMP messages reaching the NAS (there are valid reasons to = do > this). Which option to chose is up to the operator and it is = controlled in > the NAS.=20 > The AN asking for the NAS for the resource admission via the grey = lists > should be orthogonal to b/w adjustment.=20 > Thanks again Francois. =20 >=20 > High level feedback is welcome on this before we start working out = details. >=20 > Oh, last thing, does anyone know whether this use case is already = discussed > in the Framework document? >=20 > Thanks >=20 > Francois >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-42-178449091 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-43-178449092 --Apple-Mail-43-178449092 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Kris,
Hi Francois,

I think this use case makes sense and I = support working on it in the mc
extension = draft.

good.


" * the AN is allowed to make some = judgment calls about when to report
a changed admitted bandwidth. For = example, when the AN receives the leave,
the AN may want to wait a = little before reporting the changed admitted
bandwidth in case a join = comes in (say because user is simply changing
channel)." =  
--[Fortune: Maybe there should be some configuratble policy = about when to
report the b/w, e.g. report immediately after the AC = action, report after a
configurable time after the AC action, or = report periodically, = etc.]

While we can give some = example of reasonable things to do (such as what you mention above), the = details can probably be left to implementers since that does not affect = interoperability. Do you agree?
 


"[Kris] Do we report the diff in b/w usage or the = total b/w used value per
access port? I think that the 'total usage' = should be certainly a priority.
Possibly you can include a flag that = would indicate that a diff in b/w usage
is reported. "
-- = [Fortune: I think we should report the 'total usage' in order to = avoid
confusions when resending the report.
In case the =  'total usage'  is reported, the 'diff in b/w usage' would = not
be needed.]

I = agree.

Francois



Best = regards,
Fortune


-----Original Message-----
From: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] On Behalf Of
POSCIC Kristian
Sent: = Wednesday, March 31, 2010 7:46 AM
To: Francois Le Faucheur; ancp@ietf.org
Subject: Re: [ANCP] = "Admitted Bandwidth Reporting" multicast use case

Thanks = Francois.
This sums it up well.
Some additional comments = inline.

-----Original Message-----
From: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] On Behalf Of
Francois Le = Faucheur
Sent: Tuesday, March 30, 2010 8:03 AM
To: ancp@ietf.org
Subject: [ANCP] = "Admitted Bandwidth Reporting" multicast use = case

Folks,

Following up on this item.

For memory, = the draft minutes say:

Kris Poscic: = Question regarding whether a use case of interest can = be
supported with defined mechanisms
use case is where AN does AC and does IGMP suppression. = All I want to
do is report bandwidth usage to NAS (eg so = NAS adjusts Qos). I saw bandwidth
allocation and query. but not quite = the same thing. Can this use case be
supported?
Francois: can possibly be emulated with Bandwidth = Delegation
capability
Chris: = possibly but that would not be optimal
Francois: I can agree probably agree with that. Let's have = a
discussion off-line.

We had a chat after the = meeting and I also discussed this with Tom and then
with Woj. There = seems to be agreement that this is a valid use case worth
addressing. = We discussed an approach along the lines of:
* define = a new capability for "admitted bandwidth reporting"
(actual name is = TBD)
= * if the capability is negotiated, the AN MUST report to the NAS = the
new value of the bandwidth currently allocated/admitted by the AN = on a given
port whenever that value changes (eg the AN just admitted = another multicast
channel in the White List, or the user just jumped = from and SD channel to a
HD channel,..).
* the AN = is allowed to make some judgment calls about when to report
a changed = admitted bandwidth. For example, when the AN receives the leave,
the = AN may want to wait a little before reporting the changed = admitted
bandwidth in case a join comes in (say because user is = simply changing
channel).
* on receipt of a new admitted = bandwidth value, the NAS MAY adjust
its QoS mechanisms accordingly = (note that, when doing so, the NAS needs to
take into account the = rest of the video traffic that is not admitted by the
AN such as = unicast VoD traffic or NAS Initiated Multicast traffic.

[Kris] =  Little more details for a possible use case: This feature will = be
primarily used when the multicast is sent from the NAS towards the = AN over a
common multicast VLAN. Since the subscriber QoS context in = the NAS actually
does not see this mcast traffic, (mcast traffic is = sent over a separate
common VLAN), QoS b/w adjustment needs to be = made for the subscriber. Most
likely, every other traffic that is = flowing directly over subscribers queues
in the NAS will be = automatically included in the subscriber QoS. This would
include any = unicast video streams that are directly flowing over the
subscriber = queues.

= * the call flow to report a new admitted bandwidth value will = only
involve a message in the direction AN-->NAS. No response is = needed from NAS
(except in case of errored message as per usual ANCP = procedures).
= * we'll look into whether the AN-->NAS message used for = admitted
bandwidth reporting should be a new message type or = piggy-backed using an
existing message (eg PortUp, Generic = Response,..)


[Kris]
Do we report the diff in b/w usage or = the total b/w used value per access
port? I think that the 'total = usage' should be certainly a priority.
Possibly you can include a = flag that would indicate that a diff in b/w usage
is reported. =

= * one question that needs more thoughts is combination of this = new
capability with various other multicast capabilities (eg what = should be done
when we have both this new capability and Grey List, = since the NAS is
already aware of all admitted multicast grey = groups). I don't think any of
that should be a show stopper, but it = has to be carefully walked through.


[Kris] This is my (maybe = skewed :)) view on this: QoS B/W adjustment in the
NAS can be done = based on IGMPs received from the AN or based on this new
model = (proposed here) via ANCP. The latter would be normally the case in = the
absence of IGMP messages reaching the NAS (there are valid = reasons to do
this). Which option to chose is up to the operator and = it is controlled in
the NAS.
The AN asking for the NAS for the = resource admission via the grey lists
should be orthogonal to b/w = adjustment.
Thanks again Francois. =     

High level feedback is welcome on this = before we start working out details.

Oh, last thing, does anyone = know whether this use case is already discussed
in the Framework = document?

Thanks

Francois

___________________________= ____________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ancp
_______________________________________________
= ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp


Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 
 Think before you = print.
R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 --Apple-Mail-43-178449092 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-43-178449092-- --Apple-Mail-42-178449091-- From Kristian.Poscic@alcatel-lucent.com Tue Apr 6 07:02:30 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B914A3A685D for ; Tue, 6 Apr 2010 07:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 wtHddqFz294m for ; Tue, 6 Apr 2010 07:02:29 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 12B563A6808 for ; Tue, 6 Apr 2010 07:02:29 -0700 (PDT) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id o36E2Pt8003096; Tue, 6 Apr 2010 09:02:25 -0500 (CDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.pdc.alcatel-lucent.com [172.22.216.19]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o36E2OeY005896; Tue, 6 Apr 2010 09:02:24 -0500 (CDT) Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 09:02:24 -0500 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.11]) by USDALSMBS03.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 09:02:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAD591.B9AA13E9" Date: Tue, 6 Apr 2010 09:01:54 -0500 Message-ID: <41B3B178A129B6458752EC1B4D14998C03C3BEA8@USDALSMBS04.ad3.ad.alcatel.com> In-Reply-To: <87BC6505-4E88-45B6-9279-9DBF9BF02B43@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: RE: Thread-Index: AcrVZKpn19jJLWWSTCiLRIRcVpkSHAAKHTXg References: <41B3B178A129B6458752EC1B4D14998C03BC259E@USDALSMBS04.ad3.ad.alcatel.com> <913921.93355.qm@web113806.mail.gq1.yahoo.com> <41B3B178A129B6458752EC1B4D14998C03BC25A4@USDALSMBS04.ad3.ad.alcatel.com> <87BC6505-4E88-45B6-9279-9DBF9BF02B43@cisco.com> From: "POSCIC Kristian" To: "Francois Le Faucheur" X-OriginalArrivalTime: 06 Apr 2010 14:02:24.0414 (UTC) FILETIME=[C87DC3E0:01CAD591] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:02:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD591.B9AA13E9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD591.B9AA13E9" ------_=_NextPart_002_01CAD591.B9AA13E9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRnJhbmNvaXMg4oCTIA0KDQpJIGFncmVlIHdpdGggdGhlIGFzc2Vzc21lbnQNCg0KVGhlIHRy YW5zaWVudCB3aWxsIGFmZmVjdCBvbmx5IEhTSS4gRHVyaW5nIHRoZSB0cmFuc2llbnQsIHRoZSBO QVMgd2lsbCBrZWVwIHNlbmRpbmcgbW9yZSBIU0kgZm9yIHRoZSBzdWJzY3JpYmVyIGludG8gdGhl IGFjY2VzcyBuZXR3b3JrIGZvciB0aGUgY2FzZSB3aGVyZSB0aGlzIHdhcyBhbiBleGlzdGluZyBt dWx0aWNhc3QgY2hhbm5lbCBpbiB0aGUgTkFTLiBUaGUgQU4gIHVzdWFsbHkgaGFzIGl0cyBvd24g UW9TIHdpdGggcHJvcGVyIHByaW9yaXRpemF0aW9uIGFuZCB3aWxsIGRpc2NhcmQgdGhpcyBleGNl c3MgSFNJLCB3aGljaCBpcyBCZXN0LUVmZm9ydCBhbnl3YXkuDQoNCiANCg0KSW4gdGhlIFBPTiB3 aGVyZSB0aGUgUE9OIGlzIHNoYXJlZCBhbmQgUW9TIGltcGxlbWVudGVkIHBlciBhZ2dyZWdhdGUg bGluayAoaW5zdGVhZCBvZiBzdWJzY3JpYmVyKSwgdGhlIEhTSSB3aWxsIGJlIGFsc28gZGlzY2Fy ZGVkIGFsdGhvdWdoIGFjcm9zcyBhbGwgc3Vic2NyaWJlcnMuIFRoaXMgNW1icHMgKGZyb20gdGhl IHByZXZpb3VzIGV4YW1wbGUpIHdpbGwgYmUgY3V0IGZyb20gdGhlIEhTSSBvbiB0aGUgUE9OIHBv cnQgdW5pZm9ybWx5Lg0KDQpCdXQgYWdhaW4sIGFzc3VtaW5nIHRoYXQgdGhpcyBpcyBvbmx5IHRy YW5zaWVudCBjb25kaXRpb24sIHRyYWZmaWMgaXMgYmVzdC1lZmZvcnQgYW55d2F5LCBjb25nZXN0 aW9uIGlzIHNob3J0IGxpdmVkIChvdGhlcndpc2Ugd2UgaGF2ZSBvdGhlciBpc3N1ZXMpLCB0aGlz IHNob3VsZCBiZSBPSy4gVGhlIGJlbmVmaXQgaXMgYSBmYXN0ZXIgY2hhbm5lbCBjaGFuZ2UsIGdy ZWF0bHkgcmVkdWNlZCBtZXNzYWdpbmcgYmV0d2VlbiB0aGUgTkFTIGFuZCB0aGUgQU4uIFRoZSBk b3duc2lkZSBpcyB0aGF0IGJlc3QtZWZmb3J0IHRyYWZmaWMgaXMgY3V0IGZvciB0aGUgYW1vdW50 IG9mIGIvdyB0aGF0IG1jYXN0IGNoYW5uZWwgaXMgdGFraW5nIGR1cmluZyB0aGlzIHNob3J0IHRy YW5zaWVudCBwZXJpb2QuIEFuZCB0aGlzIHdpbGwgaGFwcGVuIG9ubHkgaWYgdGhlcmUgaXMgY29u Z2VzdGlvbiwgaWYgbm90LCB0aGluZ3MgYXJlIGZpbmUuDQoNCiANCg0KRm9yIHRoZSBjYXNlIHdo ZXJlIGNoYW5uZWwgaW4gbm90IHByZXNlbnQgYXQgdGhlIE5BUyAobmV3IGNoYW5uZWwgam9pbiks IHRoaW5ncyB3aWxsIGJlIHNpbWlsYXIuIFRoZSBOQVMgd2lsbCB0cmVhdCB0cmFmZmljIGFwcHJv cHJpYXRlbHkgdmlhIFFvUy4NCg0KIA0KDQpJdCB1cyB1cCB0byBvcGVyYXRvciB0byBkZXNpZ24g UW9TIGJlaGF2aW9yLCBidXQgSSB0aGluayBpdCBpcyBzYWZlIHRvIGFzc3VtZSB0aGF0IHZpZGVv IChtY2FzdCArIFZPRCkgY2FuIGJlIGFsd2F5cyBwcmlvcml0aXplZCBvdmVyIEhTSS4gSSBrbm93 IHRoYXQgdmVuZG9ycyB0aGF0IGNhbiBkbyB0aGlzLiBJZiB0aGVyZSBpcyBhbnkgY2FzZSB3aGVy ZSB0aGlzIGNhbm5vdCBiZSBkb25lLCBtYXliZSB0aGlzIGFwcHJvYWNoIGlzIG5vdCB0aGUgYmVz dCBhbmQgdGhleSB3aWxsIGhhdmUgdG8gcmVzb3J0IHRvIHNvbWUgb2YgdGhlIG90aGVyIGFwcHJv YWNoZXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQuIA0KDQogDQoNClRoYW5rcywNCg0Ka3Jpcw0KDQog DQoNCiANCg0KRnJvbTogRnJhbmNvaXMgTGUgRmF1Y2hldXIgW21haWx0bzpmbGVmYXVjaEBjaXNj by5jb21dIA0KU2VudDogVHVlc2RheSwgQXByaWwgMDYsIDIwMTAgMTo0MCBBTQ0KVG86IFBPU0NJ QyBLcmlzdGlhbg0KQ2M6IEZyYW5jb2lzIExlIEZhdWNoZXVyOyBTYW5qYXkgV2FkaHdhOyBhbmNw QGlldGYub3JnDQpTdWJqZWN0OiBSZTogUkU6IA0KDQogDQoNCiANCg0KIA0KDQpbU1ddIEluICM0 IGJlbG93IEkgYW0gb25seSB0YWxraW5nIGFib3V0IG11bHRpY2FzdCBhbmQgbm90IFZPRCAocGxl YXNlIG5vdGUgdGhlIGNoYW5uZWwgY2hhbmdlIHNjZW5hcmlvIG1lbnRpb25lZCBpbiB0aGVyZSku IEFOIG1heSB3YW50IHRvIG9wdGlvbmFsbHkgbm90aWZ5IE5BUyBvZiBtdWx0aWNhc3QsIHN1Y2gg dGhhdCBOQVMgY2FuIGFkanVzdCB1bmljYXN0IGIvdyBsb3dlciBkdWUgdG8gbXVsdGljYXN0IGJl aW5nIHNlbnQgb24gTVZMQU4gKGFzIG11bHRpY2FzdCBieXBhc3NlcyBub3JtYWwgUU9TIGhpZXJh cmNoeSBmb3IgdGhlIHN1YnNjcmliZXIpLiBUaGUgcG9pbnQgSSB0cmllZCBtYWtpbmcgaXMgdGhh dCBBTiB3aWxsIG5lZWQgdG8gaG9sZCBvZmYgb24gcmVwbGljYXRpb24gdGlsbCBpdCBnZXRzIGFu IEFDSyBiYWNrIGZyb20gTkFTIHdoZW4gbm90aWZ5aW5nIGl0IG9mIFFPUy1hZGp1c3QuIE9yaWdp bmFsIHJlc3BvbnNlIGZyb20gRnJhbmNvaXMgc2VlbWVkIHRvIGltcGx5IG5vIHJvdW5kLXRyaXAg d2FzIG5lZWRlZCBiZWZvcmUgQU4gc3RhcnRzIHJlcGxpY2F0aW9uICh3aGljaCBJIGRvbid0IGJl bGlldmUgaXMgdGhlIGNhc2UpLg0KDQpbS3Jpc11PaywgIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0 aGUgZGlzY29ubmVjdCBpcy4gVGhpcyBuZXcgbWVzc2FnZSB0aGF0IGlzIGJlaW5nIHByb3Bvc2Vk IHRvIHVwZGF0ZSB0aGUgYi93IHVzYWdlIChub3QgdGhlIGFsbG9jYXRpb24pIGlzIHNlbnQgZnJv bSB0aGUgQU4gdG8gdGhlIE5BUy4gVGhpcyB3aWxsIGJlIGRvbmUgb25seSBpZiB0aGVyZSBpcyBh IGRpZmZlcmVuY2UgaW4gY2hhbm5lbCBiL3cgdXNhZ2UuIEJhc2VkIG9uIHRoaXMgbWVzc2FnZSwg dGhlIE5BUyB3aWxsIGFkanVzdCBpdHMgYi93IGZvciB1bmljYXN0LiBGb3IgZXhhbXBsZSwgYSBu ZXcgam9pbiBjb21lcyBmb3IgYSAgNW1icHMgY2hhbm5lbC4gSWYgdGhpcyBjaGFubmVsIGlzIGFk bWl0dGVkIGJ5IHRoZSBBTiwgdGhlIEFOIHdpbGwgc2VuZCBhIG5ldyBiL3cgdXNhZ2UgcmVwb3J0 ICh0b3RhbCBuZXcgc3ViIHVzYWdlID0gb2xkICsgNW1icHMpLiBUaGUgTkFTIHdpbGwgbm93IGtu b3cgdGhhdCB0aGUgc3Vic2NyaWJlciBpcyBnZXR0aW5nIG1vcmUgdmlkZW8gYi93IChtY2FzdCBj aGFubmVsIGJ5cGFzc2luZyBzdWJzY3JpYmVy4oCZcyBRb1MgaGllcmFyY2h5KS4gU28gdGhlIE5T IHdpbGwgbG93ZXIgaXRzIGFnZ3JlZ2F0ZSByYXRlIGZvciB0aGUgc3Vic2NyaWJlciBmb3IgdGhl IC01TWJwcy4gV2l0aGluIHRoaXMgbmV3IGFnZ3JlZ2F0ZSAobWludXMgNW1icHMpICwgdmlkZW8g c3RpbGwgaGFzIGEgaGlnaGVyIHByaW9yaXR5IHRoYW4gSFNJIHNvIHRoZSBvbmx5IGFmZmVjdGVk IHRyYWZmaWMgd2lsbCBiZSBIU0kuICBGb3IgdGhpcyBJIGFsc28gKGFzIEZyYW5jb2lzKSBkbyBu b3QgYmVsaWV2ZSB0aGF0IGFueSBmZWVkYmFjayBpcyBuZWNlc3NhcnkgYmFjayBmcm9tIHRoZSBO QVMuDQoNCiANCg0KW0ZMRl0gTGV0J3MgZHJpbGwgZG93biBvbiB0aGF0IG9uZS4NCg0KSW4gdGhl IGNhc2Ugd2hlcmUgdGhlIEFOIHN0YXJ0cyByZXBsaWNhdGlvbiB3aXRob3V0IHdhaXRpbmcgZm9y IGFueSAiUW9TLUFkanVzdC1yZXNwb25zZSIgZnJvbSB0aGUgTkFTLCB0aGVyZSBpcyBhIHNtYWxs IHdpbmRvdyBvZiB0aW1lIChmcm9tIHRpbWUgd2hlcmUgcmVwbGljYXRpb24gc3RhcnRzIG9uIEFu IHRvIHRpbWUgd2hlbiBRb1MtYWRqdXN0IGlzIGVmZmVjdGVkIG9uIE5BUyBmb2xsb3dpbmcgdGhl ICJiYW5kd2lkdGgtdXBkYXRlIikgZHVyaW5nIHdoaWNoIHRoZXJlIG1heSBiZSBhbiBleGNlc3Np dmUgYW1vdW50IG9mIHRyYWZmaWMgc2VudCB0b3dhcmRzIGEgZ2l2ZW4gY3VzdG9tZXIgcG9ydCAo aWUgaGlnaCAibmV3IiBtdWx0aWNhc3QgbG9hZCArIGhpZ2ggIm9sZCIgdW5pY2FzdCBsb2FkKS4g SG93ZXZlciwgSSBoYXZlIGJlZW4gYXNzdW1pbmcgdGhpcyBpcyBub3QgYW4gaXNzdWUgYmVjYXVz ZToNCg0KICAgICAgICAgICAgIChpKSB0aGUgQU4gY2FuIHN0aWxsIHByaW9yaXRpemUgdmlkZW8g KHVuaWNhc3QgJiBtdWx0aWNhc3QpIG92ZXIgSFNJLCBhbmQNCg0KICAgICAgICAgICAgKGlpKSBp dCBpcyBvbmx5IHRyYW5zaWVudC4NCg0KVGhpcyBpcyB3aHkgSSBmZWVsIE9LIHdpdGggdGhlICJu byByb3VuZC10cmlwIiBhcHByb2FjaC4NCg0KSXMgaXQgc2FmZSB0byBhc3N1bWUgdGhlIEFOIGNh biBhbHdheXMgcHJpb3JpdGl6ZSB2aWRlbyBvdmVyIEhTSSBkdXJpbmcgdGhlIHRyYW5zaWVudCAi Y29uZ2VzdGlvbiIgcGVyaW9kPw0KDQogDQoNCkZyYW5jb2lzDQoNCiANCg0KIA0KDQogDQoNCiAN Cg0KIA0KDQoJDQoNCiANCg0KDQpGcmFuY29pcyBMZSBGYXVjaGV1cg0KRGlzdGluZ3Vpc2hlZCBF bmdpbmVlcg0KQ29ycG9yYXRlIERldmVsb3BtZW50DQpmbGVmYXVjaEBjaXNjby5jb20gPG1haWx0 bzpmbGVmYXVjaEBjaXNjby5jb20+IA0KUGhvbmU6ICszMyA0OSA3MjMgMjYxOQ0KTW9iaWxlOiAr MzMgNiAxOSA5OCA1MCA5MA0KDQoNCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UNCkdyZWVuc2lkZQ0K NDAwIEF2ZSBkZSBSb3VtYW5pbGxlDQowNjQxMCBTb3BoaWEgQW50aXBvbGlzDQpGcmFuY2UNCkNp c2NvLmNvbSA8aHR0cDovL3d3dy5jaXNjby5jb20+IA0KDQogDQoNCiANCg0KCQ0KIFRoaW5rIGJl Zm9yZSB5b3UgcHJpbnQuDQoNCg0KVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQp LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxs IGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0 w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCT IEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxp bmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJl LCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuDQoN CkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNpc2Nv LmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0KIA0K DQo= ------_=_NextPart_002_01CAD591.B9AA13E9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PGJhc2UgaHJlZj0ieC1tc2c6Ly8xNTUvIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHls ZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9 DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252 ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBs ZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6 U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGUgc3R5bGU9J3dvcmQtd3JhcDogYnJlYWstd29yZDsNCi13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlJz4N Cg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5IaSBGcmFuY29pcyDigJMgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkkgYWdyZWUgd2l0aCB0 aGUgYXNzZXNzbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGUgdHJhbnNpZW50IHdpbGwgYWZmZWN0IG9ubHkg SFNJLiBEdXJpbmcgdGhlIHRyYW5zaWVudCwgdGhlDQpOQVMgd2lsbCBrZWVwIHNlbmRpbmcgbW9y ZSBIU0kgZm9yIHRoZSBzdWJzY3JpYmVyIGludG8gdGhlIGFjY2VzcyBuZXR3b3JrIGZvcg0KdGhl IGNhc2Ugd2hlcmUgdGhpcyB3YXMgYW4gZXhpc3RpbmcgbXVsdGljYXN0IGNoYW5uZWwgaW4gdGhl IE5BUy4gVGhlIEFOIMKgdXN1YWxseQ0KaGFzIGl0cyBvd24gUW9TIHdpdGggcHJvcGVyIHByaW9y aXRpemF0aW9uIGFuZCB3aWxsIGRpc2NhcmQgdGhpcyBleGNlc3MgSFNJLA0Kd2hpY2ggaXMgQmVz dC1FZmZvcnQgYW55d2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SW4gdGhlIFBP TiB3aGVyZSB0aGUgUE9OIGlzIHNoYXJlZCBhbmQgUW9TIGltcGxlbWVudGVkIHBlcg0KYWdncmVn YXRlIGxpbmsgKGluc3RlYWQgb2Ygc3Vic2NyaWJlciksIHRoZSBIU0kgd2lsbCBiZSBhbHNvIGRp c2NhcmRlZCBhbHRob3VnaA0KYWNyb3NzIGFsbCBzdWJzY3JpYmVycy4gVGhpcyA1bWJwcyAoZnJv bSB0aGUgcHJldmlvdXMgZXhhbXBsZSkgd2lsbCBiZSBjdXQgZnJvbQ0KdGhlIEhTSSBvbiB0aGUg UE9OIHBvcnQgdW5pZm9ybWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5CdXQgYWdhaW4sIGFzc3VtaW5nIHRoYXQg dGhpcyBpcyBvbmx5IHRyYW5zaWVudCBjb25kaXRpb24sDQp0cmFmZmljIGlzIGJlc3QtZWZmb3J0 IGFueXdheSwgY29uZ2VzdGlvbiBpcyBzaG9ydCBsaXZlZCAob3RoZXJ3aXNlIHdlIGhhdmUNCm90 aGVyIGlzc3VlcyksIHRoaXMgc2hvdWxkIGJlIE9LLiBUaGUgYmVuZWZpdCBpcyBhIGZhc3RlciBj aGFubmVsIGNoYW5nZSwNCmdyZWF0bHkgcmVkdWNlZCBtZXNzYWdpbmcgYmV0d2VlbiB0aGUgTkFT IGFuZCB0aGUgQU4uIFRoZSBkb3duc2lkZSBpcyB0aGF0DQpiZXN0LWVmZm9ydCB0cmFmZmljIGlz IGN1dCBmb3IgdGhlIGFtb3VudCBvZiBiL3cgdGhhdCBtY2FzdCBjaGFubmVsIGlzIHRha2luZw0K ZHVyaW5nIHRoaXMgc2hvcnQgdHJhbnNpZW50IHBlcmlvZC4gQW5kIHRoaXMgd2lsbCBoYXBwZW4g b25seSBpZiB0aGVyZSBpcyBjb25nZXN0aW9uLA0KaWYgbm90LCB0aGluZ3MgYXJlIGZpbmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5Gb3IgdGhlIGNhc2Ugd2hlcmUgY2hhbm5lbCBp biBub3QgcHJlc2VudCBhdCB0aGUgTkFTIChuZXcgY2hhbm5lbA0Kam9pbiksIHRoaW5ncyB3aWxs IGJlIHNpbWlsYXIuIFRoZSBOQVMgd2lsbCB0cmVhdCB0cmFmZmljIGFwcHJvcHJpYXRlbHkgdmlh IFFvUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkl0IHVzIHVwIHRvIG9wZXJhdG9y IHRvIGRlc2lnbiBRb1MgYmVoYXZpb3IsIGJ1dCBJIHRoaW5rIGl0IGlzDQpzYWZlIHRvIGFzc3Vt ZSB0aGF0IHZpZGVvIChtY2FzdCArIFZPRCkgY2FuIGJlIGFsd2F5cyBwcmlvcml0aXplZCBvdmVy IEhTSS4gSQ0Ka25vdyB0aGF0IHZlbmRvcnMgdGhhdCBjYW4gZG8gdGhpcy4gSWYgdGhlcmUgaXMg YW55IGNhc2Ugd2hlcmUgdGhpcyBjYW5ub3QgYmUNCmRvbmUsIG1heWJlIHRoaXMgYXBwcm9hY2gg aXMgbm90IHRoZSBiZXN0IGFuZCB0aGV5IHdpbGwgaGF2ZSB0byByZXNvcnQgdG8gc29tZQ0Kb2Yg dGhlIG90aGVyIGFwcHJvYWNoZXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5rcmlzPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPsKg PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEZyYW5jb2lzIExlDQpGYXVjaGV1ciBbbWFpbHRvOmZs ZWZhdWNoQGNpc2NvLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA2LCAy MDEwIDE6NDAgQU08YnI+DQo8Yj5Ubzo8L2I+IFBPU0NJQyBLcmlzdGlhbjxicj4NCjxiPkNjOjwv Yj4gRnJhbmNvaXMgTGUgRmF1Y2hldXI7IFNhbmpheSBXYWRod2E7IGFuY3BAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJFOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxi bG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPg0K DQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAg Y2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wPg0KIDx0cj4NCiAgPHRkIHZhbGlnbj10b3Agc3R5 bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz4NCiAgPGRpdiBpZD15aXYxOTI4OTM3NzEwPg0K ICA8ZGl2Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQogIGNvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgPC9kaXY+DQogIDxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPltTV10gSW48c3Bhbg0KICBj bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PGk+Jm5ic3A7PC9pPjwvc3Bhbj4jNCBiZWxvdyBJ IGFtIG9ubHkgdGFsa2luZw0KICBhYm91dCBtdWx0aWNhc3QgYW5kIG5vdCBWT0QgKHBsZWFzZSBu b3RlIHRoZSBjaGFubmVsIGNoYW5nZSBzY2VuYXJpbw0KICBtZW50aW9uZWQgaW4gdGhlcmUpLiBB TiBtYXkgd2FudCB0byBvcHRpb25hbGx5IG5vdGlmeSBOQVMgb2YgbXVsdGljYXN0LCBzdWNoDQog IHRoYXQgTkFTIGNhbiBhZGp1c3QgdW5pY2FzdCBiL3cgbG93ZXIgZHVlIHRvIG11bHRpY2FzdCBi ZWluZyBzZW50IG9uIE1WTEFODQogIChhcyBtdWx0aWNhc3QgYnlwYXNzZXMgbm9ybWFsIFFPUyBo aWVyYXJjaHkgZm9yIHRoZSBzdWJzY3JpYmVyKS4gVGhlIHBvaW50IEkNCiAgdHJpZWQgbWFraW5n IGlzIHRoYXQgQU4gd2lsbCBuZWVkIHRvIGhvbGQgb2ZmIG9uIHJlcGxpY2F0aW9uIHRpbGwgaXQg Z2V0cyBhbg0KICBBQ0sgYmFjayBmcm9tIE5BUyB3aGVuIG5vdGlmeWluZyBpdCBvZiBRT1MtYWRq dXN0LiBPcmlnaW5hbCByZXNwb25zZSBmcm9tDQogIEZyYW5jb2lzIHNlZW1lZCB0byBpbXBseSBu byByb3VuZC10cmlwIHdhcyBuZWVkZWQgYmVmb3JlIEFOIHN0YXJ0cw0KICByZXBsaWNhdGlvbiAo d2hpY2ggSSBkb24ndCBiZWxpZXZlIGlzIHRoZSBjYXNlKS48bzpwPjwvbzpwPjwvcD4NCiAgPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PGk+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCiAgMTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+W0tyaXNdT2ssICZuYnNwO0kNCiAgdGhpbmsgdGhpcyBpcyB3 aGVyZSB0aGUgZGlzY29ubmVjdCBpcy4gVGhpcyBuZXcgbWVzc2FnZSB0aGF0IGlzIGJlaW5nDQog IHByb3Bvc2VkIHRvIHVwZGF0ZSB0aGUgYi93IHVzYWdlIChub3QgdGhlIGFsbG9jYXRpb24pIGlz IHNlbnQgZnJvbSB0aGUgQU4gdG8NCiAgdGhlIE5BUy4gVGhpcyB3aWxsIGJlIGRvbmUgb25seSBp ZiB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgaW4gY2hhbm5lbCBiL3cNCiAgdXNhZ2UuIEJhc2VkIG9u IHRoaXMgbWVzc2FnZSwgdGhlIE5BUyB3aWxsIGFkanVzdCBpdHMgYi93IGZvciB1bmljYXN0LiBG b3INCiAgZXhhbXBsZSwgYSBuZXcgam9pbiBjb21lcyBmb3IgYSAmbmJzcDs1bWJwcyBjaGFubmVs LiBJZiB0aGlzIGNoYW5uZWwgaXMNCiAgYWRtaXR0ZWQgYnkgdGhlIEFOLCB0aGUgQU4gd2lsbCBz ZW5kIGEgbmV3IGIvdyB1c2FnZSByZXBvcnQgKHRvdGFsIG5ldyBzdWINCiAgdXNhZ2UgPSBvbGQg KyA1bWJwcykuIFRoZSBOQVMgd2lsbCBub3cga25vdyB0aGF0IHRoZSBzdWJzY3JpYmVyIGlzIGdl dHRpbmcNCiAgbW9yZSB2aWRlbyBiL3cgKG1jYXN0IGNoYW5uZWwgYnlwYXNzaW5nIHN1YnNjcmli ZXLigJlzIFFvUyBoaWVyYXJjaHkpLiBTbyB0aGUNCiAgTlMgd2lsbCBsb3dlciBpdHMgYWdncmVn YXRlIHJhdGUgZm9yIHRoZSBzdWJzY3JpYmVyIGZvciB0aGUgLTVNYnBzLiBXaXRoaW4NCiAgdGhp cyBuZXcgYWdncmVnYXRlIChtaW51cyA1bWJwcykgLCB2aWRlbyBzdGlsbCBoYXMgYSBoaWdoZXIg cHJpb3JpdHkgdGhhbiBIU0kNCiAgc28gdGhlIG9ubHkgYWZmZWN0ZWQgdHJhZmZpYyB3aWxsIGJl IEhTSS4gJm5ic3A7Rm9yIHRoaXMgSSBhbHNvIChhcyBGcmFuY29pcykNCiAgZG8gbm90IGJlbGll dmUgdGhhdCBhbnkgZmVlZGJhY2sgaXMgbmVjZXNzYXJ5IGJhY2sgZnJvbSB0aGUgTkFTLjwvc3Bh bj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPC9kaXY+DQogIDwvdGQ+DQog PC90cj4NCjwvdGFibGU+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPltGTEZdIExldCdzIGRy aWxsIGRvd24gb24gdGhhdCBvbmUuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+SW4gdGhlIGNhc2Ugd2hlcmUgdGhlIEFOIHN0YXJ0cyByZXBs aWNhdGlvbiB3aXRob3V0IHdhaXRpbmcNCmZvciBhbnkgJnF1b3Q7UW9TLUFkanVzdC1yZXNwb25z ZSZxdW90OyBmcm9tIHRoZSBOQVMsIHRoZXJlIGlzIGEgc21hbGwgd2luZG93DQpvZiB0aW1lIChm cm9tIHRpbWUgd2hlcmUgcmVwbGljYXRpb24gc3RhcnRzIG9uIEFuIHRvIHRpbWUgd2hlbiBRb1Mt YWRqdXN0IGlzDQplZmZlY3RlZCBvbiBOQVMgZm9sbG93aW5nIHRoZSAmcXVvdDtiYW5kd2lkdGgt dXBkYXRlJnF1b3Q7KSBkdXJpbmcgd2hpY2ggdGhlcmUNCm1heSBiZSBhbiBleGNlc3NpdmUgYW1v dW50IG9mIHRyYWZmaWMgc2VudCB0b3dhcmRzIGEgZ2l2ZW4gY3VzdG9tZXIgcG9ydCAoaWUNCmhp Z2ggJnF1b3Q7bmV3JnF1b3Q7IG11bHRpY2FzdCBsb2FkICsgaGlnaCAmcXVvdDtvbGQmcXVvdDsg dW5pY2FzdCBsb2FkKS4NCkhvd2V2ZXIsIEkgaGF2ZSBiZWVuIGFzc3VtaW5nIHRoaXMgaXMgbm90 IGFuIGlzc3VlIGJlY2F1c2U6PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtdGFiLXNwYW4+wqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8L3NwYW4+Jm5ic3A7KGkpIHRoZQ0KQU4gY2FuIHN0aWxsIHByaW9yaXRpemUg dmlkZW8gKHVuaWNhc3QgJmFtcDsgbXVsdGljYXN0KSBvdmVyIEhTSSwgYW5kPG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9 YXBwbGUtdGFiLXNwYW4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8L3NwYW4+KGlpKSBpdCBpcw0K b25seSB0cmFuc2llbnQuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+VGhpcyBpcyB3aHkgSSBmZWVsIE9LIHdpdGggdGhlICZxdW90O25vIHJv dW5kLXRyaXAmcXVvdDsNCmFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPklzIGl0IHNhZmUgdG8gYXNzdW1lIHRoZSBBTiBjYW4g YWx3YXlzIHByaW9yaXRpemUgdmlkZW8gb3Zlcg0KSFNJIGR1cmluZyB0aGUgdHJhbnNpZW50ICZx dW90O2Nvbmdlc3Rpb24mcXVvdDsgcGVyaW9kPzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkZyYW5jb2lzPG86cD48L286cD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjx0YWJsZSBjbGFzcz1Nc29Ob3Jt YWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzDQog c3R5bGU9J3dpZHRoOjQwNy4yNXB0Jz4NCiA8dHI+DQogIDx0ZCBzdHlsZT0ncGFkZGluZzowaW4g MGluIDBpbiAwaW4nPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGltZyB3aWR0aD0xMTAgaGVpZ2h0 PTczDQogIGlkPSJfeDAwMzdfZjI1ZjJiOC01ZTMzLTQyOTctYWU3Ny0yMzI4ZDBhOGMxMzIiDQog IHNyYz0iY2lkOmltYWdlMDAxLmdpZkAwMUNBRDU1Mi5FMTA3N0Y4MCI+PG86cD48L286cD48L3A+ DQogIDx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNl bGxwYWRkaW5nPTAgd2lkdGg9NTQzDQogICBzdHlsZT0nd2lkdGg6NDA3LjI1cHQ7YmFja2dyb3Vu ZC1hdHRhY2htZW50OmluaXRpYWw7LXdlYmtpdC1iYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7DQog ICAtd2Via2l0LWJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsO2JhY2tncm91bmQtY29sb3I6aW5p dGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6DQogICA1MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15 OjAlJz4NCiAgIDx0cj4NCiAgICA8dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48 L3RkPg0KICAgPC90cj4NCiAgPC90YWJsZT4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdkaXNwbGF5Om5vbmUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCiAgPHRhYmxl IGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9 MCB3aWR0aD01NDMNCiAgIHN0eWxlPSd3aWR0aDo0MDcuMjVwdDtiYWNrZ3JvdW5kLWF0dGFjaG1l bnQ6aW5pdGlhbDstd2Via2l0LWJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsNCiAgIC13ZWJraXQt YmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7YmFja2dyb3VuZC1jb2xvcjppbml0aWFsO2JhY2tn cm91bmQtcG9zaXRpb24teDoNCiAgIDUwJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUnPg0KICAg PHRyPg0KICAgIDx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDEx LjI1cHQgLjI1aW4nPg0KICAgIDxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToNCiAgICAiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+DQogICAgPHN0cm9uZz48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkZyYW5jb2lzIExlIEZhdWNoZXVyPC9zcGFu Pjwvc3Ryb25nPjwvc3Bhbj48L2I+PHNwYW4NCiAgICBzdHlsZT0nZm9udC1zaXplOjguNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxicj4NCiAgICA8 c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+RGlz dGluZ3Vpc2hlZA0KICAgIEVuZ2luZWVyPC9zcGFuPjwvc3Ryb25nPjxicj4NCiAgICA8c3Ryb25n PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Q29ycG9yYXRl DQogICAgRGV2ZWxvcG1lbnQ8L3NwYW4+PC9zdHJvbmc+PGJyPg0KICAgIDxhIGhyZWY9Im1haWx0 bzpmbGVmYXVjaEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjojNjY2NjY2Jz5mbGVmYXVj aEBjaXNjby5jb208L3NwYW4+PC9hPjxicj4NCiAgICBQaG9uZTombmJzcDs8c3Ryb25nPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+KzMzIDQ5DQogICAgNzIz IDI2MTk8L3NwYW4+PC9zdHJvbmc+PGJyPg0KICAgIE1vYmlsZTombmJzcDs8c3Ryb25nPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+KzMzIDYNCiAgICAxOSA5 OCA1MCA5MDwvc3Bhbj48L3N0cm9uZz48YnI+DQogICAgPGJyPg0KICAgIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCiAgICA8L3RkPg0KICAgIDx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzowaW4gMGluIDcuNXB0IDE1LjBwdCc+DQogICAgPHAgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7DQogICAgZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+Q2lzY28gU3lzdGVtcyBG cmFuY2U8L3NwYW4+PC9zdHJvbmc+PHNwYW4NCiAgICBzdHlsZT0nZm9udC1zaXplOjguNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxicj4NCiAgICBH cmVlbnNpZGU8YnI+DQogICAgNDAwIEF2ZSBkZSBSb3VtYW5pbGxlPGJyPg0KICAgIDA2NDEwIFNv cGhpYSBBbnRpcG9saXM8YnI+DQogICAgRnJhbmNlPGJyPg0KICAgIDxhIGhyZWY9Imh0dHA6Ly93 d3cuY2lzY28uY29tIj48c3BhbiBzdHlsZT0nY29sb3I6IzY2NjY2Nic+Q2lzY28uY29tPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogICAgPC90ZD4NCiAgICA8dGQgd2lkdGg9MjAw IHN0eWxlPSd3aWR0aDoxNTAuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz4NCiAgICA8cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQogICAgPC90ZD4NCiAgIDwvdHI+ DQogIDwvdGFibGU+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48aW1nIGJvcmRlcj0wIHdpZHRoPTE4 IGhlaWdodD0xOQ0KICBpZD0iX3gwMDMzXzI0ZDM4ZWQtMjE0My00OWE1LThkY2EtYTcyMzk0ZmJk YWFiIg0KICBzcmM9ImNpZDppbWFnZTAwMi5naWZAMDFDQUQ1NTIuRTEwNzdGODAiPjxvOnA+PC9v OnA+PC9wPg0KICA8dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNp bmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTQwMA0KICAgc3R5bGU9J3dpZHRoOjMwMC4wcHQnPg0K ICAgPHRyPg0KICAgIDx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjwvdGQ+DQog ICA8L3RyPg0KICAgPHRyPg0KICAgIDx0ZCBzdHlsZT0ncGFkZGluZzowaW4gLjI1aW4gMGluIC4y NWluJz4NCiAgICA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCiAgICBjb2xvcjojMDA5OTAwJz4m bmJzcDtUaGluayBiZWZvcmUgeW91IHByaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgICA8 L3RkPg0KICAgPC90cj4NCiAgIDx0cj4NCiAgICA8dGQgc3R5bGU9J3BhZGRpbmc6NS4yNXB0IC4y NWluIDQuNXB0IC4yNWluJz4NCiAgICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KICAgIDcuNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM5OTk5OTknPjxicj4NCiAgICBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUNCiAgICB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZQ0KICAgIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvcg0K ICAgIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250 YWN0IHRoZSBzZW5kZXIgYnkNCiAgICByZXBseSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMg b2YgdGhpcyBtZXNzYWdlLjxicj4NCiAgICA8YnI+DQogICAgQ2lzY28gU3lzdGVtcyBGcmFuY2Us IFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUNCiAgICBE ZXNtb3VsaW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJ c3N5IGxlcyBNb3VsaW5lYXV4LA0KICAgIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2 NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGENCiAgICBwdWJsaWNhdGlvbjogSmVh bi1MdWMgTWljaGVsIEdpdm9uZS48YnI+DQogICAgPGJyPg0KICAgIEZvciBjb3Jwb3JhdGUgbGVn YWwgaW5mb3JtYXRpb24gZ28gdG86PGJyPg0KICAgIDxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28u Y29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCI+aHR0cDov L3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5o dG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgICA8L3RkPg0KICAgPC90cj4NCiAgPC90 YWJsZT4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Jv ZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_002_01CAD591.B9AA13E9-- ------_=_NextPart_001_01CAD591.B9AA13E9 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CAD591.B9AA13E9 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CAD591.B9AA13E9-- From swadhwa01@yahoo.com Tue Apr 6 10:20:00 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82A93A6850 for ; Tue, 6 Apr 2010 10:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 5YQd7jPwTVjF for ; Tue, 6 Apr 2010 10:19:57 -0700 (PDT) Received: from n8.bullet.mail.mud.yahoo.com (n8.bullet.mail.mud.yahoo.com [209.191.86.156]) by core3.amsl.com (Postfix) with SMTP id BE96B3A6803 for ; Tue, 6 Apr 2010 10:19:54 -0700 (PDT) Received: from [68.142.194.244] by n8.bullet.mail.mud.yahoo.com with NNFMP; 06 Apr 2010 17:19:50 -0000 Received: from [216.252.122.219] by t2.bullet.mud.yahoo.com with NNFMP; 06 Apr 2010 17:19:49 -0000 Received: from [98.137.27.132] by t4.bullet.sp1.yahoo.com with NNFMP; 06 Apr 2010 17:19:49 -0000 Received: from [98.137.27.208] by t4.bullet.mail.gq1.yahoo.com with NNFMP; 06 Apr 2010 17:19:49 -0000 Received: from [127.0.0.1] by omp118.mail.gq1.yahoo.com with NNFMP; 06 Apr 2010 17:19:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 423581.54168.bm@omp118.mail.gq1.yahoo.com Received: (qmail 15056 invoked by uid 60001); 6 Apr 2010 17:19:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270574389; bh=FthkaMQHXLlqT+y+Z3blQp414xeVTAGVU7ZVjysoO/Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OaLajZIBsCtYlOWt+23BR+yHRdfP5oJStbH1Lz+yeU+K4vKOutZOkVgeceyT3No+koGLE5KEqcMiiZtIuSTn6yT2X01dCG/TlZyqzDqKJjGpMlsapxeKeCUXaWDpMFunujYdtiBitDo0mAFUtv7x8Ier1XzVUCx8ADx+eqrwhSI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dOmIFesHx6j/baipt8pRxBHlT/pzy2RQwj4DvNc06sUSMXjL3ULxWxQmWvnGhDzpzb7yNYOEuZA0cNZ5iP9O5dElfuURH8j43zIhzCzAFLQvxPiFLlKUuDQj7zvW69z7v5kaqlFCVMtYewDLieuzLmmVrSbHBM1uVjyrI2zR930=; Message-ID: <238810.14739.qm@web113811.mail.gq1.yahoo.com> X-YMail-OSG: edrovwkVM1luFAk.vYyzYUtX1jqOY6Q7QHPgSPAijV3a3yM BwmymK64e99bt56uB25q2eQqob9ifXhVoJH0Bnw7rqDbzr_rWBaaNFqzjFEG 1KbBWyrm60fuGSZ5nVqR4Xaff8DDqiPmICTbpG9K4nWIrhVt3baHaCLjWoDj bI2.tNmloZjmP9GEuNmrJFkF1CGvSU6YexmJxweQo3k02HxZR7H3FS589krY K75ZS8c842OZqav21D6brd4cuAQTCc56CjuD.cLxnA_Arp2y5dypOV1y8joG HM22gyVhbkEv4yiDkualpQT.NNiJ6DgHNvxHzynmTtL1ZSM8USthpJbUMaDf SJS49.ZVxe.rVjEAj05hFvCXdJs7n9Q_C0s9FQg-- Received: from [66.129.232.2] by web113811.mail.gq1.yahoo.com via HTTP; Tue, 06 Apr 2010 10:19:49 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 6 Apr 2010 10:19:48 -0700 (PDT) From: Sanjay Wadhwa To: POSCIC Kristian , Francois Le Faucheur In-Reply-To: <87BC6505-4E88-45B6-9279-9DBF9BF02B43@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-260444045-1270574389=:14739" Cc: ancp@ietf.org Subject: Re: [ANCP] (no subject) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:20:01 -0000 --0-260444045-1270574389=:14739 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Francois =C2=A0=C2=A0 As long as we assume AN can do classification and downstream q= ueuing and scheduling to not impact video, we are ok. However, uplink=0Aban= dwidth=0Aon the AN, and bandwidth in aggregation network (if=0Apresent) is = also a consideration, especially if the channel is not=0Aalready being rece= ived by AN. Any FCC in play at the same time will=0Aalso cause unicast burs= ts, but hopefully this is prioritized/queued right all through. Dropping do= wnstream of NAS is likely to be subscriber agnostic,=0Awhich was original c= oncern. However, since this is not sustained (although quite possible acros= s several subscribers at the same time),=0Ait is reasonable to not require = an ACK before replication to reduce latency and messages. If we don't want = to make assumptions about AN capabilities, we could consider making it a co= nfigurable option on AN which is signaled in the updates. Based on network=0Adimensioning and the provisioned QOS model on NAS, there= may be no=0Acongestion at all, in which case nothing to worry. -Sanjay --- On Tue, 4/6/10, Francois Le Faucheur wrote: From: Francois Le Faucheur Subject: Re: RE: To: "POSCIC Kristian" Cc: "Francois Le Faucheur" , "Sanjay Wadhwa" , ancp@ietf.org Date: Tuesday, April 6, 2010, 4:39 AM =C2=A0[SW] In=C2=A0#4 below I am only talking about multicast and not VOD (= please note the channel change scenario mentioned in there). AN may want to= optionally notify NAS of multicast, such that NAS can adjust unicast b/w l= ower due to multicast being sent on MVLAN (as multicast bypasses normal QOS= hierarchy for the subscriber). The point I tried making is that AN will ne= ed to hold off on replication till it gets an ACK back from NAS when notify= ing it of QOS-adjust. Original response from Francois seemed to imply no ro= und-trip was needed before AN starts replication (which I don't believe is = the case).[Kris]Ok, =C2=A0I think this is where the disconnect is. This new= message that is being proposed to update the b/w usage (not the allocation= ) is sent from the AN to the NAS. This will be done only if there is a diff= erence in channel b/w usage. Based on this message, the NAS will adjust its= b/w for unicast. For example, a new join comes for a =C2=A05mbps channel. = If this channel is admitted by the AN, the AN will send a new b/w usage report (to= tal new sub usage =3D old + 5mbps). The NAS will now know that the subscrib= er is getting more video b/w (mcast channel bypassing subscriber=E2=80=99s = QoS hierarchy). So the NS will lower its aggregate rate for the subscriber = for the -5Mbps. Within this new aggregate (minus 5mbps) , video still has a= higher priority than HSI so the only affected traffic will be HSI. =C2=A0F= or this I also (as Francois) do not believe that any feedback is necessary = back from the NAS. [FLF] Let's drill down on that one.In the case where the AN starts replicat= ion without waiting for any "QoS-Adjust-response" from the NAS, there is a = small window of time (from time where replication starts on An to time when= QoS-adjust is effected on NAS following the "bandwidth-update") during whi= ch there may be an excessive amount of traffic sent towards a given custome= r port (ie high "new" multicast load + high "old" unicast load). However, I= have been assuming this is not an issue because:=09=C2=A0(i) the AN can st= ill prioritize video (unicast & multicast) over HSI, and=09(ii) it is only = transient.This is why I feel OK with the "no round-trip" approach.Is it saf= e to assume the AN can always prioritize video over HSI during the transien= t "congestion" period? Francois =0A Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone:=C2=A0+33 49 723 2619 Mobile:=C2=A0+33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =C2=A0=C2=A0Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 limit=C3= =A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 = 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 561 RCS = Nanterre, Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =0A=0A =0A=0A=0A --0-260444045-1270574389=:14739 Content-Type: multipart/related; boundary="0-406107868-1270574389=:14739" --0-406107868-1270574389=:14739 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Francois
   As long as we assume AN can do classification and downs= tream queuing and scheduling to not impact video, we are ok. However, uplink=0Abandwidth=0Aon t= he AN, and bandwidth in aggregation network (if=0Apresent) is also a consid= eration, especially if the channel is not=0Aalready being received by AN. A= ny FCC in play at the same time will=0Aalso cause unicast bursts, but hopef= ully this is prioritized/queued right all through. Dropping downstream of N= AS is likely to be subscriber agnostic,=0Awhich was original concern. Howev= er, since this is not sustained (although quite possible across several sub= scribers at the same time),=0Ait is reasonable to not require an ACK before= replication to reduce latency and messages. If we don't want to make assum= ptions about AN capabilities, we could consider making it a configurable op= tion on AN which is signaled in the updates.

Based on network=0Adime= nsioning and the provisioned QOS model on NAS, there may be no=0Acongestion= at all, in which case nothing to worry.

-Sanjay

--- O= n Tue, 4/6/10, Francois Le Faucheur <flefauch@cisco.com> wrote:

From: Francois Le Faucheur <fle= fauch@cisco.com>
Subject: Re: RE:
To: "POSCIC Kristian" <Kristi= an.Poscic@alcatel-lucent.com>
Cc: "Francois Le Faucheur" <flefauch= @cisco.com>, "Sanjay Wadhwa" <swadhwa01@yahoo.com>, ancp@ietf.org<= br>Date: Tuesday, April 6, 2010, 4:39 AM

<= base>
 

[SW] In #4 below I am only talking about multica= st and not VOD (please note the channel change scenario mentioned in there)= . AN may want to optionally notify NAS of multicast, such that NAS can adju= st unicast b/w lower due to multicast being sent on MVLAN (as multicast byp= asses normal QOS hierarchy for the subscriber). The point I tried making is= that AN will need to hold off on replication till it gets an ACK back from= NAS when notifying it of QOS-adjust. Original response from Francois seemed to imply no round-tr= ip was needed before AN starts replication (which I don't believe is the ca= se).

[Kris]Ok,  I think this= is where the disconnect is. This new message that is being proposed to upd= ate the b/w usage (not the allocation) is sent from the AN to the NAS. This= will be done only if there is a difference in channel b/w usage. Based on = this message, the NAS will adjust its b/w for unicast. For example, a new j= oin comes for a  5mbps channel. If this channel is admitted by the AN,= the AN will send a new b/w usage report (total new sub usage =3D old + 5mb= ps). The NAS will now know that the subscriber is getting more video b/w (m= cast channel bypassing subscriber=E2=80=99s QoS hierarchy). So the NS will = lower its aggregate rate for the subscriber for the -5Mbps. Within this new aggr= egate (minus 5mbps) , video still has a higher priority than HSI so the onl= y affected traffic will be HSI.  For this I also (as Francois) do not = believe that any feedback is necessary back from the NAS.

<= /span>

[FLF] Let's drill down on that= one.
In the case where the AN starts replication without waiting= for any "QoS-Adjust-response" from the NAS, there is a small window of tim= e (from time where replication starts on An to time when QoS-adjust is effe= cted on NAS following the "bandwidth-update") during which there may be an = excessive amount of traffic sent towards a given customer port (ie high "ne= w" multicast load + high "old" unicast load). However, I have been assuming this is not an issue because:
=09 (i) the AN can still prio= ritize video (unicast & multicast) over HSI, and
=09(ii) it is only t= ransient.
This is why I feel OK with the "no round-trip" approach= .
Is it safe to assume the AN can always prioritize video over HS= I during the transient "congestion" period?

Franco= is




=0A
=
=
=


Francois Le Fauche= ur
Distinguished Engineer
Corporate= Development
flefauch@cisco.com
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90


Cisco S= ystems France
Greenside
400 Ave de Roumanille
06410 Sophi= a Antipolis
France
Cisco.com

 
=0A=0A

This email may contain confidential and privileged mat= erial for the sole use of the intended recipient. Any review, use, distribu= tion or disclosure by others is strictly prohibited. If you are not the int= ended recipient (or authorized to receive for the recipient), please contac= t the sender by reply email and delete all copies of this message.

C= isco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 limit=C3= =A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 = 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 561 RCS = Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
<= a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.cisco.com/web/about= /doing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_= business/legal/cri/index.html



=0A=0A --0-406107868-1270574389=:14739 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Id: <1.3719731839@web113811.mail.gq1.yahoo.com> Content-Disposition: inline; filename="logo.gif" R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 --0-406107868-1270574389=:14739 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Id: <2.3719731839@web113811.mail.gq1.yahoo.com> Content-Disposition: inline; filename="green.gif" R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --0-406107868-1270574389=:14739-- --0-260444045-1270574389=:14739-- From fqhuang@huawei.com Tue Apr 6 17:17:23 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CEA3A6876 for ; Tue, 6 Apr 2010 17:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[AWL=-0.195, 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 J5s-I7a38Gyn for ; Tue, 6 Apr 2010 17:17:23 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3B5C93A672F for ; Tue, 6 Apr 2010 17:17:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0H00CTTCSLSB@szxga04-in.huawei.com> for ancp@ietf.org; Wed, 07 Apr 2010 08:17:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0H00I5HCSLAD@szxga04-in.huawei.com> for ancp@ietf.org; Wed, 07 Apr 2010 08:17:09 +0800 (CST) Received: from h36145c ([10.70.39.65]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0H00KFVCSL08@szxml06-in.huawei.com> for ancp@ietf.org; Wed, 07 Apr 2010 08:17:09 +0800 (CST) Date: Wed, 07 Apr 2010 08:17:10 +0800 From: Fortune HUANG In-reply-to: <86C082F6-3C46-4DC6-A139-6DFD982C4781@cisco.com> To: 'Francois Le Faucheur' Message-id: <002001cad5e7$aa53c9e0$4127460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_6Kdr66ClcMo3rhFnMXI8WQ)" Thread-index: AcrVZU1fvAaFey4dRueg1abegwZcrgAgRHrA Cc: 'POSCIC Kristian' , ancp@ietf.org Subject: Re: [ANCP] "Admitted Bandwidth Reporting" multicast use case X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:17:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6Kdr66ClcMo3rhFnMXI8WQ) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT " * the AN is allowed to make some judgment calls about when to report a changed admitted bandwidth. For example, when the AN receives the leave, the AN may want to wait a little before reporting the changed admitted bandwidth in case a join comes in (say because user is simply changing channel)." --[Fortune: Maybe there should be some configuratble policy about when to report the b/w, e.g. report immediately after the AC action, report after a configurable time after the AC action, or report periodically, etc.] While we can give some example of reasonable things to do (such as what you mention above), the details can probably be left to implementers since that does not affect interoperability. Do you agree? [Fortune: Yes, I agree. We can just give some examples for guidance but not for restriction.] Best regards, Fortune --Boundary_(ID_6Kdr66ClcMo3rhFnMXI8WQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
" * the AN is allowed to make some judgment calls about when to report
a changed admitted bandwidth. For example, when the AN receives the leave,
the AN may want to wait a little before reporting the changed admitted
bandwidth in case a join comes in (say because user is simply changing
channel)."  
--[Fortune: Maybe there should be some configuratble policy about when to
report the b/w, e.g. report immediately after the AC action, report after a
configurable time after the AC action, or report periodically, etc.]
While we can give some example of reasonable things to do (such as what you mention above), the details can probably be left to implementers since that does not affect interoperability. Do you agree?
     [Fortune: Yes, I agree. We can just give some examples for guidance but not for restriction.] 
 
 
Best regards,
Fortune

--Boundary_(ID_6Kdr66ClcMo3rhFnMXI8WQ)-- From Stefaan.De_Cnodder@alcatel-lucent.com Tue Apr 13 06:54:24 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391A03A69E7 for ; Tue, 13 Apr 2010 06:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mynncCXDiwII for ; Tue, 13 Apr 2010 06:54:22 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 69A633A6995 for ; Tue, 13 Apr 2010 06:54:21 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3DDsBwl005789 for ; Tue, 13 Apr 2010 15:54:11 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 15:54:02 +0200 Received: from FRMRSSMBS35.ad2.ad.alcatel.com ([155.132.6.13]) by FRVELSMBS21.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 15:54:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 13 Apr 2010 15:54:01 +0200 Message-ID: <83EA57A751E0184CBC24C750A55720733491E8@FRMRSSMBS35.ad2.ad.alcatel.com> In-Reply-To: <5661758E3E93364685B91DD8272F287602AD4EB9@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] capability 03 and 05 Thread-Index: AcrH2FEjIM22lyX5RSqONKBlov+9oAByGNTgBFvb3QA= References: <83EA57A751E0184CBC24C750A55720731EFE05@FRMRSSMBS35.ad2.ad.alcatel.com><8DB099E4-EB82-4A2E-A9D9-C6D6F9C6B33E@cisco.com> <5661758E3E93364685B91DD8272F287602A865EB@S4DE8PSAAQC.mitte.t-com.de> <282BBE8A501E1F4DA9C775F964BB21FE3E8097C963@GRFMBX704BA020.griffon.local> <5661758E3E93364685B91DD8272F287602A8668D@S4DE8PSAAQC.mitte.t-com.de> <4BA43844.80909@bell.net> <5661758E3E93364685B91DD8272F287602AD4EB9@S4DE8PSAAQC.mitte.t-com.de> From: "DE CNODDER Stefaan" To: X-OriginalArrivalTime: 13 Apr 2010 13:54:01.0975 (UTC) FILETIME=[C5E7E870:01CADB10] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [ANCP] capability 03 and 05 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:54:24 -0000 DQpIaSwNCg0KV2hhdCB3YXMgdGhlIGNvbmNsdXNpb24gb2YgdGhpcyB0b3BpYz8gIEkgdW5kZXJz dG9vZCBmcm9tIHRoZSBtZWV0aW5nIG1pbnV0ZXMgdGhhdCBjYXBhYmlsaXR5IDAzIHdpbGwgYmUg cmVtb3ZlZCBmcm9tIGRyYWZ0LXByb3RvIHNpbmNlIGl0IGlzIG5vdCBkZWZpbmVkIGFuZCBub3Qg dXNlZCBpbiBhbnkgb3RoZXIgZG9jdW1lbnQsIGJ1dCB3aWxsIHRoZSBvdGhlciBjYXBhYmlsaXRp ZXMgZnJvbSB0aGUgbXVsdGljYXN0IGRyYWZ0IGJlIHB1dCBpbiB0aGUgYmFzZSBzcGVjPw0KDQpX aGVuIEkga25vdyB3aGF0IHdpbGwgYmUgZG9uZSwgSSBjYW4gdXBkYXRlIHRoZSBNSUIgYmVjYXVz ZSBpdCBkZXBlbmRzIG9uIHRoZSBjYXBhYmlsaXRpZXMgZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVj Lg0KDQpyZWdhcmRzLA0KU3RlZmFhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSGFhZ1RAdGVsZWtvbS5kZSBbbWFpbHRvOkhhYWdUQHRlbGVrb20uZGVdIA0KU2VudDogbWFh bmRhZyAyMiBtYWFydCAyMDEwIDEwOjI0DQpUbzogdG9tMTExLnRheWxvckBiZWxsLm5ldA0KQ2M6 IHJvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdDsgZmxlZmF1Y2hAY2lzY28uY29tOyBE RSBDTk9EREVSIFN0ZWZhYW47IGFuY3BAaWV0Zi5vcmcNClN1YmplY3Q6IEFXOiBbQU5DUF0gY2Fw YWJpbGl0eSAwMyBhbmQgMDUNCg0KVG9tLA0KDQpJIGFncmVlIGluICBtYXJraW5nIHRoZSBjb2Rl cG9pbnQgaW4gYmFzZSBkb2N1bWVudCBhcyByZXNlcnZlZCBmb3IgbXVsdGljYXN0ICwgd2hpbGUg dGhlIE11bHRpY2FzdCBFeHRlbnNpb25zIGRvY3VtZW50IGFzc2lnbnMgdG8gdGhlIHJpZ2h0IGNh cGFiaWxpdHkuICANCg0KUmVnYXJkcw0KVGhvbWFzDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFj aHJpY2h0LS0tLS0NClZvbjogVG9tIFRheWxvciBbbWFpbHRvOnRvbTExMS50YXlsb3JAYmVsbC5u ZXRdIA0KR2VzZW5kZXQ6IFNhbXN0YWcsIDIwLiBNw6RyeiAyMDEwIDAzOjUyDQpBbjogSGFhZywg VGhvbWFzDQpDYzogcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0OyBmbGVmYXVjaEBj aXNjby5jb207IFN0ZWZhYW4uRGVfQ25vZGRlckBhbGNhdGVsLWx1Y2VudC5jb207IGFuY3BAaWV0 Zi5vcmcNCkJldHJlZmY6IFJlOiBbQU5DUF0gY2FwYWJpbGl0eSAwMyBhbmQgMDUNCg0KVGhvbWFz LCBkb2luZyB0aGF0IHdvdWxkIG1lYW4gd2UgY291bGQgbmV2ZXIgYWdhaW4gZXh0ZW5kIEFOQ1Au IEkgZXhwZWN0IHlvdXIgDQpyZWFsIGNvbmNlcm4gaXMgdG8gcHJvdGVjdCB0aGF0IGNvZGVwb2lu dC4gRm9yIHRoYXQsIHRoZSBzb2x1dGlvbiBpcyBzaW1wbGU6IHRoZSANCmJhc2UgZG9jdW1lbnQg bWFya3MgdGhlIGNvZGVwb2ludCBhcyBSZXNlcnZlZCwgYW5kIHRoZSBNdWx0aWNhc3QgRXh0ZW5z aW9ucyANCmRvY3VtZW50IGFzc2lnbnMgaXQgdG8gdGhlIHJpZ2h0IGNhcGFiaWxpdHkgZnJvbSB5 b3VyIHBvaW50IG9mIHZpZXcuDQoNClRvbSBUYXlsb3INCg0KSGFhZ1RAdGVsZWtvbS5kZSB3cm90 ZToNCj4gSGkgUm9iZXJ0YSwNCj4gDQo+IEkgYWdyZWUgdGhhdCBtdWx0aWNhc3QgYXQgYWxsIHNo b3VsZCBiZSBjb3ZlcmVkIGJ5IGEgc2VwZXJhdGUgZG9jdW1lbnQuIFRoZXJlIGlzIG5vIGRvdWJ0 IGFib3V0Lg0KPiANCj4gQnV0IG15IHBvaW50IHdhcyB0aGF0IGNvZGluZ3Mgb2YgYSBzcGVjaWZp YyBmaWVsZCBiZWxvbmdpbmcgdG8gY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBpbiB0aGUgYmFzZSBw cm90b2NvbCBkcmFmdCB3aGljaCByZWZlciB0byBhIGRlZGljYXRlZCB1ZXMgY2FzZSBkZXNjcmli ZWQgaW4gYW4gYWRkaXRpb25hbCBkb2N1bWVudCBtdXN0IGJlIG5hbWVkIGluIHRoZSBiYXNlIHBy b3RvY29sIGRyYWZ0IGFuZCBjYW5ub3QgYmUgcmVtb3ZlZCBmcm9tIHRoYXQuIFdpdGhvdXQgY2Fw YWJpbGl0eSBuZWdvdGlhdGlvbiBvZiBiYXNpYyBwcm90b2NvbCBubyB3b3JrYWJsZSBtdWx0aWNh c3QgdXNlIGNhc2UhICAgDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBUaG9tYXMNCj4gDQo+IC0tLS0t VXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBNYWdsaW9uZSBSb2JlcnRhIFtt YWlsdG86cm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XSANCj4gR2VzZW5kZXQ6IERv bm5lcnN0YWcsIDE4LiBNw6RyeiAyMDEwIDA5OjE2DQo+IEFuOiBIYWFnLCBUaG9tYXM7IGZsZWZh dWNoQGNpc2NvLmNvbTsgU3RlZmFhbi5EZV9Dbm9kZGVyQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPiBD YzogYW5jcEBpZXRmLm9yZw0KPiBCZXRyZWZmOiBSRTogW0FOQ1BdIGNhcGFiaWxpdHkgMDMgYW5k IDA1DQo+IA0KPiBIaSBUaG9tYXMsDQo+ICAgICAgSWYgSSByZW1lbWJlciBjb3JyZWN0bHksIHRo ZSB3b3JraW5nIGdyb3VwIGFncmVlZCBhbG1vc3Qgb25lIHllYXIgYWdvIHRvIGtlZXAgbXVsdGlj YXN0IGV4dGVuc2lvbnMgaW4gYSBzZXBhcmF0ZSBkcmFmdDogdGhlIG11bHRpY2FzdCBkcmFmdCBp cyBub3cgYSBXRyBpdGVtIHBhcnQgb2YgdGhlIGFuY3AgY2hhcnRlci4NCj4gIEFzIFN0ZWZhYW4g YW5kIEZyYW5jb2lzIHBvaW50ZWQgb3V0LCB0aGUgbXVsdGljYXN0IGRyYWZ0IGFscmVhZHkgY29u dGFpbnMgYSBkZWRpY2F0ZWQgc2VjdGlvbiBmb3IgbXVsdGljYXN0IGNhcGFiaWxpdGllcywgdGh1 cyBpbiBvcGluaW9uICB0aGUgbXVsdGljYXN0IHJlbGF0ZWQgY2FwYWJpbGl0aWVzIHNob3VsZCBi ZSByZW1vdmVkIGZyb20gdGhlIGFuY3AtcHJvdG9jb2wgZHJhZnQuDQo+IA0KPiBCZXN0IFJlZ2Fy ZHMsDQo+IFJvYmVydGENCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRnJvbTogYW5jcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YW5jcC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFhZ1RAdGVsZWtvbS5kZQ0KPiBTZW50OiBUaHVyc2Rh eSwgTWFyY2ggMTgsIDIwMTAgODoyMyBBTQ0KPiBUbzogZmxlZmF1Y2hAY2lzY28uY29tOyBTdGVm YWFuLkRlX0Nub2RkZXJAYWxjYXRlbC1sdWNlbnQuY29tDQo+IENjOiBhbmNwQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbQU5DUF0gY2FwYWJpbGl0eSAwMyBhbmQgMDUNCj4gDQo+IEFsbCwNCj4g DQo+IGZyb20gbXkgdW5kZXJzdGFuZGluZyBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGlzIGEgYmFz aWMgcHJvdG9jb2wgZWxlbWVudCBjb21pbmcgYWxvbmcgd2l0aCBhZGphY2VuY3kgd2hpY2ggbXVz dCBiZSBmdWxseSBkZXNjcmliZWQgaW4gcHJvdG9jb2wgZHJhZnQuDQo+IA0KPiBTbyBmcm9tIG15 IHVuZGVyc3RhbmRpbmcgdGhlIGNvZGUgZm9yIG11bHRpY2FzdCBtdXN0IGJlIGtlcHQgaW4gcHJv dG9jb2wgZHJhZnQuIEkgZG9uJ3QgcmVjb21tZW5kIHJlbW92aW5nIGNlcnRhaW4gY2FwYWJpbGl0 eSBjb2RlcyBmcm9tIHRoaXMgYmFzaWMgZHJhZnQgYmVjYXN1ZSBJIHRoaW5rIGZyb20gdGhlIGxv Z2ljYWwgb3JkZXIgYWxsIGRyYWZ0cyBtdXN0IHJlZmVyIHRvIHByb3RvY29sIGRyYWZ0IGFzIGJh c2ljIGRyYWZ0IGFuZCBub3QgZGVmaW5pbmcgYmFzaWMgZWxlbWVudHMvY29kZXMgc2VwZXJhdGVs eS4NCj4gDQo+IFJlZ2FyZHMNCj4gVGhvbWFzDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBWb246IGFuY3AtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmFuY3AtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gRnJhbmNvaXMgTGUgRmF1 Y2hldXINCj4gR2VzZW5kZXQ6IE1pdHR3b2NoLCAxNy4gTcOkcnogMjAxMCAxODoyNA0KPiBBbjog REUgQ05PRERFUiBTdGVmYWFuDQo+IENjOiBhbmNwQGlldGYub3JnDQo+IEJldHJlZmY6IFJlOiBb QU5DUF0gY2FwYWJpbGl0eSAwMyBhbmQgMDUNCj4gSGkgU3RlZmFhbiwNCj4gWWVzLCBJIHRoaW5r IHRoZSBtdWx0aWNhc3QgcmVsYXRlZCBjYXBhYmlsaXRpZXMgbmVlZCB0byBiZSByZW1vdmVkIGZy b20gYW5jcC1wcm90b2NvbC4gVGhleSBhcmUgY292ZXJlZCBpbiBhbmNwLW1jLg0KPiANCj4gRG8g YW5jcC1wcm90b2NvbCBjby1hdXRob3JzIGFncmU/DQo+IA0KPiBPbiAxNyBNYXIgMjAxMCwgYXQg MDk6MzMsIERFIENOT0RERVIgU3RlZmFhbiB3cm90ZToNCj4gDQo+IA0KPiANCj4gSGksDQo+IElu IHRoZSBwcm90b2NvbCBkcmFmdCBJIHJlYWQ6DQo+ICAgIDMuICBDYXBhYmlsaXR5IFR5cGUgOiBU cmFuc2FjdGlvbmFsLU11bHRpY2FzdCA9IDB4MDMgKGNvbnRyb2xsZXIgaS5lLg0KPiAgICAgICAg TkFTIHRlcm1pbmF0ZXMgSUdNUCBtZXNzYWdlcyBmcm9tIHN1YnNjcmliZXJzLCBhbmQgdmlhIGwy IGNvbnRyb2wNCj4gICAgICAgIHByb3RvY29sLCBzaWduYWxzIHN0YXRlIHRvIHRoZSBhY2Nlc3Mt bm9kZXMgKGUuZy4gIERTTEFNcykgdG8NCj4gICAgICAgIGVuYWJsZSBsYXllcjIgcmVwbGljYXRp b24gb2YgbXVsdGljYXN0IHN0cmVhbXMuICBJbiBBVE0gYWNjZXNzDQo+ICAgICAgICBuZXR3b3Jr IHRoaXMgaW1wbGllcyB0aGF0IE5BUyBpbnN0cnVjdHMgdGhlIGFjY2Vzcy1ub2RlIHRvIHNldHVw DQo+ICAgICAgICBhIFAyTVAgY3Jvc3MtY29ubmVjdC4gIFRoZSBkZXRhaWxzIG9mIHRoaXMgd2ls bCBiZSBjb3ZlcmVkIGluIGENCj4gICAgICAgIHNlcGFyYXRlIElELg0KPiBJcyB0aGlzIHRoZSBz YW1lIGFzIGNhcGFiaWxpdHkgMHgwNSBkZWZpbmVkIGluIGRyYWZ0LWlldGYtYW5jcC1tYy1leHRl bnNpb25zLTAyLnR4dD8gIEl0IGxvb2tzIHRvIGJlIGJldHRlciB0byByZW1vdmUgY2FwYWJpbGl0 eSAweDAzIGZyb20gdGhlIGJhc2Ugc3BlYy4NCj4gcmVnYXJkcywNCj4gU3RlZmFhbg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQU5DUCBt YWlsaW5nIGxpc3QNCj4gQU5DUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FuY3ANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBGcmFuY29pcyBMZSBGYXVj aGV1cg0KPiBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQo+IENvcnBvcmF0ZSBEZXZlbG9wbWVudA0K PiBmbGVmYXVjaEBjaXNjby5jb20NCj4gUGhvbmU6ICszMyA0OSA3MjMgMjYxOQ0KPiBNb2JpbGU6 ICszMyA2IDE5IDk4IDUwIDkwDQo+IA0KPiBDaXNjbyBTeXN0ZW1zIEZyYW5jZQ0KPiBHcmVlbnNp ZGUNCj4gNDAwIEF2ZSBkZSBSb3VtYW5pbGxlDQo+IDA2NDEwIFNvcGhpYSBBbnRpcG9saXMNCj4g RnJhbmNlDQo+IENpc2NvLmNvbQ0KPiANCj4gDQo+IA0KPiAgVGhpbmsgYmVmb3JlIHlvdSBwcmlu dC4NCj4gDQo+IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4g QW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2Yg dGhpcyBtZXNzYWdlLg0KPiANCj4gQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCBy ZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0 bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwg QXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVj dGV1ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZS4NCj4gDQo+IEZv ciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQo+IGh0dHA6Ly93d3cuY2lzY28u Y29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KPiANCj4g DQo+IA0KPiBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenph dGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBj b3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEg ZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9y YSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0 ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0 ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4gDQo+ IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2Vl KHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnli b2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFu ZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBTkNQIG1haWxp bmcgbGlzdA0KPiBBTkNQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYW5jcA0K From tom111.taylor@bell.net Tue Apr 13 07:36:39 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA473A69E7 for ; Tue, 13 Apr 2010 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, MSGID_FROM_MTA_HEADER=0.803] 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 NHvYwRpYDG65 for ; Tue, 13 Apr 2010 07:36:39 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id B04BF3A6973 for ; Tue, 13 Apr 2010 07:36:36 -0700 (PDT) Received: from BLU0-SMTP65 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 07:36:31 -0700 X-Originating-IP: [74.12.183.53] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([74.12.183.53]) by BLU0-SMTP65.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 07:36:30 -0700 Date: Tue, 13 Apr 2010 10:36:24 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: DE CNODDER Stefaan , ancp@ietf.org References: <83EA57A751E0184CBC24C750A55720731EFE05@FRMRSSMBS35.ad2.ad.alcatel.com><8DB099E4-EB82-4A2E-A9D9-C6D6F9C6B33E@cisco.com> <5661758E3E93364685B91DD8272F287602A865EB@S4DE8PSAAQC.mitte.t-com.de> <282BBE8A501E1F4DA9C775F964BB21FE3E8097C963@GRFMBX704BA020.griffon.local> <5661758E3E93364685B91DD8272F287602A8668D@S4DE8PSAAQC.mitte.t-com.de> <4BA43844.80909@bell.net> <5661758E3E93364685B91DD8272F287602AD4EB9@S4DE8PSAAQC.mitte.t-com.de> <83EA57A751E0184CBC24C750A55720733491E8@FRMRSSMBS35.ad2.ad.alcatel.com> In-Reply-To: <83EA57A751E0184CBC24C750A55720733491E8@FRMRSSMBS35.ad2.ad.alcatel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2010 14:36:31.0002 (UTC) FILETIME=[B53E8FA0:01CADB16] Subject: Re: [ANCP] capability 03 and 05 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:36:39 -0000 The conclusion is that the IANA section of the base document will indicate that capability codepoint 0x0003 is Reserved. No other changes will be made to the set of capabilities currently defined in the base document. The multicast extensions document will be updated to ensure that NAS-initiated replication is assigned capability value 0x0003 rather than 0x0005. We have a couple of choices for the remaining multicast capabilities. Because we are introducing a new bandwidth reporting capability (recently discussed) we could give it capability codepoint 0x0005 and leave the others unchanged. The second choice is to not assign codepoint 0x0005, leaving a hole in the sequence. The new capability would use codepoint 0x0009. While I was looking at the base document to check out whether capability codepoints were a scarce resource, I discovered an issue, at least in my mind. That is, that capabilities are indicated by the presence of "capability TLVs" in the adjacency message. The problem is that the capability values are equivalent to TLV types, but are not included in the registered set of TLV types. I agree with that treatment, in fact, but believe that the term "capability TLV" is going to cause confusion. I strongly suggest that the phrase be changed instead to "capability field". I also note that the multicast extensions document does not define the capability data for the capabilities it defines. Probably there isn't any, but the contents of the capability fields for multicast-related capabilities do need to be specified. A to-do for the editors. DE CNODDER Stefaan wrote: > Hi, > > What was the conclusion of this topic? I understood from the meeting minutes > that capability 03 will be removed from draft-proto since it is not defined > and not used in any other document, but will the other capabilities from the > multicast draft be put in the base spec? > > When I know what will be done, I can update the MIB because it depends on the > capabilities defined in the base spec. > > regards, Stefaan > ... From tom111.taylor@bell.net Thu Apr 15 18:21:47 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26E93A6A33 for ; Thu, 15 Apr 2010 18:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 FLbSE0TeqWxY for ; Thu, 15 Apr 2010 18:21:44 -0700 (PDT) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by core3.amsl.com (Postfix) with ESMTP id 99CE23A6A09 for ; Thu, 15 Apr 2010 18:21:22 -0700 (PDT) Received: from BLU0-SMTP80 ([65.55.116.72]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 18:21:15 -0700 X-Originating-IP: [74.12.183.53] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([74.12.183.53]) by BLU0-SMTP80.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Apr 2010 18:21:15 -0700 Date: Thu, 15 Apr 2010 21:21:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org, 'Sanjay Wadhwa' , jmoisand@juniper.net, "Haag, Thomas" , Maglione Roberta Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2010 01:21:15.0418 (UTC) FILETIME=[1BC77FA0:01CADD03] Subject: [ANCP] Review of draft-ietf-ancp-protocol-09 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 01:21:47 -0000 This is my promised review of the ANCP base protocol document, through section 5.4.2. I also have noted numerous places where trivial editorial changes might be desirable. I am dealing directly with the authors on those. Initial point: the addresses of two of the authors, Norbert Voigt and Swami Subramanian, are out of date. This could cause trouble come AUTH48, since the RFC Editor has to hear back from all authors. (1) Section 1, fifth paragraph: The introduction talks about reusing GSMPv3 messages. However, it does not mention that ANCP also introduces new messages, and that extensions to the base document can introduce further new messages. I'd suggest that this information be added. (2) Section 4.1: (a) Remove the bullet mentioning multicast replication. (b) Editorial: integrate the last paragraph with the last sentence of the first paragraph (both talking about GSMPv3). Move the paragraph with the bullets to the end, providing a neater transition to the next section. (3) Section 4.4.1, first para: Editorial: the text: "The format of relevant extensions to port management message is defined in section" is duplicated. (4) Section 5, Sub-version: The RFC Editor's Note should require the change to be made both in the Sub-version bullet and in the paragraph following Figure 6. Add the words: "both here and in the paragraph following Figure 6" to the RFC Editor's Note. (5) Section 5, Result: I would suggest the first sentence be changed to: "The Result field uses a subset of the values defined for GSMPv3 [RFC3292], plus the additional value 0x00. The specific usage of these Result values may be specified for individual message types. Where unspecified, the general rule is that values 0x00 through 0x02 MUST appear only in requests, and values 0x03 and 0x04 MUST appear only in responses. "The Result field values used in ANCP are:" (6) Section 5, Message Type: Editorial: should be moved up to follow Sub-Version. (7) Section 5, Code: In the first paragraph, change "is set to zero" to "MUST be set to zero". (8) Section 5.1: I would find it less confusing if the terminology used for the delimiting header for TCP differed from the terminology used for the message body. There would be less chance of confusing the "Type" in the header with the message type if the following changes were made: (a) Delete "TLV" in "TLV header". Just call it a header instead. (b) Call the first field in the header an identifier. I suggest replacing the existing text by: "Identifier: "This two-byte field has the fixed value 0x880C (i.e., the same value as GSMP's Ethertype). It identifies the content following the header as a GSMPv3 message". The figure has to be changed to match. (9) Section 5.2: Beginning of second paragraph: change "The NAS will set ..." to "The NAS MUST set ...". Two lines below that, change "are exchanged" to "MUST be exchanged". The following paragraph also needs occasional rephrasing to use RFC 2119 language. The paragraph after that has a bunch of "should"s. These probably need to be upper case, and the circumstances where one not use the specified settings have to be described. If there is no justification for deviating from the recommended settings, these have to be MUSTs. Again, the next-to-last paragraph dealing with adjacency timeout has to be modified to use RFC 2119 language. The reason for "SHOULD" for state cleanup is perhaps a bit more obvious here, so it's less necessary to specify the exceptions. (10) Section 5.3: (a) I repeat the point I made the other day: the type codes for the capability "TLVs" do not appear in the IANA registry and and in fact conflict with existing TLV codes. I therefore suggest that we simply call these "capability fields" rather than "capability TLVs". (b) This section also needs to be rewritten to use RFC 2119 language. (c) In the paragraph just below the figure, dealing with Tech Type, the last sentence should be deleted. This is actually a memo to the authors to make sure the IANA registration is set up, rather than a specification for the implementer. (d) The text dealing with Capability Type 0x03 should be deleted. (11) Section 5.4.1.1: I'm not sure the extension block itself has a TLV structure. It might be better to call it an extension block and say that it encapsulates one or more TLVs. That affects the title of sub-section 5.4.1.1 as well as the content of the first paragraph and the label of the figure below it. In defining the extension value you could say explicitly that it is composed of one or more TLVs as described for individual message types. (12) Section 5.4.2: (a) In the second paragraph, as much as possible, refer to section 5 for the setting of individual fields. There is no need to repeat instructions for Version, Sub-Version (with its RFC Editor's Note, missing here), "I" bit, SubMessage value, or Length. (b) fifth paragraph: will the Tech Type always be 0x05, or could PON require a different Tech Type? (c) paragraph following Figure 13: Change "is silently ignored" to "MUST be silently ignored". (d) Immediately following that paragraph, the text should be expanded a little: "The following TLVs are defined for use in the PORT UP / PORT DOWN Event message:" (e) The syntax for the ASCII strings would be clearer if you omitted the quotation marks around the complete string, put angle brackets around the variable parts, and either quoted or left unmarked the literals. (Remember to use < in your XML2RFC source instead of <). Example: atm :. You could even go all the way and use ABNF, but I expect that's overkill. (f) At the end of the description of the Access-Aggregation-Circuit-ID-ASCII (bullet 4), there is a "TBD" regarding uplink characteristics. Can that be replaced by an internal reference or should it simply be deleted? Actually, the whole paragraph seems to be out of place. (g) At the beginning of the description of DSL Line Attributes (bullet 5), it is stated that the TLV is mandatory. I assume it is mandatory when Tech Type is 0x05, but not otherwise. (h) Perhaps the description of the contents of the DSL Line Attributes TLV could be phrased this way: that the DSL Line Attributes TLV encapsulates a number of other TLVs. Refer to Figure 13 and accompanying text to describe their format, and don't talk about the assigned type code values ("start from 0x81"). (i) Would it worthwhile, the first time the abbreviation "Kb" appears, to add: "(1 Kb = 1000 bits)"? And if you actually mean 1024 bits, you really should add this explanation. From fabio.poggi@ericsson.com Tue Apr 27 09:01:41 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EC33A6B89 for ; Tue, 27 Apr 2010 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VErPz0VWsfQ8 for ; Tue, 27 Apr 2010 09:01:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DD8383A6A81 for ; Tue, 27 Apr 2010 08:59:34 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9d-4bd709d9a765 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6C.2C.23740.9D907DB4; Tue, 27 Apr 2010 17:59:21 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 17:59:21 +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_01CAE622.99A0F71A" Date: Tue, 27 Apr 2010 17:59:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ADSL Transmission System Thread-Index: AcrmIpkgMy181AQsQ6aGGSwXro+kEA== From: "Fabio Poggi" To: X-OriginalArrivalTime: 27 Apr 2010 15:59:21.0342 (UTC) FILETIME=[9994C1E0:01CAE622] X-Brightmail-Tracker: AAAAAA== Subject: [ANCP] ADSL Transmission System X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 16:01:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAE622.99A0F71A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In cap.5 (DSL Line Attributes) of draft-ietf-ancp-protocol-09 there's the sub-TLV DSL-Type =3D 0x91. Among all the foreseen values (Transmission System: ADSL1 =3D 0x01, = ADSL2 =3D 0x02, ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D = 0x06, UNKNOWN =3D 0x07) I don't see the one for SHDSL. =20 Is it wanted? (In this case, what value do you suggest to use for SHDSL) Or an SHDSL value will be inserted in further draft? (0x08 ?) =20 Many thanks in advance. Fabio =20 ------_=_NextPart_001_01CAE622.99A0F71A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

In cap.5 (DSL Line Attributes) of draft-ietf-ancp-protocol-= 09 there's the sub-TLV DSL-Type =3D 0x91.

Among all the foreseen values (Transmission System: = ADSL1 =3D 0x01, ADSL2 =3D 0x02, ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, = SDSL =3D 0x06, UNKNOWN =3D 0x07) I don't see the one for = SHDSL.

 

Is it wanted? (In this case, what value do you = suggest to use for SHDSL)

Or an SHDSL value will be inserted in further draft? = (0x08 ?)

 

Many thanks in advance.

Fabio

 

------_=_NextPart_001_01CAE622.99A0F71A-- From wdec@cisco.com Fri Apr 30 04:40:42 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398DD3A694D for ; Fri, 30 Apr 2010 04:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=-4.153, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 idBZ-li7QcPf for ; Fri, 30 Apr 2010 04:40:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D73653A68A0 for ; Fri, 30 Apr 2010 04:40:40 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwCADJe2kuQ/uCWiWdsb2JhbACBPo9Di0BeFQEBAQoLEREGHKM2mgeFEgQ X-IronPort-AV: E=Sophos;i="4.52,302,1270425600"; d="scan'208,217";a="6524901" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 30 Apr 2010 11:03:22 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3UBeQLG012846; Fri, 30 Apr 2010 11:40:26 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Apr 2010 13:40:25 +0200 Received: from 10.55.215.36 ([10.55.215.36]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Apr 2010 11:40:25 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 30 Apr 2010 13:40:33 +0200 From: Wojciech Dec To: Fabio Poggi , Message-ID: Thread-Topic: [ANCP] ADSL Transmission System Thread-Index: AcrmIpkgMy181AQsQ6aGGSwXro+kEACN1gVN In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3355479636_431786" X-OriginalArrivalTime: 30 Apr 2010 11:40:25.0892 (UTC) FILETIME=[ECF87640:01CAE859] Subject: Re: [ANCP] ADSL Transmission System X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 11:40:42 -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_3355479636_431786 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, I suspect that it is an unintentional omission, if not more of the SDSL vs SHDSL confusion. An assignment for SHDSL would appear to be justified. Thanks, Woj. On 27/04/2010 17:59, "Fabio Poggi" wrote: > Hi all, > In cap.5 (DSL Line Attributes) of draft-ietf-ancp-protocol-09 > there's the > sub-TLV DSL-Type = 0x91. > Among all the foreseen values (Transmission System: ADSL1 = 0x01, ADSL2 = > 0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN = 0x07) > I don't see the one for SHDSL. > > Is it wanted? (In this case, what value do you suggest to use for SHDSL) > Or an SHDSL value will be inserted in further draft? (0x08 ?) > > Many thanks in advance. > Fabio > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --B_3355479636_431786 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [ANCP] ADSL Transmission System Hi,

I suspect that it is an unintentional omission, if not more of the SDSL vs = SHDSL confusion. An assignment for SHDSL would appear to be justified.

Thanks,
Woj.


On 27/04/2010 17:59, "Fabio Poggi" <fabio.poggi@ericsson.com> wrote:

Hi all,
In cap.5 (DSL Line Attributes) of draft-ietf-ancp-protocol-09 <http://datatracke= r.ietf.org/doc/draft-ietf-ancp-protocol/> there's the sub-TLV DSL-Typ= e =3D 0x91.
Among all the foreseen values (Transmission System: ADSL1 =3D 0x01, ADSL2 =3D 0= x02, ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, UNKNOWN =3D 0x07)= I don't see the one for SHDSL.
 
Is it wanted? (In this case, what value do you suggest to use for SHDSL) Or an SHDSL value will be inserted in further draft? (0x08 ?)
 
Many thanks in advance.
Fabio
 

___________= ____________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp
--B_3355479636_431786--