From elena.demaria@telecomitalia.it Fri Nov 2 01:40:47 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA61221F9975 for ; Fri, 2 Nov 2012 01:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUK6fGKHSI1Z for ; Fri, 2 Nov 2012 01:40:47 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5621F9974 for ; Fri, 2 Nov 2012 01:40:47 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 2 Nov 2012 09:40:36 +0100 Received: from GRFMBX702BA020.griffon.local ([10.188.101.11]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Fri, 2 Nov 2012 09:40:36 +0100 From: Demaria Elena To: "dmm@ietf.org" Date: Fri, 2 Nov 2012 09:40:35 +0100 Thread-Topic: Review of draft-zuniga-dmm-gap-analysis-02 Thread-Index: Ac22hgLN2+klwA8wTNyhbETk9W34bA== Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5A6D86A7D@GRFMBX702BA020.griffon.local> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [DMM] Review of draft-zuniga-dmm-gap-analysis-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:40:48 -0000 Hi all, here are some comments on draft-zuniga-dmm-gap-analysis-02. I have some doubts on current scope of section 2. In my opinion "how to dep= loy a mobility solution in a DMM fashion" is the gap analysis. Probably a section on existing mobility solutions (that rapidly covers main= features) is needed but I would avoid to anticipate some considerations on= the gap analysis itself. Just briefly describe what are the main features = of the analyzed protocols. In the gap analysis itself (paragraph 3), for example, I found difficult to= understand what is missing in term of functionalities. For example in 3.1.= 1 you say that REQ1 is not satisfied by MIP6, but you are not saying what = is missing. You said that in 2.1.1: "current Mobile IPv6 / NEMO specificati= ons do not allow the use of multiple home agents by a mobile node simultane= ously". I would also have considered, for example, MIPv6 and its extensions as a wh= ole instead of separating each component. What we are trying to understand = here is if we can use some existing protocols and its currently defined ext= ensions for DMM. I think it is useful to see which extension adds which fea= ture but at the end of the document you should say something on a complete = solution. Perhaps you can add some text in chapter 4 saying that a solution= that considers protocol x plus extension y is well suited for DMM or that = none of the available solutions meets all requirements. For REQ2 (for both MIPv6 and PMIPv6) you say that the solution is transpare= nt to upper layers but in the table in paragraph 4 there is LIM (limited su= pport). I think this is wrong. Non optimal routing is already considered in= REQ1 and should not be part of REQ2. Regards, Elena Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From cjbc@it.uc3m.es Sat Nov 3 01:20:03 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9061521F847C for ; Sat, 3 Nov 2012 01:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYLC4VBbhzIZ for ; Sat, 3 Nov 2012 01:19:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4D48D21F8470 for ; Sat, 3 Nov 2012 01:19:59 -0700 (PDT) X-uc3m-safe: yes Received: from [172.20.10.2] (38.Red-95-125-171.staticIP.rima-tde.net [95.125.171.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id CB4D49D27A1; Sat, 3 Nov 2012 09:19:55 +0100 (CET) Message-ID: <1351930793.28330.4.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Demaria Elena Date: Sat, 03 Nov 2012 09:19:53 +0100 In-Reply-To: <36A93B31228D3B49B691AD31652BCAE9A5A6D86A7D@GRFMBX702BA020.griffon.local> References: <36A93B31228D3B49B691AD31652BCAE9A5A6D86A7D@GRFMBX702BA020.griffon.local> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RhLA60OCri2TAa7pa2Sl" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19336.002 X-TM-AS-Result: No--13.667-7.0-31-1 X-imss-scan-details: No--13.667-7.0-31-1 Cc: "dmm@ietf.org" Subject: Re: [DMM] Review of draft-zuniga-dmm-gap-analysis-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:20:03 -0000 --=-RhLA60OCri2TAa7pa2Sl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Elena, Thanks a lot for your comments on our draft. Please, see some answers below inline... On Fri, 2012-11-02 at 09:40 +0100, Demaria Elena wrote: > Hi all, > here are some comments on draft-zuniga-dmm-gap-analysis-02. >=20 > I have some doubts on current scope of section 2. In my opinion "how to d= eploy a mobility solution in a DMM fashion" is the gap analysis. Well, our approach was to analyze to what extent main IP mobility protocols could meet DMM requirements. In order to do so, we first describe how these main IP solutions can operate/be deployed to work in a DMM fashion. This is what we try to do in Section 2. > Probably a section on existing mobility solutions (that rapidly covers ma= in features) is needed but I would avoid to anticipate some considerations = on the gap analysis itself. Just briefly describe what are the main feature= s of the analyzed protocols. We believe that it is important to understand what are the capabilities in terms of distributed operation of main mobility solutions. This paves the way for the actual gap analysis performed in Section 3. > In the gap analysis itself (paragraph 3), for example, I found difficult = to understand what is missing in term of functionalities. For example in 3.= 1.1 you say that REQ1 is not satisfied by MIP6, but you are not saying what= is missing. You said that in 2.1.1: "current Mobile IPv6 / NEMO specifica= tions do not allow the use of multiple home agents by a mobile node simulta= neously". We sure can improve the text, and suggestions are highly welcome and appreciated. Our rationale there is that current MIPv6/NEMO do not allow to deploy distributed home agents and then enable the mobile node to dynamically switch and benefit from using them. You can deploy multiple home agents, but the mobile node will always be associated to a single one at each moment. This is what it is missing. >=20 > I would also have considered, for example, MIPv6 and its extensions as a = whole instead of separating each component. What we are trying to understan= d here is if we can use some existing protocols and its currently defined e= xtensions for DMM. I think it is useful to see which extension adds which f= eature but at the end of the document you should say something on a complet= e solution. Perhaps you can add some text in chapter 4 saying that a soluti= on that considers protocol x plus extension y is well suited for DMM or tha= t none of the available solutions meets all requirements. That is indeed a possible option that we also did consider. But here we thought there is a tradeoff between complexity of the text and clarity. We wanted to keep the text as simple as possible and we also fear that going into analyzing combinations of solutions might go into solution space, which is not the goal of the gap analysis. We should just find out if a DMM solution is actually required or if the DMM requirements can be met with existing solutions. >=20 > For REQ2 (for both MIPv6 and PMIPv6) you say that the solution is transpa= rent to upper layers but in the table in paragraph 4 there is LIM (limited = support). I think this is wrong. Non optimal routing is already considered = in REQ1 and should not be part of REQ2. It is true that this is not clear in this version. In the table we wanted to highlight that even though MIPv6 and PMIPv6 are transparent to upper layers, its use deploying multiple home agents/local mobility anchors and trying to benefit from that "distributed" mode is not, as it requires to change the home address. Maybe we can clarify this in regards of the requirements and then update the table accordingly. Thanks again for the comments. Carlos >=20 > Regards, > Elena >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p= ersone indicate. La diffusione, copia o qualsiasi altra azione derivante da= lla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di d= arne immediata comunicazione al mittente e di provvedere alla sua distruzio= ne, Grazie. >=20 > This e-mail and any attachments is confidential and may contain privilege= d information intended for the addressee(s) only. Dissemination, copying, p= rinting or use by anybody else is unauthorised. If you are not the intended= recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks. >=20 --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=20 Carlos Jes=C3=BAs Bernardos Cano Universidad Carlos III de Madrid --=-RhLA60OCri2TAa7pa2Sl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlCU06kACgkQNdy6TdFwT2eDHgCdGltXZDbq4J2wS2rNYWotnqAV uKEAn3Gvb2n4F5lrSrWlUP0XqitO8jO4 =3eo/ -----END PGP SIGNATURE----- --=-RhLA60OCri2TAa7pa2Sl-- From karagian@cs.utwente.nl Sun Nov 4 11:27:20 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9BC21F86DD for ; Sun, 4 Nov 2012 11:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbehFsG4ur0P for ; Sun, 4 Nov 2012 11:27:19 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA521F86D5 for ; Sun, 4 Nov 2012 11:27:18 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 20:27:19 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 20:27:17 +0100 From: To: , Thread-Topic: [DMM] Review of draft-zuniga-dmm-gap-analysis-02 Thread-Index: Ac22hgLN2+klwA8wTNyhbETk9W34bADDZtyAAErzD7M= Date: Sun, 4 Nov 2012 19:27:17 +0000 Message-ID: References: <36A93B31228D3B49B691AD31652BCAE9A5A6D86A7D@GRFMBX702BA020.griffon.local>, <1351930793.28330.4.camel@acorde.it.uc3m.es> In-Reply-To: <1351930793.28330.4.camel@acorde.it.uc3m.es> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] Review of draft-zuniga-dmm-gap-analysis-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:27:20 -0000 Hi all, I have also reviewd draft-zuniga-dmm-gap-analysis-02. I think that this dra= ft is usefull, but I have some comments: 1) the gap analysis should somehow use as context a generic framework, like= the one introduced in http://www.ietf.org/id/draft-chan-dmm-framework-gap-= analysis-05.txt and/or=20 http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt. 2) Section 3, describes the limitations in current practices, by using the = requirements specified in http://www.ietf.org/id/draft-ietf-dmm-requirement= s-02.txt. However, by reviewing the descibed limitations of each existing solution, I= have seen that these limitations are too briefly explained without focussi= ng in detail on how each of these limitations relates to the given requirem= ent. 3) As I already mentioned previously in emails sent to the list, more solut= ions could be included in this analysis, such as: =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6=20 http://www.rfc-editor.org/rfc/rfc5533.txt =3D> LISP Mobile Node http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt Locator/ID Separation Protocol (LISP)=20 http://www.ietf.org/id/draft-ietf-lisp-23.txt =3D> Mobile IPv6 Fast Handovers http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt This is the draft that became then RFC5568, so no need to mention it. http://www.rfc-editor.org/rfc/rfc5568.txt =3D> Fast Handovers for Proxy Mobile IPv6=20 http://www.rfc-editor.org/rfc/rfc5949.txt =3D> Host Identity Protocol http://www.rfc-editor.org/rfc/rfc4423.txt http://www.rfc-editor.org/rfc/rfc5201.txt http://www.rfc-editor.org/rfc/rfc6253.txt http://www.rfc-editor.org/rfc/rfc5206.txt =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE)=20 http://www.rfc-editor.org/rfc/rfc4555.txt =3D> GTPv2-C: 3rd Generation Partnership Project; Technical Specification G= roup Core Network and Terminals; 3GPP Evolved Packet System (EPS); =20 Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control= plane (GTPv2-C); Stage 3 (Release 11) http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip =3D> Mobility solutions used for Cloud computing support Best regards, Georgios ________________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Carlos Jes=FAs Bern= ardos Cano [cjbc@it.uc3m.es] Verzonden: zaterdag 3 november 2012 9:19 To: Demaria Elena Cc: dmm@ietf.org Onderwerp: Re: [DMM] Review of draft-zuniga-dmm-gap-analysis-02 Dear Elena, Thanks a lot for your comments on our draft. Please, see some answers below inline... On Fri, 2012-11-02 at 09:40 +0100, Demaria Elena wrote: > Hi all, > here are some comments on draft-zuniga-dmm-gap-analysis-02. > > I have some doubts on current scope of section 2. In my opinion "how to d= eploy a mobility solution in a DMM fashion" is the gap analysis. Well, our approach was to analyze to what extent main IP mobility protocols could meet DMM requirements. In order to do so, we first describe how these main IP solutions can operate/be deployed to work in a DMM fashion. This is what we try to do in Section 2. > Probably a section on existing mobility solutions (that rapidly covers ma= in features) is needed but I would avoid to anticipate some considerations = on the gap analysis itself. Just briefly describe what are the main feature= s of the analyzed protocols. We believe that it is important to understand what are the capabilities in terms of distributed operation of main mobility solutions. This paves the way for the actual gap analysis performed in Section 3. > In the gap analysis itself (paragraph 3), for example, I found difficult = to understand what is missing in term of functionalities. For example in 3.= 1.1 you say that REQ1 is not satisfied by MIP6, but you are not saying what= is missing. You said that in 2.1.1: "current Mobile IPv6 / NEMO specifica= tions do not allow the use of multiple home agents by a mobile node simulta= neously". We sure can improve the text, and suggestions are highly welcome and appreciated. Our rationale there is that current MIPv6/NEMO do not allow to deploy distributed home agents and then enable the mobile node to dynamically switch and benefit from using them. You can deploy multiple home agents, but the mobile node will always be associated to a single one at each moment. This is what it is missing. > > I would also have considered, for example, MIPv6 and its extensions as a = whole instead of separating each component. What we are trying to understan= d here is if we can use some existing protocols and its currently defined e= xtensions for DMM. I think it is useful to see which extension adds which f= eature but at the end of the document you should say something on a complet= e solution. Perhaps you can add some text in chapter 4 saying that a soluti= on that considers protocol x plus extension y is well suited for DMM or tha= t none of the available solutions meets all requirements. That is indeed a possible option that we also did consider. But here we thought there is a tradeoff between complexity of the text and clarity. We wanted to keep the text as simple as possible and we also fear that going into analyzing combinations of solutions might go into solution space, which is not the goal of the gap analysis. We should just find out if a DMM solution is actually required or if the DMM requirements can be met with existing solutions. > > For REQ2 (for both MIPv6 and PMIPv6) you say that the solution is transpa= rent to upper layers but in the table in paragraph 4 there is LIM (limited = support). I think this is wrong. Non optimal routing is already considered = in REQ1 and should not be part of REQ2. It is true that this is not clear in this version. In the table we wanted to highlight that even though MIPv6 and PMIPv6 are transparent to upper layers, its use deploying multiple home agents/local mobility anchors and trying to benefit from that "distributed" mode is not, as it requires to change the home address. Maybe we can clarify this in regards of the requirements and then update the table accordingly. Thanks again for the comments. Carlos > > Regards, > Elena > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p= ersone indicate. La diffusione, copia o qualsiasi altra azione derivante da= lla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di d= arne immediata comunicazione al mittente e di provvedere alla sua distruzio= ne, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d information intended for the addressee(s) only. Dissemination, copying, p= rinting or use by anybody else is unauthorised. If you are not the intended= recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks. > -- Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 -- Carlos Jes=FAs Bernardos Cano Universidad Carlos III de Madrid= From karagian@cs.utwente.nl Sun Nov 4 11:52:39 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7677821F878E for ; Sun, 4 Nov 2012 11:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdnOWU7vuHgx for ; Sun, 4 Nov 2012 11:52:39 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEB421F8785 for ; Sun, 4 Nov 2012 11:52:38 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 20:52:38 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 20:52:37 +0100 From: To: , Thread-Topic: [DMM] New Version Notification for draft-sarikaya-dmm-cloud-mm-00.txt Thread-Index: AQHNsVfXfrmroOJGJkmh7gTfKcTOL5faJwDR Date: Sun, 4 Nov 2012 19:52:35 +0000 Message-ID: References: <20121015214138.23791.80051.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] New Version Notification for draft-sarikaya-dmm-cloud-mm-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:52:39 -0000 Hi Behcet, I would like to mention that I find this draft useful due to the following = reasons. Currently, there is a trend to implement more and more functions of a mobil= e communication network in software, e.g., for signal and protocol processi= ng. This enables the use of cloud computing infrastructures as processing p= latforms for signal and protocol processing of mobile communication network= s, in particular for current (4G) and future (5G) generation cellular netwo= rks.=20 This can of course only be realized if, among others, efficient mobility ma= nagement solutions are supported like the ones that are in line with what D= MM would like to specify.=20 I think therefore, that the DMM WG could also consider the distributed mobi= lity management support in cloud computing like architectures as a possible= use case. Regarding your draft I have some comments: The draft mentions some limitation of the existing mobility management solu= tions in cloud-like architectures. However, these limitations are not clear= ly focussing on the requirements specified in http://www.ietf.org/id/draft-= ietf-dmm-requirements-02.txt.=20 I think that this will make the desciption of the limitations clearer! Moreover, it might also be useful to show describe these limitations by usi= ng as use as context a generic framework, like the one introduced in http:/= /www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and/or=20 http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt. Best regards, Georgios ________________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikaya [sa= rikaya2012@gmail.com] Verzonden: dinsdag 23 oktober 2012 21:51 To: dmm@ietf.org Onderwerp: [DMM] New Version Notification for draft-sarikaya-dmm-cloud-mm= -00.txt Hi all, I have submitted a new draft on Mobility Management Protocols for Cloud-Like Architectures, for details see below. Chairs: please reserve a slot in IETF 85 session if possible. Regards, Behcet A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-dmm-cloud-mm Revision: 00 Title: Mobility Management Protocols for Cloud-Like Architectures Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud-m= m Htmlized: http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-00 Abstract: Telecommunication networks are being virtualized and are moving into the cloud networks. This brings the need to redesign the mobility protocols of Mobile and Proxy Mobile IPv6. This document defines mobility management protocols for virtualized networks. Control and data plane separation is achieved by separating Home Agent and Mobile Access Gateway functionalities into the control and data planes. The IETF Secretariat _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm= From karagian@cs.utwente.nl Sun Nov 4 12:02:35 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9DC21F8841 for ; Sun, 4 Nov 2012 12:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqFLRJ6WxM4a for ; Sun, 4 Nov 2012 12:02:34 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id BE37521F8804 for ; Sun, 4 Nov 2012 12:02:33 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 21:02:33 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 21:02:31 +0100 From: To: , Thread-Topic: DMM functional framework posted Thread-Index: Ac2rtkYqUHMX3R8lT2GK/zx0O/gz3QPEEFH+ Date: Sun, 4 Nov 2012 20:02:30 +0000 Message-ID: References: <69756203DDDDE64E987BC4F70B71A26D55135B39@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D55135B39@DAPHNIS.office.hd> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] DMM functional framework posted X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:02:35 -0000 Hi Marco, I have read this draft and I think that it is useful for the DMM WG. Howeve= r, I have some comments: 1) Can you please emphasize which approach have you followed in order to de= rive the functional entities that are described in Section 3. One could der= ive other FEs than the ones mentioned in Section 3. 2) What are the main differences between the framework that you propose in = this draft and the one proposed in: framework, like the one introduced in h= ttp://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt. Best regards, Georgios ________________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Marco Liebsch [Marc= o.Liebsch@neclab.eu] Verzonden: dinsdag 16 oktober 2012 18:04 To: dmm@ietf.org Onderwerp: [DMM] DMM functional framework posted As follow up of a discussion during last IETF meeting with some of you, we= posted a new draft about an initial functional framework for DMM. We think that discussing BCP and gaps can be supported by using well defined functional e= ntities (FE) and reference points to enable DMM. Different constellations of FEs can mat= ch architectures of existing protocols and gaps as well as strengths or weak points of the a= ssociated architecture/protocol can be easily identified. The current version provides a basic set of FEs and interfaces and depicts = two key models as starting point to group FEs according to the WG's current und= erstanding how DMM may be solved. Any opinion about the proposed framework and approach as well as contributi= ons to an updated version of this draft are appreciated. Marco -- A new version of I-D, draft-liebsch-dmm-framework-analysis-00.txt has been successfully submitted by Marco Liebsch and posted to the IETF rep= ository. Filename: draft-liebsch-dmm-framework-analysis Revision: 00 Title: Distributed Mobility Management - Framework & Analysis Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-liebsch-dmm-fram= ework-analysis-00.txt Status: http://datatracker.ietf.org/doc/draft-liebsch-dmm-framewor= k-analysis Htmlized: http://tools.ietf.org/html/draft-liebsch-dmm-framework-ana= lysis-00 Abstract: Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. The Distributed Mobility Management (DMM) Working Group is investigating the impact of decentralized mobility management to existing protocol solutions, while taking into account well defined requirements, which are to be met by a future solution. This document discusses DMM using a functional framework. Functional Entities to support DMM as well as reference points between these Functional Entities are introduced and described. The described functional framework allows distribution and co-location of Functional Entities and build a DMM architecture that matches the architecture of available protocols. Such methodology eases the analysis of best current practices with regard to functional and protocol gaps. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm= From Marco.Liebsch@neclab.eu Sun Nov 4 14:31:52 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2389821F8788 for ; Sun, 4 Nov 2012 14:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDiI4u2Zfhhn for ; Sun, 4 Nov 2012 14:31:51 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id EF3EA21F8785 for ; Sun, 4 Nov 2012 14:31:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5C32B102407; Sun, 4 Nov 2012 23:31:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJIR1mk5lnt1; Sun, 4 Nov 2012 23:31:50 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 3C22B10229C; Sun, 4 Nov 2012 23:31:40 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Sun, 4 Nov 2012 23:30:39 +0100 From: Marco Liebsch To: "karagian@cs.utwente.nl" , "dmm@ietf.org" Thread-Topic: DMM functional framework posted Thread-Index: Ac2rtkYqUHMX3R8lT2GK/zx0O/gz3QPEEFH+AAPJ97A= Date: Sun, 4 Nov 2012 22:30:39 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D5513C865@DAPHNIS.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D55135B39@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] DMM functional framework posted X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 22:31:52 -0000 Hi Georgios, thanks for your comments. Please see inline for my response. >-----Original Message----- >From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >Sent: Sonntag, 4. November 2012 21:02 >To: Marco Liebsch; dmm@ietf.org >Subject: RE: DMM functional framework posted > >Hi Marco, > >I have read this draft and I think that it is useful for the DMM WG. Howev= er, I >have some comments: > >1) Can you please emphasize which approach have you followed in order to >derive the functional entities that are described in Section 3. One could = derive >other FEs than the ones mentioned in Section 3. The approach is to assume a mobility anchor/gateway and add functional entities to enable DMM without taking assumptions on the mobility protocol. Hence, it does not take assumptions on mobility protocol dependency. As soon as a suitable set of functional entities is defined, we can take mo= bility protocols (MIP6, PMIP6), either with or without extension protocols, such a= s runtime LMA redirection. Then the DMM functional entities can be placed to the associated architecture in different ways, either collocated with mobil= ity components or other components, e.g. provided by the transport network, and we can analyze if a function is implicitly supported by the mobility protoc= ol or needs a further extension or support from an external protocol. Latter point is still important, IMHO, I still think DMM should be enabled = by looking for support from other protocols outside the IP-mobility protocol space.=20 > >2) What are the main differences between the framework that you propose in >this draft and the one proposed in: framework, like the one introduced in >http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt. The main difference is that it defines DMM functional entities without bein= g dependent on functions of available IP mobility architecture. We discussed such frame= work during last IETF and came to the conclusion that such framework is useful=20 for the gap analysis and the specification of protocol extensions without b= eing Dependent on mobility protocols.=20 =20 I received some feedback to version -00 about further separation of defined functional entities into control- and data-plane, which can help to apply t= he DMM functional elements to available components of Mobile IP, Proxy Mobile IPv6, LISP on top of a Mobile IP architecture or even an OpenFlow-based arc= hitecture in the mobile carrier's transport network. The draft is simply the way of communicating the approach of using these fu= nctional elements for the analysis and the specification of protocol extensions to e= nable DMM. It's not meant as further competing gap analysis draft :-) But it reflects = what I could discuss with some DMM folks and hopefully supports the discussion about DMM while t= ackling the associated complexity behind this topic. marco > >Best regards, >Georgios > >________________________________________ >Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Marco Liebsch >[Marco.Liebsch@neclab.eu] >Verzonden: dinsdag 16 oktober 2012 18:04 >To: dmm@ietf.org >Onderwerp: [DMM] DMM functional framework posted > >As follow up of a discussion during last IETF meeting with some of you, w= e >posted a new draft about an initial functional framework for DMM. We think >that discussing BCP and gaps can be supported by using well defined functi= onal >entities (FE) and reference points to enable DMM. Different constellations= of FEs >can match architectures of existing protocols and gaps as well as strength= s or >weak points of the associated architecture/protocol can be easily identifi= ed. > >The current version provides a basic set of FEs and interfaces and depicts= two >key models as starting point to group FEs according to the WG's current >understanding how DMM may be solved. > >Any opinion about the proposed framework and approach as well as >contributions to an updated version of this draft are appreciated. > >Marco > >-- >A new version of I-D, draft-liebsch-dmm-framework-analysis-00.txt >has been successfully submitted by Marco Liebsch and posted to the IETF >repository. > >Filename: draft-liebsch-dmm-framework-analysis >Revision: 00 >Title: Distributed Mobility Management - Framework & Analysis >Creation date: 2012-10-15 >WG ID: Individual Submission >Number of pages: 16 >URL: http://www.ietf.org/internet-drafts/draft-liebsch-dmm-fra= mework- >analysis-00.txt >Status: http://datatracker.ietf.org/doc/draft-liebsch-dmm-framewo= rk- >analysis >Htmlized: http://tools.ietf.org/html/draft-liebsch-dmm-framework-an= alysis- >00 > > >Abstract: > Mobile operators consider the distribution of mobility anchors to > enable offloading some traffic from their core network. The > Distributed Mobility Management (DMM) Working Group is investigating > the impact of decentralized mobility management to existing protocol > solutions, while taking into account well defined requirements, which > are to be met by a future solution. This document discusses DMM > using a functional framework. Functional Entities to support DMM as > well as reference points between these Functional Entities are > introduced and described. The described functional framework allows > distribution and co-location of Functional Entities and build a DMM > architecture that matches the architecture of available protocols. > Such methodology eases the analysis of best current practices with > regard to functional and protocol gaps. > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Mon Nov 5 06:06:32 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D217521F86F6 for ; Mon, 5 Nov 2012 06:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PV4eMgZtxWf for ; Mon, 5 Nov 2012 06:06:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC221F84D1 for ; Mon, 5 Nov 2012 06:06:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALF85017; Mon, 05 Nov 2012 14:06:22 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 14:06:13 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 14:06:17 +0000 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.141]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 5 Nov 2012 22:06:14 +0800 From: h chan To: "karagian@cs.utwente.nl" Thread-Topic: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis Thread-Index: AQHNcYKokxa/5YVnAE2oihPhzNSmY5fb1nGQ Date: Mon, 5 Nov 2012 14:06:13 +0000 Message-ID: <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.194] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C284130CDSZXEML510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:06:33 -0000 --_000_6E31144C030982429702B11D6746B98C284130CDSZXEML510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georgios, The framework is only at a high level. As we go deeper, granularity will ar= ise. I thought these mobility management signaling are mainly in the control pla= ne. When you say separation into control path and data path, do you mean th= e signaling and the data traffic can take different paths? H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of karag= ian@cs.utwente.nl Sent: Friday, August 03, 2012 10:17 AM To: h chan Cc: dmm@ietf.org Subject: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-ana= lysis Hi Anthony, I have read the draft-chan-dmm-framework-gap-analysis-02.txt. The DMM framework part description is useful. However, I have a comment! The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities. I think that the DMM framework should provide this distinction, since funct= ions/entities that are supporting the control path may not be collocated wi= th functions/entities that are supporting the data path. This comment is in my opinion valid for both: (1) mobility routing (MR) fun= ction/entity and (2) internetwork location management (LM) function/entity. This could mean that: The MR function/entity can be divided in: MRC (Mobility Routing Control path) function/entity MRD (Mobility Routing Data path) function/entity The LM function can be divided in: LMC (internetwork Location Management Control path) function/entity LMD (internetwork Location Management Data path) function/entity Best regards, Georgios --_000_6E31144C030982429702B11D6746B98C284130CDSZXEML510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Georgios,

The framework is only at = a high level. As we go deeper, granularity will arise.

I thought these mobility = management signaling are mainly in the control plane. When you say separati= on into control path and data path, do you mean the signaling and the data traffic can take different paths?

 <= /p>

H Anthony Chan=

 <= /p>

From: dmm-boun= ces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Friday, August 03, 2012 10:17 AM
To: h chan
Cc: dmm@ietf.org
Subject: [DMM] regarding DMM framework and draft-chan-dmm-framework-= gap-analysis

 

Hi Anthony,

 

I have read the draft-chan-dmm-framework-gap-ana= lysis-02.txt.

 

The DMM framework part description is useful. Ho= wever, I have a comment!
The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities.

 

I think that the DMM framework should provide th= is distinction, since functions/entities that are supporting the control pa= th may not be collocated with functions/entities that are supporting the data path.

 

This comment is in my opinion valid for both: (1= ) mobility routing (MR) function/entity and (2) internetwork location manag= ement (LM) function/entity. 

 

This could mean that:

 

The MR function/entity can be divided in:
MRC (Mobility Routing Control path) function/entity
MRD (Mobility Routing Data path) function/entity

 

The LM function can be divided in:
LMC (internetwork Location Management Control path) function/entity
LMD (internetwork Location Management Data path) function/entity=

 

Best regards,
Georgios

--_000_6E31144C030982429702B11D6746B98C284130CDSZXEML510MBXchi_-- From karagian@cs.utwente.nl Mon Nov 5 10:30:15 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828D321F87E0 for ; Mon, 5 Nov 2012 10:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cJBIpN5E7gc for ; Mon, 5 Nov 2012 10:30:15 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D121F87D0 for ; Mon, 5 Nov 2012 10:30:05 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 5 Nov 2012 19:30:09 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.76]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 19:30:05 +0100 From: To: Thread-Topic: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis Thread-Index: AQHNu168vCnpQ4XQ4USyKuDSlnqJdJfbj6fq Date: Mon, 5 Nov 2012 18:30:04 +0000 Message-ID: References: , <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC17A63EXMBX04adutwent_" MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:30:15 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC17A63EXMBX04adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anthony, Regarding your question, yes, the framework should allow the possibility th= at data traffic and signaling take different paths! Best regards, Georgios ________________________________ Van: h chan [h.anthony.chan@huawei.com] Verzonden: maandag 5 november 2012 15:06 To: Karagiannis, G. (EWI) Cc: dmm@ietf.org Onderwerp: RE: [DMM] regarding DMM framework and draft-chan-dmm-framework-g= ap-analysis Georgios, The framework is only at a high level. As we go deeper, granularity will ar= ise. I thought these mobility management signaling are mainly in the control pla= ne. When you say separation into control path and data path, do you mean th= e signaling and the data traffic can take different paths? H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of karag= ian@cs.utwente.nl Sent: Friday, August 03, 2012 10:17 AM To: h chan Cc: dmm@ietf.org Subject: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-ana= lysis Hi Anthony, I have read the draft-chan-dmm-framework-gap-analysis-02.txt. The DMM framework part description is useful. However, I have a comment! The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities. I think that the DMM framework should provide this distinction, since funct= ions/entities that are supporting the control path may not be collocated wi= th functions/entities that are supporting the data path. This comment is in my opinion valid for both: (1) mobility routing (MR) fun= ction/entity and (2) internetwork location management (LM) function/entity. This could mean that: The MR function/entity can be divided in: MRC (Mobility Routing Control path) function/entity MRD (Mobility Routing Data path) function/entity The LM function can be divided in: LMC (internetwork Location Management Control path) function/entity LMD (internetwork Location Management Data path) function/entity Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC17A63EXMBX04adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Anthony,

 

Regarding your question, yes, the framework should allow the possibility= that data traffic and signaling take different paths!

 

Best regards,

Georgios

Van: h chan [h.anthony.chan@huawei.com] Verzonden: maandag 5 november 2012 15:06
To: Karagiannis, G. (EWI)
Cc: dmm@ietf.org
Onderwerp: RE: [DMM] regarding DMM framework and draft-chan-dmm-fram= ework-gap-analysis

Georgios,

The framework is only at a high level. As = we go deeper, granularity will arise.

I thought these mobility management signal= ing are mainly in the control plane. When you say separation into control p= ath and data path, do you mean the signaling and the data traffic can take different paths?

 

H Anthony Chan

 

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.= org] On Behalf Of karagian@cs.utwente.nl
Sent: Friday, August 03, 2012 10:17 AM
To: h chan
Cc: dmm@ietf.org
Subject: [DMM] regarding DMM framework and draft-chan-dmm-framework-= gap-analysis

 

Hi Anthony,

 

I have read the draft-chan-dmm-framework-gap-analysis-02.txt.

 

The DMM framework part description is useful. However, I have a c= omment!
The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities.

 

I think that the DMM framework should provide this distinction, s= ince functions/entities that are supporting the control path may not be col= located with functions/entities that are supporting the data path.

 

This comment is in my opinion valid for both: (1) mobility routin= g (MR) function/entity and (2) internetwork location management (LM) functi= on/entity. 

 

This could mean that:

 

The MR function/entity can be divided in:
MRC (Mobility Routing Control path) function/entity
MRD (Mobility Routing Data path) function/entity

 

The LM function can be divided in:
LMC (internetwork Location Management Control path) function/entity
LMD (internetwork Location Management Data path) function/entity

 

Best regards,
Georgios

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC17A63EXMBX04adutwent_-- From jonghyouk@gmail.com Tue Nov 6 04:52:22 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8521F88E0 for ; Tue, 6 Nov 2012 04:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITH1sf6arsFm for ; Tue, 6 Nov 2012 04:52:21 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3521F88A3 for ; Tue, 6 Nov 2012 04:52:21 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so291443iak.31 for ; Tue, 06 Nov 2012 04:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6LDRwqUOgvuV6FkXohB7iWSY3uwI5Ap5YsoPHdHCtfc=; b=wsAq6u+Pd75NWdSye91ja3spO8oRchPzEyFPk7a/m+QiFceLc9BbGumkkf/hYQv2k/ 5YKRFqUoCM9nxr2wu1Znd/VeJTb2w7oDp+WCKFNF93gdgkT8755+C1crs5TUSQuoVQSw dJRJXXA7HF8pKqcu2G4V7I7TrcY66PVfHSik/WpFou278n4xbsPl2n3HY/HbmoU4xkFH j9HI3maFcXONqZPxymDIINGVQ/UIqnvKI3IwPcvsFXrG9I/DEA6GKM/SIBoHbx66I1Vo Oei8HA97dc517X7LmTZQRC/jg/JVx2++eK2DuVWssJDMGDZSkBQMdEvFc2IngZQZh35v co6A== MIME-Version: 1.0 Received: by 10.50.184.232 with SMTP id ex8mr12593056igc.30.1352206340905; Tue, 06 Nov 2012 04:52:20 -0800 (PST) Received: by 10.64.0.34 with HTTP; Tue, 6 Nov 2012 04:52:20 -0800 (PST) In-Reply-To: References: <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com> Date: Tue, 6 Nov 2012 13:52:20 +0100 Message-ID: From: Jong-Hyouk Lee To: karagian@cs.utwente.nl Content-Type: multipart/alternative; boundary=14dae9340ef19cdbeb04cdd31296 Cc: dmm@ietf.org Subject: Re: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 12:52:22 -0000 --14dae9340ef19cdbeb04cdd31296 Content-Type: text/plain; charset=UTF-8 Georgios, We will consider that at the next version of http://tools.ietf.org/html/draft-chan-dmm-framework-gap-analysis Thanks for this comment. On Mon, Nov 5, 2012 at 7:30 PM, wrote: > Hi Anthony, > > > > Regarding your question, yes, the framework should allow the possibility > that data traffic and signaling take different paths! > > > > Best regards, > > Georgios > ------------------------------ > *Van:* h chan [h.anthony.chan@huawei.com] > *Verzonden:* maandag 5 november 2012 15:06 > *To:* Karagiannis, G. (EWI) > *Cc:* dmm@ietf.org > *Onderwerp:* RE: [DMM] regarding DMM framework and > draft-chan-dmm-framework-gap-analysis > > Georgios, > > The framework is only at a high level. As we go deeper, granularity will > arise. > > I thought these mobility management signaling are mainly in the control > plane. When you say separation into control path and data path, do you mean > the signaling and the data traffic can take different paths? > > > > H Anthony Chan > > > > *From:* dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] *On Behalf Of * > karagian@cs.utwente.nl > *Sent:* Friday, August 03, 2012 10:17 AM > *To:* h chan > *Cc:* dmm@ietf.org > *Subject:* [DMM] regarding DMM framework and > draft-chan-dmm-framework-gap-analysis > > > > Hi Anthony, > > > > I have read the draft-chan-dmm-framework-gap-analysis-02.txt. > > > > The DMM framework part description is useful. However, I have a comment! > The current provided DMM framework is not making any distinction between > control path and data path related functions/entities. > > > > I think that the DMM framework should provide this distinction, since > functions/entities that are supporting the control path may not be > collocated with functions/entities that are supporting the data path. > > > > This comment is in my opinion valid for both: (1) mobility routing (MR) > function/entity and (2) internetwork location management (LM) > function/entity. > > > > This could mean that: > > > > The MR function/entity can be divided in: > MRC (Mobility Routing Control path) function/entity > MRD (Mobility Routing Data path) function/entity > > > > The LM function can be divided in: > LMC (internetwork Location Management Control path) function/entity > LMD (internetwork Location Management Data path) function/entity > > > > Best regards, > Georgios > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --14dae9340ef19cdbeb04cdd31296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Georgios,

We will consider that at the next version of= =C2=A0http://tools.ietf.org/html/draft-chan-dmm-framework-gap-analysis=C2=A0

Thanks for this comment.

On Mon, Nov 5, 2012 at 7:30 PM, <karagian@cs.utwente.nl= > wrote:

Hi Anthony,

=C2=A0

Regarding your question, yes, the framework should allow the possibility= that data traffic and signaling take different paths!

=C2=A0

Best regards,

Georgios

Van= : h chan [h.anthony.chan@huawei.com]
Verzonden: maandag 5 november 2012 15:06
To: Karagiannis, G. (EWI)
Cc: dmm@ietf.org
Onderwerp: RE: [DMM] regarding DMM framework and draft-chan-dmm-fram= ework-gap-analysis

Georgios,

The framework is only at a high= level. As we go deeper, granularity will arise.

I thought these mobility manage= ment signaling are mainly in the control plane. When you say separation int= o control path and data path, do you mean the signaling and the data traffic can take different paths?

=C2=A0

H Anthony Chan

=C2=A0

=C2=A0

Hi Anthony,

=C2=A0

I have read the draft-chan-dmm-framework-gap-analysis-02.txt.

=C2=A0

The DMM framework part description is useful. However, I have a co= mment!
The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities.

=C2=A0

I think that the DMM framework should provide this distinction, si= nce functions/entities that are supporting the control path may not be coll= ocated with functions/entities that are supporting the data path.

=C2=A0

This comment is in my opinion valid for both: (1) mobility routing= (MR) function/entity and (2) internetwork location management (LM) functio= n/entity.=C2=A0

=C2=A0

This could mean that:

=C2=A0

The MR function/entity can be divided in:
MRC (Mobility Routing Control path) function/entity
MRD (Mobility Routing Data path) function/entity

=C2=A0

The LM function can be divided in:
LMC (internetwork Location Management Control path) function/entity
LMD (internetwork Location Management Data path) function/entity

=C2=A0

Best regards,
Georgios


_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm




--
RSM= Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living some= where between /dev/null and /dev/random

#email:=C2= =A0jonghyouk (at) gmail (dot) com

--14dae9340ef19cdbeb04cdd31296-- From Peter.McCann@huawei.com Wed Nov 7 10:54:11 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D844121F8A59 for ; Wed, 7 Nov 2012 10:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC90qjYbIXNC for ; Wed, 7 Nov 2012 10:54:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 56BDC21F8957 for ; Wed, 7 Nov 2012 10:53:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALH92183; Wed, 07 Nov 2012 18:53:51 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 18:53:36 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 18:53:47 +0000 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.159]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 10:53:44 -0800 From: Peter McCann To: "dmm@ietf.org" Thread-Topic: Comments on draft-zuniga-dmm-gap-analysis-02 Thread-Index: Ac29GTcpiQIMSWRjRwCP766sJm6b9g== Date: Wed, 7 Nov 2012 18:53:43 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E554F9@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] Comments on draft-zuniga-dmm-gap-analysis-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:54:12 -0000 Section 2.1.1 states: "current Mobile IPv6 / NEMO specifications do not allow the use of multiple home agents by a mobile node simultaneously" What exactly is the technical limitation prohibiting this simultaneous use? As I understand it, there is no problem running two simultaneous home addresses each of which can be bound to the same care-of address. Section 2.1.4 suggests that the Home Agent switch can be used to trigger a change of HA when there are no ongoing sessions that need address continuity. How is the HA supposed to determine that this condition holds? The knowledge about ongoing sessions is inside the MN. Section 2.1.5 talks about flow mobility but the relationship to DMM is not clear. Section 2.2:=20 "Service Data Gateway (SGW)" I think this should be "Serving Data Gateway". Also, you should talk about the tunnel between eNB and SGW. DMM will have the most impact=20 if we can replace those tunneling protocols too. Section 2.2.1: "On the other hand, as soon as the mobile node moves, the resulting path starts to deviate from the optimal one." You should note that this situation may be acceptable as long as the session is short-lived, and a new address is used for new sessions. Section 2.2.2 compares X2 to the PMIP local routing. I don't think=20 this is a good comparison. X2 is used to forward traffic for a single mobile node between a previous and new eNB. In contrast, the local routing solutions are about routing traffic between two different MNs. Section 2.2.3, you state that SIPTO has no mechanism for seamless session continuity if you move out of the coverage area of a local PGW. But really, there is no technical reason why you couldn't open up a GTP tunnel to the old PGW from the new network. Note also there is a double negative in the last sentence of Section 2.2.3: "cannot not survive". The draft seems to consider existing protocols only in isolation; however, I think there is something to be gained by considering combinations of the existing protocols. For example, a network-based mobility solution could be used for localized mobility management within a given domain (where the sub-optimality would be somewhat limited) and then a client-based mobility solution could be used for handling mobility outside of this domain. If a network-based mobility scheme is used to handle the client-based Care-of Address, then most of the disadvantages of the client-based mobility scheme (frequent updates over-the-air to the HA) disappear. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA From Peter.McCann@huawei.com Wed Nov 7 11:40:56 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50E21F8C21 for ; Wed, 7 Nov 2012 11:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwrxiBOep1Bz for ; Wed, 7 Nov 2012 11:40:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4221F8AAD for ; Wed, 7 Nov 2012 11:40:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMN12627; Wed, 07 Nov 2012 19:40:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 19:40:42 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 19:40:51 +0000 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.159]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 11:40:47 -0800 From: Peter McCann To: "dmm@ietf.org" Thread-Topic: Comments on draft-liebsch-dmm-framework-analysis-00 Thread-Index: Ac29H8mOiU7yIlrkRtKAICgO6UHwIw== Date: Wed, 7 Nov 2012 19:40:46 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E5556C@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:40:56 -0000 Let me ask a question to make sure I understand the approach this document takes to analyzing the problem space. In the Introduction, you state: "The initial version of this draft introduces a basic set of FEs and interfaces between these FEs to support IP address continuity in DMM, without being specific to the used mobility management protocol, which operates below the mobility anchor." And later, you introduce the FE_MA to represent this mobility anchor. I *think* you are trying to define DMM as something that runs above another mobility management protocol. Would it be legal to set the FE_MA equal to the access router, and the other mobility management protocol to NULL? That is, would it be allowed in your framework to use *only* the DMM protocol to get packets to an AR, to which the MN is currently attached? Section 3 states: "Imported HoA/HNP of a mobile node will be treated as identifier and non-routable IP address (prefix), as it probably does not match the new mobility anchor's location in the topology." I disagree. The old address (prefix) will need to be routable at least inside the new anchor point. If this anchor point is directly connected to the MN (i.e., it is the AR) then the route will be to a local link address. If this new anchor point uses a tunnel to get the packets to=20 the MN, then the old address will be routable to the tunnel interface. =20 Elsewhere in Section 3: "Forwarding can be for example accomplished by an IP tunnel to the egress function, address translation to a routable IP address or other means." I hope that "other means" can include installing an actual route for the destination IP on routers between the ingress and egress. I'd be happy to provide a diagram and text to show how draft-mccann-dmm-fla= tarch can fit into this functional framework. In the language of your draft, I think that the FE_MAs are integrated with the ARs, the FE_MCTX is the DNS server that stores the UE's current address, FE_E is co-located on the currently serving AR, and FE_I and FE_IEC are made up of a distributed netw= ork of routers running BGP (there is no single point of failure for FE_I). -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA From Marco.Liebsch@neclab.eu Wed Nov 7 15:27:10 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AF821F8B7A for ; Wed, 7 Nov 2012 15:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJQGJ2gW1A3L for ; Wed, 7 Nov 2012 15:27:05 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 98DFA21F8B7E for ; Wed, 7 Nov 2012 15:27:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D952910245B; Thu, 8 Nov 2012 00:27:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAPXX1OL26Y0; Thu, 8 Nov 2012 00:27:03 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BDCD3102451; Thu, 8 Nov 2012 00:26:53 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 00:26:32 +0100 From: Marco Liebsch To: Peter McCann , "dmm@ietf.org" Thread-Topic: Comments on draft-liebsch-dmm-framework-analysis-00 Thread-Index: Ac29H8mOiU7yIlrkRtKAICgO6UHwIwAHRBfQ Date: Wed, 7 Nov 2012 23:26:16 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D5513EEF1@DAPHNIS.office.hd> References: <5963DDF1F751474D8DEEFDCDBEE43AE716E5556C@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E5556C@dfweml512-mbx.china.huawei.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:27:10 -0000 Hi Pete, please see inline for my response. >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >Peter McCann >Sent: Mittwoch, 7. November 2012 20:41 >To: dmm@ietf.org >Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 > >Let me ask a question to make sure I understand the approach this document >takes to analyzing the problem space. In the Introduction, you state: > "The initial version of this draft introduces a basic set of FEs and > interfaces between these FEs to support IP address continuity in DMM, > without being specific to the used mobility management protocol, > which operates below the mobility anchor." >And later, you introduce the FE_MA to represent this mobility anchor. >I *think* you are trying to define DMM as something that runs above anothe= r >mobility management protocol. That would imply a solution and that is not intended. The four defined DMM = FEs can be mapped to components of existing protocols. My intention is to defin= e DMM FEs, which enable DMM use cases but are not dependent on a mobility protocol. So, some functions can be applied to existing components of, say, iBGP in a route reflector, or a LISP resolver. But some components can be placed on a Mobile IP Home Agent or even a Mobile Node. Then we can analyze if the function of the DMM FE is implicitly supported by the existing protocol or if an extension is needed. That's the rationale behind= these FEs.=20 The FE_MA is mentioned as existing component and assumed as topological anc= hor of the MN's IP address. Some or all DMM FEs may apply to the existing MA. D= epends on the analysis we want to perform. > Would it be legal to set the FE_MA equal to the >access router, and the other mobility management protocol to NULL? That i= s, >would it be allowed in your framework to use *only* the DMM protocol to ge= t >packets to an AR, to which the MN is currently attached? Yes, legal from my perspective :-) > > >Section 3 states: > "Imported HoA/HNP > of a mobile node will be treated as identifier and non-routable IP > address (prefix), as it probably does not match the new mobility > anchor's location in the topology." >I disagree. The old address (prefix) will need to be routable at least in= side the >new anchor point. If this anchor point is directly connected to the MN (i= .e., it is >the AR) then the route will be to a local link address. If this new ancho= r point >uses a tunnel to get the packets to the MN, then the old address will be r= outable >to the tunnel interface. The assumption is of course that below a mobility anchor (FE_MA) the mobili= ty protocol performs location tracking and tunnel management or whatever. The defined DMM FEs enable the required level of indirection above or at th= e mobility anchor.=20 > >Elsewhere in Section 3: > "Forwarding can be for example accomplished by an IP tunnel to the > egress function, address translation to a routable IP address or > other means." >I hope that "other means" can include installing an actual route for the >destination IP on routers between the ingress and egress. Yes. > >I'd be happy to provide a diagram and text to show how draft-mccann-dmm- >flatarch can fit into this functional framework. In the language of your = draft, I >think that the FE_MAs are integrated with the ARs, the FE_MCTX is the DNS >server that stores the UE's current address, FE_E is co-located on the cur= rently >serving AR, and FE_I and FE_IEC are made up of a distributed network of ro= uters >running BGP (there is no single point of failure for FE_I). I have that picture in mind, just lack of time caused mapping examples to be weak in version 00. I received other feedback and version 01 is actually there. I'd be happy if you contribute to the draft with our picture and text. By the way, the main motivation of the DMM FEs was to allow analysis beyond mobility protocols, hence including your solution proposal. I see the iBGP solution as hop-by-hop solution where each transport network router gets a per-host state when indirection is required. Each iBGP router hence implements an FE_I and FE_E at the same time. But let's discuss details tomorrow. marco > >-- >Peter J. McCann >Huawei Technologies (USA) >Peter.McCann@Huawei.com >+1 908 541 3563 >Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 = USA > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From Marco.Liebsch@neclab.eu Wed Nov 7 17:56:13 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1FA21F89FE for ; Wed, 7 Nov 2012 17:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qgSOktcuwEs for ; Wed, 7 Nov 2012 17:56:12 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3957D21F89B5 for ; Wed, 7 Nov 2012 17:56:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8FCC410249D for ; Thu, 8 Nov 2012 02:56:11 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3RGsSCDpyaO for ; Thu, 8 Nov 2012 02:56:11 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 77B4110249B for ; Thu, 8 Nov 2012 02:56:06 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 02:55:45 +0100 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: comments about draft-zuniga-dmm-gap-analysis Thread-Index: Ac29UxYrkP4zYiy2QSG2Md0egzcYtg== Date: Thu, 8 Nov 2012 01:55:29 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D5513F0D6@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [DMM] comments about draft-zuniga-dmm-gap-analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 01:56:13 -0000 Please find some comments about version 2 of draft-zuniga-dmm-gap-analysis = below. General comments: I think the draft addresses a good set of available mobility protocols, eve= n though I still believe that support from non-mobility protocols should be considered to solve DMM. Maybe protocols for anchor selection and reselection should be included to = the analysis? Depends on whether the selection of anchors during initial attach and relocation of= a mobility anchor is in scope of the solution to be specified. I think it's very valuable to analyze how each protocol can contribute to D= MM and the draft matches the available protocol components against the defined requirements.= What's not clear from the chosen bottom-up approach is whether such contribution is needed i= n a solution and how the contribution fits into the overall DMM scenario. The WG never conve= rged on any design constraints and design goals so far. That's a major weak point, IMHO= . I think we need to go bottom-up as well as top-down. On the very top, we may agree and def= ine design constraints and the associated scenarios (role of the MN in DMM; capability to handle m= ultiple IP addresses, one for continued use after anchor relocation, another one, which is topolo= gically correct at the MN's current anchor). Maybe such design constraints can be anchored in the = requirements draft. Some concrete comments: Why does the draft refer sometimes to 3GPP analogies, e.g. in Sect. 2.2.2? = Is it to x-check applicability in the evolved packet core? Well, personally I think it makes sense to cons= ider hooks to the DMM solution to enable inter-working with and support from external components.= But this is not really related to the analysis of gaps with available IP mobility protocols= . Section 3.1.2, HA switch Isn't it a gap to enable IP address continuity at the relocated HA? So, MIP= v6 could provide means for the MN to convey HoA context from the previous HA. An appropriate exten= sion to MIPv6 could close that gap. Correct? Such information may be provided with the an= alysis draft as well. Section 3.1.6, LMA runtime assignment The draft says '..not clear how the technology can be used to achieve DMM..= ' well, the document should go beyond a suitability analysis. From the spec of LMA runtime assig= nment I understand that it's meant to be used solely at the MN's attach. So a loaded LMA can r= efer to a different one. A gap is to perform the operation at any time. Further gap is that it'= s the current anchor that initiates relocation. Maybe not a gap, but at least a limitation. Anot= her gap, since out of scope of the specification, is the transfer of registration context between LMAs.= =20 The analysis should try to assess suitability of a protocol component to su= pport DMM and identify the functional components that need to be added to enable re-use o= f the existing protocol. Such missing functional component can be added either to the exis= ting protocol, or provided by other protocols. Section 4. I think in general it's useful to summarize all findings in a table, but in= this case I have difficulties to conclude how each protocol can find itself in the DMM solut= ion. Here, according to my opinion, a parallel top-down approach can help. Knowing abo= ut design goals and constraints, we can have a common picture of a solution in mind. Then it's easier to understand how each of these protocols contribute to th= at picture. Hope it helps. marco From h.anthony.chan@huawei.com Wed Nov 7 20:50:45 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227221F8A5C for ; Wed, 7 Nov 2012 20:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=-2.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxiMEFFVJl5o for ; Wed, 7 Nov 2012 20:50:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0C21F8A84 for ; Wed, 7 Nov 2012 20:50:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALI19899; Thu, 08 Nov 2012 04:50:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 04:50:07 +0000 Received: from SZXEML441-HUB.china.huawei.com (10.82.67.179) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 12:50:19 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.141]) by szxeml441-hub.china.huawei.com ([10.82.67.179]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 12:50:16 +0800 From: h chan To: "luo.wen@zte.com.cn" Thread-Topic: RE: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05. Thread-Index: AQHNtoOTOVYxTVj+lUe6Vn2vTFR7dZffa7tw Date: Thu, 8 Nov 2012 04:50:16 +0000 Message-ID: <6E31144C030982429702B11D6746B98C2841374F@SZXEML510-MBX.china.huawei.com> References: <6E31144C030982429702B11D6746B98C28412665@SZXEML510-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.26] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C2841374FSZXEML510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 04:50:45 -0000 --_000_6E31144C030982429702B11D6746B98C2841374FSZXEML510MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBoYXZlIGNsYXJpZmllZCB0aGUgc2VjdGlvbiBvbiBjb21wYXRpYmlsaXR5IGluIHRoZSAwNiB2 ZXJzaW9uLiBQbGVhc2UgY2hlY2suDQoNCkggQW50aG9ueSBDaGFuDQoNCkZyb206IGx1by53ZW5A enRlLmNvbS5jbiBbbWFpbHRvOmx1by53ZW5AenRlLmNvbS5jbl0NClNlbnQ6IFR1ZXNkYXksIE9j dG9iZXIgMzAsIDIwMTIgNTo0NyBBTQ0KVG86IGggY2hhbg0KQ2M6IGRtbUBpZXRmLm9yZw0KU3Vi amVjdDogtPC4tDogUkU6IFtETU1dIFNvbWUgY29tbWVudHMgb24gZHJhZnQtY2hhbi1kbW0tZnJh bWV3b3JrLWdhcC1hbmFseXNpcy0wNS4NCg0KDQpIaSBBbnRvbnkNCg0KVGhhbmtzIGZvciB5b3Vy IHJlcGx5LCBwbGVhc2Ugc2VlIGluLWxpbmUgZm9yIG1vcmUgY29tbWVudHMuDQoNCkJSDQpMdW93 ZW4NCg0KDQpoIGNoYW4gPGguYW50aG9ueS5jaGFuQGh1YXdlaS5jb20+DQoNCjIwMTIvMTAvMjUg MDU6NDUNCg0KytW8/sjLDQoNCiJsdW8ud2VuQHp0ZS5jb20uY24iIDxsdW8ud2VuQHp0ZS5jb20u Y24+DQoNCrOty80NCg0KImRtbUBpZXRmLm9yZyIgPGRtbUBpZXRmLm9yZz4NCg0K1vfM4g0KDQpS RTogW0RNTV0gU29tZSBjb21tZW50cyBvbiBkcmFmdC1jaGFuLWRtbS1mcmFtZXdvcmstZ2FwLWFu YWx5c2lzLTA1Lg0KDQoNCg0KDQoNCg0KDQpMdW93ZW4sDQoNCkxldCBtZSBmaXJzdCBleHBsYWlu IHdoYXQgd2FzIGludGVuZGVkIHRvIHNheSwgYW5kIHRoZW4gbWFrZSBjb3JyZWN0aW9ucyBhY2Nv cmRpbmdseS4NCg0KSSB0aGluayBjb21wYXRpYmlsaXR5IGluIHRoZSByZXF1aXJlbWVudCByZWZl cnMgdG8gdGhlIGZvbGxvd2luZzoNCklmIG9uZSBkZXBsb3lzIGRtbSBpbiBhIG5ldHdvcmssIGFu ZCB0aGUgbmV0d29yayBoYWQgYW4gZXhpc3RpbmcgKGNlbnRyYWxpemVkKSBtb2JpbGl0eSBtYW5h Z2VtZW50IGRlcGxveW1lbnQsIHRoZSBleGlzdGluZyBkZXBsb3ltZW50IHNob3VsZCBjb250aW51 ZSB0byB3b3JrLg0KDQpbTHVvd2VuXSBZZXMgSSBhZ3JlZS4gVGhlIGV4aXN0aW5nIGRlcGxveW1l bnQgc2hvdWxkIGNvbnRpbnVlIHRvIHdvcmsuIEJ1dCB3ZSBzaG91bGQgaWRlbnRpZnkgd2hhdCBp cyB0aGUgbWVhbmluZyB3aGVuIG9uZSBzYXlzIHRoZSAgZXhpc3RpbmcgZGVwbG95bWVudCBjYW4g Y29udGludWUgdG8gd29yay4gT25lIHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aG9zZSB0d28gZG9t YWlucyAoZG1tIGRvbWFpbiBhbmQgIGV4aXN0aW5nIGRlcGxveW1lbnQgZG9tYWluIHN1Y2ggYXMg UE1JUHY2IGRvbWFpbikgd29yayBpbmRlcGVuZGVudGx5LiBBbm90aGVyIHVuZGVyc3RhbmRpbmcg aXMgdGhhdCBtb2JpbGUgbm9kZSB3aGljaCBpcyBiZWxvbmcgdG8gZG1tIGRvbWFpbiBjYW4gYWNj ZXNzIHRoZSBuZXR3b3JrIHZpYSAgdGhlIGV4aXN0aW5nIGRlcGxveW1lbnQgZG9tYWluICggc3Vj aCBhcyBQTUlQdjYgZG9tYWluKSBpbiBhIG1hbm5lciBvZiByb2FtaW5nLiBPciBtb2JpbGUgbm9k ZSBjYW4gaGFuZG92ZXIgZnJvbSBkbW0gZG9tYWluIHRvIHRoZSBleGlzdGluZyBkZXBsb3ltZW50 IGRvbWFpbiAoIHN1Y2ggYXMgUE1JUHY2IGRvbWFpbikgc2VhbWxlc3NseSBhbmQgdmljZSB2ZXJz YS4gU28gbWF5YmUgd2Ugc2hvdWxkIG1ha2UgaXQgY2xlYXIgdGhhdCB3aGF0IGlzIHRoZSBwcmVj aXNlIG1lYW5pbmcgb2YgY29tcGF0aWJpbGl0eS4NCg0KVGhlIGFic3RyYWN0IGZ1bmN0aW9ucyBh cmUgdXNlZCB0byBidWlsZCB1cCB0aGUgcHJvdG9jb2xzIGJ5IGFkZGluZyBmdW5jdGlvbnMgb25l IHN0ZXAgYXQgYSB0aW1lIHRvIHRoZSBuZXR3b3JrLg0KDQpbTHVvd2VuXSBZZXMuDQoNClNvLCB0 aGUgaW50ZW50aW9uIG9mIHRoZSBmcmFtZXdvcmsgaXMgYXMgZm9sbG93czoNClRoZSBNUiwgTE0s IExVIGFic3RyYWN0IGZ1bmN0aW9ucyBhcmUgdGhvc2Ugb2YgSEEuIFNvLCBpdCBpcyBzdHJhaWdo dGZvcndhcmQgdG8gY29uc3RydWN0IE1JUHY2IHVzaW5nIHRoZXNlIGZ1bmN0aW9ucy4NClRoZW4g c29tZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhcmUgYWRkZWQgdG8gY29uc3RydWN0IFBNSVB2Niwg dGhlbiBzb21lIGFkZGl0aW9uYWwgZnVuY3Rpb25zIGFyZSBhZGRlZCB0byBjb25zdHJ1Y3QgSE1J UHY2LCBldGMuDQoNCltMdW93ZW5dIFRoYXQgaXMgdHJ1ZS4NCg0KU28sIHRoZSBjb25maWd1cmF0 aW9uIGFuZCBmdW5jdGlvbnMgaW4gSE1JUHY2IKGwdW5kZXIgdGhpcyBjb25zdHJ1Y3Rpb26hsSBh bHJlYWR5IGluY2x1ZGUgdGhvc2UgZm9yIFBNSVB2NiwgYW5kIHRoYXQgZm9yIFBNSVB2NiChsHVu ZGVyIHRoaXMgY29uc3RydWN0aW9uobEgaW5jbHVkZSB0aG9zZSBvZiBNSVB2NiBldGMuDQpUaGF0 IG1lYW5zIE1JUHY2IHNob3VsZCBjb250aW51ZSB0byB3b3JrIGluIHRoZSBQTUlQdjYgY29uc3Ry dWN0aW9uLCBhbmQgYm90aCBQTUlQdjYgYW5kIE1JUHY2IHNob3VsZCB3b3JrIGluIHRoZSBITUlQ djYgY29uc3RydWN0aW9uLg0KDQpbTHVvd2VuXSBJIGFtIG5vdCBzdXJlIGFib3V0IHRoaXMuIE1h eWJlIGl0IGRlcGVuZHMgb24gdGhlIHdoYXQgIGlzIHRoZSBwcmVjaXNlIG1lYW5pbmcgb2YgY29t cGF0aWJpbGl0eS4gRS5nLiBJIGRvbid0IHNlZSBob3cgYSBQTUlQdjYgbW9iaWxlIG5vZGUgY2Fu IGNvbnRpbnVlIHRvIGVuam95IHNlYW1sZXNzIG1vYmlsaXR5IHNlcnZpY2Ugd2hlbiBpdCBlbnRl cnMgYSBNSVB2NiAobWF5YmUgSSBhbSB3cm9uZy4pDQoNCk9uZSBjYW4gdGhlbiBjb250aW51ZSB0 byBjb25zdHJ1Y3QgZHluYW1pYyBtb2JpbGl0eSBtYW5hZ2VtZW50IG9uIHRvcCBvZiBITUlQdjYs IGFuZCB0aGVuIGNvbnRpbnVlIHRvIGNvbnN0cnVjdCByb3V0ZSBvcHRpbWl6YXRpb24gd2l0aCBk bW0gb24gdG9wIG9mIGR5bmFtaWMgbW9iaWxpdHkgbWFuYWdlbWVudC4gQW5kIHRoZSBhYm92ZSBp bnRlcnByZXRhdGlvbiBvZiBjb21wYXRpYmlsaXR5IHNob3VsZCBhcHBseS4NCg0KSXMgdGhhdCBh IHJlYXNvbmFibGUgYXBwcm9hY2g/DQoNCltMdW93ZW5dIEFsc28sIHdoZXRoZXIgaXQgaXMgcmVh c29uYWJsZSBvciBub3QsIG1heSBkZXBlbmRzIG9uIHRoZSBwcmVjaXNlIG1lYW5pbmcgb2YgY29t cGF0aWJpbGl0eQ0KDQpTbywgaXQgZG9lcyBub3QgaW50ZW5kIHRvIHNheSBjb21wYXRpYmxlIHRv IGVhY2ggb3RoZXIsIGFuZCB0aGUgd29yZGluZyBzaG91bGQgYmUgY29ycmVjdGVkLg0KDQpbTHVv d2VuXSBZZXMsIHRoZSB3b3JkaW5nIG1heSBuZWVkIGJlIGNvcnJlY3RlZCwgb3RoZXJ3aXNlIGl0 IG1heSBtYWtlIHBlb3BsZSBjb25mdXNlZC4NCg0KVGhlIGdhcCBhbmFseXNpcyBvbiB0aGUgZnJh bWV3b3JrIHdpdGggTVIsIExNLCBMVSBpcyBpbnRlbmRlZCB0byByZWZlciB0byB0aGF0IG9mIGEg bW9iaWxpdHkgc29sdXRpb24gYmFzZWQgb24gdGhlc2UgZnVuY3Rpb25zIGFsb25lLiAgSXQgaGFz IG5vdCBhZGRlZCB0aG9zZSBhZGRpdGlvbmFsIGZlYXR1cmVzIG5lZWRlZCBmb3IgRE1NLCBzbyBp dCBpcyB0b28gZWFybHkgdG8gc2F5IHdoZXRoZXIgaXQgY2FuIG1lZXQgdGhlIHJlc3Qgb2YgdGhl IHJlcXVpcmVtZW50cyBvdGhlciB0aGFuIHRob3NlIG1ldCBieSBNSVB2Ni4gSXQgY291bGQgaGF2 ZSBiZWVuIGxlZnQgYmxhbmsgYXMgeW91IHBvaW50ZWQgb3V0IHRoYXQgTi9BIGlzIG5vdCBhIGdv b2QgZGVzY3JpcHRpb24uDQoNCkggQW50aG9ueSBDaGFuDQoNCkZyb206IGRtbS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsdW8ud2Vu QHp0ZS5jb20uY24NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTIgMzoyMSBBTQ0KVG86 IGguYS5jaGFuQGllZWUub3JnDQpDYzogZG1tQGlldGYub3JnDQpTdWJqZWN0OiBbRE1NXSBTb21l IGNvbW1lbnRzIG9uIGRyYWZ0LWNoYW4tZG1tLWZyYW1ld29yay1nYXAtYW5hbHlzaXMtMDUuDQoN Cg0KSGkgQW50b255Og0KDQpUaGFua3MgdG8geW91ciBuZXcgZHJhZnQsIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNoYW4tZG1tLWZyYW1ld29yay1nYXAtYW5hbHlzaXMtMDUuIEkg aGF2ZSBzb21lIGNvbW1lbnRzIGFzIGZvbGxvd2luZy4NCg0KMS4gSSBoYXZlIHNvbWUgY29uY2Vy biBvbiB0aGUgc3RhdGVtZW50IChzZWN0aW9uIDYuMS4yKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICJE aWZmZXJlbnQgZGVwbG95bWVudHMgdXNpbmcgdGhlIHNhbWUgYWJzdHJhY3QgZnVuY3Rpb25zIGNh biBiZQ0KIGNvbXBhdGlibGUgd2l0aCBlYWNoIG90aGVyIGlmIHRoZWlyIGZ1bmN0aW9ucyB1c2Ug Y29tbW9uIG1lc3NhZ2UNCiBmb3JtYXRzIGJldHdlZW4gdGhlc2UgZnVuY3Rpb25zLiINCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KQWN0dWFsbHksIEkgZG9uJ3QgdGhpbmsgaXQgaXMgYSBzdXRpYWJsZSBj cml0ZXJpb24sIGkuZS4gSSBkb24ndCB0aGluayB0aGF0IHNoYXJpbmcgc2FtZSBhYnN0cmFjdCBm dW5jdGlvbnMgbmVjZXNzYXJ5IGluZGljYXRlIGRpZmZlcmVudCBkZXBsb3ltZW50cyBjYW4gY29t cGF0aWJsZSB3aXRoIGVhY2ggb3RoZXIuDQpUYWtpbmcgZmlndXJlIDYgaW4geW91ciBkcmFmdCBh cyBhbiBleGFtcGxlLCB0aGlzIGRlcGxveW1lbnQgaXMgdXNpbmcgdGhlIGFic3RyYWN0IGZ1bmN0 aW9ucyBNUiwgTE0gYW5kIExVIGFzIGluZGljYXRlZCBpbiB0aGUgZmlndXJlLiBNZWFudGltZSwg UE1JUHY2KFJGQ1s1MjEzXSkgaXMgYWxzbyB1c2luZyBzYW1lIGFic3RhY3QgZnVuY3Rpb25zIGFz IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuIFRoZW4sIGFjY29yZGluZyB0byB0aGUgY3JpdGVyaW9u LCB0aGVzZSB0d28gZGVzaWducyBzaG91bGQgYmUgY29tcGF0aWFibGUgd2l0aCBlYWNoIG90aGVy LiBIb3dldmVyLCBjb25zaWRlciB0aGF0LCBpZiB0aGVzZSB0d28gZGVzaWducyBhcmUgZGVwbG95 ZWQgdG9nZXRoZXIgKGUuZy4gb25lIG9wZXJhdG9yIGRlcGxveXMgYm90aCB0d28gZGVzaWducyks IGFuZCB3aGVuIE1OIGhhbmRvdmVyIGZyb20geW91ciBBUjIgdG8gYSBSRkNbNTIxM10gc3BlY2lm aWVkIE1BRywgSSBhbSBub3Qgc3VyZSBob3cgdG8ga2VlcCBhbGwgSVB2NiBwcmVmaXhlcyB3aGlj aCBhcmUgYW5jaG9yZWQgYXQgQVIxLCBBUjIgYW5kIEFSMyByZXNwZWN0aXZlbHkgYWxpdmUuIFRh a2luZyBmaWd1cmUgOCBhcyBhbnRoZXIgZXhhbXBsZSwgSSBhbSBub3Qgc3VyZSBob3cgdG8gcGVy Zm9ybSAgbG9jYXRpb24gbWFuYWdlbWVudCBpZiBtb2JpbGUgbm9kZSBoYW5kb3ZlcnMgdG8gYSBS RkNbNTIxM10gc3BlY2lmaWVkIFBNSVB2NiBkb21haW4gZnJvbSB0aGUgZG9tYWluIGlsbHVzdHJh dGVkIGJ5IHRoaXMgZmlndXJlLiBCZWNhdXNlIHRoZSBSRkNbNTIxM10gc3BlY2lmaWVkIExNQSBv ciBNQUcgZG9lc24ndCBoYXZlIHN1Y2ggbG9jYXRpb24gbWFuYWdlbWVudCBpbnRlcmZhY2Ugd2l0 aCB0aGUgTE0gaW4gZmlndXJlIDguDQoNCkFub3RoZXIgY29uY2VybiBhYm91dCB0aGUgImNvbXBh dGliaWxpdHkiIGlzIHRoZSBhbmFseXNpcyBjb21wYXJpc29ucyAiY29tcGF0aWJpbGl0eSIgaW4g dGFibGUgMSAoc2VjdGlvbiA2LjMpLiBZb3UgbWFyayAiWSIgdG8gYWxsIGl0ZW1zLiBCdXQsIGZv ciBleGFtcGxlLCBJIGFtIG5vdCB2ZXJ5IGNsZWFyIGFib3V0IGhvdyBjYW4gSEFIQSBiZSBjb21w YXRpYmxlIHdpdGggTUlQdjYsIGFuZCBob3cgY2FuIE11bHRpcGxlIE1ScyBhbmQgRGlzdHJpYnV0 ZWQgTE0gYmUgY29tcGF0aWJsZSB3aXRoIFBNSVB2NiAoYXMgZXhwbGFpbmVkIGFib3ZlKSBhbmQg ZXRjLiBNYXkgYmUgd2Ugc2hvdWxkIG5vdCBqdW1wIHRvIGEgY29uY2x1c2lvbiBiZWZvcmUgYSBj YXJlZnVsbHkgZXhhbWluZS4gQmVzaWRlcywgaWYgSSBhbSBub3QgbWFraW5nIG1pc3Rha2UsIHRo ZSBjb21wYXRpYmlsaXR5IGFsc28gaW5jbHVkZXMgdGhlIGNvbXBhdGliaWxpdHkgd2l0aCBhbHJl YWR5IGV4c2l0aW5nIGVuZCBob3N0IChlLmcuIG1vYmlsZSBub2RlKSwgcmlnaHQ/DQoNCjIuICBJ biB0YWJsZSAxIHNlY3Rpb24gNi4zLCB3aHkgdGhlIGxhc3QgZm91ciBhbmFseXNpcyBjb21wYXJp c29ucyBmb3IgVW5pZmllZCBmcmFtZXdvcmsgYXJlIG1hcmtlZCBhcyBOL0EgPyBCZXNpZGVzLCBJ IHRoaW5rIHRoZSBVbmlmaWVkIGZyYW1ld29yayBpcyBub3QgYSBtb2JpbGl0eSBzb2x1dGlvbiwg c28gd2h5IHlvdSBwdXQgaXQgaW4gdGhpcyBjb21wYXJpc29uIHRhYmxlPw0KDQozLiBTdGlsbCB0 YWJsZSAxLCBJIHRoaW5rIHRoZSBsYXN0IGFuYWx5c2lzIGNvbXBhcmlzb25zIG9mIE11bHRpcGxl IE1ScyBhbmQgRGlzdHJpYnV0ZWQgTE0gZGF0YWJhc2UgbXVzdCBiZSBtaXNzaW5nLg0KDQo0LiBT dGlsbCB0YWJsZSAxLCBJIHRoaW5rIHRoZSBsYXN0IGFuYWx5c2lzIGNvbXBhcmlzb25zIGl0ZW0g b2YgT3B0aW1pemUgUm91dGUgc2hvdWxkIGJlICJleGNlcHQgZmlyc3QgZmV3IHBhY2tldHMiLg0K DQpCUg0KTHVvd2VuDQo= --_000_6E31144C030982429702B11D6746B98C2841374FSZXEML510MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I have clarified the sect= ion on compatibility in the 06 version. Please check.

 <= /p>

H Anthony Chan=

 <= /p>

From: luo.wen@= zte.com.cn [mailto:luo.wen@zte.com.cn]
Sent: Tuesday, October 30, 2012 5:47 AM
To: h chan
Cc: dmm@ietf.org
Subject: =B4= =F0=B8=B4: RE: [DMM] Some comments on draft-chan-dmm-fra= mework-gap-analysis-05.

 


Hi Antony

Thanks for your reply, please see in-line for more comments.

BR
Luowen


h chan <h.anthony.chan@huawei.com>= ;

2012/10/25 05:45

=CA=D5=BC=FE=C8=CB<= /p>

"luo.wen@zte.com.cn" <luo.wen= @zte.com.cn>

=B3=AD=CB=CD

"dmm@ietf.org" <dmm@ietf.org&= gt;

=D6=F7=CC=E2

RE: [DMM] Some comments on draft-chan-dmm-= framework-gap-analysis-05.

 




Luowen,
 
Let me first explain what was intended to say, a= nd then make corrections accordingly.
 
I think compatibility in the requirement refers = to the following:
If one deploys dmm in a network, and the network= had an existing (centralized) mobility management deployment, the existing= deployment should continue to work.

[Luowen] Yes I agree. The existing deployment should continue = to work. But we should identify what is the meaning when one says the  = ;existing deployment can continue to work. One understanding is that those two domains (dmm domain and  existing deployment domain= such as PMIPv6 domain) work independently. Another understanding is that m= obile node which is belong to dmm domain can access the network via  t= he existing deployment domain ( such as PMIPv6 domain) in a manner of roaming. Or mobile node can handover from dmm domai= n to the existing deployment domain ( such as PMIPv6 domain) seamlessly and= vice versa. So maybe we should make it clear that what is the precise mean= ing of compatibility.

The abstract functions are used to build up the = protocols by adding functions one step at a time to the network.

[Luowen] Yes.

So, the intention of the framework is as follows= :
The MR, LM, LU abstract functions are those of H= A. So, it is straightforward to construct MIPv6 using these functions.
Then some additional functions are added to cons= truct PMIPv6, then some additional functions are added to construct HMIPv6,= etc.

[Luowen] That is true.

So, the configuration and functions in HMIPv6 = =A1=B0under this construction=A1=B1 already include those for PMIPv6, and t= hat for PMIPv6 =A1=B0under this construction=A1=B1 include those of MIPv6 e= tc.
That means MIPv6 should continue to work in the = PMIPv6 construction, and both PMIPv6 and MIPv6 should work in the HMIPv6 co= nstruction.

[Luowen] I am not sure about this. Maybe it depends on the wha= t  is the precise meaning of compatibility. E.g. I don't see how a PMI= Pv6 mobile node can continue to enjoy seamless mobility service when it enters a MIPv6 (maybe I am wrong.)
 
One can then continue to construct dynamic mobil= ity management on top of HMIPv6, and then continue to construct route optim= ization with dmm on top of dynamic mobility management. And the above interpretation of compatibility should apply.
 
Is that a reasonable approach?

[Luowen] Also, whether it is reasonable or not, may depends on= the precise meaning of compatibility
 
So, it does not intend to say compatible to each= other, and the wording should be corrected.

[Luowen] Yes, the wording may need be corrected, otherwise it = may make people confused.  
 
The gap analysis on the framework with MR, LM, L= U is intended to refer to that of a mobility solution based on these functi= ons alone.  It has not added those additional features needed for DMM, so it is too early to say whether it can meet the rest of = the requirements other than those met by MIPv6. It could have been left bla= nk as you pointed out that N/A is not a good description.  
 
H Anthony Chan
 
From: dmm-bounces@ietf.org [mailto:dm= m-bounces@ietf.org] On Behalf Of luo.wen@zte.com.cn
Sent: Tuesday, October 23, 2012 3:21 AM
To: h.a.chan@ieee.org
Cc: dmm@ietf.org
Subject: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-0= 5.
&= nbsp;

Hi Antony:

Thanks to your new draft, http://tools.ietf.org/html/draft-chan-dmm-framewo= rk-gap-analysis-05. I have some comments as following.

1. I have some concern on the statement (section 6.1.2)
-------------------------------------------------------------------------
 "Different deployments using the same abstract functions can be<= br>  compatible with each other if their functions use common message
 formats between these functions."  
---------------------------------------------------------------------------=
Actually, I don't think it is a sutiable criterion, i.e. I don't think that= sharing same abstract functions necessary indicate different deployments c= an compatible with each other.
Taking figure 6 in your draft as an example, this deployment is using the a= bstract functions MR, LM and LU as indicated in the figure. Meantime, PMIPv= 6(RFC[5213]) is also using same abstact functions as described in the draft= . Then, according to the criterion, these two designs should be compatiable with each other. However, consider= that, if these two designs are deployed together (e.g. one operator deploy= s both two designs), and when MN handover from your AR2 to a RFC[5213] spec= ified MAG, I am not sure how to keep all IPv6 prefixes which are anchored at AR1, AR2 and AR3 respectively= alive. Taking figure 8 as anther example, I am not sure how to perform &nb= sp;location management if mobile node handovers to a RFC[5213] specified PM= IPv6 domain from the domain illustrated by this figure. Because the RFC[5213] specified LMA or MAG doesn't have su= ch location management interface with the LM in figure 8.

Another concern about the "compatibility" is the analysis compari= sons "compatibility" in table 1 (section 6.3). You mark "Y&q= uot; to all items. But, for example, I am not very clear about how can HAHA= be compatible with MIPv6, and how can Multiple MRs and Distributed LM be compatible with PMIPv6 (as explained above) and etc. May be we shoul= d not jump to a conclusion before a carefully examine. Besides, if I am not= making mistake, the compatibility also includes the compatibility with alr= eady exsiting end host (e.g. mobile node), right?

2.  In table 1 section 6.3, why the last four analysis comparisons for= Unified framework are marked as N/A ? Besides, I think the Unified framewo= rk is not a mobility solution, so why you put it in this comparison table?<= /span>

3. Still table 1, I think the last analysis comparisons of Multiple MRs and= Distributed LM database must be missing.  

4. Still table 1, I think the last analysis comparisons item of Optimize Ro= ute should be "except first few packets".

BR
Luowen

--_000_6E31144C030982429702B11D6746B98C2841374FSZXEML510MBXchi_-- From alexandru.petrescu@gmail.com Thu Nov 8 06:33:21 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1121F8459 for ; Thu, 8 Nov 2012 06:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZWOPSW9oN3U for ; Thu, 8 Nov 2012 06:33:21 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1055E21F85AE for ; Thu, 8 Nov 2012 06:33:17 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA8EXBtF029855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 15:33:11 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA8EXBMq020013; Thu, 8 Nov 2012 15:33:11 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-18.intra.cea.fr [132.166.201.18]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA8EWhNB012673; Thu, 8 Nov 2012 15:33:10 +0100 Message-ID: <509BC28A.8030909@gmail.com> Date: Thu, 08 Nov 2012 15:32:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: h chan References: <501867A9.8060007@gmail.com> <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> <501AC93A.5000100@gmail.com> <6E31144C030982429702B11D6746B98C270D08FA@SZXEML505-MBS.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C270D08FA@SZXEML505-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dmm@ietf.org" Subject: Re: [DMM] Comment on Req2 transparency for DMM X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:33:21 -0000 Hello Antony, Thanks for the good work. You just said this is our last chance to suggest change so here is my last try. Currently in draft-ietf-dmm-requirements-02 this Req2 Transparency reads: > REQ2: Transparency to Upper Layers when needed > > DMM solutions MUST provide transparent mobility support above the IP > layer when needed. Such transparency is needed, for example, when, > upon change of point of attachment to the Internet, an application > flow cannot cope with a change in the IP address. Otherwise, support > for maintaining a stable home IP address or prefix during handovers > may be declined. This last 'declined' sounds IMHO as if this 'support' were requested in the first place. But this request assumes maybe a solution is in place (like Mobile IP or so). I'd rather use the word 'impossible', instead of 'declined', and 'is' instead of 'may be'. > Motivation: The motivation of this requirement is to enable more > efficient use of network resources and more efficient routing by not > maintaining context at the mobility anchor when there is no such > need. I agree with the motivation, although it sounds just a bit strange to me. Maybe it is strange to me because I myself assume Mobile IP :-) Maybe another motivation is like this: "it is hardly feasible to modify all applications deployed (see the large number of applications in the Deering's hourglass model [xx]) such that to support change in IP address or prefix above IP layer without restarting the applications during an ongoing flow (e.g. audio call). This motivates to propose changes at a single point which is the IP layer instead (the waist of the hourglass)." Thanks, Alex Le 03/08/2012 19:07, h chan a écrit : > How about the following: > > The DMM solutions MUST provide transparency above the IP layer when > needed. Such transparency is needed, for example, upon change of > point of attachment to the Internet for the application flows that > cannot cope with a change of IP address. Otherwise the support to > maintain a stable home IP address or prefix during handover may be > declined. > > Or > > The DMM solutions MUST enable transparency above the IP layer. Such > transparency is needed, for example, upon change of point of > attachment to the Internet for the application flows that cannot cope > with a change of IP address. Otherwise the support to maintain a > stable home IP address or prefix during handover may be declined. > > H Anthony Chan > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, August 02, 2012 > 11:39 AM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] Comment on > Req2 transparency for DMM > > H Anthony, > > Yes, this reflects Sri's and my suggestion about removal of MN/MR > qualifier. I agree with the idea of the new text as you put it. > > Then, if I re-read just like that, there still seems to be some > difficulty to my brain to understand: > > Le 01/08/2012 23:35, h chan a écrit : >> The DMM solutions MUST provide transparency above the IP layer >> when needed, such as upon change of point of attachment to the >> Internet, for the application flows that cannot cope with a change >> of IP address. Otherwise the support to maintain a stable home IP >> address or prefix during handover may be declined. > > I don't understand the last phrase - the 'otherwise' relates to the > first MUST? Or to the latter 'cannot'? > > But this may be just nitpicking on the use of language. I agree > with the direction of the idea and thank you for having provided the > modification. > > Alex > > From karagian@cs.utwente.nl Thu Nov 8 07:01:39 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024B121F8B58 for ; Thu, 8 Nov 2012 07:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD5obrL-mNQo for ; Thu, 8 Nov 2012 07:01:38 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id DF1BC21F8590 for ; Thu, 8 Nov 2012 07:01:37 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 8 Nov 2012 16:01:37 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 16:01:36 +0100 From: To: , Thread-Topic: DMM functional framework posted Thread-Index: Ac2rtkYqUHMX3R8lT2GK/zx0O/gz3QPEEFH+AAPJ97AAuvjZew== Date: Thu, 8 Nov 2012 15:01:36 +0000 Message-ID: References: <69756203DDDDE64E987BC4F70B71A26D55135B39@DAPHNIS.office.hd> , <69756203DDDDE64E987BC4F70B71A26D5513C865@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D5513C865@DAPHNIS.office.hd> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] DMM functional framework posted X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:01:39 -0000 Hi Marco, Thanks for the answers! I think that the draft is valuable. In particular, this draft can provide t= he basis for the work on gap analysis! Best regards, Georgios ________________________________________ Van: Marco Liebsch [Marco.Liebsch@neclab.eu] Verzonden: zondag 4 november 2012 23:30 To: Karagiannis, G. (EWI); dmm@ietf.org Onderwerp: RE: DMM functional framework posted Hi Georgios, thanks for your comments. Please see inline for my response. >-----Original Message----- >From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >Sent: Sonntag, 4. November 2012 21:02 >To: Marco Liebsch; dmm@ietf.org >Subject: RE: DMM functional framework posted > >Hi Marco, > >I have read this draft and I think that it is useful for the DMM WG. Howev= er, I >have some comments: > >1) Can you please emphasize which approach have you followed in order to >derive the functional entities that are described in Section 3. One could = derive >other FEs than the ones mentioned in Section 3. The approach is to assume a mobility anchor/gateway and add functional entities to enable DMM without taking assumptions on the mobility protocol. Hence, it does not take assumptions on mobility protocol dependency. As soon as a suitable set of functional entities is defined, we can take mo= bility protocols (MIP6, PMIP6), either with or without extension protocols, such a= s runtime LMA redirection. Then the DMM functional entities can be placed to the associated architecture in different ways, either collocated with mobil= ity components or other components, e.g. provided by the transport network, and we can analyze if a function is implicitly supported by the mobility protoc= ol or needs a further extension or support from an external protocol. Latter point is still important, IMHO, I still think DMM should be enabled = by looking for support from other protocols outside the IP-mobility protocol space. > >2) What are the main differences between the framework that you propose in >this draft and the one proposed in: framework, like the one introduced in >http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt. The main difference is that it defines DMM functional entities without bein= g dependent on functions of available IP mobility architecture. We discussed such frame= work during last IETF and came to the conclusion that such framework is useful for the gap analysis and the specification of protocol extensions without b= eing Dependent on mobility protocols. I received some feedback to version -00 about further separation of defined functional entities into control- and data-plane, which can help to apply t= he DMM functional elements to available components of Mobile IP, Proxy Mobile IPv6, LISP on top of a Mobile IP architecture or even an OpenFlow-based arc= hitecture in the mobile carrier's transport network. The draft is simply the way of communicating the approach of using these fu= nctional elements for the analysis and the specification of protocol extensions to e= nable DMM. It's not meant as further competing gap analysis draft :-) But it reflects = what I could discuss with some DMM folks and hopefully supports the discussion about DMM while t= ackling the associated complexity behind this topic. marco > >Best regards, >Georgios > >________________________________________ >Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Marco Liebsch >[Marco.Liebsch@neclab.eu] >Verzonden: dinsdag 16 oktober 2012 18:04 >To: dmm@ietf.org >Onderwerp: [DMM] DMM functional framework posted > >As follow up of a discussion during last IETF meeting with some of you, w= e >posted a new draft about an initial functional framework for DMM. We think >that discussing BCP and gaps can be supported by using well defined functi= onal >entities (FE) and reference points to enable DMM. Different constellations= of FEs >can match architectures of existing protocols and gaps as well as strength= s or >weak points of the associated architecture/protocol can be easily identifi= ed. > >The current version provides a basic set of FEs and interfaces and depicts= two >key models as starting point to group FEs according to the WG's current >understanding how DMM may be solved. > >Any opinion about the proposed framework and approach as well as >contributions to an updated version of this draft are appreciated. > >Marco > >-- >A new version of I-D, draft-liebsch-dmm-framework-analysis-00.txt >has been successfully submitted by Marco Liebsch and posted to the IETF >repository. > >Filename: draft-liebsch-dmm-framework-analysis >Revision: 00 >Title: Distributed Mobility Management - Framework & Analysis >Creation date: 2012-10-15 >WG ID: Individual Submission >Number of pages: 16 >URL: http://www.ietf.org/internet-drafts/draft-liebsch-dmm-fra= mework- >analysis-00.txt >Status: http://datatracker.ietf.org/doc/draft-liebsch-dmm-framewo= rk- >analysis >Htmlized: http://tools.ietf.org/html/draft-liebsch-dmm-framework-an= alysis- >00 > > >Abstract: > Mobile operators consider the distribution of mobility anchors to > enable offloading some traffic from their core network. The > Distributed Mobility Management (DMM) Working Group is investigating > the impact of decentralized mobility management to existing protocol > solutions, while taking into account well defined requirements, which > are to be met by a future solution. This document discusses DMM > using a functional framework. Functional Entities to support DMM as > well as reference points between these Functional Entities are > introduced and described. The described functional framework allows > distribution and co-location of Functional Entities and build a DMM > architecture that matches the architecture of available protocols. > Such methodology eases the analysis of best current practices with > regard to functional and protocol gaps. > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm= From Peter.McCann@huawei.com Thu Nov 8 10:43:08 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E79821F8438 for ; Thu, 8 Nov 2012 10:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65I4HI9tptsM for ; Thu, 8 Nov 2012 10:43:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5F21F842B for ; Thu, 8 Nov 2012 10:43:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMN97554; Thu, 08 Nov 2012 18:43:04 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 18:42:47 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 18:43:01 +0000 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.159]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 10:42:56 -0800 From: Peter McCann To: Marco Liebsch , "dmm@ietf.org" Thread-Topic: Comments on draft-liebsch-dmm-framework-analysis-00 Thread-Index: Ac29H8mOiU7yIlrkRtKAICgO6UHwIwAHRBfQACi1iQA= Date: Thu, 8 Nov 2012 18:42:57 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E558DA@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716E5556C@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D5513EEF1@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D5513EEF1@DAPHNIS.office.hd> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:43:08 -0000 Hi, Marco, Thanks for the response. See below. Marco Liebsch wrote: > Hi Pete, > please see inline for my response. >=20 >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Peter McCann >> Sent: Mittwoch, 7. November 2012 20:41 >> To: dmm@ietf.org >> Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 >>=20 >> Let me ask a question to make sure I understand the approach this >> document takes to analyzing the problem space. In the Introduction, >> you state: >> "The initial version of this draft introduces a basic set of FEs and >> interfaces between these FEs to support IP address continuity in DMM, >> without being specific to the used mobility management protocol, >> which operates below the mobility anchor." >> And later, you introduce the FE_MA to represent this mobility anchor. I >> *think* you are trying to define DMM as something that runs above >> another mobility management protocol. >=20 > That would imply a solution and that is not intended. The four defined > DMM FEs can be mapped to components of existing protocols. My intention > is to define DMM FEs, which enable DMM use cases but are not dependent > on a mobility protocol. So, some functions can be applied to existing > components of, say, iBGP in a route reflector, or a LISP resolver. But > some components can be placed on a Mobile IP Home Agent or even a Mobile > Node. Then we can analyze if the function of the DMM FE is implicitly > supported by the existing protocol or if an extension is needed. That's > the rationale behind these FEs. The FE_MA is mentioned as existing > component and assumed as topological anchor of the MN's IP address. Some > or all DMM FEs may apply to the existing MA. Depends on the analysis we > want to perform. Ok I understand that you want to put some of your components in the existin= g mobility anchor (and at least the FE_MA would be there) but you also seem to be distinguishing between a DMM protocol that runs *above* the FE_MA and another mobility protocol that runs *below* the FE_MA. Is that a correct interpretation? >=20 >> Would it be legal to set the FE_MA equal to the >> access router, and the other mobility management protocol to NULL? That >> is, would it be allowed in your framework to use *only* the DMM >> protocol to get packets to an AR, to which the MN is currently attached? >=20 > Yes, legal from my perspective :-) Good. It seems to me that designating the leaf node in your architecture as containing FE_MA is confusing because there may in fact be no mobility protocol running between FE_MA and AR (they may be one and the same entity)= . >> Section 3 states: >> "Imported HoA/HNP >> of a mobile node will be treated as identifier and non-routable IP >> address (prefix), as it probably does not match the new mobility >> anchor's location in the topology." >> I disagree. The old address (prefix) will need to be routable at least >> inside the new anchor point. If this anchor point is directly >> connected to the MN (i.e., it is the AR) then the route will be to a >> local link address. If this new anchor point uses a tunnel to get the >> packets to the MN, then the old address will be routable to the tunnel >> interface. >=20 > The assumption is of course that below a mobility anchor (FE_MA) the > mobility protocol performs location tracking and tunnel management or > whatever.=20 Sure, but at least one node needs to have a "route" for the old IP address, even if it is just a route to a local tunnel interface. > The defined DMM FEs enable the required level of indirection > above or at the mobility anchor. Right this reflects my understanding of your two-layer model. I am just=20 wondering why we can't further decouple ourselves from the mobility protoco= l that may exist beneath the FE_MA. It may not exist or may only be at L2 (or L1). >> Elsewhere in Section 3: >> "Forwarding can be for example accomplished by an IP tunnel to the >> egress function, address translation to a routable IP address or >> other means." >> I hope that "other means" can include installing an actual route for >> the destination IP on routers between the ingress and egress. >=20 > Yes. Good. >> I'd be happy to provide a diagram and text to show how draft-mccann- >> dmm- flatarch can fit into this functional framework. In the language >> of your draft, I think that the FE_MAs are integrated with the ARs, the >> FE_MCTX is the DNS server that stores the UE's current address, FE_E is >> co-located on the currently serving AR, and FE_I and FE_IEC are made up >> of a distributed network of routers running BGP (there is no single >> point of failure for FE_I). >=20 > I have that picture in mind, just lack of time caused mapping examples > to be weak in version 00. I received other feedback and version 01 is > actually there. I'd be happy if you contribute to the draft with our > picture and text. By the way, the main motivation of the DMM FEs was to > allow analysis beyond mobility protocols, hence including your solution > proposal. I see the iBGP solution as hop-by-hop solution where each > transport network router gets a per-host state when indirection is > required. Each iBGP router hence implements an FE_I and FE_E at the same > time. But let's discuss details tomorrow. Sorry I had a conflict and couldn't attend DMM this morning. I will take a look at your version 01 and contribute where necessary. -Pete >=20 > marco From yuri@ismailov.eu Thu Nov 8 15:01:33 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BFF21F8661 for ; Thu, 8 Nov 2012 15:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN6gsw1I6sOS for ; Thu, 8 Nov 2012 15:01:33 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.16]) by ietfa.amsl.com (Postfix) with ESMTP id BF47C21F85E2 for ; Thu, 8 Nov 2012 15:01:32 -0800 (PST) Received: from [130.129.17.19] (dhcp-1113.meeting.ietf.org [130.129.17.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 096B669149 for ; Fri, 9 Nov 2012 00:01:30 +0100 (CET) Message-ID: <509C39C9.3060203@ismailov.eu> Date: Fri, 09 Nov 2012 00:01:29 +0100 From: Yuri Ismailov User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.7) Gecko/20121013 Thunderbird/10.0.7 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [DMM] RA option for local breakout address X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:01:33 -0000 Hi folks, After some additional clarifications my confusions about the proposal today were removed and I think that considering the IPv6 only scenario it looks reasonable. The rest depends on the architecture, trusted/untrusted wireless LAN access, etc. So, the proposal makes sense for a number of use cases. /yuri From jouni.nospam@gmail.com Mon Nov 12 11:59:06 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354C421F86D3 for ; Mon, 12 Nov 2012 11:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzZPgtzcee8H for ; Mon, 12 Nov 2012 11:59:05 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA221F866B for ; Mon, 12 Nov 2012 11:59:05 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1773948lbk.31 for ; Mon, 12 Nov 2012 11:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=xhO4pg8m/ofu2gAtNyDjnziPVgtgiIUFA4sreWWxh2U=; b=PmfUlxMNli0Ne/bus8HyH/PxmNtBmTISJBFCpFeHJDp+zZM2P6gR8NsSEgbKCVUne1 BQ5BXqp5AdVAutbUAFq4hOk2QOIODsvEe/VxOBUeF/odszqdtXCB6xvBCOUhxpFwM0wA eXXohm3xF6JKNZuRHKAevaKmfuI3t4f/7esQ0yszWRBdMRlKP8mJEQ2Po3ZX1JE44UJW PXnWUjP5chIOOmhZaeGUf897YtevqybaZ8bEa0Vu7CmLQKkyNfXvqHNrXVcz7J0u0TIy XF+pe/Aq4LiBW193BVAA/TW71k09/eN1wrErXCk702/GMDxtG2q29mg5QBdbx8F8Qhxl 1AQg== Received: by 10.152.113.225 with SMTP id jb1mr8790597lab.23.1352750343867; Mon, 12 Nov 2012 11:59:03 -0800 (PST) Received: from a88-114-172-51.elisa-laajakaista.fi (a88-114-172-51.elisa-laajakaista.fi. [88.114.172.51]) by mx.google.com with ESMTPS id hu6sm2926403lab.13.2012.11.12.11.59.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 11:59:03 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 21:59:01 +0200 Message-Id: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Cc: Behcet Sarikaya , Stig Venaas Subject: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:59:06 -0000 Folks, This mail is to kick off the discussion on multicast requirement(s) for = the draft-ietf-dmm-requirements-02 document. I hope we can nail down the = essential multicast requirement(s) as soon as possible. - Jouni= From Peter.McCann@huawei.com Mon Nov 12 12:39:14 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC75421F875C for ; Mon, 12 Nov 2012 12:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOOzbBLCcfO5 for ; Mon, 12 Nov 2012 12:39:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B6A3521F86EC for ; Mon, 12 Nov 2012 12:39:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALL69260; Mon, 12 Nov 2012 20:39:12 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 20:39:06 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 20:39:12 +0000 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.159]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 12:39:08 -0800 From: Peter McCann To: jouni korhonen , "dmm@ietf.org" Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwRAx91IcrVjoO0yGCUNLe3OXiJfmqM9w Date: Mon, 12 Nov 2012 20:39:08 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> In-Reply-To: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , Behcet Sarikaya Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:39:15 -0000 jouni korhonen wrote: > Folks, >=20 > This mail is to kick off the discussion on multicast requirement(s) > for the draft-ietf-dmm-requirements-02 document. I hope we can nail > down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete From sarikaya2012@gmail.com Mon Nov 12 13:00:26 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896A121F8462 for ; Mon, 12 Nov 2012 13:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs8ah1NQN0RQ for ; Mon, 12 Nov 2012 13:00:26 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5821F8449 for ; Mon, 12 Nov 2012 13:00:25 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so10766937iec.31 for ; Mon, 12 Nov 2012 13:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lGaI3rsDHveMw41iJOdaWOmliWj+i8B1PWxapF7B5BY=; b=qmz1pdRE3yveYSlR+2RnRAZH84/zvTepfWWQnXu0gS+RehLlcI1WWINghFNxPLWW5D 3pvdRX9oRHN6jin8pBF8QjWkztYVCo+56UMqma08gc4fkV31vyNfLUGyCnKUoTDtbQEF cWfWtZk+J2X/7Yja8CvnIYOuKuea8hVKoOme+iqtiwAUAkZbsEGGkuxu7Uq/4k2vWN92 FXDAB5vyr42EKz14syYsbMMBBuL3cWg7Z0qMrbG4G/7d9dR3aoKKm+DkzadsNkxAHHAG 2nB+xtU7OPeifpwiJnks9uRYv+svxbd6z+6NDGPSbfU+bYQCZDq/NKuka0fXuSMLpKME 9KpQ== MIME-Version: 1.0 Received: by 10.42.159.196 with SMTP id m4mr9866855icx.40.1352754025324; Mon, 12 Nov 2012 13:00:25 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 12 Nov 2012 13:00:25 -0800 (PST) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> Date: Mon, 12 Nov 2012 15:00:25 -0600 Message-ID: From: Behcet Sarikaya To: Peter McCann Content-Type: text/plain; charset=ISO-8859-1 Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:00:26 -0000 Hi Pete, For PMIPv6, Multimob has defined a base multicast support protocol which is documented in RFC 6224. You may wish to take a look at this RFC. Currently Multimob is working on several extensions to the base protocol. Let's stop speculating how the multicast is supported and concentrate on dmm multicast requirements. Regards, Behcet On Mon, Nov 12, 2012 at 2:39 PM, Peter McCann wrote: > jouni korhonen wrote: >> Folks, >> >> This mail is to kick off the discussion on multicast requirement(s) >> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >> down the essential multicast requirement(s) as soon as possible. > > To me, multicast in a DMM environment means joining multicast > groups directly from access routers. It means re-joining the > multicast tree from a new access router after handover. I would > hope that we can use existing MLD protocols between the MN and > its first hop AR to accomplish this. > > -Pete > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From sarikaya2012@gmail.com Mon Nov 12 13:13:53 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA021F874D for ; Mon, 12 Nov 2012 13:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us8TFpzVEfzL for ; Mon, 12 Nov 2012 13:13:53 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 212B721F86CE for ; Mon, 12 Nov 2012 13:13:53 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so10788566iec.31 for ; Mon, 12 Nov 2012 13:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Tgwv52B/KpkO/FNDMaIsAu87yDmrbOMqbhyiR79doWE=; b=bBu+9yp8oC/JyFlrfREOR2GIe+TpPs1fj1b3sFjoLVJHJhd9hDsSdlgZGJgLQ0KHjw /AJicKbTJuKjSDq9txuy1bSbz1CaTBJHOMJdULOIFcDsa94yTBx0ZK4Nmk1nsidtsWpS uRzMetptyThJJ+czvxta64Be8i3FerZsFUmrvBm45AS5+rVadV+RLvvumN1H5rUEp6D7 XF1owlmyobhsAbMWQ8uBEDF1rLCQqDOrjzVLjL21+UxGQaUesTywq+T74eiCqd5nxaou LvHm1t/ayQJJDxXAW+cXb2ZI/QzI2SUUl1JJ9awiQYQ3Zz/LS3upgSCbqkOSTuV2UqaT HsVg== MIME-Version: 1.0 Received: by 10.50.53.170 with SMTP id c10mr9357274igp.45.1352754832492; Mon, 12 Nov 2012 13:13:52 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 12 Nov 2012 13:13:52 -0800 (PST) In-Reply-To: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> Date: Mon, 12 Nov 2012 15:13:52 -0600 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: Stig Venaas , Behcet Sarikaya , dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:13:53 -0000 Hi Jouni, This discussion originated by a presentation in Multimob of a draft on IP Multicast Use Cases and Analysis over Distributed Mobility Management, http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. This draft is on use cases not on requirements. The author, Seil mentioned that maybe he can extract some requirements from his draft. As a possible way going forward, I suggest that Seil does this and proposes some requirements maybe as part of this thread and we go from there. I can tell you that in Multimob meeting in Atlanta, we have not discussed any requirements. Regards, Behcet On Mon, Nov 12, 2012 at 1:59 PM, jouni korhonen wrote: > Folks, > > This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. > > - Jouni > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From schmidt@fhtw-berlin.de Mon Nov 12 13:32:23 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB6D21F85AD for ; Mon, 12 Nov 2012 13:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pepiiOBq+9jt for ; Mon, 12 Nov 2012 13:32:23 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8F21F85AC for ; Mon, 12 Nov 2012 13:32:22 -0800 (PST) Envelope-to: dmm@ietf.org Received: from g231108188.adsl.alicedsl.de ([92.231.108.188] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1TY1cD-000JqY-2n; Mon, 12 Nov 2012 22:32:21 +0100 Message-ID: <50A16AE0.70101@fhtw-berlin.de> Date: Mon, 12 Nov 2012 22:32:16 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Peter McCann References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: dmm@ietf.org Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:32:23 -0000 Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: > jouni korhonen wrote: >> Folks, >> >> This mail is to kick off the discussion on multicast requirement(s) >> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >> down the essential multicast requirement(s) as soon as possible. > > To me, multicast in a DMM environment means joining multicast > groups directly from access routers. It means re-joining the > multicast tree from a new access router after handover. I would > hope that we can use existing MLD protocols between the MN and > its first hop AR to accomplish this. > > -Pete > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From jouni.nospam@gmail.com Mon Nov 12 13:32:40 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD721F869C for ; Mon, 12 Nov 2012 13:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpt26faxAi5q for ; Mon, 12 Nov 2012 13:32:39 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0E21F8696 for ; Mon, 12 Nov 2012 13:32:38 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so954126eek.31 for ; Mon, 12 Nov 2012 13:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=xOQgY+k0pBJjIFokIB8ZtRJgcuQj4OLRTxR7DMkrAvI=; b=ucmKurVGdsAq32qWNyNkNyv/YXhwD4dfNIur/6LA0UzlanX/89yHBcpD5NCudrwmly x+o1zs40VJ1Ecp1NznASOnkx6V6G9H51RRy/GtMuHl4dJLC1FkIPa9VdxnGw5D4bmRII pxbcXrTRT3rPNxwsmOqjJ3vIHgDj/XaKUti/N1b8q5nivh0UalGXOa1mk4IyHeRwIV8Z aYz/NTWpYaKEiz4yEpqGygSeLMsRBsec9krIzl6laeP7yuJwvjeyB4FvIwXdJy12zXjE fc6DJQXZyGxfMQTL7S+KBDpa3yXQLlRfW0DXoNTwYkYWElhUKbSKLp90T+SzJkRfLlMa NZZQ== Received: by 10.14.1.69 with SMTP id 45mr67295130eec.23.1352755958083; Mon, 12 Nov 2012 13:32:38 -0800 (PST) Received: from [10.17.0.22] ([83.150.126.201]) by mx.google.com with ESMTPS id k2sm18314896eep.15.2012.11.12.13.32.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 13:32:37 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 23:32:35 +0200 Message-Id: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:32:40 -0000 Hi, In Introduction it says: ".. capacity, service providers need to implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO = [TS.23829]) through alternative access networks (e.g. WLAN) [Paper- Mobile.Data.Offloading]. Moreover, the presence of content providers closer to the mobile/fixed Internet Service Providers network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services." o I would also mention here that the gateway selection mechanism can = take the user proximity into account at least within EPC [29.303].. as we are = already referencing to 3GPP as an example. o One another aspect I would mention here is the commercial deployment = reality. While we have means for selecting and using more optimally located = gateways those are not pursued due charging and billing reasons; here I mean = that while assigning a gateway anchor node from a visited network while = the MN is roaming is not done until recently (and still only limited to voice = services). That kind of issues are not solved by a mobility protocol but a = different trust and/or billing models between network operators. In Section 3.2 ".. former case only the data plane is distributed. Fully distributed mobility management implies that both the data plane and the control plane are distributed. These different approaches are described in .." o Would it be OK to mention here that even if full distribution could = be achieved for the mobility part of the system, some parts are still going to be = centralized or just geographically replicated at best? Here I mean functions like subscriber management, subscription databases and network access = authentication. In Section 4.1: "PS2: Divergence from other evolutionary trends in network architecture Centralized mobility management can become non-optimal with a flat network architecture." o What are the "other"? I would consider removing PS2 if we cannot name those. "PS3: Low scalability of centralized route and mobility context maintenance" o Isn't e.g. the SDN evolution just doing to the opposite? Highly centralized management point for traffic steering? I would reconsider PS3 unless we have more evidence that this is really an issue. Or then we need to point out something that makes it more context=20 specific for DMM or mobility. In Section 4.2: "REQ2: Transparency to Upper Layers when needed DMM solutions MUST provide transparent mobility support above the IP layer when needed. Such transparency is needed, for.." o Doesn't the "when needed" make the earlier MUST conditional? At least I understand it so. If that is the case we probably could just say: "DMM solutions SHOULD provide transparent mobility support above the IP layer." ? In Section 4.4: o I would just remove the sentence:=20 "Motivation: Using IETF protocols is easier to deploy and to update." IMHO it brings no additional clarity what has already been said. In Section 4.5: o I would reword "Compatibility" to "Backwards and forward = compatibility". A general editorial note. I would consider rewording all these "PSx" and=20= "O-PSx" problem statement and just include them into the generic = requirement text. - Jouni= From Peter.McCann@huawei.com Mon Nov 12 13:53:51 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E621F86EC for ; Mon, 12 Nov 2012 13:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj7-RIY+gCee for ; Mon, 12 Nov 2012 13:53:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84A7C21F8625 for ; Mon, 12 Nov 2012 13:53:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR65296; Mon, 12 Nov 2012 21:53:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 21:53:33 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 21:53:24 +0000 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.159]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 13:53:21 -0800 From: Peter McCann To: "Thomas C. Schmidt" Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwRAx91IcrVjoO0yGCUNLe3OXiJfmqM9wgACVjAD//39nEA== Date: Mon, 12 Nov 2012 21:53:20 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> In-Reply-To: <50A16AE0.70101@fhtw-berlin.de> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:53:51 -0000 In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: > Dear Pete, >=20 > multicast mobility management is a route adaptation problem. As in the > unicast case, mobility can only be treated by routing dynamics in > trivial cases (re-connect of a tunnel, re-association with next hop). > Otherwise it is unwise to delegate mobility adaptation to routing > protocols (-> OSPF, BGP ...). >=20 > Accordingly, if DMM distributes mobility operations, handover > management should foresee easy interconnects to previous distribution > trees - both for receivers and for mobile multicast sources. >=20 > I guess, if DMM people are careful, this is not a world-class item and > can be treated along the lines of unicast solutions - an isolated > multicast protocol treatment (as has been previously proposed from > MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment > has turned out to work out simply (-> RFC6224). >=20 > Thus my argument: talk to the multicast guys before adopting a > solution ... and make the rest an easy game. >=20 > Cheers, >=20 > Thomas >=20 > On 12.11.2012 21:39, Peter McCann wrote: >> jouni korhonen wrote: >>> Folks, >>>=20 >>> This mail is to kick off the discussion on multicast requirement(s) >>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>> down the essential multicast requirement(s) as soon as possible. >>=20 >> To me, multicast in a DMM environment means joining multicast groups >> directly from access routers. It means re-joining the multicast tree >> from a new access router after handover. I would hope that we can use >> existing MLD protocols between the MN and its first hop AR to >> accomplish this. >>=20 >> -Pete >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 > From schmidt@fhtw-berlin.de Mon Nov 12 14:05:35 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E1521F84D8 for ; Mon, 12 Nov 2012 14:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gtj8JD8f-KH for ; Mon, 12 Nov 2012 14:05:34 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id C044121F8456 for ; Mon, 12 Nov 2012 14:05:34 -0800 (PST) Envelope-to: dmm@ietf.org Received: from g231108188.adsl.alicedsl.de ([92.231.108.188] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1TY28L-000M1n-5w; Mon, 12 Nov 2012 23:05:33 +0100 Message-ID: <50A172AC.5090308@fhtw-berlin.de> Date: Mon, 12 Nov 2012 23:05:32 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Peter McCann References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: dmm@ietf.org Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:05:35 -0000 Hi Pete, things would be simple, if topology were as described. Let's wait what dmm is birthing out ... and continue discussion then. In any case, complex and incompatible "grand new schemes" do not appear to make much sense. Cheers, Thomas On 12.11.2012 22:53, Peter McCann wrote: > In the DMM case my assumption is that the anchor points are closer > to the access routers and therefore are very likely to be in the same > administrative domain. In these cases, joining the multicast group > directly from the access router gives you the same access to the same > multicast streams and so tunneling the multicast packets won't be > necessary. > > -Pete > > Thomas C. Schmidt wrote: >> Dear Pete, >> >> multicast mobility management is a route adaptation problem. As in the >> unicast case, mobility can only be treated by routing dynamics in >> trivial cases (re-connect of a tunnel, re-association with next hop). >> Otherwise it is unwise to delegate mobility adaptation to routing >> protocols (-> OSPF, BGP ...). >> >> Accordingly, if DMM distributes mobility operations, handover >> management should foresee easy interconnects to previous distribution >> trees - both for receivers and for mobile multicast sources. >> >> I guess, if DMM people are careful, this is not a world-class item and >> can be treated along the lines of unicast solutions - an isolated >> multicast protocol treatment (as has been previously proposed from >> MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment >> has turned out to work out simply (-> RFC6224). >> >> Thus my argument: talk to the multicast guys before adopting a >> solution ... and make the rest an easy game. >> >> Cheers, >> >> Thomas >> >> On 12.11.2012 21:39, Peter McCann wrote: >>> jouni korhonen wrote: >>>> Folks, >>>> >>>> This mail is to kick off the discussion on multicast requirement(s) >>>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>>> down the essential multicast requirement(s) as soon as possible. >>> >>> To me, multicast in a DMM environment means joining multicast groups >>> directly from access routers. It means re-joining the multicast tree >>> from a new access router after handover. I would hope that we can use >>> existing MLD protocols between the MN and its first hop AR to >>> accomplish this. >>> >>> -Pete >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > > > From seiljeon@av.it.pt Mon Nov 12 14:48:51 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DBF21F86B8 for ; Mon, 12 Nov 2012 14:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDZxZQGoJzqi for ; Mon, 12 Nov 2012 14:48:51 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 69E5421F8696 for ; Mon, 12 Nov 2012 14:48:50 -0800 (PST) Received: from [193.136.93.25] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67005514; Mon, 12 Nov 2012 22:48:47 +0000 From: "Seil Jeon" To: "'Peter McCann'" References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> Date: Mon, 12 Nov 2012 22:49:03 -0000 Message-ID: <014801cdc127$e9b9b6c0$bd2d2440$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDpvfVQJP8hzaX/j8eL/mEb+S6VGQFDovgtAWOj9LkCV0872ZmG26vw Content-Language: ko Cc: 'Stig Venaas' , 'Behcet Sarikaya' , dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:48:51 -0000 Hi Pete, That might be one of them we can take on DMM. Imagine, depending on deployment of existing IP multicasting standard entities, we can think of various use cases as presented in http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. Direct routing cannot be applied in every scenario. After I came back from the trip, we (me and Sergio) have been working on this with priority. After carefully reviewing the requirement from the use cases, we'll announce it soon. Regards, Seil -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Peter McCann Sent: Monday, November 12, 2012 9:53 PM To: Thomas C. Schmidt Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: > Dear Pete, > > multicast mobility management is a route adaptation problem. As in the > unicast case, mobility can only be treated by routing dynamics in > trivial cases (re-connect of a tunnel, re-association with next hop). > Otherwise it is unwise to delegate mobility adaptation to routing > protocols (-> OSPF, BGP ...). > > Accordingly, if DMM distributes mobility operations, handover > management should foresee easy interconnects to previous distribution > trees - both for receivers and for mobile multicast sources. > > I guess, if DMM people are careful, this is not a world-class item and > can be treated along the lines of unicast solutions - an isolated > multicast protocol treatment (as has been previously proposed from > MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment > has turned out to work out simply (-> RFC6224). > > Thus my argument: talk to the multicast guys before adopting a > solution ... and make the rest an easy game. > > Cheers, > > Thomas > > On 12.11.2012 21:39, Peter McCann wrote: >> jouni korhonen wrote: >>> Folks, >>> >>> This mail is to kick off the discussion on multicast requirement(s) >>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>> down the essential multicast requirement(s) as soon as possible. >> >> To me, multicast in a DMM environment means joining multicast groups >> directly from access routers. It means re-joining the multicast tree >> from a new access router after handover. I would hope that we can >> use existing MLD protocols between the MN and its first hop AR to >> accomplish this. >> >> -Pete >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From JuanCarlos.Zuniga@InterDigital.com Mon Nov 12 14:51:50 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2965D21F85DF for ; Mon, 12 Nov 2012 14:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXJ1z2WDbtDb for ; Mon, 12 Nov 2012 14:51:49 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 720C421F85A8 for ; Mon, 12 Nov 2012 14:51:49 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 17:51:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 17:51:47 -0500 Message-ID: In-Reply-To: <50A172AC.5090308@fhtw-berlin.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] Multicast requirements Thread-Index: Ac3BIdsAcmfjFtlfSim0461/KC8UwAABfDGg References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> From: "Zuniga, Juan Carlos" To: "Thomas C. Schmidt" , "Peter McCann" X-OriginalArrivalTime: 12 Nov 2012 22:51:48.0544 (UTC) FILETIME=[4C3B9C00:01CDC128] Cc: Stig Venaas , Behcet Sarikaya , dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:51:50 -0000 I believe the purpose of the discussion was to propose some requirement text for draft-ietf-dmm-requirements, rather than getting in the solution space. I propose the following: Requirement: DMM solutions SHOULD support multicast services. In case the solution does not address multicast, a justification MUST be provided for the omission of multicast from the solution. Motivation: The purpose of this requirement is to encourage people to consider the impacts of running multicast services in a DMM environment from the beginning of the development, thereby avoiding the need to make protocol extensions in the future to support this kind of functionality. Regards, Juan Carlos > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Thomas C. Schmidt > Sent: Monday, November 12, 2012 5:06 PM > To: Peter McCann > Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements >=20 > Hi Pete, >=20 > things would be simple, if topology were as described. >=20 > Let's wait what dmm is birthing out ... and continue discussion then. > In > any case, complex and incompatible "grand new schemes" do not appear to > make much sense. >=20 > Cheers, >=20 > Thomas >=20 > On 12.11.2012 22:53, Peter McCann wrote: > > In the DMM case my assumption is that the anchor points are closer > > to the access routers and therefore are very likely to be in the same > > administrative domain. In these cases, joining the multicast group > > directly from the access router gives you the same access to the same > > multicast streams and so tunneling the multicast packets won't be > > necessary. > > > > -Pete > > > > Thomas C. Schmidt wrote: > >> Dear Pete, > >> > >> multicast mobility management is a route adaptation problem. As in > the > >> unicast case, mobility can only be treated by routing dynamics in > >> trivial cases (re-connect of a tunnel, re-association with next > hop). > >> Otherwise it is unwise to delegate mobility adaptation to routing > >> protocols (-> OSPF, BGP ...). > >> > >> Accordingly, if DMM distributes mobility operations, handover > >> management should foresee easy interconnects to previous > distribution > >> trees - both for receivers and for mobile multicast sources. > >> > >> I guess, if DMM people are careful, this is not a world-class item > and > >> can be treated along the lines of unicast solutions - an isolated > >> multicast protocol treatment (as has been previously proposed from > >> MULTIMOB folks) seems inappropriate. In core PMIP, multicast > treatment > >> has turned out to work out simply (-> RFC6224). > >> > >> Thus my argument: talk to the multicast guys before adopting a > >> solution ... and make the rest an easy game. > >> > >> Cheers, > >> > >> Thomas > >> > >> On 12.11.2012 21:39, Peter McCann wrote: > >>> jouni korhonen wrote: > >>>> Folks, > >>>> > >>>> This mail is to kick off the discussion on multicast > requirement(s) > >>>> for the draft-ietf-dmm-requirements-02 document. I hope we can > nail > >>>> down the essential multicast requirement(s) as soon as possible. > >>> > >>> To me, multicast in a DMM environment means joining multicast > groups > >>> directly from access routers. It means re-joining the multicast > tree > >>> from a new access router after handover. I would hope that we can > use > >>> existing MLD protocols between the MN and its first hop AR to > >>> accomplish this. > >>> > >>> -Pete > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > > > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From schmidt@fhtw-berlin.de Mon Nov 12 15:03:23 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BCA21F86B8 for ; Mon, 12 Nov 2012 15:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9KsyheRVywk for ; Mon, 12 Nov 2012 15:03:16 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1A21F869C for ; Mon, 12 Nov 2012 15:03:16 -0800 (PST) Envelope-to: dmm@ietf.org Received: from g231108188.adsl.alicedsl.de ([92.231.108.188] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1TY32B-000Pdr-B3; Tue, 13 Nov 2012 00:03:15 +0100 Message-ID: <50A18032.5060301@fhtw-berlin.de> Date: Tue, 13 Nov 2012 00:03:14 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Zuniga, Juan Carlos" References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: dmm@ietf.org Cc: Stig Venaas , Behcet Sarikaya , Peter McCann , dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:03:23 -0000 Hi Juan Carlos, this all sounds very abstract and more from an administrative point of view. Point is (and relevant arguments always have an understanding of the solution space) that some routing scenarios are easy to accomodate multicast and others aren't. My major point was: If DMM picks a solution, people should just think wider (including multicast) and then there is no need to come up with weirdo type of "solutions" in Multimob that are only justified by unicast solutions being ignorant of other use cases. In other words: Rather be clever than smart. Cheers, Thomas On 12.11.2012 23:51, Zuniga, Juan Carlos wrote: > I believe the purpose of the discussion was to propose some requirement > text for draft-ietf-dmm-requirements, rather than getting in the > solution space. I propose the following: > > > Requirement: DMM solutions SHOULD support multicast services. In case > the solution > does not address multicast, a justification MUST be provided > for the > omission of multicast from the solution. > > Motivation: The purpose of this requirement is to encourage people to > consider the impacts of running multicast services in a DMM > environment > from the beginning of the development, thereby avoiding the > need to > make protocol extensions in the future to support this kind of > functionality. > > > Regards, > > Juan Carlos > >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Thomas C. Schmidt >> Sent: Monday, November 12, 2012 5:06 PM >> To: Peter McCann >> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org >> Subject: Re: [DMM] Multicast requirements >> >> Hi Pete, >> >> things would be simple, if topology were as described. >> >> Let's wait what dmm is birthing out ... and continue discussion then. >> In >> any case, complex and incompatible "grand new schemes" do not appear > to >> make much sense. >> >> Cheers, >> >> Thomas >> >> On 12.11.2012 22:53, Peter McCann wrote: >>> In the DMM case my assumption is that the anchor points are closer >>> to the access routers and therefore are very likely to be in the > same >>> administrative domain. In these cases, joining the multicast group >>> directly from the access router gives you the same access to the > same >>> multicast streams and so tunneling the multicast packets won't be >>> necessary. >>> >>> -Pete >>> >>> Thomas C. Schmidt wrote: >>>> Dear Pete, >>>> >>>> multicast mobility management is a route adaptation problem. As in >> the >>>> unicast case, mobility can only be treated by routing dynamics in >>>> trivial cases (re-connect of a tunnel, re-association with next >> hop). >>>> Otherwise it is unwise to delegate mobility adaptation to routing >>>> protocols (-> OSPF, BGP ...). >>>> >>>> Accordingly, if DMM distributes mobility operations, handover >>>> management should foresee easy interconnects to previous >> distribution >>>> trees - both for receivers and for mobile multicast sources. >>>> >>>> I guess, if DMM people are careful, this is not a world-class item >> and >>>> can be treated along the lines of unicast solutions - an isolated >>>> multicast protocol treatment (as has been previously proposed from >>>> MULTIMOB folks) seems inappropriate. In core PMIP, multicast >> treatment >>>> has turned out to work out simply (-> RFC6224). >>>> >>>> Thus my argument: talk to the multicast guys before adopting a >>>> solution ... and make the rest an easy game. >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On 12.11.2012 21:39, Peter McCann wrote: >>>>> jouni korhonen wrote: >>>>>> Folks, >>>>>> >>>>>> This mail is to kick off the discussion on multicast >> requirement(s) >>>>>> for the draft-ietf-dmm-requirements-02 document. I hope we can >> nail >>>>>> down the essential multicast requirement(s) as soon as possible. >>>>> >>>>> To me, multicast in a DMM environment means joining multicast >> groups >>>>> directly from access routers. It means re-joining the multicast >> tree >>>>> from a new access router after handover. I would hope that we can >> use >>>>> existing MLD protocols between the MN and its first hop AR to >>>>> accomplish this. >>>>> >>>>> -Pete >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >>> >>> >>> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From sfigueiredo@av.it.pt Mon Nov 12 15:10:31 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882121F852D for ; Mon, 12 Nov 2012 15:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPPu4v9GmIhs for ; Mon, 12 Nov 2012 15:10:30 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4F321F8502 for ; Mon, 12 Nov 2012 15:10:29 -0800 (PST) Received: from [2.81.129.50] (account sfigueiredo@av.it.pt HELO [192.168.10.8]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67005669 for dmm@ietf.org; Mon, 12 Nov 2012 23:10:28 +0000 Message-ID: <50A181E4.6070901@av.it.pt> Date: Mon, 12 Nov 2012 23:10:28 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dmm@ietf.org References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:10:31 -0000 Hi Juan Carlos, On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: > I believe the purpose of the discussion was to propose some requirement > text for draft-ietf-dmm-requirements, rather than getting in the > solution space. We're inline here. > I propose the following: > > > Requirement: DMM solutions SHOULD support multicast services. In case > the solution > does not address multicast, a justification MUST be provided > for the > omission of multicast from the solution. > > Motivation: The purpose of this requirement is to encourage people to > consider the impacts of running multicast services in a DMM > environment > from the beginning of the development, thereby avoiding the > need to > make protocol extensions in the future to support this kind of > functionality. This requirement paves the way for the ones I'm reviewing with Seil, and keeps IP multicast position, i.e. as a "module" that may or not be included by operators. Although the motivation is clear, this seems as a light requirement to be achieved, in the sense that it can be easily transposed. Do you have in mind what is a valid "justification" for not addressing multicast? BR, Sérgio > > Regards, > > Juan Carlos > >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Thomas C. Schmidt >> Sent: Monday, November 12, 2012 5:06 PM >> To: Peter McCann >> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org >> Subject: Re: [DMM] Multicast requirements >> >> Hi Pete, >> >> things would be simple, if topology were as described. >> >> Let's wait what dmm is birthing out ... and continue discussion then. >> In >> any case, complex and incompatible "grand new schemes" do not appear > to >> make much sense. >> >> Cheers, >> >> Thomas >> >> On 12.11.2012 22:53, Peter McCann wrote: >>> In the DMM case my assumption is that the anchor points are closer >>> to the access routers and therefore are very likely to be in the > same >>> administrative domain. In these cases, joining the multicast group >>> directly from the access router gives you the same access to the > same >>> multicast streams and so tunneling the multicast packets won't be >>> necessary. >>> >>> -Pete >>> >>> Thomas C. Schmidt wrote: >>>> Dear Pete, >>>> >>>> multicast mobility management is a route adaptation problem. As in >> the >>>> unicast case, mobility can only be treated by routing dynamics in >>>> trivial cases (re-connect of a tunnel, re-association with next >> hop). >>>> Otherwise it is unwise to delegate mobility adaptation to routing >>>> protocols (-> OSPF, BGP ...). >>>> >>>> Accordingly, if DMM distributes mobility operations, handover >>>> management should foresee easy interconnects to previous >> distribution >>>> trees - both for receivers and for mobile multicast sources. >>>> >>>> I guess, if DMM people are careful, this is not a world-class item >> and >>>> can be treated along the lines of unicast solutions - an isolated >>>> multicast protocol treatment (as has been previously proposed from >>>> MULTIMOB folks) seems inappropriate. In core PMIP, multicast >> treatment >>>> has turned out to work out simply (-> RFC6224). >>>> >>>> Thus my argument: talk to the multicast guys before adopting a >>>> solution ... and make the rest an easy game. >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On 12.11.2012 21:39, Peter McCann wrote: >>>>> jouni korhonen wrote: >>>>>> Folks, >>>>>> >>>>>> This mail is to kick off the discussion on multicast >> requirement(s) >>>>>> for the draft-ietf-dmm-requirements-02 document. I hope we can >> nail >>>>>> down the essential multicast requirement(s) as soon as possible. >>>>> To me, multicast in a DMM environment means joining multicast >> groups >>>>> directly from access routers. It means re-joining the multicast >> tree >>>>> from a new access router after handover. I would hope that we can >> use >>>>> existing MLD protocols between the MN and its first hop AR to >>>>> accomplish this. >>>>> >>>>> -Pete >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>> >>> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Mon Nov 12 15:20:19 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCDF21F8598 for ; Mon, 12 Nov 2012 15:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qgua5g-7CAv for ; Mon, 12 Nov 2012 15:20:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F78521F847D for ; Mon, 12 Nov 2012 15:20:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR68640; Mon, 12 Nov 2012 23:20:09 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 23:19:59 +0000 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 23:20:06 +0000 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.206]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 07:19:54 +0800 From: h chan To: Seil Jeon , Peter McCann Thread-Topic: [DMM] Multicast requirements Thread-Index: AQDpvfVQAxw1oKkvDEamwV8hZo2UugFDovgtAWOj9LkCV0872ZmG26vwgAAKdUA= Date: Mon, 12 Nov 2012 23:19:53 +0000 Message-ID: <6E31144C030982429702B11D6746B98C363D25D8@SZXEML510-MBS.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <014801cdc127$e9b9b6c0$bd2d2440$@av.it.pt> In-Reply-To: <014801cdc127$e9b9b6c0$bd2d2440$@av.it.pt> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Stig Venaas' , 'Behcet Sarikaya' , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:20:19 -0000 That is right. I had discussed with Seil, and I understand that he will com= e up with his proposed text soon.=20 H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Seil = Jeon Sent: Monday, November 12, 2012 4:49 PM To: Peter McCann Cc: 'Stig Venaas'; 'Behcet Sarikaya'; dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Pete, That might be one of them we can take on DMM. Imagine, depending on deployment of existing IP multicasting standard entities, we can think of various use cases as presented in http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. Direct routing cannot be applied in every scenario. After I came back from the trip, we (me and Sergio) have been working on this with priority. After carefully reviewing the requirement from the use cases, we'll announce it soon. Regards, Seil -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Peter McCann Sent: Monday, November 12, 2012 9:53 PM To: Thomas C. Schmidt Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directl= y from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: > Dear Pete, >=20 > multicast mobility management is a route adaptation problem. As in the=20 > unicast case, mobility can only be treated by routing dynamics in=20 > trivial cases (re-connect of a tunnel, re-association with next hop). > Otherwise it is unwise to delegate mobility adaptation to routing=20 > protocols (-> OSPF, BGP ...). >=20 > Accordingly, if DMM distributes mobility operations, handover=20 > management should foresee easy interconnects to previous distribution=20 > trees - both for receivers and for mobile multicast sources. >=20 > I guess, if DMM people are careful, this is not a world-class item and=20 > can be treated along the lines of unicast solutions - an isolated=20 > multicast protocol treatment (as has been previously proposed from=20 > MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment=20 > has turned out to work out simply (-> RFC6224). >=20 > Thus my argument: talk to the multicast guys before adopting a=20 > solution ... and make the rest an easy game. >=20 > Cheers, >=20 > Thomas >=20 > On 12.11.2012 21:39, Peter McCann wrote: >> jouni korhonen wrote: >>> Folks, >>>=20 >>> This mail is to kick off the discussion on multicast requirement(s)=20 >>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail=20 >>> down the essential multicast requirement(s) as soon as possible. >>=20 >> To me, multicast in a DMM environment means joining multicast groups=20 >> directly from access routers. It means re-joining the multicast tree=20 >> from a new access router after handover. I would hope that we can=20 >> use existing MLD protocols between the MN and its first hop AR to=20 >> accomplish this. >>=20 >> -Pete >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From JuanCarlos.Zuniga@InterDigital.com Mon Nov 12 15:20:40 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C8121F8767 for ; Mon, 12 Nov 2012 15:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RsB9l6GTxmL for ; Mon, 12 Nov 2012 15:20:39 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D4EBD21F861C for ; Mon, 12 Nov 2012 15:20:38 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 18:20:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 18:20:36 -0500 Message-ID: In-Reply-To: <50A181E4.6070901@av.it.pt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] Multicast requirements Thread-Index: Ac3BKuzf/uErFgW5TUSFN5TbjobiCwAAFqCQ References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com><50A172AC.5090308@fhtw-berlin.de> <50A181E4.6070901@av.it.pt> From: "Zuniga, Juan Carlos" To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= , X-OriginalArrivalTime: 12 Nov 2012 23:20:37.0973 (UTC) FILETIME=[530D8850:01CDC12C] Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:20:40 -0000 Hi Sergio, > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > S=E9rgio Figueiredo > Sent: Monday, November 12, 2012 6:10 PM > To: dmm@ietf.org > Subject: Re: [DMM] Multicast requirements >=20 > Hi Juan Carlos, >=20 > On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: > > I believe the purpose of the discussion was to propose some > requirement > > text for draft-ietf-dmm-requirements, rather than getting in the > > solution space. > We're inline here. [JCZ] Good. We don't have time much time for religious battles, so = better to propose text soon and get the requirements finalized. >=20 > > I propose the following: > > > > > > Requirement: DMM solutions SHOULD support multicast services. In = case > > the solution > > does not address multicast, a justification MUST be > provided > > for the > > omission of multicast from the solution. > > > > Motivation: The purpose of this requirement is to encourage people = to > > consider the impacts of running multicast services in a > DMM > > environment > > from the beginning of the development, thereby avoiding > the > > need to > > make protocol extensions in the future to support this > kind of > > functionality. > This requirement paves the way for the ones I'm reviewing with Seil, > and > keeps IP multicast position, i.e. as a "module" that may or not be > included by operators. > [JCZ] I agree. However, talking about "modules" seems to me getting into = the solution space, which should not be done in the requirements. >=20 > Although the motivation is clear, this seems as a light requirement to > be achieved, in the sense that it can be easily transposed. Do you = have > in mind what is a valid "justification" for not addressing multicast? > [JCZ] I don't have one and I believe it is up to the solution proponents = to write one in case they do not support multicast. If they do, a = justification would not be needed. The reason for using SHOULD is to = allow for people that believe this is not needed to still bring their = proposals forward, but giving the reasoning why they believe this is not = needed. Regards, Juan Carlos >=20 > BR, > S=E9rgio > > > > Regards, > > > > Juan Carlos > > > >> -----Original Message----- > >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf > Of > >> Thomas C. Schmidt > >> Sent: Monday, November 12, 2012 5:06 PM > >> To: Peter McCann > >> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > >> Subject: Re: [DMM] Multicast requirements > >> > >> Hi Pete, > >> > >> things would be simple, if topology were as described. > >> > >> Let's wait what dmm is birthing out ... and continue discussion > then. > >> In > >> any case, complex and incompatible "grand new schemes" do not = appear > > to > >> make much sense. > >> > >> Cheers, > >> > >> Thomas > >> > >> On 12.11.2012 22:53, Peter McCann wrote: > >>> In the DMM case my assumption is that the anchor points are closer > >>> to the access routers and therefore are very likely to be in the > > same > >>> administrative domain. In these cases, joining the multicast = group > >>> directly from the access router gives you the same access to the > > same > >>> multicast streams and so tunneling the multicast packets won't be > >>> necessary. > >>> > >>> -Pete > >>> > >>> Thomas C. Schmidt wrote: > >>>> Dear Pete, > >>>> > >>>> multicast mobility management is a route adaptation problem. As = in > >> the > >>>> unicast case, mobility can only be treated by routing dynamics in > >>>> trivial cases (re-connect of a tunnel, re-association with next > >> hop). > >>>> Otherwise it is unwise to delegate mobility adaptation to routing > >>>> protocols (-> OSPF, BGP ...). > >>>> > >>>> Accordingly, if DMM distributes mobility operations, handover > >>>> management should foresee easy interconnects to previous > >> distribution > >>>> trees - both for receivers and for mobile multicast sources. > >>>> > >>>> I guess, if DMM people are careful, this is not a world-class = item > >> and > >>>> can be treated along the lines of unicast solutions - an isolated > >>>> multicast protocol treatment (as has been previously proposed = from > >>>> MULTIMOB folks) seems inappropriate. In core PMIP, multicast > >> treatment > >>>> has turned out to work out simply (-> RFC6224). > >>>> > >>>> Thus my argument: talk to the multicast guys before adopting a > >>>> solution ... and make the rest an easy game. > >>>> > >>>> Cheers, > >>>> > >>>> Thomas > >>>> > >>>> On 12.11.2012 21:39, Peter McCann wrote: > >>>>> jouni korhonen wrote: > >>>>>> Folks, > >>>>>> > >>>>>> This mail is to kick off the discussion on multicast > >> requirement(s) > >>>>>> for the draft-ietf-dmm-requirements-02 document. I hope we can > >> nail > >>>>>> down the essential multicast requirement(s) as soon as = possible. > >>>>> To me, multicast in a DMM environment means joining multicast > >> groups > >>>>> directly from access routers. It means re-joining the multicast > >> tree > >>>>> from a new access router after handover. I would hope that we > can > >> use > >>>>> existing MLD protocols between the MN and its first hop AR to > >>>>> accomplish this. > >>>>> > >>>>> -Pete > >>>>> > >>>>> _______________________________________________ > >>>>> dmm mailing list > >>>>> dmm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>> > >>> > >>> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From sarikaya2012@gmail.com Mon Nov 12 15:34:47 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7214521F878E for ; Mon, 12 Nov 2012 15:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHpn2r7EQ3-A for ; Mon, 12 Nov 2012 15:34:47 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E27F721F878C for ; Mon, 12 Nov 2012 15:34:46 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so10966660iec.31 for ; Mon, 12 Nov 2012 15:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9D76ITng1Mlnlr+bhTlvMMLoxMczD51wQletXQGc2kM=; b=v7XuvXswlVKxVl/Dx3w1wCRFFuhFOD9y8eXB/tXBatZsXtTh6BFf4mxdXEFUSjFGUK HTukHphNNYn4ybcMBVeFjlR870Oa9J4PuPkfkG6eQBieeqlicFLWDTK7f/KxEqoOmwO1 Pm/b5ZUCc6g0lBfKAcJszYbI3UWQmullf+w9o/sIY0N1/9LRvhA7jQIaOX1Gcy+8dA9a 9vby2W0DYNsH77UwL52RGwrZFWJWrJeCmQlxxk28X0rUGTy0jQkNZEvuKufV2Ezht6A4 fXUfNzudajrqsbEGHWMF/1lrC/2cEZErPk26vNmPXgx5XBsK7hTh1GZIft9PWG4TML7h 4SEw== MIME-Version: 1.0 Received: by 10.50.173.37 with SMTP id bh5mr9641999igc.45.1352763286124; Mon, 12 Nov 2012 15:34:46 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 12 Nov 2012 15:34:46 -0800 (PST) In-Reply-To: References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> Date: Mon, 12 Nov 2012 17:34:46 -0600 Message-ID: From: Behcet Sarikaya To: "Zuniga, Juan Carlos" Content-Type: text/plain; charset=ISO-8859-1 Cc: Stig Venaas , Behcet Sarikaya , Peter McCann , dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:34:47 -0000 Hi Juan Carlos, On Mon, Nov 12, 2012 at 4:51 PM, Zuniga, Juan Carlos wrote: > I believe the purpose of the discussion was to propose some requirement > text for draft-ietf-dmm-requirements, rather than getting in the > solution space. I propose the following: > Absolutely, let's not lose time on this. > Requirement: DMM solutions SHOULD support multicast services. In case > the solution > does not address multicast, a justification MUST be provided > for the > omission of multicast from the solution. OK. Justification could be out of scope. > > Motivation: The purpose of this requirement is to encourage people to > consider the impacts of running multicast services in a DMM > environment > from the beginning of the development, thereby avoiding the > need to > make protocol extensions in the future to support this kind of > functionality. > Agreed. Regards, Behcet From sfigueiredo@av.it.pt Mon Nov 12 15:46:06 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C675621F86CE for ; Mon, 12 Nov 2012 15:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT+Y-vSwQO2B for ; Mon, 12 Nov 2012 15:46:06 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 90B3D21F86D3 for ; Mon, 12 Nov 2012 15:46:05 -0800 (PST) Received: from [2.81.129.50] (account sfigueiredo@av.it.pt HELO [192.168.10.8]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67005954; Mon, 12 Nov 2012 23:46:04 +0000 Message-ID: <50A18A3B.5070403@av.it.pt> Date: Mon, 12 Nov 2012 23:46:03 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Zuniga, Juan Carlos" References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com><50A172AC.5090308@fhtw-berlin.de> <50A181E4.6070901@av.it.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:46:06 -0000 Hi Juan Carlos, Don't get me wrong. Although I use the word "module" I'm not referring to solution details. What I was referring to was to the optional deployment of (at least) multicast discovery / routing protocols, which this requirement keeps as is if I understood it correctly. Cheers, Sérgio On 11/12/2012 11:20 PM, Zuniga, Juan Carlos wrote: > Hi Sergio, > >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Sérgio Figueiredo >> Sent: Monday, November 12, 2012 6:10 PM >> To: dmm@ietf.org >> Subject: Re: [DMM] Multicast requirements >> >> Hi Juan Carlos, >> >> On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: >>> I believe the purpose of the discussion was to propose some >> requirement >>> text for draft-ietf-dmm-requirements, rather than getting in the >>> solution space. >> We're inline here. > [JCZ] Good. We don't have time much time for religious battles, so better to propose text soon and get the requirements finalized. >>> I propose the following: >>> >>> >>> Requirement: DMM solutions SHOULD support multicast services. In case >>> the solution >>> does not address multicast, a justification MUST be >> provided >>> for the >>> omission of multicast from the solution. >>> >>> Motivation: The purpose of this requirement is to encourage people to >>> consider the impacts of running multicast services in a >> DMM >>> environment >>> from the beginning of the development, thereby avoiding >> the >>> need to >>> make protocol extensions in the future to support this >> kind of >>> functionality. >> This requirement paves the way for the ones I'm reviewing with Seil, >> and >> keeps IP multicast position, i.e. as a "module" that may or not be >> included by operators. >> > [JCZ] I agree. However, talking about "modules" seems to me getting into the solution space, which should not be done in the requirements. >> Although the motivation is clear, this seems as a light requirement to >> be achieved, in the sense that it can be easily transposed. Do you have >> in mind what is a valid "justification" for not addressing multicast? >> > [JCZ] I don't have one and I believe it is up to the solution proponents to write one in case they do not support multicast. If they do, a justification would not be needed. The reason for using SHOULD is to allow for people that believe this is not needed to still bring their proposals forward, but giving the reasoning why they believe this is not needed. > > Regards, > > Juan Carlos >> BR, >> Sérgio >>> Regards, >>> >>> Juan Carlos >>> >>>> -----Original Message----- >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf >> Of >>>> Thomas C. Schmidt >>>> Sent: Monday, November 12, 2012 5:06 PM >>>> To: Peter McCann >>>> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org >>>> Subject: Re: [DMM] Multicast requirements >>>> >>>> Hi Pete, >>>> >>>> things would be simple, if topology were as described. >>>> >>>> Let's wait what dmm is birthing out ... and continue discussion >> then. >>>> In >>>> any case, complex and incompatible "grand new schemes" do not appear >>> to >>>> make much sense. >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On 12.11.2012 22:53, Peter McCann wrote: >>>>> In the DMM case my assumption is that the anchor points are closer >>>>> to the access routers and therefore are very likely to be in the >>> same >>>>> administrative domain. In these cases, joining the multicast group >>>>> directly from the access router gives you the same access to the >>> same >>>>> multicast streams and so tunneling the multicast packets won't be >>>>> necessary. >>>>> >>>>> -Pete >>>>> >>>>> Thomas C. Schmidt wrote: >>>>>> Dear Pete, >>>>>> >>>>>> multicast mobility management is a route adaptation problem. As in >>>> the >>>>>> unicast case, mobility can only be treated by routing dynamics in >>>>>> trivial cases (re-connect of a tunnel, re-association with next >>>> hop). >>>>>> Otherwise it is unwise to delegate mobility adaptation to routing >>>>>> protocols (-> OSPF, BGP ...). >>>>>> >>>>>> Accordingly, if DMM distributes mobility operations, handover >>>>>> management should foresee easy interconnects to previous >>>> distribution >>>>>> trees - both for receivers and for mobile multicast sources. >>>>>> >>>>>> I guess, if DMM people are careful, this is not a world-class item >>>> and >>>>>> can be treated along the lines of unicast solutions - an isolated >>>>>> multicast protocol treatment (as has been previously proposed from >>>>>> MULTIMOB folks) seems inappropriate. In core PMIP, multicast >>>> treatment >>>>>> has turned out to work out simply (-> RFC6224). >>>>>> >>>>>> Thus my argument: talk to the multicast guys before adopting a >>>>>> solution ... and make the rest an easy game. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Thomas >>>>>> >>>>>> On 12.11.2012 21:39, Peter McCann wrote: >>>>>>> jouni korhonen wrote: >>>>>>>> Folks, >>>>>>>> >>>>>>>> This mail is to kick off the discussion on multicast >>>> requirement(s) >>>>>>>> for the draft-ietf-dmm-requirements-02 document. I hope we can >>>> nail >>>>>>>> down the essential multicast requirement(s) as soon as possible. >>>>>>> To me, multicast in a DMM environment means joining multicast >>>> groups >>>>>>> directly from access routers. It means re-joining the multicast >>>> tree >>>>>>> from a new access router after handover. I would hope that we >> can >>>> use >>>>>>> existing MLD protocols between the MN and its first hop AR to >>>>>>> accomplish this. >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From JuanCarlos.Zuniga@InterDigital.com Mon Nov 12 16:10:39 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3521F86B8 for ; Mon, 12 Nov 2012 16:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2RLqgkS06Eq for ; Mon, 12 Nov 2012 16:10:39 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9EBC21F8614 for ; Mon, 12 Nov 2012 16:10:38 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 19:10:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 19:10:36 -0500 Message-ID: In-Reply-To: <50A18A3B.5070403@av.it.pt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] Multicast requirements Thread-Index: Ac3BL+LtkB4dlhAIRrO4/R5GidJ0PQAAw5sA References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com><50A172AC.5090308@fhtw-berlin.de> <50A181E4.6070901@av.it.pt> <50A18A3B.5070403@av.it.pt> From: "Zuniga, Juan Carlos" To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= X-OriginalArrivalTime: 13 Nov 2012 00:10:37.0908 (UTC) FILETIME=[4F274940:01CDC133] Cc: dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:10:40 -0000 Hi Sergio, I wasn't implying that you were proposing a solution. I just meant that = using the word module was perhaps not appropriate for drafting the = requirement. Having said that, if you believe there is some wording to = that we can propose to reflect your thinking in a clear requirement, = please suggest it. Regards, Juan Carlos > -----Original Message----- > From: S=E9rgio Figueiredo [mailto:sfigueiredo@av.it.pt] > Sent: Monday, November 12, 2012 6:46 PM > To: Zuniga, Juan Carlos > Cc: dmm@ietf.org > Subject: Re: [DMM] Multicast requirements >=20 > Hi Juan Carlos, >=20 > Don't get me wrong. Although I use the word "module" I'm not referring > to solution details. What I was referring to was to the optional > deployment of (at least) multicast discovery / routing protocols, = which > this requirement keeps as is if I understood it correctly. >=20 > Cheers, > S=E9rgio >=20 > On 11/12/2012 11:20 PM, Zuniga, Juan Carlos wrote: > > Hi Sergio, > > > >> -----Original Message----- > >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf > Of > >> S=E9rgio Figueiredo > >> Sent: Monday, November 12, 2012 6:10 PM > >> To: dmm@ietf.org > >> Subject: Re: [DMM] Multicast requirements > >> > >> Hi Juan Carlos, > >> > >> On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: > >>> I believe the purpose of the discussion was to propose some > >> requirement > >>> text for draft-ietf-dmm-requirements, rather than getting in the > >>> solution space. > >> We're inline here. > > [JCZ] Good. We don't have time much time for religious battles, so > better to propose text soon and get the requirements finalized. > >>> I propose the following: > >>> > >>> > >>> Requirement: DMM solutions SHOULD support multicast services. In > case > >>> the solution > >>> does not address multicast, a justification MUST be > >> provided > >>> for the > >>> omission of multicast from the solution. > >>> > >>> Motivation: The purpose of this requirement is to encourage people > to > >>> consider the impacts of running multicast services in = a > >> DMM > >>> environment > >>> from the beginning of the development, thereby = avoiding > >> the > >>> need to > >>> make protocol extensions in the future to support this > >> kind of > >>> functionality. > >> This requirement paves the way for the ones I'm reviewing with = Seil, > >> and > >> keeps IP multicast position, i.e. as a "module" that may or not be > >> included by operators. > >> > > [JCZ] I agree. However, talking about "modules" seems to me getting > into the solution space, which should not be done in the requirements. > >> Although the motivation is clear, this seems as a light requirement > to > >> be achieved, in the sense that it can be easily transposed. Do you > have > >> in mind what is a valid "justification" for not addressing > multicast? > >> > > [JCZ] I don't have one and I believe it is up to the solution > proponents to write one in case they do not support multicast. If they > do, a justification would not be needed. The reason for using SHOULD = is > to allow for people that believe this is not needed to still bring > their proposals forward, but giving the reasoning why they believe = this > is not needed. > > > > Regards, > > > > Juan Carlos > >> BR, > >> S=E9rgio > >>> Regards, > >>> > >>> Juan Carlos > >>> > >>>> -----Original Message----- > >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On = Behalf > >> Of > >>>> Thomas C. Schmidt > >>>> Sent: Monday, November 12, 2012 5:06 PM > >>>> To: Peter McCann > >>>> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > >>>> Subject: Re: [DMM] Multicast requirements > >>>> > >>>> Hi Pete, > >>>> > >>>> things would be simple, if topology were as described. > >>>> > >>>> Let's wait what dmm is birthing out ... and continue discussion > >> then. > >>>> In > >>>> any case, complex and incompatible "grand new schemes" do not > appear > >>> to > >>>> make much sense. > >>>> > >>>> Cheers, > >>>> > >>>> Thomas > >>>> > >>>> On 12.11.2012 22:53, Peter McCann wrote: > >>>>> In the DMM case my assumption is that the anchor points are > closer > >>>>> to the access routers and therefore are very likely to be in the > >>> same > >>>>> administrative domain. In these cases, joining the multicast > group > >>>>> directly from the access router gives you the same access to the > >>> same > >>>>> multicast streams and so tunneling the multicast packets won't = be > >>>>> necessary. > >>>>> > >>>>> -Pete > >>>>> > >>>>> Thomas C. Schmidt wrote: > >>>>>> Dear Pete, > >>>>>> > >>>>>> multicast mobility management is a route adaptation problem. As > in > >>>> the > >>>>>> unicast case, mobility can only be treated by routing dynamics > in > >>>>>> trivial cases (re-connect of a tunnel, re-association with next > >>>> hop). > >>>>>> Otherwise it is unwise to delegate mobility adaptation to > routing > >>>>>> protocols (-> OSPF, BGP ...). > >>>>>> > >>>>>> Accordingly, if DMM distributes mobility operations, handover > >>>>>> management should foresee easy interconnects to previous > >>>> distribution > >>>>>> trees - both for receivers and for mobile multicast sources. > >>>>>> > >>>>>> I guess, if DMM people are careful, this is not a world-class > item > >>>> and > >>>>>> can be treated along the lines of unicast solutions - an > isolated > >>>>>> multicast protocol treatment (as has been previously proposed > from > >>>>>> MULTIMOB folks) seems inappropriate. In core PMIP, multicast > >>>> treatment > >>>>>> has turned out to work out simply (-> RFC6224). > >>>>>> > >>>>>> Thus my argument: talk to the multicast guys before adopting a > >>>>>> solution ... and make the rest an easy game. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Thomas > >>>>>> > >>>>>> On 12.11.2012 21:39, Peter McCann wrote: > >>>>>>> jouni korhonen wrote: > >>>>>>>> Folks, > >>>>>>>> > >>>>>>>> This mail is to kick off the discussion on multicast > >>>> requirement(s) > >>>>>>>> for the draft-ietf-dmm-requirements-02 document. I hope we = can > >>>> nail > >>>>>>>> down the essential multicast requirement(s) as soon as > possible. > >>>>>>> To me, multicast in a DMM environment means joining multicast > >>>> groups > >>>>>>> directly from access routers. It means re-joining the > multicast > >>>> tree > >>>>>>> from a new access router after handover. I would hope that we > >> can > >>>> use > >>>>>>> existing MLD protocols between the MN and its first hop AR to > >>>>>>> accomplish this. > >>>>>>> > >>>>>>> -Pete > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> dmm mailing list > >>>>>>> dmm@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>> > >>>>> > >>>> _______________________________________________ > >>>> dmm mailing list > >>>> dmm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dmm > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm From k.pentikousis@huawei.com Tue Nov 13 06:49:41 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FB421F86CC for ; Tue, 13 Nov 2012 06:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3x+m+V-x-yN for ; Tue, 13 Nov 2012 06:49:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02721F85C0 for ; Tue, 13 Nov 2012 06:49:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT53654; Tue, 13 Nov 2012 14:49:31 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 14:49:18 +0000 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 14:49:26 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 22:49:17 +0800 From: Konstantinos Pentikousis To: "Zuniga, Juan Carlos" , "Thomas C. Schmidt" , Peter McCann Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwSxRzyFl17zuj0SrDo7gr/gA/pfn1QlA Date: Tue, 13 Nov 2012 14:49:15 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:49:41 -0000 Hi Juan Carlos, all, |Requirement: DMM solutions SHOULD support multicast services. In case |the solution does not address multicast, a justification MUST be provide= d |for the omission of multicast from the solution. I like this proposal. It appears to me to capture the essence of the reques= t to cover multicast in DMM. I would make it even shorter however: Requirement: DMM solutions SHOULD support multicast services. If a specific= DMM solution does not support multicast services, an explanation MUST be p= rovided. |Motivation: The purpose of this requirement is to encourage people to |consider the impacts of running multicast services in a DMM environment |from the beginning of the development, thereby avoiding the need to |make protocol extensions in the future to support this kind of functiona= lity. I second the motivation part, although I would also rephrase it a bit: Motivation: From an operational perspective, if a network domain provides m= ulticast services already, the deployment of a DMM solution should not impe= de the delivery of such services. From a protocol perspective, a DMM soluti= on should aim to address unicast as well as multicast in a coherent manner,= thus avoiding the recurrence of "multicast add-ons", as is the case with t= oday's mobility management solutions. Best Regards, Kostas From k.pentikousis@huawei.com Tue Nov 13 07:07:45 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A250921F86D3 for ; Tue, 13 Nov 2012 07:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZllOCuJNUv5u for ; Tue, 13 Nov 2012 07:07:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C921F86A2 for ; Tue, 13 Nov 2012 07:07:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT54941; Tue, 13 Nov 2012 15:07:37 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:07:28 +0000 Received: from SZXEML443-HUB.china.huawei.com (10.82.67.181) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:07:36 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by SZXEML443-HUB.china.huawei.com ([10.82.67.181]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 23:07:29 +0800 From: Konstantinos Pentikousis To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= , "dmm@ietf.org" Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwSxRzyFl17zuj0SrDo7gr/gA/pfn2zYA Date: Tue, 13 Nov 2012 15:07:29 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EE61A@szxeml545-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <50A181E4.6070901@av.it.pt> In-Reply-To: <50A181E4.6070901@av.it.pt> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:07:45 -0000 Hi Sergio, all, |Although the motivation is clear, this seems as a light requirement to |be achieved, in the sense that it can be easily transposed. Do you |have in mind what is a valid "justification" for not addressing multicas= t? I think we already discussed this in Atlanta. Multicast support should not = become yet-another-reason to delay DMM solutions, let alone the requirement= s document. And, to be honest, if I just "think wider", REQ3, 4, and 5 (IPv6, existing = mobility protocols, and compatibility) should be sufficient to cover "multi= cast support". I copy-paste from the respective motivation sections: "DMM s= olutions SHOULD target IPv6 as the primary deployment environment." [..] "A= DMM solution SHOULD first consider reusing and extending IETF-standardized= protocols before specifying new protocols." I think these two would in gen= eral cover also stuff developed in multimob. And, as if this is not suffici= ent, then REQ5 should close this discussion: "The DMM solution MUST be able= to co-exist with existing network deployments and end hosts." Therefore, i= f you already have multicast services in your domain, the DMM solution shou= ld handle them. Now, we did agree in Atlanta to have a quick resolution wrt to multicast, a= nd perhaps explicitly add "REQ7: Multicast support", if the multimob folks = can deal with this in an expedient manner. If not, imo, REQs 3/4/5 should m= ore than suffice to cover "multicast support in DMM". Best Regards, Kostas From k.pentikousis@huawei.com Tue Nov 13 07:18:58 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1524621F86A9 for ; Tue, 13 Nov 2012 07:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrcrDNatwZJl for ; Tue, 13 Nov 2012 07:18:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7F21F86AA for ; Tue, 13 Nov 2012 07:18:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT55834; Tue, 13 Nov 2012 15:18:52 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:18:41 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:18:50 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 23:18:45 +0800 From: Konstantinos Pentikousis To: "sarikaya@ieee.org" , jouni korhonen Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwSHdzyFl17zuj0SrDo7gr/gA/pfn4Luw Date: Tue, 13 Nov 2012 15:18:44 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EE627@szxeml545-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:18:58 -0000 Hi, |I can tell you that in Multimob meeting in Atlanta, we have not |discussed any requirements. Indeed. I was at the multicast meeting in Atlanta, well, the better part of= it, and I do not recall any excitement about working on the requirements f= or multicast support in DMM. On the contrary, as I'm sure the minutes will = reflect, the discussion went on about "current issues" in mulitmob drafts. Multicast is very important. Moving forward with the work in DMM is also ve= ry important. I hope we do not stall the progress on DMM requirements till = Orlando... Best Regards, Kostas From k.pentikousis@huawei.com Tue Nov 13 07:36:27 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C321F86AA for ; Tue, 13 Nov 2012 07:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfY0Gc4PF-36 for ; Tue, 13 Nov 2012 07:36:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93FBD21F86B6 for ; Tue, 13 Nov 2012 07:36:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT57059; Tue, 13 Nov 2012 15:36:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:36:11 +0000 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:36:19 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 23:36:11 +0800 From: Konstantinos Pentikousis To: "Thomas C. Schmidt" , Peter McCann Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwSHdzyFl17zuj0SrDo7gr/gA/pfn4pgg Date: Tue, 13 Nov 2012 15:36:10 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EE64F@szxeml545-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> In-Reply-To: <50A16AE0.70101@fhtw-berlin.de> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:36:27 -0000 Hi Thomas, all, |Thus my argument: talk to the multicast guys before adopting a |solution... and make the rest an easy game. Somehow I got the feeling that it was the "multicast guys" who wanted to pa= rtake in DMM, not the other way around. Therefore, the challenge is on thos= e guys to come up with a coherent DMM requirement and motivation text, in l= ine with the rest of the draft, proportional to the significance of the mat= ter and with respect to the other 6 REQs. There is already a proposal by Juan Carlos or, if you will, the one I edite= d, on the floor. Please feel free to propose specific changes, keeping in m= ind that the current average number of words for each of the requirements i= s 48 (min: REQ4 with 15 words; max: REQ5 with 79 words). Best Regards, Kostas From k.pentikousis@huawei.com Tue Nov 13 07:53:14 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCB821F868F for ; Tue, 13 Nov 2012 07:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9NLefNtwLqA for ; Tue, 13 Nov 2012 07:53:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C749121F853C for ; Tue, 13 Nov 2012 07:53:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT58196; Tue, 13 Nov 2012 15:53:06 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:52:35 +0000 Received: from SZXEML443-HUB.china.huawei.com (10.82.67.181) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 15:52:43 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by SZXEML443-HUB.china.huawei.com ([10.82.67.181]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 23:52:36 +0800 From: Konstantinos Pentikousis To: jouni korhonen , "dmm@ietf.org" Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02 Thread-Index: AQHNwSHdj8lT6/ED6UeDXgOj6Sv+55fn5yBA Date: Tue, 13 Nov 2012 15:52:35 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> In-Reply-To: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:53:14 -0000 Hi Jouni, all, | "PS2: Divergence from other evolutionary trends in network | architecture | | Centralized mobility management can become non-optimal with a | flat network architecture." | | o What are the "other"? I would consider removing PS2 if we cannot |name those. I think "other" here refers to the distributed nature of delivering network= services/content today (e.g. multiple data centers, CDNs etc.). It's not o= nly the mobile that moves around these days, but your "correspondent" node = as well. | "PS3: Low scalability of centralized route and mobility context | maintenance" | | o Isn't e.g. the SDN evolution just doing to the opposite? Highly | centralized management point for traffic steering? I would Oh dear, should we discuss SDN scalability here? :) | "REQ2: Transparency to Upper Layers when needed | | DMM solutions MUST provide transparent mobility support |above the IP layer when needed. Such transparency is needed, |for.." | | o Doesn't the "when needed" make the earlier MUST conditional? At |least I understand it so. If that is the case we probably could just say= : | "DMM solutions SHOULD provide transparent mobility support above |the IP layer." ? I know we should not be talking implementation, but since I got inspired ju= st now, this is the way I parse the former: procedure dmmXYZ (in: mobility_support_required, out: mobility_support) { mobility_support =3D false; ... if (mobility_support_required=3D=3Dtrue) then mobility_support=3Dtrue; ... } Your proposal does not capture the conditionality of mobility support for d= ifferent hosts, applications, and even different sessions of the same app. = I read it more like // set to 0 for disabling mobility support #define MOBILITY_SUPPORT 1=20 |In Section 4.4: | | o I would just remove the sentence: | "Motivation: Using IETF protocols is easier to deploy and to | update." IMHO it brings no additional clarity what has already | been said. Second this too, although the section looks a bit too short then. Best Regards, Kostas From sarikaya2012@gmail.com Tue Nov 13 08:03:38 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F8021F85B6 for ; Tue, 13 Nov 2012 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgWHxmne-XcU for ; Tue, 13 Nov 2012 08:03:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17B0721F8744 for ; Tue, 13 Nov 2012 08:03:33 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so12110183iec.31 for ; Tue, 13 Nov 2012 08:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=H9tGW+D4uRd3pSZg7cDg5djSJJWxurVKJmolZuaX3Og=; b=In1nf9CzBnomKf6SUcPzHcmIDU+gqws1KukhyEAf3jaM2rmfN06wBQLdIIZvjyc9l4 IfKv7pfd2J2taeIUsIGeoRyPTPG8auQCtgds+AbWUMzIinmbO0MYTFQEDHzO6sL9ICDv XfF+DUllMH37N4BySunZ3uyXWmQipRP9ZDlZKlqoUO3DnJFcaVsS4GvdbaLB/h2Pq34W KkW64Xbejno5ko6KdSokjNhjrKPv7NwRg+JcPvyiFRFOIqVn3Q66pB2mkZCvJEx7Negw fuLztPHBHRPz2h3f1GuO0u8TmdVvY1SukSdb1zUqphsA6VGnuF1cmLL8pGozd2U2QqGP 4gpA== MIME-Version: 1.0 Received: by 10.42.247.136 with SMTP id mc8mr21597488icb.36.1352822612497; Tue, 13 Nov 2012 08:03:32 -0800 (PST) Received: by 10.231.85.26 with HTTP; Tue, 13 Nov 2012 08:03:32 -0800 (PST) In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EE61A@szxeml545-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <50A181E4.6070901@av.it.pt> <8D38716F0C1A444BA0CD7E96454366C23A4EE61A@szxeml545-mbx.china.huawei.com> Date: Tue, 13 Nov 2012 10:03:32 -0600 Message-ID: From: Behcet Sarikaya To: Konstantinos Pentikousis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:03:38 -0000 > And, to be honest, if I just "think wider", REQ3, 4, and 5 (IPv6, existin= g mobility protocols, and compatibility) should be sufficient to cover "mul= ticast support". I copy-paste from the respective motivation sections: "DMM= solutions SHOULD target IPv6 as the primary deployment environment." [..] = "A DMM solution SHOULD first consider reusing and extending IETF-standardiz= ed protocols before specifying new protocols." I think these two would in g= eneral cover also stuff developed in multimob. And, as if this is not suffi= cient, then REQ5 should close this discussion: "The DMM solution MUST be ab= le to co-exist with existing network deployments and end hosts." Therefore,= if you already have multicast services in your domain, the DMM solution sh= ould handle them. > > Now, we did agree in Atlanta to have a quick resolution wrt to multicast,= and perhaps explicitly add "REQ7: Multicast support", if the multimob folk= s can deal with this in an expedient manner. If not, imo, REQs 3/4/5 should= more than suffice to cover "multicast support in DMM". > I agree. Existing requirements do cover what we need. Regards, Behcet From pierrick.seite@orange.com Tue Nov 13 11:20:31 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E717021F8456 for ; Tue, 13 Nov 2012 11:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMxfqbuhWTRu for ; Tue, 13 Nov 2012 11:20:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 30CFE21F8457 for ; Tue, 13 Nov 2012 11:20:30 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 020C022C7E4; Tue, 13 Nov 2012 20:20:29 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DA4852380B6; Tue, 13 Nov 2012 20:20:28 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 13 Nov 2012 20:20:28 +0100 From: To: 'Konstantinos Pentikousis' , jouni korhonen , "dmm@ietf.org" Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02 Thread-Index: AQHNwR1B964CyTnzz027SLYyL3w6AZfn2s2AgAA6qtA= Date: Tue, 13 Nov 2012 19:20:28 +0000 Message-ID: <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.13.170352 Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:20:32 -0000 Hi Jouni, Kostas, Please see comments inline. Pierrick > -----Message d'origine----- > De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de > Konstantinos Pentikousis > Envoy=E9=A0: mardi 13 novembre 2012 16:53 > =C0=A0: jouni korhonen; dmm@ietf.org > Objet=A0: Re: [DMM] comments on draft-ietf-dmm-requirements-02 >=20 > Hi Jouni, all, >=20 > | "PS2: Divergence from other evolutionary trends in network > | architecture > | > | Centralized mobility management can become non-optimal with > a > | flat network architecture." > | > | o What are the "other"? I would consider removing PS2 if we cannot > |name those. >=20 > I think "other" here refers to the distributed nature of delivering > network services/content today (e.g. multiple data centers, CDNs etc.). > It's not only the mobile that moves around these days, but your > "correspondent" node as well. > Exactly. Here, we refer to distribution of content delivery, i.e. CDN. Prob= ably, one of the main motivation for distributing mobility management :-) I= MHO, if we should keep only one PS, it would be PS#2 :-) =20 >=20 > | "PS3: Low scalability of centralized route and mobility context > | maintenance" > | > | o Isn't e.g. the SDN evolution just doing to the opposite? Highly > | centralized management point for traffic steering? I would >=20 > Oh dear, should we discuss SDN scalability here? :) >=20 >=20 > | "REQ2: Transparency to Upper Layers when needed > | > | DMM solutions MUST provide transparent mobility support > |above the IP layer when needed. Such transparency is needed, > |for.." > | > | o Doesn't the "when needed" make the earlier MUST conditional? At > |least I understand it so. If that is the case we probably could just > say: > | "DMM solutions SHOULD provide transparent mobility support above > |the IP layer." ? >=20 > I know we should not be talking implementation, but since I got > inspired just now, this is the way I parse the former: >=20 > procedure dmmXYZ (in: mobility_support_required, out: mobility_support) > { mobility_support =3D false; ... > if (mobility_support_required=3D=3Dtrue) then mobility_support=3Dtrue; ... > } >=20 > Your proposal does not capture the conditionality of mobility support > for different hosts, applications, and even different sessions of the > same app. I read it more like >=20 > // set to 0 for disabling mobility support #define MOBILITY_SUPPORT 1 >=20 I agree that conditional mobility support, depending on application capabil= ity, is a key requirement. However, I think that this requirement is orthog= onal to the distribution of mobility management functions; actually, we may= have the same requirement with centralized mobility management, right? Bas= ically, here, we refer to the capability of an application to use either a = home IP address or a local IP address, depending respectively on the need, = or not, for IP session continuity. This is not really a DMM issue but a sou= rce address selection problem and the terminal (i.e. the function tackling = with source address selection) must be able to distinguish between anchored= address/prefix and local address/prefix to make a decision. This is why we= have also suggested a work item on prefix coloring in DMM, even if the sco= pe of prefix coloring is larger than DMM. > |In Section 4.4: > | > | o I would just remove the sentence: > | "Motivation: Using IETF protocols is easier to deploy and to > | update." IMHO it brings no additional clarity what has already > | been said. >=20 > Second this too, although the section looks a bit too short then. >=20 > Best Regards, >=20 > Kostas >=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Tue Nov 13 13:17:50 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2382921F8202 for ; Tue, 13 Nov 2012 13:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRQaIcu4NIIh for ; Tue, 13 Nov 2012 13:17:49 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF121F8201 for ; Tue, 13 Nov 2012 13:17:48 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1650627eek.31 for ; Tue, 13 Nov 2012 13:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tPpc+N6WSq/7FHI225Eo2YgwiOPnOtddJltXEbsRB3I=; b=NNS8p7ewM7wA+36f8umV1kSnuH64uyRpkZFUaJnT0EkXytNY6ZztNlFyv5neFC5S2P w4gYAuOG52bgo0M/xS3JYWhNMWc461BNMm9w/FudQPQM2+K1wD2P3BgbviFM0a0PuLOM gteOLpOJnPkygq+MYV7OF/RvaSryMILEDQYWKP307BxaLU/pFxgWv2E3na6j7yYDmb8i EmEXauH+sJOSkLz6juFuuFb3UeqnzOsmVBzLvCICW7nViX1UTmeH83EU+ZGJ3rhbxnJL Z3HBfOZL8mVHuCC35JKnzYPRm76rLD0Ex4uIXoTS3oW5HJZ/mZg7yhRcySjjpaVV+GG1 W+Aw== Received: by 10.14.209.6 with SMTP id r6mr78936326eeo.34.1352841468078; Tue, 13 Nov 2012 13:17:48 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id s1sm25066615eem.9.2012.11.13.13.17.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 13:17:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 13 Nov 2012 23:17:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: Konstantinos Pentikousis , "pierrick.seite@orange.com> X-Mailer: Apple Mail (2.1085) Cc: dmm@ietf.org Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:17:50 -0000 Pierrick, Kostas, On Nov 13, 2012, at 9:20 PM, = wrote: > Hi Jouni, Kostas, >=20 > Please see comments inline. >=20 > Pierrick >=20 >> -----Message d'origine----- >> De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de >> Konstantinos Pentikousis >> Envoy=E9 : mardi 13 novembre 2012 16:53 >> =C0 : jouni korhonen; dmm@ietf.org >> Objet : Re: [DMM] comments on draft-ietf-dmm-requirements-02 >>=20 >> Hi Jouni, all, >>=20 >> | "PS2: Divergence from other evolutionary trends in network >> | architecture >> | >> | Centralized mobility management can become non-optimal = with >> a >> | flat network architecture." >> | >> | o What are the "other"? I would consider removing PS2 if we cannot >> |name those. >>=20 >> I think "other" here refers to the distributed nature of delivering >> network services/content today (e.g. multiple data centers, CDNs = etc.). >> It's not only the mobile that moves around these days, but your >> "correspondent" node as well. >>=20 >=20 > Exactly. Here, we refer to distribution of content delivery, i.e. CDN. = Probably, one of the main motivation for distributing mobility = management :-) IMHO, if we should keep only one PS, it would be PS#2 :-) Maybe we need to then say something about it like=20 "Divergence from other evolutionary trends in network architectures such as distribution of content delivery" ? >> | "PS3: Low scalability of centralized route and mobility context >> | maintenance" >> | >> | o Isn't e.g. the SDN evolution just doing to the opposite? Highly >> | centralized management point for traffic steering? I would >>=20 >> Oh dear, should we discuss SDN scalability here? :) No (without smile). But that is another trend to opposite direction and we should have a sufficient argument for our assertion here imho. What is so fundamentally resource consuming in "mobility context" handling that it requires distribution? Is it just a combination of all functions in one place (that has little to do with mobility per se)? >>=20 >>=20 >> | "REQ2: Transparency to Upper Layers when needed >> | >> | DMM solutions MUST provide transparent mobility support >> |above the IP layer when needed. Such transparency is needed, >> |for.." >> | >> | o Doesn't the "when needed" make the earlier MUST conditional? At >> |least I understand it so. If that is the case we probably could = just >> say: >> | "DMM solutions SHOULD provide transparent mobility support above >> |the IP layer." ? >>=20 >> I know we should not be talking implementation, but since I got >> inspired just now, this is the way I parse the former: >>=20 >> procedure dmmXYZ (in: mobility_support_required, out: = mobility_support) >> { mobility_support =3D false; ... >> if (mobility_support_required=3D=3Dtrue) then mobility_support=3Dtrue; = ... >> } >>=20 >> Your proposal does not capture the conditionality of mobility support >> for different hosts, applications, and even different sessions of the >> same app. I read it more like I get the point.. but I have a slight issue here. I would need to = implement the "mobility stack" whatever support function anyway even if none of my application care about it. On the other hand network based mobility = should (!) be transparent to the MN or is this promise also long gone in reality? >> // set to 0 for disabling mobility support #define MOBILITY_SUPPORT 1 >>=20 >=20 > I agree that conditional mobility support, depending on application = capability, is a key requirement. However, I think that this requirement = is orthogonal to the distribution of mobility management functions; = actually, we may have the same requirement with centralized mobility = management, right? Basically, here, we refer to the capability of an = application to use either a home IP Yes. > address or a local IP address, depending respectively on the need, or = not, for IP session continuity. This is not really a DMM issue but a = source address selection problem and the terminal (i.e. the function = tackling with source address selection) must be able to distinguish = between anchored address/prefix and local address/prefix to make a = decision. This is why we have also suggested a work item on prefix = coloring in DMM, even if the scope of prefix coloring is larger than = DMM. Agree for some obvious reason ;) >> |In Section 4.4: >> | >> | o I would just remove the sentence: >> | "Motivation: Using IETF protocols is easier to deploy and to >> | update." IMHO it brings no additional clarity what has already >> | been said. >>=20 >> Second this too, although the section looks a bit too short then. Less is quite often more ;) - Jouni >>=20 >> Best Regards, >>=20 >> Kostas >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From jouni.nospam@gmail.com Tue Nov 13 13:19:30 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C37321F8441 for ; Tue, 13 Nov 2012 13:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqhQPHzpqs9z for ; Tue, 13 Nov 2012 13:19:29 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5623021F8201 for ; Tue, 13 Nov 2012 13:19:29 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so3384080eaa.31 for ; Tue, 13 Nov 2012 13:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ifiFPhVgvAT7KozBIT2/AYL61b+I9NH3+J5YJIi0HJA=; b=pZDt4LOPNBgnJ5oGFvzdFPDzKmUHzJ5YSPJQ8pyWVnnuldxeWrgjr8yYKW4QpsLaDn 0NH6vnVhHvzqAhkSGptCdF1wotLFGPD9Kx4BBRuZufJDLGZf5yC2AcIEBuBY5errtozW R+ADqQngGz3A1b7v6Np+sDHaN81EBoXCjKaS0xJm/pgEYBtf4kx15hN5YiYUxs0peKm4 Us8xViY8jjVg8Y22dARhQfP1UGq0IyNqxvC6yrTIHJHuxWdmV15PfDZR6TBrwlM2HWu5 0+wYUIBSw7BlXnrj6ZY+lErDkMtaJE80JFW7zodmSaOAHYgJXaLhZh/cunIfrM0Actgm YFkA== Received: by 10.14.209.136 with SMTP id s8mr78455639eeo.33.1352841568552; Tue, 13 Nov 2012 13:19:28 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id f3sm25069409eeo.13.2012.11.13.13.19.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 13:19:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> Date: Tue, 13 Nov 2012 23:19:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> To: Konstantinos Pentikousis X-Mailer: Apple Mail (2.1085) Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" , Peter McCann Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:19:30 -0000 On Nov 13, 2012, at 4:49 PM, Konstantinos Pentikousis wrote: > Hi Juan Carlos, all, >=20 > |Requirement: DMM solutions SHOULD support multicast services. In = case > |the solution does not address multicast, a justification MUST be = provided > |for the omission of multicast from the solution. >=20 > I like this proposal. It appears to me to capture the essence of the = request to cover multicast in DMM. I would make it even shorter however: >=20 > Requirement: DMM solutions SHOULD support multicast services. If a = specific DMM solution does not support multicast services, an = explanation MUST be provided. Sounds ok to me. > |Motivation: The purpose of this requirement is to encourage people = to > |consider the impacts of running multicast services in a DMM = environment > |from the beginning of the development, thereby avoiding the need to > |make protocol extensions in the future to support this kind of = functionality. >=20 > I second the motivation part, although I would also rephrase it a bit: >=20 > Motivation: =46rom an operational perspective, if a network domain = provides multicast services already, the deployment of a DMM solution = should not impede the delivery of such services. =46rom a protocol = perspective, a DMM solution should aim to address unicast as well as = multicast in a coherent manner, thus avoiding the recurrence of = "multicast add-ons", as is the case with today's mobility management = solutions. Ack. - Jouni >=20 > Best Regards, >=20 > Kostas >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From sarikaya2012@gmail.com Tue Nov 13 18:35:58 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F264921F84D0 for ; Tue, 13 Nov 2012 18:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feF4003+DWaH for ; Tue, 13 Nov 2012 18:35:57 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A56B621F84B2 for ; Tue, 13 Nov 2012 18:35:56 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so1885311iaf.31 for ; Tue, 13 Nov 2012 18:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jb09J+ZmWBzitq5H18xfDYNvfazqOOjQIjYoAwRWxtE=; b=aTKdtAsIbXstEHFAI1Su9DGVmbW7CsCwPiwIrPlntGun9HhnlWA66F5j/0jAdAPpaQ fmyKyMzXuLJHzfjhJ4yxRJQbYAbgVM+yd28tYvNT8GuDyONMpJfjtqRw1jAvPxckF/19 97pH09MkSjtZMBL52K4wrYzi5jQTOiL+7CF9D7U1llvXvbDEVu676lX+OnALjPzFI6Pw HI5urtnOaPibva6D4DKfNcRYc5n1pGTi/jje11CM7mBHJ91XlmHzSITyTCkDy92ST6h6 xsO8YDwlBCVkE/BtthzDnH1c8alKP2BGxx3n6SgQdYC7GA5AVHYclKAdqxm0QYyi5veI UG3Q== MIME-Version: 1.0 Received: by 10.50.5.205 with SMTP id u13mr495794igu.37.1352860554378; Tue, 13 Nov 2012 18:35:54 -0800 (PST) Received: by 10.231.85.26 with HTTP; Tue, 13 Nov 2012 18:35:54 -0800 (PST) In-Reply-To: <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> Date: Tue, 13 Nov 2012 20:35:54 -0600 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: Stig Venaas , Behcet Sarikaya , Peter McCann , "dmm@ietf.org" , Konstantinos Pentikousis Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 02:35:58 -0000 Hi Jouni, >> Requirement: DMM solutions SHOULD support multicast services. So here it is a should. >> If a specific DMM solution does not support multicast services, an explanation MUST be provided. Why is it a must here? My comment on this requirement is in mobility area, we have never had these types of requirements. For example PMIPv6 was developed with no multicast support. MIPv6 and PMIPv6 were developed with no fast handover support. MIPSHOP WG worked on handover extensions to these protocols. As you know, Costas has changed his view "thinking wider". If we look back to the beginning of this discussion, i.e. Multimob meeting in Atlanta and Seil's presentation, we, at least myself, were mislead. In that presentation at http://www.ietf.org/proceedings/85/slides/slides-85-multimob-6.pptx We thought that he had a multicast requirement and a reasonable suggestion was to take it to dmm. However, if you look at his slide 6, he does have a requirement there but it is REQ1 from the DMM requirements draft :-). If existing requirements are covering what we want, as it seems with REQ 3/4/5, why not go with them? Regards, Behcet From jouni.nospam@gmail.com Tue Nov 13 23:18:29 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28D421F85CB for ; Tue, 13 Nov 2012 23:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i2tbxyw5mxS for ; Tue, 13 Nov 2012 23:18:29 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C48F321F85C9 for ; Tue, 13 Nov 2012 23:18:28 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so70614eek.31 for ; Tue, 13 Nov 2012 23:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GFDevDB+votOeEaPWv40sH33FgO4Yk8VcRZ+1EWHN94=; b=YdQn6qQNCiYD/OjHvjNwqn6TY/1aZOW2b5Q7gfA6j/zhBvLS7S0ysixDJ09t71hqDS KT7yRpyeY2oBk9YuDPE46gVBtwYJKhxnVZi1CnXo0JH0FUV6rpCfyiHYzR4WaUCDrdU/ FMO/QiMHYS1Ik6RQhbKwc/Kk/hcjHsUVQ6NXAD/UmK/axcAvjcO2i9y76gvXYUj6J9zT qOx3i3UcU/MCSeAJ+XhX0XfmE+9B4UEi9W0W/ZpxoMVchb8Z51PIeaopngL3VrtVRvXq vLCKTKQOdQlobhaBC2nibsTk7MfQjWMUb5Q6i76C7d5e8cnmFjO5jYylKEAiwZ/U7XLm sxLQ== Received: by 10.14.0.68 with SMTP id 44mr84423913eea.1.1352877507976; Tue, 13 Nov 2012 23:18:27 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id i1sm27841944eeo.8.2012.11.13.23.18.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 23:18:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 14 Nov 2012 09:18:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1085) Cc: Stig Venaas , Behcet Sarikaya , Peter McCann , "dmm@ietf.org" , Konstantinos Pentikousis Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 07:18:29 -0000 Behcet, On Nov 14, 2012, at 4:35 AM, Behcet Sarikaya wrote: > Hi Jouni, >=20 >>> Requirement: DMM solutions SHOULD support multicast services. >=20 > So here it is a should. It seems so. >>> If a specific DMM solution does not support multicast services, an = explanation MUST be provided. >=20 > Why is it a must here? So that one provides a proper justification why the solution chose to=20 leverage the former SHOULD and left multicast support unattended. That makes sense to me. > My comment on this requirement is in mobility area, we have never had > these types of requirements. >=20 > For example PMIPv6 was developed with no multicast support. I doubt it was intentional. RFC6224 did a good job clarifying the = operation of a MAG as a MLD proxy later on. > MIPv6 and PMIPv6 were developed with no fast handover support. MIPSHOP > WG worked on handover extensions to these protocols. >=20 > As you know, Costas has changed his view "thinking wider". I'll let him speak for himself. > If we look back to the beginning of this discussion, i.e. Multimob > meeting in Atlanta and Seil's presentation, we, at least myself, were > mislead. In that presentation at > http://www.ietf.org/proceedings/85/slides/slides-85-multimob-6.pptx >=20 > We thought that he had a multicast requirement and a reasonable > suggestion was to take it to dmm. However, if you look at his slide 6, > he does have a requirement there but it is REQ1 from the DMM > requirements draft :-). >=20 > If existing requirements are covering what we want, as it seems with > REQ 3/4/5, why not go with them? Perhaps we should have learned what happened with PMIPv6. The assumption = was that multicast would work over it just fine, which was at the end not = quite true. Thus a specific requirement reminding us about that should be ok. = If that multicast specific note boils down to a clarification to an = existing requirement, it is ok. I just don't think we are there yet to jump into = that conclusion. So, coming back to the proposal from JC & Kostas. There was a concrete = text proposal. If someone thinks the multicast requirement can be part of = existing requirements; propose text. - Jouni >=20 > Regards, >=20 > Behcet From k.pentikousis@huawei.com Wed Nov 14 09:21:20 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7621F85A5 for ; Wed, 14 Nov 2012 09:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UQ-VujrpQI2 for ; Wed, 14 Nov 2012 09:21:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B5ED221F842E for ; Wed, 14 Nov 2012 09:21:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMU56554; Wed, 14 Nov 2012 17:21:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 17:21:03 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 17:21:14 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 01:21:05 +0800 From: Konstantinos Pentikousis To: "sarikaya@ieee.org" , jouni korhonen Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwSxRzyFl17zuj0SrDo7gr/gA/pfn1QlA///rmQCAAFhyAIABePCg Date: Wed, 14 Nov 2012 17:21:04 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , Behcet Sarikaya , Peter McCann , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:21:20 -0000 Hi Behcet |As you know, Costas has changed his view "thinking wider". I didn't change my view :) Maybe it was not so clearly explained, apologies= for that. I think that it does not harm to have a separate "REQ no. 7" add= ressing multicast along the lines previously mentioned in the mailing list.= However, if drafting such a REQ delays our progress in the WG wrt the -req= s draft, the best practices/gap analysis work or, even worse, going after c= oncrete DMM solutions in a speedy manner, it makes more sense to tweak some= of the existing requirements text so we can accommodate the requirement fo= r multicast support. After all, the current DMM chapter does not explicitly= mention "multicast". |If existing requirements are covering what we want, as it seems with |REQ 3/4/5, why not go with them? I agree, but it's reasonable, since the point was brought up, to explicitly= cover multicast (one way or another, see above) in the -reqs draft. Best Regards, Kostas From k.pentikousis@huawei.com Wed Nov 14 09:32:30 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8338E21F8754 for ; Wed, 14 Nov 2012 09:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4YgFV047r3S for ; Wed, 14 Nov 2012 09:32:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC821F8721 for ; Wed, 14 Nov 2012 09:32:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMU57131; Wed, 14 Nov 2012 17:32:27 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 17:32:14 +0000 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 17:32:26 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 01:32:20 +0800 From: Konstantinos Pentikousis To: "pierrick.seite@orange.com" , jouni korhonen , "dmm@ietf.org" Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02 Thread-Index: AQHNwSHdj8lT6/ED6UeDXgOj6Sv+55fn5yBA//+4YACAAffxwA== Date: Wed, 14 Nov 2012 17:32:18 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EEAF4@szxeml545-mbx.china.huawei.com> References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:32:30 -0000 Hi Pierrick, all, |IMHO, if we should keep only one PS, it would be PS#2 :-) How about combining PS1 and PS2? |I agree that conditional mobility support, depending on application |capability, is a key requirement. However, I think that this |requirement is orthogonal to the distribution of mobility management |functions; actually, we may have the same requirement with centralized |mobility management, right? You are right, it is orthogonal. | This is not really a DMM issue Indeed, but if we're to design a modern mobility management solution then i= t should be considered from the beginning, right? Best Regards, Kostas From JuanCarlos.Zuniga@InterDigital.com Wed Nov 14 10:23:34 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBC721F86E7 for ; Wed, 14 Nov 2012 10:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnWZl30FM1WH for ; Wed, 14 Nov 2012 10:23:34 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D1AF921F85FD for ; Wed, 14 Nov 2012 10:23:33 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Nov 2012 13:23:32 -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: Wed, 14 Nov 2012 13:23:31 -0500 Message-ID: In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] Multicast requirements Thread-Index: AQHNwSxRzyFl17zuj0SrDo7gr/gA/pfn1QlA///rmQCAAFhyAIABePCggAAU5bA= References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com><5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com><50A16AE0.70101@fhtw-berlin.de><5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com><50A172AC.5090308@fhtw-berlin.de><8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com><61CEE523-F244-486B-AA95-591828D53EED@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com> From: "Zuniga, Juan Carlos" To: "Konstantinos Pentikousis" , , "jouni korhonen" X-OriginalArrivalTime: 14 Nov 2012 18:23:32.0556 (UTC) FILETIME=[271A40C0:01CDC295] Cc: Stig Venaas , Behcet Sarikaya , Peter McCann , dmm@ietf.org Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:23:34 -0000 Hi, > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Konstantinos Pentikousis > Sent: Wednesday, November 14, 2012 12:21 PM > To: sarikaya@ieee.org; jouni korhonen > Cc: Stig Venaas; Behcet Sarikaya; Peter McCann; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements >=20 > Hi Behcet >=20 > |As you know, Costas has changed his view "thinking wider". >=20 > I didn't change my view :) Maybe it was not so clearly explained, > apologies for that. I think that it does not harm to have a separate > "REQ no. 7" addressing multicast along the lines previously mentioned > in the mailing list. However, if drafting such a REQ delays our > progress in the WG wrt the -reqs draft, the best practices/gap analysis > work or, even worse, going after concrete DMM solutions in a speedy > manner, it makes more sense to tweak some of the existing requirements > text so we can accommodate the requirement for multicast support. After > all, the current DMM chapter does not explicitly mention "multicast". >=20 >=20 > |If existing requirements are covering what we want, as it seems with > |REQ 3/4/5, why not go with them? >=20 > I agree, but it's reasonable, since the point was brought up, to > explicitly cover multicast (one way or another, see above) in the -reqs > draft. [JCZ] I also agree with explicitly covering multicast. Implicitly covering it has not been good enough, as this is what triggered this whole discussion. Explicitly covering it does not seem to be harmful either.=20 The amended text by Kostas seems good to me and I think that we can move forward with it. Hence, I support including that text in the WG requirements draft. Regards, JC >=20 > Best Regards, >=20 > Kostas >=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From k.pentikousis@huawei.com Wed Nov 14 10:29:29 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D7921F8776 for ; Wed, 14 Nov 2012 10:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmHP1tlmcDzX for ; Wed, 14 Nov 2012 10:29:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3C21F8769 for ; Wed, 14 Nov 2012 10:29:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALN44505; Wed, 14 Nov 2012 18:29:27 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 18:29:12 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 18:29:24 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 02:28:19 +0800 From: Konstantinos Pentikousis To: jouni korhonen Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02 Thread-Index: AQHNwSHdj8lT6/ED6UeDXgOj6Sv+55fn5yBA//+4YACAACC/AIAB2X8A Date: Wed, 14 Nov 2012 18:28:17 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EEB34@szxeml545-mbx.china.huawei.com> References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:29:29 -0000 Hi Jouni, all, |Maybe we need to then say something about it like | "Divergence from other evolutionary trends in network | architectures such as distribution of content delivery" ? Sounds good to me. |No (without smile). But that is another trend to opposite direction |and we should have a sufficient argument for our assertion here imho. Wh= at |is so fundamentally resource consuming in "mobility context" handling |that it requires distribution? Is it just a combination of all |functions in one place (that has little to do with mobility per se)? I think scalability here refers to the "hub-and-spoke" nature of the routin= g fabric as introduced by a "centralized" mobility anchor. You may have val= id technical and/or operational reasons for adopting a hub-and-spoke model,= that's ok. But maybe others may want an alternative model which aims for d= ifferent optimalities, and for those the hub-and-spoke model is not, well, = "scalable". SDN, well the OpenFlow flavor of it anyway, is "logically centralized" wrt = network control, not how packets move around. SDN can do hub-and-spoke as w= ell as other routing fabrics. Information-centric networking, another major= trend, is definitely not pointing towards the merits of the current type o= f centralization... So I think PS3 is valid. =20 |I would need to implement the "mobility stack" whatever support function |anyway even if none of my application care about it. If you are absolutely sure that none of your apps needs mobility support, a= nd none will ever need it in the future, then there's no reason to implemen= t it, sure. But if there's a chance one app may need it and 100 won't, then= perhaps you get to implement it. The difference is that, if you do impleme= nt that "mobility stack", with conditional support you run that code for on= e app only (and route the respective packets accordingly), while with today= 's approach you do the same for 101 apps. Best Regards, Kostas From sarikaya2012@gmail.com Wed Nov 14 15:03:02 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CBA21F84E2 for ; Wed, 14 Nov 2012 15:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzQ1WLOYCIwU for ; Wed, 14 Nov 2012 15:03:01 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECF621F84E1 for ; Wed, 14 Nov 2012 15:03:01 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so702750iaf.31 for ; Wed, 14 Nov 2012 15:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PbVDG6daKF6VOlxOqP1QUOYLvykwdEWKIBDav2fxM7s=; b=0Je1GaTDiVCtqE1IMRVlsznppwGT8GeRlQfzzdGkAUKMKK7WfFWB+SniXf9kNOmqw4 P3L7bOuJ0PaUXZiQWDzTVZro12suetTVTQxvwf70K3ZTDLDcfBLS8l4Zt4Z6/FbjNGU4 wlsZHNYd7/IJ6ndPllGCv+37cM/QqqITi+2a8DJcVWVz/9P2ykA+xe1DE1dvIsAnM759 EJ7svI6W3IaoJGoe0wsvgQ7gf793rPfWUiEgw+KV/c0Kx+GrKdiTpvXBciIrc8QGnrgI R+2LOz1/xKGuB5yZK8nf0l8nNNhVYBOZLU1qewkhWVgvoB4nxiRRCS10KQvmexcAZ/r8 IqBw== MIME-Version: 1.0 Received: by 10.50.173.37 with SMTP id bh5mr863786igc.45.1352934180784; Wed, 14 Nov 2012 15:03:00 -0800 (PST) Received: by 10.231.85.26 with HTTP; Wed, 14 Nov 2012 15:03:00 -0800 (PST) In-Reply-To: References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com> Date: Wed, 14 Nov 2012 17:03:00 -0600 Message-ID: From: Behcet Sarikaya To: "Zuniga, Juan Carlos" Content-Type: text/plain; charset=ISO-8859-1 Cc: Stig Venaas , Peter McCann , dmm@ietf.org, Konstantinos Pentikousis Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:03:02 -0000 > [JCZ] I also agree with explicitly covering multicast. Implicitly > covering it has not been good enough, as this is what triggered this > whole discussion. Explicitly covering it does not seem to be harmful > either. > The amended text by Kostas seems good to me and I think that we can move > forward with it. Hence, I support including that text in the WG > requirements draft. Disagree. Such requirements state nothing new, and are useless. How are we going to judge on somebody's multicast solution by looking at this requirement? If we include this requirement then we should also have a requirement saying that fast handover should supported. If we have a requirement saying that fast handover should be supported then we should also have a requirement saying that even faster handover should be supported. I think we are reading too much into multicast and unicast should be designed in an integrated manner. The fact is that multicast is considered as an area of specialization, it requires knowledge of very different protocols than we are accustomed to in mobility. Let dmm deal with its current charter that does not include a word of multicast and if everything goes well we can come back and discuss dmm multicast. Regards, Behcet From prvs=6565d6a3d=schmidt@informatik.haw-hamburg.de Mon Nov 12 13:29:54 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139C621F8625 for ; Mon, 12 Nov 2012 13:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMsvtCrWSv3p for ; Mon, 12 Nov 2012 13:29:53 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2A94121F8614 for ; Mon, 12 Nov 2012 13:29:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAVpoVCNFh5K/2dsb2JhbABEFsNMgQiCHgEBAQQBAQEkCwEFNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBF4dzB7l7jBUag1SCXAObZ4VKhQ6CYg6BYxc Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 12 Nov 2012 22:29:51 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 08A5A104DABC; Mon, 12 Nov 2012 22:29:51 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28289-10; Mon, 12 Nov 2012 22:29:50 +0100 (CET) Received: from [192.168.178.36] (g231108188.adsl.alicedsl.de [92.231.108.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id D7DD7107B96A; Mon, 12 Nov 2012 22:29:49 +0100 (CET) Message-ID: <50A16A4D.6030507@informatik.haw-hamburg.de> Date: Mon, 12 Nov 2012 22:29:49 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Peter McCann References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Mailman-Approved-At: Wed, 14 Nov 2012 23:48:07 -0800 Cc: Stig Venaas , Behcet Sarikaya , "dmm@ietf.org" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:29:54 -0000 Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: > jouni korhonen wrote: >> Folks, >> >> This mail is to kick off the discussion on multicast requirement(s) >> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >> down the essential multicast requirement(s) as soon as possible. > > To me, multicast in a DMM environment means joining multicast > groups directly from access routers. It means re-joining the > multicast tree from a new access router after handover. I would > hope that we can use existing MLD protocols between the MN and > its first hop AR to accomplish this. > > -Pete > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From pierrick.seite@orange.com Thu Nov 15 00:39:56 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99A021F8809 for ; Thu, 15 Nov 2012 00:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKRCXYksq7aM for ; Thu, 15 Nov 2012 00:39:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7EA21F8618 for ; Thu, 15 Nov 2012 00:39:55 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 96AD43B4E3C; Thu, 15 Nov 2012 09:39:54 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 767E023807B; Thu, 15 Nov 2012 09:39:54 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 15 Nov 2012 09:39:54 +0100 From: To: 'jouni korhonen' , Konstantinos Pentikousis Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02 Thread-Index: AQHNwR1B964CyTnzz027SLYyL3w6AZfn2s2AgABro6yAAlCWMA== Date: Thu, 15 Nov 2012 08:39:53 +0000 Message-ID: <32463_1352968794_50A4AA5A_32463_1611_1_81C77F07008CA24F9783A98CFD706F71067B90@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "dmm@ietf.org" Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:39:57 -0000 > >> | "PS2: Divergence from other evolutionary trends in network > >> | architecture > >> | > >> | Centralized mobility management can become non-optimal > with > >> a > >> | flat network architecture." > >> | > >> | o What are the "other"? I would consider removing PS2 if we > cannot > >> |name those. > >> > >> I think "other" here refers to the distributed nature of delivering > >> network services/content today (e.g. multiple data centers, CDNs > etc.). > >> It's not only the mobile that moves around these days, but your > >> "correspondent" node as well. > >> > > > > Exactly. Here, we refer to distribution of content delivery, i.e. > CDN. > > Probably, one of the main motivation for distributing mobility > > management :-) IMHO, if we should keep only one PS, it would be PS#2 > > :-) >=20 > Maybe we need to then say something about it like > "Divergence from other evolutionary trends in network > architectures such as distribution of content delivery" ? >=20 Agreed. Pierrick ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From pierrick.seite@orange.com Thu Nov 15 01:10:22 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2321F87EA for ; Thu, 15 Nov 2012 01:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02buRNYl8w-y for ; Thu, 15 Nov 2012 01:10:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44821F87DB for ; Thu, 15 Nov 2012 01:10:02 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8158322D037; Thu, 15 Nov 2012 10:10:01 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 62B6D238074; Thu, 15 Nov 2012 10:10:01 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 15 Nov 2012 10:10:01 +0100 From: To: 'Konstantinos Pentikousis' , jouni korhonen , "dmm@ietf.org" Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02 Thread-Index: AQHNwR1B964CyTnzz027SLYyL3w6AZfn5yBA//+4YACAAffxwIAA9ZlQ Date: Thu, 15 Nov 2012 09:10:01 +0000 Message-ID: <32465_1352970601_50A4B169_32465_6251_1_81C77F07008CA24F9783A98CFD706F71069BFA@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8D38716F0C1A444BA0CD7E96454366C23A4EEAF4@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EEAF4@szxeml545-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.15.84515 Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 09:10:22 -0000 > -----Message d'origine----- > De=A0: Konstantinos Pentikousis [mailto:k.pentikousis@huawei.com] > Envoy=E9=A0: mercredi 14 novembre 2012 18:32 > =C0=A0: SEITE Pierrick OLNC/OLN; jouni korhonen; dmm@ietf.org > Objet=A0: RE: [DMM] comments on draft-ietf-dmm-requirements-02 >=20 > Hi Pierrick, all, >=20 > |IMHO, if we should keep only one PS, it would be PS#2 :-) >=20 > How about combining PS1 and PS2? >=20 >=20 > |I agree that conditional mobility support, depending on application > |capability, is a key requirement. However, I think that this > |requirement is orthogonal to the distribution of mobility management > |functions; actually, we may have the same requirement with > centralized > |mobility management, right? >=20 > You are right, it is orthogonal. >=20 >=20 > | This is not really a DMM issue >=20 > Indeed, but if we're to design a modern mobility management solution > then it should be considered from the beginning, right? >=20 For sure. I'm 100% convinced about benefit of "dynamic" mobility management= . I'm just saying that conditional mobility support is a requirement for mo= bility management system but probably not for DMM protocol. IMHO, condition= al mobility support according application capability is probably a connecti= on management issue (i.e. interface, source address selection issue) withou= t direct impact on DMM protocol itself. Anyway, it is worth to stress this = requirement since "always-on" mobility support should be avoided. >=20 > Best Regards, >=20 > Kostas >=20 >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Thu Nov 15 02:56:36 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A4F21F84B9 for ; Thu, 15 Nov 2012 02:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezj7s+M3Mzan for ; Thu, 15 Nov 2012 02:56:35 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED421F849A for ; Thu, 15 Nov 2012 02:56:35 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so987950eek.31 for ; Thu, 15 Nov 2012 02:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZnY2I95b+HpbiSmCxYN51we5VevoVRRZtRvBUe7NThU=; b=j/xOeMp55VS2zZzXaYseK4EISeZxRcjb9Vsy8xa6W0QW8ZI2xk2jyYh14FfAZxec6b pFoi4GlAbND1k3tB594eRLa8582V3KLMp084QLOyLLeZCuRTqvGTAA2rOtdSyP0E2hCy qR+TrD8UyJq6yVuVXyLgqy0vMd8FxlevWCquezSPcbFoooV0RjOQ+Je9i03QYpAgRMEL 7cmHDNMdUnKZ5ai0GmXgFFp0ZWHfj5EzQrA/OmZwYb76mAy+IzNiOJsSOFK5zK1IrPmC K/Wk6oFGMiI9Zu5hXTOSTe+2B3A67H4H61YEIRjrzq6W7r197Ssn2GK1JM1y1phSSKLc LpuQ== Received: by 10.14.174.194 with SMTP id x42mr2772667eel.22.1352976994440; Thu, 15 Nov 2012 02:56:34 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id z43sm35516386een.16.2012.11.15.02.56.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 02:56:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EEB34@szxeml545-mbx.china.huawei.com> Date: Thu, 15 Nov 2012 12:56:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8D38716F0C1A444BA0CD7E96454366C23A4EEB34@szxeml545-mbx.china.huawei.com> To: Konstantinos Pentikousis X-Mailer: Apple Mail (2.1085) Cc: "dmm@ietf.org" Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 10:56:36 -0000 Hi, On Nov 14, 2012, at 8:28 PM, Konstantinos Pentikousis wrote: > Hi Jouni, all, >=20 > |Maybe we need to then say something about it like > | "Divergence from other evolutionary trends in network > | architectures such as distribution of content delivery" ? >=20 > Sounds good to me. Good. > |No (without smile). But that is another trend to opposite direction > |and we should have a sufficient argument for our assertion here = imho. What > |is so fundamentally resource consuming in "mobility context" = handling > |that it requires distribution? Is it just a combination of all > |functions in one place (that has little to do with mobility per se)? >=20 > I think scalability here refers to the "hub-and-spoke" nature of the = routing fabric as introduced by a "centralized" mobility anchor. You may = have valid technical and/or operational reasons for adopting a = hub-and-spoke model, that's ok. But maybe others may want an alternative = model which aims for different optimalities, and for those the = hub-and-spoke model is not, well, "scalable". >=20 > SDN, well the OpenFlow flavor of it anyway, is "logically centralized" = wrt network control, not how packets move around. SDN can do = hub-and-spoke as well as other routing fabrics. Information-centric = networking, another major trend, is definitely not pointing towards the = merits of the current type of centralization... So I think PS3 is valid. PS3 says "centralized route management".. I would be far more = comfortable if PS3 says "centralized tunnel management" which is more = concretely what we do today as per hub-and-spoke type tunneled traffic = deployments. > |I would need to implement the "mobility stack" whatever support = function > |anyway even if none of my application care about it. >=20 > If you are absolutely sure that none of your apps needs mobility = support, and none will ever need it in the future, then there's no = reason to implement it, sure. But if there's a chance one app may need = it and 100 won't, then perhaps you get to implement it. The difference = is that, if you do implement that "mobility stack", with conditional = support you run that code for one app only (and route the respective = packets accordingly), while with today's approach you do the same for = 101 apps. Fair reasoning. However, what is the "mobility stack" here then? Is it = something we today understand as a MIP enabled stack or could it be = something more generic? What I mean here is that we should be very = cautious with MN side impacts not to freak out less mobility cautious = people. If the "mobility stack" could be beneficial also outside = mobility use cases that would be awesome. - Jouni >=20 > Best Regards, >=20 > Kostas >=20 >=20 >=20 >=20 >=20 >=20 >=20 From jouni.nospam@gmail.com Thu Nov 15 03:17:10 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2393F21F84D3 for ; Thu, 15 Nov 2012 03:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxxvuIM2YZQ5 for ; Thu, 15 Nov 2012 03:17:09 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 635CF21F85E3 for ; Thu, 15 Nov 2012 03:17:09 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1000694eek.31 for ; Thu, 15 Nov 2012 03:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dF5wOrHWYBe5K18J/h/YpTWkti/RpE1z4zLEGh86O7s=; b=DHGsNFjj3GbW4Lq6SygvQfdkCYpsiYYM1JSwSfaDcDhxzjIAC2P93VdZ9d8TudzeQa j+JwfCivVOPvfYFpRu7TOiBIZor7h6QcrTHntepHHA34x9kLXnjf1VyIqYY46LCQjH9t SGypUXpEJnw1RyG/K068cKpP3EhoUXVDOUvmTflWV1ffLK1XhATevBWh4NOS+ndFFANu 1GOiSUQZwsWzScfZvjhAPwEoBuMEMujP1GNWVt8KeiMd9FpDyVqsvG/e1ZaXpvV50/Qp P4OV0qJr8QyMvcTmcg6NUrqZOCFuSrJ+M5gEWgtHJ8paWrzJVfrNWWYAsrxm7qq53OJ7 BByA== Received: by 10.14.173.71 with SMTP id u47mr2936729eel.20.1352978228593; Thu, 15 Nov 2012 03:17:08 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id i1sm35609168eeo.8.2012.11.15.03.17.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 03:17:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 15 Nov 2012 13:17:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de> <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1085) Cc: Peter McCann , Stig Venaas , dmm@ietf.org, Konstantinos Pentikousis Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 11:17:10 -0000 On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: >=20 > I think we are reading too much into multicast and unicast should be > designed in an integrated manner. >=20 > The fact is that multicast is considered as an area of specialization, > it requires knowledge of very different protocols than we are > accustomed to in mobility. "Requirement: DMM solutions SHOULD support multicast services. If a = specific DMM solution does not support multicast services, an = explanation MUST be provided." To me that reads basically "do not break foundations for multicast = unless you have a valid & documented reason for it". If we look e.g. = into RFC625 multicast wording that is there very briefly but gives a = hint to a developer where to head to. That is the level I would expect = DMM documents should aim to. - Jouni > Let dmm deal with its current charter that does not include a word of > multicast and if everything goes well we can come back and discuss dmm > multicast. >=20 > Regards, >=20 > Behcet From jouni.nospam@gmail.com Thu Nov 15 06:17:20 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDF321F84E6 for ; Thu, 15 Nov 2012 06:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz5-wlEW6HJy for ; Thu, 15 Nov 2012 06:17:18 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF8421F85FA for ; Thu, 15 Nov 2012 06:17:17 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so762178eaa.31 for ; Thu, 15 Nov 2012 06:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=XZHYTCJiNEeEKqxOTZYC5GMiSRsIdrHiVVK6Y9S5UUM=; b=q5VekWS6bRK/VnzViXxtZ5Edq3Vqt6MTWcEFQmgFNUymBrHdWGNInlB25qd5ZxqMnm bQ1c4+XcXY1joOvHTQbWKvKg5Mu/ALVkwogZDZjxbIF7ROhrfi24wIiZCw5jCwCol/PU DU6rDid40w2Gz8nYtM3yrQhtRyniD+2SQiknmjVoUE6oKc0xrmLHRBa/uVcpXsJSoLpz 9PYz/aP7S2PnxOLHnH6mH/wW1qvxWuMsHJDGrqCogIElRf7FHtdZhtMpGigS7bfPfesf gUSiZB7rMVG9OAAgO6mb82xTeej6pn4Y/QngkLvxq1sW8amX9wGDKYInls7babug1utm whCA== Received: by 10.14.209.136 with SMTP id s8mr4101265eeo.33.1352989037270; Thu, 15 Nov 2012 06:17:17 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id d44sm36433465eeo.10.2012.11.15.06.16.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 06:16:51 -0800 (PST) From: Jouni Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Nov 2012 16:16:48 +0200 Message-Id: To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Julien Laganier Subject: [DMM] Draft meeting minutes X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:17:20 -0000 Folks, Check the draft minutes. And thanks to Peer and Carlos for excellent & = detailed minutes. These are combined from those both. - Jouni ----------------- DMM WG meeting started at 9:00 am Thursday November 08, 2012.=20 WG chair Jouni Korhonen (JK) and Julien Laganier (JL) chaired the = meeting. Minute takers: Peer Azmat Shah and Carlos Bernandos ** Agenda and WG update =20 Jouni discussed the milestones of the DMM WG. He told that in Jan 2013 = we have to submit I-D =93Solution requirements=94 to IESG for consideration as = informational RFC. Also, in March 2013 we have to submit I-D =91Gap Analysis=94 to = IESG for consideration as an informational RFC. In March 2012, we also have to = evaluate the need for further work based on the identified Gap Analysis and have = to revise the milestones and/or charter of the group.=20 Keorgios Karagiannis (GK): there is no framework draft in the milestones = list. Would this be included in the gap analysis document? JK: this is a grey area, the gap analysis should be based on operational experience. Brian Haberman (BH): this has to do with how you design the protocol. = Once the current milestones are complete, this can be analyzed as part of = the rechartering process. Marco Liebsch (ML): it is useful to have design goals, I'm not proposing = to have a design goals document, but the content should be anchored = somewhere, maybe in the requirements document. JK: this is why we have a requirements document. At the end of the = meeting we will ask which of the four documents would be the baseline for the = current practices and gap analysis milestone. It does not make sense to keep = the four documents evolving. Konstantinos Pentikousis (KP): the gap analysis is kind-of an analytical = work. The current practices is different. It is better to have two different = documents. They can be combined for the publication phase at the end, but they = are two different jobs. JK: I have a problem of doing a gap analysis based on something you do = not have. KP: you do it based on the specifications and the requirements. The gap = analysis should have to do with operational aspects and also with what is = missing from current specs. Specs might not specify something, but leave the = freedom to do it in a different way. But if something is missing on the current = specs, this should also be considered. ** draft-ietf-dmm-requirements =20 Anthony Chan (AC) discussed the DMM requirements. A suggestion was given = by an audience that unicast and multicast requirements should be done in = advance and we have to keep every thing together and multicast should not be left = for later on. Luo Wen (LW): Question on Req5, roaming and handover scenarios are = different. You have a PMIP domain and deploy a DMM domain. Since it is difficult = to explain here, I'll send an e-mail. AC: I don't understand the question. JL: Please, send suggested text you think is missing to the list. Peer Azmat (PA): do you need information from lower layers? JK: this is not considered in this group. GK: you had something on multicast, are you going to discuss it now? JK: I did not attend the MULTIMOB session but BH has something to = comment. BH: DMM is in the position to now take into consideration multicast. = Lets do everything together in DMM. CP: multicast and mobility have been around for a long time and even = many people say it is impossible to solve the multicast mobility problem. It is = important to understand the requirements of multicast. This could delay the work = on unicast DMM. GK: maybe we should have a requirement that states that the DMM solution = should have some hooks to multicast, solution specified in such a way that = can be extended to support multicast. Behcet Sarikaya (BS): with MULTIMOB co-chair hat on. The requirements = should be=20 done in DMM WG and the solution should be developed in the MULTIMOB WG. AC: are you in a position to propose concrete text? Seil Jeon (SJ): we have some text. JK: please suggest text to the mailing list. BH: the requirements should be here in the same single document. People = that=20 attended to MULTIMOB WG, please propose text for the DMM requirements document. BS: the current document that has been presented in MULTIMOB WG on DMM = is not=20 about requirements, it is about use cases. Karen Seil (KS): I'd like to see requirements in terms of performance = from an application point of view. If you are going to do multicast, do it = since the beginning, because it has security implications. JK: you do not need to wait for next meeting to say something, please = send=20 comments to the mailing list within this month. Juan-Carlos Zuniga (JCZ): It is good to bring multicast here. I also = agree with=20 CP that we should avoid bringing a too strong multicast requirement = that=20 jeopardizes or delays the rest of the work. Suggestion is to add a = requirement=20 on the "SHOULD" terms. KP: people should submit requirements for multicast. The other thing we = can do=20 is say that whatever solution MULTIMOB does, DMM should support it. I = prefer=20 the "outsourcing" solution, leaving the work to the MULTIMOB WG. Dapeng Liu (DL): the text on the requirements draft comes mainly from = the=20 charter and there is no multicast in the charter. If our intention is = to do a=20 solution for multicast and unicast, this is going to be hard. If = people have=20 strong requirement for multicast it is valid to add it here. ** draft-zuniga-dmm-gap-analysis =20 Next presentation was DMM Gap Analysis by Juan Carlos. He told that the difference of this draft from version 1 is that Charlie joined as an = author. Comments received from the people on the mailing list have been = addressed,=20 source address selection mechanism is added and also multihoming in IPv6 = is=20 included in this draft. Juan Carlos discussed that different existing = mobility=20 protocols follow the DMM requirements or not. Then he discussed the next = steps=20 to address latest comments received on 2nd version of draft. DL: the title is gap analysis, does it cover also current practices? JCZ: yes, two clear sections in the document, one covering the current=20= practices, while the other performs the gap analysis. DL: in my understanding, your document compares existing IP mobility = protocols=20 with requirements. We already have done that during the WG formation = process.=20 We do not need this at all, as we have already convinced people. JCZ: what we did in the document is to take a DMM eye on current IP = mobility=20 protocols and go forward on how specs could operate in DMM way, so we = think we=20 have done what the charter expects. Yuri Ismailov (YI): we should analyze functions of each of the = protocols, and=20 who operates them and how they can collaborate to achieve DMM. Ahmad Muhanna (AM): this is part of the protocol definition itself. JK: Yuri, please bring this to the mailing list. GK: you are missing a framework. Use the requirements, project them on = the=20 framework and then analyze how the solutions meet the requirement. It = is also=20 useful to include more solutions. The use case on cloud infrastructure = should=20 also be included. ML: I sent some comments to the list. This draft is valuable, follows a=20= bottom-up approach. I also agree with previous comment, we have = protocol=20 components and we should compare them with DMM functions. We need = bottom-up=20 and also top-down approaches. JL: related comment. In terms of how current practices are described = there.=20 There is one widely deployed mobile network, which is the 3GPP one. = This=20 should be added to the analysis (a new column). We need to compare = with=20 something that is out there, otherwise the analysis might end up being=20= academic. ** draft-liu-dmm-of-deployment =20 The presentation was about the deployment of existing mobility protocols = in DMM=20 scenarios. Dapeng Liu discussed that what the best current practice of = DMM is?=20 He added that before deploying existing protocols, first look whether it = is=20 feasible or not as DMM charter says. He added that motivation of this = practice=20 draft is that, there are many proposed solutions for DMM. A lot of = discussions=20 were made from the audience on the GTP and MobileIP. Julien was of the = opinion=20 that we should take help from the requirements and gap analysis of GTP = to be=20 used in the gap analysis for DMM, but all others was of the opposite = opinion. =20 JL: have you said that there is no deployment of mobility = specifications? GTP,=20 PMIPv6 and MIPv4 are deployed. Do not focus only on MIP, consider also = GPRS,=20 because it is deployed. JK: we have deployments of PMIPv6, DSMIP did not make it. We have = concrete=20 examples of solutions deployed. CP: saying that GTP is exaclty like PMIP is like saying a bike is like a = bus. Alex Petrescu (AP): comment on the previos academic aspect. It is hard = to do a =20 gap analysis on GTP, because at the IETF we do not have the GTP spec.=20= Regarding the use of MIP, and talking from the perspective of = vehicular=20 communications, we do see deployment in this field, with very strong=20= deployment plans. JL: it was not my intention to say we work on GTP and not on MIP. Just = use GTP=20 as another input. KP: we could also describe what happens on analog communications, but = we do not=20 have any way of affect or influence them. We may have an appendix = describing=20 GTP, but we should focus on what we can influence. KS: Interoperability issues would matter. You might want to identify = these, as=20 that would be helpful. CP: a lot of discussion is going around 3GPP. I wonder if the intention = is to do=20 solutions compatible with 3GPP. ** draft-chan-dmm-framework-gap-analysis=20 Next, Anthony Chan presented the unified view through reconfiguration of=20= existing functions. He identified 3 basic Internet functions and = mobility=20 functions. He said that we can redistribute the MIP and PMIP functions = into DMM=20 functions. Tricci: It is complex to read the draft. If you can simplify it, that = would be=20 helpful. ** draft-liebsch-dmm-framework-analysis =20 Marco Liebsch presented a set of functional entities that enable DMM use = cases=20 and IP address continuity. First he discussed the existing MobileIP and = DMM=20 entities, then he discussed the DD design constraints. He added that = these=20 design constraints have impact on the DMM solutions. He proposed that we = should=20 move to a general DMM functionality that can be applied to existing = mobility=20 protocols, rather than making a complete new DMM solution. It was = commented=20 that he does not agree on the statement of the presenter that it is not = a new=20 gap analysis. He said that presenter has proposed a new framework and = gap=20 analysis and at this point he is late, as majority of the things have = been=20 finalized in the gap analysis of the DMM WG. KP: I do not agree this is not a framework gap analysis. I think it = comes it a=20 bit late. Draft is on a very early stage. Overlaps 85% with previous = drafts. ML: the draft is meant to convey the message, hope to be adopted by = other draft. JCZ: when we were doing the analysis we missed some sort-of framework. I = do see=20 your draft as complementary. I think it would add value and be = complementary. GK: this is useful, not only for doing the analysis, but also to help = people=20 specify solutions. AM: thanks Marco. Really nice work. I agree with Kostas. ML: I disagree it overlaps 85% with other drafts. ** draft-seite-dmm-dma =20 Pierrick Seite discussed the basic practices of DMM deployment. The = usecase for=20 DMM is to distribute the functionality as much as possible closer to MN. = He discussed two different approaches: node centric and network centric. = Many=20 questions were asked from the audience and Jouni, WG Chair, told that = these=20 basic discussions should be made on the mailing list rather than to be = discussed=20 in the meeting. Alper Yegin (AY): when do you turn down the tunnel between the ARs (net = based=20 solution)? how do you know when to do it? PS: based on prefix lifetime. AY: might be long, communications might go longer than prefix lifetime. = I do not=20 think this is the best option. Tricci: when you move to a new AR, how do you get the same address? Pierrick Seite (PS): this is just PMIPv6. Tricci: PMIPv6 does not specify that right now. How does the MN keeps = the same=20 address? JL: you keep using the old address, session continuity exists as long as = you=20 keep the address anchored at the previous router. JL: you could use anycast to find the previous anchor. Carlos J. Bernardos (CJB): I think we are going too much in solution = space.=20 Obtaining used addressed by the MN is not a major issue. You can use = for=20 example a centralized LMA for control plane, or anycast as mentioned = by JL. Tricci: not an issue, just needs clarification. ** draft-korhonen-dmm-prefix-properties =20 Sri Gundavelli presented DMM prefix properties. Followed by a = presentation of=20 SP-WiFi Service for Retail model.=20 Sri Gundavelli (SG): asks the chairs to move this draft forward. YI: is it in scope adopting this in this group? JL: lets proceed with the presentation and then we discuss about that. YI: this option has to be provisioned, who does that? How an application = decides=20 which address to use? SG: that decision is performed based on the policy table, we are just = populating=20 the table, we are not telling the host what to do. That is defined in = RFC=20 3484. JL: in addition to policy table there is also an API that allows the = application=20 to prefer home vs care-of address. One question I have: you have local=20= breakout, for some traffic you want to have it centraly anchored. Do = you=20 expect to have most of the traffic locally broken out? why do not you = use=20 source address selection policies provisioned with DHCP? CP: (missed comment) SG: not familiar with these solutions, I have to take a look at it. Pascal Thubert (PT): the scope is not clear. If you want to have local=20= communications, you can use the addressing architecture, for example, = using=20 ULAs to use a local printer. SG: the host should be aware that the local address has no mobility = properties,=20 and has to deprecate when moving. Any application with mobility = requirements=20 should use a mobility-enabled address. BH: I'm looking a draft that contains a security bit and a mobility bit. = Am I=20 looking at the right draft? JK: yes. BH: so you are doing more than mobility capabilities. What was the = rationale of=20 associating this with the PIO and not with the RA itself? Are the = capabilities=20 associated with the prefix or with the link? SG: with the PIO. BH: we have mobility, we have security, which other things you want to=20= advertise? it has an impact on where this draft should be discussed. SG: if we set up a registry, then new drafts can come and register other = uses=20 for capabilities associated with prefixes. AP: is this only for PMIPv6? when you talk source address selection, = this=20 address is only obtained from a prefix in PMIPv6. In DHCP it is not. SG: also with SLAAC. AP: if we do source address selection, it sounds strange to put this = capability=20 on the prefix. If we were doing prefix address selection, then it = would. When=20 you put a single capability on a prefix, you force all the addresses = for that=20 address to share the same capability. SG: if you want properties at address level, then you cannot put it on = prefix=20 level. AY: you might want to look at RFCXXXX (missed the number). YI: your proposal seemed to be about address selection, but your = presentation is=20 about RA options. SG: maybe title was not good. YI: if you are talking about address selection, I don't think this work = belongs=20 to this WG. ** draft-gundavelli-v6ops-community-wifi-svcs=20 SG presents the slides. JCZ: quick comment. In the IEEE 802 there is this OMNIRAN group = discussing very=20 similar issues. Over there, discusssion is more 802 wide. I just = wanted to=20 make the group to be aware, there might be some coordination required. ** draft-sarikaya-dmm-cloud-mm =20 Bechet Sarikaya presented mobility management protocols for cloud like=20= architectures. He discussed the MIPv6 for cloud and told that there are = two HA=20 planes, HA control plan for data and HA control for Handover. Handover = HA=20 control plane resides in the cloud. He also discussed PMIPv6 for cloud = and=20 concluded that PMIPv6 requires fewer changes for DMM as compared to = MPIv6 in=20 cloud. Sarikaya told that if you want to contribute to this draft then = please=20 comment on the mailing list. GK: as I have already mentioned on the mailing list, many mobility = functions can=20 be implemented in the cloud. Many EU projects and companies are = looking at=20 this. This should be considered as a use case in DMM. ** wrap up Jouni concluded the meeting with a discussion on the current practices = and gap=20 analysis and told that we are going to discuss the current practices and = gap=20 analysis on the mailing list so that we can have an IETF document before = the=20 next IETF meeting. Final discussion was that whether we should merge the = two=20 drafts, gap analysis and current practices, or select one before the = next=20 meeting.=20 JK: contribute text for multicast to the requirements. Do not wait until = March,=20 do it next week, this month. JK: the other thing is the gap analysis. We have a couple of potential=20= candidates for a baseline for write up as WG document. We are going to=20= initiate this discussion on the mailing list, and we are going to pick = up one,=20 so we have a document before next IETF. Tricci: question. If two drafts merge into one, is this not allowed? JL: we are going to ask people what they want to do. Authors of these = drafts,=20 please talk during this week. AP: is it up to the authors to organize however they want? BH: if the authors want to merge, great, but the WG cannot force them to = do it. KP: I would prefer that we address the comments and we have a more = constructive=20 approach. Main point is not to loose information in the process. We = will take=20 it offline. JK: this will be initiated shortly after the meeting. From sfigueiredo@av.it.pt Fri Nov 16 06:59:21 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C8021F8858 for ; Fri, 16 Nov 2012 06:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sa0hTO9i7cD for ; Fri, 16 Nov 2012 06:59:19 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51921F8859 for ; Fri, 16 Nov 2012 06:59:17 -0800 (PST) Received: from [193.136.93.70] (account sfigueiredo@av.it.pt [193.136.93.70] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67048008 for dmm@ietf.org; Fri, 16 Nov 2012 14:59:15 +0000 Message-ID: <50A654C5.5030601@av.it.pt> Date: Fri, 16 Nov 2012 14:59:17 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dmm@ietf.org References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <014801cdc127$e9b9b6c0$bd2d2440$@av.it.pt> In-Reply-To: <014801cdc127$e9b9b6c0$bd2d2440$@av.it.pt> Content-Type: multipart/alternative; boundary="------------000008020707070200020901" Subject: Re: [DMM] Multicast requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:59:22 -0000 This is a multi-part message in MIME format. --------------000008020707070200020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, As requested we have been working on a proposal for updating current DMM Requirements draft, reflecting the work developed in "draft-sfigueiredo-multimob-use-case-dmm-03.txt". We were careful to follow the expressed concerns, mainly by not impacting the current (mostly accepted) draft structure and content. As such, we propose the following 2 changes: # Proposal 1 - small update to PS1 # PS1: Non-optimal routesRouting via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), *or when using IP multicasting*. # Proposal 2 - Add a new requirement# REQ8: Flexible multicast distribution "DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints". Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6. PS6: Duplicate multicast traffic IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the tunnel's downstream entity (e.g. MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03]. Best regards, Sérgio & Seil On 11/12/2012 10:49 PM, Seil Jeon wrote: > Hi Pete, > > That might be one of them we can take on DMM. Imagine, depending on > deployment of existing IP multicasting standard entities, we can think of > various use cases as presented in > http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. > Direct routing cannot be applied in every scenario. > > After I came back from the trip, we (me and Sergio) have been working on > this with priority. After carefully reviewing the requirement from the use > cases, we'll announce it soon. > > Regards, > Seil > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Peter > McCann > Sent: Monday, November 12, 2012 9:53 PM > To: Thomas C. Schmidt > Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > In the DMM case my assumption is that the anchor points are closer to the > access routers and therefore are very likely to be in the same > administrative domain. In these cases, joining the multicast group directly > from the access router gives you the same access to the same multicast > streams and so tunneling the multicast packets won't be necessary. > > -Pete > > Thomas C. Schmidt wrote: >> Dear Pete, >> >> multicast mobility management is a route adaptation problem. As in the >> unicast case, mobility can only be treated by routing dynamics in >> trivial cases (re-connect of a tunnel, re-association with next hop). >> Otherwise it is unwise to delegate mobility adaptation to routing >> protocols (-> OSPF, BGP ...). >> >> Accordingly, if DMM distributes mobility operations, handover >> management should foresee easy interconnects to previous distribution >> trees - both for receivers and for mobile multicast sources. >> >> I guess, if DMM people are careful, this is not a world-class item and >> can be treated along the lines of unicast solutions - an isolated >> multicast protocol treatment (as has been previously proposed from >> MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment >> has turned out to work out simply (-> RFC6224). >> >> Thus my argument: talk to the multicast guys before adopting a >> solution ... and make the rest an easy game. >> >> Cheers, >> >> Thomas >> >> On 12.11.2012 21:39, Peter McCann wrote: >>> jouni korhonen wrote: >>>> Folks, >>>> >>>> This mail is to kick off the discussion on multicast requirement(s) >>>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>>> down the essential multicast requirement(s) as soon as possible. >>> To me, multicast in a DMM environment means joining multicast groups >>> directly from access routers. It means re-joining the multicast tree >>> from a new access router after handover. I would hope that we can >>> use existing MLD protocols between the MN and its first hop AR to >>> accomplish this. >>> >>> -Pete >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --------------000008020707070200020901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

As requested we have been working on a proposal for updating current DMM Requirements draft, reflecting the work developed in "draft-sfigueiredo-multimob-use-case-dmm-03.txt". We were careful to follow the expressed concerns, mainly by not impacting the current (mostly accepted) draft structure and content.
As such, we propose the following 2 changes:

# Proposal 1 - small update to PS1 #

PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), or when using IP multicasting.


# Proposal 2 - Add a new requirement#

REQ8: Flexible multicast distribution

"DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6.

PS6: Duplicate multicast traffic

IP multicast distribution over architectures using IP mobility solutions  may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].


Best regards,
Sérgio & Seil


On 11/12/2012 10:49 PM, Seil Jeon wrote:
Hi Pete,

That might be one of them we can take on DMM. Imagine, depending on
deployment of existing IP multicasting standard entities, we can think of
various use cases as presented in
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03.
Direct routing cannot be applied in every scenario.

After I came back from the trip, we (me and Sergio) have been working on
this with priority. After carefully reviewing the requirement from the use
cases, we'll announce it soon.

Regards,
Seil

-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Peter
McCann
Sent: Monday, November 12, 2012 9:53 PM
To: Thomas C. Schmidt
Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

In the DMM case my assumption is that the anchor points are closer to the
access routers and therefore are very likely to be in the same
administrative domain.  In these cases, joining the multicast group directly
from the access router gives you the same access to the same multicast
streams and so tunneling the multicast packets won't be necessary.

-Pete

Thomas C. Schmidt wrote:

Dear Pete,

multicast mobility management is a route adaptation problem. As in the 
unicast case, mobility can only be treated by routing dynamics in 
trivial cases (re-connect of a tunnel, re-association with next hop).
Otherwise it is unwise to delegate mobility adaptation to routing 
protocols (-> OSPF, BGP ...).

Accordingly, if DMM distributes mobility operations, handover 
management should foresee easy interconnects to previous distribution 
trees - both for receivers and for mobile multicast sources.

I guess, if DMM people are careful, this is not a world-class item and 
can be treated along the lines of unicast solutions - an isolated 
multicast protocol treatment (as has been previously proposed from 
MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment 
has turned out to work out simply (-> RFC6224).

Thus my argument: talk to the multicast guys before adopting a 
solution ... and make the rest an easy game.

Cheers,

Thomas

On 12.11.2012 21:39, Peter McCann wrote:

jouni korhonen wrote:

Folks,

This mail is to kick off the discussion on multicast requirement(s) 
for the draft-ietf-dmm-requirements-02 document. I hope we can nail 
down the essential multicast requirement(s) as soon as possible.

To me, multicast in a DMM environment means joining multicast groups 
directly from access routers.  It means re-joining the multicast tree 
from a new access router after handover.  I would hope that we can 
use existing MLD protocols between the MN and its first hop AR to 
accomplish this.

-Pete

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



      

      


_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


    

    

  


--------------000008020707070200020901--

From stig@venaas.com  Fri Nov 16 12:01:29 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF821F8B00 for ; Fri, 16 Nov 2012 12:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIxo+tNXH+MT for ; Fri, 16 Nov 2012 12:01:29 -0800 (PST)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E03E721F8B24 for ; Fri, 16 Nov 2012 12:01:21 -0800 (PST)
Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3DB3B7FC7; Fri, 16 Nov 2012 21:01:19 +0100 (CET)
Message-ID: <50A69B8C.6050309@venaas.com>
Date: Fri, 16 Nov 2012 12:01:16 -0800
From: Stig Venaas 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: jouni korhonen 
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com>
In-Reply-To: <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Peter McCann , dmm@ietf.org, Konstantinos Pentikousis 
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 20:01:29 -0000

On 11/15/2012 3:17 AM, jouni korhonen wrote:
>
> On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
>
>>
>> I think we are reading too much into multicast and unicast should be
>> designed in an integrated manner.
>>
>> The fact is that multicast is considered as an area of specialization,
>> it requires knowledge of very different protocols than we are
>> accustomed to in mobility.
>
> "Requirement: DMM solutions SHOULD support multicast services. If a specific DMM solution does not support multicast services, an explanation MUST be provided."

This sounds good to me.

The main thing I want to achieve is what was describes as motivation
earlier in this thread. Multicast should at least be considered when
looking into DMM solutions, and not just an afterthought once the
solution is decided.

Stig

> To me that reads basically "do not break foundations for multicast unless you have a valid & documented reason for it".  If we look e.g. into RFC625 multicast wording that is there very briefly but gives a hint to a developer where to head to. That is the level I would expect DMM documents should aim to.
>
> - Jouni
>
>
>> Let dmm deal with its current charter that does not include a word of
>> multicast and if everything goes well we can come back and discuss dmm
>> multicast.
>>
>> Regards,
>>
>> Behcet


From JuanCarlos.Zuniga@InterDigital.com  Fri Nov 16 12:14:26 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C021F86AB for ; Fri, 16 Nov 2012 12:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level: 
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q80y70mu68C8 for ; Fri, 16 Nov 2012 12:14:25 -0800 (PST)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2D21F85DF for ; Fri, 16 Nov 2012 12:14:25 -0800 (PST)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 16 Nov 2012 15:14:22 -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: Fri, 16 Nov 2012 15:14:21 -0500
Message-ID: 
In-Reply-To: <50A69B8C.6050309@venaas.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [DMM] Multicast requirements
Thread-Index: Ac3ENShuQxC2a3JARliciluOX40A9gAAY0uw
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com>
From: "Zuniga, Juan Carlos" 
To: "Stig Venaas" , 
X-OriginalArrivalTime: 16 Nov 2012 20:14:22.0320 (UTC) FILETIME=[F77F3700:01CDC436]
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 20:14:26 -0000

> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>=20
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>=20
> This sounds good to me.
>=20
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>=20
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed
text.

Regards,

Juan Carlos
=20
>=20
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet


From sarikaya2012@gmail.com  Fri Nov 16 13:20:40 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9321F8A65 for ; Fri, 16 Nov 2012 13:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.585
X-Spam-Level: 
X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LerpMtq3AaII for ; Fri, 16 Nov 2012 13:20:40 -0800 (PST)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2120821F898C for ; Fri, 16 Nov 2012 13:20:40 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id j26so2203704iaf.31 for ; Fri, 16 Nov 2012 13:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=YsYmn5k3xeBkHVsjjeCydaCjTwl6TdsOwNKRdrSMAk8=; b=EhpZZagiaVKYWPSnjAJtxRZrzN3z8HLdgLTkeu1VJFBbtQLKp26ShIhzHRknRZHHjq beU1iaEG3dd5R89vIa9HJQtfgCbp5cMc3I5B2jfawr/qkXEilb+DS2ek7Dic5O9Pa3h0 J3tGz1jaePzTGdv7dQb5ejBU+G2gRkxuvCjzIFpBzzhCIehifxB0VlK1BsNOMhRU9cJs 3sIUu3dNoFjWHfgAiV8Uc+5gdU0rptM4NDZbUvvUKTS3VKCrnxn4zki0tpwEHAP09QZT DLYJLUJAmGc6uM/lP2QdpruW68shUcwp3W6iMatCGDoMoohjLQ5psKV8HxJGxqUaNX3p otUw==
MIME-Version: 1.0
Received: by 10.42.147.74 with SMTP id m10mr5103918icv.0.1353100839630; Fri, 16 Nov 2012 13:20:39 -0800 (PST)
Received: by 10.231.85.26 with HTTP; Fri, 16 Nov 2012 13:20:39 -0800 (PST)
Date: Fri, 16 Nov 2012 15:20:39 -0600
Message-ID: 
From: Behcet Sarikaya 
To: karagian@cs.utwente.nl
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: dmm@ietf.org
Subject: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 21:20:40 -0000

Hi Georgios,

Can you please suggest some requirements on cmm in DMM?

I think that it would be relevant and useful to DMM while requirements
are still being discussed.

Regards,

Behcet
On Sun, Nov 4, 2012 at 1:52 PM,   wrote:
> Hi Behcet,
>
> I would like to mention that I find this draft useful due to the followin=
g reasons.
>
> Currently, there is a trend to implement more and more functions of a mob=
ile communication network in software, e.g., for signal and protocol proces=
sing. This enables the use of cloud computing infrastructures as processing=
 platforms for signal and protocol processing of mobile communication netwo=
rks, in particular for current (4G) and future (5G) generation cellular net=
works.
> This can of course only be realized if, among others, efficient mobility =
management solutions are supported like the ones that are in line with what=
 DMM would like to specify.
> I think therefore, that the DMM WG could also consider the distributed mo=
bility management support in cloud computing like architectures as a possib=
le use case.
>
> Regarding your draft I have some comments:
> The draft mentions some limitation of the existing mobility management so=
lutions in cloud-like architectures. However, these limitations are not cle=
arly focussing on the requirements specified in http://www.ietf.org/id/draf=
t-ietf-dmm-requirements-02.txt.
> I think that this will make the desciption of the limitations clearer!
> Moreover, it might also be useful to show describe these limitations by u=
sing as use as context a generic framework, like the one introduced in http=
://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and/or
> http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.
>
> Best regards,
> Georgios
>
>
>
>
> ________________________________________
> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikaya [=
sarikaya2012@gmail.com]
> Verzonden: dinsdag 23 oktober 2012 21:51
> To: dmm@ietf.org
> Onderwerp: [DMM] New Version Notification for   draft-sarikaya-dmm-cloud-=
mm-00.txt
>
> Hi all,
>
> I have submitted a new draft on Mobility Management Protocols for
> Cloud-Like Architectures, for details see below.
>
> Chairs: please reserve a slot in IETF 85 session if possible.
>
> Regards,
>
> Behcet
>
> A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Filename:        draft-sarikaya-dmm-cloud-mm
> Revision:        00
> Title:           Mobility Management Protocols for Cloud-Like Architectur=
es
> Creation date:   2012-10-15
> WG ID:           Individual Submission
> Number of pages: 11
> URL:
> http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud=
-mm
> Htmlized:        http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-0=
0
>
>
> Abstract:
>    Telecommunication networks are being virtualized and are moving into
>    the cloud networks.  This brings the need to redesign the mobility
>    protocols of Mobile and Proxy Mobile IPv6.  This document defines
>    mobility management protocols for virtualized networks.  Control and
>    data plane separation is achieved by separating Home Agent and Mobile
>    Access Gateway functionalities into the control and data planes.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

From seiljeon@av.it.pt  Fri Nov 16 13:25:29 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77321F8484 for ; Fri, 16 Nov 2012 13:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugZ8cnjMqpec for ; Fri, 16 Nov 2012 13:25:28 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 158C521F844A for ; Fri, 16 Nov 2012 13:25:27 -0800 (PST)
Received: from [193.136.93.253] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67051119; Fri, 16 Nov 2012 21:25:26 +0000
From: "Seil Jeon" 
To: "'Zuniga, Juan Carlos'" 
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>	<5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com>	<50A16AE0.70101@fhtw-berlin.de>	<5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com>	<50A172AC.5090308@fhtw-berlin.de>		<8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com>	<61CEE523-F244-486B-AA95-591828D53EED@gmail.com>		<8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>			<500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com>	<50A69B8C.6050309@venaas.com> 
In-Reply-To: 
Date: Fri, 16 Nov 2012 21:25:43 -0000
Message-ID: <000601cdc440$ef947f50$cebd7df0$@av.it.pt>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDpvfVQJP8hzaX/j8eL/mEb+S6VGQFDovgtAWOj9LkCV0872QJCguPBArNqST4DOAIq+gKAnybWAiMZa28AsJ0RhAGsXNOSAWW2xzICO5diUAJYPa3lAgTlok6Y05onoA==
Content-Language: ko
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 21:25:29 -0000

Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions but
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
> 
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are 
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an 
> explanation MUST be provided."
> 
> This sounds good to me.
> 
> The main thing I want to achieve is what was describes as motivation 
> earlier in this thread. Multicast should at least be considered when 
> looking into DMM solutions, and not just an afterthought once the 
> solution is decided.
> 
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos
 
> 
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a 
> hint to a developer where to head to. That is the level I would expect 
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


From karagian@cs.utwente.nl  Sat Nov 17 04:01:31 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D69421F854B for ; Sat, 17 Nov 2012 04:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.353
X-Spam-Level: 
X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDJHRBJpiHfd for ; Sat, 17 Nov 2012 04:01:30 -0800 (PST)
Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id BB7B621F8527 for ; Sat, 17 Nov 2012 04:01:29 -0800 (PST)
Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 17 Nov 2012 13:01:43 +0100
Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sat, 17 Nov 2012 13:01:28 +0100
From: 
To: , 
Thread-Topic: [DMM] Multicast requirements
Thread-Index: AQHNwRA0ROEvu/ugykqiqasOU9dSupfmmKIAgAAO2QCAAAXjAIAAA2gAgAAM7ICAAQuEgIAAbPwAgABYcwCAAPdQAIAAEXOAgABOFgCAAM0agIACJMkAgAADqICAABPxgIAA/N76gAAIloU=
Date: Sat, 17 Nov 2012 12:01:27 +0000
Message-ID: 
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt>
In-Reply-To: <000601cdc440$ef947f50$cebd7df0$@av.it.pt>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [86.91.134.3]
Content-Type: multipart/alternative; boundary="_000_BE9EEFD1660D4560A928AEAE093F34A1mimectl_"
MIME-Version: 1.0
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Nov 2012 12:01:31 -0000

--_000_BE9EEFD1660D4560A928AEAE093F34A1mimectl_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Seil Jeon [seiljeon=
@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements

Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that m=
y
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions bu=
t
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

--_000_BE9EEFD1660D4560A928AEAE093F34A1mimectl_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <15EDB2CEC73A4A4AB2CD5EA0A067A1C9@exchange.utwente.nl>
Content-Transfer-Encoding: quoted-printable










Hi all,


 


I also agree that the DMM solution should somehow consider muticast depl=
oyment. However, I do not thnk that the DMM WG is the right WG to provide t=
he multicast based DMM solution!


 


One alternative solution will be to have a multicast requirement that em=
phasizes the need of having extensibility hooks (possibilities) that can be=
 used later on by the multimob WG to provide a



a multicast enabled DMM solution!


 


 


So a requirement that specifies something like the following could be us=
ed for this purpose:


 


"The DMM (unicast) solution MUST be specified in such a way th=
at it can be extended to also support multicast traffic."


 


 


Best regards,


Georgios


 


 


 






Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Seil Jeo=
n [seiljeon@av.it.pt]

Verzonden: vrijdag 16 november 2012 22:25

To: 'Zuniga, Juan Carlos'

Cc: dmm@ietf.org

Onderwerp: Re: [DMM] Multicast requirements











Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.com]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis; =


> Peter McCann; dmm@ietf.org

> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/dmm



_______________________________________________

dmm mailing list

dmm@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/dmm








--_000_BE9EEFD1660D4560A928AEAE093F34A1mimectl_--

From karagian@cs.utwente.nl  Sat Nov 17 04:28:36 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF6421F8545 for ; Sat, 17 Nov 2012 04:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.383
X-Spam-Level: 
X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcaFtRUBz+6x for ; Sat, 17 Nov 2012 04:28:35 -0800 (PST)
Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id E12FE21F84DC for ; Sat, 17 Nov 2012 04:28:34 -0800 (PST)
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 17 Nov 2012 13:28:48 +0100
Received: from EXMBX04.ad.utwente.nl ([169.254.4.65]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Sat, 17 Nov 2012 13:28:33 +0100
From: 
To: 
Thread-Topic: Requirements on cmm
Thread-Index: AQHNxEA9HB5eBaBA0kWagnUmHfZBPpft8qfAgAAC+Y0=
Date: Sat, 17 Nov 2012 12:28:33 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [86.91.134.3]
Content-Type: multipart/alternative; boundary="_000_BC258C8560C4498C8ECCB979F0F6CB24mimectl_"
MIME-Version: 1.0
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Nov 2012 12:28:36 -0000

--_000_BC258C8560C4498C8ECCB979F0F6CB24mimectl_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Behcet, Hi all,



Regarding the cloud like architecture use case, the requirement that could =
be used for this purpose can be the following one:



"The DMM solution MAY have the ability to be applied in virtualized and/or =
cloud like archietctures."



Motivation:



Currently, there is a trend to implement more and more functions of a mobil=
e communication network in software, e.g., for signal and protocol processi=
ng. This enables the use of cloud computing infrastructures as processing p=
latforms for signal and protocol processing of mobile communication network=
s, in particular for current (4G) and future (5G) generation cellular netwo=
rks. This can only be realized if, among others, efficient DMM solutions ar=
e supported by the cloud computing architectures.



Best regards,

Georgios

________________________________
Van: Behcet Sarikaya [sarikaya2012@gmail.com]
Verzonden: vrijdag 16 november 2012 22:20
To: Karagiannis, G. (EWI)
Cc: dmm@ietf.org
Onderwerp: Requirements on cmm

Hi Georgios,

Can you please suggest some requirements on cmm in DMM?

I think that it would be relevant and useful to DMM while requirements
are still being discussed.

Regards,

Behcet
On Sun, Nov 4, 2012 at 1:52 PM,   wrote:
> Hi Behcet,
>
> I would like to mention that I find this draft useful due to the followin=
g reasons.
>
> Currently, there is a trend to implement more and more functions of a mob=
ile communication network in software, e.g., for signal and protocol proces=
sing. This enables the use of cloud computing infrastructures as processing=
 platforms for signal and protocol processing of mobile communication netwo=
rks, in particular for current (4G) and future (5G) generation cellular net=
works.
> This can of course only be realized if, among others, efficient mobility =
management solutions are supported like the ones that are in line with what=
 DMM would like to specify.
> I think therefore, that the DMM WG could also consider the distributed mo=
bility management support in cloud computing like architectures as a possib=
le use case.
>
> Regarding your draft I have some comments:
> The draft mentions some limitation of the existing mobility management so=
lutions in cloud-like architectures. However, these limitations are not cle=
arly focussing on the requirements specified in http://www.ietf.org/id/draf=
t-ietf-dmm-requirements-02.txt.
> I think that this will make the desciption of the limitations clearer!
> Moreover, it might also be useful to show describe these limitations by u=
sing as use as context a generic framework, like the one introduced in http=
://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and/or
> http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.
>
> Best regards,
> Georgios
>
>
>
>
> ________________________________________
> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikaya [=
sarikaya2012@gmail.com]
> Verzonden: dinsdag 23 oktober 2012 21:51
> To: dmm@ietf.org
> Onderwerp: [DMM] New Version Notification for   draft-sarikaya-dmm-cloud-=
mm-00.txt
>
> Hi all,
>
> I have submitted a new draft on Mobility Management Protocols for
> Cloud-Like Architectures, for details see below.
>
> Chairs: please reserve a slot in IETF 85 session if possible.
>
> Regards,
>
> Behcet
>
> A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Filename:        draft-sarikaya-dmm-cloud-mm
> Revision:        00
> Title:           Mobility Management Protocols for Cloud-Like Architectur=
es
> Creation date:   2012-10-15
> WG ID:           Individual Submission
> Number of pages: 11
> URL:
> http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud=
-mm
> Htmlized:        http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-0=
0
>
>
> Abstract:
>    Telecommunication networks are being virtualized and are moving into
>    the cloud networks.  This brings the need to redesign the mobility
>    protocols of Mobile and Proxy Mobile IPv6.  This document defines
>    mobility management protocols for virtualized networks.  Control and
>    data plane separation is achieved by separating Home Agent and Mobile
>    Access Gateway functionalities into the control and data planes.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

--_000_BC258C8560C4498C8ECCB979F0F6CB24mimectl_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










Hi Behcet, Hi all,


 


Regarding the cloud like architecture use case, the requirement that cou=
ld be used for this purpose can be the following one:


 


"The DMM solution MAY have the ability to be applied in virtualized=
 and/or cloud like archietctures."


 


Motivation:


 


Currently, there is a trend to implement more and more functions of a mo=
bile communication network in software, e.g., for signal and protocol proce=
ssing. This enables the use of cloud computing infrastructures as processin=
g platforms for signal and protocol
 processing of mobile communication networks, in particular for current (4G=
) and future (5G) generation cellular networks. This can only be realized i=
f, among others, efficient DMM solutions are supported by the cloud computi=
ng architectures.


 


Best regards,


Georgios








Van: Behcet Sarikaya [sarikaya2012@gmail.com]

Verzonden: vrijdag 16 november 2012 22:20

To: Karagiannis, G. (EWI)

Cc: dmm@ietf.org

Onderwerp: Requirements on cmm











Hi Georgios,



Can you please suggest some requirements on cmm in DMM?



I think that it would be relevant and useful to DMM while requirements

are still being discussed.



Regards,



Behcet

On Sun, Nov 4, 2012 at 1:52 PM,  <karagian@cs.utwente.nl> wrote:=


> Hi Behcet,

>

> I would like to mention that I find this draft useful due to the follo=
wing reasons.

>

> Currently, there is a trend to implement more and more functions of a =
mobile communication network in software, e.g., for signal and protocol pro=
cessing. This enables the use of cloud computing infrastructures as process=
ing platforms for signal and protocol
 processing of mobile communication networks, in particular for current (4G=
) and future (5G) generation cellular networks.

> This can of course only be realized if, among others, efficient mobili=
ty management solutions are supported like the ones that are in line with w=
hat DMM would like to specify.

> I think therefore, that the DMM WG could also consider the distributed=
 mobility management support in cloud computing like architectures as a pos=
sible use case.

>

> Regarding your draft I have some comments:

> The draft mentions some limitation of the existing mobility management=
 solutions in cloud-like architectures. However, these limitations are not =
clearly focussing on the requirements specified in

http://www.ietf.org/id/draft-ietf-dmm-requirements-02.txt.

> I think that this will make the desciption of the limitations clearer!=


> Moreover, it might also be useful to show describe these limitations b=
y using as use as context a generic framework, like the one introduced in

http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and=
/or

> 
http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.

>

> Best regards,

> Georgios

>

>

>

>

> ________________________________________

> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikay=
a [sarikaya2012@gmail.com]

> Verzonden: dinsdag 23 oktober 2012 21:51

> To: dmm@ietf.org

> Onderwerp: [DMM] New Version Notification for   draft-sarika=
ya-dmm-cloud-mm-00.txt

>

> Hi all,

>

> I have submitted a new draft on Mobility Management Protocols for

> Cloud-Like Architectures, for details see below.

>

> Chairs: please reserve a slot in IETF 85 session if possible.

>

> Regards,

>

> Behcet

>

> A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt

> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.

>

> Filename:        draft-sarikaya-dmm=
-cloud-mm

> Revision:        00

> Title:           Mob=
ility Management Protocols for Cloud-Like Architectures

> Creation date:   2012-10-15

> WG ID:           Ind=
ividual Submission

> Number of pages: 11

> URL:

> 
http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt<=
br>
> Status:          
http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud-mm

> Htmlized:        
http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-00

>

>

> Abstract:

>    Telecommunication networks are being virtualized and=
 are moving into

>    the cloud networks.  This brings the need to re=
design the mobility

>    protocols of Mobile and Proxy Mobile IPv6.  Thi=
s document defines

>    mobility management protocols for virtualized networ=
ks.  Control and

>    data plane separation is achieved by separating Home=
 Agent and Mobile

>    Access Gateway functionalities into the control and =
data planes.

>

>

>

>

> The IETF Secretariat

> _______________________________________________

> dmm mailing list

> dmm@ietf.org

> https://www.ietf.org/mailman/listinfo/dmm








--_000_BC258C8560C4498C8ECCB979F0F6CB24mimectl_--

From jouni.nospam@gmail.com  Sat Nov 17 15:05:00 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467F221F84F3 for ; Sat, 17 Nov 2012 15:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDDNtC3lR7CO for ; Sat, 17 Nov 2012 15:04:59 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1952E21F84F2 for ; Sat, 17 Nov 2012 15:04:58 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so813819eaa.31 for ; Sat, 17 Nov 2012 15:04:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pKOKpT1nzjAkLpO7OWlhACUXb2nbbnNIM4HCjfKllyc=; b=COz0XlYc8sF2qxNeQoyOG/XD7KvhooFBdpkJXI474/NeepCr8ap90YJCyn0wh6e/4u YQcfnsYfnTL6FvcJQ3frgSSg1UGlKBs9mtTnQs57AJdw1Ch0+2n1j6olc1dUPl71wDCw l4df6Ei1aQQJORUAT+XiHV0Ne4F6KvmLNjkcMRrAAqXywK4TVVuiX9EutE7ze5PMLtWH vG31NqsbmGSUAsj/38x8Yglcnpe6tVttW1gYVxfJWbM/zfc4cikCGnTZ44/L2qTY6ckP IIIHGiahhw6dmCwSk1q3BS60yLt3wa3v66s/r487XX2QP7OuVayNXpuW6piiAxu+QYpW GK2Q==
Received: by 10.14.213.7 with SMTP id z7mr9606396eeo.39.1353193498297; Sat, 17 Nov 2012 15:04:58 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id 46sm3801156eeg.4.2012.11.17.15.04.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Nov 2012 15:04:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Sun, 18 Nov 2012 01:04:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To:  
X-Mailer: Apple Mail (2.1085)
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Nov 2012 23:05:00 -0000

Hi,

I do not see a reason for this requirement. Give me an example how =
node/function virtualization would be visible e.g. at the IP mobility =
protocol level. Many vendors already today virtualize their elements =
(and call it cloud or something semantically equivalently foggy stuff) =
and that has not had any impact on the signaling protocols they use on =
the level of the infrastructure they virtualize.

- Jouni


On Nov 17, 2012, at 2:28 PM,  =
 wrote:

> Hi Behcet, Hi all,
> =20
> Regarding the cloud like architecture use case, the requirement that =
could be used for this purpose can be the following one:
> =20
> "The DMM solution MAY have the ability to be applied in virtualized =
and/or cloud like archietctures."
> =20
> Motivation:
> =20
> Currently, there is a trend to implement more and more functions of a =
mobile communication network in software, e.g., for signal and protocol =
processing. This enables the use of cloud computing infrastructures as =
processing platforms for signal and protocol processing of mobile =
communication networks, in particular for current (4G) and future (5G) =
generation cellular networks. This can only be realized if, among =
others, efficient DMM solutions are supported by the cloud computing =
architectures.
> =20
> Best regards,
> Georgios
> Van: Behcet Sarikaya [sarikaya2012@gmail.com]
> Verzonden: vrijdag 16 november 2012 22:20
> To: Karagiannis, G. (EWI)
> Cc: dmm@ietf.org
> Onderwerp: Requirements on cmm
>=20
> Hi Georgios,
>=20
> Can you please suggest some requirements on cmm in DMM?
>=20
> I think that it would be relevant and useful to DMM while requirements
> are still being discussed.
>=20
> Regards,
>=20
> Behcet
> On Sun, Nov 4, 2012 at 1:52 PM,   wrote:
> > Hi Behcet,
> >
> > I would like to mention that I find this draft useful due to the =
following reasons.
> >
> > Currently, there is a trend to implement more and more functions of =
a mobile communication network in software, e.g., for signal and =
protocol processing. This enables the use of cloud computing =
infrastructures as processing platforms for signal and protocol =
processing of mobile communication networks, in particular for current =
(4G) and future (5G) generation cellular networks.
> > This can of course only be realized if, among others, efficient =
mobility management solutions are supported like the ones that are in =
line with what DMM would like to specify.
> > I think therefore, that the DMM WG could also consider the =
distributed mobility management support in cloud computing like =
architectures as a possible use case.
> >
> > Regarding your draft I have some comments:
> > The draft mentions some limitation of the existing mobility =
management solutions in cloud-like architectures. However, these =
limitations are not clearly focussing on the requirements specified in =
http://www.ietf.org/id/draft-ietf-dmm-requirements-02.txt.
> > I think that this will make the desciption of the limitations =
clearer!
> > Moreover, it might also be useful to show describe these limitations =
by using as use as context a generic framework, like the one introduced =
in http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt =
and/or
> > http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> > ________________________________________
> > Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet =
Sarikaya [sarikaya2012@gmail.com]
> > Verzonden: dinsdag 23 oktober 2012 21:51
> > To: dmm@ietf.org
> > Onderwerp: [DMM] New Version Notification for   =
draft-sarikaya-dmm-cloud-mm-00.txt
> >
> > Hi all,
> >
> > I have submitted a new draft on Mobility Management Protocols for
> > Cloud-Like Architectures, for details see below.
> >
> > Chairs: please reserve a slot in IETF 85 session if possible.
> >
> > Regards,
> >
> > Behcet
> >
> > A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt
> > has been successfully submitted by Behcet Sarikaya and posted to the
> > IETF repository.
> >
> > Filename:        draft-sarikaya-dmm-cloud-mm
> > Revision:        00
> > Title:           Mobility Management Protocols for Cloud-Like =
Architectures
> > Creation date:   2012-10-15
> > WG ID:           Individual Submission
> > Number of pages: 11
> > URL:
> > =
http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt
> > Status:          =
http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud-mm
> > Htmlized:        =
http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-00
> >
> >
> > Abstract:
> >    Telecommunication networks are being virtualized and are moving =
into
> >    the cloud networks.  This brings the need to redesign the =
mobility
> >    protocols of Mobile and Proxy Mobile IPv6.  This document defines
> >    mobility management protocols for virtualized networks.  Control =
and
> >    data plane separation is achieved by separating Home Agent and =
Mobile
> >    Access Gateway functionalities into the control and data planes.
> >
> >
> >
> >
> > The IETF Secretariat
> > _______________________________________________
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From pierrick.seite@orange.com  Mon Nov 19 00:55:33 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315D621F84CF for ; Mon, 19 Nov 2012 00:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdsE97NUkbw2 for ; Mon, 19 Nov 2012 00:55:29 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0186421F8533 for ; Mon, 19 Nov 2012 00:55:28 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 679D63B42E7; Mon, 19 Nov 2012 09:55:27 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3EFB227C066; Mon, 19 Nov 2012 09:55:27 +0100 (CET)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 19 Nov 2012 09:55:26 +0100
From: 
To: "'karagian@cs.utwente.nl'" , "seiljeon@av.it.pt" , "JuanCarlos.Zuniga@InterDigital.com" 
Thread-Topic: [DMM] Multicast requirements
Thread-Index: AQHNxDUid4OMZkBJ4kOGBja1rhCxHZfs1L+AgAAT8YCAAPStgIAC/0fw
Date: Mon, 19 Nov 2012 08:55:26 +0000
Message-ID: <23120_1353315327_50A9F3FF_23120_281_1_81C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.6]
Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F7106F2F7PEXCVZYM12corpora_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 08:55:33 -0000

--_000_81C77F07008CA24F9783A98CFD706F7106F2F7PEXCVZYM12corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de karag=
ian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions but
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_81C77F07008CA24F9783A98CFD706F7106F2F7PEXCVZYM12corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi all,=



 <=
/p>

I tend to =
agree with Georgious, however I still do not figure out what is the use-cas=
e for distributed mobile multicast (other than academic considerations)?
 Can someone give concrete example? 


 =
;


I haven=
217;t real all messages from this thread. So, maybe I missed important poin=
ts.


 =
;


BR,


Pierrick


 =
;








De : dmm-=
bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should someho=
w consider muticast deployment. However, I do not thnk that the DMM WG is t=
he right WG to provide the multicast based DMM solution!<=
/p>

 


One alternative solution will be to have a multi=
cast requirement that emphasizes the need of having extensibility hooks (po=
ssibilities) that can be used later on by the multimob
 WG to provide a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like t=
he following could be used for this purpose:


 


"The DMM (unicast) solution MUST be sp=
ecified in such a way that it can be extended to also support multicast tra=
ffic."


 


 


Best regards,


Georgios


 


 


 












Van:
dmm-bounces@ietf.org
 [dmm-bounces@ietf.org] namens Seil Jeon [seiljeon@av.it.pt]

Verzonden: vrijdag 16 november 2012 22:25

To: 'Zuniga, Juan Carlos'

Cc: <=
span lang=3D"EN-US">dmm@ietf.org

Onderwerp: Re: [DMM] Multicast requirements








Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,

accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
 [mailto:dmm-bounces@ietf.org=
]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.co=
m]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org;
 Zuniga, Juan Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org

> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

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



_______________________________________________

dmm mailing list

dmm@ietf.org

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










______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_81C77F07008CA24F9783A98CFD706F7106F2F7PEXCVZYM12corpora_--

From seiljeon@av.it.pt  Mon Nov 19 03:14:35 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B7621F85E0 for ; Mon, 19 Nov 2012 03:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqsy1wJd0cpJ for ; Mon, 19 Nov 2012 03:14:34 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id A03FD21F85D2 for ; Mon, 19 Nov 2012 03:14:31 -0800 (PST)
Received: from [193.136.93.253] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67065597; Mon, 19 Nov 2012 11:14:29 +0000
From: "Seil Jeon" 
To: 
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>	<5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com>	<50A16AE0.70101@fhtw-berlin.de>	<5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com>	<50A172AC.5090308@fhtw-berlin.de>		<8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com>	<61CEE523-F244-486B-AA95-591828D53EED@gmail.com>		<8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>			<500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com>	<50A69B8C.6050309@venaas.com>	, <000601cdc440$ef947f50$cebd7df0$@av.it.pt>  <23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <23120_1353315327_50A9F3FF_23120_281_1_81C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Date: Mon, 19 Nov 2012 11:14:48 -0000
Message-ID: <008801cdc647$16916f20$43b44d60$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CDC647.169D5600"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDpvfVQJP8hzaX/j8eL/mEb+S6VGQFDovgtAWOj9LkCV0872QJCguPBArNqST4DOAIq+gKAnybWAiMZa28AsJ0RhAGsXNOSAWW2xzICO5diUAJYPa3lAgTlok4CGdKjrAILCPUtATL6kvCYrOVcAA==
Content-Language: ko
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 11:14:35 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0089_01CDC647.169D5600
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Pierrick,

=20

I=E2=80=99ve many times thought about your question. I would say how =
effectively should we deploy/support multicast over distributed mobility =
rather than distributed mobile multicast. As a result, you can find this =
deployment use case and gap analysis at =
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 =
presented in multimob several times.

=20

In unicast DMM, main innovation is to distribute the anchor function at =
many access routers from single core. Following architectural concept of =
DMM, flexible multicast distribution is one of multicast requirement =
resulted from the draft described above.=20

=20

REQ8: Flexible multicast distribution

"DMM solutions SHOULD be compatible with flexible multicast distribution =
scenarios. This flexibility enables different IP multicast flows with =
respect to a mobile host to be managed (e.g., subscribed, received =
and/or transmitted) using multiple endpoints".=20

Motivation: The motivation for this requirement is to enable flexibility =
in multicast distribution. The multicast solution may therefore avoid =
having multicast-capable access routers being restricted to manage all =
IP multicast traffic relative to a host via a single endpoint (e.g. =
regular or tunnel interface), which would lead to the problems described =
in PS1 and PS6.

PS6: Duplicate multicast traffic

IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].




Regards,

=20

Seil

=20

From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com]=20
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it.pt; =
JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

=20

Hi all,

=20

I tend to agree with Georgious, however I still do not figure out what =
is the use-case for distributed mobile multicast (other than academic =
considerations)? Can someone give concrete example?=20

=20

I haven=E2=80=99t real all messages from this thread. So, maybe I missed =
important points.

=20

BR,

Pierrick

=20

De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de =
karagian@cs.utwente.nl
Envoy=C3=A9 : samedi 17 novembre 2012 13:01
=C3=80 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements

=20

Hi all,

=20

I also agree that the DMM solution should somehow consider muticast =
deployment. However, I do not thnk that the DMM WG is the right WG to =
provide the multicast based DMM solution!

=20

One alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a=20

a multicast enabled DMM solution!

=20

=20

So a requirement that specifies something like the following could be =
used for this purpose:

=20

"The DMM (unicast) solution MUST be specified in such a way that it can =
be extended to also support multicast traffic."

=20

=20

Best regards,

Georgios

=20

=20

=20

  _____ =20

Van:   dmm-bounces@ietf.org =
[dmm-bounces@ietf.org] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc:   dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements

Hi Juan,

I've been looked at changed flow of your proposed text but sorry now =
that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's =
description,
it seems quite reasonable at the first step, not giving any restrictions =
but
leaving some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas;   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [  mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc:   sarikaya@ieee.org; Zuniga, Juan =
Carlos; Konstantinos Pentikousis;=20
> Peter McCann;   dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>=20
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are=20
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an=20
> explanation MUST be provided."
>=20
> This sounds good to me.
>=20
> The main thing I want to achieve is what was describes as motivation=20
> earlier in this thread. Multicast should at least be considered when=20
> looking into DMM solutions, and not just an afterthought once the=20
> solution is decided.
>=20
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed =
text.

Regards,

Juan Carlos
=20
>=20
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a=20
> hint to a developer where to head to. That is the level I would expect =

> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm

_________________________________________________________________________=
________________________________________________
=20
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
=20
This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.
Thank you.

------=_NextPart_000_0089_01CDC647.169D5600
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi =
Pierrick,
 
I=E2=80=99ve =
many times thought about your question. I would say how effectively =
should we deploy/support multicast over distributed mobility rather than =
distributed mobile multicast. As a result, you can find this deployment =
use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-=
03 presented in multimob several times.
 
In unicast =
DMM, main innovation is to distribute the anchor function at many access =
routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted =
from the draft described above. 
 
REQ8: Flexible multicast =
distribution
"DMM =
solutions SHOULD be compatible with flexible multicast distribution =
scenarios. This flexibility enables different IP multicast flows with =
respect to a mobile host to be managed (e.g., subscribed, received =
and/or transmitted) using multiple endpoints". 

Motivation: =
The motivation for this requirement is to enable flexibility in =
multicast distribution. The multicast solution may therefore avoid =
having multicast-capable access routers being restricted to manage all =
IP multicast traffic relative to a host via a single endpoint (e.g. =
regular or tunnel interface), which would lead to the problems described =
in PS1 and PS6.
PS6: =
Duplicate multicast traffic
IP =
multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].


Regards,=

 
Seil
 
From:=
 =
pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] =

Sent: Monday, November 19, 2012 8:55 AM
To: =
'karagian@cs.utwente.nl'; seiljeon@av.it.pt; =
JuanCarlos.Zuniga@InterDigital.com
Cc: =
dmm@ietf.org
Subject: RE: [DMM] Multicast =
requirements
 
Hi all,
 
I tend to agree with Georgious, however I still do not figure out =
what is the use-case for distributed mobile multicast (other than =
academic considerations)? Can someone give concrete example? =

 
I haven=E2=80=99t real all messages from this thread. So, maybe I =
missed important points.
 
BR,
Pierrick
 
De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] =
De la part de karagian@cs.utwente.nl
E=
nvoy=C3=A9 : samedi 17 novembre 2012 =
13:01
=C3=80 : seiljeon@av.it.pt; JuanCarlos.Zuniga@Inte=
rDigital.com
Cc : dmm@ietf.org
Objet : Re: =
[DMM] Multicast requirements
 
=
Hi all,
=
 
=
I also agree that the DMM solution should somehow consider muticast =
deployment. However, I do not thnk that the DMM WG is the right WG to =
provide the multicast based DMM solution!
=
 
=
One alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a =

=
a multicast enabled DMM solution!
=
 
=
 
=
So a requirement that specifies something like the following could be =
used for this purpose:
=
 
=
"The DMM (unicast) solution MUST be specified in such a way =
that it can be extended to also support multicast =
traffic."
=
 
=
 
=
Best regards,
=
Georgios
=
 
=
 
=
 
=

=
Van:=
 =
dmm-bounces@ietf.org=
 [dmm-bounces@ietf.org] namens Seil Jeon =
[seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 =
22:25
To: 'Zuniga, Juan Carlos'
Cc: =
dmm@ietf.org=

Onderwerp: Re: [DMM] Multicast =
requirements
=
Hi Juan,

I've been looked at changed flow of your proposed text =
but sorry now that my
comment is posted.
At first time, I couldn't =
make sure however, on hearing Stig's description,
it seems quite =
reasonable at the first step, not giving any restrictions but
leaving =
some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the =
DMM solution to
support multicast.
So I think additional =
requirements need to be made for the DMM solution,
accordingly. But =
of course, this should not also give any specific
limitation and =
restriction but should be made towards the direction not
limiting the =
benefits provided by distributed deployment.

I hope to get more =
comments on this.

=
Regards,

Seil


-----Original Message-----
From: =
=
dmm-bounces@ietf.org=
 [=
mailto:dmm-bounces@ietf.org=
] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 =
8:14 PM
To: Stig Venaas; =
dmm@ietf.org=

Subject: Re: [DMM] Multicast requirements


> =
-----Original Message-----
> From: Stig Venaas [=
mailto:stig@venaas.com=
]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni =
korhonen
> Cc: =
sarikaya@ieee.org=
; Zuniga, Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann; =
=
dmm@ietf.org=

> Subject: Re: [DMM] Multicast requirements
> 
> On =
11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On =
Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> =
>>
> >> I think we are reading too much into multicast =
and unicast should
be
> >> designed in an integrated =
manner.
=
> >>
> >> The fact is that multicast is considered =
as an area of
> specialization,
> >> it requires =
knowledge of very different protocols than we are 
> >> =
accustomed to in mobility.
> >
> > "Requirement: =
DMM solutions SHOULD support multicast services. If a
> specific =
DMM solution does not support multicast services, an 
> =
explanation MUST be provided."
> 
> This sounds good to =
me.
> 
> The main thing I want to achieve is what was =
describes as motivation 
> earlier in this thread. Multicast =
should at least be considered when 
> looking into DMM solutions, =
and not just an afterthought once the 
> solution is =
decided.
> 
> Stig

[JCZ] I fully agree with this. =
That was the intention of the proposed text.

Regards,

Juan =
Carlos
 
> 
> > To me that reads basically =
"do not break foundations for multicast
> unless you have a =
valid & documented reason for it".  If we look =
e.g.
> into RFC625 multicast wording that is there very briefly =
but gives a 
> hint to a developer where to head to. That is the =
level I would expect 
> DMM documents should aim to.
> =
>
> > - Jouni
> >
> >
> >> Let =
dmm deal with its current charter that does not include a word
> =
of
> >> multicast and if everything goes well we can come =
back and discuss
> dmm
> >> multicast.
=
> >>
> >> Regards,
> >>
> =
>> =
Behcet

_______________________________________________
dmm =
mailing list
=
dmm@ietf.org=

=
https://www.ietf.org/mailman/listinfo/dmm<=
span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>=


_______________________________________________
dmm mailing =
list
=
dmm@ietf.org=

=
https://www.ietf.org/mailman/listinfo/dmm<=
span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>=

_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
France Telecom =
- Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, France Telecom - Orange is not =
liable for messages that have been modified, changed or =
falsified.
Thank =
you.

------=_NextPart_000_0089_01CDC647.169D5600--


From sarikaya2012@gmail.com  Mon Nov 19 09:25:18 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F76421F8570 for ; Mon, 19 Nov 2012 09:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.585
X-Spam-Level: 
X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOjtxGJhdKqP for ; Mon, 19 Nov 2012 09:25:17 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA321F858B for ; Mon, 19 Nov 2012 09:25:17 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so7886380iec.31 for ; Mon, 19 Nov 2012 09:25:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5DvGJyGWO5d/z19hV9JbYgxKxf9t2MopHWyjOsetCAw=; b=IwZqOliiMkDoIelYEOH0oxVRgFZAwujwLfcRteK2HCsoAG46/CiA97eegavsFnG/xn TezuuJI8rxUQD232+/xpi2nn2mAi5KL0sV8McAyzpaGwMGYPnQ1uFl5JoPze1WNMgvPr OJuUCQNIO3xF1nfwIfY3fto8DhAW4xOM9WcW8hjXPaAwa1vl5lzzJj8BLXMJqvT0u334 nbwO8LNKlgI/WXo4tZLAHSNK78Om+Xzr8QciY3KLnICvg9zXBhabiKUAtxHECIN6Snrj AyUMf/XtNw9Fid4rQwvzVMOziu3s3PwPy5RYBfJjBHpfLlrDCeCUTfGEejaO3sgEmOoW Cfzg==
MIME-Version: 1.0
Received: by 10.42.63.4 with SMTP id a4mr11453366ici.40.1353345917252; Mon, 19 Nov 2012 09:25:17 -0800 (PST)
Received: by 10.231.85.26 with HTTP; Mon, 19 Nov 2012 09:25:17 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 19 Nov 2012 11:25:17 -0600
Message-ID: 
From: Behcet Sarikaya 
To: karagian@cs.utwente.nl
Content-Type: text/plain; charset=ISO-8859-1
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 17:25:18 -0000

Hi all,

Here is the requirement I have in mind:

The DMM solution SHOULD support more than one cloud network belonging
to the same DMM domain.

Two points:

The above requirement does have protocol impact.

Second point: I also support Georgios' requirement as a base. We can
work on both and make it better.

Regards,

Behcet

On Sat, Nov 17, 2012 at 6:28 AM,   wrote:
> Hi Behcet, Hi all,
>
>
>
> Regarding the cloud like architecture use case, the requirement that could
> be used for this purpose can be the following one:
>
>
>
> "The DMM solution MAY have the ability to be applied in virtualized and/or
> cloud like archietctures."
>
>
>
> Motivation:
>
>
>
> Currently, there is a trend to implement more and more functions of a mobile
> communication network in software, e.g., for signal and protocol processing.
> This enables the use of cloud computing infrastructures as processing
> platforms for signal and protocol processing of mobile communication
> networks, in particular for current (4G) and future (5G) generation cellular
> networks. This can only be realized if, among others, efficient DMM
> solutions are supported by the cloud computing architectures.
>
>
>
> Best regards,
>
> Georgios
>
> ________________________________
> Van: Behcet Sarikaya [sarikaya2012@gmail.com]
> Verzonden: vrijdag 16 november 2012 22:20
> To: Karagiannis, G. (EWI)
> Cc: dmm@ietf.org
> Onderwerp: Requirements on cmm
>
> Hi Georgios,
>
> Can you please suggest some requirements on cmm in DMM?
>
> I think that it would be relevant and useful to DMM while requirements
> are still being discussed.
>
> Regards,
>
> Behcet
> On Sun, Nov 4, 2012 at 1:52 PM,   wrote:
>> Hi Behcet,
>>
>> I would like to mention that I find this draft useful due to the following
>> reasons.
>>
>> Currently, there is a trend to implement more and more functions of a
>> mobile communication network in software, e.g., for signal and protocol
>> processing. This enables the use of cloud computing infrastructures as
>> processing platforms for signal and protocol processing of mobile
>> communication networks, in particular for current (4G) and future (5G)
>> generation cellular networks.
>> This can of course only be realized if, among others, efficient mobility
>> management solutions are supported like the ones that are in line with what
>> DMM would like to specify.
>> I think therefore, that the DMM WG could also consider the distributed
>> mobility management support in cloud computing like architectures as a
>> possible use case.
>>
>> Regarding your draft I have some comments:
>> The draft mentions some limitation of the existing mobility management
>> solutions in cloud-like architectures. However, these limitations are not
>> clearly focussing on the requirements specified in
>> http://www.ietf.org/id/draft-ietf-dmm-requirements-02.txt.
>> I think that this will make the desciption of the limitations clearer!
>> Moreover, it might also be useful to show describe these limitations by
>> using as use as context a generic framework, like the one introduced in
>> http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and/or
>> http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.
>>
>> Best regards,
>> Georgios
>>
>>
>>
>>
>> ________________________________________
>> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikaya
>> [sarikaya2012@gmail.com]
>> Verzonden: dinsdag 23 oktober 2012 21:51
>> To: dmm@ietf.org
>> Onderwerp: [DMM] New Version Notification for
>> draft-sarikaya-dmm-cloud-mm-00.txt
>>
>> Hi all,
>>
>> I have submitted a new draft on Mobility Management Protocols for
>> Cloud-Like Architectures, for details see below.
>>
>> Chairs: please reserve a slot in IETF 85 session if possible.
>>
>> Regards,
>>
>> Behcet
>>
>> A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt
>> has been successfully submitted by Behcet Sarikaya and posted to the
>> IETF repository.
>>
>> Filename:        draft-sarikaya-dmm-cloud-mm
>> Revision:        00
>> Title:           Mobility Management Protocols for Cloud-Like
>> Architectures
>> Creation date:   2012-10-15
>> WG ID:           Individual Submission
>> Number of pages: 11
>> URL:
>> http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud-mm
>> Htmlized:        http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-00
>>
>>
>> Abstract:
>>    Telecommunication networks are being virtualized and are moving into
>>    the cloud networks.  This brings the need to redesign the mobility
>>    protocols of Mobile and Proxy Mobile IPv6.  This document defines
>>    mobility management protocols for virtualized networks.  Control and
>>    data plane separation is achieved by separating Home Agent and Mobile
>>    Access Gateway functionalities into the control and data planes.
>>
>>
>>
>>
>> The IETF Secretariat
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm

From brian@innovationslab.net  Mon Nov 19 11:53:23 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6AC21F85E6 for ; Mon, 19 Nov 2012 11:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNWDUhfjtcz2 for ; Mon, 19 Nov 2012 11:53:23 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2063821F8564 for ; Mon, 19 Nov 2012 11:53:23 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BD18C88099 for ; Mon, 19 Nov 2012 11:53:22 -0800 (PST)
Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7917F13001B for ; Mon, 19 Nov 2012 11:53:22 -0800 (PST)
Message-ID: <50AA8E30.1050408@innovationslab.net>
Date: Mon, 19 Nov 2012 14:53:20 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: dmm@ietf.org
References:   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 19:53:23 -0000

Behcet,

On 11/19/12 12:25 PM, Behcet Sarikaya wrote:
> Hi all,
>
> Here is the requirement I have in mind:
>
> The DMM solution SHOULD support more than one cloud network belonging
> to the same DMM domain.
>
> Two points:
>
> The above requirement does have protocol impact.

Could you elaborate on what that impact would be?

It is unclear to me what the impact of using a cloud service would be. 
The IETF has not had to change other protocols in order to have them 
work within "the cloud".

Regards,
Brian

>
> Second point: I also support Georgios' requirement as a base. We can
> work on both and make it better.
>
> Regards,
>
> Behcet
>
> On Sat, Nov 17, 2012 at 6:28 AM,   wrote:
>> Hi Behcet, Hi all,
>>
>>
>>
>> Regarding the cloud like architecture use case, the requirement that could
>> be used for this purpose can be the following one:
>>
>>
>>
>> "The DMM solution MAY have the ability to be applied in virtualized and/or
>> cloud like archietctures."
>>
>>
>>
>> Motivation:
>>
>>
>>
>> Currently, there is a trend to implement more and more functions of a mobile
>> communication network in software, e.g., for signal and protocol processing.
>> This enables the use of cloud computing infrastructures as processing
>> platforms for signal and protocol processing of mobile communication
>> networks, in particular for current (4G) and future (5G) generation cellular
>> networks. This can only be realized if, among others, efficient DMM
>> solutions are supported by the cloud computing architectures.
>>
>>
>>
>> Best regards,
>>
>> Georgios
>>
>> ________________________________
>> Van: Behcet Sarikaya [sarikaya2012@gmail.com]
>> Verzonden: vrijdag 16 november 2012 22:20
>> To: Karagiannis, G. (EWI)
>> Cc: dmm@ietf.org
>> Onderwerp: Requirements on cmm
>>
>> Hi Georgios,
>>
>> Can you please suggest some requirements on cmm in DMM?
>>
>> I think that it would be relevant and useful to DMM while requirements
>> are still being discussed.
>>
>> Regards,
>>
>> Behcet
>> On Sun, Nov 4, 2012 at 1:52 PM,   wrote:
>>> Hi Behcet,
>>>
>>> I would like to mention that I find this draft useful due to the following
>>> reasons.
>>>
>>> Currently, there is a trend to implement more and more functions of a
>>> mobile communication network in software, e.g., for signal and protocol
>>> processing. This enables the use of cloud computing infrastructures as
>>> processing platforms for signal and protocol processing of mobile
>>> communication networks, in particular for current (4G) and future (5G)
>>> generation cellular networks.
>>> This can of course only be realized if, among others, efficient mobility
>>> management solutions are supported like the ones that are in line with what
>>> DMM would like to specify.
>>> I think therefore, that the DMM WG could also consider the distributed
>>> mobility management support in cloud computing like architectures as a
>>> possible use case.
>>>
>>> Regarding your draft I have some comments:
>>> The draft mentions some limitation of the existing mobility management
>>> solutions in cloud-like architectures. However, these limitations are not
>>> clearly focussing on the requirements specified in
>>> http://www.ietf.org/id/draft-ietf-dmm-requirements-02.txt.
>>> I think that this will make the desciption of the limitations clearer!
>>> Moreover, it might also be useful to show describe these limitations by
>>> using as use as context a generic framework, like the one introduced in
>>> http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and/or
>>> http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.
>>>
>>> Best regards,
>>> Georgios
>>>
>>>
>>>
>>>
>>> ________________________________________
>>> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikaya
>>> [sarikaya2012@gmail.com]
>>> Verzonden: dinsdag 23 oktober 2012 21:51
>>> To: dmm@ietf.org
>>> Onderwerp: [DMM] New Version Notification for
>>> draft-sarikaya-dmm-cloud-mm-00.txt
>>>
>>> Hi all,
>>>
>>> I have submitted a new draft on Mobility Management Protocols for
>>> Cloud-Like Architectures, for details see below.
>>>
>>> Chairs: please reserve a slot in IETF 85 session if possible.
>>>
>>> Regards,
>>>
>>> Behcet
>>>
>>> A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt
>>> has been successfully submitted by Behcet Sarikaya and posted to the
>>> IETF repository.
>>>
>>> Filename:        draft-sarikaya-dmm-cloud-mm
>>> Revision:        00
>>> Title:           Mobility Management Protocols for Cloud-Like
>>> Architectures
>>> Creation date:   2012-10-15
>>> WG ID:           Individual Submission
>>> Number of pages: 11
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud-mm
>>> Htmlized:        http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-00
>>>
>>>
>>> Abstract:
>>>     Telecommunication networks are being virtualized and are moving into
>>>     the cloud networks.  This brings the need to redesign the mobility
>>>     protocols of Mobile and Proxy Mobile IPv6.  This document defines
>>>     mobility management protocols for virtualized networks.  Control and
>>>     data plane separation is achieved by separating Home Agent and Mobile
>>>     Access Gateway functionalities into the control and data planes.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


From sarikaya2012@gmail.com  Mon Nov 19 12:41:50 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823221F85C7 for ; Mon, 19 Nov 2012 12:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.586
X-Spam-Level: 
X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1Ot6Ui8Sye0 for ; Mon, 19 Nov 2012 12:41:50 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 446BD21F84ED for ; Mon, 19 Nov 2012 12:41:50 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id c13so6173ieb.31 for ; Mon, 19 Nov 2012 12:41:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IMLYGgtcxBzZHLddRIbpRec4X0uvVKrjBDTKmtmy3Wc=; b=S354XBPpmxVOz01A01GspU8XED0TEdfi6k5dIC++lToHi0K5oCR7eLLZMfSBgA9dRe zJ+4Z6laVwg7HbVN0XieLAkns41XE3BFCZTb8VlJRgeUKn0MqQABg/1Oj0pzi60fnpGw jOWCTgSfwPRyNI6XpHt9TRbjhkFjJTPW3yfAAlATiHe4yCO2MWK1LEuR+I+E9PFYcAtp ZGUo3UP0vbUuJ4vU+E9yth9UZL5xWzdu5xsER6YolbfimwWQC/rvlolRMKHk0X/z+ps8 /SmbRaJOJjzwFTw85pNjWnLOCP1ecewe7hEZgxJmV0Xa2MIBpAjPDMk8p5tItunHJz/0 7dFA==
MIME-Version: 1.0
Received: by 10.50.152.240 with SMTP id vb16mr7985688igb.45.1353357709939; Mon, 19 Nov 2012 12:41:49 -0800 (PST)
Received: by 10.231.85.26 with HTTP; Mon, 19 Nov 2012 12:41:49 -0800 (PST)
In-Reply-To: <50AA8E30.1050408@innovationslab.net>
References:    <50AA8E30.1050408@innovationslab.net>
Date: Mon, 19 Nov 2012 14:41:49 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Brian Haberman 
Content-Type: text/plain; charset=ISO-8859-1
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 20:41:50 -0000

Hi Brian,

On Mon, Nov 19, 2012 at 1:53 PM, Brian Haberman
 wrote:
> Behcet,
>
>
> On 11/19/12 12:25 PM, Behcet Sarikaya wrote:
>>
>> Hi all,
>>
>> Here is the requirement I have in mind:
>>
>> The DMM solution SHOULD support more than one cloud network belonging
>> to the same DMM domain.
>>
>> Two points:
>>
>> The above requirement does have protocol impact.
>
>
> Could you elaborate on what that impact would be?
>
> It is unclear to me what the impact of using a cloud service would be. The
> IETF has not had to change other protocols in order to have them work within
> "the cloud".

I think it is early to say.

Cloud networks have been all Layer 2 based and because of that many
mobility issues do not surface. For example virtual machine mobility
is just change of Ethernet address and no IP layer changes are needed.

However, I think that the trend is towards Layer 3 based clouds and
also inter-cloud communication needs are increasing. For example there
are many people advocating the development of an IETF virtual machine
mobility protocol.

I think we need to look at DMM from this perspective,and see if we can
make our mobility protocols more suitable to the cloud.

That is the reason why I wrote
draft-sarikaya-dmm-cloud-mm.
With even the simplistic assumptions, my drafts shows that the cloud
does have some protocol implications on our protocols.

Regards,

Behcet

From h.anthony.chan@huawei.com  Mon Nov 19 14:28:24 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4ED21F8597 for ; Mon, 19 Nov 2012 14:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level: 
X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.700,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5rEywKbaoUf for ; Mon, 19 Nov 2012 14:28:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA86C21F8570 for ; Mon, 19 Nov 2012 14:28:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMY39813; Mon, 19 Nov 2012 22:28:18 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 22:27:50 +0000
Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 22:28:14 +0000
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.221]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 06:28:11 +0800
From: h chan 
To: Seil Jeon , "pierrick.seite@orange.com" 
Thread-Topic: [DMM] Multicast requirements
Thread-Index: AQHNxDUid4OMZkBJ4kOGBja1rhCxHZfs1L+AgAAT8YCAAPStgIAC/0fw//+jAQCAATCAsA==
Date: Mon, 19 Nov 2012 22:28:10 +0000
Message-ID: <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huawei.com>
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E565D5@dfweml512-mbx.china.huawei.com> <50A16AE0.70101@fhtw-berlin.de> <5963DDF1F751474D8DEEFDCDBEE43AE716E56698@dfweml512-mbx.china.huawei.com> <50A172AC.5090308@fhtw-berlin.de>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt>  <23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt>
In-Reply-To: <008801cdc647$16916f20$43b44d60$@av.it.pt>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.141.172]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C36494729SZXEML510MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 22:28:24 -0000

--_000_6E31144C030982429702B11D6746B98C36494729SZXEML510MBSchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlcmUgYXJlIDMgcHJvcG9zYWxzIGZvciBtdWx0aWNhc3QgcmVxdWlyZW1lbnRzLiBCZWZvcmUg
Y29tcGFyaW5nIHRoZXNlIHByb3Bvc2FscywgbGV0IHVzIHVuZGVyc3RhbmQgd2hhdCBhcmUgdGhl
IHByb2JsZW1zIGZpcnN0LiBUd28gcHJvYmxlbSBzdGF0ZW1lbnRzIGhhdmUgYmVlbiBwcm9wb3Nl
ZDoNCg0KUFMxIChyZXZpc2VkKTogTm9uLW9wdGltYWwgcm91dGVzDQoNClJvdXRpbmcgdmlhIGEg
Y2VudHJhbGl6ZWQgYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBsb25nZXIgcm91dGUuIFRoZSBw
cm9ibGVtIGlzIGVzcGVjaWFsbHkgbWFuaWZlc3RlZCB3aGVuIGFjY2Vzc2luZyBhIGxvY2FsIHNl
cnZlciBvciBzZXJ2ZXJzIG9mIGEgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrIChDRE4pLCBvciB3
aGVuIHJlY2VpdmluZyAvIHNlbmRpbmcgSVAgbXVsdGljYXN0IHBhY2tldHMuDQpQUzY6IER1cGxp
Y2F0ZSBtdWx0aWNhc3QgdHJhZmZpYw0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFy
Y2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zICBtYXkgbGVhZCB0byBjb252
ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25zIHRvd2FyZHMgdGhl
IHR1bm5lbOKAmXMgZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2NikuICBDb25j
cmV0ZWx5LCB3aGVuIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGluZGl2aWR1YWwgbW9iaWxl
IG5vZGVzIGlzIGNvdXBsZWQgd2l0aCBtb2JpbGl0eSB0dW5uZWxzLCBkdXBsaWNhdGUgbXVsdGlj
YXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSByZWNlaXZlZCB0aHJvdWdoIGRpZmZl
cmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IG1vcmUgc2V2
ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgZW52aXJvbm1lbnQgW2RyYWZ0LXNmaWd1ZWly
ZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wM10uDQoNClRoZW4sIGxldCB1cyBzZWUgd2hldGhl
ciBhbGwgdGhlIDMgUkVRIHByb3Bvc2FscyBoYXZlIHRoZSBzYW1lIGludGVudGlvbi4gSW4gdGhl
IGZvbGxvd2luZywgSSByZXBocmFzZSB0aGVtIHRvIGhpZ2hsaWdodCB0aGVpciBzaW1pbGFyaXRp
ZXMuDQoNClJFUTcuMTogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbg0KRE1NIHNvbHV0
aW9ucyBzaG91bGQgYmUgY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmli
dXRpb24gc2NlbmFyaW8uIEV0Yy4NClRoZSBNb3RpdmF0aW9uIGlzIHRvIGFsbG93IGZsZXhpYmls
aXR5IGluIChlbmFibGUpIG11bHRpY2FzdCBzb2x1dGlvbnMgdG8gc29sdmUgdGhlIHByb2JsZW1z
IFBTMSBhbmQgUFM2IGFzIGV4cGxhaW5lZCBpbiB1c2UgY2FzZXMgYWxyZWFkeSBwcmVzZW50ZWQg
YW5kIGRpc2N1c3NlZCBpbiBtdWx0aW1vYiB3Zy4NCg0KUkVRNy4yOg0KRE1NIHNvbHV0aW9ucyBz
aG91bGQgZW5hYmxlIHNvbHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLg0KDQoo
T3JpZ2luYWwgd29yZGluZyB3YXMgIlRoZSBETU0gKHVuaWNhc3QpIHNvbHV0aW9uIE1VU1QgYmUg
c3BlY2lmaWVkIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWxzbyBz
dXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiIgSSByZXBocmFzZSBpdCB0byBoaWdobGlnaHQgdGhl
IHNpbWlsYXJpdHkgd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxzIGFuZCBhbHNvIGNoYW5nZWQgdGhl
IG11c3QgdG8gc2hvdWxkLikNCg0KUkVRNy4zOg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxl
IHNvbHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcy4NCg0KT3JpZ2luYWwgd29y
ZGluZyB3YXMg4oCcRE1NIHNvbHV0aW9ucyBzaG91bGQgc3VwcG9ydCBtdWx0aWNhc3Qgc2Vydmlj
ZXMg4oCmIGV0Yy4gR2l2ZW4gdGhhdCBpdCBpcyB0aGUgc2NvcGUgb2YgbXVsdGltb2IgYW5kIG5v
dCBkbW0gd2cgdG8gcHJvdmlkZSB0aGUgbXVsdGljYXN0IHNvbHV0aW9uLCBJIHRoaW5rIOKAnHN1
cHBvcnTigJ0gaGVyZSBtZWFucyDigJxlbmFibGXigJ0gc29sdXRpb25zIHRvIGJlIGRldmVsb3Bl
ZCAoYnkgbXVsdGltb2IpLg0KDQpTaW1pbGFyaXR5IGFuZCBzdWJ0bGUgZGlmZmVyZW5jZXM6IEJv
dGggUkVRNy4yIGFuZCBSRVE3LjMgd2FudCB0byBlbmFibGUgbXVsdGljYXN0IHNlcnZpY2VzLiBZ
ZXQgdGhlIGV4cGxhbmF0aW9uIGluIFJFUTcuMSBzZWVtcyB0byBpbmRpY2F0ZSBub3QganVzdCB0
byBlbmFibGUgYW55IG9uZSBtdWx0aWNhc3Qgc29sdXRpb24gYnV0IGFsc28gbmVlZHMgdGhlIGZs
ZXhpYmlsaXR5IGluIG11bHRpY2FzdCBzb2x1dGlvbi4gTm90IGFsbCBtdWx0aWNhc3Qgc29sdXRp
b25zIGFyZSB0aGUgc2FtZS4gU29tZSBvZiB0aGVtIHJlc3VsdHMgaW4gUFMxIG9yIFBTNi4NCg0K
QXJlIHRoZXJlIGFueSBhcmUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdlZW46DQpJbiBSRVE3
LjEsIERNTSBzb2x1dGlvbnMgc2hvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBmbGV4aWJsZSBtdWx0
aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvLCBldGMuDQpWZXJzdXMNCkRNTSBzb2x1dGlvbnMg
c2hvdWxkIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJlIGNvbXBhdGlibGUgd2l0
aCBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvLCBldGMuDQoNCkggQW50aG9ueSBDaGFu
DQoNCkZyb206IGRtbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBTZWlsIEplb24NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTksIDIw
MTIgNToxNSBBTQ0KVG86IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20NCkNjOiBkbW1AaWV0Zi5v
cmcNClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzDQoNCkhpIFBpZXJy
aWNrLA0KDQpJ4oCZdmUgbWFueSB0aW1lcyB0aG91Z2h0IGFib3V0IHlvdXIgcXVlc3Rpb24uIEkg
d291bGQgc2F5IGhvdyBlZmZlY3RpdmVseSBzaG91bGQgd2UgZGVwbG95L3N1cHBvcnQgbXVsdGlj
YXN0IG92ZXIgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgcmF0aGVyIHRoYW4gZGlzdHJpYnV0ZWQgbW9i
aWxlIG11bHRpY2FzdC4gQXMgYSByZXN1bHQsIHlvdSBjYW4gZmluZCB0aGlzIGRlcGxveW1lbnQg
dXNlIGNhc2UgYW5kIGdhcCBhbmFseXNpcyBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDMgcHJlc2VudGVkIGluIG11
bHRpbW9iIHNldmVyYWwgdGltZXMuDQoNCkluIHVuaWNhc3QgRE1NLCBtYWluIGlubm92YXRpb24g
aXMgdG8gZGlzdHJpYnV0ZSB0aGUgYW5jaG9yIGZ1bmN0aW9uIGF0IG1hbnkgYWNjZXNzIHJvdXRl
cnMgZnJvbSBzaW5nbGUgY29yZS4gRm9sbG93aW5nIGFyY2hpdGVjdHVyYWwgY29uY2VwdCBvZiBE
TU0sIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gaXMgb25lIG9mIG11bHRpY2FzdCBy
ZXF1aXJlbWVudCByZXN1bHRlZCBmcm9tIHRoZSBkcmFmdCBkZXNjcmliZWQgYWJvdmUuDQoNCg0K
UkVRODogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbg0KIkRNTSBzb2x1dGlvbnMgU0hP
VUxEIGJlIGNvbXBhdGlibGUgd2l0aCBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNj
ZW5hcmlvcy4gVGhpcyBmbGV4aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUCBtdWx0aWNhc3Qg
Zmxvd3Mgd2l0aCByZXNwZWN0IHRvIGEgbW9iaWxlIGhvc3QgdG8gYmUgbWFuYWdlZCAoZS5nLiwg
c3Vic2NyaWJlZCwgcmVjZWl2ZWQgYW5kL29yIHRyYW5zbWl0dGVkKSB1c2luZyBtdWx0aXBsZSBl
bmRwb2ludHMiLg0KDQpNb3RpdmF0aW9uOiBUaGUgbW90aXZhdGlvbiBmb3IgdGhpcyByZXF1aXJl
bWVudCBpcyB0byBlbmFibGUgZmxleGliaWxpdHkgaW4gbXVsdGljYXN0IGRpc3RyaWJ1dGlvbi4g
VGhlIG11bHRpY2FzdCBzb2x1dGlvbiBtYXkgdGhlcmVmb3JlIGF2b2lkIGhhdmluZyBtdWx0aWNh
c3QtY2FwYWJsZSBhY2Nlc3Mgcm91dGVycyBiZWluZyByZXN0cmljdGVkIHRvIG1hbmFnZSBhbGwg
SVAgbXVsdGljYXN0IHRyYWZmaWMgcmVsYXRpdmUgdG8gYSBob3N0IHZpYSBhIHNpbmdsZSBlbmRw
b2ludCAoZS5nLiByZWd1bGFyIG9yIHR1bm5lbCBpbnRlcmZhY2UpLCB3aGljaCB3b3VsZCBsZWFk
IHRvIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQgaW4gUFMxIGFuZCBQUzYuDQpQUzY6IER1cGxpY2F0
ZSBtdWx0aWNhc3QgdHJhZmZpYw0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hp
dGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zICBtYXkgbGVhZCB0byBjb252ZXJn
ZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25zIHRvd2FyZHMgdGhlIHR1
bm5lbOKAmXMgZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2NikuICBDb25jcmV0
ZWx5LCB3aGVuIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGluZGl2aWR1YWwgbW9iaWxlIG5v
ZGVzIGlzIGNvdXBsZWQgd2l0aCBtb2JpbGl0eSB0dW5uZWxzLCBkdXBsaWNhdGUgbXVsdGljYXN0
IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSByZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVu
dCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IG1vcmUgc2V2ZXJl
IGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgZW52aXJvbm1lbnQgW2RyYWZ0LXNmaWd1ZWlyZWRv
LW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wM10uDQoNClJlZ2FyZHMsDQoNClNlaWwNCg0KRnJvbTog
cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbSBbbWFpbHRvOnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5j
b21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE5LCAyMDEyIDg6NTUgQU0NClRvOiAna2FyYWdp
YW5AY3MudXR3ZW50ZS5ubCc7IHNlaWxqZW9uQGF2Lml0LnB0OyBKdWFuQ2FybG9zLlp1bmlnYUBJ
bnRlckRpZ2l0YWwuY29tDQpDYzogZG1tQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RNTV0gTXVs
dGljYXN0IHJlcXVpcmVtZW50cw0KDQpIaSBhbGwsDQoNCkkgdGVuZCB0byBhZ3JlZSB3aXRoIEdl
b3JnaW91cywgaG93ZXZlciBJIHN0aWxsIGRvIG5vdCBmaWd1cmUgb3V0IHdoYXQgaXMgdGhlIHVz
ZS1jYXNlIGZvciBkaXN0cmlidXRlZCBtb2JpbGUgbXVsdGljYXN0IChvdGhlciB0aGFuIGFjYWRl
bWljIGNvbnNpZGVyYXRpb25zKT8gQ2FuIHNvbWVvbmUgZ2l2ZSBjb25jcmV0ZSBleGFtcGxlPw0K
DQpJIGhhdmVu4oCZdCByZWFsIGFsbCBtZXNzYWdlcyBmcm9tIHRoaXMgdGhyZWFkLiBTbywgbWF5
YmUgSSBtaXNzZWQgaW1wb3J0YW50IHBvaW50cy4NCg0KQlIsDQpQaWVycmljaw0KDQpEZSA6IGRt
bS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpk
bW0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBrYXJhZ2lhbkBjcy51dHdlbnRlLm5s
PG1haWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sPg0KRW52b3nDqSA6IHNhbWVkaSAxNyBub3Zl
bWJyZSAyMDEyIDEzOjAxDQrDgCA6IHNlaWxqZW9uQGF2Lml0LnB0PG1haWx0bzpzZWlsamVvbkBh
di5pdC5wdD47IEp1YW5DYXJsb3MuWnVuaWdhQEludGVyRGlnaXRhbC5jb208bWFpbHRvOkp1YW5D
YXJsb3MuWnVuaWdhQEludGVyRGlnaXRhbC5jb20+DQpDYyA6IGRtbUBpZXRmLm9yZzxtYWlsdG86
ZG1tQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50cw0K
DQoNCkhpIGFsbCwNCg0KDQoNCkkgYWxzbyBhZ3JlZSB0aGF0IHRoZSBETU0gc29sdXRpb24gc2hv
dWxkIHNvbWVob3cgY29uc2lkZXIgbXV0aWNhc3QgZGVwbG95bWVudC4gSG93ZXZlciwgSSBkbyBu
b3QgdGhuayB0aGF0IHRoZSBETU0gV0cgaXMgdGhlIHJpZ2h0IFdHIHRvIHByb3ZpZGUgdGhlIG11
bHRpY2FzdCBiYXNlZCBETU0gc29sdXRpb24hDQoNCg0KDQpPbmUgYWx0ZXJuYXRpdmUgc29sdXRp
b24gd2lsbCBiZSB0byBoYXZlIGEgbXVsdGljYXN0IHJlcXVpcmVtZW50IHRoYXQgZW1waGFzaXpl
cyB0aGUgbmVlZCBvZiBoYXZpbmcgZXh0ZW5zaWJpbGl0eSBob29rcyAocG9zc2liaWxpdGllcykg
dGhhdCBjYW4gYmUgdXNlZCBsYXRlciBvbiBieSB0aGUgbXVsdGltb2IgV0cgdG8gcHJvdmlkZSBh
DQoNCmEgbXVsdGljYXN0IGVuYWJsZWQgRE1NIHNvbHV0aW9uIQ0KDQoNCg0KDQoNClNvIGEgcmVx
dWlyZW1lbnQgdGhhdCBzcGVjaWZpZXMgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyBjb3Vs
ZCBiZSB1c2VkIGZvciB0aGlzIHB1cnBvc2U6DQoNCg0KDQoiVGhlIERNTSAodW5pY2FzdCkgc29s
dXRpb24gTVVTVCBiZSBzcGVjaWZpZWQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSBleHRl
bmRlZCB0byBhbHNvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuIg0KDQoNCg0KDQoNCkJlc3Qg
cmVnYXJkcywNCg0KR2Vvcmdpb3MNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NClZhbjogZG1tLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRtbS1ib3VuY2Vz
QGlldGYub3JnPiBbZG1tLWJvdW5jZXNAaWV0Zi5vcmddIG5hbWVucyBTZWlsIEplb24gW3NlaWxq
ZW9uQGF2Lml0LnB0XQ0KVmVyem9uZGVuOiB2cmlqZGFnIDE2IG5vdmVtYmVyIDIwMTIgMjI6MjUN
ClRvOiAnWnVuaWdhLCBKdWFuIENhcmxvcycNCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBp
ZXRmLm9yZz4NCk9uZGVyd2VycDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMNCkhp
IEp1YW4sDQoNCkkndmUgYmVlbiBsb29rZWQgYXQgY2hhbmdlZCBmbG93IG9mIHlvdXIgcHJvcG9z
ZWQgdGV4dCBidXQgc29ycnkgbm93IHRoYXQgbXkNCmNvbW1lbnQgaXMgcG9zdGVkLg0KQXQgZmly
c3QgdGltZSwgSSBjb3VsZG4ndCBtYWtlIHN1cmUgaG93ZXZlciwgb24gaGVhcmluZyBTdGlnJ3Mg
ZGVzY3JpcHRpb24sDQppdCBzZWVtcyBxdWl0ZSByZWFzb25hYmxlIGF0IHRoZSBmaXJzdCBzdGVw
LCBub3QgZ2l2aW5nIGFueSByZXN0cmljdGlvbnMgYnV0DQpsZWF2aW5nIHNvbWUtc3BlY2lmaWMg
Zm9yIHRoZSBETU0gc29sdXRpb24gaXQgZG9lcyBub3Qgc3VwcG9ydCBtdWx0aWNhc3QuDQoNCk9u
IHRoZSBvdGhlciBoYW5kLCBpdCByZW1haW5zIGF0IGEgYmFzaWMgc3RhZ2UgZm9yIHRoZSBETU0g
c29sdXRpb24gdG8NCnN1cHBvcnQgbXVsdGljYXN0Lg0KU28gSSB0aGluayBhZGRpdGlvbmFsIHJl
cXVpcmVtZW50cyBuZWVkIHRvIGJlIG1hZGUgZm9yIHRoZSBETU0gc29sdXRpb24sDQphY2NvcmRp
bmdseS4gQnV0IG9mIGNvdXJzZSwgdGhpcyBzaG91bGQgbm90IGFsc28gZ2l2ZSBhbnkgc3BlY2lm
aWMNCmxpbWl0YXRpb24gYW5kIHJlc3RyaWN0aW9uIGJ1dCBzaG91bGQgYmUgbWFkZSB0b3dhcmRz
IHRoZSBkaXJlY3Rpb24gbm90DQpsaW1pdGluZyB0aGUgYmVuZWZpdHMgcHJvdmlkZWQgYnkgZGlz
dHJpYnV0ZWQgZGVwbG95bWVudC4NCg0KSSBob3BlIHRvIGdldCBtb3JlIGNvbW1lbnRzIG9uIHRo
aXMuDQoNClJlZ2FyZHMsDQoNClNlaWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogZG1tLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPiBb
bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNClp1bmlnYSwgSnVhbiBD
YXJsb3MNClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgODoxNCBQTQ0KVG86IFN0aWcg
VmVuYWFzOyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
RE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBTdGlnIFZlbmFhcyBbbWFpbHRvOnN0aWdAdmVuYWFzLmNvbV0NCj4gU2Vu
dDogRnJpZGF5LCBOb3ZlbWJlciAxNiwgMjAxMiAzOjAxIFBNDQo+IFRvOiBqb3VuaSBrb3Job25l
bg0KPiBDYzogc2FyaWtheWFAaWVlZS5vcmc8bWFpbHRvOnNhcmlrYXlhQGllZWUub3JnPjsgWnVu
aWdhLCBKdWFuIENhcmxvczsgS29uc3RhbnRpbm9zIFBlbnRpa291c2lzOw0KPiBQZXRlciBNY0Nh
bm47IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW0RN
TV0gTXVsdGljYXN0IHJlcXVpcmVtZW50cw0KPg0KPiBPbiAxMS8xNS8yMDEyIDM6MTcgQU0sIGpv
dW5pIGtvcmhvbmVuIHdyb3RlOg0KPiA+DQo+ID4gT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFN
LCBCZWhjZXQgU2FyaWtheWEgd3JvdGU6DQo+ID4NCj4gPj4NCj4gPj4gSSB0aGluayB3ZSBhcmUg
cmVhZGluZyB0b28gbXVjaCBpbnRvIG11bHRpY2FzdCBhbmQgdW5pY2FzdCBzaG91bGQNCmJlDQo+
ID4+IGRlc2lnbmVkIGluIGFuIGludGVncmF0ZWQgbWFubmVyLg0KPiA+Pg0KPiA+PiBUaGUgZmFj
dCBpcyB0aGF0IG11bHRpY2FzdCBpcyBjb25zaWRlcmVkIGFzIGFuIGFyZWEgb2YNCj4gc3BlY2lh
bGl6YXRpb24sDQo+ID4+IGl0IHJlcXVpcmVzIGtub3dsZWRnZSBvZiB2ZXJ5IGRpZmZlcmVudCBw
cm90b2NvbHMgdGhhbiB3ZSBhcmUNCj4gPj4gYWNjdXN0b21lZCB0byBpbiBtb2JpbGl0eS4NCj4g
Pg0KPiA+ICJSZXF1aXJlbWVudDogRE1NIHNvbHV0aW9ucyBTSE9VTEQgc3VwcG9ydCBtdWx0aWNh
c3Qgc2VydmljZXMuIElmIGENCj4gc3BlY2lmaWMgRE1NIHNvbHV0aW9uIGRvZXMgbm90IHN1cHBv
cnQgbXVsdGljYXN0IHNlcnZpY2VzLCBhbg0KPiBleHBsYW5hdGlvbiBNVVNUIGJlIHByb3ZpZGVk
LiINCj4NCj4gVGhpcyBzb3VuZHMgZ29vZCB0byBtZS4NCj4NCj4gVGhlIG1haW4gdGhpbmcgSSB3
YW50IHRvIGFjaGlldmUgaXMgd2hhdCB3YXMgZGVzY3JpYmVzIGFzIG1vdGl2YXRpb24NCj4gZWFy
bGllciBpbiB0aGlzIHRocmVhZC4gTXVsdGljYXN0IHNob3VsZCBhdCBsZWFzdCBiZSBjb25zaWRl
cmVkIHdoZW4NCj4gbG9va2luZyBpbnRvIERNTSBzb2x1dGlvbnMsIGFuZCBub3QganVzdCBhbiBh
ZnRlcnRob3VnaHQgb25jZSB0aGUNCj4gc29sdXRpb24gaXMgZGVjaWRlZC4NCj4NCj4gU3RpZw0K
DQpbSkNaXSBJIGZ1bGx5IGFncmVlIHdpdGggdGhpcy4gVGhhdCB3YXMgdGhlIGludGVudGlvbiBv
ZiB0aGUgcHJvcG9zZWQgdGV4dC4NCg0KUmVnYXJkcywNCg0KSnVhbiBDYXJsb3MNCg0KPg0KPiA+
IFRvIG1lIHRoYXQgcmVhZHMgYmFzaWNhbGx5ICJkbyBub3QgYnJlYWsgZm91bmRhdGlvbnMgZm9y
IG11bHRpY2FzdA0KPiB1bmxlc3MgeW91IGhhdmUgYSB2YWxpZCAmIGRvY3VtZW50ZWQgcmVhc29u
IGZvciBpdCIuICBJZiB3ZSBsb29rIGUuZy4NCj4gaW50byBSRkM2MjUgbXVsdGljYXN0IHdvcmRp
bmcgdGhhdCBpcyB0aGVyZSB2ZXJ5IGJyaWVmbHkgYnV0IGdpdmVzIGENCj4gaGludCB0byBhIGRl
dmVsb3BlciB3aGVyZSB0byBoZWFkIHRvLiBUaGF0IGlzIHRoZSBsZXZlbCBJIHdvdWxkIGV4cGVj
dA0KPiBETU0gZG9jdW1lbnRzIHNob3VsZCBhaW0gdG8uDQo+ID4NCj4gPiAtIEpvdW5pDQo+ID4N
Cj4gPg0KPiA+PiBMZXQgZG1tIGRlYWwgd2l0aCBpdHMgY3VycmVudCBjaGFydGVyIHRoYXQgZG9l
cyBub3QgaW5jbHVkZSBhIHdvcmQNCj4gb2YNCj4gPj4gbXVsdGljYXN0IGFuZCBpZiBldmVyeXRo
aW5nIGdvZXMgd2VsbCB3ZSBjYW4gY29tZSBiYWNrIGFuZCBkaXNjdXNzDQo+IGRtbQ0KPiA+PiBt
dWx0aWNhc3QuDQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+DQo+ID4+IEJlaGNldA0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcg
bGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt
bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2
ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn
aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv
dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug
cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUg
ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0
cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KRnJhbmNlIFRlbGVj
b20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg
ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls
ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNo
b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh
dGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo
bWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFu
Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo
YW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo=

--_000_6E31144C030982429702B11D6746B98C36494729SZXEML510MBSchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYg
MCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29Q
bGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnANCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg
bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu
LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy
aWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg
UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u
UGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u
IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC
YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLmVt
YWlscXVvdGUsIGxpLmVtYWlscXVvdGUsIGRpdi5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1l
OmVtYWlscXVvdGU7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbi10b3A6MGluOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6MS4w
cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWls
eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5UZXh0ZWRlYnVsbGVzLCBsaS5UZXh0ZWRlYnVs
bGVzLCBkaXYuVGV4dGVkZWJ1bGxlcw0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVz
IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1
bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz
cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0
IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM
aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTc4Njk2Njc2Ow0K
CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjI3Njk1MjYg
ODQ5Mzc0NzY0IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3
Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt
dGV4dDoiXCglMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1i
b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIDMgcHJvcG9zYWxzIGZvciBtdWx0aWNhc3Qg
cmVxdWlyZW1lbnRzLiBCZWZvcmUgY29tcGFyaW5nIHRoZXNlIHByb3Bvc2FscywgbGV0IHVzIHVu
ZGVyc3RhbmQgd2hhdCBhcmUgdGhlIHByb2JsZW1zIGZpcnN0LiBUd28gcHJvYmxlbSBzdGF0ZW1l
bnRzIGhhdmUNCiBiZWVuIHByb3Bvc2VkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UFMxIChyZXZpc2VkKTogTm9uLW9w
dGltYWwgcm91dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMzOTkiPlJvdXRpbmcgdmlh
IGEgY2VudHJhbGl6ZWQgYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBsb25nZXIgcm91dGUuIFRo
ZSBwcm9ibGVtIGlzIGVzcGVjaWFsbHkgbWFuaWZlc3RlZCB3aGVuIGFjY2Vzc2luZyBhIGxvY2Fs
IHNlcnZlciBvciBzZXJ2ZXJzIG9mIGEgQ29udGVudA0KIERlbGl2ZXJ5IE5ldHdvcmsgKENETiks
IDxiPm9yIHdoZW4gcmVjZWl2aW5nIC8gc2VuZGluZyBJUCBtdWx0aWNhc3QgcGFja2V0czwvYj4u
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzk5Ij5QUzY6IER1cGxpY2F0ZSBtdWx0aWNh
c3QgdHJhZmZpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzk5Ij5JUCBtdWx0aWNhc3QgZGlz
dHJpYnV0aW9uIG92ZXIgYXJjaGl0ZWN0dXJlcyB1c2luZyBJUCBtb2JpbGl0eSBzb2x1dGlvbnMm
bmJzcDsgbWF5IGxlYWQgdG8gY29udmVyZ2VuY2Ugb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vi
c2NyaXB0aW9ucyB0b3dhcmRzIHRoZSB0dW5uZWzigJlzDQogZG93bnN0cmVhbSBlbnRpdHkgKGUu
Zy4gTUFHIGluIFBNSVB2NikuJm5ic3A7IENvbmNyZXRlbHksIHdoZW4gbXVsdGljYXN0IHN1YnNj
cmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIG1vYmls
aXR5IHR1bm5lbHMsIGR1cGxpY2F0ZSBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25l
IHRvIGJlIHJlY2VpdmVkIHRocm91Z2ggZGlmZmVyZW50IHVwc3RyZWFtIHBhdGhzLiBUaGlzIHBy
b2JsZW0gaXMgcG90ZW50aWFsbHkNCiBtb3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1dGVkIG1vYmls
aXR5IGVudmlyb25tZW50IFtkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0t
MDNdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+VGhlbiwgbGV0IHVzIHNlZSB3aGV0aGVyIGFsbCB0aGUgMyBSRVEgcHJv
cG9zYWxzIGhhdmUgdGhlIHNhbWUgaW50ZW50aW9uLiBJbiB0aGUgZm9sbG93aW5nLCBJIHJlcGhy
YXNlIHRoZW0gdG8gaGlnaGxpZ2h0IHRoZWlyIHNpbWlsYXJpdGllcy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJFUTcu
MTogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5ETU0gc29sdXRpb25zIHNob3VsZCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUg
bXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBzY2VuYXJpby4gRXRjLg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPlRoZSBNb3RpdmF0aW9uIGlzIHRvIGFsbG93IGZsZXhpYmlsaXR5IGluIChl
bmFibGUpIG11bHRpY2FzdCBzb2x1dGlvbnMgdG8gc29sdmUgdGhlIHByb2JsZW1zIFBTMSBhbmQg
UFM2IGFzIGV4cGxhaW5lZCBpbiB1c2UgY2FzZXMgYWxyZWFkeSBwcmVzZW50ZWQgYW5kIGRpc2N1
c3NlZA0KIGluIG11bHRpbW9iIHdnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UkVRNy4yOg0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBzb2x1dGlvbnMgdG8g
c3VwcG9ydCBtdWx0aWNhc3QgdHJhZmZpYy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KE9yaWdpbmFsIHdvcmRpbmcg
d2FzICZxdW90O1RoZSBETU0gKHVuaWNhc3QpIHNvbHV0aW9uIE1VU1QgYmUgc3BlY2lmaWVkIGlu
IHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWxzbyBzdXBwb3J0IG11bHRp
Y2FzdCB0cmFmZmljLiZxdW90OyBJIHJlcGhyYXNlIGl0DQogdG8gaGlnaGxpZ2h0IHRoZSBzaW1p
bGFyaXR5IHdpdGggdGhlIG90aGVyIHByb3Bvc2FscyBhbmQgYWxzbyBjaGFuZ2VkIHRoZSBtdXN0
IHRvIHNob3VsZC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SRVE3LjM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBzb2x1dGlvbnMgdG8gc3VwcG9ydCBtdWx0
aWNhc3Qgc2VydmljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PcmlnaW5hbCB3b3JkaW5nIHdhcyDigJxETU0gc29s
dXRpb25zIHNob3VsZCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcyDigKYgZXRjLiBHaXZlbiB0
aGF0IGl0IGlzIHRoZSBzY29wZSBvZiBtdWx0aW1vYiBhbmQgbm90IGRtbSB3ZyB0byBwcm92aWRl
IHRoZSBtdWx0aWNhc3QNCiBzb2x1dGlvbiwgSSB0aGluayDigJxzdXBwb3J04oCdIGhlcmUgbWVh
bnMg4oCcZW5hYmxl4oCdIHNvbHV0aW9ucyB0byBiZSBkZXZlbG9wZWQgKGJ5IG11bHRpbW9iKS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlNpbWlsYXJpdHkgYW5kIHN1YnRsZSBkaWZmZXJlbmNlczogQm90aCBSRVE3LjIg
YW5kIFJFUTcuMyB3YW50IHRvIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMuIFlldCB0aGUgZXhw
bGFuYXRpb24gaW4gUkVRNy4xIHNlZW1zIHRvIGluZGljYXRlIG5vdCBqdXN0IHRvIGVuYWJsZQ0K
IGFueSBvbmUgbXVsdGljYXN0IHNvbHV0aW9uIGJ1dCBhbHNvIG5lZWRzIHRoZSBmbGV4aWJpbGl0
eSBpbiBtdWx0aWNhc3Qgc29sdXRpb24uIE5vdCBhbGwgbXVsdGljYXN0IHNvbHV0aW9ucyBhcmUg
dGhlIHNhbWUuIFNvbWUgb2YgdGhlbSByZXN1bHRzIGluIFBTMSBvciBQUzYuDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5BcmUgdGhlcmUgYW55IGFyZSBlc3NlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2Vlbjo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gUkVRNy4xLCBETU0gc29sdXRpb25zIHNo
b3VsZCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBz
Y2VuYXJpbywgZXRjLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlZlcnN1czxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ETU0gc29sdXRpb25zIHNob3VsZCBlbmFibGUgbXVs
dGljYXN0IHNlcnZpY2VzIHdoaWNoIGFyZSBjb21wYXRpYmxlIHdpdGggbXVsdGljYXN0IGRpc3Ry
aWJ1dGlvbiBzY2VuYXJpbywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SCBBbnRob255IENoYW48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGll
dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TZWlsIEplb248YnI+DQo8Yj5TZW50OjwvYj4g
TW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxMiA1OjE1IEFNPGJyPg0KPGI+VG86PC9iPiBwaWVycmlj
ay5zZWl0ZUBvcmFuZ2UuY29tPGJyPg0KPGI+Q2M6PC9iPiBkbW1AaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5IaSBQaWVycmljayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J4oCZ
dmUgbWFueSB0aW1lcyB0aG91Z2h0IGFib3V0IHlvdXIgcXVlc3Rpb24uIEkgd291bGQgc2F5IGhv
dyBlZmZlY3RpdmVseSBzaG91bGQgd2UgZGVwbG95L3N1cHBvcnQgbXVsdGljYXN0IG92ZXIgZGlz
dHJpYnV0ZWQgbW9iaWxpdHkgcmF0aGVyIHRoYW4gZGlzdHJpYnV0ZWQgbW9iaWxlIG11bHRpY2Fz
dC4NCiBBcyBhIHJlc3VsdCwgeW91IGNhbiBmaW5kIHRoaXMgZGVwbG95bWVudCB1c2UgY2FzZSBh
bmQgZ2FwIGFuYWx5c2lzIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wMyI+DQpodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDM8
L2E+IHByZXNlbnRlZCBpbiBtdWx0aW1vYiBzZXZlcmFsIHRpbWVzLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkluIHVuaWNhc3QgRE1NLCBtYWluIGlubm92YXRpb24gaXMgdG8g
ZGlzdHJpYnV0ZSB0aGUgYW5jaG9yIGZ1bmN0aW9uIGF0IG1hbnkgYWNjZXNzIHJvdXRlcnMgZnJv
bSBzaW5nbGUgY29yZS4gRm9sbG93aW5nIGFyY2hpdGVjdHVyYWwgY29uY2VwdCBvZiBETU0sIGZs
ZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24NCiBpcyBvbmUgb2YgbXVsdGljYXN0IHJlcXVp
cmVtZW50IHJlc3VsdGVkIGZyb20gdGhlIGRyYWZ0IGRlc2NyaWJlZCBhYm92ZS4gPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+UkVRODogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtETU0gc29sdXRpb25zIFNIT1VMRCBiZSBjb21w
YXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBzY2VuYXJpb3MuIFRo
aXMgZmxleGliaWxpdHkgZW5hYmxlcyBkaWZmZXJlbnQgSVAgbXVsdGljYXN0IGZsb3dzIHdpdGgg
cmVzcGVjdCB0byBhIG1vYmlsZSBob3N0IHRvIGJlIG1hbmFnZWQNCiAoZS5nLiwgc3Vic2NyaWJl
ZCwgcmVjZWl2ZWQgYW5kL29yIHRyYW5zbWl0dGVkKSB1c2luZyBtdWx0aXBsZSBlbmRwb2ludHMm
cXVvdDsuIDxicj4NCjxicj4NCk1vdGl2YXRpb246IFRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHJl
cXVpcmVtZW50IGlzIHRvIGVuYWJsZSBmbGV4aWJpbGl0eSBpbiBtdWx0aWNhc3QgZGlzdHJpYnV0
aW9uLiBUaGUgbXVsdGljYXN0IHNvbHV0aW9uIG1heSB0aGVyZWZvcmUgYXZvaWQgaGF2aW5nIG11
bHRpY2FzdC1jYXBhYmxlIGFjY2VzcyByb3V0ZXJzIGJlaW5nIHJlc3RyaWN0ZWQgdG8gbWFuYWdl
IGFsbCBJUCBtdWx0aWNhc3QgdHJhZmZpYyByZWxhdGl2ZSB0byBhIGhvc3QgdmlhDQogYSBzaW5n
bGUgZW5kcG9pbnQgKGUuZy4gcmVndWxhciBvciB0dW5uZWwgaW50ZXJmYWNlKSwgd2hpY2ggd291
bGQgbGVhZCB0byB0aGUgcHJvYmxlbXMgZGVzY3JpYmVkIGluIFBTMSBhbmQgUFM2LjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QUzY6IER1cGxpY2F0ZSBtdWx0aWNhc3Qg
dHJhZmZpYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij5JUCBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIG92ZXIgYXJjaGl0ZWN0
dXJlcyB1c2luZyBJUCBtb2JpbGl0eSBzb2x1dGlvbnMmbmJzcDsgbWF5IGxlYWQgdG8gY29udmVy
Z2VuY2Ugb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dhcmRzIHRoZSB0
dW5uZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBpbiBQTUlQdjYpLiZuYnNwOyBD
b25jcmV0ZWx5LA0KIHdoZW4gbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBt
b2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIG1vYmlsaXR5IHR1bm5lbHMsIGR1cGxpY2F0ZSBt
dWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJlIHJlY2VpdmVkIHRocm91Z2gg
ZGlmZmVyZW50IHVwc3RyZWFtIHBhdGhzLiBUaGlzIHByb2JsZW0gaXMgcG90ZW50aWFsbHkgbW9y
ZSBzZXZlcmUgaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudA0KIFtkcmFmdC1z
ZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLjxicj4NCjxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbSBb
bWFpbHRvOnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9u
ZGF5LCBOb3ZlbWJlciAxOSwgMjAxMiA4OjU1IEFNPGJyPg0KPGI+VG86PC9iPiAna2FyYWdpYW5A
Y3MudXR3ZW50ZS5ubCc7IHNlaWxqZW9uQGF2Lml0LnB0OyBKdWFuQ2FybG9zLlp1bmlnYUBJbnRl
ckRpZ2l0YWwuY29tPGJyPg0KPGI+Q2M6PC9iPiBkbW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUkU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRl
bmQgdG8gYWdyZWUgd2l0aCBHZW9yZ2lvdXMsIGhvd2V2ZXIgSSBzdGlsbCBkbyBub3QgZmlndXJl
IG91dCB3aGF0IGlzIHRoZSB1c2UtY2FzZSBmb3IgZGlzdHJpYnV0ZWQgbW9iaWxlIG11bHRpY2Fz
dCAob3RoZXIgdGhhbiBhY2FkZW1pYyBjb25zaWRlcmF0aW9ucyk/DQogQ2FuIHNvbWVvbmUgZ2l2
ZSBjb25jcmV0ZSBleGFtcGxlPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZW7igJl0IHJlYWwgYWxsIG1lc3Nh
Z2VzIGZyb20gdGhpcyB0aHJlYWQuIFNvLCBtYXliZSBJIG1pc3NlZCBpbXBvcnRhbnQgcG9pbnRz
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBpZXJyaWNrPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPmRtbS1ib3Vu
Y2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj5t
YWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gPGEg
aHJlZj0ibWFpbHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmwiPmthcmFnaWFuQGNzLnV0d2VudGUu
bmw8L2E+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IHNhbWVkaSAxNyBub3ZlbWJyZSAyMDEy
IDEzOjAxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86c2VpbGplb25AYXYu
aXQucHQiPnNlaWxqZW9uQGF2Lml0LnB0PC9hPjsgPGEgaHJlZj0ibWFpbHRvOkp1YW5DYXJsb3Mu
WnVuaWdhQEludGVyRGlnaXRhbC5jb20iPg0KSnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFs
LmNvbTwvYT48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5v
cmciPmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbRE1NXSBN
dWx0aWNhc3QgcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOmJsYWNrIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6YmxhY2siPkkgYWxzbyBhZ3JlZSB0aGF0IHRoZSBETU0gc29sdXRpb24gc2hvdWxkIHNv
bWVob3cgY29uc2lkZXIgbXV0aWNhc3QgZGVwbG95bWVudC4gSG93ZXZlciwgSSBkbyBub3QgdGhu
ayB0aGF0IHRoZSBETU0gV0cgaXMgdGhlIHJpZ2h0IFdHIHRvIHByb3ZpZGUgdGhlIG11bHRpY2Fz
dCBiYXNlZCBETU0NCiBzb2x1dGlvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs
YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjpibGFjayI+T25lIGFsdGVybmF0aXZlIHNvbHV0aW9uIHdpbGwgYmUgdG8gaGF2ZSBhIG11
bHRpY2FzdCByZXF1aXJlbWVudCB0aGF0IGVtcGhhc2l6ZXMgdGhlIG5lZWQgb2YgaGF2aW5nIGV4
dGVuc2liaWxpdHkgaG9va3MgKHBvc3NpYmlsaXRpZXMpIHRoYXQgY2FuIGJlIHVzZWQgbGF0ZXIg
b24gYnkgdGhlDQogbXVsdGltb2IgV0cgdG8gcHJvdmlkZSBhIDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+
YSBtdWx0aWNhc3QgZW5hYmxlZCBETU0gc29sdXRpb24hPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz
cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U28gYSByZXF1
aXJlbWVudCB0aGF0IHNwZWNpZmllcyBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIGNvdWxk
IGJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjpibGFjayI+JnF1b3Q7VGhlIERNTSAodW5pY2FzdCkgc29sdXRpb24mbmJzcDtNVVNU
IGJlIHNwZWNpZmllZCBpbiBzdWNoIGEgd2F5IHRoYXQgaXQgY2FuIGJlIGV4dGVuZGVkIHRvIGFs
c28gc3VwcG9ydCBtdWx0aWNhc3QgdHJhZmZpYy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HZW9yZ2lvczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48
c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIg
YWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlGd2RNc2ci
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VmFuOjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxzcGFuIGxhbmc9
IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmRt
bS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+ZG1tLWJvdW5jZXNAaWV0Zi5v
cmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+DQogW2RtbS1ib3VuY2VzQGlldGYub3JnXSBuYW1lbnMgU2VpbCBKZW9uIFtzZWlsamVvbkBh
di5pdC5wdF08YnI+DQo8Yj5WZXJ6b25kZW46PC9iPiB2cmlqZGFnIDE2IG5vdmVtYmVyIDIwMTIg
MjI6MjU8YnI+DQo8Yj5Ubzo8L2I+ICdadW5pZ2EsIEp1YW4gQ2FybG9zJzxicj4NCjxiPkNjOjwv
Yj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbUBp
ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OmJsYWNrIj48YnI+DQo8Yj5PbmRlcndlcnA6PC9iPiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVp
cmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOmJsYWNrIj5IaSBKdWFuLDxicj4NCjxicj4NCkkndmUgYmVlbiBsb29rZWQgYXQgY2hhbmdl
ZCBmbG93IG9mIHlvdXIgcHJvcG9zZWQgdGV4dCBidXQgc29ycnkgbm93IHRoYXQgbXk8YnI+DQpj
b21tZW50IGlzIHBvc3RlZC48YnI+DQpBdCBmaXJzdCB0aW1lLCBJIGNvdWxkbid0IG1ha2Ugc3Vy
ZSBob3dldmVyLCBvbiBoZWFyaW5nIFN0aWcncyBkZXNjcmlwdGlvbiw8YnI+DQppdCBzZWVtcyBx
dWl0ZSByZWFzb25hYmxlIGF0IHRoZSBmaXJzdCBzdGVwLCBub3QgZ2l2aW5nIGFueSByZXN0cmlj
dGlvbnMgYnV0PGJyPg0KbGVhdmluZyBzb21lLXNwZWNpZmljIGZvciB0aGUgRE1NIHNvbHV0aW9u
IGl0IGRvZXMgbm90IHN1cHBvcnQgbXVsdGljYXN0Ljxicj4NCjxicj4NCk9uIHRoZSBvdGhlciBo
YW5kLCBpdCByZW1haW5zIGF0IGEgYmFzaWMgc3RhZ2UgZm9yIHRoZSBETU0gc29sdXRpb24gdG88
YnI+DQpzdXBwb3J0IG11bHRpY2FzdC48YnI+DQpTbyBJIHRoaW5rIGFkZGl0aW9uYWwgcmVxdWly
ZW1lbnRzIG5lZWQgdG8gYmUgbWFkZSBmb3IgdGhlIERNTSBzb2x1dGlvbiw8YnI+DQphY2NvcmRp
bmdseS4gQnV0IG9mIGNvdXJzZSwgdGhpcyBzaG91bGQgbm90IGFsc28gZ2l2ZSBhbnkgc3BlY2lm
aWM8YnI+DQpsaW1pdGF0aW9uIGFuZCByZXN0cmljdGlvbiBidXQgc2hvdWxkIGJlIG1hZGUgdG93
YXJkcyB0aGUgZGlyZWN0aW9uIG5vdDxicj4NCmxpbWl0aW5nIHRoZSBiZW5lZml0cyBwcm92aWRl
ZCBieSBkaXN0cmlidXRlZCBkZXBsb3ltZW50Ljxicj4NCjxicj4NCkkgaG9wZSB0byBnZXQgbW9y
ZSBjb21tZW50cyBvbiB0aGlzLjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkcyw8YnI+DQo8YnI+DQpTZWlsPGJyPg0KPGJyPg0K
PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8L3NwYW4+PHNwYW4g
bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWls
dG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5kbW0tYm91bmNlc0Bp
ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OmJsYWNrIj4NCiBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPm1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwv
c3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5d
DQogT24gQmVoYWxmIE9mPGJyPg0KWnVuaWdhLCBKdWFuIENhcmxvczxicj4NClNlbnQ6IEZyaWRh
eSwgTm92ZW1iZXIgMTYsIDIwMTIgODoxNCBQTTxicj4NClRvOiBTdGlnIFZlbmFhczsgPC9zcGFu
PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJl
Zj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbUBpZXRmLm9yZzwv
c3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48
YnI+DQpTdWJqZWN0OiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50czxicj4NCjxicj4N
Cjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFN0
aWcgVmVuYWFzIFs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c3RpZ0B2ZW5hYXMuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gbGFuZz0iRU4tVVMiPm1haWx0bzpzdGlnQHZlbmFhcy5jb208L3NwYW4+PC9hPjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XTxicj4NCiZndDsg
U2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNiwgMjAxMiAzOjAxIFBNPGJyPg0KJmd0OyBUbzogam91
bmkga29yaG9uZW48YnI+DQomZ3Q7IENjOiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c2FyaWtheWFAaWVlZS5v
cmciPjxzcGFuIGxhbmc9IkVOLVVTIj5zYXJpa2F5YUBpZWVlLm9yZzwvc3Bhbj48L2E+PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj47DQogWnVuaWdhLCBKdWFu
IENhcmxvczsgS29uc3RhbnRpbm9zIFBlbnRpa291c2lzOyA8YnI+DQomZ3Q7IFBldGVyIE1jQ2Fu
bjsgPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbUBp
ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OmJsYWNrIj48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1l
bnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDExLzE1LzIwMTIgMzoxNyBBTSwgam91bmkga29y
aG9uZW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIE5vdiAxNSwgMjAx
MiwgYXQgMTowMyBBTSwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4N
CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgd2UgYXJlIHJlYWRpbmcg
dG9vIG11Y2ggaW50byBtdWx0aWNhc3QgYW5kIHVuaWNhc3Qgc2hvdWxkPGJyPg0KYmU8YnI+DQom
Z3Q7ICZndDsmZ3Q7IGRlc2lnbmVkIGluIGFuIGludGVncmF0ZWQgbWFubmVyLjxicj4NCjwvc3Bh
bj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsg
Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoZSBmYWN0IGlzIHRoYXQgbXVsdGljYXN0IGlz
IGNvbnNpZGVyZWQgYXMgYW4gYXJlYSBvZjxicj4NCiZndDsgc3BlY2lhbGl6YXRpb24sPGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyBpdCByZXF1aXJlcyBrbm93bGVkZ2Ugb2YgdmVyeSBkaWZmZXJlbnQgcHJv
dG9jb2xzIHRoYW4gd2UgYXJlIDxicj4NCiZndDsgJmd0OyZndDsgYWNjdXN0b21lZCB0byBpbiBt
b2JpbGl0eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7UmVxdWlyZW1lbnQ6
IERNTSBzb2x1dGlvbnMgU0hPVUxEIHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2VzLiBJZiBhPGJy
Pg0KJmd0OyBzcGVjaWZpYyBETU0gc29sdXRpb24gZG9lcyBub3Qgc3VwcG9ydCBtdWx0aWNhc3Qg
c2VydmljZXMsIGFuIDxicj4NCiZndDsgZXhwbGFuYXRpb24gTVVTVCBiZSBwcm92aWRlZC4mcXVv
dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBzb3VuZHMgZ29vZCB0byBtZS48YnI+DQomZ3Q7
IDxicj4NCiZndDsgVGhlIG1haW4gdGhpbmcgSSB3YW50IHRvIGFjaGlldmUgaXMgd2hhdCB3YXMg
ZGVzY3JpYmVzIGFzIG1vdGl2YXRpb24gPGJyPg0KJmd0OyBlYXJsaWVyIGluIHRoaXMgdGhyZWFk
LiBNdWx0aWNhc3Qgc2hvdWxkIGF0IGxlYXN0IGJlIGNvbnNpZGVyZWQgd2hlbiA8YnI+DQomZ3Q7
IGxvb2tpbmcgaW50byBETU0gc29sdXRpb25zLCBhbmQgbm90IGp1c3QgYW4gYWZ0ZXJ0aG91Z2h0
IG9uY2UgdGhlIDxicj4NCiZndDsgc29sdXRpb24gaXMgZGVjaWRlZC48YnI+DQomZ3Q7IDxicj4N
CiZndDsgU3RpZzxicj4NCjxicj4NCltKQ1pdIEkgZnVsbHkgYWdyZWUgd2l0aCB0aGlzLiBUaGF0
IHdhcyB0aGUgaW50ZW50aW9uIG9mIHRoZSBwcm9wb3NlZCB0ZXh0Ljxicj4NCjxicj4NClJlZ2Fy
ZHMsPGJyPg0KPGJyPg0KSnVhbiBDYXJsb3M8YnI+DQombmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgJmd0OyBUbyBtZSB0aGF0IHJlYWRzIGJhc2ljYWxseSAmcXVvdDtkbyBub3QgYnJlYWsgZm91
bmRhdGlvbnMgZm9yIG11bHRpY2FzdDxicj4NCiZndDsgdW5sZXNzIHlvdSBoYXZlIGEgdmFsaWQg
JmFtcDsgZG9jdW1lbnRlZCByZWFzb24gZm9yIGl0JnF1b3Q7LiZuYnNwOyBJZiB3ZSBsb29rIGUu
Zy48YnI+DQomZ3Q7IGludG8gUkZDNjI1IG11bHRpY2FzdCB3b3JkaW5nIHRoYXQgaXMgdGhlcmUg
dmVyeSBicmllZmx5IGJ1dCBnaXZlcyBhIDxicj4NCiZndDsgaGludCB0byBhIGRldmVsb3BlciB3
aGVyZSB0byBoZWFkIHRvLiBUaGF0IGlzIHRoZSBsZXZlbCBJIHdvdWxkIGV4cGVjdCA8YnI+DQom
Z3Q7IERNTSBkb2N1bWVudHMgc2hvdWxkIGFpbSB0by48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7
ICZndDsgLSBKb3VuaTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0
OyZndDsgTGV0IGRtbSBkZWFsIHdpdGggaXRzIGN1cnJlbnQgY2hhcnRlciB0aGF0IGRvZXMgbm90
IGluY2x1ZGUgYSB3b3JkPGJyPg0KJmd0OyBvZjxicj4NCiZndDsgJmd0OyZndDsgbXVsdGljYXN0
IGFuZCBpZiBldmVyeXRoaW5nIGdvZXMgd2VsbCB3ZSBjYW4gY29tZSBiYWNrIGFuZCBkaXNjdXNz
PGJyPg0KJmd0OyBkbW08YnI+DQomZ3Q7ICZndDsmZ3Q7IG11bHRpY2FzdC48YnI+DQo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDs8YnI+
DQomZ3Q7ICZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0
OyZndDsgQmVoY2V0PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxzcGFuIGxh
bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRv
OmRtbUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8L3Nw
YW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2RtbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOmJsYWNrIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PHNwYW4gbGFu
Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86
ZG1tQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bh
bj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZG1tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj
b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg
ZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y
aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl
eiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG
UiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p
bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0
ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZy
YW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug
bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBh
dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h
dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBP
cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs
IGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_6E31144C030982429702B11D6746B98C36494729SZXEML510MBSchi_--

From sfigueiredo@av.it.pt  Mon Nov 19 15:23:52 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D623421F84A1 for ; Mon, 19 Nov 2012 15:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.39
X-Spam-Level: 
X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK5AO9pntyKY for ; Mon, 19 Nov 2012 15:23:45 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2921F81FE for ; Mon, 19 Nov 2012 15:23:44 -0800 (PST)
Received: from [2.83.241.202] (account sfigueiredo@av.it.pt HELO [192.168.10.8]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67071889 for dmm@ietf.org; Mon, 19 Nov 2012 23:23:42 +0000
Message-ID: <50AABF7D.9020003@av.it.pt>
Date: Mon, 19 Nov 2012 23:23:41 +0000
From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: dmm@ietf.org
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt>  <23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huaw ei.com>
In-Reply-To: <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------030006050308010602020507"
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 23:23:52 -0000

This is a multi-part message in MIME format.
--------------030006050308010602020507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with 
your analysis.

As for the question you posed, first I would like to exactly understand 
what you mean with "multicast distribution scenario" in "DMM solutions 
should enable multicast services which are compatible with multicast 
distribution scenario, etc.". It seems like there is no major difference 
between this and the "DMM solutions should enable solutions to support 
multicast services." requirement? Aren't both expressing the need to 
enable multicast in a DMM solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to 
the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 
solutions to allow deployment of multicast services, 7.1 concerns  "how" 
IP multicast should be enabled in order to avoid the aforementioned PSs. 
The usage of the word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a 
mobile host to be managed (e.g., subscribed, received and/or 
transmitted) using multiple endpoints".

In other words, compatibility with "multicast distribution scenario" 
doesn't necessarily avoid PS1 and PS6.

Thank you and best regards,
Sérgio

On 11/19/2012 10:28 PM, h chan wrote:
>
> There are 3 proposals for multicast requirements. Before comparing 
> these proposals, let us understand what are the problems first. Two 
> problem statements have been proposed:
>
> PS1 (revised): Non-optimal routes
>
> Routing via a centralized anchor often results in a longer route. The 
> problem is especially manifested when accessing a local server or 
> servers of a Content Delivery Network (CDN), *or when receiving / 
> sending IP multicast packets*.
>
> PS6: Duplicate multicast traffic
>
> IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel's downstream entity (e.g. MAG in 
> PMIPv6).  Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
> Then, let us see whether all the 3 REQ proposals have the same 
> intention. In the following, I rephrase them to highlight their 
> similarities.
>
> REQ7.1: Flexible multicast distribution
>
> DMM solutions should be compatible with flexible multicast 
> distribution scenario. Etc.
>
> The Motivation is to allow flexibility in (enable) multicast solutions 
> to solve the problems PS1 and PS6 as explained in use cases already 
> presented and discussed in multimob wg.
>
> REQ7.2:
>
> DMM solutions should enable solutions to support multicast traffic.
>
> (Original wording was "The DMM (unicast) solution MUST be specified in 
> such a way that it can be extended to also support multicast traffic." 
> I rephrase it to highlight the similarity with the other proposals and 
> also changed the must to should.)
>
> REQ7.3:
>
> DMM solutions should enable solutions to support multicast services.
>
> Original wording was "DMM solutions should support multicast services 
> ... etc. Given that it is the scope of multimob and not dmm wg to 
> provide the multicast solution, I think "support" here means "enable" 
> solutions to be developed (by multimob).
>
> Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to 
> enable multicast services. Yet the explanation in REQ7.1 seems to 
> indicate not just to enable any one multicast solution but also needs 
> the flexibility in multicast solution. Not all multicast solutions are 
> the same. Some of them results in PS1 or PS6.
>
> Are there any are essential differences between:
>
> In REQ7.1, DMM solutions should be compatible with flexible multicast 
> distribution scenario, etc.
>
> Versus
>
> DMM solutions should enable multicast services which are compatible 
> with multicast distribution scenario, etc.
>
> H Anthony Chan
>
> *From:*dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] *On Behalf 
> Of *Seil Jeon
> *Sent:* Monday, November 19, 2012 5:15 AM
> *To:* pierrick.seite@orange.com
> *Cc:* dmm@ietf.org
> *Subject:* Re: [DMM] Multicast requirements
>
> Hi Pierrick,
>
> I've many times thought about your question. I would say how 
> effectively should we deploy/support multicast over distributed 
> mobility rather than distributed mobile multicast. As a result, you 
> can find this deployment use case and gap analysis at 
> http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 
> presented in multimob several times.
>
> In unicast DMM, main innovation is to distribute the anchor function 
> at many access routers from single core. Following architectural 
> concept of DMM, flexible multicast distribution is one of multicast 
> requirement resulted from the draft described above.
>
> REQ8: Flexible multicast distribution
>
> "DMM solutions SHOULD be compatible with flexible multicast 
> distribution scenarios. This flexibility enables different IP 
> multicast flows with respect to a mobile host to be managed (e.g., 
> subscribed, received and/or transmitted) using multiple endpoints".
>
> Motivation: The motivation for this requirement is to enable 
> flexibility in multicast distribution. The multicast solution may 
> therefore avoid having multicast-capable access routers being 
> restricted to manage all IP multicast traffic relative to a host via a 
> single endpoint (e.g. regular or tunnel interface), which would lead 
> to the problems described in PS1 and PS6.
>
> PS6: Duplicate multicast traffic
>
> IP multicast distribution over architectures using IP mobility 
> solutions may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel's downstream entity (e.g. MAG in 
> PMIPv6). Concretely, when multicast subscription for individual mobile 
> nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
> Regards,
>
> Seil
>
> *From:*pierrick.seite@orange.com [mailto:pierrick.seite@orange.com]
> *Sent:* Monday, November 19, 2012 8:55 AM
> *To:* 'karagian@cs.utwente.nl'; seiljeon@av.it.pt; 
> JuanCarlos.Zuniga@InterDigital.com
> *Cc:* dmm@ietf.org
> *Subject:* RE: [DMM] Multicast requirements
>
> Hi all,
>
> I tend to agree with Georgious, however I still do not figure out what 
> is the use-case for distributed mobile multicast (other than academic 
> considerations)? Can someone give concrete example?
>
> I haven't real all messages from this thread. So, maybe I missed 
> important points.
>
> BR,
>
> Pierrick
>
> *De :*dmm-bounces@ietf.org  
> [mailto:dmm-bounces@ietf.org] *De la part de* karagian@cs.utwente.nl 
> 
> *Envoyé :* samedi 17 novembre 2012 13:01
> *À :* seiljeon@av.it.pt ; 
> JuanCarlos.Zuniga@InterDigital.com 
> 
> *Cc :* dmm@ietf.org 
> *Objet :* Re: [DMM] Multicast requirements
>
> Hi all,
>
> I also agree that the DMM solution should somehow consider muticast 
> deployment. However, I do not thnk that the DMM WG is the right WG to 
> provide the multicast based DMM solution!
>
> One alternative solution will be to have a multicast requirement that 
> emphasizes the need of having extensibility hooks (possibilities) that 
> can be used later on by the multimob WG to provide a
>
> a multicast enabled DMM solution!
>
> So a requirement that specifies something like the following could be 
> used for this purpose:
>
> "The DMM (unicast) solution MUST be specified in such a way that it 
> can be extended to also support multicast traffic."
>
> Best regards,
>
> Georgios
>
> ------------------------------------------------------------------------
>
> *Van:*dmm-bounces@ietf.org 
> [dmm-bounces@ietf.org] namens Seil Jeon 
> [seiljeon@av.it.pt]
> *Verzonden:* vrijdag 16 november 2012 22:25
> *To:* 'Zuniga, Juan Carlos'
> *Cc:* dmm@ietf.org 
> *Onderwerp:* Re: [DMM] Multicast requirements
>
> Hi Juan,
>
> I've been looked at changed flow of your proposed text but sorry now 
> that my
> comment is posted.
> At first time, I couldn't make sure however, on hearing Stig's 
> description,
> it seems quite reasonable at the first step, not giving any 
> restrictions but
> leaving some-specific for the DMM solution it does not support multicast.
>
> On the other hand, it remains at a basic stage for the DMM solution to
> support multicast.
> So I think additional requirements need to be made for the DMM solution,
> accordingly. But of course, this should not also give any specific
> limitation and restriction but should be made towards the direction not
> limiting the benefits provided by distributed deployment.
>
> I hope to get more comments on this.
>
> Regards,
>
> Seil
>
>
> -----Original Message-----
> From: dmm-bounces@ietf.org 
> [mailto:dmm-bounces@ietf.org] On Behalf Of
> Zuniga, Juan Carlos
> Sent: Friday, November 16, 2012 8:14 PM
> To: Stig Venaas; dmm@ietf.org 
> Subject: Re: [DMM] Multicast requirements
>
>
> > -----Original Message-----
> > From: Stig Venaas [mailto:stig@venaas.com]
> > Sent: Friday, November 16, 2012 3:01 PM
> > To: jouni korhonen
> > Cc: sarikaya@ieee.org ; Zuniga, Juan 
> Carlos; Konstantinos Pentikousis;
> > Peter McCann; dmm@ietf.org 
> > Subject: Re: [DMM] Multicast requirements
> >
> > On 11/15/2012 3:17 AM, jouni korhonen wrote:
> > >
> > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> > >
> > >>
> > >> I think we are reading too much into multicast and unicast should
> be
> > >> designed in an integrated manner.
> > >>
> > >> The fact is that multicast is considered as an area of
> > specialization,
> > >> it requires knowledge of very different protocols than we are
> > >> accustomed to in mobility.
> > >
> > > "Requirement: DMM solutions SHOULD support multicast services. If a
> > specific DMM solution does not support multicast services, an
> > explanation MUST be provided."
> >
> > This sounds good to me.
> >
> > The main thing I want to achieve is what was describes as motivation
> > earlier in this thread. Multicast should at least be considered when
> > looking into DMM solutions, and not just an afterthought once the
> > solution is decided.
> >
> > Stig
>
> [JCZ] I fully agree with this. That was the intention of the proposed 
> text.
>
> Regards,
>
> Juan Carlos
>
> >
> > > To me that reads basically "do not break foundations for multicast
> > unless you have a valid & documented reason for it".  If we look e.g.
> > into RFC625 multicast wording that is there very briefly but gives a
> > hint to a developer where to head to. That is the level I would expect
> > DMM documents should aim to.
> > >
> > > - Jouni
> > >
> > >
> > >> Let dmm deal with its current charter that does not include a word
> > of
> > >> multicast and if everything goes well we can come back and discuss
> > dmm
> > >> multicast.
> > >>
> > >> Regards,
> > >>
> > >> Behcet
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmm
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmm
>
> _________________________________________________________________________________________________________________________
>   
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>   
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


--------------030006050308010602020507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Anthony,

      

      Thank you for trying to progress on this matter. I mostly agree
      with your analysis.

      

      As for the question you posed, first I would like to exactly
      understand what you mean with "multicast distribution scenario" in
      "DMM
        solutions should enable multicast services which are compatible
        with multicast distribution scenario, etc.". It seems
      like there is no major difference between this and the "DMM
        solutions should enable solutions to support multicast services."
      requirement? Aren't both expressing the need to enable multicast
      in a DMM solution?

      

      As you stated, "neglecting" the requirement 7.1 we proposed, leads
      to the PSs you referred.  So, while 7.2 and 7.3 express the need
      for DMM solutions to allow deployment of multicast services, 7.1
      concerns  "how" IP multicast should be enabled in order to avoid
      the aforementioned PSs. The usage of the word "flexible"is
      explained by: 

      

      "This
        flexibility enables different IP multicast flows with respect to
        a mobile host to be managed (e.g., subscribed, received and/or
        transmitted) using multiple

        endpoints". 

        

      In other words, compatibility with "multicast distribution
      scenario" doesn't necessarily avoid PS1 and PS6.

      

      Thank you and best regards,

      Sérgio

      

      On 11/19/2012 10:28 PM, h chan wrote:

    

    

      
      
      
      
      

        
There
            are 3 proposals for multicast requirements. Before comparing
            these proposals, let us understand what are the problems
            first. Two problem statements have been proposed:

        
 

        
PS1
            (revised): Non-optimal routes

        
Routing
            via a centralized anchor often results in a longer route.
            The problem is especially manifested when accessing a local
            server or servers of a Content Delivery Network (CDN), or
              when receiving / sending IP multicast packets.
            

        
PS6:
            Duplicate multicast traffic

        
IP
            multicast distribution over architectures using IP mobility
            solutions  may lead to convergence of duplicated multicast
            subscriptions towards the tunnel’s downstream entity (e.g.
            MAG in PMIPv6).  Concretely, when multicast subscription for
            individual mobile nodes is coupled with mobility tunnels,
            duplicate multicast subscription(s) is prone to be received
            through different upstream paths. This problem is
            potentially more severe in a distributed mobility
            environment [draft-sfigueiredo-multimob-use-case-dmm-03].

        
 

        
Then,
            let us see whether all the 3 REQ proposals have the same
            intention. In the following, I rephrase them to highlight
            their similarities.

        
 

        
REQ7.1:
            Flexible multicast distribution

        
DMM
            solutions should be compatible with flexible multicast
            distribution scenario. Etc.
            

        
The
            Motivation is to allow flexibility in (enable) multicast
            solutions to solve the problems PS1 and PS6 as explained in
            use cases already presented and discussed in multimob wg.

        
 

        
REQ7.2:
            

        
DMM
            solutions should enable solutions to support multicast
            traffic.
            

        
 

        
(Original
            wording was "The DMM (unicast) solution MUST be specified in
            such a way that it can be extended to also support multicast
            traffic." I rephrase it to highlight the similarity with the
            other proposals and also changed the must to should.)

        
 

        
REQ7.3:

        
DMM
            solutions should enable solutions to support multicast
            services.

        
 

        
Original
            wording was “DMM solutions should support multicast services
            … etc. Given that it is the scope of multimob and not dmm wg
            to provide the multicast solution, I think “support” here
            means “enable” solutions to be developed (by multimob).

        
 

        
Similarity
            and subtle differences: Both REQ7.2 and REQ7.3 want to
            enable multicast services. Yet the explanation in REQ7.1
            seems to indicate not just to enable any one multicast
            solution but also needs the flexibility in multicast
            solution. Not all multicast solutions are the same. Some of
            them results in PS1 or PS6.
            

        
 

        

          
Are
              there any are essential differences between:

          
In
              REQ7.1, DMM solutions should be compatible with flexible
              multicast distribution scenario, etc.
              

          
Versus

          
DMM
              solutions should enable multicast services which are
              compatible with multicast distribution scenario, etc.

          
 

          
H
              Anthony Chan

        

        
 

        

          

            
From:
                dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
                On Behalf Of Seil Jeon

                Sent: Monday, November 19, 2012 5:15 AM

                To: pierrick.seite@orange.com

                Cc: dmm@ietf.org

                Subject: Re: [DMM] Multicast requirements

          

        

        
 

        
Hi
            Pierrick,

        
 

        
I’ve
            many times thought about your question. I would say how
            effectively should we deploy/support multicast over
            distributed mobility rather than distributed mobile
            multicast. As a result, you can find this deployment use
            case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
            presented in multimob several times.

        
 

        
In
            unicast DMM, main innovation is to distribute the anchor
            function at many access routers from single core. Following
            architectural concept of DMM, flexible multicast
            distribution is one of multicast requirement resulted from
            the draft described above. 

        
 

        
REQ8: Flexible multicast distribution

        
"DMM
          solutions SHOULD be compatible with flexible multicast
          distribution scenarios. This flexibility enables different IP
          multicast flows with respect to a mobile host to be managed
          (e.g., subscribed, received and/or transmitted) using multiple
          endpoints". 

          

          Motivation: The motivation for this requirement is to enable
          flexibility in multicast distribution. The multicast solution
          may therefore avoid having multicast-capable access routers
          being restricted to manage all IP multicast traffic relative
          to a host via a single endpoint (e.g. regular or tunnel
          interface), which would lead to the problems described in PS1
          and PS6.

        
PS6:
          Duplicate multicast traffic

        
IP multicast
          distribution over architectures using IP mobility solutions 
          may lead to convergence of duplicated multicast subscriptions
          towards the tunnel’s downstream entity (e.g. MAG in PMIPv6). 
          Concretely, when multicast subscription for individual mobile
          nodes is coupled with mobility tunnels, duplicate multicast
          subscription(s) is prone to be received through different
          upstream paths. This problem is potentially more severe in a
          distributed mobility environment
          [draft-sfigueiredo-multimob-use-case-dmm-03].

          

          

        
Regards,

        
 

        
Seil

        
 

        

          

            
From:
                pierrick.seite@orange.com
                [mailto:pierrick.seite@orange.com]
                

                Sent: Monday, November 19, 2012 8:55 AM

                To: 'karagian@cs.utwente.nl'; seiljeon@av.it.pt;
                JuanCarlos.Zuniga@InterDigital.com

                Cc: dmm@ietf.org

                Subject: RE: [DMM] Multicast requirements

          

        

        
 

        
Hi all,

        
 

        
I
            tend to agree with Georgious, however I still do not figure
            out what is the use-case for distributed mobile multicast
            (other than academic considerations)? Can someone give
            concrete example? 

        
 

        
I
            haven’t real all messages from this thread. So, maybe I
            missed important points.

        
 

        
BR,

        
Pierrick

        
 

        

          

            

              
De :
                  dmm-bounces@ietf.org
                  [mailto:dmm-bounces@ietf.org]
                  De la part de karagian@cs.utwente.nl

                  Envoyé : samedi 17 novembre 2012 13:01

                  À : seiljeon@av.it.pt;
                  
                    JuanCarlos.Zuniga@InterDigital.com

                  Cc : dmm@ietf.org

                  Objet : Re: [DMM] Multicast requirements

            

          

          
 

          

            
Hi all,

            
 

            
I also agree that the DMM solution should
                somehow consider muticast deployment. However, I do not
                thnk that the DMM WG is the right WG to provide the
                multicast based DMM solution!

            
 

            
One alternative solution will be to have a
                multicast requirement that emphasizes the need of having
                extensibility hooks (possibilities) that can be used
                later on by the multimob WG to provide a 

            
a multicast enabled DMM solution!

            
 

            
 

            
So a requirement that specifies something like
                the following could be used for this purpose:

            
 

            
"The DMM (unicast) solution MUST be specified
                in such a way that it can be extended to also support
                multicast traffic."

            
 

            
 

            
Best regards,

            
Georgios

            
 

            
 

            
 

            

              

                  

                

              

                
Van:
                  dmm-bounces@ietf.org
                    [dmm-bounces@ietf.org] namens Seil Jeon
                    [seiljeon@av.it.pt]

                    Verzonden: vrijdag 16 november 2012 22:25

                    To: 'Zuniga, Juan Carlos'

                    Cc: dmm@ietf.org

                    Onderwerp: Re: [DMM] Multicast requirements

              

            

            

              
Hi Juan,

                  

                  I've been looked at changed flow of your proposed text
                  but sorry now that my

                  comment is posted.

                  At first time, I couldn't make sure however, on
                  hearing Stig's description,

                  it seems quite reasonable at the first step, not
                  giving any restrictions but

                  leaving some-specific for the DMM solution it does not
                  support multicast.

                  

                  On the other hand, it remains at a basic stage for the
                  DMM solution to

                  support multicast.

                  So I think additional requirements need to be made for
                  the DMM solution,

                  accordingly. But of course, this should not also give
                  any specific

                  limitation and restriction but should be made towards
                  the direction not

                  limiting the benefits provided by distributed
                  deployment.

                  

                  I hope to get more comments on this.

                  

                Regards,

                  

                  Seil

                  

                  

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

                  From: dmm-bounces@ietf.org
                  [mailto:dmm-bounces@ietf.org]
                  On Behalf Of

                  Zuniga, Juan Carlos

                  Sent: Friday, November 16, 2012 8:14 PM

                  To: Stig Venaas; dmm@ietf.org

                  Subject: Re: [DMM] Multicast requirements

                  

                  

                  > -----Original Message-----

                  > From: Stig Venaas [mailto:stig@venaas.com]

                  > Sent: Friday, November 16, 2012 3:01 PM

                  > To: jouni korhonen

                  > Cc: sarikaya@ieee.org;
                  Zuniga, Juan Carlos; Konstantinos Pentikousis; 

                  > Peter McCann; dmm@ietf.org

                  > Subject: Re: [DMM] Multicast requirements

                  > 

                  > On 11/15/2012 3:17 AM, jouni korhonen wrote:

                  > >

                  > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya
                  wrote:

                  > >

                  > >>

                  > >> I think we are reading too much into
                  multicast and unicast should

                  be

                  > >> designed in an integrated manner.

                > >>

                  > >> The fact is that multicast is considered
                  as an area of

                  > specialization,

                  > >> it requires knowledge of very different
                  protocols than we are 

                  > >> accustomed to in mobility.

                  > >

                  > > "Requirement: DMM solutions SHOULD support
                  multicast services. If a

                  > specific DMM solution does not support multicast
                  services, an 

                  > explanation MUST be provided."

                  > 

                  > This sounds good to me.

                  > 

                  > The main thing I want to achieve is what was
                  describes as motivation 

                  > earlier in this thread. Multicast should at least
                  be considered when 

                  > looking into DMM solutions, and not just an
                  afterthought once the 

                  > solution is decided.

                  > 

                  > Stig

                  

                  [JCZ] I fully agree with this. That was the intention
                  of the proposed text.

                  

                  Regards,

                  

                  Juan Carlos

                   

                  > 

                  > > To me that reads basically "do not break
                  foundations for multicast

                  > unless you have a valid & documented reason
                  for it".  If we look e.g.

                  > into RFC625 multicast wording that is there very
                  briefly but gives a 

                  > hint to a developer where to head to. That is the
                  level I would expect 

                  > DMM documents should aim to.

                  > >

                  > > - Jouni

                  > >

                  > >

                  > >> Let dmm deal with its current charter
                  that does not include a word

                  > of

                  > >> multicast and if everything goes well we
                  can come back and discuss

                  > dmm

                  > >> multicast.

                >
                  >>

                  > >> Regards,

                  > >>

                  > >> Behcet

                  

                  _______________________________________________

                  dmm mailing list

                dmm@ietf.org

                https://www.ietf.org/mailman/listinfo/dmm

                  

                  _______________________________________________

                  dmm mailing list

                dmm@ietf.org

                https://www.ietf.org/mailman/listinfo/dmm

            

          

        

        
_________________________________________________________________________________________________________________________

        
 

        
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

        
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

        
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

        
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

        
 

        
This message and its attachments may contain confidential or privileged information that may be protected by law;

        
they should not be distributed, used or copied without authorisation.

        
If you have received this email in error, please notify the sender and delete this message and its attachments.

        
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.

        
Thank you.

      

      

      

      

      
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


    

    

  


--------------030006050308010602020507--

From luo.wen@zte.com.cn  Mon Nov 19 18:33:14 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6398621F87FB for ; Mon, 19 Nov 2012 18:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.007
X-Spam-Level: 
X-Spam-Status: No, score=-94.007 tagged_above=-999 required=5 tests=[AWL=2.316, BAYES_20=-0.74, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxSOENqJA69c for ; Mon, 19 Nov 2012 18:33:13 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B102221F87FA for ; Mon, 19 Nov 2012 18:33:12 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4BF181267EEB for ; Tue, 20 Nov 2012 10:34:36 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 7AA617255B7; Tue, 20 Nov 2012 10:30:58 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qAK2X49a071648; Tue, 20 Nov 2012 10:33:04 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
To: "dmm@ietf.org" , h chan 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Tue, 20 Nov 2012 10:33:00 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-20 10:33:03, Serialize complete at 2012-11-20 10:33:03
Content-Type: multipart/related; boundary="=_related 000E051748257ABC_="
X-MAIL: mse02.zte.com.cn qAK2X49a071648
Subject: [DMM] Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirements-02
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 02:33:14 -0000

This is a multipart message in MIME format.
--=_related 000E051748257ABC_=
Content-Type: multipart/alternative; boundary="=_alternative 000E051748257ABC_="


--=_alternative 000E051748257ABC_=
Content-Type: text/plain; charset="US-ASCII"

Hi All,

I have a comment on REQ5:  Compatibility of 
draft-ietf-dmm-requirements-02. What is not clear to me is that the 
meaning of the terms "compatibility\compatible\interoperate\co-exist" is 
not specific. Here is my clearification as following based on the comment 
I provided in the last DMM session in Atlanta.

Consider the scenario which is illustrated in figure A & B: 
Assuming operator A has already deployed PMIP protocol in city A (blue 
area in both figures), and wants to deploy dmm enabled euqipment in a 
certain area of city A in incremental manner (green area in both figures). 
Operator A needs the dmm protocol enabled area to be 
compatible\interopertable to exsiting PMIP protocol enabled area.  Here, 
operator A may have different requirements in terms of 
compatible\interopertable which are illustrated in figure A and B 
respectively.

Figure A, consider as roaming scenario. Any mobile node, as long as it is 
a subscriber of operator A, can be attached to operator A's network in 
both blue and green areas. The mobile node can not see any difference. 
E.g. assuming mobile node is now in green area, powered on, and initial 
attachment is performed (be asigned with an IP@). Then the mobile node can 
access the service provided by operator A (internet access and etc.).  In 
"roaming" scenario, when mobile node leaves green area and enters into 
blue area, the mobile node may need to perform initial attachment 
percedure again (be asigned with another IP@) for the purpose of accessing 
operator A's service. In this case, session continuity may not guaranteed 
when mobile node moves between the green and blue areas (i.e. IP@ may 
change when mobile node moves accross the border of the green and blue 
area).

Figure B, consider as handover scenario which requires more than the 
roaming scenario. E.g. assuming mobile node is initialized in blue area 
(be asigned with an IP@) and enjoys session continuity support when it 
moves within the blue area. When the mobile node enters the green area, in 
this handover scenario, the session continuity for sessions which have 
already setup shall be maintained (i.e. keep IP@ unchanged). The same 
requirement may also be applied to the scenario that when the mobile node 
is initialized in green area and moves to blue area. 

What I suggest is that we should make the terms 
"compatibility\compatible\interoperate\co-exist" more specific. I suppose 
adding some usage cases or usage scenarios may help to understand REQ5 
better.





Any comments are welcome.

BR
LUOWEN


--=_alternative 000E051748257ABC_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3RxbraIj5IaSBBbGwsPC9mb250Pg0KPGJyPg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSLOosjt0cW62iI+SSBoYXZlIGEgY29tbWVudCBvbiBSRVE1
OiAmbmJzcDtDb21wYXRpYmlsaXR5DQpvZiBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDIu
IFdoYXQgaXMgbm90IGNsZWFyIHRvIG1lIGlzIHRoYXQgdGhlDQptZWFuaW5nIG9mIHRoZSB0ZXJt
cyAmcXVvdDtjb21wYXRpYmlsaXR5XGNvbXBhdGlibGVcaW50ZXJvcGVyYXRlXGNvLWV4aXN0JnF1
b3Q7DQppcyBub3Qgc3BlY2lmaWMuIEhlcmUgaXMgbXkgY2xlYXJpZmljYXRpb24gYXMgZm9sbG93
aW5nIGJhc2VkIG9uIHRoZSBjb21tZW50DQpJIHByb3ZpZGVkIGluIHRoZSBsYXN0IERNTSBzZXNz
aW9uIGluIEF0bGFudGEuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSLOosjt
0cW62iI+Q29uc2lkZXIgdGhlIHNjZW5hcmlvIHdoaWNoIGlzIGlsbHVzdHJhdGVkDQppbiBmaWd1
cmUgQSAmYW1wOyBCOiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3R
xbraIj5Bc3N1bWluZyBvcGVyYXRvciBBIGhhcyBhbHJlYWR5IGRlcGxveWVkDQpQTUlQIHByb3Rv
Y29sIGluIGNpdHkgQSAoYmx1ZSBhcmVhIGluIGJvdGggZmlndXJlcyksIGFuZCB3YW50cyB0byBk
ZXBsb3kNCmRtbSBlbmFibGVkIGV1cWlwbWVudCBpbiBhIGNlcnRhaW4gYXJlYSBvZiBjaXR5IEEg
aW4gaW5jcmVtZW50YWwgbWFubmVyDQooZ3JlZW4gYXJlYSBpbiBib3RoIGZpZ3VyZXMpLiBPcGVy
YXRvciBBIG5lZWRzIHRoZSBkbW0gcHJvdG9jb2wgZW5hYmxlZA0KYXJlYSB0byBiZSBjb21wYXRp
YmxlXGludGVyb3BlcnRhYmxlIHRvIGV4c2l0aW5nIFBNSVAgcHJvdG9jb2wgZW5hYmxlZA0KYXJl
YS4gJm5ic3A7SGVyZSwgb3BlcmF0b3IgQSBtYXkgaGF2ZSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRz
IGluIHRlcm1zIG9mDQpjb21wYXRpYmxlXGludGVyb3BlcnRhYmxlIHdoaWNoIGFyZSBpbGx1c3Ry
YXRlZCBpbiBmaWd1cmUgQSBhbmQgQiByZXNwZWN0aXZlbHkuPC9mb250Pg0KPGJyPg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSLOosjt0cW62iI+RmlndXJlIEEsIGNvbnNpZGVyIGFzIHJvYW1pbmcg
c2NlbmFyaW8uDQpBbnkgbW9iaWxlIG5vZGUsIGFzIGxvbmcgYXMgaXQgaXMgYSBzdWJzY3JpYmVy
IG9mIG9wZXJhdG9yIEEsIGNhbiBiZSBhdHRhY2hlZA0KdG8gb3BlcmF0b3IgQSdzIG5ldHdvcmsg
aW4gYm90aCBibHVlIGFuZCBncmVlbiBhcmVhcy4gVGhlIG1vYmlsZSBub2RlIGNhbg0Kbm90IHNl
ZSBhbnkgZGlmZmVyZW5jZS4gRS5nLiBhc3N1bWluZyBtb2JpbGUgbm9kZSBpcyBub3cgaW4gZ3Jl
ZW4gYXJlYSwNCnBvd2VyZWQgb24sIGFuZCBpbml0aWFsIGF0dGFjaG1lbnQgaXMgcGVyZm9ybWVk
IChiZSBhc2lnbmVkIHdpdGggYW4gSVBAKS4NClRoZW4gdGhlIG1vYmlsZSBub2RlIGNhbiBhY2Nl
c3MgdGhlIHNlcnZpY2UgcHJvdmlkZWQgYnkgb3BlcmF0b3IgQSAoaW50ZXJuZXQNCmFjY2VzcyBh
bmQgZXRjLikuICZuYnNwO0luICZxdW90O3JvYW1pbmcmcXVvdDsgc2NlbmFyaW8sIHdoZW4gbW9i
aWxlIG5vZGUNCmxlYXZlcyBncmVlbiBhcmVhIGFuZCBlbnRlcnMgaW50byBibHVlIGFyZWEsIHRo
ZSBtb2JpbGUgbm9kZSBtYXkgbmVlZCB0bw0KcGVyZm9ybSBpbml0aWFsIGF0dGFjaG1lbnQgcGVy
Y2VkdXJlIGFnYWluIChiZSBhc2lnbmVkIHdpdGggYW5vdGhlciBJUEApDQpmb3IgdGhlIHB1cnBv
c2Ugb2YgYWNjZXNzaW5nIG9wZXJhdG9yIEEncyBzZXJ2aWNlLiBJbiB0aGlzIGNhc2UsIHNlc3Np
b24NCmNvbnRpbnVpdHkgbWF5IG5vdCBndWFyYW50ZWVkIHdoZW4gbW9iaWxlIG5vZGUgbW92ZXMg
YmV0d2VlbiB0aGUgZ3JlZW4NCmFuZCBibHVlIGFyZWFzIChpLmUuIElQQCBtYXkgY2hhbmdlIHdo
ZW4gbW9iaWxlIG5vZGUgbW92ZXMgYWNjcm9zcyB0aGUNCmJvcmRlciBvZiB0aGUgZ3JlZW4gYW5k
IGJsdWUgYXJlYSkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSLOosjt0cW6
2iI+RmlndXJlIEIsIGNvbnNpZGVyIGFzIGhhbmRvdmVyIHNjZW5hcmlvDQp3aGljaCByZXF1aXJl
cyBtb3JlIHRoYW4gdGhlIHJvYW1pbmcgc2NlbmFyaW8uIEUuZy4gYXNzdW1pbmcgbW9iaWxlIG5v
ZGUNCmlzIGluaXRpYWxpemVkIGluIGJsdWUgYXJlYSAoYmUgYXNpZ25lZCB3aXRoIGFuIElQQCkg
YW5kIGVuam95cyBzZXNzaW9uDQpjb250aW51aXR5IHN1cHBvcnQgd2hlbiBpdCBtb3ZlcyB3aXRo
aW4gdGhlIGJsdWUgYXJlYS4gV2hlbiB0aGUgbW9iaWxlDQpub2RlIGVudGVycyB0aGUgZ3JlZW4g
YXJlYSwgaW4gdGhpcyBoYW5kb3ZlciBzY2VuYXJpbywgdGhlIHNlc3Npb24gY29udGludWl0eQ0K
Zm9yIHNlc3Npb25zIHdoaWNoIGhhdmUgYWxyZWFkeSBzZXR1cCBzaGFsbCBiZSBtYWludGFpbmVk
IChpLmUuIGtlZXAgSVBADQp1bmNoYW5nZWQpLiBUaGUgc2FtZSByZXF1aXJlbWVudCBtYXkgYWxz
byBiZSBhcHBsaWVkIHRvIHRoZSBzY2VuYXJpbyB0aGF0DQp3aGVuIHRoZSBtb2JpbGUgbm9kZSBp
cyBpbml0aWFsaXplZCBpbiBncmVlbiBhcmVhIGFuZCBtb3ZlcyB0byBibHVlIGFyZWEuDQo8L2Zv
bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3RxbraIj5XaGF0IEkgc3VnZ2Vz
dCBpcyB0aGF0IHdlIHNob3VsZCBtYWtlDQp0aGUgdGVybXMgJnF1b3Q7Y29tcGF0aWJpbGl0eVxj
b21wYXRpYmxlXGludGVyb3BlcmF0ZVxjby1leGlzdCZxdW90OyBtb3JlDQpzcGVjaWZpYy4gSSBz
dXBwb3NlIGFkZGluZyBzb21lIHVzYWdlIGNhc2VzIG9yIHVzYWdlIHNjZW5hcmlvcyBtYXkgaGVs
cA0KdG8gdW5kZXJzdGFuZCBSRVE1IGJldHRlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGltZyBzcmM9
Y2lkOl8xXzA3OTlEMTI0MDc5OUNFRDAwMDBFMDUxNzQ4MjU3QUJDPg0KPGJyPg0KPGJyPjxpbWcg
c3JjPWNpZDpfMV8wNzk5RDdGQzA3OTlENUE4MDAwRTA1MTc0ODI1N0FCQz4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0izqLI7dHFutoiPkFueSBjb21tZW50cyBhcmUgd2VsY29tZS48L2Zv
bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3RxbraIj5CUjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0izqLI7dHFutoiPkxVT1dFTjwvZm9udD4NCjxicj4NCjxicj4N
Cg==
--=_alternative 000E051748257ABC_=--
--=_related 000E051748257ABC_=
Content-Type: image/gif
Content-ID: <_1_0799D1240799CED0000E051748257ABC>
Content-Transfer-Encoding: base64

R0lGODlhzwLgAecAAOjo8P///8DAwJDQUCAgIDg4OLi4uICAgMjIyEBAQAAAAHh4eFBQUGBgYODg
4NjY2JCQkKCgoHBwcPDw8LCwsDAwMKiwuHBweOjo6CgoKPgAAEhISODg6PggIBgYGKioqNjY6NDY
4IiIiJiYmFhYWNDQ0MjQ2PiAgBAQGAAA+LjAyJCQmICAiKCosGiYODA4MLC4wAgICJigqGBoaJiY
oFhYYIiIkEhoKMDI0AgIEBAQEPg4OPjIyHh4gGhoaGhwcGBgaIjISJDQOFBQWCgwGFhgYIC4SBgY
IBgYEGCIMPi4uEBYKPiQkCAgKDgAEFiAMICwQHioQHjQUPhgYABQOFBYUGhocIjASPhQUBAYECAo
GCAoIDhQIPjg4BAQCBggEGiQOGig2HCoQCAoKDBAIDhAOEBIQEhQSEiI4FBwKFCQ4FCwUGCY2Pjw
8CAgGCAwGDBIIDgAIFhgWJCQIJCYoBAYCBggGCg4IECA4FBYWFB4KHB4eHCgOJCwKJDIUNhgYAhQ
kBBooCBgeCBgyCBwQCh4kDiQUEhwiEiIaFCYgGB4mGCoaGhQAHhwEICw4IigaJDI6KDAiKDYcKjg
8LjQoMiQmMjw+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAzwLgAUAI/wADCBxI
sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN
mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp0MVQJ3qVCrVq1izas1pNSMCBREQHChAQGABBQUM
ElCAIMCDAgUeBICLIEIDBQc8jj2412HfmATaFnQgF+FfhA8cjOy6tbHjx5A9Mr74VTBBuAIdEGAw
MHAACAQIQJibViHduhEEelbdlkEBBAYYeD5AoAHsApwD9G1AgAJsCQJl+26AuWDtumQF/n1wXKxc
17BlWx4IOjfvvKw7t+0rgUDYCKn/Hv82mxc8AgqiOU6OzL69+/cD18Ofb1I+/fv48xe1jxBBgbwI
lKWbgAEwkFsAEpQ2kH95ETeQZm1FICAECmZGgAEDOfgAW9oNSFB6e22IoUAGlKWZXMwpRgB2c+VF
AHACSWhQgIqZxZmMn1WoGoyqYUjbh6OtONB/Hg5WomBCfkYggml9VZhBBsa45EL86WfllVjOVOVK
Ab6m0QEHQhRaaiF1OZ1fYRq1ZZZstulmSGuyWRlEY3n3Xpxv5qnnng/h+ZRnAS44pVkEwMVZoIQe
KFuNBHU3mJ2R+cnnpJTyKWmlV16K6aacdrrUAix6KuqopJaKFQUbmKrqqqy26pNmE7j/KuustNZa
UgVn2qrrrrz2epAEIvgq7LDEyvpBmsUm+9MEFCyQgAIZJLDACAbEupIBESzgGloLfICBsrM+kIG1
4Ja7kgM+EDACfR8kwEAJ5mI5gZfx1guSf/B26kACFNjbWAPr+itwRiLwuCCHBQBXwGh9/WgWcKtd
hh1vDPRbUF9EkpddAElyLBhvcHHYsILMjXiAAqGlrFuFGUu8sccHFTywUiM0MFEKAeA8884FCMCr
Ax4MLEC2Q5yVQwEkXNACDAA07fTTUEct9dRUV2311VhnrfXWXFsdggU2XFBABgocUQCoBjC6c1AM
fFBQcRZiV5sCT3LsaABf8UYQcw4e/2TAAaMtGMDfZAr0wAEHjNjiZwc82bIDiKt9+GgtE/T3AYy2
9fdAERxQuFuIK04QAhV0WgIEQ6BAQBE0mND167DHLvvstNdu++2yWyB2DBUsQAG5a380QcUPIGB8
3QIhQG7dlk335ATIL+h55qMPZAAEign2wAQOQPD59gM9AAEEdR+OIfgGgRcA9Mkb9Lfo12ePdwLf
0hdB6iTIgPv+/Pfv//8ADKAAt2YCFmSgCQuIXvAWMoIMfO5KFKhAqLLygAWggAFMG6AGN8jBDnrw
gyCMXQh6gIIhiG6BCHGACDagAxJEoH5DmcAHGuCBAohAgQf5AAF8oLahPGADBbBACP+HSMQiGvGI
SAQhCC6QHhRiqYES6KFJSlCBC3AgiVjMoha3yMUuyg4GEnQim0CzABg+xAoNuKIX18jGNrrxjV4E
Y67EqJ+3MPECIICjHvfIxz76cYN7WAAd2zMCEsCOAyzwQA/U+MdGOvKRkOQjDsY1yKlgAAWMFCAH
LuABFmRSgCGwgg6IoAcjDOCUqEylKlfJyla68pWwhKULuOCFMugvkrjMJRx7IMhKJiUHedziEj1g
A6vhYAs3CEIsl8nMZjrzmdBcpRjeIAFdWvOaIZxBsHwpFJwFDWdtNAERTKnKKyyhDk+I5in94MpI
GEAEBjCePI0XAUGwU534zGcs0+D/gwDmLAAA+Cc2B8rHf9bgn9wESgUyyEUYvEGfqTTCOZMQS0pY
ABJhYAMb1MBRNKAhDBQ4hCAgStKSuhIMZSCoSlfKNX4llCgL1aIJsmDSZUriAQ8owQMwgIA/VAIB
OXUAYRQRCHLW9KhHfUIVWMrUpj7NpS89CtA+ScQQeAGpWM2qVqGpBzk49asEZYEVojoVIBTziByw
AxS2KoQ4SGEAjFCAIQYwByoMQAhOWMMp58CFMbx1q4CF5RJEANbC5hIEFcgXWR9DgQQE04gqsANF
A0vZyq7yCmQwpGE3+0gabAB4i61jBVagRRWYIQs3MKplV8tKMMBBB57krGwdGYIK/2wztKRCjxX5
qAIZXKAKL4iBAohAhBsY1wXIdSYUkPsE43KBCFlQwBZecAEWWOCxs82uNcEIBDPiNlkOsAIKWIBd
OHKgAAzVrnqbCoMNZMBt341v+A5whASsgKoabEEC1svfSOJgBiWEr3wHfBIHjGADMdiADVyHtQS0
oL8QzmILZuCBJkjAZwTOcFIEkADQpjBbBYgBATZwgetG+MQqWMEMQtyEIRwAwxqOcWRcSJQSGOAD
C3BWAY6ggBjAZQYXsIEF0htCgDbNyEO0gAVWcIEfwCUHCjja2RYAAQOcUMZYJlUJCuDdLHv5y7MC
FpjHTGZWvUWKZU5zJXOs5pSwuf/NcH7KmxXiMOsRQDFwwdHgCDCB1eSZQCXqc654EwHQYAcuDTjA
XTDknyoXZyz/oU1pEMU3CujNLbVRdHIuxgDw1EY5cDlAv3BDAQkogNELMwDcLvOfBPm5YqZm9GYk
AKY7401AfEPcpw1ANwvJhdCGFsh16jTBxXEsYXVyyJzjzOykLHtmiJqInl/y7GZbeyjVDh9elBIx
nUQbK9m+0gk00IEdmJsJATjBFFLCBA24G93XtlK4sxNtRBXAZgT5i4Q8vJpo70UzFnOZxjiGnb8k
qdu3HshfiGRwABEIUeJJC8ANUrmDKS5JJQLTQe79IALIpc68bsuLDLJw7IRcNdj/kRCjGpAbhB9k
3voZ9w4K0gEN8CDd7q55zU8QgC7kvAM7DwAPyE2QHZAb6DMniBLI3YWBdKHmSog3fmAudYtQvepY
n8nVJXIhBA2K3grA96UJQoER9Y0goBmRj2wdoLXbLFZww9z6Rg6zvAl7UA8gE2iU8+kJ8Lpf88pL
3gWy94LwmkwROPXA99ZEJCEJO3cztuUExHGPbD3rmG/J5aPqgBJdGSWbz7zoR0/60pv+9KhPvepX
z/rWu/71sI+97GdP+9rbnlaaWn3ubw/73R/kK7TuTm4wkzEi+bk0ZEGcbE64bxIJqIkwIwiEBmSt
PodH4r3pEKQKpKOC4Ig21jp7/4IedSaWY7oAqZFAywMHs75sn+8DGf/b8gL+j/ie962//+n1j3/V
7/7bGeFyDDEeftF9XjEoAGgTHUMRmlFxVNJ/EFgQa5J4tBZqCbcyA9FnkcYAEaIAFUgkDXgA6hcx
Z/F5plaBrqEcHiiCuSFpIkh3fZF4icYbltEdLFIiidYXFBB2iiYbM1IoH3gZimcQzMEAL0gmLtgd
MIKDiFMaf3EdIygYsnEAscIbtJaCF1gQImIcBpMQ/BeBpveFpCeGYDh6ZCgUgPJwgwJ9ySMgc7Jn
AqF+BwEpkRcpZRiBZ/geb4FvbpKHd4h1DJAAgjiIhFiIhniIiJiIiriIjNiIhv9YADXkiJI4iZRY
iZZ4iZeILH+4iVAxARmAQ5wYiqXXNqJYiqknM6aYiqRHOqrYipnXZ2jmirIYZ6Q4i/MhAA2gAw3w
eUiBAD7QQgFniwPYS8KYFRTgQHpiABkQMKYoAAZYjEsxAQkAY1+BhRbSN7TRHeQigNKHALGohXNE
cIjhjQr3jL+XK0AleQqRjoORAV1Gew5QAd8IjUiBATqAEBNAhZxjPYGzOZajjwVRZW6RIBJwZddD
eIojkLpBLiwXKwAJAQzAMLFykIMzGhCAOBg5IhAZkWiXMBOgkGhnMuQCkAeBKzGGAVZ2AAtQAwVQ
AQoALbhxAT2gZOXVQUiGZB7/9DW6cwEk0JIvmQEFsAE5VnaKJYs0tivOWCsPgGMJgAIoUAAXIAMM
dmLqxQEWwAIkQDYVAAQQAGNV1zNDoiNYKCR7xwA2gyhzYpYcc30UVyhwwXH1JiASkjB3UzmewXBu
aSgYOCTF1h3/MZaWkZdwMRpzKQF1SEUeVkcikAA5wAArUJNUGZlZpAI/kAFHAAQCRmATQALEWCkQ
QD/sUQJAgAIkQGSSeZraBQI2QAAVMAKJOUgfUAFQBRkIwEI68EBUoWoF8GCo2Zu+STsh8AMeUEYD
hi3achYEkAC0ZgBeSRnv5CxaKZTU8poc4QAN8F454QBFowK/2Z3eOUQc0APv/0ePiEECFRCMGjEB
QEACkPmd7vmeWtQCBNCc5JkQJeAaV/YAFcCd8Nmf/tlIDdCZ9ck5DFA1KpAA6PWfCrqgcKQCFUCd
oTgBHhAC/KMCBZAA/OlFuvMCCvAFcHADLnAFrJVKYvAES0AECuAGVbACU8mgLmpE2iSKG3BLRGQB
QYkDtINISLAEqjWiPtpKT5AFVdCiL1qkt5MB4Wh7DqZHFgCURBAFPxqlW3UDDWCkVto1FUCftOdN
AtVFJvAFyuRMSeCha6VOBtACkzAJkOAIYdCmGSUDNlAIYSqlWfUEmsU/AtWlVzpbBoVQvDcBOYBf
RzQDaTCiJaACbbpRaIAHeP8wCI6qAhEACIlAp6sVA+25pwx6AQIKgQ/gAVqkACPqB1dgBGAABg0g
B3LQAD7gA8CyCJQ6ojdwAZhqpCtwUKkok0nEAktAWW0FBn51V06QBnaFV2uQVwPQB7/6qlplBEgg
qLPqniBga/SIKs7qQT9wA8qarSYVBXdApM8Kny3wWQPKEBhQADSARRBgB4WqrezKrWZAod+qoCCQ
AMw4rhwxAhUgRF2EAxfgBl+wBEkwp+zqSlGQBmQQA2dAA9Uar/AJAj+QAPNorysRAR6AR9c0AyzA
sBrLNRZQAUMQsRJrFPiaAffFRSZQAfC6sSqrAiSAAgsAsiFrJQgwmvZ1qbH/cwGyqrIvqgIAVgAj
8I4xWy+nMwQ6oABDwKI6C2G6kwC84zsQGrQvBQE+UBJ+dwBAUAAogBYktgIWsLBJa0y6s2IeoACy
uQARUJRQi3UTkFi2gjM6k7ZwqxHHErd060TSqKV1m7f1YgAJoLd+GxFXdzmI80AXGT0U8JCNYxCH
+7QTQYBZyBAJeBLcuI5flxEOiBtWt6l/O2ZXV2e3dmilwXJdF33FIbojgnCFN398ORcwsiHbQSCa
IWuqwX6dwSKe2yOEJyB/ESVv07ocQhDWmJbIQiOdARyIQncb0wAS0AD4lrrUsSQLOHARM7kEEXqb
O2DWu3rZe73fBXOAogAc/+gfpcFrB2A89Fco6YgbhFF5heIbZPEa6IFv3ZE2fUMWEIAAEAAWtyYB
Uogh+VsYCFeN51EotpG/ZMIA/ttrAiy+fGcb8RuHF2KdyHdvyjM67YsAsWY3nfFAO3i/DDwgtoEA
l4YeqQEaiiFpQCXCv+aGLyIYp5G/FlMoIPlymitu7nbDN1dzOawBURcARsdz48ZzPqwBPDd0PCwQ
47ZuATAFGgBvRXfE7dYB3LsR27srJQKz+WaOMFHFVsIEQAd0QjzFP8HFCtEduGk4bMgS88gctFsT
8/u0bJyBEUEWWCwRZCzGCXXHBTF2s6sWbRGXfnx3UJImlZfFwDtpBFIo9P+mhhSXciKjIHU4cIl3
JvU3d2TigJXcIeLYGc47JHw4OL3GEXqMx2tWw7Q3yqScyqq8yqzcykSBtx8Byx4hyx1ByxxhyxuB
yxqhyxnByxjhyxcBzBYhzBVBzBRhzBOBzBKhzBHBzBDhzA8BzQ0hzdN8EtTMENe8ENmsENucEN2M
EN98EOFsEONcEOVMEOc8EOksEOscAO38ztZsEvAsz/FMz/ZcEvOMz/Wsz/dMEvnsz/sM0P0sEv88
EgVN0AFt0AmN0APN0Pz80AIN0Qrd0CGxzgdd0QuN0RQNEhfN0Rnt0Rsdyx8t0iE9yyNdyyeN0iWt
0hLt0BH90hPd0hot0yD/TdMkbdMmjdMsDdMuHdM8PdM/XdNBfdNDndM6fcspjdQrnctJzdRL7dRH
DdVFvdMSCIZ52NFE3dNaDdQ+3dVbLdRezdUE4YdZd9VNvctPjdZp3ctnzdZr/csjTdY8QZGG18YK
QdcwQZIZCIp4fRCJsRhU/dVZLdaEDdaCbdRTrdRRrdYHQYZvKI6G8snecXxmoSC3e3efFhwIIBvb
xxvtC2oU8L6CIR6hwQBP0h21IX97w9mmTXgNICGCx9ks4tkFgJ4OUAA1srwD0doXwtl6x4egERoM
g36lfRANEDi0ERqgOBFm/dbB7NzD3NZwDd3FLN3PHdKO/busphoRoJak/zvBdPYa8/QynjG/KrId
FSIkexEg8/THS6LaQ8KBcLiXcxHCx+N1aRN9H+IfBsAcsEje6P24oFaOjcw5ZLHcEtHci+3WiS3V
YW3YhT3YEY7YDx4Acl11Ct7gjF3hFH7YgT3hHw7hIi7hAnHhUpfhHB7iHQ7iiq3hDO7i073gMW4Q
u/cAmmgRrR0REPDJD7HjH2HjRHjjd6LiKz7iRH7kLZ7iSe7hS87iDj7WDSEbZJEbEGeWQjKXm7Hb
hZLlUhIa3QFUo1sgPD4XoXFvCsLZkAImqJ3mZ54yLccjFALBZMEjnv0iCCgaKWMzJbPbY77m9KLm
KVM4fgmDVo457ztyAf+CMoBCFl7ehqBhgN4Ru32C5E/u5C+u5JVu5JS+4ZjO6YK9JiasMRCnIAlj
EKG+OIU8fQHAvMzxgyvXJHxGcuk93LeWObYmI6ObfcZRONPWhpdhHQ3Q6mrxOXZyGOmh64YcHAey
GkniuT8SuUqCkZDmECjO5Jle5CSe7di+7Zt+6dbu6fGBEwuTEY7rEOY3EuNOJ1oMFNVu6d6u6U0O
79fO7fGu7d0+41WNh/d+3TIe3dR9zNbt7/0u8DDO7zTOHhVTEapWxzOC4FrR7vIO7vZe7/Q+7/tO
8J3+7iNu4juRhsRxFl0YHHmZcBSCFgygGYVT6oZXFlfsHhA/8RYf8zL/L/EwT/MVb/MXX90IwfE6
kYaCohZtjJbaDSYlsnH27R9j3hgvf/Maz/T4/u1N7/QGn/FPH+E8DxnjmSk5D/D/vswBr/MDD/YF
j/FQX/UlbtVbn8xfr/Zd7/Vt38xrz/Zhz/WNjfYUn/ZuP/ZiT/VTX/Z97+5mX/NRj/cEMbfcHPd5
r/d0r/hyz/dkD/h/H/GDf/eUP/OTb/kJUYvajPhw//bPzPmfP/eN7/h77/ePL/mBL/WnL/gGASvR
DPqv7/mxL/qJb/qlD/mrr/q3j/qRz/q9r/sqWfu2v/ikT/zDP/q4v/u+n/uEH/q03/nP7/wwPi9J
uvmy7xBYrfvGn/zI/8/93c/7zF/5OC/+lz/+M5+U4Y/5v9/8s8/4wg/+yq/937/88c/+2A/797/U
AFP+/J/69g8QAQQOJDhQQEGECRUuJHiQ4UOIBR1GpLhwYkWMEjNubMjR40WPFUGGjDiS5EOTJy2q
FMmSYkqXGhU6qOAgJsyYBnOi3MkQ586fOYPe7KlwqMujLJOqXHqyKcmnIaN+LGq0asKpHE2OaNAz
68avGcNiHNvyqsyzOtMKLPtyrdq3bUu+ZUs3gFyIeHnS1euzYAIDVfuu5Gt3sNXCidcexmrYseLF
j+NKjpwYQYEJZxkj3Iy28mTIaTvD/VxaNOXToTWjXs13wQHQsU23lv+duvbV0aQpYjAgYkECAgoS
DJewYEEEA8mVL2f+wfjv4Qo8JJBwwMADsKxxaxfMvWjuCRk+ePdKHqh5oeiRGsYQgYSODSJy50QA
gYEOBiMczL+rfr3q7QDMiYIN6hLwO/+USpCpBaHqyYEFCJCgBLsqZOiBCBvA7rwDy+uQw9tiYmA8
3WibLcAQu/swvRQrGiGDBTKzcEaSRMgANgdXJErH/1oMyQECZOyIRwWJZNBIpxqUKiMMEhCBRiir
iqAAm8hSckkkc/RxIxEkIGxLFsHcUcweT0QQogeoDAABAghAyAACGBDogDgLIgABhOp8iAE3F3qA
AAgGkvHPQBU6oAD/gfgkqQAcCdJzoQkYoGCuLLEks8hLH6oAT78qpcpTra78NFMtEzIggYIQUAAB
BuQUiAADDp3TTQMUCCyAOxFiNAAIgjQU0QAKyJXNQnPFtdFcH4hAoF7nBFZWglp91csAGnCVgK54
VaDRgXbFFTNtNySogRE6JbVU28w8MyQEKnAL1OzgFUvUUOU1C6EuE1KVUwIKyBZaOscVllOCvO2W
2wCgNdhbYwlAFk9vI1g14WeBbQBYgeAkOGNj2UQ4WByNxXVjgvJtzN571fXwLQiUO+C5DQqQGQUF
avZA5gIYuOCHPC7w+eefLRB6aKIDSMHoAIhWegWgm/Z5BpwzqFmB/xxkrmCD51pOjkIQVe46XbBN
FFsgHwqN8my0AyDw5HMt9TrMB3pboIAmFOjXZ6FDAGBvvvv2+2/AAxd8cMILN/xwxBEX2oYLSCgg
BgUKGGKBD25Vse1R3x4zbFzFTfvzGRVgW/MyOYdogliHkLqAGWyAIXHYY5d9dtprt/32wUNo4YIN
PKj6OK4Rw7ze4eM9ce2CCrC7TQkdVWBZgoDsU1UCqhxIYoxzMrjgjxfafq2yRzd93cgeGKGGIzwg
YQUTcHf/ffjjl39++vfmoIUflC9gAcu/HhtF0h0pIZsqWPYS1ieHRaBPwYIAmwSyr4sJBEgPgBZB
FFglBnRFVYUKWP8AxCWBPg1MICAUyK6ANCmKBQBIhfLYm7qVrX4NJIIBmAABlvXBBUrQV+L73+Wc
IoEmeKAINNBb/Yx4RCQmUYlLHBwMepCAGGxAP1ZC2buKR8WFfMBVMrsetgbisBHqyYFrmliwwJjC
gvSKZGNcEwJRqCgzyogBwNrVA54nKA/eMQASQxibMlNDYIlsjgOpEgHeuMDX7OWKWFxIe2qQgwqw
AAdMpGQlLXlJTB6RAzIgAQpuRDD+hJJe84pIk0gGOlRy5AEJ8Jy5AsigEiwABQVYAQgyeUtc5lKX
u7ydCoqAggREQEhhemWS2vaBDKAwlcs0SgXMxsjxkaQEQBDiJHn/eU1sZlOb2wwcB1aQgQqUy23R
9J8P2ZWADZySmRZygA8qoEx09ZAiCOjdCrh5T3zmU5/aVAEDjjCCYQqvmPE0J318oAMSkGidLjFA
A3TQgP6taQMJUCcpyWQAmVlgnxvlaEc9eksQXMADC8DAkBaZMnmuLGO/EQ7/rAc63hxgAzHYHwWG
+ZQJ0OkAAVXkiXrVAw58VKhDJWpRk6iCAmyglQUFYErLSRKXPec5DZCqcayTHJ4SVCvorGh/+FKC
CpDAlkYla1nNelbctcAD3RPgQDNHTmLCNSQYWEAGRJCZzTggAT8IKlr9+lfABrZwMAgnptxKvMMi
Vq7rwSgDgieV/wy8TrCTpWxlKcuBBgAhq3kZJTSdGtfPbo4gdAUURDCwAXtaVrWrZa1fQVAAhXK2
irI9qRUTa7yIUCCsD0hT+1r7W+AGt6h7WEBPF9vW4yI3tKWDSAJa0LcQzIAAqRVuda17XWxyADA8
bGp3vctU8JKvkRnwreFkQIA8FBG762Vve404gyeV6LsqTa4xa0uphVRAsrYLQRE8IAOygsACTDPD
C2pGBATfQMEuYHCDHfxgFzxBwVxAcBYUgIQXzOACFlCBez384b4VIDCivC9tb2tRMznAA32tHw08
MAP13tICctCBFpYAhiAMQMc75nGPffxjIAdZyECOgh7IEIMX2P8gxiBm8mRZ4KoSu7K+WhXv/1Cw
5CWaIA8ZAPD8OMACJNwhCUMmc5nNfGY0/xgKN/BCFcrbZDgbtQjPnO9Tq1xnO9P3AxvA5gpePFbE
maAMd4hCmg19aEQnWshpQIII4vzojqogAydG6XINO2W3RYAB+jTBBjKgUb6BoAxLyLGiTX1qVCua
D1oYAaRdvU0cNAHTirW0cvFMTAV49ANkuMIA0lCHG/Ta1H5IdAkekWpkJzoJZmDxq52dyQsU99bM
nTa1w6vSo+3zBS4gsxiI8AZuo7nUPo6EDHBgAhNAQt2OcEQY6HCIRCRb3oomAqjrh7Rn57tvSKu2
ra+dZ4DjOp//MiCDooPw6xuMu8yUaMEk2h0GNkScDWoIQwQCYYR5ZzzRYtiCvj2OxGjXmsr0FfnI
uwaBInCTAzFQuMZ9TAkZqEHmaKA5GvCABzQIwAaAwLjLfZ7mG1zg40OPXwhQMGvcIj3pJR8nyrep
gJb/fAAPcEDVMXB1rGNdAIUoBLGl/vUyL6EHRCc7f4+udM/22993LqiKm61LHHwB7Do+AAQiUDkE
UN0BV987BugAiEXMXfBCTsIZyn742LHAClH+EqUrrXb7pioD2DzDmAd/ecwb+gvWRHznBycDAzKd
1pA3OWjrPAEPYDmTNIAD2IXghDFIYcevp8IAXq8A2Q+gD7HP/7zgo+AGzwc/cA0IFIkdb1u0p/3f
AilBBt6eyRbcQepCiIMUGkGF169hDrXP/gAYYYjd5773P+fD5IV//r2toAYmPb6Jk//45Yv2IRgg
7y53HfXx51/jYGA2+s8PX+6Kv0sTvdETwAGkCAJ5PkyCADLAP/17wEMDgxcANP/rvBbYgM0yEMYT
qPdDPgJcuo24jA7bJQjQAj6AQBQcsiC4gRdQvQokuxlYPA8kvbf6QBTrQPxyCREoAArMJRUwAy2w
vBTMPCNYAiRgAQV8QbKjgQpYqhzEQeOyQeVjOypkCQoggOfSJhrIgC+4gUIbwlMLgiSAg4d6MyX0
PBBggBooqf/Ig0Ipk0L4q8KAu4kRmK59goELMLA34AI9CLfxgwIwuIE78AIkqIIVcMEzDL4QmKiX
sjY5lD8arMFILMAqc4Ah0K/KAoH6S0ROpB0OECnoccM3NMC1I7lJBMH4Iy0kLCsYKIAk7ERY/BsV
iJn+Mb72i8JTvEE4nEFSLAi6EiIzvCcWmIFYLMa/WQEC2ICICsBHhMRmdERT7MXSc0aSwIADOIIN
yEJdYgAaMMZODIEeQIEhyApbFEUO3MUnREf3U0eUwAAIyAACuIBg9LIM4DxvDD4aYAAUqIHBKEd2
bDxzPMdcnMJofMQPAIIjyIAfGMHZwYEK6MF7fDYQWAEGyAH/J9kQfxzIOJxDaOTIA5TGcYJDBDiA
DEABEiAiv5EBPovIOHOiCsiBGogANkxHjeTFZyxFj8RJ0wNJSeRJipCA+LoL80Ef9bEBe2TJv7qf
C9Af/rlJnaTGgszJNvxHgKRKgfRJSEmAkXgKB6CA30CBqrkAc0NKS+IAC2ABElgdIIAAmMhIrNTF
mlzHuJTLtyRIqZxGikiTRmS/00CdEViADagABZilItgweztDHBiwC0gAwZyl4jCAx9pJp5zKucTF
ycTLj7zMkKzMUcyIU6HJunwIBFAOqjKOBMCZHJiafpEZEvgZG1Aa2DzMv0GabAscE4hNopGBn4Ea
mZGampkl/5mZHOPQGsjsSMmMyrvczNAETc3syeakROQ8zod4GbuUTuuEyuR0zujEzus0Tu70TvDM
zO0Mz6ckT4HYAHjayOyEzvVExed0z/EUz/aEy/ekz/qszu80T7zEgCbEzPKUz+4E0PwUUP1UzvtU
zwH9TwWlzOVkTuQUgATIQPwsUO2czwklUAxdUP9k0AN1UAtF0ATl0Pj0NwjwgQ+1yREV0RP10ADV
UANN0Q190RWlyw5l0RBFF3JpUBqFURltURX10Rjt0RsV0gz90QSlk+FIUiVdUiY9zSZ9UiiN0iUt
ACmtUitNUiq9Ui2FUiotgArI0i0NUzANUzJ1Ui09I/YEUv8iLdIgrVA1ddMhTdM4ldOBMI6FulM8
zVOFsFM4pVA6ZdM1ddE+BdRBNVI/hU+E4FOG6KA5sZUSapOXUiBjEZbqsaA26aqQqCCCYCOI4FQL
EZmK8NSY+B6WUFREfdM/FdRUNVRCXdU2PdU5hdU6lbZFzSEywg4ukhUgsYlJRRRdrVRQPaADGFYS
ApmDkaADuJiJ0VQwGiNsGVadwpVQFNUAiJU56pMKkhloHSQVSlblIRl/cRSIYZRhHSROjSBnDUVc
CZRmkVZhJVY3YVRjTZ6QIZhg3VNaldVW1VdV5VdW7Vf75FFXDdR/NVVDYZ44gSdpSZRQNJaFDQAG
aNhTukL/5nmjRmEA2KBYQMmVA8igNikATmGjBmAeKOOTflEghAChk8VWKDugj7UJjVWjlGUeBeIU
OnnZNuqVNoEeNlLZR3mV7NFYQxIISXUYjEWIox2ZL8LUWSXYV/XXpw3YGbXMGt1RVIXaQDVYPd3a
t8gpjoiVZYwSrQXRQ5XaqzXbWEXbsr3Qf21b/xxbro1buZ0RuLXRtSVbgjiBExjYQnVbp/3bvgVc
vk3VupVbNFWIe10nak2lwyWJwqVagYXOE9CAHSiIDugAHhAILNAADbjcDtjbE/hczf1cAeCBy50C
0VWCDuDcDmCChOiCy22Dy+0Cqz1btvXbwM1d3SXcfM0T/zxhI2eNqAqiE5wRllcJ2QWSFVUp3olZ
mJBpFAO41m053lRJXozxlugVlukFXmzFGOWNHJxp3u7hVAlAlAmCWGpxlP4BI03dldWUGfbNninR
Xn7BEU3toMQtiMftzKqF3MmtXIJYXR7ggc6l3QDYAQ0A3QQWCAQ+gdLt3IHY3CkY4AFug4KYXM+9
XA2YAsidWv6NXKwd3BDmXYZgAOx4AChD4YGgAGHZFQjIFgkyWRNOlA1RYWaBYZUtABQiPhliIWHB
jpHVYR6G2FayYV6B4SEOYgrgYSO24RceiCcOo37ZYToTCBS+jDjxnGJNCBbul0Y5FEmFYV5pYRyJ
Yg/iE/8GYJUNweINGdksHogZfoj9rUrOpOOKsGCBMF0NUAI77t8P9uA+BuHbjVq2neO5PeR52suI
mAAnBB1DZkZBHmTBHWFKVtt9tWTcFWFMfmRE7mRP5ghO9oyAhGRAvko/DuRSJuW0leRCDeWIgJMr
VGSFQABZXhOmRYCNcQBaRogHyAwu2tRbruUH2OWC6OWByLtiJuZZBle2suWEaNyHKF95zQlXli8d
7WDbxVuAZWVN5mZMzmR+rWaGEBZo9SLfbaNjttUzXk11DlaEbRPYaF+M6eIWpl7uTYgg/lY0MiOE
dZV8LqNj7RY6+hhSbZiL9RIJaNkvwtgDACF1dQlx9qr/DTTlSNZmcP5mQrboScborO1dksipRqSg
gNopGmoUry0IB0hoYeoeBzgUCbiVByjfl84YOjuUwGgoiDIADvojk+4e+wgUktZpgsgpfwnFn06Y
rLKPBlDXllEIpYYekhYIa5ERNtnLWEEICmhmj4hotzxlik5lzugsb+bobtbojv5ktE7rUvVos97d
Sh5ruG7rskZRsOZLq1RlgjiVMh2OCtjrMu1rvw5TwA5sLR1swrZSwz5sKU3sKg1bus7mx15luX7r
ySbrua5dyY7su9XsS45rzt7myvZsu+3s0C7tz75o0cbmzB5t0D7tjHbtjU5t1d5s1kZt067t18bt
2IZt/7e2bMrm7cvGbNoWbtIG7t/W7d6W7T+GbOQ+buJu7eZ27tku7uj2betWblRm7ue2beO+bo2O
CvAe2PDG2vHm6PKW5PM26/SG7fXW7fbebg1Eb/Geb/Kmb/mub/w2b/u+b/3Ob/7+b/Xe7wD37wHv
bwMHcPcWcPZW8AQn8AV38AY/8AJH8AincPiWaAufbruu8AeX8A7P8OXG67CG8At/bw235hOP7wlf
8Q9ncQ5vcRh/8bwQgIOg8Rqn8bvAcRvP8RvvcR7/8R0Pch0fch8X8iInciBHciNP8iNvciZ/8iWP
ciWfcieX8iqncijHcivP8ivvci7/8i0Pcy0fcy8X8/8yJ3MwR3MzT/Mzb3M2f/M1j3M1n3M3l/M6
p3M4n3MMd/ESZ/A+J/EU3/MY/3MPl3FCB/HsFnFRHvRAN/EQH3GMdvREh3RE/2pLV/QNP3Q+b3Q/
53RAf/RFN3RPL3RNZ3RQz/RTR/FUV3FTn/RQL3VRX3VBj3VXR3VZl/RLp/RNv/VO5/VPr3VVB/ZZ
h3ViH/VKx/Rgz/VXN/ZdF/ZhZ/ZWV3Zbd3ZcR3ZWp3VpT3Zrf3Zq7/Vu//Vsv/Zi93VSh3Zs3/Zq
1/VoR3dvD3du//Zyh/djV/dzp/dxl/dmd/d0X3Zyn3d+x/d1t3dzv3d9b3eB7/d8Z3dwV/h4B/h6
//f/gl/4g3d4gmd4f5/2iG94i0/4ic/4i9f2jt/4gId4kX94jC/5ig95lSf5lT/5lgd5lo95l5d5
cR94m0f4kZ95nYf5na95nDd5ng96n6f4myf6n095mh96j//u/qjxpn96p496qJ96qa96qr96q896
rN96re96rv96rw97sB97sS97sj97s097tF97rw+OqXl7uI97uZ97uq97u797vM97vd97vu97v/97
wK97N1F7wmd7wy98xJ/6d1/6nBf6xUf5omd8oFd6yBcdtb58zMcIy4f8o4/8l6f8z3/80N/3nhf9
pDf90id9x1f9mt/8zH992C8I1z991kf91Zd42jf4/9HX/dzH/dTv9NmPfeHH/OC/fd83/o8H/d7X
eM43eueXfKRH9eIffur35Om3feX//ePHfu6vfe/nfe1n/t3f/me//o1IE5xpgCq5mPQMgPIFYpnp
iovBmYd2CU0diPtf1NCLknuFo4QAiAMFAhAsaDAAAQYHFzJs6FCBQwEOJ0qc2LCixYUYMxrcyJGg
R44hRX48ODLjSYspKZbs2LLgyogvQc4MEPNizZsMdWrM6XNmSog1GSJQgICgAwIRAhQgQMCAQYEE
jjIdWLVgAwJDJwpk2PXj161iF059GXasWKE7f77kaZJtS7cw4ZaUOxco3Y92aeLt2zYvSb9xAaMk
HP9ALdqiVA0ogFqggAECDghG0Fr2KuYADKwaLMDAwYMCDQgSKEABQdbJqB8EyErwQGkECBhoDfBV
wlMHDaziPg2bc8EDBxw48Pw69oOkEgJQUBpgdevaBglAIC35ee3Sp1Pbtgo7AgIDFGwTaICg+eiD
BQ4EqDzewAS0BhG/FVzXMEv7gf/q3z+4f2EAqoSfTALmxx+C/yV4X0P0iVXUYwVUR9Bj7WkVGWlU
VchUaaKxdtBvEWZHFUJURfAYAUZ11xl7XUEYoVEISLfiQlI59RpnTYlo1YlNqWgQhhA0AIFCBSxV
YkFluTgjjsEBRyF7xREwnHzzFbigXgTiZOCWWPr/x6CXAYY5IJddKngmmGhmWeZaAjq4lWILbSjV
h5dtuGFDlcV30GVIrkcQY0fBVlCgKyY1nkGHFoRnklTh1iRBu8nJXgCFHsTAowhBwFmfSg6U1JFO
iqoepYuWKt+bfI15oJpfrhmXABLFKmusNtU6q6206porr7j6eiuwu/4qbLC9FjusscQqmyyzyDp7
LLTLPitttM1WO6211GqbLbfYenutAKnWFNqHBjWQXgASQEUQA6ztJlpr6DbkAG0JfdhuQfg+QBsD
s7EmZGXlFSRkQbhph5VTEBB8EAVNmadQAAsD2pTAAeybkL8LFYeoAQWUiy+7/6IrFWQRoysxVtU1
/1zaqah2C+6238YM88szU2uTlm2uemWrYvZM5s5mpjn0qz+zSrSrBYlbJdNNO/001FEzLe5eOLPZ
09X1Gc0z0j53DfTWQhf99dFjm52012enjfZhUrv9Ntxxy10l1TljHbTOYd+t995kc6022H6LzXbZ
hP9t+OBrKx64lXM7/jjkkUtdd9YuVX4X3lrzrbngeXfeN+CFLy4644h7Hvrho6fetuStu/467A2u
Tjrts9ueeO2453666aD3zjnqut/Ou+rCG0986YsvPZGMTvdZ0lnQP1ll8wdVH7tDe4rV1GQlUZ45
8L9bDj7mm49vfvmfh1888rv7zv77ycvv/vryL/9fkAMIlHs9QQ9or/9B8leugiBgMs+zyAMEBZwE
MiR/UQFO/rpnkQgG8Cj8I0j1CjgTAGqMRPjT4EH81z8QkqZlDNTYAAu2HiZZ5HvoU9ULrUY+GKrv
fDVMX/DaN7z40c+GOeThDuvXQxyy7X62weBTsHOc0UyAMeOZwJ+OiB2oMOZIDVARvAKQlHXlqwDx
iYxVGAAxCNQGNhMi42S+spn4QFEhmWJKi64jI6jA5ihSWkhRGBAfCihgKVncIogu4xrynPE6sFFN
EmHDxAcciYxJKlXFZMSePE5Ae4SqTRY54sIb0vCHQgwiEeH3yeMBkZSj1KEpfSi+UM4PlKwcYif/
i8gR2JRmSkqkEYec4hSI0bIp7IlihkjjmAkRcEYuUoAunaJAFq2If3HCVLoglkynsKdPF7wlQSRg
lSRKiCwetOVZ/jRNcAInK4/5kS1xSR5skoUBwsFNqFroyliKUpX1fGUq8ZlPerZynzKMYdUCardT
lhKVBi1o/O73laRMsoyceeOoGJou6UDgRw8ggATklSRiloY0xAzOddqjANZ8JZ24pI50MrkodA3S
IEU5UlImdNGMMkSMl0xjSCMwUqZoFJdR1ClV0skYLjJgNNekkLwYk0LZ+VOgl+MnLGWFM6lSdapW
rSpWr6rVrHJ1q17tKli/KtawknWsZi0rWs+q/9a0snWtbm0rXM1qxAhgygEQgMoEKGWAj+ZVNKGi
qwTsui4HaLM6B9CeNh1C1wY8YK8FocBuqNSdBzSAAaFyLKC0KVkkStBi2lQXoSpLgbwuJK8TKOxB
EjsvgYAWR5S1rEEe8Nl1YZYgRDKs9iq7pwhUlpikXYgBWsYc4TIEInE97luTi9zlWs2pM4TqPP/J
Sel60p79PChBs2tdWFJXltgziCPlE72POCAyXIxaeFsy3u++ZJPV1Sd2tztP5wJ0oPJtqn3hi1Dt
6pe/0MWvm9gr4AET2GUAfm537/nf/d43vv1tMIMfLOEFR5jC/k3wdSuMYe4GpcAe/jCIHxJd+v9O
l8SrtDCEL2ziE294xPlF8YRbfOD6MjXENr7xgN3L4hUrWMYa5nGGVfxiH/94yEDmsJENY0Qct2Rj
W2lY9+DT5BsxOWo67vGRXYzgLM+4xEl+KpGFDGYuO5ifS67yR0h0lODG8yDBPcCHjjIBnYLnOYla
qqYqi+anXTnIKf5zjPdC5iKP+ctbNjSND13oGu95LGUpyoQGlVovEiQ+GfyRTS0WUnNJk7iNHkqf
kbzo5w5azIo+daJT7eVRq7pxnxbLo6VzzQNemkTOcc5BdBqhAjTm1WgJtZZRzclSAxrGxg5zsZEd
aESvWtjvNbOvYW1BWbNwN3tCJFKSmG1ohrD/1wNjYbRbAuwuP1vZxpZZzdKN7nXTjN02U3e74/1u
d8N73vKuN77p/a0zh9t6BHRpQxBwAC56EAKhkgDEQrjUB+C53xkx7r31HfGJ27vitjI3xom9bFY3
u9U7Zna5O+xw2E0AstMbudPGXeaMgxzLLXc5x0P+cj9v3NneRTnOc660YHsc5j2n+bE1HvSZi9rm
Pv85v3Wu9BurnNBGB7rQWR7zj0/96B2/uswZvfStv7rppv55VInOc6xT/elFB/vYAdcYA7C97W5/
O9zjLve5073udr873vOu973zve9+/3vcvZ7sqAud8GInd9nRjnirZ93saU98QTaAqMUDXeqO/6f8
2cleecNXffOHXznnLw/6zzsdTRPYNOYfz3jIN17xZQ6960uvec93PvOtn73tE/+ADFgy9b4ffe1V
T3tSk/7ruBd+7lev/OHH3viN/0DCmX/838v+9tY/MXOzr9zta7/73P++98MP/vGLv/zkP7/5ZbWA
0aQf/e5vP/zfL//4p9XyzR988fEffOo7n/X+Xz5LMMAH3F/NEeDQ7R/wER8CVt//Sd/1ASDyRSD/
6R+CGUAFlIDoMSAETmABTt/r5V8HPqADNmDyjeAGJqABmpsDeEDvkaAEoqAHaqAJQh0IHmAG9t8J
ymAJ7uAL6qArGUACwF4M4uAM8iAHnlsN2v/fEFJgCgqhCBohDD7hQojAcjihCx6hEkohFgpaElph
DhIhFPrgFnZh8ZHAkXhhEfYgGKohEw4bGS7gGo4hHLahFkbhFR5UBZAIGoZhHNrhF9Ih9r3hDQLi
H4bgHYqhH6ah7zlABmAAISpiIvLhI0qiIUIiIl5iH2LiJLJhJVpiJq4hAlSAJnYiJdpgEwpiXVBc
vqmixFlcK66iK7KiLMYiLcKiLb4iLs7iLcYKBGyALuZiLQLjLgbjLxYjMR6jtWThIX7iJsrhIJIi
J5riErKSD3xUM0ZiNCpjIUpjHTIjNDrjKc7hN2IjOE4jPRVASuxhNqpjOXajf7EjOcbjKHL/4zJe
4zxqoyf6EAZkQGfdIzz6Iyqao7n9ozfS4zbiYyki5DoG5NiE4kESpD0WpEK240MyZD2OI0CKo0Hm
I0ZqTgSQwEVuZEJCZEdGZLGRpEgupEZOpDxKJEqy5N1IgAi4o0mWpE2mJEUq2EvupEVW5Ery5E8S
hOQJJFA+I062ZE3CpEv2JEceZUYapVImpU2cXj82ZVTe5FU65VI+VVGGI1R2JVEyZUJGQAW0oFWC
JU1iJVoWBv3Nn1rdFQSIQAMsQAIkQAXYJV7epV7iZQKs3wHApVu2pWAGJmEOpmEW5lZ9wEAcJmMi
ZmM+pmNGZlZl5USWgAGsXwLEgA4UgAQM/1zDjUV5icAC+EgCkMACfMBNrKVPfqVYutICLIBqnmVr
5mRTdiUFaFMMbMACnJeACcABMIAOVIAPfID2xOZIziZSlqQAUqZxqiRrBuVzlsQEjEAF6IAZOuKr
TcAHNIAHZAAEYGdYQmd0eiXfTMAFaqVUNidtHidXHh4GiEAGFMAImCXKRcAGEMACVOVTkmd4jmfn
JEVxIud+9id/piVzNgRlecABgCfXldYIJARvqqWAbqV/Bg8QUmiBhuSBiucLwR4GLAB1NOhMfEAG
BFZ6TuiJcqjfUOGAGuiGVqiGFl6SYQAJNIB+imhLfGgCTIZ6Jid6SmjtmaGPvmiGrmaR0v8gmJHA
Btwojg4FBjRAAtAne8KokRLoQeThejrnkU7plk5gCZRMk0ZNKMpFj7ZojLYcIzIohlqpi5bpmoqE
MeYKAhSAmsoHBEyeQ9RWQ8CZV3zmwujpTAzJQtzpREzABogAMgqjosbpoiYqoxqjAGTAozoqpQ6j
pTbqpU5qphLjRD5AAsSZAvTRQZjTa4Qqnh5Q1JiURaxXTQDTSxhqhJpplbZpQEKAD8zqmaooreoq
BL6mSylAc3DRb34FbEARuqCqO7FLLXmQbUAMplAMp8hGiigTkkhJUywHjfwmdiTTUsypU3gMEu2S
q7ILpaBUivTUR8omr+KqkVZjrlKpusL/K5eKIFVaj1FExmScSLbWhmqh6p+QUazSSCZF0WWY1POU
l6dAim0RQHykF4ZUxnQIF8GGCqruI5O6aYrKa7BhaWCkQEF4bLx2aZaOrI/yWL3a61G4h0Mdx2NN
hb+Wim4AK4hYBTARbFBB0lFkGpIQa45gqzqx7CNNSjAN7UGcrKyGLJsuY2Ox3WtKgA5IwGtGbdTu
WoRUQIQEgMdSLdXWwGvOpdRGrQi0HbMSadKyK9I+G48lQKzGCXl0D7HOyOn9CDMdQAMcgATI7ANB
iakMLW0cFpJkhd3SxjKtiE7VrXBARd/SLaX4kkCMKxwRLar2D7iR7a5qbOKERwS85mPk/0CoKsCu
/cAFhK4MWADphgAAnC7qpq7qri7rAgDWBoDremzrzi7tAgAIkK4FyEDoXkARiEjnosBjvOYIAGrl
iuyQouSKjUBPhanr+OrRzmvxLoRlam4BoIAC5MBjgO4KWAAM1K73fi/4hq/4ji/5qkDuhm4C+Ijn
FgAQLMDwTgDGAqnlfmB/LCfzYo9DPq+WLiEGGIDy2qUCeEABzEAPWAAOkC8CJ7ACLzADNzDqcoAF
0MAFbACvAW/7GsDYUu67Gm+FrZgHMOn9Qs6bxO+PSqMBiAAQVIACVAADXAANWIADx7AMzzAN1/D3
moAF9MAPVK8O9OUHfKb+kmwQM6Dahv9w7FzU8aKofpXXAmzAEXjuD9CACtgwFVexFV/xFd/uBdBG
DHDmCDArCWvwNnofA8xkCMmGbOBRBp/Qc+AZBzlNsi5EHHPEHMfNBySAZOYxZFbVB4yAE3vABlxA
C5guFheyIR8yItcwDNhADahwAjSAAeyxHk/yYSrjBOhA7+FJw3BKQgRSbRSFqmpGRz2N4z7uR5Sy
1BAAnoWxxpUABCTAEXgACayACSSyLd8yLudyA1vABfBaAeymWbKyEmsj9KnHk0gKQvwmupzIpUVG
qJzLemWFNslReZwTtpLRuSjA4r4Lrx3JT5UHbSCKrumIcNEGwmkbRo3yY+CGVWDzFQn/l0wK8ZsW
xANAwBCgAAEUAQ0Qsi73sz//M0B/Lwz0QGZWwAJQgDCvawkW86I8iaTZ0p9gSK0BkraOl2egcWJd
jzMJCSb57ANgURyhMcSmlylX0G9uE8UeABoDEwJwdGqZcRJDJwZEQA3kQAWwwAEHtE7vNE/3dOpy
gAyQAApkgEpvcNki6ao8QAVgJ6PIyJGk05RQMwapSGRImkX3lEZnx5FALFP4LL4+rqRFxYyEsox0
DzJ3SpshxFZLxwQEIfTWowBIQBN4wAy0gE/fNV7nNU+bgA1sQG6OQFUmtFFyWTzzWjJ9VDoB0i2x
LVf/rLKiCGtk9WNzJia9i1N8SBTd/y2KTMgVPcZmCNe3isY2kYi1NsVkZ8qFnm0DYoAf5wADrAAI
6LVszzZtB7QK/EAGHIEEIIBgGyCZTQAD4KkRP41S12lMo5oB1DQD0AAH1LZzPzd09zMOXEB3QgAI
ZywHRyQGGMlwO40FAvE8K9gELEAFEEAP8HN0p7d6rzcitwADoAAQYKA8Y7eBNrFxd7d0NsCtzm9B
YQAENAEB2EBsszeBF7iBYzEMkEAO1IAH9bYbjpkDbEAD3Dd+M8R4F0AJOLhBkGWAD/iBfziIhzgN
JzgKnOYwZyWmYssdZ0DAVjgCJMAGRICmpnjEfcAGeMB5i7iO7ziPOzANFEAGwGal0v/4kEOLBlMA
C2cw81JWiA7xjwFhBshAj085lVc5+ZoACSgohYtxbYqdAWxABXwnjk6nXQ7gA5BABQg3l/dQxxQA
DFs5nMe5nM8uCFD3AtSphpstQ9CVB/iAmvuaAPgAASTAfOYpC3+Ierb5m885oze6o9e5B9x5Ca/5
fM/FTJNAD+8mjvnmBugAAwC2spERCWx5TmLABRCAlDu6qq+6o4dAA3jniXOhQl9mAniAApTmaVbN
g1AAZmpmX45WU30oAYyAlRpABjQAerO6si97nMsAAVwAqdM32sZ6Y4lm+nZuXfbl12571GZ7DITq
XUKtAWQ4opXAZrT4pFfEg9IAs7f/u7vPeQgwwI7q+XzFur0zBJIzlo9OwKt377v/O8BbOQf8QAWk
4zDnOb0LzwTAp6Sj5wFkwBQHvMRPPJUTvHxLeyAq9Ft/IWFlgIznzIPaNcWPPMnvOAiQQAKAJwlL
MstTcmT6ccF3nwNUgA2UvM3fvIiHAGe6fPtReqWnO1uQqA9cd4JtSrLjPNIn/XrbQAUQvZNjfMIf
t5rk1ZTQp0dMAAmwgNJvPdeztwmgY3bLb9iLPdk4gA9kwACOT3GIfNe3vds7NwdsgDXur1FHr933
jgDA+FFIRGjU8tv/PeDP9h4sQNSHt2oXvn9FgA54gAEEvuM/Pl4P/sZPPuXT/Sph/0AFHHCdEwAL
NDfkfz7o67KgSv3dIz7U+9kF9ADrmkAeZADbhz7sx34Vh0AFLBXy3jt/Z6IAFIDn064FVMAG5LTs
Dz/xM7B9Gr7lmz7Z51ANrAD5rgBde3jxTz/10y4HZMDFI++Mb3+Rd/+mcguJSj/5gsAPeEDN8zju
7u4LrD/7t7/7v0AVhO72WoDfV7/9VzELMID3S5zPk37pA0QAgQMJBhBQsOCHDQAYNnT4EGJEExsy
WIh4EWNGjRsz4qBx4UWMGES43EjiYkBKlStZtnS5EoqLNDeIaFGwpUoPCxw49vT5E2hQoUOJFjV6
FGlSpRlVZDCIECrCg1GpPq0Kdf/qValasXLd6pVgVrBWx5IdKxYsWq9qBx74sfRhiwwMTMBNqoJF
GQVEbrgI8hJwYMGDWUZ5wiWLGzkyQNh1/BhyZMmTKUsOQYBCWYFstXKu6vmzZrNpRYOmajoq6q6a
VX9FaIVFZRYeLjSuDNGCHB1E9Bgh/Bt4cMIuuHh5YSPEbeXLmTd3/twhBw8OWJeufr1s64Law1rH
ftZ7dqgiZjAHMYPACsotzni54Vt4fPnzX4Ihg6RHcuj7+ff3/5+hEDyYQLzv1goPPAMPVJAr7gZy
cDMEBVJoPxU2KMAipThgAYkloKAPxBBFVOmJLKqoC8AUVVyRxaGaKhBG0hjsTML/BWOU8UYbExxo
ghx48k8GAvLQT6gWtlgCvhGVXJK+EhuwrcUopZwSwAsW2BFLHXHMUssuG6zxyxmvQqsG9VTckLYf
NeLAhy/AYBLOOOm7YoktYKASzzz1nMyDB7b8M8wcA+VyUEAL9ZLG70ogYMoQivBAhosO0CIKOS29
VL4bMkBxz049/dQnGoYwNFFCSzV1TDBPJTVVMUMbaIEe9FShgAJUAMAEIt7ElNdef7uCiz1AHZbY
YmMg8NBkUz2I2aeafdbZaKGdVtpqqb3W2myx3Vbbbrn91ttwn80BSj0tsMMLJH1dl13A0jhDzWLl
nbfFGiAAF19xsx0N0VYFXbXf/1f/9XdHDHIAIIBZ3/grpSBuqCMNhufzI7BHkngkkowzpoDjCChu
F9MkzqAsYYZKphfllB8KoIcrlSU44NNUhTnm1GYWGFWBUwhgZzxB2OLDl4yA44sk4KTggxZkoIGO
ppse4ZBAQPZ1iQMk4xlrlbVWGeudAX5ZZlfDHhhnVsuueTUYd+55ShGWAM6FN4gQQ8QPcAjAkkkg
ccSRMPyGIJAkp8YUCjvihavrk7denNjEv378bLDHznlysytH27UdHUAB4SlfQEm+J+pY4or4IqHA
Eb399psNNsL44JBEBmeXiAztOllxxnXvNAAWJMB8O7FtFj5tyocn+3LJjw8ghv/DV9yC7hCveDiN
3yRBHZIwWmdDje7VsMAGQD6e3VcyIt0d/fR/mkEE4LtDfnnL43f/wZuThxxnCWKL0gyjmYQCDnAI
jCQM4DfvqQENCcSDIz4ACESQr11auJX6KFhBiOQAA/SLEPyKJ78OapBfyvugCDOHgAxESQZkmJok
YJBABeIBhngYRBgEUIhCjA+CvRLDFizYwwrKYAMezBwIIRRC/N2PZiQMHvGGmIAWtMgNlWoXJRyA
AStakQMgMIEKYACDEigCEILLYa/gQAMfnnF3FdBOESHERvvNT4nv4+AQiViQzbEIBDEAGRVL4IAq
PuABJXhAFasYAUDIbozsSkP/edDYSJXZAAjGG+GYBMCsShrkkpW05CYxyUlNdhKUnxRlJknpyVKG
8pSjNOUqUclKVbYSlq+UZSppKQARAGFFFiBCuxCAAT8SEgEIKMEwBymAQBQike1ywQsc2cx5CWgC
s3RlLWNJzUy+cZJJPCIct5nNyH0NNioKgRfaFQUfNACdPpDAAiAQAQoIYJg2CITEktkrPcjBmfkE
lXSoI0k6dvOfAF3iHAfqz4IK8aAD2cD5AISEoJHPDxE1wkRxWM9eccFM+tRonjKAACYmVKByNKhI
EUrSOn7UpAMpU4pWwAWLvpRdUEDCRmk6JQ5kIALYDOg3tdlTnv4UiUDlpk+D/+qWFGWADzBVKqbu
8MSaPlWcBMCAG1G6QYKmNKT1q6pVR6pV5BmgAADiABLEaCkhOEELhlBJI7RAhQGcVQuESEkfxiCF
pTJpCfuD6l77Y4ECcLWkXg0sYE96VcEO1ohEHSqPKjDB/oy1rHESQhzOuoYBNIIKc3BrZTU7ALra
9a4jyitfSbsfBuSUsHE8rGpTm9XWKtabQZXtYmcrEPIAqApP4NVkpXDWNNS1s5V9axxcUNfQhigI
X+BUaZl7GxNkIIOrZW1ia7tTocaWttnF7natW90ATCABtuOPChZ2Kd561rjBdYJlU8II4x53PiJr
7nxvk4DMgNS11NVud/eLX//Y8pe7/r0ugAlSggqUaz8QcCl8GfwSMbwAwfSVMFwg2V+s/rc7+dKw
vjbcYQ5/2MMhBvGIDyKCDTjvOXvgAj0bfFw+EGG5E5ZxUlqwAQOQGMcibpZ+LSzd/FLVsK8dsIBl
RoET/+cDb4hsi+v5hDKgeMZRLtIGkOXdCw/Zxxi+spWzjOUuc1nIYCYLWGMMHRCYYcVMrqcL7BAB
Kb/ZKCxgQJW9HOYe8zjAW74znglM5D0DOUsPKMCd/oODDHBhyWruVRKysAA4P1ooHCBB+xAL6MJ2
1c55/vKfdernEU6AAYz8DwgaoAX/KRpTRqiTUyHd6p405cZB5rOnaV1rPWv/OtN9vrWuN41r6hog
A479jwrMYGpUL0nVSGABlF3d7IfMYM6WvvS0qT1daVu703qeQA0SQCQAmcAKOoBDUo8NnCukIQtl
MKOz2Z2RFRAgK9f+8VZnvWtb95rXub63vu1tbwwkgAQRLvQF3PCFG0ix3AMIQhLgEIMz0IDZ7W53
CwiA2n7je9/15jfGL75xj2v84/LWMscFYuCATwkHLDCDAt7Ql9BC4TBecMMMZBBxiUuc4gcQs8jr
zPOdZ5vkIQe60KvjAG6XWUowsIEcXqAALZDhBk9wQekwJQYX3GAJRIgBEspwgRZ4++Zhv4gNCPCB
edO7jdZU+zTZXs22S9Pt/3GH+9zXLve60/3tdzdAAzyw7mJZwAIXEPwLCK8Awx8e8YlXABIIXwXB
r8ACSBf75DESAgZU4F5517zdN4/3aoIc9D7nNNqHHnpVCaACDAC7yjgQXsq/Pik08EAD6Fzts2Pa
9KTXvaxF72vTTGABtBE4sVaQB9gffyh+LcBUep/v3OO++RmPfsefD/1OO8AKHtDrsEKQgdUjH/wR
sVAGzC790k+f6Lw///p3b33NfCD7F/j+lIpgg/DfPyIyKEAFyj969W8V/dLP/f6PAAdwRyYAAo6A
BAhNSiwgAWwO/8IOBHoABWqgBGxv5AQQA+us+iqN/QrQA6ECAWoABX5A8v+ggwMaKwLBjwYqIAMW
oPawrf0GKwA7cAN/bgZvULs+IAE8wAT5gwVEbQXFjgY2AAUWoJ9sUAZBcAkNMASZsAmfENOMDAWK
QNgo47mGbwgfDQRWoAKaQASS0PxyMArL0Axvzwl10Pc+sAQW4AgyADkiY6G2sNksgARyYAgiIAbX
kAzR8EB0LMcCERAHURALkRAP0RADUQRqIAY2wAZOECiAiA7hrAWAwAMIQATMDhE3MRE5UcSU0A/V
0PlqkBQ/UCsQ4AAyAAWGoOaAAgQqAAcmUcJSrgJyoAYiILqCDhQzcBd7zhSlEBhFcQyh8Ow+AAje
8Aeu8CF+QFZkka+6kAH/ciABRMBPeLEU+zADr5EYrfEXhZH6tNGORmAIUIAAioAGQkAFKgACndGC
YKAHEiAGKoCduvEMuREA6TEU65EDwTEY9bEgEiACIKAGPMADSGAFIJEdVSbwCkABCmABKCAG+dEb
dTEAJdIf/S8NL5IPt5EgRqABROoBRgAImgAFGEAn1jEhWcQjfqACYiABFiDWNHIU8dEeMzIfb7Im
bTIn+/GIHKAAqrHXSuADFqAAcgAFEsDr5i8llQN8iqACFCADakAEDKDKLBIn95EmcZAjtVInsRIb
vZJsfAACNhIDDGABNqAJYqAAfsAGLEApl/InYKAFLoABCEAtJWAEPEom/4exK7mSBrPSLydSAwWz
FwNTIAyAyjDyKgxgKGugJdWSBC5ABhhQFkPAAljgAgqAABSgCRxyKoFyMPfyGwFTMUWTIklzI/uy
NE2TsMALNKzSAQwAAoiSIRWAAApgAwSvBSJPykAA8HrgAoqgVgyvM2vgIcfyKw3zKpVzJxvk7p6z
86CT86bT86pTOq0zOrOTOq+TO6dJnbBzO7XTOg1ANs8JCFzQ8DKgVgpA8HQT8CxAC48ia7LGMSwT
8D5C8GpgPTdTASqgAjZgARoAAiBgqrozPA8UPBPUQBVUPBfUQaepMFdzOSW0OVkzQtPmASogF8FS
NWOrBMjTAEZgAUaUAf/W00RPVPESD2tS9PCOoFYq4ETXE0BHdCrJUy+tskInNDV5Mkc5lEd9lDBx
FEhlkAH6T0dnMjmHx2uwpkeH9Ej58keZ00mnlEql1EoptEqx9DQ+gAG2Uku/dEeDFDWR1EvDlDWF
9ErN9ElHM0lxDQMy4ALLlEw7dE6jFEzrVEzbFE/X9DT1FErzVE7vbQEOAE3v9E8ttFDVtEnTdE/5
9EIbdVENlU0DdVJPsQAIJFEhNUsVdVM1lVEP1VEfdd8yFVQjlVM/tVKFKAFiklRTFVDptFQ7NVZR
tU8pNTRDtVVrFVZdVXk8clYlVVft9FSB9VZN1VOJVVSD9VWF9ViH1Vn/rcsnQbNYZZVXcXVMf/VZ
sbVZt3VUO9FbPfFbwxVcx1VcA3ED7qVcyVVd05Vd19Vd2xVe31Ve4zVcklVZEfVaq9VYQUoAEmAP
p5VWARZZc1Vgs1VfqfVeXYtg7bVgufVgA3Y0XHNfH3Zg8zVhJ/ZiEbZhtbVb/ZRiDTZjIRYcReB3
rNVjQ7ZiT3ZjP9ZhURZkGRZmp28CyBMCQNRmbxZnZTNnd9Zma5ZnedZnfzZng1Zob5ZoixZEjxZp
ddYAIgAzllZpkTZqi3ZqhbZqdxZTLXZlXbZlt9ZrY1ZrF7ZVR1Q0ytZszxZt01Zt15Zt2xZWrkRs
tRZsVXZubdVr49Zj/8nWbfeWb/vWb/8WcLmCbPHWbut2V7mWY1m2Ywt3bF0mcB+XICZAWgdCL72i
ciGXIC53LDSXbR/gX892cOWWcA/3a0eXWReXdA1XK/S2Kg6gIWuFADBjIBiySwtiM/WSdhHidvf2
AP4KIRCAAMACeDFXdzn3FIOXbwtA5woCAu6rbEOXbk13WacXX1VWekWTdaniAJB3IBrAd9ezZAWi
ACSAAHC3VsI3AMa3fKEiAmrF4mqWAkrUeSOgRBugn3rXAbw3fIdXIPK3AOx3IB7Aew/AALiXICCg
VpY3AGTzARgAOXuXAWKSfv9XDAlCAv73AdZXICA41iZA53q3AaqRf/8DwAEu+LQOU4EDoGYFon0L
wOJUuAAiWHkRYoUD4AAQMIYnNyqgl3FF14ej94ftlkER9EGJWDwbwHG114ADAAEUwKNqJQAqTiAY
4CM1GIqlOACoOIo1t4Cr0WnF13ejOIUD4AEUwE+2Vy8z+Mb4V4sFggDGkgFqNwDIFyGqDAKQF403
mHsbQI4Fooyl9Y6RhQKc2Ib3uEub2OII4HfYWI4NwIzTt2QveIEJwIuDt4w7mADGOH2XV5H7V4Ov
IkCNWJSHmJSLuJQbFJVH2ZRXOZVPmYhVl3qpInujYnsLgo7T968cgAD2rnatOJd3mY/dWHO39wCK
uZjFV4Fn2GklIAL/gNejepcgMpmJkVeRjZmAt5hylzgAGiCTmxaPwziGrXksl7mZPxmZo/mJGUCc
p5kgvJedsXkgpDmKH6CA9diaPziMNxkhZhie+7kqeDh1r9dkexiIrTeId3WWoQKNg4l8PxKM/bgh
49l8ITqMzZmECcChY/Ocz/l/BaIBCNl1kdOd35l89RK1uNmjEEAzdXcsffKbB2KQUYsq09ehP1pz
I0ABcgrUCDmmD5NAmtih79hP+Hd7Y22kJ5mSPTmjb0yXa1qeCYKfP9midxhuD/p0FRerETerS3fo
BHpiE5p4rwKQLDcqHECHMxchzFqsuQIBKth4C+Kt2zqbBeKtKRcq/7CYIMYarv8WoK9aq/+aqwua
oIXYqr0RrMMasRN7b0d4LCKAfF9YsQWir2MZYwN7sAO6sAcas8HisCPbsz8btBV7sqv3sv3asje7
tEkbtQU3iUPbtV8btvt2tDXbtGFZtWvbq0U2s2W5tfc6ts32hn8bKjxYuGW7qgW7K0+gA5Z7uU+A
BzRAA3hA95ibsjXWthV2t7+6t9G6uAtCna9iqoWbsYX7u9V2tiv7ugXiBDRgBzKnC6T7VLqgDQaC
B+B7K7BAA6aAvW+7unU7tfn7n7d7IBjATxpYpW+zcsEqdj8SAhrAaZeXmzF6wBGgLgsAAShAM/t4
ewmAwD0aAsi3k/8FzTZ/spBjV4Et2sAzvMTDd8PlOcURXCAa3Gk5nCA2vMO3+cPN2ZnrUooFDSgl
AH0FAsMXfCAafMgtHKY1swDuS8alOcKXnIwZ8jar8cmdlwEoXJsJ4rytW0jXuwNOAMznuwOiOwD0
+8v1WwNOIADWW80DYAfSXACeWwM6YAeYoAvGnAmUYLm7YDuYIL8DAL/bnMuze9DFY14PPV07G5ub
uBrrmaYLYnuRxWmRxdHf+DAVINYkWZedd31jeHY5WZPFWJjh+pHnmHv5OZp1jtEPE4+5V9Nld9Sh
+HcxfXY/spYD4IsLoqM9+ZkNWIrH99MLOQZ1WS/l2WmTcKQ7GZT/PxLRm90Q13sHKoEHKsEgxnza
5/wpxvwPAuAPNGDbBeDNTyDO55xZ3py5tT1aKgG6d4DOoZvanR3e6TXewSW9C90rFH19R5h/dxnS
w7h3gwngR/2dbfivnBngcTeZQV3IK85PolpzRxiaz5kCGF6f9f2lN7jgy/fgNxquDbhEp1gCdLmC
ozgmo3gsI96Nda7iDp5AUJ58DYA6NFieUb6QBT7A692/owLaC8LaA2DMpyAA9DzN13zO2+DO4fy5
O2Ag/HwH+DzoEQLPlx7b7X21cRu5rZ6zBXzULV7IFeAAEMAAfofmayWYIgC1NBjifZebKQDsSxbV
+TmGPeqO2Z6b/zn54bkX5Wd47hGg7geeqP1d7TGj7Tk+cxvSAPieAKosdiG7678erBx6exsA7D1d
hRUAAoIJ8sO4RMG+LnH3ysH48Le3GsO7ILY857tSCU6ACQriBP5gvoMeC6ZACcJdIJQAC7BACZjg
BJRAANoAzAuCCbBgB3a/IJTgD1afIHRfCage6/8bvXMbIRS9u6cfcBkgyLWC5mPb9FOWoE9g+LFg
zLGA+fub+0kX+iVV+qlf/dn2wBkf+/NZ+4/b+Z+f0E+/+c2//tFf69ef//s/sQFiwYIAAgIYPIgw
IcKCChsmZOgwIsSIDSdSfHjRocWMBjdy9JgR5EWRFElK5KjQpP9GlBhZHlRZ0WVHmTNpwkxJk2DO
mwYF5vwJNKjQoUSLGj160CfPhTub2nQqc+lLqC6l1oxKlaVVnU+7Yv0KtmpWlFuX+kTK8cADtGjV
sjXaoACEjG7fClU69mPekHtH9i3596RXsYO1Bl5ZWG9ixWENL454FikBBgzsEmVQwLLmAAUO0CTg
maUDAp3f4n3sFzVg1YIbkz0ckzVi14wJ0+Z7O3Xu1btbc4xslEGDAAQkOCSAIAACAhAIOI+gkIJz
5xQaHpheOYAE0sUNHhAOmoACBaC1cy/gwCBy5cynQ0/ooAB34wG+NygfgXv2+PMb5nevHnnrISTd
dOohsJyAy9H/FwAEmSlEQASjGcDWab3NZluGjl0YG4c4ydahhq+B+KGHLVUlQEEpqpgiQS2u6CKL
MsZII4w2vojjjDfqmGONPe7oo44NDHRUcwZN2NB6y6XHXkQPGJlQdwiVZ1Bp1yFUwIMIIRDXgewx
uVxEDhiw3pUGUXaQBFoGMOaAB2GGJX2lJdRllMkRF9poaz1AAJMIoRlAfhUOB2ShPx7KY6JBLmqo
oo0yiiikjkb6aKWUXjppppJuaqmmnXKKKaie4siViUyReKKIFAE31AMKSHBArPclmVyYBtk6JX1k
QvjeQQRUl9ABa2ZpkKvAquklrri+mR1xyQl7UAEMMuvrndEO/3dtlaFhie2Ud1IZKAHEUZhQc7HG
SixSFqqKm6lToXqqu1exqxu9vNnr24b4YjiivKXuG6K+GbEqlJRvrpmsuLcqjGVnDTDA8EF8MnCA
BJWR2QC63q1prgGjZUzZg0oyvKxB91UM8bNaTkBarAwkd7LFbkbbmbDdzplQlho7eyZoExi03bYS
K0Cur9MSta7A/QJcItOpKl0b1O06HS/V7/pbFrxXWz2v1PUOTORmYo9N9tgPl61Q0kt7fS/b+a4N
d9RxT+02v3N/fXfbedstd9907803ZGGjTXjhhrP03OE9DZS11l0DHjDkTdcdud94W6435m9rHnjm
f3Ne+eeiO/9EsOKmn4464WqDPrnkT7teNeWts/467bHDvrXstY++Oe+9X+575w0t0IABxh+PfPLK
L898884/D3300k9PffXWX4999ssP+a/ut9ueO+6Pgz9+8KEDj77n6f+ufvvCsw//+/Kf7/78s5t/
//r2764//fH7v7/v4Y9/9QOgAfNXQAT+T4EBDB/5uic+CA5QgP1j4AEJuEAMNrB8FdTgBSmYQA9a
cIQiLCEIM3jCDUpwgg5kIQdDmMIPtrCDMSThDGF4QxTmUIWNwxpsbLhDGb5Qh0Pk4Q9NGEQgFlGI
K6RhEpG4RCU2EYdRhOIUV6IinWRxi1rsIhe/6MUwgnGMYizSIxnPaMY0onGNamwjG9/oxjjCcY5y
rCMd72jHPOJxj3rsIx//6MdAAnKQgiwkIQ+Zxysa0XGKZGIPudZIKT7Se0+soRUnGUFMPlCTLozk
JY9oyVBWcpRVFKUnTXlKUqaylKrkpBNZCctVytKVVJwlKFt5y1jSkoi2ZOQuF+nDYAoTkr90ZC57
OUxK6vKYxZQkM5/pS2gmM5PSVCYyiVlNazbzk9Hs5jQ3mU1qehOb49RmOMH5zU5uE5XrxGU5xZnO
V17TnO9EZzxr2c5l1lOdMgkIADs=
--=_related 000E051748257ABC_=
Content-Type: image/gif
Content-ID: <_1_0799D7FC0799D5A8000E051748257ABC>
Content-Transfer-Encoding: base64

R0lGODlhOgPEAecAAOjo8MDAwP///5DQUCAgIDg4OMjIyICAgAAAALi4uHh4eEBAQFBQUGBgYODg
4NjY2JCQkPDw8HBwcKCgoLCwsEhISDAwMLi4wHh4gKiwuCgoKOjo6DA4OHBweNDQ0BgYGKioqODg
6JiYmNjY6PggIMDI0IiIiFhYWNDY4PgAAFhYYBAQEGhoaMjQ2AgICGhocLjAyLC4wJCYmKCosIiI
kJigqJCQmJiYoICAiGhwcAAA+BAQGNDQ2Njg6FhgYGBoaGiYOAgIEEhoKICIiDA4MIjISPg4OPjI
yGCIMIjASPiAgKCgqFBQWIC4SGBgaJDQOOjosDhQIFiAMGCY2ICwQCgwGDBIGCAgKCAoGGig2HCo
QBgYIEiI4FBYWFBwKBAYCHioQPhQUDgAEFgAOMjo8ECA4FCQ4HCgOHjQUABQOABYsBgYEEBIQEBY
KPhwcCAoICAwEFBYUFB4KGiQOPhgYBAQCBAYEBggCCAgGCAoKCAwGChAGDAwiFCI4FCwUFiQ2AAA
YAAwiBhgeBhgwCBwQCBwkDh4qDiQUEiAeFBwkFgAAFigcFio8GhQAHCQwHCwaHhwEICw4IDIsJCQ
IJDI6Ji4eKBYAKCoYKDosKjAkLDYgMDYqMhgcMiAOMiYmOioYOjIiPigoAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAOgPEAUAI/wAFCBxI
sKDBgwEOKlzIsGDChhAjCnwosaJCihYzDsSoMSPHjhU/gowocmTDkiYXokyJkGVIlxJXwtw4E6LM
mjdn5oS502VPlj9rjgxqkuhQoQyNglTakalGpx6RqpR6cSECqlizat3KlepVnF0FQLU49mVYn2HL
xkzLtqtakm25vrVpdaYBBAYGEoAgoEABAhMINmBAIG/fAgL9DpRAQKEBwwUNPCj4wICDgQcQO4As
IDPBygY3CzDQ+ODjgw8iDJRM2XLHwqMnK9ws27NoiJsv1/yqM+7WuSfPonXrWyvwpMWzHp9KvPlB
3iwjHFBdEAJfgRR0d1YN4cABvtYhQv9gwOD6dszUx/OdLiABhAeDAwt0P5BCgwIHtCcYTEF6aAkM
TOBfe+YJIF0BDcgngHrnGXSAbA6wJ5CE59E3nwT4XWYhgQZBkIAAD2AowYe7CbVcVc79JhxQyWF1
YkspGtciVS8aVKNDda2o44489qgRdMPJNaNUNyJVJE0xKjekkUua2CRYCgGpEGEMHEDAAaOV5lli
BPjlVwMCUWkllvgRBJsAgKGpoECkEeTZXV76NdmWiWH5Zmls4iVAA2DyKVCXcfJ1ZpYGtbkYYmom
WtCgaNqJaJ1oxlnAeo8a8KWVhl054aOdNWZoaAQAWgACWEYkZUpHTvRkbz5GlaSLq/L/FGuQKr5K
Y46t5qrrrmGdWtSsLNrKK47CMlmsk8dCKWSyrD437FnsSRcBhmAeNK1ffPmXgAQISDAdhRSsqdcE
GD67oq9HMSururumKhawqML7K7vBLmuvQeia2ypnlGnnp77D5tuUvOneCzBB7iZM8FILD0xvvA/P
azBLEpiA4sSwRlxwrRjferCNDT8VsqsdEzkyWSebVXJFIDAAl8YMw+zwysjS/KzCMoucM8kc9yzj
zihr/IAG1Knss5JAG/2zzc1+jCTT60JN69JHZyx1vVV7DFEEBfDLM9VgI301xBlFIEIFK5wgwgY6
RgBCAx9YAAHbqjqNcMprJZ332BJn/22y3i+v3IAITYdttd/G3kuBpnZ3JAIBhA+LM98bG6414jVj
rqzmhYtQbeKcRx361EI90HXjYTmwgNeA02VRAgosgIAFLEDAOurCOQBC7C5okKB2wbUePOUxE9+U
pUUfbvnfxusM0wIk4p6rBxYkr/xMFJywAgseSO/9VhtAoMGkdBcu9uhYLw9TBARcNjn6ZMPft+Of
G6RpmQl4WtpdeT1AAAV9KZWbNEOABgDPTHn5lKHKdBjMPGozB2AAomDzKQFMoH1/OsBjLIWlvQwk
fwwxgQSuF0ICWOx7KPxeAArAggNeTH6VO5/6RsIAEIBMeMjBIXOIN4ETpLBxChBg0/8icIITEkQC
9YsgQcZDqJncB4AFwZBsJAg8CNRvK4ziURZfczuYGMACsnnfDDc3RomIcHgwLF4aZwbDE4jrLIxD
UxcZwjj2jfAuBSyIlyakJTxZyUScSgkEWGCRC05KIA4ggARXgydDEWCEBaETnQaimM78RTZniuPi
7mMQBiZAT/zTS6nopKkG4EkvkIHNIxeyOAfhCUEDSaRszCTAQcGGkwvBpQAoAEo/PoqBZ/rUJCHS
wzKKzpikI4gHEsBMESjgmU7wiwVcICkLIOCa2MzmNS2AGB30ZQfaDOcOJBWnCjxTASZgZgLyIkYZ
upOEEHFjTar0p1R67YKqtCcfQ1X/ABfGkZGGScCjlGilUHVKOYHUyAdc+MOGOhQr0AMdMhXigQko
oABB+MACOlCDGADgoyANqUhHStKSmvSkKE2pSlfK0pa69KUoRUEGcOCDUWlABem03gsnGr9C+vCh
AAuiSSJqEPIIBAKl+UsCPdgZNhHgQ3dhgGp4GRhDWekypPkQpgTggL8Y5AHyQSofwaSaVe7JZU3N
UvRciRkEBIZraDXqgk75J0jqxqyDmWvyzHrXvHxSPhNAAFQRUC1TfpWpfnWrQAI72MLuT09NPIBi
4ZpBUTYxlH2pViLXSpAVlC+ZI/GACQrgAgvkYAYhgKlqV8va1rr2tbCNrWxZWwIa/zBgB1dwAgh0
6rrmCcBzr4mTpiSJKAfch5/1/GBpYPMXL3WpL5BMbkESIEECkKqJo0FAnPRk3L88tyNnjM4KeAvU
hkSgQOVFoVgZIk9lGcAJO1iADUYw2/ra9774za9+98vflcLgB+NcGzxBQtT0coV65HVJeFG3RYUw
kIEIPAsDousYzhaEAv1MyTBvltCGbMAEH/BBCfpL4hKb+MQoTrGKVTsCHHxABXO8G1ZMF2MDR0R1
Nb5VAhYwy12VS46oRBMUCQOpANoPrXYEkWIFolMIB3O5Q05qqWyZKUhu6ZNYsupAJ/i5u1aLNB3u
0b8MQoEr/IC+K06zmtfM5ja72f/EM1DkZ4diARvucJf/NPDjIscrmYjAAu6ysaAz4oAKsCB5Xc1B
at/M6EbX9wKhGmkGCFCB+paAAEOobw9ASoALOPrTro2BBiJHPfQGrWxnS5uAV+Q2uMmtfIEGbUZA
YAEGWHjQuLaIAxijgDkP5AEWgAGoh03s2F4AAZ4GAAE4oIKPYoADH61ApT86aR589AUVIIAMrk0A
lHYaAJAGabgBUAJkO5sAmwZAD7Q9UgJggNPJVranX9DtYhe7BRZ4t0oboIBTr9F5jRNjBHroggpo
MNfmcoDn4maCWf7kARUg1aLtTfGKW5zcFeDAiC/OcZeiYAE5wO8N0HpD3/rbbu3/zFgEmHkABZxg
ARpAgAsWsIBzeoiZ3QOfOnf3TAYswLoroPkzQZCAB6ScIBRYgGozUAEN3KDjLW3BTDvQATYQgQgu
0KYLqsD1KmAhnG+4+g+oPoMMQN3bL6B2vTmgbwBwIO0ilTa8RcpuTm9b3iM9drwBgIF69/2jKqgA
tj/KdsJD2+3P1ve3zy7bETDABxNfcQwsUDeTK81pR2fev7/2zhfgwMQ10MACzL7fEpygDlEAwwBW
z/rWu/71sI+97GdP+9q/vghS0MMbbBB5xus3A8APfvB773vZhsAHFUCzvUOwUMvvLeB4C9zmT36+
AFiA2CGgwQe6sPGQoqAAQiiC/+3HT/7ym//86Gf9GaoAAf6G6v3u5vvh5f/RJXBg2cv+6OLBXe9v
338FCPABlIZ4IbV/INV3+Pdu4wZuCAB/32Z/+Dd/cdYBxHdfBgAC95UDBYACxSdSM7AAPDU/mBd9
vTV9l2c13uRN9pYBRCB+s5cEQuACbdAE6VeDtFcJAWACIrBBj+EBPkgDiGCDQvh6c1AA+iUAKSgA
LnUDFsCBHDd5LBUAGUAGkZAFWTAFWGgGfzADNKAG6bZaGFAALdCBLIWEZng5IegjmSdR74SG56MA
bedob6AFQyh7VBAFX+AFSVCHr5cJCVCFWPgHf2AGZsAFXJABEBAINMiHjNh6Vv9QAyc2AgXweWQ4
UhbgUSPlAJroABvQiZ7YiQ4wAWoQCSxlAxogbJXoWi6QYLLGhh+zhpmThmoUNiAwbW+WAVXQiEOo
BXvwBVJwgw7gAQ+giZ7ACQYgjMPoAEugBoswe1SAAHAgB1Sgi+cHBERQXyGQA02YitzIjTCgAc4n
fShHgmgki2ykPrX4ZmyABNTYju64ekiAAFXgglSABVYwje/YeliAiit1Az9HA8rXjfYFBWNABp2g
BgQZCZ+gBgCQkABgCYwACnxABgJZX9/4Ljq0UyOYkTASjiU4UQcQcmw2AkRAh/nIh08gBmgwAI2A
AIcwAJOQBinpB6s3CVGQByv/eZLmFwXtV5E++ZNRZwEuBItktJEeWY5tqHnmKBAbUABL4GYQgAVn
oJNUWZWsVwRtsIFAuZVcWVIjUAF8hpQD5ooHQ5TmM5axmJQssThP2WgxEAeop3pWOZerh3t6gAcA
2ZV6uZcg9ZUq4Guch5ZF+YrkmENHaZgm+HxiUWtOWHwjAHw1QHUncHWUSQQf8AGVeXVsQHU4AHz8
yJegGZopRQMEoACs2IppKZiSU5h3tpSB6YaqaRoq8AE4UIGgBgMWYJuiuZu8CQAxUAFbIAKsaJbH
pJbmQpyoOZiwuZxKmRUKwAQ7kAPdt18jYAHT2ZvYWZEh4I9boAA9lpxnyZxk/wkwyJk+xqmczRmb
4MkQFOAEW0AAOYCJI9UFNpCd9klxKGADDFBwEMBQJZeY4nie4UmerKmR6mmeB9pTApoRxfSfDeEe
TmBNFnACnXmf99kCkVkAOxBfCkAB31meCpqgIiiialigHQmgH7mg67miFFUAgOmgKioRBpAAFnVR
BWBN10RNflEBVNcBnemZsmWGACCksPWYkNmjNeUX1nVN41QAKhBEzPSiYimeqUml6DmeWHqcJgqj
JDqLMRqiVkoQXJNjJ+qa1Nel5/ilIxqmxYmmAGemwgGia5qebMqiYEqnAlExA5qlV1qleMqne+qn
gNqmdYqgZbmlxHKYrammMf9kNS3DqF7qpq/5p4JaqX16qYGKqYRKoBzJpWFaYAgXqigEqpFaqHc6
qHY6p6hqqJSqqe2CqDLGNKR6EJWEGcvVQYGRSJuBJ5qSJrpaQWFCcj+WJtIlEA+wXrCUJ3OCGA8A
WXK0WQOhS4WCSwVAcnEEYSCyXmYSXRdUWZDyR3pBKUoWPSCEJteRJnIlAOWiS4nkNRSEQdjVELP6
ppCappJ6pqaqqpaaqfzaZ7D6NJwzr6LaUEqkEYRBYT4isPjaqv36GXQQCvR6ryeYr41KsaXKqYpq
oJ96a9KDWY5BVwCzYbzisSmhsBPLsJsqECSQAkdAEEqQAkYgAEaQAnQgEEf/kAIkoLI5KwA3SwIJ
MbNKYKw4ewRES7QGsbItKwB0ALNTirKpWrFOy6r6IqdQC6gKq2UO5FRdcj9CRBhKOhnC9Eulwi1K
eq761BeK1BnahSDv6iBiG2SS9SWwQVxFZmTqurZM1WCZ4VxrYlCmwU/flVlKSgCysTheglYQ5rUF
wBiUlLZ7AijECqwKYbKKWa8Ra7H2irmXG7Wnuq/+2qmJGrAcO7CkCzCUG6ASW7mpi7qaO6mr2rmu
qitUe7FWO7ogYVZ38Z2RtWUHMQGZEbhOBTyk4S3ewVwU9k8QgCGagrWbchAJEEFeBV160QDeMSbz
Ab0gS6x/Yrb2Iy6Ggln+/3MZYxZL/8NHUnG6Kbq66du6C/u6+hq7sNuwsvuvlSe6pXu/DCEdb7Qi
6Nu07lu1nvu0tBvAUkvA8fu5GVumluu6Bvy+8nvAApy5nOvAKdvAAAy/FBzBmzu19IuRCeypE3zB
D5zBBYzBIlzBJjzAKSzB/6vCI1yioBurKOq/FuzCKPzCNqzBDLzCG1zDLOzDPczDO7yaMQywcKq6
7HuyLfzD6Ckw+PvEPuLEQ3zDVKzDKzK7TIzDWVzFJazFQTygUiyj3eIds6QYINStQNZAaOsd+ytZ
DlisZ2JKfqEnk1Qmb9KA8JcXgyK5D6C4WvJLDohWcjwq/NImEiABE4AYT/8Fx3lxJ26btXpUKqbE
AFA0E2GsxEA8xVYcpx2MxV/MxRDcxaA8p5cMxabcK5ncvqmMyTfTya5cxPV7xKyLp2Hsu+ZhKBEw
GR5yvehly9N1AIFBQQThALrrAN0RIZzSHdGTyxZ0ANEzSb6rIAaQPJARzQXhu+sEsm3yvNI8zLrb
Ht+hHcyMzdcMzAPBzLtszObsVBIAGeq8VnkxAaZ2VmgsEaU8y0v8yZt8Fp6syaK8z/i8ykgcwhcr
xcb8IanBJkz2nQYAzNpx0CBSNM8LtkdEcqEBAW81S6F4cM0rz+LcY8/LL+VKEM/LWR49GqYBzt8J
IAzR0GvlGSdN0s58zj3/9gAPgtIDIc+xJM89xjoR4DW30RD3vL4EvcUADcsePMOIKctEnc/+HMp3
OtSnPNVeIdABLcSq3MpI3c9Z7cVPTcJQTcqm3LZOZT+F/FiQcUiLHEl4HCpLBsVSvdQL3NWjDMMf
HLpMTcNYzcpeTdeyFtdUHdgwAdgaW9T6/M/zu9WvfNcynNdyrb563ddMBq+F7dR+jdhhfcJHHdkI
rNSLCtmPncQDbdl8Xdc5jNkFUQGV3NRWzdp7Pdqtzdmb7dmVHduhbdhfrdmorduZfdpQ3XK+DdbC
zdvDHdwawUwK0AAVQHMLgKPYJHrM/UwUkACnWdtazdhGPNelPdufLdpX/y3ZsH2pO8bd1g3e323a
LBwBJvBI/gkwG6AApSmlr6rY9I3dsazd4W3ern2WDiCUtt3duH3Zvd0RDNAA8o1rEaAAUtUqXE0S
b3MCo4IANCcBCiAC6/QxDpAAFPBMy/0BAVhzHnLgA37YI57bxn3iM1MANdLg+Y3eJC4RNSTYJ7EA
1f3agZMALEAAFtBwMr4jA6c9DLA2LH7e5K3AoK0Qyb3YtG3kSfyo9uO4tvpYUG63WlGrENFgGiG5
eWpErZsAFVBnPU66HmBKEFDjTB7g273bKA4RTn7fR17eLm7iRh0aH9AQjAOtl+WsdytEzQtmf/FG
ZN1EDMRLh7Ql/IQgE/+0VLvUgF4CJl0FucZ66IzbECqOpwmeYWGe6eYVOww15Psd5wLeEIlEXp4u
22o+55ntAeCo6UKh2iZiOt98RKXBJ6RxGZMeVY9RSYsTGEh1GVbSAAawSZ1UAPmjG92aSWRiZQll
AA0wGYY1cG61VO0cJh8CAQgwGewD7A39JwVAAcyOQbs+V5eBIMS82iDCGKzBS7ZjKcv+SJnS7d9+
GYk0QuE+zAU0o4ScXQwQ7F0C7NYuH13i7c3F71dkLRVgZ0sOwqTd4gxhATlW6re98ES+24RbE8B0
trQUZMnlF9W7SIvyfsSeJ3ocGH6yJeDqxqGCsIPNEhugAe3N6jCPFK7/juYMb6jBrgDRtAUy5xc5
0AE2kAHyaaEvVQIZEJkdsAB/cU0FAOJzU98wpOoxPxMz3xHjjRRaruUfuyPaIbJh4T/z3CNIFesM
EfYgMUj//UIGYAIVEAQa8AM28JlCH/cs9ZhHX1oKAAIiXtyoPsx1rkWsg+UHAfg9Uukm0V6LYmoQ
ZsfFtbxLlkh8sUAFn6yP20mlEliN/Cj5wy9bkkhY8tMd4kuQzFQNsc2Aj62O1MgEQB3sU1WNBLJW
kjyvP9msz0jGClnMa0l15VRZVhrNChn+g0QLEQEuEMDbcgUE8AOkJ/fKT4YoQANrXwH9idfa3eYV
AQHNVSpWNBDZ3ylX/7L9++61lcwAsiFQofI5GKZIfay7cmwffNHHUcRPUFRQ31HwEKGnNTE4UZ//
W+EAfZ8SEwAQCz5gaAHA4EGECRUuZNjQ4UOIESVOpFjR4kWMGTVu5NiRYQ0GOxQ4EFDS5EmUKUsG
UNnSpUoGIF7OpFnT5k2cOQUEWBBB58+SLCAAJVrTAAIDKAk0KJkAqYAHJiUQKFngQNWrSguYLMBA
gAMCFEoe2IqyAFUBTr0KOIA2asmpWEsubfpUAIGsApIKiEBggl60bfcyKFtAQlMCJAsw5UugbFHI
Lh8UIPnSwYsPODxu5tzZ82fQoUWPJt0ZRgUNMlGyjJwyQoMTG04yaP8gu/Vt3DQjKGDgM/dP1iYj
MMj72/hx5MmVJ6dQwINJlg4WVEBR2vp17Nm1b+fe3bMNAiJq7q5QuWZwlRFMEJBgfjnuDQoIKLD9
vij6mh4qVHhu3/9/AAMUToHUUgLBghK8U3BBBhu6AIEL9juIgAww4MAgDAi4wCAVCDCIABkMGsLD
DBBYAoAeOMBAIQ0BeFAFDj10EUKDSgwRABkQyIDFFT/koAcAhkAgwRJPTLHHBpPMCAMLCjJIgQrq
ywm/4xJIQIEGKlhgSwsQ8NJLDbbcUgEFKEjAtykFhIzK3DxgYYUTVFNzTjp/80CBDxj4awILGEjA
JQoqCEFJQgs19FD/RBP1jAYNEtRohgrQbIlN5Cg9ztI6X8L0t01dcgAEBRZwQYMTTPgzU1RV8mAC
CRZAwAKh9sKp05JM+IGhEHBYoQsnFfX1V46WIGBYAk4EoIIXOGhRBgKUrcAgHpRV9oWFXiCWgw0v
IACBYRN6cMODSqAxQ2YRqsDCHjngQIVnJ8ygRWC1u0GDGLJrQQMpab1N39b4TXWn//xdM2CC/bO0
gho8Q6GDD3KozlAYOtAAgSq80GIAjDPWeGOOO/b4Y5AzTgKJKNZYIQ4bRoh3ZZYbzECDGRLVQDyD
C/73PJvfE/i+nJfD74EPkmyhi8wGvQiFCqoAImSmm3b6aaij1jgJ/yE+uKE7Hi7gQaGsFboA3A+z
dTRshC4YGwAbNLDABgDgTSjrs6EduwSwAcjAhxUKqLdli2LQ4Gq+EbJBBZ17vtmlnYlKHKjFgTM8
OfRcMJplFto4Y487pJB6c84799xzLaro1bMSkn1hR7uHOCgD1e1WQYUMWMewhyE4eGFrAG74YO8e
LFThRgB4SFZ1DIBMSAZkeRhix94TWkIFFXHP4PXYW18IhwJUvoiCGVrwnhLwI4nEEQgMoWSzEjSg
IfCKcijOuMZ1il/N+Wd9vNL7LxXOBQAEUDSEFSThc0jAAhyW9jmpVQIELSADGSKRBQhmYQqOEIEh
EIFADHKsDZr5jP//DOJBh8DAAntjX0IIELeEGGAKZmBhH7jAhTLEcAoBKEQhjmYBJJVQIwLAgAKU
U7+bABFAQsRZzYxoHyLSBD8qYNuhVtCEDEKtCFL4ghUuxjlNeGAKWzRDH2JYhkGoYYaGKEQRonjG
jUWhiaJBQQHWp0ONQEAEIKBAAAzwAAc4YAMb0OMDEjEI4zFkBAvIweTg6JkPvAVy+TvcSZI4k0dq
ipGcut8LOKikN1wRjZvsWBKSMAcWwOYEDWgACyRwgCGYkWlw+NKXrMDJkFkhYRoJAcPeeMjPQEER
gSDDQXSpBgDoEhC9BAAo+EBMXJImBB9wzw8n2UiAHbFw0vTZMwX/4IRbMqgAc4AlLJ8ghjnkAQ0D
+KYX0vBNP4jBDwOggjgReAYruMAKUoAiBvVAQoPAAAeuqgAOUJhMgAa0IiEggCIjiThrHu6gk0po
vxoamcRtoAAwSBIMsECFbmZUo58TAgME+lGQbuYENGMoNZ0JTUmadJEqxR9LgXKgf3rHb1HA6EZt
msEieMEOEjBkSH3604lASUo2WahKipqSo+rPpfB76MCW+psGECBmvmoBDSqwAiy0AQn1vOnTzuCF
eGogB1MFalnNSpERnMA5lHxqbpLK1Lbi5q3QaSrP2moA1MwymSFYAOrO+lfAKuwEWyDpXFdSV8Wh
NKVIRCzjGuu4/7jOigk76MDDkpSDHAZWs5ttyAwWsAUIDJWoj5UfaelnWvtF1qGqhSgjJ8AEFyyA
BqPDiGc5e9ufhuAGJwhCASDgAMNGk7GsdapijYraICJ3tMS163CP44ACROVTDNBAEPpJUdxm1zsj
qMEPqlsBEyQxuONVbhGNi9TyKjG9kFzvYqfZmgqIBaE6o0ADnFCAICCgKx24gV+126AWVCgHBfgA
AsKkAAgkoJnNfW+Dq8ncxJ4XvRB2LIUh61wHn1QnB/BhajH84OHqwCQiVuqHNZzhlZo4xSg+L3kt
XNoXpynGHn5JAiJVXBaXOMdwVXFLe6xjEO+YrRJ2ZHvn+2MeC//ZrYbbgAUUKVcjlxTJQ1YylGec
3Csvd8rQdPGWrTyTBTSATGMmc5nNfGY0p1nNa2Zzm938ZjjHWc5zpnOd0UyAUzE4yHs+MZ9X7Gcf
V3lfRF5NlI8b1wXk2SUFKIABHD0VxtwFAZEuyQSGZZJtUVoAlkbLb6yiErLcJNRqMkCncTJq4xBA
VrhJdGuzbF5Br9bLg361ems9a1nH2tVgVnRLzsLos1AaL3X5C2AwnRWnFLvUrnHMAQ7AgL2oGtNJ
YfQBGsAAtDCaOA1AgHxHfQAEnFICa5FAuMlCGJSApQHPRrcAPo2YdY+62tc2dUkoMGlrYxvezi5L
W6wylcOwpSz/E8B3VGWVAAKspTFWeXZSwPJvbK96LklZdkkqTpNW4xjQQO5zx//s8UBvPMmE7rKu
Nd6SjBNa5Sv/V8ojjOtdt4QEKTjCSZRAgjCUJBQzJ4ERSECCkvy8JEf4OUvCQAI6CF0ASU8BzlUy
85ofoem2hvnJP371kBO55CKnsktcjpKKozrUD0DAk90d6a442gAS2MrFUf1pwTja0nPJs7SPsmoD
TEAwxkbJ2wN+F1nlfe9iL8zf4a5quaPFL6B+zF2uwna5nOQoiiy1Yv5OdkeHRe3SXgzYIRBVi9ul
KyfpfOUx3usLm1zPRaFDCnIuZdW/PPYVrvrqJbx1kHNcJV9n/3nvIQOBd+ekAUNRLO9hXHvZc33J
t3av8r88ezrhHuu6T4nxIWNpBigcpcP2/bRzcnec0Jv4xrE+jZ1Pa+TTHvrHX7+M0x99Q0/Yy+XX
iaWbmX2wB0bhz04JthM+bpgglqGYDGIJOOI4CU4zAOgalnG7irDbP+2Di2EpgLkTgAM0iagaFnKb
wApEianQwJOQtpT4QLq4uAzEwHoriQZovLl4n8igPy1rP/PLvZGjwa6zweV7vzmRvqybvpNYAFOx
EiEcQiIsQiM8QiRMQiVcQiZsQid8QiiMQimcQio0QgtAPfY7v1zTwpjjQqvrQTCkPuPiQTGsQR+8
wTPMQRnEMv8ddL81jEEvtL0wNMM5RMPuu0M8zEM93EM+7EM//ENADERBHERCLERDPERETERFXERG
bERHfMSaQABInMTDkURKvERMzERN1ERLbI1SI5YCkC9sc8GIs0AQ9L9h0bTbQLWTYMWZuDhUEcHZ
SEGTcMWUSLjl6MRN3EVe7EVf3ENdhAzwEwAIKDt3iy5jFDjAq4rCKIsIGD2lCLhrm4sC8IlijIoH
KDYICAy6EICpIIlRwz9i5EaHO4uUMBMV7De6iACnEItnvIpsLIltvMWsGJaoQDhqtEZjHLUVrIyo
ALe/eMYIdLer2EZJwY1g/EWFXEiGbEg6SUiiGEbSG7hhqQz/EWQ0ZqwxWfS+iSPISnuKtqgMgvvH
siCA8eOKSAM9pdgLlUS1uDCLrCA4iRMAUiqMaezIjhw17qvFx7DF4Iu824BIhxxKoixKo9QJoTxK
pUxKpWxKp3xKhWRKqGxIqZxKq7xKrDzEqmwJWGyNjbQJW6yJsIyMruQ74zIALMyJbTG7mdjKrHxL
uIxL39vKveiLvwg7BCg2+ysJ2rC4krDLTRPBYkwKcXyAxDALxuiLwkMMcESAU3EKkqyKlNyKeZyL
v1jBv1w8zFTBFDwKxgCLoSjMwzyJzRzHxnxMY9xMwATIv6wMChhN7gNNlNSLSWuJChTHSJRL3dxN
3ly5qhw1/6dwwMB4jG2UOOBEgIIUQW7bC7BggL8LQcYotZKMtMoAt1MJSWU8OwxUuMV4jHb7Cr58
DHMEO+SsC/lqzufEwGqUx8BwzLE4zO+sTvEMOHCLtoCTTb74tLKci+cku7RECbfsTQEdUAJNjgD1
jwioLxYkirGcCb0bzeNI0NIUtQW9wwMtUAzNUA29iQvdUELsUA8NURHFUBDtwwNgy5t4gKyIAAlA
Ucm4tEss0RGdURqFSxndQ7vrtkpLQdy0OLQYxs3Ex/5jjM6bxButUSRN0qWERLvrtLJsi1MRi4tb
PEzzrZSATASE0EY8UiXtUi+NSqx8ALZTxV/k0i89UzSN0f80LUQzXVM3fVM4JYoCCK44rVM7vdO4
NID1xFM+7VM/TVIFcME/HVRCLVS5jAANcFFDXVRGbdShBIGBdFRJnVRKzcSYqFTfC4BQGZUGCC/c
MAARYIECQIAFkAA5wVRUfVOwOMhURZUIEIEC0IDQQqlXjdVZbVVc9VATSM9cDRAPKAAWWLDuiw8L
oNNePdZFtICZRNbk+NWTNMQDMVZmndY9NAALoFbl2IAFkC9KtFZF3U0rmYAxYwEx2RYvIQAxSVcx
KbMTUNd0HVUvia0tYYAxC0JhxVZIlAATwFfj0NZlzcQHWIBv1cQEOIATIIDYYgEFSID+UMQNSAAI
CBWEXQD/BQCBe+VXIuuLi8VYnYDUotRXRnwACDiBFbCAMpFLDzABBnCBAlAAaeXYlJiAE4BZT9xT
k3A0lXiAwDO7B2BV/qMJBuBWlWgAXmWLSPW+BKCMiKTF+OrDAGiAD1iA30JTEGiAFWAAEWBVmoUv
od3an9jVlsCLvqy0RvtRpGgL3/jJsSgM9lDbZSy1FRzVgPs0/7PScGQPbDuVJg1PRivPY5wK8XSM
hKPFSptZQvOAqFKAgcXTWrWAU/XamngADdBayLUJj3UJ7sOLw6w4iTQMt2XFpB3IvfXRyMPItQWM
ytjM0dVOTCu2EBy/ynQJkL0ZD9iS/2xVB5gK163csegw/979iaaNSw/QgDnZgAZYgH+l2fjQgJdN
0wiwgIb9XZ1Q1t3cgBXwDxEoVumtiQ2gDcpF1QRYgO0likDNDWjUia8ES2c7gPGLAPYFtaEoWGdL
i/U9gNsFCplFDulIS7A4FbBgj9Y1y9Y4CzxrxbOItqji1gYlT1nZyZtI359oC7XMCwhWy+SFj21t
1QYgqfH9CerFjXdzjFMaT+FoC+LwCREmi07rCgooN9TbyRJEip0kjm/jRpPYS/i43ty41JowScPk
S6YoYLOsOMcAtmEjvJTAyLkTUhHkPsgLywlgtG2hOLtwPJNIAMLYlqswjFts4KQoYil+PATwE1Dr
NCFuQf965Mhl/DUpZkEu9j63E8963Is4tonJ2Fg/dQALwOOUIDEB8OPt/eDbCGEvTmOcXMYeVQkH
Dj2HW4p+U8f3zFYdjgxBvombXFtFegCF02STAL5mk8dI+7yUICWpyDMGeAsGOMnhUEVNTjgDOOUd
LQs9LSiadIz6Ir5W7kZY5su38OR3879d9sBubI5PVolZjopg3uWkTUWVIOZThmVOBmUMJL5djmZi
JNOX0NgMRUtxVQBG2wEE6C1G6wBy7oAZiJ0M0B7Q+GP/YefQGAF0voFy9gFgy68dYDQyEYEEaF6i
LF/ezN+isNYOBpDZ9UUHgFhvnhjHwKwMoK3/UpIMkGf/wnCB3lKBMuFnQqxkuLReyNjggQ4QB/iA
Q4RYJ+gSUsGBDOiph37oEpBn/NoCiqUAPobE4J0TCK5gRb5gOhleyCATyVhWnU23O7rZHzUPWHQA
BRRqAT4JnV2wnr1ZiUPqgZXg00XqlAhql8BZyYvqpIbqrP7XruZKidPqlAhriUwJq76Js6YJge69
ADgAUdGAH6gBdV5puy4NfaqAINAACZiAmf7DQAGK1/yLbQTHpTCA12SMBvgLhCM+x4CAvMvcRj6M
wf6Kw07aKjYJMr5GwAjFP5kKBdvMxU4LkySKgiYKWiZPYhkWasuLd2sLwRXOk4A8Il7tYZPF/Yyq
vk0K/7HjltV+z9h2CarOTmU8CtuWuNcEYLbwbWLhzKC1Nwb0vp/EyIsrS7Wd7rZzUrOl4+HkSTRG
Y86t4gK20pbQaDrZgNfqLX+6a/bmmxCoAR/YAQ1QAJ32PbBVS15F4osz3RkuyaSY0HQ0iXszzscY
tosDi67d7wqlCYCODAhggZZQ0AOojATr5FOZAOd0gAp3XxYlb77ICzE1jDxLgGujAPdVCQhIZbbw
CYhFiRRX8UrL8AqnwGb+tBZvivGT8AV78ZPk8ZIIcQk4FR8fCzRJ8dH+y7w4cRSnDdc1ctdV8g83
CU1mCiW/8bSAXcNwAPuN8h8fW29ccHurAARNbwa4gf+6bm80N6uI0YAtUIDoVTk9/d6GrOnbuNyP
xl5sJgoKmKwccOg0//P2voHPmvDzsnOHPG3jOIHdvfPnIgA51xQ+93NAn3RKb4gbKIArgIBHBxB/
/cWAXVzcCN/zKlhNnzgVPUkV3fLSdUFV0/KpNQktJ/SrjgBXb4oD2N1Uz7On1guoeF8flQBZ0buT
rMuo0LtegwBVLwkNn/AFRpX7ponLoKwzr3Rqr3aMqIECcFw6CdhQ6dpH9NY6aTJQB5BlVjhZlDZL
M4yXfDe3lUV89DdgG8jgE8GKS3cJWPc55sgZTri2kG3iDrWjADZG01lTa/Y5oXOU2ADMwAGVtnaH
f3j/jzgNDfD224AA6HUJZ1XEaEWpgMXom711o5a8K57avdj1XRd5Fe01kYUAFD15vBt5kih533j5
GyY+Df+TXSd24VAkB9C7VdPwgBz395Aob1d4qYJ4pE966xiBH7gCiod2iiWKXw1WPiRWjweOmWH0
k/jV9/EACygkpQ97sdcOvxHUTdNe5KhVWRWtVFH7WwVECNCAA9h0ak0AvpaSDVCBE5j2seebB6mA
CzkIHiAA6PGWmPKaw/ca3JmRunGRxkcIAkCSFjEbxO97hBiBAliBpxcQTY3rTiUiUBVVUjXVTBSB
pXjzVt2AtmiPlNiAClAAyw+obwEA26F94gl8t2mb/xV5l+AhgK1RltVuF8jPFhlxERmZfdrPIXXh
kQkBmxYBfmIRfqSfAZhhiBLQ9ml92g9ggavPSi1H16x9CQqwAL6P/UPqnUACHtmBFgs5nYQYAmMx
iN5ZF+BBiOJBESRpHoMogQqAEREBiAoqZAAoaNCgigo9AGBYWLBhwR4YOAw8aPEixowaN3Ls6PEj
yIIhfDAYEbKgjQURBLBs6fIlzJgyZ9KsafMmzpw6d/LsOXODCAYrGoDwafQo0qRKdXpQoEGDAg80
E1SwUJQlhQohTnLt6vUr2LBix5Ita/Ys2rRqwcbQcMPsjAorl9Kta/cu3rwuN4BgoYFAgwkO9BIu
7P8zgYICKxhAkKo0QoEYBVHk+NABxdrMmjdz7uwZAIELFy8gkHHhggwOBEo8RECAh0UCCDAU5ODa
Ig/Zoj/zJptjAebNFa4aLm78OHK8ASYoYGABgYYFCkQkmJu8sAEKCk4sQPBBuokEG5BH0MDaY43o
GXqzb+8+bYkhBGpXMFihfsEXHA7yyBA69gsHEbAeaLsdRJqBBRFAGwbzTVSQCioAwAFtE+4nkIIE
/fcehxmVoAEN750gwnUlmngiioU9kACLLYKgAIwxyjgjBC22GECKdHVQYVgtdLECDlt1yNUIGXRQ
AR4IVNGGEEBoMQCUUUo5JZVVWpkEEFIIYYUdCBD/kYMNMAzZFQcUJjTfhDz2QACFGFQgmgoLvlDB
hgaVQEAFGLxAAEEKJlgQaWWqRsASBjVo3361VVimQQRI6OeYHGJQQAuRFjQCAYPluCmnnXr6aacV
1KBZCDh80EWl7sVwwgpVeEGFlbHKOiuttcqKRBR1EEGDSZb6+iuwXLVgAY/BGqSBAaAquyyzzTpr
kwk/vJdBBRrYcFYGRFQBhK3devstuLYmIcQaEvRqbEd1CvinRi2sUMEHp9qQKkcwGFnBCu/SEBy6
a9lgXr8aofCBdc8afDDCCRdWAIG+jtDBBz/wu1EMeAiRRLgZa7wxx1ICsQYLQnLWIGwXDMhQaQD0
/8ABfhjAtmaAoHEgWm6P/pcBAoWuuUIONaQMgAoIsFuhyeuRptBC9xUk30MvE8BAtaMGfBIKC+Qg
8tQcFZCAwl17/TXYNTkRYtYFpcewDERg3DHbbbsNLhIFnJsWRRc9+NB+JjeaqKMGsaxgAj4QsMVF
exo0hNAW3Z0bbXo3OoRFjst8UQkFXBuWBxNAEIABnXtugA2GoJWeZGVztYOmYau+OuvLOrADAAKY
fkAbVFJhxRdeFPE277NqEoAJvYNLxRtzqyV7QchTbQHZWcMg90kJxEAGGZRkcX0WU0xRAw5TjDUC
A11gbTpXAtDgROvpq7/+dToI4P7UcUjxbRFSfP9hxZPCd1vJBBmUQAkAARiJLMhgCIV4hP4yVgQs
nCct73vgR0LAgA6QDyMhABhHDBCJSGhvCmb4IBe4EAkQCMIRX/HPDCpIlge6j30ufCEMlbKDiQEr
BGtowtu0sIcvzC+BUaoEBQCIvQ6aYQogSEQhdudDjbUBB++hwQKMp0LKoQkjDhig9szQhzKUYRCD
KIMBcKAGenlkJBWQ4hTF4gMIxLCNbnxjTTxQRWDZIApLjNK4XNAGHLJNEzH4wwe1GEIuliEDJETE
HTlGhTV85gYWIGMaOfIBSALAAR7wwAM24AlOUMAAD/CAAxwQgEL0wSMxsMBbIqmWGzABjq58JRz/
IxCE8Y0JBXVI5KyQAAc4zMFbmQilAzYgzGEO8wFi5CMuNSaHE6xlBF0oiSrL8oAWJOAGOJBAA1ig
TQkooAZojOZnOqAAWJKznC+M1q9CgIBkfosKbfjCxagEgQlQgHMPAOYGQrmBURaCVl5AAEADCk8w
sHMAQshBWWCwgAU0EJwOfehGBlYwc1K0omFDp6VmUIWCcpRWSQgoAlxghbUlEwhE8EoI/tUFGkLU
LFAYwyUCQQYAvPQAaqDpGCQxhkgAABR8mGlL1yJRixK1qGBzgAZY+h42IKGjG3uCGPKAhihBNQ1Q
RcBUB0AFqYarCF74QhQIqj8siGkjLaABvjCg/9SgruWlM7UEAhgBgE/c9KU8nasKfspWtMDIqH79
a9cMYAFaugcCdnQquKCKBkhYVQx+mERj/TCARhxiq1nNoRB2iAA4MAkJQBBrlcAAhDlk1gUhLYAP
OpCBte61ta69iA1UANjZ0hZhEbBAWYdUgiqQFLG+XaIUmPna4RKXIwyYQG2Tq1yDbaAAue3QCIjQ
w99Sl2NNqAIEiqvd7RpkRMv9LngN5gQF+EoBH2hqddNrpSZYgQgN5S58W1sCCyQrvPa9r7M2UAHy
/soGawiregvqVTs0gLXxPbBD50sc/DK4wc4SgQZKFywY/GANaxACaAPcrSIgwQoIYIMNvongEf87
NAQ/WEDqHKziFRsMBARoXtmK1AE2JEkPVRCCHICAzLedgbRRqEIdvPSDMJG4yNptwQJUkGIWM7nJ
tjVvKuVrAREbucojLsFC6+vkLXNZdQaIWjQxgFArk3nEKPjBB0ww0S6zuc2tc4ACdnCC96YzMmW+
M3FDQAM8cc3Nfv7zK0WwgA+o9T0xKABh8azoKc6AATtQwAMALelJ+9UAEtiB5agMlh84cdGeLlsG
ThCECohgzZQ+NaqV64EDWEDON0g0RkagAUp+utbtgUEHNLAFJ1Ag1b7+tZ8dMAEnXGEHDPBBAWyt
bFLNIAcWcMECDoAjYFO72qdmwIJjsgHtPLv/AGB67rIXLWMGEGAHTICAlq2t7nWj+gEWGI9eMpeY
IHzA2zjIAK3Dja4M1KADDCgAdJhwgOqwu+AGZ7cJJICwDSRABAqQQAEKYNp6F6ADHbhBBsBt6yJl
AAMdOEHEAXqFAuxXAQlI98FTrvKVtyQCFehzeBluoxfNqOYRv/nNH4jzm4+35jKqkY1QzvKhE73o
djFAAUxt9KUzvelO54kCDvD0qVO96lZvrmOsrvWtc93gWek62MMu9lOfALljPzva067iBxRgyWp/
O9wnvQCYxx1Uc6873vNemLuzrwFshAkEGpCTwJvoAQzoCeHxwoBIv+QAjPcJ3/Uu+cknJfIz/4n4
S/7NEgIcoABSZ0kCCBD6lnDe8y0J/ehhMgECFOBppIcAAWQjeAFQIPax77UACiABcse+vp1vCe8J
YPbcx74ADSgATCTAetZrigEQJ0CylN96hdPe9gTA/UsaYHvlt0T6BKD+AZxve7P/niXBP7wANM+S
B2RKAKtvPfrdv33ow4T+BiAA7GM//JpYnvL+//9N9F9MYF7Lcd7mSZ0DXJ/oCcD9kR4CKiDXNOBL
6F5M0N/mJcv3gR4BsITpsYQBIECk/d79TdT9pc7xvcQDIADuQRwHfp4AXF/9UV/quYTwtcTqbR72
tUT5bR4biWD7eWD7JaADOB8HUp9LGF9LJP+g0NnfBgIhTgggAEahFLIEFBbdDvLEDW5KFU4hF07e
FnahXnyhcpFAChiBGYaBADxAGITCcZChG7gBGZKA24EhHdLEFiZA27GOBD5L+LmSGCYXGaaAIBqB
AChBGRbiIQpAKKQACbAECTSiABwBI7KEEaQAGjoiCUSaAzwiTMThI1piHYZiANLdS0hg5/0bwOEe
27Ge6Rkf6yWL9j3fYNzf8QEcBERc7GnK6jUAueHe9+Ei8t0iAhTA4bGf+KHfHuogMbYe/gHj+j2N
8qHfKYYc7hkfLv7gLvbi5klf4+EcYMhf6iygS9zfzVmgNYac2d0fA8QiB2pfARgA7DVAAyD/gNQJ
IzGyhDu23uzR4j3OxB/WFhkegUsYIiEKgCfGIUuEgSB+IiRWohK0RCgcpEC+RCAKYiKKIkbGxBaa
IvKxhAiC4AS6IBKWYhMKwA6a3gGUJA1qmf0hQH2NpBIyoEp6ZEfmngvSH0zS3w6WXwfapEnO5AXG
xBXWYPpBwO7BxAc+ngRSoAY6QAnCRE8SZRZ+4EvGX+4pXDL6IylumRE8IgmEweNlpFgixz+yW+jN
IU30pN1t5Vi2pdaVpVvuBFzGJV2u3FwOnguqHgGEpbKsHl96SkoWwF++hF8axQH8HV7cZV0uJrsp
Zk0kYKThX0yY4tMcgATQI0ysYwIcAALs/x9WAIZlSt3qHcAE9OMyOl5KMsABrMT3GYD2zWITpqZl
YmbjHdcucuC/OR77NQAFaJ9H2uY3oiBopqTgRUBKSkBeCkACquYBCF4DJsBlIucLIqZkEuYGpuBg
Vh5bMiZ32uV2+sQJ6iBQcqQykiTw1eT6IQDdYSdU5qUBmmRNGiB50mT99RnsteDr1SdL3OdLZCDp
1ZcF0qAROiEDuqQNFkBpVuCAMoBVLoVjdieEotqDcl0CfmdxTGiEZuifYWiEcqiGfiiIhqiIjiiJ
lqiJniiKpqiKriiLtihtTdtOwKhOyGhO0ChO2OhN4KhN6GhN8ChN+OhMAKlMCGlMEClMGP/pSyCp
SyhpSzApSzipAECplPbElPJElcYolWaplWoplm6pl3YpmM4ol4rpl5JpmNaoUlypma4pmpZpm57p
jY7pm7JpnLppncJpjsrpndJpntppn+Lpjurpn/JpoPppoQJqjwrqoRJqohpqoyLqj6apoj4qo0aq
o1oqpAbppGJqpWrqpXpqpg7ppoJqp4rqp5pqqBbpqKJqqarqqbpqqh7pqsJqq8rqq9pqrCappN6q
rvLqks4qrtZqr+bqr/pqkwLrsAprsRLrsTrqc4AUtEartE4rtVartV4rtmartm4rt3art34ruGKr
BZDqnJbrnprroKLroqorsz4psi6rsjb/a7tG6bvKa7y6q7Hi67yqKbtyKrsigIu+BMCyar+S67ke
bLoi7Loq7L7Wq77eK73ma8Q2rMTyK8P668UabMJu7MK2xMAGLEt8bLAWLMFmbMlyLKWSLK0ahcWi
LMa6rMZ2rMymrMmubM2O7M0mq8riLMye7MyKrCsl3ksIrU0YXqcsHkwkAGIC3uzNBATkIF4ALbzu
rM7m7NRarb1S7dU67MRCbMvO7MuCbczSbM/abNnyrNj6LNmmrdn+LF1QJQO+Zu65xkskoIHmXkdi
nrAFZ11cYXniRFaiSIDihN+WiNRmLdY+rNYi7tlWbeNubcVy7deuLeWGbeWOreVmLuZu/67aam7n
cm7bUu7h+gTcHiDe8iINht5L5m1NpiRSMqNg8mDsIcDsOUDrTR9NKp/+0af5jV9LaF/scd9L1J7t
4V74aZ9oLh/62e7yDahy7qX5xWdk5h/t/ubv2p7UdR7wQm/mfR65tZ7QHcXodu3iKm7iku/5Tq7n
6iqOtC+9ui/8vq/8xi/9zq/91i/+3q/+5i//7q//9i8A/68ABzABD7ABFzACH7ACJzADL7ADN/D4
8sQH3hwCUB/mrePmIZc55i0rMt/QlmTqEeULppsDqO5P0mAPIl8KsiQGGmEWxsQD8Kfrml/8sWAS
mrBLsCDSMYYAyGMG/yd8Pi8pznAQh/+kAMCehRoFwDYwEz+wEzcxFD+xFAfw51Zx6K4v2l6uFWcx
Fjsu23Ix6ILxFnuxFl9xGJNxBO9E6R5h3nbe520wB6InTBTuCAMxgwLxUKawTK6ZCL8w6clgbNYk
U7rEHQdlf9bePWVKSQaoTiLfU7rETsqxT7KEA8wj1CLF+KrvGUNuGYuxGY8xJ3ut5I5y5JYyxZ6y
KJtyKsdEGuvEGrcEAb5g09If8ApeLMsEuR1Ac74xC/cw5+2eTrKeZfpn+XEmch4l7dFuc5IbVHoe
LwZyAXpe+MHiL5Ob0E1A9QrAZVJnL5cfNjfALhexOMNy9oLzZV6y+G4y434xGXdxKKv/s/k+Ljyj
rzzHMzu/Myivcye38zxrcj7b8z7j8ycPdBa38olmMimjcvnS8z3r8yo/9EL7M0Hz8z8zdEA7dD8n
NEQzrEGbKEKrckRrdEgnhUR7sklT9EQL9EmrNEqvNEZXdEm3tEyzNE3rc0eX6EcrdPqK9E6TNE/X
s0W780un9FC7NEAL9VFnNEj3NKLeNInm9EYDdUzXdFJXtFEHtVLrtFT/dENXNVF79VVPdVHPtE2T
LlAixeASboOqNV4EbuC60AOEL01A9UhrdVdjNUzvql1fNFiTdV9TNV5/dWCHNVfz9WD79WFzslOP
41kfRVrfBB3bRGQjhVs3dqe8p1GE/95I4gRdM3VU37VY/3VWf7Zhh3ZijzVgm7ZqFzZSnzZAGzTr
PR+Bdl7ESV0stp6mxHbrXW/EWXMCDt8gAyEuqp86siN8luPslR854mKybLYNRxw3cqDyjidgOONv
w7LzEh8ukp83Ni10sx5N1rYxRmMaAhzrRdr73S4QHt9avyDXiLBNdPZWL/V87/WQBkD74neU6jd+
57d/7/d/9zeAD7iAFzh/H3iAIziBK7iBJ7iDL/iDNziET7iEVziDX3iEYziFa7iFZ7iHb/iHdziI
j7iIlziHn3iIX3hHr0hKSh1lwjIDeI4Np+FmGmAhB2XqIXNLsCdL6PD1eU4j02D2Ov8ySALhYCxg
CB+A55hedQrADLZEMmpejq91k78gcg2l1HHekmfvTBrABKQkgH4eEZ/wI0Pl7J0lZ5M4iqt5irc5
m7+5ibt5nMP5iec1fYM2a492XZN2a6/2nQtAKxOxfEJzO87xIktdP6bh3Ybfk3tgkaefI/8gJKNn
DX6kUjZh6EUA98I3D7YEfzL2ESY3AzR6p5Me1wylBnumOOdkmHukSvqgTCjf5/jmTcg3nv95n+e5
Z+85r++6r9c3n+v5r986K9uEZt+cixN67+JipB17bUv3d2sZuc1helvjZ96cNHojdwPh8qEnBHRm
Et7ubqdh8ekeddci36afpE9gB/v/nrZTsrgrO2dGnPbVl/Shdwfv41knwKMXenwLO7D3esCfL2Hj
OsATe7DbuX0ffGkX9mIfB6f7xGTbBAYXRsTXxMQnjK03vMErfMIPPMgjvMCL/LBz/MJ7/MgD+qew
XdMmBdHmBINm51KwPOK1fNhsfK53vGD7OVLw/McX/MnvvK4Lvc4DPaM+fIjiPMPnfNAbPcsOvdOX
PNP/PGL7fMpP/b+CrMcuPdejvNTPc9SHvMlTfWpDfdWbfdn/OdKzTgIu7U4UpsS7vTkpvdeLPdZ/
Pd4TfdOffdHz/d6n/d+jdlmz2CvbxDPLPTnRvd6TveCLtuO79uJffddHft6HPcnb//3kW77KmxMT
Mqfr1W1lNqdMOnl0Zjl1yv0N8jhFKb7m3z3m132kRrHsTzHtz77t1z7u377u5z7v777vK/Dasw4T
QjlQcroEli77DYYPg77xWjYcLXHvR//vT7/04z7sj73kX7/rXz73Y3/l+z1MBP/qDD+BCqh5FqiW
lWaCxiAht7crsT74Zz/lvz79t37mx//3Az7jP77Vl7z4A4QAgQMJFjR4EGFChQsLEjAgwACBgREP
SiBwsQFEiQIbXBzY8WCDAgYJHGB4EmVKlSsNIkgYgKUAmCxnrqyp8mbKnCh3nuzJ8KfNmEEVEn05
FCnNpEKVNmX6FOfSqE6nQtWZ0P9lTK1buXbV6oBAAq9jyZZFmPWgUYRq00q9SvWtVZ5j2RqsW/Au
wbwD9wrsK9PtXLiC5foMbHgw4sJADwtEaxZyZMkDIxyYMBlz5pOP8TZe+Be056Kij3oNnZgx6s+k
17Juq3o07NKLV8tubfv1Qc6aeff2/Rs41tlVicctTvi44uS47bpuzrwzdL3Oo9OObX24ce3Ityvv
LnAFAvHjyZc3fx59evXr2bd3/x5+fPnz6ddHvyI7d/3e96fGfvs//gT0b7naAnzuwOoKvG7B/AY0
sEEAI8xtQgQrVPA7CAkywAIHCcyQQRA91LA/Eh8MsUQUTxxRRen4om46F/2C8UX/GQGz8bQEY9Sx
Rh5nxJHGH328saAJTmjRxA9TZJFJCUV0ckkoV5RSySkp3CrHC3fUskcuhfSSSDCzfPLKKMu00kIy
0zRzTTQxFEACE5KcE8k6mzyzyjzpvLNNPe2kck9A1woAJkILJVQmRA1N9NBGGX100UgVndRRSSul
FFJMLc300k45/XTTUDUd1VNRSyUVVFRNTfXUVll9ddVYVZ3VVVlrpRVWXG3N9VYLEtgVWF2FvZVY
Xo0Ntlhkjx122WSZVRbaUQXl8003t1SzWj+pvZbNbAPF89s+w/X2T3DLFfdccmeLgAAHrO0SW27f
/TJeeLuVV9tp9TV3W3uDDLNe/3rv9TdffvdFt1+B5wV4YIULRvhgdSPGd1yKY/PAgggaZnjhMTf2
uON/QX5YYoNDBhLlIUeumGCWHXaZY5ItTjhmmFdOd+bWQGBATJF9TrlnoAOuGeeWg1b5Z6SF/jjp
o50e+maao15LAQWUvvppppc+GWuo6Wra661lNlpqsLXu+uysuQazABDEttnstcNGW+60sYx77JeL
1rvst/cmum+68wZ8YrIL57vwCCy4zO/A1R58apMhlrzkyS2vHO7GDyec8pw7N/xzxEPn/HLPSwf9
dNFTJx1z0wUCK4LIV5e9ddRrV/121l232AMRJChAvAUWqJqCBIx/iCAPjDe+6v8KFhDPggYgqIv2
v6u3fXfstcc9e+631/37670fH3zyxS8f/bsoqMB8vDMX/P3Ha9tgggZWKECBBDTWLAETGHCBASJw
V+7+Mjv3We+Ajpub/BCoudGdD4IoMYEEwpfAzUXQgQZUiQdYsIIGUCA4CjEACz7QgELR6IQpBIwK
WbhCF7YQhi+UYQxpOEMb1hCHN9RhDnm4Qx/2EIg/FGIQiThEIxYRiUdUYhKZuEQXLmACTZSiE6dY
RSpe0YpZ3GEEWECAExQwOB7oSAM2oMUTXtCCD0yjBuHXwDYq0G5xrJtBLIC8CmaQgGvM49sgQAAJ
DDCEY9mAAkqyv7+xkYFwnCP/5PTYvfQ18o5vRCNsHKCBDSBygZmUIyOFFgEFaACMgTyJBwpARpph
cpPx0+QiVZlKNyZykpJU41pGMktZopKVrwwbFysASFHyZgMNYMAlc4dLTt5yj8h0JAaVGUlY2vJx
EGCBIo/5TGO2smMiKIAdfxmcByzAJN+7pi5dSU1sVnOV6CxnLK2ZTIKwAALkzKU55anOd0WgAvHs
5j4FAIICXDKUzkznOQlaz4LSE6HsHKhByVnHgyp0ndBcKLUcsICA8tMsDyiACL6Gx2XG7QHLE+ny
FNCAqilgAiMVaU6Y2c6PelSgER3ncDagAV9CdJ44tedOv7UBCzwAo0ElyAYW/8BNSLYPaMYzQUkX
YIHgLeAEJ4XA8oA6mQgsDwQnlYDwPoCADyygAsRLgLtaOlGdPlSiMk0mh9T60mYi9a2AiwADQChU
uw6ElMQ86iNhc1UIKGABGkBAARiA0oveNaQKYMECVrCCBbAgf1Wd6VkZmtC05nSWIshIW2OK2cle
1k9xuutoCbIzoDwLtc5SbaZEAAEGCHYBEpiAZEkbyKsqgAGNHd5UVxut3qa2WcH1rXCBO1zjzooB
Jjjub5lL3OYu17nRNS4ICKDX2o5WcQYQFWUta4ADVAAB4BTLdclbkN6d4AMakAAIDAlatH4Wvu40
a1oWMN75xtetLu1slapWXv/yajauHjOARQjAgglY178J/owCCuCCE0zAkGXlLFz1S+GAReADN/Ws
fCfM1wAbpAJ1JQgBEMC4gYBlIwZAQLsIUoBwEkQCPFuIAwog4oMwgIICeICIY6wQhwiAAgXQcEoo
YhCMtfe9BEwACRcAAdoqGMpaiQAI7LcAESCYp5Xl7pbdWzSM2bfCHg6zhNemOA8chAANQABt/Zhi
BFCAAPoUgIsNEgHJJuAAEEAyRCYiADyb+AEaM0ABtqkxOw8EzwcA5I/5DBEDPNoAkp2AZYp0gAQU
uc4s3rDpNgABDWx0yFEWNVmo/AEWnDnJ+b0vhzeNPdOSOcuWxe9+DcSuUJf/ZAIbmTMEiqzih5RS
IHQuyAFG4uuE/FjF+jzARoRN6IEQWyD2BbYAkK1rjtRSJAJh12WyzRFrGyTDrX7ZAwhZAROPGt29
CQAJTdhlWbM61ly+XH/FvGpVdxjWBnIoQkoigD4KgAEZ6TUCkLfsOb/42bVMQAEIIOOGPATTRW52
LQUAbTgRwMUMqGW1T0wAEWOc0ISOJ6M1ohDYxftKBngtR9Pd8l+qXAMsrze+95rvczHAbRamOUx1
Lu4bhdjH4bSIjAduxwSsGOECsfhAfkcSiOta4uHsdsWLTQBDY1wgHIcTxQWi8RN3neIMXwhbU/2i
BAjPxi5Xezcf0EUW7Bnl/7PuedzhTZAIaIC2Nn/3vX0eQWmO3ZC0taNRIbLnQ0PEMkMe/IYEEmhE
K1oAhxfABC5z+MVHANKPvrOliwQBdxHeIPTeuwA2YBEwrx31QXXACQpwF73Lu+5a5tfJ+U732pd9
7jbbwAfgnnqMagDV8k6ABSSAZd8fH6OeTrq7YX972Y9zfcyXvtxn3vehwBP5o40+Fo3oaZlnH/x3
9cBjuW/G8p/f/OnnPgskoH73ox/+75d//F3Q+/CL8gM5B+34l39//wc1ATRA/2jt+WJv9ObuwQ6w
+myPABXwLxTgSDAK9HxPAfpP5ySgAexPISrj/xDiADTwNz7QK0RwMrRJr/9eb/oMsPnsJQK2qQCd
zwFr7l8q4Pu8AgLSTiEoLesmcCEa7gAY4CI+TzyeDAIGy8+A0CSW7QB+BwFyrCzOLnA2wNwO4t8G
AnikjWcwbSyAh+uyjuC8cLOUrgsTQqPsiAEs0Md4UCUgYAwX4gwHguS2Ig4l4wEcCgWp7w7lq5KM
DwZXMPdesAE3x1fMYqqULgLYkAGerDJ8UGMcAhFpi9gY4PSy7sWcTcUsgiASwI9qyeAqDuq+sCwe
4Ns+ipTUMM0EItcwUSM+zyEYzgUFIsgwrq4goAFyreEOgtACbsRyDXlKQhWpLiQuosb8jQsTEXgw
DqiW7SJezAGAEOuoLQH/nNHEYnEYdcwZw9DbBmuzYvEUC0KjVqwAgCospHEgHsAZ+2/QMI4XrTEd
eUYZnZABVA7jDCAWHS4hNqCwZJDnFjB+AqAN8VAfP2wfP+DJukLY/Oh15pDaXgwhBQAsHqITBUCY
SEICHq0jgMrXOlEUHcDiOnHZHi3XsJEsduN7Fk4No43FwoLaLqMAckzFqkoTg80J6Swim64gnK3Z
TILR+u3oxGLpDuIhIQIUFxLNTOIX4VDOfqwlrVAnndAgInLaHFIh+y3rkvIhps4mmU7XHuALX1Ig
fvEg9aknv/IfC6IFTxIg9zEPd2SCdk4g3zLMCNIsDtKOppIh6/LXzvAA//ZSzuBw+YxNmMDCJzlx
IyJyMkhyfEQLJRjgDGsp1+BsIqBuIwhgAjJPY5buJ4Nt4yZAF6mtFxlyL8fQ9NwF2YaSKuFstg5u
zpxyB+HwISjTMhtvjJ5S11QSKUniLl1zzhog855sKXUT05aOLgUiOMvSLhYABPswBZUzLbFvLmBC
BwQgOkMtEJezOtNySAaxLIazNW8yDEnuxyigxKJtz6hyQ0ARCBkH2iLAIiByFDPqPbln0JKTIMBi
zawQAeQs4jaiCHnNADYLM8fQ2aTS4XYS4dRsDDXOAKJxJysy2OLR3zzuP/sNLHjzP7vTM/0tPy2S
IyxyFFUsNcXzABY0Kv9bDEIztDVF0UIP4MmOjjdj8ekSjim7szhXQjEZ8A9j8CQ2gKRMCrBCLgjG
A+QK4AQ6wEhpIAOSFASSlEljAACeFEqjFEqlk0ql1EoBAAWYVEuTtAaMtAN+IOQESzyCIOSYQKqW
B8HW8jpVcHRosJscoCAPwgCoM8GgMGIArAPzFPlMC0f5sQCvCs8aQAUKwKkQ4NMYwEiTFAWulFEb
1VEfNUoFYEohlVIrtVGzNAMwoANYr1CvoADCSgGKJ/jWlDnZdHUgUE/3qQL55EZT1VXV7shwz0/L
RnkOgMG2wFAXoAOQtAUs1Vd/FViDVViH1VIzYAY6wAcKIEgLwExTCgT/1TRHL6j+XjWQwi1aGKAv
qVVbR+0BPqC4vvW5igsElqoABGsHCkAFOiADYIBY29Vd3xVe43VYRyADbKADmgoBVsACsHV6wtVf
pQtcQQVbt/U31gdRDGb7CFZho+zvdNRHDEABfscFGk5dR0BeLxZjM1ZjN9ZRYcAGwNQFrsBME4AP
oXVW12L36BMzSHDYVLbiXDY4gM9OMIwPucIcD+JmUSJnu4kW94lF74ojYyJotQLo/HABDcAEVECw
CsAHaMBJORZqo1Zqp3ZjW+BYF2AHyFQBTABmo9U6ZwRPRUkhUfQkxpafbHVPwtYstDAyiSw+NSMi
M3NbIwIt3bZuByJh/7ETJ5C2AoJAA36gBiyWageXcAvXcOM1BjCgb9ULBGr2ZL/2RnBuK6hxFmvx
IhyOG78zATqiIVHUHJdxIlxxHYftIqjSHAdNxpQxEWGR4bpRKzxAA7SlAWpwIJyRMrvud4SxdjHu
FjWijzCCOHXNIhjOCTm3zQyCxng3x36wI0wiHZGx63jXHgsCCFfMHUupdCXLds8NFUuX6Fo3HKOX
4R7CFnuX0cr3dn23dLkXFkt3I9CXcSLid2932VZMIoqMebOXEv2y5Or3IkTRvjqzIDYAP4xWLQLg
ABbABSwgB2YgBA4XgiNYgic4WGEABxhgB67ACSZggEw2R/ZtJX5TNf9rcgy7zTxV8cewciR+kStN
0XnfLCE/zqimbiVSVlsIoCBbWDejUthC13k1bc6ycDIrsSkHItcSwgE00T0Hogr97NsGDQ3jVteg
TYcxNOuwsYljso/AzHVb0+uskIIiYoDYViK78ItlchWDlzhBEX+neONAs+SEEnmOmBgTAoRNFUMS
QAKugAB+IAMemIIDWZAHmZAbtQRooG/ziU7x2K1sjSVgE9Iuk+KgDSwc1CZJrgqV0kI1bzVHzKhQ
E6jobD8z7yEq+SGyciXCTVvqyyAiYs96mM76aIBE2doIK449jiRMjI4JgjF1M0ANQpaDLYrdWEZd
mSEmwNnk9nXUTMT/kHnjfg0bgW0/DaJEd7PFBE4y1xh58HeS35h/i+4jGkAUFUKV5Y6DlJUBbkBw
C5md29md2RkGOkADdsAJ2MuApcLMVqI/ORQYxVDHNpTYNq4AKvMAEGC8fkxFH+1nXZQex7cg+ogC
JvSHCaIjIlqP/5nXApolHHlFVvUpm3AJZQyWTWICQJrQfrglNTqONbEBQhMWEaClhWkUmzfGfuwn
kfAAWnryTJomp/efJSCefrniQLrHbjI0awmndTqnlxCGXUylGe2kiW2zppmanbqWonraqJra3pCb
ZXSoJYDY+g3TfBA/JxGvYpe76IcJyBQHSuCd3xqu47qQQ6AGfGAH/zRAAZDHg0EMBxeWJWJ1SfKW
Wt/WrwOpALL1oacJoihABXYgneUasiNbsge5BTqAADTABBaZkf1F9Ap7JdR2ShLQs0c7OCLiFRHC
hi+II7dAA2hgUScbtmNbtiM4A04gCJigr0sVX/aQtE/iLEeDiCJgBRy3t4v7NxaAAqYoq77qBmbb
uZ8bugu3BV7gXKMo/sqvVY27tBighvbFH7UbvEOoLetktRlgBqIbvdNbvaMWBTBgB5hALPRurnJ7
tPPqbk6C9qDMbA3iDQFu+fZbMhqANVli4TR7IX7Qv2b3Qw7xCiygudcbwiNcwi+2BBr7BeLUsnwK
wxeWqO6WWn5bv//vNied7q7Mc2WNE6Pu+CgG6QN+4LUnHMZjXMaH1QY0oALMGo8r6bBST6Nol0bG
e7SI9yB/xxUFoo8aQM3CacQbgsj/t3tlGgdLidAwjsib0MjTLMmFOeuafCS+EXqpXOziOBIJDYY1
IuAa0rQZ7oxHKwCQkyEc4AVWAAcAecbr3M7vnFJjoAIEkMsmwAJgAp8Q+1X9CaA6SiVaEMd/qUJ9
yTbJ1gBokdmU/L/t698+EiRHUYRtUwsfHSRUExp1kyjLEc/EujC7WSMi+tEcgislC5WFqsNN7gU+
YM7xnNZr3davFAb2fABvBmNoNwC0ycN5HJwcaXYwhrgDaeFkDDz/X5Nx6HjJR8y+MNEwcTE3b7nZ
Ix1DDVTpanOi+xkYxbggvBLsRosF5AQhTEDW6fzW153dbR0GhMcDQAYf3+42eMnAXS6Yhml1NMgA
ikoCQS59lx3gQE4Vnx0Oh/cZ4WSwGA6xe5jRigwICa3gw0ngLy4cNTHkaNmfNx7OQk7Gci3kaHif
8EkEdmL8FsCt213lV/7WceADzF07iG3D6cWTQAn5SMmUNgeRiGoAw9vnFaIMhYS6cIDli97obb0E
FkAFDHwmKEA79aSP/qjlBqmQBgeXGOzef360PamX9OIAPuC8j17sx/7OR+AELGBUDQIEhj1CIsAE
0mzHNUOMCEAB/449e6BLVCigAU7A7rVeYSHAAkr+UBpAA56W7A9fWDEg5TW2AhYf8d01BF5gcRQl
ASrgBJL7XyVlAjro8oVqhFYgnwD2VLZMo1gg6/0+T01AA9JOBAggAx5/xi9APGRASlWAADjAcC+A
AC7AVwkAA6B092FfXkPgBBbABNDea5+DfuwHf/SHN/rnfwJIw84nvgbJAugb9f/PHBcg7THGBoS/
zmV/CVwfShUXA3D/SV+gdDmA94eAAKKU/GXg9gmgAq40+HXf/S+C9jGAxC7iSQFCBoGBBGQAOHjw
AgEEAy8AIDBkIAIVCAVyIFABocaNHDt6/AgypMiRJEt+jKHhBv+KBQoECAjgMqbMmTNh0rxZE6dL
DyIkFECAYAFLBRQSGDUw04NRowoUVFgA1EIDCDZ1xqxqlSbWrFa3cnXp9asJDQ0efD2LNq3atWzb
un3bNoIJAgoi0HQ6wqTevXz7+v0LOHDfCwguZCDAA4AMDgAwMH74QiOBDAAqZATAAUPlywBePJbs
UGFiAAoTFj5Y4TPmyBsJaD5YECEBh5YRehaMO7dukytzcFxiYQLbsFyJZzXedbhyuC+Xq60qQgMD
pMyrW7+OPft1BwroOvDqoMCS3eTLmz+PniRhhwKXEDjoGLZB2fMLYrjMgfXH2aTfJ/S/3kEcUITQ
gBy5JptDsDn/lF96Dj6oVw4LoADSCBVA8JxzaSGnE4c4eXgTiMVpiFZYICxQgAh2acdiiy6+qFYC
DRBgwopgyWSABi1AyGOPPv64UYCNIQbfYyVghMELsR1UAkMI9UBAZvcpCFp/CJUGWwWvcSClgRxV
4FoPD1HJH5RSVkAlkGrmdoMGMZikwAklkniWiDmtZadMeXZI51ccbgBBARpAsAGMhh6K6FsgMOCC
BhTwKcCJIaxJaaWWXopppprmVoIGNPg1QwU2Qpohnn2OaCpze96YKloTMNoACInOSuuhHiiggQYH
ODDTiQs8qicFFUy6abHGHotsssr6NQIDPhALWKijanXqcdUm/9fqW6s2l+2cAmwgAqMnTDBtreae
a5UBEhCggQIeiGgAAwSIQMEC0C6Lb7767suvgxhYsONu0n54LakbFkywqgiHWC0FCliwAgMQeIBu
xYhuAAILGnzQgAi83nmWAxZQ8MMHGOTVb8oqb8oBmkESNJAKYsKHEUcYIFgZzhqBmebKDs6gwQzp
5XAAw93WuTC1R1sLU9PNOQ3101JHTfXUVleN9dVTPxDnCh9UoEAC5VpMdlYGQNCABUE1EEDWbmvN
wKcajdDBBz9Q6HPeKl/Qc0IaXVDCRiVcMJpHgLfWt5CoPXazlwdZtOVF8x2kAs96o9eCBa89OEJw
Wr8N+ueih/9O+uimh55wqaof3K0HE0gAVQEnKAACdWXP6kACB8C+ggYnmJDAVQt7oMG9HdnwNQyX
L4/sEpQBoMJjkh+UAQLj9ZAZACXMF5HN/EHv35gcKQ6bZjc/NAT172WPGQdNBt4YY98zj1sIPjCA
so82qKBn0iCzvjpvwWVbBPRf/9CiFKcswAUuEEpTJpAAit3OKhtgigIYsICFWABsEETa0mbyAhzo
ZQYFKEAN6BeYEWRghRlQHgpNUgIwcck/7MMMzGoGPi6dpkqyec38rrTDg/BgMkOCTQaGGDj2cQkA
h1GMf374Qr7QQAPwW9MINGAWbgXQg1v0kwENJkAAijGMZKT/SQSMcoCmsGABFliABoDCEKHIcQEM
aIod74hHBaxxjiiCYwOFUsemgCABWTRaF1GFkwh8AG99gQEDPmAD+mUABx0gwhsQYIcqtEEIQkAC
EICQhAGIcpSkLKUotfBJL3CyClVAgAuIEIcO1CBgefueCmi4OSVxhH0yCCJqOHOY0UCRNEEcAgLm
cz4ADHFJSnyMQIgkvijuBSU30NQPTKDFMXJRm1784CGt5U1sfVOc3ERkOcE5TjDKxAEfMN5fUFCy
DuQvWSGYwQ/e4IIqdBIMpuynP/8JUH8WAQhCiAIWXMAGGlQRXzx4QQVk0IPXDOF5B4nogCY3hAqk
DwMz0wgP/xzzAoo2pqNPwoBJMSBSJm6uBBSd6EGGkL6DLKFwHJVmSXrjzkvh4AUFDKc6u5nObZYR
qOck51DNeVR0FvWnSI1Jjs4zAgzYjZaWysAP1oAFIZwhoFztqle/OoAmSCEKCLUBI22KVr3loABn
NVYNCvBFVgXVkEsVql2JmlSj3rWpeN2rUvP606dCCHkVcCGPRkADPOhBDk0Aq2MfC9l/AiEKdYjD
m9KK2XzVwE36qkEFfJq6utIVsH7Va19Py9fU/rW0TF0talfLzpz+rIQnNE8GiLAGORQhsrztrW9H
qYUorEAC81xZBRaKkOOWRLktsEEXPgCUEkp3ukDRQAFk2f/WzHqkU3Lj107nqjTw/o+0rzWtas3r
2vO2Fr3sXa97Q+sSC1yWUjB4rg1ka5LbVgEIv+2vf32bBCGsgbgrG2Y0QZKBCnzABR2g6l5QUAMf
rKAANMguWpvVBfzi61eiDW+Hx8vaEI9WxB4mb4lJDOLyvnfEeIWADzYFzxXIUy8K+AAS/ovjHPe2
CVYgAnIfpKSLsOY+txwI/IIcJWEuZiCf+Z5FMIICDEz4AwNRUt9kiEOFROQxYBrIfIK8YAvUVpoY
KICDVYaCHXz4gOJl85pf0jY4Ny3ObZuzneWM5zrnmc58vrOe/9znPfs50IAetKEFjehCJ5rQjD60
oh/d6EX/O5rQCXCBhis1Ahx8wAdn1ogCqsBPHYt61JAVgo8hpLPsJTN+QYqefBCSTP7UBgYW0IAF
oPeZIfbtStkjDPyaRKY0XcDVMHhKp1WWgaChsANsm7SzJQ1tSD9b2tGOdJxZrF74otjNJk5xtrGd
3nCT08X6sgFGDJuBD8yB1OxuN1iTEIVhpYcA49lIfIqkPesd5DYHjrVDrrCCzQmIQMqEYkRG0+vw
KYSk+a43vw8Sgg5wNjAhoAAOAmCAjBvAAxxPgAwMQJ7MCZx+ae42t7ctPNCqWNsrB3d7Wf7tE7dc
5jH/n3xTdhgX3NjdPO95QIFABAvj5jAqMCnjPhOfIRbd/zKPidLSofkBT5nJpC4bYmYcCsVevsAx
CdcIBhCwdYcWfOmp6UgIuvCDvzyAAiAAwQRuIIO4x10EhviDbuxXgeK+kMMz97a4V0zzNqdc8HJ9
c+FNPnjDZxPxhUdAylggBOBa4QtS2K3PL395KugoX/bDH74yUAC9i+QBNSCDAMhABkpEIgusr8EQ
DMFwv9iAitrtQEv6fnLcJ57xLge831/ee5j/XfjAD3zx76QDAXxAAMnP1wSs8M8mtMEFQggl5r0K
hDlUYvuVyIT3M0EBETzi+v08AxEuDRjmCwAA6tcLDDRgWH3BIPQlccAMKEGG1bN+CvzPgggKQQmB
QU3axf9+ycc/yTd8waeAxud7x5d7NfeACciAxNeAu4dyh7dNzYcvI/ABjdVVReAFX2AFVEB+/QR+
bfd2cDd3EFAIiFCC/iQECpAe7WcSHcAA6JcsOTByHlFPqsd//PcHZtAHU0ABiVAIfzECC5ADOPhC
6qd7GPiEi3eBC/h7FQiFEGiBUdhThCeF3ZR8y6eByCIDUcBbUnAHe7BVJZgJQoN6qad/WSADiWAI
lveCpqQFxVMe7UeDIIECBVBNlxMDtwYSGzADWTAFQSiEXMAFZcAFF0ADgfBjJLFWQodZ6neAWHiF
EliFFDiFW6h4nsh7oNiJGuJ4y4IDbeBfQAAHd7BzPZf/ADOQeqy3f/xXAzRQCONXh/7UBGvAhOdB
Qse2Mh3QAR9BiIq4iGWAjMg4CDEAAoKQBXtRAwQwXwTYEbY3iio3gVTogFmIiV3YjaKohXHljUq1
AEKTLKcoamAwebrFbgGQAZRgiD8YhH2QBRPQgrkIULvYi7vxAy8mTStgYQ6wAQM5kCHQAyNQAjAQ
CSUQAIVQBjBkAd1FjR9hASICjt8ojtmokZuojdyoiRG4jZkYkuNITiDAGcbSAnbgbtL3BdWXYwHg
CFnwB4jYB4pYBlOQAIggCPgYUFIQBz7yfin1QgUglA7gAA9glBvwAA/gAUl5lImgBqLHERi2j5n1
fqEo/44XySelw5Wn45VdCZZfKZZhSZZjaZZlCZDIwgatyHMgKIIk6FswaYzHmIxlYAA0oAa4yJP/
hAXxdx6dV5UqowHFFQIbYJQC+QAYx3Ee8AAbMAFqEAkiUWaROJEe4QMScJaZWZabqZlSw4kdKZJW
SJKiqZUjWZpgVC/IggB1aIZ7wF+P5QEAUJAHiZAKGQkt0IwuuJcAJQTDiB43II2VuRExoEcN0AAs
IAEHAAEQZAAPkACGMAUhUQDmKJwjEYifmJUZyZEbCZKkmZ3YuJ3h2Z3axgR/uCkwgAV7CQRVwIpe
xZhIaZhLiZSHaQCFUAj56IH4iAQnqRsxQACRVJ0j0f8DD4ACHlACwBigfEEAEnSNXHiaDYqd4Dme
oDman8mdHmlaV0CZlJKSuzlKVDB5XkCHpbQJhimQG2AAislxRokDamB9fAlHd+AFcHl9PikwGrCD
CaqjPcIAwhGhDqqdE3qhoWmh4omh3imhR1qkuRcBOyCVlIIAI+qhYdUGX/CiogQGxskCyKmcE0AB
AdCUSzAIi8BVTQBHZ4oA0Hd5bZCjD+YDyrajcQokL1A0QJqkREqhQ1qhFPqgfPqddnpIDkAAT6om
P+AFU+pbjwAGc5CfXCUHaKqmmOcChCoSyNMBgTmRUDAGVcAICNEJFqAGAKCpVfCQAAAKfEAGckoS
GCD/J3e6p3rapxjpqrFqpHgKq396ThFAe5kSAi4gpYjqbq2UpgNghmnYc725FyUgYV3gl6raEZqK
CWMQmZ2gBp8QqpoaCdZqqqjqrCFxAiJAq0Jaq686rrc6q7iKleeqrjpRjpqCnsB6eUWwB1KKBF/Q
BlcqakjABiSBAjkQMdTZrSKhqWSgqQcQCGSgrdgqqmNQCdwasB1RkeQqrhOrpH6qMOv6oxmbroBa
VyapKTUQqfBqSk8gBlhwCKMECViQBiSLBYQgSlSQB2jAW0kgB1+ABZWXY1rwBjxYAz9AAJs2Zg9b
EgO7ramasNKKEJZwsEKrETFQACsSrhVrrlw4tRoL/6Eba7XhyBW6uqE/ggIfgK8iOwAkS7J+MACQ
kAaTsLJi4AdqOwAwK7P9lQRIYAUucAdtgAShVmosoEI00AEF0Ds/ALBMS7g98q0Ua6vjGrWJCxbW
5rjT9rjVBrmTK7mVS22XG7mYS7maa7lxdgD8WSkFsG5iO0okiwYk6wUxq7ZlO7ZiAAQxy24DxUlW
AAdfgKZn+gVwoElrQAOYWri/258WEDycS7yZa7ybe7ydu6RSq7joerXPq7VowQDmaSktoAE0KrKm
+7awu7psO0qNALu7KQS+AbzlCyQhYAG2g7gSy7zru7gWy7FYK7/QK6tpsQEW0KxrkgF6ELak67+i
JP8FDGC+A+wjh7u8jNu+CYzACwy/WVu/DvyRCsy+DBwAG1AA+asmLfAGWvC/HRwF5EvAIZweBoyk
8Uu/Jhy9EGyazpvC3vIABTCNmBYHUdC/HYyPc4AFgyvCO5wbIUDCK4yx88vCDyzERHzCQLw6EVAB
Elm9GuCSNpyLQIAFB8DDVbwbfQgsLXzEJawtQxzBFOzFSKzCP4UXmoICFaAHxgrFbSlg1GvFb/wX
NWABhbTFBzzBd7wtVVvEX4zHYczFe+wBFlBvmmIDaxAF2LvG/wWCdtAAlAjHjzwSFqIA70vJflzH
DbzHYpzJfxxiCjAhxmIDioWziRxZYEBZjQzJqdz/FzZgARJUyUF8yUasxbMsy7XMx7G6ARVwApRq
RYmFBTNKygCFBJRlWapszHsxAwQgK+5ryZiMcpwJzZ0ZzdMszdVMzddszVoDAhbwArxcKSXQAXhg
B1GABI1KumcgBK1UATfgu8ecyslmAtgsz9k8z9Fsx6+MwrasybGsuA6wABXgyOeJA2ywAvm0TyU4
UF5gUAigAT9QA97szhG9EeYmArfczHo8hRhNyxYNyxu9z9G7AU5wcysTAzPQASdABCvgSqxkBZwk
B58E0580BzH9SUjASW3ASlhQXddFAxkQ0BIN1B9BNwSQxRydz0ateBqtz5zs0Uy91Pd8ExPwAZea
/1mh0s5BjdUjATRO8DGbDNUd3Y1KjdRe7cxN/dVHLQAOwAQaELT0c0UImtVxvRctcAJX8Cj4PMZn
ndTNC9Zjzc/M3NcffRMGUAFszTw+wMRyrdh6AU8fUNGAjdZO7dcXzdeRrddkLdaCnS6CAqAp41mL
DdomQdcfUCOX/dcSjNdukdqnDcaBLdmaDcQP8AJTDdGWggIAE9q5/RFvZQHLPNlPXdbALdyVndfB
/dvHDdvqFAEicAUW4MaaUgFtrduh3QIS5gQMytp97NqmTdmQXdyZ/drhzd3qxR07cAI6rCY3IMDT
HdpR9gF8t9pmbdzJrRXJW7zIi9+dm9/3rd/9zf/f/23fAb7f9g0CJ7AD0wsk1lvb7A3HLVA3LCHg
/h3hAD7gFS7hAz7eyC3e873h4J3hK+wAB3AFGoADPx0Y7crgQF0DJxAETFDUH97hxI3Z5Srj2R3f
w+3dM57jd5UAKhAE03vVHEED/pjiqpwBPrADFiAChfLdNS7fHp6nTo7jqN3dVL7dHA7jLkEBTrAF
BJADMVwSJWABC17kQtsCNLBATLDkVm7ZWO7mUD7lrd3mcC7lGp7lb94rIsAEDUQDcB0CCyCUZQ68
EbYD7aK+dL7jT17n9K3oiR7n2j3nix7jjr5aHnAAFnDgCgVrICzoTFtPOQAxKkAuTU7pjI7obN7/
xVd+6nJO6qiu465+yQ5gAitAADtQATiAwZ1OjSPQsxbQQAeAFTdu53he6pNu7Kz+6shu41Wu7GYd
AQWgvjCBMRKgAUGwABgA5rp+OShwA28aBBVgAodO7LDe6OT+6Hks6Xe+6pDe6s1+7n6sAHUagWd0
ACrwRgWA2Nmu7ZmCAia9AB8QBAWgABPwLszO7sl+8Mt+sZFe7Oqe7uPu7sMu1gGwAGNDQAHQEz9B
AAyAUmS+73wBAzewVi6wBWCTAF0N8Qlf7hFv6g/fP/VMzzEP8zMv8zVP8zdv81pDAQUgHDgfAA8A
AQfAAAUAXW3UAT3t8QwOAyatAoCLABvUABOA/yE+n/NUb/VVj/U07/ANn/LC3vJcv+6iKAHY9PWJ
lwAToABM8BMBfwIdgAMrFOTly1I1IIyCggAfIPAHQEgKz/DmLvEuD/hlz/LHrvLvruqBj+rCsvJ3
PEgJ0BRq/0YMXQAMIIwrpO8Psn4Hkfleu0I20AFrVQAugAABL/AKIAJGIfiF//dgj/iDv/WE7/Ww
b/Cx//qtfb90nPqUfEZGAQJ25BMlFPmjP10FUAHCaPzHb/wspPzql3zKv0J+i/zI7wPDH/ykX0J2
BAFLgd1dP/vdf/isD/6y//1+n/ve3/dgPC7trvrl7xLJh4CrT/7if/7rL//qj+7h7/rcP/75H//2
Bi/0ACFA4ECCBQcGMJjQIEKFDQUwdJgQYsSCEykevLgwY8WNBC1m/HgxJMWREUs6PNkwpcKVEjti
fPkwpsyYLTXWnGnTZE6eOH2+1OmxJ9ChHYPCJPrTaNGLDxaAYAoyqsipJKvuVLrxqMCtNJN+XZpV
qliqZK2axQp2JterKNuqfMsyrku0buvCvSs3L0EGULv+nXtT7djBZQufPZw2bGK7jPE61guZrmTB
i9ey3VtZa2COmTtT/mx5s2ehpJFGnHDi9GjQpVuvJiw6NmvZhmsjvq2Y9u7ZvW3z/u0b92XApjG/
Pp67sfLHzCM7nwxdc8IHFja4lh4a+HDhurv/L9/uPfh47uTFl0d/Xj34783DszcZAKH8+fIf2qd/
v/5+/f3z/8cvQP4AHFBA/wwk8MACF1SwwQQfRDBCBiGcUEIHLaTwwgo31LDDBC0wgcMMR8SwRBFN
9BBFEk9kMcUWV3QxRhhnVLHGF22UEUcab+Qxxx5JfO4999oLksjohCzSPPjSW3K9Ic0zQYIkmXyS
yimdvLJJLavE8kgjp1OSyy2zFLNMMs/0Mkw0rUyTTTDd1O7LONVss8s37ZwTTuwG8qCA69bME889
5RyUzjvHrBPRQ81MlNFFAS1UT9gMDVTRSh0VdFJJk0OyUUg1zZRTQkG1NNJQvRIoggoSOLU4/+RQ
7fRRT2eVtdZLPxWVUlNLJRXTXX3tFVdYRxXW1ex+LZYzZGm9ldllbX02tAMU0DVYZ62FFttms811
02Gr7bZVZbWNtlxyzw2X13SBTda4b701NtZt5zV33XZfZciAAiIg9l1x3Y2334DB9Vfdgtk9+N5j
0U34WnsdbhjecR/mNmJ6rU1AAY01bmBjjz8GWYGOQyZ545FLJvlklEFWeWWPW3aZ45hZVuADmFG+
2eWcV94Z55gP4JfhgSUGeGKL6z1aaKOH/hdfoytm2uCoEW5pAVYvwzprrbfmumuvv6bIaqSnVlje
sZdGu2i1nV574bIFTpvtiMQGu26778Y7b/+9DaKb4ov9Prtts5UWHO7CCSYb4q6gjtvtpAG3tu+9
J6e8cssrlzxxxg8nWm7HNf/7cdFBD/y1+WQ6PXXUV1e9ddZfdz122GeXvXbab7c999stuNohBggA
noACKCAI+N4HAh55Ao4XKHmwCzggoQMK2Gj6ywUygICZrK+bAAMKeoAACLAuIAHdz8c9ffTXV799
9t93P37455e/fvrvtz9//PfXn+rGB4dcABsmOYUUgHoDSQACiCcAAvzOAQQpQAO01zwHQlCCDTHA
AxKSwYIY4HsDgZ4AHvBBgXBPICM0CApN2EESEoSEDjDAA13YQoPAUADZIwgMZZjDFq5Qhxn/4WAH
H+i9i8RwI5n7n+E8B8DRJRFxTuzc554WOtIRbolGImBCDFiQA0yQAAeAwAQFwAAJ4LB5YBQjGc1I
kAQSLwIhZOC+BAABBGiQAldrwAELQIAJCIQBB+QeAxggkDD6UY4JEJ5BDvDACBBASgLYYx8F0MUH
Zo9VdxRIHhVJRAfssYQEqOTyJik+QoJykgf8I7/eOEhEyrABrFSgAN4YvQRKsgEIoCEDv2cABDQg
k2Kc2/GqKMBhNpFzTZPiMaUGRWQSh5nLVCajsmiQLRJEkwyMngSo98obivGLAtCmALi5RhAGD3iD
1CXyvveA3xlwgnBs3vesx0tzeo+cKxQI/wX2uE+BwLOe32Sn8DxZECJiz4v1jN4KQzhPYPJSntRD
ZD/rOUh4ppOguxQjOR2CxGi+7YkdVdwz/QfSzV1RpB6NIhOrxjwtHlAAnXTpN8VZzTXKNI8H1Cg4
galOnhb0gpB06U+5R0qCjq95LjUo8vQYvX768qK/pKZTxflOqQ6EkgKZQB1PeUarupQBV9WpQSQg
RjrmkohrzKlCOGrSlCoxmWxtpltVetKQaq2Yd6WrrKZZEAgcwK8Q2GEJe2dUWTJ1koMdSAQMSxDF
RlCSkwwaZF8qAQZMQLGETAAFGNCA3iWAsBTI4yIHMoHNPsCzBklAAzh72jke7wHalMDVHP9AWcsu
FoGvpMBlTwjbq03vAa98LGsFkABtirZ4jy2sYwcy2wKMD2iKVKVhdRs2YeaVitYt3Vu1O1eSXre7
0IQreLerVpZez7zn3Ro+M+KATtr2vGsd70fDO9L5ojSu8o1vW7Frxfzel2/lRW+ABTxgy8GXu/Vt
FAkUvGABhCEFRgDYghVshFDo18L+xbB4D4w1vH6Xv53aK4FFPGISa83AckVxmEiQgiNo5wiBDVKL
BeKAF0tkxS2OwI0zTN/+ajjFF+4xjzc8ZPKW2MhHRnJHToxfIqs4BW5QQpQFoIQHv3TFdFDCikkg
EAUL5AgpIAFCjABmI4RBAG548BHo8OT/iqzYCEZQsAZ3bF8fM/nHc66IjvT8oz37yM87ShHvGqJP
GB85AZHd4E6RrF4SH5pr5QN0pPssaT7zZ8WcOIInPBEAKod5zHRAiCfA/JAuB0DUYQ7AleXzZTAr
eNT/uXEAKLDiMEza1pX+861zjWtK79rXAKKzkO9c5/865IMR0OAEDsA8ZUOAXw+IgAOeO1wwulAA
yr5aXwMrbePeUITVlmVWJ/BBB/T1sTlF9hxFK23CvtTciU32sgcC7XJ3+6V+3eH3EmBb62E7VS2E
dkKUjdyA91XOA+lr7+j93Af49WoREDcJG36Ag3t7Au0u9oeHLeyC6HggVIZwp1u85i0L/2DFSjgz
mMWcApRzmeUzRjSpUxCKI4RixW7Ac0mDHGye1zVrHUawzkEM4G5+8oN/bGpiIVnQCZhyjL7kpVF/
x6pGRs8BBFjgUJ2awF3iMlUypIApc9rF7zWSAPziuizBbkqyG1Kiqfrm1bN+wEQqEgGSpIBWiVrI
gkRwINfcY9C62M9HtnLpHzz4WLHn9WsXNHt95GVVi6xxO1eeIFFGtJpbHgE3GEEJXy75lD3/gCgj
JMoyPmHnw9Byj0TZ9agnds69G/TZ79zyss9ukzOe6BK6lKHUNOw+Dej3NZpwoQI1IDoLmk6HYs+A
DWj72F3qz10+v+0m5B48jz/8Aig/l/9bBaHVQXl1GJOz+RW1JwK4XwANwrPpBZCA4m/I+IpuMa27
Nybtc08YEoSh82CGvdrTPdyjPCDjOAPcuJ4TugQUgBAzI+zTI6niF3gKIxoqvumLnge4O6WzqHS6
uquBvxLyOukLP54KwUnyOgjsp+DLwA1MlXiSHgToLaebgD0qL7/LJHQKPLdjIKmSIX9aoN+ZMVFq
vA+ypKKjrv27vdhjwgMkQGLaLyj0MAFawCV0wiYUiBDzNlk6uHRDoANAvJgzgAOYgHyDt3mLrAeA
AAg4uBZqIQiQpIbTIBLKJS8UociSOIrbQjv0woA7oTRcwzZUiHS7OBirKNQCQwhaJDj/LAgHUDaJ
QzTPqiSCYMQTgsPA+j78Azrbq0IE9DlOFEAG7MQn/MQBxMJSnLwkU8XJyawT7IhDHLEl88RRPEVa
vMJbVMBQtMJcrEVdnEVfLAgtXMVhJMb3qq4pzD9QVMJfXEZS3ERTRBhb5MUCxDNhLMZrxMa8kUVn
jMJkhMZplEL9o8ZeRBppRMVdPEf8y8Z19BoUYscsPEZxDEdlHEdcTEduRMZntAr+4cf+6cd/9EeZ
EDSwMR6FaDgBI0OHOEgk46OmYKoIkICKo4jwUbSugbSABMiMxMiN1MiO5MiP9MiQBMmRBEhw9EZR
BEaCsMaY2CzDMwjd8qzfgsXJMiDk/yIImWSAq0mAPzIsCGjFhmug50qt7ns4porJ0FIICDCgnvzJ
l8qjBtghpZxJmqysVOkiCXAviDSg8bks4kIArFSsyKIAm2yeCQinutlGcqxHk9RHdDTHt0xJe6wY
uGxGtZzHhljJjhi8meK9UQqaa2KsgRAkg5Ap5DGqq2s/YCrM4hmfBzy7TEKqFyylt/MjqSKlyOI7
vkCn4dKqDhTMzUyq+fuga4oog9ispAObtJTLuGTLbmxLZlzLe7RL2VzNurTHvMyIBDKnXjKIB/S9
yISkrzKAsxwIjcoev0LOCVwsmQqfBoAAfYke3+wqg5CgZWu6FUQerEROVqnOBLjOp/9CHqZaPp5y
oQlqvn4aHyIkiANAgN0kSxOLR3q8S5S0zdbMR9fET7vKT3k8yYTAzYsgqiG0SensvQ4iIkQCzj96
IAdgFQMKmgWqP6fqIn4Jo+icIBUsqpcaKHgaqw+SJFLqJEXrIjyKqVwa0XxCQgZCLuHBOM6suKYr
tKxRTfvkz9fExxrdT/kUHbqMTR6dT/8kOhFjL4qgIRtyCAc4OImcCSXdoBQi0pfIRBHaIdVCrxml
TRrVURudTS2tzR4NHR/tT9j8UXV8xzK9ntfCQWOszytlUzDlUiz9xjZlTYhx0xyN0/800zzVU020
U/r00jWt0/sUVP4MVBwFKTzd00T/zVMrLdQs7VO3nNNGjVMwlVQ/HdMuMYEF0FRNtYBN9dRPBdUF
6NRQJdVNHdVSJdVTRVVQVdVV9dRWdVVOjVVWndVPhdVYvVVXzdVV3VVPrYDAelM5BdRIJdZhNdY/
RdZLZQld67VmZdZn5TVo/TVpddZotdZpvdZqxdZt1dZupdZvzVZw5VZx9dZwNdcDgVNLDdMbddRB
bVdDhdd3lddJLdZkXdfZrFRIPVZl7VJ+TVd9tddgzVcxvdd+Ldh/JdhiGlh2pdd9PVhhDdhHTViJ
ZVh1Fdh69VeIpUKMfdiF3VKK/Vh3bdiIFVmLBVmDvViHXRyOTVmSjdeRzViPRdmTI0XYigXYmGVZ
mqXTnC3Zm+1Ynn1Zk+3ZiR1amyXaoPXZKgoIADs=
--=_related 000E051748257ABC_=--

From luo.wen@zte.com.cn  Mon Nov 19 23:03:56 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA721F8490; Mon, 19 Nov 2012 23:03:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.479
X-Spam-Level: 
X-Spam-Status: No, score=-92.479 tagged_above=-999 required=5 tests=[AWL=-1.529, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGhWVCssHPjR; Mon, 19 Nov 2012 23:03:55 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5703C21F8485; Mon, 19 Nov 2012 23:03:50 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 85CBC126BC7B; Tue, 20 Nov 2012 15:05:14 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAK73cDv055693; Tue, 20 Nov 2012 15:03:38 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: 
To: jouni korhonen 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Tue, 20 Nov 2012 15:03:36 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-20 15:03:37, Serialize complete at 2012-11-20 15:03:37
Content-Type: multipart/alternative; boundary="=_alternative 0026CAFE48257ABC_="
X-MAIL: mse01.zte.com.cn qAK73cDv055693
Cc: dmm-bounces@ietf.org, "dmm@ietf.org" , Konstantinos Pentikousis 
Subject: [DMM] =?gb2312?b?tPC4tDogUmU6ICBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWRt?= =?gb2312?b?bS1yZXF1aXJlbWVudHMtMDI=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 07:03:56 -0000

This is a multipart message in MIME format.
--=_alternative 0026CAFE48257ABC_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGksIEFsbA0KDQo+Pj4gIHwgICJQUzI6ICBEaXZlcmdlbmNlIGZyb20gb3RoZXIgZXZvbHV0aW9u
YXJ5IHRyZW5kcyBpbiBuZXR3b3JrDQo+Pj4gIHwgICAgICAgICBhcmNoaXRlY3R1cmUNCj4+PiAg
fA0KPj4+ICB8ICAgICAgICAgQ2VudHJhbGl6ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBjYW4gYmVj
b21lIG5vbi1vcHRpbWFsIHdpdGgNCj4+PiBhDQo+Pj4gIHwgICAgICAgICBmbGF0IG5ldHdvcmsg
YXJjaGl0ZWN0dXJlLiINCj4+PiAgfA0KPj4+ICB8IG8gV2hhdCBhcmUgdGhlICJvdGhlciI/IEkg
d291bGQgY29uc2lkZXIgcmVtb3ZpbmcgUFMyIGlmIHdlIGNhbm5vdA0KPj4+ICB8bmFtZSB0aG9z
ZS4NCj4+Pg0KPj4+IEkgdGhpbmsgIm90aGVyIiBoZXJlIHJlZmVycyB0byB0aGUgZGlzdHJpYnV0
ZWQgbmF0dXJlIG9mIGRlbGl2ZXJpbmcNCj4+PiBuZXR3b3JrIHNlcnZpY2VzL2NvbnRlbnQgdG9k
YXkgKGUuZy4gbXVsdGlwbGUgZGF0YSBjZW50ZXJzLCBDRE5zIA0KZXRjLikuDQo+Pj4gSXQncyBu
b3Qgb25seSB0aGUgbW9iaWxlIHRoYXQgbW92ZXMgYXJvdW5kIHRoZXNlIGRheXMsIGJ1dCB5b3Vy
DQo+Pj4gImNvcnJlc3BvbmRlbnQiIG5vZGUgYXMgd2VsbC4NCj4+PiANCj4+IA0KPj4gRXhhY3Rs
eS4gSGVyZSwgd2UgcmVmZXIgdG8gZGlzdHJpYnV0aW9uIG9mIGNvbnRlbnQgZGVsaXZlcnksIGku
ZS4gQ0ROLiANClByb2JhYmx5LCBvbmUgb2YgdGhlIG1haW4gbW90aXZhdGlvbiBmb3IgZGlzdHJp
YnV0aW5nIG1vYmlsaXR5IG1hbmFnZW1lbnQgDQo6LSkgSU1ITywgaWYgd2Ugc2hvdWxkIGtlZXAg
b25seSBvbmUgUFMsIGl0IHdvdWxkIGJlIFBTIzIgOi0pDQoNCj5NYXliZSB3ZSBuZWVkIHRvIHRo
ZW4gc2F5IHNvbWV0aGluZyBhYm91dCBpdCBsaWtlIA0KPiAiRGl2ZXJnZW5jZSBmcm9tIG90aGVy
IGV2b2x1dGlvbmFyeSB0cmVuZHMgaW4gbmV0d29yaw0KPiBhcmNoaXRlY3R1cmVzIHN1Y2ggYXMg
ZGlzdHJpYnV0aW9uIG9mIGNvbnRlbnQgZGVsaXZlcnkiID8NCg0KW0x1b3dlbl0gIE1heWJlICJv
dGhlciIganVzdCBtZWFucyBhbm90aGVyIGtpbmQgb2YgbmV0d29yayBhcmNoaXRlY3R1cmUgDQpl
dm9sdXRpb24gdHJlbmRzLiBJIGludGVycHJldCB0aGUgIm90aGVyIiBqdXN0IGFzIHRoZSAiZmxh
dHRlbiBuZXR3b3JrIi4NCg0KDQo+ICB8ICAiUkVRMjogIFRyYW5zcGFyZW5jeSB0byBVcHBlciBM
YXllcnMgd2hlbiBuZWVkZWQNCj4gIHwNCj4gIHwgICAgICAgICAgRE1NIHNvbHV0aW9ucyBNVVNU
IHByb3ZpZGUgdHJhbnNwYXJlbnQgbW9iaWxpdHkgc3VwcG9ydA0KPiAgfGFib3ZlIHRoZSBJUCBs
YXllciB3aGVuIG5lZWRlZC4gIFN1Y2ggdHJhbnNwYXJlbmN5IGlzIG5lZWRlZCwNCj4gIHxmb3Iu
LiINCj4gIHwNCj4gIHwgbyBEb2Vzbid0IHRoZSAid2hlbiBuZWVkZWQiIG1ha2UgdGhlIGVhcmxp
ZXIgTVVTVCBjb25kaXRpb25hbD8gQXQNCj4gIHxsZWFzdCBJIHVuZGVyc3RhbmQgaXQgc28uIElm
IHRoYXQgaXMgdGhlIGNhc2Ugd2UgcHJvYmFibHkgY291bGQganVzdCANCnNheToNCj4gIHwgICAi
RE1NIHNvbHV0aW9ucyBTSE9VTEQgcHJvdmlkZSB0cmFuc3BhcmVudCBtb2JpbGl0eSBzdXBwb3J0
IGFib3ZlDQo+ICB8dGhlIElQIGxheWVyLiIgPw0KDQo+IEkga25vdyB3ZSBzaG91bGQgbm90IGJl
IHRhbGtpbmcgaW1wbGVtZW50YXRpb24sIGJ1dCBzaW5jZSBJIGdvdCBpbnNwaXJlZCANCmp1c3Qg
bm93LCB0aGlzIGlzIHRoZSB3YXkgSSBwYXJzZSB0aGUgZm9ybWVyOg0KDQo+IHByb2NlZHVyZSBk
bW1YWVogKGluOiBtb2JpbGl0eV9zdXBwb3J0X3JlcXVpcmVkLCBvdXQ6IG1vYmlsaXR5X3N1cHBv
cnQpIA0Kew0KPiBtb2JpbGl0eV9zdXBwb3J0ID0gZmFsc2U7DQo+IC4uLg0KPiBpZiAobW9iaWxp
dHlfc3VwcG9ydF9yZXF1aXJlZD09dHJ1ZSkgdGhlbiBtb2JpbGl0eV9zdXBwb3J0PXRydWU7DQo+
IC4uLg0KPiB9DQoNCltMdW93ZW5dIEkgaW50ZXJwcmV0IHRoaXMgbG9naWMgYXMgdGhlIG5ldHdv
cmsgc3VwcG9ydCBtb2JpbGl0eSwgYW5kIA0KZGVwZW5kcyBvbiBhcHBsaWNhdGlvbnMgb24gZWFj
aCBpbmRpdmlkdWFsIG1vYmlsZSBub2RlIHRvIGNob29zZSB1c2UgdGhlIA0KbW9iaWxpdHkgb3Ig
bm90LiBJIHRoaW5rIGl0IHJlYXNvbmFibGUsIGFuZCB3aGV0aGVyIHRvIGNob29zZSB1c2UgbW9i
aWxpdHkgDQpzdXBwb3J0IG9yIG5vdCBpcyBhcHBsaWNhdGlvbnMnIGRlY2lzaW9uLg0KDQo+IFlv
dXIgcHJvcG9zYWwgZG9lcyBub3QgY2FwdHVyZSB0aGUgY29uZGl0aW9uYWxpdHkgb2YgbW9iaWxp
dHkgc3VwcG9ydCANCmZvciBkaWZmZXJlbnQgaG9zdHMsIGFwcGxpY2F0aW9ucywgYW5kIGV2ZW4g
ZGlmZmVyZW50IHNlc3Npb25zIG9mIHRoZSBzYW1lIA0KYXBwLiBJIHJlYWQgaXQgbW9yZSBsaWtl
DQoNCj4gLy8gc2V0IHRvIDAgZm9yIGRpc2FibGluZyBtb2JpbGl0eSBzdXBwb3J0DQo+ICNkZWZp
bmUgTU9CSUxJVFlfU1VQUE9SVCAxIA0KDQpbTHVvd2VuXSBJIGludGVycHJldCB0aGlzIGxvZ2lj
IGFzIHRoZSBvcGVyYXRvciBjb3VsZCBoYXZlIHNvbWUga2luZCBvZiANCmdsb2JhbCBjb25maWd1
cmF0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIHRvIHByb3ZpZGUgbW9iaWxpdHkgc3VwcG9ydCB0byBh
bGwgDQppdHMgc3Vic2NyaWJlcnMgb3Igbm90LiBJdCBtYXkgcHJvdmlkZSwgdGhlbiAjZGVmaW5l
IE1PQklMSVRZX1NVUFBPUlQgMSANCixvdGhlcndpc2UgI2RlZmluZSBNT0JJTElUWV9TVVBQT1JU
IDAuIEkgdGhpbmsgaXQgcmVhc29uYWJsZSwgc29tZSANCm9wZXJhdG9yIG1heSBvbmx5IHByb3Zp
ZGUgZml4ZWQvbm9tYWRpYyBhY2Nlc3Mgc2VydmljZS4NCg0KDQo+PiAgfEkgd291bGQgbmVlZCB0
byBpbXBsZW1lbnQgdGhlICJtb2JpbGl0eSBzdGFjayIgd2hhdGV2ZXIgc3VwcG9ydCANCmZ1bmN0
aW9uDQo+PiAgfGFueXdheSBldmVuIGlmIG5vbmUgb2YgbXkgYXBwbGljYXRpb24gY2FyZSBhYm91
dCBpdC4NCj4+IA0KPj4gSWYgeW91IGFyZSBhYnNvbHV0ZWx5IHN1cmUgdGhhdCBub25lIG9mIHlv
dXIgYXBwcyBuZWVkcyBtb2JpbGl0eSANCnN1cHBvcnQsIGFuZCBub25lIHdpbGwgZXZlciBuZWVk
IGl0IGluIHRoZSBmdXR1cmUsIHRoZW4gdGhlcmUncyBubyByZWFzb24gDQp0byBpbXBsZW1lbnQg
aXQsIHN1cmUuIEJ1dCBpZiB0aGVyZSdzIGEgY2hhbmNlIG9uZSBhcHAgbWF5IG5lZWQgaXQgYW5k
IDEwMCANCndvbid0LCB0aGVuIHBlcmhhcHMgeW91IGdldCB0byBpbXBsZW1lbnQgaXQuIFRoZSBk
aWZmZXJlbmNlIGlzIHRoYXQsIGlmIA0KeW91IGRvIGltcGxlbWVudCB0aGF0ICJtb2JpbGl0eSBz
dGFjayIsIHdpdGggY29uZGl0aW9uYWwgc3VwcG9ydCB5b3UgcnVuIA0KdGhhdCBjb2RlIGZvciBv
bmUgYXBwIG9ubHkgKGFuZCByb3V0ZSB0aGUgcmVzcGVjdGl2ZSBwYWNrZXRzIGFjY29yZGluZ2x5
KSwgDQp3aGlsZSB3aXRoIHRvZGF5J3MgYXBwcm9hY2ggeW91IGRvIHRoZSBzYW1lIGZvciAxMDEg
YXBwcy4NCg0KPiBGYWlyIHJlYXNvbmluZy4gSG93ZXZlciwgd2hhdCBpcyB0aGUgIm1vYmlsaXR5
IHN0YWNrIiBoZXJlIHRoZW4/IElzIGl0IA0Kc29tZXRoaW5nIHdlIHRvZGF5IHVuZGVyc3RhbmQg
YXMgYSBNSVAgZW5hYmxlZCBzdGFjayBvciBjb3VsZCBpdCBiZSANCnNvbWV0aGluZyBtb3JlIGdl
bmVyaWM/IFdoYXQgSSBtZWFuIGhlcmUgaXMgdGhhdCB3ZSBzaG91bGQgYmUgdmVyeSANCmNhdXRp
b3VzIHdpdGggTU4gc2lkZSBpbXBhY3RzIG5vdCB0byBmcmVhayBvdXQgbGVzcyBtb2JpbGl0eSBj
YXV0aW91cyANCnBlb3BsZS4gSWYgdGhlICJtb2JpbGl0eSBzdGFjayIgY291bGQgYmUgYmVuZWZp
Y2lhbCBhbHNvIG91dHNpZGUgbW9iaWxpdHkgDQp1c2UgY2FzZXMgdGhhdCB3b3VsZCBiZSBhd2Vz
b21lLg0KDQpbTHVvd2VuXSBIaSBKb3VuaSwgd2hhdCBkbyB5b3UgbWVhbiAiV2hhdCBJIG1lYW4g
aGVyZSBpcyB0aGF0IHdlIHNob3VsZCBiZSANCnZlcnkgY2F1dGlvdXMgd2l0aCBNTiBzaWRlIGlt
cGFjdHMgbm90IHRvIGZyZWFrIG91dCBsZXNzIG1vYmlsaXR5IGNhdXRpb3VzIA0KcGVvcGxlIiA/
ICBUaGUgYXBwbGljYWlvbnMgb24gdGhlIG1vYmlsZSBub2RlIGRvZXNuJ3QgbmVlZCB0byB1bmRl
cnN0YW5kIA0Kd2hhdCBpcyB0aGUgbW9iaWxpdHkgKGkuZS4gdGhlIGFwcGxpY2F0aW9uIGRldmVs
b3BlciBkb2Vzbid0IG5lZWQgdG8gDQp1bmRlcnN0YW5kKSwgYW5kIGl0IHNlZW1zIHRvIGxldCBh
biBvcmRpbmFyeSB1c2VyIHRvIHVuZGVyc3RhbmQgdGhlIA0KbW9iaWx0eSBjb25jZXB0IGlzIGlt
cG9zc2libGUuIEFzIHBlciBteSB1bmRlcnN0YW5kaW5nLCB0aGUgYXBwbGljYXRpb24gDQpvbmx5
IGNhcmUgdG8gYmluZCB0byBhbiBJUEAgd2hpY2ggY2FuIHN1cnZpdmUgbG9uZ2VyIHRoYW4gaXRz
ZWxmLg0KDQoNCkJSDQpMdW93ZW4NCg0KDQoNCg0KDQpqb3VuaSBrb3Job25lbiA8am91bmkubm9z
cGFtQGdtYWlsLmNvbT4gDQq3orz+yMs6ICBkbW0tYm91bmNlc0BpZXRmLm9yZw0KMjAxMi8xMS8x
NSAxODo1Ng0KDQrK1bz+yMsNCktvbnN0YW50aW5vcyBQZW50aWtvdXNpcyA8ay5wZW50aWtvdXNp
c0BodWF3ZWkuY29tPg0Ks63LzQ0KImRtbUBpZXRmLm9yZyIgPGRtbUBpZXRmLm9yZz4NCtb3zOIN
ClJlOiBbRE1NXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDINCg0K
DQoNCg0KDQoNCg0KSGksDQoNCk9uIE5vdiAxNCwgMjAxMiwgYXQgODoyOCBQTSwgS29uc3RhbnRp
bm9zIFBlbnRpa291c2lzIHdyb3RlOg0KDQo+IEhpIEpvdW5pLCBhbGwsDQo+IA0KPiAgfE1heWJl
IHdlIG5lZWQgdG8gdGhlbiBzYXkgc29tZXRoaW5nIGFib3V0IGl0IGxpa2UNCj4gIHwgICJEaXZl
cmdlbmNlIGZyb20gb3RoZXIgZXZvbHV0aW9uYXJ5IHRyZW5kcyBpbiBuZXR3b3JrDQo+ICB8ICAg
YXJjaGl0ZWN0dXJlcyBzdWNoIGFzIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IGRlbGl2ZXJ5IiA/
DQo+IA0KPiBTb3VuZHMgZ29vZCB0byBtZS4NCg0KR29vZC4NCg0KPiAgfE5vICh3aXRob3V0IHNt
aWxlKS4gQnV0IHRoYXQgaXMgYW5vdGhlciB0cmVuZCB0byBvcHBvc2l0ZSBkaXJlY3Rpb24NCj4g
IHxhbmQgd2Ugc2hvdWxkIGhhdmUgYSBzdWZmaWNpZW50IGFyZ3VtZW50IGZvciBvdXIgYXNzZXJ0
aW9uIGhlcmUgaW1oby4gDQpXaGF0DQo+ICB8aXMgc28gZnVuZGFtZW50YWxseSByZXNvdXJjZSBj
b25zdW1pbmcgaW4gIm1vYmlsaXR5IGNvbnRleHQiIGhhbmRsaW5nDQo+ICB8dGhhdCBpdCByZXF1
aXJlcyBkaXN0cmlidXRpb24/IElzIGl0IGp1c3QgYSBjb21iaW5hdGlvbiBvZiBhbGwNCj4gIHxm
dW5jdGlvbnMgaW4gb25lIHBsYWNlICh0aGF0IGhhcyBsaXR0bGUgdG8gZG8gd2l0aCBtb2JpbGl0
eSBwZXIgc2UpPw0KPiANCj4gSSB0aGluayBzY2FsYWJpbGl0eSBoZXJlIHJlZmVycyB0byB0aGUg
Imh1Yi1hbmQtc3Bva2UiIG5hdHVyZSBvZiB0aGUgDQpyb3V0aW5nIGZhYnJpYyBhcyBpbnRyb2R1
Y2VkIGJ5IGEgImNlbnRyYWxpemVkIiBtb2JpbGl0eSBhbmNob3IuIFlvdSBtYXkgDQpoYXZlIHZh
bGlkIHRlY2huaWNhbCBhbmQvb3Igb3BlcmF0aW9uYWwgcmVhc29ucyBmb3IgYWRvcHRpbmcgYSAN
Cmh1Yi1hbmQtc3Bva2UgbW9kZWwsIHRoYXQncyBvay4gQnV0IG1heWJlIG90aGVycyBtYXkgd2Fu
dCBhbiBhbHRlcm5hdGl2ZSANCm1vZGVsIHdoaWNoIGFpbXMgZm9yIGRpZmZlcmVudCBvcHRpbWFs
aXRpZXMsIGFuZCBmb3IgdGhvc2UgdGhlIA0KaHViLWFuZC1zcG9rZSBtb2RlbCBpcyBub3QsIHdl
bGwsICJzY2FsYWJsZSIuDQo+IA0KPiBTRE4sIHdlbGwgdGhlIE9wZW5GbG93IGZsYXZvciBvZiBp
dCBhbnl3YXksIGlzICJsb2dpY2FsbHkgY2VudHJhbGl6ZWQiIA0Kd3J0IG5ldHdvcmsgY29udHJv
bCwgbm90IGhvdyBwYWNrZXRzIG1vdmUgYXJvdW5kLiBTRE4gY2FuIGRvIGh1Yi1hbmQtc3Bva2Ug
DQphcyB3ZWxsIGFzIG90aGVyIHJvdXRpbmcgZmFicmljcy4gSW5mb3JtYXRpb24tY2VudHJpYyBu
ZXR3b3JraW5nLCBhbm90aGVyIA0KbWFqb3IgdHJlbmQsIGlzIGRlZmluaXRlbHkgbm90IHBvaW50
aW5nIHRvd2FyZHMgdGhlIG1lcml0cyBvZiB0aGUgY3VycmVudCANCnR5cGUgb2YgY2VudHJhbGl6
YXRpb24uLi4gU28gSSB0aGluayBQUzMgaXMgdmFsaWQuDQoNClBTMyBzYXlzICJjZW50cmFsaXpl
ZCByb3V0ZSBtYW5hZ2VtZW50Ii4uIEkgd291bGQgYmUgZmFyIG1vcmUgY29tZm9ydGFibGUgDQpp
ZiBQUzMgc2F5cyAiY2VudHJhbGl6ZWQgdHVubmVsIG1hbmFnZW1lbnQiIHdoaWNoIGlzIG1vcmUg
Y29uY3JldGVseSB3aGF0IA0Kd2UgZG8gdG9kYXkgYXMgcGVyIGh1Yi1hbmQtc3Bva2UgdHlwZSB0
dW5uZWxlZCB0cmFmZmljIGRlcGxveW1lbnRzLg0KDQo+ICB8SSB3b3VsZCBuZWVkIHRvIGltcGxl
bWVudCB0aGUgIm1vYmlsaXR5IHN0YWNrIiB3aGF0ZXZlciBzdXBwb3J0IA0KZnVuY3Rpb24NCj4g
IHxhbnl3YXkgZXZlbiBpZiBub25lIG9mIG15IGFwcGxpY2F0aW9uIGNhcmUgYWJvdXQgaXQuDQo+
IA0KPiBJZiB5b3UgYXJlIGFic29sdXRlbHkgc3VyZSB0aGF0IG5vbmUgb2YgeW91ciBhcHBzIG5l
ZWRzIG1vYmlsaXR5IA0Kc3VwcG9ydCwgYW5kIG5vbmUgd2lsbCBldmVyIG5lZWQgaXQgaW4gdGhl
IGZ1dHVyZSwgdGhlbiB0aGVyZSdzIG5vIHJlYXNvbiANCnRvIGltcGxlbWVudCBpdCwgc3VyZS4g
QnV0IGlmIHRoZXJlJ3MgYSBjaGFuY2Ugb25lIGFwcCBtYXkgbmVlZCBpdCBhbmQgMTAwIA0Kd29u
J3QsIHRoZW4gcGVyaGFwcyB5b3UgZ2V0IHRvIGltcGxlbWVudCBpdC4gVGhlIGRpZmZlcmVuY2Ug
aXMgdGhhdCwgaWYgDQp5b3UgZG8gaW1wbGVtZW50IHRoYXQgIm1vYmlsaXR5IHN0YWNrIiwgd2l0
aCBjb25kaXRpb25hbCBzdXBwb3J0IHlvdSBydW4gDQp0aGF0IGNvZGUgZm9yIG9uZSBhcHAgb25s
eSAoYW5kIHJvdXRlIHRoZSByZXNwZWN0aXZlIHBhY2tldHMgYWNjb3JkaW5nbHkpLCANCndoaWxl
IHdpdGggdG9kYXkncyBhcHByb2FjaCB5b3UgZG8gdGhlIHNhbWUgZm9yIDEwMSBhcHBzLg0KDQpG
YWlyIHJlYXNvbmluZy4gSG93ZXZlciwgd2hhdCBpcyB0aGUgIm1vYmlsaXR5IHN0YWNrIiBoZXJl
IHRoZW4/IElzIGl0IA0Kc29tZXRoaW5nIHdlIHRvZGF5IHVuZGVyc3RhbmQgYXMgYSBNSVAgZW5h
YmxlZCBzdGFjayBvciBjb3VsZCBpdCBiZSANCnNvbWV0aGluZyBtb3JlIGdlbmVyaWM/IFdoYXQg
SSBtZWFuIGhlcmUgaXMgdGhhdCB3ZSBzaG91bGQgYmUgdmVyeSANCmNhdXRpb3VzIHdpdGggTU4g
c2lkZSBpbXBhY3RzIG5vdCB0byBmcmVhayBvdXQgbGVzcyBtb2JpbGl0eSBjYXV0aW91cyANCnBl
b3BsZS4gSWYgdGhlICJtb2JpbGl0eSBzdGFjayIgY291bGQgYmUgYmVuZWZpY2lhbCBhbHNvIG91
dHNpZGUgbW9iaWxpdHkgDQp1c2UgY2FzZXMgdGhhdCB3b3VsZCBiZSBhd2Vzb21lLg0KDQotIEpv
dW5pDQoNCg0KDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBLb3N0YXMNCj4gDQo+IA0KPiAN
Cj4gDQo+IA0KPiANCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCg0K
--=_alternative 0026CAFE48257ABC_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSwgQWxsPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv
bnQgc2l6ZT0yPjx0dD4mZ3Q7Jmd0OyZndDsgJm5ic3A7fCAmbmJzcDsmcXVvdDtQUzI6ICZuYnNw
O0RpdmVyZ2VuY2UNCmZyb20gb3RoZXIgZXZvbHV0aW9uYXJ5IHRyZW5kcyBpbiBuZXR3b3JrPGJy
Pg0KJmd0OyZndDsmZ3Q7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFyY2hp
dGVjdHVyZTxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDt8PGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNw
O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENlbnRyYWxpemVkIG1vYmlsaXR5IG1hbmFn
ZW1lbnQNCmNhbiBiZWNvbWUgbm9uLW9wdGltYWwgd2l0aDxicj4NCiZndDsmZ3Q7Jmd0OyBhPGJy
Pg0KJmd0OyZndDsmZ3Q7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZsYXQg
bmV0d29yayBhcmNoaXRlY3R1cmUuJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwO3w8YnI+
DQomZ3Q7Jmd0OyZndDsgJm5ic3A7fCBvIFdoYXQgYXJlIHRoZSAmcXVvdDtvdGhlciZxdW90Oz8g
SSB3b3VsZCBjb25zaWRlcg0KcmVtb3ZpbmcgUFMyIGlmIHdlIGNhbm5vdDxicj4NCiZndDsmZ3Q7
Jmd0OyAmbmJzcDt8bmFtZSB0aG9zZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsgSSB0aGluayAmcXVvdDtvdGhlciZxdW90OyBoZXJlIHJlZmVycyB0byB0aGUgZGlzdHJpYnV0
ZWQgbmF0dXJlDQpvZiBkZWxpdmVyaW5nPGJyPg0KJmd0OyZndDsmZ3Q7IG5ldHdvcmsgc2Vydmlj
ZXMvY29udGVudCB0b2RheSAoZS5nLiBtdWx0aXBsZSBkYXRhIGNlbnRlcnMsDQpDRE5zIGV0Yy4p
Ljxicj4NCiZndDsmZ3Q7Jmd0OyBJdCdzIG5vdCBvbmx5IHRoZSBtb2JpbGUgdGhhdCBtb3ZlcyBh
cm91bmQgdGhlc2UgZGF5cywgYnV0DQp5b3VyPGJyPg0KJmd0OyZndDsmZ3Q7ICZxdW90O2NvcnJl
c3BvbmRlbnQmcXVvdDsgbm9kZSBhcyB3ZWxsLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBFeGFjdGx5LiBIZXJlLCB3ZSByZWZlciB0byBkaXN0cmlidXRp
b24gb2YgY29udGVudCBkZWxpdmVyeSwgaS5lLg0KQ0ROLiBQcm9iYWJseSwgb25lIG9mIHRoZSBt
YWluIG1vdGl2YXRpb24gZm9yIGRpc3RyaWJ1dGluZyBtb2JpbGl0eSBtYW5hZ2VtZW50DQo6LSkg
SU1ITywgaWYgd2Ugc2hvdWxkIGtlZXAgb25seSBvbmUgUFMsIGl0IHdvdWxkIGJlIFBTIzIgOi0p
PGJyPg0KPGJyPg0KJmd0O01heWJlIHdlIG5lZWQgdG8gdGhlbiBzYXkgc29tZXRoaW5nIGFib3V0
IGl0IGxpa2UgPGJyPg0KJmd0OyAmcXVvdDtEaXZlcmdlbmNlIGZyb20gb3RoZXIgZXZvbHV0aW9u
YXJ5IHRyZW5kcyBpbiBuZXR3b3JrPGJyPg0KJmd0OyBhcmNoaXRlY3R1cmVzIHN1Y2ggYXMgZGlz
dHJpYnV0aW9uIG9mIGNvbnRlbnQgZGVsaXZlcnkmcXVvdDsgPzwvdHQ+PC9mb250Pg0KPGJyPg0K
PGJyPjxmb250IHNpemU9Mj48dHQ+W0x1b3dlbl0gJm5ic3A7TWF5YmUgJnF1b3Q7b3RoZXImcXVv
dDsganVzdCBtZWFucw0KYW5vdGhlciBraW5kIG9mIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGV2b2x1
dGlvbiB0cmVuZHMuIEkgaW50ZXJwcmV0IHRoZQ0KJnF1b3Q7b3RoZXImcXVvdDsganVzdCBhcyB0
aGUgJnF1b3Q7ZmxhdHRlbiBuZXR3b3JrJnF1b3Q7LjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPg0K
PGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDt8ICZuYnNwOyZxdW90O1JFUTI6ICZuYnNw
O1RyYW5zcGFyZW5jeQ0KdG8gVXBwZXIgTGF5ZXJzIHdoZW4gbmVlZGVkPGJyPg0KJmd0OyAmbmJz
cDt8PGJyPg0KJmd0OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtE
TU0gc29sdXRpb25zIE1VU1QgcHJvdmlkZQ0KdHJhbnNwYXJlbnQgbW9iaWxpdHkgc3VwcG9ydDxi
cj4NCiZndDsgJm5ic3A7fGFib3ZlIHRoZSBJUCBsYXllciB3aGVuIG5lZWRlZC4gJm5ic3A7U3Vj
aCB0cmFuc3BhcmVuY3kgaXMNCm5lZWRlZCw8YnI+DQomZ3Q7ICZuYnNwO3xmb3IuLiZxdW90Ozxi
cj4NCiZndDsgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7fCBvIERvZXNuJ3QgdGhlICZxdW90O3do
ZW4gbmVlZGVkJnF1b3Q7IG1ha2UgdGhlIGVhcmxpZXIgTVVTVA0KY29uZGl0aW9uYWw/IEF0PGJy
Pg0KJmd0OyAmbmJzcDt8bGVhc3QgSSB1bmRlcnN0YW5kIGl0IHNvLiBJZiB0aGF0IGlzIHRoZSBj
YXNlIHdlIHByb2JhYmx5IGNvdWxkDQpqdXN0IHNheTo8YnI+DQomZ3Q7ICZuYnNwO3wgJm5ic3A7
ICZxdW90O0RNTSBzb2x1dGlvbnMgU0hPVUxEIHByb3ZpZGUgdHJhbnNwYXJlbnQgbW9iaWxpdHkN
CnN1cHBvcnQgYWJvdmU8YnI+DQomZ3Q7ICZuYnNwO3x0aGUgSVAgbGF5ZXIuJnF1b3Q7ID88YnI+
DQo8YnI+DQomZ3Q7IEkga25vdyB3ZSBzaG91bGQgbm90IGJlIHRhbGtpbmcgaW1wbGVtZW50YXRp
b24sIGJ1dCBzaW5jZSBJIGdvdCBpbnNwaXJlZA0KanVzdCBub3csIHRoaXMgaXMgdGhlIHdheSBJ
IHBhcnNlIHRoZSBmb3JtZXI6PGJyPg0KPGJyPg0KJmd0OyBwcm9jZWR1cmUgZG1tWFlaIChpbjog
bW9iaWxpdHlfc3VwcG9ydF9yZXF1aXJlZCwgb3V0OiBtb2JpbGl0eV9zdXBwb3J0KQ0Kezxicj4N
CiZndDsgbW9iaWxpdHlfc3VwcG9ydCA9IGZhbHNlOzxicj4NCiZndDsgLi4uPGJyPg0KJmd0OyBp
ZiAobW9iaWxpdHlfc3VwcG9ydF9yZXF1aXJlZD09dHJ1ZSkgdGhlbiBtb2JpbGl0eV9zdXBwb3J0
PXRydWU7PGJyPg0KJmd0OyAuLi48YnI+DQomZ3Q7IH08L3R0PjwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTI+PHR0PltMdW93ZW5dIEkgaW50ZXJwcmV0IHRoaXMgbG9naWMgYXMgdGhlIG5l
dHdvcmsgc3VwcG9ydA0KbW9iaWxpdHksIGFuZCBkZXBlbmRzIG9uIGFwcGxpY2F0aW9ucyBvbiBl
YWNoIGluZGl2aWR1YWwgbW9iaWxlIG5vZGUgdG8NCmNob29zZSB1c2UgdGhlIG1vYmlsaXR5IG9y
IG5vdC4gSSB0aGluayBpdCByZWFzb25hYmxlLCBhbmQgd2hldGhlciB0byBjaG9vc2UNCnVzZSBt
b2JpbGl0eSBzdXBwb3J0IG9yIG5vdCBpcyBhcHBsaWNhdGlvbnMnIGRlY2lzaW9uLjxicj4NCjxi
cj4NCiZndDsgWW91ciBwcm9wb3NhbCBkb2VzIG5vdCBjYXB0dXJlIHRoZSBjb25kaXRpb25hbGl0
eSBvZiBtb2JpbGl0eSBzdXBwb3J0DQpmb3IgZGlmZmVyZW50IGhvc3RzLCBhcHBsaWNhdGlvbnMs
IGFuZCBldmVuIGRpZmZlcmVudCBzZXNzaW9ucyBvZiB0aGUgc2FtZQ0KYXBwLiBJIHJlYWQgaXQg
bW9yZSBsaWtlPGJyPg0KPGJyPg0KJmd0OyAvLyBzZXQgdG8gMCBmb3IgZGlzYWJsaW5nIG1vYmls
aXR5IHN1cHBvcnQ8YnI+DQomZ3Q7ICNkZWZpbmUgTU9CSUxJVFlfU1VQUE9SVCAxIDwvdHQ+PC9m
b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+W0x1b3dlbl0gSSBpbnRlcnByZXQgdGhp
cyBsb2dpYyBhcyB0aGUgb3BlcmF0b3IgY291bGQNCmhhdmUgc29tZSBraW5kIG9mIGdsb2JhbCBj
b25maWd1cmF0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIHRvIHByb3ZpZGUgbW9iaWxpdHkNCnN1cHBv
cnQgdG8gYWxsIGl0cyBzdWJzY3JpYmVycyBvciBub3QuIEl0IG1heSBwcm92aWRlLCB0aGVuICNk
ZWZpbmUgTU9CSUxJVFlfU1VQUE9SVA0KMSAsb3RoZXJ3aXNlICNkZWZpbmUgTU9CSUxJVFlfU1VQ
UE9SVCAwLiBJIHRoaW5rIGl0IHJlYXNvbmFibGUsIHNvbWUgb3BlcmF0b3INCm1heSBvbmx5IHBy
b3ZpZGUgZml4ZWQvbm9tYWRpYyBhY2Nlc3Mgc2VydmljZS48L3R0PjwvZm9udD4NCjxicj4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsmZ3Q7ICZuYnNwO3xJIHdvdWxkIG5lZWQgdG8g
aW1wbGVtZW50IHRoZSAmcXVvdDttb2JpbGl0eQ0Kc3RhY2smcXVvdDsgd2hhdGV2ZXIgc3VwcG9y
dCBmdW5jdGlvbjxicj4NCiZndDsmZ3Q7ICZuYnNwO3xhbnl3YXkgZXZlbiBpZiBub25lIG9mIG15
IGFwcGxpY2F0aW9uIGNhcmUgYWJvdXQgaXQuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg
SWYgeW91IGFyZSBhYnNvbHV0ZWx5IHN1cmUgdGhhdCBub25lIG9mIHlvdXIgYXBwcyBuZWVkcyBt
b2JpbGl0eQ0Kc3VwcG9ydCwgYW5kIG5vbmUgd2lsbCBldmVyIG5lZWQgaXQgaW4gdGhlIGZ1dHVy
ZSwgdGhlbiB0aGVyZSdzIG5vIHJlYXNvbg0KdG8gaW1wbGVtZW50IGl0LCBzdXJlLiBCdXQgaWYg
dGhlcmUncyBhIGNoYW5jZSBvbmUgYXBwIG1heSBuZWVkIGl0IGFuZA0KMTAwIHdvbid0LCB0aGVu
IHBlcmhhcHMgeW91IGdldCB0byBpbXBsZW1lbnQgaXQuIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQs
DQppZiB5b3UgZG8gaW1wbGVtZW50IHRoYXQgJnF1b3Q7bW9iaWxpdHkgc3RhY2smcXVvdDssIHdp
dGggY29uZGl0aW9uYWwgc3VwcG9ydA0KeW91IHJ1biB0aGF0IGNvZGUgZm9yIG9uZSBhcHAgb25s
eSAoYW5kIHJvdXRlIHRoZSByZXNwZWN0aXZlIHBhY2tldHMgYWNjb3JkaW5nbHkpLA0Kd2hpbGUg
d2l0aCB0b2RheSdzIGFwcHJvYWNoIHlvdSBkbyB0aGUgc2FtZSBmb3IgMTAxIGFwcHMuPGJyPg0K
PGJyPg0KJmd0OyBGYWlyIHJlYXNvbmluZy4gSG93ZXZlciwgd2hhdCBpcyB0aGUgJnF1b3Q7bW9i
aWxpdHkgc3RhY2smcXVvdDsgaGVyZQ0KdGhlbj8gSXMgaXQgc29tZXRoaW5nIHdlIHRvZGF5IHVu
ZGVyc3RhbmQgYXMgYSBNSVAgZW5hYmxlZCBzdGFjayBvciBjb3VsZA0KaXQgYmUgc29tZXRoaW5n
IG1vcmUgZ2VuZXJpYz8gV2hhdCBJIG1lYW4gaGVyZSBpcyB0aGF0IHdlIHNob3VsZCBiZSB2ZXJ5
DQpjYXV0aW91cyB3aXRoIE1OIHNpZGUgaW1wYWN0cyBub3QgdG8gZnJlYWsgb3V0IGxlc3MgbW9i
aWxpdHkgY2F1dGlvdXMgcGVvcGxlLg0KSWYgdGhlICZxdW90O21vYmlsaXR5IHN0YWNrJnF1b3Q7
IGNvdWxkIGJlIGJlbmVmaWNpYWwgYWxzbyBvdXRzaWRlIG1vYmlsaXR5DQp1c2UgY2FzZXMgdGhh
dCB3b3VsZCBiZSBhd2Vzb21lLjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48
dHQ+W0x1b3dlbl0gSGkgSm91bmksIHdoYXQgZG8geW91IG1lYW4gJnF1b3Q7V2hhdCBJIG1lYW4N
CmhlcmUgaXMgdGhhdCB3ZSBzaG91bGQgYmUgdmVyeSBjYXV0aW91cyB3aXRoIE1OIHNpZGUgaW1w
YWN0cyBub3QgdG8gZnJlYWsNCm91dCBsZXNzIG1vYmlsaXR5IGNhdXRpb3VzIHBlb3BsZSZxdW90
OyA/ICZuYnNwO1RoZSBhcHBsaWNhaW9ucyBvbiB0aGUNCm1vYmlsZSBub2RlIGRvZXNuJ3QgbmVl
ZCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgdGhlIG1vYmlsaXR5IChpLmUuIHRoZSBhcHBsaWNhdGlv
bg0KZGV2ZWxvcGVyIGRvZXNuJ3QgbmVlZCB0byB1bmRlcnN0YW5kKSwgYW5kIGl0IHNlZW1zIHRv
IGxldCBhbiBvcmRpbmFyeQ0KdXNlciB0byB1bmRlcnN0YW5kIHRoZSBtb2JpbHR5IGNvbmNlcHQg
aXMgaW1wb3NzaWJsZS4gQXMgcGVyIG15IHVuZGVyc3RhbmRpbmcsDQp0aGUgYXBwbGljYXRpb24g
b25seSBjYXJlIHRvIGJpbmQgdG8gYW4gSVBAIHdoaWNoIGNhbiBzdXJ2aXZlIGxvbmdlciB0aGFu
DQppdHNlbGYuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPkJSPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5MdW93ZW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk
dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFj
ZT0ic2Fucy1zZXJpZiI+PGI+am91bmkga29yaG9uZW4gJmx0O2pvdW5pLm5vc3BhbUBnbWFpbC5j
b20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63
orz+yMs6ICZuYnNwO2RtbS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0x
IGZhY2U9InNhbnMtc2VyaWYiPjIwMTIvMTEvMTUgMTg6NTY8L2ZvbnQ+DQo8dGQgd2lkdGg9NTkl
Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249
cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4N
Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+S29uc3RhbnRpbm9zIFBlbnRpa291
c2lzICZsdDtrLnBlbnRpa291c2lzQGh1YXdlaS5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10
b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm
Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m
cXVvdDtkbW1AaWV0Zi5vcmcmcXVvdDsgJmx0O2RtbUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIg
dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt
c2VyaWYiPlJlOiBbRE1NXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMt
MDI8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K
PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+
PHR0Pjxicj4NCkhpLDxicj4NCjxicj4NCk9uIE5vdiAxNCwgMjAxMiwgYXQgODoyOCBQTSwgS29u
c3RhbnRpbm9zIFBlbnRpa291c2lzIHdyb3RlOjxicj4NCjxicj4NCiZndDsgSGkgSm91bmksIGFs
bCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7fE1heWJlIHdlIG5lZWQgdG8gdGhlbiBzYXkg
c29tZXRoaW5nIGFib3V0IGl0IGxpa2U8YnI+DQomZ3Q7ICZuYnNwO3wgJm5ic3A7JnF1b3Q7RGl2
ZXJnZW5jZSBmcm9tIG90aGVyIGV2b2x1dGlvbmFyeSB0cmVuZHMgaW4gbmV0d29yazxicj4NCiZn
dDsgJm5ic3A7fCAmbmJzcDsgYXJjaGl0ZWN0dXJlcyBzdWNoIGFzIGRpc3RyaWJ1dGlvbiBvZiBj
b250ZW50IGRlbGl2ZXJ5JnF1b3Q7DQo/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvdW5kcyBnb29k
IHRvIG1lLjxicj4NCjxicj4NCkdvb2QuPGJyPg0KPGJyPg0KJmd0OyAmbmJzcDt8Tm8gKHdpdGhv
dXQgc21pbGUpLiBCdXQgdGhhdCBpcyBhbm90aGVyIHRyZW5kIHRvIG9wcG9zaXRlIGRpcmVjdGlv
bjxicj4NCiZndDsgJm5ic3A7fGFuZCB3ZSBzaG91bGQgaGF2ZSBhIHN1ZmZpY2llbnQgYXJndW1l
bnQgZm9yIG91ciBhc3NlcnRpb24NCmhlcmUgaW1oby4gV2hhdDxicj4NCiZndDsgJm5ic3A7fGlz
IHNvIGZ1bmRhbWVudGFsbHkgcmVzb3VyY2UgY29uc3VtaW5nIGluICZxdW90O21vYmlsaXR5IGNv
bnRleHQmcXVvdDsNCmhhbmRsaW5nPGJyPg0KJmd0OyAmbmJzcDt8dGhhdCBpdCByZXF1aXJlcyBk
aXN0cmlidXRpb24/IElzIGl0IGp1c3QgYSBjb21iaW5hdGlvbiBvZg0KYWxsPGJyPg0KJmd0OyAm
bmJzcDt8ZnVuY3Rpb25zIGluIG9uZSBwbGFjZSAodGhhdCBoYXMgbGl0dGxlIHRvIGRvIHdpdGgg
bW9iaWxpdHkNCnBlciBzZSk/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgc2NhbGFiaWxp
dHkgaGVyZSByZWZlcnMgdG8gdGhlICZxdW90O2h1Yi1hbmQtc3Bva2UmcXVvdDsgbmF0dXJlDQpv
ZiB0aGUgcm91dGluZyBmYWJyaWMgYXMgaW50cm9kdWNlZCBieSBhICZxdW90O2NlbnRyYWxpemVk
JnF1b3Q7IG1vYmlsaXR5DQphbmNob3IuIFlvdSBtYXkgaGF2ZSB2YWxpZCB0ZWNobmljYWwgYW5k
L29yIG9wZXJhdGlvbmFsIHJlYXNvbnMgZm9yIGFkb3B0aW5nDQphIGh1Yi1hbmQtc3Bva2UgbW9k
ZWwsIHRoYXQncyBvay4gQnV0IG1heWJlIG90aGVycyBtYXkgd2FudCBhbiBhbHRlcm5hdGl2ZQ0K
bW9kZWwgd2hpY2ggYWltcyBmb3IgZGlmZmVyZW50IG9wdGltYWxpdGllcywgYW5kIGZvciB0aG9z
ZSB0aGUgaHViLWFuZC1zcG9rZQ0KbW9kZWwgaXMgbm90LCB3ZWxsLCAmcXVvdDtzY2FsYWJsZSZx
dW90Oy48YnI+DQomZ3Q7IDxicj4NCiZndDsgU0ROLCB3ZWxsIHRoZSBPcGVuRmxvdyBmbGF2b3Ig
b2YgaXQgYW55d2F5LCBpcyAmcXVvdDtsb2dpY2FsbHkgY2VudHJhbGl6ZWQmcXVvdDsNCndydCBu
ZXR3b3JrIGNvbnRyb2wsIG5vdCBob3cgcGFja2V0cyBtb3ZlIGFyb3VuZC4gU0ROIGNhbiBkbyBo
dWItYW5kLXNwb2tlDQphcyB3ZWxsIGFzIG90aGVyIHJvdXRpbmcgZmFicmljcy4gSW5mb3JtYXRp
b24tY2VudHJpYyBuZXR3b3JraW5nLCBhbm90aGVyDQptYWpvciB0cmVuZCwgaXMgZGVmaW5pdGVs
eSBub3QgcG9pbnRpbmcgdG93YXJkcyB0aGUgbWVyaXRzIG9mIHRoZSBjdXJyZW50DQp0eXBlIG9m
IGNlbnRyYWxpemF0aW9uLi4uIFNvIEkgdGhpbmsgUFMzIGlzIHZhbGlkLjxicj4NCjxicj4NClBT
MyBzYXlzICZxdW90O2NlbnRyYWxpemVkIHJvdXRlIG1hbmFnZW1lbnQmcXVvdDsuLiBJIHdvdWxk
IGJlIGZhciBtb3JlDQpjb21mb3J0YWJsZSBpZiBQUzMgc2F5cyAmcXVvdDtjZW50cmFsaXplZCB0
dW5uZWwgbWFuYWdlbWVudCZxdW90OyB3aGljaA0KaXMgbW9yZSBjb25jcmV0ZWx5IHdoYXQgd2Ug
ZG8gdG9kYXkgYXMgcGVyIGh1Yi1hbmQtc3Bva2UgdHlwZSB0dW5uZWxlZA0KdHJhZmZpYyBkZXBs
b3ltZW50cy48YnI+DQo8YnI+DQomZ3Q7ICZuYnNwO3xJIHdvdWxkIG5lZWQgdG8gaW1wbGVtZW50
IHRoZSAmcXVvdDttb2JpbGl0eSBzdGFjayZxdW90OyB3aGF0ZXZlcg0Kc3VwcG9ydCBmdW5jdGlv
bjxicj4NCiZndDsgJm5ic3A7fGFueXdheSBldmVuIGlmIG5vbmUgb2YgbXkgYXBwbGljYXRpb24g
Y2FyZSBhYm91dCBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgeW91IGFyZSBhYnNvbHV0ZWx5
IHN1cmUgdGhhdCBub25lIG9mIHlvdXIgYXBwcyBuZWVkcyBtb2JpbGl0eSBzdXBwb3J0LA0KYW5k
IG5vbmUgd2lsbCBldmVyIG5lZWQgaXQgaW4gdGhlIGZ1dHVyZSwgdGhlbiB0aGVyZSdzIG5vIHJl
YXNvbiB0byBpbXBsZW1lbnQNCml0LCBzdXJlLiBCdXQgaWYgdGhlcmUncyBhIGNoYW5jZSBvbmUg
YXBwIG1heSBuZWVkIGl0IGFuZCAxMDAgd29uJ3QsIHRoZW4NCnBlcmhhcHMgeW91IGdldCB0byBp
bXBsZW1lbnQgaXQuIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQsIGlmIHlvdSBkbyBpbXBsZW1lbnQN
CnRoYXQgJnF1b3Q7bW9iaWxpdHkgc3RhY2smcXVvdDssIHdpdGggY29uZGl0aW9uYWwgc3VwcG9y
dCB5b3UgcnVuIHRoYXQNCmNvZGUgZm9yIG9uZSBhcHAgb25seSAoYW5kIHJvdXRlIHRoZSByZXNw
ZWN0aXZlIHBhY2tldHMgYWNjb3JkaW5nbHkpLCB3aGlsZQ0Kd2l0aCB0b2RheSdzIGFwcHJvYWNo
IHlvdSBkbyB0aGUgc2FtZSBmb3IgMTAxIGFwcHMuPGJyPg0KPGJyPg0KRmFpciByZWFzb25pbmcu
IEhvd2V2ZXIsIHdoYXQgaXMgdGhlICZxdW90O21vYmlsaXR5IHN0YWNrJnF1b3Q7IGhlcmUgdGhl
bj8NCklzIGl0IHNvbWV0aGluZyB3ZSB0b2RheSB1bmRlcnN0YW5kIGFzIGEgTUlQIGVuYWJsZWQg
c3RhY2sgb3IgY291bGQgaXQNCmJlIHNvbWV0aGluZyBtb3JlIGdlbmVyaWM/IFdoYXQgSSBtZWFu
IGhlcmUgaXMgdGhhdCB3ZSBzaG91bGQgYmUgdmVyeSBjYXV0aW91cw0Kd2l0aCBNTiBzaWRlIGlt
cGFjdHMgbm90IHRvIGZyZWFrIG91dCBsZXNzIG1vYmlsaXR5IGNhdXRpb3VzIHBlb3BsZS4gSWYN
CnRoZSAmcXVvdDttb2JpbGl0eSBzdGFjayZxdW90OyBjb3VsZCBiZSBiZW5lZmljaWFsIGFsc28g
b3V0c2lkZSBtb2JpbGl0eQ0KdXNlIGNhc2VzIHRoYXQgd291bGQgYmUgYXdlc29tZS48YnI+DQo8
YnI+DQotIEpvdW5pPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3Qg
UmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgS29zdGFzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8
YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQpkbW1AaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K
--=_alternative 0026CAFE48257ABC_=--

From jouni.nospam@gmail.com  Tue Nov 20 00:03:40 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3126E21F857A; Tue, 20 Nov 2012 00:03:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.33
X-Spam-Level: 
X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-0.183,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoXv3DxVkSEO; Tue, 20 Nov 2012 00:03:39 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC68721F8538; Tue, 20 Nov 2012 00:03:38 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so4702622lbk.31 for ; Tue, 20 Nov 2012 00:03:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a+dr4Kcm0bDsTH8INq/Avlfs/h2JG2KUYbQpusDaf4Q=; b=htekhPzfRT/wU42mUmHZJ8eGBxxoo4PxVqPs1sfAfb7K4aswPZ51oFnhGQZzLH43uV WXkJa4/ZXqT043UdN1Akxa6+xZIKhU4ZMsSpXLiVoM4eAmaWRNAJzbphXN21lR2cKmYZ OP4ZP83ft493n2EBQaKtMQXf6Gzh0bKe+YKcMJrZaXQY20N3eZsXZ8JZQjWdDU3KYiOI wJr6lBwC9qXu59JR/bXDJEK4inJCeYZihbHrWOkBvmbEAzJqyFnZHadoV7URxmNg9pt4 GPZBYdaS3cBS7KLlpraZhb36GThGhgnwILDIKCsEWoCUByUrRU7+DOvGTlcPPPj+Ed0A 5B1Q==
Received: by 10.112.84.69 with SMTP id w5mr6212078lby.116.1353398617572; Tue, 20 Nov 2012 00:03:37 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id ts2sm4411324lab.10.2012.11.20.00.03.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 00:03:36 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Tue, 20 Nov 2012 10:03:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B730FDB-6094-471A-B830-9E7076B22070@gmail.com>
References: 
To: luo.wen@zte.com.cn
X-Mailer: Apple Mail (2.1085)
Cc: dmm-bounces@ietf.org, "dmm@ietf.org" , Konstantinos Pentikousis 
Subject: Re: [DMM] =?utf-8?b?562U5aSNOiBSZTogIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?q?dmm-requirements-02?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 08:03:40 -0000

On Nov 20, 2012, at 9:03 AM, luo.wen@zte.com.cn wrote:


[snip]

> >>  |I would need to implement the "mobility stack" whatever support =
function
> >>  |anyway even if none of my application care about it.
> >>=20
> >> If you are absolutely sure that none of your apps needs mobility =
support, and none will ever need it in the future, then there's no =
reason to implement it, sure. But if there's a chance one app may need =
it and 100 won't, then perhaps you get to implement it. The difference =
is that, if you do implement that "mobility stack", with conditional =
support you run that code for one app only (and route the respective =
packets accordingly), while with today's approach you do the same for =
101 apps.
>=20
> > Fair reasoning. However, what is the "mobility stack" here then? Is =
it something we today understand as a MIP enabled stack or could it be =
something more generic? What I mean here is that we should be very =
cautious with MN side impacts not to freak out less mobility cautious =
people. If the "mobility stack" could be beneficial also outside =
mobility use cases that would be awesome.
>=20
> [Luowen] Hi Jouni, what do you mean "What I mean here is that we =
should be very cautious with MN side impacts not to freak out less =
mobility cautious people" ?  The applicaions on the mobile node doesn't =
need to understand what is the mobility (i.e. the

I mean the below the "applications that any random developer can do" =
support.. i.e. middleware, vendor APIs, OS & IP stack level things etc. =
For example, if the "mobility stack" needs to hook deep inside the IP =
stack, it basically has to be part of the platform level baseline =
software to be successful. If the "mobility stack" is something that =
just requires higher privileges (like installing a driver) than a =
consumer has, then operators & enterprises can distribute required =
software at will.

- Jouni

>  application developer doesn't need to understand), and it seems to =
let an ordinary user to understand the mobilty concept is impossible. As =
per my understanding, the application only care to bind to an IP@ which =
can survive longer than itself.=20




From jouni.nospam@gmail.com  Tue Nov 20 00:09:22 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B613821F872A for ; Tue, 20 Nov 2012 00:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.533
X-Spam-Level: 
X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCkZ7hvKonSF for ; Tue, 20 Nov 2012 00:09:22 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DAAD421F858B for ; Tue, 20 Nov 2012 00:09:21 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so4706586lbk.31 for ; Tue, 20 Nov 2012 00:09:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MxcsJ+EfhhIZuxBH+uH6ZAFPAgfWkuA7/HUgHvxOPkc=; b=bg1vIaw9vgVASiAFIT7nesV/VaWwurE2kgLL3wa4htosJoFG3vVPnAuPgaW+oJsS6f KXKcWWYjGU1U0azbkmwdDLCZC9vA+4VYa0tfKNo4Swd+F0eYvI9YLd5IkD3XTmQrXY61 i+n2hLMYREojfotivHPIUkReCkgYNfraISoXguGY1LZkvWihMHSXJC47MbEN2aQfUOCe lsa+t9tQfE1tyQhUgOG56dyb4cqRyG9wyXDDnktCFI3kJfSno+DlHWI5GzWbEMcJzg1x ZQUZv0lDnKfahkymgMZRuoxfSKo3jP+DaJl8ewkZzJ5w/AISJNOhrkjKofjWeMX0fxPJ 1IlA==
Received: by 10.112.13.140 with SMTP id h12mr6191745lbc.12.1353398960776; Tue, 20 Nov 2012 00:09:20 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id g3sm4006369lbm.15.2012.11.20.00.09.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 00:09:19 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Tue, 20 Nov 2012 10:09:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0839BA60-9A5F-472C-83B8-6BF9FEFC6422@gmail.com>
References:    <50AA8E30.1050408@innovationslab.net> 
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1085)
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 08:09:22 -0000

Behcet,

On Nov 19, 2012, at 10:41 PM, Behcet Sarikaya wrote:

> Hi Brian,
>=20
> On Mon, Nov 19, 2012 at 1:53 PM, Brian Haberman
>  wrote:
>> Behcet,
>>=20
>>=20
>> On 11/19/12 12:25 PM, Behcet Sarikaya wrote:
>>>=20
>>> Hi all,
>>>=20
>>> Here is the requirement I have in mind:
>>>=20
>>> The DMM solution SHOULD support more than one cloud network =
belonging
>>> to the same DMM domain.
>>>=20
>>> Two points:
>>>=20
>>> The above requirement does have protocol impact.
>>=20
>>=20
>> Could you elaborate on what that impact would be?
>>=20
>> It is unclear to me what the impact of using a cloud service would =
be. The
>> IETF has not had to change other protocols in order to have them work =
within
>> "the cloud".
>=20
> I think it is early to say.

I am confused. If you think it is too early to say, then how can you =
claim cloud has an impact? If there is something concrete you have in =
mind, just say it.

- Jouni




>=20
> Cloud networks have been all Layer 2 based and because of that many
> mobility issues do not surface. For example virtual machine mobility
> is just change of Ethernet address and no IP layer changes are needed.
>=20
> However, I think that the trend is towards Layer 3 based clouds and
> also inter-cloud communication needs are increasing. For example there
> are many people advocating the development of an IETF virtual machine
> mobility protocol.
>=20
> I think we need to look at DMM from this perspective,and see if we can
> make our mobility protocols more suitable to the cloud.
>=20
> That is the reason why I wrote
> draft-sarikaya-dmm-cloud-mm.
> With even the simplistic assumptions, my drafts shows that the cloud
> does have some protocol implications on our protocols.
>=20
> Regards,
>=20
> Behcet
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From Marco.Liebsch@neclab.eu  Tue Nov 20 01:59:39 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1490A21F870F for ; Tue, 20 Nov 2012 01:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x8=0.8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLIZnQ+fKXuN for ; Tue, 20 Nov 2012 01:59:38 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B98DC21F8711 for ; Tue, 20 Nov 2012 01:59:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B165A10263F; Tue, 20 Nov 2012 10:59:32 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOUT1nZwqm2I; Tue, 20 Nov 2012 10:59:32 +0100 (CET)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 926E7102601; Tue, 20 Nov 2012 10:59:22 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.183]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 10:59:21 +0100
From: Marco Liebsch 
To: Peter McCann , "dmm@ietf.org" 
Thread-Topic: Comments on draft-liebsch-dmm-framework-analysis-00
Thread-Index: Ac29H8mOiU7yIlrkRtKAICgO6UHwIwAHRBfQACi1iQACSFgY0A==
Date: Tue, 20 Nov 2012 09:59:20 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D551538F4@Hydra.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE716E5556C@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D5513EEF1@DAPHNIS.office.hd> <5963DDF1F751474D8DEEFDCDBEE43AE716E558DA@dfweml512-mbx.china.huawei.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E558DA@dfweml512-mbx.china.huawei.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 09:59:39 -0000

Hi Pete,
please see inline. Sorry for the delay in continuing the discussion.

>-----Original Message-----
>From: Peter McCann [mailto:Peter.McCann@huawei.com]
>Sent: Donnerstag, 8. November 2012 19:43
>To: Marco Liebsch; dmm@ietf.org
>Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00
>
>Hi, Marco,
>
>Thanks for the response.  See below.
>
>Marco Liebsch wrote:
>> Hi Pete,
>> please see inline for my response.
>>
>>> -----Original Message-----
>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of
>>> Peter McCann
>>> Sent: Mittwoch, 7. November 2012 20:41
>>> To: dmm@ietf.org
>>> Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
>>>
>>> Let me ask a question to make sure I understand the approach this
>>> document takes to analyzing the problem space.  In the Introduction,
>>> you state:
>>>   "The initial version of this draft introduces a basic set of FEs and
>>>   interfaces between these FEs to support IP address continuity in DMM,
>>>   without being specific to the used mobility management protocol,
>>>   which operates below the mobility anchor."
>>> And later, you introduce the FE_MA to represent this mobility anchor.
>>> I
>>> *think* you are trying to define DMM as something that runs above
>>> another mobility management protocol.
>>
>> That would imply a solution and that is not intended. The four defined
>> DMM FEs can be mapped to components of existing protocols. My
>> intention is to define DMM FEs, which enable DMM use cases but are not
>> dependent on a mobility protocol. So, some functions can be applied to
>> existing components of, say, iBGP in a route reflector, or a LISP
>> resolver. But some components can be placed on a Mobile IP Home Agent
>> or even a Mobile Node. Then we can analyze if the function of the DMM
>> FE is implicitly supported by the existing protocol or if an extension
>> is needed. That's the rationale behind these FEs. The FE_MA is
>> mentioned as existing component and assumed as topological anchor of
>> the MN's IP address. Some or all DMM FEs may apply to the existing MA.
>> Depends on the analysis we want to perform.
>
>Ok I understand that you want to put some of your components in the existi=
ng
>mobility anchor (and at least the FE_MA would be there) but you also seem =
to
>be distinguishing between a DMM protocol that runs *above* the FE_MA and
>another mobility protocol that runs *below* the FE_MA.  Is that a correct
>interpretation?

The draft is not a solution, but a functional framework. As you write, some
functions can be placed on an existing mobility anchor (which may be even
co-located with an access router). Typically, the Egress Function is at the
MN's topological anchor after anchor relocation. To analyze if a mobility
protocol supports one or more of the required functions to enable DMM impli=
citly,
some of the other identified DMM functional entities could be placed
on the mobility anchor, or even on a MAG or a MN in case of host mobility.
See, this is solely for the analysis. But also for the identification and s=
pecification
of extensions. If we place the FE_IEC to an iBGP router, maybe the defined
DMM function is implicitly supported by the iBGP protocol. That's the
rationale behind the framework. And that was my intention to allow
enabling DMM with support from non-mobility protocols, e.g. being deployed
in the transport network. This can be in your example iBGP, or MPLS or Open=
Flow.

>
>>
>>>   Would it be legal to set the FE_MA equal to the access router, and
>>> the other mobility management protocol to NULL? That is, would it be
>>> allowed in your framework to use *only* the DMM protocol to get
>>> packets to an AR, to which the MN is currently attached?
>>
>> Yes, legal from my perspective  :-)
>
>Good.  It seems to me that designating the leaf node in your architecture =
as
>containing FE_MA is confusing because there may in fact be no mobility pro=
tocol
>running between FE_MA and AR (they may be one and the same entity).

Yes, then it's local IPC of a function call ;-) FE_MA is just a general nam=
ing of
the MN's topological anchor or, maybe better, point of attachment. The DMM
framework simply assumes that packets arriving at that point of attachment
can be forwarded to the MN without any help of the functional entities
of the DMM framework. If this is the Access Router or a Base Station, that
requirement is met.


>
>>> Section 3 states:
>>>   "Imported HoA/HNP
>>>   of a mobile node will be treated as identifier and non-routable IP
>>>   address (prefix), as it probably does not match the new mobility
>>>   anchor's location in the topology."
>>> I disagree.  The old address (prefix) will need to be routable at
>>> least inside the new anchor point.  If this anchor point is directly
>>> connected to the MN (i.e., it is the AR) then the route will be to a
>>> local link address.  If this new anchor point uses a tunnel to get
>>> the packets to the MN, then the old address will be routable to the
>>> tunnel interface.
>>
>> The assumption is of course that below a mobility anchor (FE_MA) the
>> mobility protocol performs location tracking and tunnel management or
>> whatever.
>
>Sure, but at least one node needs to have a "route" for the old IP address=
, even if
>it is just a route to a local tunnel interface.

If the DMM solution supports importing the 'old' address to the new point o=
f attachment
(mobility anchor, access router, whatever), then the FE_MCTX handles that.
Means the MN's current point of attachment knows the 'old address' and
has a state (mobility state at the anchor or Neighbor state at an Access Ro=
uter) to
allow association of the arriving packet with the attached MN.
If we do not importing the 'old' address context into the new point of atta=
chment,
then it's a scenario you refer to above and we need a state at the previous
point of attachment and tunnel the packet to the new point of attachment.
That would imply an indirect route via the previous point of attachment,
hence sub-optimal.

>
>> The defined DMM FEs enable the required level of indirection above or
>> at the mobility anchor.
>
>Right this reflects my understanding of your two-layer model.  I am just
>wondering why we can't further decouple ourselves from the mobility protoc=
ol
>that may exist beneath the FE_MA.  It may not exist or may only be at L2 (=
or L1).

The framework is exactly this: Decouple functions for DMM support from the
mobility protocol. If there is no mobility protocols, means the point of at=
tachment
is the MN's current access router, the Egress Function may be located on Ac=
cess Routers
and the control functions can be applied to existing or extended functions =
of the
transport network (LISP, iBGP, OpenFlow, ..)


>
>>> Elsewhere in Section 3:
>>>   "Forwarding can be for example accomplished by an IP tunnel to the
>>>   egress function, address translation to a routable IP address or
>>>   other means."
>>> I hope that "other means" can include installing an actual route for
>>> the destination IP on routers between the ingress and egress.
>>
>> Yes.
>
>Good.
>
>>> I'd be happy to provide a diagram and text to show how draft-mccann-
>>> dmm- flatarch can fit into this functional framework.  In the
>>> language of your draft, I think that the FE_MAs are integrated with
>>> the ARs, the FE_MCTX is the DNS server that stores the UE's current
>>> address, FE_E is co-located on the currently serving AR, and FE_I and
>>> FE_IEC are made up of a distributed network of routers running BGP
>>> (there is no single point of failure for FE_I).
>>
>> I have that picture in mind, just lack of time caused mapping examples
>> to be weak in version 00. I received other feedback and version 01 is
>> actually there. I'd be happy if you contribute to the draft with our
>> picture and text. By the way, the main motivation of the DMM FEs was
>> to allow analysis beyond mobility protocols, hence including your
>> solution proposal. I see the iBGP solution as hop-by-hop solution
>> where each transport network router gets a per-host state when
>> indirection is required. Each iBGP router hence implements an FE_I and
>> FE_E at the same time. But let's discuss details tomorrow.
>
>Sorry I had a conflict and couldn't attend DMM this morning.  I will take =
a look
>at your version 01 and contribute where necessary.

What about this: In iBGP, routers implement the control plane in a distribu=
ted
manner (if we do not assume route reflectors first). Routing states are
clear between an Ingress and an Egress Function. Each router needs to
have a per-host state to take further routing decisions on a per-hop basis.
That could look like this:

       iBGP Router
  +------------------+
  |      FE_IEC      |
  |      /    \      |
  |     /      \     |
--->FE_I------->FE_E----->data
  |                  |
  +------------------+


What do you think?

marco




>
>-Pete
>
>>
>> marco
>


From Marco.Liebsch@neclab.eu  Tue Nov 20 02:09:35 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B7F21F8845 for ; Tue, 20 Nov 2012 02:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.039
X-Spam-Level: 
X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x8=0.8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpzh0xp5hhNZ for ; Tue, 20 Nov 2012 02:09:33 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0D21F878D for ; Tue, 20 Nov 2012 02:09:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E21D0102601; Tue, 20 Nov 2012 11:09:26 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0SDGmRrDwQE; Tue, 20 Nov 2012 11:09:26 +0100 (CET)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C24EF102565; Tue, 20 Nov 2012 11:09:16 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.183]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 11:09:16 +0100
From: Marco Liebsch 
To: Marco Liebsch , Peter McCann , "dmm@ietf.org" 
Thread-Topic: Comments on draft-liebsch-dmm-framework-analysis-00
Thread-Index: Ac29H8mOiU7yIlrkRtKAICgO6UHwIwAHRBfQACi1iQACSFgY0AABcAxw
Date: Tue, 20 Nov 2012 10:09:15 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D55153920@Hydra.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE716E5556C@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D5513EEF1@DAPHNIS.office.hd> <5963DDF1F751474D8DEEFDCDBEE43AE716E558DA@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D551538F4@Hydra.office.hd>
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D551538F4@Hydra.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 10:09:35 -0000

..small correction in the figure below: Packets should arrive
at the FE_E of the iBGP router, then the next hop state is checked,
then packets are transmitted via FE_I. So please swap FE_I and FE_E in the =
figure.

marco

>-----Original Message-----
>From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of
>Marco Liebsch
>Sent: Dienstag, 20. November 2012 10:59
>To: Peter McCann; dmm@ietf.org
>Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
>
>Hi Pete,
>please see inline. Sorry for the delay in continuing the discussion.
>
>>-----Original Message-----
>>From: Peter McCann [mailto:Peter.McCann@huawei.com]
>>Sent: Donnerstag, 8. November 2012 19:43
>>To: Marco Liebsch; dmm@ietf.org
>>Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00
>>
>>Hi, Marco,
>>
>>Thanks for the response.  See below.
>>
>>Marco Liebsch wrote:
>>> Hi Pete,
>>> please see inline for my response.
>>>
>>>> -----Original Message-----
>>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf
>>>> Of Peter McCann
>>>> Sent: Mittwoch, 7. November 2012 20:41
>>>> To: dmm@ietf.org
>>>> Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
>>>>
>>>> Let me ask a question to make sure I understand the approach this
>>>> document takes to analyzing the problem space.  In the Introduction,
>>>> you state:
>>>>   "The initial version of this draft introduces a basic set of FEs and
>>>>   interfaces between these FEs to support IP address continuity in DMM=
,
>>>>   without being specific to the used mobility management protocol,
>>>>   which operates below the mobility anchor."
>>>> And later, you introduce the FE_MA to represent this mobility anchor.
>>>> I
>>>> *think* you are trying to define DMM as something that runs above
>>>> another mobility management protocol.
>>>
>>> That would imply a solution and that is not intended. The four
>>> defined DMM FEs can be mapped to components of existing protocols. My
>>> intention is to define DMM FEs, which enable DMM use cases but are
>>> not dependent on a mobility protocol. So, some functions can be
>>> applied to existing components of, say, iBGP in a route reflector, or
>>> a LISP resolver. But some components can be placed on a Mobile IP
>>> Home Agent or even a Mobile Node. Then we can analyze if the function
>>> of the DMM FE is implicitly supported by the existing protocol or if
>>> an extension is needed. That's the rationale behind these FEs. The
>>> FE_MA is mentioned as existing component and assumed as topological
>>> anchor of the MN's IP address. Some or all DMM FEs may apply to the
>existing MA.
>>> Depends on the analysis we want to perform.
>>
>>Ok I understand that you want to put some of your components in the
>>existing mobility anchor (and at least the FE_MA would be there) but
>>you also seem to be distinguishing between a DMM protocol that runs
>>*above* the FE_MA and another mobility protocol that runs *below* the
>>FE_MA.  Is that a correct interpretation?
>
>The draft is not a solution, but a functional framework. As you write, som=
e
>functions can be placed on an existing mobility anchor (which may be even =
co-
>located with an access router). Typically, the Egress Function is at the M=
N's
>topological anchor after anchor relocation. To analyze if a mobility proto=
col
>supports one or more of the required functions to enable DMM implicitly, s=
ome
>of the other identified DMM functional entities could be placed on the mob=
ility
>anchor, or even on a MAG or a MN in case of host mobility.
>See, this is solely for the analysis. But also for the identification and =
specification
>of extensions. If we place the FE_IEC to an iBGP router, maybe the defined=
 DMM
>function is implicitly supported by the iBGP protocol. That's the rational=
e behind
>the framework. And that was my intention to allow enabling DMM with suppor=
t
>from non-mobility protocols, e.g. being deployed in the transport network.=
 This
>can be in your example iBGP, or MPLS or OpenFlow.
>
>>
>>>
>>>>   Would it be legal to set the FE_MA equal to the access router, and
>>>> the other mobility management protocol to NULL? That is, would it be
>>>> allowed in your framework to use *only* the DMM protocol to get
>>>> packets to an AR, to which the MN is currently attached?
>>>
>>> Yes, legal from my perspective  :-)
>>
>>Good.  It seems to me that designating the leaf node in your
>>architecture as containing FE_MA is confusing because there may in fact
>>be no mobility protocol running between FE_MA and AR (they may be one and
>the same entity).
>
>Yes, then it's local IPC of a function call ;-) FE_MA is just a general na=
ming of the
>MN's topological anchor or, maybe better, point of attachment. The DMM
>framework simply assumes that packets arriving at that point of attachment=
 can
>be forwarded to the MN without any help of the functional entities of the =
DMM
>framework. If this is the Access Router or a Base Station, that requiremen=
t is
>met.
>
>
>>
>>>> Section 3 states:
>>>>   "Imported HoA/HNP
>>>>   of a mobile node will be treated as identifier and non-routable IP
>>>>   address (prefix), as it probably does not match the new mobility
>>>>   anchor's location in the topology."
>>>> I disagree.  The old address (prefix) will need to be routable at
>>>> least inside the new anchor point.  If this anchor point is directly
>>>> connected to the MN (i.e., it is the AR) then the route will be to a
>>>> local link address.  If this new anchor point uses a tunnel to get
>>>> the packets to the MN, then the old address will be routable to the
>>>> tunnel interface.
>>>
>>> The assumption is of course that below a mobility anchor (FE_MA) the
>>> mobility protocol performs location tracking and tunnel management or
>>> whatever.
>>
>>Sure, but at least one node needs to have a "route" for the old IP
>>address, even if it is just a route to a local tunnel interface.
>
>If the DMM solution supports importing the 'old' address to the new point =
of
>attachment (mobility anchor, access router, whatever), then the FE_MCTX
>handles that.
>Means the MN's current point of attachment knows the 'old address' and has=
 a
>state (mobility state at the anchor or Neighbor state at an Access Router)=
 to
>allow association of the arriving packet with the attached MN.
>If we do not importing the 'old' address context into the new point of
>attachment, then it's a scenario you refer to above and we need a state at=
 the
>previous point of attachment and tunnel the packet to the new point of
>attachment.
>That would imply an indirect route via the previous point of attachment, h=
ence
>sub-optimal.
>
>>
>>> The defined DMM FEs enable the required level of indirection above or
>>> at the mobility anchor.
>>
>>Right this reflects my understanding of your two-layer model.  I am
>>just wondering why we can't further decouple ourselves from the
>>mobility protocol that may exist beneath the FE_MA.  It may not exist or =
may
>only be at L2 (or L1).
>
>The framework is exactly this: Decouple functions for DMM support from the
>mobility protocol. If there is no mobility protocols, means the point of
>attachment is the MN's current access router, the Egress Function may be
>located on Access Routers and the control functions can be applied to exis=
ting or
>extended functions of the transport network (LISP, iBGP, OpenFlow, ..)
>
>
>>
>>>> Elsewhere in Section 3:
>>>>   "Forwarding can be for example accomplished by an IP tunnel to the
>>>>   egress function, address translation to a routable IP address or
>>>>   other means."
>>>> I hope that "other means" can include installing an actual route for
>>>> the destination IP on routers between the ingress and egress.
>>>
>>> Yes.
>>
>>Good.
>>
>>>> I'd be happy to provide a diagram and text to show how draft-mccann-
>>>> dmm- flatarch can fit into this functional framework.  In the
>>>> language of your draft, I think that the FE_MAs are integrated with
>>>> the ARs, the FE_MCTX is the DNS server that stores the UE's current
>>>> address, FE_E is co-located on the currently serving AR, and FE_I
>>>> and FE_IEC are made up of a distributed network of routers running
>>>> BGP (there is no single point of failure for FE_I).
>>>
>>> I have that picture in mind, just lack of time caused mapping
>>> examples to be weak in version 00. I received other feedback and
>>> version 01 is actually there. I'd be happy if you contribute to the
>>> draft with our picture and text. By the way, the main motivation of
>>> the DMM FEs was to allow analysis beyond mobility protocols, hence
>>> including your solution proposal. I see the iBGP solution as
>>> hop-by-hop solution where each transport network router gets a
>>> per-host state when indirection is required. Each iBGP router hence
>>> implements an FE_I and FE_E at the same time. But let's discuss details
>tomorrow.
>>
>>Sorry I had a conflict and couldn't attend DMM this morning.  I will
>>take a look at your version 01 and contribute where necessary.
>
>What about this: In iBGP, routers implement the control plane in a distrib=
uted
>manner (if we do not assume route reflectors first). Routing states are cl=
ear
>between an Ingress and an Egress Function. Each router needs to have a per=
-
>host state to take further routing decisions on a per-hop basis.
>That could look like this:
>
>       iBGP Router
>  +------------------+
>  |      FE_IEC      |
>  |      /    \      |
>  |     /      \     |
>--->FE_I------->FE_E----->data
>  |                  |
>  +------------------+
>
>
>What do you think?
>
>marco
>
>
>
>
>>
>>-Pete
>>
>>>
>>> marco
>>
>
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm

From h.anthony.chan@huawei.com  Tue Nov 20 08:52:24 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7180821F86C4 for ; Tue, 20 Nov 2012 08:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.563
X-Spam-Level: 
X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM6kLYZrpMIm for ; Tue, 20 Nov 2012 08:52:21 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0466921F8695 for ; Tue, 20 Nov 2012 08:52:18 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMZ21784; Tue, 20 Nov 2012 16:52:18 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 16:51:48 +0000
Received: from SZXEML446-HUB.china.huawei.com (10.82.67.184) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 16:52:16 +0000
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.221]) by szxeml446-hub.china.huawei.com ([10.82.67.184]) with mapi id 14.01.0323.003; Wed, 21 Nov 2012 00:52:10 +0800
From: h chan 
To: "luo.wen@zte.com.cn" , "dmm@ietf.org" 
Thread-Topic: Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirements-02
Thread-Index: AQHNxsdoSre8JpjtD0y1+b2Iza8SQZfy51Og
Date: Tue, 20 Nov 2012 16:52:09 +0000
Message-ID: <6E31144C030982429702B11D6746B98C36494847@SZXEML510-MBS.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.157.175]
Content-Type: multipart/related; boundary="_005_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirements-02
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 16:52:24 -0000

--_005_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_
Content-Type: multipart/alternative;
	boundary="_000_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_"

--_000_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for drawing the figure to explain your comments.

Let me try to understand by rephrasing in terms of a well-known cellular ne=
twork analogy:

The blue area is GPRS. The green area is WCDMA
WCDMA can be deployed incrementally.

In your figure, the Green area is inside the blue area. So, the green area =
in your figure is WCDMA+GPRS

Figure B:
When a phone was in the GPRS only area, and move to an WCDMA+GPRS area. The=
re was an option for "new session" to use WCDMA.  Yet the session with exis=
ting GPRS simply continues to use GPRS without breaking session continuity.

Figure A:
When a phone was in the WCDMA+GPRS area, and move to an GPRS only area:
If there was existing GPRS session prior to the move, the GPRS session cont=
inues.
If there was WCMDA session prior to the move, the WCDMA session was not sup=
ported outside the WCDMA session.

In the later case, you could in principle perform a handover from WCDMA to =
GPRS. Yet the data-rate could drop. You can only perform such a handover on=
ly if the data-rate performance allowed by GPRS can support that particular=
 application session.

I would not go too far with compatibility that the user should see no diffe=
rence. In this analogy, the user may see a difference in performance whethe=
r it is in WCDMA or GPRS network in terms of data rate etc, else there was =
no need for WCDMA.

H Anthony Chan

From: luo.wen@zte.com.cn [mailto:luo.wen@zte.com.cn]
Sent: Monday, November 19, 2012 8:33 PM
To: dmm@ietf.org; h chan
Subject: Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirements-02


Hi All,

I have a comment on REQ5:  Compatibility of draft-ietf-dmm-requirements-02.=
 What is not clear to me is that the meaning of the terms "compatibility\co=
mpatible\interoperate\co-exist" is not specific. Here is my clearification =
as following based on the comment I provided in the last DMM session in Atl=
anta.

Consider the scenario which is illustrated in figure A & B:
Assuming operator A has already deployed PMIP protocol in city A (blue area=
 in both figures), and wants to deploy dmm enabled euqipment in a certain a=
rea of city A in incremental manner (green area in both figures). Operator =
A needs the dmm protocol enabled area to be compatible\interopertable to ex=
siting PMIP protocol enabled area.  Here, operator A may have different req=
uirements in terms of compatible\interopertable which are illustrated in fi=
gure A and B respectively.

Figure A, consider as roaming scenario. Any mobile node, as long as it is a=
 subscriber of operator A, can be attached to operator A's network in both =
blue and green areas. The mobile node can not see any difference. E.g. assu=
ming mobile node is now in green area, powered on, and initial attachment i=
s performed (be asigned with an IP@). Then the mobile node can access the s=
ervice provided by operator A (internet access and etc.).  In "roaming" sce=
nario, when mobile node leaves green area and enters into blue area, the mo=
bile node may need to perform initial attachment percedure again (be asigne=
d with another IP@) for the purpose of accessing operator A's service. In t=
his case, session continuity may not guaranteed when mobile node moves betw=
een the green and blue areas (i.e. IP@ may change when mobile node moves ac=
cross the border of the green and blue area).

Figure B, consider as handover scenario which requires more than the roamin=
g scenario. E.g. assuming mobile node is initialized in blue area (be asign=
ed with an IP@) and enjoys session continuity support when it moves within =
the blue area. When the mobile node enters the green area, in this handover=
 scenario, the session continuity for sessions which have already setup sha=
ll be maintained (i.e. keep IP@ unchanged). The same requirement may also b=
e applied to the scenario that when the mobile node is initialized in green=
 area and moves to blue area.

What I suggest is that we should make the terms "compatibility\compatible\i=
nteroperate\co-exist" more specific. I suppose adding some usage cases or u=
sage scenarios may help to understand REQ5 better.

[cid:image001.gif@01CDC708.FFDD4750]

[cid:image002.gif@01CDC708.FFDD4750]

Any comments are welcome.

BR
LUOWEN

--_000_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks for drawing the fi=
gure to explain your comments.



 <=
/p>

Let me try to understand =
by rephrasing in terms of a well-known cellular network analogy:=



 <=
/p>

The blue area is GPRS. Th=
e green area is WCDMA



WCDMA can be deployed inc=
rementally.


 <=
/p>

In your figure, the Green=
 area is inside the blue area. So, the green area in your figure is WCDMA&#=
43;GPRS


 <=
/p>

Figure B:


When a phone was in the G=
PRS only area, and move to an WCDMA+GPRS area. There was an option for =
“new session” to use WCDMA.  Yet the session with existing=
 GPRS
 simply continues to use GPRS without breaking session continuity.


 <=
/p>

Figure A:


When a phone was in the W=
CDMA+GPRS area, and move to an GPRS only area:


If there was existing GPR=
S session prior to the move, the GPRS session continues.



If there was WCMDA sessio=
n prior to the move, the WCDMA session was not supported outside the WCDMA =
session.



 <=
/p>

In the later case, you co=
uld in principle perform a handover from WCDMA to GPRS. Yet the data-rate c=
ould drop. You can only perform such a handover only if
 the data-rate performance allowed by GPRS can support that particular appl=
ication session.



 <=
/p>

I would not go too far wi=
th compatibility that the user should see no difference. In this analogy, t=
he user may see a difference in performance whether it is
 in WCDMA or GPRS network in terms of data rate etc, else there was no need=
 for WCDMA.



 <=
/p>

H Anthony Chan=



 <=
/p>



From: luo.wen@=
zte.com.cn [mailto:luo.wen@zte.com.cn]


Sent: Monday, November 19, 2012 8:33 PM

To: dmm@ietf.org; h chan

Subject: Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirem=
ents-02




 




Hi All,




I have a comment on REQ5:  Compatibility of draft-ietf=
-dmm-requirements-02. What is not clear to me is that the meaning of the te=
rms "compatibility\compatible\interoperate\co-exist" is not
 specific. Here is my clearification as following based on the comment I pr=
ovided in the last DMM session in Atlanta.




Consider the scenario which is illustrated in figure A &=
; B:  


Assuming operator A has already deployed PMIP protocol in c=
ity A (blue area in both figures), and wants to deploy dmm enabled euqipmen=
t in a certain area of city A in incremental manner (green
 area in both figures). Operator A needs the dmm protocol enabled area to b=
e compatible\interopertable to exsiting PMIP protocol enabled area.  H=
ere, operator A may have different requirements in terms of compatible\inte=
ropertable which are illustrated in figure
 A and B respectively. 



Figure A, consider as roaming scenario. Any mobile node, as=
 long as it is a subscriber of operator A, can be attached to operator A's =
network in both blue and green areas. The mobile node
 can not see any difference. E.g. assuming mobile node is now in green area=
, powered on, and initial attachment is performed (be asigned with an IP@).=
 Then the mobile node can access the service provided by operator A (intern=
et access and etc.).  In "roaming"
 scenario, when mobile node leaves green area and enters into blue area, th=
e mobile node may need to perform initial attachment percedure again (be as=
igned with another IP@) for the purpose of accessing operator A's service. =
In this case, session continuity
 may not guaranteed when mobile node moves between the green and blue areas=
 (i.e. IP@ may change when mobile node moves accross the border of the gree=
n and blue area).




Figure B, consider as handover scenario which requires more=
 than the roaming scenario. E.g. assuming mobile node is initialized in blu=
e area (be asigned with an IP@) and enjoys session continuity
 support when it moves within the blue area. When the mobile node enters th=
e green area, in this handover scenario, the session continuity for session=
s which have already setup shall be maintained (i.e. keep IP@ unchanged). T=
he same requirement may also be
 applied to the scenario that when the mobile node is initialized in green =
area and moves to blue area.




What I suggest is that we should make the terms "compa=
tibility\compatible\interoperate\co-exist" more specific. I suppose ad=
ding some usage cases or usage scenarios may help to understand
 REQ5 better. 











Any comments are welcome.




BR 

LUOWEN







--_000_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_--

--_005_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=23789;
	creation-date="Tue, 20 Nov 2012 16:52:06 GMT";
	modification-date="Tue, 20 Nov 2012 16:52:06 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhzwLgAecAAOjo8P///8DAwJDQUCAgIDg4OLi4uICAgMjIyEBAQAAAAHh4eFBQUGBgYODg
4NjY2JCQkKCgoHBwcPDw8LCwsDAwMKiwuHBweOjo6CgoKPgAAEhISODg6PggIBgYGKioqNjY6NDY
4IiIiJiYmFhYWNDQ0MjQ2PiAgBAQGAAA+LjAyJCQmICAiKCosGiYODA4MLC4wAgICJigqGBoaJiY
oFhYYIiIkEhoKMDI0AgIEBAQEPg4OPjIyHh4gGhoaGhwcGBgaIjISJDQOFBQWCgwGFhgYIC4SBgY
IBgYEGCIMPi4uEBYKPiQkCAgKDgAEFiAMICwQHioQHjQUPhgYABQOFBYUGhocIjASPhQUBAYECAo
GCAoIDhQIPjg4BAQCBggEGiQOGig2HCoQCAoKDBAIDhAOEBIQEhQSEiI4FBwKFCQ4FCwUGCY2Pjw
8CAgGCAwGDBIIDgAIFhgWJCQIJCYoBAYCBggGCg4IECA4FBYWFB4KHB4eHCgOJCwKJDIUNhgYAhQ
kBBooCBgeCBgyCBwQCh4kDiQUEhwiEiIaFCYgGB4mGCoaGhQAHhwEICw4IigaJDI6KDAiKDYcKjg
8LjQoMiQmMjw+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAzwLgAUAI/wADCBxI
sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN
mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp0MVQJ3qVCrVq1izas1pNSMCBREQHChAQGABBQUM
ElCAIMCDAgUeBICLIEIDBQc8jj2412HfmATaFnQgF+FfhA8cjOy6tbHjx5A9Mr74VTBBuAIdEGAw
MHAACAQIQJibViHduhEEelbdlkEBBAYYeD5AoAHsApwD9G1AgAJsCQJl+26AuWDtumQF/n1wXKxc
17BlWx4IOjfvvKw7t+0rgUDYCKn/Hv82mxc8AgqiOU6OzL69+/cD18Ofb1I+/fv48xe1jxBBgbwI
lKWbgAEwkFsAEpQ2kH95ETeQZm1FICAECmZGgAEDOfgAW9oNSFB6e22IoUAGlKWZXMwpRgB2c+VF
AHACSWhQgIqZxZmMn1WoGoyqYUjbh6OtONB/Hg5WomBCfkYggml9VZhBBsa45EL86WfllVjOVOVK
Ab6m0QEHQhRaaiF1OZ1fYRq1ZZZstulmSGuyWRlEY3n3Xpxv5qnnng/h+ZRnAS44pVkEwMVZoIQe
KFuNBHU3mJ2R+cnnpJTyKWmlV16K6aacdrrUAix6KuqopJaKFQUbmKrqqqy26pNmE7j/KuustNZa
UgVn2qrrrrz2epAEIvgq7LDEyvpBmsUm+9MEFCyQgAIZJLDACAbEupIBESzgGloLfICBsrM+kIG1
4Ja7kgM+EDACfR8kwEAJ5mI5gZfx1guSf/B26kACFNjbWAPr+itwRiLwuCCHBQBXwGh9/WgWcKtd
hh1vDPRbUF9EkpddAElyLBhvcHHYsILMjXiAAqGlrFuFGUu8sccHFTywUiM0MFEKAeA8884FCMCr
Ax4MLEC2Q5yVQwEkXNACDAA07fTTUEct9dRUV2311VhnrfXWXFsdggU2XFBABgocUQCoBjC6c1AM
fFBQcRZiV5sCT3LsaABf8UYQcw4e/2TAAaMtGMDfZAr0wAEHjNjiZwc82bIDiKt9+GgtE/T3AYy2
9fdAERxQuFuIK04QAhV0WgIEQ6BAQBE0mND167DHLvvstNdu++2yWyB2DBUsQAG5a380QcUPIGB8
3QIhQG7dlk335ATIL+h55qMPZAAEign2wAQOQPD59gM9AAEEdR+OIfgGgRcA9Mkb9Lfo12ePdwLf
0hdB6iTIgPv+/Pfv//8ADKAAt2YCFmSgCQuIXvAWMoIMfO5KFKhAqLLygAWggAFMG6AGN8jBDnrw
gyCMXQh6gIIhiG6BCHGACDagAxJEoH5DmcAHGuCBAohAgQf5AAF8oLahPGADBbBACP+HSMQiGvGI
SAQhCC6QHhRiqYES6KFJSlCBC3AgiVjMoha3yMUuyg4GEnQim0CzABg+xAoNuKIX18jGNrrxjV4E
Y67EqJ+3MPECIICjHvfIxz76cYN7WAAd2zMCEsCOAyzwQA/U+MdGOvKRkOQjDsY1yKlgAAWMFCAH
LuABFmRSgCGwgg6IoAcjDOCUqEylKlfJyla68pWwhKULuOCFMugvkrjMJRx7IMhKJiUHedziEj1g
A6vhYAs3CEIsl8nMZjrzmdBcpRjeIAFdWvOaIZxBsHwpFJwFDWdtNAERTKnKKyyhDk+I5in94MpI
GEAEBjCePI0XAUGwU534zGcs0+D/gwDmLAAA+Cc2B8rHf9bgn9wESgUyyEUYvEGfqTTCOZMQS0pY
ABJhYAMb1MBRNKAhDBQ4hCAgStKSuhIMZSCoSlfKNX4llCgL1aIJsmDSZUriAQ8owQMwgIA/VAIB
OXUAYRQRCHLW9KhHfUIVWMrUpj7NpS89CtA+ScQQeAGpWM2qVqGpBzk49asEZYEVojoVIBTziByw
AxS2KoQ4SGEAjFCAIQYwByoMQAhOWMMp58CFMbx1q4CF5RJEANbC5hIEFcgXWR9DgQQE04gqsANF
A0vZyq7yCmQwpGE3+0gabAB4i61jBVagRRWYIQs3MKplV8tKMMBBB57krGwdGYIK/2wztKRCjxX5
qAIZXKAKL4iBAohAhBsY1wXIdSYUkPsE43KBCFlQwBZecAEWWOCxs82uNcEIBDPiNlkOsAIKWIBd
OHKgAAzVrnqbCoMNZMBt341v+A5whASsgKoabEEC1svfSOJgBiWEr3wHfBIHjGADMdiADVyHtQS0
oL8QzmILZuCBJkjAZwTOcFIEkADQpjBbBYgBATZwgetG+MQqWMEMQtyEIRwAwxqOcWRcSJQSGOAD
C3BWAY6ggBjAZQYXsIEF0htCgDbNyEO0gAVWcIEfwCUHCjja2RYAAQOcUMZYJlUJCuDdLHv5y7MC
FpjHTGZWvUWKZU5zJXOs5pSwuf/NcH7KmxXiMOsRQDFwwdHgCDCB1eSZQCXqc654EwHQYAcuDTjA
XTDknyoXZyz/oU1pEMU3CujNLbVRdHIuxgDw1EY5cDlAv3BDAQkogNELMwDcLvOfBPm5YqZm9GYk
AKY7401AfEPcpw1ANwvJhdCGFsh16jTBxXEsYXVyyJzjzOykLHtmiJqInl/y7GZbeyjVDh9elBIx
nUQbK9m+0gk00IEdmJsJATjBFFLCBA24G93XtlK4sxNtRBXAZgT5i4Q8vJpo70UzFnOZxjiGnb8k
qdu3HshfiGRwABEIUeJJC8ANUrmDKS5JJQLTQe79IALIpc68bsuLDLJw7IRcNdj/kRCjGpAbhB9k
3voZ9w4K0gEN8CDd7q55zU8QgC7kvAM7DwAPyE2QHZAb6DMniBLI3YWBdKHmSog3fmAudYtQvepY
n8nVJXIhBA2K3grA96UJQoER9Y0goBmRj2wdoLXbLFZww9z6Rg6zvAl7UA8gE2iU8+kJ8Lpf88pL
3gWy94LwmkwROPXA99ZEJCEJO3cztuUExHGPbD3rmG/J5aPqgBJdGSWbz7zoR0/60pv+9KhPvepX
z/rWu/71sI+97GdP+9rbnlaaWn3ubw/73R/kK7TuTm4wkzEi+bk0ZEGcbE64bxIJqIkwIwiEBmSt
PodH4r3pEKQKpKOC4Ig21jp7/4IedSaWY7oAqZFAywMHs75sn+8DGf/b8gL+j/ie962//+n1j3/V
7/7bGeFyDDEeftF9XjEoAGgTHUMRmlFxVNJ/EFgQa5J4tBZqCbcyA9FnkcYAEaIAFUgkDXgA6hcx
Z/F5plaBrqEcHiiCuSFpIkh3fZF4icYbltEdLFIiidYXFBB2iiYbM1IoH3gZimcQzMEAL0gmLtgd
MIKDiFMaf3EdIygYsnEAscIbtJaCF1gQImIcBpMQ/BeBpveFpCeGYDh6ZCgUgPJwgwJ9ySMgc7Jn
AqF+BwEpkRcpZRiBZ/geb4FvbpKHd4h1DJAAgjiIhFiIhniIiJiIiriIjNiIhv9YADXkiJI4iZRY
iZZ4iZeILH+4iVAxARmAQ5wYiqXXNqJYiqknM6aYiqRHOqrYipnXZ2jmirIYZ6Q4i/MhAA2gAw3w
eUiBAD7QQgFniwPYS8KYFRTgQHpiABkQMKYoAAZYjEsxAQkAY1+BhRbSN7TRHeQigNKHALGohXNE
cIjhjQr3jL+XK0AleQqRjoORAV1Gew5QAd8IjUiBATqAEBNAhZxjPYGzOZajjwVRZW6RIBJwZddD
eIojkLpBLiwXKwAJAQzAMLFykIMzGhCAOBg5IhAZkWiXMBOgkGhnMuQCkAeBKzGGAVZ2AAtQAwVQ
AQoALbhxAT2gZOXVQUiGZB7/9DW6cwEk0JIvmQEFsAE5VnaKJYs0tivOWCsPgGMJgAIoUAAXIAMM
dmLqxQEWwAIkQDYVAAQQAGNV1zNDoiNYKCR7xwA2gyhzYpYcc30UVyhwwXH1JiASkjB3UzmewXBu
aSgYOCTF1h3/MZaWkZdwMRpzKQF1SEUeVkcikAA5wAArUJNUGZlZpAI/kAFHAAQCRmATQALEWCkQ
QD/sUQJAgAIkQGSSeZraBQI2QAAVMAKJOUgfUAFQBRkIwEI68EBUoWoF8GCo2Zu+STsh8AMeUEYD
hi3achYEkAC0ZgBeSRnv5CxaKZTU8poc4QAN8F454QBFowK/2Z3eOUQc0APv/0ePiEECFRCMGjEB
QEACkPmd7vmeWtQCBNCc5JkQJeAaV/YAFcCd8Nmf/tlIDdCZ9ck5DFA1KpAA6PWfCrqgcKQCFUCd
oTgBHhAC/KMCBZAA/OlFuvMCCvAFcHADLnAFrJVKYvAES0AECuAGVbACU8mgLmpE2iSKG3BLRGQB
QYkDtINISLAEqjWiPtpKT5AFVdCiL1qkt5MB4Wh7DqZHFgCURBAFPxqlW3UDDWCkVto1FUCftOdN
AtVFJvAFyuRMSeCha6VOBtACkzAJkOAIYdCmGSUDNlAIYSqlWfUEmsU/AtWlVzpbBoVQvDcBOYBf
RzQDaTCiJaACbbpRaIAHeP8wCI6qAhEACIlAp6sVA+25pwx6AQIKgQ/gAVqkACPqB1dgBGAABg0g
B3LQAD7gA8CyCJQ6ojdwAZhqpCtwUKkok0nEAktAWW0FBn51V06QBnaFV2uQVwPQB7/6qlplBEgg
qLPqniBga/SIKs7qQT9wA8qarSYVBXdApM8Kny3wWQPKEBhQADSARRBgB4WqrezKrWZAod+qoCCQ
AMw4rhwxAhUgRF2EAxfgBl+wBEkwp+zqSlGQBmQQA2dAA9Uar/AJAj+QAPNorysRAR6AR9c0AyzA
sBrLNRZQAUMQsRJrFPiaAffFRSZQAfC6sSqrAiSAAgsAsiFrJQgwmvZ1qbH/cwGyqrIvqgIAVgAj
8I4xWy+nMwQ6oABDwKI6C2G6kwC84zsQGrQvBQE+UBJ+dwBAUAAogBYktgIWsLBJa0y6s2IeoACy
uQARUJRQi3UTkFi2gjM6k7ZwqxHHErd060TSqKV1m7f1YgAJoLd+GxFXdzmI80AXGT0U8JCNYxCH
+7QTQYBZyBAJeBLcuI5flxEOiBtWt6l/O2ZXV2e3dmilwXJdF33FIbojgnCFN398ORcwsiHbQSCa
IWuqwX6dwSKe2yOEJyB/ESVv07ocQhDWmJbIQiOdARyIQncb0wAS0AD4lrrUsSQLOHARM7kEEXqb
O2DWu3rZe73fBXOAogAc/+gfpcFrB2A89Fco6YgbhFF5heIbZPEa6IFv3ZE2fUMWEIAAEAAWtyYB
Uogh+VsYCFeN51EotpG/ZMIA/ttrAiy+fGcb8RuHF2KdyHdvyjM67YsAsWY3nfFAO3i/DDwgtoEA
l4YeqQEaiiFpQCXCv+aGLyIYp5G/FlMoIPlymitu7nbDN1dzOawBURcARsdz48ZzPqwBPDd0PCwQ
47ZuATAFGgBvRXfE7dYB3LsR27srJQKz+WaOMFHFVsIEQAd0QjzFP8HFCtEduGk4bMgS88gctFsT
8/u0bJyBEUEWWCwRZCzGCXXHBTF2s6sWbRGXfnx3UJImlZfFwDtpBFIo9P+mhhSXciKjIHU4cIl3
JvU3d2TigJXcIeLYGc47JHw4OL3GEXqMx2tWw7Q3yqScyqq8yqzcykSBtx8Byx4hyx1ByxxhyxuB
yxqhyxnByxjhyxcBzBYhzBVBzBRhzBOBzBKhzBHBzBDhzA8BzQ0hzdN8EtTMENe8ENmsENucEN2M
EN98EOFsEONcEOVMEOc8EOksEOscAO38ztZsEvAsz/FMz/ZcEvOMz/Wsz/dMEvnsz/sM0P0sEv88
EgVN0AFt0AmN0APN0Pz80AIN0Qrd0CGxzgdd0QuN0RQNEhfN0Rnt0Rsdyx8t0iE9yyNdyyeN0iWt
0hLt0BH90hPd0hot0yD/TdMkbdMmjdMsDdMuHdM8PdM/XdNBfdNDndM6fcspjdQrnctJzdRL7dRH
DdVFvdMSCIZ52NFE3dNaDdQ+3dVbLdRezdUE4YdZd9VNvctPjdZp3ctnzdZr/csjTdY8QZGG18YK
QdcwQZIZCIp4fRCJsRhU/dVZLdaEDdaCbdRTrdRRrdYHQYZvKI6G8snecXxmoSC3e3efFhwIIBvb
xxvtC2oU8L6CIR6hwQBP0h21IX97w9mmTXgNICGCx9ks4tkFgJ4OUAA1srwD0doXwtl6x4egERoM
g36lfRANEDi0ERqgOBFm/dbB7NzD3NZwDd3FLN3PHdKO/busphoRoJak/zvBdPYa8/QynjG/KrId
FSIkexEg8/THS6LaQ8KBcLiXcxHCx+N1aRN9H+IfBsAcsEje6P24oFaOjcw5ZLHcEtHci+3WiS3V
YW3YhT3YEY7YDx4Acl11Ct7gjF3hFH7YgT3hHw7hIi7hAnHhUpfhHB7iHQ7iiq3hDO7i073gMW4Q
u/cAmmgRrR0REPDJD7HjH2HjRHjjd6LiKz7iRH7kLZ7iSe7hS87iDj7WDSEbZJEbEGeWQjKXm7Hb
hZLlUhIa3QFUo1sgPD4XoXFvCsLZkAImqJ3mZ54yLccjFALBZMEjnv0iCCgaKWMzJbPbY77m9KLm
KVM4fgmDVo457ztyAf+CMoBCFl7ehqBhgN4Ru32C5E/u5C+u5JVu5JS+4ZjO6YK9JiasMRCnIAlj
EKG+OIU8fQHAvMzxgyvXJHxGcuk93LeWObYmI6ObfcZRONPWhpdhHQ3Q6mrxOXZyGOmh64YcHAey
GkniuT8SuUqCkZDmECjO5Jle5CSe7di+7Zt+6dbu6fGBEwuTEY7rEOY3EuNOJ1oMFNVu6d6u6U0O
79fO7fGu7d0+41WNh/d+3TIe3dR9zNbt7/0u8DDO7zTOHhVTEapWxzOC4FrR7vIO7vZe7/Q+7/tO
8J3+7iNu4juRhsRxFl0YHHmZcBSCFgygGYVT6oZXFlfsHhA/8RYf8zL/L/EwT/MVb/MXX90IwfE6
kYaCohZtjJbaDSYlsnH27R9j3hgvf/Maz/T4/u1N7/QGn/FPH+E8DxnjmSk5D/D/vswBr/MDD/YF
j/FQX/UlbtVbn8xfr/Zd7/Vt38xrz/Zhz/WNjfYUn/ZuP/ZiT/VTX/Z97+5mX/NRj/cEMbfcHPd5
r/d0r/hyz/dkD/h/H/GDf/eUP/OTb/kJUYvajPhw//bPzPmfP/eN7/h77/ePL/mBL/WnL/gGASvR
DPqv7/mxL/qJb/qlD/mrr/q3j/qRz/q9r/sqWfu2v/ikT/zDP/q4v/u+n/uEH/q03/nP7/wwPi9J
uvmy7xBYrfvGn/zI/8/93c/7zF/5OC/+lz/+M5+U4Y/5v9/8s8/4wg/+yq/937/88c/+2A/797/U
AFP+/J/69g8QAQQOJDhQQEGECRUuJHiQ4UOIBR1GpLhwYkWMEjNubMjR40WPFUGGjDiS5EOTJy2q
FMmSYkqXGhU6qOAgJsyYBnOi3MkQ586fOYPe7KlwqMujLJOqXHqyKcmnIaN+LGq0asKpHE2OaNAz
68avGcNiHNvyqsyzOtMKLPtyrdq3bUu+ZUs3gFyIeHnS1euzYAIDVfuu5Gt3sNXCidcexmrYseLF
j+NKjpwYQYEJZxkj3Iy28mTIaTvD/VxaNOXToTWjXs13wQHQsU23lv+duvbV0aQpYjAgYkECAgoS
DJewYEEEA8mVL2f+wfjv4Qo8JJBwwMADsKxxaxfMvWjuCRk+ePdKHqh5oeiRGsYQgYSODSJy50QA
gYEOBiMczL+rfr3q7QDMiYIN6hLwO/+USpCpBaHqyYEFCJCgBLsqZOiBCBvA7rwDy+uQw9tiYmA8
3WibLcAQu/swvRQrGiGDBTKzcEaSRMgANgdXJErH/1oMyQECZOyIRwWJZNBIpxqUKiMMEhCBRiir
iqAAm8hSckkkc/RxIxEkIGxLFsHcUcweT0QQogeoDAABAghAyAACGBDogDgLIgABhOp8iAE3F3qA
AAgGkvHPQBU6oAD/gfgkqQAcCdJzoQkYoGCuLLEks8hLH6oAT78qpcpTra78NFMtEzIggYIQUAAB
BuQUiAADDp3TTQMUCCyAOxFiNAAIgjQU0QAKyJXNQnPFtdFcH4hAoF7nBFZWglp91csAGnCVgK54
VaDRgXbFFTNtNySogRE6JbVU28w8MyQEKnAL1OzgFUvUUOU1C6EuE1KVUwIKyBZaOscVllOCvO2W
2wCgNdhbYwlAFk9vI1g14WeBbQBYgeAkOGNj2UQ4WByNxXVjgvJtzN571fXwLQiUO+C5DQqQGQUF
avZA5gIYuOCHPC7w+eefLRB6aKIDSMHoAIhWegWgm/Z5BpwzqFmB/xxkrmCD51pOjkIQVe46XbBN
FFsgHwqN8my0AyDw5HMt9TrMB3pboIAmFOjXZ6FDAGBvvvv2+2/AAxd8cMILN/xwxBEX2oYLSCgg
BgUKGGKBD25Vse1R3x4zbFzFTfvzGRVgW/MyOYdogliHkLqAGWyAIXHYY5d9dtprt/32wUNo4YIN
PKj6OK4Rw7ze4eM9ce2CCrC7TQkdVWBZgoDsU1UCqhxIYoxzMrjgjxfafq2yRzd93cgeGKGGIzwg
YQUTcHf/ffjjl39++vfmoIUflC9gAcu/HhtF0h0pIZsqWPYS1ieHRaBPwYIAmwSyr4sJBEgPgBZB
FFglBnRFVYUKWP8AxCWBPg1MICAUyK6ANCmKBQBIhfLYm7qVrX4NJIIBmAABlvXBBUrQV+L73+Wc
IoEmeKAINNBb/Yx4RCQmUYlLHBwMepCAGGxAP1ZC2buKR8WFfMBVMrsetgbisBHqyYFrmliwwJjC
gvSKZGNcEwJRqCgzyogBwNrVA54nKA/eMQASQxibMlNDYIlsjgOpEgHeuMDX7OWKWFxIe2qQgwqw
AAdMpGQlLXlJTB6RAzIgAQpuRDD+hJJe84pIk0gGOlRy5AEJ8Jy5AsigEiwABQVYAQgyeUtc5lKX
u7ydCoqAggREQEhhemWS2vaBDKAwlcs0SgXMxsjxkaQEQBDiJHn/eU1sZlOb2wwcB1aQgQqUy23R
9J8P2ZWADZySmRZygA8qoEx09ZAiCOjdCrh5T3zmU5/aVAEDjjCCYQqvmPE0J318oAMSkGidLjFA
A3TQgP6taQMJUCcpyWQAmVlgnxvlaEc9eksQXMADC8DAkBaZMnmuLGO/EQ7/rAc63hxgAzHYHwWG
+ZQJ0OkAAVXkiXrVAw58VKhDJWpRk6iCAmyglQUFYErLSRKXPec5DZCqcayTHJ4SVCvorGh/+FKC
CpDAlkYla1nNelbctcAD3RPgQDNHTmLCNSQYWEAGRJCZzTggAT8IKlr9+lfABrZwMAgnptxKvMMi
Vq7rwSgDgieV/wy8TrCTpWxlKcuBBgAhq3kZJTSdGtfPbo4gdAUURDCwAXtaVrWrZa1fQVAAhXK2
irI9qRUTa7yIUCCsD0hT+1r7W+AGt6h7WEBPF9vW4yI3tKWDSAJa0LcQzIAAqRVuda17XWxyADA8
bGp3vctU8JKvkRnwreFkQIA8FBG762Vve404gyeV6LsqTa4xa0uphVRAsrYLQRE8IAOygsACTDPD
C2pGBATfQMEuYHCDHfxgFzxBwVxAcBYUgIQXzOACFlCBez384b4VIDCivC9tb2tRMznAA32tHw08
MAP13tICctCBFpYAhiAMQMc75nGPffxjIAdZyECOgh7IEIMX2P8gxiBm8mRZ4KoSu7K+WhXv/1Cw
5CWaIA8ZAPD8OMACJNwhCUMmc5nNfGY0/xgKN/BCFcrbZDgbtQjPnO9Tq1xnO9P3AxvA5gpePFbE
maAMd4hCmg19aEQnWshpQIII4vzojqogAydG6XINO2W3RYAB+jTBBjKgUb6BoAxLyLGiTX1qVCua
D1oYAaRdvU0cNAHTirW0cvFMTAV49ANkuMIA0lCHG/Ta1H5IdAkekWpkJzoJZmDxq52dyQsU99bM
nTa1w6vSo+3zBS4gsxiI8AZuo7nUPo6EDHBgAhNAQt2OcEQY6HCIRCRb3oomAqjrh7Rn57tvSKu2
ra+dZ4DjOp//MiCDooPw6xuMu8yUaMEk2h0GNkScDWoIQwQCYYR5ZzzRYtiCvj2OxGjXmsr0FfnI
uwaBInCTAzFQuMZ9TAkZqEHmaKA5GvCABzQIwAaAwLjLfZ7mG1zg40OPXwhQMGvcIj3pJR8nyrep
gJb/fAAPcEDVMXB1rGNdAIUoBLGl/vUyL6EHRCc7f4+udM/22993LqiKm61LHHwB7Do+AAQiUDkE
UN0BV987BugAiEXMXfBCTsIZyn742LHAClH+EqUrrXb7pioD2DzDmAd/ecwb+gvWRHznBycDAzKd
1pA3OWjrPAEPYDmTNIAD2IXghDFIYcevp8IAXq8A2Q+gD7HP/7zgo+AGzwc/cA0IFIkdb1u0p/3f
AilBBt6eyRbcQepCiIMUGkGF169hDrXP/gAYYYjd5773P+fD5IV//r2toAYmPb6Jk//45Yv2IRgg
7y53HfXx51/jYGA2+s8PX+6Kv0sTvdETwAGkCAJ5PkyCADLAP/17wEMDgxcANP/rvBbYgM0yEMYT
qPdDPgJcuo24jA7bJQjQAj6AQBQcsiC4gRdQvQokuxlYPA8kvbf6QBTrQPxyCREoAArMJRUwAy2w
vBTMPCNYAiRgAQV8QbKjgQpYqhzEQeOyQeVjOypkCQoggOfSJhrIgC+4gUIbwlMLgiSAg4d6MyX0
PBBggBooqf/Ig0Ipk0L4q8KAu4kRmK59goELMLA34AI9CLfxgwIwuIE78AIkqIIVcMEzDL4QmKiX
sjY5lD8arMFILMAqc4Ah0K/KAoH6S0ROpB0OECnoccM3NMC1I7lJBMH4Iy0kLCsYKIAk7ERY/BsV
iJn+Mb72i8JTvEE4nEFSLAi6EiIzvCcWmIFYLMa/WQEC2ICICsBHhMRmdERT7MXSc0aSwIADOIIN
yEJdYgAaMMZODIEeQIEhyApbFEUO3MUnREf3U0eUwAAIyAACuIBg9LIM4DxvDD4aYAAUqIHBKEd2
bDxzPMdcnMJofMQPAIIjyIAfGMHZwYEK6MF7fDYQWAEGyAH/J9kQfxzIOJxDaOTIA5TGcYJDBDiA
DEABEiAiv5EBPovIOHOiCsiBGogANkxHjeTFZyxFj8RJ0wNJSeRJipCA+LoL80Ef9bEBe2TJv7qf
C9Af/rlJnaTGgszJNvxHgKRKgfRJSEmAkXgKB6CA30CBqrkAc0NKS+IAC2ABElgdIIAAmMhIrNTF
mlzHuJTLtyRIqZxGikiTRmS/00CdEViADagABZilItgweztDHBiwC0gAwZyl4jCAx9pJp5zKucTF
ycTLj7zMkKzMUcyIU6HJunwIBFAOqjKOBMCZHJiafpEZEvgZG1Aa2DzMv0GabAscE4hNopGBn4Ea
mZGampkl/5mZHOPQGsjsSMmMyrvczNAETc3syeakROQ8zod4GbuUTuuEyuR0zujEzus0Tu70TvDM
zO0Mz6ckT4HYAHjayOyEzvVExed0z/EUz/aEy/ekz/qszu80T7zEgCbEzPKUz+4E0PwUUP1UzvtU
zwH9TwWlzOVkTuQUgATIQPwsUO2czwklUAxdUP9k0AN1UAtF0ATl0Pj0NwjwgQ+1yREV0RP10ADV
UANN0Q190RWlyw5l0RBFF3JpUBqFURltURX10Rjt0RsV0gz90QSlk+FIUiVdUiY9zSZ9UiiN0iUt
ACmtUitNUiq9Ui2FUiotgArI0i0NUzANUzJ1Ui09I/YEUv8iLdIgrVA1ddMhTdM4ldOBMI6FulM8
zVOFsFM4pVA6ZdM1ddE+BdRBNVI/hU+E4FOG6KA5sZUSapOXUiBjEZbqsaA26aqQqCCCYCOI4FQL
EZmK8NSY+B6WUFREfdM/FdRUNVRCXdU2PdU5hdU6lbZFzSEywg4ukhUgsYlJRRRdrVRQPaADGFYS
ApmDkaADuJiJ0VQwGiNsGVadwpVQFNUAiJU56pMKkhloHSQVSlblIRl/cRSIYZRhHSROjSBnDUVc
CZRmkVZhJVY3YVRjTZ6QIZhg3VNaldVW1VdV5VdW7Vf75FFXDdR/NVVDYZ44gSdpSZRQNJaFDQAG
aNhTukL/5nmjRmEA2KBYQMmVA8igNikATmGjBmAeKOOTflEghAChk8VWKDugj7UJjVWjlGUeBeIU
OnnZNuqVNoEeNlLZR3mV7NFYQxIISXUYjEWIox2ZL8LUWSXYV/XXpw3YGbXMGt1RVIXaQDVYPd3a
t8gpjoiVZYwSrQXRQ5XaqzXbWEXbsr3Qf21b/xxbro1buZ0RuLXRtSVbgjiBExjYQnVbp/3bvgVc
vk3VupVbNFWIe10nak2lwyWJwqVagYXOE9CAHSiIDugAHhAILNAADbjcDtjbE/hczf1cAeCBy50C
0VWCDuDcDmCChOiCy22Dy+0Cqz1btvXbwM1d3SXcfM0T/zxhI2eNqAqiE5wRllcJ2QWSFVUp3olZ
mJBpFAO41m053lRJXozxlugVlukFXmzFGOWNHJxp3u7hVAlAlAmCWGpxlP4BI03dldWUGfbNninR
Xn7BEU3toMQtiMftzKqF3MmtXIJYXR7ggc6l3QDYAQ0A3QQWCAQ+gdLt3IHY3CkY4AFug4KYXM+9
XA2YAsidWv6NXKwd3BDmXYZgAOx4AChD4YGgAGHZFQjIFgkyWRNOlA1RYWaBYZUtABQiPhliIWHB
jpHVYR6G2FayYV6B4SEOYgrgYSO24RceiCcOo37ZYToTCBS+jDjxnGJNCBbul0Y5FEmFYV5pYRyJ
Yg/iE/8GYJUNweINGdksHogZfoj9rUrOpOOKsGCBMF0NUAI77t8P9uA+BuHbjVq2neO5PeR52suI
mAAnBB1DZkZBHmTBHWFKVtt9tWTcFWFMfmRE7mRP5ghO9oyAhGRAvko/DuRSJuW0leRCDeWIgJMr
VGSFQABZXhOmRYCNcQBaRogHyAwu2tRbruUH2OWC6OWByLtiJuZZBle2suWEaNyHKF95zQlXli8d
7WDbxVuAZWVN5mZMzmR+rWaGEBZo9SLfbaNjttUzXk11DlaEbRPYaF+M6eIWpl7uTYgg/lY0MiOE
dZV8LqNj7RY6+hhSbZiL9RIJaNkvwtgDACF1dQlx9qr/DTTlSNZmcP5mQrboScborO1dksipRqSg
gNopGmoUry0IB0hoYeoeBzgUCbiVByjfl84YOjuUwGgoiDIADvojk+4e+wgUktZpgsgpfwnFn06Y
rLKPBlDXllEIpYYekhYIa5ERNtnLWEEICmhmj4hotzxlik5lzugsb+bobtbojv5ktE7rUvVos97d
Sh5ruG7rskZRsOZLq1RlgjiVMh2OCtjrMu1rvw5TwA5sLR1swrZSwz5sKU3sKg1bus7mx15luX7r
ySbrua5dyY7su9XsS45rzt7myvZsu+3s0C7tz75o0cbmzB5t0D7tjHbtjU5t1d5s1kZt067t18bt
2IZt/7e2bMrm7cvGbNoWbtIG7t/W7d6W7T+GbOQ+buJu7eZ27tku7uj2betWblRm7ue2beO+bo2O
CvAe2PDG2vHm6PKW5PM26/SG7fXW7fbebg1Eb/Geb/Kmb/mub/w2b/u+b/3Ob/7+b/Xe7wD37wHv
bwMHcPcWcPZW8AQn8AV38AY/8AJH8AincPiWaAufbruu8AeX8A7P8OXG67CG8At/bw235hOP7wlf
8Q9ncQ5vcRh/8bwQgIOg8Rqn8bvAcRvP8RvvcR7/8R0Pch0fch8X8iInciBHciNP8iNvciZ/8iWP
ciWfcieX8iqncijHcivP8ivvci7/8i0Pcy0fcy8X8/8yJ3MwR3MzT/Mzb3M2f/M1j3M1n3M3l/M6
p3M4n3MMd/ESZ/A+J/EU3/MY/3MPl3FCB/HsFnFRHvRAN/EQH3GMdvREh3RE/2pLV/QNP3Q+b3Q/
53RAf/RFN3RPL3RNZ3RQz/RTR/FUV3FTn/RQL3VRX3VBj3VXR3VZl/RLp/RNv/VO5/VPr3VVB/ZZ
h3ViH/VKx/Rgz/VXN/ZdF/ZhZ/ZWV3Zbd3ZcR3ZWp3VpT3Zrf3Zq7/Vu//Vsv/Zi93VSh3Zs3/Zq
1/VoR3dvD3du//Zyh/djV/dzp/dxl/dmd/d0X3Zyn3d+x/d1t3dzv3d9b3eB7/d8Z3dwV/h4B/h6
//f/gl/4g3d4gmd4f5/2iG94i0/4ic/4i9f2jt/4gId4kX94jC/5ig95lSf5lT/5lgd5lo95l5d5
cR94m0f4kZ95nYf5na95nDd5ng96n6f4myf6n095mh96j//u/qjxpn96p496qJ96qa96qr96q896
rN96re96rv96rw97sB97sS97sj97s097tF97rw+OqXl7uI97uZ97uq97u797vM97vd97vu97v/97
wK97N1F7wmd7wy98xJ/6d1/6nBf6xUf5omd8oFd6yBcdtb58zMcIy4f8o4/8l6f8z3/80N/3nhf9
pDf90id9x1f9mt/8zH992C8I1z991kf91Zd42jf4/9HX/dzH/dTv9NmPfeHH/OC/fd83/o8H/d7X
eM43eueXfKRH9eIffur35Om3feX//ePHfu6vfe/nfe1n/t3f/me//o1IE5xpgCq5mPQMgPIFYpnp
iovBmYd2CU0diPtf1NCLknuFo4QAiAMFAhAsaDAAAQYHFzJs6FCBQwEOJ0qc2LCixYUYMxrcyJGg
R44hRX48ODLjSYspKZbs2LLgyogvQc4MEPNizZsMdWrM6XNmSog1GSJQgICgAwIRAhQgQMCAQYEE
jjIdWLVgAwJDJwpk2PXj161iF059GXasWKE7f77kaZJtS7cw4ZaUOxco3Y92aeLt2zYvSb9xAaMk
HP9ALdqiVA0ogFqggAECDghG0Fr2KuYADKwaLMDAwYMCDQgSKEABQdbJqB8EyErwQGkECBhoDfBV
wlMHDaziPg2bc8EDBxw48Pw69oOkEgJQUBpgdevaBglAIC35ee3Sp1Pbtgo7AgIDFGwTaICg+eiD
BQ4EqDzewAS0BhG/FVzXMEv7gf/q3z+4f2EAqoSfTALmxx+C/yV4X0P0iVXUYwVUR9Bj7WkVGWlU
VchUaaKxdtBvEWZHFUJURfAYAUZ11xl7XUEYoVEISLfiQlI59RpnTYlo1YlNqWgQhhA0AIFCBSxV
YkFluTgjjsEBRyF7xREwnHzzFbigXgTiZOCWWPr/x6CXAYY5IJddKngmmGhmWeZaAjq4lWILbSjV
h5dtuGFDlcV30GVIrkcQY0fBVlCgKyY1nkGHFoRnklTh1iRBu8nJXgCFHsTAowhBwFmfSg6U1JFO
iqoepYuWKt+bfI15oJpfrhmXABLFKmusNtU6q6206porr7j6eiuwu/4qbLC9FjusscQqmyyzyDp7
LLTLPitttM1WO6211GqbLbfYenutAKnWFNqHBjWQXgASQEUQA6ztJlpr6DbkAG0JfdhuQfg+QBsD
s7EmZGXlFSRkQbhph5VTEBB8EAVNmadQAAsD2pTAAeybkL8LFYeoAQWUiy+7/6IrFWQRoysxVtU1
/1zaqah2C+6238YM88szU2uTlm2uemWrYvZM5s5mpjn0qz+zSrSrBYlbJdNNO/001FEzLe5eOLPZ
09X1Gc0z0j53DfTWQhf99dFjm52012enjfZhUrv9Ntxxy10l1TljHbTOYd+t995kc6022H6LzXbZ
hP9t+OBrKx64lXM7/jjkkUtdd9YuVX4X3lrzrbngeXfeN+CFLy4644h7Hvrho6fetuStu/467A2u
Tjrts9ueeO2453666aD3zjnqut/Ou+rCG0986YsvPZGMTvdZ0lnQP1ll8wdVH7tDe4rV1GQlUZ45
8L9bDj7mm49vfvmfh1888rv7zv77ycvv/vryL/9fkAMIlHs9QQ9or/9B8leugiBgMs+zyAMEBZwE
MiR/UQFO/rpnkQgG8Cj8I0j1CjgTAGqMRPjT4EH81z8QkqZlDNTYAAu2HiZZ5HvoU9ULrUY+GKrv
fDVMX/DaN7z40c+GOeThDuvXQxyy7X62weBTsHOc0UyAMeOZwJ+OiB2oMOZIDVARvAKQlHXlqwDx
iYxVGAAxCNQGNhMi42S+spn4QFEhmWJKi64jI6jA5ihSWkhRGBAfCihgKVncIogu4xrynPE6sFFN
EmHDxAcciYxJKlXFZMSePE5Ae4SqTRY54sIb0vCHQgwiEeH3yeMBkZSj1KEpfSi+UM4PlKwcYif/
i8gR2JRmSkqkEYec4hSI0bIp7IlihkjjmAkRcEYuUoAunaJAFq2If3HCVLoglkynsKdPF7wlQSRg
lSRKiCwetOVZ/jRNcAInK4/5kS1xSR5skoUBwsFNqFroyliKUpX1fGUq8ZlPerZynzKMYdUCardT
lhKVBi1o/O73laRMsoyceeOoGJou6UDgRw8ggATklSRiloY0xAzOddqjANZ8JZ24pI50MrkodA3S
IEU5UlImdNGMMkSMl0xjSCMwUqZoFJdR1ClV0skYLjJgNNekkLwYk0LZ+VOgl+MnLGWFM6lSdapW
rSpWr6rVrHJ1q17tKli/KtawknWsZi0rWs+q/9a0snWtbm0rXM1qxAhgygEQgMoEKGWAj+ZVNKGi
qwTsui4HaLM6B9CeNh1C1wY8YK8FocBuqNSdBzSAAaFyLKC0KVkkStBi2lQXoSpLgbwuJK8TKOxB
EjsvgYAWR5S1rEEe8Nl1YZYgRDKs9iq7pwhUlpikXYgBWsYc4TIEInE97luTi9zlWs2pM4TqPP/J
Sel60p79PChBs2tdWFJXltgziCPlE72POCAyXIxaeFsy3u++ZJPV1Sd2tztP5wJ0oPJtqn3hi1Dt
6pe/0MWvm9gr4AET2GUAfm537/nf/d43vv1tMIMfLOEFR5jC/k3wdSuMYe4GpcAe/jCIHxJd+v9O
l8SrtDCEL2ziE294xPlF8YRbfOD6MjXENr7xgN3L4hUrWMYa5nGGVfxiH/94yEDmsJENY0Qct2Rj
W2lY9+DT5BsxOWo67vGRXYzgLM+4xEl+KpGFDGYuO5ifS67yR0h0lODG8yDBPcCHjjIBnYLnOYla
qqYqi+anXTnIKf5zjPdC5iKP+ctbNjSND13oGu95LGUpyoQGlVovEiQ+GfyRTS0WUnNJk7iNHkqf
kbzo5w5azIo+daJT7eVRq7pxnxbLo6VzzQNemkTOcc5BdBqhAjTm1WgJtZZRzclSAxrGxg5zsZEd
aESvWtjvNbOvYW1BWbNwN3tCJFKSmG1ohrD/1wNjYbRbAuwuP1vZxpZZzdKN7nXTjN02U3e74/1u
d8N73vKuN77p/a0zh9t6BHRpQxBwAC56EAKhkgDEQrjUB+C53xkx7r31HfGJ27vitjI3xom9bFY3
u9U7Zna5O+xw2E0AstMbudPGXeaMgxzLLXc5x0P+cj9v3NneRTnOc660YHsc5j2n+bE1HvSZi9rm
Pv85v3Wu9BurnNBGB7rQWR7zj0/96B2/uswZvfStv7rppv55VInOc6xT/elFB/vYAdcYA7C97W5/
O9zjLve5073udr873vOu973zve9+/3vcvZ7sqAud8GInd9nRjnirZ93saU98QTaAqMUDXeqO/6f8
2cleecNXffOHXznnLw/6zzsdTRPYNOYfz3jIN17xZQ6960uvec93PvOtn73tE/+ADFgy9b4ffe1V
T3tSk/7ruBd+7lev/OHH3viN/0DCmX/838v+9tY/MXOzr9zta7/73P++98MP/vGLv/zkP7/5ZbWA
0aQf/e5vP/zfL//4p9XyzR988fEffOo7n/X+Xz5LMMAH3F/NEeDQ7R/wER8CVt//Sd/1ASDyRSD/
6R+CGUAFlIDoMSAETmABTt/r5V8HPqADNmDyjeAGJqABmpsDeEDvkaAEoqAHaqAJQh0IHmAG9t8J
ymAJ7uAL6qArGUACwF4M4uAM8iAHnlsN2v/fEFJgCgqhCBohDD7hQojAcjihCx6hEkohFgpaElph
DhIhFPrgFnZh8ZHAkXhhEfYgGKohEw4bGS7gGo4hHLahFkbhFR5UBZAIGoZhHNrhF9Ih9r3hDQLi
H4bgHYqhH6ah7zlABmAAISpiIvLhI0qiIUIiIl5iH2LiJLJhJVpiJq4hAlSAJnYiJdpgEwpiXVBc
vqmixFlcK66iK7KiLMYiLcKiLb4iLs7iLcYKBGyALuZiLQLjLgbjLxYjMR6jtWThIX7iJsrhIJIi
J5riErKSD3xUM0ZiNCpjIUpjHTIjNDrjKc7hN2IjOE4jPRVASuxhNqpjOXajf7EjOcbjKHL/4zJe
4zxqoyf6EAZkQGfdIzz6Iyqao7n9ozfS4zbiYyki5DoG5NiE4kESpD0WpEK240MyZD2OI0CKo0Hm
I0ZqTgSQwEVuZEJCZEdGZLGRpEgupEZOpDxKJEqy5N1IgAi4o0mWpE2mJEUq2EvupEVW5Ery5E8S
hOQJJFA+I062ZE3CpEv2JEceZUYapVImpU2cXj82ZVTe5FU65VI+VVGGI1R2JVEyZUJGQAW0oFWC
JU1iJVoWBv3Nn1rdFQSIQAMsQAIkQAXYJV7epV7iZQKs3wHApVu2pWAGJmEOpmEW5lZ9wEAcJmMi
ZmM+pmNGZlZl5USWgAGsXwLEgA4UgAQM/1zDjUV5icAC+EgCkMACfMBNrKVPfqVYutICLIBqnmVr
5mRTdiUFaFMMbMACnJeACcABMIAOVIAPfID2xOZIziZSlqQAUqZxqiRrBuVzlsQEjEAF6IAZOuKr
TcAHNIAHZAAEYGdYQmd0eiXfTMAFaqVUNidtHidXHh4GiEAGFMAImCXKRcAGEMACVOVTkmd4jmfn
JEVxIud+9id/piVzNgRlecABgCfXldYIJARvqqWAbqV/Bg8QUmiBhuSBiucLwR4GLAB1NOhMfEAG
BFZ6TuiJcqjfUOGAGuiGVqiGFl6SYQAJNIB+imhLfGgCTIZ6Jid6SmjtmaGPvmiGrmaR0v8gmJHA
Btwojg4FBjRAAtAne8KokRLoQeThejrnkU7plk5gCZRMk0ZNKMpFj7ZojLYcIzIohlqpi5bpmoqE
MeYKAhSAmsoHBEyeQ9RWQ8CZV3zmwujpTAzJQtzpREzABogAMgqjosbpoiYqoxqjAGTAozoqpQ6j
pTbqpU5qphLjRD5AAsSZAvTRQZjTa4Qqnh5Q1JiURaxXTQDTSxhqhJpplbZpQEKAD8zqmaooreoq
BL6mSylAc3DRb34FbEARuqCqO7FLLXmQbUAMplAMp8hGiigTkkhJUywHjfwmdiTTUsypU3gMEu2S
q7ILpaBUivTUR8omr+KqkVZjrlKpusL/K5eKIFVaj1FExmScSLbWhmqh6p+QUazSSCZF0WWY1POU
l6dAim0RQHykF4ZUxnQIF8GGCqruI5O6aYrKa7BhaWCkQEF4bLx2aZaOrI/yWL3a61G4h0Mdx2NN
hb+Wim4AK4hYBTARbFBB0lFkGpIQa45gqzqx7CNNSjAN7UGcrKyGLJsuY2Ox3WtKgA5IwGtGbdTu
WoRUQIQEgMdSLdXWwGvOpdRGrQi0HbMSadKyK9I+G48lQKzGCXl0D7HOyOn9CDMdQAMcgATI7ANB
iakMLW0cFpJkhd3SxjKtiE7VrXBARd/SLaX4kkCMKxwRLar2D7iR7a5qbOKERwS85mPk/0CoKsCu
/cAFhK4MWADphgAAnC7qpq7qri7rAgDWBoDremzrzi7tAgAIkK4FyEDoXkARiEjnosBjvOYIAGrl
iuyQouSKjUBPhanr+OrRzmvxLoRlam4BoIAC5MBjgO4KWAAM1K73fi/4hq/4ji/5qkDuhm4C+Ijn
FgAQLMDwTgDGAqnlfmB/LCfzYo9DPq+WLiEGGIDy2qUCeEABzEAPWAAOkC8CJ7ACLzADNzDqcoAF
0MAFbACvAW/7GsDYUu67Gm+FrZgHMOn9Qs6bxO+PSqMBiAAQVIACVAADXAANWIADx7AMzzAN1/D3
moAF9MAPVK8O9OUHfKb+kmwQM6Dahv9w7FzU8aKofpXXAmzAEXjuD9CACtgwFVexFV/xFd/uBdBG
DHDmCDArCWvwNnofA8xkCMmGbOBRBp/Qc+AZBzlNsi5EHHPEHMfNBySAZOYxZFbVB4yAE3vABlxA
C5guFheyIR8yItcwDNhADahwAjSAAeyxHk/yYSrjBOhA7+FJw3BKQgRSbRSFqmpGRz2N4z7uR5Sy
1BAAnoWxxpUABCTAEXgACayACSSyLd8yLudyA1vABfBaAeymWbKyEmsj9KnHk0gKQvwmupzIpUVG
qJzLemWFNslReZwTtpLRuSjA4r4Lrx3JT5UHbSCKrumIcNEGwmkbRo3yY+CGVWDzFQn/l0wK8ZsW
xANAwBCgAAEUAQ0Qsi73sz//M0B/Lwz0QGZWwAJQgDCvawkW86I8iaTZ0p9gSK0BkraOl2egcWJd
jzMJCSb57ANgURyhMcSmlylX0G9uE8UeABoDEwJwdGqZcRJDJwZEQA3kQAWwwAEHtE7vNE/3dOpy
gAyQAApkgEpvcNki6ao8QAVgJ6PIyJGk05RQMwapSGRImkX3lEZnx5FALFP4LL4+rqRFxYyEsox0
DzJ3SpshxFZLxwQEIfTWowBIQBN4wAy0gE/fNV7nNU+bgA1sQG6OQFUmtFFyWTzzWjJ9VDoB0i2x
LVf/rLKiCGtk9WNzJia9i1N8SBTd/y2KTMgVPcZmCNe3isY2kYi1NsVkZ8qFnm0DYoAf5wADrAAI
6LVszzZtB7QK/EAGHIEEIIBgGyCZTQAD4KkRP41S12lMo5oB1DQD0AAH1LZzPzd09zMOXEB3QgAI
ZywHRyQGGMlwO40FAvE8K9gELEAFEEAP8HN0p7d6rzcitwADoAAQYKA8Y7eBNrFxd7d0NsCtzm9B
YQAENAEB2EBsszeBF7iBYzEMkEAO1IAH9bYbjpkDbEAD3Dd+M8R4F0AJOLhBkGWAD/iBfziIhzgN
JzgKnOYwZyWmYssdZ0DAVjgCJMAGRICmpnjEfcAGeMB5i7iO7ziPOzANFEAGwGal0v/4kEOLBlMA
C2cw81JWiA7xjwFhBshAj085lVc5+ZoACSgohYtxbYqdAWxABXwnjk6nXQ7gA5BABQg3l/dQxxQA
DFs5nMe5nM8uCFD3AtSphpstQ9CVB/iAmvuaAPgAASTAfOYpC3+Ierb5m885oze6o9e5B9x5Ca/5
fM/FTJNAD+8mjvnmBugAAwC2spERCWx5TmLABRCAlDu6qq+6o4dAA3jniXOhQl9mAniAApTmaVbN
g1AAZmpmX45WU30oAYyAlRpABjQAerO6si97nMsAAVwAqdM32sZ6Y4lm+nZuXfbl12571GZ7DITq
XUKtAWQ4opXAZrT4pFfEg9IAs7f/u7vPeQgwwI7q+XzFur0zBJIzlo9OwKt377v/O8BbOQf8QAWk
4zDnOb0LzwTAp6Sj5wFkwBQHvMRPPJUTvHxLeyAq9Ft/IWFlgIznzIPaNcWPPMnvOAiQQAKAJwlL
MstTcmT6ccF3nwNUgA2UvM3fvIiHAGe6fPtReqWnO1uQqA9cd4JtSrLjPNIn/XrbQAUQvZNjfMIf
t5rk1ZTQp0dMAAmwgNJvPdeztwmgY3bLb9iLPdk4gA9kwACOT3GIfNe3vds7NwdsgDXur1FHr933
jgDA+FFIRGjU8tv/PeDP9h4sQNSHt2oXvn9FgA54gAEEvuM/Pl4P/sZPPuXT/Sph/0AFHHCdEwAL
NDfkfz7o67KgSv3dIz7U+9kF9ADrmkAeZADbhz7sx34Vh0AFLBXy3jt/Z6IAFIDn064FVMAG5LTs
Dz/xM7B9Gr7lmz7Z51ANrAD5rgBde3jxTz/10y4HZMDFI++Mb3+Rd/+mcguJSj/5gsAPeEDN8zju
7u4LrD/7t7/7v0AVhO72WoDfV7/9VzELMID3S5zPk37pA0QAgQMJBhBQsOCHDQAYNnT4EGJEExsy
WIh4EWNGjRsz4qBx4UWMGES43EjiYkBKlStZtnS5EoqLNDeIaFGwpUoPCxw49vT5E2hQoUOJFjV6
FGlSpRlVZDCIECrCg1GpPq0Kdf/qValasXLd6pVgVrBWx5IdKxYsWq9qBx74sfRhiwwMTMBNqoJF
GQVEbrgI8hJwYMGDWUZ5wiWLGzkyQNh1/BhyZMmTKUsOQYBCWYFstXKu6vmzZrNpRYOmajoq6q6a
VX9FaIVFZRYeLjSuDNGCHB1E9Bgh/Bt4cMIuuHh5YSPEbeXLmTd3/twhBw8OWJeufr1s64Law1rH
ftZ7dqgiZjAHMYPACsotzni54Vt4fPnzX4Ihg6RHcuj7+ff3/5+hEDyYQLzv1goPPAMPVJAr7gZy
cDMEBVJoPxU2KMAipThgAYkloKAPxBBFVOmJLKqoC8AUVVyRxaGaKhBG0hjsTML/BWOU8UYbExxo
ghx48k8GAvLQT6gWtlgCvhGVXJK+EhuwrcUopZwSwAsW2BFLHXHMUssuG6zxyxmvQqsG9VTckLYf
NeLAhy/AYBLOOOm7YoktYKASzzz1nMyDB7b8M8wcA+VyUEAL9ZLG70ogYMoQivBAhosO0CIKOS29
VL4bMkBxz049/dQnGoYwNFFCSzV1TDBPJTVVMUMbaIEe9FShgAJUAMAEIt7ElNdef7uCiz1AHZbY
YmMg8NBkUz2I2aeafdbZaKGdVtpqqb3W2myx3Vbbbrn91ttwn80BSj0tsMMLJH1dl13A0jhDzWLl
nbfFGiAAF19xsx0N0VYFXbXf/1f/9XdHDHIAIIBZ3/grpSBuqCMNhufzI7BHkngkkowzpoDjCChu
F9MkzqAsYYZKphfllB8KoIcrlSU44NNUhTnm1GYWGFWBUwhgZzxB2OLDl4yA44sk4KTggxZkoIGO
ppse4ZBAQPZ1iQMk4xlrlbVWGeudAX5ZZlfDHhhnVsuueTUYd+55ShGWAM6FN4gQQ8QPcAjAkkkg
ccSRMPyGIJAkp8YUCjvihavrk7denNjEv378bLDHznlysytH27UdHUAB4SlfQEm+J+pY4or4IqHA
Eb399psNNsL44JBEBmeXiAztOllxxnXvNAAWJMB8O7FtFj5tyocn+3LJjw8ghv/DV9yC7hCveDiN
3yRBHZIwWmdDje7VsMAGQD6e3VcyIt0d/fR/mkEE4LtDfnnL43f/wZuThxxnCWKL0gyjmYQCDnAI
jCQM4DfvqQENCcSDIz4ACESQr11auJX6KFhBiOQAA/SLEPyKJ78OapBfyvugCDOHgAxESQZkmJok
YJBABeIBhngYRBgEUIhCjA+CvRLDFizYwwrKYAMezBwIIRRC/N2PZiQMHvGGmIAWtMgNlWoXJRyA
AStakQMgMIEKYACDEigCEILLYa/gQAMfnnF3FdBOESHERvvNT4nv4+AQiViQzbEIBDEAGRVL4IAq
PuABJXhAFasYAUDIbozsSkP/edDYSJXZAAjGG+GYBMCsShrkkpW05CYxyUlNdhKUnxRlJknpyVKG
8pSjNOUqUclKVbYSlq+UZSppKQARAGFFFiBCuxCAAT8SEgEIKMEwBymAQBQike1ywQsc2cx5CWgC
s3RlLWNJzUy+cZJJPCIct5nNyH0NNioKgRfaFQUfNACdPpDAAiAQAQoIYJg2CITEktkrPcjBmfkE
lXSoI0k6dvOfAF3iHAfqz4IK8aAD2cD5AISEoJHPDxE1wkRxWM9eccFM+tRonjKAACYmVKByNKhI
EUrSOn7UpAMpU4pWwAWLvpRdUEDCRmk6JQ5kIALYDOg3tdlTnv4UiUDlpk+D/+qWFGWADzBVKqbu
8MSaPlWcBMCAG1G6QYKmNKT1q6pVR6pV5BmgAADiABLEaCkhOEELhlBJI7RAhQGcVQuESEkfxiCF
pTJpCfuD6l77Y4ECcLWkXg0sYE96VcEO1ohEHSqPKjDB/oy1rHESQhzOuoYBNIIKc3BrZTU7ALra
9a4jyitfSbsfBuSUsHE8rGpTm9XWKtabQZXtYmcrEPIAqApP4NVkpXDWNNS1s5V9axxcUNfQhigI
X+BUaZl7GxNkIIOrZW1ia7tTocaWttnF7natW90ATCABtuOPChZ2Kd561rjBdYJlU8II4x53PiJr
7nxvk4DMgNS11NVud/eLX//Y8pe7/r0ugAlSggqUaz8QcCl8GfwSMbwAwfSVMFwg2V+s/rc7+dKw
vjbcYQ5/2MMhBvGIDyKCDTjvOXvgAj0bfFw+EGG5E5ZxUlqwAQOQGMcibpZ+LSzd/FLVsK8dsIBl
RoET/+cDb4hsi+v5hDKgeMZRLtIGkOXdCw/Zxxi+spWzjOUuc1nIYCYLWGMMHRCYYcVMrqcL7BAB
Kb/ZKCxgQJW9HOYe8zjAW74znglM5D0DOUsPKMCd/oODDHBhyWruVRKysAA4P1ooHCBB+xAL6MJ2
1c55/vKfdernEU6AAYz8DwgaoAX/KRpTRqiTUyHd6p405cZB5rOnaV1rPWv/OtN9vrWuN41r6hog
A479jwrMYGpUL0nVSGABlF3d7IfMYM6WvvS0qT1daVu703qeQA0SQCQAmcAKOoBDUo8NnCukIQtl
MKOz2Z2RFRAgK9f+8VZnvWtb95rXub63vu1tbwwkgAQRLvQF3PCFG0ix3AMIQhLgEIMz0IDZ7W53
CwiA2n7je9/15jfGL75xj2v84/LWMscFYuCATwkHLDCDAt7Ql9BC4TBecMMMZBBxiUuc4gcQs8jr
zPOdZ5vkIQe60KvjAG6XWUowsIEcXqAALZDhBk9wQekwJQYX3GAJRIgBEspwgRZ4++Zhv4gNCPCB
edO7jdZU+zTZXs22S9Pt/3GH+9zXLve60/3tdzdAAzyw7mJZwAIXEPwLCK8Awx8e8YlXABIIXwXB
r8ACSBf75DESAgZU4F5517zdN4/3aoIc9D7nNNqHHnpVCaACDAC7yjgQXsq/Pik08EAD6Fzts2Pa
9KTXvaxF72vTTGABtBE4sVaQB9gffyh+LcBUep/v3OO++RmPfsefD/1OO8AKHtDrsEKQgdUjH/wR
sVAGzC790k+f6Lw///p3b33NfCD7F/j+lIpgg/DfPyIyKEAFyj969W8V/dLP/f6PAAdwRyYAAo6A
BAhNSiwgAWwO/8IOBHoABWqgBGxv5AQQA+us+iqN/QrQA6ECAWoABX5A8v+ggwMaKwLBjwYqIAMW
oPawrf0GKwA7cAN/bgZvULs+IAE8wAT5gwVEbQXFjgY2AAUWoJ9sUAZBcAkNMASZsAmfENOMDAWK
QNgo47mGbwgfDQRWoAKaQASS0PxyMArL0Axvzwl10Pc+sAQW4AgyADkiY6G2sNksgARyYAgiIAbX
kAzR8EB0LMcCERAHURALkRAP0RADUQRqIAY2wAZOECiAiA7hrAWAwAMIQATMDhE3MRE5UcSU0A/V
0PlqkBQ/UCsQ4AAyAAWGoOaAAgQqAAcmUcJSrgJyoAYiILqCDhQzcBd7zhSlEBhFcQyh8Ow+AAje
8Aeu8CF+QFZkka+6kAH/ciABRMBPeLEU+zADr5EYrfEXhZH6tNGORmAIUIAAioAGQkAFKgACndGC
YKAHEiAGKoCduvEMuREA6TEU65EDwTEY9bEgEiACIKAGPMADSGAFIJEdVSbwCkABCmABKCAG+dEb
dTEAJdIf/S8NL5IPt5EgRqABROoBRgAImgAFGEAn1jEhWcQjfqACYiABFiDWNHIU8dEeMzIfb7Im
bTIn+/GIHKAAqrHXSuADFqAAcgAFEsDr5i8llQN8iqACFCADakAEDKDKLBIn95EmcZAjtVInsRIb
vZJsfAACNhIDDGABNqAJYqAAfsAGLEApl/InYKAFLoABCEAtJWAEPEom/4exK7mSBrPSLydSAwWz
FwNTIAyAyjDyKgxgKGugJdWSBC5ABhhQFkPAAljgAgqAABSgCRxyKoFyMPfyGwFTMUWTIklzI/uy
NE2TsMALNKzSAQwAAoiSIRWAAApgAwSvBSJPykAA8HrgAoqgVgyvM2vgIcfyKw3zKpVzJxvk7p6z
86CT86bT86pTOq0zOrOTOq+TO6dJnbBzO7XTOg1ANs8JCFzQ8DKgVgpA8HQT8CxAC48ia7LGMSwT
8D5C8GpgPTdTASqgAjZgARoAAiBgqrozPA8UPBPUQBVUPBfUQaepMFdzOSW0OVkzQtPmASogF8FS
NWOrBMjTAEZgAUaUAf/W00RPVPESD2tS9PCOoFYq4ETXE0BHdCrJUy+tskInNDV5Mkc5lEd9lDBx
FEhlkAH6T0dnMjmHx2uwpkeH9Ej58keZ00mnlEql1EoptEqx9DQ+gAG2Uku/dEeDFDWR1EvDlDWF
9ErN9ElHM0lxDQMy4ALLlEw7dE6jFEzrVEzbFE/X9DT1FErzVE7vbQEOAE3v9E8ttFDVtEnTdE/5
9EIbdVENlU0DdVJPsQAIJFEhNUsVdVM1lVEP1VEfdd8yFVQjlVM/tVKFKAFiklRTFVDptFQ7NVZR
tU8pNTRDtVVrFVZdVXk8clYlVVft9FSB9VZN1VOJVVSD9VWF9ViH1Vn/rcsnQbNYZZVXcXVMf/VZ
sbVZt3VUO9FbPfFbwxVcx1VcA3ED7qVcyVVd05Vd19Vd2xVe31Ve4zVcklVZEfVaq9VYQUoAEmAP
p5VWARZZc1Vgs1VfqfVeXYtg7bVgufVgA3Y0XHNfH3Zg8zVhJ/ZiEbZhtbVb/ZRiDTZjIRYcReB3
rNVjQ7ZiT3ZjP9ZhURZkGRZmp28CyBMCQNRmbxZnZTNnd9Zma5ZnedZnfzZng1Zob5ZoixZEjxZp
ddYAIgAzllZpkTZqi3ZqhbZqdxZTLXZlXbZlt9ZrY1ZrF7ZVR1Q0ytZszxZt01Zt15Zt2xZWrkRs
tRZsVXZubdVr49Zj/8nWbfeWb/vWb/8WcLmCbPHWbut2V7mWY1m2Ywt3bF0mcB+XICZAWgdCL72i
ciGXIC53LDSXbR/gX892cOWWcA/3a0eXWReXdA1XK/S2Kg6gIWuFADBjIBiySwtiM/WSdhHidvf2
AP4KIRCAAMACeDFXdzn3FIOXbwtA5woCAu6rbEOXbk13WacXX1VWekWTdaniAJB3IBrAd9ezZAWi
ACSAAHC3VsI3AMa3fKEiAmrF4mqWAkrUeSOgRBugn3rXAbw3fIdXIPK3AOx3IB7Aew/AALiXICCg
VpY3AGTzARgAOXuXAWKSfv9XDAlCAv73AdZXICA41iZA53q3AaqRf/8DwAEu+LQOU4EDoGYFon0L
wOJUuAAiWHkRYoUD4AAQMIYnNyqgl3FF14ej94ftlkER9EGJWDwbwHG114ADAAEUwKNqJQAqTiAY
4CM1GIqlOACoOIo1t4Cr0WnF13ejOIUD4AEUwE+2Vy8z+Mb4V4sFggDGkgFqNwDIFyGqDAKQF403
mHsbQI4Fooyl9Y6RhQKc2Ib3uEub2OII4HfYWI4NwIzTt2QveIEJwIuDt4w7mADGOH2XV5H7V4Ov
IkCNWJSHmJSLuJQbFJVH2ZRXOZVPmYhVl3qpInujYnsLgo7T968cgAD2rnatOJd3mY/dWHO39wCK
uZjFV4Fn2GklIAL/gNejepcgMpmJkVeRjZmAt5hylzgAGiCTmxaPwziGrXksl7mZPxmZo/mJGUCc
p5kgvJedsXkgpDmKH6CA9diaPziMNxkhZhie+7kqeDh1r9dkexiIrTeId3WWoQKNg4l8PxKM/bgh
49l8ITqMzZmECcChY/Ocz/l/BaIBCNl1kdOd35l89RK1uNmjEEAzdXcsffKbB2KQUYsq09ehP1pz
I0ABcgrUCDmmD5NAmtih79hP+Hd7Y22kJ5mSPTmjb0yXa1qeCYKfP9midxhuD/p0FRerETerS3fo
BHpiE5p4rwKQLDcqHECHMxchzFqsuQIBKth4C+Kt2zqbBeKtKRcq/7CYIMYarv8WoK9aq/+aqwua
oIXYqr0RrMMasRN7b0d4LCKAfF9YsQWir2MZYwN7sAO6sAcas8HisCPbsz8btBV7sqv3sv3asje7
tEkbtQU3iUPbtV8btvt2tDXbtGFZtWvbq0U2s2W5tfc6ts32hn8bKjxYuGW7qgW7K0+gA5Z7uU+A
BzRAA3hA95ibsjXWthV2t7+6t9G6uAtCna9iqoWbsYX7u9V2tiv7ugXiBDRgBzKnC6T7VLqgDQaC
B+B7K7BAA6aAvW+7unU7tfn7n7d7IBjATxpYpW+zcsEqdj8SAhrAaZeXmzF6wBGgLgsAAShAM/t4
ewmAwD0aAsi3k/8FzTZ/spBjV4Et2sAzvMTDd8PlOcURXCAa3Gk5nCA2vMO3+cPN2ZnrUooFDSgl
AH0FAsMXfCAafMgtHKY1swDuS8alOcKXnIwZ8jar8cmdlwEoXJsJ4rytW0jXuwNOAMznuwOiOwD0
+8v1WwNOIADWW80DYAfSXACeWwM6YAeYoAvGnAmUYLm7YDuYIL8DAL/bnMuze9DFY14PPV07G5ub
uBrrmaYLYnuRxWmRxdHf+DAVINYkWZedd31jeHY5WZPFWJjh+pHnmHv5OZp1jtEPE4+5V9Nld9Sh
+HcxfXY/spYD4IsLoqM9+ZkNWIrH99MLOQZ1WS/l2WmTcKQ7GZT/PxLRm90Q13sHKoEHKsEgxnza
5/wpxvwPAuAPNGDbBeDNTyDO55xZ3py5tT1aKgG6d4DOoZvanR3e6TXewSW9C90rFH19R5h/dxnS
w7h3gwngR/2dbfivnBngcTeZQV3IK85PolpzRxiaz5kCGF6f9f2lN7jgy/fgNxquDbhEp1gCdLmC
ozgmo3gsI96Nda7iDp5AUJ58DYA6NFieUb6QBT7A692/owLaC8LaA2DMpyAA9DzN13zO2+DO4fy5
O2Ag/HwH+DzoEQLPlx7b7X21cRu5rZ6zBXzULV7IFeAAEMAAfofmayWYIgC1NBjifZebKQDsSxbV
+TmGPeqO2Z6b/zn54bkX5Wd47hGg7geeqP1d7TGj7Tk+cxvSAPieAKosdiG7678erBx6exsA7D1d
hRUAAoIJ8sO4RMG+LnH3ysH48Le3GsO7ILY857tSCU6ACQriBP5gvoMeC6ZACcJdIJQAC7BACZjg
BJRAANoAzAuCCbBgB3a/IJTgD1afIHRfCage6/8bvXMbIRS9u6cfcBkgyLWC5mPb9FOWoE9g+LFg
zLGA+fub+0kX+iVV+qlf/dn2wBkf+/NZ+4/b+Z+f0E+/+c2//tFf69ef//s/sQFiwYIAAgIYPIgw
IcKCChsmZOgwIsSIDSdSfHjRocWMBjdy9JgR5EWRFElK5KjQpP9GlBhZHlRZ0WVHmTNpwkxJk2DO
mwYF5vwJNKjQoUSLGj160CfPhTub2nQqc+lLqC6l1oxKlaVVnU+7Yv0KtmpWlFuX+kTK8cADtGjV
sjXaoACEjG7fClU69mPekHtH9i3596RXsYO1Bl5ZWG9ixWENL454FikBBgzsEmVQwLLmAAUO0CTg
maUDAp3f4n3sFzVg1YIbkz0ckzVi14wJ0+Z7O3Xu1btbc4xslEGDAAQkOCSAIAACAhAIOI+gkIJz
5xQaHpheOYAE0sUNHhAOmoACBaC1cy/gwCBy5cynQ0/ooAB34wG+NygfgXv2+PMb5nevHnnrISTd
dOohsJyAy9H/FwAEmSlEQASjGcDWab3NZluGjl0YG4c4ydahhq+B+KGHLVUlQEEpqpgiQS2u6CKL
MsZII4w2vojjjDfqmGONPe7oo44NDHRUcwZN2NB6y6XHXkQPGJlQdwiVZ1Bp1yFUwIMIIRDXgewx
uVxEDhiw3pUGUXaQBFoGMOaAB2GGJX2lJdRllMkRF9poaz1AAJMIoRlAfhUOB2ShPx7KY6JBLmqo
oo0yiiikjkb6aKWUXjppppJuaqmmnXKKKaie4siViUyReKKIFAE31AMKSHBArPclmVyYBtk6JX1k
QvjeQQRUl9ABa2ZpkKvAquklrri+mR1xyQl7UAEMMuvrndEO/3dtlaFhie2Ud1IZKAHEUZhQc7HG
SixSFqqKm6lToXqqu1exqxu9vNnr24b4YjiivKXuG6K+GbEqlJRvrpmsuLcqjGVnDTDA8EF8MnCA
BJWR2QC63q1prgGjZUzZg0oyvKxB91UM8bNaTkBarAwkd7LFbkbbmbDdzplQlho7eyZoExi03bYS
K0Cur9MSta7A/QJcItOpKl0b1O06HS/V7/pbFrxXWz2v1PUOTORmYo9N9tgPl61Q0kt7fS/b+a4N
d9RxT+02v3N/fXfbedstd9907803ZGGjTXjhhrP03OE9DZS11l0DHjDkTdcdud94W6435m9rHnjm
f3Ne+eeiO/9EsOKmn4464WqDPrnkT7teNeWts/467bHDvrXstY++Oe+9X+575w0t0IABxh+PfPLK
L898884/D3300k9PffXWX4999ssP+a/ut9ueO+6Pgz9+8KEDj77n6f+ufvvCsw//+/Kf7/78s5t/
//r2764//fH7v7/v4Y9/9QOgAfNXQAT+T4EBDB/5uic+CA5QgP1j4AEJuEAMNrB8FdTgBSmYQA9a
cIQiLCEIM3jCDUpwgg5kIQdDmMIPtrCDMSThDGF4QxTmUIWNwxpsbLhDGb5Qh0Pk4Q9NGEQgFlGI
K6RhEpG4RCU2EYdRhOIUV6IinWRxi1rsIhe/6MUwgnGMYizSIxnPaMY0onGNamwjG9/oxjjCcY5y
rCMd72jHPOJxj3rsIx//6MdAAnKQgiwkIQ+Zxysa0XGKZGIPudZIKT7Se0+soRUnGUFMPlCTLozk
JY9oyVBWcpRVFKUnTXlKUqaylKrkpBNZCctVytKVVJwlKFt5y1jSkoi2ZOQuF+nDYAoTkr90ZC57
OUxK6vKYxZQkM5/pS2gmM5PSVCYyiVlNazbzk9Hs5jQ3mU1qehOb49RmOMH5zU5uE5XrxGU5xZnO
V17TnO9EZzxr2c5l1lOdMgkIADs=

--_005_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_
Content-Type: image/gif; name="image002.gif"
Content-Description: image002.gif
Content-Disposition: inline; filename="image002.gif"; size=31550;
	creation-date="Tue, 20 Nov 2012 16:52:07 GMT";
	modification-date="Tue, 20 Nov 2012 16:52:07 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhOgPEAecAAOjo8MDAwP///5DQUCAgIDg4OMjIyICAgAAAALi4uHh4eEBAQFBQUGBgYODg
4NjY2JCQkPDw8HBwcKCgoLCwsEhISDAwMLi4wHh4gKiwuCgoKOjo6DA4OHBweNDQ0BgYGKioqODg
6JiYmNjY6PggIMDI0IiIiFhYWNDY4PgAAFhYYBAQEGhoaMjQ2AgICGhocLjAyLC4wJCYmKCosIiI
kJigqJCQmJiYoICAiGhwcAAA+BAQGNDQ2Njg6FhgYGBoaGiYOAgIEEhoKICIiDA4MIjISPg4OPjI
yGCIMIjASPiAgKCgqFBQWIC4SGBgaJDQOOjosDhQIFiAMGCY2ICwQCgwGDBIGCAgKCAoGGig2HCo
QBgYIEiI4FBYWFBwKBAYCHioQPhQUDgAEFgAOMjo8ECA4FCQ4HCgOHjQUABQOABYsBgYEEBIQEBY
KPhwcCAoICAwEFBYUFB4KGiQOPhgYBAQCBAYEBggCCAgGCAoKCAwGChAGDAwiFCI4FCwUFiQ2AAA
YAAwiBhgeBhgwCBwQCBwkDh4qDiQUEiAeFBwkFgAAFigcFio8GhQAHCQwHCwaHhwEICw4IDIsJCQ
IJDI6Ji4eKBYAKCoYKDosKjAkLDYgMDYqMhgcMiAOMiYmOioYOjIiPigoAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAOgPEAUAI/wAFCBxI
sKDBgwEOKlzIsGDChhAjCnwosaJCihYzDsSoMSPHjhU/gowocmTDkiYXokyJkGVIlxJXwtw4E6LM
mjdn5oS502VPlj9rjgxqkuhQoQyNglTakalGpx6RqpR6cSECqlizat3KlepVnF0FQLU49mVYn2HL
xkzLtqtakm25vrVpdaYBBAYGEoAgoEABAhMINmBAIG/fAgL9DpRAQKEBwwUNPCj4wICDgQcQO4As
IDPBygY3CzDQ+ODjgw8iDJRM2XLHwqMnK9ws27NoiJsv1/yqM+7WuSfPonXrWyvwpMWzHp9KvPlB
3iwjHFBdEAJfgRR0d1YN4cABvtYhQv9gwOD6dszUx/OdLiABhAeDAwt0P5BCgwIHtCcYTEF6aAkM
TOBfe+YJIF0BDcgngHrnGXSAbA6wJ5CE59E3nwT4XWYhgQZBkIAAD2AowYe7CbVcVc79JhxQyWF1
YkspGtciVS8aVKNDda2o44489qgRdMPJNaNUNyJVJE0xKjekkUua2CRYCgGpEGEMHEDAAaOV5lli
BPjlVwMCUWkllvgRBJsAgKGpoECkEeTZXV76NdmWiWH5Zmls4iVAA2DyKVCXcfJ1ZpYGtbkYYmom
WtCgaNqJaJ1oxlnAeo8a8KWVhl054aOdNWZoaAQAWgACWEYkZUpHTvRkbz5GlaSLq/L/FGuQKr5K
Y46t5qrrrmGdWtSsLNrKK47CMlmsk8dCKWSyrD437FnsSRcBhmAeNK1ffPmXgAQISDAdhRSsqdcE
GD67oq9HMSururumKhawqML7K7vBLmuvQeia2ypnlGnnp77D5tuUvOneCzBB7iZM8FILD0xvvA/P
azBLEpiA4sSwRlxwrRjferCNDT8VsqsdEzkyWSebVXJFIDAAl8YMw+zwysjS/KzCMoucM8kc9yzj
zihr/IAG1Knss5JAG/2zzc1+jCTT60JN69JHZyx1vVV7DFEEBfDLM9VgI301xBlFIEIFK5wgwgY6
RgBCAx9YAAHbqjqNcMprJZ332BJn/22y3i+v3IAITYdttd/G3kuBpnZ3JAIBhA+LM98bG6414jVj
rqzmhYtQbeKcRx361EI90HXjYTmwgNeA02VRAgosgIAFLEDAOurCOQBC7C5okKB2wbUePOUxE9+U
pUUfbvnfxusM0wIk4p6rBxYkr/xMFJywAgseSO/9VhtAoMGkdBcu9uhYLw9TBARcNjn6ZMPft+Of
G6RpmQl4WtpdeT1AAAV9KZWbNEOABgDPTHn5lKHKdBjMPGozB2AAomDzKQFMoH1/OsBjLIWlvQwk
fwwxgQSuF0ICWOx7KPxeAArAggNeTH6VO5/6RsIAEIBMeMjBIXOIN4ETpLBxChBg0/8icIITEkQC
9YsgQcZDqJncB4AFwZBsJAg8CNRvK4ziURZfczuYGMACsnnfDDc3RomIcHgwLF4aZwbDE4jrLIxD
UxcZwjj2jfAuBSyIlyakJTxZyUScSgkEWGCRC05KIA4ggARXgydDEWCEBaETnQaimM78RTZniuPi
7mMQBiZAT/zTS6nopKkG4EkvkIHNIxeyOAfhCUEDSaRszCTAQcGGkwvBpQAoAEo/PoqBZ/rUJCHS
wzKKzpikI4gHEsBMESjgmU7wiwVcICkLIOCa2MzmNS2AGB30ZQfaDOcOJBWnCjxTASZgZgLyIkYZ
upOEEHFjTar0p1R67YKqtCcfQ1X/ABfGkZGGScCjlGilUHVKOYHUyAdc+MOGOhQr0AMdMhXigQko
oABB+MACOlCDGADgoyANqUhHStKSmvSkKE2pSlfK0pa69KUoRUEGcOCDUWlABem03gsnGr9C+vCh
AAuiSSJqEPIIBAKl+UsCPdgZNhHgQ3dhgGp4GRhDWekypPkQpgTggL8Y5AHyQSofwaSaVe7JZU3N
UvRciRkEBIZraDXqgk75J0jqxqyDmWvyzHrXvHxSPhNAAFQRUC1TfpWpfnWrQAI72MLuT09NPIBi
4ZpBUTYxlH2pViLXSpAVlC+ZI/GACQrgAgvkYAYhgKlqV8va1rr2tbCNrWxZWwIa/zBgB1dwAgh0
6rrmCcBzr4mTpiSJKAfch5/1/GBpYPMXL3WpL5BMbkESIEECkKqJo0FAnPRk3L88tyNnjM4KeAvU
hkSgQOVFoVgZIk9lGcAJO1iADUYw2/ra9774za9+98vflcLgB+NcGzxBQtT0coV65HVJeFG3RYUw
kIEIPAsDousYzhaEAv1MyTBvltCGbMAEH/BBCfpL4hKb+MQoTrGKVTsCHHxABXO8G1ZMF2MDR0R1
Nb5VAhYwy12VS46oRBMUCQOpANoPrXYEkWIFolMIB3O5Q05qqWyZKUhu6ZNYsupAJ/i5u1aLNB3u
0b8MQoEr/IC+K06zmtfM5ja72f/EM1DkZ4diARvucJf/NPDjIscrmYjAAu6ysaAz4oAKsCB5Xc1B
at/M6EbX9wKhGmkGCFCB+paAAEOobw9ASoALOPrTro2BBiJHPfQGrWxnS5uAV+Q2uMmtfIEGbUZA
YAEGWHjQuLaIAxijgDkP5AEWgAGoh03s2F4AAZ4GAAE4oIKPYoADH61ApT86aR589AUVIIAMrk0A
lHYaAJAGabgBUAJkO5sAmwZAD7Q9UgJggNPJVranX9DtYhe7BRZ4t0oboIBTr9F5jRNjBHroggpo
MNfmcoDn4maCWf7kARUg1aLtTfGKW5zcFeDAiC/OcZeiYAE5wO8N0HpD3/rbbu3/zFgEmHkABZxg
ARpAgAsWsIBzeoiZ3QOfOnf3TAYswLoroPkzQZCAB6ScIBRYgGozUAEN3KDjLW3BTDvQATYQgQgu
0KYLqsD1KmAhnG+4+g+oPoMMQN3bL6B2vTmgbwBwIO0ilTa8RcpuTm9b3iM9drwBgIF69/2jKqgA
tj/KdsJD2+3P1ve3zy7bETDABxNfcQwsUDeTK81pR2fev7/2zhfgwMQ10MACzL7fEpygDlEAwwBW
z/rWu/71sI+97GdP+9q/vghS0MMbbBB5xus3A8APfvB773vZhsAHFUCzvUOwUMvvLeB4C9zmT36+
AFiA2CGgwQe6sPGQoqAAQiiC/+3HT/7ym//86Gf9GaoAAf6G6v3u5vvh5f/RJXBg2cv+6OLBXe9v
338FCPABlIZ4IbV/INV3+Pdu4wZuCAB/32Z/+Dd/cdYBxHdfBgAC95UDBYACxSdSM7AAPDU/mBd9
vTV9l2c13uRN9pYBRCB+s5cEQuACbdAE6VeDtFcJAWACIrBBj+EBPkgDiGCDQvh6c1AA+iUAKSgA
LnUDFsCBHDd5LBUAGUAGkZAFWTAFWGgGfzADNKAG6bZaGFAALdCBLIWEZng5IegjmSdR74SG56MA
bedob6AFQyh7VBAFX+AFSVCHr5cJCVCFWPgHf2AGZsAFXJABEBAINMiHjNh6Vv9QAyc2AgXweWQ4
UhbgUSPlAJroABvQiZ7YiQ4wAWoQCSxlAxogbJXoWi6QYLLGhh+zhpmThmoUNiAwbW+WAVXQiEOo
BXvwBVJwgw7gAQ+giZ7ACQYgjMPoAEugBoswe1SAAHAgB1Sgi+cHBERQXyGQA02YitzIjTCgAc4n
fShHgmgki2ykPrX4ZmyABNTYju64ekiAAFXgglSABVYwje/YeliAiit1Az9HA8rXjfYFBWNABp2g
BgQZCZ+gBgCQkABgCYwACnxABgJZX9/4Ljq0UyOYkTASjiU4UQcQcmw2AkRAh/nIh08gBmgwAI2A
AIcwAJOQBinpB6s3CVGQByv/eZLmFwXtV5E++ZNRZwEuBItktJEeWY5tqHnmKBAbUABL4GYQgAVn
oJNUWZWsVwRtsIFAuZVcWVIjUAF8hpQD5ooHQ5TmM5axmJQssThP2WgxEAeop3pWOZerh3t6gAcA
2ZV6uZcg9ZUq4Guch5ZF+YrkmENHaZgm+HxiUWtOWHwjAHw1QHUncHWUSQQf8AGVeXVsQHU4AHz8
yJegGZopRQMEoACs2IppKZiSU5h3tpSB6YaqaRoq8AE4UIGgBgMWYJuiuZu8CQAxUAFbIAKsaJbH
pJbmQpyoOZiwuZxKmRUKwAQ7kAPdt18jYAHT2ZvYWZEh4I9boAA9lpxnyZxk/wkwyJk+xqmczRmb
4MkQFOAEW0AAOYCJI9UFNpCd9klxKGADDFBwEMBQJZeY4nie4UmerKmR6mmeB9pTApoRxfSfDeEe
TmBNFnACnXmf99kCkVkAOxBfCkAB31meCpqgIiiialigHQmgH7mg67miFFUAgOmgKioRBpAAFnVR
BWBN10RNflEBVNcBnemZsmWGACCksPWYkNmjNeUX1nVN41QAKhBEzPSiYimeqUml6DmeWHqcJgqj
JDqLMRqiVkoQXJNjJ+qa1Nel5/ilIxqmxYmmAGemwgGia5qebMqiYEqnAlExA5qlV1qleMqne+qn
gNqmdYqgZbmlxHKYrammMf9kNS3DqF7qpq/5p4JaqX16qYGKqYRKoBzJpWFaYAgXqigEqpFaqHc6
qHY6p6hqqJSqqe2CqDLGNKR6EJWEGcvVQYGRSJuBJ5qSJrpaQWFCcj+WJtIlEA+wXrCUJ3OCGA8A
WXK0WQOhS4WCSwVAcnEEYSCyXmYSXRdUWZDyR3pBKUoWPSCEJteRJnIlAOWiS4nkNRSEQdjVELP6
ppCappJ6pqaqqpaaqfzaZ7D6NJwzr6LaUEqkEYRBYT4isPjaqv36GXQQCvR6ryeYr41KsaXKqYpq
oJ96a9KDWY5BVwCzYbzisSmhsBPLsJsqECSQAkdAEEqQAkYgAEaQAnQgEEf/kAIkoLI5KwA3SwIJ
MbNKYKw4ewRES7QGsbItKwB0ALNTirKpWrFOy6r6IqdQC6gKq2UO5FRdcj9CRBhKOhnC9Eulwi1K
eq761BeK1BnahSDv6iBiG2SS9SWwQVxFZmTqurZM1WCZ4VxrYlCmwU/flVlKSgCysTheglYQ5rUF
wBiUlLZ7AijECqwKYbKKWa8Ra7H2irmXG7Wnuq/+2qmJGrAcO7CkCzCUG6ASW7mpi7qaO6mr2rmu
qitUe7FWO7ogYVZ38Z2RtWUHMQGZEbhOBTyk4S3ewVwU9k8QgCGagrWbchAJEEFeBV160QDeMSbz
Ab0gS6x/Yrb2Iy6Ggln+/3MZYxZL/8NHUnG6Kbq66du6C/u6+hq7sNuwsvuvlSe6pXu/DCEdb7Qi
6Nu07lu1nvu0tBvAUkvA8fu5GVumluu6Bvy+8nvAApy5nOvAKdvAAAy/FBzBmzu19IuRCeypE3zB
D5zBBYzBIlzBJjzAKSzB/6vCI1yioBurKOq/FuzCKPzCNqzBDLzCG1zDLOzDPczDO7yaMQywcKq6
7HuyLfzD6Ckw+PvEPuLEQ3zDVKzDKzK7TIzDWVzFJazFQTygUiyj3eIds6QYINStQNZAaOsd+ytZ
DlisZ2JKfqEnk1Qmb9KA8JcXgyK5D6C4WvJLDohWcjwq/NImEiABE4AYT/8Fx3lxJ26btXpUKqbE
AFA0E2GsxEA8xVYcpx2MxV/MxRDcxaA8p5cMxabcK5ncvqmMyTfTya5cxPV7xKyLp2Hsu+ZhKBEw
GR5yvehly9N1AIFBQQThALrrAN0RIZzSHdGTyxZ0ANEzSb6rIAaQPJARzQXhu+sEsm3yvNI8zLrb
Ht+hHcyMzdcMzAPBzLtszObsVBIAGeq8VnkxAaZ2VmgsEaU8y0v8yZt8Fp6syaK8z/i8ykgcwhcr
xcb8IanBJkz2nQYAzNpx0CBSNM8LtkdEcqEBAW81S6F4cM0rz+LcY8/LL+VKEM/LWR49GqYBzt8J
IAzR0GvlGSdN0s58zj3/9gAPgtIDIc+xJM89xjoR4DW30RD3vL4EvcUADcsePMOIKctEnc/+HMp3
OtSnPNVeIdABLcSq3MpI3c9Z7cVPTcJQTcqm3LZOZT+F/FiQcUiLHEl4HCpLBsVSvdQL3NWjDMMf
HLpMTcNYzcpeTdeyFtdUHdgwAdgaW9T6/M/zu9WvfNcynNdyrb563ddMBq+F7dR+jdhhfcJHHdkI
rNSLCtmPncQDbdl8Xdc5jNkFUQGV3NRWzdp7Pdqtzdmb7dmVHduhbdhfrdmorduZfdpQ3XK+DdbC
zdvDHdwawUwK0AAVQHMLgKPYJHrM/UwUkACnWdtazdhGPNelPdufLdpX/y3ZsH2pO8bd1g3e323a
LBwBJvBI/gkwG6AApSmlr6rY9I3dsazd4W3ern2WDiCUtt3duH3Zvd0RDNAA8o1rEaAAUtUqXE0S
b3MCo4IANCcBCiAC6/QxDpAAFPBMy/0BAVhzHnLgA37YI57bxn3iM1MANdLg+Y3eJC4RNSTYJ7EA
1f3agZMALEAAFtBwMr4jA6c9DLA2LH7e5K3AoK0Qyb3YtG3kSfyo9uO4tvpYUG63WlGrENFgGiG5
eWpErZsAFVBnPU66HmBKEFDjTB7g273bKA4RTn7fR17eLm7iRh0aH9AQjAOtl+WsdytEzQtmf/FG
ZN1EDMRLh7Ql/IQgE/+0VLvUgF4CJl0FucZ66IzbECqOpwmeYWGe6eYVOww15Psd5wLeEIlEXp4u
22o+55ntAeCo6UKh2iZiOt98RKXBJ6RxGZMeVY9RSYsTGEh1GVbSAAawSZ1UAPmjG92aSWRiZQll
AA0wGYY1cG61VO0cJh8CAQgwGewD7A39JwVAAcyOQbs+V5eBIMS82iDCGKzBS7ZjKcv+SJnS7d9+
GYk0QuE+zAU0o4ScXQwQ7F0C7NYuH13i7c3F71dkLRVgZ0sOwqTd4gxhATlW6re98ES+24RbE8B0
trQUZMnlF9W7SIvyfsSeJ3ocGH6yJeDqxqGCsIPNEhugAe3N6jCPFK7/juYMb6jBrgDRtAUy5xc5
0AE2kAHyaaEvVQIZEJkdsAB/cU0FAOJzU98wpOoxPxMz3xHjjRRaruUfuyPaIbJh4T/z3CNIFesM
EfYgMUj//UIGYAIVEAQa8AM28JlCH/cs9ZhHX1oKAAIiXtyoPsx1rkWsg+UHAfg9Uukm0V6LYmoQ
ZsfFtbxLlkh8sUAFn6yP20mlEliN/Cj5wy9bkkhY8tMd4kuQzFQNsc2Aj62O1MgEQB3sU1WNBLJW
kjyvP9msz0jGClnMa0l15VRZVhrNChn+g0QLEQEuEMDbcgUE8AOkJ/fKT4YoQANrXwH9idfa3eYV
AQHNVSpWNBDZ3ylX/7L9++61lcwAsiFQofI5GKZIfay7cmwffNHHUcRPUFRQ31HwEKGnNTE4UZ//
W+EAfZ8SEwAQCz5gaAHA4EGECRUuZNjQ4UOIESVOpFjR4kWMGTVu5NiRYQ0GOxQ4EFDS5EmUKUsG
UNnSpUoGIF7OpFnT5k2cOQUEWBBB58+SLCAAJVrTAAIDKAk0KJkAqYAHJiUQKFngQNWrSguYLMBA
gAMCFEoe2IqyAFUBTr0KOIA2asmpWEsubfpUAIGsApIKiEBggl60bfcyKFtAQlMCJAsw5UugbFHI
Lh8UIPnSwYsPODxu5tzZ82fQoUWPJt0ZRgUNMlGyjJwyQoMTG04yaP8gu/Vt3DQjKGDgM/dP1iYj
MMj72/hx5MmVJ6dQwINJlg4WVEBR2vp17Nm1b+fe3bMNAiJq7q5QuWZwlRFMEJBgfjnuDQoIKLD9
vij6mh4qVHhu3/9/AAMUToHUUgLBghK8U3BBBhu6AIEL9juIgAww4MAgDAi4wCAVCDCIABkMGsLD
DBBYAoAeOMBAIQ0BeFAFDj10EUKDSgwRABkQyIDFFT/koAcAhkAgwRJPTLHHBpPMCAMLCjJIgQrq
ywm/4xJIQIEGKlhgSwsQ8NJLDbbcUgEFKEjAtykFhIzK3DxgYYUTVFNzTjp/80CBDxj4awILGEjA
JQoqCEFJQgs19FD/RBP1jAYNEtRohgrQbIlN5Cg9ztI6X8L0t01dcgAEBRZwQYMTTPgzU1RV8mAC
CRZAwAKh9sKp05JM+IGhEHBYoQsnFfX1V46WIGBYAk4EoIIXOGhRBgKUrcAgHpRV9oWFXiCWgw0v
IACBYRN6cMODSqAxQ2YRqsDCHjngQIVnJ8ygRWC1u0GDGLJrQQMpab1N39b4TXWn//xdM2CC/bO0
gho8Q6GDD3KozlAYOtAAgSq80GIAjDPWeGOOO/b4Y5AzTgKJKNZYIQ4bRoh3ZZYbzECDGRLVQDyD
C/73PJvfE/i+nJfD74EPkmyhi8wGvQiFCqoAImSmm3b6aaij1jgJ/yE+uKE7Hi7gQaGsFboA3A+z
dTRshC4YGwAbNLDABgDgTSjrs6EduwSwAcjAhxUKqLdli2LQ4Gq+EbJBBZ17vtmlnYlKHKjFgTM8
OfRcMJplFto4Y487pJB6c84799xzLaro1bMSkn1hR7uHOCgD1e1WQYUMWMewhyE4eGFrAG74YO8e
LFThRgB4SFZ1DIBMSAZkeRhix94TWkIFFXHP4PXYW18IhwJUvoiCGVrwnhLwI4nEEQgMoWSzEjSg
IfCKcijOuMZ1il/N+Wd9vNL7LxXOBQAEUDSEFSThc0jAAhyW9jmpVQIELSADGSKRBQhmYQqOEIEh
EIFADHKsDZr5jP//DOJBh8DAAntjX0IIELeEGGAKZmBhH7jAhTLEcAoBKEQhjmYBJJVQIwLAgAKU
U7+bABFAQsRZzYxoHyLSBD8qYNuhVtCEDEKtCFL4ghUuxjlNeGAKWzRDH2JYhkGoYYaGKEQRonjG
jUWhiaJBQQHWp0ONQEAEIKBAAAzwAAc4YAMb0OMDEjEI4zFkBAvIweTg6JkPvAVy+TvcSZI4k0dq
ipGcut8LOKikN1wRjZvsWBKSMAcWwOYEDWgACyRwgCGYkWlw+NKXrMDJkFkhYRoJAcPeeMjPQEER
gSDDQXSpBgDoEhC9BAAo+EBMXJImBB9wzw8n2UiAHbFw0vTZMwX/4IRbMqgAc4AlLJ8ghjnkAQ0D
+KYX0vBNP4jBDwOggjgReAYruMAKUoAiBvVAQoPAAAeuqgAOUJhMgAa0IiEggCIjiThrHu6gk0po
vxoamcRtoAAwSBIMsECFbmZUo58TAgME+lGQbuYENGMoNZ0JTUmadJEqxR9LgXKgf3rHb1HA6EZt
msEieMEOEjBkSH3604lASUo2WahKipqSo+rPpfB76MCW+psGECBmvmoBDSqwAiy0AQn1vOnTzuCF
eGogB1MFalnNSpERnMA5lHxqbpLK1Lbi5q3QaSrP2moA1MwymSFYAOrO+lfAKuwEWyDpXFdSV8Wh
NKVIRCzjGuu4/7jOigk76MDDkpSDHAZWs5ttyAwWsAUIDJWoj5UfaelnWvtF1qGqhSgjJ8AEFyyA
BqPDiGc5e9ufhuAGJwhCASDgAMNGk7GsdapijYraICJ3tMS163CP44ACROVTDNBAEPpJUdxm1zsj
qMEPqlsBEyQxuONVbhGNi9TyKjG9kFzvYqfZmgqIBaE6o0ADnFCAICCgKx24gV+126AWVCgHBfgA
AsKkAAgkoJnNfW+Dq8ncxJ4XvRB2LIUh61wHn1QnB/BhajH84OHqwCQiVuqHNZzhlZo4xSg+L3kt
XNoXpynGHn5JAiJVXBaXOMdwVXFLe6xjEO+YrRJ2ZHvn+2MeC//ZrYbbgAUUKVcjlxTJQ1YylGec
3Csvd8rQdPGWrTyTBTSATGMmc5nNfGY0p1nNa2Zzm938ZjjHWc5zpnOd0UyAUzE4yHs+MZ9X7Gcf
V3lfRF5NlI8b1wXk2SUFKIABHD0VxtwFAZEuyQSGZZJtUVoAlkbLb6yiErLcJNRqMkCncTJq4xBA
VrhJdGuzbF5Br9bLg361ems9a1nH2tVgVnRLzsLos1AaL3X5C2AwnRWnFLvUrnHMAQ7AgL2oGtNJ
YfQBGsAAtDCaOA1AgHxHfQAEnFICa5FAuMlCGJSApQHPRrcAPo2YdY+62tc2dUkoMGlrYxvezi5L
W6wylcOwpSz/E8B3VGWVAAKspTFWeXZSwPJvbK96LklZdkkqTpNW4xjQQO5zx//s8UBvPMmE7rKu
Nd6SjBNa5Sv/V8ojjOtdt4QEKTjCSZRAgjCUJBQzJ4ERSECCkvy8JEf4OUvCQAI6CF0ASU8BzlUy
85ofoem2hvnJP371kBO55CKnsktcjpKKozrUD0DAk90d6a442gAS2MrFUf1pwTja0nPJs7SPsmoD
TEAwxkbJ2wN+F1nlfe9iL8zf4a5quaPFL6B+zF2uwna5nOQoiiy1Yv5OdkeHRe3SXgzYIRBVi9ul
KyfpfOUx3usLm1zPRaFDCnIuZdW/PPYVrvrqJbx1kHNcJV9n/3nvIQOBd+ekAUNRLO9hXHvZc33J
t3av8r88ezrhHuu6T4nxIWNpBigcpcP2/bRzcnec0Jv4xrE+jZ1Pa+TTHvrHX7+M0x99Q0/Yy+XX
iaWbmX2wB0bhz04JthM+bpgglqGYDGIJOOI4CU4zAOgalnG7irDbP+2Di2EpgLkTgAM0iagaFnKb
wApEianQwJOQtpT4QLq4uAzEwHoriQZovLl4n8igPy1rP/PLvZGjwa6zweV7vzmRvqybvpNYAFOx
EiEcQiIsQiM8QiRMQiVcQiZsQid8QiiMQimcQio0QgtAPfY7v1zTwpjjQqvrQTCkPuPiQTGsQR+8
wTPMQRnEMv8ddL81jEEvtL0wNMM5RMPuu0M8zEM93EM+7EM//ENADERBHERCLERDPERETERFXERG
bERHfMSaQABInMTDkURKvERMzERN1ERLbI1SI5YCkC9sc8GIs0AQ9L9h0bTbQLWTYMWZuDhUEcHZ
SEGTcMWUSLjl6MRN3EVe7EVf3ENdhAzwEwAIKDt3iy5jFDjAq4rCKIsIGD2lCLhrm4sC8IlijIoH
KDYICAy6EICpIIlRwz9i5EaHO4uUMBMV7De6iACnEItnvIpsLIltvMWsGJaoQDhqtEZjHLUVrIyo
ALe/eMYIdLer2EZJwY1g/EWFXEiGbEg6SUiiGEbSG7hhqQz/EWQ0ZqwxWfS+iSPISnuKtqgMgvvH
siCA8eOKSAM9pdgLlUS1uDCLrCA4iRMAUiqMaezIjhw17qvFx7DF4Iu824BIhxxKoixKo9QJoTxK
pUxKpWxKp3xKhWRKqGxIqZxKq7xKrDzEqmwJWGyNjbQJW6yJsIyMruQ74zIALMyJbTG7mdjKrHxL
uIxL39vKveiLvwg7BCg2+ysJ2rC4krDLTRPBYkwKcXyAxDALxuiLwkMMcESAU3EKkqyKlNyKeZyL
v1jBv1w8zFTBFDwKxgCLoSjMwzyJzRzHxnxMY9xMwATIv6wMChhN7gNNlNSLSWuJChTHSJRL3dxN
3ly5qhw1/6dwwMB4jG2UOOBEgIIUQW7bC7BggL8LQcYotZKMtMoAt1MJSWU8OwxUuMV4jHb7Cr58
DHMEO+SsC/lqzufEwGqUx8BwzLE4zO+sTvEMOHCLtoCTTb74tLKci+cku7RECbfsTQEdUAJNjgD1
jwioLxYkirGcCb0bzeNI0NIUtQW9wwMtUAzNUA29iQvdUELsUA8NURHFUBDtwwNgy5t4gKyIAAlA
Ucm4tEss0RGdURqFSxndQ7vrtkpLQdy0OLQYxs3Ex/5jjM6bxButUSRN0qWERLvrtLJsi1MRi4tb
PEzzrZSATASE0EY8UiXtUi+NSqx8ALZTxV/k0i89UzSN0f80LUQzXVM3fVM4JYoCCK44rVM7vdO4
NID1xFM+7VM/TVIFcME/HVRCLVS5jAANcFFDXVRGbdShBIGBdFRJnVRKzcSYqFTfC4BQGZUGCC/c
MAARYIECQIAFkAA5wVRUfVOwOMhURZUIEIEC0IDQQqlXjdVZbVVc9VATSM9cDRAPKAAWWLDuiw8L
oNNePdZFtICZRNbk+NWTNMQDMVZmndY9NAALoFbl2IAFkC9KtFZF3U0rmYAxYwEx2RYvIQAxSVcx
KbMTUNd0HVUvia0tYYAxC0JhxVZIlAATwFfj0NZlzcQHWIBv1cQEOIATIIDYYgEFSID+UMQNSAAI
CBWEXQD/BQCBe+VXIuuLi8VYnYDUotRXRnwACDiBFbCAMpFLDzABBnCBAlAAaeXYlJiAE4BZT9xT
k3A0lXiAwDO7B2BV/qMJBuBWlWgAXmWLSPW+BKCMiKTF+OrDAGiAD1iA30JTEGiAFWAAEWBVmoUv
od3an9jVlsCLvqy0RvtRpGgL3/jJsSgM9lDbZSy1FRzVgPs0/7PScGQPbDuVJg1PRivPY5wK8XSM
hKPFSptZQvOAqFKAgcXTWrWAU/XamngADdBayLUJj3UJ7sOLw6w4iTQMt2XFpB3IvfXRyMPItQWM
ytjM0dVOTCu2EBy/ynQJkL0ZD9iS/2xVB5gK163csegw/979iaaNSw/QgDnZgAZYgH+l2fjQgJdN
0wiwgIb9XZ1Q1t3cgBXwDxEoVumtiQ2gDcpF1QRYgO0likDNDWjUia8ES2c7gPGLAPYFtaEoWGdL
i/U9gNsFCplFDulIS7A4FbBgj9Y1y9Y4CzxrxbOItqji1gYlT1nZyZtI359oC7XMCwhWy+SFj21t
1QYgqfH9CerFjXdzjFMaT+FoC+LwCREmi07rCgooN9TbyRJEip0kjm/jRpPYS/i43ty41JowScPk
S6YoYLOsOMcAtmEjvJTAyLkTUhHkPsgLywlgtG2hOLtwPJNIAMLYlqswjFts4KQoYil+PATwE1Dr
NCFuQf965Mhl/DUpZkEu9j63E8963Is4tonJ2Fg/dQALwOOUIDEB8OPt/eDbCGEvTmOcXMYeVQkH
Dj2HW4p+U8f3zFYdjgxBvombXFtFegCF02STAL5mk8dI+7yUICWpyDMGeAsGOMnhUEVNTjgDOOUd
LQs9LSiadIz6Ir5W7kZY5su38OR3879d9sBubI5PVolZjopg3uWkTUWVIOZThmVOBmUMJL5djmZi
JNOX0NgMRUtxVQBG2wEE6C1G6wBy7oAZiJ0M0B7Q+GP/YefQGAF0voFy9gFgy68dYDQyEYEEaF6i
LF/ezN+isNYOBpDZ9UUHgFhvnhjHwKwMoK3/UpIMkGf/wnCB3lKBMuFnQqxkuLReyNjggQ4QB/iA
Q4RYJ+gSUsGBDOiph37oEpBn/NoCiqUAPobE4J0TCK5gRb5gOhleyCATyVhWnU23O7rZHzUPWHQA
BRRqAT4JnV2wnr1ZiUPqgZXg00XqlAhql8BZyYvqpIbqrP7XruZKidPqlAhriUwJq76Js6YJge69
ADgAUdGAH6gBdV5puy4NfaqAINAACZiAmf7DQAGK1/yLbQTHpTCA12SMBvgLhCM+x4CAvMvcRj6M
wf6Kw07aKjYJMr5GwAjFP5kKBdvMxU4LkySKgiYKWiZPYhkWasuLd2sLwRXOk4A8Il7tYZPF/Yyq
vk0K/7HjltV+z9h2CarOTmU8CtuWuNcEYLbwbWLhzKC1Nwb0vp/EyIsrS7Wd7rZzUrOl4+HkSTRG
Y86t4gK20pbQaDrZgNfqLX+6a/bmmxCoAR/YAQ1QAJ32PbBVS15F4osz3RkuyaSY0HQ0iXszzscY
tosDi67d7wqlCYCODAhggZZQ0AOojATr5FOZAOd0gAp3XxYlb77ICzE1jDxLgGujAPdVCQhIZbbw
CYhFiRRX8UrL8AqnwGb+tBZvivGT8AV78ZPk8ZIIcQk4FR8fCzRJ8dH+y7w4cRSnDdc1ctdV8g83
CU1mCiW/8bSAXcNwAPuN8h8fW29ccHurAARNbwa4gf+6bm80N6uI0YAtUIDoVTk9/d6GrOnbuNyP
xl5sJgoKmKwccOg0//P2voHPmvDzsnOHPG3jOIHdvfPnIgA51xQ+93NAn3RKb4gbKIArgIBHBxB/
/cWAXVzcCN/zKlhNnzgVPUkV3fLSdUFV0/KpNQktJ/SrjgBXb4oD2N1Uz7On1guoeF8flQBZ0buT
rMuo0LtegwBVLwkNn/AFRpX7ponLoKwzr3Rqr3aMqIECcFw6CdhQ6dpH9NY6aTJQB5BlVjhZlDZL
M4yXfDe3lUV89DdgG8jgE8GKS3cJWPc55sgZTri2kG3iDrWjADZG01lTa/Y5oXOU2ADMwAGVtnaH
f3j/jzgNDfD224AA6HUJZ1XEaEWpgMXom711o5a8K57avdj1XRd5Fe01kYUAFD15vBt5kih533j5
GyY+Df+TXSd24VAkB9C7VdPwgBz395Aob1d4qYJ4pE966xiBH7gCiod2iiWKXw1WPiRWjweOmWH0
k/jV9/EACygkpQ97sdcOvxHUTdNe5KhVWRWtVFH7WwVECNCAA9h0ak0AvpaSDVCBE5j2seebB6mA
CzkIHiAA6PGWmPKaw/ca3JmRunGRxkcIAkCSFjEbxO97hBiBAliBpxcQTY3rTiUiUBVVUjXVTBSB
pXjzVt2AtmiPlNiAClAAyw+obwEA26F94gl8t2mb/xV5l+AhgK1RltVuF8jPFhlxERmZfdrPIXXh
kQkBmxYBfmIRfqSfAZhhiBLQ9ml92g9ggavPSi1H16x9CQqwAL6P/UPqnUACHtmBFgs5nYQYAmMx
iN5ZF+BBiOJBESRpHoMogQqAEREBiAoqZAAoaNCgigo9AGBYWLBhwR4YOAw8aPEixowaN3Ls6PEj
yIIhfDAYEbKgjQURBLBs6fIlzJgyZ9KsafMmzpw6d/LsOXODCAYrGoDwafQo0qRKdXpQoEGDAg80
E1SwUJQlhQohTnLt6vUr2LBix5Ita/Ys2rRqwcbQcMPsjAorl9Kta/cu3rwuN4BgoYFAgwkO9BIu
7P8zgYICKxhAkKo0QoEYBVHk+NABxdrMmjdz7uwZAIELFy8gkHHhggwOBEo8RECAh0UCCDAU5ODa
Ig/Zoj/zJptjAebNFa4aLm78OHK8ASYoYGABgYYFCkQkmJu8sAEKCk4sQPBBuokEG5BH0MDaY43o
GXqzb+8+bYkhBGpXMFihfsEXHA7yyBA69gsHEbAeaLsdRJqBBRFAGwbzTVSQCioAwAFtE+4nkIIE
/fcehxmVoAEN750gwnUlmngiioU9kACLLYKgAIwxyjgjBC22GECKdHVQYVgtdLECDlt1yNUIGXRQ
AR4IVNGGEEBoMQCUUUo5JZVVWpkEEFIIYYUdCBD/kYMNMAzZFQcUJjTfhDz2QACFGFQgmgoLvlDB
hgaVQEAFGLxAAEEKJlgQaWWqRsASBjVo3361VVimQQRI6OeYHGJQQAuRFjQCAYPluCmnnXr6aacV
1KBZCDh80EWl7sVwwgpVeEGFlbHKOiuttcqKRBR1EEGDSZb6+iuwXLVgAY/BGqSBAaAquyyzzTpr
kwk/vJdBBRrYcFYGRFQBhK3devstuLYmIcQaEvRqbEd1CvinRi2sUMEHp9qQKkcwGFnBCu/SEBy6
a9lgXr8aofCBdc8afDDCCRdWAIG+jtDBBz/wu1EMeAiRRLgZa7wxx1ICsQYLQnLWIGwXDMhQaQD0
/8ABfhjAtmaAoHEgWm6P/pcBAoWuuUIONaQMgAoIsFuhyeuRptBC9xUk30MvE8BAtaMGfBIKC+Qg
8tQcFZCAwl17/TXYNTkRYtYFpcewDERg3DHbbbsNLhIFnJsWRRc9+NB+JjeaqKMGsaxgAj4QsMVF
exo0hNAW3Z0bbXo3OoRFjst8UQkFXBuWBxNAEIABnXtugA2GoJWeZGVztYOmYau+OuvLOrADAAKY
fkAbVFJhxRdeFPE277NqEoAJvYNLxRtzqyV7QchTbQHZWcMg90kJxEAGGZRkcX0WU0xRAw5TjDUC
A11gbTpXAtDgROvpq7/+dToI4P7UcUjxbRFSfP9hxZPCd1vJBBmUQAkAARiJLMhgCIV4hP4yVgQs
nCct73vgR0LAgA6QDyMhABhHDBCJSGhvCmb4IBe4EAkQCMIRX/HPDCpIlge6j30ufCEMlbKDiQEr
BGtowtu0sIcvzC+BUaoEBQCIvQ6aYQogSEQhdudDjbUBB++hwQKMp0LKoQkjDhig9szQhzKUYRCD
KIMBcKAGenlkJBWQ4hTF4gMIxLCNbnxjTTxQRWDZIApLjNK4XNAGHLJNEzH4wwe1GEIuliEDJETE
HTlGhTV85gYWIGMaOfIBSALAAR7wwAM24AlOUMAAD/CAAxwQgEL0wSMxsMBbIqmWGzABjq58JRz/
IxCE8Y0JBXVI5KyQAAc4zMFbmQilAzYgzGEO8wFi5CMuNSaHE6xlBF0oiSrL8oAWJOAGOJBAA1ig
TQkooAZojOZnOqAAWJKznC+M1q9CgIBkfosKbfjCxagEgQlQgHMPAOYGQrmBURaCVl5AAEADCk8w
sHMAQshBWWCwgAU0EJwOfehGBlYwc1K0omFDp6VmUIWCcpRWSQgoAlxghbUlEwhE8EoI/tUFGkLU
LFAYwyUCQQYAvPQAaqDpGCQxhkgAABR8mGlL1yJRixK1qGBzgAZY+h42IKGjG3uCGPKAhihBNQ1Q
RcBUB0AFqYarCF74QhQIqj8siGkjLaABvjCg/9SgruWlM7UEAhgBgE/c9KU8nasKfspWtMDIqH79
a9cMYAFaugcCdnQquKCKBkhYVQx+mERj/TCARhxiq1nNoRB2iAA4MAkJQBBrlcAAhDlk1gUhLYAP
OpCBte61ta69iA1UANjZ0hZhEbBAWYdUgiqQFLG+XaIUmPna4RKXIwyYQG2Tq1yDbaAAue3QCIjQ
w99Sl2NNqAIEiqvd7RpkRMv9LngN5gQF+EoBH2hqddNrpSZYgQgN5S58W1sCCyQrvPa9r7M2UAHy
/soGawiregvqVTs0gLXxPbBD50sc/DK4wc4SgQZKFywY/GANaxACaAPcrSIgwQoIYIMNvongEf87
NAQ/WEDqHKziFRsMBARoXtmK1AE2JEkPVRCCHICAzLedgbRRqEIdvPSDMJG4yNptwQJUkGIWM7nJ
tjVvKuVrAREbucojLsFC6+vkLXNZdQaIWjQxgFArk3nEKPjBB0ww0S6zuc2tc4ACdnCC96YzMmW+
M3FDQAM8cc3Nfv7zK0WwgA+o9T0xKABh8azoKc6AATtQwAMALelJ+9UAEtiB5agMlh84cdGeLlsG
ThCECohgzZQ+NaqV64EDWEDON0g0RkagAUp+utbtgUEHNLAFJ1Ag1b7+tZ8dMAEnXGEHDPBBAWyt
bFLNIAcWcMECDoAjYFO72qdmwIJjsgHtPLv/AGB67rIXLWMGEGAHTICAlq2t7nWj+gEWGI9eMpeY
IHzA2zjIAK3Dja4M1KADDCgAdJhwgOqwu+AGZ7cJJICwDSRABAqQQAEKYNp6F6ADHbhBBsBt6yJl
AAMdOEHEAXqFAuxXAQlI98FTrvKVtyQCFehzeBluoxfNqOYRv/nNH4jzm4+35jKqkY1QzvKhE73o
djFAAUxt9KUzvelO54kCDvD0qVO96lZvrmOsrvWtc93gWek62MMu9lOfALljPzva067iBxRgyWp/
O9wnvQCYxx1Uc6873vNemLuzrwFshAkEGpCTwJvoAQzoCeHxwoBIv+QAjPcJ3/Uu+cknJfIz/4n4
S/7NEgIcoABSZ0kCCBD6lnDe8y0J/ehhMgECFOBppIcAAWQjeAFQIPax77UACiABcse+vp1vCe8J
YPbcx74ADSgATCTAetZrigEQJ0CylN96hdPe9gTA/UsaYHvlt0T6BKD+AZxve7P/niXBP7wANM+S
B2RKAKtvPfrdv33ow4T+BiAA7GM//JpYnvL+//9N9F9MYF7Lcd7mSZ0DXJ/oCcD9kR4CKiDXNOBL
6F5M0N/mJcv3gR4BsITpsYQBIECk/d79TdT9pc7xvcQDIADuQRwHfp4AXF/9UV/quYTwtcTqbR72
tUT5bR4biWD7eWD7JaADOB8HUp9LGF9LJP+g0NnfBgIhTgggAEahFLIEFBbdDvLEDW5KFU4hF07e
FnahXnyhcpFAChiBGYaBADxAGITCcZChG7gBGZKA24EhHdLEFiZA27GOBD5L+LmSGCYXGaaAIBqB
AChBGRbiIQpAKKQACbAECTSiABwBI7KEEaQAGjoiCUSaAzwiTMThI1piHYZiANLdS0hg5/0bwOEe
27Ge6Rkf6yWL9j3fYNzf8QEcBERc7GnK6jUAueHe9+Ei8t0iAhTA4bGf+KHfHuogMbYe/gHj+j2N
8qHfKYYc7hkfLv7gLvbi5klf4+EcYMhf6iygS9zfzVmgNYac2d0fA8QiB2pfARgA7DVAAyD/gNQJ
IzGyhDu23uzR4j3OxB/WFhkegUsYIiEKgCfGIUuEgSB+IiRWohK0RCgcpEC+RCAKYiKKIkbGxBaa
IvKxhAiC4AS6IBKWYhMKwA6a3gGUJA1qmf0hQH2NpBIyoEp6ZEfmngvSH0zS3w6WXwfapEnO5AXG
xBXWYPpBwO7BxAc+ngRSoAY6QAnCRE8SZRZ+4EvGX+4pXDL6IylumRE8IgmEweNlpFgixz+yW+jN
IU30pN1t5Vi2pdaVpVvuBFzGJV2u3FwOnguqHgGEpbKsHl96SkoWwF++hF8axQH8HV7cZV0uJrsp
Zk0kYKThX0yY4tMcgATQI0ysYwIcAALs/x9WAIZlSt3qHcAE9OMyOl5KMsABrMT3GYD2zWITpqZl
YmbjHdcucuC/OR77NQAFaJ9H2uY3oiBopqTgRUBKSkBeCkACquYBCF4DJsBlIucLIqZkEuYGpuBg
Vh5bMiZ32uV2+sQJ6iBQcqQykiTw1eT6IQDdYSdU5qUBmmRNGiB50mT99RnsteDr1SdL3OdLZCDp
1ZcF0qAROiEDuqQNFkBpVuCAMoBVLoVjdieEotqDcl0CfmdxTGiEZuifYWiEcqiGfiiIhqiIjiiJ
lqiJniiKpqiKriiLtihtTdtOwKhOyGhO0ChO2OhN4KhN6GhN8ChN+OhMAKlMCGlMEClMGP/pSyCp
SyhpSzApSzipAECplPbElPJElcYolWaplWoplm6pl3YpmM4ol4rpl5JpmNaoUlypma4pmpZpm57p
jY7pm7JpnLppncJpjsrpndJpntppn+Lpjurpn/JpoPppoQJqjwrqoRJqohpqoyLqj6apoj4qo0aq
o1oqpAbppGJqpWrqpXpqpg7ppoJqp4rqp5pqqBbpqKJqqarqqbpqqh7pqsJqq8rqq9pqrCappN6q
rvLqks4qrtZqr+bqr/pqkwLrsAprsRLrsTrqc4AUtEartE4rtVartV4rtmartm4rt3art34ruGKr
BZDqnJbrnprroKLroqorsz4psi6rsjb/a7tG6bvKa7y6q7Hi67yqKbtyKrsigIu+BMCyar+S67ke
bLoi7Loq7L7Wq77eK73ma8Q2rMTyK8P668UabMJu7MK2xMAGLEt8bLAWLMFmbMlyLKWSLK0ahcWi
LMa6rMZ2rMymrMmubM2O7M0mq8riLMye7MyKrCsl3ksIrU0YXqcsHkwkAGIC3uzNBATkIF4ALbzu
rM7m7NRarb1S7dU67MRCbMvO7MuCbczSbM/abNnyrNj6LNmmrdn+LF1QJQO+Zu65xkskoIHmXkdi
nrAFZ11cYXniRFaiSIDihN+WiNRmLdY+rNYi7tlWbeNubcVy7deuLeWGbeWOreVmLuZu/67aam7n
cm7bUu7h+gTcHiDe8iINht5L5m1NpiRSMqNg8mDsIcDsOUDrTR9NKp/+0af5jV9LaF/scd9L1J7t
4V74aZ9oLh/62e7yDahy7qX5xWdk5h/t/ubv2p7UdR7wQm/mfR65tZ7QHcXodu3iKm7iku/5Tq7n
6iqOtC+9ui/8vq/8xi/9zq/91i/+3q/+5i//7q//9i8A/68ABzABD7ABFzACH7ACJzADL7ADN/D4
8sQH3hwCUB/mrePmIZc55i0rMt/QlmTqEeULppsDqO5P0mAPIl8KsiQGGmEWxsQD8Kfrml/8sWAS
mrBLsCDSMYYAyGMG/yd8Pi8pznAQh/+kAMCehRoFwDYwEz+wEzcxFD+xFAfw51Zx6K4v2l6uFWcx
Fjsu23Ix6ILxFnuxFl9xGJNxBO9E6R5h3nbe520wB6InTBTuCAMxgwLxUKawTK6ZCL8w6clgbNYk
U7rEHQdlf9bePWVKSQaoTiLfU7rETsqxT7KEA8wj1CLF+KrvGUNuGYuxGY8xJ3ut5I5y5JYyxZ6y
KJtyKsdEGuvEGrcEAb5g09If8ApeLMsEuR1Ac74xC/cw5+2eTrKeZfpn+XEmch4l7dFuc5IbVHoe
LwZyAXpe+MHiL5Ob0E1A9QrAZVJnL5cfNjfALhexOMNy9oLzZV6y+G4y434xGXdxKKv/s/k+Ljyj
rzzHMzu/Myivcye38zxrcj7b8z7j8ycPdBa38olmMimjcvnS8z3r8yo/9EL7M0Hz8z8zdEA7dD8n
NEQzrEGbKEKrckRrdEgnhUR7sklT9EQL9EmrNEqvNEZXdEm3tEyzNE3rc0eX6EcrdPqK9E6TNE/X
s0W780un9FC7NEAL9VFnNEj3NKLeNInm9EYDdUzXdFJXtFEHtVLrtFT/dENXNVF79VVPdVHPtE2T
LlAixeASboOqNV4EbuC60AOEL01A9UhrdVdjNUzvql1fNFiTdV9TNV5/dWCHNVfz9WD79WFzslOP
41kfRVrfBB3bRGQjhVs3dqe8p1GE/95I4gRdM3VU37VY/3VWf7Zhh3ZijzVgm7ZqFzZSnzZAGzTr
PR+Bdl7ESV0stp6mxHbrXW/EWXMCDt8gAyEuqp86siN8luPslR854mKybLYNRxw3cqDyjidgOONv
w7LzEh8ukp83Ni10sx5N1rYxRmMaAhzrRdr73S4QHt9avyDXiLBNdPZWL/V87/WQBkD74neU6jd+
57d/7/d/9zeAD7iAFzh/H3iAIziBK7iBJ7iDL/iDNziET7iEVziDX3iEYziFa7iFZ7iHb/iHdziI
j7iIlziHn3iIX3hHr0hKSh1lwjIDeI4Np+FmGmAhB2XqIXNLsCdL6PD1eU4j02D2Ov8ySALhYCxg
CB+A55hedQrADLZEMmpejq91k78gcg2l1HHekmfvTBrABKQkgH4eEZ/wI0Pl7J0lZ5M4iqt5irc5
m7+5ibt5nMP5iec1fYM2a492XZN2a6/2nQtAKxOxfEJzO87xIktdP6bh3Ybfk3tgkaefI/8gJKNn
DX6kUjZh6EUA98I3D7YEfzL2ESY3AzR6p5Me1wylBnumOOdkmHukSvqgTCjf5/jmTcg3nv95n+e5
Z+85r++6r9c3n+v5r986K9uEZt+cixN67+JipB17bUv3d2sZuc1helvjZ96cNHojdwPh8qEnBHRm
Et7ubqdh8ekeddci36afpE9gB/v/nrZTsrgrO2dGnPbVl/Shdwfv41knwKMXenwLO7D3esCfL2Hj
OsATe7DbuX0ffGkX9mIfB6f7xGTbBAYXRsTXxMQnjK03vMErfMIPPMgjvMCL/LBz/MJ7/MgD+qew
XdMmBdHmBINm51KwPOK1fNhsfK53vGD7OVLw/McX/MnvvK4Lvc4DPaM+fIjiPMPnfNAbPcsOvdOX
PNP/PGL7fMpP/b+CrMcuPdejvNTPc9SHvMlTfWpDfdWbfdn/OdKzTgIu7U4UpsS7vTkpvdeLPdZ/
Pd4TfdOffdHz/d6n/d+jdlmz2CvbxDPLPTnRvd6TveCLtuO79uJffddHft6HPcnb//3kW77KmxMT
Mqfr1W1lNqdMOnl0Zjl1yv0N8jhFKb7m3z3m132kRrHsTzHtz77t1z7u377u5z7v777vK/Dasw4T
QjlQcroEli77DYYPg77xWjYcLXHvR//vT7/04z7sj73kX7/rXz73Y3/l+z1MBP/qDD+BCqh5FqiW
lWaCxiAht7crsT74Zz/lvz79t37mx//3Az7jP77Vl7z4A4QAgQMJFjR4EGFChQsLEjAgwACBgREP
SiBwsQFEiQIbXBzY8WCDAgYJHGB4EmVKlSsNIkgYgKUAmCxnrqyp8mbKnCh3nuzJ8KfNmEEVEn05
FCnNpEKVNmX6FOfSqE6nQtWZ0P9lTK1buXbV6oBAAq9jyZZFmPWgUYRq00q9SvWtVZ5j2RqsW/Au
wbwD9wrsK9PtXLiC5foMbHgw4sJADwtEaxZyZMkDIxyYMBlz5pOP8TZe+Be056Kij3oNnZgx6s+k
17Juq3o07NKLV8tubfv1Qc6aeff2/Rs41tlVicctTvi44uS47bpuzrwzdL3Oo9OObX24ce3Ityvv
LnAFAvHjyZc3fx59evXr2bd3/x5+fPnz6ddHvyI7d/3e96fGfvs//gT0b7naAnzuwOoKvG7B/AY0
sEEAI8xtQgQrVPA7CAkywAIHCcyQQRA91LA/Eh8MsUQUTxxRRen4om46F/2C8UX/GQGz8bQEY9Sx
Rh5nxJHGH328saAJTmjRxA9TZJFJCUV0ckkoV5RSySkp3CrHC3fUskcuhfSSSDCzfPLKKMu00kIy
0zRzTTQxFEACE5KcE8k6mzyzyjzpvLNNPe2kck9A1woAJkILJVQmRA1N9NBGGX100UgVndRRSSul
FFJMLc300k45/XTTUDUd1VNRSyUVVFRNTfXUVll9ddVYVZ3VVVlrpRVWXG3N9VYLEtgVWF2FvZVY
Xo0Ntlhkjx122WSZVRbaUQXl8003t1SzWj+pvZbNbAPF89s+w/X2T3DLFfdccmeLgAAHrO0SW27f
/TJeeLuVV9tp9TV3W3uDDLNe/3rv9TdffvdFt1+B5wV4YIULRvhgdSPGd1yKY/PAgggaZnjhMTf2
uON/QX5YYoNDBhLlIUeumGCWHXaZY5ItTjhmmFdOd+bWQGBATJF9TrlnoAOuGeeWg1b5Z6SF/jjp
o50e+maao15LAQWUvvppppc+GWuo6Wra661lNlpqsLXu+uysuQazABDEttnstcNGW+60sYx77JeL
1rvst/cmum+68wZ8YrIL57vwCCy4zO/A1R58apMhlrzkyS2vHO7GDyec8pw7N/xzxEPn/HLPSwf9
dNFTJx1z0wUCK4LIV5e9ddRrV/121l232AMRJChAvAUWqJqCBIx/iCAPjDe+6v8KFhDPggYgqIv2
v6u3fXfstcc9e+631/37670fH3zyxS8f/bsoqMB8vDMX/P3Ha9tgggZWKECBBDTWLAETGHCBASJw
V+7+Mjv3We+Ajpub/BCoudGdD4IoMYEEwpfAzUXQgQZUiQdYsIIGUCA4CjEACz7QgELR6IQpBIwK
WbhCF7YQhi+UYQxpOEMb1hCHN9RhDnm4Qx/2EIg/FGIQiThEIxYRiUdUYhKZuEQXLmACTZSiE6dY
RSpe0YpZ3GEEWECAExQwOB7oSAM2oMUTXtCCD0yjBuHXwDYq0G5xrJtBLIC8CmaQgGvM49sgQAAJ
DDCEY9mAAkqyv7+xkYFwnCP/5PTYvfQ18o5vRCNsHKCBDSBygZmUIyOFFgEFaACMgTyJBwpARpph
cpPx0+QiVZlKNyZykpJU41pGMktZopKVrwwbFysASFHyZgMNYMAlc4dLTt5yj8h0JAaVGUlY2vJx
EGCBIo/5TGO2smMiKIAdfxmcByzAJN+7pi5dSU1sVnOV6CxnLK2ZTIKwAALkzKU55anOd0WgAvHs
5j4FAIICXDKUzkznOQlaz4LSE6HsHKhByVnHgyp0ndBcKLUcsICA8tMsDyiACL6Gx2XG7QHLE+ny
FNCAqilgAiMVaU6Y2c6PelSgER3ncDagAV9CdJ44tedOv7UBCzwAo0ElyAYW/8BNSLYPaMYzQUkX
YIHgLeAEJ4XA8oA6mQgsDwQnlYDwPoCADyygAsRLgLtaOlGdPlSiMk0mh9T60mYi9a2AiwADQChU
uw6ElMQ86iNhc1UIKGABGkBAARiA0oveNaQKYMECVrCCBbAgf1Wd6VkZmtC05nSWIshIW2OK2cle
1k9xuutoCbIzoDwLtc5SbaZEAAEGCHYBEpiAZEkbyKsqgAGNHd5UVxut3qa2WcH1rXCBO1zjzooB
Jjjub5lL3OYu17nRNS4ICKDX2o5WcQYQFWUta4ADVAAB4BTLdclbkN6d4AMakAAIDAlatH4Wvu40
a1oWMN75xtetLu1slapWXv/yajauHjOARQjAgglY178J/owCCuCCE0zAkGXlLFz1S+GAReADN/Ws
fCfM1wAbpAJ1JQgBEMC4gYBlIwZAQLsIUoBwEkQCPFuIAwog4oMwgIICeICIY6wQhwiAAgXQcEoo
YhCMtfe9BEwACRcAAdoqGMpaiQAI7LcAESCYp5Xl7pbdWzSM2bfCHg6zhNemOA8chAANQABt/Zhi
BFCAAPoUgIsNEgHJJuAAEEAyRCYiADyb+AEaM0ABtqkxOw8EzwcA5I/5DBEDPNoAkp2AZYp0gAQU
uc4s3rDpNgABDWx0yFEWNVmo/AEWnDnJ+b0vhzeNPdOSOcuWxe9+DcSuUJf/ZAIbmTMEiqzih5RS
IHQuyAFG4uuE/FjF+jzARoRN6IEQWyD2BbYAkK1rjtRSJAJh12WyzRFrGyTDrX7ZAwhZAROPGt29
CQAJTdhlWbM61ly+XH/FvGpVdxjWBnIoQkoigD4KgAEZ6TUCkLfsOb/42bVMQAEIIOOGPATTRW52
LQUAbTgRwMUMqGW1T0wAEWOc0ISOJ6M1ohDYxftKBngtR9Pd8l+qXAMsrze+95rvczHAbRamOUx1
Lu4bhdjH4bSIjAduxwSsGOECsfhAfkcSiOta4uHsdsWLTQBDY1wgHIcTxQWi8RN3neIMXwhbU/2i
BAjPxi5Xezcf0EUW7Bnl/7PuedzhTZAIaIC2Nn/3vX0eQWmO3ZC0taNRIbLnQ0PEMkMe/IYEEmhE
K1oAhxfABC5z+MVHANKPvrOliwQBdxHeIPTeuwA2YBEwrx31QXXACQpwF73Lu+5a5tfJ+U732pd9
7jbbwAfgnnqMagDV8k6ABSSAZd8fH6OeTrq7YX972Y9zfcyXvtxn3vehwBP5o40+Fo3oaZlnH/x3
9cBjuW/G8p/f/OnnPgskoH73ox/+75d//F3Q+/CL8gM5B+34l39//wc1ATRA/2jt+WJv9ObuwQ6w
+myPABXwLxTgSDAK9HxPAfpP5ySgAexPISrj/xDiADTwNz7QK0RwMrRJr/9eb/oMsPnsJQK2qQCd
zwFr7l8q4Pu8AgLSTiEoLesmcCEa7gAY4CI+TzyeDAIGy8+A0CSW7QB+BwFyrCzOLnA2wNwO4t8G
AnikjWcwbSyAh+uyjuC8cLOUrgsTQqPsiAEs0Md4UCUgYAwX4gwHguS2Ig4l4wEcCgWp7w7lq5KM
DwZXMPdesAE3x1fMYqqULgLYkAGerDJ8UGMcAhFpi9gY4PSy7sWcTcUsgiASwI9qyeAqDuq+sCwe
4Ns+ipTUMM0EItcwUSM+zyEYzgUFIsgwrq4goAFyreEOgtACbsRyDXlKQhWpLiQuosb8jQsTEXgw
DqiW7SJezAGAEOuoLQH/nNHEYnEYdcwZw9DbBmuzYvEUC0KjVqwAgCospHEgHsAZ+2/QMI4XrTEd
eUYZnZABVA7jDCAWHS4hNqCwZJDnFjB+AqAN8VAfP2wfP+DJukLY/Oh15pDaXgwhBQAsHqITBUCY
SEICHq0jgMrXOlEUHcDiOnHZHi3XsJEsduN7Fk4No43FwoLaLqMAckzFqkoTg80J6Swim64gnK3Z
TILR+u3oxGLpDuIhIQIUFxLNTOIX4VDOfqwlrVAnndAgInLaHFIh+y3rkvIhps4mmU7XHuALX1Ig
fvEg9aknv/IfC6IFTxIg9zEPd2SCdk4g3zLMCNIsDtKOppIh6/LXzvAA//ZSzuBw+YxNmMDCJzlx
IyJyMkhyfEQLJRjgDGsp1+BsIqBuIwhgAjJPY5buJ4Nt4yZAF6mtFxlyL8fQ9NwF2YaSKuFstg5u
zpxyB+HwISjTMhtvjJ5S11QSKUniLl1zzhog855sKXUT05aOLgUiOMvSLhYABPswBZUzLbFvLmBC
BwQgOkMtEJezOtNySAaxLIazNW8yDEnuxyigxKJtz6hyQ0ARCBkH2iLAIiByFDPqPbln0JKTIMBi
zawQAeQs4jaiCHnNADYLM8fQ2aTS4XYS4dRsDDXOAKJxJysy2OLR3zzuP/sNLHjzP7vTM/0tPy2S
IyxyFFUsNcXzABY0Kv9bDEIztDVF0UIP4MmOjjdj8ekSjim7szhXQjEZ8A9j8CQ2gKRMCrBCLgjG
A+QK4AQ6wEhpIAOSFASSlEljAACeFEqjFEqlk0ql1EoBAAWYVEuTtAaMtAN+IOQESzyCIOSYQKqW
B8HW8jpVcHRosJscoCAPwgCoM8GgMGIArAPzFPlMC0f5sQCvCs8aQAUKwKkQ4NMYwEiTFAWulFEb
1VEfNUoFYEohlVIrtVGzNAMwoANYr1CvoADCSgGKJ/jWlDnZdHUgUE/3qQL55EZT1VXV7shwz0/L
RnkOgMG2wFAXoAOQtAUs1Vd/FViDVViH1VIzYAY6wAcKIEgLwExTCgT/1TRHL6j+XjWQwi1aGKAv
qVVbR+0BPqC4vvW5igsElqoABGsHCkAFOiADYIBY29Vd3xVe43VYRyADbKADmgoBVsACsHV6wtVf
pQtcQQVbt/U31gdRDGb7CFZho+zvdNRHDEABfscFGk5dR0BeLxZjM1ZjN9ZRYcAGwNQFrsBME4AP
oXVW12L36BMzSHDYVLbiXDY4gM9OMIwPucIcD+JmUSJnu4kW94lF74ojYyJotQLo/HABDcAEVECw
CsAHaMBJORZqo1Zqp3ZjW+BYF2AHyFQBTABmo9U6ZwRPRUkhUfQkxpafbHVPwtYstDAyiSw+NSMi
M3NbIwIt3bZuByJh/7ETJ5C2AoJAA36gBiyWageXcAvXcOM1BjCgb9ULBGr2ZL/2RnBuK6hxFmvx
IhyOG78zATqiIVHUHJdxIlxxHYftIqjSHAdNxpQxEWGR4bpRKzxAA7SlAWpwIJyRMrvud4SxdjHu
FjWijzCCOHXNIhjOCTm3zQyCxng3x36wI0wiHZGx63jXHgsCCFfMHUupdCXLds8NFUuX6Fo3HKOX
4R7CFnuX0cr3dn23dLkXFkt3I9CXcSLid2932VZMIoqMebOXEv2y5Or3IkTRvjqzIDYAP4xWLQLg
ABbABSwgB2YgBA4XgiNYgic4WGEABxhgB67ACSZggEw2R/ZtJX5TNf9rcgy7zTxV8cewciR+kStN
0XnfLCE/zqimbiVSVlsIoCBbWDejUthC13k1bc6ycDIrsSkHItcSwgE00T0Hogr97NsGDQ3jVteg
TYcxNOuwsYljso/AzHVb0+uskIIiYoDYViK78ItlchWDlzhBEX+neONAs+SEEnmOmBgTAoRNFUMS
QAKugAB+IAMemIIDWZAHmZAbtQRooG/ziU7x2K1sjSVgE9Iuk+KgDSwc1CZJrgqV0kI1bzVHzKhQ
E6jobD8z7yEq+SGyciXCTVvqyyAiYs96mM76aIBE2doIK449jiRMjI4JgjF1M0ANQpaDLYrdWEZd
mSEmwNnk9nXUTMT/kHnjfg0bgW0/DaJEd7PFBE4y1xh58HeS35h/i+4jGkAUFUKV5Y6DlJUBbkBw
C5md29md2RkGOkADdsAJ2MuApcLMVqI/ORQYxVDHNpTYNq4AKvMAEGC8fkxFH+1nXZQex7cg+ogC
JvSHCaIjIlqP/5nXApolHHlFVvUpm3AJZQyWTWICQJrQfrglNTqONbEBQhMWEaClhWkUmzfGfuwn
kfAAWnryTJomp/efJSCefrniQLrHbjI0awmndTqnlxCGXUylGe2kiW2zppmanbqWonraqJra3pCb
ZXSoJYDY+g3TfBA/JxGvYpe76IcJyBQHSuCd3xqu47qQQ6AGfGAH/zRAAZDHg0EMBxeWJWJ1SfKW
Wt/WrwOpALL1oacJoihABXYgneUasiNbsge5BTqAADTABBaZkf1F9Ap7JdR2ShLQs0c7OCLiFRHC
hi+II7dAA2hgUScbtmNbtiM4A04gCJigr0sVX/aQtE/iLEeDiCJgBRy3t4v7NxaAAqYoq77qBmbb
uZ8bugu3BV7gXKMo/sqvVY27tBighvbFH7UbvEOoLetktRlgBqIbvdNbvaMWBTBgB5hALPRurnJ7
tPPqbk6C9qDMbA3iDQFu+fZbMhqANVli4TR7IX7Qv2b3Qw7xCiygudcbwiNcwi+2BBr7BeLUsnwK
wxeWqO6WWn5bv//vNied7q7Mc2WNE6Pu+CgG6QN+4LUnHMZjXMaH1QY0oALMGo8r6bBST6Nol0bG
e7SI9yB/xxUFoo8aQM3CacQbgsj/t3tlGgdLidAwjsib0MjTLMmFOeuafCS+EXqpXOziOBIJDYY1
IuAa0rQZ7oxHKwCQkyEc4AVWAAcAecbr3M7vnFJjoAIEkMsmwAJgAp8Q+1X9CaA6SiVaEMd/qUJ9
yTbJ1gBokdmU/L/t698+EiRHUYRtUwsfHSRUExp1kyjLEc/EujC7WSMi+tEcgislC5WFqsNN7gU+
YM7xnNZr3davFAb2fABvBmNoNwC0ycN5HJwcaXYwhrgDaeFkDDz/X5Nx6HjJR8y+MNEwcTE3b7nZ
Ix1DDVTpanOi+xkYxbggvBLsRosF5AQhTEDW6fzW153dbR0GhMcDQAYf3+42eMnAXS6Yhml1NMgA
ikoCQS59lx3gQE4Vnx0Oh/cZ4WSwGA6xe5jRigwICa3gw0ngLy4cNTHkaNmfNx7OQk7Gci3kaHif
8EkEdmL8FsCt213lV/7WceADzF07iG3D6cWTQAn5SMmUNgeRiGoAw9vnFaIMhYS6cIDli97obb0E
FkAFDHwmKEA79aSP/qjlBqmQBgeXGOzef360PamX9OIAPuC8j17sx/7OR+AELGBUDQIEhj1CIsAE
0mzHNUOMCEAB/449e6BLVCigAU7A7rVeYSHAAkr+UBpAA56W7A9fWDEg5TW2AhYf8d01BF5gcRQl
ASrgBJL7XyVlAjro8oVqhFYgnwD2VLZMo1gg6/0+T01AA9JOBAggAx5/xi9APGRASlWAADjAcC+A
AC7AVwkAA6B092FfXkPgBBbABNDea5+DfuwHf/SHN/rnfwJIw84nvgbJAugb9f/PHBcg7THGBoS/
zmV/CVwfShUXA3D/SV+gdDmA94eAAKKU/GXg9gmgAq40+HXf/S+C9jGAxC7iSQFCBoGBBGQAOHjw
AgEEAy8AIDBkIAIVCAVyIFABocaNHDt6/AgypMiRJEt+jKHhBv+KBQoECAjgMqbMmTNh0rxZE6dL
DyIkFECAYAFLBRQSGDUw04NRowoUVFgA1EIDCDZ1xqxqlSbWrFa3cnXp9asJDQ0efD2LNq3atWzb
un3bNoIJAgoi0HQ6wqTevXz7+v0LOHDfCwguZCDAA4AMDgAwMH74QiOBDAAqZATAAUPlywBePJbs
UGFiAAoTFj5Y4TPmyBsJaD5YECEBh5YRehaMO7dukytzcFxiYQLbsFyJZzXedbhyuC+Xq60qQgMD
pMyrW7+OPft1BwroOvDqoMCS3eTLmz+PniRhhwKXEDjoGLZB2fMLYrjMgfXH2aTfJ/S/3kEcUITQ
gBy5JptDsDn/lF96Dj6oVw4LoADSCBVA8JxzaSGnE4c4eXgTiMVpiFZYICxQgAh2acdiiy6+qFYC
DRBgwopgyWSABi1AyGOPPv64UYCNIQbfYyVghMELsR1UAkMI9UBAZvcpCFp/CJUGWwWvcSClgRxV
4FoPD1HJH5RSVkAlkGrmdoMGMZikwAklkniWiDmtZadMeXZI51ccbgBBARpAsAGMhh6K6FsgMOCC
BhTwKcCJIaxJaaWWXopppprmVoIGNPg1QwU2Qpohnn2OaCpze96YKloTMNoACInOSuuhHiiggQYH
ODDTiQs8qicFFUy6abHGHotsssr6NQIDPhALWKijanXqcdUm/9fqW6s2l+2cAmwgAqMnTDBtreae
a5UBEhCggQIeiGgAAwSIQMEC0C6Lb7767suvgxhYsONu0n54LakbFkywqgiHWC0FCliwAgMQeIBu
xYhuAAILGnzQgAi83nmWAxZQ8MMHGOTVb8oqb8oBmkESNJAKYsKHEUcYIFgZzhqBmebKDs6gwQzp
5XAAw93WuTC1R1sLU9PNOQ3101JHTfXUVleN9dVTPxDnCh9UoEAC5VpMdlYGQNCABUE1EEDWbmvN
wKcajdDBBz9Q6HPeKl/Qc0IaXVDCRiVcMJpHgLfWt5CoPXazlwdZtOVF8x2kAs96o9eCBa89OEJw
Wr8N+ueih/9O+uimh55wqaof3K0HE0gAVQEnKAACdWXP6kACB8C+ggYnmJDAVQt7oMG9HdnwNQyX
L4/sEpQBoMJjkh+UAQLj9ZAZACXMF5HN/EHv35gcKQ6bZjc/NAT172WPGQdNBt4YY98zj1sIPjCA
so82qKBn0iCzvjpvwWVbBPRf/9CiFKcswAUuEEpTJpAAit3OKhtgigIYsICFWABsEETa0mbyAhzo
ZQYFKEAN6BeYEWRghRlQHgpNUgIwcck/7MMMzGoGPi6dpkqyec38rrTDg/BgMkOCTQaGGDj2cQkA
h1GMf374Qr7QQAPwW9MINGAWbgXQg1v0kwENJkAAijGMZKT/SQSMcoCmsGABFliABoDCEKHIcQEM
aIod74hHBaxxjiiCYwOFUsemgCABWTRaF1GFkwh8AG99gQEDPmAD+mUABx0gwhsQYIcqtEEIQkAC
EICQhAGIcpSkLKUotfBJL3CyClVAgAuIEIcO1CBgefueCmi4OSVxhH0yCCJqOHOY0UCRNEEcAgLm
cz4ADHFJSnyMQIgkvijuBSU30NQPTKDFMXJRm1784CGt5U1sfVOc3ERkOcE5TjDKxAEfMN5fUFCy
DuQvWSGYwQ/e4IIqdBIMpuynP/8JUH8WAQhCiAIWXMAGGlQRXzx4QQVk0IPXDOF5B4nogCY3hAqk
DwMz0wgP/xzzAoo2pqNPwoBJMSBSJm6uBBSd6EGGkL6DLKFwHJVmSXrjzkvh4AUFDKc6u5nObZYR
qOck51DNeVR0FvWnSI1Jjs4zAgzYjZaWysAP1oAFIZwhoFztqle/OoAmSCEKCLUBI22KVr3loABn
NVYNCvBFVgXVkEsVql2JmlSj3rWpeN2rUvP606dCCHkVcCGPRkADPOhBDk0Aq2MfC9l/AiEKdYjD
m9KK2XzVwE36qkEFfJq6utIVsH7Va19Py9fU/rW0TF0talfLzpz+rIQnNE8GiLAGORQhsrztrW9H
qYUorEAC81xZBRaKkOOWRLktsEEXPgCUEkp3ukDRQAFk2f/WzHqkU3Lj107nqjTw/o+0rzWtas3r
2vO2Fr3sXa97Q+sSC1yWUjB4rg1ka5LbVgEIv+2vf32bBCGsgbgrG2Y0QZKBCnzABR2g6l5QUAMf
rKAANMguWpvVBfzi61eiDW+Hx8vaEI9WxB4mb4lJDOLyvnfEeIWADzYFzxXIUy8K+AAS/ovjHPe2
CVYgAnIfpKSLsOY+txwI/IIcJWEuZiCf+Z5FMIICDEz4AwNRUt9kiEOFROQxYBrIfIK8YAvUVpoY
KICDVYaCHXz4gOJl85pf0jY4Ny3ObZuzneWM5zrnmc58vrOe/9znPfs50IAetKEFjehCJ5rQjD60
oh/d6EX/O5rQCXCBhis1Ahx8wAdn1ogCqsBPHYt61JAVgo8hpLPsJTN+QYqefBCSTP7UBgYW0IAF
oPeZIfbtStkjDPyaRKY0XcDVMHhKp1WWgaChsANsm7SzJQ1tSD9b2tGOdJxZrF74otjNJk5xtrGd
3nCT08X6sgFGDJuBD8yB1OxuN1iTEIVhpYcA49lIfIqkPesd5DYHjrVDrrCCzQmIQMqEYkRG0+vw
KYSk+a43vw8Sgg5wNjAhoAAOAmCAjBvAAxxPgAwMQJ7MCZx+ae42t7ctPNCqWNsrB3d7Wf7tE7dc
5jH/n3xTdhgX3NjdPO95QIFABAvj5jAqMCnjPhOfIRbd/zKPidLSofkBT5nJpC4bYmYcCsVevsAx
CdcIBhCwdYcWfOmp6UgIuvCDvzyAAiAAwQRuIIO4x10EhviDbuxXgeK+kMMz97a4V0zzNqdc8HJ9
c+FNPnjDZxPxhUdAylggBOBa4QtS2K3PL395KugoX/bDH74yUAC9i+QBNSCDAMhABkpEIgusr8EQ
DMFwv9iAitrtQEv6fnLcJ57xLge831/ee5j/XfjAD3zx76QDAXxAAMnP1wSs8M8mtMEFQggl5r0K
hDlUYvuVyIT3M0EBETzi+v08AxEuDRjmCwAA6tcLDDRgWH3BIPQlccAMKEGG1bN+CvzPgggKQQmB
QU3axf9+ycc/yTd8waeAxud7x5d7NfeACciAxNeAu4dyh7dNzYcvI/ABjdVVReAFX2AFVEB+/QR+
bfd2cDd3EFAIiFCC/iQECpAe7WcSHcAA6JcsOTByHlFPqsd//PcHZtAHU0ABiVAIfzECC5ADOPhC
6qd7GPiEi3eBC/h7FQiFEGiBUdhThCeF3ZR8y6eByCIDUcBbUnAHe7BVJZgJQoN6qad/WSADiWAI
lveCpqQFxVMe7UeDIIECBVBNlxMDtwYSGzADWTAFQSiEXMAFZcAFF0ADgfBjJLFWQodZ6neAWHiF
EliFFDiFW6h4nsh7oNiJGuJ4y4IDbeBfQAAHd7BzPZf/ADOQeqy3f/xXAzRQCONXh/7UBGvAhOdB
Qse2Mh3QAR9BiIq4iGWAjMg4CDEAAoKQBXtRAwQwXwTYEbY3iio3gVTogFmIiV3YjaKohXHljUq1
AEKTLKcoamAwebrFbgGQAZRgiD8YhH2QBRPQgrkIULvYi7vxAy8mTStgYQ6wAQM5kCHQAyNQAjAQ
CSUQAIVQBjBkAd1FjR9hASICjt8ojtmokZuojdyoiRG4jZkYkuNITiDAGcbSAnbgbtL3BdWXYwHg
CFnwB4jYB4pYBlOQAIggCPgYUFIQBz7yfin1QgUglA7gAA9glBvwAA/gAUl5lImgBqLHERi2j5n1
fqEo/44XySelw5Wn45VdCZZfKZZhSZZjaZZlCZDIwgatyHMgKIIk6FswaYzHmIxlYAA0oAa4yJP/
hAXxdx6dV5UqowHFFQIbYJQC+QAYx3Ee8AAbMAFqEAkiUWaROJEe4QMScJaZWZabqZlSw4kdKZJW
SJKiqZUjWZpgVC/IggB1aIZ7wF+P5QEAUJAHiZAKGQkt0IwuuJcAJQTDiB43II2VuRExoEcN0AAs
IAEHAAEQZAAPkACGMAUhUQDmKJwjEYifmJUZyZEbCZKkmZ3YuJ3h2Z3axgR/uCkwgAV7CQRVwIpe
xZhIaZhLiZSHaQCFUAj56IH4iAQnqRsxQACRVJ0j0f8DD4ACHlACwBigfEEAEnSNXHiaDYqd4Dme
oDman8mdHmlaV0CZlJKSuzlKVDB5XkCHpbQJhimQG2AAislxRokDamB9fAlHd+AFcHl9PikwGrCD
CaqjPcIAwhGhDqqdE3qhoWmh4omh3imhR1qkuRcBOyCVlIIAI+qhYdUGX/CiogQGxskCyKmcE0AB
AdCUSzAIi8BVTQBHZ4oA0Hd5bZCjD+YDyrajcQokL1A0QJqkREqhQ1qhFPqgfPqddnpIDkAAT6om
P+AFU+pbjwAGc5CfXCUHaKqmmOcChCoSyNMBgTmRUDAGVcAICNEJFqAGAKCpVfCQAAAKfEAGckoS
GCD/J3e6p3rapxjpqrFqpHgKq396ThFAe5kSAi4gpYjqbq2UpgNghmnYc725FyUgYV3gl6raEZqK
CWMQmZ2gBp8QqpoaCdZqqqjqrCFxAiJAq0Jaq686rrc6q7iKleeqrjpRjpqCnsB6eUWwB1KKBF/Q
BlcqakjABiSBAjkQMdTZrSKhqWSgqQcQCGSgrdgqqmNQCdwasB1RkeQqrhOrpH6qMOv6oxmbroBa
VyapKTUQqfBqSk8gBlhwCKMECViQBiSLBYQgSlSQB2jAW0kgB1+ABZWXY1rwBjxYAz9AAJs2Zg9b
EgO7ramasNKKEJZwsEKrETFQACsSrhVrrlw4tRoL/6Eba7XhyBW6uqE/ggIfgK8iOwAkS7J+MACQ
kAaTsLJi4AdqOwAwK7P9lQRIYAUucAdtgAShVmosoEI00AEF0Ds/ALBMS7g98q0Ua6vjGrWJCxbW
5rjT9rjVBrmTK7mVS22XG7mYS7maa7lxdgD8WSkFsG5iO0okiwYk6wUxq7ZlO7ZiAAQxy24DxUlW
AAdfgKZn+gVwoElrQAOYWri/258WEDycS7yZa7ybe7ydu6RSq7joerXPq7VowQDmaSktoAE0KrKm
+7awu7psO0qNALu7KQS+AbzlCyQhYAG2g7gSy7zru7gWy7FYK7/QK6tpsQEW0KxrkgF6ELak67+i
JP8FDGC+A+wjh7u8jNu+CYzACwy/WVu/DvyRCsy+DBwAG1AA+asmLfAGWvC/HRwF5EvAIZweBoyk
8Uu/Jhy9EGyazpvC3vIABTCNmBYHUdC/HYyPc4AFgyvCO5wbIUDCK4yx88vCDyzERHzCQLw6EVAB
Elm9GuCSNpyLQIAFB8DDVbwbfQgsLXzEJawtQxzBFOzFSKzCP4UXmoICFaAHxgrFbSlg1GvFb/wX
NWABhbTFBzzBd7wtVVvEX4zHYczFe+wBFlBvmmIDaxAF2LvG/wWCdtAAlAjHjzwSFqIA70vJflzH
DbzHYpzJfxxiCjAhxmIDioWziRxZYEBZjQzJqdz/FzZgARJUyUF8yUasxbMsy7XMx7G6ARVwApRq
RYmFBTNKygCFBJRlWapszHsxAwQgK+5ryZiMcpwJzZ0ZzdMszdVMzddszVoDAhbwArxcKSXQAXhg
B1GABI1KumcgBK1UATfgu8ecyslmAtgsz9k8z9Fsx6+MwrasybGsuA6wABXgyOeJA2ywAvm0TyU4
UF5gUAigAT9QA97szhG9EeYmArfczHo8hRhNyxYNyxu9z9G7AU5wcysTAzPQASdABCvgSqxkBZwk
B58E0580BzH9SUjASW3ASlhQXddFAxkQ0BIN1B9BNwSQxRydz0ateBqtz5zs0Uy91Pd8ExPwAZea
/1mh0s5BjdUjATRO8DGbDNUd3Y1KjdRe7cxN/dVHLQAOwAQaELT0c0UImtVxvRctcAJX8Cj4PMZn
ndTNC9Zjzc/M3NcffRMGUAFszTw+wMRyrdh6AU8fUNGAjdZO7dcXzdeRrddkLdaCnS6CAqAp41mL
DdomQdcfUCOX/dcSjNdukdqnDcaBLdmaDcQP8AJTDdGWggIAE9q5/RFvZQHLPNlPXdbALdyVndfB
/dvHDdvqFAEicAUW4MaaUgFtrduh3QIS5gQMytp97NqmTdmQXdyZ/drhzd3qxR07cAI6rCY3IMDT
HdpR9gF8t9pmbdzJrRXJW7zIi9+dm9/3rd/9zf/f/23fAb7f9g0CJ7AD0wsk1lvb7A3HLVA3LCHg
/h3hAD7gFS7hAz7eyC3e873h4J3hK+wAB3AFGoADPx0Y7crgQF0DJxAETFDUH97hxI3Z5Srj2R3f
w+3dM57jd5UAKhAE03vVHEED/pjiqpwBPrADFiAChfLdNS7fHp6nTo7jqN3dVL7dHA7jLkEBTrAF
BJADMVwSJWABC17kQtsCNLBATLDkVm7ZWO7mUD7lrd3mcC7lGp7lb94rIsAEDUQDcB0CCyCUZQ68
EbYD7aK+dL7jT17n9K3oiR7n2j3nix7jjr5aHnAAFnDgCgVrICzoTFtPOQAxKkAuTU7pjI7obN7/
xVd+6nJO6qiu465+yQ5gAitAADtQATiAwZ1OjSPQsxbQQAeAFTdu53he6pNu7Kz+6shu41Wu7GYd
AQWgvjCBMRKgAUGwABgA5rp+OShwA28aBBVgAodO7LDe6OT+6Hks6Xe+6pDe6s1+7n6sAHUagWd0
ACrwRgWA2Nmu7ZmCAia9AB8QBAWgABPwLszO7sl+8Mt+sZFe7Oqe7uPu7sMu1gGwAGNDQAHQEz9B
AAyAUmS+73wBAzewVi6wBWCTAF0N8Qlf7hFv6g/fP/VMzzEP8zMv8zVP8zdv81pDAQUgHDgfAA8A
AQfAAAUAXW3UAT3t8QwOAyatAoCLABvUABOA/yE+n/NUb/VVj/U07/ANn/LC3vJcv+6iKAHY9PWJ
lwAToABM8BMBfwIdgAMrFOTly1I1IIyCggAfIPAHQEgKz/DmLvEuD/hlz/LHrvLvruqBj+rCsvJ3
PEgJ0BRq/0YMXQAMIIwrpO8Psn4Hkfleu0I20AFrVQAugAABL/AKIAJGIfiF//dgj/iDv/WE7/Ww
b/Cx//qtfb90nPqUfEZGAQJ25BMlFPmjP10FUAHCaPzHb/wspPzql3zKv0J+i/zI7wPDH/ykX0J2
BAFLgd1dP/vdf/isD/6y//1+n/ve3/dgPC7trvrl7xLJh4CrT/7if/7rL//qj+7h7/rcP/75H//2
Bi/0ACFA4ECCBQcGMJjQIEKFDQUwdJgQYsSCEykevLgwY8WNBC1m/HgxJMWREUs6PNkwpcKVEjti
fPkwpsyYLTXWnGnTZE6eOH2+1OmxJ9ChHYPCJPrTaNGLDxaAYAoyqsipJKvuVLrxqMCtNJN+XZpV
qliqZK2axQp2JterKNuqfMsyrku0buvCvSs3L0EGULv+nXtT7djBZQufPZw2bGK7jPE61guZrmTB
i9ey3VtZa2COmTtT/mx5s2ehpJFGnHDi9GjQpVuvJiw6NmvZhmsjvq2Y9u7ZvW3z/u0b92XApjG/
Pp67sfLHzCM7nwxdc8IHFja4lh4a+HDhurv/L9/uPfh47uTFl0d/Xj34783DszcZAKH8+fIf2qd/
v/5+/f3z/8cvQP4AHFBA/wwk8MACF1SwwQQfRDBCBiGcUEIHLaTwwgo31LDDBC0wgcMMR8SwRBFN
9BBFEk9kMcUWV3QxRhhnVLHGF22UEUcab+Qxxx5JfO4999oLksjohCzSPPjSW3K9Ic0zQYIkmXyS
yimdvLJJLavE8kgjp1OSyy2zFLNMMs/0Mkw0rUyTTTDd1O7LONVss8s37ZwTTuwG8qCA69bME889
5RyUzjvHrBPRQ81MlNFFAS1UT9gMDVTRSh0VdFJJk0OyUUg1zZRTQkG1NNJQvRIoggoSOLU4/+RQ
7fRRT2eVtdZLPxWVUlNLJRXTXX3tFVdYRxXW1ex+LZYzZGm9ldllbX02tAMU0DVYZ62FFttms811
02Gr7bZVZbWNtlxyzw2X13SBTda4b701NtZt5zV33XZfZciAAiIg9l1x3Y2334DB9Vfdgtk9+N5j
0U34WnsdbhjecR/mNmJ6rU1AAY01bmBjjz8GWYGOQyZ545FLJvlklEFWeWWPW3aZ45hZVuADmFG+
2eWcV94Z55gP4JfhgSUGeGKL6z1aaKOH/hdfoytm2uCoEW5pAVYvwzprrbfmumuvv6bIaqSnVlje
sZdGu2i1nV574bIFTpvtiMQGu26778Y7b/+9DaKb4ov9Prtts5UWHO7CCSYb4q6gjtvtpAG3tu+9
J6e8cssrlzxxxg8nWm7HNf/7cdFBD/y1+WQ6PXXUV1e9ddZfdz122GeXvXbab7c999stuNohBggA
noACKCAI+N4HAh55Ao4XKHmwCzggoQMK2Gj6ywUygICZrK+bAAMKeoAACLAuIAHdz8c9ffTXV799
9t93P37455e/fvrvtz9//PfXn+rGB4dcABsmOYUUgHoDSQACiCcAAvzOAQQpQAO01zwHQlCCDTHA
AxKSwYIY4HsDgZ4AHvBBgXBPICM0CApN2EESEoSEDjDAA13YQoPAUADZIwgMZZjDFq5Qhxn/4WAH
H+i9i8RwI5n7n+E8B8DRJRFxTuzc554WOtIRbolGImBCDFiQA0yQAAeAwAQFwAAJ4LB5YBQjGc1I
kAQSLwIhZOC+BAABBGiQAldrwAELQIAJCIQBB+QeAxggkDD6UY4JEJ5BDvDACBBASgLYYx8F0MUH
Zo9VdxRIHhVJRAfssYQEqOTyJik+QoJykgf8I7/eOEhEyrABrFSgAN4YvQRKsgEIoCEDv2cABDQg
k2Kc2/GqKMBhNpFzTZPiMaUGRWQSh5nLVCajsmiQLRJEkwyMngSo98obivGLAtCmALi5RhAGD3iD
1CXyvveA3xlwgnBs3vesx0tzeo+cKxQI/wX2uE+BwLOe32Sn8DxZECJiz4v1jN4KQzhPYPJSntRD
ZD/rOUh4ppOguxQjOR2CxGi+7YkdVdwz/QfSzV1RpB6NIhOrxjwtHlAAnXTpN8VZzTXKNI8H1Cg4
galOnhb0gpB06U+5R0qCjq95LjUo8vQYvX768qK/pKZTxflOqQ6EkgKZQB1PeUarupQBV9WpQSQg
RjrmkohrzKlCOGrSlCoxmWxtpltVetKQaq2Yd6WrrKZZEAgcwK8Q2GEJe2dUWTJ1koMdSAQMSxDF
RlCSkwwaZF8qAQZMQLGETAAFGNCA3iWAsBTI4yIHMoHNPsCzBklAAzh72jke7wHalMDVHP9AWcsu
FoGvpMBlTwjbq03vAa98LGsFkABtirZ4jy2sYwcy2wKMD2iKVKVhdRs2YeaVitYt3Vu1O1eSXre7
0IQreLerVpZez7zn3Ro+M+KATtr2vGsd70fDO9L5ojSu8o1vW7Frxfzel2/lRW+ABTxgy8GXu/Vt
FAkUvGABhCEFRgDYghVshFDo18L+xbB4D4w1vH6Xv53aK4FFPGISa83AckVxmEiQgiNo5wiBDVKL
BeKAF0tkxS2OwI0zTN/+ajjFF+4xjzc8ZPKW2MhHRnJHToxfIqs4BW5QQpQFoIQHv3TFdFDCikkg
EAUL5AgpIAFCjABmI4RBAG548BHo8OT/iqzYCEZQsAZ3bF8fM/nHc66IjvT8oz37yM87ShHvGqJP
GB85AZHd4E6RrF4SH5pr5QN0pPssaT7zZ8WcOIInPBEAKod5zHRAiCfA/JAuB0DUYQ7AleXzZTAr
eNT/uXEAKLDiMEza1pX+861zjWtK79rXAKKzkO9c5/865IMR0OAEDsA8ZUOAXw+IgAOeO1wwulAA
yr5aXwMrbePeUITVlmVWJ/BBB/T1sTlF9hxFK23CvtTciU32sgcC7XJ3+6V+3eH3EmBb62E7VS2E
dkKUjdyA91XOA+lr7+j93Af49WoREDcJG36Ag3t7Au0u9oeHLeyC6HggVIZwp1u85i0L/2DFSjgz
mMWcApRzmeUzRjSpUxCKI4RixW7Ac0mDHGye1zVrHUawzkEM4G5+8oN/bGpiIVnQCZhyjL7kpVF/
x6pGRs8BBFjgUJ2awF3iMlUypIApc9rF7zWSAPziuizBbkqyG1Kiqfrm1bN+wEQqEgGSpIBWiVrI
gkRwINfcY9C62M9HtnLpHzz4WLHn9WsXNHt95GVVi6xxO1eeIFFGtJpbHgE3GEEJXy75lD3/gCgj
JMoyPmHnw9Byj0TZ9agnds69G/TZ79zyss9ukzOe6BK6lKHUNOw+Dej3NZpwoQI1IDoLmk6HYs+A
DWj72F3qz10+v+0m5B48jz/8Aig/l/9bBaHVQXl1GJOz+RW1JwK4XwANwrPpBZCA4m/I+IpuMa27
Nybtc08YEoSh82CGvdrTPdyjPCDjOAPcuJ4TugQUgBAzI+zTI6niF3gKIxoqvumLnge4O6WzqHS6
uquBvxLyOukLP54KwUnyOgjsp+DLwA1MlXiSHgToLaebgD0qL7/LJHQKPLdjIKmSIX9aoN+ZMVFq
vA+ypKKjrv27vdhjwgMkQGLaLyj0MAFawCV0wiYUiBDzNlk6uHRDoANAvJgzgAOYgHyDt3mLrAeA
AAg4uBZqIQiQpIbTIBLKJS8UociSOIrbQjv0woA7oTRcwzZUiHS7OBirKNQCQwhaJDj/LAgHUDaJ
QzTPqiSCYMQTgsPA+j78Azrbq0IE9DlOFEAG7MQn/MQBxMJSnLwkU8XJyawT7IhDHLEl88RRPEVa
vMJbVMBQtMJcrEVdnEVfLAgtXMVhJMb3qq4pzD9QVMJfXEZS3ERTRBhb5MUCxDNhLMZrxMa8kUVn
jMJkhMZplEL9o8ZeRBppRMVdPEf8y8Z19BoUYscsPEZxDEdlHEdcTEduRMZntAr+4cf+6cd/9EeZ
EDSwMR6FaDgBI0OHOEgk46OmYKoIkICKo4jwUbSugbSABMiMxMiN1MiO5MiP9MiQBMmRBEhw9EZR
BEaCsMaY2CzDMwjd8qzfgsXJMiDk/yIImWSAq0mAPzIsCGjFhmug50qt7ns4porJ0FIICDCgnvzJ
l8qjBtghpZxJmqysVOkiCXAviDSg8bks4kIArFSsyKIAm2yeCQinutlGcqxHk9RHdDTHt0xJe6wY
uGxGtZzHhljJjhi8meK9UQqaa2KsgRAkg5Ap5DGqq2s/YCrM4hmfBzy7TEKqFyylt/MjqSKlyOI7
vkCn4dKqDhTMzUyq+fuga4oog9ispAObtJTLuGTLbmxLZlzLe7RL2VzNurTHvMyIBDKnXjKIB/S9
yISkrzKAsxwIjcoev0LOCVwsmQqfBoAAfYke3+wqg5CgZWu6FUQerEROVqnOBLjOp/9CHqZaPp5y
oQlqvn4aHyIkiANAgN0kSxOLR3q8S5S0zdbMR9fET7vKT3k8yYTAzYsgqiG0SensvQ4iIkQCzj96
IAdgFQMKmgWqP6fqIn4Jo+icIBUsqpcaKHgaqw+SJFLqJEXrIjyKqVwa0XxCQgZCLuHBOM6suKYr
tKxRTfvkz9fExxrdT/kUHbqMTR6dT/8kOhFjL4qgIRtyCAc4OImcCSXdoBQi0pfIRBHaIdVCrxml
TRrVURudTS2tzR4NHR/tT9j8UXV8xzK9ntfCQWOszytlUzDlUiz9xjZlTYhx0xyN0/800zzVU020
U/r00jWt0/sUVP4MVBwFKTzd00T/zVMrLdQs7VO3nNNGjVMwlVQ/HdMuMYEF0FRNtYBN9dRPBdUF
6NRQJdVNHdVSJdVTRVVQVdVV9dRWdVVOjVVWndVPhdVYvVVXzdVV3VVPrYDAelM5BdRIJdZhNdY/
RdZLZQld67VmZdZn5TVo/TVpddZotdZpvdZqxdZt1dZupdZvzVZw5VZx9dZwNdcDgVNLDdMbddRB
bVdDhdd3lddJLdZkXdfZrFRIPVZl7VJ+TVd9tddgzVcxvdd+Ldh/JdhiGlh2pdd9PVhhDdhHTViJ
ZVh1Fdh69VeIpUKMfdiF3VKK/Vh3bdiIFVmLBVmDvViHXRyOTVmSjdeRzViPRdmTI0XYigXYmGVZ
mqXTnC3Zm+1Ynn1Zk+3ZiR1amyXaoPXZKgoIADs=

--_005_6E31144C030982429702B11D6746B98C36494847SZXEML510MBSchi_--

From h.anthony.chan@huawei.com  Tue Nov 20 09:51:21 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BCE21F867A for ; Tue, 20 Nov 2012 09:51:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.726
X-Spam-Level: 
X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=0.572,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twZheBee+hvB for ; Tue, 20 Nov 2012 09:51:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B3DA121F8685 for ; Tue, 20 Nov 2012 09:51:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALT04856; Tue, 20 Nov 2012 17:51:01 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 17:50:34 +0000
Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 17:51:00 +0000
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.221]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Wed, 21 Nov 2012 01:50:53 +0800
From: h chan 
To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= , "dmm@ietf.org" 
Thread-Topic: [DMM] Multicast PS to requirements
Thread-Index: AQHNxqz10Lpebwr8wEqNc0MI7ktPh5fzAOKg
Date: Tue, 20 Nov 2012 17:50:52 +0000
Message-ID: <6E31144C030982429702B11D6746B98C36494893@SZXEML510-MBS.china.huawei.com>
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt> 	<23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huaw	ei.com> <50AABF7D.9020003@av.it.pt>
In-Reply-To: <50AABF7D.9020003@av.it.pt>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.157.175]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C36494893SZXEML510MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [DMM]  Multicast PS to requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 17:51:21 -0000

--_000_6E31144C030982429702B11D6746B98C36494893SZXEML510MBSchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Let us also use another thread to check for consensus of the PS from multim=
ob.

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of S=E9r=
gio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.

As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should =
enable multicast services which are compatible with multicast distribution =
scenario, etc.". It seems like there is no major difference between this an=
d the "DMM solutions should enable solutions to support multicast services.=
" requirement? Aren't both expressing the need to enable multicast in a DMM=
 solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the P=
Ss you referred.  So, while 7.2 and 7.3 express the need for DMM solutions =
to allow deployment of multicast services, 7.1 concerns  "how" IP multicast=
 should be enabled in order to avoid the aforementioned PSs. The usage of t=
he word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mo=
bile host to be managed (e.g., subscribed, received and/or transmitted) usi=
ng multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn'=
t necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these pr=
oposals, let us understand what are the problems first. Two problem stateme=
nts have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. I=
n the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution sce=
nario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to s=
olve the problems PS1 and PS6 as explained in use cases already presented a=
nd discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such=
 a way that it can be extended to also support multicast traffic." I rephra=
se it to highlight the similarity with the other proposals and also changed=
 the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was "DMM solutions should support multicast services ... e=
tc. Given that it is the scope of multimob and not dmm wg to provide the mu=
lticast solution, I think "support" here means "enable" solutions to be dev=
eloped (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable mu=
lticast services. Yet the explanation in REQ7.1 seems to indicate not just =
to enable any one multicast solution but also needs the flexibility in mult=
icast solution. Not all multicast solutions are the same. Some of them resu=
lts in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distr=
ibution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with mu=
lticast distribution scenario, etc.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively sh=
ould we deploy/support multicast over distributed mobility rather than dist=
ributed mobile multicast. As a result, you can find this deployment use cas=
e and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob=
-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at man=
y access routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted fr=
om the draft described above.


REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution sc=
enarios. This flexibility enables different IP multicast flows with respect=
 to a mobile host to be managed (e.g., subscribed, received and/or transmit=
ted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via a single endpoint (e.g. regular or tunnel =
interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].


Regards,

Seil

From: pierrick.seite@orange.com [mailto:p=
ierrick.seite@orange.com]
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it=
.pt; JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterD=
igital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that m=
y
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions bu=
t
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.




_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


--_000_6E31144C030982429702B11D6746B98C36494893SZXEML510MBSchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Let us also use another t=
hread to check for consensus of the PS from multimob.



 <=
/p>

PS1 (revised): Non-optima=
l routes


Routing via a centrali=
zed anchor often results in a longer route. The problem is especially manif=
ested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



PS6: Duplicate multicast traffic=



IP multicast distribution=
 over architectures using IP mobility solutions  may lead to convergen=
ce of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 <=
/p>



H Anthony Chan=





 <=
/p>





From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org=
]
On Behalf Of S=E9rgio Figueiredo

Sent: Monday, November 19, 2012 5:24 PM

To: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.



As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should enable multicast services which
 are compatible with multicast distribution scenario, etc.". It=
 seems like there is no major difference between this and the "DMM solutions should enable solutions to support
 multicast services." requirement? Aren't both expressing the n=
eed to enable multicast in a DMM solution?



As you stated, "neglecting" the requirement 7.1 we proposed, lead=
s to the PSs you referred.  So, while 7.2 and 7.3 express the need for=
 DMM solutions to allow deployment of multicast services, 7.1 concerns =
; "how" IP multicast should be enabled in order to avoid
 the aforementioned PSs. The usage of the word "flexible"is expla=
ined by: 



"This flexibility enables different I=
P multicast flows with respect to a mobile host to be managed (e.g., subscr=
ibed, received and/or transmitted) using
multiple endpoints". 



In other words, compatibility with "multicast distribution scenario&qu=
ot; doesn't necessarily avoid PS1 and PS6.



Thank you and best regards,

S=E9rgio



On 11/19/2012 10:28 PM, h chan wrote:






There are 3 proposals for=
 multicast requirements. Before comparing these proposals, let us understan=
d what are the problems first. Two problem statements have
 been proposed:


 <=
/p>

PS1 (revised): Non-optima=
l routes


Routing via a centrali=
zed anchor often results in a longer route. The problem is especially manif=
ested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



PS6: Duplicate multicast traffic=



IP multicast distribution=
 over architectures using IP mobility solutions  may lead to convergen=
ce of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 <=
/p>

Then, let us see whether =
all the 3 REQ proposals have the same intention. In the following, I rephra=
se them to highlight their similarities.


 <=
/p>

REQ7.1: Flexible multicas=
t distribution


DMM solutions should be c=
ompatible with flexible multicast distribution scenario. Etc.



The Motivation is to allo=
w flexibility in (enable) multicast solutions to solve the problems PS1 and=
 PS6 as explained in use cases already presented and discussed
 in multimob wg.


 <=
/p>

REQ7.2:



DMM solutions should enab=
le solutions to support multicast traffic.



 <=
/p>

(Original wording was &qu=
ot;The DMM (unicast) solution MUST be specified in such a way that it can b=
e extended to also support multicast traffic." I rephrase it
 to highlight the similarity with the other proposals and also changed the =
must to should.)


 <=
/p>

REQ7.3:=



DMM solutions should enab=
le solutions to support multicast services.


 <=
/p>

Original wording was R=
20;DMM solutions should support multicast services … etc. Given that =
it is the scope of multimob and not dmm wg to provide the multicast
 solution, I think “support” here means “enable” so=
lutions to be developed (by multimob).


 <=
/p>

Similarity and subtle dif=
ferences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet the=
 explanation in REQ7.1 seems to indicate not just to enable
 any one multicast solution but also needs the flexibility in multicast sol=
ution. Not all multicast solutions are the same. Some of them results in PS=
1 or PS6.



 <=
/p>



Are there any are essenti=
al differences between:


In REQ7.1, DMM solutions =
should be compatible with flexible multicast distribution scenario, etc.



Versus<=
/p>

DMM solutions should enab=
le multicast services which are compatible with multicast distribution scen=
ario, etc.


 <=
/p>

H Anthony Chan




 <=
/p>





From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Seil Jeon

Sent: Monday, November 19, 2012 5:15 AM

To: pierrick.seite@oran=
ge.com

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 


Hi Pierrick,


 


I’ve many times thought about your =
question. I would say how effectively should we deploy/support multicast ov=
er distributed mobility rather than distributed mobile multicast.
 As a result, you can find this deployment use case and gap analysis at 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 p=
resented in multimob several times.


 


In unicast DMM, main innovation is to dis=
tribute the anchor function at many access routers from single core. Follow=
ing architectural concept of DMM, flexible multicast distribution
 is one of multicast requirement resulted from the draft described above. <=
/span>



 


REQ8: Flexible multicast distribution<=
/p>

"DMM solutions SHOULD be compatible with flexible multicast d=
istribution scenarios. This flexibility enables different IP multicast flow=
s with respect to a mobile host to be managed
 (e.g., subscribed, received and/or transmitted) using multiple endpoints&q=
uot;. 



Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via
 a single endpoint (e.g. regular or tunnel interface), which would lead to =
the problems described in PS1 and PS6.


PS6: Duplicate multicast traffic


IP multicast distribu=
tion over architectures using IP mobility solutions  may lead to conve=
rgence of duplicated multicast subscriptions towards the tunnel’s dow=
nstream entity (e.g. MAG in PMIPv6).  Concretely,
 when multicast subscription for individual mobile nodes is coupled with mo=
bility tunnels, duplicate multicast subscription(s) is prone to be received=
 through different upstream paths. This problem is potentially more severe =
in a distributed mobility environment
 [draft-sfigueiredo-multimob-use-case-dmm-03].








Regards,


 


Seil


 






From:
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.=
com]


Sent: Monday, November 19, 2012 8:55 AM

To: 'karagian@cs.utwente.n=
l'; 
seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc: dmm@ietf.org

Subject: RE: [DMM] Multicast requirements






 


Hi all,


 =



I tend to agree with Geor=
gious, however I still do not figure out what is the use-case for distribut=
ed mobile multicast (other than academic considerations)?
 Can someone give concrete example? 


 <=
/p>

I haven’t real all =
messages from this thread. So, maybe I missed important points.=



 <=
/p>

BR,


Pierrick


 <=
/p>







De :
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.=
utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; 
JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should someho=
w consider muticast deployment. However, I do not thnk that the DMM WG is t=
he right WG to provide the multicast based DMM solution!<=
/p>

 


One alternative solution will be to have a multi=
cast requirement that emphasizes the need of having extensibility hooks (po=
ssibilities) that can be used later on by the multimob WG
 to provide a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like t=
he following could be used for this purpose:


 


"The DMM (unicast) solution MUST be sp=
ecified in such a way that it can be extended to also support multicast tra=
ffic."


 


 


Best regards,


Georgios


 


 


 





Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
[mailto:dmm-bounces@i=
etf.org]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.co=
m]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; Zun=
iga, Juan
 Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org

> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

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



_______________________________________________

dmm mailing list

dmm@ietf.org

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








____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.











_______________________________________________


dmm mailing list


dmm@ietf.org


https://www.ietf=
.org/mailman/listinfo/dmm




 






--_000_6E31144C030982429702B11D6746B98C36494893SZXEML510MBSchi_--

From lmcm@tid.es  Tue Nov 20 11:47:15 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902F421F868A for ; Tue, 20 Nov 2012 11:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEefRg6OnQzp for ; Tue, 20 Nov 2012 11:47:07 -0800 (PST)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12C4621F866C for ; Tue, 20 Nov 2012 11:47:01 -0800 (PST)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MDS009Q6XMB1Z@tid.hi.inet> for dmm@ietf.org; Tue, 20 Nov 2012 20:47:00 +0100 (MET)
Received: from tid (tid.hi.inet [10.95.64.10])	by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 49.8B.03143.33EDBA05; Tue, 20 Nov 2012 20:46:59 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MDS007TEXMB4L@tid.hi.inet> for dmm@ietf.org; Tue, 20 Nov 2012 20:46:59 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Tue, 20 Nov 2012 20:46:59 +0100
Date: Tue, 20 Nov 2012 19:46:58 +0000
From: LUIS MIGUEL CONTRERAS MURILLO 
In-reply-to: <6E31144C030982429702B11D6746B98C36494893@SZXEML510-MBS.china.huawei.com>
X-Originating-IP: [10.95.64.115]
To: h chan 
Message-id: <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1knWBNGFEJT7EgX1sQVEqA)"
Content-language: es-ES
Accept-Language: es-ES, en-US
Thread-topic: [DMM]  Multicast PS to requirements
Thread-index: AQHNx0fiha5g/DHSTUmilRylVyhUsJfzHlCg
X-AuditID: 0a5f4068-b7f746d000000c47-6d-50abde33c14a
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXCFe/ApWt8b3WAwdGp2hb3H9U4MHosWfKT KYAxissmJTUnsyy1SN8ugSvj2eE57AWr9zNX7F+wlrWB8VAHcxcjJ4eEgIlEw8k9bBC2mMSF e+uBbC4OIYENjBIfb19ignC+MUrs2LkNrENIYBqjxL/n5SA2i4CqxKX2h4wgNpuAocSsnZNY QWxhAQOJd/M3gk3lFIiQaPh4DGqDgsSfc49ZQGwRATWJkz8mA/VycDALKEq0vxAECfMKeEsc Wz6JDcIWlPgx+R5YObNArsT9zy3MELa4xJxfE8FWMQrISqw8f5oRYqShxK/Fk9lARooIGEk8 OOEGsVVAYsme81D/ikq8fPyPFeKtBRwSTbvPMU1gFJuFZN0sJOtmIVkHYetJ3Jg6hQ3C1pZY tvA1VI2uxIx/h1iQxRcwsq9iFCtOKspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJu4wdjMt3qhxi FOBgVOLhdZi2OkCINbGsuDL3EKMkB5OSKO/Ri0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrz/ NwLleFMSK6tSi/JhUjIcHEoSvOJ3gVKCRanpqRVpmTnA5AKTZuLgBGnnAWrXB6nhLS5IzC3O TIfIn2LU5pgzs/0JI8e2T11PGIVY8vLzUqXEeT/fASoVACnNKM2Dm/aKURzobGFeU5BBPMBU CTfnFdAKJqAV8S5gK0oSEVJSDYyy6a+6ytmTVq/ckft34X7rE6sZ/d+tt1i5csGkbUyvzt0L Nj688+DKoJZS+7hw995fXK9FrDc+NJ3lGWWddL5d6kS91cZ9f7o3rP1/8N+xpotnDzP02Wzf sEljNdc01SUBOzhOT//yYtdKLjfJdw7zhA4aMU/vtzw5XZNrIr9Bv/GCx3PNm68tU2Ipzkg0 1GIuKk4EAKupiJFSAwAA
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com>  <000601cdc440$ef947f50$cebd7df0$@av.it.pt>  <"23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7"@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <50AABF7D.9020003@av.it.pt> <6E31144C030982429702B11D6746B98C36494893@SZXEML510-MBS.china.huawei.com>
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Multicast PS to requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 19:47:15 -0000

--Boundary_(ID_1knWBNGFEJT7EgX1sQVEqA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Hi Anthony,

some comments in line

Best regards,

Luis

De: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: S=E9rgio Figueiredo; dmm@ietf.org
Asunto: [DMM] Multicast PS to requirements

Let us also use another thread to check for consensus of the PS from multim=
ob.

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.

[Luis>>] This is correct if the multicast content is locally available. How=
ever this could not be always the case for multicast listeners, for a numbe=
r of reasons (for instance, conflict in the multicast address allocation be=
tween the Home Network and the DMM domain).
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

[Luis>>] This seems not to be a problem of the IP mobility solutions handli=
ng multicast traffic with mobility tunnels in general, but a problem of con=
sidering several upstream paths ending on the same mobility access router a=
s a consequence of extending tunnels from previousMAR to newMAR to forward =
the multicast traffic.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of S=E9rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.

As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should =
enable multicast services which are compatible with multicast distribution =
scenario, etc.". It seems like there is no major difference between this an=
d the "DMM solutions should enable solutions to support multicast services.=
" requirement? Aren't both expressing the need to enable multicast in a DMM=
 solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the P=
Ss you referred.  So, while 7.2 and 7.3 express the need for DMM solutions =
to allow deployment of multicast services, 7.1 concerns  "how" IP multicast=
 should be enabled in order to avoid the aforementioned PSs. The usage of t=
he word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mo=
bile host to be managed (e.g., subscribed, received and/or transmitted) usi=
ng multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn'=
t necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these pr=
oposals, let us understand what are the problems first. Two problem stateme=
nts have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. I=
n the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution sce=
nario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to s=
olve the problems PS1 and PS6 as explained in use cases already presented a=
nd discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such=
 a way that it can be extended to also support multicast traffic." I rephra=
se it to highlight the similarity with the other proposals and also changed=
 the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was "DMM solutions should support multicast services ... e=
tc. Given that it is the scope of multimob and not dmm wg to provide the mu=
lticast solution, I think "support" here means "enable" solutions to be dev=
eloped (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable mu=
lticast services. Yet the explanation in REQ7.1 seems to indicate not just =
to enable any one multicast solution but also needs the flexibility in mult=
icast solution. Not all multicast solutions are the same. Some of them resu=
lts in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distr=
ibution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with mu=
lticast distribution scenario, etc.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively sh=
ould we deploy/support multicast over distributed mobility rather than dist=
ributed mobile multicast. As a result, you can find this deployment use cas=
e and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob=
-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at man=
y access routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted fr=
om the draft described above.


REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution sc=
enarios. This flexibility enables different IP multicast flows with respect=
 to a mobile host to be managed (e.g., subscribed, received and/or transmit=
ted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via a single endpoint (e.g. regular or tunnel =
interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].



Regards,

Seil

From: pierrick.seite@orange.com [mailto:p=
ierrick.seite@orange.com]
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it=
.pt; JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterD=
igital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that m=
y
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions bu=
t
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.





_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

--Boundary_(ID_1knWBNGFEJT7EgX1sQVEqA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable










Hi Anthony,



 


some comments in line



 


Best regards,

 


Luis


 






De: dmm-bounces@ietf.org [m=
ailto:dmm-bounces@ietf.org]
En nombre de h chan

Enviado el: martes, 20 de noviembre de 2012 18:51

Para: S=E9rgio Figueiredo; dmm@ietf.org

Asunto: [DMM] Multicast PS to requirements






 


Let us also use another=
 thread to check for consensus of the PS from multimob.



 


PS1 (revised): Non-opti=
mal routes


Routing via a centra=
lized anchor often results in a longer route. The problem is especially man=
ifested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



[Luis>>]=
 This is correct if the multicast content is locally available. However thi=
s could not be always the case for multicast listeners, for a
 number of reasons (for instance, conflict in the multicast address allocat=
ion between the Home Network and the DMM domain).



PS6: Duplica=
te multicast traffic


IP multicast distributi=
on over architectures using IP mobility solutions  may lead to converg=
ence of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 =



[Luis>>] Th=
is seems not to be a problem of the IP mobility solutions handling multicas=
t traffic with mobility tunnels in general, but a problem of considering
 several upstream paths ending on the same mobility access router as a cons=
equence of extending tunnels from previousMAR to newMAR to forward the mult=
icast traffic.


 




H Anthony Chan



 






From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of S=E9rgio Figueiredo

Sent: Monday, November 19, 2012 5:24 PM

To: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.



As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should enable multicast services
 which are compatible with multicast distribution scenario, etc.&quo=
t;. It seems like there is no major difference between this and the "<=
span style=3D"font-size:11.0pt; font-family:"Calibri","sans-=
serif"; color:#1F497D">DMM solutions should enable solutions
 to support multicast services." requirement? Aren't both expre=
ssing the need to enable multicast in a DMM solution?



As you stated, "neglecting" the requirement 7.1 we proposed, lead=
s to the PSs you referred.  So, while 7.2 and 7.3 express the need for=
 DMM solutions to allow deployment of multicast services, 7.1 concerns =
; "how" IP multicast should be enabled in order to avoid
 the aforementioned PSs. The usage of the word "flexible"is expla=
ined by: 



"This flexibility enables different I=
P multicast flows with respect to a mobile host to be managed (e.g., subscr=
ibed, received and/or transmitted) using
multiple endpoints". 



In other words, compatibility with "multicast distribution scenario&qu=
ot; doesn't necessarily avoid PS1 and PS6.



Thank you and best regards,

S=E9rgio



On 11/19/2012 10:28 PM, h chan wrote:






There are 3 proposals f=
or multicast requirements. Before comparing these proposals, let us underst=
and what are the problems first. Two problem statements
 have been proposed:


 


PS1 (revised): Non-opti=
mal routes


Routing via a centra=
lized anchor often results in a longer route. The problem is especially man=
ifested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



PS6: Duplica=
te multicast traffic


IP multicast distributi=
on over architectures using IP mobility solutions  may lead to converg=
ence of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 


Then, let us see whethe=
r all the 3 REQ proposals have the same intention. In the following, I reph=
rase them to highlight their similarities.


 


REQ7.1: Flexible multic=
ast distribution


DMM solutions should be=
 compatible with flexible multicast distribution scenario. Etc.



The Motivation is to al=
low flexibility in (enable) multicast solutions to solve the problems PS1 a=
nd PS6 as explained in use cases already presented and discussed
 in multimob wg.


 


REQ7.2:



DMM solutions should en=
able solutions to support multicast traffic.



 


(Original wording was &=
quot;The DMM (unicast) solution MUST be specified in such a way that it can=
 be extended to also support multicast traffic." I rephrase it
 to highlight the similarity with the other proposals and also changed the =
must to should.)


 


REQ7.3:


DMM solutions should en=
able solutions to support multicast services.


 


Original wording was &#=
8220;DMM solutions should support multicast services … etc. Given tha=
t it is the scope of multimob and not dmm wg to provide the multicast
 solution, I think “support” here means “enable” so=
lutions to be developed (by multimob).


 


Similarity and subtle d=
ifferences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet t=
he explanation in REQ7.1 seems to indicate not just to enable
 any one multicast solution but also needs the flexibility in multicast sol=
ution. Not all multicast solutions are the same. Some of them results in PS=
1 or PS6.



 




Are there any are essen=
tial differences between:


In REQ7.1, DMM solution=
s should be compatible with flexible multicast distribution scenario, etc.



Versus


DMM solutions should en=
able multicast services which are compatible with multicast distribution sc=
enario, etc.


 


H Anthony Chan



 






From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Seil Jeon

Sent: Monday, November 19, 2012 5:15 AM

To: pierrick.seite@oran=
ge.com

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 


Hi Pierrick,


 


I’ve many times thought about your=
 question. I would say how effectively should we deploy/support multicast o=
ver distributed mobility rather than distributed mobile multicast.
 As a result, you can find this deployment use case and gap analysis at 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 p=
resented in multimob several times.


 


In unicast DMM, main innovation is to di=
stribute the anchor function at many access routers from single core. Follo=
wing architectural concept of DMM, flexible multicast distribution
 is one of multicast requirement resulted from the draft described above. <=
/span>



 


REQ8: Flexible multicast distribution


"DMM solutions SHOULD be compatible =
with flexible multicast distribution scenarios. This flexibility enables di=
fferent IP multicast flows with respect to a mobile host to be managed (e.g=
., subscribed, received and/or transmitted)
 using multiple endpoints". 



Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via
 a single endpoint (e.g. regular or tunnel interface), which would lead to =
the problems described in PS1 and PS6.


PS6: Duplicate multicast traffic


IP multicast distribu=
tion over architectures using IP mobility solutions  may lead to conve=
rgence of duplicated multicast subscriptions towards the tunnel’s dow=
nstream entity (e.g. MAG in PMIPv6).  Concretely,
 when multicast subscription for individual mobile nodes is coupled with mo=
bility tunnels, duplicate multicast subscription(s) is prone to be received=
 through different upstream paths. This problem is potentially more severe =
in a distributed mobility environment
 [draft-sfigueiredo-multimob-use-case-dmm-03].










Regards,


 


Seil


 






From:
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.=
com]


Sent: Monday, November 19, 2012 8:55 AM

To: 'karagian@cs.utwente.n=
l'; 
seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc: dmm@ietf.org

Subject: RE: [DMM] Multicast requirements






 


Hi all,


 


I tend to agree with Ge=
orgious, however I still do not figure out what is the use-case for distrib=
uted mobile multicast (other than academic considerations)?
 Can someone give concrete example? 


 


I haven’t real al=
l messages from this thread. So, maybe I missed important points.

 


BR,


Pierrick


 








De :
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.=
utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; 
JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should someh=
ow consider muticast deployment. However, I do not thnk that the DMM WG is =
the right WG to provide the multicast based DMM solution!


 


One alternative solution will be to have a mult=
icast requirement that emphasizes the need of having extensibility hooks (p=
ossibilities) that can be used later on by the multimob
 WG to provide a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like =
the following could be used for this purpose:


 


"The DMM (unicast) solution MUST be s=
pecified in such a way that it can be extended to also support multicast tr=
affic."


 


 


Best regards,


Georgios


 


 


 





Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
[mailto:dmm-bounces=
@ietf.org]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.c=
om]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; Z=
uniga, Juan
 Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mail=
man/listinfo/dmm



_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mail=
man/listinfo/dmm








____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
/pre>

a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
/pre>

France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.













_______________________________________________


dmm mailing list


dmm@ietf.org


https://www.ietf=
.org/mailman/listinfo/dmm




 









Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.

This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:

http://www.tid.es/ES/PAGINAS/disclaimer.aspx





--Boundary_(ID_1knWBNGFEJT7EgX1sQVEqA)--

From seiljeon@av.it.pt  Tue Nov 20 14:32:26 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FAC21F8828 for ; Tue, 20 Nov 2012 14:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NmxYpHoUKoc for ; Tue, 20 Nov 2012 14:32:18 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 965B021F8826 for ; Tue, 20 Nov 2012 14:32:16 -0800 (PST)
Received: from [193.120.41.115] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67083344; Tue, 20 Nov 2012 22:32:12 +0000
From: "Seil Jeon" 
To: "'LUIS MIGUEL CONTRERAS MURILLO'" 
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>		<8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com>	<61CEE523-F244-486B-AA95-591828D53EED@gmail.com>		<8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>			<500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com>	<50A69B8C.6050309@venaas.com>		<000601cdc440$ef947f50$cebd7df0$@av.it.pt>		<"23120_1353315327_ 50A9F3FF_23120_281_1_8	1C77F07008CA24F9783A98CFD706F7106F2F7"@PEXCVZYM12.corporate.adroot.infra.ftgroup>	<008801cdc647$16916f20$43b44d60$@av.it.pt> <50AABF7D.9020003@av.it.pt>	<6E31144C030982429702B11D6746B98C3649 4893@SZXEML510-MBS.chi na.huawei.com> <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet>
In-Reply-To: <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet>
Date: Tue, 20 Nov 2012 22:32:27 -0000
Message-ID: <00b001cdc76e$ee15d2b0$ca417810$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01CDC76E.EE28E580"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDpvfVQJP8hzaX/j8eL/mEb+S6VGQKzakk+AzgCKvoCgJ8m1gIjGWtvALCdEYQBrFzTkgFltscyAjuXYlACWD2t5QIE5aJOAhnSo6wCCwj1LQKx6r6UAkS4dAsB8a5iawJ9PXG5Apc4xYGYkvOIMA==
Content-Language: ko
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast PS to requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 22:32:27 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00B1_01CDC76E.EE28E580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Luis,

=20

See inline, please.

=20

Regards,

=20

Seil

=20

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
LUIS
MIGUEL CONTRERAS MURILLO
Sent: Tuesday, November 20, 2012 7:47 PM
To: h chan
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast PS to requirements

=20

Hi Anthony,=20

=20

some comments in line=20

=20

Best regards,

=20

Luis

=20

De: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] En nombre de h =
chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: S=E9rgio Figueiredo; dmm@ietf.org
Asunto: [DMM] Multicast PS to requirements

=20

Let us also use another thread to check for consensus of the PS from
multimob.=20

=20

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The
problem is especially manifested when accessing a local server or =
servers of
a Content Delivery Network (CDN), or when receiving / sending IP =
multicast
packets.=20

[Luis>>] This is correct if the multicast content is locally available.
However this could not be always the case for multicast listeners, for a
number of reasons (for instance, conflict in the multicast address
allocation between the Home Network and the DMM domain).=20

=20

>> I think you seem talking the opposite case. When all IP multicast is =
used
locally regardless of IP mobility tunnel, it might avoid the PS1.

=20

PS6: Duplicate multicast traffic

IP multicast distribution over architectures using IP mobility solutions
may lead to convergence of duplicated multicast subscriptions towards =
the
tunnel=92s downstream entity (e.g. MAG in PMIPv6).  Concretely, when =
multicast
subscription for individual mobile nodes is coupled with mobility =
tunnels,
duplicate multicast subscription(s) is prone to be received through
different upstream paths. This problem is potentially more severe in a
distributed mobility environment
[draft-sfigueiredo-multimob-use-case-dmm-03].

=20

[Luis>>] This seems not to be a problem of the IP mobility solutions
handling multicast traffic with mobility tunnels in general, but a =
problem
of considering several upstream paths ending on the same mobility access
router as a consequence of extending tunnels from previousMAR to newMAR =
to
forward the multicast traffic.

=20

>> Thanks to clarifying the issue correctly. Let me rephrase this again =
as
following,

=20

=93IP multicast distribution over architectures making mobility tunnel
endpoint towards an MN terminated on access router may lead to =85=94

=20

=20

=20

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
S=E9rgio
Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

=20

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with =
your
analysis.

As for the question you posed, first I would like to exactly understand =
what
you mean with "multicast distribution scenario" in "DMM solutions should
enable multicast services which are compatible with multicast =
distribution
scenario, etc.". It seems like there is no major difference between this =
and
the "DMM solutions should enable solutions to support multicast =
services."
requirement? Aren't both expressing the need to enable multicast in a =
DMM
solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to =
the
PSs you referred.  So, while 7.2 and 7.3 express the need for DMM =
solutions
to allow deployment of multicast services, 7.1 concerns  "how" IP =
multicast
should be enabled in order to avoid the aforementioned PSs. The usage of =
the
word "flexible"is explained by:=20

"This flexibility enables different IP multicast flows with respect to a
mobile host to be managed (e.g., subscribed, received and/or =
transmitted)
using multiple endpoints".=20

In other words, compatibility with "multicast distribution scenario" =
doesn't
necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:

There are 3 proposals for multicast requirements. Before comparing these
proposals, let us understand what are the problems first. Two problem
statements have been proposed:

=20

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The
problem is especially manifested when accessing a local server or =
servers of
a Content Delivery Network (CDN), or when receiving / sending IP =
multicast
packets.=20

PS6: Duplicate multicast traffic

IP multicast distribution over architectures using IP mobility solutions
may lead to convergence of duplicated multicast subscriptions towards =
the
tunnel=92s downstream entity (e.g. MAG in PMIPv6).  Concretely, when =
multicast
subscription for individual mobile nodes is coupled with mobility =
tunnels,
duplicate multicast subscription(s) is prone to be received through
different upstream paths. This problem is potentially more severe in a
distributed mobility environment
[draft-sfigueiredo-multimob-use-case-dmm-03].

=20

Then, let us see whether all the 3 REQ proposals have the same =
intention. In
the following, I rephrase them to highlight their similarities.

=20

REQ7.1: Flexible multicast distribution

DMM solutions should be compatible with flexible multicast distribution
scenario. Etc.=20

The Motivation is to allow flexibility in (enable) multicast solutions =
to
solve the problems PS1 and PS6 as explained in use cases already =
presented
and discussed in multimob wg.

=20

REQ7.2:=20

DMM solutions should enable solutions to support multicast traffic.=20

=20

(Original wording was "The DMM (unicast) solution MUST be specified in =
such
a way that it can be extended to also support multicast traffic." I =
rephrase
it to highlight the similarity with the other proposals and also changed =
the
must to should.)

=20

REQ7.3:

DMM solutions should enable solutions to support multicast services.

=20

Original wording was =93DMM solutions should support multicast services =
=85 etc.
Given that it is the scope of multimob and not dmm wg to provide the
multicast solution, I think =93support=94 here means =93enable=94 =
solutions to be
developed (by multimob).

=20

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable
multicast services. Yet the explanation in REQ7.1 seems to indicate not =
just
to enable any one multicast solution but also needs the flexibility in
multicast solution. Not all multicast solutions are the same. Some of =
them
results in PS1 or PS6.=20

=20

Are there any are essential differences between:

In REQ7.1, DMM solutions should be compatible with flexible multicast
distribution scenario, etc.=20

Versus

DMM solutions should enable multicast services which are compatible with
multicast distribution scenario, etc.

=20

H Anthony Chan

=20

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Seil
Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

=20

Hi Pierrick,

=20

I=92ve many times thought about your question. I would say how =
effectively
should we deploy/support multicast over distributed mobility rather than
distributed mobile multicast. As a result, you can find this deployment =
use
case and gap analysis at
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
presented in multimob several times.

=20

In unicast DMM, main innovation is to distribute the anchor function at =
many
access routers from single core. Following architectural concept of DMM,
flexible multicast distribution is one of multicast requirement resulted
from the draft described above.=20

=20

REQ8: Flexible multicast distribution

"DMM solutions SHOULD be compatible with flexible multicast distribution
scenarios. This flexibility enables different IP multicast flows with
respect to a mobile host to be managed (e.g., subscribed, received =
and/or
transmitted) using multiple endpoints".=20

Motivation: The motivation for this requirement is to enable flexibility =
in
multicast distribution. The multicast solution may therefore avoid =
having
multicast-capable access routers being restricted to manage all IP =
multicast
traffic relative to a host via a single endpoint (e.g. regular or tunnel
interface), which would lead to the problems described in PS1 and PS6.

PS6: Duplicate multicast traffic

IP multicast distribution over architectures using IP mobility solutions
may lead to convergence of duplicated multicast subscriptions towards =
the
tunnel=92s downstream entity (e.g. MAG in PMIPv6).  Concretely, when =
multicast
subscription for individual mobile nodes is coupled with mobility =
tunnels,
duplicate multicast subscription(s) is prone to be received through
different upstream paths. This problem is potentially more severe in a
distributed mobility environment
[draft-sfigueiredo-multimob-use-case-dmm-03].




Regards,

=20

Seil

=20

From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com]=20
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it.pt;
JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

=20

Hi all,

=20

I tend to agree with Georgious, however I still do not figure out what =
is
the use-case for distributed mobile multicast (other than academic
considerations)? Can someone give concrete example?=20

=20

I haven=92t real all messages from this thread. So, maybe I missed =
important
points.

=20

BR,

Pierrick

=20

De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de
karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements

=20

Hi all,

=20

I also agree that the DMM solution should somehow consider muticast
deployment. However, I do not thnk that the DMM WG is the right WG to
provide the multicast based DMM solution!

=20

One alternative solution will be to have a multicast requirement that
emphasizes the need of having extensibility hooks (possibilities) that =
can
be used later on by the multimob WG to provide a=20

a multicast enabled DMM solution!

=20

=20

So a requirement that specifies something like the following could be =
used
for this purpose:

=20

"The DMM (unicast) solution MUST be specified in such a way that it can =
be
extended to also support multicast traffic."

=20

=20

Best regards,

Georgios

=20

=20

=20


  _____ =20


Van:   dmm-bounces@ietf.org
[dmm-bounces@ietf.org] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc:   dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements

Hi Juan,

I've been looked at changed flow of your proposed text but sorry now =
that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's =
description,
it seems quite reasonable at the first step, not giving any restrictions =
but
leaving some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From:   dmm-bounces@ietf.org [
 mailto:dmm-bounces@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas;   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [  mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc:   sarikaya@ieee.org; Zuniga, Juan =
Carlos;
Konstantinos Pentikousis;=20
> Peter McCann;   dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>=20
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are=20
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an=20
> explanation MUST be provided."
>=20
> This sounds good to me.
>=20
> The main thing I want to achieve is what was describes as motivation=20
> earlier in this thread. Multicast should at least be considered when=20
> looking into DMM solutions, and not just an afterthought once the=20
> solution is decided.
>=20
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed =
text.

Regards,

Juan Carlos
=20
>=20
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a=20
> hint to a developer where to head to. That is the level I would expect =

> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
  dmm@ietf.org
 
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
  dmm@ietf.org
 
https://www.ietf.org/mailman/listinfo/dmm

_________________________________________________________________________=
___
_____________________________________________
=20
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
=20
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for =
messages
that have been modified, changed or falsified.
Thank you.






_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

=20

=20

  _____ =20


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en =
el enlace
situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx


------=_NextPart_000_00B1_01CDC76E.EE28E580
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Luis,
 
See inline, please.
 
Regards,
 
Seil
 
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, November 20, =
2012 7:47 PM
To: h chan
Cc: =
dmm@ietf.org
Subject: Re: [DMM] Multicast PS to =
requirements
 
Hi Anthony, 
 
some comments in line 
 
Best regards,
 
Luis
 
De: dmm-bounces@ietf.org =
[mailto:dmm-bounces@ietf.org] =
En nombre de h chan
Enviado el: martes, 20 de noviembre =
de 2012 18:51
Para: S=E9rgio Figueiredo; dmm@ietf.org
Asunto: [DMM] =
Multicast PS to requirements
 
Let us also use another thread to check for consensus of the PS from =
multimob. 
 
PS1 (revised): Non-optimal routes
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / =
sending IP multicast packets. 
[Luis>>] This is correct if the multicast content is locally =
available. However this could not be always the case for multicast =
listeners, for a number of reasons (for instance, conflict in the =
multicast address allocation between the Home Network and the DMM =
domain). 
 
>> I think you seem talking the opposite case. When all IP =
multicast is used locally regardless of IP mobility tunnel, it might =
avoid the PS1.
 
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel’s downstream entity (e.g. MAG in =
PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].
 
[Luis>>] This seems not to be a problem of the IP mobility =
solutions handling multicast traffic with mobility tunnels in general, =
but a problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast =
traffic.
 
>> Thanks to clarifying the issue correctly. Let me rephrase =
this again as following,
 
“IP multicast distribution over architectures making mobility =
tunnel endpoint towards an MN terminated on access router may lead to =
…”
 
 
 
From: dmm-bounces@ietf.org =
[mailto:dmm-bounces@ietf.org] =
On Behalf Of S=E9rgio Figueiredo
Sent: Monday, November =
19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: =
[DMM] Multicast requirements
 
Hi =
Anthony,

Thank you for trying to progress on this matter. I =
mostly agree with your analysis.

As for the question you posed, =
first I would like to exactly understand what you mean with =
"multicast distribution scenario" in "DMM solutions should enable multicast services which are compatible =
with multicast distribution scenario, etc.". It seems like =
there is no major difference between this and the "DMM solutions should enable solutions to support multicast =
services." requirement? Aren't both expressing the need to =
enable multicast in a DMM solution?

As you stated, =
"neglecting" the requirement 7.1 we proposed, leads to the PSs =
you referred.  So, while 7.2 and 7.3 express the need for DMM =
solutions to allow deployment of multicast services, 7.1 concerns  =
"how" IP multicast should be enabled in order to avoid the =
aforementioned PSs. The usage of the word "flexible"is =
explained by: 

"This =
flexibility enables different IP multicast flows with respect to a =
mobile host to be managed (e.g., subscribed, received and/or =
transmitted) using multiple endpoints". 

In other =
words, compatibility with "multicast distribution scenario" =
doesn't necessarily avoid PS1 and PS6.

Thank you and best =
regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan =
wrote:
There are 3 proposals for multicast requirements. Before comparing =
these proposals, let us understand what are the problems first. Two =
problem statements have been proposed:
 
PS1 (revised): Non-optimal routes
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / =
sending IP multicast packets. 
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel’s downstream entity (e.g. MAG in =
PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].
 
Then, let us see whether all the 3 REQ proposals have the same =
intention. In the following, I rephrase them to highlight their =
similarities.
 
REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast =
distribution scenario. Etc. 
The Motivation is to allow flexibility in (enable) multicast =
solutions to solve the problems PS1 and PS6 as explained in use cases =
already presented and discussed in multimob wg.
 
REQ7.2: 
DMM solutions should enable solutions to support multicast traffic. =

 
(Original wording was "The DMM (unicast) solution MUST be =
specified in such a way that it can be extended to also support =
multicast traffic." I rephrase it to highlight the similarity with =
the other proposals and also changed the must to =
should.)
 
REQ7.3:
DMM solutions should enable solutions to support multicast =
services.
 
Original wording was “DMM solutions should support multicast =
services … etc. Given that it is the scope of multimob and not dmm =
wg to provide the multicast solution, I think “support” here =
means “enable” solutions to be developed (by =
multimob).
 
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to =
enable multicast services. Yet the explanation in REQ7.1 seems to =
indicate not just to enable any one multicast solution but also needs =
the flexibility in multicast solution. Not all multicast solutions are =
the same. Some of them results in PS1 or PS6. 
 
Are there any are essential differences =
between:
In REQ7.1, DMM solutions should be compatible with flexible multicast =
distribution scenario, etc. 
Versus
DMM solutions should enable multicast services which are compatible =
with multicast distribution scenario, etc.
 
H Anthony Chan
 
From:=
 =
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] =
On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 =
5:15 AM
To: pierrick.seite@orange.comCc: dmm@ietf.org
Subject: Re: =
[DMM] Multicast requirements
 
Hi =
Pierrick,
 =

I’ve =
many times thought about your question. I would say how effectively =
should we deploy/support multicast over distributed mobility rather than =
distributed mobile multicast. As a result, you can find this deployment =
use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-=
03 presented in multimob several times.
 =

In unicast =
DMM, main innovation is to distribute the anchor function at many access =
routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted =
from the draft described above. 
 =

REQ8: Flexible multicast =
distribution
"DMM solutions =
SHOULD be compatible with flexible multicast distribution scenarios. =
This flexibility enables different IP multicast flows with respect to a =
mobile host to be managed (e.g., subscribed, received and/or =
transmitted) using multiple endpoints". 

Motivation: The =
motivation for this requirement is to enable flexibility in multicast =
distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP =
multicast traffic relative to a host via a single endpoint (e.g. regular =
or tunnel interface), which would lead to the problems described in PS1 =
and PS6.
PS6: Duplicate multicast =
traffic
IP multicast distribution over =
architectures using IP mobility solutions  may lead to convergence =
of duplicated multicast subscriptions towards the tunnel’s =
downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility =
tunnels, duplicate multicast subscription(s) is prone to be received =
through different upstream paths. This problem is potentially more =
severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].


<=
p class=3DMsoNormal>Regards,
 =

Seil
 =

From:=
 =
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.co=
m] 
Sent: Monday, November 19, 2012 8:55 AM
To: =
'karagian@cs.utwente.nl'; =
seiljeon@av.it.pt; JuanCarlos.Zuniga@Inte=
rDigital.com
Cc: dmm@ietf.org
Subject: RE: =
[DMM] Multicast requirements
 
Hi all,
 
I tend to agree with Georgious, however I still do not figure out =
what is the use-case for distributed mobile multicast (other than =
academic considerations)? Can someone give concrete example? =

 
I haven’t real all messages from this thread. So, maybe I =
missed important points.
 
BR,
Pierrick
 
De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] =
De la part de karagian@cs.utwente.nl
E=
nvoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@Inte=
rDigital.com
Cc : dmm@ietf.org
Objet : Re: =
[DMM] Multicast requirements
 
Hi =
all,
 
I also =
agree that the DMM solution should somehow consider muticast deployment. =
However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!
 
One =
alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a =

a multicast =
enabled DMM solution!
 
 
So a =
requirement that specifies something like the following could be used =
for this purpose:
 
"The =
DMM (unicast) solution MUST be specified in such a way that it can =
be extended to also support multicast =
traffic."
 
 
Best =
regards,
Georgios
 
 
 
Van:<=
/b> =
dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens =
Seil Jeon [seiljeon@av.it.pt]
Verzonden:=
 vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan =
Carlos'
Cc: dmm@ietf.org
Onder=
werp: Re: [DMM] Multicast =
requirements
Hi =
Juan,

I've been looked at changed flow of your proposed text but =
sorry now that my
comment is posted.
At first time, I couldn't =
make sure however, on hearing Stig's description,
it seems quite =
reasonable at the first step, not giving any restrictions but
leaving =
some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the =
DMM solution to
support multicast.
So I think additional =
requirements need to be made for the DMM solution,
accordingly. But =
of course, this should not also give any specific
limitation and =
restriction but should be made towards the direction not
limiting the =
benefits provided by distributed deployment.

I hope to get more =
comments on this.

Regards,
=

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf =
Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 =
PM
To: Stig Venaas; dmm@ietf.org
Subject:=
 Re: [DMM] Multicast requirements


> -----Original =
Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> =
Sent: Friday, November 16, 2012 3:01 PM
> To: jouni =
korhonen
> Cc: sarikaya@ieee.org; Zuniga, =
Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann; =
dmm@ietf.org
> =
Subject: Re: [DMM] Multicast requirements
> 
> On 11/15/2012 =
3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, =
2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> =
>>
> >> I think we are reading too much into multicast =
and unicast should
be
> >> designed in an integrated =
manner.
> =
>>
> >> The fact is that multicast is considered as an =
area of
> specialization,
> >> it requires knowledge =
of very different protocols than we are 
> >> accustomed to =
in mobility.
> >
> > "Requirement: DMM solutions =
SHOULD support multicast services. If a
> specific DMM solution =
does not support multicast services, an 
> explanation MUST be =
provided."
> 
> This sounds good to me.
> =

> The main thing I want to achieve is what was describes as =
motivation 
> earlier in this thread. Multicast should at least be =
considered when 
> looking into DMM solutions, and not just an =
afterthought once the 
> solution is decided.
> 
> =
Stig

[JCZ] I fully agree with this. That was the intention of the =
proposed text.

Regards,

Juan Carlos
 
> =

> > To me that reads basically "do not break foundations =
for multicast
> unless you have a valid & documented reason =
for it".  If we look e.g.
> into RFC625 multicast =
wording that is there very briefly but gives a 
> hint to a =
developer where to head to. That is the level I would expect 
> =
DMM documents should aim to.
> >
> > - Jouni
> =
>
> >
> >> Let dmm deal with its current charter =
that does not include a word
> of
> >> multicast and =
if everything goes well we can come back and discuss
> dmm
> =
>> multicast.
> =
>>
> >> Regards,
> >>
> >> =
Behcet

_______________________________________________
dmm =
mailing list
dmm@ietf.org
<=
span lang=3DFR =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>https://www.ietf.org/mailman/listinfo/dmm<=
span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>

____=
___________________________________________
dmm mailing =
list
dmm@ietf.org
<=
span lang=3DFR =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>https://www.ietf.org/mailman/listinfo/dmm<=
o:p>
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
France Telecom =
- Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, France Telecom - Orange is not =
liable for messages that have been modified, changed or =
falsified.
Thank =
you.



__________=
_____________________________________
dmm mailing =
list
dmm@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dmm
 
 
Este mensaje se dirige exclusivamente a su destinatario. Puede =
consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo =
electr=F3nico en el enlace situado m=E1s abajo.
This message is =
intended exclusively for its addressee. We only send and receive email =
on the basis of the terms set out at:
http://www.tid.es/E=
S/PAGINAS/disclaimer.aspx

------=_NextPart_000_00B1_01CDC76E.EE28E580--


From sfigueiredo@av.it.pt  Tue Nov 20 15:21:28 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F14221F87E1 for ; Tue, 20 Nov 2012 15:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psVBpxNl-ssN for ; Tue, 20 Nov 2012 15:21:19 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id A221E21F87F4 for ; Tue, 20 Nov 2012 15:21:18 -0800 (PST)
Received: from [217.129.25.167] (account sfigueiredo@av.it.pt HELO [192.168.0.101]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 67083645 for dmm@ietf.org; Tue, 20 Nov 2012 23:21:16 +0000
Message-ID: <50AC1070.4040408@av.it.pt>
Date: Tue, 20 Nov 2012 23:21:20 +0000
From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: dmm@ietf.org
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com>  <000601cdc440$ef947f50$cebd7df0$@av.it.pt>  <"23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7"@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <50AABF7D.9020003@av.it.pt> <6E31144C030982429702B11D6746B98C36494893@SZXEML510-MBS.china.huawei.com> <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet>
In-Reply-To: <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet>
Content-Type: multipart/alternative; boundary="------------040909050409070104000404"
Subject: Re: [DMM] Multicast PS to requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 23:21:28 -0000

This is a multi-part message in MIME format.
--------------040909050409070104000404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Luis,

A few more comments on this inline:

Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
>
> Hi Anthony,
>
> some comments in line
>
> Best regards,
>
> Luis
>
> *De:*dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] *En nombre de 
> *h chan
> *Enviado el:* martes, 20 de noviembre de 2012 18:51
> *Para:* Sérgio Figueiredo; dmm@ietf.org
> *Asunto:* [DMM] Multicast PS to requirements
>
> Let us also use another thread to check for consensus of the PS from 
> multimob.
>
> PS1 (revised): Non-optimal routes
>
> Routing via a centralized anchor often results in a longer route. The 
> problem is especially manifested when accessing a local server or 
> servers of a Content Delivery Network (CDN), *or when receiving / 
> sending IP multicast packets*.
>
> */[Luis>>] This is correct if the multicast content is locally 
> available. However this could not be always the case for multicast 
> listeners, for a number of reasons (for instance, conflict in the 
> multicast address allocation between the Home Network and the DMM 
> domain). /*
>
[SF] Sure, and the same applies to "accessing a local server a CDN" - it 
is implicit that the content is locally available. But it can be 
improved as "when receiving locally available IP multicast or sending IP 
multicast".

> PS6: Duplicate multicast traffic
>
> IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel's downstream entity (e.g. MAG in 
> PMIPv6).  Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
> *//*
>
> */[Luis>>] This seems not to be a problem of the IP mobility solutions 
> handling multicast traffic with mobility tunnels in general, but a 
> problem of considering several upstream paths ending on the same 
> mobility access router as a consequence of extending tunnels from 
> previousMAR to newMAR to forward the multicast traffic./*
>
[SF] Exactly. Which is more than likely to happen in a DMM solution, 
where all "mobility entities" may act as "mobility access routers", and, 
after mobility, we want to take advantage of the tunnel for the 
subscription. In those cases, care must be taken in order to not greatly 
magnify convergence problem observed e.g. in RFC6224.

Regards,
Sérgio

> H Anthony Chan
>
> *From:*dmm-bounces@ietf.org  
> [mailto:dmm-bounces@ietf.org] *On Behalf Of *Sérgio Figueiredo
> *Sent:* Monday, November 19, 2012 5:24 PM
> *To:* dmm@ietf.org 
> *Subject:* Re: [DMM] Multicast requirements
>
> Hi Anthony,
>
> Thank you for trying to progress on this matter. I mostly agree with 
> your analysis.
>
> As for the question you posed, first I would like to exactly 
> understand what you mean with "multicast distribution scenario" in 
> "DMM solutions should enable multicast services which are compatible 
> with multicast distribution scenario, etc.". It seems like there is no 
> major difference between this and the "DMM solutions should enable 
> solutions to support multicast services." requirement? Aren't both 
> expressing the need to enable multicast in a DMM solution?
>
> As you stated, "neglecting" the requirement 7.1 we proposed, leads to 
> the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 
> solutions to allow deployment of multicast services, 7.1 concerns  
> "how" IP multicast should be enabled in order to avoid the 
> aforementioned PSs. The usage of the word "flexible"is explained by:
>
> "This flexibility enables different IP multicast flows with respect to 
> a mobile host to be managed (e.g., subscribed, received and/or 
> transmitted) using multiple endpoints".
>
> In other words, compatibility with "multicast distribution scenario" 
> doesn't necessarily avoid PS1 and PS6.
>
> Thank you and best regards,
> Sérgio
>
> On 11/19/2012 10:28 PM, h chan wrote:
>
>     There are 3 proposals for multicast requirements. Before comparing
>     these proposals, let us understand what are the problems first.
>     Two problem statements have been proposed:
>
>     PS1 (revised): Non-optimal routes
>
>     Routing via a centralized anchor often results in a longer route.
>     The problem is especially manifested when accessing a local server
>     or servers of a Content Delivery Network (CDN), *or when receiving
>     / sending IP multicast packets*.
>
>     PS6: Duplicate multicast traffic
>
>     IP multicast distribution over architectures using IP mobility
>     solutions  may lead to convergence of duplicated multicast
>     subscriptions towards the tunnel's downstream entity (e.g. MAG in
>     PMIPv6). Concretely, when multicast subscription for individual
>     mobile nodes is coupled with mobility tunnels, duplicate multicast
>     subscription(s) is prone to be received through different upstream
>     paths. This problem is potentially more severe in a distributed
>     mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>     Then, let us see whether all the 3 REQ proposals have the same
>     intention. In the following, I rephrase them to highlight their
>     similarities.
>
>     REQ7.1: Flexible multicast distribution
>
>     DMM solutions should be compatible with flexible multicast
>     distribution scenario. Etc.
>
>     The Motivation is to allow flexibility in (enable) multicast
>     solutions to solve the problems PS1 and PS6 as explained in use
>     cases already presented and discussed in multimob wg.
>
>     REQ7.2:
>
>     DMM solutions should enable solutions to support multicast traffic.
>
>     (Original wording was "The DMM (unicast) solution MUST be
>     specified in such a way that it can be extended to also support
>     multicast traffic." I rephrase it to highlight the similarity with
>     the other proposals and also changed the must to should.)
>
>     REQ7.3:
>
>     DMM solutions should enable solutions to support multicast services.
>
>     Original wording was "DMM solutions should support multicast
>     services ... etc. Given that it is the scope of multimob and not
>     dmm wg to provide the multicast solution, I think "support" here
>     means "enable" solutions to be developed (by multimob).
>
>     Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to
>     enable multicast services. Yet the explanation in REQ7.1 seems to
>     indicate not just to enable any one multicast solution but also
>     needs the flexibility in multicast solution. Not all multicast
>     solutions are the same. Some of them results in PS1 or PS6.
>
>     Are there any are essential differences between:
>
>     In REQ7.1, DMM solutions should be compatible with flexible
>     multicast distribution scenario, etc.
>
>     Versus
>
>     DMM solutions should enable multicast services which are
>     compatible with multicast distribution scenario, etc.
>
>     H Anthony Chan
>
>     *From:*dmm-bounces@ietf.org 
>     [mailto:dmm-bounces@ietf.org] *On Behalf Of *Seil Jeon
>     *Sent:* Monday, November 19, 2012 5:15 AM
>     *To:* pierrick.seite@orange.com 
>     *Cc:* dmm@ietf.org 
>     *Subject:* Re: [DMM] Multicast requirements
>
>     Hi Pierrick,
>
>     I've many times thought about your question. I would say how
>     effectively should we deploy/support multicast over distributed
>     mobility rather than distributed mobile multicast. As a result,
>     you can find this deployment use case and gap analysis at
>     http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
>     presented in multimob several times.
>
>     In unicast DMM, main innovation is to distribute the anchor
>     function at many access routers from single core. Following
>     architectural concept of DMM, flexible multicast distribution is
>     one of multicast requirement resulted from the draft described above.
>
>     REQ8: Flexible multicast distribution
>
>     "DMM solutions SHOULD be compatible with flexible multicast
>     distribution scenarios. This flexibility enables different IP
>     multicast flows with respect to a mobile host to be managed (e.g.,
>     subscribed, received and/or transmitted) using multiple endpoints".
>
>     Motivation: The motivation for this requirement is to enable
>     flexibility in multicast distribution. The multicast solution may
>     therefore avoid having multicast-capable access routers being
>     restricted to manage all IP multicast traffic relative to a host
>     via a single endpoint (e.g. regular or tunnel interface), which
>     would lead to the problems described in PS1 and PS6.
>
>     PS6: Duplicate multicast traffic
>
>     IP multicast distribution over architectures using IP mobility
>     solutions may lead to convergence of duplicated multicast
>     subscriptions towards the tunnel's downstream entity (e.g. MAG in
>     PMIPv6).  Concretely, when multicast subscription for individual
>     mobile nodes is coupled with mobility tunnels, duplicate multicast
>     subscription(s) is prone to be received through different upstream
>     paths. This problem is potentially more severe in a distributed
>     mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>
>
>     Regards,
>
>     Seil
>
>     *From:*pierrick.seite@orange.com
>      [mailto:pierrick.seite@orange.com]
>     *Sent:* Monday, November 19, 2012 8:55 AM
>     *To:* 'karagian@cs.utwente.nl ';
>     seiljeon@av.it.pt ;
>     JuanCarlos.Zuniga@InterDigital.com
>     
>     *Cc:* dmm@ietf.org 
>     *Subject:* RE: [DMM] Multicast requirements
>
>     Hi all,
>
>     I tend to agree with Georgious, however I still do not figure out
>     what is the use-case for distributed mobile multicast (other than
>     academic considerations)? Can someone give concrete example?
>
>     I haven't real all messages from this thread. So, maybe I missed
>     important points.
>
>     BR,
>
>     Pierrick
>
>     *De :*dmm-bounces@ietf.org 
>     [mailto:dmm-bounces@ietf.org] *De la part de*
>     karagian@cs.utwente.nl 
>     *Envoyé :* samedi 17 novembre 2012 13:01
>     *À :* seiljeon@av.it.pt ;
>     JuanCarlos.Zuniga@InterDigital.com
>     
>     *Cc :* dmm@ietf.org 
>     *Objet :* Re: [DMM] Multicast requirements
>
>     Hi all,
>
>     I also agree that the DMM solution should somehow consider
>     muticast deployment. However, I do not thnk that the DMM WG is the
>     right WG to provide the multicast based DMM solution!
>
>     One alternative solution will be to have a multicast requirement
>     that emphasizes the need of having extensibility hooks
>     (possibilities) that can be used later on by the multimob WG to
>     provide a
>
>     a multicast enabled DMM solution!
>
>     So a requirement that specifies something like the following could
>     be used for this purpose:
>
>     "The DMM (unicast) solution MUST be specified in such a way that
>     it can be extended to also support multicast traffic."
>
>     Best regards,
>
>     Georgios
>
>     ------------------------------------------------------------------------
>
>     *Van:*dmm-bounces@ietf.org
>     [dmm-bounces@ietf.org
>     ] namens Seil Jeon [seiljeon@av.it.pt
>     ]
>     *Verzonden:* vrijdag 16 november 2012 22:25
>     *To:* 'Zuniga, Juan Carlos'
>     *Cc:* dmm@ietf.org 
>     *Onderwerp:* Re: [DMM] Multicast requirements
>
>     Hi Juan,
>
>     I've been looked at changed flow of your proposed text but sorry
>     now that my
>     comment is posted.
>     At first time, I couldn't make sure however, on hearing Stig's
>     description,
>     it seems quite reasonable at the first step, not giving any
>     restrictions but
>     leaving some-specific for the DMM solution it does not support
>     multicast.
>
>     On the other hand, it remains at a basic stage for the DMM solution to
>     support multicast.
>     So I think additional requirements need to be made for the DMM
>     solution,
>     accordingly. But of course, this should not also give any specific
>     limitation and restriction but should be made towards the
>     direction not
>     limiting the benefits provided by distributed deployment.
>
>     I hope to get more comments on this.
>
>     Regards,
>
>     Seil
>
>
>     -----Original Message-----
>     From: dmm-bounces@ietf.org 
>     [mailto:dmm-bounces@ietf.org] On Behalf Of
>     Zuniga, Juan Carlos
>     Sent: Friday, November 16, 2012 8:14 PM
>     To: Stig Venaas; dmm@ietf.org 
>     Subject: Re: [DMM] Multicast requirements
>
>
>     > -----Original Message-----
>     > From: Stig Venaas [mailto:stig@venaas.com]
>     > Sent: Friday, November 16, 2012 3:01 PM
>     > To: jouni korhonen
>     > Cc: sarikaya@ieee.org ; Zuniga, Juan
>     Carlos; Konstantinos Pentikousis;
>     > Peter McCann; dmm@ietf.org 
>     > Subject: Re: [DMM] Multicast requirements
>     >
>     > On 11/15/2012 3:17 AM, jouni korhonen wrote:
>     > >
>     > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
>     > >
>     > >>
>     > >> I think we are reading too much into multicast and unicast should
>     be
>     > >> designed in an integrated manner.
>     > >>
>     > >> The fact is that multicast is considered as an area of
>     > specialization,
>     > >> it requires knowledge of very different protocols than we are
>     > >> accustomed to in mobility.
>     > >
>     > > "Requirement: DMM solutions SHOULD support multicast services.
>     If a
>     > specific DMM solution does not support multicast services, an
>     > explanation MUST be provided."
>     >
>     > This sounds good to me.
>     >
>     > The main thing I want to achieve is what was describes as
>     motivation
>     > earlier in this thread. Multicast should at least be considered
>     when
>     > looking into DMM solutions, and not just an afterthought once the
>     > solution is decided.
>     >
>     > Stig
>
>     [JCZ] I fully agree with this. That was the intention of the
>     proposed text.
>
>     Regards,
>
>     Juan Carlos
>
>     >
>     > > To me that reads basically "do not break foundations for multicast
>     > unless you have a valid & documented reason for it".  If we look
>     e.g.
>     > into RFC625 multicast wording that is there very briefly but
>     gives a
>     > hint to a developer where to head to. That is the level I would
>     expect
>     > DMM documents should aim to.
>     > >
>     > > - Jouni
>     > >
>     > >
>     > >> Let dmm deal with its current charter that does not include a
>     word
>     > of
>     > >> multicast and if everything goes well we can come back and
>     discuss
>     > dmm
>     > >> multicast.
>     > >>
>     > >> Regards,
>     > >>
>     > >> Behcet
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dmm
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dmm
>
>     _________________________________________________________________________________________________________________________
>
>       
>
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
>     France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>       
>
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>
>     they should not be distributed, used or copied without authorisation.
>
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>
>     As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
>
>     Thank you.
>
>
>
>
>
>     _______________________________________________
>
>     dmm mailing list
>
>     dmm@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/dmm
>
>
> ------------------------------------------------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


--------------040909050409070104000404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Luis,

      

      A few more comments on this inline:

      

      Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:

    

    

      
      
      

        
Hi Anthony,
          

        
 

        
some comments in line
          

        
 

        
Best regards,

        
 

        
Luis

        
 

        

          

            
De: dmm-bounces@ietf.org
                [mailto:dmm-bounces@ietf.org]
                En nombre de h chan

                Enviado el: martes, 20 de noviembre de 2012 18:51

                Para: Sérgio Figueiredo; dmm@ietf.org

                Asunto: [DMM] Multicast PS to requirements

          

        

        
 

        
Let us also use another thread to check for
            consensus of the PS from multimob.
          

        
 

        
PS1 (revised): Non-optimal routes

        
Routing via a centralized anchor often
            results in a longer route. The problem is especially
            manifested when accessing a local server or servers of a
            Content Delivery Network (CDN), or when receiving /
              sending IP multicast packets.
          

        
[Luis>>] This is correct if the
                multicast content is locally available. However this
                could not be always the case for multicast listeners,
                for a number of reasons (for instance, conflict in the
                multicast address allocation between the Home Network
                and the DMM domain).
              

      

    

    [SF] Sure, and the same applies to "accessing a local server a CDN"
    - it is implicit that the content is locally available. But it can
    be improved as "when receiving locally available IP multicast or
    sending IP multicast".

    

    

      

        

        
PS6: Duplicate multicast traffic

        
IP multicast distribution over architectures
            using IP mobility solutions  may lead to convergence of
            duplicated multicast subscriptions towards the tunnel’s
            downstream entity (e.g. MAG in PMIPv6).  Concretely, when
            multicast subscription for individual mobile nodes is
            coupled with mobility tunnels, duplicate multicast
            subscription(s) is prone to be received through different
            upstream paths. This problem is potentially more severe in a
            distributed mobility environment
            [draft-sfigueiredo-multimob-use-case-dmm-03].

        
 

        
[Luis>>] This seems not to be a
                problem of the IP mobility solutions handling multicast
                traffic with mobility tunnels in general, but a problem
                of considering several upstream paths ending on the same
                mobility access router as a consequence of extending
                tunnels from previousMAR to newMAR to forward the
                multicast traffic.

      

    

    [SF] Exactly. Which is more than likely to happen in a DMM solution,
    where all "mobility entities" may act as "mobility access routers",
    and, after mobility, we want to take advantage of the tunnel for the
    subscription. In those cases, care must be taken in order to not
    greatly magnify convergence problem observed e.g. in RFC6224.

    

    Regards,

    Sérgio

    

    

      

        

        
 

        

          
H Anthony Chan

        

        
 

        

          

            
From:
                dmm-bounces@ietf.org
                [mailto:dmm-bounces@ietf.org]
                On Behalf Of Sérgio Figueiredo

                Sent: Monday, November 19, 2012 5:24 PM

                To: dmm@ietf.org

                Subject: Re: [DMM] Multicast requirements

          

        

        
 

        

          
Hi Anthony,

            

            Thank you for trying to progress on this matter. I mostly
            agree with your analysis.

            

            As for the question you posed, first I would like to exactly
            understand what you mean with "multicast distribution
            scenario" in "DMM solutions should enable multicast
              services which are compatible with multicast distribution
              scenario, etc.". It seems like there is no major
            difference between this and the "DMM solutions should enable solutions to
              support multicast services." requirement? Aren't
            both expressing the need to enable multicast in a DMM
            solution?

            

            As you stated, "neglecting" the requirement 7.1 we proposed,
            leads to the PSs you referred.  So, while 7.2 and 7.3
            express the need for DMM solutions to allow deployment of
            multicast services, 7.1 concerns  "how" IP multicast should
            be enabled in order to avoid the aforementioned PSs. The
            usage of the word "flexible"is explained by: 

            

            "This flexibility enables
              different IP multicast flows with respect to a mobile host
              to be managed (e.g., subscribed, received and/or
              transmitted) using
            multiple endpoints". 

            

            In other words, compatibility with "multicast distribution
            scenario" doesn't necessarily avoid PS1 and PS6.

            

            Thank you and best regards,

            Sérgio

            

            On 11/19/2012 10:28 PM, h chan wrote:

        

        

          
There are 3 proposals for multicast
              requirements. Before comparing these proposals, let us
              understand what are the problems first. Two problem
              statements have been proposed:

          
 

          
PS1 (revised): Non-optimal routes

          
Routing via a centralized anchor often
              results in a longer route. The problem is especially
              manifested when accessing a local server or servers of a
              Content Delivery Network (CDN), or when receiving /
                sending IP multicast packets.
            

          
PS6: Duplicate multicast traffic

          
IP multicast distribution over
              architectures using IP mobility solutions  may lead to
              convergence of duplicated multicast subscriptions towards
              the tunnel’s downstream entity (e.g. MAG in PMIPv6). 
              Concretely, when multicast subscription for individual
              mobile nodes is coupled with mobility tunnels, duplicate
              multicast subscription(s) is prone to be received through
              different upstream paths. This problem is potentially more
              severe in a distributed mobility environment
              [draft-sfigueiredo-multimob-use-case-dmm-03].

          
 

          
Then, let us see whether all the 3 REQ
              proposals have the same intention. In the following, I
              rephrase them to highlight their similarities.

          
 

          
REQ7.1: Flexible multicast distribution

          
DMM solutions should be compatible with
              flexible multicast distribution scenario. Etc.
            

          
The Motivation is to allow flexibility in
              (enable) multicast solutions to solve the problems PS1 and
              PS6 as explained in use cases already presented and
              discussed in multimob wg.

          
 

          
REQ7.2:
            

          
DMM solutions should enable solutions to
              support multicast traffic.
            

          
 

          
(Original wording was "The DMM (unicast)
              solution MUST be specified in such a way that it can be
              extended to also support multicast traffic." I rephrase it
              to highlight the similarity with the other proposals and
              also changed the must to should.)

          
 

          
REQ7.3:

          
DMM solutions should enable solutions to
              support multicast services.

          
 

          
Original wording was “DMM solutions should
              support multicast services … etc. Given that it is the
              scope of multimob and not dmm wg to provide the multicast
              solution, I think “support” here means “enable” solutions
              to be developed (by multimob).

          
 

          
Similarity and subtle differences: Both
              REQ7.2 and REQ7.3 want to enable multicast services. Yet
              the explanation in REQ7.1 seems to indicate not just to
              enable any one multicast solution but also needs the
              flexibility in multicast solution. Not all multicast
              solutions are the same. Some of them results in PS1 or
              PS6.
            

          
 

          

            
Are there any are essential differences
                between:

            
In REQ7.1, DMM solutions should be
                compatible with flexible multicast distribution
                scenario, etc.
              

            
Versus

            
DMM solutions should enable multicast
                services which are compatible with multicast
                distribution scenario, etc.

            
 

            
H Anthony Chan

          

          
 

          

            

              
From:
                  dmm-bounces@ietf.org
                  [mailto:dmm-bounces@ietf.org]
                  On Behalf Of Seil Jeon

                  Sent: Monday, November 19, 2012 5:15 AM

                  To: pierrick.seite@orange.com

                  Cc: dmm@ietf.org

                  Subject: Re: [DMM] Multicast requirements

            

          

          
 

          
Hi
              Pierrick,

          
 

          
I’ve
              many times thought about your question. I would say how
              effectively should we deploy/support multicast over
              distributed mobility rather than distributed mobile
              multicast. As a result, you can find this deployment use
              case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
              presented in multimob several times.

          
 

          
In
              unicast DMM, main innovation is to distribute the anchor
              function at many access routers from single core.
              Following architectural concept of DMM, flexible multicast
              distribution is one of multicast requirement resulted from
              the draft described above. 
          

          
 

          
REQ8: Flexible multicast distribution

          
"DMM solutions SHOULD be
            compatible with flexible multicast distribution scenarios.
            This flexibility enables different IP multicast flows with
            respect to a mobile host to be managed (e.g., subscribed,
            received and/or transmitted) using multiple endpoints". 

            

            Motivation: The motivation for this requirement is to enable
            flexibility in multicast distribution. The multicast
            solution may therefore avoid having multicast-capable access
            routers being restricted to manage all IP multicast traffic
            relative to a host via a single endpoint (e.g. regular or
            tunnel interface), which would lead to the problems
            described in PS1 and PS6.

          
PS6: Duplicate multicast traffic

          
IP multicast
            distribution over architectures using IP mobility solutions 
            may lead to convergence of duplicated multicast
            subscriptions towards the tunnel’s downstream entity (e.g.
            MAG in PMIPv6).  Concretely, when multicast subscription for
            individual mobile nodes is coupled with mobility tunnels,
            duplicate multicast subscription(s) is prone to be received
            through different upstream paths. This problem is
            potentially more severe in a distributed mobility
            environment [draft-sfigueiredo-multimob-use-case-dmm-03].

            

            

            

          

          
Regards,

          
 

          
Seil

          
 

          

            

              
From:
                  pierrick.seite@orange.com
                  [mailto:pierrick.seite@orange.com]
                  

                  Sent: Monday, November 19, 2012 8:55 AM

                  To: 'karagian@cs.utwente.nl';
                  
                    seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

                  Cc: dmm@ietf.org

                  Subject: RE: [DMM] Multicast requirements

            

          

          
 

          
Hi all,

          
 

          
I tend to agree with Georgious, however I
              still do not figure out what is the use-case for
              distributed mobile multicast (other than academic
              considerations)? Can someone give concrete example? 

          
 

          
I haven’t real all messages from this
              thread. So, maybe I missed important points.

          
 

          
BR,

          
Pierrick

          
 

          

            

              

                
De :
                    dmm-bounces@ietf.org
                    [mailto:dmm-bounces@ietf.org]
                    De la part de karagian@cs.utwente.nl

                    Envoyé : samedi 17 novembre 2012 13:01

                    À : seiljeon@av.it.pt;
                    
                      JuanCarlos.Zuniga@InterDigital.com

                    Cc : dmm@ietf.org

                    Objet : Re: [DMM] Multicast requirements

              

            

            
 

            

              
Hi all,

              
 

              
I also agree that the DMM solution should
                  somehow consider muticast deployment. However, I do
                  not thnk that the DMM WG is the right WG to provide
                  the multicast based DMM solution!

              
 

              
One alternative solution will be to have a
                  multicast requirement that emphasizes the need of
                  having extensibility hooks (possibilities) that can be
                  used later on by the multimob WG to provide a 

              
a multicast enabled DMM solution!

              
 

              
 

              
So a requirement that specifies something
                  like the following could be used for this purpose:

              
 

              
"The DMM (unicast) solution MUST be
                  specified in such a way that it can be extended to
                  also support multicast traffic."

              
 

              
 

              
Best regards,

              
Georgios

              
 

              
 

              
 

              

                

                    

                  

                

                  
Van:
                    dmm-bounces@ietf.org
                      [dmm-bounces@ietf.org]
                      namens Seil Jeon [seiljeon@av.it.pt]

                      Verzonden: vrijdag 16 november 2012 22:25

                      To: 'Zuniga, Juan Carlos'

                      Cc: dmm@ietf.org

                      Onderwerp: Re: [DMM] Multicast requirements

                

              

              

                
Hi Juan,

                    

                    I've been looked at changed flow of your proposed
                    text but sorry now that my

                    comment is posted.

                    At first time, I couldn't make sure however, on
                    hearing Stig's description,

                    it seems quite reasonable at the first step, not
                    giving any restrictions but

                    leaving some-specific for the DMM solution it does
                    not support multicast.

                    

                    On the other hand, it remains at a basic stage for
                    the DMM solution to

                    support multicast.

                    So I think additional requirements need to be made
                    for the DMM solution,

                    accordingly. But of course, this should not also
                    give any specific

                    limitation and restriction but should be made
                    towards the direction not

                    limiting the benefits provided by distributed
                    deployment.

                    

                    I hope to get more comments on this.

                    

                  Regards,

                    

                    Seil

                    

                    

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

                    From: dmm-bounces@ietf.org
                  [mailto:dmm-bounces@ietf.org]
                    On Behalf Of

                    Zuniga, Juan Carlos

                    Sent: Friday, November 16, 2012 8:14 PM

                    To: Stig Venaas; dmm@ietf.org

                    Subject: Re: [DMM] Multicast requirements

                    

                    

                    > -----Original Message-----

                    > From: Stig Venaas [mailto:stig@venaas.com]

                    > Sent: Friday, November 16, 2012 3:01 PM

                    > To: jouni korhonen

                    > Cc: sarikaya@ieee.org;
                    Zuniga, Juan Carlos; Konstantinos Pentikousis; 

                    > Peter McCann; dmm@ietf.org

                    > Subject: Re: [DMM] Multicast requirements

                    > 

                    > On 11/15/2012 3:17 AM, jouni korhonen wrote:

                    > >

                    > > On Nov 15, 2012, at 1:03 AM, Behcet
                    Sarikaya wrote:

                    > >

                    > >>

                    > >> I think we are reading too much into
                    multicast and unicast should

                    be

                    > >> designed in an integrated manner.

                  > >>

                    > >> The fact is that multicast is
                    considered as an area of

                    > specialization,

                    > >> it requires knowledge of very
                    different protocols than we are 

                    > >> accustomed to in mobility.

                    > >

                    > > "Requirement: DMM solutions SHOULD support
                    multicast services. If a

                    > specific DMM solution does not support
                    multicast services, an 

                    > explanation MUST be provided."

                    > 

                    > This sounds good to me.

                    > 

                    > The main thing I want to achieve is what was
                    describes as motivation 

                    > earlier in this thread. Multicast should at
                    least be considered when 

                    > looking into DMM solutions, and not just an
                    afterthought once the 

                    > solution is decided.

                    > 

                    > Stig

                    

                    [JCZ] I fully agree with this. That was the
                    intention of the proposed text.

                    

                    Regards,

                    

                    Juan Carlos

                     

                    > 

                    > > To me that reads basically "do not break
                    foundations for multicast

                    > unless you have a valid & documented reason
                    for it".  If we look e.g.

                    > into RFC625 multicast wording that is there
                    very briefly but gives a 

                    > hint to a developer where to head to. That is
                    the level I would expect 

                    > DMM documents should aim to.

                    > >

                    > > - Jouni

                    > >

                    > >

                    > >> Let dmm deal with its current charter
                    that does not include a word

                    > of

                    > >> multicast and if everything goes well
                    we can come back and discuss

                    > dmm

                    > >> multicast.

                  >
                    >>

                    > >> Regards,

                    > >>

                    > >> Behcet

                    

                    _______________________________________________

                    dmm mailing list

                  dmm@ietf.org

                  https://www.ietf.org/mailman/listinfo/dmm

                    

                    _______________________________________________

                    dmm mailing list

                  dmm@ietf.org

                  https://www.ietf.org/mailman/listinfo/dmm

              

            

          

          
_________________________________________________________________________________________________________________________

          
 

          
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

          
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

          
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

          
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

          
 

          
This message and its attachments may contain confidential or privileged information that may be protected by law;

          
they should not be distributed, used or copied without authorisation.

          
If you have received this email in error, please notify the sender and delete this message and its attachments.

          
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.

          
Thank you.

          


            

            

            

          

          
_______________________________________________

          
dmm mailing list

          
dmm@ietf.org

          
https://www.ietf.org/mailman/listinfo/dmm

        

        
 

      

      

      

      

        Este mensaje se dirige exclusivamente a su destinatario. Puede
        consultar nuestra política de envío y recepción de correo
        electrónico en el enlace situado más abajo.

        This message is intended exclusively for its addressee. We only
        send and receive email on the basis of the terms set out at:

        http://www.tid.es/ES/PAGINAS/disclaimer.aspx

      
      

      

      

      
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


    

    

  


--------------040909050409070104000404--

From lmcm@tid.es  Wed Nov 21 00:39:39 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790CE21F85EE for ; Wed, 21 Nov 2012 00:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.348
X-Spam-Level: 
X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG3PEiRJjCiv for ; Wed, 21 Nov 2012 00:39:22 -0800 (PST)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9D21F84B2 for ; Wed, 21 Nov 2012 00:39:16 -0800 (PST)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MDT00C0WXAIXH@tid.hi.inet> for dmm@ietf.org; Wed, 21 Nov 2012 09:37:37 +0100 (MET)
Received: from tid (tid.hi.inet [10.95.64.10])	by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id AF.B3.03143.0D29CA05; Wed, 21 Nov 2012 09:37:36 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MDT00IBHXAOJ8@tid.hi.inet> for dmm@ietf.org; Wed, 21 Nov 2012 09:37:36 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 09:36:56 +0100
Date: Wed, 21 Nov 2012 08:37:36 +0000
From: LUIS MIGUEL CONTRERAS MURILLO 
In-reply-to: <50AC1070.4040408@av.it.pt>
X-Originating-IP: [10.95.64.115]
To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= , "dmm@ietf.org" 
Message-id: <823234EF5C7C334998D973D822FF801B1EDBA6AE@EX10-MB2-MAD.hi.inet>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_7X7jjYTke+XwN4dPsjTuAA)"
Content-language: es-ES
Accept-Language: es-ES, en-US
Thread-topic: [DMM] Multicast PS to requirements
Thread-index: AQHNx3W8NaTcJfvZl0KZnbbxSemrn5fz91HA
X-AuditID: 0a5f4068-b7f746d000000c47-eb-50ac92d0798a
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXCFe/ApXth0poAg51TlCzuP6pxYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG2eXnWQvmfGSu+PR9NVsDY8MW5i5GDg4JAROJazusuxg5gUwx iQv31rN1MXJxCAlsYJTYdO8bK4TzjVGia+00dghnGqPEvOmHmUFaWARUJZYsP8wOYrMJGErM 2jmJFcQWFtCXeHV+HZjNKaAhcWzxahaIFQoSf849BrNFBBIkfvV/AuvlFfCWWNy1jQ3CFpT4 MfkeWA2zQK7Enh3HmSBscYk5vyaCzWQUkJVYef40I8QcA4mPG7ewQdhGEn9XPWWF2CUgsWTP eWYIW1Ti5eN/UN98Ype4uvkE8wRG0VlI9s1Csm8Wkn0Qtp7EjalT2CBsbYllC18zQ9i6EjP+ HWJBFl/AyL6KUaw4qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMkxjJ2MC7fqXKIUYCDUYmH94LI mgAh1sSy4srcQ4ySHExKorxO/UAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwM8kA53pTEyqrU onyYlAwHh5IE768JQCnBotT01Iq0zBxgIoFJM3FwgrTzALV7TARpLy5IzC3OTIfIn2LU5pgz s/0JI8e2T11PGIVY8vLzUqXEeZ+ClAqAlGaU5sFNe8UoDnS2MO8fkGU8wLQIN+cV0AomoBXx LqtBVpQkIqSkGhhTVmV43F1qd+T3ZxuZ5X2LLQW3r/DxYbzQOTXHp93gjht76EuF8GmndIxv 9BnrlBr8mNs1QVjmzcq6SXmnHF7sK5O84liYsV89+OHGmN0/arjSBTMP6k28l7X82Tdbc6kz xyUK+SwbZDJ/iy9h44hJ1U4u3DA5Svj251ltBvvOnZNZO2flpjAlluKMREMt5qLiRAAFX8vo SAMAAA==
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com>  <000601cdc440$ef947f50$cebd7df0$@av.it.pt>  <"23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7"@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <50AABF7D.9020003@av.it.pt> <6E31144C030982429702B11D6746B98C36494893@SZXEML510-MBS.china.huawei.com> <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet> <50AC1070.4040408@av.it.pt>
Subject: Re: [DMM] Multicast PS to requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Nov 2012 08:39:39 -0000

--Boundary_(ID_7X7jjYTke+XwN4dPsjTuAA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Thanks Sergio, Seil,

Just a final comment. For PS1, not sure if the word "especially" in the sen=
tence "The problem is especially manifested ..." should be removed.

Regards,

Luis

De: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] En nombre de S=E9rgi=
o Figueiredo
Enviado el: mi=E9rcoles, 21 de noviembre de 2012 0:21
Para: dmm@ietf.org
Asunto: Re: [DMM] Multicast PS to requirements

Hi Luis,

A few more comments on this inline:

Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
Hi Anthony,

some comments in line

Best regards,

Luis

De: dmm-bounces@ietf.org [mailto:dmm-bounces@i=
etf.org] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: S=E9rgio Figueiredo; dmm@ietf.org
Asunto: [DMM] Multicast PS to requirements

Let us also use another thread to check for consensus of the PS from multim=
ob.

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.

[Luis>>] This is correct if the multicast content is locally available. How=
ever this could not be always the case for multicast listeners, for a numbe=
r of reasons (for instance, conflict in the multicast address allocation be=
tween the Home Network and the DMM domain).
[SF] Sure, and the same applies to "accessing a local server a CDN" - it is=
 implicit that the content is locally available. But it can be improved as =
"when receiving locally available IP multicast or sending IP multicast".


PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

[Luis>>] This seems not to be a problem of the IP mobility solutions handli=
ng multicast traffic with mobility tunnels in general, but a problem of con=
sidering several upstream paths ending on the same mobility access router a=
s a consequence of extending tunnels from previousMAR to newMAR to forward =
the multicast traffic.
[SF] Exactly. Which is more than likely to happen in a DMM solution, where =
all "mobility entities" may act as "mobility access routers", and, after mo=
bility, we want to take advantage of the tunnel for the subscription. In th=
ose cases, care must be taken in order to not greatly magnify convergence p=
roblem observed e.g. in RFC6224.

Regards,
S=E9rgio



H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of S=E9rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.

As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should =
enable multicast services which are compatible with multicast distribution =
scenario, etc.". It seems like there is no major difference between this an=
d the "DMM solutions should enable solutions to support multicast services.=
" requirement? Aren't both expressing the need to enable multicast in a DMM=
 solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the P=
Ss you referred.  So, while 7.2 and 7.3 express the need for DMM solutions =
to allow deployment of multicast services, 7.1 concerns  "how" IP multicast=
 should be enabled in order to avoid the aforementioned PSs. The usage of t=
he word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mo=
bile host to be managed (e.g., subscribed, received and/or transmitted) usi=
ng multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn'=
t necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these pr=
oposals, let us understand what are the problems first. Two problem stateme=
nts have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. I=
n the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution sce=
nario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to s=
olve the problems PS1 and PS6 as explained in use cases already presented a=
nd discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such=
 a way that it can be extended to also support multicast traffic." I rephra=
se it to highlight the similarity with the other proposals and also changed=
 the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was "DMM solutions should support multicast services ... e=
tc. Given that it is the scope of multimob and not dmm wg to provide the mu=
lticast solution, I think "support" here means "enable" solutions to be dev=
eloped (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable mu=
lticast services. Yet the explanation in REQ7.1 seems to indicate not just =
to enable any one multicast solution but also needs the flexibility in mult=
icast solution. Not all multicast solutions are the same. Some of them resu=
lts in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distr=
ibution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with mu=
lticast distribution scenario, etc.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively sh=
ould we deploy/support multicast over distributed mobility rather than dist=
ributed mobile multicast. As a result, you can find this deployment use cas=
e and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob=
-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at man=
y access routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted fr=
om the draft described above.


REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution sc=
enarios. This flexibility enables different IP multicast flows with respect=
 to a mobile host to be managed (e.g., subscribed, received and/or transmit=
ted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via a single endpoint (e.g. regular or tunnel =
interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].


Regards,

Seil

From: pierrick.seite@orange.com [mailto:p=
ierrick.seite@orange.com]
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it=
.pt; JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterD=
igital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that m=
y
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions bu=
t
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.




_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx




_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

--Boundary_(ID_7X7jjYTke+XwN4dPsjTuAA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable










Thanks Sergio, Seil,


 


Just a final comment. F=
or PS1, not sure if the word “especially” in the sentence ̶=
0;The
 problem is especially manifested … 


Regards,


 


Luis


 






De: dmm-bounces@ietf.org [m=
ailto:dmm-bounces@ietf.org]
En nombre de S=E9rgio Figueiredo

Enviado el: mi=E9rcoles, 21 de noviembre de 2012 0:21

Para: dmm@ietf.org

Asunto: Re: [DMM] Multicast PS to requirements






 




Hi Luis,



A few more comments on this inline:



Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:








Hi Anthony,



 


some comments in line



 


Best regards,

 


Luis


 






De:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
En nombre de h chan

Enviado el: martes, 20 de noviembre de 2012 18:51

Para: S=E9rgio Figueiredo; dmm@ietf.=
org

Asunto: [DMM] Multicast PS to requirements






 


Let us also use another=
 thread to check for consensus of the PS from multimob.



 


PS1 (revised): Non-opti=
mal routes


Routing via a centra=
lized anchor often results in a longer route. The problem is especially man=
ifested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



[Luis>>]=
 This is correct if the multicast content is locally available. However thi=
s could not be always the case for multicast listeners, for a
 number of reasons (for instance, conflict in the multicast address allocat=
ion between the Home Network and the DMM domain).







[SF] Sure, and the same applies to "accessing a=
 local server a CDN" - it is implicit that the content is locally avai=
lable. But it can be improved as "when receiving locally available IP =
multicast or sending IP multicast".










PS6: Duplicate multicas=
t traffic


IP multicast distributi=
on over architectures using IP mobility solutions  may lead to converg=
ence of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 =



[Luis>>] Th=
is seems not to be a problem of the IP mobility solutions handling multicas=
t traffic with mobility tunnels in general, but a problem of considering
 several upstream paths ending on the same mobility access router as a cons=
equence of extending tunnels from previousMAR to newMAR to forward the mult=
icast traffic.




[SF] Exactly. Which is more than likely to happen in=
 a DMM solution, where all "mobility entities" may act as "m=
obility access routers", and, after mobility, we want to take advantag=
e of the tunnel for the subscription. In those cases,
 care must be taken in order to not greatly magnify convergence problem obs=
erved e.g. in RFC6224.



Regards,

S=E9rgio










 




H Anthony Chan



 






From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of S=E9rgio Figueiredo

Sent: Monday, November 19, 2012 5:24 PM

To: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.



As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should enable multicast services
 which are compatible with multicast distribution scenario, etc.&quo=
t;. It seems like there is no major difference between this and the "<=
span style=3D"font-size:11.0pt; font-family:"Calibri","sans-=
serif"; color:#1F497D">DMM solutions should enable solutions
 to support multicast services." requirement? Aren't both expre=
ssing the need to enable multicast in a DMM solution?



As you stated, "neglecting" the requirement 7.1 we proposed, lead=
s to the PSs you referred.  So, while 7.2 and 7.3 express the need for=
 DMM solutions to allow deployment of multicast services, 7.1 concerns =
; "how" IP multicast should be enabled in order to avoid
 the aforementioned PSs. The usage of the word "flexible"is expla=
ined by: 



"This flexibility enables different I=
P multicast flows with respect to a mobile host to be managed (e.g., subscr=
ibed, received and/or transmitted) using
multiple endpoints". 



In other words, compatibility with "multicast distribution scenario&qu=
ot; doesn't necessarily avoid PS1 and PS6.



Thank you and best regards,

S=E9rgio



On 11/19/2012 10:28 PM, h chan wrote:






There are 3 proposals f=
or multicast requirements. Before comparing these proposals, let us underst=
and what are the problems first. Two problem statements
 have been proposed:


 


PS1 (revised): Non-opti=
mal routes


Routing via a centra=
lized anchor often results in a longer route. The problem is especially man=
ifested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



PS6: Duplicate multicas=
t traffic


IP multicast distributi=
on over architectures using IP mobility solutions  may lead to converg=
ence of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 


Then, let us see whethe=
r all the 3 REQ proposals have the same intention. In the following, I reph=
rase them to highlight their similarities.


 


REQ7.1: Flexible multic=
ast distribution


DMM solutions should be=
 compatible with flexible multicast distribution scenario. Etc.



The Motivation is to al=
low flexibility in (enable) multicast solutions to solve the problems PS1 a=
nd PS6 as explained in use cases already presented and discussed
 in multimob wg.


 


REQ7.2:



DMM solutions should en=
able solutions to support multicast traffic.



 


(Original wording was &=
quot;The DMM (unicast) solution MUST be specified in such a way that it can=
 be extended to also support multicast traffic." I rephrase it
 to highlight the similarity with the other proposals and also changed the =
must to should.)


 


REQ7.3:


DMM solutions should en=
able solutions to support multicast services.


 


Original wording was &#=
8220;DMM solutions should support multicast services … etc. Given tha=
t it is the scope of multimob and not dmm wg to provide the multicast
 solution, I think “support” here means “enable” so=
lutions to be developed (by multimob).


 


Similarity and subtle d=
ifferences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet t=
he explanation in REQ7.1 seems to indicate not just to enable
 any one multicast solution but also needs the flexibility in multicast sol=
ution. Not all multicast solutions are the same. Some of them results in PS=
1 or PS6.



 




Are there any are essen=
tial differences between:


In REQ7.1, DMM solution=
s should be compatible with flexible multicast distribution scenario, etc.



Versus


DMM solutions should en=
able multicast services which are compatible with multicast distribution sc=
enario, etc.


 


H Anthony Chan



 






From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Seil Jeon

Sent: Monday, November 19, 2012 5:15 AM

To: pierrick.seite@oran=
ge.com

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 


Hi Pierrick,


 


I’ve many times thought about your=
 question. I would say how effectively should we deploy/support multicast o=
ver distributed mobility rather than distributed mobile multicast.
 As a result, you can find this deployment use case and gap analysis at 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 p=
resented in multimob several times.


 


In unicast DMM, main innovation is to di=
stribute the anchor function at many access routers from single core. Follo=
wing architectural concept of DMM, flexible multicast distribution
 is one of multicast requirement resulted from the draft described above. <=
/span>



 


REQ8: Flexible multicast distribution


"DMM solutions SHOULD be compatible with flexib=
le multicast distribution scenarios. This flexibility enables different IP =
multicast flows with respect to a mobile host to be managed (e.g., subscrib=
ed, received and/or transmitted) using
 multiple endpoints". 



Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via
 a single endpoint (e.g. regular or tunnel interface), which would lead to =
the problems described in PS1 and PS6.


PS6: Duplicate multicast traffic


IP multicast distribu=
tion over architectures using IP mobility solutions  may lead to conve=
rgence of duplicated multicast subscriptions towards the tunnel’s dow=
nstream entity (e.g. MAG in PMIPv6).  Concretely,
 when multicast subscription for individual mobile nodes is coupled with mo=
bility tunnels, duplicate multicast subscription(s) is prone to be received=
 through different upstream paths. This problem is potentially more severe =
in a distributed mobility environment
 [draft-sfigueiredo-multimob-use-case-dmm-03].








Regards,


 


Seil


 






From:
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.=
com]


Sent: Monday, November 19, 2012 8:55 AM

To: 'karagian@cs.utwente.n=
l'; 
seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc: dmm@ietf.org

Subject: RE: [DMM] Multicast requirements






 


Hi all,


 


I tend to agree with Ge=
orgious, however I still do not figure out what is the use-case for distrib=
uted mobile multicast (other than academic considerations)?
 Can someone give concrete example? 


 


I haven’t real al=
l messages from this thread. So, maybe I missed important points.

 


BR,


Pierrick


 








De :
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.=
utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; 
JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should someh=
ow consider muticast deployment. However, I do not thnk that the DMM WG is =
the right WG to provide the multicast based DMM solution!


 


One alternative solution will be to have a mult=
icast requirement that emphasizes the need of having extensibility hooks (p=
ossibilities) that can be used later on by the multimob
 WG to provide a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like =
the following could be used for this purpose:


 


"The DMM (unicast) solution MUST be s=
pecified in such a way that it can be extended to also support multicast tr=
affic."


 


 


Best regards,


Georgios


 


 


 












Van:<=
/span>
dmm-bounces@ietf.org
[dmm-bounces@ie=
tf.org] namens Seil Jeon [seiljeon=
@av.it.pt]

Verzonden: vrijdag 16 november 2012 22:25

To: 'Zuniga, Juan Carlos'

Cc: =
dmm@ietf.org

Onderwerp: Re: [DMM] Multicast requirements








Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
[mailto:dmm-bounces=
@ietf.org]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.c=
om]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; Z=
uniga, Juan
 Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mail=
man/listinfo/dmm



_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mail=
man/listinfo/dmm








____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
/pre>

a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
/pre>

France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.











_______________________________________________


dmm mailing list


dmm@ietf.org


https://www.ietf=
.org/mailman/listinfo/dmm




 




 










Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.

This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:

http://www.tid.es/=
ES/PAGINAS/disclaimer.aspx










_______________________________________________


dmm mailing list


dmm@ietf.org


https://www.ietf=
.org/mailman/listinfo/dmm


 









Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.

This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:

http://www.tid.es/ES/PAGINAS/disclaimer.aspx





--Boundary_(ID_7X7jjYTke+XwN4dPsjTuAA)--

From pierrick.seite@orange.com  Wed Nov 21 01:37:42 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCBB21F8653 for ; Wed, 21 Nov 2012 01:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLUBPimnBLrc for ; Wed, 21 Nov 2012 01:37:32 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9222C21F85AA for ; Wed, 21 Nov 2012 01:37:31 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6A566324387; Wed, 21 Nov 2012 10:37:27 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7718035C060; Wed, 21 Nov 2012 10:37:26 +0100 (CET)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 10:37:26 +0100
From: 
To: 'LUIS MIGUEL CONTRERAS MURILLO' , =?iso-8859-1?Q?S=E9rgio_Figueiredo?= , "dmm@ietf.org" 
Thread-Topic: [DMM] Multicast PS to requirements
Thread-Index: AQHNx1fc3ICMD4bvHEqgf97DnMU+GJfzTAsAgACbawCAABd8QA==
Date: Wed, 21 Nov 2012 09:37:25 +0000
Message-ID: <25279_1353490647_50ACA0D7_25279_3269_8_81C77F07008CA24F9783A98CFD706F710700AB@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com>  <000601cdc440$ef947f50$cebd7df0$@av.it.pt> 	<"23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7"@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <50AABF7D.9020003@av.it.pt> <6E31144C030982429702B11D6746B98C36494893@SZXEML510-MBS.china.huawei.com> <823234EF5C7C334998D973D822FF801B1EDBA068@EX10-MB2-MAD.hi.inet> <50AC1070.4040408@av.it.pt> <823234EF5C7C334998D973D822FF801B1EDBA6AE@EX10-MB2-MAD.hi.inet>
In-Reply-To: <823234EF5C7C334998D973D822FF801B1EDBA6AE@EX10-MB2-MAD.hi.inet>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F710700ABPEXCVZYM12corpora_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.21.84517
Subject: Re: [DMM] Multicast PS to requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Nov 2012 09:37:42 -0000

--_000_81C77F07008CA24F9783A98CFD706F710700ABPEXCVZYM12corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Referring to CDN does not make any assumptions on the delivery mode. So, if=
 you really want to stress multicast, I suggest the following:

Routing via a centralized anchor often results in a longer route. The probl=
em is [especially] manifested when accessing a local server or servers of a=
 Content Delivery Network (CDN), including both unicast and multicast deliv=
ery mode.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de LUIS =
MIGUEL CONTRERAS MURILLO
Envoy=E9 : mercredi 21 novembre 2012 09:38
=C0 : S=E9rgio Figueiredo; dmm@ietf.org
Objet : Re: [DMM] Multicast PS to requirements

Thanks Sergio, Seil,

Just a final comment. For PS1, not sure if the word "especially" in the sen=
tence "The problem is especially manifested ..." should be removed.

Regards,

Luis

De: dmm-bounces@ietf.org [mailto:dmm-bounces@i=
etf.org] En nombre de S=E9rgio Figueiredo
Enviado el: mi=E9rcoles, 21 de noviembre de 2012 0:21
Para: dmm@ietf.org
Asunto: Re: [DMM] Multicast PS to requirements

Hi Luis,

A few more comments on this inline:

Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
Hi Anthony,

some comments in line

Best regards,

Luis

De: dmm-bounces@ietf.org [mailto:dmm-bounces@i=
etf.org] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: S=E9rgio Figueiredo; dmm@ietf.org
Asunto: [DMM] Multicast PS to requirements

Let us also use another thread to check for consensus of the PS from multim=
ob.

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.

[Luis>>] This is correct if the multicast content is locally available. How=
ever this could not be always the case for multicast listeners, for a numbe=
r of reasons (for instance, conflict in the multicast address allocation be=
tween the Home Network and the DMM domain).
[SF] Sure, and the same applies to "accessing a local server a CDN" - it is=
 implicit that the content is locally available. But it can be improved as =
"when receiving locally available IP multicast or sending IP multicast".

PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

[Luis>>] This seems not to be a problem of the IP mobility solutions handli=
ng multicast traffic with mobility tunnels in general, but a problem of con=
sidering several upstream paths ending on the same mobility access router a=
s a consequence of extending tunnels from previousMAR to newMAR to forward =
the multicast traffic.
[SF] Exactly. Which is more than likely to happen in a DMM solution, where =
all "mobility entities" may act as "mobility access routers", and, after mo=
bility, we want to take advantage of the tunnel for the subscription. In th=
ose cases, care must be taken in order to not greatly magnify convergence p=
roblem observed e.g. in RFC6224.

Regards,
S=E9rgio


H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of S=E9rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.

As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should =
enable multicast services which are compatible with multicast distribution =
scenario, etc.". It seems like there is no major difference between this an=
d the "DMM solutions should enable solutions to support multicast services.=
" requirement? Aren't both expressing the need to enable multicast in a DMM=
 solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the P=
Ss you referred.  So, while 7.2 and 7.3 express the need for DMM solutions =
to allow deployment of multicast services, 7.1 concerns  "how" IP multicast=
 should be enabled in order to avoid the aforementioned PSs. The usage of t=
he word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mo=
bile host to be managed (e.g., subscribed, received and/or transmitted) usi=
ng multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn'=
t necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these pr=
oposals, let us understand what are the problems first. Two problem stateme=
nts have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. I=
n the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution sce=
nario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to s=
olve the problems PS1 and PS6 as explained in use cases already presented a=
nd discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such=
 a way that it can be extended to also support multicast traffic." I rephra=
se it to highlight the similarity with the other proposals and also changed=
 the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was "DMM solutions should support multicast services ... e=
tc. Given that it is the scope of multimob and not dmm wg to provide the mu=
lticast solution, I think "support" here means "enable" solutions to be dev=
eloped (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable mu=
lticast services. Yet the explanation in REQ7.1 seems to indicate not just =
to enable any one multicast solution but also needs the flexibility in mult=
icast solution. Not all multicast solutions are the same. Some of them resu=
lts in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distr=
ibution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with mu=
lticast distribution scenario, etc.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively sh=
ould we deploy/support multicast over distributed mobility rather than dist=
ributed mobile multicast. As a result, you can find this deployment use cas=
e and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob=
-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at man=
y access routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted fr=
om the draft described above.


REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution sc=
enarios. This flexibility enables different IP multicast flows with respect=
 to a mobile host to be managed (e.g., subscribed, received and/or transmit=
ted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via a single endpoint (e.g. regular or tunnel =
interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Regards,

Seil

From: pierrick.seite@orange.com [mailto:p=
ierrick.seite@orange.com]
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it=
.pt; JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterD=
igital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions but
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.



_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx



_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_81C77F07008CA24F9783A98CFD706F710700ABPEXCVZYM12corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

Referring =
to CDN does not make any assumptions on the delivery mode. So, if you reall=
y want to stress multicast, I suggest the following:


 =
;


Routing vi=
a a centralized anchor often results in a longer route. The problem is [esp=
ecially] manifested when accessing a local server or servers
 of a Content Delivery Network (CDN), including both unicast and multicast =
delivery mode.


 =
;


BR,


Pierrick


 =
;








De :=
 dmm-bounces@ietf.org [mailto:dmm-bounces@ietf=
.org]
De la part de LUIS MIGUEL CONTRERAS MURILLO

Envoy=E9 : mercredi 21 novembre 2012 09:38

=C0 : S=E9rgio Figueiredo; dmm@ietf.org

Objet : Re: [DMM] Multicast PS to requirements






 




Thanks Ser=
gio, Seil,


 


Just a fin=
al comment. For PS1, not sure if the word “especially” in the s=
entence “The
 problem is especially manifested …” should be removed.=



 


Regards,


 


Luis


 






De:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
En nombre de S=E9rgio Figueiredo

Enviado el: mi=E9rcoles, 21 de noviembre de 2012 0:21

Para: dmm@ietf.org

Asunto: Re: [DMM] Multicast PS to requirements






 




Hi Luis,



A few more comments on this inline:



Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:








Hi Anthony,



 


some comme=
nts in line



 


Best regar=
ds,


 


Luis


 






De:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
En nombre de h chan

Enviado el: martes, 20 de noviembre de 2012 18:51

Para: S=E9rgio Figueiredo; dmm@ietf.=
org

Asunto: [DMM] Multicast PS to requirements






 


Let us als=
o use another thread to check for consensus of the PS from multimob.



 


PS1 (revis=
ed): Non-optimal routes


Routing=
 via a centralized anchor often results in a longer route. The problem is e=
specially manifested when accessing a local server or servers
 of a Content Delivery Network (CDN), or when receiving / sending IP mul=
ticast packets.



[=
Luis>>] This is correct if the multicast content is locally available=
. However this could not be always the case for multicast listeners,
 for a number of reasons (for instance, conflict in the multicast address a=
llocation between the Home Network and the DMM domain).







=
[SF] Sure, and the same applies to "accessing a local server a CDN&quo=
t; - it is implicit that the content is locally available. But it can be im=
proved as "when receiving locally available IP multicast
 or sending IP multicast".








PS6: Dupli=
cate multicast traffic


IP multica=
st distribution over architectures using IP mobility solutions  may le=
ad to convergence of duplicated multicast subscriptions towards
 the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretel=
y, when multicast subscription for individual mobile nodes is coupled with =
mobility tunnels, duplicate multicast subscription(s) is prone to be receiv=
ed through different upstream paths. This problem
 is potentially more severe in a distributed mobility environment [draft-sf=
igueiredo-multimob-use-case-dmm-03].=



&nbs=
p;


[Lui=
s>>] This seems not to be a problem of the IP mobility solutions hand=
ling multicast traffic with mobility tunnels in general, but a problem
 of considering several upstream paths ending on the same mobility access r=
outer as a consequence of extending tunnels from previousMAR to newMAR to f=
orward the multicast traffic.




=
[SF] Exactly. Which is more than likely to happen in a DMM solution, where =
all "mobility entities" may act as "mobility access routers&=
quot;, and, after mobility, we want to take advantage of the
 tunnel for the subscription. In those cases, care must be taken in order t=
o not greatly magnify convergence problem observed e.g. in RFC6224.



Regards,

S=E9rgio








 




H Anthony =
Chan




 






From:=

dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of S=E9rgio Figueiredo

Sent: Monday, November 19, 2012 5:24 PM

To: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.



As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should enable
 multicast services which are compatible with multicast distribution scenar=
io, etc.". It seems like there is no major=
 difference between this and the "DMM
 solutions should enable solutions to support multicast services." requirement? Aren't both expressing the need to en=
able multicast in a DMM solution?



As you stated, "neglecting" the requirement 7.1 we proposed, lead=
s to the PSs you referred.  So, while 7.2 and 7.3 express the need for=
 DMM solutions to allow deployment of multicast services, 7.1 concerns =
; "how" IP multicast should be enabled in order to avoid
 the aforementioned PSs. The usage of the word "flexible"is expla=
ined by: 



"This flexibili=
ty enables different IP multicast flows with respect to a mobile host to be=
 managed (e.g., subscribed, received and/or transmitted) using
multiple endpoints". 



In other words, compatibility with "multicast distribution scenario&qu=
ot; doesn't necessarily avoid PS1 and PS6.



Thank you and best regards,

S=E9rgio



On 11/19/2012 10:28 PM, h chan wrote:






There are =
3 proposals for multicast requirements. Before comparing these proposals, l=
et us understand what are the problems first. Two problem
 statements have been proposed:


 


PS1 (revis=
ed): Non-optimal routes


Routing=
 via a centralized anchor often results in a longer route. The problem is e=
specially manifested when accessing a local server or servers
 of a Content Delivery Network (CDN), or when receiving / sending IP mul=
ticast packets.



PS6: Dupli=
cate multicast traffic


IP multica=
st distribution over architectures using IP mobility solutions  may le=
ad to convergence of duplicated multicast subscriptions towards
 the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretel=
y, when multicast subscription for individual mobile nodes is coupled with =
mobility tunnels, duplicate multicast subscription(s) is prone to be receiv=
ed through different upstream paths. This problem
 is potentially more severe in a distributed mobility environment [draft-sf=
igueiredo-multimob-use-case-dmm-03].=



 


Then, let =
us see whether all the 3 REQ proposals have the same intention. In the foll=
owing, I rephrase them to highlight their similarities.


 


REQ7.1: Fl=
exible multicast distribution=



DMM soluti=
ons should be compatible with flexible multicast distribution scenario. Etc.



The Motiva=
tion is to allow flexibility in (enable) multicast solutions to solve the p=
roblems PS1 and PS6 as explained in use cases already presented
 and discussed in multimob wg.


 


REQ7.2:



DMM soluti=
ons should enable solutions to support multicast traffic.



 


(Original =
wording was "The DMM (unicast) solution MUST be specified in such a wa=
y that it can be extended to also support multicast traffic." I
 rephrase it to highlight the similarity with the other proposals and also =
changed the must to should.)<=
/p>

 


REQ7.3:


DMM soluti=
ons should enable solutions to support multicast services.


 


Original w=
ording was “DMM solutions should support multicast services … e=
tc. Given that it is the scope of multimob and not dmm wg to provide the
 multicast solution, I think “support” here means “enable=
” solutions to be developed (by multimob).


 


Similarity=
 and subtle differences: Both REQ7.2 and REQ7.3 want to enable multicast se=
rvices. Yet the explanation in REQ7.1 seems to indicate not
 just to enable any one multicast solution but also needs the flexibility i=
n multicast solution. Not all multicast solutions are the same. Some of the=
m results in PS1 or PS6.



 




Are there =
any are essential differences between:


In REQ7.1,=
 DMM solutions should be compatible with flexible multicast distribution sc=
enario, etc.



Versus


DMM soluti=
ons should enable multicast services which are compatible with multicast di=
stribution scenario, etc.


 


H Anthony =
Chan




 






From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Seil Jeon

Sent: Monday, November 19, 2012 5:15 AM

To: pierrick.seite@oran=
ge.com

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 


Hi Pierrick,


 


I’ve many times thou=
ght about your question. I would say how effectively should we deploy/suppo=
rt multicast over distributed mobility rather than distributed mobile
 multicast. As a result, you can find this deployment use case and gap anal=
ysis at
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-0=
3 presented in multimob several times.=



 


In unicast DMM, main innov=
ation is to distribute the anchor function at many access routers from sing=
le core. Following architectural concept of DMM, flexible
 multicast distribution is one of multicast requirement resulted from the d=
raft described above.



 


REQ8: Flexible multicast dis=
tribution


"DMM solutions SHOULD be c=
ompatible with flexible multicast distribution scenarios. This flexibility =
enables different IP multicast flows with respect to a mobile host to be ma=
naged (e.g., subscribed, received and/or
 transmitted) using multiple endpoints". 



Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via
 a single endpoint (e.g. regular or tunnel interface), which would lead to =
the problems described in PS1 and PS6.


PS6: Duplicate multicast traffi=
c


=
IP multicast distribution over architectures using IP mobility solutions&nb=
sp; may lead to convergence of duplicated multicast subscriptions towards t=
he tunnel’s downstream entity (e.g. MAG in
 PMIPv6).  Concretely, when multicast subscription for individual mobi=
le nodes is coupled with mobility tunnels, duplicate multicast subscription=
(s) is prone to be received through different upstream paths. This problem =
is potentially more severe in a distributed
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].






Regards,


 


Seil


 






From:
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.=
com]


Sent: Monday, November 19, 2012 8:55 AM

To: 'karagian@cs.utwente.n=
l'; 
seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc: dmm@ietf.org

Subject: RE: [DMM] Multicast requirements






 


Hi all,


 


I tend to =
agree with Georgious, however I still do not figure out what is the use-cas=
e for distributed mobile multicast (other than academic considerations)?
 Can someone give concrete example? =



 


I haven=
217;t real all messages from this thread. So, maybe I missed important poin=
ts.


 


BR,=



Pierrick


 








De :
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.=
utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; 
JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should somehow consider m=
uticast deployment. However, I do not thnk that the DMM WG is the right WG =
to provide the multicast based DMM solution!


 


One alternative solution will be to have a multicast require=
ment that emphasizes the need of having extensibility hooks (possibilities)=
 that can be used later on by the multimob WG to provide
 a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like the following=
 could be used for this purpose:


 


"The DMM (unicast) solution MUST be specified in s=
uch a way that it can be extended to also support multicast traffic."<=
/span>


 


 


Best regards,<=
/p>

Georgios


 


 


 












Van:
dmm-bounces@ietf.org
[=
dmm-bounces@ietf.org] namens Seil Jeon [seiljeon@av.it.pt]

Verzonden: vrijdag 16 november 2012 22:25

To: 'Zuniga, Juan Carlos'

Cc: dmm@ietf.org

Onderwerp: Re: [DMM] Multicast requirements








Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,

accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
[mailto:dmm-bounce=
s@ietf.org]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.com=
]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; =
Zuniga, Juan
 Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm=
@ietf.org

https://www.ietf.org/mailman/listinfo/=
dmm



_______________________________________________

dmm mailing list

dmm=
@ietf.org

https://www.ietf.org/mailman/listinfo/=
dmm








______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,=



France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;=



they should not be distributed, used or copied without authorisation.<=
span lang=3D"EN-US">


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, France Telecom - Orange is not liable for me=
ssages that have been modified, changed or falsified.<=
o:p>


Thank you.


=







_______________________________________________


dmm mailing list


dmm@ietf.org<=
o:p>


https://www.ietf.org/mailman/listinfo/dmm




 




 










Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.

This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:

http://www.tid.es/=
ES/PAGINAS/disclaimer.aspx








_______________________________________________


dmm mailing list


dmm@ietf.org<=
o:p>


https://www.ietf.org/mailman/listinfo/dmm


 




 










Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.

This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:

http://www.tid.es/=
ES/PAGINAS/disclaimer.aspx






______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_81C77F07008CA24F9783A98CFD706F710700ABPEXCVZYM12corpora_--

From luo.wen@zte.com.cn  Wed Nov 21 18:03:01 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BFF21E8050; Wed, 21 Nov 2012 18:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.95
X-Spam-Level: 
X-Spam-Status: No, score=-90.95 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds6D6LahZwOx; Wed, 21 Nov 2012 18:03:00 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 160DA21E8044; Wed, 21 Nov 2012 18:03:00 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4C75943D4E; Thu, 22 Nov 2012 10:02:52 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 29E0370521E; Thu, 22 Nov 2012 10:00:46 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAM22m42055228; Thu, 22 Nov 2012 10:02:48 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <8B730FDB-6094-471A-B830-9E7076B22070@gmail.com>
To: jouni korhonen 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Thu, 22 Nov 2012 10:02:41 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-22 10:02:43, Serialize complete at 2012-11-22 10:02:43
Content-Type: multipart/alternative; boundary="=_alternative 000B3E9148257ABE_="
X-MAIL: mse01.zte.com.cn qAM22m42055228
Cc: dmm-bounces@ietf.org, "dmm@ietf.org" , Konstantinos Pentikousis 
Subject: [DMM] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgY29tbWVudHMgb24gZHJh?= =?gb2312?b?ZnQtaWV0Zi1kbW0tcmVxdWlyZW1lbnRzLTAy?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 02:03:01 -0000

This is a multipart message in MIME format.
--=_alternative 000B3E9148257ABE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgSm91bmksDQoNCj4gSSBtZWFuIHRoZSBiZWxvdyB0aGUgImFwcGxpY2F0aW9ucyB0aGF0IGFu
eSByYW5kb20gZGV2ZWxvcGVyIGNhbiBkbyIgDQpzdXBwb3J0Li4gaS5lLiBtaWRkbGV3YXJlLCB2
ZW5kb3IgQVBJcywgT1MgJiBJUCBzdGFjayBsZXZlbCB0aGluZ3MgZXRjLiANCkZvciBleGFtcGxl
LCBpZiB0aGUgIm1vYmlsaXR5IHN0YWNrIiBuZWVkcyB0byBob29rIGRlZXAgaW5zaWRlIHRoZSBJ
UCANCnN0YWNrLCBpdCBiYXNpY2FsbHkgaGFzIHRvIGJlIHBhcnQgb2YgdGhlIHBsYXRmb3JtIGxl
dmVsIGJhc2VsaW5lIHNvZnR3YXJlIA0KdG8gYmUgc3VjY2Vzc2Z1bC4gSWYgdGhlICJtb2JpbGl0
eSBzdGFjayIgaXMgc29tZXRoaW5nIHRoYXQganVzdCByZXF1aXJlcyANCmhpZ2hlciBwcml2aWxl
Z2VzIChsaWtlIGluc3RhbGxpbmcgYSBkcml2ZXIpIHRoYW4gYSBjb25zdW1lciBoYXMsIHRoZW4g
DQpvcGVyYXRvcnMgJiBlbnRlcnByaXNlcyBjYW4gZGlzdHJpYnV0ZSByZXF1aXJlZCBzb2Z0d2Fy
ZSBhdCB3aWxsLg0KDQpbTHVvd2VuXSBJIHNlZSBpdCBjb3VsZCBiZSBhIG1pZGRsZXdhcmUgb3Ig
c29tZXRoaW5nIGxpa2UgdGhhdC4gTWF5IGJlIGl0IA0KaXMgZWFzeSB0byBpbnN0YWxsIHRoaXMg
bWlkZGxld2FyZSBqdXN0IGFzIHRvIGluc3RhbGwgYSBkcml2ZXIsIGFuZCB0aGUgDQpkZXZlbG9w
ZXJzIGRvbid0IGhhdmUgdG8ga25vdyBob3cgdGhlIElQIG1vYmlsaXR5IGlzIHJlYWxpemVkLCBv
bmx5IG5lZWQgDQp0byBrbm93IGhvdyB0byBpbnZva2UgaXQgaXMgT0suIFdoYXQgaXMgbWlzc2lu
ZyBoZXJlIEkgY291bGQgaW1hZ2UgbWF5YmUgYSANCmd1aWRlbGluZSB0byBndWlkZSB0aGUgZGV2
ZWxvcGVyIHdoaWNoIGtpbmQgb2YgYXBwbGljYWlvbiBuZWVkcyB3aGljaCBraW5kIA0Kb2YgbW9i
aWxpdHkgc3VwcG9ydCAoaS5lIHdpdGggb3Igd2l0aG91dCBtb2JpbGl0eSBzdXBwb3J0KS4gQnV0
IHdoYXQgYXJlIA0KYmVuaWZpdHMgZm9yIGEgZGV2ZWxvcGVyIHRvIGZvbGxvdyB0aGlzIGd1aWRl
bGluZT8gSSBtZWFuLCBpdCB3aWxsIGJlIG11Y2ggDQplYXNpZXIgZm9yIGEgZGV2ZWxwb2VyIGNv
ZGluZyBoaXMgYXBwbGNhdGlvbiBwcm9ncmFtbWUgaWYgYSBzdGFibGUgSVBAIGNhbiANCmJlIGd1
YXJhbnRlZWQuDQoNCkJSDQpMdW93ZW4NCg0KDQoNCg0KDQpqb3VuaSBrb3Job25lbiA8am91bmku
bm9zcGFtQGdtYWlsLmNvbT4gDQoyMDEyLzExLzIwIDE2OjAzDQoNCsrVvP7Iyw0KbHVvLndlbkB6
dGUuY29tLmNuDQqzrcvNDQoiZG1tQGlldGYub3JnIiA8ZG1tQGlldGYub3JnPiwgZG1tLWJvdW5j
ZXNAaWV0Zi5vcmcsIEtvbnN0YW50aW5vcyANClBlbnRpa291c2lzIDxrLnBlbnRpa291c2lzQGh1
YXdlaS5jb20+DQrW98ziDQpSZTogtPC4tDogUmU6IFtETU1dIGNvbW1lbnRzIG9uIGRyYWZ0LWll
dGYtZG1tLXJlcXVpcmVtZW50cy0wMg0KDQoNCg0KDQoNCg0KDQpPbiBOb3YgMjAsIDIwMTIsIGF0
IDk6MDMgQU0sIGx1by53ZW5AenRlLmNvbS5jbiB3cm90ZToNCg0KDQpbc25pcF0NCg0KPiA+PiAg
fEkgd291bGQgbmVlZCB0byBpbXBsZW1lbnQgdGhlICJtb2JpbGl0eSBzdGFjayIgd2hhdGV2ZXIg
c3VwcG9ydCANCmZ1bmN0aW9uDQo+ID4+ICB8YW55d2F5IGV2ZW4gaWYgbm9uZSBvZiBteSBhcHBs
aWNhdGlvbiBjYXJlIGFib3V0IGl0Lg0KPiA+PiANCj4gPj4gSWYgeW91IGFyZSBhYnNvbHV0ZWx5
IHN1cmUgdGhhdCBub25lIG9mIHlvdXIgYXBwcyBuZWVkcyBtb2JpbGl0eSANCnN1cHBvcnQsIGFu
ZCBub25lIHdpbGwgZXZlciBuZWVkIGl0IGluIHRoZSBmdXR1cmUsIHRoZW4gdGhlcmUncyBubyBy
ZWFzb24gDQp0byBpbXBsZW1lbnQgaXQsIHN1cmUuIEJ1dCBpZiB0aGVyZSdzIGEgY2hhbmNlIG9u
ZSBhcHAgbWF5IG5lZWQgaXQgYW5kIDEwMCANCndvbid0LCB0aGVuIHBlcmhhcHMgeW91IGdldCB0
byBpbXBsZW1lbnQgaXQuIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQsIGlmIA0KeW91IGRvIGltcGxl
bWVudCB0aGF0ICJtb2JpbGl0eSBzdGFjayIsIHdpdGggY29uZGl0aW9uYWwgc3VwcG9ydCB5b3Ug
cnVuIA0KdGhhdCBjb2RlIGZvciBvbmUgYXBwIG9ubHkgKGFuZCByb3V0ZSB0aGUgcmVzcGVjdGl2
ZSBwYWNrZXRzIGFjY29yZGluZ2x5KSwgDQp3aGlsZSB3aXRoIHRvZGF5J3MgYXBwcm9hY2ggeW91
IGRvIHRoZSBzYW1lIGZvciAxMDEgYXBwcy4NCj4gDQo+ID4gRmFpciByZWFzb25pbmcuIEhvd2V2
ZXIsIHdoYXQgaXMgdGhlICJtb2JpbGl0eSBzdGFjayIgaGVyZSB0aGVuPyBJcyBpdCANCnNvbWV0
aGluZyB3ZSB0b2RheSB1bmRlcnN0YW5kIGFzIGEgTUlQIGVuYWJsZWQgc3RhY2sgb3IgY291bGQg
aXQgYmUgDQpzb21ldGhpbmcgbW9yZSBnZW5lcmljPyBXaGF0IEkgbWVhbiBoZXJlIGlzIHRoYXQg
d2Ugc2hvdWxkIGJlIHZlcnkgDQpjYXV0aW91cyB3aXRoIE1OIHNpZGUgaW1wYWN0cyBub3QgdG8g
ZnJlYWsgb3V0IGxlc3MgbW9iaWxpdHkgY2F1dGlvdXMgDQpwZW9wbGUuIElmIHRoZSAibW9iaWxp
dHkgc3RhY2siIGNvdWxkIGJlIGJlbmVmaWNpYWwgYWxzbyBvdXRzaWRlIG1vYmlsaXR5IA0KdXNl
IGNhc2VzIHRoYXQgd291bGQgYmUgYXdlc29tZS4NCj4gDQo+IFtMdW93ZW5dIEhpIEpvdW5pLCB3
aGF0IGRvIHlvdSBtZWFuICJXaGF0IEkgbWVhbiBoZXJlIGlzIHRoYXQgd2Ugc2hvdWxkIA0KYmUg
dmVyeSBjYXV0aW91cyB3aXRoIE1OIHNpZGUgaW1wYWN0cyBub3QgdG8gZnJlYWsgb3V0IGxlc3Mg
bW9iaWxpdHkgDQpjYXV0aW91cyBwZW9wbGUiID8gIFRoZSBhcHBsaWNhaW9ucyBvbiB0aGUgbW9i
aWxlIG5vZGUgZG9lc24ndCBuZWVkIHRvIA0KdW5kZXJzdGFuZCB3aGF0IGlzIHRoZSBtb2JpbGl0
eSAoaS5lLiB0aGUNCg0KSSBtZWFuIHRoZSBiZWxvdyB0aGUgImFwcGxpY2F0aW9ucyB0aGF0IGFu
eSByYW5kb20gZGV2ZWxvcGVyIGNhbiBkbyIgDQpzdXBwb3J0Li4gaS5lLiBtaWRkbGV3YXJlLCB2
ZW5kb3IgQVBJcywgT1MgJiBJUCBzdGFjayBsZXZlbCB0aGluZ3MgZXRjLiANCkZvciBleGFtcGxl
LCBpZiB0aGUgIm1vYmlsaXR5IHN0YWNrIiBuZWVkcyB0byBob29rIGRlZXAgaW5zaWRlIHRoZSBJ
UCANCnN0YWNrLCBpdCBiYXNpY2FsbHkgaGFzIHRvIGJlIHBhcnQgb2YgdGhlIHBsYXRmb3JtIGxl
dmVsIGJhc2VsaW5lIHNvZnR3YXJlIA0KdG8gYmUgc3VjY2Vzc2Z1bC4gSWYgdGhlICJtb2JpbGl0
eSBzdGFjayIgaXMgc29tZXRoaW5nIHRoYXQganVzdCByZXF1aXJlcyANCmhpZ2hlciBwcml2aWxl
Z2VzIChsaWtlIGluc3RhbGxpbmcgYSBkcml2ZXIpIHRoYW4gYSBjb25zdW1lciBoYXMsIHRoZW4g
DQpvcGVyYXRvcnMgJiBlbnRlcnByaXNlcyBjYW4gZGlzdHJpYnV0ZSByZXF1aXJlZCBzb2Z0d2Fy
ZSBhdCB3aWxsLg0KDQotIEpvdW5pDQoNCj4gIGFwcGxpY2F0aW9uIGRldmVsb3BlciBkb2Vzbid0
IG5lZWQgdG8gdW5kZXJzdGFuZCksIGFuZCBpdCBzZWVtcyB0byBsZXQgDQphbiBvcmRpbmFyeSB1
c2VyIHRvIHVuZGVyc3RhbmQgdGhlIG1vYmlsdHkgY29uY2VwdCBpcyBpbXBvc3NpYmxlLiBBcyBw
ZXIgDQpteSB1bmRlcnN0YW5kaW5nLCB0aGUgYXBwbGljYXRpb24gb25seSBjYXJlIHRvIGJpbmQg
dG8gYW4gSVBAIHdoaWNoIGNhbiANCnN1cnZpdmUgbG9uZ2VyIHRoYW4gaXRzZWxmLiANCg0KDQoN
Cg0KDQo=
--=_alternative 000B3E9148257ABE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEpvdW5pLDwvZm9udD4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgSSBtZWFuIHRoZSBiZWxvdyB0aGUgJnF1b3Q7
YXBwbGljYXRpb25zIHRoYXQNCmFueSByYW5kb20gZGV2ZWxvcGVyIGNhbiBkbyZxdW90OyBzdXBw
b3J0Li4gaS5lLiBtaWRkbGV3YXJlLCB2ZW5kb3IgQVBJcywNCk9TICZhbXA7IElQIHN0YWNrIGxl
dmVsIHRoaW5ncyBldGMuIEZvciBleGFtcGxlLCBpZiB0aGUgJnF1b3Q7bW9iaWxpdHkNCnN0YWNr
JnF1b3Q7IG5lZWRzIHRvIGhvb2sgZGVlcCBpbnNpZGUgdGhlIElQIHN0YWNrLCBpdCBiYXNpY2Fs
bHkgaGFzIHRvDQpiZSBwYXJ0IG9mIHRoZSBwbGF0Zm9ybSBsZXZlbCBiYXNlbGluZSBzb2Z0d2Fy
ZSB0byBiZSBzdWNjZXNzZnVsLiBJZiB0aGUNCiZxdW90O21vYmlsaXR5IHN0YWNrJnF1b3Q7IGlz
IHNvbWV0aGluZyB0aGF0IGp1c3QgcmVxdWlyZXMgaGlnaGVyIHByaXZpbGVnZXMNCihsaWtlIGlu
c3RhbGxpbmcgYSBkcml2ZXIpIHRoYW4gYSBjb25zdW1lciBoYXMsIHRoZW4gb3BlcmF0b3JzICZh
bXA7IGVudGVycHJpc2VzDQpjYW4gZGlzdHJpYnV0ZSByZXF1aXJlZCBzb2Z0d2FyZSBhdCB3aWxs
LjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+W0x1b3dlbl0gSSBzZWUg
aXQgY291bGQgYmUgYSBtaWRkbGV3YXJlIG9yIHNvbWV0aGluZw0KbGlrZSB0aGF0LiBNYXkgYmUg
aXQgaXMgZWFzeSB0byBpbnN0YWxsIHRoaXMgbWlkZGxld2FyZSBqdXN0IGFzIHRvIGluc3RhbGwN
CmEgZHJpdmVyLCBhbmQgdGhlIGRldmVsb3BlcnMgZG9uJ3QgaGF2ZSB0byBrbm93IGhvdyB0aGUg
SVAgbW9iaWxpdHkgaXMNCnJlYWxpemVkLCBvbmx5IG5lZWQgdG8ga25vdyBob3cgdG8gaW52b2tl
IGl0IGlzIE9LLiBXaGF0IGlzIG1pc3NpbmcgaGVyZQ0KSSBjb3VsZCBpbWFnZSBtYXliZSBhIGd1
aWRlbGluZSB0byBndWlkZSB0aGUgZGV2ZWxvcGVyIHdoaWNoIGtpbmQgb2YgYXBwbGljYWlvbg0K
bmVlZHMgd2hpY2gga2luZCBvZiBtb2JpbGl0eSBzdXBwb3J0IChpLmUgd2l0aCBvciB3aXRob3V0
IG1vYmlsaXR5IHN1cHBvcnQpLg0KQnV0IHdoYXQgYXJlIGJlbmlmaXRzIGZvciBhIGRldmVsb3Bl
ciB0byBmb2xsb3cgdGhpcyBndWlkZWxpbmU/IEkgbWVhbiwNCml0IHdpbGwgYmUgbXVjaCBlYXNp
ZXIgZm9yIGEgZGV2ZWxwb2VyIGNvZGluZyBoaXMgYXBwbGNhdGlvbiBwcm9ncmFtbWUNCmlmIGEg
c3RhYmxlIElQQCBjYW4gYmUgZ3VhcmFudGVlZC48L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPkx1b3dlbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi
cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5qb3VuaSBrb3Job25lbiAmbHQ7am91bmku
bm9zcGFtQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i
c2Fucy1zZXJpZiI+MjAxMi8xMS8yMCAxNjowMzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFi
bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48
Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5sdW8ud2VuQHp0ZS5jb20uY248L2ZvbnQ+DQo8
dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPiZxdW90O2RtbUBpZXRmLm9yZyZxdW90OyAmbHQ7ZG1tQGlldGYub3JnJmd0OywN
CmRtbS1ib3VuY2VzQGlldGYub3JnLCBLb25zdGFudGlub3MgUGVudGlrb3VzaXMgJmx0O2sucGVu
dGlrb3VzaXNAaHVhd2VpLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk
aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+
PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiC08Li0OiBSZTog
W0RNTV0gY29tbWVudHMgb24gZHJhZnQtaWV0Zi1kbW0tcmVxdWlyZW1lbnRzLTAyPC9mb250Pjwv
dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl
Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpP
biBOb3YgMjAsIDIwMTIsIGF0IDk6MDMgQU0sIGx1by53ZW5AenRlLmNvbS5jbiB3cm90ZTo8YnI+
DQo8YnI+DQo8YnI+DQpbc25pcF08YnI+DQo8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwO3xJIHdv
dWxkIG5lZWQgdG8gaW1wbGVtZW50IHRoZSAmcXVvdDttb2JpbGl0eSBzdGFjayZxdW90Ow0Kd2hh
dGV2ZXIgc3VwcG9ydCBmdW5jdGlvbjxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7fGFueXdheSBl
dmVuIGlmIG5vbmUgb2YgbXkgYXBwbGljYXRpb24gY2FyZSBhYm91dCBpdC48YnI+DQomZ3Q7ICZn
dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSWYgeW91IGFyZSBhYnNvbHV0ZWx5IHN1cmUgdGhh
dCBub25lIG9mIHlvdXIgYXBwcyBuZWVkcyBtb2JpbGl0eQ0Kc3VwcG9ydCwgYW5kIG5vbmUgd2ls
bCBldmVyIG5lZWQgaXQgaW4gdGhlIGZ1dHVyZSwgdGhlbiB0aGVyZSdzIG5vIHJlYXNvbg0KdG8g
aW1wbGVtZW50IGl0LCBzdXJlLiBCdXQgaWYgdGhlcmUncyBhIGNoYW5jZSBvbmUgYXBwIG1heSBu
ZWVkIGl0IGFuZA0KMTAwIHdvbid0LCB0aGVuIHBlcmhhcHMgeW91IGdldCB0byBpbXBsZW1lbnQg
aXQuIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQsDQppZiB5b3UgZG8gaW1wbGVtZW50IHRoYXQgJnF1
b3Q7bW9iaWxpdHkgc3RhY2smcXVvdDssIHdpdGggY29uZGl0aW9uYWwgc3VwcG9ydA0KeW91IHJ1
biB0aGF0IGNvZGUgZm9yIG9uZSBhcHAgb25seSAoYW5kIHJvdXRlIHRoZSByZXNwZWN0aXZlIHBh
Y2tldHMgYWNjb3JkaW5nbHkpLA0Kd2hpbGUgd2l0aCB0b2RheSdzIGFwcHJvYWNoIHlvdSBkbyB0
aGUgc2FtZSBmb3IgMTAxIGFwcHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgRmFpciByZWFz
b25pbmcuIEhvd2V2ZXIsIHdoYXQgaXMgdGhlICZxdW90O21vYmlsaXR5IHN0YWNrJnF1b3Q7DQpo
ZXJlIHRoZW4/IElzIGl0IHNvbWV0aGluZyB3ZSB0b2RheSB1bmRlcnN0YW5kIGFzIGEgTUlQIGVu
YWJsZWQgc3RhY2sgb3INCmNvdWxkIGl0IGJlIHNvbWV0aGluZyBtb3JlIGdlbmVyaWM/IFdoYXQg
SSBtZWFuIGhlcmUgaXMgdGhhdCB3ZSBzaG91bGQNCmJlIHZlcnkgY2F1dGlvdXMgd2l0aCBNTiBz
aWRlIGltcGFjdHMgbm90IHRvIGZyZWFrIG91dCBsZXNzIG1vYmlsaXR5IGNhdXRpb3VzDQpwZW9w
bGUuIElmIHRoZSAmcXVvdDttb2JpbGl0eSBzdGFjayZxdW90OyBjb3VsZCBiZSBiZW5lZmljaWFs
IGFsc28gb3V0c2lkZQ0KbW9iaWxpdHkgdXNlIGNhc2VzIHRoYXQgd291bGQgYmUgYXdlc29tZS48
YnI+DQomZ3Q7IDxicj4NCiZndDsgW0x1b3dlbl0gSGkgSm91bmksIHdoYXQgZG8geW91IG1lYW4g
JnF1b3Q7V2hhdCBJIG1lYW4gaGVyZSBpcyB0aGF0DQp3ZSBzaG91bGQgYmUgdmVyeSBjYXV0aW91
cyB3aXRoIE1OIHNpZGUgaW1wYWN0cyBub3QgdG8gZnJlYWsgb3V0IGxlc3MgbW9iaWxpdHkNCmNh
dXRpb3VzIHBlb3BsZSZxdW90OyA/ICZuYnNwO1RoZSBhcHBsaWNhaW9ucyBvbiB0aGUgbW9iaWxl
IG5vZGUgZG9lc24ndA0KbmVlZCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgdGhlIG1vYmlsaXR5IChp
LmUuIHRoZTxicj4NCjxicj4NCkkgbWVhbiB0aGUgYmVsb3cgdGhlICZxdW90O2FwcGxpY2F0aW9u
cyB0aGF0IGFueSByYW5kb20gZGV2ZWxvcGVyIGNhbiBkbyZxdW90Ow0Kc3VwcG9ydC4uIGkuZS4g
bWlkZGxld2FyZSwgdmVuZG9yIEFQSXMsIE9TICZhbXA7IElQIHN0YWNrIGxldmVsIHRoaW5ncw0K
ZXRjLiBGb3IgZXhhbXBsZSwgaWYgdGhlICZxdW90O21vYmlsaXR5IHN0YWNrJnF1b3Q7IG5lZWRz
IHRvIGhvb2sgZGVlcA0KaW5zaWRlIHRoZSBJUCBzdGFjaywgaXQgYmFzaWNhbGx5IGhhcyB0byBi
ZSBwYXJ0IG9mIHRoZSBwbGF0Zm9ybSBsZXZlbA0KYmFzZWxpbmUgc29mdHdhcmUgdG8gYmUgc3Vj
Y2Vzc2Z1bC4gSWYgdGhlICZxdW90O21vYmlsaXR5IHN0YWNrJnF1b3Q7IGlzDQpzb21ldGhpbmcg
dGhhdCBqdXN0IHJlcXVpcmVzIGhpZ2hlciBwcml2aWxlZ2VzIChsaWtlIGluc3RhbGxpbmcgYSBk
cml2ZXIpDQp0aGFuIGEgY29uc3VtZXIgaGFzLCB0aGVuIG9wZXJhdG9ycyAmYW1wOyBlbnRlcnBy
aXNlcyBjYW4gZGlzdHJpYnV0ZSByZXF1aXJlZA0Kc29mdHdhcmUgYXQgd2lsbC48YnI+DQo8YnI+
DQotIEpvdW5pPGJyPg0KPGJyPg0KJmd0OyAmbmJzcDthcHBsaWNhdGlvbiBkZXZlbG9wZXIgZG9l
c24ndCBuZWVkIHRvIHVuZGVyc3RhbmQpLCBhbmQgaXQgc2VlbXMNCnRvIGxldCBhbiBvcmRpbmFy
eSB1c2VyIHRvIHVuZGVyc3RhbmQgdGhlIG1vYmlsdHkgY29uY2VwdCBpcyBpbXBvc3NpYmxlLg0K
QXMgcGVyIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBhcHBsaWNhdGlvbiBvbmx5IGNhcmUgdG8gYmlu
ZCB0byBhbiBJUEAgd2hpY2gNCmNhbiBzdXJ2aXZlIGxvbmdlciB0aGFuIGl0c2VsZi4gPGJyPg0K
PGJyPg0KPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo=
--=_alternative 000B3E9148257ABE_=--

From luo.wen@zte.com.cn  Wed Nov 21 19:18:43 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E8421E8055; Wed, 21 Nov 2012 19:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.371
X-Spam-Level: 
X-Spam-Status: No, score=-95.371 tagged_above=-999 required=5 tests=[AWL=2.382, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QiSQEtpQDUU; Wed, 21 Nov 2012 19:18:42 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58321E8048; Wed, 21 Nov 2012 19:18:41 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B11C61292E74; Thu, 22 Nov 2012 11:20:07 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAM3IVgd078273; Thu, 22 Nov 2012 11:18:31 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huawei.com>
To: h chan 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Thu, 22 Nov 2012 11:18:24 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-22 11:18:26, Serialize complete at 2012-11-22 11:18:26
Content-Type: multipart/alternative; boundary="=_alternative 00122D1E48257ABE_="
X-MAIL: mse01.zte.com.cn qAM3IVgd078273
Cc: dmm-bounces@ietf.org, "dmm@ietf.org" 
Subject: [DMM] =?gb2312?b?tPC4tDogUmU6ICBNdWx0aWNhc3QgcmVxdWlyZW1lbnRz?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 03:18:43 -0000

This is a multipart message in MIME format.
--=_alternative 00122D1E48257ABE_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgQW50aG9ueSwNCg0KVGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gQW5kIEkgdGhpbmsgdGhlIG1v
dGl2YXRpb24gc2hvdWxkIGJlIGFsc28gDQppbmNsdWRlZC4gVG8gbWUsIHRoZSB0ZXh0IGZyb20g
SnVhbkNhcmxvcyBpcyByZXNhb25hYmxlDQoNCj4gTW90aXZhdGlvbjogVGhlIHB1cnBvc2Ugb2Yg
dGhpcyByZXF1aXJlbWVudCBpcyB0byBlbmNvdXJhZ2UgcGVvcGxlIHRvDQo+ICAgICAgICAgY29u
c2lkZXIgdGhlIGltcGFjdHMgb2YgcnVubmluZyBtdWx0aWNhc3Qgc2VydmljZXMgaW4gYSBETU0N
Cj5lbnZpcm9ubWVudA0K77yeICAgICAgICAgIGZyb20gdGhlIGJlZ2lubmluZyBvZiB0aGUgZGV2
ZWxvcG1lbnQsIHRoZXJlYnkgYXZvaWRpbmcgdGhlDQrvvJ7jgIBuZWVkIHRvDQrvvJ4gICAgICAg
ICBtYWtlIHByb3RvY29sIGV4dGVuc2lvbnMgaW4gdGhlIGZ1dHVyZSB0byBzdXBwb3J0IHRoaXMg
a2luZCBvZg0K77yeICAgICAgICAgZnVuY3Rpb25hbGl0eS4NCg0KVGhhbmtzDQpMdW93ZW4NCg0K
DQoNCg0KaCBjaGFuIDxoLmFudGhvbnkuY2hhbkBodWF3ZWkuY29tPiANCuWPkeS7tuS6ujogIGRt
bS1ib3VuY2VzQGlldGYub3JnDQoyMDEyLzExLzIwIDA2OjI4DQoNCuaUtuS7tuS6ug0KU2VpbCBK
ZW9uIDxzZWlsamVvbkBhdi5pdC5wdD4sICJwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tIiANCjxw
aWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPg0K5oqE6YCBDQoiZG1tQGlldGYub3JnIiA8ZG1tQGll
dGYub3JnPg0K5Li76aKYDQpSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50cw0KDQoNCg0K
DQoNCg0KVGhlcmUgYXJlIDMgcHJvcG9zYWxzIGZvciBtdWx0aWNhc3QgcmVxdWlyZW1lbnRzLiBC
ZWZvcmUgY29tcGFyaW5nIHRoZXNlIA0KcHJvcG9zYWxzLCBsZXQgdXMgdW5kZXJzdGFuZCB3aGF0
IGFyZSB0aGUgcHJvYmxlbXMgZmlyc3QuIFR3byBwcm9ibGVtIA0Kc3RhdGVtZW50cyBoYXZlIGJl
ZW4gcHJvcG9zZWQ6DQogDQpQUzEgKHJldmlzZWQpOiBOb24tb3B0aW1hbCByb3V0ZXMNClJvdXRp
bmcgdmlhIGEgY2VudHJhbGl6ZWQgYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBsb25nZXIgcm91
dGUuIFRoZSANCnByb2JsZW0gaXMgZXNwZWNpYWxseSBtYW5pZmVzdGVkIHdoZW4gYWNjZXNzaW5n
IGEgbG9jYWwgc2VydmVyIG9yIHNlcnZlcnMgDQpvZiBhIENvbnRlbnQgRGVsaXZlcnkgTmV0d29y
ayAoQ0ROKSwgb3Igd2hlbiByZWNlaXZpbmcgLyBzZW5kaW5nIElQIA0KbXVsdGljYXN0IHBhY2tl
dHMuIA0KUFM2OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWMNCklQIG11bHRpY2FzdCBkaXN0
cmlidXRpb24gb3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyAN
Cm1heSBsZWFkIHRvIGNvbnZlcmdlbmNlIG9mIGR1cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlw
dGlvbnMgdG93YXJkcyB0aGUgDQp0dW5uZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1B
RyBpbiBQTUlQdjYpLiAgQ29uY3JldGVseSwgd2hlbiANCm11bHRpY2FzdCBzdWJzY3JpcHRpb24g
Zm9yIGluZGl2aWR1YWwgbW9iaWxlIG5vZGVzIGlzIGNvdXBsZWQgd2l0aCANCm1vYmlsaXR5IHR1
bm5lbHMsIGR1cGxpY2F0ZSBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJl
IA0KcmVjZWl2ZWQgdGhyb3VnaCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJvYmxl
bSBpcyBwb3RlbnRpYWxseSANCm1vcmUgc2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkg
ZW52aXJvbm1lbnQgDQpbZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAz
XS4NCiANClRoZW4sIGxldCB1cyBzZWUgd2hldGhlciBhbGwgdGhlIDMgUkVRIHByb3Bvc2FscyBo
YXZlIHRoZSBzYW1lIGludGVudGlvbi4gDQpJbiB0aGUgZm9sbG93aW5nLCBJIHJlcGhyYXNlIHRo
ZW0gdG8gaGlnaGxpZ2h0IHRoZWlyIHNpbWlsYXJpdGllcy4NCiANClJFUTcuMTogRmxleGlibGUg
bXVsdGljYXN0IGRpc3RyaWJ1dGlvbg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJs
ZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gDQpzY2VuYXJpby4gRXRjLiAN
ClRoZSBNb3RpdmF0aW9uIGlzIHRvIGFsbG93IGZsZXhpYmlsaXR5IGluIChlbmFibGUpIG11bHRp
Y2FzdCBzb2x1dGlvbnMgdG8gDQpzb2x2ZSB0aGUgcHJvYmxlbXMgUFMxIGFuZCBQUzYgYXMgZXhw
bGFpbmVkIGluIHVzZSBjYXNlcyBhbHJlYWR5IHByZXNlbnRlZCANCmFuZCBkaXNjdXNzZWQgaW4g
bXVsdGltb2Igd2cuDQogDQpSRVE3LjI6IA0KRE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxlIHNv
bHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiANCiANCihPcmlnaW5hbCB3b3Jk
aW5nIHdhcyAiVGhlIERNTSAodW5pY2FzdCkgc29sdXRpb24gTVVTVCBiZSBzcGVjaWZpZWQgaW4g
DQpzdWNoIGEgd2F5IHRoYXQgaXQgY2FuIGJlIGV4dGVuZGVkIHRvIGFsc28gc3VwcG9ydCBtdWx0
aWNhc3QgdHJhZmZpYy4iIEkgDQpyZXBocmFzZSBpdCB0byBoaWdobGlnaHQgdGhlIHNpbWlsYXJp
dHkgd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxzIGFuZCBhbHNvIA0KY2hhbmdlZCB0aGUgbXVzdCB0
byBzaG91bGQuKQ0KIA0KUkVRNy4zOg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxlIHNvbHV0
aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcy4NCiANCk9yaWdpbmFsIHdvcmRpbmcg
d2FzIOKAnERNTSBzb2x1dGlvbnMgc2hvdWxkIHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2VzIOKA
piANCmV0Yy4gR2l2ZW4gdGhhdCBpdCBpcyB0aGUgc2NvcGUgb2YgbXVsdGltb2IgYW5kIG5vdCBk
bW0gd2cgdG8gcHJvdmlkZSB0aGUgDQptdWx0aWNhc3Qgc29sdXRpb24sIEkgdGhpbmsg4oCcc3Vw
cG9ydOKAnSBoZXJlIG1lYW5zIOKAnGVuYWJsZeKAnSBzb2x1dGlvbnMgdG8gDQpiZSBkZXZlbG9w
ZWQgKGJ5IG11bHRpbW9iKS4NCiANClNpbWlsYXJpdHkgYW5kIHN1YnRsZSBkaWZmZXJlbmNlczog
Qm90aCBSRVE3LjIgYW5kIFJFUTcuMyB3YW50IHRvIGVuYWJsZSANCm11bHRpY2FzdCBzZXJ2aWNl
cy4gWWV0IHRoZSBleHBsYW5hdGlvbiBpbiBSRVE3LjEgc2VlbXMgdG8gaW5kaWNhdGUgbm90IA0K
anVzdCB0byBlbmFibGUgYW55IG9uZSBtdWx0aWNhc3Qgc29sdXRpb24gYnV0IGFsc28gbmVlZHMg
dGhlIGZsZXhpYmlsaXR5IA0KaW4gbXVsdGljYXN0IHNvbHV0aW9uLiBOb3QgYWxsIG11bHRpY2Fz
dCBzb2x1dGlvbnMgYXJlIHRoZSBzYW1lLiBTb21lIG9mIA0KdGhlbSByZXN1bHRzIGluIFBTMSBv
ciBQUzYuIA0KIA0KQXJlIHRoZXJlIGFueSBhcmUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdl
ZW46DQpJbiBSRVE3LjEsIERNTSBzb2x1dGlvbnMgc2hvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBm
bGV4aWJsZSBtdWx0aWNhc3QgDQpkaXN0cmlidXRpb24gc2NlbmFyaW8sIGV0Yy4gDQpWZXJzdXMN
CkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJl
IGNvbXBhdGlibGUgd2l0aCANCm11bHRpY2FzdCBkaXN0cmlidXRpb24gc2NlbmFyaW8sIGV0Yy4N
CiANCkggQW50aG9ueSBDaGFuIA0KIA0KRnJvbTogZG1tLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0
bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNlaWwgDQpKZW9uDQpTZW50OiBN
b25kYXksIE5vdmVtYmVyIDE5LCAyMDEyIDU6MTUgQU0NClRvOiBwaWVycmljay5zZWl0ZUBvcmFu
Z2UuY29tDQpDYzogZG1tQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RNTV0gTXVsdGljYXN0IHJl
cXVpcmVtZW50cw0KIA0KSGkgUGllcnJpY2ssDQogDQpJ4oCZdmUgbWFueSB0aW1lcyB0aG91Z2h0
IGFib3V0IHlvdXIgcXVlc3Rpb24uIEkgd291bGQgc2F5IGhvdyBlZmZlY3RpdmVseSANCnNob3Vs
ZCB3ZSBkZXBsb3kvc3VwcG9ydCBtdWx0aWNhc3Qgb3ZlciBkaXN0cmlidXRlZCBtb2JpbGl0eSBy
YXRoZXIgdGhhbiANCmRpc3RyaWJ1dGVkIG1vYmlsZSBtdWx0aWNhc3QuIEFzIGEgcmVzdWx0LCB5
b3UgY2FuIGZpbmQgdGhpcyBkZXBsb3ltZW50IA0KdXNlIGNhc2UgYW5kIGdhcCBhbmFseXNpcyBh
dCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9i
LXVzZS1jYXNlLWRtbS0wMyANCnByZXNlbnRlZCBpbiBtdWx0aW1vYiBzZXZlcmFsIHRpbWVzLg0K
IA0KSW4gdW5pY2FzdCBETU0sIG1haW4gaW5ub3ZhdGlvbiBpcyB0byBkaXN0cmlidXRlIHRoZSBh
bmNob3IgZnVuY3Rpb24gYXQgDQptYW55IGFjY2VzcyByb3V0ZXJzIGZyb20gc2luZ2xlIGNvcmUu
IEZvbGxvd2luZyBhcmNoaXRlY3R1cmFsIGNvbmNlcHQgb2YgDQpETU0sIGZsZXhpYmxlIG11bHRp
Y2FzdCBkaXN0cmlidXRpb24gaXMgb25lIG9mIG11bHRpY2FzdCByZXF1aXJlbWVudCANCnJlc3Vs
dGVkIGZyb20gdGhlIGRyYWZ0IGRlc2NyaWJlZCBhYm92ZS4gDQogDQpSRVE4OiBGbGV4aWJsZSBt
dWx0aWNhc3QgZGlzdHJpYnV0aW9uDQoiRE1NIHNvbHV0aW9ucyBTSE9VTEQgYmUgY29tcGF0aWJs
ZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gDQpzY2VuYXJpb3MuIFRoaXMg
ZmxleGliaWxpdHkgZW5hYmxlcyBkaWZmZXJlbnQgSVAgbXVsdGljYXN0IGZsb3dzIHdpdGggDQpy
ZXNwZWN0IHRvIGEgbW9iaWxlIGhvc3QgdG8gYmUgbWFuYWdlZCAoZS5nLiwgc3Vic2NyaWJlZCwg
cmVjZWl2ZWQgYW5kL29yIA0KdHJhbnNtaXR0ZWQpIHVzaW5nIG11bHRpcGxlIGVuZHBvaW50cyIu
IA0KDQpNb3RpdmF0aW9uOiBUaGUgbW90aXZhdGlvbiBmb3IgdGhpcyByZXF1aXJlbWVudCBpcyB0
byBlbmFibGUgZmxleGliaWxpdHkgDQppbiBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uLiBUaGUgbXVs
dGljYXN0IHNvbHV0aW9uIG1heSB0aGVyZWZvcmUgYXZvaWQgDQpoYXZpbmcgbXVsdGljYXN0LWNh
cGFibGUgYWNjZXNzIHJvdXRlcnMgYmVpbmcgcmVzdHJpY3RlZCB0byBtYW5hZ2UgYWxsIElQIA0K
bXVsdGljYXN0IHRyYWZmaWMgcmVsYXRpdmUgdG8gYSBob3N0IHZpYSBhIHNpbmdsZSBlbmRwb2lu
dCAoZS5nLiByZWd1bGFyIA0Kb3IgdHVubmVsIGludGVyZmFjZSksIHdoaWNoIHdvdWxkIGxlYWQg
dG8gdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiBQUzEgDQphbmQgUFM2Lg0KUFM2OiBEdXBsaWNh
dGUgbXVsdGljYXN0IHRyYWZmaWMNCklQIG11bHRpY2FzdCBkaXN0cmlidXRpb24gb3ZlciBhcmNo
aXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyANCm1heSBsZWFkIHRvIGNvbnZl
cmdlbmNlIG9mIGR1cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlwdGlvbnMgdG93YXJkcyB0aGUg
DQp0dW5uZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBpbiBQTUlQdjYpLiAgQ29u
Y3JldGVseSwgd2hlbiANCm11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGluZGl2aWR1YWwgbW9i
aWxlIG5vZGVzIGlzIGNvdXBsZWQgd2l0aCANCm1vYmlsaXR5IHR1bm5lbHMsIGR1cGxpY2F0ZSBt
dWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJlIA0KcmVjZWl2ZWQgdGhyb3Vn
aCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJvYmxlbSBpcyBwb3RlbnRpYWxseSAN
Cm1vcmUgc2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgZW52aXJvbm1lbnQgDQpbZHJh
ZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzXS4NCg0KUmVnYXJkcywNCiAN
ClNlaWwNCiANCkZyb206IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20gW21haWx0bzpwaWVycmlj
ay5zZWl0ZUBvcmFuZ2UuY29tXSANClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIgODo1
NSBBTQ0KVG86ICdrYXJhZ2lhbkBjcy51dHdlbnRlLm5sJzsgc2VpbGplb25AYXYuaXQucHQ7IA0K
SnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbQ0KQ2M6IGRtbUBpZXRmLm9yZw0KU3Vi
amVjdDogUkU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMNCiANCkhpIGFsbCwNCiANCkkg
dGVuZCB0byBhZ3JlZSB3aXRoIEdlb3JnaW91cywgaG93ZXZlciBJIHN0aWxsIGRvIG5vdCBmaWd1
cmUgb3V0IHdoYXQgaXMgDQp0aGUgdXNlLWNhc2UgZm9yIGRpc3RyaWJ1dGVkIG1vYmlsZSBtdWx0
aWNhc3QgKG90aGVyIHRoYW4gYWNhZGVtaWMgDQpjb25zaWRlcmF0aW9ucyk/IENhbiBzb21lb25l
IGdpdmUgY29uY3JldGUgZXhhbXBsZT8gDQogDQpJIGhhdmVu4oCZdCByZWFsIGFsbCBtZXNzYWdl
cyBmcm9tIHRoaXMgdGhyZWFkLiBTbywgbWF5YmUgSSBtaXNzZWQgDQppbXBvcnRhbnQgcG9pbnRz
Lg0KIA0KQlIsDQpQaWVycmljaw0KIA0KRGUgOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv
OmRtbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIA0Ka2FyYWdpYW5AY3MudXR3ZW50
ZS5ubA0KRW52b3nDqSA6IHNhbWVkaSAxNyBub3ZlbWJyZSAyMDEyIDEzOjAxDQrDgCA6IHNlaWxq
ZW9uQGF2Lml0LnB0OyBKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29tDQpDYyA6IGRt
bUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50cw0KIA0K
SGkgYWxsLA0KIA0KSSBhbHNvIGFncmVlIHRoYXQgdGhlIERNTSBzb2x1dGlvbiBzaG91bGQgc29t
ZWhvdyBjb25zaWRlciBtdXRpY2FzdCANCmRlcGxveW1lbnQuIEhvd2V2ZXIsIEkgZG8gbm90IHRo
bmsgdGhhdCB0aGUgRE1NIFdHIGlzIHRoZSByaWdodCBXRyB0byANCnByb3ZpZGUgdGhlIG11bHRp
Y2FzdCBiYXNlZCBETU0gc29sdXRpb24hDQogDQpPbmUgYWx0ZXJuYXRpdmUgc29sdXRpb24gd2ls
bCBiZSB0byBoYXZlIGEgbXVsdGljYXN0IHJlcXVpcmVtZW50IHRoYXQgDQplbXBoYXNpemVzIHRo
ZSBuZWVkIG9mIGhhdmluZyBleHRlbnNpYmlsaXR5IGhvb2tzIChwb3NzaWJpbGl0aWVzKSB0aGF0
IGNhbiANCmJlIHVzZWQgbGF0ZXIgb24gYnkgdGhlIG11bHRpbW9iIFdHIHRvIHByb3ZpZGUgYSAN
CmEgbXVsdGljYXN0IGVuYWJsZWQgRE1NIHNvbHV0aW9uIQ0KIA0KIA0KU28gYSByZXF1aXJlbWVu
dCB0aGF0IHNwZWNpZmllcyBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIGNvdWxkIGJlIHVz
ZWQgDQpmb3IgdGhpcyBwdXJwb3NlOg0KIA0KIlRoZSBETU0gKHVuaWNhc3QpIHNvbHV0aW9uIE1V
U1QgYmUgc3BlY2lmaWVkIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgDQpleHRlbmRlZCB0
byBhbHNvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuIg0KIA0KIA0KQmVzdCByZWdhcmRzLA0K
R2Vvcmdpb3MNCiANCiANCiANCg0KVmFuOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbZG1tLWJvdW5j
ZXNAaWV0Zi5vcmddIG5hbWVucyBTZWlsIEplb24gDQpbc2VpbGplb25AYXYuaXQucHRdDQpWZXJ6
b25kZW46IHZyaWpkYWcgMTYgbm92ZW1iZXIgMjAxMiAyMjoyNQ0KVG86ICdadW5pZ2EsIEp1YW4g
Q2FybG9zJw0KQ2M6IGRtbUBpZXRmLm9yZw0KT25kZXJ3ZXJwOiBSZTogW0RNTV0gTXVsdGljYXN0
IHJlcXVpcmVtZW50cw0KSGkgSnVhbiwNCg0KSSd2ZSBiZWVuIGxvb2tlZCBhdCBjaGFuZ2VkIGZs
b3cgb2YgeW91ciBwcm9wb3NlZCB0ZXh0IGJ1dCBzb3JyeSBub3cgdGhhdCANCm15DQpjb21tZW50
IGlzIHBvc3RlZC4NCkF0IGZpcnN0IHRpbWUsIEkgY291bGRuJ3QgbWFrZSBzdXJlIGhvd2V2ZXIs
IG9uIGhlYXJpbmcgU3RpZydzIA0KZGVzY3JpcHRpb24sDQppdCBzZWVtcyBxdWl0ZSByZWFzb25h
YmxlIGF0IHRoZSBmaXJzdCBzdGVwLCBub3QgZ2l2aW5nIGFueSByZXN0cmljdGlvbnMgDQpidXQN
CmxlYXZpbmcgc29tZS1zcGVjaWZpYyBmb3IgdGhlIERNTSBzb2x1dGlvbiBpdCBkb2VzIG5vdCBz
dXBwb3J0IG11bHRpY2FzdC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGl0IHJlbWFpbnMgYXQgYSBi
YXNpYyBzdGFnZSBmb3IgdGhlIERNTSBzb2x1dGlvbiB0bw0Kc3VwcG9ydCBtdWx0aWNhc3QuDQpT
byBJIHRoaW5rIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG5lZWQgdG8gYmUgbWFkZSBmb3IgdGhl
IERNTSBzb2x1dGlvbiwNCmFjY29yZGluZ2x5LiBCdXQgb2YgY291cnNlLCB0aGlzIHNob3VsZCBu
b3QgYWxzbyBnaXZlIGFueSBzcGVjaWZpYw0KbGltaXRhdGlvbiBhbmQgcmVzdHJpY3Rpb24gYnV0
IHNob3VsZCBiZSBtYWRlIHRvd2FyZHMgdGhlIGRpcmVjdGlvbiBub3QNCmxpbWl0aW5nIHRoZSBi
ZW5lZml0cyBwcm92aWRlZCBieSBkaXN0cmlidXRlZCBkZXBsb3ltZW50Lg0KDQpJIGhvcGUgdG8g
Z2V0IG1vcmUgY29tbWVudHMgb24gdGhpcy4NCg0KUmVnYXJkcywNCg0KU2VpbA0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv
OmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNClp1bmlnYSwgSnVhbiBDYXJsb3MN
ClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgODoxNCBQTQ0KVG86IFN0aWcgVmVuYWFz
OyBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRz
DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGlnIFZlbmFhcyBb
bWFpbHRvOnN0aWdAdmVuYWFzLmNvbV0NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNiwgMjAx
MiAzOjAxIFBNDQo+IFRvOiBqb3VuaSBrb3Job25lbg0KPiBDYzogc2FyaWtheWFAaWVlZS5vcmc7
IFp1bmlnYSwgSnVhbiBDYXJsb3M7IEtvbnN0YW50aW5vcyBQZW50aWtvdXNpczsgDQo+IFBldGVy
IE1jQ2FubjsgZG1tQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVx
dWlyZW1lbnRzDQo+IA0KPiBPbiAxMS8xNS8yMDEyIDM6MTcgQU0sIGpvdW5pIGtvcmhvbmVuIHdy
b3RlOg0KPiA+DQo+ID4gT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFNLCBCZWhjZXQgU2FyaWth
eWEgd3JvdGU6DQo+ID4NCj4gPj4NCj4gPj4gSSB0aGluayB3ZSBhcmUgcmVhZGluZyB0b28gbXVj
aCBpbnRvIG11bHRpY2FzdCBhbmQgdW5pY2FzdCBzaG91bGQNCmJlDQo+ID4+IGRlc2lnbmVkIGlu
IGFuIGludGVncmF0ZWQgbWFubmVyLg0KPiA+Pg0KPiA+PiBUaGUgZmFjdCBpcyB0aGF0IG11bHRp
Y2FzdCBpcyBjb25zaWRlcmVkIGFzIGFuIGFyZWEgb2YNCj4gc3BlY2lhbGl6YXRpb24sDQo+ID4+
IGl0IHJlcXVpcmVzIGtub3dsZWRnZSBvZiB2ZXJ5IGRpZmZlcmVudCBwcm90b2NvbHMgdGhhbiB3
ZSBhcmUgDQo+ID4+IGFjY3VzdG9tZWQgdG8gaW4gbW9iaWxpdHkuDQo+ID4NCj4gPiAiUmVxdWly
ZW1lbnQ6IERNTSBzb2x1dGlvbnMgU0hPVUxEIHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2VzLiBJ
ZiBhDQo+IHNwZWNpZmljIERNTSBzb2x1dGlvbiBkb2VzIG5vdCBzdXBwb3J0IG11bHRpY2FzdCBz
ZXJ2aWNlcywgYW4gDQo+IGV4cGxhbmF0aW9uIE1VU1QgYmUgcHJvdmlkZWQuIg0KPiANCj4gVGhp
cyBzb3VuZHMgZ29vZCB0byBtZS4NCj4gDQo+IFRoZSBtYWluIHRoaW5nIEkgd2FudCB0byBhY2hp
ZXZlIGlzIHdoYXQgd2FzIGRlc2NyaWJlcyBhcyBtb3RpdmF0aW9uIA0KPiBlYXJsaWVyIGluIHRo
aXMgdGhyZWFkLiBNdWx0aWNhc3Qgc2hvdWxkIGF0IGxlYXN0IGJlIGNvbnNpZGVyZWQgd2hlbiAN
Cj4gbG9va2luZyBpbnRvIERNTSBzb2x1dGlvbnMsIGFuZCBub3QganVzdCBhbiBhZnRlcnRob3Vn
aHQgb25jZSB0aGUgDQo+IHNvbHV0aW9uIGlzIGRlY2lkZWQuDQo+IA0KPiBTdGlnDQoNCltKQ1pd
IEkgZnVsbHkgYWdyZWUgd2l0aCB0aGlzLiBUaGF0IHdhcyB0aGUgaW50ZW50aW9uIG9mIHRoZSBw
cm9wb3NlZCANCnRleHQuDQoNClJlZ2FyZHMsDQoNCkp1YW4gQ2FybG9zDQogDQo+IA0KPiA+IFRv
IG1lIHRoYXQgcmVhZHMgYmFzaWNhbGx5ICJkbyBub3QgYnJlYWsgZm91bmRhdGlvbnMgZm9yIG11
bHRpY2FzdA0KPiB1bmxlc3MgeW91IGhhdmUgYSB2YWxpZCAmIGRvY3VtZW50ZWQgcmVhc29uIGZv
ciBpdCIuICBJZiB3ZSBsb29rIGUuZy4NCj4gaW50byBSRkM2MjUgbXVsdGljYXN0IHdvcmRpbmcg
dGhhdCBpcyB0aGVyZSB2ZXJ5IGJyaWVmbHkgYnV0IGdpdmVzIGEgDQo+IGhpbnQgdG8gYSBkZXZl
bG9wZXIgd2hlcmUgdG8gaGVhZCB0by4gVGhhdCBpcyB0aGUgbGV2ZWwgSSB3b3VsZCBleHBlY3Qg
DQo+IERNTSBkb2N1bWVudHMgc2hvdWxkIGFpbSB0by4NCj4gPg0KPiA+IC0gSm91bmkNCj4gPg0K
PiA+DQo+ID4+IExldCBkbW0gZGVhbCB3aXRoIGl0cyBjdXJyZW50IGNoYXJ0ZXIgdGhhdCBkb2Vz
IG5vdCBpbmNsdWRlIGEgd29yZA0KPiBvZg0KPiA+PiBtdWx0aWNhc3QgYW5kIGlmIGV2ZXJ5dGhp
bmcgZ29lcyB3ZWxsIHdlIGNhbiBjb21lIGJhY2sgYW5kIGRpc2N1c3MNCj4gZG1tDQo+ID4+IG11
bHRpY2FzdC4NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4NCj4gPj4gQmVoY2V0DQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBs
aXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpk
bW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQogDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p
bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQpjb25maWRlbnRpZWxsZXMg
b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4
cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiANCnJlY3Ug
Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRl
dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh
Z2VzIA0KZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KRnJh
bmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt
ZXNzYWdlIGEgZXRlIA0KYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCiANClRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv
ciBwcml2aWxlZ2VkIA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsN
CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh
dXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg
cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCANCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20g
LSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgDQptZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp
ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRm
Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KDQo=
--=_alternative 00122D1E48257ABE_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFudGhvbnksPC9mb250Pg0K
PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSBz
dW1tYXJ5LiBBbmQgSSB0aGluaw0KdGhlIG1vdGl2YXRpb24gc2hvdWxkIGJlIGFsc28gaW5jbHVk
ZWQuIFRvIG1lLCB0aGUgdGV4dCBmcm9tIEp1YW5DYXJsb3MNCmlzIHJlc2FvbmFibGU8L2ZvbnQ+
DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IE1vdGl2YXRpb246IFRoZSBwdXJwb3Nl
IG9mIHRoaXMgcmVxdWlyZW1lbnQgaXMNCnRvIGVuY291cmFnZSBwZW9wbGUgdG88YnI+DQomZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25zaWRlciB0aGUgaW1wYWN0cyBvZiBydW5u
aW5nIG11bHRpY2FzdA0Kc2VydmljZXMgaW4gYSBETU08YnI+DQomZ3Q7ZW52aXJvbm1lbnQ8YnI+
DQrvvJ4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Zyb20gdGhlIGJlZ2lubmlu
ZyBvZiB0aGUgZGV2ZWxvcG1lbnQsDQp0aGVyZWJ5IGF2b2lkaW5nIHRoZTxicj4NCu+8nuOAgG5l
ZWQgdG88YnI+DQrvvJ4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1ha2UgcHJvdG9jb2wg
ZXh0ZW5zaW9ucyBpbiB0aGUgZnV0dXJlDQp0byBzdXBwb3J0IHRoaXMga2luZCBvZjxicj4NCu+8
niAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25hbGl0eS48L3R0PjwvZm9udD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlRoYW5rczwvdHQ+PC9mb250Pg0KPGJyPjxmb250
IHNpemU9Mj48dHQ+THVvd2VuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8
dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBz
aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aCBjaGFuICZsdDtoLmFudGhvbnkuY2hhbkBodWF3
ZWkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp
ZiI+5Y+R5Lu25Lq6OiAmbmJzcDtkbW0tYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250
IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLzExLzIwIDA2OjI4PC9mb250Pg0KPHRkIHdp
ZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2
IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2Zv
bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNlaWwgSmVvbiAm
bHQ7c2VpbGplb25AYXYuaXQucHQmZ3Q7LA0KJnF1b3Q7cGllcnJpY2suc2VpdGVAb3JhbmdlLmNv
bSZxdW90OyAmbHQ7cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFs
aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt
c2VyaWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z
ZXJpZiI+JnF1b3Q7ZG1tQGlldGYub3JnJnF1b3Q7ICZsdDtkbW1AaWV0Zi5vcmcmZ3Q7PC9mb250
Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm
YWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPlJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPC9mb250Pjwv
dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl
Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5
N2QgZmFjZT0iQ2FsaWJyaSI+VGhlcmUgYXJlIDMgcHJvcG9zYWxzIGZvcg0KbXVsdGljYXN0IHJl
cXVpcmVtZW50cy4gQmVmb3JlIGNvbXBhcmluZyB0aGVzZSBwcm9wb3NhbHMsIGxldCB1cyB1bmRl
cnN0YW5kDQp3aGF0IGFyZSB0aGUgcHJvYmxlbXMgZmlyc3QuIFR3byBwcm9ibGVtIHN0YXRlbWVu
dHMgaGF2ZSBiZWVuIHByb3Bvc2VkOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm
NDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UFMxIChyZXZpc2VkKTogTm9uLW9wdGltYWwNCnJvdXRl
czwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzMzMzM5OSBmYWNlPSJDYWxpYnJpIj5S
b3V0aW5nIHZpYSBhIGNlbnRyYWxpemVkDQphbmNob3Igb2Z0ZW4gcmVzdWx0cyBpbiBhIGxvbmdl
ciByb3V0ZS4gVGhlIHByb2JsZW0gaXMgZXNwZWNpYWxseSBtYW5pZmVzdGVkDQp3aGVuIGFjY2Vz
c2luZyBhIGxvY2FsIHNlcnZlciBvciBzZXJ2ZXJzIG9mIGEgQ29udGVudCBEZWxpdmVyeSBOZXR3
b3JrDQooQ0ROKSwgPGI+b3Igd2hlbiByZWNlaXZpbmcgLyBzZW5kaW5nIElQIG11bHRpY2FzdCBw
YWNrZXRzPC9iPi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMzMzMzk5IGZhY2U9
IkNhbGlicmkiPlBTNjogRHVwbGljYXRlIG11bHRpY2FzdA0KdHJhZmZpYzwvZm9udD4NCjxicj48
Zm9udCBzaXplPTIgY29sb3I9IzMzMzM5OSBmYWNlPSJDYWxpYnJpIj5JUCBtdWx0aWNhc3QgZGlz
dHJpYnV0aW9uDQpvdmVyIGFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25z
ICZuYnNwO21heSBsZWFkIHRvIGNvbnZlcmdlbmNlDQpvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBz
dWJzY3JpcHRpb25zIHRvd2FyZHMgdGhlIHR1bm5lbOKAmXMgZG93bnN0cmVhbQ0KZW50aXR5IChl
LmcuIE1BRyBpbiBQTUlQdjYpLiAmbmJzcDtDb25jcmV0ZWx5LCB3aGVuIG11bHRpY2FzdCBzdWJz
Y3JpcHRpb24NCmZvciBpbmRpdmlkdWFsIG1vYmlsZSBub2RlcyBpcyBjb3VwbGVkIHdpdGggbW9i
aWxpdHkgdHVubmVscywgZHVwbGljYXRlDQptdWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHBy
b25lIHRvIGJlIHJlY2VpdmVkIHRocm91Z2ggZGlmZmVyZW50IHVwc3RyZWFtDQpwYXRocy4gVGhp
cyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IG1vcmUgc2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9i
aWxpdHkNCmVudmlyb25tZW50IFtkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1k
bW0tMDNdLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNzBjMCBmYWNlPSJDYWxp
YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i
Q2FsaWJyaSI+VGhlbiwgbGV0IHVzIHNlZSB3aGV0aGVyDQphbGwgdGhlIDMgUkVRIHByb3Bvc2Fs
cyBoYXZlIHRoZSBzYW1lIGludGVudGlvbi4gSW4gdGhlIGZvbGxvd2luZywgSSByZXBocmFzZQ0K
dGhlbSB0byBoaWdobGlnaHQgdGhlaXIgc2ltaWxhcml0aWVzLjwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UkVRNy4xOiBGbGV4aWJsZSBt
dWx0aWNhc3QNCmRpc3RyaWJ1dGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm
NDk3ZCBmYWNlPSJDYWxpYnJpIj5ETU0gc29sdXRpb25zIHNob3VsZCBiZSBjb21wYXRpYmxlDQp3
aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gc2NlbmFyaW8uIEV0Yy4gPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoZSBNb3Rp
dmF0aW9uIGlzIHRvIGFsbG93DQpmbGV4aWJpbGl0eSBpbiAoZW5hYmxlKSBtdWx0aWNhc3Qgc29s
dXRpb25zIHRvIHNvbHZlIHRoZSBwcm9ibGVtcyBQUzEgYW5kDQpQUzYgYXMgZXhwbGFpbmVkIGlu
IHVzZSBjYXNlcyBhbHJlYWR5IHByZXNlbnRlZCBhbmQgZGlzY3Vzc2VkIGluIG11bHRpbW9iDQp3
Zy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+
Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli
cmkiPlJFUTcuMjogPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9
IkNhbGlicmkiPkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZQ0Kc29sdXRpb25zIHRvIHN1cHBv
cnQgbXVsdGljYXN0IHRyYWZmaWMuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm
NDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+KE9yaWdpbmFsIHdvcmRpbmcgd2FzICZxdW90O1RoZQ0K
RE1NICh1bmljYXN0KSBzb2x1dGlvbiBNVVNUIGJlIHNwZWNpZmllZCBpbiBzdWNoIGEgd2F5IHRo
YXQgaXQgY2FuIGJlIGV4dGVuZGVkDQp0byBhbHNvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMu
JnF1b3Q7IEkgcmVwaHJhc2UgaXQgdG8gaGlnaGxpZ2h0IHRoZQ0Kc2ltaWxhcml0eSB3aXRoIHRo
ZSBvdGhlciBwcm9wb3NhbHMgYW5kIGFsc28gY2hhbmdlZCB0aGUgbXVzdCB0byBzaG91bGQuKTwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJz
cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+
UkVRNy4zOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp
YnJpIj5ETU0gc29sdXRpb25zIHNob3VsZCBlbmFibGUNCnNvbHV0aW9ucyB0byBzdXBwb3J0IG11
bHRpY2FzdCBzZXJ2aWNlcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg
ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0
OTdkIGZhY2U9IkNhbGlicmkiPk9yaWdpbmFsIHdvcmRpbmcgd2FzIOKAnERNTQ0Kc29sdXRpb25z
IHNob3VsZCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcyDigKYgZXRjLiBHaXZlbiB0aGF0IGl0
IGlzIHRoZQ0Kc2NvcGUgb2YgbXVsdGltb2IgYW5kIG5vdCBkbW0gd2cgdG8gcHJvdmlkZSB0aGUg
bXVsdGljYXN0IHNvbHV0aW9uLCBJIHRoaW5rDQrigJxzdXBwb3J04oCdIGhlcmUgbWVhbnMg4oCc
ZW5hYmxl4oCdIHNvbHV0aW9ucyB0byBiZSBkZXZlbG9wZWQgKGJ5IG11bHRpbW9iKS48L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlNpbWls
YXJpdHkgYW5kIHN1YnRsZSBkaWZmZXJlbmNlczoNCkJvdGggUkVRNy4yIGFuZCBSRVE3LjMgd2Fu
dCB0byBlbmFibGUgbXVsdGljYXN0IHNlcnZpY2VzLiBZZXQgdGhlIGV4cGxhbmF0aW9uDQppbiBS
RVE3LjEgc2VlbXMgdG8gaW5kaWNhdGUgbm90IGp1c3QgdG8gZW5hYmxlIGFueSBvbmUgbXVsdGlj
YXN0IHNvbHV0aW9uDQpidXQgYWxzbyBuZWVkcyB0aGUgZmxleGliaWxpdHkgaW4gbXVsdGljYXN0
IHNvbHV0aW9uLiBOb3QgYWxsIG11bHRpY2FzdA0Kc29sdXRpb25zIGFyZSB0aGUgc2FtZS4gU29t
ZSBvZiB0aGVtIHJlc3VsdHMgaW4gUFMxIG9yIFBTNi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5BcmUgdGhlcmUgYW55IGFyZSBlc3Nl
bnRpYWwNCmRpZmZlcmVuY2VzIGJldHdlZW46PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv
cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkluIFJFUTcuMSwgRE1NIHNvbHV0aW9ucw0Kc2hvdWxk
IGJlIGNvbXBhdGlibGUgd2l0aCBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5h
cmlvLCBldGMuDQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i
Q2FsaWJyaSI+VmVyc3VzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh
Y2U9IkNhbGlicmkiPkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZQ0KbXVsdGljYXN0IHNlcnZp
Y2VzIHdoaWNoIGFyZSBjb21wYXRpYmxlIHdpdGggbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBzY2Vu
YXJpbywNCmV0Yy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i
Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh
Y2U9IkNhbGlicmkiPkggQW50aG9ueSBDaGFuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s
b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IGRtbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86
ZG1tLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNlaWwgSmVvbjxiPjxi
cj4NClNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDE5LCAyMDEyIDU6MTUgQU08Yj48YnI+DQpU
bzo8L2I+IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb208Yj48YnI+DQpDYzo8L2I+IGRtbUBpZXRm
Lm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50
czwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IaSBQaWVycmljayw8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9IkFyaWFsIj5J4oCZdmUgbWFueSB0aW1lcyB0aG91Z2h0IGFib3V0IHlvdXIg
cXVlc3Rpb24uDQpJIHdvdWxkIHNheSBob3cgZWZmZWN0aXZlbHkgc2hvdWxkIHdlIGRlcGxveS9z
dXBwb3J0IG11bHRpY2FzdCBvdmVyIGRpc3RyaWJ1dGVkDQptb2JpbGl0eSByYXRoZXIgdGhhbiBk
aXN0cmlidXRlZCBtb2JpbGUgbXVsdGljYXN0LiBBcyBhIHJlc3VsdCwgeW91IGNhbg0KZmluZCB0
aGlzIGRlcGxveW1lbnQgdXNlIGNhc2UgYW5kIGdhcCBhbmFseXNpcyBhdCA8L2ZvbnQ+PGEgaHJl
Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2It
dXNlLWNhc2UtZG1tLTAzIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNl
LWNhc2UtZG1tLTAzPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4NCnBy
ZXNlbnRlZCBpbiBtdWx0aW1vYiBzZXZlcmFsIHRpbWVzLjwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJp
YWwiPkluIHVuaWNhc3QgRE1NLCBtYWluIGlubm92YXRpb24gaXMgdG8gZGlzdHJpYnV0ZQ0KdGhl
IGFuY2hvciBmdW5jdGlvbiBhdCBtYW55IGFjY2VzcyByb3V0ZXJzIGZyb20gc2luZ2xlIGNvcmUu
IEZvbGxvd2luZw0KYXJjaGl0ZWN0dXJhbCBjb25jZXB0IG9mIERNTSwgZmxleGlibGUgbXVsdGlj
YXN0IGRpc3RyaWJ1dGlvbiBpcyBvbmUgb2YNCm11bHRpY2FzdCByZXF1aXJlbWVudCByZXN1bHRl
ZCBmcm9tIHRoZSBkcmFmdCBkZXNjcmliZWQgYWJvdmUuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt
ZXMgTmV3IFJvbWFuIj5SRVE4OiBGbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZxdW90O0RNTSBzb2x1
dGlvbnMgU0hPVUxEIGJlIGNvbXBhdGlibGUNCndpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3Ry
aWJ1dGlvbiBzY2VuYXJpb3MuIFRoaXMgZmxleGliaWxpdHkgZW5hYmxlcw0KZGlmZmVyZW50IElQ
IG11bHRpY2FzdCBmbG93cyB3aXRoIHJlc3BlY3QgdG8gYSBtb2JpbGUgaG9zdCB0byBiZSBtYW5h
Z2VkDQooZS5nLiwgc3Vic2NyaWJlZCwgcmVjZWl2ZWQgYW5kL29yIHRyYW5zbWl0dGVkKSB1c2lu
ZyBtdWx0aXBsZSBlbmRwb2ludHMmcXVvdDsuDQo8YnI+DQo8YnI+DQpNb3RpdmF0aW9uOiBUaGUg
bW90aXZhdGlvbiBmb3IgdGhpcyByZXF1aXJlbWVudCBpcyB0byBlbmFibGUgZmxleGliaWxpdHkN
CmluIG11bHRpY2FzdCBkaXN0cmlidXRpb24uIFRoZSBtdWx0aWNhc3Qgc29sdXRpb24gbWF5IHRo
ZXJlZm9yZSBhdm9pZCBoYXZpbmcNCm11bHRpY2FzdC1jYXBhYmxlIGFjY2VzcyByb3V0ZXJzIGJl
aW5nIHJlc3RyaWN0ZWQgdG8gbWFuYWdlIGFsbCBJUCBtdWx0aWNhc3QNCnRyYWZmaWMgcmVsYXRp
dmUgdG8gYSBob3N0IHZpYSBhIHNpbmdsZSBlbmRwb2ludCAoZS5nLiByZWd1bGFyIG9yIHR1bm5l
bA0KaW50ZXJmYWNlKSwgd2hpY2ggd291bGQgbGVhZCB0byB0aGUgcHJvYmxlbXMgZGVzY3JpYmVk
IGluIFBTMSBhbmQgUFM2LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj5QUzY6IER1cGxpY2F0ZSBtdWx0aWNhc3QgdHJhZmZpYzwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JUCBtdWx0aWNhc3QgZGlzdHJpYnV0aW9u
IG92ZXINCmFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zICZuYnNwO21h
eSBsZWFkIHRvIGNvbnZlcmdlbmNlDQpvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRp
b25zIHRvd2FyZHMgdGhlIHR1bm5lbOKAmXMgZG93bnN0cmVhbQ0KZW50aXR5IChlLmcuIE1BRyBp
biBQTUlQdjYpLiAmbmJzcDtDb25jcmV0ZWx5LCB3aGVuIG11bHRpY2FzdCBzdWJzY3JpcHRpb24N
CmZvciBpbmRpdmlkdWFsIG1vYmlsZSBub2RlcyBpcyBjb3VwbGVkIHdpdGggbW9iaWxpdHkgdHVu
bmVscywgZHVwbGljYXRlDQptdWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJl
IHJlY2VpdmVkIHRocm91Z2ggZGlmZmVyZW50IHVwc3RyZWFtDQpwYXRocy4gVGhpcyBwcm9ibGVt
IGlzIHBvdGVudGlhbGx5IG1vcmUgc2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkNCmVu
dmlyb25tZW50IFtkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLjxi
cj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlJlZ2FyZHMsPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJBcmlhbCI+U2VpbDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
QXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5G
cm9tOjwvYj4gcGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbSBbbWFpbHRvOnBpZXJyaWNrLnNlaXRl
QG9yYW5nZS5jb21dDQo8Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAx
MiA4OjU1IEFNPGI+PGJyPg0KVG86PC9iPiAna2FyYWdpYW5AY3MudXR3ZW50ZS5ubCc7IHNlaWxq
ZW9uQGF2Lml0LnB0OyBKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29tPGI+PGJyPg0K
Q2M6PC9iPiBkbW1AaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUkU6IFtETU1dIE11bHRp
Y2FzdCByZXF1aXJlbWVudHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh
Y2U9IkNhbGlicmkiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5
N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j
MWY0OTdkIGZhY2U9IkNhbGlicmkiPkkgdGVuZCB0byBhZ3JlZSB3aXRoIEdlb3JnaW91cywNCmhv
d2V2ZXIgSSBzdGlsbCBkbyBub3QgZmlndXJlIG91dCB3aGF0IGlzIHRoZSB1c2UtY2FzZSBmb3Ig
ZGlzdHJpYnV0ZWQNCm1vYmlsZSBtdWx0aWNhc3QgKG90aGVyIHRoYW4gYWNhZGVtaWMgY29uc2lk
ZXJhdGlvbnMpPyBDYW4gc29tZW9uZSBnaXZlDQpjb25jcmV0ZSBleGFtcGxlPyA8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkkgaGF2ZW7i
gJl0IHJlYWwgYWxsIG1lc3NhZ2VzDQpmcm9tIHRoaXMgdGhyZWFkLiBTbywgbWF5YmUgSSBtaXNz
ZWQgaW1wb3J0YW50IHBvaW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5
N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j
MWY0OTdkIGZhY2U9IkNhbGlicmkiPkJSLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9
IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5QaWVycmljazwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RGUgOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0t
Ym91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48
dT5kbW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJU
YWhvbWEiPg0KWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxm
b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmRtbS1ib3VuY2Vz
QGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+
RGUgbGEgcGFydCBkZTwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmthcmFnaWFuQGNzLnV0d2Vu
dGUubmw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5rYXJhZ2lhbkBj
cy51dHdlbnRlLm5sPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+
PGJyPg0KRW52b3nDqSA6PC9iPiBzYW1lZGkgMTcgbm92ZW1icmUgMjAxMiAxMzowMTxiPjxicj4N
CsOAIDo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzpzZWlsamVvbkBhdi5pdC5wdD48Zm9udCBz
aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnNlaWxqZW9uQGF2Lml0LnB0PC91Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250PjxhIGhyZWY9bWFp
bHRvOkp1YW5DYXJsb3MuWnVuaWdhQEludGVyRGlnaXRhbC5jb20+PGZvbnQgc2l6ZT0yIGNvbG9y
PWJsdWUgZmFjZT0iVGFob21hIj48dT5KdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29t
PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KQ2MgOjwv
Yj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9
Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp
emU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCk9iamV0IDo8L2I+IFJlOiBbRE1NXSBNdWx0aWNh
c3QgcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5IaSBh
bGwsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZuYnNwOzwvZm9udD4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5JIGFsc28gYWdyZWUgdGhhdCB0aGUgRE1N
IHNvbHV0aW9uIHNob3VsZA0Kc29tZWhvdyBjb25zaWRlciBtdXRpY2FzdCBkZXBsb3ltZW50LiBI
b3dldmVyLCBJIGRvIG5vdCB0aG5rIHRoYXQgdGhlIERNTQ0KV0cgaXMgdGhlIHJpZ2h0IFdHIHRv
IHByb3ZpZGUgdGhlIG11bHRpY2FzdCBiYXNlZCBETU0gc29sdXRpb24hPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0iVGFob21hIj5PbmUgYWx0ZXJuYXRpdmUgc29sdXRpb24gd2lsbCBiZSB0byBoYXZlDQph
IG11bHRpY2FzdCByZXF1aXJlbWVudCB0aGF0IGVtcGhhc2l6ZXMgdGhlIG5lZWQgb2YgaGF2aW5n
IGV4dGVuc2liaWxpdHkNCmhvb2tzIChwb3NzaWJpbGl0aWVzKSB0aGF0IGNhbiBiZSB1c2VkIGxh
dGVyIG9uIGJ5IHRoZSBtdWx0aW1vYiBXRyB0byBwcm92aWRlDQphIDwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0iVGFob21hIj5hIG11bHRpY2FzdCBlbmFibGVkIERNTSBzb2x1dGlvbiE8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0iVGFob21hIj5TbyBhIHJlcXVpcmVtZW50IHRoYXQgc3BlY2lmaWVzIHNvbWV0aGlu
Zw0KbGlrZSB0aGUgZm9sbG93aW5nIGNvdWxkIGJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZTo8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZxdW90O1RoZSBETU0gKHVuaWNhc3QpIHNvbHV0aW9u
IE1VU1QgYmUNCnNwZWNpZmllZCBpbiBzdWNoIGEgd2F5IHRoYXQgaXQgY2FuIGJlIGV4dGVuZGVk
IHRvIGFsc28gc3VwcG9ydCBtdWx0aWNhc3QNCnRyYWZmaWMuJnF1b3Q7PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0iVGFob21hIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t
YSI+QmVzdCByZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5H
ZW9yZ2lvczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4mbmJzcDs8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZuYnNwOzwvZm9udD4NCjxkaXYgYWxpZ249Y2VudGVy
Pg0KPGJyPg0KPGhyPjwvZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPlZh
bjo8L2I+IDwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250
IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8
L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCltkbW0tYm91bmNlc0Bp
ZXRmLm9yZ10gbmFtZW5zIFNlaWwgSmVvbiBbc2VpbGplb25AYXYuaXQucHRdPGI+PGJyPg0KVmVy
em9uZGVuOjwvYj4gdnJpamRhZyAxNiBub3ZlbWJlciAyMDEyIDIyOjI1PGI+PGJyPg0KVG86PC9i
PiAnWnVuaWdhLCBKdWFuIENhcmxvcyc8Yj48YnI+DQpDYzo8L2I+IDwvZm9udD48YSBocmVmPW1h
aWx0bzpkbW1AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48
dT5kbW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48
Yj48YnI+DQpPbmRlcndlcnA6PC9iPiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50czwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5IaSBKdWFuLDxicj4NCjxicj4N
CkkndmUgYmVlbiBsb29rZWQgYXQgY2hhbmdlZCBmbG93IG9mIHlvdXIgcHJvcG9zZWQgdGV4dCBi
dXQgc29ycnkgbm93IHRoYXQNCm15PGJyPg0KY29tbWVudCBpcyBwb3N0ZWQuPGJyPg0KQXQgZmly
c3QgdGltZSwgSSBjb3VsZG4ndCBtYWtlIHN1cmUgaG93ZXZlciwgb24gaGVhcmluZyBTdGlnJ3Mg
ZGVzY3JpcHRpb24sPGJyPg0KaXQgc2VlbXMgcXVpdGUgcmVhc29uYWJsZSBhdCB0aGUgZmlyc3Qg
c3RlcCwgbm90IGdpdmluZyBhbnkgcmVzdHJpY3Rpb25zDQpidXQ8YnI+DQpsZWF2aW5nIHNvbWUt
c3BlY2lmaWMgZm9yIHRoZSBETU0gc29sdXRpb24gaXQgZG9lcyBub3Qgc3VwcG9ydCBtdWx0aWNh
c3QuPGJyPg0KPGJyPg0KT24gdGhlIG90aGVyIGhhbmQsIGl0IHJlbWFpbnMgYXQgYSBiYXNpYyBz
dGFnZSBmb3IgdGhlIERNTSBzb2x1dGlvbiB0bzxicj4NCnN1cHBvcnQgbXVsdGljYXN0Ljxicj4N
ClNvIEkgdGhpbmsgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgbmVlZCB0byBiZSBtYWRlIGZvciB0
aGUgRE1NIHNvbHV0aW9uLDxicj4NCmFjY29yZGluZ2x5LiBCdXQgb2YgY291cnNlLCB0aGlzIHNo
b3VsZCBub3QgYWxzbyBnaXZlIGFueSBzcGVjaWZpYzxicj4NCmxpbWl0YXRpb24gYW5kIHJlc3Ry
aWN0aW9uIGJ1dCBzaG91bGQgYmUgbWFkZSB0b3dhcmRzIHRoZSBkaXJlY3Rpb24gbm90PGJyPg0K
bGltaXRpbmcgdGhlIGJlbmVmaXRzIHByb3ZpZGVkIGJ5IGRpc3RyaWJ1dGVkIGRlcGxveW1lbnQu
PGJyPg0KPGJyPg0KSSBob3BlIHRvIGdldCBtb3JlIGNvbW1lbnRzIG9uIHRoaXMuPGJyPg0KPGJy
Pg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpTZWlsPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3Vu
Y2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRt
bS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t
YSI+DQpbPC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0
PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpk
bW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhv
bWEiPl0NCk9uIEJlaGFsZiBPZjxicj4NClp1bmlnYSwgSnVhbiBDYXJsb3M8YnI+DQpTZW50OiBG
cmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDg6MTQgUE08YnI+DQpUbzogU3RpZyBWZW5hYXM7IDwv
Zm9udD48YSBocmVmPW1haWx0bzpkbW1AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg
ZmFjZT0iVGFob21hIj48dT5kbW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIg
ZmFjZT0iVGFob21hIj48YnI+DQpTdWJqZWN0OiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVt
ZW50czxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+
DQomZ3Q7IEZyb206IFN0aWcgVmVuYWFzIFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3RpZ0B2ZW5h
YXMuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21h
Ij48dT5tYWlsdG86c3RpZ0B2ZW5hYXMuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZh
Y2U9IlRhaG9tYSI+XTxicj4NCiZndDsgU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNiwgMjAxMiAz
OjAxIFBNPGJyPg0KJmd0OyBUbzogam91bmkga29yaG9uZW48YnI+DQomZ3Q7IENjOiA8L2ZvbnQ+
PGEgaHJlZj1tYWlsdG86c2FyaWtheWFAaWVlZS5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg
ZmFjZT0iVGFob21hIj48dT5zYXJpa2F5YUBpZWVlLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp
emU9MiBmYWNlPSJUYWhvbWEiPjsNClp1bmlnYSwgSnVhbiBDYXJsb3M7IEtvbnN0YW50aW5vcyBQ
ZW50aWtvdXNpczsgPGJyPg0KJmd0OyBQZXRlciBNY0Nhbm47IDwvZm9udD48YSBocmVmPW1haWx0
bzpkbW1AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5k
bW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48YnI+
DQomZ3Q7IFN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IE9uIDExLzE1LzIwMTIgMzoxNyBBTSwgam91bmkga29yaG9uZW4gd3JvdGU6
PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIE5vdiAxNSwgMjAxMiwgYXQgMTowMyBB
TSwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZn
dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgd2UgYXJlIHJlYWRpbmcgdG9vIG11Y2ggaW50
byBtdWx0aWNhc3QgYW5kIHVuaWNhc3QNCnNob3VsZDxicj4NCmJlPGJyPg0KJmd0OyAmZ3Q7Jmd0
OyBkZXNpZ25lZCBpbiBhbiBpbnRlZ3JhdGVkIG1hbm5lci48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7Jmd0OyBUaGUgZmFjdCBpcyB0aGF0IG11bHRpY2FzdCBpcyBjb25zaWRlcmVk
IGFzIGFuIGFyZWEgb2Y8YnI+DQomZ3Q7IHNwZWNpYWxpemF0aW9uLDxicj4NCiZndDsgJmd0OyZn
dDsgaXQgcmVxdWlyZXMga25vd2xlZGdlIG9mIHZlcnkgZGlmZmVyZW50IHByb3RvY29scyB0aGFu
IHdlDQphcmUgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhY2N1c3RvbWVkIHRvIGluIG1vYmlsaXR5Ljxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmcXVvdDtSZXF1aXJlbWVudDogRE1NIHNvbHV0
aW9ucyBTSE9VTEQgc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMuDQpJZiBhPGJyPg0KJmd0OyBz
cGVjaWZpYyBETU0gc29sdXRpb24gZG9lcyBub3Qgc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMs
IGFuIDxicj4NCiZndDsgZXhwbGFuYXRpb24gTVVTVCBiZSBwcm92aWRlZC4mcXVvdDs8YnI+DQom
Z3Q7IDxicj4NCiZndDsgVGhpcyBzb3VuZHMgZ29vZCB0byBtZS48YnI+DQomZ3Q7IDxicj4NCiZn
dDsgVGhlIG1haW4gdGhpbmcgSSB3YW50IHRvIGFjaGlldmUgaXMgd2hhdCB3YXMgZGVzY3JpYmVz
IGFzIG1vdGl2YXRpb24NCjxicj4NCiZndDsgZWFybGllciBpbiB0aGlzIHRocmVhZC4gTXVsdGlj
YXN0IHNob3VsZCBhdCBsZWFzdCBiZSBjb25zaWRlcmVkIHdoZW4NCjxicj4NCiZndDsgbG9va2lu
ZyBpbnRvIERNTSBzb2x1dGlvbnMsIGFuZCBub3QganVzdCBhbiBhZnRlcnRob3VnaHQgb25jZSB0
aGUNCjxicj4NCiZndDsgc29sdXRpb24gaXMgZGVjaWRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsg
U3RpZzxicj4NCjxicj4NCltKQ1pdIEkgZnVsbHkgYWdyZWUgd2l0aCB0aGlzLiBUaGF0IHdhcyB0
aGUgaW50ZW50aW9uIG9mIHRoZSBwcm9wb3NlZCB0ZXh0Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJy
Pg0KPGJyPg0KSnVhbiBDYXJsb3M8YnI+DQogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgVG8g
bWUgdGhhdCByZWFkcyBiYXNpY2FsbHkgJnF1b3Q7ZG8gbm90IGJyZWFrIGZvdW5kYXRpb25zIGZv
cg0KbXVsdGljYXN0PGJyPg0KJmd0OyB1bmxlc3MgeW91IGhhdmUgYSB2YWxpZCAmYW1wOyBkb2N1
bWVudGVkIHJlYXNvbiBmb3IgaXQmcXVvdDsuICZuYnNwO0lmDQp3ZSBsb29rIGUuZy48YnI+DQom
Z3Q7IGludG8gUkZDNjI1IG11bHRpY2FzdCB3b3JkaW5nIHRoYXQgaXMgdGhlcmUgdmVyeSBicmll
Zmx5IGJ1dCBnaXZlcw0KYSA8YnI+DQomZ3Q7IGhpbnQgdG8gYSBkZXZlbG9wZXIgd2hlcmUgdG8g
aGVhZCB0by4gVGhhdCBpcyB0aGUgbGV2ZWwgSSB3b3VsZCBleHBlY3QNCjxicj4NCiZndDsgRE1N
IGRvY3VtZW50cyBzaG91bGQgYWltIHRvLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAt
IEpvdW5pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBM
ZXQgZG1tIGRlYWwgd2l0aCBpdHMgY3VycmVudCBjaGFydGVyIHRoYXQgZG9lcyBub3QgaW5jbHVk
ZQ0KYSB3b3JkPGJyPg0KJmd0OyBvZjxicj4NCiZndDsgJmd0OyZndDsgbXVsdGljYXN0IGFuZCBp
ZiBldmVyeXRoaW5nIGdvZXMgd2VsbCB3ZSBjYW4gY29tZSBiYWNrIGFuZA0KZGlzY3Vzczxicj4N
CiZndDsgZG1tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtdWx0aWNhc3QuPGJyPg0KJmd0OyAmZ3Q7Jmd0
Ozxicj4NCiZndDsgJmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7Jmd0OyBCZWhjZXQ8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9
bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi
Pjx1PmRtbUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh
Y2U9IlRhaG9tYSI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZG1tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9y
PWJsdWUgZmFjZT0iVGFob21hIj48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RtbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NCjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
ZG1tIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhv
bWEiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYub3JnPjxmb250
IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYub3JnPC91PjwvZm9u
dD48L2E+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT48YnI+DQo8L3U+
PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0g
dGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC91PjwvZm9udD48L2E+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg
cGV1dmVudA0KY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp
dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQNCmRvbmM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9IkNvdXJpZXIgTmV3Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcw0K
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUNCnNpZ25hbGVyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD
b3VyaWVyIE5ldyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kNCnF1ZSBsZXMg
cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp
YmxlcyBkJ2FsdGVyYXRpb24sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZQ0KcmVzcG9uc2FiaWxp
dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp
LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoaXMgbWVzc2FnZSBhbmQg
aXRzIGF0dGFjaG1lbnRzIG1heQ0KY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp
bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkNCmxhdzs8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0
ZWQsIHVzZWQNCm9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl
bWFpbCBpbg0KZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0iQ291cmllciBOZXciPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20N
Ci0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm
aWVkLCBjaGFuZ2VkIG9yDQpmYWxzaWZpZWQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl
PSJDb3VyaWVyIE5ldyI+VGhhbmsgeW91LjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcg
bGlzdDxicj4NCmRtbUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZG1tPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo=
--=_alternative 00122D1E48257ABE_=--

From luo.wen@zte.com.cn  Wed Nov 21 19:43:44 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B4421F8660; Wed, 21 Nov 2012 19:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.808
X-Spam-Level: 
X-Spam-Status: No, score=-91.808 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8kCG4vzh0Ak; Wed, 21 Nov 2012 19:43:43 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id AEBF021F865E; Wed, 21 Nov 2012 19:43:42 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id CF0434434A; Thu, 22 Nov 2012 11:43:35 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 939A9705C2C; Thu, 22 Nov 2012 11:41:29 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAM3hMHe020375; Thu, 22 Nov 2012 11:43:22 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <50A654C5.5030601@av.it.pt>
To: =?GB2312?B?U6imcmdpbyBGaWd1ZWlyZWRv?= 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Thu, 22 Nov 2012 11:43:16 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-22 11:43:17, Serialize complete at 2012-11-22 11:43:17
Content-Type: multipart/alternative; boundary="=_alternative 001473D248257ABE_="
X-MAIL: mse01.zte.com.cn qAM3hMHe020375
Cc: dmm-bounces@ietf.org, dmm@ietf.org
Subject: [DMM] =?gb2312?b?tPC4tDogUmU6ICBNdWx0aWNhc3QgcmVxdWlyZW1lbnRz?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 03:43:44 -0000

This is a multipart message in MIME format.
--=_alternative 001473D248257ABE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgIFOopnJnaW8gJiBTZWlsDQoNClRoYW5rcyBmb3IgdGhlIHByb3Bvc2VkIHRleHQuIA0KDQo+
IFJFUTg6IEZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24NCj4gIkRNTSBzb2x1dGlvbnMg
U0hPVUxEIGJlIGNvbXBhdGlibGUgd2l0aCBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9u
IA0Kc2NlbmFyaW9zLiBUaGlzIGZsZXhpYmlsaXR5IGVuYWJsZXMgZGlmZmVyZW50IElQIG11bHRp
Y2FzdCBmbG93cyB3aXRoIA0KcmVzcGVjdCB0byBhIG1vYmlsZSBob3N0IHRvIGJlIG1hbmFnZWQg
KGUuZy4sIHN1YnNjcmliZWQsIHJlY2VpdmVkIGFuZC9vciANCnRyYW5zbWl0dGVkKSB1c2luZyBt
dWx0aXBsZSBlbmRwb2ludHMiLiANCg0KW0x1b3dlbl0gTm90IHF1aXRlIHVuZGVyc3RhbmQgd2hh
dCBpcyBtZWFuaW5nIG9mICIgZmxleGlibGUgbXVsdGljYXN0IA0KZGlzdHJpYnV0aW9uIHNjZW5h
cmlvcyI/ICBBbmQgd2hhdCBpcyAibXVsdGlwbGUgZW5kcG9pbnRzIqO/IEkgaGF2ZSByZWFkIA0K
dGhyb3VnaCB0aGUgZHJhZnQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZmln
dWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDMgDQpyb3VnaGx5IChzb3JyeSwgbm90IGlu
IGRldGFpbGVkKSwgaXQgaW5kZWVkIGRlc2NyaWJlcyBzb21lIHNjZW5hcmlvcyBvZiANCm11bHRp
Y2FzdCB3aXRoIGRtbSBjb25jZXB0LiBCdXQgaXQgZ2l2ZXMgbWUgYW4gaW1wcmVzc2lvbiB0aGF0
IHRoZSANCnNjZW5hcmlvcyBhcmUgYmFzZWQgb24gc29tZSBraW5kIG9mIGFzc3VtZWQgdW5pY2Fz
dCBzb2x1dGlvbiBhbmQgDQphcmNoaXRlY3R1cmUuIEFsc28sIHRoZSB0ZXh0IHByb3Bvc2VkIGhl
cmUgZ2l2ZSBtZSBmZWVsaW5nIHRoYXQgaXQgZmFsbHMgDQppbnRvIHNvbHV0aW9uIHNjb3BlLg0K
QlINCkx1b3dlbg0KDQoNCg0KDQoNCg0KU6imcmdpbyBGaWd1ZWlyZWRvIDxzZmlndWVpcmVkb0Bh
di5pdC5wdD4gDQq3orz+yMs6ICBkbW0tYm91bmNlc0BpZXRmLm9yZw0KMjAxMi8xMS8xNiAyMjo1
OQ0KDQrK1bz+yMsNCmRtbUBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpSZTogW0RNTV0gTXVsdGlj
YXN0IHJlcXVpcmVtZW50cw0KDQoNCg0KDQoNCg0KRGVhciBhbGwsDQoNCkFzIHJlcXVlc3RlZCB3
ZSBoYXZlIGJlZW4gd29ya2luZyBvbiBhIHByb3Bvc2FsIGZvciB1cGRhdGluZyBjdXJyZW50IERN
TSANClJlcXVpcmVtZW50cyBkcmFmdCwgcmVmbGVjdGluZyB0aGUgd29yayBkZXZlbG9wZWQgaW4g
DQoiZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzLnR4dCIuIFdlIHdl
cmUgY2FyZWZ1bCB0byANCmZvbGxvdyB0aGUgZXhwcmVzc2VkIGNvbmNlcm5zLCBtYWlubHkgYnkg
bm90IGltcGFjdGluZyB0aGUgY3VycmVudCAobW9zdGx5IA0KYWNjZXB0ZWQpIGRyYWZ0IHN0cnVj
dHVyZSBhbmQgY29udGVudC4NCkFzIHN1Y2gsIHdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZyAyIGNo
YW5nZXM6DQoNCiMgUHJvcG9zYWwgMSAtIHNtYWxsIHVwZGF0ZSB0byBQUzEgIw0KUFMxOiBOb24t
b3B0aW1hbCByb3V0ZXMgUm91dGluZyB2aWEgYSBjZW50cmFsaXplZCBhbmNob3Igb2Z0ZW4gcmVz
dWx0cyBpbiANCmEgbG9uZ2VyIHJvdXRlLiBUaGUgcHJvYmxlbSBpcyBlc3BlY2lhbGx5IG1hbmlm
ZXN0ZWQgd2hlbiBhY2Nlc3NpbmcgYSANCmxvY2FsIHNlcnZlciBvciBzZXJ2ZXJzIG9mIGEgQ29u
dGVudCBEZWxpdmVyeSBOZXR3b3JrIChDRE4pLCBvciB3aGVuIHVzaW5nIA0KSVAgbXVsdGljYXN0
aW5nLg0KDQojIFByb3Bvc2FsIDIgLSBBZGQgYSBuZXcgcmVxdWlyZW1lbnQjDQpSRVE4OiBGbGV4
aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uDQoiRE1NIHNvbHV0aW9ucyBTSE9VTEQgYmUgY29t
cGF0aWJsZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gDQpzY2VuYXJpb3Mu
IFRoaXMgZmxleGliaWxpdHkgZW5hYmxlcyBkaWZmZXJlbnQgSVAgbXVsdGljYXN0IGZsb3dzIHdp
dGggDQpyZXNwZWN0IHRvIGEgbW9iaWxlIGhvc3QgdG8gYmUgbWFuYWdlZCAoZS5nLiwgc3Vic2Ny
aWJlZCwgcmVjZWl2ZWQgYW5kL29yIA0KdHJhbnNtaXR0ZWQpIHVzaW5nIG11bHRpcGxlIGVuZHBv
aW50cyIuIA0KDQpNb3RpdmF0aW9uOiBUaGUgbW90aXZhdGlvbiBmb3IgdGhpcyByZXF1aXJlbWVu
dCBpcyB0byBlbmFibGUgZmxleGliaWxpdHkgDQppbiBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uLiBU
aGUgbXVsdGljYXN0IHNvbHV0aW9uIG1heSB0aGVyZWZvcmUgYXZvaWQgDQpoYXZpbmcgbXVsdGlj
YXN0LWNhcGFibGUgYWNjZXNzIHJvdXRlcnMgYmVpbmcgcmVzdHJpY3RlZCB0byBtYW5hZ2UgYWxs
IElQIA0KbXVsdGljYXN0IHRyYWZmaWMgcmVsYXRpdmUgdG8gYSBob3N0IHZpYSBhIHNpbmdsZSBl
bmRwb2ludCAoZS5nLiByZWd1bGFyIA0Kb3IgdHVubmVsIGludGVyZmFjZSksIHdoaWNoIHdvdWxk
IGxlYWQgdG8gdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiBQUzEgDQphbmQgUFM2Lg0KUFM2OiBE
dXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWMNCklQIG11bHRpY2FzdCBkaXN0cmlidXRpb24gb3Zl
ciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyANCm1heSBsZWFkIHRv
IGNvbnZlcmdlbmNlIG9mIGR1cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlwdGlvbnMgdG93YXJk
cyB0aGUgDQp0dW5uZWyhr3MgZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2Niku
ICBDb25jcmV0ZWx5LCB3aGVuIA0KbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBmb3IgaW5kaXZpZHVh
bCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIA0KbW9iaWxpdHkgdHVubmVscywgZHVwbGlj
YXRlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJvbmUgdG8gYmUgDQpyZWNlaXZlZCB0
aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlh
bGx5IA0KbW9yZSBzZXZlcmUgaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudCAN
CltkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLg0KDQoNCkJlc3Qg
cmVnYXJkcywNClOopnJnaW8gJiBTZWlsDQoNCg0KT24gMTEvMTIvMjAxMiAxMDo0OSBQTSwgU2Vp
bCBKZW9uIHdyb3RlOg0KSGkgUGV0ZSwNCg0KVGhhdCBtaWdodCBiZSBvbmUgb2YgdGhlbSB3ZSBj
YW4gdGFrZSBvbiBETU0uIEltYWdpbmUsIGRlcGVuZGluZyBvbg0KZGVwbG95bWVudCBvZiBleGlz
dGluZyBJUCBtdWx0aWNhc3Rpbmcgc3RhbmRhcmQgZW50aXRpZXMsIHdlIGNhbiB0aGluayBvZg0K
dmFyaW91cyB1c2UgY2FzZXMgYXMgcHJlc2VudGVkIGluDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDMuDQpEaXJlY3Qg
cm91dGluZyBjYW5ub3QgYmUgYXBwbGllZCBpbiBldmVyeSBzY2VuYXJpby4NCg0KQWZ0ZXIgSSBj
YW1lIGJhY2sgZnJvbSB0aGUgdHJpcCwgd2UgKG1lIGFuZCBTZXJnaW8pIGhhdmUgYmVlbiB3b3Jr
aW5nIG9uDQp0aGlzIHdpdGggcHJpb3JpdHkuIEFmdGVyIGNhcmVmdWxseSByZXZpZXdpbmcgdGhl
IHJlcXVpcmVtZW50IGZyb20gdGhlIHVzZQ0KY2FzZXMsIHdlJ2xsIGFubm91bmNlIGl0IHNvb24u
DQoNClJlZ2FyZHMsDQpTZWlsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBk
bW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgDQpQZXRlcg0KTWNDYW5uDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDEyLCAyMDEyIDk6
NTMgUE0NClRvOiBUaG9tYXMgQy4gU2NobWlkdA0KQ2M6IFN0aWcgVmVuYWFzOyBCZWhjZXQgU2Fy
aWtheWE7IGRtbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJl
bWVudHMNCg0KSW4gdGhlIERNTSBjYXNlIG15IGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgYW5jaG9y
IHBvaW50cyBhcmUgY2xvc2VyIHRvIHRoZQ0KYWNjZXNzIHJvdXRlcnMgYW5kIHRoZXJlZm9yZSBh
cmUgdmVyeSBsaWtlbHkgdG8gYmUgaW4gdGhlIHNhbWUNCmFkbWluaXN0cmF0aXZlIGRvbWFpbi4g
IEluIHRoZXNlIGNhc2VzLCBqb2luaW5nIHRoZSBtdWx0aWNhc3QgZ3JvdXAgDQpkaXJlY3RseQ0K
ZnJvbSB0aGUgYWNjZXNzIHJvdXRlciBnaXZlcyB5b3UgdGhlIHNhbWUgYWNjZXNzIHRvIHRoZSBz
YW1lIG11bHRpY2FzdA0Kc3RyZWFtcyBhbmQgc28gdHVubmVsaW5nIHRoZSBtdWx0aWNhc3QgcGFj
a2V0cyB3b24ndCBiZSBuZWNlc3NhcnkuDQoNCi1QZXRlDQoNClRob21hcyBDLiBTY2htaWR0IHdy
b3RlOg0KDQpEZWFyIFBldGUsDQoNCm11bHRpY2FzdCBtb2JpbGl0eSBtYW5hZ2VtZW50IGlzIGEg
cm91dGUgYWRhcHRhdGlvbiBwcm9ibGVtLiBBcyBpbiB0aGUgDQp1bmljYXN0IGNhc2UsIG1vYmls
aXR5IGNhbiBvbmx5IGJlIHRyZWF0ZWQgYnkgcm91dGluZyBkeW5hbWljcyBpbiANCnRyaXZpYWwg
Y2FzZXMgKHJlLWNvbm5lY3Qgb2YgYSB0dW5uZWwsIHJlLWFzc29jaWF0aW9uIHdpdGggbmV4dCBo
b3ApLg0KT3RoZXJ3aXNlIGl0IGlzIHVud2lzZSB0byBkZWxlZ2F0ZSBtb2JpbGl0eSBhZGFwdGF0
aW9uIHRvIHJvdXRpbmcgDQpwcm90b2NvbHMgKC0+IE9TUEYsIEJHUCAuLi4pLg0KDQpBY2NvcmRp
bmdseSwgaWYgRE1NIGRpc3RyaWJ1dGVzIG1vYmlsaXR5IG9wZXJhdGlvbnMsIGhhbmRvdmVyIA0K
bWFuYWdlbWVudCBzaG91bGQgZm9yZXNlZSBlYXN5IGludGVyY29ubmVjdHMgdG8gcHJldmlvdXMg
ZGlzdHJpYnV0aW9uIA0KdHJlZXMgLSBib3RoIGZvciByZWNlaXZlcnMgYW5kIGZvciBtb2JpbGUg
bXVsdGljYXN0IHNvdXJjZXMuDQoNCkkgZ3Vlc3MsIGlmIERNTSBwZW9wbGUgYXJlIGNhcmVmdWws
IHRoaXMgaXMgbm90IGEgd29ybGQtY2xhc3MgaXRlbSBhbmQgDQpjYW4gYmUgdHJlYXRlZCBhbG9u
ZyB0aGUgbGluZXMgb2YgdW5pY2FzdCBzb2x1dGlvbnMgLSBhbiBpc29sYXRlZCANCm11bHRpY2Fz
dCBwcm90b2NvbCB0cmVhdG1lbnQgKGFzIGhhcyBiZWVuIHByZXZpb3VzbHkgcHJvcG9zZWQgZnJv
bSANCk1VTFRJTU9CIGZvbGtzKSBzZWVtcyBpbmFwcHJvcHJpYXRlLiBJbiBjb3JlIFBNSVAsIG11
bHRpY2FzdCB0cmVhdG1lbnQgDQpoYXMgdHVybmVkIG91dCB0byB3b3JrIG91dCBzaW1wbHkgKC0+
IFJGQzYyMjQpLg0KDQpUaHVzIG15IGFyZ3VtZW50OiB0YWxrIHRvIHRoZSBtdWx0aWNhc3QgZ3V5
cyBiZWZvcmUgYWRvcHRpbmcgYSANCnNvbHV0aW9uIC4uLiBhbmQgbWFrZSB0aGUgcmVzdCBhbiBl
YXN5IGdhbWUuDQoNCkNoZWVycywNCg0KVGhvbWFzDQoNCk9uIDEyLjExLjIwMTIgMjE6MzksIFBl
dGVyIE1jQ2FubiB3cm90ZToNCg0Kam91bmkga29yaG9uZW4gd3JvdGU6DQoNCkZvbGtzLA0KDQpU
aGlzIG1haWwgaXMgdG8ga2ljayBvZmYgdGhlIGRpc2N1c3Npb24gb24gbXVsdGljYXN0IHJlcXVp
cmVtZW50KHMpIA0KZm9yIHRoZSBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDIgZG9jdW1l
bnQuIEkgaG9wZSB3ZSBjYW4gbmFpbCANCmRvd24gdGhlIGVzc2VudGlhbCBtdWx0aWNhc3QgcmVx
dWlyZW1lbnQocykgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KDQpUbyBtZSwgbXVsdGljYXN0IGlu
IGEgRE1NIGVudmlyb25tZW50IG1lYW5zIGpvaW5pbmcgbXVsdGljYXN0IGdyb3VwcyANCmRpcmVj
dGx5IGZyb20gYWNjZXNzIHJvdXRlcnMuICBJdCBtZWFucyByZS1qb2luaW5nIHRoZSBtdWx0aWNh
c3QgdHJlZSANCmZyb20gYSBuZXcgYWNjZXNzIHJvdXRlciBhZnRlciBoYW5kb3Zlci4gIEkgd291
bGQgaG9wZSB0aGF0IHdlIGNhbiANCnVzZSBleGlzdGluZyBNTEQgcHJvdG9jb2xzIGJldHdlZW4g
dGhlIE1OIGFuZCBpdHMgZmlyc3QgaG9wIEFSIHRvIA0KYWNjb21wbGlzaCB0aGlzLg0KDQotUGV0
ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1t
IG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbQ0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnDQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGll
dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcg
bGlzdA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2RtbQ0KDQoNCg==
--=_alternative 001473D248257ABE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3RxbraIj5IaSAmbmJzcDtTqKZyZ2lvICZhbXA7
IFNlaWw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3RxbraIj5UaGFu
a3MgZm9yIHRoZSBwcm9wb3NlZCB0ZXh0LiA8L2ZvbnQ+DQo8YnI+DQo8cD48Zm9udCBzaXplPTIg
ZmFjZT0izqLI7dHFutoiPiZndDsgUkVRODogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlv
bjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSLOosjt0cW62iI+Jmd0OyAmcXVvdDtETU0g
c29sdXRpb25zIFNIT1VMRCBiZQ0KY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBk
aXN0cmlidXRpb24gc2NlbmFyaW9zLiBUaGlzIGZsZXhpYmlsaXR5DQplbmFibGVzIGRpZmZlcmVu
dCBJUCBtdWx0aWNhc3QgZmxvd3Mgd2l0aCByZXNwZWN0IHRvIGEgbW9iaWxlIGhvc3QgdG8gYmUN
Cm1hbmFnZWQgKGUuZy4sIHN1YnNjcmliZWQsIHJlY2VpdmVkIGFuZC9vciB0cmFuc21pdHRlZCkg
dXNpbmcgbXVsdGlwbGUNCmVuZHBvaW50cyZxdW90Oy4gPGJyPg0KPC9mb250Pg0KPHA+PGZvbnQg
c2l6ZT0yIGZhY2U9Is6iyO3RxbraIj5bTHVvd2VuXSBOb3QgcXVpdGUgdW5kZXJzdGFuZCB3aGF0
DQppcyBtZWFuaW5nIG9mICZxdW90OyBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNj
ZW5hcmlvcyZxdW90Oz8gJm5ic3A7QW5kDQp3aGF0IGlzICZxdW90O211bHRpcGxlIGVuZHBvaW50
cyZxdW90O6O/IEkgaGF2ZSByZWFkIHRocm91Z2ggdGhlIGRyYWZ0DQo8YnI+DQo8L2ZvbnQ+PGEg
aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGlt
b2ItdXNlLWNhc2UtZG1tLTAzIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSLOosjt0cW6
2iI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGlt
b2ItdXNlLWNhc2UtZG1tLTAzPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3R
xbraIj4NCnJvdWdobHkgKHNvcnJ5LCBub3QgaW4gZGV0YWlsZWQpLCBpdCBpbmRlZWQgZGVzY3Jp
YmVzIHNvbWUgc2NlbmFyaW9zIG9mDQptdWx0aWNhc3Qgd2l0aCBkbW0gY29uY2VwdC4gQnV0IGl0
IGdpdmVzIG1lIGFuIGltcHJlc3Npb24gdGhhdCB0aGUgc2NlbmFyaW9zDQphcmUgYmFzZWQgb24g
c29tZSBraW5kIG9mIGFzc3VtZWQgdW5pY2FzdCBzb2x1dGlvbiBhbmQgYXJjaGl0ZWN0dXJlLiBB
bHNvLA0KdGhlIHRleHQgcHJvcG9zZWQgaGVyZSBnaXZlIG1lIGZlZWxpbmcgdGhhdCBpdCBmYWxs
cyBpbnRvIHNvbHV0aW9uIHNjb3BlLjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSLOosjt
0cW62iI+QlI8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0izqLI7dHFutoiPkx1b3dlbjwv
Zm9udD4NCjxwPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw
MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPjxiPlOopnJnaW8gRmlndWVpcmVkbyAmbHQ7c2ZpZ3VlaXJlZG9AYXYuaXQucHQm
Z3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+
yMs6ICZuYnNwO2RtbS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPjIwMTIvMTEvMTYgMjI6NTk8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0K
PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln
aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0
ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ZG1tQGlldGYub3JnPC9mb250Pg0KPHRy
IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+
DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m
b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0RNTV0g
TXVsdGljYXN0IHJlcXVpcmVtZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy
IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy
Pg0KPGJyPjxmb250IHNpemU9Mz5EZWFyIGFsbCw8YnI+DQo8YnI+DQpBcyByZXF1ZXN0ZWQgd2Ug
aGF2ZSBiZWVuIHdvcmtpbmcgb24gYSBwcm9wb3NhbCBmb3IgdXBkYXRpbmcgY3VycmVudCBETU0N
ClJlcXVpcmVtZW50cyBkcmFmdCwgcmVmbGVjdGluZyB0aGUgd29yayBkZXZlbG9wZWQgaW4gJnF1
b3Q7ZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzLnR4dCZxdW90Oy4N
CldlIHdlcmUgY2FyZWZ1bCB0byBmb2xsb3cgdGhlIGV4cHJlc3NlZCBjb25jZXJucywgbWFpbmx5
IGJ5IG5vdCBpbXBhY3RpbmcNCnRoZSBjdXJyZW50IChtb3N0bHkgYWNjZXB0ZWQpIGRyYWZ0IHN0
cnVjdHVyZSBhbmQgY29udGVudC48YnI+DQpBcyBzdWNoLCB3ZSBwcm9wb3NlIHRoZSBmb2xsb3dp
bmcgMiBjaGFuZ2VzOjxicj4NCjxicj4NCiMgUHJvcG9zYWwgMSAtIHNtYWxsIHVwZGF0ZSB0byBQ
UzEgIzwvZm9udD4NCjxwPjxmb250IHNpemU9Mz5QUzE6IE5vbi1vcHRpbWFsIHJvdXRlcyBSb3V0
aW5nIHZpYSBhIGNlbnRyYWxpemVkIGFuY2hvcg0Kb2Z0ZW4gcmVzdWx0cyBpbiBhIGxvbmdlciBy
b3V0ZS4gVGhlIHByb2JsZW0gaXMgZXNwZWNpYWxseSBtYW5pZmVzdGVkIHdoZW4NCmFjY2Vzc2lu
ZyBhIGxvY2FsIHNlcnZlciBvciBzZXJ2ZXJzIG9mIGEgQ29udGVudCBEZWxpdmVyeSBOZXR3b3Jr
IChDRE4pLA0KPGI+b3Igd2hlbiB1c2luZyBJUCBtdWx0aWNhc3Rpbmc8L2I+LjwvZm9udD4NCjxw
Pjxmb250IHNpemU9Mz48YnI+DQojIFByb3Bvc2FsIDIgLSBBZGQgYSBuZXcgcmVxdWlyZW1lbnQj
PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zPlJFUTg6IEZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmli
dXRpb248L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+JnF1b3Q7RE1NIHNvbHV0aW9ucyBTSE9VTEQg
YmUgY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxlDQptdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5h
cmlvcy4gVGhpcyBmbGV4aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUA0KbXVsdGljYXN0IGZs
b3dzIHdpdGggcmVzcGVjdCB0byBhIG1vYmlsZSBob3N0IHRvIGJlIG1hbmFnZWQgKGUuZy4sIHN1
YnNjcmliZWQsDQpyZWNlaXZlZCBhbmQvb3IgdHJhbnNtaXR0ZWQpIHVzaW5nIG11bHRpcGxlIGVu
ZHBvaW50cyZxdW90Oy4gPGJyPg0KPGJyPg0KTW90aXZhdGlvbjogVGhlIG1vdGl2YXRpb24gZm9y
IHRoaXMgcmVxdWlyZW1lbnQgaXMgdG8gZW5hYmxlIGZsZXhpYmlsaXR5DQppbiBtdWx0aWNhc3Qg
ZGlzdHJpYnV0aW9uLiBUaGUgbXVsdGljYXN0IHNvbHV0aW9uIG1heSB0aGVyZWZvcmUgYXZvaWQg
aGF2aW5nDQptdWx0aWNhc3QtY2FwYWJsZSBhY2Nlc3Mgcm91dGVycyBiZWluZyByZXN0cmljdGVk
IHRvIG1hbmFnZSBhbGwgSVAgbXVsdGljYXN0DQp0cmFmZmljIHJlbGF0aXZlIHRvIGEgaG9zdCB2
aWEgYSBzaW5nbGUgZW5kcG9pbnQgKGUuZy4gcmVndWxhciBvciB0dW5uZWwNCmludGVyZmFjZSks
IHdoaWNoIHdvdWxkIGxlYWQgdG8gdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiBQUzEgYW5kIFBT
Ni48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+UFM2OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRyYWZm
aWM8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+SVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVy
IGFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkNCnNvbHV0aW9ucyAmbmJzcDttYXkgbGVh
ZCB0byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25zDQp0
b3dhcmRzIHRoZSB0dW5uZWyhr3MgZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2
NikuICZuYnNwO0NvbmNyZXRlbHksDQp3aGVuIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGlu
ZGl2aWR1YWwgbW9iaWxlIG5vZGVzIGlzIGNvdXBsZWQgd2l0aA0KbW9iaWxpdHkgdHVubmVscywg
ZHVwbGljYXRlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJvbmUgdG8gYmUgcmVjZWl2
ZWQNCnRocm91Z2ggZGlmZmVyZW50IHVwc3RyZWFtIHBhdGhzLiBUaGlzIHByb2JsZW0gaXMgcG90
ZW50aWFsbHkgbW9yZSBzZXZlcmUNCmluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgZW52aXJvbm1l
bnQgW2RyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wM10uPGJyPg0KPGJy
Pg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClOopnJnaW8gJmFtcDsgU2VpbDxicj4NCjxicj4N
Cjxicj4NCk9uIDExLzEyLzIwMTIgMTA6NDkgUE0sIFNlaWwgSmVvbiB3cm90ZTo8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0zPjx0dD5IaSBQZXRlLDxicj4NCjxicj4NClRoYXQgbWlnaHQgYmUgb25l
IG9mIHRoZW0gd2UgY2FuIHRha2Ugb24gRE1NLiBJbWFnaW5lLCBkZXBlbmRpbmcgb248YnI+DQpk
ZXBsb3ltZW50IG9mIGV4aXN0aW5nIElQIG11bHRpY2FzdGluZyBzdGFuZGFyZCBlbnRpdGllcywg
d2UgY2FuIHRoaW5rDQpvZjxicj4NCnZhcmlvdXMgdXNlIGNhc2VzIGFzIHByZXNlbnRlZCBpbjxi
cj4NCjwvdHQ+PC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wMyI+PGZvbnQgc2l6ZT0zIGNvbG9y
PWJsdWU+PHR0Pjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNmaWd1ZWlyZWRv
LW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wMzwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z
Pjx0dD4uPGJyPg0KRGlyZWN0IHJvdXRpbmcgY2Fubm90IGJlIGFwcGxpZWQgaW4gZXZlcnkgc2Nl
bmFyaW8uPGJyPg0KPGJyPg0KQWZ0ZXIgSSBjYW1lIGJhY2sgZnJvbSB0aGUgdHJpcCwgd2UgKG1l
IGFuZCBTZXJnaW8pIGhhdmUgYmVlbiB3b3JraW5nIG9uPGJyPg0KdGhpcyB3aXRoIHByaW9yaXR5
LiBBZnRlciBjYXJlZnVsbHkgcmV2aWV3aW5nIHRoZSByZXF1aXJlbWVudCBmcm9tIHRoZQ0KdXNl
PGJyPg0KY2FzZXMsIHdlJ2xsIGFubm91bmNlIGl0IHNvb24uPGJyPg0KPGJyPg0KUmVnYXJkcyw8
YnI+DQpTZWlsPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t
OiA8L3R0PjwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250
IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5kbW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L3R0Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0zPjx0dD4NCls8L3R0PjwvZm9udD48YSBocmVmPSJtYWlsdG86
ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5tYWls
dG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48
dHQ+XQ0KT24gQmVoYWxmIE9mIFBldGVyPGJyPg0KTWNDYW5uPGJyPg0KU2VudDogTW9uZGF5LCBO
b3ZlbWJlciAxMiwgMjAxMiA5OjUzIFBNPGJyPg0KVG86IFRob21hcyBDLiBTY2htaWR0PGJyPg0K
Q2M6IFN0aWcgVmVuYWFzOyBCZWhjZXQgU2FyaWtheWE7IDwvdHQ+PC9mb250PjxhIGhyZWY9bWFp
bHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+ZG1tQGlldGYu
b3JnPC91PjwvdHQ+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PHR0Pjxicj4NClN1YmplY3Q6IFJl
OiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPGJyPg0KPGJyPg0KSW4gdGhlIERNTSBjYXNl
IG15IGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgYW5jaG9yIHBvaW50cyBhcmUgY2xvc2VyIHRvIHRo
ZTxicj4NCmFjY2VzcyByb3V0ZXJzIGFuZCB0aGVyZWZvcmUgYXJlIHZlcnkgbGlrZWx5IHRvIGJl
IGluIHRoZSBzYW1lPGJyPg0KYWRtaW5pc3RyYXRpdmUgZG9tYWluLiAmbmJzcDtJbiB0aGVzZSBj
YXNlcywgam9pbmluZyB0aGUgbXVsdGljYXN0IGdyb3VwDQpkaXJlY3RseTxicj4NCmZyb20gdGhl
IGFjY2VzcyByb3V0ZXIgZ2l2ZXMgeW91IHRoZSBzYW1lIGFjY2VzcyB0byB0aGUgc2FtZSBtdWx0
aWNhc3Q8YnI+DQpzdHJlYW1zIGFuZCBzbyB0dW5uZWxpbmcgdGhlIG11bHRpY2FzdCBwYWNrZXRz
IHdvbid0IGJlIG5lY2Vzc2FyeS48YnI+DQo8YnI+DQotUGV0ZTxicj4NCjxicj4NClRob21hcyBD
LiBTY2htaWR0IHdyb3RlOjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+
RGVhciBQZXRlLDxicj4NCjxicj4NCm11bHRpY2FzdCBtb2JpbGl0eSBtYW5hZ2VtZW50IGlzIGEg
cm91dGUgYWRhcHRhdGlvbiBwcm9ibGVtLiBBcyBpbiB0aGUNCjxicj4NCnVuaWNhc3QgY2FzZSwg
bW9iaWxpdHkgY2FuIG9ubHkgYmUgdHJlYXRlZCBieSByb3V0aW5nIGR5bmFtaWNzIGluIDxicj4N
CnRyaXZpYWwgY2FzZXMgKHJlLWNvbm5lY3Qgb2YgYSB0dW5uZWwsIHJlLWFzc29jaWF0aW9uIHdp
dGggbmV4dCBob3ApLjxicj4NCk90aGVyd2lzZSBpdCBpcyB1bndpc2UgdG8gZGVsZWdhdGUgbW9i
aWxpdHkgYWRhcHRhdGlvbiB0byByb3V0aW5nIDxicj4NCnByb3RvY29scyAoLSZndDsgT1NQRiwg
QkdQIC4uLikuPGJyPg0KPGJyPg0KQWNjb3JkaW5nbHksIGlmIERNTSBkaXN0cmlidXRlcyBtb2Jp
bGl0eSBvcGVyYXRpb25zLCBoYW5kb3ZlciA8YnI+DQptYW5hZ2VtZW50IHNob3VsZCBmb3Jlc2Vl
IGVhc3kgaW50ZXJjb25uZWN0cyB0byBwcmV2aW91cyBkaXN0cmlidXRpb24gPGJyPg0KdHJlZXMg
LSBib3RoIGZvciByZWNlaXZlcnMgYW5kIGZvciBtb2JpbGUgbXVsdGljYXN0IHNvdXJjZXMuPGJy
Pg0KPGJyPg0KSSBndWVzcywgaWYgRE1NIHBlb3BsZSBhcmUgY2FyZWZ1bCwgdGhpcyBpcyBub3Qg
YSB3b3JsZC1jbGFzcyBpdGVtIGFuZA0KPGJyPg0KY2FuIGJlIHRyZWF0ZWQgYWxvbmcgdGhlIGxp
bmVzIG9mIHVuaWNhc3Qgc29sdXRpb25zIC0gYW4gaXNvbGF0ZWQgPGJyPg0KbXVsdGljYXN0IHBy
b3RvY29sIHRyZWF0bWVudCAoYXMgaGFzIGJlZW4gcHJldmlvdXNseSBwcm9wb3NlZCBmcm9tIDxi
cj4NCk1VTFRJTU9CIGZvbGtzKSBzZWVtcyBpbmFwcHJvcHJpYXRlLiBJbiBjb3JlIFBNSVAsIG11
bHRpY2FzdCB0cmVhdG1lbnQNCjxicj4NCmhhcyB0dXJuZWQgb3V0IHRvIHdvcmsgb3V0IHNpbXBs
eSAoLSZndDsgUkZDNjIyNCkuPGJyPg0KPGJyPg0KVGh1cyBteSBhcmd1bWVudDogdGFsayB0byB0
aGUgbXVsdGljYXN0IGd1eXMgYmVmb3JlIGFkb3B0aW5nIGEgPGJyPg0Kc29sdXRpb24gLi4uIGFu
ZCBtYWtlIHRoZSByZXN0IGFuIGVhc3kgZ2FtZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJy
Pg0KVGhvbWFzPGJyPg0KPGJyPg0KT24gMTIuMTEuMjAxMiAyMTozOSwgUGV0ZXIgTWNDYW5uIHdy
b3RlOjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+am91bmkga29yaG9u
ZW4gd3JvdGU6PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5Gb2xrcyw8
YnI+DQo8YnI+DQpUaGlzIG1haWwgaXMgdG8ga2ljayBvZmYgdGhlIGRpc2N1c3Npb24gb24gbXVs
dGljYXN0IHJlcXVpcmVtZW50KHMpIDxicj4NCmZvciB0aGUgZHJhZnQtaWV0Zi1kbW0tcmVxdWly
ZW1lbnRzLTAyIGRvY3VtZW50LiBJIGhvcGUgd2UgY2FuIG5haWwgPGJyPg0KZG93biB0aGUgZXNz
ZW50aWFsIG11bHRpY2FzdCByZXF1aXJlbWVudChzKSBhcyBzb29uIGFzIHBvc3NpYmxlLjxicj4N
CjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KVG8gbWUsIG11bHRpY2Fz
dCBpbiBhIERNTSBlbnZpcm9ubWVudCBtZWFucyBqb2luaW5nIG11bHRpY2FzdCBncm91cHMgPGJy
Pg0KZGlyZWN0bHkgZnJvbSBhY2Nlc3Mgcm91dGVycy4gJm5ic3A7SXQgbWVhbnMgcmUtam9pbmlu
ZyB0aGUgbXVsdGljYXN0IHRyZWUNCjxicj4NCmZyb20gYSBuZXcgYWNjZXNzIHJvdXRlciBhZnRl
ciBoYW5kb3Zlci4gJm5ic3A7SSB3b3VsZCBob3BlIHRoYXQgd2UgY2FuDQo8YnI+DQp1c2UgZXhp
c3RpbmcgTUxEIHByb3RvY29scyBiZXR3ZWVuIHRoZSBNTiBhbmQgaXRzIGZpcnN0IGhvcCBBUiB0
byA8YnI+DQphY2NvbXBsaXNoIHRoaXMuPGJyPg0KPGJyPg0KLVBldGU8YnI+DQo8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWls
aW5nIGxpc3Q8YnI+DQo8L3R0PjwvZm9udD48YSBocmVmPW1haWx0bzpkbW1AaWV0Zi5vcmc+PGZv
bnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHR0Pjx1PmRtbUBpZXRmLm9yZzwvdT48L3R0PjwvZm9udD48
L2E+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQo8L3R0PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0
dD48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvdT48L3R0Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48
Zm9udCBzaXplPTM+PHR0Pjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+
PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJyPg0KPC90dD48L2ZvbnQ+PGEgaHJlZj1t
YWlsdG86ZG1tQGlldGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5kbW1AaWV0
Zi5vcmc8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KPC90dD48L2Zv
bnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbT48Zm9u
dCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kbW08L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KPGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpk
bW0gbWFpbGluZyBsaXN0PGJyPg0KPC90dD48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYu
b3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5kbW1AaWV0Zi5vcmc8L3U+PC90dD48
L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KPC90dD48L2ZvbnQ+PGEgaHJlZj1odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbT48Zm9udCBzaXplPTMgY29sb3I9
Ymx1ZT48dHQ+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L3U+
PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQpkbW1AaWV0Zi5vcmc8YnI+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTxicj4NCjwvdHQ+PC9mb250Pg0K
PGJyPg0K
--=_alternative 001473D248257ABE_=--

From luo.wen@zte.com.cn  Thu Nov 22 00:03:13 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE9721F8833; Thu, 22 Nov 2012 00:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.966
X-Spam-Level: 
X-Spam-Status: No, score=-95.966 tagged_above=-999 required=5 tests=[AWL=1.787, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-ffqHlMF7tQ; Thu, 22 Nov 2012 00:03:11 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 288D921F8834; Thu, 22 Nov 2012 00:03:09 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id A477C1295A2A; Thu, 22 Nov 2012 16:04:34 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAM82sRw012507; Thu, 22 Nov 2012 16:02:54 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <50AC1070.4040408@av.it.pt>
To: =?GB2312?B?U6imcmdpbyBGaWd1ZWlyZWRv?= 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Thu, 22 Nov 2012 16:02:45 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-22 16:02:49, Serialize complete at 2012-11-22 16:02:49
Content-Type: multipart/alternative; boundary="=_alternative 002C366248257ABE_="
X-MAIL: mse01.zte.com.cn qAM82sRw012507
Cc: dmm-bounces@ietf.org, dmm@ietf.org
Subject: [DMM] =?gb2312?b?tPC4tDogUmU6ICBNdWx0aWNhc3QgUFMgdG8gcmVxdWlyZW1l?= =?gb2312?b?bnRz?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 08:03:13 -0000

This is a multipart message in MIME format.
--=_alternative 002C366248257ABE_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgU8Opcmdpbw0KDQo+IFBTNjogRHVwbGljYXRlIG11bHRpY2FzdCB0cmFmZmljDQo+IElQIG11
bHRpY2FzdCBkaXN0cmlidXRpb24gb3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5
IHNvbHV0aW9ucyANCiBtYXkgbGVhZCB0byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRp
Y2FzdCBzdWJzY3JpcHRpb25zIHRvd2FyZHMgdGhlIA0KdHVubmVs4oCZcyBkb3duc3RyZWFtIGVu
dGl0eSAoZS5nLiBNQUcgaW4gUE1JUHY2KS4gID5Db25jcmV0ZWx5LCB3aGVuIA0KbXVsdGljYXN0
IHN1YnNjcmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRo
IA0KbW9iaWxpdHkgdHVubmVscywgZHVwbGljYXRlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykg
aXMgcHJvbmUgdG8gYmUgDQpyZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbSBwYXRo
cy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IA0KbW9yZSBzZXZlcmUgaW4gYSBkaXN0cmli
dXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudCANCltkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11
c2UtY2FzZS1kbW0tMDNdLg0KIA0KPltMdWlzPj5dIFRoaXMgc2VlbXMgbm90IHRvIGJlIGEgcHJv
YmxlbSBvZiB0aGUgSVAgbW9iaWxpdHkgc29sdXRpb25zIA0KaGFuZGxpbmcgbXVsdGljYXN0IHRy
YWZmaWMgd2l0aCBtb2JpbGl0eSB0dW5uZWxzIGluIGdlbmVyYWwsIGJ1dCBhIHByb2JsZW0gDQpv
ZiBjb25zaWRlcmluZyBzZXZlcmFsIHVwc3RyZWFtIHBhdGhzIGVuZGluZyBvbiB0aGUgc2FtZSBt
b2JpbGl0eSBhY2Nlc3MgDQpyb3V0ZXIgYXMgYSBjb25zZXF1ZW5jZSBvZiBleHRlbmRpbmcgdHVu
bmVscyBmcm9tIHByZXZpb3VzTUFSIHRvIG5ld01BUiB0byANCmZvcndhcmQgdGhlIG11bHRpY2Fz
dCB0cmFmZmljLg0KPiBbU0ZdIEV4YWN0bHkuIFdoaWNoIGlzIG1vcmUgdGhhbiBsaWtlbHkgdG8g
aGFwcGVuIGluIGEgRE1NIHNvbHV0aW9uLCANCndoZXJlIGFsbCAibW9iaWxpdHkgZW50aXRpZXMi
IG1heSBhY3QgYXMgIm1vYmlsaXR5IGFjY2VzcyByb3V0ZXJzIiwgYW5kLCANCmFmdGVyIG1vYmls
aXR5LCB3ZSB3YW50IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSB0dW5uZWwgZm9yIHRoZSANCnN1
YnNjcmlwdGlvbi4gSW4gdGhvc2UgY2FzZXMsIGNhcmUgbXVzdCBiZSB0YWtlbiBpbiBvcmRlciB0
byBub3QgZ3JlYXRseSANCm1hZ25pZnkgY29udmVyZ2VuY2UgcHJvYmxlbSBvYnNlcnZlZCBlLmcu
IGluIFJGQzYyMjQuDQpbTHVvd2VuXSBBY2NvcmRpbmcgdG8gdGhlIGFib3ZlIGRpc2N1c3Npb24s
IEkgYmVsaWV2ZSB0aGUgUFM2ICBpcyBiYXNlZCBvbiANCnRoZSB1c2FnZSBzY2VuYXJpb3MgZGlz
Y3Vzc2VkIGluIA0KZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzLiBC
dXQsIGl0IHNlZW1zIHRvIG1lIHRoZSB1c2FnZSANCnNjZW5hcmlvcyBpbiB0aGlzIGRyYWZ0IGlz
IGJhc2VkIG9uIGEgYXNzdW1lZCBkbW0gdW5pY2FzdCBzb2x1dGlvbiBhbmQgDQphcmNoaXRlY3R1
cmUuIElNSE8sIHRoZSBQUyBzaG91bGQgYmUgYmFzZWQgb24gY3VycmVudCBleGlzdGluZyBwcm90
b2NvbCANCihlLmcuIFJGQykgb3IgY3VycmVudCBkZXBsb3ltZW50LCBub3QgYSBhc3N1bWVkIHNv
bHV0aW9uLg0KQlINCkx1b3dlbg0KDQoNCg0KDQoNCg0KU8OpcmdpbyBGaWd1ZWlyZWRvIDxzZmln
dWVpcmVkb0Bhdi5pdC5wdD4gDQrlj5Hku7bkuro6ICBkbW0tYm91bmNlc0BpZXRmLm9yZw0KMjAx
Mi8xMS8yMSAwNzoyMQ0KDQrmlLbku7bkuroNCmRtbUBpZXRmLm9yZw0K5oqE6YCBDQoNCuS4u+mi
mA0KUmU6IFtETU1dIE11bHRpY2FzdCBQUyB0byByZXF1aXJlbWVudHMNCg0KDQoNCg0KDQoNCkhp
IEx1aXMsDQoNCkEgZmV3IG1vcmUgY29tbWVudHMgb24gdGhpcyBpbmxpbmU6DQoNCkVtIDIwLTEx
LTIwMTIgMTk6NDYsIExVSVMgTUlHVUVMIENPTlRSRVJBUyBNVVJJTExPIGVzY3JldmV1Og0KSGkg
QW50aG9ueSwgDQogDQpzb21lIGNvbW1lbnRzIGluIGxpbmUgDQogDQpCZXN0IHJlZ2FyZHMsDQog
DQpMdWlzDQogDQpEZTogZG1tLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkbW0tYm91bmNlc0Bp
ZXRmLm9yZ10gRW4gbm9tYnJlIGRlIGggY2hhbg0KRW52aWFkbyBlbDogbWFydGVzLCAyMCBkZSBu
b3ZpZW1icmUgZGUgMjAxMiAxODo1MQ0KUGFyYTogU8OpcmdpbyBGaWd1ZWlyZWRvOyBkbW1AaWV0
Zi5vcmcNCkFzdW50bzogW0RNTV0gTXVsdGljYXN0IFBTIHRvIHJlcXVpcmVtZW50cw0KIA0KTGV0
IHVzIGFsc28gdXNlIGFub3RoZXIgdGhyZWFkIHRvIGNoZWNrIGZvciBjb25zZW5zdXMgb2YgdGhl
IFBTIGZyb20gDQptdWx0aW1vYi4gDQogDQpQUzEgKHJldmlzZWQpOiBOb24tb3B0aW1hbCByb3V0
ZXMNClJvdXRpbmcgdmlhIGEgY2VudHJhbGl6ZWQgYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBs
b25nZXIgcm91dGUuIFRoZSANCnByb2JsZW0gaXMgZXNwZWNpYWxseSBtYW5pZmVzdGVkIHdoZW4g
YWNjZXNzaW5nIGEgbG9jYWwgc2VydmVyIG9yIHNlcnZlcnMgDQpvZiBhIENvbnRlbnQgRGVsaXZl
cnkgTmV0d29yayAoQ0ROKSwgb3Igd2hlbiByZWNlaXZpbmcgLyBzZW5kaW5nIElQIA0KbXVsdGlj
YXN0IHBhY2tldHMuIA0KW0x1aXM+Pl0gVGhpcyBpcyBjb3JyZWN0IGlmIHRoZSBtdWx0aWNhc3Qg
Y29udGVudCBpcyBsb2NhbGx5IGF2YWlsYWJsZS4gDQpIb3dldmVyIHRoaXMgY291bGQgbm90IGJl
IGFsd2F5cyB0aGUgY2FzZSBmb3IgbXVsdGljYXN0IGxpc3RlbmVycywgZm9yIGEgDQpudW1iZXIg
b2YgcmVhc29ucyAoZm9yIGluc3RhbmNlLCBjb25mbGljdCBpbiB0aGUgbXVsdGljYXN0IGFkZHJl
c3MgDQphbGxvY2F0aW9uIGJldHdlZW4gdGhlIEhvbWUgTmV0d29yayBhbmQgdGhlIERNTSBkb21h
aW4pLiANCltTRl0gU3VyZSwgYW5kIHRoZSBzYW1lIGFwcGxpZXMgdG8gImFjY2Vzc2luZyBhIGxv
Y2FsIHNlcnZlciBhIENETiIgLSBpdCANCmlzIGltcGxpY2l0IHRoYXQgdGhlIGNvbnRlbnQgaXMg
bG9jYWxseSBhdmFpbGFibGUuIEJ1dCBpdCBjYW4gYmUgaW1wcm92ZWQgDQphcyAid2hlbiByZWNl
aXZpbmcgbG9jYWxseSBhdmFpbGFibGUgSVAgbXVsdGljYXN0IG9yIHNlbmRpbmcgSVAgDQptdWx0
aWNhc3QiLg0KDQpQUzY6IER1cGxpY2F0ZSBtdWx0aWNhc3QgdHJhZmZpYw0KSVAgbXVsdGljYXN0
IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRp
b25zIA0KbWF5IGxlYWQgdG8gY29udmVyZ2VuY2Ugb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vi
c2NyaXB0aW9ucyB0b3dhcmRzIHRoZSANCnR1bm5lbOKAmXMgZG93bnN0cmVhbSBlbnRpdHkgKGUu
Zy4gTUFHIGluIFBNSVB2NikuICBDb25jcmV0ZWx5LCB3aGVuIA0KbXVsdGljYXN0IHN1YnNjcmlw
dGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIA0KbW9iaWxp
dHkgdHVubmVscywgZHVwbGljYXRlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJvbmUg
dG8gYmUgDQpyZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBw
cm9ibGVtIGlzIHBvdGVudGlhbGx5IA0KbW9yZSBzZXZlcmUgaW4gYSBkaXN0cmlidXRlZCBtb2Jp
bGl0eSBlbnZpcm9ubWVudCANCltkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1k
bW0tMDNdLg0KIA0KW0x1aXM+Pl0gVGhpcyBzZWVtcyBub3QgdG8gYmUgYSBwcm9ibGVtIG9mIHRo
ZSBJUCBtb2JpbGl0eSBzb2x1dGlvbnMgDQpoYW5kbGluZyBtdWx0aWNhc3QgdHJhZmZpYyB3aXRo
IG1vYmlsaXR5IHR1bm5lbHMgaW4gZ2VuZXJhbCwgYnV0IGEgcHJvYmxlbSANCm9mIGNvbnNpZGVy
aW5nIHNldmVyYWwgdXBzdHJlYW0gcGF0aHMgZW5kaW5nIG9uIHRoZSBzYW1lIG1vYmlsaXR5IGFj
Y2VzcyANCnJvdXRlciBhcyBhIGNvbnNlcXVlbmNlIG9mIGV4dGVuZGluZyB0dW5uZWxzIGZyb20g
cHJldmlvdXNNQVIgdG8gbmV3TUFSIHRvIA0KZm9yd2FyZCB0aGUgbXVsdGljYXN0IHRyYWZmaWMu
DQpbU0ZdIEV4YWN0bHkuIFdoaWNoIGlzIG1vcmUgdGhhbiBsaWtlbHkgdG8gaGFwcGVuIGluIGEg
RE1NIHNvbHV0aW9uLCB3aGVyZSANCmFsbCAibW9iaWxpdHkgZW50aXRpZXMiIG1heSBhY3QgYXMg
Im1vYmlsaXR5IGFjY2VzcyByb3V0ZXJzIiwgYW5kLCBhZnRlciANCm1vYmlsaXR5LCB3ZSB3YW50
IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSB0dW5uZWwgZm9yIHRoZSBzdWJzY3JpcHRpb24uIElu
IA0KdGhvc2UgY2FzZXMsIGNhcmUgbXVzdCBiZSB0YWtlbiBpbiBvcmRlciB0byBub3QgZ3JlYXRs
eSBtYWduaWZ5IA0KY29udmVyZ2VuY2UgcHJvYmxlbSBvYnNlcnZlZCBlLmcuIGluIFJGQzYyMjQu
DQoNClJlZ2FyZHMsDQpTw6lyZ2lvDQoNCiANCkggQW50aG9ueSBDaGFuDQogDQpGcm9tOiBkbW0t
Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgDQpTw6lyZ2lvIEZpZ3VlaXJlZG8NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIg
NToyNCBQTQ0KVG86IGRtbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtETU1dIE11bHRpY2FzdCBy
ZXF1aXJlbWVudHMNCiANCkhpIEFudGhvbnksDQoNClRoYW5rIHlvdSBmb3IgdHJ5aW5nIHRvIHBy
b2dyZXNzIG9uIHRoaXMgbWF0dGVyLiBJIG1vc3RseSBhZ3JlZSB3aXRoIHlvdXIgDQphbmFseXNp
cy4NCg0KQXMgZm9yIHRoZSBxdWVzdGlvbiB5b3UgcG9zZWQsIGZpcnN0IEkgd291bGQgbGlrZSB0
byBleGFjdGx5IHVuZGVyc3RhbmQgDQp3aGF0IHlvdSBtZWFuIHdpdGggIm11bHRpY2FzdCBkaXN0
cmlidXRpb24gc2NlbmFyaW8iIGluICJETU0gc29sdXRpb25zIA0Kc2hvdWxkIGVuYWJsZSBtdWx0
aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJlIGNvbXBhdGlibGUgd2l0aCBtdWx0aWNhc3QgDQpkaXN0
cmlidXRpb24gc2NlbmFyaW8sIGV0Yy4iLiBJdCBzZWVtcyBsaWtlIHRoZXJlIGlzIG5vIG1ham9y
IGRpZmZlcmVuY2UgDQpiZXR3ZWVuIHRoaXMgYW5kIHRoZSAiRE1NIHNvbHV0aW9ucyBzaG91bGQg
ZW5hYmxlIHNvbHV0aW9ucyB0byBzdXBwb3J0IA0KbXVsdGljYXN0IHNlcnZpY2VzLiIgcmVxdWly
ZW1lbnQ/IEFyZW4ndCBib3RoIGV4cHJlc3NpbmcgdGhlIG5lZWQgdG8gDQplbmFibGUgbXVsdGlj
YXN0IGluIGEgRE1NIHNvbHV0aW9uPw0KDQpBcyB5b3Ugc3RhdGVkLCAibmVnbGVjdGluZyIgdGhl
IHJlcXVpcmVtZW50IDcuMSB3ZSBwcm9wb3NlZCwgbGVhZHMgdG8gdGhlIA0KUFNzIHlvdSByZWZl
cnJlZC4gIFNvLCB3aGlsZSA3LjIgYW5kIDcuMyBleHByZXNzIHRoZSBuZWVkIGZvciBETU0gDQpz
b2x1dGlvbnMgdG8gYWxsb3cgZGVwbG95bWVudCBvZiBtdWx0aWNhc3Qgc2VydmljZXMsIDcuMSBj
b25jZXJucyAgImhvdyIgDQpJUCBtdWx0aWNhc3Qgc2hvdWxkIGJlIGVuYWJsZWQgaW4gb3JkZXIg
dG8gYXZvaWQgdGhlIGFmb3JlbWVudGlvbmVkIFBTcy4gDQpUaGUgdXNhZ2Ugb2YgdGhlIHdvcmQg
ImZsZXhpYmxlImlzIGV4cGxhaW5lZCBieTogDQoNCiJUaGlzIGZsZXhpYmlsaXR5IGVuYWJsZXMg
ZGlmZmVyZW50IElQIG11bHRpY2FzdCBmbG93cyB3aXRoIHJlc3BlY3QgdG8gYSANCm1vYmlsZSBo
b3N0IHRvIGJlIG1hbmFnZWQgKGUuZy4sIHN1YnNjcmliZWQsIHJlY2VpdmVkIGFuZC9vciB0cmFu
c21pdHRlZCkgDQp1c2luZyBtdWx0aXBsZSBlbmRwb2ludHMiLiANCg0KSW4gb3RoZXIgd29yZHMs
IGNvbXBhdGliaWxpdHkgd2l0aCAibXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBzY2VuYXJpbyIgDQpk
b2Vzbid0IG5lY2Vzc2FyaWx5IGF2b2lkIFBTMSBhbmQgUFM2Lg0KDQpUaGFuayB5b3UgYW5kIGJl
c3QgcmVnYXJkcywNClPDqXJnaW8NCg0KT24gMTEvMTkvMjAxMiAxMDoyOCBQTSwgaCBjaGFuIHdy
b3RlOg0KVGhlcmUgYXJlIDMgcHJvcG9zYWxzIGZvciBtdWx0aWNhc3QgcmVxdWlyZW1lbnRzLiBC
ZWZvcmUgY29tcGFyaW5nIHRoZXNlIA0KcHJvcG9zYWxzLCBsZXQgdXMgdW5kZXJzdGFuZCB3aGF0
IGFyZSB0aGUgcHJvYmxlbXMgZmlyc3QuIFR3byBwcm9ibGVtIA0Kc3RhdGVtZW50cyBoYXZlIGJl
ZW4gcHJvcG9zZWQ6DQogDQpQUzEgKHJldmlzZWQpOiBOb24tb3B0aW1hbCByb3V0ZXMNClJvdXRp
bmcgdmlhIGEgY2VudHJhbGl6ZWQgYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBsb25nZXIgcm91
dGUuIFRoZSANCnByb2JsZW0gaXMgZXNwZWNpYWxseSBtYW5pZmVzdGVkIHdoZW4gYWNjZXNzaW5n
IGEgbG9jYWwgc2VydmVyIG9yIHNlcnZlcnMgDQpvZiBhIENvbnRlbnQgRGVsaXZlcnkgTmV0d29y
ayAoQ0ROKSwgb3Igd2hlbiByZWNlaXZpbmcgLyBzZW5kaW5nIElQIA0KbXVsdGljYXN0IHBhY2tl
dHMuIA0KUFM2OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWMNCklQIG11bHRpY2FzdCBkaXN0
cmlidXRpb24gb3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyAN
Cm1heSBsZWFkIHRvIGNvbnZlcmdlbmNlIG9mIGR1cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlw
dGlvbnMgdG93YXJkcyB0aGUgDQp0dW5uZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1B
RyBpbiBQTUlQdjYpLiAgQ29uY3JldGVseSwgd2hlbiANCm11bHRpY2FzdCBzdWJzY3JpcHRpb24g
Zm9yIGluZGl2aWR1YWwgbW9iaWxlIG5vZGVzIGlzIGNvdXBsZWQgd2l0aCANCm1vYmlsaXR5IHR1
bm5lbHMsIGR1cGxpY2F0ZSBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJl
IA0KcmVjZWl2ZWQgdGhyb3VnaCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJvYmxl
bSBpcyBwb3RlbnRpYWxseSANCm1vcmUgc2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkg
ZW52aXJvbm1lbnQgDQpbZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAz
XS4NCiANClRoZW4sIGxldCB1cyBzZWUgd2hldGhlciBhbGwgdGhlIDMgUkVRIHByb3Bvc2FscyBo
YXZlIHRoZSBzYW1lIGludGVudGlvbi4gDQpJbiB0aGUgZm9sbG93aW5nLCBJIHJlcGhyYXNlIHRo
ZW0gdG8gaGlnaGxpZ2h0IHRoZWlyIHNpbWlsYXJpdGllcy4NCiANClJFUTcuMTogRmxleGlibGUg
bXVsdGljYXN0IGRpc3RyaWJ1dGlvbg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJs
ZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gDQpzY2VuYXJpby4gRXRjLiAN
ClRoZSBNb3RpdmF0aW9uIGlzIHRvIGFsbG93IGZsZXhpYmlsaXR5IGluIChlbmFibGUpIG11bHRp
Y2FzdCBzb2x1dGlvbnMgdG8gDQpzb2x2ZSB0aGUgcHJvYmxlbXMgUFMxIGFuZCBQUzYgYXMgZXhw
bGFpbmVkIGluIHVzZSBjYXNlcyBhbHJlYWR5IHByZXNlbnRlZCANCmFuZCBkaXNjdXNzZWQgaW4g
bXVsdGltb2Igd2cuDQogDQpSRVE3LjI6IA0KRE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxlIHNv
bHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiANCiANCihPcmlnaW5hbCB3b3Jk
aW5nIHdhcyAiVGhlIERNTSAodW5pY2FzdCkgc29sdXRpb24gTVVTVCBiZSBzcGVjaWZpZWQgaW4g
DQpzdWNoIGEgd2F5IHRoYXQgaXQgY2FuIGJlIGV4dGVuZGVkIHRvIGFsc28gc3VwcG9ydCBtdWx0
aWNhc3QgdHJhZmZpYy4iIEkgDQpyZXBocmFzZSBpdCB0byBoaWdobGlnaHQgdGhlIHNpbWlsYXJp
dHkgd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxzIGFuZCBhbHNvIA0KY2hhbmdlZCB0aGUgbXVzdCB0
byBzaG91bGQuKQ0KIA0KUkVRNy4zOg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxlIHNvbHV0
aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcy4NCiANCk9yaWdpbmFsIHdvcmRpbmcg
d2FzIOKAnERNTSBzb2x1dGlvbnMgc2hvdWxkIHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2VzIOKA
piANCmV0Yy4gR2l2ZW4gdGhhdCBpdCBpcyB0aGUgc2NvcGUgb2YgbXVsdGltb2IgYW5kIG5vdCBk
bW0gd2cgdG8gcHJvdmlkZSB0aGUgDQptdWx0aWNhc3Qgc29sdXRpb24sIEkgdGhpbmsg4oCcc3Vw
cG9ydOKAnSBoZXJlIG1lYW5zIOKAnGVuYWJsZeKAnSBzb2x1dGlvbnMgdG8gDQpiZSBkZXZlbG9w
ZWQgKGJ5IG11bHRpbW9iKS4NCiANClNpbWlsYXJpdHkgYW5kIHN1YnRsZSBkaWZmZXJlbmNlczog
Qm90aCBSRVE3LjIgYW5kIFJFUTcuMyB3YW50IHRvIGVuYWJsZSANCm11bHRpY2FzdCBzZXJ2aWNl
cy4gWWV0IHRoZSBleHBsYW5hdGlvbiBpbiBSRVE3LjEgc2VlbXMgdG8gaW5kaWNhdGUgbm90IA0K
anVzdCB0byBlbmFibGUgYW55IG9uZSBtdWx0aWNhc3Qgc29sdXRpb24gYnV0IGFsc28gbmVlZHMg
dGhlIGZsZXhpYmlsaXR5IA0KaW4gbXVsdGljYXN0IHNvbHV0aW9uLiBOb3QgYWxsIG11bHRpY2Fz
dCBzb2x1dGlvbnMgYXJlIHRoZSBzYW1lLiBTb21lIG9mIA0KdGhlbSByZXN1bHRzIGluIFBTMSBv
ciBQUzYuIA0KIA0KQXJlIHRoZXJlIGFueSBhcmUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdl
ZW46DQpJbiBSRVE3LjEsIERNTSBzb2x1dGlvbnMgc2hvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBm
bGV4aWJsZSBtdWx0aWNhc3QgDQpkaXN0cmlidXRpb24gc2NlbmFyaW8sIGV0Yy4gDQpWZXJzdXMN
CkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJl
IGNvbXBhdGlibGUgd2l0aCANCm11bHRpY2FzdCBkaXN0cmlidXRpb24gc2NlbmFyaW8sIGV0Yy4N
CiANCkggQW50aG9ueSBDaGFuDQogDQpGcm9tOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv
OmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2VpbCANCkplb24NClNlbnQ6IE1v
bmRheSwgTm92ZW1iZXIgMTksIDIwMTIgNToxNSBBTQ0KVG86IHBpZXJyaWNrLnNlaXRlQG9yYW5n
ZS5jb20NCkNjOiBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVx
dWlyZW1lbnRzDQogDQpIaSBQaWVycmljaywNCiANCknigJl2ZSBtYW55IHRpbWVzIHRob3VnaHQg
YWJvdXQgeW91ciBxdWVzdGlvbi4gSSB3b3VsZCBzYXkgaG93IGVmZmVjdGl2ZWx5IA0Kc2hvdWxk
IHdlIGRlcGxveS9zdXBwb3J0IG11bHRpY2FzdCBvdmVyIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IHJh
dGhlciB0aGFuIA0KZGlzdHJpYnV0ZWQgbW9iaWxlIG11bHRpY2FzdC4gQXMgYSByZXN1bHQsIHlv
dSBjYW4gZmluZCB0aGlzIGRlcGxveW1lbnQgDQp1c2UgY2FzZSBhbmQgZ2FwIGFuYWx5c2lzIGF0
IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2It
dXNlLWNhc2UtZG1tLTAzIA0KcHJlc2VudGVkIGluIG11bHRpbW9iIHNldmVyYWwgdGltZXMuDQog
DQpJbiB1bmljYXN0IERNTSwgbWFpbiBpbm5vdmF0aW9uIGlzIHRvIGRpc3RyaWJ1dGUgdGhlIGFu
Y2hvciBmdW5jdGlvbiBhdCANCm1hbnkgYWNjZXNzIHJvdXRlcnMgZnJvbSBzaW5nbGUgY29yZS4g
Rm9sbG93aW5nIGFyY2hpdGVjdHVyYWwgY29uY2VwdCBvZiANCkRNTSwgZmxleGlibGUgbXVsdGlj
YXN0IGRpc3RyaWJ1dGlvbiBpcyBvbmUgb2YgbXVsdGljYXN0IHJlcXVpcmVtZW50IA0KcmVzdWx0
ZWQgZnJvbSB0aGUgZHJhZnQgZGVzY3JpYmVkIGFib3ZlLiANCiANClJFUTg6IEZsZXhpYmxlIG11
bHRpY2FzdCBkaXN0cmlidXRpb24NCiJETU0gc29sdXRpb25zIFNIT1VMRCBiZSBjb21wYXRpYmxl
IHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiANCnNjZW5hcmlvcy4gVGhpcyBm
bGV4aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUCBtdWx0aWNhc3QgZmxvd3Mgd2l0aCANCnJl
c3BlY3QgdG8gYSBtb2JpbGUgaG9zdCB0byBiZSBtYW5hZ2VkIChlLmcuLCBzdWJzY3JpYmVkLCBy
ZWNlaXZlZCBhbmQvb3IgDQp0cmFuc21pdHRlZCkgdXNpbmcgbXVsdGlwbGUgZW5kcG9pbnRzIi4g
DQoNCk1vdGl2YXRpb246IFRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHJlcXVpcmVtZW50IGlzIHRv
IGVuYWJsZSBmbGV4aWJpbGl0eSANCmluIG11bHRpY2FzdCBkaXN0cmlidXRpb24uIFRoZSBtdWx0
aWNhc3Qgc29sdXRpb24gbWF5IHRoZXJlZm9yZSBhdm9pZCANCmhhdmluZyBtdWx0aWNhc3QtY2Fw
YWJsZSBhY2Nlc3Mgcm91dGVycyBiZWluZyByZXN0cmljdGVkIHRvIG1hbmFnZSBhbGwgSVAgDQpt
dWx0aWNhc3QgdHJhZmZpYyByZWxhdGl2ZSB0byBhIGhvc3QgdmlhIGEgc2luZ2xlIGVuZHBvaW50
IChlLmcuIHJlZ3VsYXIgDQpvciB0dW5uZWwgaW50ZXJmYWNlKSwgd2hpY2ggd291bGQgbGVhZCB0
byB0aGUgcHJvYmxlbXMgZGVzY3JpYmVkIGluIFBTMSANCmFuZCBQUzYuDQpQUzY6IER1cGxpY2F0
ZSBtdWx0aWNhc3QgdHJhZmZpYw0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hp
dGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zIA0KbWF5IGxlYWQgdG8gY29udmVy
Z2VuY2Ugb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dhcmRzIHRoZSAN
CnR1bm5lbOKAmXMgZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2NikuICBDb25j
cmV0ZWx5LCB3aGVuIA0KbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBtb2Jp
bGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIA0KbW9iaWxpdHkgdHVubmVscywgZHVwbGljYXRlIG11
bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJvbmUgdG8gYmUgDQpyZWNlaXZlZCB0aHJvdWdo
IGRpZmZlcmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IA0K
bW9yZSBzZXZlcmUgaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudCANCltkcmFm
dC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLg0KDQoNCg0KUmVnYXJkcywN
CiANClNlaWwNCiANCkZyb206IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20gW21haWx0bzpwaWVy
cmljay5zZWl0ZUBvcmFuZ2UuY29tXSANClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIg
ODo1NSBBTQ0KVG86ICdrYXJhZ2lhbkBjcy51dHdlbnRlLm5sJzsgc2VpbGplb25AYXYuaXQucHQ7
IA0KSnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbQ0KQ2M6IGRtbUBpZXRmLm9yZw0K
U3ViamVjdDogUkU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMNCiANCkhpIGFsbCwNCiAN
CkkgdGVuZCB0byBhZ3JlZSB3aXRoIEdlb3JnaW91cywgaG93ZXZlciBJIHN0aWxsIGRvIG5vdCBm
aWd1cmUgb3V0IHdoYXQgaXMgDQp0aGUgdXNlLWNhc2UgZm9yIGRpc3RyaWJ1dGVkIG1vYmlsZSBt
dWx0aWNhc3QgKG90aGVyIHRoYW4gYWNhZGVtaWMgDQpjb25zaWRlcmF0aW9ucyk/IENhbiBzb21l
b25lIGdpdmUgY29uY3JldGUgZXhhbXBsZT8gDQogDQpJIGhhdmVu4oCZdCByZWFsIGFsbCBtZXNz
YWdlcyBmcm9tIHRoaXMgdGhyZWFkLiBTbywgbWF5YmUgSSBtaXNzZWQgDQppbXBvcnRhbnQgcG9p
bnRzLg0KIA0KQlIsDQpQaWVycmljaw0KIA0KRGUgOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFp
bHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIA0Ka2FyYWdpYW5AY3MudXR3
ZW50ZS5ubA0KRW52b3nDqSA6IHNhbWVkaSAxNyBub3ZlbWJyZSAyMDEyIDEzOjAxDQrDgCA6IHNl
aWxqZW9uQGF2Lml0LnB0OyBKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29tDQpDYyA6
IGRtbUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50cw0K
IA0KSGkgYWxsLA0KIA0KSSBhbHNvIGFncmVlIHRoYXQgdGhlIERNTSBzb2x1dGlvbiBzaG91bGQg
c29tZWhvdyBjb25zaWRlciBtdXRpY2FzdCANCmRlcGxveW1lbnQuIEhvd2V2ZXIsIEkgZG8gbm90
IHRobmsgdGhhdCB0aGUgRE1NIFdHIGlzIHRoZSByaWdodCBXRyB0byANCnByb3ZpZGUgdGhlIG11
bHRpY2FzdCBiYXNlZCBETU0gc29sdXRpb24hDQogDQpPbmUgYWx0ZXJuYXRpdmUgc29sdXRpb24g
d2lsbCBiZSB0byBoYXZlIGEgbXVsdGljYXN0IHJlcXVpcmVtZW50IHRoYXQgDQplbXBoYXNpemVz
IHRoZSBuZWVkIG9mIGhhdmluZyBleHRlbnNpYmlsaXR5IGhvb2tzIChwb3NzaWJpbGl0aWVzKSB0
aGF0IGNhbiANCmJlIHVzZWQgbGF0ZXIgb24gYnkgdGhlIG11bHRpbW9iIFdHIHRvIHByb3ZpZGUg
YSANCmEgbXVsdGljYXN0IGVuYWJsZWQgRE1NIHNvbHV0aW9uIQ0KIA0KIA0KU28gYSByZXF1aXJl
bWVudCB0aGF0IHNwZWNpZmllcyBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIGNvdWxkIGJl
IHVzZWQgDQpmb3IgdGhpcyBwdXJwb3NlOg0KIA0KIlRoZSBETU0gKHVuaWNhc3QpIHNvbHV0aW9u
IE1VU1QgYmUgc3BlY2lmaWVkIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgDQpleHRlbmRl
ZCB0byBhbHNvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuIg0KIA0KIA0KQmVzdCByZWdhcmRz
LA0KR2Vvcmdpb3MNCiANCiANCiANCg0KVmFuOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbZG1tLWJv
dW5jZXNAaWV0Zi5vcmddIG5hbWVucyBTZWlsIEplb24gWw0Kc2VpbGplb25AYXYuaXQucHRdDQpW
ZXJ6b25kZW46IHZyaWpkYWcgMTYgbm92ZW1iZXIgMjAxMiAyMjoyNQ0KVG86ICdadW5pZ2EsIEp1
YW4gQ2FybG9zJw0KQ2M6IGRtbUBpZXRmLm9yZw0KT25kZXJ3ZXJwOiBSZTogW0RNTV0gTXVsdGlj
YXN0IHJlcXVpcmVtZW50cw0KSGkgSnVhbiwNCg0KSSd2ZSBiZWVuIGxvb2tlZCBhdCBjaGFuZ2Vk
IGZsb3cgb2YgeW91ciBwcm9wb3NlZCB0ZXh0IGJ1dCBzb3JyeSBub3cgdGhhdCANCm15DQpjb21t
ZW50IGlzIHBvc3RlZC4NCkF0IGZpcnN0IHRpbWUsIEkgY291bGRuJ3QgbWFrZSBzdXJlIGhvd2V2
ZXIsIG9uIGhlYXJpbmcgU3RpZydzIA0KZGVzY3JpcHRpb24sDQppdCBzZWVtcyBxdWl0ZSByZWFz
b25hYmxlIGF0IHRoZSBmaXJzdCBzdGVwLCBub3QgZ2l2aW5nIGFueSByZXN0cmljdGlvbnMgDQpi
dXQNCmxlYXZpbmcgc29tZS1zcGVjaWZpYyBmb3IgdGhlIERNTSBzb2x1dGlvbiBpdCBkb2VzIG5v
dCBzdXBwb3J0IG11bHRpY2FzdC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGl0IHJlbWFpbnMgYXQg
YSBiYXNpYyBzdGFnZSBmb3IgdGhlIERNTSBzb2x1dGlvbiB0bw0Kc3VwcG9ydCBtdWx0aWNhc3Qu
DQpTbyBJIHRoaW5rIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG5lZWQgdG8gYmUgbWFkZSBmb3Ig
dGhlIERNTSBzb2x1dGlvbiwNCmFjY29yZGluZ2x5LiBCdXQgb2YgY291cnNlLCB0aGlzIHNob3Vs
ZCBub3QgYWxzbyBnaXZlIGFueSBzcGVjaWZpYw0KbGltaXRhdGlvbiBhbmQgcmVzdHJpY3Rpb24g
YnV0IHNob3VsZCBiZSBtYWRlIHRvd2FyZHMgdGhlIGRpcmVjdGlvbiBub3QNCmxpbWl0aW5nIHRo
ZSBiZW5lZml0cyBwcm92aWRlZCBieSBkaXN0cmlidXRlZCBkZXBsb3ltZW50Lg0KDQpJIGhvcGUg
dG8gZ2V0IG1vcmUgY29tbWVudHMgb24gdGhpcy4NCg0KUmVnYXJkcywNCg0KU2VpbA0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFp
bHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNClp1bmlnYSwgSnVhbiBDYXJs
b3MNClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgODoxNCBQTQ0KVG86IFN0aWcgVmVu
YWFzOyBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1l
bnRzDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGlnIFZlbmFh
cyBbbWFpbHRvOnN0aWdAdmVuYWFzLmNvbV0NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNiwg
MjAxMiAzOjAxIFBNDQo+IFRvOiBqb3VuaSBrb3Job25lbg0KPiBDYzogc2FyaWtheWFAaWVlZS5v
cmc7IFp1bmlnYSwgSnVhbiBDYXJsb3M7IEtvbnN0YW50aW5vcyBQZW50aWtvdXNpczsgDQo+IFBl
dGVyIE1jQ2FubjsgZG1tQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3Qg
cmVxdWlyZW1lbnRzDQo+IA0KPiBPbiAxMS8xNS8yMDEyIDM6MTcgQU0sIGpvdW5pIGtvcmhvbmVu
IHdyb3RlOg0KPiA+DQo+ID4gT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFNLCBCZWhjZXQgU2Fy
aWtheWEgd3JvdGU6DQo+ID4NCj4gPj4NCj4gPj4gSSB0aGluayB3ZSBhcmUgcmVhZGluZyB0b28g
bXVjaCBpbnRvIG11bHRpY2FzdCBhbmQgdW5pY2FzdCBzaG91bGQNCmJlDQo+ID4+IGRlc2lnbmVk
IGluIGFuIGludGVncmF0ZWQgbWFubmVyLg0KPiA+Pg0KPiA+PiBUaGUgZmFjdCBpcyB0aGF0IG11
bHRpY2FzdCBpcyBjb25zaWRlcmVkIGFzIGFuIGFyZWEgb2YNCj4gc3BlY2lhbGl6YXRpb24sDQo+
ID4+IGl0IHJlcXVpcmVzIGtub3dsZWRnZSBvZiB2ZXJ5IGRpZmZlcmVudCBwcm90b2NvbHMgdGhh
biB3ZSBhcmUgDQo+ID4+IGFjY3VzdG9tZWQgdG8gaW4gbW9iaWxpdHkuDQo+ID4NCj4gPiAiUmVx
dWlyZW1lbnQ6IERNTSBzb2x1dGlvbnMgU0hPVUxEIHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2Vz
LiBJZiBhDQo+IHNwZWNpZmljIERNTSBzb2x1dGlvbiBkb2VzIG5vdCBzdXBwb3J0IG11bHRpY2Fz
dCBzZXJ2aWNlcywgYW4gDQo+IGV4cGxhbmF0aW9uIE1VU1QgYmUgcHJvdmlkZWQuIg0KPiANCj4g
VGhpcyBzb3VuZHMgZ29vZCB0byBtZS4NCj4gDQo+IFRoZSBtYWluIHRoaW5nIEkgd2FudCB0byBh
Y2hpZXZlIGlzIHdoYXQgd2FzIGRlc2NyaWJlcyBhcyBtb3RpdmF0aW9uIA0KPiBlYXJsaWVyIGlu
IHRoaXMgdGhyZWFkLiBNdWx0aWNhc3Qgc2hvdWxkIGF0IGxlYXN0IGJlIGNvbnNpZGVyZWQgd2hl
biANCj4gbG9va2luZyBpbnRvIERNTSBzb2x1dGlvbnMsIGFuZCBub3QganVzdCBhbiBhZnRlcnRo
b3VnaHQgb25jZSB0aGUgDQo+IHNvbHV0aW9uIGlzIGRlY2lkZWQuDQo+IA0KPiBTdGlnDQoNCltK
Q1pdIEkgZnVsbHkgYWdyZWUgd2l0aCB0aGlzLiBUaGF0IHdhcyB0aGUgaW50ZW50aW9uIG9mIHRo
ZSBwcm9wb3NlZCANCnRleHQuDQoNClJlZ2FyZHMsDQoNCkp1YW4gQ2FybG9zDQogDQo+IA0KPiA+
IFRvIG1lIHRoYXQgcmVhZHMgYmFzaWNhbGx5ICJkbyBub3QgYnJlYWsgZm91bmRhdGlvbnMgZm9y
IG11bHRpY2FzdA0KPiB1bmxlc3MgeW91IGhhdmUgYSB2YWxpZCAmIGRvY3VtZW50ZWQgcmVhc29u
IGZvciBpdCIuICBJZiB3ZSBsb29rIGUuZy4NCj4gaW50byBSRkM2MjUgbXVsdGljYXN0IHdvcmRp
bmcgdGhhdCBpcyB0aGVyZSB2ZXJ5IGJyaWVmbHkgYnV0IGdpdmVzIGEgDQo+IGhpbnQgdG8gYSBk
ZXZlbG9wZXIgd2hlcmUgdG8gaGVhZCB0by4gVGhhdCBpcyB0aGUgbGV2ZWwgSSB3b3VsZCBleHBl
Y3QgDQo+IERNTSBkb2N1bWVudHMgc2hvdWxkIGFpbSB0by4NCj4gPg0KPiA+IC0gSm91bmkNCj4g
Pg0KPiA+DQo+ID4+IExldCBkbW0gZGVhbCB3aXRoIGl0cyBjdXJyZW50IGNoYXJ0ZXIgdGhhdCBk
b2VzIG5vdCBpbmNsdWRlIGEgd29yZA0KPiBvZg0KPiA+PiBtdWx0aWNhc3QgYW5kIGlmIGV2ZXJ5
dGhpbmcgZ29lcyB3ZWxsIHdlIGNhbiBjb21lIGJhY2sgYW5kIGRpc2N1c3MNCj4gZG1tDQo+ID4+
IG11bHRpY2FzdC4NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4NCj4gPj4gQmVoY2V0DQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGlu
ZyBsaXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vZG1tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg
am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQpjb25maWRlbnRpZWxs
ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMs
IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiANCnJl
Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVk
aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l
c3NhZ2VzIA0KZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0K
RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj
ZSBtZXNzYWdlIGEgZXRlIA0KYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCiAN
ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBvciBwcml2aWxlZ2VkIA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh
dzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCANCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVj
b20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgDQptZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt
b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBs
aXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZG1tDQogDQoNCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRl
c3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIA0KbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v
IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSANCnNpdHVh
ZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3Ig
aXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCANCnJlY2VpdmUgZW1haWwgb24gdGhlIGJh
c2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5B
Uy9kaXNjbGFpbWVyLmFzcHgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3Jn
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCg==
--=_alternative 002C366248257ABE_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFPDqXJnaW88L2ZvbnQ+DQo8
YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBQ
UzY6IER1cGxpY2F0ZSBtdWx0aWNhc3QNCnRyYWZmaWM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+Jmd0OyBJUCBtdWx0aWNhc3QgZGlzdHJpYnV0
aW9uDQpvdmVyIGFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zICZuYnNw
O21heSBsZWFkIHRvIGNvbnZlcmdlbmNlDQpvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3Jp
cHRpb25zIHRvd2FyZHMgdGhlIHR1bm5lbOKAmXMgZG93bnN0cmVhbQ0KZW50aXR5IChlLmcuIE1B
RyBpbiBQTUlQdjYpLiAmbmJzcDsmZ3Q7Q29uY3JldGVseSwgd2hlbiBtdWx0aWNhc3Qgc3Vic2Ny
aXB0aW9uDQpmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIG1vYmls
aXR5IHR1bm5lbHMsIGR1cGxpY2F0ZQ0KbXVsdGljYXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9u
ZSB0byBiZSByZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbQ0KcGF0aHMuIFRoaXMg
cHJvYmxlbSBpcyBwb3RlbnRpYWxseSBtb3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1dGVkIG1vYmls
aXR5DQplbnZpcm9ubWVudCBbZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1t
LTAzXS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy
aSI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx
ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+Jmd0O1tMdWlzJmd0OyZndDtdDQpUaGlzIHNlZW1z
IG5vdCB0byBiZSBhIHByb2JsZW0gb2YgdGhlIElQIG1vYmlsaXR5IHNvbHV0aW9ucyBoYW5kbGlu
ZyBtdWx0aWNhc3QNCnRyYWZmaWMgd2l0aCBtb2JpbGl0eSB0dW5uZWxzIGluIGdlbmVyYWwsIGJ1
dCBhIHByb2JsZW0gb2YgY29uc2lkZXJpbmcNCnNldmVyYWwgdXBzdHJlYW0gcGF0aHMgZW5kaW5n
IG9uIHRoZSBzYW1lIG1vYmlsaXR5IGFjY2VzcyByb3V0ZXIgYXMgYSBjb25zZXF1ZW5jZQ0Kb2Yg
ZXh0ZW5kaW5nIHR1bm5lbHMgZnJvbSBwcmV2aW91c01BUiB0byBuZXdNQVIgdG8gZm9yd2FyZCB0
aGUgbXVsdGljYXN0DQp0cmFmZmljLjwvaT48L2I+PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPiZn
dDsgW1NGXSBFeGFjdGx5LiBXaGljaCBpcyBtb3JlIHRoYW4gbGlrZWx5IHRvIGhhcHBlbg0KaW4g
YSBETU0gc29sdXRpb24sIHdoZXJlIGFsbCAmcXVvdDttb2JpbGl0eSBlbnRpdGllcyZxdW90OyBt
YXkgYWN0IGFzICZxdW90O21vYmlsaXR5DQphY2Nlc3Mgcm91dGVycyZxdW90OywgYW5kLCBhZnRl
ciBtb2JpbGl0eSwgd2Ugd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZg0KdGhlIHR1bm5lbCBmb3Ig
dGhlIHN1YnNjcmlwdGlvbi4gSW4gdGhvc2UgY2FzZXMsIGNhcmUgbXVzdCBiZSB0YWtlbiBpbg0K
b3JkZXIgdG8gbm90IGdyZWF0bHkgbWFnbmlmeSBjb252ZXJnZW5jZSBwcm9ibGVtIG9ic2VydmVk
IGUuZy4gaW4gUkZDNjIyNC48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+W0x1b3dlbl0gQWNjb3Jk
aW5nIHRvIHRoZSBhYm92ZSBkaXNjdXNzaW9uLCBJIGJlbGlldmUgdGhlDQpQUzYgJm5ic3A7aXMg
YmFzZWQgb24gdGhlIHVzYWdlIHNjZW5hcmlvcyBkaXNjdXNzZWQgaW4gPC9mb250Pjxmb250IHNp
emU9MiBjb2xvcj0jMzMzMzk5IGZhY2U9IkNhbGlicmkiPmRyYWZ0LXNmaWd1ZWlyZWRvLW11bHRp
bW9iLXVzZS1jYXNlLWRtbS0wMzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
Lg0KQnV0LCBpdCBzZWVtcyB0byBtZSB0aGUgPC9mb250Pjxmb250IHNpemU9Mj51c2FnZSBzY2Vu
YXJpb3MgaW4gdGhpcyBkcmFmdA0KaXMgYmFzZWQgb24gYSBhc3N1bWVkIGRtbSB1bmljYXN0IHNv
bHV0aW9uIGFuZCBhcmNoaXRlY3R1cmUuIElNSE8sIHRoZQ0KUFMgc2hvdWxkIGJlIGJhc2VkIG9u
IGN1cnJlbnQgZXhpc3RpbmcgcHJvdG9jb2wgKGUuZy4gUkZDKSBvciBjdXJyZW50IGRlcGxveW1l
bnQsDQpub3QgYSBhc3N1bWVkIHNvbHV0aW9uLjwvZm9udD4NCjxwPjxmb250IHNpemU9Mj5CUjwv
Zm9udD4NCjxwPjxmb250IHNpemU9Mj5MdW93ZW48YnI+DQo8L2ZvbnQ+DQo8cD4NCjxicj4NCjxi
cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg
d2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Tw6lyZ2lvIEZpZ3Vl
aXJlZG8gJmx0O3NmaWd1ZWlyZWRvQGF2Lml0LnB0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5Y+R5Lu25Lq6OiAmbmJzcDtkbW0tYm91bmNlc0Bp
ZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLzEx
LzIxIDA3OjIxPC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy
IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPmRtbUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K
PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5oqE6YCBPC9m
b250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0
Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+
PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRE1NXSBNdWx0aWNhc3QgUFMgdG8g
cmVxdWlyZW1lbnRzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv
cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv
bnQgc2l6ZT0zPkhpIEx1aXMsPGJyPg0KPGJyPg0KQSBmZXcgbW9yZSBjb21tZW50cyBvbiB0aGlz
IGlubGluZTo8YnI+DQo8YnI+DQpFbSAyMC0xMS0yMDEyIDE5OjQ2LCBMVUlTIE1JR1VFTCBDT05U
UkVSQVMgTVVSSUxMTyBlc2NyZXZldTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx
ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SGkgQW50aG9ueSwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5zb21lIGNvbW1lbnRzIGluIGxpbmUg
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZu
YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp
Ij5CZXN0IHJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh
Y2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3
ZCBmYWNlPSJDYWxpYnJpIj5MdWlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0
OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
VGFob21hIj48Yj5EZTo8L2I+IDwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0
Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5j
ZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8
L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIg
Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPkVuIG5vbWJyZSBk
ZSA8L2I+aCBjaGFuPGI+PGJyPg0KRW52aWFkbyBlbDo8L2I+IG1hcnRlcywgMjAgZGUgbm92aWVt
YnJlIGRlIDIwMTIgMTg6NTE8Yj48YnI+DQpQYXJhOjwvYj4gU8OpcmdpbyBGaWd1ZWlyZWRvOyA8
L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVl
IGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y
IGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KQXN1bnRvOjwvYj4gW0RNTV0gTXVsdGljYXN0IFBTIHRv
IHJlcXVpcmVtZW50czwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv
bWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i
Q2FsaWJyaSI+TGV0IHVzIGFsc28gdXNlIGFub3RoZXIgdGhyZWFkDQp0byBjaGVjayBmb3IgY29u
c2Vuc3VzIG9mIHRoZSBQUyBmcm9tIG11bHRpbW9iLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlBTMSAocmV2aXNlZCk6IE5vbi1vcHRp
bWFsDQpyb3V0ZXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0i
Q2FsaWJyaSI+Um91dGluZyB2aWEgYSBjZW50cmFsaXplZA0KYW5jaG9yIG9mdGVuIHJlc3VsdHMg
aW4gYSBsb25nZXIgcm91dGUuIFRoZSBwcm9ibGVtIGlzIGVzcGVjaWFsbHkgbWFuaWZlc3RlZA0K
d2hlbiBhY2Nlc3NpbmcgYSBsb2NhbCBzZXJ2ZXIgb3Igc2VydmVycyBvZiBhIENvbnRlbnQgRGVs
aXZlcnkgTmV0d29yaw0KKENETiksIDxiPm9yIHdoZW4gcmVjZWl2aW5nIC8gc2VuZGluZyBJUCBt
dWx0aWNhc3QgcGFja2V0czwvYj4uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm
NDk3ZCBmYWNlPSJDYWxpYnJpIj48Yj48aT5bTHVpcyZndDsmZ3Q7XSBUaGlzDQppcyBjb3JyZWN0
IGlmIHRoZSBtdWx0aWNhc3QgY29udGVudCBpcyBsb2NhbGx5IGF2YWlsYWJsZS4gSG93ZXZlciB0
aGlzDQpjb3VsZCBub3QgYmUgYWx3YXlzIHRoZSBjYXNlIGZvciBtdWx0aWNhc3QgbGlzdGVuZXJz
LCBmb3IgYSBudW1iZXIgb2YgcmVhc29ucw0KKGZvciBpbnN0YW5jZSwgY29uZmxpY3QgaW4gdGhl
IG11bHRpY2FzdCBhZGRyZXNzIGFsbG9jYXRpb24gYmV0d2VlbiB0aGUNCkhvbWUgTmV0d29yayBh
bmQgdGhlIERNTSBkb21haW4pLiA8L2k+PC9iPjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz5bU0Zd
IFN1cmUsIGFuZCB0aGUgc2FtZSBhcHBsaWVzIHRvICZxdW90O2FjY2Vzc2luZyBhIGxvY2FsDQpz
ZXJ2ZXIgYSBDRE4mcXVvdDsgLSBpdCBpcyBpbXBsaWNpdCB0aGF0IHRoZSBjb250ZW50IGlzIGxv
Y2FsbHkgYXZhaWxhYmxlLg0KQnV0IGl0IGNhbiBiZSBpbXByb3ZlZCBhcyAmcXVvdDt3aGVuIHJl
Y2VpdmluZyBsb2NhbGx5IGF2YWlsYWJsZSBJUCBtdWx0aWNhc3QNCm9yIHNlbmRpbmcgSVAgbXVs
dGljYXN0JnF1b3Q7Ljxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzMzMzM5
OSBmYWNlPSJDYWxpYnJpIj5QUzY6IER1cGxpY2F0ZSBtdWx0aWNhc3QNCnRyYWZmaWM8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+SVAgbXVsdGlj
YXN0IGRpc3RyaWJ1dGlvbg0Kb3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNv
bHV0aW9ucyAmbmJzcDttYXkgbGVhZCB0byBjb252ZXJnZW5jZQ0Kb2YgZHVwbGljYXRlZCBtdWx0
aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dhcmRzIHRoZSB0dW5uZWzigJlzIGRvd25zdHJlYW0NCmVu
dGl0eSAoZS5nLiBNQUcgaW4gUE1JUHY2KS4gJm5ic3A7Q29uY3JldGVseSwgd2hlbiBtdWx0aWNh
c3Qgc3Vic2NyaXB0aW9uDQpmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3
aXRoIG1vYmlsaXR5IHR1bm5lbHMsIGR1cGxpY2F0ZQ0KbXVsdGljYXN0IHN1YnNjcmlwdGlvbihz
KSBpcyBwcm9uZSB0byBiZSByZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbQ0KcGF0
aHMuIFRoaXMgcHJvYmxlbSBpcyBwb3RlbnRpYWxseSBtb3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1
dGVkIG1vYmlsaXR5DQplbnZpcm9ubWVudCBbZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNl
LWNhc2UtZG1tLTAzXS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj
ZT0iQ2FsaWJyaSI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+W0x1aXMmZ3Q7Jmd0O10gVGhpcw0K
c2VlbXMgbm90IHRvIGJlIGEgcHJvYmxlbSBvZiB0aGUgSVAgbW9iaWxpdHkgc29sdXRpb25zIGhh
bmRsaW5nIG11bHRpY2FzdA0KdHJhZmZpYyB3aXRoIG1vYmlsaXR5IHR1bm5lbHMgaW4gZ2VuZXJh
bCwgYnV0IGEgcHJvYmxlbSBvZiBjb25zaWRlcmluZw0Kc2V2ZXJhbCB1cHN0cmVhbSBwYXRocyBl
bmRpbmcgb24gdGhlIHNhbWUgbW9iaWxpdHkgYWNjZXNzIHJvdXRlciBhcyBhIGNvbnNlcXVlbmNl
DQpvZiBleHRlbmRpbmcgdHVubmVscyBmcm9tIHByZXZpb3VzTUFSIHRvIG5ld01BUiB0byBmb3J3
YXJkIHRoZSBtdWx0aWNhc3QNCnRyYWZmaWMuPC9pPjwvYj48L2ZvbnQ+DQo8cD48Zm9udCBzaXpl
PTM+W1NGXSBFeGFjdGx5LiBXaGljaCBpcyBtb3JlIHRoYW4gbGlrZWx5IHRvIGhhcHBlbiBpbiBh
DQpETU0gc29sdXRpb24sIHdoZXJlIGFsbCAmcXVvdDttb2JpbGl0eSBlbnRpdGllcyZxdW90OyBt
YXkgYWN0IGFzICZxdW90O21vYmlsaXR5DQphY2Nlc3Mgcm91dGVycyZxdW90OywgYW5kLCBhZnRl
ciBtb2JpbGl0eSwgd2Ugd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZg0KdGhlIHR1bm5lbCBmb3Ig
dGhlIHN1YnNjcmlwdGlvbi4gSW4gdGhvc2UgY2FzZXMsIGNhcmUgbXVzdCBiZSB0YWtlbiBpbg0K
b3JkZXIgdG8gbm90IGdyZWF0bHkgbWFnbmlmeSBjb252ZXJnZW5jZSBwcm9ibGVtIG9ic2VydmVk
IGUuZy4gaW4gUkZDNjIyNC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClPDqXJnaW88YnI+DQo8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5i
c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki
PkggQW50aG9ueSBDaGFuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh
Y2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h
Ij48Yj5Gcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9y
ZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5kbW0tYm91bmNlc0Bp
ZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KWzwvZm9u
dD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xv
cj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPC91Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5Tw6lyZ2lvIEZpZ3VlaXJlZG88Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAx
OSwgMjAxMiA1OjI0IFBNPGI+PGJyPg0KVG86PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1t
QGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGll
dGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0K
U3ViamVjdDo8L2I+IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5IaSBBbnRob255LDxicj4NCjxicj4N
ClRoYW5rIHlvdSBmb3IgdHJ5aW5nIHRvIHByb2dyZXNzIG9uIHRoaXMgbWF0dGVyLiBJIG1vc3Rs
eSBhZ3JlZSB3aXRoIHlvdXINCmFuYWx5c2lzLjxicj4NCjxicj4NCkFzIGZvciB0aGUgcXVlc3Rp
b24geW91IHBvc2VkLCBmaXJzdCBJIHdvdWxkIGxpa2UgdG8gZXhhY3RseSB1bmRlcnN0YW5kDQp3
aGF0IHlvdSBtZWFuIHdpdGggJnF1b3Q7bXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBzY2VuYXJpbyZx
dW90OyBpbiAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs
aWJyaSI+RE1NDQpzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMgd2hp
Y2ggYXJlIGNvbXBhdGlibGUgd2l0aCBtdWx0aWNhc3QNCmRpc3RyaWJ1dGlvbiBzY2VuYXJpbywg
ZXRjLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mcXVvdDsuDQpJ
dCBzZWVtcyBsaWtlIHRoZXJlIGlzIG5vIG1ham9yIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIGFu
ZCB0aGUgJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli
cmkiPkRNTQ0Kc29sdXRpb25zIHNob3VsZCBlbmFibGUgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVs
dGljYXN0IHNlcnZpY2VzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij4mcXVvdDsNCnJlcXVpcmVtZW50PyBBcmVuJ3QgYm90aCBleHByZXNzaW5nIHRoZSBuZWVkIHRv
IGVuYWJsZSBtdWx0aWNhc3QgaW4gYSBETU0NCnNvbHV0aW9uPzxicj4NCjxicj4NCkFzIHlvdSBz
dGF0ZWQsICZxdW90O25lZ2xlY3RpbmcmcXVvdDsgdGhlIHJlcXVpcmVtZW50IDcuMSB3ZSBwcm9w
b3NlZCwNCmxlYWRzIHRvIHRoZSBQU3MgeW91IHJlZmVycmVkLiAmbmJzcDtTbywgd2hpbGUgNy4y
IGFuZCA3LjMgZXhwcmVzcyB0aGUNCm5lZWQgZm9yIERNTSBzb2x1dGlvbnMgdG8gYWxsb3cgZGVw
bG95bWVudCBvZiBtdWx0aWNhc3Qgc2VydmljZXMsIDcuMSBjb25jZXJucw0KJm5ic3A7JnF1b3Q7
aG93JnF1b3Q7IElQIG11bHRpY2FzdCBzaG91bGQgYmUgZW5hYmxlZCBpbiBvcmRlciB0byBhdm9p
ZA0KdGhlIGFmb3JlbWVudGlvbmVkIFBTcy4gVGhlIHVzYWdlIG9mIHRoZSB3b3JkICZxdW90O2Zs
ZXhpYmxlJnF1b3Q7aXMgZXhwbGFpbmVkDQpieTogPGJyPg0KPGJyPg0KJnF1b3Q7VGhpcyBmbGV4
aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUCBtdWx0aWNhc3QgZmxvd3Mgd2l0aCByZXNwZWN0
DQp0byBhIG1vYmlsZSBob3N0IHRvIGJlIG1hbmFnZWQgKGUuZy4sIHN1YnNjcmliZWQsIHJlY2Vp
dmVkIGFuZC9vciB0cmFuc21pdHRlZCkNCnVzaW5nIG11bHRpcGxlIGVuZHBvaW50cyZxdW90Oy4g
PGJyPg0KPGJyPg0KSW4gb3RoZXIgd29yZHMsIGNvbXBhdGliaWxpdHkgd2l0aCAmcXVvdDttdWx0
aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvJnF1b3Q7DQpkb2Vzbid0IG5lY2Vzc2FyaWx5IGF2
b2lkIFBTMSBhbmQgUFM2Ljxicj4NCjxicj4NClRoYW5rIHlvdSBhbmQgYmVzdCByZWdhcmRzLDxi
cj4NClPDqXJnaW88YnI+DQo8YnI+DQpPbiAxMS8xOS8yMDEyIDEwOjI4IFBNLCBoIGNoYW4gd3Jv
dGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki
PlRoZXJlIGFyZSAzIHByb3Bvc2FscyBmb3INCm11bHRpY2FzdCByZXF1aXJlbWVudHMuIEJlZm9y
ZSBjb21wYXJpbmcgdGhlc2UgcHJvcG9zYWxzLCBsZXQgdXMgdW5kZXJzdGFuZA0Kd2hhdCBhcmUg
dGhlIHByb2JsZW1zIGZpcnN0LiBUd28gcHJvYmxlbSBzdGF0ZW1lbnRzIGhhdmUgYmVlbiBwcm9w
b3NlZDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy
aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh
bGlicmkiPlBTMSAocmV2aXNlZCk6IE5vbi1vcHRpbWFsDQpyb3V0ZXM8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+Um91dGluZyB2aWEgYSBjZW50
cmFsaXplZA0KYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBsb25nZXIgcm91dGUuIFRoZSBwcm9i
bGVtIGlzIGVzcGVjaWFsbHkgbWFuaWZlc3RlZA0Kd2hlbiBhY2Nlc3NpbmcgYSBsb2NhbCBzZXJ2
ZXIgb3Igc2VydmVycyBvZiBhIENvbnRlbnQgRGVsaXZlcnkgTmV0d29yaw0KKENETiksIDxiPm9y
IHdoZW4gcmVjZWl2aW5nIC8gc2VuZGluZyBJUCBtdWx0aWNhc3QgcGFja2V0czwvYj4uIDwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzMzMzM5OSBmYWNlPSJDYWxpYnJpIj5QUzY6IER1
cGxpY2F0ZSBtdWx0aWNhc3QNCnRyYWZmaWM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+SVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbg0Kb3ZlciBh
cmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyAmbmJzcDttYXkgbGVhZCB0
byBjb252ZXJnZW5jZQ0Kb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dh
cmRzIHRoZSB0dW5uZWzigJlzIGRvd25zdHJlYW0NCmVudGl0eSAoZS5nLiBNQUcgaW4gUE1JUHY2
KS4gJm5ic3A7Q29uY3JldGVseSwgd2hlbiBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uDQpmb3IgaW5k
aXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIG1vYmlsaXR5IHR1bm5lbHMsIGR1
cGxpY2F0ZQ0KbXVsdGljYXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSByZWNlaXZl
ZCB0aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbQ0KcGF0aHMuIFRoaXMgcHJvYmxlbSBpcyBwb3Rl
bnRpYWxseSBtb3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1dGVkIG1vYmlsaXR5DQplbnZpcm9ubWVu
dCBbZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzXS48L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoZW4sIGxl
dCB1cyBzZWUgd2hldGhlcg0KYWxsIHRoZSAzIFJFUSBwcm9wb3NhbHMgaGF2ZSB0aGUgc2FtZSBp
bnRlbnRpb24uIEluIHRoZSBmb2xsb3dpbmcsIEkgcmVwaHJhc2UNCnRoZW0gdG8gaGlnaGxpZ2h0
IHRoZWlyIHNpbWlsYXJpdGllcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5
N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j
MWY0OTdkIGZhY2U9IkNhbGlicmkiPlJFUTcuMTogRmxleGlibGUgbXVsdGljYXN0DQpkaXN0cmli
dXRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy
aSI+RE1NIHNvbHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJsZQ0Kd2l0aCBmbGV4aWJsZSBtdWx0
aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvLiBFdGMuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5UaGUgTW90aXZhdGlvbiBpcyB0byBhbGxv
dw0KZmxleGliaWxpdHkgaW4gKGVuYWJsZSkgbXVsdGljYXN0IHNvbHV0aW9ucyB0byBzb2x2ZSB0
aGUgcHJvYmxlbXMgUFMxIGFuZA0KUFM2IGFzIGV4cGxhaW5lZCBpbiB1c2UgY2FzZXMgYWxyZWFk
eSBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCBpbiBtdWx0aW1vYg0Kd2cuPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5SRVE3LjI6IDwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5ETU0gc29s
dXRpb25zIHNob3VsZCBlbmFibGUNCnNvbHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCB0cmFm
ZmljLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy
aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh
bGlicmkiPihPcmlnaW5hbCB3b3JkaW5nIHdhcyAmcXVvdDtUaGUNCkRNTSAodW5pY2FzdCkgc29s
dXRpb24gTVVTVCBiZSBzcGVjaWZpZWQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSBleHRl
bmRlZA0KdG8gYWxzbyBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiZxdW90OyBJIHJlcGhyYXNl
IGl0IHRvIGhpZ2hsaWdodCB0aGUNCnNpbWlsYXJpdHkgd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxz
IGFuZCBhbHNvIGNoYW5nZWQgdGhlIG11c3QgdG8gc2hvdWxkLik8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlJFUTcuMzo8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+RE1NIHNvbHV0aW9u
cyBzaG91bGQgZW5hYmxlDQpzb2x1dGlvbnMgdG8gc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMu
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZu
YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp
Ij5PcmlnaW5hbCB3b3JkaW5nIHdhcyDigJxETU0NCnNvbHV0aW9ucyBzaG91bGQgc3VwcG9ydCBt
dWx0aWNhc3Qgc2VydmljZXMg4oCmIGV0Yy4gR2l2ZW4gdGhhdCBpdCBpcyB0aGUNCnNjb3BlIG9m
IG11bHRpbW9iIGFuZCBub3QgZG1tIHdnIHRvIHByb3ZpZGUgdGhlIG11bHRpY2FzdCBzb2x1dGlv
biwgSSB0aGluaw0K4oCcc3VwcG9ydOKAnSBoZXJlIG1lYW5zIOKAnGVuYWJsZeKAnSBzb2x1dGlv
bnMgdG8gYmUgZGV2ZWxvcGVkIChieSBtdWx0aW1vYikuPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5TaW1pbGFyaXR5IGFuZCBzdWJ0bGUg
ZGlmZmVyZW5jZXM6DQpCb3RoIFJFUTcuMiBhbmQgUkVRNy4zIHdhbnQgdG8gZW5hYmxlIG11bHRp
Y2FzdCBzZXJ2aWNlcy4gWWV0IHRoZSBleHBsYW5hdGlvbg0KaW4gUkVRNy4xIHNlZW1zIHRvIGlu
ZGljYXRlIG5vdCBqdXN0IHRvIGVuYWJsZSBhbnkgb25lIG11bHRpY2FzdCBzb2x1dGlvbg0KYnV0
IGFsc28gbmVlZHMgdGhlIGZsZXhpYmlsaXR5IGluIG11bHRpY2FzdCBzb2x1dGlvbi4gTm90IGFs
bCBtdWx0aWNhc3QNCnNvbHV0aW9ucyBhcmUgdGhlIHNhbWUuIFNvbWUgb2YgdGhlbSByZXN1bHRz
IGluIFBTMSBvciBQUzYuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm
YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5
N2QgZmFjZT0iQ2FsaWJyaSI+QXJlIHRoZXJlIGFueSBhcmUgZXNzZW50aWFsDQpkaWZmZXJlbmNl
cyBiZXR3ZWVuOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD
YWxpYnJpIj5JbiBSRVE3LjEsIERNTSBzb2x1dGlvbnMNCnNob3VsZCBiZSBjb21wYXRpYmxlIHdp
dGggZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBzY2VuYXJpbywgZXRjLg0KPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlZlcnN1czwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5ETU0g
c29sdXRpb25zIHNob3VsZCBlbmFibGUNCm11bHRpY2FzdCBzZXJ2aWNlcyB3aGljaCBhcmUgY29t
cGF0aWJsZSB3aXRoIG11bHRpY2FzdCBkaXN0cmlidXRpb24gc2NlbmFyaW8sDQpldGMuPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5IIEFu
dGhvbnkgQ2hhbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD
YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+
RnJvbTo8L2I+IDwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxm
b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0Zi5v
cmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEg
aHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1
ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+
PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2Vp
bCBKZW9uPGI+PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIgNToxNSBB
TTxiPjxicj4NClRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOnBpZXJyaWNrLnNlaXRlQG9y
YW5nZS5jb20+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5waWVycmlj
ay5zZWl0ZUBvcmFuZ2UuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t
YSI+PGI+PGJyPg0KQ2M6PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYub3JnPjxm
b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYub3JnPC91Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+
IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0iQXJpYWwiPkhpIFBpZXJyaWNrLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
QXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPknigJl2
ZSBtYW55IHRpbWVzIHRob3VnaHQgYWJvdXQgeW91ciBxdWVzdGlvbi4NCkkgd291bGQgc2F5IGhv
dyBlZmZlY3RpdmVseSBzaG91bGQgd2UgZGVwbG95L3N1cHBvcnQgbXVsdGljYXN0IG92ZXIgZGlz
dHJpYnV0ZWQNCm1vYmlsaXR5IHJhdGhlciB0aGFuIGRpc3RyaWJ1dGVkIG1vYmlsZSBtdWx0aWNh
c3QuIEFzIGEgcmVzdWx0LCB5b3UgY2FuDQpmaW5kIHRoaXMgZGVwbG95bWVudCB1c2UgY2FzZSBh
bmQgZ2FwIGFuYWx5c2lzIGF0IDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDMiPjxmb250IHNp
emU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDM8L3U+PC9mb250Pjwv
YT48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPg0KcHJlc2VudGVkIGluIG11bHRpbW9iIHNldmVy
YWwgdGltZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+SW4gdW5pY2FzdCBETU0sIG1haW4g
aW5ub3ZhdGlvbiBpcyB0byBkaXN0cmlidXRlDQp0aGUgYW5jaG9yIGZ1bmN0aW9uIGF0IG1hbnkg
YWNjZXNzIHJvdXRlcnMgZnJvbSBzaW5nbGUgY29yZS4gRm9sbG93aW5nDQphcmNoaXRlY3R1cmFs
IGNvbmNlcHQgb2YgRE1NLCBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIGlzIG9uZSBv
Zg0KbXVsdGljYXN0IHJlcXVpcmVtZW50IHJlc3VsdGVkIGZyb20gdGhlIGRyYWZ0IGRlc2NyaWJl
ZCBhYm92ZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9m
b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJFUTg6IEZsZXhp
YmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+JnF1b3Q7RE1NIHNvbHV0aW9ucyBTSE9VTEQgYmUgY29tcGF0aWJs
ZQ0Kd2l0aCBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvcy4gVGhpcyBm
bGV4aWJpbGl0eSBlbmFibGVzDQpkaWZmZXJlbnQgSVAgbXVsdGljYXN0IGZsb3dzIHdpdGggcmVz
cGVjdCB0byBhIG1vYmlsZSBob3N0IHRvIGJlIG1hbmFnZWQNCihlLmcuLCBzdWJzY3JpYmVkLCBy
ZWNlaXZlZCBhbmQvb3IgdHJhbnNtaXR0ZWQpIHVzaW5nIG11bHRpcGxlIGVuZHBvaW50cyZxdW90
Oy4NCjxicj4NCjxicj4NCk1vdGl2YXRpb246IFRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHJlcXVp
cmVtZW50IGlzIHRvIGVuYWJsZSBmbGV4aWJpbGl0eQ0KaW4gbXVsdGljYXN0IGRpc3RyaWJ1dGlv
bi4gVGhlIG11bHRpY2FzdCBzb2x1dGlvbiBtYXkgdGhlcmVmb3JlIGF2b2lkIGhhdmluZw0KbXVs
dGljYXN0LWNhcGFibGUgYWNjZXNzIHJvdXRlcnMgYmVpbmcgcmVzdHJpY3RlZCB0byBtYW5hZ2Ug
YWxsIElQIG11bHRpY2FzdA0KdHJhZmZpYyByZWxhdGl2ZSB0byBhIGhvc3QgdmlhIGEgc2luZ2xl
IGVuZHBvaW50IChlLmcuIHJlZ3VsYXIgb3IgdHVubmVsDQppbnRlcmZhY2UpLCB3aGljaCB3b3Vs
ZCBsZWFkIHRvIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQgaW4gUFMxIGFuZCBQUzYuPC9mb250Pg0K
PGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlBTNjogRHVwbGljYXRlIG11
bHRpY2FzdCB0cmFmZmljPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPklQIG11bHRpY2FzdCBkaXN0cmlidXRpb24gb3Zlcg0KYXJjaGl0ZWN0dXJlcyB1c2lu
ZyBJUCBtb2JpbGl0eSBzb2x1dGlvbnMgJm5ic3A7bWF5IGxlYWQgdG8gY29udmVyZ2VuY2UNCm9m
IGR1cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlwdGlvbnMgdG93YXJkcyB0aGUgdHVubmVs4oCZ
cyBkb3duc3RyZWFtDQplbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2NikuICZuYnNwO0NvbmNyZXRl
bHksIHdoZW4gbXVsdGljYXN0IHN1YnNjcmlwdGlvbg0KZm9yIGluZGl2aWR1YWwgbW9iaWxlIG5v
ZGVzIGlzIGNvdXBsZWQgd2l0aCBtb2JpbGl0eSB0dW5uZWxzLCBkdXBsaWNhdGUNCm11bHRpY2Fz
dCBzdWJzY3JpcHRpb24ocykgaXMgcHJvbmUgdG8gYmUgcmVjZWl2ZWQgdGhyb3VnaCBkaWZmZXJl
bnQgdXBzdHJlYW0NCnBhdGhzLiBUaGlzIHByb2JsZW0gaXMgcG90ZW50aWFsbHkgbW9yZSBzZXZl
cmUgaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eQ0KZW52aXJvbm1lbnQgW2RyYWZ0LXNmaWd1ZWly
ZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wM10uPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
IkFyaWFsIj5TZWlsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiA8L2Zv
bnQ+PGEgaHJlZj1tYWlsdG86cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT48Zm9udCBzaXplPTIg
Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb208L3U+
PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEgaHJlZj1t
YWlsdG86cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm
YWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPC91PjwvZm9u
dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IE1v
bmRheSwgTm92ZW1iZXIgMTksIDIwMTIgODo1NSBBTTxiPjxicj4NClRvOjwvYj4gJzwvZm9udD48
YSBocmVmPW1haWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sPjxmb250IHNpemU9MiBjb2xvcj1i
bHVlIGZhY2U9IlRhaG9tYSI+PHU+a2FyYWdpYW5AY3MudXR3ZW50ZS5ubDwvdT48L2ZvbnQ+PC9h
Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPic7DQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c2Vp
bGplb25AYXYuaXQucHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5z
ZWlsamVvbkBhdi5pdC5wdDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi
PjsNCjwvZm9udD48YSBocmVmPW1haWx0bzpKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwu
Y29tPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+SnVhbkNhcmxvcy5a
dW5pZ2FASW50ZXJEaWdpdGFsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJU
YWhvbWEiPjxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9y
Zz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9yZzwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1YmplY3Q6
PC9iPiBSRTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50czwvZm9udD4NCjxicj48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SGkgYWxsLDwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SSB0ZW5kIHRvIGFncmVl
IHdpdGggR2Vvcmdpb3VzLA0KaG93ZXZlciBJIHN0aWxsIGRvIG5vdCBmaWd1cmUgb3V0IHdoYXQg
aXMgdGhlIHVzZS1jYXNlIGZvciBkaXN0cmlidXRlZA0KbW9iaWxlIG11bHRpY2FzdCAob3RoZXIg
dGhhbiBhY2FkZW1pYyBjb25zaWRlcmF0aW9ucyk/IENhbiBzb21lb25lIGdpdmUNCmNvbmNyZXRl
IGV4YW1wbGU/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD
YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj
ZT0iQ2FsaWJyaSI+SSBoYXZlbuKAmXQgcmVhbCBhbGwgbWVzc2FnZXMNCmZyb20gdGhpcyB0aHJl
YWQuIFNvLCBtYXliZSBJIG1pc3NlZCBpbXBvcnRhbnQgcG9pbnRzLjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+QlIsPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlBpZXJyaWNrPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5EZSA6PC9iPiA8L2ZvbnQ+
PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9
Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+
PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQpbPC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0t
Ym91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48
dT5tYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIg
ZmFjZT0iVGFob21hIj5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWls
dG86a2FyYWdpYW5AY3MudXR3ZW50ZS5ubD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJU
YWhvbWEiPjx1PmthcmFnaWFuQGNzLnV0d2VudGUubmw8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl
PTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpFbnZvecOpIDo8L2I+IHNhbWVkaSAxNyBub3ZlbWJy
ZSAyMDEyIDEzOjAxPGI+PGJyPg0Kw4AgOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOnNlaWxq
ZW9uQGF2Lml0LnB0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+c2Vp
bGplb25AYXYuaXQucHQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47
DQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86SnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNv
bT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pkp1YW5DYXJsb3MuWnVu
aWdhQEludGVyRGlnaXRhbC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFo
b21hIj48Yj48YnI+DQpDYyA6PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYub3Jn
Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYub3JnPC91
PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KT2JqZXQgOjwv
Yj4gUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRh
aG9tYSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPkkgYWxz
byBhZ3JlZSB0aGF0IHRoZSBETU0gc29sdXRpb24gc2hvdWxkDQpzb21laG93IGNvbnNpZGVyIG11
dGljYXN0IGRlcGxveW1lbnQuIEhvd2V2ZXIsIEkgZG8gbm90IHRobmsgdGhhdCB0aGUgRE1NDQpX
RyBpcyB0aGUgcmlnaHQgV0cgdG8gcHJvdmlkZSB0aGUgbXVsdGljYXN0IGJhc2VkIERNTSBzb2x1
dGlvbiE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPk9uZSBhbHRlcm5hdGl2ZSBzb2x1dGlv
biB3aWxsIGJlIHRvIGhhdmUNCmEgbXVsdGljYXN0IHJlcXVpcmVtZW50IHRoYXQgZW1waGFzaXpl
cyB0aGUgbmVlZCBvZiBoYXZpbmcgZXh0ZW5zaWJpbGl0eQ0KaG9va3MgKHBvc3NpYmlsaXRpZXMp
IHRoYXQgY2FuIGJlIHVzZWQgbGF0ZXIgb24gYnkgdGhlIG11bHRpbW9iIFdHIHRvIHByb3ZpZGUN
CmEgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPmEgbXVsdGljYXN0IGVu
YWJsZWQgRE1NIHNvbHV0aW9uITwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h
Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPlNvIGEgcmVxdWlyZW1lbnQgdGhh
dCBzcGVjaWZpZXMgc29tZXRoaW5nDQpsaWtlIHRoZSBmb2xsb3dpbmcgY291bGQgYmUgdXNlZCBm
b3IgdGhpcyBwdXJwb3NlOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4m
bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+JnF1b3Q7VGhlIERN
TSAodW5pY2FzdCkgc29sdXRpb24gTVVTVCBiZQ0Kc3BlY2lmaWVkIGluIHN1Y2ggYSB3YXkgdGhh
dCBpdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWxzbyBzdXBwb3J0IG11bHRpY2FzdA0KdHJhZmZpYy4m
cXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0iVGFob21hIj5CZXN0IHJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJUYWhvbWEiPkdlb3JnaW9zPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl
PSJUYWhvbWEiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4m
bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Jm5ic3A7PC9mb250
Pg0KPGRpdiBhbGlnbj1jZW50ZXI+DQo8YnI+DQo8aHI+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9IlRhaG9tYSI+PGI+VmFuOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0tYm91
bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5k
bW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhv
bWEiPg0KWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250
IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8
L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQpuYW1lbnMgU2VpbCBK
ZW9uIFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c2VpbGplb25AYXYuaXQucHQ+PGZvbnQgc2l6ZT0y
IGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5zZWlsamVvbkBhdi5pdC5wdDwvdT48L2ZvbnQ+
PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl08Yj48YnI+DQpWZXJ6b25kZW46PC9iPiB2
cmlqZGFnIDE2IG5vdmVtYmVyIDIwMTIgMjI6MjU8Yj48YnI+DQpUbzo8L2I+ICdadW5pZ2EsIEp1
YW4gQ2FybG9zJzxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRm
Lm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9y
ZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCk9uZGVy
d2VycDo8L2I+IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPkhpIEp1YW4sPGJyPg0KPGJyPg0KSSd2ZSBiZWVuIGxv
b2tlZCBhdCBjaGFuZ2VkIGZsb3cgb2YgeW91ciBwcm9wb3NlZCB0ZXh0IGJ1dCBzb3JyeSBub3cg
dGhhdA0KbXk8YnI+DQpjb21tZW50IGlzIHBvc3RlZC48YnI+DQpBdCBmaXJzdCB0aW1lLCBJIGNv
dWxkbid0IG1ha2Ugc3VyZSBob3dldmVyLCBvbiBoZWFyaW5nIFN0aWcncyBkZXNjcmlwdGlvbiw8
YnI+DQppdCBzZWVtcyBxdWl0ZSByZWFzb25hYmxlIGF0IHRoZSBmaXJzdCBzdGVwLCBub3QgZ2l2
aW5nIGFueSByZXN0cmljdGlvbnMNCmJ1dDxicj4NCmxlYXZpbmcgc29tZS1zcGVjaWZpYyBmb3Ig
dGhlIERNTSBzb2x1dGlvbiBpdCBkb2VzIG5vdCBzdXBwb3J0IG11bHRpY2FzdC48YnI+DQo8YnI+
DQpPbiB0aGUgb3RoZXIgaGFuZCwgaXQgcmVtYWlucyBhdCBhIGJhc2ljIHN0YWdlIGZvciB0aGUg
RE1NIHNvbHV0aW9uIHRvPGJyPg0Kc3VwcG9ydCBtdWx0aWNhc3QuPGJyPg0KU28gSSB0aGluayBh
ZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIG1hZGUgZm9yIHRoZSBETU0gc29sdXRp
b24sPGJyPg0KYWNjb3JkaW5nbHkuIEJ1dCBvZiBjb3Vyc2UsIHRoaXMgc2hvdWxkIG5vdCBhbHNv
IGdpdmUgYW55IHNwZWNpZmljPGJyPg0KbGltaXRhdGlvbiBhbmQgcmVzdHJpY3Rpb24gYnV0IHNo
b3VsZCBiZSBtYWRlIHRvd2FyZHMgdGhlIGRpcmVjdGlvbiBub3Q8YnI+DQpsaW1pdGluZyB0aGUg
YmVuZWZpdHMgcHJvdmlkZWQgYnkgZGlzdHJpYnV0ZWQgZGVwbG95bWVudC48YnI+DQo8YnI+DQpJ
IGhvcGUgdG8gZ2V0IG1vcmUgY29tbWVudHMgb24gdGhpcy48YnI+DQo8YnI+DQpSZWdhcmRzLDxi
cj4NCjxicj4NClNlaWw8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LTxicj4NCkZyb206IDwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmci
Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0
Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+
PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250
IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmRtbS1ib3VuY2VzQGll
dGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KT24gQmVo
YWxmIE9mPGJyPg0KWnVuaWdhLCBKdWFuIENhcmxvczxicj4NClNlbnQ6IEZyaWRheSwgTm92ZW1i
ZXIgMTYsIDIwMTIgODoxNCBQTTxicj4NClRvOiBTdGlnIFZlbmFhczsgPC9mb250PjxhIGhyZWY9
bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi
Pjx1PmRtbUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi
Pjxicj4NClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPGJyPg0KPGJy
Pg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog
U3RpZyBWZW5hYXMgWzwvZm9udD48YSBocmVmPW1haWx0bzpzdGlnQHZlbmFhcy5jb20gdGFyZ2V0
PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpz
dGlnQHZlbmFhcy5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5d
PGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDM6MDEgUE08YnI+DQom
Z3Q7IFRvOiBqb3VuaSBrb3Job25lbjxicj4NCiZndDsgQ2M6IDwvZm9udD48YSBocmVmPW1haWx0
bzpzYXJpa2F5YUBpZWVlLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi
Pjx1PnNhcmlrYXlhQGllZWUub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRh
aG9tYSI+Ow0KWnVuaWdhLCBKdWFuIENhcmxvczsgS29uc3RhbnRpbm9zIFBlbnRpa291c2lzOyA8
YnI+DQomZ3Q7IFBldGVyIE1jQ2FubjsgPC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9y
Zz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9yZzwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NCiZndDsgU3ViamVj
dDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZndDsg
T24gMTEvMTUvMjAxMiAzOjE3IEFNLCBqb3VuaSBrb3Job25lbiB3cm90ZTo8YnI+DQomZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFNLCBCZWhjZXQgU2Fy
aWtheWEgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg
Jmd0OyZndDsgSSB0aGluayB3ZSBhcmUgcmVhZGluZyB0b28gbXVjaCBpbnRvIG11bHRpY2FzdCBh
bmQgdW5pY2FzdA0Kc2hvdWxkPGJyPg0KYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRlc2lnbmVkIGlu
IGFuIGludGVncmF0ZWQgbWFubmVyLjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm
Z3Q7IFRoZSBmYWN0IGlzIHRoYXQgbXVsdGljYXN0IGlzIGNvbnNpZGVyZWQgYXMgYW4gYXJlYSBv
Zjxicj4NCiZndDsgc3BlY2lhbGl6YXRpb24sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpdCByZXF1aXJl
cyBrbm93bGVkZ2Ugb2YgdmVyeSBkaWZmZXJlbnQgcHJvdG9jb2xzIHRoYW4gd2UNCmFyZSA8YnI+
DQomZ3Q7ICZndDsmZ3Q7IGFjY3VzdG9tZWQgdG8gaW4gbW9iaWxpdHkuPGJyPg0KJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7ICZxdW90O1JlcXVpcmVtZW50OiBETU0gc29sdXRpb25zIFNIT1VMRCBz
dXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcy4NCklmIGE8YnI+DQomZ3Q7IHNwZWNpZmljIERNTSBz
b2x1dGlvbiBkb2VzIG5vdCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcywgYW4gPGJyPg0KJmd0
OyBleHBsYW5hdGlvbiBNVVNUIGJlIHByb3ZpZGVkLiZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0
OyBUaGlzIHNvdW5kcyBnb29kIHRvIG1lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbWFpbiB0
aGluZyBJIHdhbnQgdG8gYWNoaWV2ZSBpcyB3aGF0IHdhcyBkZXNjcmliZXMgYXMgbW90aXZhdGlv
bg0KPGJyPg0KJmd0OyBlYXJsaWVyIGluIHRoaXMgdGhyZWFkLiBNdWx0aWNhc3Qgc2hvdWxkIGF0
IGxlYXN0IGJlIGNvbnNpZGVyZWQgd2hlbg0KPGJyPg0KJmd0OyBsb29raW5nIGludG8gRE1NIHNv
bHV0aW9ucywgYW5kIG5vdCBqdXN0IGFuIGFmdGVydGhvdWdodCBvbmNlIHRoZQ0KPGJyPg0KJmd0
OyBzb2x1dGlvbiBpcyBkZWNpZGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdGlnPGJyPg0KPGJy
Pg0KW0pDWl0gSSBmdWxseSBhZ3JlZSB3aXRoIHRoaXMuIFRoYXQgd2FzIHRoZSBpbnRlbnRpb24g
b2YgdGhlIHByb3Bvc2VkIHRleHQuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpKdWFu
IENhcmxvczxicj4NCiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBUbyBtZSB0aGF0IHJlYWRz
IGJhc2ljYWxseSAmcXVvdDtkbyBub3QgYnJlYWsgZm91bmRhdGlvbnMgZm9yDQptdWx0aWNhc3Q8
YnI+DQomZ3Q7IHVubGVzcyB5b3UgaGF2ZSBhIHZhbGlkICZhbXA7IGRvY3VtZW50ZWQgcmVhc29u
IGZvciBpdCZxdW90Oy4gJm5ic3A7SWYNCndlIGxvb2sgZS5nLjxicj4NCiZndDsgaW50byBSRkM2
MjUgbXVsdGljYXN0IHdvcmRpbmcgdGhhdCBpcyB0aGVyZSB2ZXJ5IGJyaWVmbHkgYnV0IGdpdmVz
DQphIDxicj4NCiZndDsgaGludCB0byBhIGRldmVsb3BlciB3aGVyZSB0byBoZWFkIHRvLiBUaGF0
IGlzIHRoZSBsZXZlbCBJIHdvdWxkIGV4cGVjdA0KPGJyPg0KJmd0OyBETU0gZG9jdW1lbnRzIHNo
b3VsZCBhaW0gdG8uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0gSm91bmk8YnI+DQom
Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IExldCBkbW0gZGVhbCB3
aXRoIGl0cyBjdXJyZW50IGNoYXJ0ZXIgdGhhdCBkb2VzIG5vdCBpbmNsdWRlDQphIHdvcmQ8YnI+
DQomZ3Q7IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtdWx0aWNhc3QgYW5kIGlmIGV2ZXJ5dGhpbmcg
Z29lcyB3ZWxsIHdlIGNhbiBjb21lIGJhY2sgYW5kDQpkaXNjdXNzPGJyPg0KJmd0OyBkbW08YnI+
DQomZ3Q7ICZndDsmZ3Q7IG11bHRpY2FzdC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEJl
aGNldDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1
ZSBmYWNlPSJUYWhvbWEiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGll
dGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYu
b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48
dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kbW0gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJU
YWhvbWEiPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC91Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KPGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBs
aXN0PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+PGJyPg0K
PC91PjwvZm9udD48YSBocmVmPW1haWx0bzpkbW1AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9y
PWJsdWUgZmFjZT0iVGFob21hIj48dT5kbW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz
aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJl
Zj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSB0YXJnZXQ9X2JsYW5r
Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L3U+PC9mb250PjwvYT4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0iQ291cmllciBOZXciPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv
dXJpZXIgTmV3Ij5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50DQpjb250
ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg
bmUgZG9pdmVudA0KZG9uYzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO
ZXciPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzDQpzYW5zIGF1dG9yaXNh
dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs
ZQ0Kc2lnbmFsZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5h
IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0KcXVlIGxlcyBwaWVjZXMgam9pbnRl
cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh
dGlvbiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5GcmFuY2Ug
VGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlDQpyZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz
YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5DQpjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo
YXQgbWF5IGJlIHByb3RlY3RlZCBieQ0KbGF3OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0iQ291cmllciBOZXciPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZA0Kb3Ig
Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9IkNvdXJpZXIgTmV3Ij5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluDQplcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp
dHMgYXR0YWNobWVudHMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l
dyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbQ0KLSBPcmFuZ2UgaXMg
bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg
b3INCmZhbHNpZmllZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3
Ij5UaGFuayB5b3UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPjxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291
cmllciBOZXciPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ZG1tIG1haWxpbmcg
bGlzdDwvZm9udD4NCjxicj48YSBocmVmPW1haWx0bzpkbW1AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0y
IGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmRtbUBpZXRmLm9yZzwvdT48L2ZvbnQ+
PC9hPg0KPGJyPjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
bW0+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC91PjwvZm9udD48L2E+DQo8YnI+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQg
c2l6ZT0zPjxicj4NCjwvZm9udD4NCjxocj48Zm9udCBzaXplPTEgY29sb3I9IzgwODA4MCBmYWNl
PSJBcmlhbCI+PGJyPg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1
IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyDQpudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbD
rW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlDQpzaXR1
YWRvIG3DoXMgYWJham8uPGJyPg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5
IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kDQpyZWNlaXZlIGVtYWlsIG9uIHRo
ZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9y
PWJsdWUgZmFjZT0iQXJpYWwiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3
LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweD48Zm9udCBzaXplPTEgY29sb3I9Ymx1
ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVy
LmFzcHg8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJyPg0KPC9mb250
PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl
PSJDb3VyaWVyIE5ldyI+PHU+ZG1tQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y
IGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQo8L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJD
b3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08
L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCjwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDxicj4NCmRtbUBpZXRmLm9yZzxi
cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPGJyPg0KPC90dD48
L2ZvbnQ+DQo8YnI+DQo=
--=_alternative 002C366248257ABE_=--

From sfigueiredo@av.it.pt  Thu Nov 22 01:35:12 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058C121F8912 for ; Thu, 22 Nov 2012 01:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Level: 
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpqOJavFQpCd for ; Thu, 22 Nov 2012 01:35:09 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9760721F886C for ; Thu, 22 Nov 2012 01:35:07 -0800 (PST)
Received: from [193.136.93.250] (account sfigueiredo@av.it.pt [193.136.93.250] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67096852; Thu, 22 Nov 2012 09:35:05 +0000
Message-ID: <50ADF1D4.6070102@av.it.pt>
Date: Thu, 22 Nov 2012 09:35:16 +0000
From: =?UTF-8?B?U8OpcmdpbyBGaWd1ZWlyZWRv?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: luo.wen@zte.com.cn
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030107020209090801030106"
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?562U5aSNOiBSZTogIE11bHRpY2FzdCBQUyB0byByZXF1aXJl?= =?utf-8?q?ments?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 09:35:12 -0000

This is a multi-part message in MIME format.
--------------030107020209090801030106
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Luo,

Thanks for your comment. My answer is placed inline:

On 11/22/2012 08:02 AM, luo.wen@zte.com.cn wrote:
>
> Hi Sérgio
>
> > PS6: Duplicate multicast traffic
> > IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> PMIPv6).  >Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
> *//*
> */>[Luis>>] This seems not to be a problem of the IP mobility 
> solutions handling multicast traffic with mobility tunnels in general, 
> but a problem of considering several upstream paths ending on the same 
> mobility access router as a consequence of extending tunnels from 
> previousMAR to newMAR to forward the multicast traffic./*
>
> > [SF] Exactly. Which is more than likely to happen in a DMM solution, 
> where all "mobility entities" may act as "mobility access routers", 
> and, after mobility, we want to take advantage of the tunnel for the 
> subscription. In those cases, care must be taken in order to not 
> greatly magnify convergence problem observed e.g. in RFC6224.
>
> [Luowen] According to the above discussion, I believe the PS6  is 
> based on the usage scenarios discussed in 
> draft-sfigueiredo-multimob-use-case-dmm-03. But, it seems to me the 
> usage scenarios in this draft is based on a assumed dmm unicast 
> solution and architecture. IMHO, the PS should be based on current 
> existing protocol (e.g. RFC) or current deployment, not a assumed 
> solution.
>
SF: PS6is observable is both existing protocols (e.g. RFC6224) and in 
the use cases we analyzed - in a PMIPv6-based DMM solution. So I assume 
the PS fits in the REQs document. As I said before, if ignored, the 
tunnel convergence problem might be a much serious problem than in RFC6224.

Best regards,
Sérgio

> BR
>
> Luowen
>
>
>
>
>
> *Sérgio Figueiredo *
> å‘件人:  dmm-bounces@ietf.org
>
> 2012/11/21 07:21
>
> 	
> 收件人
> 	dmm@ietf.org
> 抄é€
> 	
> 主题
> 	Re: [DMM] Multicast PS to requirements
>
>
>
> 	
>
>
>
>
>
> Hi Luis,
>
> A few more comments on this inline:
>
> Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
> Hi Anthony,
>
> some comments in line
>
> Best regards,
>
> Luis
>
> *De:* _dmm-bounces@ietf.org_ 
> [_mailto:dmm-bounces@ietf.org_] *En 
> nombre de *h chan*
> Enviado el:* martes, 20 de noviembre de 2012 18:51*
> Para:* Sérgio Figueiredo; _dmm@ietf.org_ *
> Asunto:* [DMM] Multicast PS to requirements
>
> Let us also use another thread to check for consensus of the PS from 
> multimob.
>
> PS1 (revised): Non-optimal routes
> Routing via a centralized anchor often results in a longer route. The 
> problem is especially manifested when accessing a local server or 
> servers of a Content Delivery Network (CDN), *or when receiving / 
> sending IP multicast packets*.
> */[Luis>>] This is correct if the multicast content is locally 
> available. However this could not be always the case for multicast 
> listeners, for a number of reasons (for instance, conflict in the 
> multicast address allocation between the Home Network and the DMM 
> domain). /*
>
> [SF] Sure, and the same applies to "accessing a local server a CDN" - 
> it is implicit that the content is locally available. But it can be 
> improved as "when receiving locally available IP multicast or sending 
> IP multicast".
>
> PS6: Duplicate multicast traffic
> IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> PMIPv6).  Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
> *//*
> */[Luis>>] This seems not to be a problem of the IP mobility solutions 
> handling multicast traffic with mobility tunnels in general, but a 
> problem of considering several upstream paths ending on the same 
> mobility access router as a consequence of extending tunnels from 
> previousMAR to newMAR to forward the multicast traffic./*
>
> [SF] Exactly. Which is more than likely to happen in a DMM solution, 
> where all "mobility entities" may act as "mobility access routers", 
> and, after mobility, we want to take advantage of the tunnel for the 
> subscription. In those cases, care must be taken in order to not 
> greatly magnify convergence problem observed e.g. in RFC6224.
>
> Regards,
> Sérgio
>
>
> H Anthony Chan
>
> *From:* _dmm-bounces@ietf.org_ 
> [_mailto:dmm-bounces@ietf.org_] *On 
> Behalf Of *Sérgio Figueiredo*
> Sent:* Monday, November 19, 2012 5:24 PM*
> To:* _dmm@ietf.org_ *
> Subject:* Re: [DMM] Multicast requirements
>
> Hi Anthony,
>
> Thank you for trying to progress on this matter. I mostly agree with 
> your analysis.
>
> As for the question you posed, first I would like to exactly 
> understand what you mean with "multicast distribution scenario" in 
> "DMM solutions should enable multicast services which are compatible 
> with multicast distribution scenario, etc.". It seems like there is no 
> major difference between this and the "DMM solutions should enable 
> solutions to support multicast services." requirement? Aren't both 
> expressing the need to enable multicast in a DMM solution?
>
> As you stated, "neglecting" the requirement 7.1 we proposed, leads to 
> the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 
> solutions to allow deployment of multicast services, 7.1 concerns 
>  "how" IP multicast should be enabled in order to avoid the 
> aforementioned PSs. The usage of the word "flexible"is explained by:
>
> "This flexibility enables different IP multicast flows with respect to 
> a mobile host to be managed (e.g., subscribed, received and/or 
> transmitted) using multiple endpoints".
>
> In other words, compatibility with "multicast distribution scenario" 
> doesn't necessarily avoid PS1 and PS6.
>
> Thank you and best regards,
> Sérgio
>
> On 11/19/2012 10:28 PM, h chan wrote:
> There are 3 proposals for multicast requirements. Before comparing 
> these proposals, let us understand what are the problems first. Two 
> problem statements have been proposed:
>
> PS1 (revised): Non-optimal routes
> Routing via a centralized anchor often results in a longer route. The 
> problem is especially manifested when accessing a local server or 
> servers of a Content Delivery Network (CDN), *or when receiving / 
> sending IP multicast packets*.
> PS6: Duplicate multicast traffic
> IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> PMIPv6).  Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
> Then, let us see whether all the 3 REQ proposals have the same 
> intention. In the following, I rephrase them to highlight their 
> similarities.
>
> REQ7.1: Flexible multicast distribution
> DMM solutions should be compatible with flexible multicast 
> distribution scenario. Etc.
> The Motivation is to allow flexibility in (enable) multicast solutions 
> to solve the problems PS1 and PS6 as explained in use cases already 
> presented and discussed in multimob wg.
>
> REQ7.2:
> DMM solutions should enable solutions to support multicast traffic.
>
> (Original wording was "The DMM (unicast) solution MUST be specified in 
> such a way that it can be extended to also support multicast traffic." 
> I rephrase it to highlight the similarity with the other proposals and 
> also changed the must to should.)
>
> REQ7.3:
> DMM solutions should enable solutions to support multicast services.
>
> Original wording was “DMM solutions should support multicast services 
> … etc. Given that it is the scope of multimob and not dmm wg to 
> provide the multicast solution, I think “support†here means “enable†
> solutions to be developed (by multimob).
>
> Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to 
> enable multicast services. Yet the explanation in REQ7.1 seems to 
> indicate not just to enable any one multicast solution but also needs 
> the flexibility in multicast solution. Not all multicast solutions are 
> the same. Some of them results in PS1 or PS6.
>
> Are there any are essential differences between:
> In REQ7.1, DMM solutions should be compatible with flexible multicast 
> distribution scenario, etc.
> Versus
> DMM solutions should enable multicast services which are compatible 
> with multicast distribution scenario, etc.
>
> H Anthony Chan
>
> *From:* _dmm-bounces@ietf.org_ 
> [_mailto:dmm-bounces@ietf.org_] *On 
> Behalf Of *Seil Jeon*
> Sent:* Monday, November 19, 2012 5:15 AM*
> To:* _pierrick.seite@orange.com_ *
> Cc:* _dmm@ietf.org_ *
> Subject:* Re: [DMM] Multicast requirements
>
> Hi Pierrick,
>
> I’ve many times thought about your question. I would say how 
> effectively should we deploy/support multicast over distributed 
> mobility rather than distributed mobile multicast. As a result, you 
> can find this deployment use case and gap analysis at 
> _http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03_presented 
> in multimob several times.
>
> In unicast DMM, main innovation is to distribute the anchor function 
> at many access routers from single core. Following architectural 
> concept of DMM, flexible multicast distribution is one of multicast 
> requirement resulted from the draft described above.
>
> REQ8: Flexible multicast distribution
> "DMM solutions SHOULD be compatible with flexible multicast 
> distribution scenarios. This flexibility enables different IP 
> multicast flows with respect to a mobile host to be managed (e.g., 
> subscribed, received and/or transmitted) using multiple endpoints".
>
> Motivation: The motivation for this requirement is to enable 
> flexibility in multicast distribution. The multicast solution may 
> therefore avoid having multicast-capable access routers being 
> restricted to manage all IP multicast traffic relative to a host via a 
> single endpoint (e.g. regular or tunnel interface), which would lead 
> to the problems described in PS1 and PS6.
> PS6: Duplicate multicast traffic
> IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> PMIPv6).  Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>
>
> Regards,
>
> Seil
>
> *From:* _pierrick.seite@orange.com_ 
> [_mailto:pierrick.seite@orange.com_] *
> Sent:* Monday, November 19, 2012 8:55 AM*
> To:* '_karagian@cs.utwente.nl_ '; 
> _seiljeon@av.it.pt_ ; 
> _JuanCarlos.Zuniga@InterDigital.com_ 
> *
> Cc:* _dmm@ietf.org_ *
> Subject:* RE: [DMM] Multicast requirements
>
> Hi all,
>
> I tend to agree with Georgious, however I still do not figure out what 
> is the use-case for distributed mobile multicast (other than academic 
> considerations)? Can someone give concrete example?
>
> I haven’t real all messages from this thread. So, maybe I missed 
> important points.
>
> BR,
> Pierrick
>
> *De :* _dmm-bounces@ietf.org_ 
> [_mailto:dmm-bounces@ietf.org_] *De la 
> part de* _karagian@cs.utwente.nl_ *
> Envoyé :* samedi 17 novembre 2012 13:01*
> À :* _seiljeon@av.it.pt_ ; 
> _JuanCarlos.Zuniga@InterDigital.com_ 
> *
> Cc :* _dmm@ietf.org_ *
> Objet :* Re: [DMM] Multicast requirements
>
> Hi all,
>
> I also agree that the DMM solution should somehow consider muticast 
> deployment. However, I do not thnk that the DMM WG is the right WG to 
> provide the multicast based DMM solution!
>
> One alternative solution will be to have a multicast requirement that 
> emphasizes the need of having extensibility hooks (possibilities) that 
> can be used later on by the multimob WG to provide a
> a multicast enabled DMM solution!
>
>
> So a requirement that specifies something like the following could be 
> used for this purpose:
>
> "The DMM (unicast) solution MUST be specified in such a way that it 
> can be extended to also support multicast traffic."
>
>
> Best regards,
> Georgios
>
>
>
> ------------------------------------------------------------------------
>
> *Van:* _dmm-bounces@ietf.org_ 
> [_dmm-bounces@ietf.org_ 
> ] namens Seil Jeon [_seiljeon@av.it.pt_ 
> ]*
> Verzonden:* vrijdag 16 november 2012 22:25*
> To:* 'Zuniga, Juan Carlos'*
> Cc:* _dmm@ietf.org_ *
> Onderwerp:* Re: [DMM] Multicast requirements
> Hi Juan,
>
> I've been looked at changed flow of your proposed text but sorry now 
> that my
> comment is posted.
> At first time, I couldn't make sure however, on hearing Stig's 
> description,
> it seems quite reasonable at the first step, not giving any 
> restrictions but
> leaving some-specific for the DMM solution it does not support multicast.
>
> On the other hand, it remains at a basic stage for the DMM solution to
> support multicast.
> So I think additional requirements need to be made for the DMM solution,
> accordingly. But of course, this should not also give any specific
> limitation and restriction but should be made towards the direction not
> limiting the benefits provided by distributed deployment.
>
> I hope to get more comments on this.
>
> Regards,
>
> Seil
>
>
> -----Original Message-----
> From: _dmm-bounces@ietf.org_ 
> [_mailto:dmm-bounces@ietf.org_] On Behalf Of
> Zuniga, Juan Carlos
> Sent: Friday, November 16, 2012 8:14 PM
> To: Stig Venaas; _dmm@ietf.org_ 
> Subject: Re: [DMM] Multicast requirements
>
>
> > -----Original Message-----
> > From: Stig Venaas [_mailto:stig@venaas.com_]
> > Sent: Friday, November 16, 2012 3:01 PM
> > To: jouni korhonen
> > Cc: _sarikaya@ieee.org_ ; Zuniga, Juan 
> Carlos; Konstantinos Pentikousis;
> > Peter McCann; _dmm@ietf.org_ 
> > Subject: Re: [DMM] Multicast requirements
> >
> > On 11/15/2012 3:17 AM, jouni korhonen wrote:
> > >
> > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> > >
> > >>
> > >> I think we are reading too much into multicast and unicast should
> be
> > >> designed in an integrated manner.
> > >>
> > >> The fact is that multicast is considered as an area of
> > specialization,
> > >> it requires knowledge of very different protocols than we are
> > >> accustomed to in mobility.
> > >
> > > "Requirement: DMM solutions SHOULD support multicast services. If a
> > specific DMM solution does not support multicast services, an
> > explanation MUST be provided."
> >
> > This sounds good to me.
> >
> > The main thing I want to achieve is what was describes as motivation
> > earlier in this thread. Multicast should at least be considered when
> > looking into DMM solutions, and not just an afterthought once the
> > solution is decided.
> >
> > Stig
>
> [JCZ] I fully agree with this. That was the intention of the proposed 
> text.
>
> Regards,
>
> Juan Carlos
>
> >
> > > To me that reads basically "do not break foundations for multicast
> > unless you have a valid & documented reason for it".  If we look e.g.
> > into RFC625 multicast wording that is there very briefly but gives a
> > hint to a developer where to head to. That is the level I would expect
> > DMM documents should aim to.
> > >
> > > - Jouni
> > >
> > >
> > >> Let dmm deal with its current charter that does not include a word
> > of
> > >> multicast and if everything goes well we can come back and discuss
> > dmm
> > >> multicast.
> > >>
> > >> Regards,
> > >>
> > >> Behcet
>
> _______________________________________________
> dmm mailing list_
> __dmm@ietf.org_ _
> __https://www.ietf.org/mailman/listinfo/dmm_
>
> _______________________________________________
> dmm mailing list_
> __dmm@ietf.org_ _
> __https://www.ietf.org/mailman/listinfo/dmm_
> _________________________________________________________________________________________________________________________ 
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a 
> ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.
>
>
>
>
> _______________________________________________
> dmm mailing list
> _dmm@ietf.org_ 
> _https://www.ietf.org/mailman/listinfo/dmm_
>
>
> ------------------------------------------------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:_
> __http://www.tid.es/ES/PAGINAS/disclaimer.aspx_
>
>
> _______________________________________________
> dmm mailing list
> _dmm@ietf.org_ 
> _https://www.ietf.org/mailman/listinfo/dmm_
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


--------------030107020209090801030106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Luo,

      

      Thanks for your comment. My answer is placed inline:

      

      On 11/22/2012 08:02 AM, luo.wen@zte.com.cn wrote:

    

    

      

      Hi Sérgio
      

      

      > PS6: Duplicate
        multicast
        traffic
      

      > IP multicast
        distribution
        over architectures using IP mobility solutions  may lead to
        convergence
        of duplicated multicast subscriptions towards the tunnel’s
        downstream
        entity (e.g. MAG in PMIPv6).  >Concretely, when multicast
        subscription
        for individual mobile nodes is coupled with mobility tunnels,
        duplicate
        multicast subscription(s) is prone to be received through
        different upstream
        paths. This problem is potentially more severe in a distributed
        mobility
        environment [draft-sfigueiredo-multimob-use-case-dmm-03].
      

       
      

      >[Luis>>]
This
            seems not to be a problem of the IP mobility solutions
            handling multicast
            traffic with mobility tunnels in general, but a problem of
            considering
            several upstream paths ending on the same mobility access
            router as a consequence
            of extending tunnels from previousMAR to newMAR to forward
            the multicast
            traffic.
      
> [SF] Exactly. Which is more than likely to
          happen
          in a DMM solution, where all "mobility entities" may act as
          "mobility
          access routers", and, after mobility, we want to take
          advantage of
          the tunnel for the subscription. In those cases, care must be
          taken in
          order to not greatly magnify convergence problem observed e.g.
          in RFC6224.
      

      
[Luowen] According to the above discussion, I
          believe the
          PS6  is based on the usage scenarios discussed in draft-sfigueiredo-multimob-use-case-dmm-03.
          But, it seems to me the usage scenarios
          in this draft
          is based on a assumed dmm unicast solution and architecture.
          IMHO, the
          PS should be based on current existing protocol (e.g. RFC) or
          current deployment,
          not a assumed solution.

    

    SF: PS6 is observable
          is both existing protocols (e.g. RFC6224) and
            in the use cases we analyzed -
                in a PMIPv6-based DMM
                    solution. So I assume
            the PS fits in the REQs document. As I said before, if ignored, the tunnel convergence problem
                    might be a much serious problem than
                      in RFC6224.

                      

                      Best regards,

                        Sérgio

                      

          
    

      

      

      
BR
      

      
Luowen

        
      

      

        

        

        

        

        

          
            

              Sérgio
                    Figueiredo <sfigueiredo@av.it.pt>
                
                

                å‘件人:
                   dmm-bounces@ietf.org
                
2012/11/21 07:21
                

              		
              
                

                  
                    

                      
                        
收件人

                      		
                      dmm@ietf.org
                      
                    

                    

                      
                        
抄é€

                      		
                      
                        

                      		
                    

                    

                      
                        
主题

                      		
                      Re: [DMM]
                          Multicast PS to requirements
                    

                  
                

                

                

                  
                    

                      
                        

                      		
                      

                      		
                    

                  
                

                

              		
            

          
        

        

        

        

        Hi Luis,

          

          A few more comments on this inline:

          

          Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
        

        Hi Anthony, 
        

         
        

        some comments in
          line 
        

         
        

        Best regards,
        

         
        

        Luis
        

         
        

        De: dmm-bounces@ietf.org
          [mailto:dmm-bounces@ietf.org]
          En nombre de h chan

            Enviado el: martes, 20 de noviembre de 2012 18:51

            Para: Sérgio Figueiredo; dmm@ietf.org

            Asunto: [DMM] Multicast PS to requirements
        

         
        

        Let us also use
          another thread
          to check for consensus of the PS from multimob. 
        

         
        

        PS1 (revised):
          Non-optimal
          routes
        

        Routing via a
          centralized
          anchor often results in a longer route. The problem is
          especially manifested
          when accessing a local server or servers of a Content Delivery
          Network
          (CDN), or when receiving / sending IP multicast packets.
        
        

        [Luis>>]
              This
              is correct if the multicast content is locally available.
              However this
              could not be always the case for multicast listeners, for
              a number of reasons
              (for instance, conflict in the multicast address
              allocation between the
              Home Network and the DMM domain). 
      

      
[SF] Sure, and the same applies to "accessing a
          local
          server a CDN" - it is implicit that the content is locally
          available.
          But it can be improved as "when receiving locally available IP
          multicast
          or sending IP multicast".

        
        

        PS6: Duplicate
          multicast
          traffic
        

        IP multicast
          distribution
          over architectures using IP mobility solutions  may lead to
          convergence
          of duplicated multicast subscriptions towards the tunnel’s
          downstream
          entity (e.g. MAG in PMIPv6).  Concretely, when multicast
          subscription
          for individual mobile nodes is coupled with mobility tunnels,
          duplicate
          multicast subscription(s) is prone to be received through
          different upstream
          paths. This problem is potentially more severe in a
          distributed mobility
          environment [draft-sfigueiredo-multimob-use-case-dmm-03].
        

         
        

        [Luis>>]
              This
              seems not to be a problem of the IP mobility solutions
              handling multicast
              traffic with mobility tunnels in general, but a problem of
              considering
              several upstream paths ending on the same mobility access
              router as a consequence
              of extending tunnels from previousMAR to newMAR to forward
              the multicast
              traffic.
      

      
[SF] Exactly. Which is more than likely to
          happen in a
          DMM solution, where all "mobility entities" may act as
          "mobility
          access routers", and, after mobility, we want to take
          advantage of
          the tunnel for the subscription. In those cases, care must be
          taken in
          order to not greatly magnify convergence problem observed e.g.
          in RFC6224.

          

          Regards,

          Sérgio

        
        

         
        

        H Anthony Chan
        

         
        

        From: dmm-bounces@ietf.org
          [mailto:dmm-bounces@ietf.org]
          On Behalf Of Sérgio Figueiredo

            Sent: Monday, November 19, 2012 5:24 PM

            To: dmm@ietf.org

            Subject: Re: [DMM] Multicast requirements
        

         
        

        Hi Anthony,

          

          Thank you for trying to progress on this matter. I mostly
          agree with your
          analysis.

          

          As for the question you posed, first I would like to exactly
          understand
          what you mean with "multicast distribution scenario" in "DMM
          solutions should enable multicast services which are
          compatible with multicast
          distribution scenario, etc.".
          It seems like there is no major difference between this and
          the "DMM
          solutions should enable solutions to support multicast
          services."
          requirement? Aren't both expressing the need to enable
          multicast in a DMM
          solution?

          

          As you stated, "neglecting" the requirement 7.1 we proposed,
          leads to the PSs you referred.  So, while 7.2 and 7.3 express
          the
          need for DMM solutions to allow deployment of multicast
          services, 7.1 concerns
           "how" IP multicast should be enabled in order to avoid
          the aforementioned PSs. The usage of the word "flexible"is
          explained
          by: 

          

          "This flexibility enables different IP multicast flows with
          respect
          to a mobile host to be managed (e.g., subscribed, received
          and/or transmitted)
          using multiple endpoints". 

          

          In other words, compatibility with "multicast distribution
          scenario"
          doesn't necessarily avoid PS1 and PS6.

          

          Thank you and best regards,

          Sérgio

          

          On 11/19/2012 10:28 PM, h chan wrote:
        

        There are 3
          proposals for
          multicast requirements. Before comparing these proposals, let
          us understand
          what are the problems first. Two problem statements have been
          proposed:
        

         
        

        PS1 (revised):
          Non-optimal
          routes
        

        Routing via a
          centralized
          anchor often results in a longer route. The problem is
          especially manifested
          when accessing a local server or servers of a Content Delivery
          Network
          (CDN), or when receiving / sending IP multicast packets.
        
        

        PS6: Duplicate
          multicast
          traffic
        

        IP multicast
          distribution
          over architectures using IP mobility solutions  may lead to
          convergence
          of duplicated multicast subscriptions towards the tunnel’s
          downstream
          entity (e.g. MAG in PMIPv6).  Concretely, when multicast
          subscription
          for individual mobile nodes is coupled with mobility tunnels,
          duplicate
          multicast subscription(s) is prone to be received through
          different upstream
          paths. This problem is potentially more severe in a
          distributed mobility
          environment [draft-sfigueiredo-multimob-use-case-dmm-03].
        

         
        

        Then, let us see
          whether
          all the 3 REQ proposals have the same intention. In the
          following, I rephrase
          them to highlight their similarities.
        

         
        

        REQ7.1: Flexible
          multicast
          distribution
        

        DMM solutions
          should be compatible
          with flexible multicast distribution scenario. Etc. 
        

        The Motivation is
          to allow
          flexibility in (enable) multicast solutions to solve the
          problems PS1 and
          PS6 as explained in use cases already presented and discussed
          in multimob
          wg.
        

         
        

        REQ7.2: 
        

        DMM solutions
          should enable
          solutions to support multicast traffic. 
        

         
        

        (Original wording
          was "The
          DMM (unicast) solution MUST be specified in such a way that it
          can be extended
          to also support multicast traffic." I rephrase it to highlight
          the
          similarity with the other proposals and also changed the must
          to should.)
        

         
        

        REQ7.3:
        

        DMM solutions
          should enable
          solutions to support multicast services.
        

         
        

        Original wording
          was “DMM
          solutions should support multicast services … etc. Given that
          it is the
          scope of multimob and not dmm wg to provide the multicast
          solution, I think
          “support†here means “enable†solutions to be developed (by
          multimob).
        

         
        

        Similarity and
          subtle differences:
          Both REQ7.2 and REQ7.3 want to enable multicast services. Yet
          the explanation
          in REQ7.1 seems to indicate not just to enable any one
          multicast solution
          but also needs the flexibility in multicast solution. Not all
          multicast
          solutions are the same. Some of them results in PS1 or PS6. 
        

         
        

        Are there any are
          essential
          differences between:
        

        In REQ7.1, DMM
          solutions
          should be compatible with flexible multicast distribution
          scenario, etc.
        
        

        Versus
        

        DMM solutions
          should enable
          multicast services which are compatible with multicast
          distribution scenario,
          etc.
        

         
        

        H Anthony Chan
        

         
        

        From: dmm-bounces@ietf.org
          [mailto:dmm-bounces@ietf.org]
          On Behalf Of Seil Jeon

            Sent: Monday, November 19, 2012 5:15 AM

            To: pierrick.seite@orange.com

            Cc: dmm@ietf.org

            Subject: Re: [DMM] Multicast requirements
        

         
        

        Hi Pierrick,
        

         
        

        I’ve many times thought about your
          question.
          I would say how effectively should we deploy/support multicast
          over distributed
          mobility rather than distributed mobile multicast. As a
          result, you can
          find this deployment use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
          presented in multimob several times.
        

         
        

        In unicast DMM, main innovation is
          to distribute
          the anchor function at many access routers from single core.
          Following
          architectural concept of DMM, flexible multicast distribution
          is one of
          multicast requirement resulted from the draft described above.
        
        

         
        

        REQ8: Flexible multicast
          distribution
        

        "DMM solutions SHOULD be
          compatible
          with flexible multicast distribution scenarios. This
          flexibility enables
          different IP multicast flows with respect to a mobile host to
          be managed
          (e.g., subscribed, received and/or transmitted) using multiple
          endpoints".
          

          

          Motivation: The motivation for this requirement is to enable
          flexibility
          in multicast distribution. The multicast solution may
          therefore avoid having
          multicast-capable access routers being restricted to manage
          all IP multicast
          traffic relative to a host via a single endpoint (e.g. regular
          or tunnel
          interface), which would lead to the problems described in PS1
          and PS6.
        

        PS6: Duplicate multicast
          traffic
        

        IP multicast distribution
          over
          architectures using IP mobility solutions  may lead to
          convergence
          of duplicated multicast subscriptions towards the tunnel’s
          downstream
          entity (e.g. MAG in PMIPv6).  Concretely, when multicast
          subscription
          for individual mobile nodes is coupled with mobility tunnels,
          duplicate
          multicast subscription(s) is prone to be received through
          different upstream
          paths. This problem is potentially more severe in a
          distributed mobility
          environment [draft-sfigueiredo-multimob-use-case-dmm-03].

          

          

        
        

        Regards,
        

         
        

        Seil
        

         
        

        From: pierrick.seite@orange.com
          [mailto:pierrick.seite@orange.com]
          

            Sent: Monday, November 19, 2012 8:55 AM

            To: 'karagian@cs.utwente.nl';
        seiljeon@av.it.pt;
        JuanCarlos.Zuniga@InterDigital.com

            Cc: dmm@ietf.org

            Subject: RE: [DMM] Multicast requirements
        

         
        

        Hi all,
        

         
        

        I tend to agree
          with Georgious,
          however I still do not figure out what is the use-case for
          distributed
          mobile multicast (other than academic considerations)? Can
          someone give
          concrete example? 
        

         
        

        I haven’t real all
          messages
          from this thread. So, maybe I missed important points.
        

         
        

        BR,
        

        Pierrick
        

         
        

        De : dmm-bounces@ietf.org
          [mailto:dmm-bounces@ietf.org]
          De la part de karagian@cs.utwente.nl

            Envoyé : samedi 17 novembre 2012 13:01

            À : seiljeon@av.it.pt;
        JuanCarlos.Zuniga@InterDigital.com

            Cc : dmm@ietf.org

            Objet : Re: [DMM] Multicast requirements
        

         
        

        Hi all,
        

         
        

        I also agree that the DMM solution
          should
          somehow consider muticast deployment. However, I do not thnk
          that the DMM
          WG is the right WG to provide the multicast based DMM
          solution!
        

         
        

        One alternative solution will be to
          have
          a multicast requirement that emphasizes the need of having
          extensibility
          hooks (possibilities) that can be used later on by the
          multimob WG to provide
          a 
        

        a multicast enabled DMM solution!
        

         
        

         
        

        So a requirement that specifies
          something
          like the following could be used for this purpose:
        

         
        

        "The DMM (unicast) solution MUST be
          specified in such a way that it can be extended to also
          support multicast
          traffic."
        

         
        

         
        

        Best regards,
        

        Georgios
        

         
        

         
        

         
      

      

        

        

      

      Van: dmm-bounces@ietf.org
        [dmm-bounces@ietf.org]
        namens Seil Jeon [seiljeon@av.it.pt]

          Verzonden: vrijdag 16 november 2012 22:25

          To: 'Zuniga, Juan Carlos'

          Cc: dmm@ietf.org

          Onderwerp: Re: [DMM] Multicast requirements
      

      Hi Juan,

        

        I've been looked at changed flow of your proposed text but sorry
        now that
        my

        comment is posted.

        At first time, I couldn't make sure however, on hearing Stig's
        description,

        it seems quite reasonable at the first step, not giving any
        restrictions
        but

        leaving some-specific for the DMM solution it does not support
        multicast.

        

        On the other hand, it remains at a basic stage for the DMM
        solution to

        support multicast.

        So I think additional requirements need to be made for the DMM
        solution,

        accordingly. But of course, this should not also give any
        specific

        limitation and restriction but should be made towards the
        direction not

        limiting the benefits provided by distributed deployment.

        

        I hope to get more comments on this.

        

        Regards,

        

        Seil

        

        

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

        From: dmm-bounces@ietf.org
        [mailto:dmm-bounces@ietf.org]
        On Behalf Of

        Zuniga, Juan Carlos

        Sent: Friday, November 16, 2012 8:14 PM

        To: Stig Venaas; dmm@ietf.org

        Subject: Re: [DMM] Multicast requirements

        

        

        > -----Original Message-----

        > From: Stig Venaas [mailto:stig@venaas.com]

        > Sent: Friday, November 16, 2012 3:01 PM

        > To: jouni korhonen

        > Cc: sarikaya@ieee.org;
        Zuniga, Juan Carlos; Konstantinos Pentikousis; 

        > Peter McCann; dmm@ietf.org

        > Subject: Re: [DMM] Multicast requirements

        > 

        > On 11/15/2012 3:17 AM, jouni korhonen wrote:

        > >

        > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

        > >

        > >>

        > >> I think we are reading too much into multicast and
        unicast
        should

        be

        > >> designed in an integrated manner.

        > >>

        > >> The fact is that multicast is considered as an
        area of

        > specialization,

        > >> it requires knowledge of very different protocols
        than we
        are 

        > >> accustomed to in mobility.

        > >

        > > "Requirement: DMM solutions SHOULD support multicast
        services.
        If a

        > specific DMM solution does not support multicast services,
        an 

        > explanation MUST be provided."

        > 

        > This sounds good to me.

        > 

        > The main thing I want to achieve is what was describes as
        motivation
        

        > earlier in this thread. Multicast should at least be
        considered when
        

        > looking into DMM solutions, and not just an afterthought
        once the
        

        > solution is decided.

        > 

        > Stig

        

        [JCZ] I fully agree with this. That was the intention of the
        proposed text.

        

        Regards,

        

        Juan Carlos

        

        > 

        > > To me that reads basically "do not break foundations
        for
        multicast

        > unless you have a valid & documented reason for it".
         If
        we look e.g.

        > into RFC625 multicast wording that is there very briefly
        but gives
        a 

        > hint to a developer where to head to. That is the level I
        would expect
        

        > DMM documents should aim to.

        > >

        > > - Jouni

        > >

        > >

        > >> Let dmm deal with its current charter that does
        not include
        a word

        > of

        > >> multicast and if everything goes well we can come
        back and
        discuss

        > dmm

        > >> multicast.

        > >>

        > >> Regards,

        > >>

        > >> Behcet

        

        _______________________________________________

        dmm mailing list

        dmm@ietf.org

        https://www.ietf.org/mailman/listinfo/dmm

        

        _______________________________________________

        dmm mailing list

        dmm@ietf.org

        https://www.ietf.org/mailman/listinfo/dmm
      

      _________________________________________________________________________________________________________________________
      

       
      

      Ce message et ses pieces jointes
        peuvent
        contenir des informations confidentielles ou privilegiees et ne
        doivent
        donc
      

      pas etre diffuses, exploites ou
        copies
        sans autorisation. Si vous avez recu ce message par erreur,
        veuillez le
        signaler
      

      a l'expediteur et le detruire
        ainsi
        que les pieces jointes. Les messages electroniques etant
        susceptibles d'alteration,
      

      France Telecom - Orange decline
        toute
        responsabilite si ce message a ete altere, deforme ou falsifie.
        Merci.
      

       
      

      This message and its attachments
        may
        contain confidential or privileged information that may be
        protected by
        law;
      

      they should not be distributed,
        used
        or copied without authorisation.
      

      If you have received this email
        in
        error, please notify the sender and delete this message and its
        attachments.
      

      As emails may be altered, France
        Telecom
        - Orange is not liable for messages that have been modified,
        changed or
        falsified.
      

      Thank you.
      

      

        

        

      
      

      _______________________________________________
      

      dmm mailing list
      

      dmm@ietf.org
      

      https://www.ietf.org/mailman/listinfo/dmm
      

       
      


        
      

      


        Este mensaje se dirige exclusivamente a su destinatario. Puede
        consultar
        nuestra política de envío y recepción de correo electrónico en
        el enlace
        situado más abajo.

        This message is intended exclusively for its addressee. We only
        send and
        receive email on the basis of the terms set out at:

        http://www.tid.es/ES/PAGINAS/disclaimer.aspx

        

      
      

      _______________________________________________

        dmm mailing list

      dmm@ietf.org

      https://www.ietf.org/mailman/listinfo/dmm

      
      

      _______________________________________________

          dmm mailing list

          dmm@ietf.org

          https://www.ietf.org/mailman/listinfo/dmm

        
      

    

    

  


--------------030107020209090801030106--

From seiljeon@av.it.pt  Thu Nov 22 14:27:10 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D985221F86B7 for ; Thu, 22 Nov 2012 14:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.753
X-Spam-Level: 
X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkab1AVJTPLW for ; Thu, 22 Nov 2012 14:27:08 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2721F86AB for ; Thu, 22 Nov 2012 14:27:06 -0800 (PST)
Received: from [193.120.41.115] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67103757; Thu, 22 Nov 2012 22:27:02 +0000
From: "Seil Jeon" 
To: 
References:  <50ADF1D4.6070102@av.it.pt>
In-Reply-To: <50ADF1D4.6070102@av.it.pt>
Date: Thu, 22 Nov 2012 22:27:21 -0000
Message-ID: <017701cdc900$8b92a940$a2b7fbc0$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01CDC900.8BA5BC10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLv90wWgrs4VN0kqprTcwHSy8Kf8AJNoL4ClZ+g5nA=
Content-Language: ko
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?562U5aSNOiBSZTogIE11bHRpY2FzdCBQUyB0byByZXF1aXJl?= =?utf-8?q?ments?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 22:27:11 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0178_01CDC900.8BA5BC10
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Luo,

=20

Additionally following the comment by Sergio,

=20

=20

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 AM
To: luo.wen@zte.com.cn
Cc: dmm@ietf.org
Subject: Re: [DMM] =E7=AD=94=E5=A4=8D: Re: Multicast PS to requirements

=20

Hi Luo,

Thanks for your comment. My answer is placed inline:

On 11/22/2012 08:02 AM, luo.wen@zte.com.cn wrote:


Hi S=C3=A9rgio=20

> PS6: Duplicate multicast traffic=20
> IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast subscriptions =
towards the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
>Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].=20
 =20
>[Luis>>] This seems not to be a problem of the IP mobility solutions =
handling multicast traffic with mobility tunnels in general, but a =
problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic.=20

> [SF] Exactly. Which is more than likely to happen in a DMM solution, =
where all "mobility entities" may act as "mobility access routers", and, =
after mobility, we want to take advantage of the tunnel for the =
subscription. In those cases, care must be taken in order to not greatly =
magnify convergence problem observed e.g. in RFC6224.=20

[Luowen] According to the above discussion, I believe the PS6  is based =
on the usage scenarios discussed in =
draft-sfigueiredo-multimob-use-case-dmm-03. But, it seems to me the =
usage scenarios in this draft is based on a assumed dmm unicast solution =
and architecture. IMHO, the PS should be based on current existing =
protocol (e.g. RFC) or current deployment, not a assumed solution.

SF: PS6 is observable is both existing protocols (e.g. RFC6224) and in =
the use cases we analyzed - in a PMIPv6-based DMM solution. So I assume =
the PS fits in the REQs document. As I said before, if ignored, the =
tunnel convergence problem might be a much serious problem than in =
RFC6224.

>> In the use case draft, there are any solutions not assumed. We =
presented use cases, having various deployments of existing multicast =
standard entities, and corresponding analysis based on distributed =
deployment specified in DMM REQ1.

No more, no less.

=20

Regards,

=20

Seil











S=C3=A9rgio Figueiredo   =
=20
=E5=8F=91=E4=BB=B6=E4=BA=BA:  dmm-bounces@ietf.org=20

2012/11/21 07:21=20


=E6=94=B6=E4=BB=B6=E4=BA=BA

dmm@ietf.org=20


=E6=8A=84=E9=80=81

=09

=E4=B8=BB=E9=A2=98

Re: [DMM] Multicast PS to requirements

=20

	=09




Hi Luis,

A few more comments on this inline:

Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:=20
Hi Anthony,=20
 =20
some comments in line=20
 =20
Best regards,=20
 =20
Luis=20
 =20
De:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] En nombre de =
h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: S=C3=A9rgio Figueiredo;   dmm@ietf.org
Asunto: [DMM] Multicast PS to requirements=20
 =20
Let us also use another thread to check for consensus of the PS from =
multimob.=20
 =20
PS1 (revised): Non-optimal routes=20
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / sending =
IP multicast packets.=20
[Luis>>] This is correct if the multicast content is locally available. =
However this could not be always the case for multicast listeners, for a =
number of reasons (for instance, conflict in the multicast address =
allocation between the Home Network and the DMM domain).=20

[SF] Sure, and the same applies to "accessing a local server a CDN" - it =
is implicit that the content is locally available. But it can be =
improved as "when receiving locally available IP multicast or sending IP =
multicast".

PS6: Duplicate multicast traffic=20
IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].=20
 =20
[Luis>>] This seems not to be a problem of the IP mobility solutions =
handling multicast traffic with mobility tunnels in general, but a =
problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic.=20

[SF] Exactly. Which is more than likely to happen in a DMM solution, =
where all "mobility entities" may act as "mobility access routers", and, =
after mobility, we want to take advantage of the tunnel for the =
subscription. In those cases, care must be taken in order to not greatly =
magnify convergence problem observed e.g. in RFC6224.

Regards,
S=C3=A9rgio

 =20
H Anthony Chan=20
 =20
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of =
S=C3=A9rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To:   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements=20
 =20
Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with =
your analysis.

As for the question you posed, first I would like to exactly understand =
what you mean with "multicast distribution scenario" in "DMM solutions =
should enable multicast services which are compatible with multicast =
distribution scenario, etc.". It seems like there is no major difference =
between this and the "DMM solutions should enable solutions to support =
multicast services." requirement? Aren't both expressing the need to =
enable multicast in a DMM solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to =
the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM =
solutions to allow deployment of multicast services, 7.1 concerns  "how" =
IP multicast should be enabled in order to avoid the aforementioned PSs. =
The usage of the word "flexible"is explained by:=20

"This flexibility enables different IP multicast flows with respect to a =
mobile host to be managed (e.g., subscribed, received and/or =
transmitted) using multiple endpoints".=20

In other words, compatibility with "multicast distribution scenario" =
doesn't necessarily avoid PS1 and PS6.

Thank you and best regards,
S=C3=A9rgio

On 11/19/2012 10:28 PM, h chan wrote:=20
There are 3 proposals for multicast requirements. Before comparing these =
proposals, let us understand what are the problems first. Two problem =
statements have been proposed:=20
 =20
PS1 (revised): Non-optimal routes=20
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / sending =
IP multicast packets.=20
PS6: Duplicate multicast traffic=20
IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].=20
 =20
Then, let us see whether all the 3 REQ proposals have the same =
intention. In the following, I rephrase them to highlight their =
similarities.=20
 =20
REQ7.1: Flexible multicast distribution=20
DMM solutions should be compatible with flexible multicast distribution =
scenario. Etc.=20
The Motivation is to allow flexibility in (enable) multicast solutions =
to solve the problems PS1 and PS6 as explained in use cases already =
presented and discussed in multimob wg.=20
 =20
REQ7.2:=20
DMM solutions should enable solutions to support multicast traffic.=20
 =20
(Original wording was "The DMM (unicast) solution MUST be specified in =
such a way that it can be extended to also support multicast traffic." I =
rephrase it to highlight the similarity with the other proposals and =
also changed the must to should.)=20
 =20
REQ7.3:=20
DMM solutions should enable solutions to support multicast services.=20
 =20
Original wording was =E2=80=9CDMM solutions should support multicast =
services =E2=80=A6 etc. Given that it is the scope of multimob and not =
dmm wg to provide the multicast solution, I think =
=E2=80=9Csupport=E2=80=9D here means =E2=80=9Cenable=E2=80=9D solutions =
to be developed (by multimob).=20
 =20
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable =
multicast services. Yet the explanation in REQ7.1 seems to indicate not =
just to enable any one multicast solution but also needs the flexibility =
in multicast solution. Not all multicast solutions are the same. Some of =
them results in PS1 or PS6.=20
 =20
Are there any are essential differences between:=20
In REQ7.1, DMM solutions should be compatible with flexible multicast =
distribution scenario, etc.=20
Versus=20
DMM solutions should enable multicast services which are compatible with =
multicast distribution scenario, etc.=20
 =20
H Anthony Chan=20
 =20
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of =
Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To:   pierrick.seite@orange.com
Cc:   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements=20
 =20
Hi Pierrick,=20
 =20
I=E2=80=99ve many times thought about your question. I would say how =
effectively should we deploy/support multicast over distributed mobility =
rather than distributed mobile multicast. As a result, you can find this =
deployment use case and gap analysis at  =
 =
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 =
presented in multimob several times.=20
 =20
In unicast DMM, main innovation is to distribute the anchor function at =
many access routers from single core. Following architectural concept of =
DMM, flexible multicast distribution is one of multicast requirement =
resulted from the draft described above.=20
 =20
REQ8: Flexible multicast distribution=20
"DMM solutions SHOULD be compatible with flexible multicast distribution =
scenarios. This flexibility enables different IP multicast flows with =
respect to a mobile host to be managed (e.g., subscribed, received =
and/or transmitted) using multiple endpoints".=20

Motivation: The motivation for this requirement is to enable flexibility =
in multicast distribution. The multicast solution may therefore avoid =
having multicast-capable access routers being restricted to manage all =
IP multicast traffic relative to a host via a single endpoint (e.g. =
regular or tunnel interface), which would lead to the problems described =
in PS1 and PS6.=20
PS6: Duplicate multicast traffic=20
IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].



Regards,=20
 =20
Seil=20
 =20
From:   pierrick.seite@orange.com [ =
 mailto:pierrick.seite@orange.com]=20
Sent: Monday, November 19, 2012 8:55 AM
To: '  karagian@cs.utwente.nl';  =
 seiljeon@av.it.pt;  =
 =
JuanCarlos.Zuniga@InterDigital.com
Cc:   dmm@ietf.org
Subject: RE: [DMM] Multicast requirements=20
 =20
Hi all,=20
 =20
I tend to agree with Georgious, however I still do not figure out what =
is the use-case for distributed mobile multicast (other than academic =
considerations)? Can someone give concrete example?=20
 =20
I haven=E2=80=99t real all messages from this thread. So, maybe I missed =
important points.=20
 =20
BR,=20
Pierrick=20
 =20
De :   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] De la part de =
  karagian@cs.utwente.nl
Envoy=C3=A9 : samedi 17 novembre 2012 13:01
=C3=80 :   seiljeon@av.it.pt;  =
 =
JuanCarlos.Zuniga@InterDigital.com
Cc :   dmm@ietf.org
Objet : Re: [DMM] Multicast requirements=20
 =20
Hi all,=20
 =20
I also agree that the DMM solution should somehow consider muticast =
deployment. However, I do not thnk that the DMM WG is the right WG to =
provide the multicast based DMM solution!=20
 =20
One alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a=20
a multicast enabled DMM solution!=20
 =20
 =20
So a requirement that specifies something like the following could be =
used for this purpose:=20
 =20
"The DMM (unicast) solution MUST be specified in such a way that it can =
be extended to also support multicast traffic."=20
 =20
 =20
Best regards,=20
Georgios=20
 =20
 =20
 =20

=20

  _____ =20


Van:   dmm-bounces@ietf.org [ =
 dmm-bounces@ietf.org] namens Seil Jeon [ =
 seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc:   dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements=20
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now =
that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's =
description,
it seems quite reasonable at the first step, not giving any restrictions =
but
leaving some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas;   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [  mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc:   sarikaya@ieee.org; Zuniga, Juan =
Carlos; Konstantinos Pentikousis;=20
> Peter McCann;   dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>=20
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are=20
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an=20
> explanation MUST be provided."
>=20
> This sounds good to me.
>=20
> The main thing I want to achieve is what was describes as motivation=20
> earlier in this thread. Multicast should at least be considered when=20
> looking into DMM solutions, and not just an afterthought once the=20
> solution is decided.
>=20
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed =
text.

Regards,

Juan Carlos

>=20
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a=20
> hint to a developer where to head to. That is the level I would expect =

> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm=20
_________________________________________________________________________=
________________________________________________=20
 =20
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc=20
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler=20
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,=20
France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.=20
 =20
This message and its attachments may contain confidential or privileged =
information that may be protected by law;=20
they should not be distributed, used or copied without authorisation.=20
If you have received this email in error, please notify the sender and =
delete this message and its attachments.=20
As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.=20
Thank you.=20




_______________________________________________=20
dmm mailing list=20
  dmm@ietf.org=20
  =
https://www.ietf.org/mailman/listinfo/dmm=20
 =20

=20

  _____ =20


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar =
nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo =
electr=C3=B3nico en el enlace situado m=C3=A1s abajo.
This message is intended exclusively for its addressee. We only send and =
receive email on the basis of the terms set out at:
  =
http://www.tid.es/ES/PAGINAS/disclaimer.aspx


_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

=20


------=_NextPart_000_0178_01CDC900.8BA5BC10
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Luo,
 
Additionally following the comment by =
Sergio,
 
 
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 =
AM
To: luo.wen@zte.com.cn
Cc: =
dmm@ietf.org
Subject: Re: [DMM] =E7=AD=94=E5=A4=8D: Re: Multicast PS to =
requirements
 
Hi =
Luo,

Thanks for your comment. My answer is placed =
inline:

On 11/22/2012 08:02 AM, luo.wen@zte.com.cn =
wrote:

Hi =
S=C3=A9rgio 

> PS6: Duplicate multicast traffic 
> IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  >Concretely, when multicast subscription for =
individual mobile nodes is coupled with mobility tunnels, duplicate =
multicast subscription(s) is prone to be received through different =
upstream paths. This problem is potentially more severe in a distributed =
mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03]. 
  
>[Luis>>] This seems not to be a problem of the IP mobility =
solutions handling multicast traffic with mobility tunnels in general, =
but a problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic. =

> [SF] Exactly. =
Which is more than likely to happen in a DMM solution, where all =
"mobility entities" may act as "mobility access =
routers", and, after mobility, we want to take advantage of the =
tunnel for the subscription. In those cases, care must be taken in order =
to not greatly magnify convergence problem observed e.g. in =
RFC6224. 
[Luowen] According to the above discussion, I =
believe the PS6  is based on the usage scenarios discussed in =
draft-sfigueiredo-multimob-use-case-dmm-03. But, it =
seems to me the usage scenarios =
in this draft is based on a assumed dmm unicast solution and =
architecture. IMHO, the PS should be based on current existing protocol =
(e.g. RFC) or current deployment, not a assumed =
solution.
SF: PS6 is observable is both existing =
protocols (e.g. RFC6224) and in the use cases we analyzed - in a =
PMIPv6-based DMM solution. So I assume the PS fits in the REQs document. =
As I said before, if ignored, the tunnel convergence problem might be a =
much serious problem than in RFC6224.

>> In the use case draft, there are any solutions not assumed. =
We presented use cases, having various deployments of existing multicast =
standard entities, and corresponding analysis based on distributed =
deployment specified in DMM REQ1.
No more, no less.
 
Regards,
 
Seil





S=C3=A9rgio =
Figueiredo <sfigueiredo@av.it.pt> =

=E5=8F=91=E4=BB=B6=E4=BA=BA:  dmm-bounces@ietf.org =

2012/11/21 =
07:21 
=E6=94=B6=E4=BB=B6=
=E4=BA=BA
dmm@ietf.org =

=E6=8A=84=E9=80=81=

=E4=B8=BB=
=E9=A2=98
Re: [DMM] =
Multicast PS to requirements
 



Hi =
Luis,

A few more comments on this inline:

Em 20-11-2012 =
19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu: 
Hi Anthony, 
  
some comments in line 
  
Best regards, 
  
Luis 
  
De: =
dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] En =
nombre de h chan
Enviado el: martes, 20 de noviembre de =
2012 18:51
Para: S=C3=A9rgio Figueiredo; dmm@ietf.org=

Asunto:<=
/span> [DMM] =
Multicast PS to requirements 
  
Let us also use another thread to check for consensus of the PS from =
multimob. 
  
PS1 (revised): Non-optimal routes 
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / =
sending IP multicast packets. 
[Luis>>] This is correct if the multicast content is locally =
available. However this could not be always the case for multicast =
listeners, for a number of reasons (for instance, conflict in the =
multicast address allocation between the Home Network and the DMM =
domain). 
[SF] Sure, and the same =
applies to "accessing a local server a CDN" - it is implicit =
that the content is locally available. But it can be improved as =
"when receiving locally available IP multicast or sending IP =
multicast".

PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment [draft-sfigueiredo-multimob-use-case-dmm-03]. =

  
[Luis>>] This seems not to be a problem of the IP mobility =
solutions handling multicast traffic with mobility tunnels in general, =
but a problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic. =

[SF] Exactly. Which is more than likely to happen in a =
DMM solution, where all "mobility entities" may act as =
"mobility access routers", and, after mobility, we want to =
take advantage of the tunnel for the subscription. In those cases, care =
must be taken in order to not greatly magnify convergence problem =
observed e.g. in RFC6224.

Regards,
S=C3=A9rgio

  
H Anthony Chan 
  
From:=
 =
dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] On =
Behalf Of S=C3=A9rgio Figueiredo
Sent: Monday, November =
19, 2012 5:24 PM
To: dmm@ietf.org=

Subject:=
 Re: [DMM] =
Multicast requirements 
  
Hi Anthony,

Thank =
you for trying to progress on this matter. I mostly agree with your =
analysis.

As for the question you posed, first I would like to =
exactly understand what you mean with "multicast distribution =
scenario" in "DMM solutions should enable multicast services which are compatible =
with multicast distribution scenario, etc.". It seems like =
there is no major difference between this and the "DMM solutions should enable solutions to support multicast =
services." requirement? Aren't both expressing the need to =
enable multicast in a DMM solution?

As you stated, =
"neglecting" the requirement 7.1 we proposed, leads to the PSs =
you referred.  So, while 7.2 and 7.3 express the need for DMM =
solutions to allow deployment of multicast services, 7.1 concerns =
 "how" IP multicast should be enabled in order to avoid =
the aforementioned PSs. The usage of the word "flexible"is =
explained by: 

"This flexibility enables different IP =
multicast flows with respect to a mobile host to be managed (e.g., =
subscribed, received and/or transmitted) using multiple endpoints". =


In other words, compatibility with "multicast distribution =
scenario" doesn't necessarily avoid PS1 and PS6.

Thank you =
and best regards,
S=C3=A9rgio

On 11/19/2012 10:28 PM, h chan =
wrote: 
There are 3 proposals for multicast requirements. Before comparing =
these proposals, let us understand what are the problems first. Two =
problem statements have been proposed: 
  
PS1 (revised): Non-optimal routes 
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / =
sending IP multicast packets. 
PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment [draft-sfigueiredo-multimob-use-case-dmm-03]. =

  
Then, let us see whether all the 3 REQ proposals have the same =
intention. In the following, I rephrase them to highlight their =
similarities. 
  
REQ7.1: Flexible multicast distribution 
DMM solutions should be compatible with flexible multicast =
distribution scenario. Etc. 
The Motivation is to allow flexibility in (enable) multicast =
solutions to solve the problems PS1 and PS6 as explained in use cases =
already presented and discussed in multimob wg. 
  
REQ7.2: 
DMM solutions should enable solutions to support multicast traffic. =

  
(Original wording was "The DMM (unicast) solution MUST be =
specified in such a way that it can be extended to also support =
multicast traffic." I rephrase it to highlight the similarity with =
the other proposals and also changed the must to should.) =

  
REQ7.3: 
DMM solutions should enable solutions to support multicast =
services. 
  
Original wording was =E2=80=9CDMM solutions should support multicast =
services =E2=80=A6 etc. Given that it is the scope of multimob and not =
dmm wg to provide the multicast solution, I think =
=E2=80=9Csupport=E2=80=9D here means =E2=80=9Cenable=E2=80=9D solutions =
to be developed (by multimob). 
  
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to =
enable multicast services. Yet the explanation in REQ7.1 seems to =
indicate not just to enable any one multicast solution but also needs =
the flexibility in multicast solution. Not all multicast solutions are =
the same. Some of them results in PS1 or PS6. 
  
Are there any are essential differences between: 
In REQ7.1, DMM solutions should be compatible with flexible multicast =
distribution scenario, etc. 
Versus 
DMM solutions should enable multicast services which are compatible =
with multicast distribution scenario, etc. 
  
H Anthony Chan 
  
From:=
 =
dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] On =
Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 =
AM
To: pierrick.sei=
te@orange.com
Cc: dmm@ietf.org=

Subject:=
 Re: [DMM] =
Multicast requirements 
  
Hi =
Pierrick, 
 =
 
I=E2=80=99ve =
many times thought about your question. I would say how effectively =
should we deploy/support multicast over distributed mobility rather than =
distributed mobile multicast. As a result, you can find this deployment =
use case and gap analysis at http://tools.=
ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented =
in multimob several times. 
 =
 
In unicast =
DMM, main innovation is to distribute the anchor function at many access =
routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted =
from the draft described above. 
 =
 
REQ8: Flexible multicast distribution 
"DMM solutions =
SHOULD be compatible with flexible multicast distribution scenarios. =
This flexibility enables different IP multicast flows with respect to a =
mobile host to be managed (e.g., subscribed, received and/or =
transmitted) using multiple endpoints". 

Motivation: The =
motivation for this requirement is to enable flexibility in multicast =
distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP =
multicast traffic relative to a host via a single endpoint (e.g. regular =
or tunnel interface), which would lead to the problems described in PS1 =
and PS6. 
PS6: Duplicate multicast traffic 
IP multicast =
distribution over architectures using IP mobility solutions  may =
lead to convergence of duplicated multicast subscriptions towards the =
tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6). =
 Concretely, when multicast subscription for individual mobile =
nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].



Regards, 
 =
 
Seil =

 =
 
From:=
 =
pierrick.sei=
te@orange.com [mailto:pierr=
ick.seite@orange.com] =

Sent: Monday, November 19, 2012 8:55 AM
To: =
'karagian@cs.=
utwente.nl'; =
seiljeon@av.=
it.pt; JuanCarlos.Z=
uniga@InterDigital.com
Cc: dmm@ietf.org=

Subject:=
 RE: [DMM] =
Multicast requirements 
  
Hi all, 
  
I tend to agree with Georgious, however I still do not figure out =
what is the use-case for distributed mobile multicast (other than =
academic considerations)? Can someone give concrete example? =

  
I haven=E2=80=99t real all messages from this thread. So, maybe I =
missed important points. 
  
BR, 
Pierrick 
  
De =
: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] De la =
part de karagian@cs.=
utwente.nl
Envoy=C3=
=A9 : samedi 17 =
novembre 2012 13:01
=C3=80 : seiljeon@av.=
it.pt; JuanCarlos.Z=
uniga@InterDigital.com
Cc =
: dmm@ietf.org=

Objet =
: Re: [DMM] =
Multicast requirements 
  
Hi =
all, 
  
I also =
agree that the DMM solution should somehow consider muticast deployment. =
However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution! 
  
One =
alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a 
a multicast =
enabled DMM solution! 
  
  
So a =
requirement that specifies something like the following could be used =
for this purpose: 
  
"The =
DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic." 
  
  
Best =
regards, 
Georgios 
  
  
  
 

Van:<=
/b> =
dmm-bounces@=
ietf.org [dmm-bounces@=
ietf.org] namens =
Seil Jeon [seiljeon@av.=
it.pt]
Verz=
onden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan =
Carlos'
Cc: dmm@ietf.org=

Onderwer=
p: Re: [DMM] =
Multicast requirements 
Hi =
Juan,

I've been looked at changed flow of your proposed text but =
sorry now that my
comment is posted.
At first time, I couldn't =
make sure however, on hearing Stig's description,
it seems quite =
reasonable at the first step, not giving any restrictions but
leaving =
some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the =
DMM solution to
support multicast.
So I think additional =
requirements need to be made for the DMM solution,
accordingly. But =
of course, this should not also give any specific
limitation and =
restriction but should be made towards the direction not
limiting the =
benefits provided by distributed deployment.

I hope to get more =
comments on this.

Regards,

Seil


-----Original =
Message-----
From: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] On Behalf =
Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 =
PM
To: Stig Venaas; dmm@ietf.org=

Subject:=
 Re: [DMM] Multicast requirements


> -----Original =
Message-----
> From: Stig Venaas [mailto:stig@=
venaas.com]
> =
Sent: Friday, November 16, 2012 3:01 PM
> To: jouni =
korhonen
> Cc: sarikaya@iee=
e.org; Zuniga, =
Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann; dmm@ietf.org=

> =
Subject: Re: [DMM] Multicast requirements
> 
> On 11/15/2012 =
3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, =
2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> =
>>
> >> I think we are reading too much into multicast =
and unicast should
be
> >> designed in an integrated =
manner.
> >>
> >> The fact is that multicast is =
considered as an area of
> specialization,
> >> it =
requires knowledge of very different protocols than we are 
> =
>> accustomed to in mobility.
> >
> > =
"Requirement: DMM solutions SHOULD support multicast services. If =
a
> specific DMM solution does not support multicast services, an =

> explanation MUST be provided."
> 
> This =
sounds good to me.
> 
> The main thing I want to achieve is =
what was describes as motivation 
> earlier in this thread. =
Multicast should at least be considered when 
> looking into DMM =
solutions, and not just an afterthought once the 
> solution is =
decided.
> 
> Stig

[JCZ] I fully agree with this. =
That was the intention of the proposed text.

Regards,

Juan =
Carlos

> 
> > To me that reads basically "do not =
break foundations for multicast
> unless you have a valid & =
documented reason for it".  If we look e.g.
> into =
RFC625 multicast wording that is there very briefly but gives a 
> =
hint to a developer where to head to. That is the level I would expect =

> DMM documents should aim to.
> >
> > - =
Jouni
> >
> >
> >> Let dmm deal with its =
current charter that does not include a word
> of
> >> =
multicast and if everything goes well we can come back and =
discuss
> dmm
> >> multicast.
> >>
> =
>> Regards,
> >>
> >> =
Behcet

_______________________________________________
dmm =
mailing list<=
br>dmm@ietf.org=
<=
br>https://www.=
ietf.org/mailman/listinfo/dmm

____=
___________________________________________
dmm mailing =
list<=
br>dmm@ietf.org=
<=
br>https://www.=
ietf.org/mailman/listinfo/dmm 
___________________________________________________________________=
______________________________________________________ 
  =

Ce =
message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc 
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler 
a l'expediteur et =
le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration, 
France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci. 
  =

This =
message and its attachments may contain confidential or privileged =
information that may be protected by law; 
they should not be =
distributed, used or copied without authorisation. 
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments. 
As emails may be =
altered, France Telecom - Orange is not liable for messages that have =
been modified, changed or falsified. 
Thank you. =





_______________________________________________ 
dmm mailing =
list 
dmm@ietf.org 
https://www.ietf.org/mailman/listinfo/dmm 
  =

 
Este mensaje se dirige exclusivamente a su destinatario. Puede =
consultar nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo =
electr=C3=B3nico en el enlace situado m=C3=A1s abajo.
This message is =
intended exclusively for its addressee. We only send and receive email =
on the basis of the terms set out at:http://www.tid=
.es/ES/PAGINAS/disclaimer.aspx


_______________________________________________
dmm mailing =
list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

______________________________________________=
_
dmm mailing list
dmm@ietf.org
https://www.ietf.org/m=
ailman/listinfo/dmm
 

------=_NextPart_000_0178_01CDC900.8BA5BC10--


From luo.wen@zte.com.cn  Sun Nov 25 19:03:22 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66221F862E for ; Sun, 25 Nov 2012 19:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.548
X-Spam-Level: 
X-Spam-Status: No, score=-94.548 tagged_above=-999 required=5 tests=[CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.606, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUdB8V2p47Ie for ; Sun, 25 Nov 2012 19:03:13 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 340A121F84B5 for ; Sun, 25 Nov 2012 19:03:09 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 23068125C829; Mon, 26 Nov 2012 11:04:40 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAQ32sg4061392; Mon, 26 Nov 2012 11:02:54 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <017701cdc900$8b92a940$a2b7fbc0$@av.it.pt>
To: "Seil Jeon" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: luo.wen@zte.com.cn
Date: Mon, 26 Nov 2012 11:02:53 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-26 11:02:42, Serialize complete at 2012-11-26 11:02:42
Content-Type: multipart/alternative; boundary="=_alternative 0010C19B48257AC2_="
X-MAIL: mse01.zte.com.cn qAQ32sg4061392
Cc: dmm@ietf.org
Subject: [DMM] =?gb2312?b?tPC4tDogUkU6ICC08Li0OiBSZTogIE11bHRpY2FzdCBQUyB0?= =?gb2312?b?byByZXF1aXJlbWVudHM=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Nov 2012 03:03:22 -0000

This is a multipart message in MIME format.
--=_alternative 0010C19B48257AC2_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgU2VpbCAmIFPDqXJnaW86DQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBseSwgQW5kIHdpdGgg
YWxsIHJlc3BlY3QsIEkgZG9uJ3Qga25vdyB3aGVyZSBhcmUgeW91IA0KY29taW5nIGZyb20gd2hl
biB5b3Ugc2F5IHRoZXJlIGFyZSBhbnkgc29sdXRpb25zIG5vdCBhc3N1bWVkPyANCg0KV2hlbiBJ
IHJlYWQgeW91ciBkcmFmdCwgeW91IGhhdmUgYXNzdW1wdGlvbiBBMyA6IA0KSXQgaXMgYXNzdW1l
ZCB0aGF0IHdoZW4gdGhlIElQIG1vYmlsaXR5IGhhcHBlbnMsIGF0IGxlYXN0IG9uZQ0KICAgbXVs
dGljYXN0IGZsb3cgaXMgYmVpbmcgcmVjZWl2ZWQgKGxpc3RlbmVyKSAvIHNlbnQgKHNlbmRlciku
IGFuZCBhDQogICBtb2JpbGl0eSB0dW5uZWwgd2lsbCBiZSBjcmVhdGVkIGJldHdlZW4gdGhlIFAt
TUFSIGFuZCB0aGUgTi1NQVIuDQoNCmFuZCBBNDogLi4uIEJ1dCB3aGVuIGEgdXNlciBtb3ZlcyB0
byBhbm90aGVyIE1BUiAoTi1NQVIpLCB1bmRlcg0KICAgYXNzdW1wdGlvbiBBMywgdGhlIHVwc3Ry
ZWFtIGludGVyZmFjZSBvZiBNTEQgUHJveHkgd2lsbCBiZSBjb25maWd1cmVkDQogICB0b3dhcmRz
IHRoZSBhbmNob3IgdGhhdCBlbmFibGVzIHVuaWNhc3QgSVAgYWRkcmVzcyBjb250aW51aXR5IHRv
IGJlDQogICBrZXB0IChQLU1BUiwgYW5hbG9nb3VzIHRvIExNQSBmdW5jdGlvbikuDQoNCklNSE8s
IGlmIHdpdGhvdXQgYSBhc3N1bWVkIHNvbHV0aW9uLCB3aHkgeW91IGFzc3VtZSwgZS5nLiBhIG1v
YmlsaXR5IA0KdHVubmVsIHdpbGwgYmUgY3JlYXRlcyBiZXR3ZWVuIHRoZSBQLU1BUiBhbmQgTi1N
QVI/ICBBbHNvLCB3aGVuIEkgcmVhZCANCnlvdXIgZmlndXJlIDEsMiBhbmQgMywgd2h5IHRoZSB0
cmFmZmljIG11c3QgYmUgZGVsaXZlcmVkIGluIHRoaXMgd2F5PyBBbmQgDQp0aGUgbGltaXRhdGlv
bnMgeW91IGhhdmUgZGlzY3Vzc2VkIGFyZSBiYXNpY2FsbHkgYmFzZWQgb24gc3VjaCBzY2VuYXJp
b3MsIA0Kbm90Pw0KDQpNeSBwb2ludCBpcywgdGhlIG11bHRpY2FzdCByZXF1aXJlbWVudHMgaW4g
RE1NIFJFUSBpbiB0aGlzIHN0YWdlIHNob3VsZCBiZSANCnNvbWUgdGV4dCBsaWtlICJETU0gc29s
dXRpb25zIHNob3VsZCBlbmFibGUgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGljYXN0IA0KdHJh
ZmZpYy4gIi4gU2NlbmFyaW9zIGZvciBtdWx0aWNhc3QgZGlzY3Vzc2VkIGluIHRoaXMgc3RhZ2Ug
aXMgdG9vIGVhcmx5IA0Kc2luY2UgdGhlcmUgYXJlIG5vIGRtbSBzb2x1dGlvbnMgYW5kIGFyY2hp
dGVjdHVyZSwgbWFueSBwZW9wbGUgc2hhcmVzIHRoaXMgDQpvcGluaW9ucyBJIGJlbGlldmUuDQoN
CkJSDQpMdW93ZW4gDQoNCg0KDQoNCiJTZWlsIEplb24iIDxzZWlsamVvbkBhdi5pdC5wdD4gDQoy
MDEyLzExLzIzIDA2OjI3DQoNCuaUtuS7tuS6ug0KPGx1by53ZW5AenRlLmNvbS5jbj4NCuaKhOmA
gQ0KPGRtbUBpZXRmLm9yZz4sICdTw6lyZ2lvIEZpZ3VlaXJlZG8nIDxzZmlndWVpcmVkb0Bhdi5p
dC5wdD4NCuS4u+mimA0KUkU6IFtETU1dIOetlOWkjTogUmU6ICBNdWx0aWNhc3QgUFMgdG8gcmVx
dWlyZW1lbnRzDQoNCg0KDQoNCg0KDQpIaSBMdW8sDQogDQpBZGRpdGlvbmFsbHkgZm9sbG93aW5n
IHRoZSBjb21tZW50IGJ5IFNlcmdpbywNCiANCiANCkZyb206IGRtbS1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANClNlcmdpbyBGaWd1
ZWlyZWRvDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjIsIDIwMTIgOTozNSBBTQ0KVG86IGx1
by53ZW5AenRlLmNvbS5jbg0KQ2M6IGRtbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtETU1dIOet
lOWkjTogUmU6IE11bHRpY2FzdCBQUyB0byByZXF1aXJlbWVudHMNCiANCkhpIEx1bywNCg0KVGhh
bmtzIGZvciB5b3VyIGNvbW1lbnQuIE15IGFuc3dlciBpcyBwbGFjZWQgaW5saW5lOg0KDQpPbiAx
MS8yMi8yMDEyIDA4OjAyIEFNLCBsdW8ud2VuQHp0ZS5jb20uY24gd3JvdGU6DQoNCkhpIFPDqXJn
aW8gDQoNCj4gUFM2OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWMgDQo+IElQIG11bHRpY2Fz
dCBkaXN0cmlidXRpb24gb3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0
aW9ucyANCiBtYXkgbGVhZCB0byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBz
dWJzY3JpcHRpb25zIHRvd2FyZHMgdGhlIA0KdHVubmVs4oCZcyBkb3duc3RyZWFtIGVudGl0eSAo
ZS5nLiBNQUcgaW4gUE1JUHY2KS4gID5Db25jcmV0ZWx5LCB3aGVuIA0KbXVsdGljYXN0IHN1YnNj
cmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoIA0KbW9i
aWxpdHkgdHVubmVscywgZHVwbGljYXRlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJv
bmUgdG8gYmUgDQpyZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbSBwYXRocy4gVGhp
cyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IA0KbW9yZSBzZXZlcmUgaW4gYSBkaXN0cmlidXRlZCBt
b2JpbGl0eSBlbnZpcm9ubWVudCANCltkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2Fz
ZS1kbW0tMDNdLiANCiAgDQo+W0x1aXM+Pl0gVGhpcyBzZWVtcyBub3QgdG8gYmUgYSBwcm9ibGVt
IG9mIHRoZSBJUCBtb2JpbGl0eSBzb2x1dGlvbnMgDQpoYW5kbGluZyBtdWx0aWNhc3QgdHJhZmZp
YyB3aXRoIG1vYmlsaXR5IHR1bm5lbHMgaW4gZ2VuZXJhbCwgYnV0IGEgcHJvYmxlbSANCm9mIGNv
bnNpZGVyaW5nIHNldmVyYWwgdXBzdHJlYW0gcGF0aHMgZW5kaW5nIG9uIHRoZSBzYW1lIG1vYmls
aXR5IGFjY2VzcyANCnJvdXRlciBhcyBhIGNvbnNlcXVlbmNlIG9mIGV4dGVuZGluZyB0dW5uZWxz
IGZyb20gcHJldmlvdXNNQVIgdG8gbmV3TUFSIHRvIA0KZm9yd2FyZCB0aGUgbXVsdGljYXN0IHRy
YWZmaWMuIA0KPiBbU0ZdIEV4YWN0bHkuIFdoaWNoIGlzIG1vcmUgdGhhbiBsaWtlbHkgdG8gaGFw
cGVuIGluIGEgRE1NIHNvbHV0aW9uLCANCndoZXJlIGFsbCAibW9iaWxpdHkgZW50aXRpZXMiIG1h
eSBhY3QgYXMgIm1vYmlsaXR5IGFjY2VzcyByb3V0ZXJzIiwgYW5kLCANCmFmdGVyIG1vYmlsaXR5
LCB3ZSB3YW50IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSB0dW5uZWwgZm9yIHRoZSANCnN1YnNj
cmlwdGlvbi4gSW4gdGhvc2UgY2FzZXMsIGNhcmUgbXVzdCBiZSB0YWtlbiBpbiBvcmRlciB0byBu
b3QgZ3JlYXRseSANCm1hZ25pZnkgY29udmVyZ2VuY2UgcHJvYmxlbSBvYnNlcnZlZCBlLmcuIGlu
IFJGQzYyMjQuIA0KW0x1b3dlbl0gQWNjb3JkaW5nIHRvIHRoZSBhYm92ZSBkaXNjdXNzaW9uLCBJ
IGJlbGlldmUgdGhlIFBTNiAgaXMgYmFzZWQgb24gDQp0aGUgdXNhZ2Ugc2NlbmFyaW9zIGRpc2N1
c3NlZCBpbiANCmRyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wMy4gQnV0
LCBpdCBzZWVtcyB0byBtZSB0aGUgdXNhZ2UgDQpzY2VuYXJpb3MgaW4gdGhpcyBkcmFmdCBpcyBi
YXNlZCBvbiBhIGFzc3VtZWQgZG1tIHVuaWNhc3Qgc29sdXRpb24gYW5kIA0KYXJjaGl0ZWN0dXJl
LiBJTUhPLCB0aGUgUFMgc2hvdWxkIGJlIGJhc2VkIG9uIGN1cnJlbnQgZXhpc3RpbmcgcHJvdG9j
b2wgDQooZS5nLiBSRkMpIG9yIGN1cnJlbnQgZGVwbG95bWVudCwgbm90IGEgYXNzdW1lZCBzb2x1
dGlvbi4NClNGOiBQUzYgaXMgb2JzZXJ2YWJsZSBpcyBib3RoIGV4aXN0aW5nIHByb3RvY29scyAo
ZS5nLiBSRkM2MjI0KSBhbmQgaW4gdGhlIA0KdXNlIGNhc2VzIHdlIGFuYWx5emVkIC0gaW4gYSBQ
TUlQdjYtYmFzZWQgRE1NIHNvbHV0aW9uLiBTbyBJIGFzc3VtZSB0aGUgUFMgDQpmaXRzIGluIHRo
ZSBSRVFzIGRvY3VtZW50LiBBcyBJIHNhaWQgYmVmb3JlLCBpZiBpZ25vcmVkLCB0aGUgdHVubmVs
IA0KY29udmVyZ2VuY2UgcHJvYmxlbSBtaWdodCBiZSBhIG11Y2ggc2VyaW91cyBwcm9ibGVtIHRo
YW4gaW4gUkZDNjIyNC4NCg0KPj4gSW4gdGhlIHVzZSBjYXNlIGRyYWZ0LCB0aGVyZSBhcmUgYW55
IHNvbHV0aW9ucyBub3QgYXNzdW1lZC4gV2UgDQpwcmVzZW50ZWQgdXNlIGNhc2VzLCBoYXZpbmcg
dmFyaW91cyBkZXBsb3ltZW50cyBvZiBleGlzdGluZyBtdWx0aWNhc3QgDQpzdGFuZGFyZCBlbnRp
dGllcywgYW5kIGNvcnJlc3BvbmRpbmcgYW5hbHlzaXMgYmFzZWQgb24gZGlzdHJpYnV0ZWQgDQpk
ZXBsb3ltZW50IHNwZWNpZmllZCBpbiBETU0gUkVRMS4NCk5vIG1vcmUsIG5vIGxlc3MuDQogDQpS
ZWdhcmRzLA0KIA0KU2VpbA0KDQoNCg0KDQoNCg0KU8OpcmdpbyBGaWd1ZWlyZWRvIDxzZmlndWVp
cmVkb0Bhdi5pdC5wdD4gDQrlj5Hku7bkuro6ICBkbW0tYm91bmNlc0BpZXRmLm9yZyANCjIwMTIv
MTEvMjEgMDc6MjEgDQoNCg0K5pS25Lu25Lq6DQpkbW1AaWV0Zi5vcmcgDQrmioTpgIENCg0K5Li7
6aKYDQpSZTogW0RNTV0gTXVsdGljYXN0IFBTIHRvIHJlcXVpcmVtZW50cw0KIA0KDQoNCg0KDQoN
Cg0KDQoNCkhpIEx1aXMsDQoNCkEgZmV3IG1vcmUgY29tbWVudHMgb24gdGhpcyBpbmxpbmU6DQoN
CkVtIDIwLTExLTIwMTIgMTk6NDYsIExVSVMgTUlHVUVMIENPTlRSRVJBUyBNVVJJTExPIGVzY3Jl
dmV1OiANCkhpIEFudGhvbnksIA0KICANCnNvbWUgY29tbWVudHMgaW4gbGluZSANCiAgDQpCZXN0
IHJlZ2FyZHMsIA0KICANCkx1aXMgDQogIA0KRGU6IGRtbS1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIEVuIG5vbWJyZSBkZSBoIGNoYW4NCkVudmlhZG8gZWw6
IG1hcnRlcywgMjAgZGUgbm92aWVtYnJlIGRlIDIwMTIgMTg6NTENClBhcmE6IFPDqXJnaW8gRmln
dWVpcmVkbzsgZG1tQGlldGYub3JnDQpBc3VudG86IFtETU1dIE11bHRpY2FzdCBQUyB0byByZXF1
aXJlbWVudHMgDQogIA0KTGV0IHVzIGFsc28gdXNlIGFub3RoZXIgdGhyZWFkIHRvIGNoZWNrIGZv
ciBjb25zZW5zdXMgb2YgdGhlIFBTIGZyb20gDQptdWx0aW1vYi4gDQogIA0KUFMxIChyZXZpc2Vk
KTogTm9uLW9wdGltYWwgcm91dGVzIA0KUm91dGluZyB2aWEgYSBjZW50cmFsaXplZCBhbmNob3Ig
b2Z0ZW4gcmVzdWx0cyBpbiBhIGxvbmdlciByb3V0ZS4gVGhlIA0KcHJvYmxlbSBpcyBlc3BlY2lh
bGx5IG1hbmlmZXN0ZWQgd2hlbiBhY2Nlc3NpbmcgYSBsb2NhbCBzZXJ2ZXIgb3Igc2VydmVycyAN
Cm9mIGEgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrIChDRE4pLCBvciB3aGVuIHJlY2VpdmluZyAv
IHNlbmRpbmcgSVAgDQptdWx0aWNhc3QgcGFja2V0cy4gDQpbTHVpcz4+XSBUaGlzIGlzIGNvcnJl
Y3QgaWYgdGhlIG11bHRpY2FzdCBjb250ZW50IGlzIGxvY2FsbHkgYXZhaWxhYmxlLiANCkhvd2V2
ZXIgdGhpcyBjb3VsZCBub3QgYmUgYWx3YXlzIHRoZSBjYXNlIGZvciBtdWx0aWNhc3QgbGlzdGVu
ZXJzLCBmb3IgYSANCm51bWJlciBvZiByZWFzb25zIChmb3IgaW5zdGFuY2UsIGNvbmZsaWN0IGlu
IHRoZSBtdWx0aWNhc3QgYWRkcmVzcyANCmFsbG9jYXRpb24gYmV0d2VlbiB0aGUgSG9tZSBOZXR3
b3JrIGFuZCB0aGUgRE1NIGRvbWFpbikuIA0KW1NGXSBTdXJlLCBhbmQgdGhlIHNhbWUgYXBwbGll
cyB0byAiYWNjZXNzaW5nIGEgbG9jYWwgc2VydmVyIGEgQ0ROIiAtIGl0IA0KaXMgaW1wbGljaXQg
dGhhdCB0aGUgY29udGVudCBpcyBsb2NhbGx5IGF2YWlsYWJsZS4gQnV0IGl0IGNhbiBiZSBpbXBy
b3ZlZCANCmFzICJ3aGVuIHJlY2VpdmluZyBsb2NhbGx5IGF2YWlsYWJsZSBJUCBtdWx0aWNhc3Qg
b3Igc2VuZGluZyBJUCANCm11bHRpY2FzdCIuDQoNClBTNjogRHVwbGljYXRlIG11bHRpY2FzdCB0
cmFmZmljIA0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hpdGVjdHVyZXMgdXNp
bmcgSVAgbW9iaWxpdHkgc29sdXRpb25zIA0KbWF5IGxlYWQgdG8gY29udmVyZ2VuY2Ugb2YgZHVw
bGljYXRlZCBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dhcmRzIHRoZSANCnR1bm5lbOKAmXMg
ZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBNSVB2NikuICBDb25jcmV0ZWx5LCB3aGVu
IA0KbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMg
Y291cGxlZCB3aXRoIA0KbW9iaWxpdHkgdHVubmVscywgZHVwbGljYXRlIG11bHRpY2FzdCBzdWJz
Y3JpcHRpb24ocykgaXMgcHJvbmUgdG8gYmUgDQpyZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1
cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IA0KbW9yZSBzZXZlcmUg
aW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudCANCltkcmFmdC1zZmlndWVpcmVk
by1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLiANCiAgDQpbTHVpcz4+XSBUaGlzIHNlZW1zIG5v
dCB0byBiZSBhIHByb2JsZW0gb2YgdGhlIElQIG1vYmlsaXR5IHNvbHV0aW9ucyANCmhhbmRsaW5n
IG11bHRpY2FzdCB0cmFmZmljIHdpdGggbW9iaWxpdHkgdHVubmVscyBpbiBnZW5lcmFsLCBidXQg
YSBwcm9ibGVtIA0Kb2YgY29uc2lkZXJpbmcgc2V2ZXJhbCB1cHN0cmVhbSBwYXRocyBlbmRpbmcg
b24gdGhlIHNhbWUgbW9iaWxpdHkgYWNjZXNzIA0Kcm91dGVyIGFzIGEgY29uc2VxdWVuY2Ugb2Yg
ZXh0ZW5kaW5nIHR1bm5lbHMgZnJvbSBwcmV2aW91c01BUiB0byBuZXdNQVIgdG8gDQpmb3J3YXJk
IHRoZSBtdWx0aWNhc3QgdHJhZmZpYy4gDQpbU0ZdIEV4YWN0bHkuIFdoaWNoIGlzIG1vcmUgdGhh
biBsaWtlbHkgdG8gaGFwcGVuIGluIGEgRE1NIHNvbHV0aW9uLCB3aGVyZSANCmFsbCAibW9iaWxp
dHkgZW50aXRpZXMiIG1heSBhY3QgYXMgIm1vYmlsaXR5IGFjY2VzcyByb3V0ZXJzIiwgYW5kLCBh
ZnRlciANCm1vYmlsaXR5LCB3ZSB3YW50IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSB0dW5uZWwg
Zm9yIHRoZSBzdWJzY3JpcHRpb24uIEluIA0KdGhvc2UgY2FzZXMsIGNhcmUgbXVzdCBiZSB0YWtl
biBpbiBvcmRlciB0byBub3QgZ3JlYXRseSBtYWduaWZ5IA0KY29udmVyZ2VuY2UgcHJvYmxlbSBv
YnNlcnZlZCBlLmcuIGluIFJGQzYyMjQuDQoNClJlZ2FyZHMsDQpTw6lyZ2lvDQoNCiAgDQpIIEFu
dGhvbnkgQ2hhbiANCiAgDQpGcm9tOiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtbS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU8OpDQpyZ2lvIEZpZ3VlaXJlZG8NClNlbnQ6
IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIgNToyNCBQTQ0KVG86IGRtbUBpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMgDQogDQpIaSBBbnRob255LA0K
DQpUaGFuayB5b3UgZm9yIHRyeWluZyB0byBwcm9ncmVzcyBvbiB0aGlzIG1hdHRlci4gSSBtb3N0
bHkgYWdyZWUgd2l0aCB5b3VyIA0KYW5hbHlzaXMuDQoNCkFzIGZvciB0aGUgcXVlc3Rpb24geW91
IHBvc2VkLCBmaXJzdCBJIHdvdWxkIGxpa2UgdG8gZXhhY3RseSB1bmRlcnN0YW5kIA0Kd2hhdCB5
b3UgbWVhbiB3aXRoICJtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvIiBpbiAiRE1NIHNv
bHV0aW9ucyANCnNob3VsZCBlbmFibGUgbXVsdGljYXN0IHNlcnZpY2VzIHdoaWNoIGFyZSBjb21w
YXRpYmxlIHdpdGggbXVsdGljYXN0IA0KZGlzdHJpYnV0aW9uIHNjZW5hcmlvLCBldGMuIi4gSXQg
c2VlbXMgbGlrZSB0aGVyZSBpcyBubyBtYWpvciBkaWZmZXJlbmNlIA0KYmV0d2VlbiB0aGlzIGFu
ZCB0aGUgIkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBzb2x1dGlvbnMgdG8gc3VwcG9ydCAN
Cm11bHRpY2FzdCBzZXJ2aWNlcy4iIHJlcXVpcmVtZW50PyBBcmVuJ3QgYm90aCBleHByZXNzaW5n
IHRoZSBuZWVkIHRvIA0KZW5hYmxlIG11bHRpY2FzdCBpbiBhIERNTSBzb2x1dGlvbj8NCg0KQXMg
eW91IHN0YXRlZCwgIm5lZ2xlY3RpbmciIHRoZSByZXF1aXJlbWVudCA3LjEgd2UgcHJvcG9zZWQs
IGxlYWRzIHRvIHRoZSANClBTcyB5b3UgcmVmZXJyZWQuICBTbywgd2hpbGUgNy4yIGFuZCA3LjMg
ZXhwcmVzcyB0aGUgbmVlZCBmb3IgRE1NIA0Kc29sdXRpb25zIHRvIGFsbG93IGRlcGxveW1lbnQg
b2YgbXVsdGljYXN0IHNlcnZpY2VzLCA3LjEgY29uY2VybnMgICJob3ciIA0KSVAgbXVsdGljYXN0
IHNob3VsZCBiZSBlbmFibGVkIGluIG9yZGVyIHRvIGF2b2lkIHRoZSBhZm9yZW1lbnRpb25lZCBQ
U3MuIA0KVGhlIHVzYWdlIG9mIHRoZSB3b3JkICJmbGV4aWJsZSJpcyBleHBsYWluZWQgYnk6IA0K
DQoiVGhpcyBmbGV4aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUCBtdWx0aWNhc3QgZmxvd3Mg
d2l0aCByZXNwZWN0IHRvIGEgDQptb2JpbGUgaG9zdCB0byBiZSBtYW5hZ2VkIChlLmcuLCBzdWJz
Y3JpYmVkLCByZWNlaXZlZCBhbmQvb3IgdHJhbnNtaXR0ZWQpIA0KdXNpbmcgbXVsdGlwbGUgZW5k
cG9pbnRzIi4gDQoNCkluIG90aGVyIHdvcmRzLCBjb21wYXRpYmlsaXR5IHdpdGggIm11bHRpY2Fz
dCBkaXN0cmlidXRpb24gc2NlbmFyaW8iIA0KZG9lc24ndCBuZWNlc3NhcmlseSBhdm9pZCBQUzEg
YW5kIFBTNi4NCg0KVGhhbmsgeW91IGFuZCBiZXN0IHJlZ2FyZHMsDQpTw6lyZ2lvDQoNCk9uIDEx
LzE5LzIwMTIgMTA6MjggUE0sIGggY2hhbiB3cm90ZTogDQpUaGVyZSBhcmUgMyBwcm9wb3NhbHMg
Zm9yIG11bHRpY2FzdCByZXF1aXJlbWVudHMuIEJlZm9yZSBjb21wYXJpbmcgdGhlc2UgDQpwcm9w
b3NhbHMsIGxldCB1cyB1bmRlcnN0YW5kIHdoYXQgYXJlIHRoZSBwcm9ibGVtcyBmaXJzdC4gVHdv
IHByb2JsZW0gDQpzdGF0ZW1lbnRzIGhhdmUgYmVlbiBwcm9wb3NlZDogDQogIA0KUFMxIChyZXZp
c2VkKTogTm9uLW9wdGltYWwgcm91dGVzIA0KUm91dGluZyB2aWEgYSBjZW50cmFsaXplZCBhbmNo
b3Igb2Z0ZW4gcmVzdWx0cyBpbiBhIGxvbmdlciByb3V0ZS4gVGhlIA0KcHJvYmxlbSBpcyBlc3Bl
Y2lhbGx5IG1hbmlmZXN0ZWQgd2hlbiBhY2Nlc3NpbmcgYSBsb2NhbCBzZXJ2ZXIgb3Igc2VydmVy
cyANCm9mIGEgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrIChDRE4pLCBvciB3aGVuIHJlY2Vpdmlu
ZyAvIHNlbmRpbmcgSVAgDQptdWx0aWNhc3QgcGFja2V0cy4gDQpQUzY6IER1cGxpY2F0ZSBtdWx0
aWNhc3QgdHJhZmZpYyANCklQIG11bHRpY2FzdCBkaXN0cmlidXRpb24gb3ZlciBhcmNoaXRlY3R1
cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyANCm1heSBsZWFkIHRvIGNvbnZlcmdlbmNl
IG9mIGR1cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlwdGlvbnMgdG93YXJkcyB0aGUgDQp0dW5u
ZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBpbiBQTUlQdjYpLiAgQ29uY3JldGVs
eSwgd2hlbiANCm11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGluZGl2aWR1YWwgbW9iaWxlIG5v
ZGVzIGlzIGNvdXBsZWQgd2l0aCANCm1vYmlsaXR5IHR1bm5lbHMsIGR1cGxpY2F0ZSBtdWx0aWNh
c3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJlIA0KcmVjZWl2ZWQgdGhyb3VnaCBkaWZm
ZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJvYmxlbSBpcyBwb3RlbnRpYWxseSANCm1vcmUg
c2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgZW52aXJvbm1lbnQgDQpbZHJhZnQtc2Zp
Z3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzXS4gDQogIA0KVGhlbiwgbGV0IHVzIHNl
ZSB3aGV0aGVyIGFsbCB0aGUgMyBSRVEgcHJvcG9zYWxzIGhhdmUgdGhlIHNhbWUgaW50ZW50aW9u
LiANCkluIHRoZSBmb2xsb3dpbmcsIEkgcmVwaHJhc2UgdGhlbSB0byBoaWdobGlnaHQgdGhlaXIg
c2ltaWxhcml0aWVzLiANCiAgDQpSRVE3LjE6IEZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRp
b24gDQpETU0gc29sdXRpb25zIHNob3VsZCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUgbXVs
dGljYXN0IGRpc3RyaWJ1dGlvbiANCnNjZW5hcmlvLiBFdGMuIA0KVGhlIE1vdGl2YXRpb24gaXMg
dG8gYWxsb3cgZmxleGliaWxpdHkgaW4gKGVuYWJsZSkgbXVsdGljYXN0IHNvbHV0aW9ucyB0byAN
CnNvbHZlIHRoZSBwcm9ibGVtcyBQUzEgYW5kIFBTNiBhcyBleHBsYWluZWQgaW4gdXNlIGNhc2Vz
IGFscmVhZHkgcHJlc2VudGVkIA0KYW5kIGRpc2N1c3NlZCBpbiBtdWx0aW1vYiB3Zy4gDQogIA0K
UkVRNy4yOiANCkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBzb2x1dGlvbnMgdG8gc3VwcG9y
dCBtdWx0aWNhc3QgdHJhZmZpYy4gDQogIA0KKE9yaWdpbmFsIHdvcmRpbmcgd2FzICJUaGUgRE1N
ICh1bmljYXN0KSBzb2x1dGlvbiBNVVNUIGJlIHNwZWNpZmllZCBpbiANCnN1Y2ggYSB3YXkgdGhh
dCBpdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWxzbyBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiIg
SSANCnJlcGhyYXNlIGl0IHRvIGhpZ2hsaWdodCB0aGUgc2ltaWxhcml0eSB3aXRoIHRoZSBvdGhl
ciBwcm9wb3NhbHMgYW5kIGFsc28gDQpjaGFuZ2VkIHRoZSBtdXN0IHRvIHNob3VsZC4pIA0KICAN
ClJFUTcuMzogDQpETU0gc29sdXRpb25zIHNob3VsZCBlbmFibGUgc29sdXRpb25zIHRvIHN1cHBv
cnQgbXVsdGljYXN0IHNlcnZpY2VzLiANCiAgDQpPcmlnaW5hbCB3b3JkaW5nIHdhcyDigJxETU0g
c29sdXRpb25zIHNob3VsZCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcyDigKYgDQpldGMuIEdp
dmVuIHRoYXQgaXQgaXMgdGhlIHNjb3BlIG9mIG11bHRpbW9iIGFuZCBub3QgZG1tIHdnIHRvIHBy
b3ZpZGUgdGhlIA0KbXVsdGljYXN0IHNvbHV0aW9uLCBJIHRoaW5rIOKAnHN1cHBvcnTigJ0gaGVy
ZSBtZWFucyDigJxlbmFibGXigJ0gc29sdXRpb25zIHRvIA0KYmUgZGV2ZWxvcGVkIChieSBtdWx0
aW1vYikuIA0KICANClNpbWlsYXJpdHkgYW5kIHN1YnRsZSBkaWZmZXJlbmNlczogQm90aCBSRVE3
LjIgYW5kIFJFUTcuMyB3YW50IHRvIGVuYWJsZSANCm11bHRpY2FzdCBzZXJ2aWNlcy4gWWV0IHRo
ZSBleHBsYW5hdGlvbiBpbiBSRVE3LjEgc2VlbXMgdG8gaW5kaWNhdGUgbm90IA0KanVzdCB0byBl
bmFibGUgYW55IG9uZSBtdWx0aWNhc3Qgc29sdXRpb24gYnV0IGFsc28gbmVlZHMgdGhlIGZsZXhp
YmlsaXR5IA0KaW4gbXVsdGljYXN0IHNvbHV0aW9uLiBOb3QgYWxsIG11bHRpY2FzdCBzb2x1dGlv
bnMgYXJlIHRoZSBzYW1lLiBTb21lIG9mIA0KdGhlbSByZXN1bHRzIGluIFBTMSBvciBQUzYuIA0K
ICANCkFyZSB0aGVyZSBhbnkgYXJlIGVzc2VudGlhbCBkaWZmZXJlbmNlcyBiZXR3ZWVuOiANCklu
IFJFUTcuMSwgRE1NIHNvbHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxl
IG11bHRpY2FzdCANCmRpc3RyaWJ1dGlvbiBzY2VuYXJpbywgZXRjLiANClZlcnN1cyANCkRNTSBz
b2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJlIGNvbXBh
dGlibGUgd2l0aCANCm11bHRpY2FzdCBkaXN0cmlidXRpb24gc2NlbmFyaW8sIGV0Yy4gDQogIA0K
SCBBbnRob255IENoYW4gDQogIA0KRnJvbTogZG1tLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpk
bW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNlaWwgDQpKZW9uDQpTZW50OiBNb25k
YXksIE5vdmVtYmVyIDE5LCAyMDEyIDU6MTUgQU0NClRvOiBwaWVycmljay5zZWl0ZUBvcmFuZ2Uu
Y29tDQpDYzogZG1tQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVp
cmVtZW50cyANCiAgDQpIaSBQaWVycmljaywgDQogIA0KSeKAmXZlIG1hbnkgdGltZXMgdGhvdWdo
dCBhYm91dCB5b3VyIHF1ZXN0aW9uLiBJIHdvdWxkIHNheSBob3cgZWZmZWN0aXZlbHkgDQpzaG91
bGQgd2UgZGVwbG95L3N1cHBvcnQgbXVsdGljYXN0IG92ZXIgZGlzdHJpYnV0ZWQgbW9iaWxpdHkg
cmF0aGVyIHRoYW4gDQpkaXN0cmlidXRlZCBtb2JpbGUgbXVsdGljYXN0LiBBcyBhIHJlc3VsdCwg
eW91IGNhbiBmaW5kIHRoaXMgZGVwbG95bWVudCANCnVzZSBjYXNlIGFuZCBnYXAgYW5hbHlzaXMg
YXQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZmlndWVpcmVkby1tdWx0aW1v
Yi11c2UtY2FzZS1kbW0tMDMgDQpwcmVzZW50ZWQgaW4gbXVsdGltb2Igc2V2ZXJhbCB0aW1lcy4g
DQogIA0KSW4gdW5pY2FzdCBETU0sIG1haW4gaW5ub3ZhdGlvbiBpcyB0byBkaXN0cmlidXRlIHRo
ZSBhbmNob3IgZnVuY3Rpb24gYXQgDQptYW55IGFjY2VzcyByb3V0ZXJzIGZyb20gc2luZ2xlIGNv
cmUuIEZvbGxvd2luZyBhcmNoaXRlY3R1cmFsIGNvbmNlcHQgb2YgDQpETU0sIGZsZXhpYmxlIG11
bHRpY2FzdCBkaXN0cmlidXRpb24gaXMgb25lIG9mIG11bHRpY2FzdCByZXF1aXJlbWVudCANCnJl
c3VsdGVkIGZyb20gdGhlIGRyYWZ0IGRlc2NyaWJlZCBhYm92ZS4gDQogIA0KUkVRODogRmxleGli
bGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiANCiJETU0gc29sdXRpb25zIFNIT1VMRCBiZSBjb21w
YXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiANCnNjZW5hcmlvcy4g
VGhpcyBmbGV4aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUCBtdWx0aWNhc3QgZmxvd3Mgd2l0
aCANCnJlc3BlY3QgdG8gYSBtb2JpbGUgaG9zdCB0byBiZSBtYW5hZ2VkIChlLmcuLCBzdWJzY3Jp
YmVkLCByZWNlaXZlZCBhbmQvb3IgDQp0cmFuc21pdHRlZCkgdXNpbmcgbXVsdGlwbGUgZW5kcG9p
bnRzIi4gDQoNCk1vdGl2YXRpb246IFRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHJlcXVpcmVtZW50
IGlzIHRvIGVuYWJsZSBmbGV4aWJpbGl0eSANCmluIG11bHRpY2FzdCBkaXN0cmlidXRpb24uIFRo
ZSBtdWx0aWNhc3Qgc29sdXRpb24gbWF5IHRoZXJlZm9yZSBhdm9pZCANCmhhdmluZyBtdWx0aWNh
c3QtY2FwYWJsZSBhY2Nlc3Mgcm91dGVycyBiZWluZyByZXN0cmljdGVkIHRvIG1hbmFnZSBhbGwg
SVAgDQptdWx0aWNhc3QgdHJhZmZpYyByZWxhdGl2ZSB0byBhIGhvc3QgdmlhIGEgc2luZ2xlIGVu
ZHBvaW50IChlLmcuIHJlZ3VsYXIgDQpvciB0dW5uZWwgaW50ZXJmYWNlKSwgd2hpY2ggd291bGQg
bGVhZCB0byB0aGUgcHJvYmxlbXMgZGVzY3JpYmVkIGluIFBTMSANCmFuZCBQUzYuIA0KUFM2OiBE
dXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWMgDQpJUCBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIG92
ZXIgYXJjaGl0ZWN0dXJlcyB1c2luZyBJUCBtb2JpbGl0eSBzb2x1dGlvbnMgDQptYXkgbGVhZCB0
byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25zIHRvd2Fy
ZHMgdGhlIA0KdHVubmVs4oCZcyBkb3duc3RyZWFtIGVudGl0eSAoZS5nLiBNQUcgaW4gUE1JUHY2
KS4gIENvbmNyZXRlbHksIHdoZW4gDQptdWx0aWNhc3Qgc3Vic2NyaXB0aW9uIGZvciBpbmRpdmlk
dWFsIG1vYmlsZSBub2RlcyBpcyBjb3VwbGVkIHdpdGggDQptb2JpbGl0eSB0dW5uZWxzLCBkdXBs
aWNhdGUgbXVsdGljYXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSANCnJlY2VpdmVk
IHRocm91Z2ggZGlmZmVyZW50IHVwc3RyZWFtIHBhdGhzLiBUaGlzIHByb2JsZW0gaXMgcG90ZW50
aWFsbHkgDQptb3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IGVudmlyb25tZW50
IA0KW2RyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wM10uDQoNCg0KDQpS
ZWdhcmRzLCANCiAgDQpTZWlsIA0KICANCkZyb206IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20g
W21haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tXSANClNlbnQ6IE1vbmRheSwgTm92ZW1i
ZXIgMTksIDIwMTIgODo1NSBBTQ0KVG86ICdrYXJhZ2lhbkBjcy51dHdlbnRlLm5sJzsgc2VpbGpl
b25AYXYuaXQucHQ7IA0KSnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbQ0KQ2M6IGRt
bUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMgDQog
IA0KSGkgYWxsLCANCiAgDQpJIHRlbmQgdG8gYWdyZWUgd2l0aCBHZW9yZ2lvdXMsIGhvd2V2ZXIg
SSBzdGlsbCBkbyBub3QgZmlndXJlIG91dCB3aGF0IGlzIA0KdGhlIHVzZS1jYXNlIGZvciBkaXN0
cmlidXRlZCBtb2JpbGUgbXVsdGljYXN0IChvdGhlciB0aGFuIGFjYWRlbWljIA0KY29uc2lkZXJh
dGlvbnMpPyBDYW4gc29tZW9uZSBnaXZlIGNvbmNyZXRlIGV4YW1wbGU/IA0KICANCkkgaGF2ZW7i
gJl0IHJlYWwgYWxsIG1lc3NhZ2VzIGZyb20gdGhpcyB0aHJlYWQuIFNvLCBtYXliZSBJIG1pc3Nl
ZCANCmltcG9ydGFudCBwb2ludHMuIA0KICANCkJSLCANClBpZXJyaWNrIA0KICANCkRlIDogZG1t
LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy
dCBkZSANCmthcmFnaWFuQGNzLnV0d2VudGUubmwNCkVudm95w6kgOiBzYW1lZGkgMTcgbm92ZW1i
cmUgMjAxMiAxMzowMQ0Kw4AgOiBzZWlsamVvbkBhdi5pdC5wdDsgSnVhbkNhcmxvcy5adW5pZ2FA
SW50ZXJEaWdpdGFsLmNvbQ0KQ2MgOiBkbW1AaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtETU1dIE11
bHRpY2FzdCByZXF1aXJlbWVudHMgDQogIA0KSGkgYWxsLCANCiAgDQpJIGFsc28gYWdyZWUgdGhh
dCB0aGUgRE1NIHNvbHV0aW9uIHNob3VsZCBzb21laG93IGNvbnNpZGVyIG11dGljYXN0IA0KZGVw
bG95bWVudC4gSG93ZXZlciwgSSBkbyBub3QgdGhuayB0aGF0IHRoZSBETU0gV0cgaXMgdGhlIHJp
Z2h0IFdHIHRvIA0KcHJvdmlkZSB0aGUgbXVsdGljYXN0IGJhc2VkIERNTSBzb2x1dGlvbiEgDQog
IA0KT25lIGFsdGVybmF0aXZlIHNvbHV0aW9uIHdpbGwgYmUgdG8gaGF2ZSBhIG11bHRpY2FzdCBy
ZXF1aXJlbWVudCB0aGF0IA0KZW1waGFzaXplcyB0aGUgbmVlZCBvZiBoYXZpbmcgZXh0ZW5zaWJp
bGl0eSBob29rcyAocG9zc2liaWxpdGllcykgdGhhdCBjYW4gDQpiZSB1c2VkIGxhdGVyIG9uIGJ5
IHRoZSBtdWx0aW1vYiBXRyB0byBwcm92aWRlIGEgDQphIG11bHRpY2FzdCBlbmFibGVkIERNTSBz
b2x1dGlvbiEgDQogIA0KICANClNvIGEgcmVxdWlyZW1lbnQgdGhhdCBzcGVjaWZpZXMgc29tZXRo
aW5nIGxpa2UgdGhlIGZvbGxvd2luZyBjb3VsZCBiZSB1c2VkIA0KZm9yIHRoaXMgcHVycG9zZTog
DQogIA0KIlRoZSBETU0gKHVuaWNhc3QpIHNvbHV0aW9uIE1VU1QgYmUgc3BlY2lmaWVkIGluIHN1
Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgDQpleHRlbmRlZCB0byBhbHNvIHN1cHBvcnQgbXVsdGlj
YXN0IHRyYWZmaWMuIiANCiAgDQogIA0KQmVzdCByZWdhcmRzLCANCkdlb3JnaW9zIA0KICANCiAg
DQogIA0KIA0KDQoNClZhbjogZG1tLWJvdW5jZXNAaWV0Zi5vcmcgW2RtbS1ib3VuY2VzQGlldGYu
b3JnXSBuYW1lbnMgU2VpbCBKZW9uIFsNCnNlaWxqZW9uQGF2Lml0LnB0XQ0KVmVyem9uZGVuOiB2
cmlqZGFnIDE2IG5vdmVtYmVyIDIwMTIgMjI6MjUNClRvOiAnWnVuaWdhLCBKdWFuIENhcmxvcycN
CkNjOiBkbW1AaWV0Zi5vcmcNCk9uZGVyd2VycDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJl
bWVudHMgDQpIaSBKdWFuLA0KDQpJJ3ZlIGJlZW4gbG9va2VkIGF0IGNoYW5nZWQgZmxvdyBvZiB5
b3VyIHByb3Bvc2VkIHRleHQgYnV0IHNvcnJ5IG5vdyB0aGF0IA0KbXkNCmNvbW1lbnQgaXMgcG9z
dGVkLg0KQXQgZmlyc3QgdGltZSwgSSBjb3VsZG4ndCBtYWtlIHN1cmUgaG93ZXZlciwgb24gaGVh
cmluZyBTdGlnJ3MgDQpkZXNjcmlwdGlvbiwNCml0IHNlZW1zIHF1aXRlIHJlYXNvbmFibGUgYXQg
dGhlIGZpcnN0IHN0ZXAsIG5vdCBnaXZpbmcgYW55IHJlc3RyaWN0aW9ucyANCmJ1dA0KbGVhdmlu
ZyBzb21lLXNwZWNpZmljIGZvciB0aGUgRE1NIHNvbHV0aW9uIGl0IGRvZXMgbm90IHN1cHBvcnQg
bXVsdGljYXN0Lg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgaXQgcmVtYWlucyBhdCBhIGJhc2ljIHN0
YWdlIGZvciB0aGUgRE1NIHNvbHV0aW9uIHRvDQpzdXBwb3J0IG11bHRpY2FzdC4NClNvIEkgdGhp
bmsgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgbmVlZCB0byBiZSBtYWRlIGZvciB0aGUgRE1NIHNv
bHV0aW9uLA0KYWNjb3JkaW5nbHkuIEJ1dCBvZiBjb3Vyc2UsIHRoaXMgc2hvdWxkIG5vdCBhbHNv
IGdpdmUgYW55IHNwZWNpZmljDQpsaW1pdGF0aW9uIGFuZCByZXN0cmljdGlvbiBidXQgc2hvdWxk
IGJlIG1hZGUgdG93YXJkcyB0aGUgZGlyZWN0aW9uIG5vdA0KbGltaXRpbmcgdGhlIGJlbmVmaXRz
IHByb3ZpZGVkIGJ5IGRpc3RyaWJ1dGVkIGRlcGxveW1lbnQuDQoNCkkgaG9wZSB0byBnZXQgbW9y
ZSBjb21tZW50cyBvbiB0aGlzLg0KDQpSZWdhcmRzLA0KDQpTZWlsDQoNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IGRtbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZG1tLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KWnVuaWdhLCBKdWFuIENhcmxvcw0KU2VudDog
RnJpZGF5LCBOb3ZlbWJlciAxNiwgMjAxMiA4OjE0IFBNDQpUbzogU3RpZyBWZW5hYXM7IGRtbUBp
ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMNCg0KDQo+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0aWcgVmVuYWFzIFttYWlsdG86
c3RpZ0B2ZW5hYXMuY29tXQ0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDM6MDEg
UE0NCj4gVG86IGpvdW5pIGtvcmhvbmVuDQo+IENjOiBzYXJpa2F5YUBpZWVlLm9yZzsgWnVuaWdh
LCBKdWFuIENhcmxvczsgS29uc3RhbnRpbm9zIFBlbnRpa291c2lzOyANCj4gUGV0ZXIgTWNDYW5u
OyBkbW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVu
dHMNCj4gDQo+IE9uIDExLzE1LzIwMTIgMzoxNyBBTSwgam91bmkga29yaG9uZW4gd3JvdGU6DQo+
ID4NCj4gPiBPbiBOb3YgMTUsIDIwMTIsIGF0IDE6MDMgQU0sIEJlaGNldCBTYXJpa2F5YSB3cm90
ZToNCj4gPg0KPiA+Pg0KPiA+PiBJIHRoaW5rIHdlIGFyZSByZWFkaW5nIHRvbyBtdWNoIGludG8g
bXVsdGljYXN0IGFuZCB1bmljYXN0IHNob3VsZA0KYmUNCj4gPj4gZGVzaWduZWQgaW4gYW4gaW50
ZWdyYXRlZCBtYW5uZXIuDQo+ID4+DQo+ID4+IFRoZSBmYWN0IGlzIHRoYXQgbXVsdGljYXN0IGlz
IGNvbnNpZGVyZWQgYXMgYW4gYXJlYSBvZg0KPiBzcGVjaWFsaXphdGlvbiwNCj4gPj4gaXQgcmVx
dWlyZXMga25vd2xlZGdlIG9mIHZlcnkgZGlmZmVyZW50IHByb3RvY29scyB0aGFuIHdlIGFyZSAN
Cj4gPj4gYWNjdXN0b21lZCB0byBpbiBtb2JpbGl0eS4NCj4gPg0KPiA+ICJSZXF1aXJlbWVudDog
RE1NIHNvbHV0aW9ucyBTSE9VTEQgc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMuIElmIGENCj4g
c3BlY2lmaWMgRE1NIHNvbHV0aW9uIGRvZXMgbm90IHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2Vz
LCBhbiANCj4gZXhwbGFuYXRpb24gTVVTVCBiZSBwcm92aWRlZC4iDQo+IA0KPiBUaGlzIHNvdW5k
cyBnb29kIHRvIG1lLg0KPiANCj4gVGhlIG1haW4gdGhpbmcgSSB3YW50IHRvIGFjaGlldmUgaXMg
d2hhdCB3YXMgZGVzY3JpYmVzIGFzIG1vdGl2YXRpb24gDQo+IGVhcmxpZXIgaW4gdGhpcyB0aHJl
YWQuIE11bHRpY2FzdCBzaG91bGQgYXQgbGVhc3QgYmUgY29uc2lkZXJlZCB3aGVuIA0KPiBsb29r
aW5nIGludG8gRE1NIHNvbHV0aW9ucywgYW5kIG5vdCBqdXN0IGFuIGFmdGVydGhvdWdodCBvbmNl
IHRoZSANCj4gc29sdXRpb24gaXMgZGVjaWRlZC4NCj4gDQo+IFN0aWcNCg0KW0pDWl0gSSBmdWxs
eSBhZ3JlZSB3aXRoIHRoaXMuIFRoYXQgd2FzIHRoZSBpbnRlbnRpb24gb2YgdGhlIHByb3Bvc2Vk
IA0KdGV4dC4NCg0KUmVnYXJkcywNCg0KSnVhbiBDYXJsb3MNCg0KPiANCj4gPiBUbyBtZSB0aGF0
IHJlYWRzIGJhc2ljYWxseSAiZG8gbm90IGJyZWFrIGZvdW5kYXRpb25zIGZvciBtdWx0aWNhc3QN
Cj4gdW5sZXNzIHlvdSBoYXZlIGEgdmFsaWQgJiBkb2N1bWVudGVkIHJlYXNvbiBmb3IgaXQiLiAg
SWYgd2UgbG9vayBlLmcuDQo+IGludG8gUkZDNjI1IG11bHRpY2FzdCB3b3JkaW5nIHRoYXQgaXMg
dGhlcmUgdmVyeSBicmllZmx5IGJ1dCBnaXZlcyBhIA0KPiBoaW50IHRvIGEgZGV2ZWxvcGVyIHdo
ZXJlIHRvIGhlYWQgdG8uIFRoYXQgaXMgdGhlIGxldmVsIEkgd291bGQgZXhwZWN0IA0KPiBETU0g
ZG9jdW1lbnRzIHNob3VsZCBhaW0gdG8uDQo+ID4NCj4gPiAtIEpvdW5pDQo+ID4NCj4gPg0KPiA+
PiBMZXQgZG1tIGRlYWwgd2l0aCBpdHMgY3VycmVudCBjaGFydGVyIHRoYXQgZG9lcyBub3QgaW5j
bHVkZSBhIHdvcmQNCj4gb2YNCj4gPj4gbXVsdGljYXN0IGFuZCBpZiBldmVyeXRoaW5nIGdvZXMg
d2VsbCB3ZSBjYW4gY29tZSBiYWNrIGFuZCBkaXNjdXNzDQo+IGRtbQ0KPiA+PiBtdWx0aWNhc3Qu
DQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+DQo+ID4+IEJlaGNldA0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1t
QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxp
bmcgbGlzdA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RtbSANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18gDQoNCiAgDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl
cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQpjb25maWRlbnRpZWxsZXMgb3Ug
cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyANCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs
b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogDQpyZWN1IGNl
IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgDQphIGwnZXhwZWRpdGV1
ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn
ZXMgDQplbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIA0KRnJh
bmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt
ZXNzYWdlIGEgZXRlIA0KYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4gDQogIA0K
VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs
IG9yIHByaXZpbGVnZWQgDQppbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3
OyANCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy
b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgDQpkZWxldGUgdGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMuIA0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVs
ZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciANCm1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu
IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4gDQpUaGFuayB5b3UuIA0KDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCmRtbSBtYWls
aW5nIGxpc3QgDQpkbW1AaWV0Zi5vcmcgDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2RtbSANCiANCiANCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1l
bnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgDQpudWVzdHJhIHBvbMOtdGlj
YSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgDQpl
bmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1
c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIA0KcmVjZWl2ZSBlbWFp
bCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5l
cy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpk
bW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQog
DQoNCg==
--=_alternative 0010C19B48257AC2_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IuW+rui9r+mbhem7kSI+SGkgU2VpbCAmYW1wOyBTw6ly
Z2lvOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhh
bmsgeW91IGZvciB5b3VyIHJlcGx5LCBBbmQgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSLlvq7o
va/pm4Xpu5EiPndpdGgNCmFsbCByZXNwZWN0LCBJIGRvbid0IGtub3cgd2hlcmUgYXJlIHlvdSBj
b21pbmcgZnJvbSB3aGVuIHlvdSBzYXkgdGhlcmUNCmFyZSBhbnkgc29sdXRpb25zIG5vdCBhc3N1
bWVkPyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IuW+rui9r+mbhem7kSI+
V2hlbiBJIHJlYWQgeW91ciBkcmFmdCwgeW91IGhhdmUgYXNzdW1wdGlvbg0KQTMgOiA8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IuW+rui9r+mbhem7kSI+SXQgaXMgYXNzdW1lZCB0aGF0
IHdoZW4gdGhlIElQIG1vYmlsaXR5DQpoYXBwZW5zLCBhdCBsZWFzdCBvbmU8YnI+DQogJm5ic3A7
IG11bHRpY2FzdCBmbG93IGlzIGJlaW5nIHJlY2VpdmVkIChsaXN0ZW5lcikgLyBzZW50IChzZW5k
ZXIpLiBhbmQNCmE8YnI+DQogJm5ic3A7IG1vYmlsaXR5IHR1bm5lbCB3aWxsIGJlIGNyZWF0ZWQg
YmV0d2VlbiB0aGUgUC1NQVIgYW5kIHRoZSBOLU1BUi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9IuW+rui9r+mbhem7kSI+YW5kIEE0OiAuLi4gQnV0IHdoZW4gYSB1c2VyIG1v
dmVzDQp0byBhbm90aGVyIE1BUiAoTi1NQVIpLCB1bmRlcjxicj4NCiAmbmJzcDsgYXNzdW1wdGlv
biBBMywgdGhlIHVwc3RyZWFtIGludGVyZmFjZSBvZiBNTEQgUHJveHkgd2lsbCBiZSBjb25maWd1
cmVkPGJyPg0KICZuYnNwOyB0b3dhcmRzIHRoZSBhbmNob3IgdGhhdCBlbmFibGVzIHVuaWNhc3Qg
SVAgYWRkcmVzcyBjb250aW51aXR5IHRvDQpiZTxicj4NCiAmbmJzcDsga2VwdCAoUC1NQVIsIGFu
YWxvZ291cyB0byBMTUEgZnVuY3Rpb24pLjxicj4NCjxicj4NCklNSE8sIGlmIHdpdGhvdXQgYSBh
c3N1bWVkIHNvbHV0aW9uLCB3aHkgeW91IGFzc3VtZSwgZS5nLiBhIG1vYmlsaXR5IHR1bm5lbA0K
d2lsbCBiZSBjcmVhdGVzIGJldHdlZW4gdGhlIFAtTUFSIGFuZCBOLU1BUj8gJm5ic3A7QWxzbywg
d2hlbiBJIHJlYWQgeW91cg0KZmlndXJlIDEsMiBhbmQgMywgd2h5IHRoZSB0cmFmZmljIG11c3Qg
YmUgZGVsaXZlcmVkIGluIHRoaXMgd2F5PyBBbmQgdGhlDQpsaW1pdGF0aW9ucyB5b3UgaGF2ZSBk
aXNjdXNzZWQgYXJlIGJhc2ljYWxseSBiYXNlZCBvbiBzdWNoIHNjZW5hcmlvcywgbm90PzwvZm9u
dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i5b6u6L2v6ZuF6buRIj5NeSBwb2ludCBp
cywgdGhlIG11bHRpY2FzdCByZXF1aXJlbWVudHMNCmluIERNTSBSRVEgaW4gdGhpcyBzdGFnZSBz
aG91bGQgYmUgc29tZSB0ZXh0IGxpa2UgJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j
MWY0OTdkIGZhY2U9IkNhbGlicmkiPkRNTQ0Kc29sdXRpb25zIHNob3VsZCBlbmFibGUgc29sdXRp
b25zIHRvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuIDwvZm9udD48Zm9udCBzaXplPTIgZmFj
ZT0i5b6u6L2v6ZuF6buRIj4mcXVvdDsuDQpTY2VuYXJpb3MgZm9yIG11bHRpY2FzdCBkaXNjdXNz
ZWQgaW4gdGhpcyBzdGFnZSBpcyB0b28gZWFybHkgc2luY2UgdGhlcmUNCmFyZSBubyBkbW0gc29s
dXRpb25zIGFuZCBhcmNoaXRlY3R1cmUsIG1hbnkgcGVvcGxlIHNoYXJlcyB0aGlzIG9waW5pb25z
DQpJIGJlbGlldmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSLlvq7ova/p
m4Xpu5EiPkJSPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSLlvq7ova/pm4Xpu5EiPkx1
b3dlbiA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N
Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z
ZXJpZiI+PGI+JnF1b3Q7U2VpbCBKZW9uJnF1b3Q7ICZsdDtzZWlsamVvbkBhdi5pdC5wdCZndDs8
L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi8xMS8y
MyAwNjoyNzwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2
YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+5pS25Lu25Lq6PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj4mbHQ7bHVvLndlbkB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249
dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp
ZiI+5oqE6YCBPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm
Ij4mbHQ7ZG1tQGlldGYub3JnJmd0OywgJ1PDqXJnaW8gRmlndWVpcmVkbycNCiZsdDtzZmlndWVp
cmVkb0Bhdi5pdC5wdCZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp
Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rp
dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtETU1dIOetlOWkjTog
UmU6ICZuYnNwO011bHRpY2FzdA0KUFMgdG8gcmVxdWlyZW1lbnRzPC9mb250PjwvdGFibGU+DQo8
YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv
dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IaSBMdW8s
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+QWRkaXRpb25hbGx5IGZvbGxvd2luZyB0aGUgY29t
bWVudCBieSBTZXJnaW8sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5i
c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBkbW0tYm91bmNlc0Bp
ZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5TZXJnaW8gRmlndWVpcmVkbzxiPjxicj4NClNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIg
MjIsIDIwMTIgOTozNSBBTTxiPjxicj4NClRvOjwvYj4gbHVvLndlbkB6dGUuY29tLmNuPGI+PGJy
Pg0KQ2M6PC9iPiBkbW1AaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtETU1dIDwv
Zm9udD48Zm9udCBzaXplPTI+562U5aSNPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi
PjoNClJlOiBNdWx0aWNhc3QgUFMgdG8gcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5IaSBMdW8sPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5
b3VyIGNvbW1lbnQuIE15IGFuc3dlciBpcyBwbGFjZWQgaW5saW5lOjxicj4NCjxicj4NCk9uIDEx
LzIyLzIwMTIgMDg6MDIgQU0sIDwvZm9udD48YSBocmVmPW1haWx0bzpsdW8ud2VuQHp0ZS5jb20u
Y24+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5sdW8u
d2VuQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj4NCndyb3RlOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi
cj4NCkhpIFPDqXJnaW88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzMzMzM5OSBmYWNlPSJDYWxpYnJpIj48
YnI+DQomZ3Q7IFBTNjogRHVwbGljYXRlIG11bHRpY2FzdCB0cmFmZmljPC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j
MzMzMzk5IGZhY2U9IkNhbGlicmkiPjxicj4NCiZndDsgSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlv
biBvdmVyIGFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zDQombmJzcDtt
YXkgbGVhZCB0byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRp
b25zIHRvd2FyZHMNCnRoZSB0dW5uZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBp
biBQTUlQdjYpLiAmbmJzcDsmZ3Q7Q29uY3JldGVseSwNCndoZW4gbXVsdGljYXN0IHN1YnNjcmlw
dGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoDQptb2JpbGl0
eSB0dW5uZWxzLCBkdXBsaWNhdGUgbXVsdGljYXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0
byBiZSByZWNlaXZlZA0KdGhyb3VnaCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJv
YmxlbSBpcyBwb3RlbnRpYWxseSBtb3JlIHNldmVyZQ0KaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0
eSBlbnZpcm9ubWVudCBbZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAz
XS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZv
bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+PGJyPg0KIDwvaT48
L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9u
dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48Yj48aT48YnI+DQom
Z3Q7W0x1aXMmZ3Q7Jmd0O10gVGhpcyBzZWVtcyBub3QgdG8gYmUgYSBwcm9ibGVtIG9mIHRoZSBJ
UCBtb2JpbGl0eSBzb2x1dGlvbnMNCmhhbmRsaW5nIG11bHRpY2FzdCB0cmFmZmljIHdpdGggbW9i
aWxpdHkgdHVubmVscyBpbiBnZW5lcmFsLCBidXQgYSBwcm9ibGVtDQpvZiBjb25zaWRlcmluZyBz
ZXZlcmFsIHVwc3RyZWFtIHBhdGhzIGVuZGluZyBvbiB0aGUgc2FtZSBtb2JpbGl0eSBhY2Nlc3MN
CnJvdXRlciBhcyBhIGNvbnNlcXVlbmNlIG9mIGV4dGVuZGluZyB0dW5uZWxzIGZyb20gcHJldmlv
dXNNQVIgdG8gbmV3TUFSDQp0byBmb3J3YXJkIHRoZSBtdWx0aWNhc3QgdHJhZmZpYy48L2k+PC9i
PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxw
Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZndDsgW1NGXSBFeGFjdGx5LiBX
aGljaCBpcyBtb3JlDQp0aGFuIGxpa2VseSB0byBoYXBwZW4gaW4gYSBETU0gc29sdXRpb24sIHdo
ZXJlIGFsbCAmcXVvdDttb2JpbGl0eSBlbnRpdGllcyZxdW90Ow0KbWF5IGFjdCBhcyAmcXVvdDtt
b2JpbGl0eSBhY2Nlc3Mgcm91dGVycyZxdW90OywgYW5kLCBhZnRlciBtb2JpbGl0eSwgd2UNCndh
bnQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIHR1bm5lbCBmb3IgdGhlIHN1YnNjcmlwdGlvbi4g
SW4gdGhvc2UgY2FzZXMsDQpjYXJlIG11c3QgYmUgdGFrZW4gaW4gb3JkZXIgdG8gbm90IGdyZWF0
bHkgbWFnbmlmeSBjb252ZXJnZW5jZSBwcm9ibGVtDQpvYnNlcnZlZCBlLmcuIGluIFJGQzYyMjQu
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+DQo8cD48
Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bTHVvd2VuXSBBY2NvcmRpbmcgdG8g
dGhlIGFib3ZlDQpkaXNjdXNzaW9uLCBJIGJlbGlldmUgdGhlIFBTNiAmbmJzcDtpcyBiYXNlZCBv
biB0aGUgdXNhZ2Ugc2NlbmFyaW9zIGRpc2N1c3NlZA0KaW4gPC9mb250Pjxmb250IHNpemU9MiBj
b2xvcj0jMzMzMzk5IGZhY2U9IkNhbGlicmkiPmRyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVz
ZS1jYXNlLWRtbS0wMzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPi4NCkJ1dCwgaXQg
c2VlbXMgdG8gbWUgdGhlIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij51c2FnZQ0Kc2NlbmFyaW9zIGluIHRoaXMgZHJhZnQgaXMgYmFzZWQgb24gYSBhc3N1bWVkIGRt
bSB1bmljYXN0IHNvbHV0aW9uIGFuZA0KYXJjaGl0ZWN0dXJlLiBJTUhPLCB0aGUgUFMgc2hvdWxk
IGJlIGJhc2VkIG9uIGN1cnJlbnQgZXhpc3RpbmcgcHJvdG9jb2wNCihlLmcuIFJGQykgb3IgY3Vy
cmVudCBkZXBsb3ltZW50LCBub3QgYSBhc3N1bWVkIHNvbHV0aW9uLjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TRjogUFM2IGlzIG9ic2VydmFibGUgaXMg
Ym90aCBleGlzdGluZw0KcHJvdG9jb2xzIChlLmcuIFJGQzYyMjQpIGFuZCBpbiB0aGUgdXNlIGNh
c2VzIHdlIGFuYWx5emVkIC0gaW4gYSBQTUlQdjYtYmFzZWQNCkRNTSBzb2x1dGlvbi4gU28gSSBh
c3N1bWUgdGhlIFBTIGZpdHMgaW4gdGhlIFJFUXMgZG9jdW1lbnQuIEFzIEkgc2FpZCBiZWZvcmUs
DQppZiBpZ25vcmVkLCB0aGUgdHVubmVsIGNvbnZlcmdlbmNlIHByb2JsZW0gbWlnaHQgYmUgYSBt
dWNoIHNlcmlvdXMgcHJvYmxlbQ0KdGhhbiBpbiBSRkM2MjI0Ljxicj4NCjwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiZndDsmZ3Q7IEluIHRoZSB1c2UgY2FzZSBkcmFmdCwg
dGhlcmUgYXJlIGFueSBzb2x1dGlvbnMgbm90IGFzc3VtZWQuIFdlDQpwcmVzZW50ZWQgdXNlIGNh
c2VzLCBoYXZpbmcgdmFyaW91cyBkZXBsb3ltZW50cyBvZiBleGlzdGluZyBtdWx0aWNhc3Qgc3Rh
bmRhcmQNCmVudGl0aWVzLCBhbmQgY29ycmVzcG9uZGluZyBhbmFseXNpcyBiYXNlZCBvbiBkaXN0
cmlidXRlZCBkZXBsb3ltZW50IHNwZWNpZmllZA0KaW4gRE1NIFJFUTEuPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJBcmlhbCI+Tm8gbW9yZSwgbm8gbGVzcy48L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9IkFyaWFsIj5SZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi
PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlNlaWw8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pg0K
PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPC9mb250
Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUw
JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPlPDqXJnaW8gRmlndWVpcmVkbyA8L2I+PC9m
b250PjxhIGhyZWY9bWFpbHRvOnNmaWd1ZWlyZWRvQGF2Lml0LnB0Pjxmb250IHNpemU9MSBjb2xv
cj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT4mbHQ7c2ZpZ3VlaXJlZG9AYXYuaXQucHQmZ3Q7PC91
PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+PGZvbnQg
c2l6ZT0xPjxicj4NCuWPkeS7tuS6ujwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjog
Jm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQg
c2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmRtbS1ib3VuY2VzQGlldGYub3JnPC91
PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+
DQo8cD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTIvMTEvMjEgMDc6MjE8L2ZvbnQ+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NDkl
Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0x
NCU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MT7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+
DQo8dGQgd2lkdGg9ODUlPjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTEg
Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ZG1tQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv
cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xPuaKhOmAgTwvZm9udD48L2Rp
dj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz
aXplPTE+5Li76aKYPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+
UmU6IFtETU1dIE11bHRpY2FzdCBQUyB0byByZXF1aXJlbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxi
cj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD4N
Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAl
Pg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8cD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8YnI+DQpIaSBMdWlzLDxicj4NCjxi
cj4NCkEgZmV3IG1vcmUgY29tbWVudHMgb24gdGhpcyBpbmxpbmU6PGJyPg0KPGJyPg0KRW0gMjAt
MTEtMjAxMiAxOTo0NiwgTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE8gZXNjcmV2ZXU6IDwv
Zm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpIaSBB
bnRob255LCA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48
YnI+DQpzb21lIGNvbW1lbnRzIGluIGxpbmUgPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5
N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KQmVzdCByZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk
IGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh
bGlicmkiPjxicj4NCkx1aXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+
DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpEZTo8L2I+IDwvZm9udD48YSBo
cmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVl
IGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u
dCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3Vu
Y2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1h
aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl
PSJUYWhvbWEiPl0NCjxiPkVuIG5vbWJyZSBkZSA8L2I+aCBjaGFuPGI+PGJyPg0KRW52aWFkbyBl
bDo8L2I+IG1hcnRlcywgMjAgZGUgbm92aWVtYnJlIGRlIDIwMTIgMTg6NTE8Yj48YnI+DQpQYXJh
OjwvYj4gU8OpcmdpbyBGaWd1ZWlyZWRvOyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYu
b3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYub3Jn
PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KQXN1bnRv
OjwvYj4gW0RNTV0gTXVsdGljYXN0IFBTIHRvIHJlcXVpcmVtZW50czwvZm9udD48Zm9udCBzaXpl
PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KTGV0IHVzIGFsc28gdXNlIGFu
b3RoZXIgdGhyZWFkIHRvIGNoZWNrIGZvciBjb25zZW5zdXMgb2YgdGhlIFBTIGZyb20gbXVsdGlt
b2IuDQo8YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu
YnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+
DQpQUzEgKHJldmlzZWQpOiBOb24tb3B0aW1hbCByb3V0ZXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkg
ZmFjZT0iQ2FsaWJyaSI+PGJyPg0KUm91dGluZyB2aWEgYSBjZW50cmFsaXplZCBhbmNob3Igb2Z0
ZW4gcmVzdWx0cyBpbiBhIGxvbmdlciByb3V0ZS4gVGhlIHByb2JsZW0NCmlzIGVzcGVjaWFsbHkg
bWFuaWZlc3RlZCB3aGVuIGFjY2Vzc2luZyBhIGxvY2FsIHNlcnZlciBvciBzZXJ2ZXJzIG9mIGEN
CkNvbnRlbnQgRGVsaXZlcnkgTmV0d29yayAoQ0ROKSwgPGI+b3Igd2hlbiByZWNlaXZpbmcgLyBz
ZW5kaW5nIElQIG11bHRpY2FzdA0KcGFja2V0czwvYj4uIDwvZm9udD48Zm9udCBzaXplPTIgY29s
b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48Yj48aT48YnI+DQpbTHVpcyZndDsmZ3Q7XSBUaGlz
IGlzIGNvcnJlY3QgaWYgdGhlIG11bHRpY2FzdCBjb250ZW50IGlzIGxvY2FsbHkgYXZhaWxhYmxl
Lg0KSG93ZXZlciB0aGlzIGNvdWxkIG5vdCBiZSBhbHdheXMgdGhlIGNhc2UgZm9yIG11bHRpY2Fz
dCBsaXN0ZW5lcnMsIGZvcg0KYSBudW1iZXIgb2YgcmVhc29ucyAoZm9yIGluc3RhbmNlLCBjb25m
bGljdCBpbiB0aGUgbXVsdGljYXN0IGFkZHJlc3MgYWxsb2NhdGlvbg0KYmV0d2VlbiB0aGUgSG9t
ZSBOZXR3b3JrIGFuZCB0aGUgRE1NIGRvbWFpbikuIDwvaT48L2I+PC9mb250Pg0KPHA+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1NGXSBTdXJlLCBhbmQgdGhlIHNhbWUgYXBw
bGllcw0KdG8gJnF1b3Q7YWNjZXNzaW5nIGEgbG9jYWwgc2VydmVyIGEgQ0ROJnF1b3Q7IC0gaXQg
aXMgaW1wbGljaXQgdGhhdCB0aGUNCmNvbnRlbnQgaXMgbG9jYWxseSBhdmFpbGFibGUuIEJ1dCBp
dCBjYW4gYmUgaW1wcm92ZWQgYXMgJnF1b3Q7d2hlbiByZWNlaXZpbmcNCmxvY2FsbHkgYXZhaWxh
YmxlIElQIG11bHRpY2FzdCBvciBzZW5kaW5nIElQIG11bHRpY2FzdCZxdW90Oy48YnI+DQo8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KUFM2OiBE
dXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2Fs
aWJyaSI+PGJyPg0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hpdGVjdHVyZXMg
dXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zDQombmJzcDttYXkgbGVhZCB0byBjb252ZXJnZW5j
ZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25zIHRvd2FyZHMNCnRoZSB0dW5u
ZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBpbiBQTUlQdjYpLiAmbmJzcDtDb25j
cmV0ZWx5LA0Kd2hlbiBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uIGZvciBpbmRpdmlkdWFsIG1vYmls
ZSBub2RlcyBpcyBjb3VwbGVkIHdpdGgNCm1vYmlsaXR5IHR1bm5lbHMsIGR1cGxpY2F0ZSBtdWx0
aWNhc3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJlIHJlY2VpdmVkDQp0aHJvdWdoIGRp
ZmZlcmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IG1vcmUg
c2V2ZXJlDQppbiBhIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IGVudmlyb25tZW50IFtkcmFmdC1zZmln
dWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLjwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm
YWNlPSJDYWxpYnJpIj48Yj48aT48YnI+DQogPC9pPjwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0
OTdkIGZhY2U9IkNhbGlicmkiPjxiPjxpPjxicj4NCltMdWlzJmd0OyZndDtdIFRoaXMgc2VlbXMg
bm90IHRvIGJlIGEgcHJvYmxlbSBvZiB0aGUgSVAgbW9iaWxpdHkgc29sdXRpb25zDQpoYW5kbGlu
ZyBtdWx0aWNhc3QgdHJhZmZpYyB3aXRoIG1vYmlsaXR5IHR1bm5lbHMgaW4gZ2VuZXJhbCwgYnV0
IGEgcHJvYmxlbQ0Kb2YgY29uc2lkZXJpbmcgc2V2ZXJhbCB1cHN0cmVhbSBwYXRocyBlbmRpbmcg
b24gdGhlIHNhbWUgbW9iaWxpdHkgYWNjZXNzDQpyb3V0ZXIgYXMgYSBjb25zZXF1ZW5jZSBvZiBl
eHRlbmRpbmcgdHVubmVscyBmcm9tIHByZXZpb3VzTUFSIHRvIG5ld01BUg0KdG8gZm9yd2FyZCB0
aGUgbXVsdGljYXN0IHRyYWZmaWMuPC9pPjwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj5bU0ZdIEV4YWN0bHkuIFdoaWNoIGlzIG1vcmUgdGhhbg0KbGlrZWx5IHRvIGhhcHBl
biBpbiBhIERNTSBzb2x1dGlvbiwgd2hlcmUgYWxsICZxdW90O21vYmlsaXR5IGVudGl0aWVzJnF1
b3Q7DQptYXkgYWN0IGFzICZxdW90O21vYmlsaXR5IGFjY2VzcyByb3V0ZXJzJnF1b3Q7LCBhbmQs
IGFmdGVyIG1vYmlsaXR5LCB3ZQ0Kd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZiB0aGUgdHVubmVs
IGZvciB0aGUgc3Vic2NyaXB0aW9uLiBJbiB0aG9zZSBjYXNlcywNCmNhcmUgbXVzdCBiZSB0YWtl
biBpbiBvcmRlciB0byBub3QgZ3JlYXRseSBtYWduaWZ5IGNvbnZlcmdlbmNlIHByb2JsZW0NCm9i
c2VydmVkIGUuZy4gaW4gUkZDNjIyNC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClPDqXJnaW88
YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJy
Pg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSCBBbnRo
b255IENoYW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u
dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1h
aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i
VGFob21hIj48dT5kbW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPg0KWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0
Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmRt
bS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t
YSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Tw6lyZ2lvIEZpZ3VlaXJlZG88Yj48YnI+DQpTZW50
OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxMiA1OjI0IFBNPGI+PGJyPg0KVG86PC9iPiA8
L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVl
IGZhY2U9IlRhaG9tYSI+PHU+ZG1tQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y
IGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbRE1NXSBNdWx0aWNhc3Qg
cmVxdWlyZW1lbnRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PGJyPg0KICZuYnNwOzxicj4NCkhpIEFudGhvbnksPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZvciB0
cnlpbmcgdG8gcHJvZ3Jlc3Mgb24gdGhpcyBtYXR0ZXIuIEkgbW9zdGx5IGFncmVlIHdpdGggeW91
cg0KYW5hbHlzaXMuPGJyPg0KPGJyPg0KQXMgZm9yIHRoZSBxdWVzdGlvbiB5b3UgcG9zZWQsIGZp
cnN0IEkgd291bGQgbGlrZSB0byBleGFjdGx5IHVuZGVyc3RhbmQNCndoYXQgeW91IG1lYW4gd2l0
aCAmcXVvdDttdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvJnF1b3Q7IGluICZxdW90Ozwv
Zm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5ETU0NCnNvbHV0
aW9ucyBzaG91bGQgZW5hYmxlIG11bHRpY2FzdCBzZXJ2aWNlcyB3aGljaCBhcmUgY29tcGF0aWJs
ZSB3aXRoIG11bHRpY2FzdA0KZGlzdHJpYnV0aW9uIHNjZW5hcmlvLCBldGMuPC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZxdW90Oy4NCkl0IHNlZW1zIGxpa2UgdGhl
cmUgaXMgbm8gbWFqb3IgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoaXMgYW5kIHRoZSAmcXVvdDs8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+RE1NDQpzb2x1dGlv
bnMgc2hvdWxkIGVuYWJsZSBzb2x1dGlvbnMgdG8gc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMu
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZxdW90Ow0KcmVxdWly
ZW1lbnQ/IEFyZW4ndCBib3RoIGV4cHJlc3NpbmcgdGhlIG5lZWQgdG8gZW5hYmxlIG11bHRpY2Fz
dCBpbiBhIERNTQ0Kc29sdXRpb24/PGJyPg0KPGJyPg0KQXMgeW91IHN0YXRlZCwgJnF1b3Q7bmVn
bGVjdGluZyZxdW90OyB0aGUgcmVxdWlyZW1lbnQgNy4xIHdlIHByb3Bvc2VkLA0KbGVhZHMgdG8g
dGhlIFBTcyB5b3UgcmVmZXJyZWQuICZuYnNwO1NvLCB3aGlsZSA3LjIgYW5kIDcuMyBleHByZXNz
IHRoZQ0KbmVlZCBmb3IgRE1NIHNvbHV0aW9ucyB0byBhbGxvdyBkZXBsb3ltZW50IG9mIG11bHRp
Y2FzdCBzZXJ2aWNlcywgNy4xIGNvbmNlcm5zDQombmJzcDsmcXVvdDtob3cmcXVvdDsgSVAgbXVs
dGljYXN0IHNob3VsZCBiZSBlbmFibGVkIGluIG9yZGVyIHRvIGF2b2lkDQp0aGUgYWZvcmVtZW50
aW9uZWQgUFNzLiBUaGUgdXNhZ2Ugb2YgdGhlIHdvcmQgJnF1b3Q7ZmxleGlibGUmcXVvdDtpcyBl
eHBsYWluZWQNCmJ5OiA8YnI+DQo8YnI+DQomcXVvdDtUaGlzIGZsZXhpYmlsaXR5IGVuYWJsZXMg
ZGlmZmVyZW50IElQIG11bHRpY2FzdCBmbG93cyB3aXRoIHJlc3BlY3QNCnRvIGEgbW9iaWxlIGhv
c3QgdG8gYmUgbWFuYWdlZCAoZS5nLiwgc3Vic2NyaWJlZCwgcmVjZWl2ZWQgYW5kL29yIHRyYW5z
bWl0dGVkKQ0KdXNpbmcgbXVsdGlwbGUgZW5kcG9pbnRzJnF1b3Q7LiA8YnI+DQo8YnI+DQpJbiBv
dGhlciB3b3JkcywgY29tcGF0aWJpbGl0eSB3aXRoICZxdW90O211bHRpY2FzdCBkaXN0cmlidXRp
b24gc2NlbmFyaW8mcXVvdDsNCmRvZXNuJ3QgbmVjZXNzYXJpbHkgYXZvaWQgUFMxIGFuZCBQUzYu
PGJyPg0KPGJyPg0KVGhhbmsgeW91IGFuZCBiZXN0IHJlZ2FyZHMsPGJyPg0KU8Opcmdpbzxicj4N
Cjxicj4NCk9uIDExLzE5LzIwMTIgMTA6MjggUE0sIGggY2hhbiB3cm90ZTogPC9mb250Pjxmb250
IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClRoZXJlIGFyZSAzIHBy
b3Bvc2FscyBmb3IgbXVsdGljYXN0IHJlcXVpcmVtZW50cy4gQmVmb3JlIGNvbXBhcmluZyB0aGVz
ZQ0KcHJvcG9zYWxzLCBsZXQgdXMgdW5kZXJzdGFuZCB3aGF0IGFyZSB0aGUgcHJvYmxlbXMgZmly
c3QuIFR3byBwcm9ibGVtIHN0YXRlbWVudHMNCmhhdmUgYmVlbiBwcm9wb3NlZDo8L2ZvbnQ+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29s
b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3
ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpQUzEgKHJldmlzZWQpOiBOb24tb3B0aW1hbCByb3V0ZXM8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGNvbG9yPSMzMzMzOTkgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KUm91dGluZyB2aWEgYSBj
ZW50cmFsaXplZCBhbmNob3Igb2Z0ZW4gcmVzdWx0cyBpbiBhIGxvbmdlciByb3V0ZS4gVGhlIHBy
b2JsZW0NCmlzIGVzcGVjaWFsbHkgbWFuaWZlc3RlZCB3aGVuIGFjY2Vzc2luZyBhIGxvY2FsIHNl
cnZlciBvciBzZXJ2ZXJzIG9mIGENCkNvbnRlbnQgRGVsaXZlcnkgTmV0d29yayAoQ0ROKSwgPGI+
b3Igd2hlbiByZWNlaXZpbmcgLyBzZW5kaW5nIElQIG11bHRpY2FzdA0KcGFja2V0czwvYj4uIDxi
cj4NClBTNjogRHVwbGljYXRlIG11bHRpY2FzdCB0cmFmZmljPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMzMzMzk5
IGZhY2U9IkNhbGlicmkiPjxicj4NCklQIG11bHRpY2FzdCBkaXN0cmlidXRpb24gb3ZlciBhcmNo
aXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucw0KJm5ic3A7bWF5IGxlYWQgdG8g
Y29udmVyZ2VuY2Ugb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dhcmRz
DQp0aGUgdHVubmVs4oCZcyBkb3duc3RyZWFtIGVudGl0eSAoZS5nLiBNQUcgaW4gUE1JUHY2KS4g
Jm5ic3A7Q29uY3JldGVseSwNCndoZW4gbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBmb3IgaW5kaXZp
ZHVhbCBtb2JpbGUgbm9kZXMgaXMgY291cGxlZCB3aXRoDQptb2JpbGl0eSB0dW5uZWxzLCBkdXBs
aWNhdGUgbXVsdGljYXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSByZWNlaXZlZA0K
dGhyb3VnaCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJvYmxlbSBpcyBwb3RlbnRp
YWxseSBtb3JlIHNldmVyZQ0KaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudCBb
ZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzXS48L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg
ZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhlbiwgbGV0IHVzIHNlZSB3aGV0aGVyIGFsbCB0aGUgMyBS
RVEgcHJvcG9zYWxzIGhhdmUgdGhlIHNhbWUgaW50ZW50aW9uLg0KSW4gdGhlIGZvbGxvd2luZywg
SSByZXBocmFzZSB0aGVtIHRvIGhpZ2hsaWdodCB0aGVpciBzaW1pbGFyaXRpZXMuPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBj
b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0
OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClJFUTcuMTogRmxleGlibGUgbXVsdGljYXN0IGRpc3Ry
aWJ1dGlvbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u
dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpETU0gc29s
dXRpb25zIHNob3VsZCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3Ry
aWJ1dGlvbg0Kc2NlbmFyaW8uIEV0Yy4gPGJyPg0KVGhlIE1vdGl2YXRpb24gaXMgdG8gYWxsb3cg
ZmxleGliaWxpdHkgaW4gKGVuYWJsZSkgbXVsdGljYXN0IHNvbHV0aW9ucw0KdG8gc29sdmUgdGhl
IHByb2JsZW1zIFBTMSBhbmQgUFM2IGFzIGV4cGxhaW5lZCBpbiB1c2UgY2FzZXMgYWxyZWFkeSBw
cmVzZW50ZWQNCmFuZCBkaXNjdXNzZWQgaW4gbXVsdGltb2Igd2cuPC9mb250Pjxmb250IHNpemU9
MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0
OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9
IkNhbGlicmkiPjxicj4NClJFUTcuMjogPGJyPg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxl
IHNvbHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiA8YnI+DQogPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl
PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQooT3JpZ2luYWwgd29yZGluZyB3
YXMgJnF1b3Q7VGhlIERNTSAodW5pY2FzdCkgc29sdXRpb24gTVVTVCBiZSBzcGVjaWZpZWQNCmlu
IHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWxzbyBzdXBwb3J0IG11bHRp
Y2FzdCB0cmFmZmljLiZxdW90Ow0KSSByZXBocmFzZSBpdCB0byBoaWdobGlnaHQgdGhlIHNpbWls
YXJpdHkgd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxzIGFuZA0KYWxzbyBjaGFuZ2VkIHRoZSBtdXN0
IHRvIHNob3VsZC4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxm
b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClJFUTcuMzo8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXpl
PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpETU0gc29sdXRpb25zIHNob3Vs
ZCBlbmFibGUgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2VzLjwvZm9udD48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIg
Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm
NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpPcmlnaW5hbCB3b3JkaW5nIHdhcyDigJxETU0gc29s
dXRpb25zIHNob3VsZCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcw0K4oCmIGV0Yy4gR2l2ZW4g
dGhhdCBpdCBpcyB0aGUgc2NvcGUgb2YgbXVsdGltb2IgYW5kIG5vdCBkbW0gd2cgdG8gcHJvdmlk
ZQ0KdGhlIG11bHRpY2FzdCBzb2x1dGlvbiwgSSB0aGluayDigJxzdXBwb3J04oCdIGhlcmUgbWVh
bnMg4oCcZW5hYmxl4oCdIHNvbHV0aW9ucw0KdG8gYmUgZGV2ZWxvcGVkIChieSBtdWx0aW1vYiku
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250
IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj
b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClNpbWlsYXJpdHkgYW5kIHN1YnRsZSBk
aWZmZXJlbmNlczogQm90aCBSRVE3LjIgYW5kIFJFUTcuMyB3YW50IHRvIGVuYWJsZQ0KbXVsdGlj
YXN0IHNlcnZpY2VzLiBZZXQgdGhlIGV4cGxhbmF0aW9uIGluIFJFUTcuMSBzZWVtcyB0byBpbmRp
Y2F0ZSBub3QNCmp1c3QgdG8gZW5hYmxlIGFueSBvbmUgbXVsdGljYXN0IHNvbHV0aW9uIGJ1dCBh
bHNvIG5lZWRzIHRoZSBmbGV4aWJpbGl0eQ0KaW4gbXVsdGljYXN0IHNvbHV0aW9uLiBOb3QgYWxs
IG11bHRpY2FzdCBzb2x1dGlvbnMgYXJlIHRoZSBzYW1lLiBTb21lIG9mDQp0aGVtIHJlc3VsdHMg
aW4gUFMxIG9yIFBTNi4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs
aWJyaSI+PGJyPg0KQXJlIHRoZXJlIGFueSBhcmUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdl
ZW46PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxm
b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkluIFJFUTcuMSwg
RE1NIHNvbHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxlIG11bHRpY2Fz
dCBkaXN0cmlidXRpb24NCnNjZW5hcmlvLCBldGMuIDxicj4NClZlcnN1czwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j
MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkRNTSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBt
dWx0aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJlIGNvbXBhdGlibGUgd2l0aA0KbXVsdGljYXN0IGRp
c3RyaWJ1dGlvbiBzY2VuYXJpbywgZXRjLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp
YnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu
YnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+
DQpIIEFudGhvbnkgQ2hhbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N
CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250
Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkZyb206PC9iPiA8L2ZvbnQ+PGEg
aHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1
ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv
bnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQpbPC9mb250PjxhIGhyZWY9Im1haWx0bzpkbW0tYm91
bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5t
YWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj
ZT0iVGFob21hIj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNlaWwgSmVvbjxiPjxicj4NClNlbnQ6
PC9iPiBNb25kYXksIE5vdmVtYmVyIDE5LCAyMDEyIDU6MTUgQU08Yj48YnI+DQpUbzo8L2I+IDwv
Zm9udD48YSBocmVmPW1haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPjxmb250IHNpemU9
MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbTwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkNjOjwvYj4g
PC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1
ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0RNTV0gTXVsdGljYXN0
IHJlcXVpcmVtZW50czwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N
Cjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBQ
aWVycmljayw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh
bCI+PGJyPg0KSeKAmXZlIG1hbnkgdGltZXMgdGhvdWdodCBhYm91dCB5b3VyIHF1ZXN0aW9uLiBJ
IHdvdWxkIHNheSBob3cgZWZmZWN0aXZlbHkNCnNob3VsZCB3ZSBkZXBsb3kvc3VwcG9ydCBtdWx0
aWNhc3Qgb3ZlciBkaXN0cmlidXRlZCBtb2JpbGl0eSByYXRoZXIgdGhhbg0KZGlzdHJpYnV0ZWQg
bW9iaWxlIG11bHRpY2FzdC4gQXMgYSByZXN1bHQsIHlvdSBjYW4gZmluZCB0aGlzIGRlcGxveW1l
bnQNCnVzZSBjYXNlIGFuZCBnYXAgYW5hbHlzaXMgYXQgPC9mb250PjxhIGhyZWY9Imh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRt
bS0wMyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pmh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0w
MzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+DQpwcmVzZW50ZWQgaW4g
bXVsdGltb2Igc2V2ZXJhbCB0aW1lcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogPC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkluIHVuaWNhc3QgRE1NLCBtYWluIGlubm92YXRpb24g
aXMgdG8gZGlzdHJpYnV0ZSB0aGUgYW5jaG9yIGZ1bmN0aW9uIGF0DQptYW55IGFjY2VzcyByb3V0
ZXJzIGZyb20gc2luZ2xlIGNvcmUuIEZvbGxvd2luZyBhcmNoaXRlY3R1cmFsIGNvbmNlcHQgb2YN
CkRNTSwgZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBpcyBvbmUgb2YgbXVsdGljYXN0
IHJlcXVpcmVtZW50IHJlc3VsdGVkDQpmcm9tIHRoZSBkcmFmdCBkZXNjcmliZWQgYWJvdmUuIDxi
cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PGJy
Pg0KUkVRODogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiA8YnI+DQomcXVvdDtETU0g
c29sdXRpb25zIFNIT1VMRCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRp
c3RyaWJ1dGlvbg0Kc2NlbmFyaW9zLiBUaGlzIGZsZXhpYmlsaXR5IGVuYWJsZXMgZGlmZmVyZW50
IElQIG11bHRpY2FzdCBmbG93cyB3aXRoIHJlc3BlY3QNCnRvIGEgbW9iaWxlIGhvc3QgdG8gYmUg
bWFuYWdlZCAoZS5nLiwgc3Vic2NyaWJlZCwgcmVjZWl2ZWQgYW5kL29yIHRyYW5zbWl0dGVkKQ0K
dXNpbmcgbXVsdGlwbGUgZW5kcG9pbnRzJnF1b3Q7LiA8YnI+DQo8YnI+DQpNb3RpdmF0aW9uOiBU
aGUgbW90aXZhdGlvbiBmb3IgdGhpcyByZXF1aXJlbWVudCBpcyB0byBlbmFibGUgZmxleGliaWxp
dHkNCmluIG11bHRpY2FzdCBkaXN0cmlidXRpb24uIFRoZSBtdWx0aWNhc3Qgc29sdXRpb24gbWF5
IHRoZXJlZm9yZSBhdm9pZCBoYXZpbmcNCm11bHRpY2FzdC1jYXBhYmxlIGFjY2VzcyByb3V0ZXJz
IGJlaW5nIHJlc3RyaWN0ZWQgdG8gbWFuYWdlIGFsbCBJUCBtdWx0aWNhc3QNCnRyYWZmaWMgcmVs
YXRpdmUgdG8gYSBob3N0IHZpYSBhIHNpbmdsZSBlbmRwb2ludCAoZS5nLiByZWd1bGFyIG9yIHR1
bm5lbA0KaW50ZXJmYWNlKSwgd2hpY2ggd291bGQgbGVhZCB0byB0aGUgcHJvYmxlbXMgZGVzY3Jp
YmVkIGluIFBTMSBhbmQgUFM2Lg0KPGJyPg0KUFM2OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRyYWZm
aWMgPGJyPg0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hpdGVjdHVyZXMgdXNp
bmcgSVAgbW9iaWxpdHkgc29sdXRpb25zDQombmJzcDttYXkgbGVhZCB0byBjb252ZXJnZW5jZSBv
ZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25zIHRvd2FyZHMNCnRoZSB0dW5uZWzi
gJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBpbiBQTUlQdjYpLiAmbmJzcDtDb25jcmV0
ZWx5LA0Kd2hlbiBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uIGZvciBpbmRpdmlkdWFsIG1vYmlsZSBu
b2RlcyBpcyBjb3VwbGVkIHdpdGgNCm1vYmlsaXR5IHR1bm5lbHMsIGR1cGxpY2F0ZSBtdWx0aWNh
c3Qgc3Vic2NyaXB0aW9uKHMpIGlzIHByb25lIHRvIGJlIHJlY2VpdmVkDQp0aHJvdWdoIGRpZmZl
cmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IG1vcmUgc2V2
ZXJlDQppbiBhIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IGVudmlyb25tZW50IFtkcmFmdC1zZmlndWVp
cmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLjxicj4NCjxicj4NCjxicj4NCjwvZm9udD48
Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClJlZ2FyZHMsPC9mb250Pjxmb250IHNpemU9
MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs
Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNw
OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClNlaWw8L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i
QXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkZyb206PC9i
PiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT48Zm9udCBz
aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5j
b208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEg
aHJlZj1tYWlsdG86cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT48Zm9udCBzaXplPTIgY29sb3I9
Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPC91
PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8
L2I+IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIgODo1NSBBTTxiPjxicj4NClRvOjwvYj4gJzwv
Zm9udD48YSBocmVmPW1haWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sPjxmb250IHNpemU9MiBj
b2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+a2FyYWdpYW5AY3MudXR3ZW50ZS5ubDwvdT48L2Zv
bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPic7DQo8L2ZvbnQ+PGEgaHJlZj1tYWls
dG86c2VpbGplb25AYXYuaXQucHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21h
Ij48dT5zZWlsamVvbkBhdi5pdC5wdDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJU
YWhvbWEiPjsNCjwvZm9udD48YSBocmVmPW1haWx0bzpKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRp
Z2l0YWwuY29tPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+SnVhbkNh
cmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBm
YWNlPSJUYWhvbWEiPjxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBp
ZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRm
Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1
YmplY3Q6PC9iPiBSRTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50czwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSGkgYWxsLDwvZm9udD48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBj
b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0
OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkkgdGVuZCB0byBhZ3JlZSB3aXRoIEdlb3JnaW91cywg
aG93ZXZlciBJIHN0aWxsIGRvIG5vdCBmaWd1cmUgb3V0IHdoYXQNCmlzIHRoZSB1c2UtY2FzZSBm
b3IgZGlzdHJpYnV0ZWQgbW9iaWxlIG11bHRpY2FzdCAob3RoZXIgdGhhbiBhY2FkZW1pYyBjb25z
aWRlcmF0aW9ucyk/DQpDYW4gc29tZW9uZSBnaXZlIGNvbmNyZXRlIGV4YW1wbGU/IDxicj4NCiA8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxm
b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkkgaGF2ZW7igJl0
IHJlYWwgYWxsIG1lc3NhZ2VzIGZyb20gdGhpcyB0aHJlYWQuIFNvLCBtYXliZSBJIG1pc3NlZCBp
bXBvcnRhbnQNCnBvaW50cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+
DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9u
dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpCUiw8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXpl
PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpQaWVycmljazwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xv
cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi
PjxiPjxicj4NCkRlIDo8L2I+IDwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0
Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5j
ZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8
L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIg
Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPkRlIGxhIHBhcnQg
ZGU8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sPjxmb250
IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+a2FyYWdpYW5AY3MudXR3ZW50ZS5u
bDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkVudm95
w6kgOjwvYj4gc2FtZWRpIDE3IG5vdmVtYnJlIDIwMTIgMTM6MDE8Yj48YnI+DQrDgCA6PC9iPiA8
L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c2VpbGplb25AYXYuaXQucHQ+PGZvbnQgc2l6ZT0yIGNvbG9y
PWJsdWUgZmFjZT0iVGFob21hIj48dT5zZWlsamVvbkBhdi5pdC5wdDwvdT48L2ZvbnQ+PC9hPjxm
b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjsNCjwvZm9udD48YSBocmVmPW1haWx0bzpKdWFuQ2Fy
bG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29tPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9
IlRhaG9tYSI+PHU+SnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbTwvdT48L2ZvbnQ+
PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkNjIDo8L2I+IDwvZm9udD48
YSBocmVmPW1haWx0bzpkbW1AaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i
VGFob21hIj48dT5kbW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i
VGFob21hIj48Yj48YnI+DQpPYmpldCA6PC9iPiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVt
ZW50czwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCiAm
bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KSGkgYWxsLDwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NCkkg
YWxzbyBhZ3JlZSB0aGF0IHRoZSBETU0gc29sdXRpb24gc2hvdWxkIHNvbWVob3cgY29uc2lkZXIg
bXV0aWNhc3QgZGVwbG95bWVudC4NCkhvd2V2ZXIsIEkgZG8gbm90IHRobmsgdGhhdCB0aGUgRE1N
IFdHIGlzIHRoZSByaWdodCBXRyB0byBwcm92aWRlIHRoZSBtdWx0aWNhc3QNCmJhc2VkIERNTSBz
b2x1dGlvbiE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFo
b21hIj48YnI+DQpPbmUgYWx0ZXJuYXRpdmUgc29sdXRpb24gd2lsbCBiZSB0byBoYXZlIGEgbXVs
dGljYXN0IHJlcXVpcmVtZW50IHRoYXQgZW1waGFzaXplcw0KdGhlIG5lZWQgb2YgaGF2aW5nIGV4
dGVuc2liaWxpdHkgaG9va3MgKHBvc3NpYmlsaXRpZXMpIHRoYXQgY2FuIGJlIHVzZWQNCmxhdGVy
IG9uIGJ5IHRoZSBtdWx0aW1vYiBXRyB0byBwcm92aWRlIGEgPGJyPg0KYSBtdWx0aWNhc3QgZW5h
YmxlZCBETU0gc29sdXRpb24hPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NCiA8L2ZvbnQ+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NClNv
IGEgcmVxdWlyZW1lbnQgdGhhdCBzcGVjaWZpZXMgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2lu
ZyBjb3VsZCBiZSB1c2VkDQpmb3IgdGhpcyBwdXJwb3NlOjwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxi
cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m
b250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NCiZxdW90O1RoZSBETU0gKHVuaWNh
c3QpIHNvbHV0aW9uIE1VU1QgYmUgc3BlY2lmaWVkIGluIHN1Y2ggYSB3YXkgdGhhdCBpdA0KY2Fu
IGJlIGV4dGVuZGVkIHRvIGFsc28gc3VwcG9ydCBtdWx0aWNhc3QgdHJhZmZpYy4mcXVvdDs8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0K
IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+
PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KQmVzdCByZWdhcmRzLDwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJUYWhvbWEiPjxicj4NCkdlb3JnaW9zPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO
ZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KIDwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt
ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJy
Pg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2Zv
bnQ+DQo8ZGl2IGFsaWduPWNlbnRlcj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8aHI+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KVmFuOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpk
bW0tYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21h
Ij48dT5kbW0tYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl
PSJUYWhvbWEiPg0KWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmci
Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0
Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQpuYW1lbnMg
U2VpbCBKZW9uIFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c2VpbGplb25AYXYuaXQucHQ+PGZvbnQg
c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5zZWlsamVvbkBhdi5pdC5wdDwvdT48
L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl08Yj48YnI+DQpWZXJ6b25kZW46
PC9iPiB2cmlqZGFnIDE2IG5vdmVtYmVyIDIwMTIgMjI6MjU8Yj48YnI+DQpUbzo8L2I+ICdadW5p
Z2EsIEp1YW4gQ2FybG9zJzxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRt
bUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBp
ZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4N
Ck9uZGVyd2VycDo8L2I+IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBm
YWNlPSJUYWhvbWEiPjxicj4NCkhpIEp1YW4sPGJyPg0KPGJyPg0KSSd2ZSBiZWVuIGxvb2tlZCBh
dCBjaGFuZ2VkIGZsb3cgb2YgeW91ciBwcm9wb3NlZCB0ZXh0IGJ1dCBzb3JyeSBub3cgdGhhdA0K
bXk8YnI+DQpjb21tZW50IGlzIHBvc3RlZC48YnI+DQpBdCBmaXJzdCB0aW1lLCBJIGNvdWxkbid0
IG1ha2Ugc3VyZSBob3dldmVyLCBvbiBoZWFyaW5nIFN0aWcncyBkZXNjcmlwdGlvbiw8YnI+DQpp
dCBzZWVtcyBxdWl0ZSByZWFzb25hYmxlIGF0IHRoZSBmaXJzdCBzdGVwLCBub3QgZ2l2aW5nIGFu
eSByZXN0cmljdGlvbnMNCmJ1dDxicj4NCmxlYXZpbmcgc29tZS1zcGVjaWZpYyBmb3IgdGhlIERN
TSBzb2x1dGlvbiBpdCBkb2VzIG5vdCBzdXBwb3J0IG11bHRpY2FzdC48YnI+DQo8YnI+DQpPbiB0
aGUgb3RoZXIgaGFuZCwgaXQgcmVtYWlucyBhdCBhIGJhc2ljIHN0YWdlIGZvciB0aGUgRE1NIHNv
bHV0aW9uIHRvPGJyPg0Kc3VwcG9ydCBtdWx0aWNhc3QuPGJyPg0KU28gSSB0aGluayBhZGRpdGlv
bmFsIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIG1hZGUgZm9yIHRoZSBETU0gc29sdXRpb24sPGJy
Pg0KYWNjb3JkaW5nbHkuIEJ1dCBvZiBjb3Vyc2UsIHRoaXMgc2hvdWxkIG5vdCBhbHNvIGdpdmUg
YW55IHNwZWNpZmljPGJyPg0KbGltaXRhdGlvbiBhbmQgcmVzdHJpY3Rpb24gYnV0IHNob3VsZCBi
ZSBtYWRlIHRvd2FyZHMgdGhlIGRpcmVjdGlvbiBub3Q8YnI+DQpsaW1pdGluZyB0aGUgYmVuZWZp
dHMgcHJvdmlkZWQgYnkgZGlzdHJpYnV0ZWQgZGVwbG95bWVudC48YnI+DQo8YnI+DQpJIGhvcGUg
dG8gZ2V0IG1vcmUgY29tbWVudHMgb24gdGhpcy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxi
cj4NClNlaWw8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N
CkZyb206IDwvZm9udD48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250
IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8
L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEgaHJl
Zj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9
MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3Jn
PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KT24gQmVoYWxmIE9m
PGJyPg0KWnVuaWdhLCBKdWFuIENhcmxvczxicj4NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYs
IDIwMTIgODoxNCBQTTxicj4NClRvOiBTdGlnIFZlbmFhczsgPC9mb250PjxhIGhyZWY9bWFpbHRv
OmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRt
bUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4N
ClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzPGJyPg0KPGJyPg0KPGJy
Pg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogU3RpZyBW
ZW5hYXMgWzwvZm9udD48YSBocmVmPW1haWx0bzpzdGlnQHZlbmFhcy5jb20gdGFyZ2V0PV9ibGFu
az48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpzdGlnQHZl
bmFhcy5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dPGJyPg0K
Jmd0OyBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDM6MDEgUE08YnI+DQomZ3Q7IFRv
OiBqb3VuaSBrb3Job25lbjxicj4NCiZndDsgQ2M6IDwvZm9udD48YSBocmVmPW1haWx0bzpzYXJp
a2F5YUBpZWVlLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnNh
cmlrYXlhQGllZWUub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+
Ow0KWnVuaWdhLCBKdWFuIENhcmxvczsgS29uc3RhbnRpbm9zIFBlbnRpa291c2lzOyA8YnI+DQom
Z3Q7IFBldGVyIE1jQ2FubjsgPC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9yZz48Zm9u
dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9yZzwvdT48L2Zv
bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NCiZndDsgU3ViamVjdDogUmU6
IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTEv
MTUvMjAxMiAzOjE3IEFNLCBqb3VuaSBrb3Job25lbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDsgT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFNLCBCZWhjZXQgU2FyaWtheWEg
d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn
dDsgSSB0aGluayB3ZSBhcmUgcmVhZGluZyB0b28gbXVjaCBpbnRvIG11bHRpY2FzdCBhbmQgdW5p
Y2FzdA0Kc2hvdWxkPGJyPg0KYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRlc2lnbmVkIGluIGFuIGlu
dGVncmF0ZWQgbWFubmVyLjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRo
ZSBmYWN0IGlzIHRoYXQgbXVsdGljYXN0IGlzIGNvbnNpZGVyZWQgYXMgYW4gYXJlYSBvZjxicj4N
CiZndDsgc3BlY2lhbGl6YXRpb24sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpdCByZXF1aXJlcyBrbm93
bGVkZ2Ugb2YgdmVyeSBkaWZmZXJlbnQgcHJvdG9jb2xzIHRoYW4gd2UNCmFyZSA8YnI+DQomZ3Q7
ICZndDsmZ3Q7IGFjY3VzdG9tZWQgdG8gaW4gbW9iaWxpdHkuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7ICZxdW90O1JlcXVpcmVtZW50OiBETU0gc29sdXRpb25zIFNIT1VMRCBzdXBwb3J0
IG11bHRpY2FzdCBzZXJ2aWNlcy4NCklmIGE8YnI+DQomZ3Q7IHNwZWNpZmljIERNTSBzb2x1dGlv
biBkb2VzIG5vdCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcywgYW4gPGJyPg0KJmd0OyBleHBs
YW5hdGlvbiBNVVNUIGJlIHByb3ZpZGVkLiZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlz
IHNvdW5kcyBnb29kIHRvIG1lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbWFpbiB0aGluZyBJ
IHdhbnQgdG8gYWNoaWV2ZSBpcyB3aGF0IHdhcyBkZXNjcmliZXMgYXMgbW90aXZhdGlvbg0KPGJy
Pg0KJmd0OyBlYXJsaWVyIGluIHRoaXMgdGhyZWFkLiBNdWx0aWNhc3Qgc2hvdWxkIGF0IGxlYXN0
IGJlIGNvbnNpZGVyZWQgd2hlbg0KPGJyPg0KJmd0OyBsb29raW5nIGludG8gRE1NIHNvbHV0aW9u
cywgYW5kIG5vdCBqdXN0IGFuIGFmdGVydGhvdWdodCBvbmNlIHRoZQ0KPGJyPg0KJmd0OyBzb2x1
dGlvbiBpcyBkZWNpZGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdGlnPGJyPg0KPGJyPg0KW0pD
Wl0gSSBmdWxseSBhZ3JlZSB3aXRoIHRoaXMuIFRoYXQgd2FzIHRoZSBpbnRlbnRpb24gb2YgdGhl
IHByb3Bvc2VkIHRleHQuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpKdWFuIENhcmxv
czxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvIG1lIHRoYXQgcmVhZHMgYmFzaWNh
bGx5ICZxdW90O2RvIG5vdCBicmVhayBmb3VuZGF0aW9ucyBmb3INCm11bHRpY2FzdDxicj4NCiZn
dDsgdW5sZXNzIHlvdSBoYXZlIGEgdmFsaWQgJmFtcDsgZG9jdW1lbnRlZCByZWFzb24gZm9yIGl0
JnF1b3Q7LiAmbmJzcDtJZg0Kd2UgbG9vayBlLmcuPGJyPg0KJmd0OyBpbnRvIFJGQzYyNSBtdWx0
aWNhc3Qgd29yZGluZyB0aGF0IGlzIHRoZXJlIHZlcnkgYnJpZWZseSBidXQgZ2l2ZXMNCmEgPGJy
Pg0KJmd0OyBoaW50IHRvIGEgZGV2ZWxvcGVyIHdoZXJlIHRvIGhlYWQgdG8uIFRoYXQgaXMgdGhl
IGxldmVsIEkgd291bGQgZXhwZWN0DQo8YnI+DQomZ3Q7IERNTSBkb2N1bWVudHMgc2hvdWxkIGFp
bSB0by48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLSBKb3VuaTxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgTGV0IGRtbSBkZWFsIHdpdGggaXRz
IGN1cnJlbnQgY2hhcnRlciB0aGF0IGRvZXMgbm90IGluY2x1ZGUNCmEgd29yZDxicj4NCiZndDsg
b2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7IG11bHRpY2FzdCBhbmQgaWYgZXZlcnl0aGluZyBnb2VzIHdl
bGwgd2UgY2FuIGNvbWUgYmFjayBhbmQNCmRpc2N1c3M8YnI+DQomZ3Q7IGRtbTxicj4NCiZndDsg
Jmd0OyZndDsgbXVsdGljYXN0Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7
IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgQmVoY2V0PGJy
Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpkbW0gbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzpkbW1A
aWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5kbW1AaWV0
Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBO
ZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2RtbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1i
bHVlIGZhY2U9IlRhaG9tYSI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9kbW08L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48YnI+DQo8YnI+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRt
bSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOmRtbUBpZXRmLm9y
Zz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRtbUBpZXRmLm9yZzwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj
ZT0iVGFob21hIj48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250
Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj
ZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy
Pg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg
aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcw0Kb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl
bnQgZG9uYzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCnBhcyBldHJlIGRpZmZ1c2Vz
LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCnJl
Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj
ZT0iQ291cmllciBOZXciPjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp
IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KZWxlY3Ryb25pcXVlcyBldGFu
dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt
ZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi
cj4NCkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg
c2kgY2UgbWVzc2FnZSBhIGV0ZQ0KYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll
ciBOZXciPjxicj4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu
IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQppbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90
ZWN0ZWQgYnkgbGF3OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N
CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCnRoZXkgc2hvdWxk
IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u
LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9u
dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo
aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCmRlbGV0ZSB0
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3
Ij48YnI+DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3Jhbmdl
IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzDQp0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh
bmdlZCBvciBmYWxzaWZpZWQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVGhhbmsg
eW91LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+
PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y
IGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpkbW0gbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs
dWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFp
bHRvOmRtbUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5l
dyI+PHU+ZG1tQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kbW0+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291
cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC91
PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQog
Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i
c3A7PC9mb250Pg0KPGRpdiBhbGlnbj1jZW50ZXI+DQo8YnI+DQo8aHI+PC9kaXY+DQo8YnI+PGZv
bnQgc2l6ZT0xIGNvbG9yPSM4MDgwODAgZmFjZT0iQXJpYWwiPjxicj4NCkVzdGUgbWVuc2FqZSBz
ZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRh
cg0KbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxl
Y3Ryw7NuaWNvIGVuDQplbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLjxicj4NClRoaXMgbWVz
c2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBz
ZW5kIGFuZA0KcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg
YXQ6PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMv
ZGlzY2xhaW1lci5hc3B4Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5o
dHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweDwvdT48L2ZvbnQ+PC9h
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxicj4NCjwvZm9udD48
Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDwvZm9udD48
Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwv
dT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1tQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1i
bHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5kbW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u
dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48
L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbT48
Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv
dXJpZXIgTmV3Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs
dWUgZmFjZT0iQ291cmllciBOZXciPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86
ZG1tQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48
dT5kbW1AaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl
PSJDb3VyaWVyIE5ldyI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9
IkNvdXJpZXIgTmV3Ij48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt
bTwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PiZuYnNwOzwvZm9udD4NCjxicj4NCg==
--=_alternative 0010C19B48257AC2_=--

From Peter.McCann@huawei.com  Mon Nov 26 07:54:26 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9145C21F85C7; Mon, 26 Nov 2012 07:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl3wJgtq2aVq; Mon, 26 Nov 2012 07:54:25 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC721F85A6; Mon, 26 Nov 2012 07:54:17 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AND82885; Mon, 26 Nov 2012 15:54:15 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Nov 2012 15:54:10 +0000
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Nov 2012 15:54:14 +0000
Received: from DFWEML512-MBB.china.huawei.com ([169.254.14.19]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 26 Nov 2012 07:54:08 -0800
From: Peter McCann 
To: jouni korhonen 
Thread-Topic: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
Thread-Index: AQHNxz3DQQQBC3W/sU+JRgVtIyAvCpfy7olggAC+hYD//3xY0IAAjCcA//97uoCAAJVJgP//ejdQABOHHoAABSeKoAAWNosAAAesqeAAJAylgAC4CjtwABlJU4AACu3TkA==
Date: Mon, 26 Nov 2012 15:54:07 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E66E4E@dfweml512-mbb.china.huawei.com>
References:  <5963DDF1F751474D8DEEFDCDBEE43AE716E587E9@dfweml512-mbx.china.huawei.com> <9892BC94-F495-405F-93E9-90A33DAF8C96@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E588CF@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E5890E@dfweml512-mbx.china.huawei.com> <4B2145DF-3D42-4EE4-A1F7-E3622F2A74D8@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E58955@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E58A92@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E58BDE@dfweml512-mbx.china.huawei.com> <88BBDF91-7A51-427A-BD3C-897B79C17781@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E65D8B@dfweml512-mbb.china.huawei.com> <60EF112E-92B4-45D2-90F3-AD64173E4BD4@gmail.com>
In-Reply-To: <60EF112E-92B4-45D2-90F3-AD64173E4BD4@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.132]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "netext@ietf.org" , "dmm@ietf.org" , Basavaraj Patil , "draft-ietf-netext-pd-pmip@tools.ietf.org" 
Subject: Re: [DMM] [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Nov 2012 15:54:26 -0000

Hi, Jouni,

jouni korhonen wrote:
> Pete,
>=20
>=20
> On Nov 26, 2012, at 10:57 AM, Peter McCann wrote:
>=20
>> Hi, Jouni,
>>=20
>> jouni korhonen wrote:
>>> Pete,
>>>=20
>>> I hope we start getting closer to convergence.. this thread is getting
>>> longish..
>>=20
>> Yes and sorry about the delay responding.  We had the Thanksgiving
>> holiday here in the US and I was out of touch.
>>=20
>>> On Nov 21, 2012, at 6:34 PM, Peter McCann wrote:
>>>=20
>>>> Hi, Jouni,
>>>>=20
>>>> jouni korhonen wrote:
>>>>>>=20
>>>>>> I guess if you sent a DHCP Renew every time you detected a link
>>>>>> flap (handover to new MAG) that would do the trick.  It seems
>>>>>> somewhat expensive, though.
>>>>>=20
>>>>> It is what RFC3315 says.. client sends a confirm request.
>>>>=20
>>>> Right, I am just pointing out that the link may flap even when the
>>>> same LMA is reachable.  Seems like overhead.  You seem to be
>>>> requiring that the link doesn't flap when the PMIP session continues
>>>> after a MAG to MAG handover under the same LMA.
>>>=20
>>> I would say it it does not flap. The MR (at will) will still see it as
>>> a change of access point or something equivalent at the L2. If that
>>> event then gets delivered to the IP level somehow is out of my
>>> control. I have no control how the DHCPv6-PD client gets implemented
>>> in the MR or whether the network driver delivers proper events to
>>> upper layers.
>>>=20
>>> This is getting to the original reason why we wrote the draft.
>>> Depending on how the MR figures out "whether the link changed" it may
>>> or may not bother sending the Confirm Request. And if it does not,
>>> then the MAG does not know about the delegated prefixes -> forwarding
>>> fails. On the network side I cannot really trust the MR DHCPv6-PD
>>> client to do the right thing all the time.
>>=20
>> Ok, so can we summarize the recommendation for PMIP deployments:
>>=20
>> (1) When handing off between two MAGs under the same LMA, the change of
>> link SHOULD NOT be propagated to the IP stack (the link flap should not
>> be visible to IP).
>=20
> Should not is OKish. Cannot guarantee that though.

Right.  I think that many links will flap on every handover, whether
LMA changes or not.

>> (2) When handing off between two MAGs where the second MAG cannot or
>> does not connect back to the previous LMA, the change of link MUST be
>> propagated up the IP stack.
>=20
> Yep.

Ok, good.

>> I think that (1) is a SHOULD NOT because violation of this SHOULD NOT
>> only leads to some extra traffic on the link from re-confirmation. In
>> contrast, (2) is a MUST because the absence of a link down/up event
>> could lead to a hung session where the MN thinks it has a routable
>> prefix but actually does not.
>>=20
>> Have either of these two requirements been codified in 5213 or
>> elsewhere?
>=20
> RFC5213 is prepared to handle 1) independent whether the event is
> sent or not, ref the DNA text and link-local address MO.

Ok, I see that text now.

Should we document (2) somewhere?

>>>>> The LMA-LMA hanover, as per current RFC5213, would be visible as a
>>>>> link flap or L2 session termination whatever. At least on those L2
>>>>> technologies that I am aware of.
>>>>=20
>>>> In my view, a MAG to MAG handover under the same LMA is equally
>>>> likely to lead to a link flap.  Which really does no harm, it only
>>>> leads to extra DHCP or RS/RA reconfirmation traffic in this case.
>>>=20
>>> LMA-LMA handover based on the existing specs means the end of PMIP
>>> session, which on the point-to-point link technologies I am aware of
>>> also results in the termination of the L2 session. We have not defined
>>> how renumbering would work in this case. In certain L2 technologies
>>> renumbering is not even supported (ref 3GPP).
>>=20
>> Are you aware of a deployment of PMIP over the 3GPP PDP context link?
>> I am not.  The existing GPRS model is that the GGSN or PGW is the
> first
>=20
> I am. This is not an academic exercise.
>=20
>> hop router, and traffic is always tunneled directly back to that
>> router. In contrast, PMIP has the MAG as the first hop router.  This is
>> a fundamental difference that IMHO makes it more likely to see a link
>> flap on a MAG to MAG handover, even when the same LMA is reachable from
>> both.
>=20
> If the LMA stays the same, the link does not flap.=20

I don't see how you can make a blanket statement like this for all
link layers that might be used for PMIP.  In particular, it seems
to require a knowledge, at the L2, of whether the current MAG can
see the same LMA.  This knowledge needs to be propagated across the
link to the client, and used to determine whether the link down/up
event propagates through the IP stack.  Perhaps your particular=20
implementation experience involved carrying such a signal but I
cannot imagine that it holds true for every L2, especially if they
were not designed with PMIP in mind.

> One might receive
> an event that the access point (or equivalent) changed. This again
> depends on the client side implementation.

And in many implementations I can imagine this event treated as a link
flap.
=20
>> I think you agree with me that a change of MAG that results in a change
>> of LMA should always result in a link down/up event that is visible to
>> the IP stack.
>=20
> I repeat what I said earlier. If the LMA changes the L2 session goes
> down, prefixes may change etc. It is a bit more than just link up/down
> because it also involves setting up a new PMIP session & L2 session. (on
> L2 technologies I am concerned with).

You seem to be implying that the L2 technology has a notion of a PMIP
session.  The layered protocol model would seem to discourage this,
and I can imagine that many link layers are designed without PMIP
in mind.

>>>> Yes, that might help, but it seems to run counter to the
>>>> recommendation in RFC 6543.  Also, I am not so sure that it will be
>>>> possible to define
>>>=20
>>> I know and again back to the context of my assertion:
>>>=20
>>> "..(possible by specs but a hack in a way, thus not elaborated in this
>>> I-D)."
>>>=20
>>> And that "specs" dates to original RC5213 which would allow us this.
>>> Even when using RFC6543 I can turn it off by configuration.
>>=20
>> Agreed, it's possible.
>>=20
>>>> clean boundaries a priori where different link local addresses would
>>>> be assigned.  There may be some overlap in the LMA coverage areas
>>>> (although
>>>=20
>>> Assuming RFC6543 is not used and we do assign different link-locals,
>>> then it is up to the LMA decide when to use which link-local. Two
>>> examples: each LMA has its own or each PMIP session gets its own
>>> "unique" link-local. Both cases have possibility of address collisions
>>> but are quite unlikely. I do not really care about coverage areas
>>> rather the case when something happened on the emulated home link and
>>> for that case the two examples would be sufficient. Note that I am not
>>> prompting such "solution".
>>=20
>> Did you mean to say "up to the MAG"?  I am not sure I like the idea of
>> the LMA controlling the MAG's link-local address.
>=20
> No.. or lets say my wording was imprecise. Whether this feature is
> enabled depends on the MAG configuration. If MAG allows the LMA to
> generate the link-local, then LMA does it and MAG uses that address. In
> that case the LMA decides when to use which link-local address.

It would still require coordination between the old LMA and the new
LMA, precisely in those situations where no such coordination is possible
(the PMIP domains are distinct and unconnected).

>>>> You may be running a server on the MN which is waiting for inbound
>>>> connections.  The peer correspondent nodes would send traffic to the
>>>> old prefix, and there would be no indication to the MN that the old
>>>> prefix isn't valid anymore.
>>>=20
>>> As said we cannot heal all networking issues by specifications if
>>> people do not implement them properly. If your delegated prefix is
>>> gone from the network point of view and your MR sits there doing
>>> nothing while it should based on e.g. RFC3315, tough luck.
>>=20
>> If the link down/up event has been hidden from the IP stack, then
>> sitting there doing nothing is exactly what an RFC3315 compliant
>> implementation would do.  Hence my use of MUST in (2) above.
>=20
> Sure. Never claimed it to be different. But as said, I cannot control
> the client side implementation. That is the point.

But you seem to be making assumptions about the L2 implementation=20
and that, in particular, it knows when a PMIP session is disconnected.


I am sorry to be making a big deal about these issues.  I am raising
them because I think it will be important to get these details right
when it comes to the DMM solution.  There, I think we will have some
set of prefixes assigned to the MN at any given time, and some arbitrary
subset will need to be deprecated and/or torn down proactively upon=20
each handover (change of MAG if a PMIP-style solution is used to=20
re-route the packets).  However, we can discuss more details on the
DMM list if you prefer (and this may get us a bit into DMM solution
space.  But, I am trying to think ahead).

-Pete



From seiljeon@av.it.pt  Mon Nov 26 08:03:39 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C717721F8585 for ; Mon, 26 Nov 2012 08:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level: 
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGl5sf0A9tec for ; Mon, 26 Nov 2012 08:03:37 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 28BEA21F856C for ; Mon, 26 Nov 2012 08:03:33 -0800 (PST)
Received: from [193.136.93.174] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67132022; Mon, 26 Nov 2012 16:03:29 +0000
From: "Seil Jeon" 
To: 
References: <017701cdc900$8b92a940$a2b7fbc0$@av.it.pt> 
In-Reply-To: 
Date: Mon, 26 Nov 2012 16:03:51 -0000
Message-ID: <005f01cdcbef$a0dbe400$e293ac00$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01CDCBEF.A0F3B1C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ+EfORuC4I2n89MTd9lE28/dZe2JaboxFw
Content-Language: ko
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?562U5aSNOiBSZTogIE11bHRpY2FzdCBQUyB0byByZXF1aXJl?= =?utf-8?q?ments?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Nov 2012 16:03:39 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0060_01CDCBEF.A0F3B1C0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Luo,

=20

Thanks to your comments based on our draft.

=20

See inline, please.

=20

Regards,

=20

Seil

=20

From: luo.wen@zte.com.cn [mailto:luo.wen@zte.com.cn]=20
Sent: Monday, November 26, 2012 3:03 AM
To: Seil Jeon
Cc: dmm@ietf.org; 'S=C3=A9rgio Figueiredo'
Subject: =E7=AD=94=E5=A4=8D: RE: [DMM] =E7=AD=94=E5=A4=8D: Re: Multicast =
PS to requirements

=20


Hi Seil & S=C3=A9rgio:=20

Thank you for your reply, And with all respect, I don't know where are =
you coming from when you say there are any solutions not assumed?=20

When I read your draft, you have assumption A3 :=20
It is assumed that when the IP mobility happens, at least one
  multicast flow is being received (listener) / sent (sender). and a
  mobility tunnel will be created between the P-MAR and the N-MAR.=20

>> This show a certain =E2=80=9CSTATUS=E2=80=9D that can be made by =
various DMM solutions not a solution obviously.

and A4: ... But when a user moves to another MAR (N-MAR), under
  assumption A3, the upstream interface of MLD Proxy will be configured
  towards the anchor that enables unicast IP address continuity to be
  kept (P-MAR, analogous to LMA function).

>> It is also same, see the next explanation in details.

IMHO, if without a assumed solution, why you assume, e.g. a mobility =
tunnel will be creates between the P-MAR and N-MAR?  Also, when I read =
your figure 1,2 and 3, why the traffic must be delivered in this way? =
And the limitations you have discussed are basically based on such =
scenarios, not?

>> =E2=80=9CMobility tunnel=E2=80=9D itself is not a solution. =
We=E2=80=99re playing on the =E2=80=9Ctunneling pipe=E2=80=9D when we =
talk about IP mobility. And you know? There are two ways possible to =
configure MLD upstream interface on the IP mobility; following the =
direction of anchor router or always upper multicast router when we use =
existing IGMP/MLD standard. As I mentioned above, these situations may =
happen which DMM solutions you propose, if you follow =E2=80=9CREQ1: =
distributed deployment=E2=80=9D. And this assumption is quite reasonable =
without support of any DMM solutions.

Importantly, in here, we didn=E2=80=99t assume nor consider any =
protocol, behavior, and even signaling.

=20


My point is, the multicast requirements in DMM REQ in this stage should =
be some text like "DMM solutions should enable solutions to support =
multicast traffic. ".

=20

>> It=E2=80=99s not bad but not to be only one. As I said maybe 10 days =
ago, it remains at a basic stage for the DMM solution to support =
multicast. I don=E2=80=99t know what can we get from that. We need to =
touch more multicast-characteristic for DMM multicast as specified not =
giving any specific limitation and restriction but importantly being =
made towards the direction not limiting the benefits provided by =
distributed deployment. I think you=E2=80=99re quite aware of this need.

=20

Scenarios for multicast discussed in this stage is too early since there =
are no dmm solutions and architecture, many people shares this opinions =
I believe.=20



>> As I said, these use cases are not based on any DMM solutions but on =
existing DMM requirements. The requirement we proposed is resulted from =
the presented use cases and full analysis.=20

=20

And sorry I don=E2=80=99t agree with your opinion. In DMM meeting, it =
was agreed to worth to look at DMM multicast requirements, many people =
wanted to see them. But it was urged to be made quickly. So, =
we=E2=80=99re discussing and making progressing for better text, right? =
You can check the meeting minutes.


BR=20
Luowen=20





"Seil Jeon" =20

2012/11/23 06:27=20


=E6=94=B6=E4=BB=B6=E4=BA=BA

=20


=E6=8A=84=E9=80=81

, 'S=C3=A9rgio Figueiredo' =20


=E4=B8=BB=E9=A2=98

RE: [DMM] =E7=AD=94=E5=A4=8D: Re:  Multicast PS to requirements

=20

	=09




Hi Luo,=20
 =20
Additionally following the comment by Sergio,=20
 =20
 =20
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 AM
To: luo.wen@zte.com.cn
Cc: dmm@ietf.org
Subject: Re: [DMM] =E7=AD=94=E5=A4=8D: Re: Multicast PS to requirements=20
 =20
Hi Luo,

Thanks for your comment. My answer is placed inline:

On 11/22/2012 08:02 AM, luo.wen@zte.com.cn wrote:=20

Hi S=C3=A9rgio=20

> PS6: Duplicate multicast traffic=20
> IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast subscriptions =
towards the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
>Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].=20
=20
>[Luis>>] This seems not to be a problem of the IP mobility solutions =
handling multicast traffic with mobility tunnels in general, but a =
problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic.=20

> [SF] Exactly. Which is more than likely to happen in a DMM solution, =
where all "mobility entities" may act as "mobility access routers", and, =
after mobility, we want to take advantage of the tunnel for the =
subscription. In those cases, care must be taken in order to not greatly =
magnify convergence problem observed e.g. in RFC6224.=20

[Luowen] According to the above discussion, I believe the PS6  is based =
on the usage scenarios discussed in =
draft-sfigueiredo-multimob-use-case-dmm-03. But, it seems to me the =
usage scenarios in this draft is based on a assumed dmm unicast solution =
and architecture. IMHO, the PS should be based on current existing =
protocol (e.g. RFC) or current deployment, not a assumed solution.=20
SF: PS6 is observable is both existing protocols (e.g. RFC6224) and in =
the use cases we analyzed - in a PMIPv6-based DMM solution. So I assume =
the PS fits in the REQs document. As I said before, if ignored, the =
tunnel convergence problem might be a much serious problem than in =
RFC6224.

>> In the use case draft, there are any solutions not assumed. We =
presented use cases, having various deployments of existing multicast =
standard entities, and corresponding analysis based on distributed =
deployment specified in DMM REQ1.=20
No more, no less.=20
 =20
Regards,=20
 =20
Seil=20

=20


S=C3=A9rgio Figueiredo   =
=20
=E5=8F=91=E4=BB=B6=E4=BA=BA:    =
dmm-bounces@ietf.org=20

2012/11/21 07:21=20

=20


=E6=94=B6=E4=BB=B6=E4=BA=BA

  dmm@ietf.org=20


=E6=8A=84=E9=80=81

=09

=E4=B8=BB=E9=A2=98

Re: [DMM] Multicast PS to requirements


 =20

=20

	=09




Hi Luis,

A few more comments on this inline:

Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:=20
Hi Anthony,=20
=20
some comments in line=20
=20
Best regards,=20
=20
Luis=20
=20
De:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] En nombre de =
h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: S=C3=A9rgio Figueiredo;   dmm@ietf.org
Asunto: [DMM] Multicast PS to requirements=20
=20
Let us also use another thread to check for consensus of the PS from =
multimob.=20
=20
PS1 (revised): Non-optimal routes=20
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / sending =
IP multicast packets.=20
[Luis>>] This is correct if the multicast content is locally available. =
However this could not be always the case for multicast listeners, for a =
number of reasons (for instance, conflict in the multicast address =
allocation between the Home Network and the DMM domain).=20

[SF] Sure, and the same applies to "accessing a local server a CDN" - it =
is implicit that the content is locally available. But it can be =
improved as "when receiving locally available IP multicast or sending IP =
multicast".

PS6: Duplicate multicast traffic=20
IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].=20
=20
[Luis>>] This seems not to be a problem of the IP mobility solutions =
handling multicast traffic with mobility tunnels in general, but a =
problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic.=20

[SF] Exactly. Which is more than likely to happen in a DMM solution, =
where all "mobility entities" may act as "mobility access routers", and, =
after mobility, we want to take advantage of the tunnel for the =
subscription. In those cases, care must be taken in order to not greatly =
magnify convergence problem observed e.g. in RFC6224.

Regards,
S=C3=A9rgio

=20
H Anthony Chan=20
=20
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of =
S=C3=A9rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To:   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements=20
=20
Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with =
your analysis.

As for the question you posed, first I would like to exactly understand =
what you mean with "multicast distribution scenario" in "DMM solutions =
should enable multicast services which are compatible with multicast =
distribution scenario, etc.". It seems like there is no major difference =
between this and the "DMM solutions should enable solutions to support =
multicast services." requirement? Aren't both expressing the need to =
enable multicast in a DMM solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to =
the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM =
solutions to allow deployment of multicast services, 7.1 concerns  "how" =
IP multicast should be enabled in order to avoid the aforementioned PSs. =
The usage of the word "flexible"is explained by:=20

"This flexibility enables different IP multicast flows with respect to a =
mobile host to be managed (e.g., subscribed, received and/or =
transmitted) using multiple endpoints".=20

In other words, compatibility with "multicast distribution scenario" =
doesn't necessarily avoid PS1 and PS6.

Thank you and best regards,
S=C3=A9rgio

On 11/19/2012 10:28 PM, h chan wrote:=20
There are 3 proposals for multicast requirements. Before comparing these =
proposals, let us understand what are the problems first. Two problem =
statements have been proposed:=20
=20
PS1 (revised): Non-optimal routes=20
Routing via a centralized anchor often results in a longer route. The =
problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / sending =
IP multicast packets.=20
PS6: Duplicate multicast traffic=20
IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].=20
=20
Then, let us see whether all the 3 REQ proposals have the same =
intention. In the following, I rephrase them to highlight their =
similarities.=20
=20
REQ7.1: Flexible multicast distribution=20
DMM solutions should be compatible with flexible multicast distribution =
scenario. Etc.=20
The Motivation is to allow flexibility in (enable) multicast solutions =
to solve the problems PS1 and PS6 as explained in use cases already =
presented and discussed in multimob wg.=20
=20
REQ7.2:=20
DMM solutions should enable solutions to support multicast traffic.=20
=20
(Original wording was "The DMM (unicast) solution MUST be specified in =
such a way that it can be extended to also support multicast traffic." I =
rephrase it to highlight the similarity with the other proposals and =
also changed the must to should.)=20
=20
REQ7.3:=20
DMM solutions should enable solutions to support multicast services.=20
=20
Original wording was =E2=80=9CDMM solutions should support multicast =
services =E2=80=A6 etc. Given that it is the scope of multimob and not =
dmm wg to provide the multicast solution, I think =
=E2=80=9Csupport=E2=80=9D here means =E2=80=9Cenable=E2=80=9D solutions =
to be developed (by multimob).=20
=20
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable =
multicast services. Yet the explanation in REQ7.1 seems to indicate not =
just to enable any one multicast solution but also needs the flexibility =
in multicast solution. Not all multicast solutions are the same. Some of =
them results in PS1 or PS6.=20
=20
Are there any are essential differences between:=20
In REQ7.1, DMM solutions should be compatible with flexible multicast =
distribution scenario, etc.=20
Versus=20
DMM solutions should enable multicast services which are compatible with =
multicast distribution scenario, etc.=20
=20
H Anthony Chan=20
=20
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of =
Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To:   pierrick.seite@orange.com
Cc:   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements=20
=20
Hi Pierrick,=20
=20
I=E2=80=99ve many times thought about your question. I would say how =
effectively should we deploy/support multicast over distributed mobility =
rather than distributed mobile multicast. As a result, you can find this =
deployment use case and gap analysis at  =
 =
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 =
presented in multimob several times.=20
=20
In unicast DMM, main innovation is to distribute the anchor function at =
many access routers from single core. Following architectural concept of =
DMM, flexible multicast distribution is one of multicast requirement =
resulted from the draft described above.=20
=20
REQ8: Flexible multicast distribution=20
"DMM solutions SHOULD be compatible with flexible multicast distribution =
scenarios. This flexibility enables different IP multicast flows with =
respect to a mobile host to be managed (e.g., subscribed, received =
and/or transmitted) using multiple endpoints".=20

Motivation: The motivation for this requirement is to enable flexibility =
in multicast distribution. The multicast solution may therefore avoid =
having multicast-capable access routers being restricted to manage all =
IP multicast traffic relative to a host via a single endpoint (e.g. =
regular or tunnel interface), which would lead to the problems described =
in PS1 and PS6.=20
PS6: Duplicate multicast traffic=20
IP multicast distribution over architectures using IP mobility solutions =
 may lead to convergence of duplicated multicast subscriptions towards =
the tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6).  =
Concretely, when multicast subscription for individual mobile nodes is =
coupled with mobility tunnels, duplicate multicast subscription(s) is =
prone to be received through different upstream paths. This problem is =
potentially more severe in a distributed mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].



Regards,=20
=20
Seil=20
=20
From:   pierrick.seite@orange.com [ =
 mailto:pierrick.seite@orange.com]=20
Sent: Monday, November 19, 2012 8:55 AM
To: '  karagian@cs.utwente.nl';  =
 seiljeon@av.it.pt;  =
 =
JuanCarlos.Zuniga@InterDigital.com
Cc:   dmm@ietf.org
Subject: RE: [DMM] Multicast requirements=20
=20
Hi all,=20
=20
I tend to agree with Georgious, however I still do not figure out what =
is the use-case for distributed mobile multicast (other than academic =
considerations)? Can someone give concrete example?=20
=20
I haven=E2=80=99t real all messages from this thread. So, maybe I missed =
important points.=20
=20
BR,=20
Pierrick=20
=20
De :   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] De la part de =
  karagian@cs.utwente.nl
Envoy=C3=A9 : samedi 17 novembre 2012 13:01
=C3=80 :   seiljeon@av.it.pt;  =
 =
JuanCarlos.Zuniga@InterDigital.com
Cc :   dmm@ietf.org
Objet : Re: [DMM] Multicast requirements=20
=20
Hi all,=20
=20
I also agree that the DMM solution should somehow consider muticast =
deployment. However, I do not thnk that the DMM WG is the right WG to =
provide the multicast based DMM solution!=20
=20
One alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a=20
a multicast enabled DMM solution!=20
=20
=20
So a requirement that specifies something like the following could be =
used for this purpose:=20
=20
"The DMM (unicast) solution MUST be specified in such a way that it can =
be extended to also support multicast traffic."=20
=20
=20
Best regards,=20
Georgios=20
=20
=20
 =20


 =20

  _____ =20



Van:   dmm-bounces@ietf.org [ =
 dmm-bounces@ietf.org] namens Seil Jeon [ =
 seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc:   dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements=20
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now =
that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's =
description,
it seems quite reasonable at the first step, not giving any restrictions =
but
leaving some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From:   dmm-bounces@ietf.org [ =
 mailto:dmm-bounces@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas;   dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [  mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc:   sarikaya@ieee.org; Zuniga, Juan =
Carlos; Konstantinos Pentikousis;=20
> Peter McCann;   dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>=20
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are=20
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an=20
> explanation MUST be provided."
>=20
> This sounds good to me.
>=20
> The main thing I want to achieve is what was describes as motivation=20
> earlier in this thread. Multicast should at least be considered when=20
> looking into DMM solutions, and not just an afterthought once the=20
> solution is decided.
>=20
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed =
text.

Regards,

Juan Carlos

>=20
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a=20
> hint to a developer where to head to. That is the level I would expect =

> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm=20
_________________________________________________________________________=
________________________________________________=20
=20
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc=20
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler=20
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,=20
France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.=20
=20
This message and its attachments may contain confidential or privileged =
information that may be protected by law;=20
they should not be distributed, used or copied without authorisation.=20
If you have received this email in error, please notify the sender and =
delete this message and its attachments.=20
As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.=20
Thank you.=20




_______________________________________________=20
dmm mailing list=20
  dmm@ietf.org=20
  =
https://www.ietf.org/mailman/listinfo/dmm=20
 =20

 =20

=20

  _____ =20



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar =
nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo =
electr=C3=B3nico en el enlace situado m=C3=A1s abajo.
This message is intended exclusively for its addressee. We only send and =
receive email on the basis of the terms set out at:
  =
http://www.tid.es/ES/PAGINAS/disclaimer.aspx


_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
  dmm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/dmm=20
 =20


------=_NextPart_000_0060_01CDCBEF.A0F3B1C0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi =
Luo,
 
Thanks to =
your comments based on our draft.
 
See inline, =
please.
 
Regards,=

 
Seil
 
From:=
 =
luo.wen@zte.com.cn [mailto:luo.wen@zte.com.cn] 
Sent: Monday, =
November 26, 2012 3:03 AM
To: Seil Jeon
Cc: =
dmm@ietf.org; 'S=C3=A9rgio Figueiredo'
Subject: =E7=AD=94=E5=A4=8D: RE: [DMM] =
=E7=AD=94=E5=A4=8D: Re: =
Multicast PS to requirements
 

Hi =
Seil & S=C3=A9rgio: 

Thank you =
for your reply, And with all respect, I don't know where are you coming =
from when you say there are any solutions not assumed? =


When I read your draft, you have assumption A3 : =

It is assumed that when the IP mobility happens, at =
least one
  multicast flow is being received (listener) / sent =
(sender). and a
  mobility tunnel will be created between the =
P-MAR and the N-MAR. 
>> =
This show a certain =E2=80=9CSTATUS=E2=80=9D that can be made by various =
DMM solutions not a solution obviously.
and A4: ... But when a user moves to another MAR =
(N-MAR), under
  assumption A3, the upstream interface of MLD =
Proxy will be configured
  towards the anchor that enables =
unicast IP address continuity to be
  kept (P-MAR, analogous to =
LMA function).
>> It =
is also same, see the next explanation in details.
IMHO, if without a assumed solution, why you =
assume, e.g. a mobility tunnel will be creates between the P-MAR and =
N-MAR?  Also, when I read your figure 1,2 and 3, why the traffic =
must be delivered in this way? And the limitations you have discussed =
are basically based on such scenarios, not?
>> =
=E2=80=9CMobility tunnel=E2=80=9D itself is not a solution. =
We=E2=80=99re playing on the =E2=80=9Ctunneling pipe=E2=80=9D when we =
talk about IP mobility. And you know? There are two ways possible to =
configure MLD upstream interface on the IP mobility; following the =
direction of anchor router or always upper multicast router when we use =
existing IGMP/MLD standard. As I mentioned above, these situations may =
happen which DMM solutions you propose, if you follow =E2=80=9CREQ1: =
distributed deployment=E2=80=9D. And this assumption is quite reasonable =
without support of any DMM solutions.
Importantly, =
in here, we didn=E2=80=99t assume nor consider any protocol, behavior, =
and even signaling.
 

My =
point is, the multicast requirements in DMM REQ in this stage should be =
some text like "DMM solutions should enable solutions to support multicast traffic. =
".
 
>> It=E2=80=99s not bad but not to be only =
one. As I said maybe 10 days ago, it remains at a basic stage for the =
DMM solution to support multicast. I don=E2=80=99t know what can we get =
from that. We need to touch more multicast-characteristic for DMM =
multicast as specified not giving any specific limitation and =
restriction but importantly being made towards the direction not =
limiting the benefits provided by distributed deployment. I think =
you=E2=80=99re quite aware of this need.
 
 =
Scenarios for multicast discussed in this stage is too early since there =
are no dmm solutions and architecture, many people shares this opinions =
I believe. 

>> As I said, these use cases are not based =
on any DMM solutions but on existing DMM requirements. The requirement =
we proposed is resulted from the presented use cases and full analysis. =

 
And sorry I don=E2=80=99t agree with your opinion. =
In DMM meeting, it was agreed to worth to look at DMM multicast =
requirements, many people wanted to see them. But it was urged to be =
made quickly. So, we=E2=80=99re discussing and making progressing for =
better text, right? You can check the meeting minutes.

BR 
Luowen 


"Seil =
Jeon" <seiljeon@av.it.pt> =

2012/11/23 =
06:27 
=E6=94=
=B6=E4=BB=B6=E4=BA=BA
<luo.wen@zte.com.cn> =

=E6=8A=
=84=E9=80=81
<dmm@ietf.org>, 'S=C3=A9rgio =
Figueiredo' <sfigueiredo@av.it.pt> =

=E4=B8=
=BB=E9=A2=98
RE: [DMM] =
=E7=AD=
=94=E5=A4=8D: Re: =
 Multicast PS to =
requirements
 



Hi =
Luo, 
 =
 
Additionally =
following the comment by Sergio, 
 =
 
 =
 
From:=
 =
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] =
On Behalf Of Sergio Figueiredo
Sent: Thursday, November =
22, 2012 9:35 AM
To: luo.wen@zte.com.cn
Cc: =
dmm@ietf.org
Subject: Re: =
[DMM] =E7=AD=
=94=E5=A4=8D: Re: =
Multicast PS to requirements 
  
Hi Luo,

Thanks =
for your comment. My answer is placed inline:

On 11/22/2012 08:02 =
AM, luo.wen@zte.com.cn wrote: =


Hi =
S=C3=A9rgio 

> PS6: Duplicate multicast traffic 
> IP multicast distribution over architectures using IP =
mobility solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  >Concretely, when multicast subscription for =
individual mobile nodes is coupled with mobility tunnels, duplicate =
multicast subscription(s) is prone to be received through different =
upstream paths. This problem is potentially more severe in a distributed =
mobility environment =
[draft-sfigueiredo-multimob-use-case-dmm-03]. 
 
>[Luis>>] This seems not to be a problem of the IP =
mobility solutions handling multicast traffic with mobility tunnels in =
general, but a problem of considering several upstream paths ending on =
the same mobility access router as a consequence of extending tunnels =
from previousMAR to newMAR to forward the multicast =
traffic. 
> [SF] Exactly. Which is more than likely =
to happen in a DMM solution, where all "mobility entities" may =
act as "mobility access routers", and, after mobility, we want =
to take advantage of the tunnel for the subscription. In those cases, =
care must be taken in order to not greatly magnify convergence problem =
observed e.g. in RFC6224. 
[Luowen] =
According to the above discussion, I believe the PS6  is based on =
the usage scenarios discussed in draft-sfigueiredo-multimob-use-case-dmm-03. But, it =
seems to me the usage scenarios =
in this draft is based on a assumed dmm unicast solution and =
architecture. IMHO, the PS should be based on current existing protocol =
(e.g. RFC) or current deployment, not a assumed solution. =

SF: PS6 is observable is both =
existing protocols (e.g. RFC6224) and in the use cases we analyzed - in =
a PMIPv6-based DMM solution. So I assume the PS fits in the REQs =
document. As I said before, if ignored, the tunnel convergence problem =
might be a much serious problem than in RFC6224.

>> =
In the use case draft, there are any solutions not assumed. We presented =
use cases, having various deployments of existing multicast standard =
entities, and corresponding analysis based on distributed deployment =
specified in DMM REQ1. 
No more, no =
less. 
 =
 
Regards, 
 =
 
Seil =

 
S=C3=A9rgio =
Figueiredo <sfigueired=
o@av.it.pt> 
=E5=8F=91=E4=BB=B6=E4=BA=BA: =
 dmm-bounces@ie=
tf.org 
2012/11/21 =
07:21 
 
=E6=94=
=B6=E4=BB=B6=E4=BA=BA
dmm@ietf.org 
=E6=8A=
=84=E9=80=81
=E4=B8=
=BB=E9=A2=98
Re: [DMM] =
Multicast PS to requirements

  =

 



Hi =
Luis,

A few more comments on this inline:

Em 20-11-2012 =
19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu: 
Hi Anthony, 
 
some comments in line 
 
Best regards, 
 
Luis 
 
De: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] En =
nombre de h chan
Enviado el: martes, 20 de noviembre de =
2012 18:51
Para: S=C3=A9rgio Figueiredo; dmm@ietf.org=

Asunto:<=
/span> [DMM] =
Multicast PS to requirements 
 
Let us also use another thread to check for consensus of the PS =
from multimob. 
 
PS1 (revised): Non-optimal routes 
Routing via a centralized anchor often results in a longer route. =
The problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / =
sending IP multicast packets. 
[Luis>>] This is correct if the multicast content is =
locally available. However this could not be always the case for =
multicast listeners, for a number of reasons (for instance, conflict in =
the multicast address allocation between the Home Network and the DMM =
domain). 
[SF] Sure, and the same =
applies to "accessing a local server a CDN" - it is implicit =
that the content is locally available. But it can be improved as =
"when receiving locally available IP multicast or sending IP =
multicast".

PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment [draft-sfigueiredo-multimob-use-case-dmm-03]. =

 
[Luis>>] This seems not to be a problem of the IP mobility =
solutions handling multicast traffic with mobility tunnels in general, =
but a problem of considering several upstream paths ending on the same =
mobility access router as a consequence of extending tunnels from =
previousMAR to newMAR to forward the multicast traffic. =

[SF] Exactly. Which is more than likely to happen in a =
DMM solution, where all "mobility entities" may act as =
"mobility access routers", and, after mobility, we want to =
take advantage of the tunnel for the subscription. In those cases, care =
must be taken in order to not greatly magnify convergence problem =
observed e.g. in RFC6224.

Regards,
S=C3=A9rgio

 
H Anthony Chan 
 
From: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] On =
Behalf Of S=C3=A9rgio Figueiredo
Sent: Monday, November =
19, 2012 5:24 PM
To: dmm@ietf.org=

Subject:=
 Re: [DMM] =
Multicast requirements 
 
Hi Anthony,

Thank you =
for trying to progress on this matter. I mostly agree with your =
analysis.

As for the question you posed, first I would like to =
exactly understand what you mean with "multicast distribution =
scenario" in "DMM solutions should enable multicast services which are compatible =
with multicast distribution scenario, etc.". It seems like =
there is no major difference between this and the "DMM solutions should enable solutions to support multicast =
services." requirement? Aren't both expressing the need to =
enable multicast in a DMM solution?

As you stated, =
"neglecting" the requirement 7.1 we proposed, leads to the PSs =
you referred.  So, while 7.2 and 7.3 express the need for DMM =
solutions to allow deployment of multicast services, 7.1 concerns =
 "how" IP multicast should be enabled in order to avoid =
the aforementioned PSs. The usage of the word "flexible"is =
explained by: 

"This flexibility enables different IP =
multicast flows with respect to a mobile host to be managed (e.g., =
subscribed, received and/or transmitted) using multiple endpoints". =


In other words, compatibility with "multicast distribution =
scenario" doesn't necessarily avoid PS1 and PS6.

Thank you =
and best regards,
S=C3=A9rgio

On 11/19/2012 10:28 PM, h chan =
wrote: 
There are 3 proposals for multicast requirements. Before =
comparing these proposals, let us understand what are the problems =
first. Two problem statements have been proposed: 
 
PS1 (revised): Non-optimal routes 
Routing via a centralized anchor often results in a longer route. =
The problem is especially manifested when accessing a local server or =
servers of a Content Delivery Network (CDN), or when receiving / =
sending IP multicast packets. 
PS6: Duplicate multicast =
traffic 
IP multicast distribution over architectures using IP mobility =
solutions  may lead to convergence of duplicated multicast =
subscriptions towards the tunnel=E2=80=99s downstream entity (e.g. MAG =
in PMIPv6).  Concretely, when multicast subscription for individual =
mobile nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment [draft-sfigueiredo-multimob-use-case-dmm-03]. 
 
Then, let us see whether all the 3 REQ proposals have the same =
intention. In the following, I rephrase them to highlight their =
similarities. 
 
REQ7.1: Flexible multicast distribution 
DMM solutions should be compatible with flexible multicast =
distribution scenario. Etc. 
The Motivation is to allow flexibility =
in (enable) multicast solutions to solve the problems PS1 and PS6 as =
explained in use cases already presented and discussed in multimob =
wg. 
 
REQ7.2: 
DMM solutions should enable solutions to support =
multicast traffic. 
 
(Original wording was "The DMM (unicast) solution MUST be =
specified in such a way that it can be extended to also support =
multicast traffic." I rephrase it to highlight the similarity with =
the other proposals and also changed the must to should.) 
 
REQ7.3: 
DMM solutions should enable solutions to support multicast =
services. 
 
Original wording was =E2=80=9CDMM solutions should support =
multicast services =E2=80=A6 etc. Given that it is the scope of multimob =
and not dmm wg to provide the multicast solution, I think =
=E2=80=9Csupport=E2=80=9D here means =E2=80=9Cenable=E2=80=9D solutions =
to be developed (by multimob). 
 
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to =
enable multicast services. Yet the explanation in REQ7.1 seems to =
indicate not just to enable any one multicast solution but also needs =
the flexibility in multicast solution. Not all multicast solutions are =
the same. Some of them results in PS1 or PS6. 
 
Are there any are essential differences between: 
In REQ7.1, DMM solutions should be compatible with flexible =
multicast distribution scenario, etc. 
Versus 
DMM solutions should enable multicast services which are =
compatible with multicast distribution scenario, etc. 
 
H Anthony Chan 
 
From: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] On =
Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 =
AM
To: pierrick.sei=
te@orange.com
Cc: dmm@ietf.org=

Subject:=
 Re: [DMM] =
Multicast requirements 
 
Hi =
Pierrick, 
&n=
bsp;
I=E2=80=99=
ve many times thought about your question. I would say how effectively =
should we deploy/support multicast over distributed mobility rather than =
distributed mobile multicast. As a result, you can find this deployment =
use case and gap analysis at http://tools.=
ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented =
in multimob several times. 
&n=
bsp;
In =
unicast DMM, main innovation is to distribute the anchor function at =
many access routers from single core. Following architectural concept of =
DMM, flexible multicast distribution is one of multicast requirement =
resulted from the draft described above. 
 
REQ8: =
Flexible multicast distribution 
"DMM solutions SHOULD be =
compatible with flexible multicast distribution scenarios. This =
flexibility enables different IP multicast flows with respect to a =
mobile host to be managed (e.g., subscribed, received and/or =
transmitted) using multiple endpoints". 

Motivation: The =
motivation for this requirement is to enable flexibility in multicast =
distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP =
multicast traffic relative to a host via a single endpoint (e.g. regular =
or tunnel interface), which would lead to the problems described in PS1 =
and PS6. 
PS6: Duplicate multicast traffic 
IP multicast =
distribution over architectures using IP mobility solutions  may =
lead to convergence of duplicated multicast subscriptions towards the =
tunnel=E2=80=99s downstream entity (e.g. MAG in PMIPv6). =
 Concretely, when multicast subscription for individual mobile =
nodes is coupled with mobility tunnels, duplicate multicast =
subscription(s) is prone to be received through different upstream =
paths. This problem is potentially more severe in a distributed mobility =
environment =
[draft-sfigueiredo-multimob-use-case-dmm-03].



Regards,<=
/span> 
&n=
bsp;
Seil 
&n=
bsp;
From: pierrick.sei=
te@orange.com [mailto:pierr=
ick.seite@orange.com] =

Sent: Monday, November 19, 2012 8:55 AM
To: =
'karagian@cs.=
utwente.nl'; =
seiljeon@av.=
it.pt; JuanCarlos.Z=
uniga@InterDigital.com
Cc: dmm@ietf.org=

Subject:=
 RE: [DMM] =
Multicast requirements 
 
Hi all, 
 
I tend to agree with Georgious, however I still do not figure out =
what is the use-case for distributed mobile multicast (other than =
academic considerations)? Can someone give concrete example? =

 
I haven=E2=80=99t real all messages from this thread. So, maybe I =
missed important points. 
 
BR, 
Pierrick 
 
De =
: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] De la =
part de karagian@cs.=
utwente.nl
Envoy=C3=
=A9 : samedi 17 =
novembre 2012 13:01
=C3=80 : seiljeon@av.=
it.pt; JuanCarlos.Z=
uniga@InterDigital.com
Cc =
: dmm@ietf.org=

Objet =
: Re: [DMM] =
Multicast requirements 
 
Hi =
all, 
&=
nbsp;
I also =
agree that the DMM solution should somehow consider muticast deployment. =
However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution! 
&=
nbsp;
One =
alternative solution will be to have a multicast requirement that =
emphasizes the need of having extensibility hooks (possibilities) that =
can be used later on by the multimob WG to provide a 
a multicast =
enabled DMM solution! 
&=
nbsp;
&=
nbsp;
So a =
requirement that specifies something like the following could be used =
for this purpose: 
&=
nbsp;
"Th=
e DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic." 
&=
nbsp;
&=
nbsp;
Best =
regards, 
Georgios=
 
&=
nbsp;
&=
nbsp;
&=
nbsp; 

  


Van: dmm-bounces@=
ietf.org [dmm-bounces@=
ietf.org] namens =
Seil Jeon [seiljeon@av.=
it.pt]
Verz=
onden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan =
Carlos'
Cc: dmm@ietf.org=

Onderwer=
p: Re: [DMM] =
Multicast requirements 
Hi =
Juan,

I've been looked at changed flow of your proposed text but =
sorry now that my
comment is posted.
At first time, I couldn't =
make sure however, on hearing Stig's description,
it seems quite =
reasonable at the first step, not giving any restrictions but
leaving =
some-specific for the DMM solution it does not support =
multicast.

On the other hand, it remains at a basic stage for the =
DMM solution to
support multicast.
So I think additional =
requirements need to be made for the DMM solution,
accordingly. But =
of course, this should not also give any specific
limitation and =
restriction but should be made towards the direction not
limiting the =
benefits provided by distributed deployment.

I hope to get more =
comments on this.

Regards,

Seil


-----Original =
Message-----
From: dmm-bounces@=
ietf.org [mailto:dmm-b=
ounces@ietf.org] On Behalf =
Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 =
PM
To: Stig Venaas; dmm@ietf.org=

Subject:=
 Re: [DMM] Multicast requirements


> -----Original =
Message-----
> From: Stig Venaas [mailto:stig@=
venaas.com]
> =
Sent: Friday, November 16, 2012 3:01 PM
> To: jouni =
korhonen
> Cc: sarikaya@iee=
e.org; Zuniga, =
Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann; dmm@ietf.org=

> =
Subject: Re: [DMM] Multicast requirements
> 
> On 11/15/2012 =
3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, =
2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> =
>>
> >> I think we are reading too much into multicast =
and unicast should
be
> >> designed in an integrated =
manner.
> >>
> >> The fact is that multicast is =
considered as an area of
> specialization,
> >> it =
requires knowledge of very different protocols than we are 
> =
>> accustomed to in mobility.
> >
> > =
"Requirement: DMM solutions SHOULD support multicast services. If =
a
> specific DMM solution does not support multicast services, an =

> explanation MUST be provided."
> 
> This =
sounds good to me.
> 
> The main thing I want to achieve is =
what was describes as motivation 
> earlier in this thread. =
Multicast should at least be considered when 
> looking into DMM =
solutions, and not just an afterthought once the 
> solution is =
decided.
> 
> Stig

[JCZ] I fully agree with this. =
That was the intention of the proposed text.

Regards,

Juan =
Carlos

> 
> > To me that reads basically "do not =
break foundations for multicast
> unless you have a valid & =
documented reason for it".  If we look e.g.
> into =
RFC625 multicast wording that is there very briefly but gives a 
> =
hint to a developer where to head to. That is the level I would expect =

> DMM documents should aim to.
> >
> > - =
Jouni
> >
> >
> >> Let dmm deal with its =
current charter that does not include a word
> of
> >> =
multicast and if everything goes well we can come back and =
discuss
> dmm
> >> multicast.
> >>
> =
>> Regards,
> >>
> >> =
Behcet

_______________________________________________
dmm =
mailing list
dmm@ietf.org=

https://www.=
ietf.org/mailman/listinfo/dmm

____=
___________________________________________
dmm mailing =
list
dmm@ietf.org=

https://www.=
ietf.org/mailman/listinfo/dmm 
_______________________________________________________________=
__________________________________________________________ 
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc 
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler 
a l'expediteur =
et le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration, 
France Telecom =
- Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci. 
 
This message =
and its attachments may contain confidential or privileged information =
that may be protected by law; 
they should not =
be distributed, used or copied without authorisation. 
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments. 
As emails may =
be altered, France Telecom - Orange is not liable for messages that have =
been modified, changed or falsified. 
Thank =
you. 




_______________________________________________ 
dmm mailing =
list 
dmm@ietf.org 
https://www.ietf.org/mailman/listinfo/dmm 
  =

  
 

Este mensaje se dirige exclusivamente a su destinatario. Puede =
consultar nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo =
electr=C3=B3nico en el enlace situado m=C3=A1s abajo.
This message is =
intended exclusively for its addressee. We only send and receive email =
on the basis of the terms set out at:
http://www.tid=
.es/ES/PAGINAS/disclaimer.aspx


_______________________________________________
dmm mailing =
list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing =
list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm 
  =


------=_NextPart_000_0060_01CDCBEF.A0F3B1C0--


From sarikaya2012@gmail.com  Mon Nov 26 12:19:43 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C6D21F8524 for ; Mon, 26 Nov 2012 12:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM9gqD1gfNAK for ; Mon, 26 Nov 2012 12:19:42 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A60CC21F851B for ; Mon, 26 Nov 2012 12:19:42 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id c13so10426129ieb.31 for ; Mon, 26 Nov 2012 12:19:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=GXvEmHs79no9cU72SEtS6uvuVZr84I8CrNb/ClARBVs=; b=AZY/Q0YO4YsWWUgkJ798fbOKsmT6EZtUIz6I3LatrMwTiyVhTrs4Sd8YIsM675wAfP 7zQxt9cSixzD7JQrxEePs/CkF2g1Anlz6gdsSTIGs2Wo+EHwL/zhg9f3PS+PQKiun0BJ Tqb4m3vWDL/ZVnOiFAg5AMOMOKB9aeyb3iD6NorkM6V5okABI37btHHIFv6uvom9MHLh 2RLETxlFzJkWSEHjEE8ulc1khRBRayh2BFWay1C5Lt2TQa1HWMwES4PjRooFxVi2q9y3 4aB4gVoXQLjYVQxpa2H6gnIdY53xcewXLEeK9lTJeN7agK1uTD8upryklEDtrjbCT6gO pN6w==
MIME-Version: 1.0
Received: by 10.50.104.232 with SMTP id gh8mr15997623igb.45.1353961182224; Mon, 26 Nov 2012 12:19:42 -0800 (PST)
Received: by 10.231.10.204 with HTTP; Mon, 26 Nov 2012 12:19:42 -0800 (PST)
Date: Mon, 26 Nov 2012 14:19:42 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Brian Haberman 
Content-Type: text/plain; charset=ISO-8859-1
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on virtual network mm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Nov 2012 20:19:43 -0000

Hi Brian,

You are absolutely right.

I have to correct what I mean.

I think the term cloud is very confusing.
So I suggest not using cmm from now on.

What I mean is virtual network mobility management.
 So myself and some other colleagues are suggesting to also work on
virtual network mobility management issues.

I think that this is well within IETF scope as there are working
groups such as nvo3 working on virtual network issues.

Apologies for the confusion.

Regards,

Behcet

On Mon, Nov 19, 2012 at 1:53 PM, Brian Haberman
 wrote:
> Behcet,
>
>
> On 11/19/12 12:25 PM, Behcet Sarikaya wrote:
>>
>> Hi all,
>>
>> Here is the requirement I have in mind:
>>
>> The DMM solution SHOULD support more than one cloud network belonging
>> to the same DMM domain.
>>
>> Two points:
>>
>> The above requirement does have protocol impact.
>
>
> Could you elaborate on what that impact would be?
>
> It is unclear to me what the impact of using a cloud service would be. The
> IETF has not had to change other protocols in order to have them work within
> "the cloud".
>
> Regards,
> Brian
>
>
>>
>> Second point: I also support Georgios' requirement as a base. We can
>> work on both and make it better.
>>
>> Regards,
>>
>> Behcet
>>
>> On Sat, Nov 17, 2012 at 6:28 AM,   wrote:
>>>
>>> Hi Behcet, Hi all,
>>>
>>>
>>>
>>> Regarding the cloud like architecture use case, the requirement that
>>> could
>>> be used for this purpose can be the following one:
>>>
>>>
>>>
>>> "The DMM solution MAY have the ability to be applied in virtualized
>>> and/or
>>> cloud like archietctures."
>>>
>>>
>>>
>>> Motivation:
>>>
>>>
>>>
>>> Currently, there is a trend to implement more and more functions of a
>>> mobile
>>> communication network in software, e.g., for signal and protocol
>>> processing.
>>> This enables the use of cloud computing infrastructures as processing
>>> platforms for signal and protocol processing of mobile communication
>>> networks, in particular for current (4G) and future (5G) generation
>>> cellular
>>> networks. This can only be realized if, among others, efficient DMM
>>> solutions are supported by the cloud computing architectures.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Georgios
>>>
>>> ________________________________
>>> Van: Behcet Sarikaya [sarikaya2012@gmail.com]
>>> Verzonden: vrijdag 16 november 2012 22:20
>>> To: Karagiannis, G. (EWI)
>>> Cc: dmm@ietf.org
>>> Onderwerp: Requirements on cmm
>>>
>>> Hi Georgios,
>>>
>>> Can you please suggest some requirements on cmm in DMM?
>>>
>>> I think that it would be relevant and useful to DMM while requirements
>>> are still being discussed.
>>>
>>> Regards,
>>>
>>> Behcet
>>> On Sun, Nov 4, 2012 at 1:52 PM,   wrote:
>>>>
>>>> Hi Behcet,
>>>>
>>>> I would like to mention that I find this draft useful due to the
>>>> following
>>>> reasons.
>>>>
>>>> Currently, there is a trend to implement more and more functions of a
>>>> mobile communication network in software, e.g., for signal and protocol
>>>> processing. This enables the use of cloud computing infrastructures as
>>>> processing platforms for signal and protocol processing of mobile
>>>> communication networks, in particular for current (4G) and future (5G)
>>>> generation cellular networks.
>>>> This can of course only be realized if, among others, efficient mobility
>>>> management solutions are supported like the ones that are in line with
>>>> what
>>>> DMM would like to specify.
>>>> I think therefore, that the DMM WG could also consider the distributed
>>>> mobility management support in cloud computing like architectures as a
>>>> possible use case.
>>>>
>>>> Regarding your draft I have some comments:
>>>> The draft mentions some limitation of the existing mobility management
>>>> solutions in cloud-like architectures. However, these limitations are
>>>> not
>>>> clearly focussing on the requirements specified in
>>>> http://www.ietf.org/id/draft-ietf-dmm-requirements-02.txt.
>>>> I think that this will make the desciption of the limitations clearer!
>>>> Moreover, it might also be useful to show describe these limitations by
>>>> using as use as context a generic framework, like the one introduced in
>>>> http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt
>>>> and/or
>>>> http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.
>>>>
>>>> Best regards,
>>>> Georgios
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________________
>>>> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Behcet Sarikaya
>>>> [sarikaya2012@gmail.com]
>>>> Verzonden: dinsdag 23 oktober 2012 21:51
>>>> To: dmm@ietf.org
>>>> Onderwerp: [DMM] New Version Notification for
>>>> draft-sarikaya-dmm-cloud-mm-00.txt
>>>>
>>>> Hi all,
>>>>
>>>> I have submitted a new draft on Mobility Management Protocols for
>>>> Cloud-Like Architectures, for details see below.
>>>>
>>>> Chairs: please reserve a slot in IETF 85 session if possible.
>>>>
>>>> Regards,
>>>>
>>>> Behcet
>>>>
>>>> A new version of I-D, draft-sarikaya-dmm-cloud-mm-00.txt
>>>> has been successfully submitted by Behcet Sarikaya and posted to the
>>>> IETF repository.
>>>>
>>>> Filename:        draft-sarikaya-dmm-cloud-mm
>>>> Revision:        00
>>>> Title:           Mobility Management Protocols for Cloud-Like
>>>> Architectures
>>>> Creation date:   2012-10-15
>>>> WG ID:           Individual Submission
>>>> Number of pages: 11
>>>> URL:
>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-cloud-mm-00.txt
>>>> Status:
>>>> http://datatracker.ietf.org/doc/draft-sarikaya-dmm-cloud-mm
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-sarikaya-dmm-cloud-mm-00
>>>>
>>>>
>>>> Abstract:
>>>>     Telecommunication networks are being virtualized and are moving into
>>>>     the cloud networks.  This brings the need to redesign the mobility
>>>>     protocols of Mobile and Proxy Mobile IPv6.  This document defines
>>>>     mobility management protocols for virtualized networks.  Control and
>>>>     data plane separation is achieved by separating Home Agent and
>>>> Mobile
>>>>     Access Gateway functionalities into the control and data planes.
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>> _______________________________________________
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

From h.anthony.chan@huawei.com  Mon Nov 26 14:23:11 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9489521F853C for ; Mon, 26 Nov 2012 14:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujvs8ypKNimU for ; Mon, 26 Nov 2012 14:23:11 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1F521F8531 for ; Mon, 26 Nov 2012 14:23:10 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALX86366; Mon, 26 Nov 2012 22:23:09 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Nov 2012 22:23:03 +0000
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Nov 2012 22:23:07 +0000
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.162]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Tue, 27 Nov 2012 06:23:02 +0800
From: h chan 
To: Alexandru Petrescu 
Thread-Topic: [DMM] Comment on Req2 transparency for DMM
Thread-Index: AQHNvb4AR9veurc7ykm59ZWJvZy8m5f8zEhA
Date: Mon, 26 Nov 2012 22:23:01 +0000
Message-ID: <6E31144C030982429702B11D6746B98C364994EA@SZXEML510-MBX.china.huawei.com>
References: <501867A9.8060007@gmail.com> <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> <501AC93A.5000100@gmail.com> <6E31144C030982429702B11D6746B98C270D08FA@SZXEML505-MBS.china.huawei.com> <509BC28A.8030909@gmail.com>
In-Reply-To: <509BC28A.8030909@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.198]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Comment on Req2 transparency for DMM
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Nov 2012 22:23:11 -0000

Alex,

Thanks. How about the following change:

REQ2:  Transparency to Upper Layers when needed
DMM solutions MUST provide transparent mobility support above the IP layer =
when needed.  Such transparency is needed, for example, when, upon change o=
f point of attachment to the Internet, an application flow cannot cope with=
 a change in the IP address. However, it is not always necessary to maintai=
n a stable home IP address or prefix during handovers.

H Anthony Chan


-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20
Sent: Thursday, November 08, 2012 8:33 AM
To: h chan
Cc: dmm@ietf.org
Subject: Re: [DMM] Comment on Req2 transparency for DMM

Hello Antony,

Thanks for the good work.  You just said this is our last chance to
suggest change so here is my last try.

Currently in draft-ietf-dmm-requirements-02 this Req2 Transparency reads:

> REQ2:  Transparency to Upper Layers when needed
>
> DMM solutions MUST provide transparent mobility support above the IP
>  layer when needed.  Such transparency is needed, for example, when,
>  upon change of point of attachment to the Internet, an application
> flow cannot cope with a change in the IP address.  Otherwise, support
> for maintaining a stable home IP address or prefix during handovers
> may be declined.

This last 'declined' sounds IMHO as if this 'support' were requested in
the first place.  But this request assumes maybe a solution is in place
(like Mobile IP or so).  I'd rather use the word 'impossible', instead
of 'declined', and 'is' instead of 'may be'.

> Motivation: The motivation of this requirement is to enable more
> efficient use of network resources and more efficient routing by not
>  maintaining context at the mobility anchor when there is no such
> need.

I agree with the motivation, although it sounds just a bit strange to
me.  Maybe it is strange to me because I myself assume Mobile IP :-)

Maybe another motivation is like this: "it is hardly feasible to modify
all applications deployed (see the large number of applications in the
Deering's hourglass model [xx]) such that to support change in IP
address or prefix above IP layer without restarting the applications
during an ongoing flow (e.g. audio call).  This motivates to propose
changes at a single point which is the IP layer instead (the waist of
the hourglass)."

Thanks,

Alex

Le 03/08/2012 19:07, h chan a =E9crit :
> How about the following:
>
> The DMM solutions MUST provide transparency above the IP layer when
> needed. Such transparency is needed, for example, upon change of
> point of attachment to the Internet for the application flows that
> cannot cope with a change of IP address. Otherwise the support to
> maintain a stable home IP address or prefix during handover may be
> declined.
>
> Or
>
> The DMM solutions MUST enable transparency above the IP layer. Such
> transparency is needed, for example, upon change of point of
> attachment to the Internet for the application flows that cannot cope
> with a change of IP address. Otherwise the support to maintain a
> stable home IP address or prefix during handover may be declined.
>
> H Anthony Chan
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, August 02, 2012
> 11:39 AM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] Comment on
> Req2 transparency for DMM
>
> H Anthony,
>
> Yes, this reflects Sri's and my suggestion about removal of MN/MR
> qualifier.  I agree with the idea of the new text as you put it.
>
> Then, if I re-read just like that, there still seems to be some
> difficulty to my brain to understand:
>
> Le 01/08/2012 23:35, h chan a =E9crit :
>> The DMM solutions MUST provide transparency above the IP layer
>> when needed, such as upon change of point of attachment to the
>> Internet, for the application flows that cannot cope with a change
>> of IP address. Otherwise the support to maintain a stable home IP
>> address or prefix during handover may be declined.
>
> I don't understand the last phrase - the 'otherwise' relates to the
> first MUST?  Or to the latter 'cannot'?
>
> But this may be just nitpicking on the use of language.  I agree
> with the direction of the idea and thank you for having provided the
>  modification.
>
> Alex
>
>



From h.anthony.chan@huawei.com  Mon Nov 26 18:02:45 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7B721F8629 for ; Mon, 26 Nov 2012 18:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFHRhRfEiEUL for ; Mon, 26 Nov 2012 18:02:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1018321F8625 for ; Mon, 26 Nov 2012 18:02:39 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALX95520; Tue, 27 Nov 2012 02:02:38 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 02:02:29 +0000
Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 02:02:35 +0000
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.162]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.003; Tue, 27 Nov 2012 10:02:17 +0800
From: h chan 
To: jouni korhonen , Konstantinos Pentikousis 
Thread-Topic: [DMM] comments on draft-ietf-dmm-requirements-02
Thread-Index: AQHNwx/e964CyTnzz027SLYyL3w6AZf8+Ndw
Date: Tue, 27 Nov 2012 02:02:16 +0000
Message-ID: <6E31144C030982429702B11D6746B98C3649960E@SZXEML510-MBX.china.huawei.com>
References: <9A62768E-AE38-4F59-A032-33289653BF56@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23A4EE664@szxeml545-mbx.china.huawei.com> <1504_1352834428_50A29D7C_1504_11957_1_81C77F07008CA24F9783A98CFD706F7105D234@PEXCVZYM12.corporate.adroot.infra.ftgroup>  <8D38716F0C1A444BA0CD7E96454366C23A4EEB34@szxeml545-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.244]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2012 02:02:45 -0000

How about changing PS3 to the following:

Low scalability of centralized tunnel and mobility context maintenance

Setting up tunnels through a central anchor which maintains the mobility co=
ntext for each MN therein requires more resources at the centralized anchor=
, thus reducing scalability.=20
Distributing the routes and the mobility context maintenance function among=
 different networks can increase scalability.

The current text is:

Low scalability of centralized route and mobility context maintenance

Setting up routes through a central anchor and maintaining mobility context=
 for each MN therein requires more resources in a centralized design, thus =
reducing scalability.=20
Distributing the route maintenance function and the mobility context mainte=
nance function among different network entities can increase scalability.

H Anthony Chan


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of jouni=
 korhonen
Sent: Thursday, November 15, 2012 4:57 AM
To: Konstantinos Pentikousis
Cc: dmm@ietf.org
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02


Hi,

On Nov 14, 2012, at 8:28 PM, Konstantinos Pentikousis wrote:

>>  |  "PS3:  Low scalability of centralized route and mobility context
>>  |         maintenance"
>>  |
>>  | o Isn't e.g. the SDN evolution just doing to the opposite? Highly
>>  |    centralized management point for traffic steering? I would reconsi=
der
>>  |    PS3 unless we have more evidence that this is really an issue. Or
>>  |    then we need to point out something that makes it more context=20
>>  |    specific for DMM or mobility.
>>=20
>> Oh dear, should we discuss SDN scalability here? :)

>  |No (without smile). But that is another trend to opposite direction
>  |and we should have a sufficient argument for our assertion here imho. W=
hat
>  |is so fundamentally resource consuming in "mobility context" handling
>  |that it requires distribution? Is it just a combination of all
>  |functions in one place (that has little to do with mobility per se)?
>=20
> I think scalability here refers to the "hub-and-spoke" nature of the rout=
ing fabric as introduced by a "centralized" mobility anchor. You may have v=
alid technical and/or operational reasons for adopting a hub-and-spoke mode=
l, that's ok. But maybe others may want an alternative model which aims for=
 different optimalities, and for those the hub-and-spoke model is not, well=
, "scalable".
>=20
> SDN, well the OpenFlow flavor of it anyway, is "logically centralized" wr=
t network control, not how packets move around. SDN can do hub-and-spoke as=
 well as other routing fabrics. Information-centric networking, another maj=
or trend, is definitely not pointing towards the merits of the current type=
 of centralization... So I think PS3 is valid.

PS3 says "centralized route management".. I would be far more comfortable i=
f PS3 says "centralized tunnel management" which is more concretely what we=
 do today as per hub-and-spoke type tunneled traffic deployments.


- Jouni



>=20
> Best Regards,
>=20
> Kostas
>=20
>=20
>=20
>=20
>=20
>=20
>=20

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

From jouni.nospam@gmail.com  Tue Nov 27 01:00:32 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB0421F850A; Tue, 27 Nov 2012 01:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaE5a3gpgJr8; Tue, 27 Nov 2012 01:00:31 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68D21F84F9; Tue, 27 Nov 2012 01:00:24 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so10089020lbk.31 for ; Tue, 27 Nov 2012 01:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9AfpLNb2iPclqYRuDAWlOi7Lx55BMJ+cv2TIpdnDmVY=; b=z9MWheK+KZpYTXj8lowEveSdzgGnvtO3K86SWzz64TnsncnUbqNPM/olnttzUtgSmP p6ZCsFYbtGDbrM/SN5SvNSQrgfVtLbxnq/H+udlXj/hwUADgp4flBCSlwLOgn5CGfa9s fPHw3VDleauA3QgMJ5Y9x0ehkQrBePOWsvBnosI8al8R8D8C7ZXFSAxBDWq3QUSZlXFh dkYyEdAtnMdG9/muRgeRjfOV65IpcWd5lTyOlL+oRO15sQvJ47Sg5w8CKl2VtGGH8ZpN wqigVJ8APB/d90/ccpFS/CiejNh1x3OjMhj/x8ApdxgTEjgQfDJmWOwajkpykwnruuXF hKew==
Received: by 10.152.104.50 with SMTP id gb18mr14161359lab.9.1354006823128; Tue, 27 Nov 2012 01:00:23 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id p9sm6684670lbc.3.2012.11.27.01.00.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 01:00:19 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E66E4E@dfweml512-mbb.china.huawei.com>
Date: Tue, 27 Nov 2012 11:00:16 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <6362111E-CF9B-4E1A-AE02-A3296AD7D238@gmail.com>
References:  <5963DDF1F751474D8DEEFDCDBEE43AE716E587E9@dfweml512-mbx.china.huawei.com> <9892BC94-F495-405F-93E9-90A33DAF8C96@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E588CF@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E5890E@dfweml512-mbx.china.huawei.com> <4B2145DF-3D42-4EE4-A1F7-E3622F2A74D8@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E58955@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E58A92@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E58BDE@dfweml512-mbx.china.huawei.com> <88BBDF91-7A51-427A-BD3C-897B79C17781@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E65D8B@dfweml512-mbb.china.huawei.com> <60EF112E-92B4-45D2-90F3-AD64173E4BD4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E66E4E@dfweml 512-mbb.china.huawei.com>
To: Peter McCann 
X-Mailer: Apple Mail (2.1085)
Cc: "netext@ietf.org" , "dmm@ietf.org" , Basavaraj Patil , "draft-ietf-netext-pd-pmip@tools.ietf.org" 
Subject: Re: [DMM] [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2012 09:00:32 -0000

Pete,

On Nov 26, 2012, at 5:54 PM, Peter McCann wrote:

[budget cut scale removal of text]

>>> hop router, and traffic is always tunneled directly back to that
>>> router. In contrast, PMIP has the MAG as the first hop router.  This is
>>> a fundamental difference that IMHO makes it more likely to see a link
>>> flap on a MAG to MAG handover, even when the same LMA is reachable from
>>> both.
>> 
>> If the LMA stays the same, the link does not flap. 
> 
> I don't see how you can make a blanket statement like this for all
> link layers that might be used for PMIP.  In particular, it seems
> to require a knowledge, at the L2, of whether the current MAG can
> see the same LMA.  This knowledge needs to be propagated across the
> link to the client, and used to determine whether the link down/up
> event propagates through the IP stack.  Perhaps your particular 
> implementation experience involved carrying such a signal but I
> cannot imagine that it holds true for every L2, especially if they
> were not designed with PMIP in mind.

I am just reflecting the nature of existing point-to-point L2 
technologies. They tend to be session oriented, ref PPP and 3GPP
stuff. Even when a WLAN type of technology is twisted to resemble
point-to-point (and with authentication) you can make it session
aware.. with limitations. And if the whole user session is between
UE and the LMA, then any leg losing the session usually torn down
the whole pipe including your L2.

I am curious to learn what point-to-point L2 technologies you have
in mind? Something already on the field or on the drawing board?


[smaller cost cut scale removal of text]

>> I repeat what I said earlier. If the LMA changes the L2 session goes
>> down, prefixes may change etc. It is a bit more than just link up/down
>> because it also involves setting up a new PMIP session & L2 session. (on
>> L2 technologies I am concerned with).
> 
> You seem to be implying that the L2 technology has a notion of a PMIP
> session.  The layered protocol model would seem to discourage this,
> and I can imagine that many link layers are designed without PMIP
> in mind.

I do not have a PMIP aware L2 in mind. See above. Just a point-to-point L2
that has a notion of session itself i.e. one has to explicitly set it up and
it can be disconnected at will by either end.

[snip]

>>>> Assuming RFC6543 is not used and we do assign different link-locals,
>>>> then it is up to the LMA decide when to use which link-local. Two
>>>> examples: each LMA has its own or each PMIP session gets its own
>>>> "unique" link-local. Both cases have possibility of address collisions
>>>> but are quite unlikely. I do not really care about coverage areas
>>>> rather the case when something happened on the emulated home link and
>>>> for that case the two examples would be sufficient. Note that I am not
>>>> prompting such "solution".
>>> 
>>> Did you mean to say "up to the MAG"?  I am not sure I like the idea of
>>> the LMA controlling the MAG's link-local address.
>> 
>> No.. or lets say my wording was imprecise. Whether this feature is
>> enabled depends on the MAG configuration. If MAG allows the LMA to
>> generate the link-local, then LMA does it and MAG uses that address. In
>> that case the LMA decides when to use which link-local address.
> 
> It would still require coordination between the old LMA and the new
> LMA, precisely in those situations where no such coordination is possible
> (the PMIP domains are distinct and unconnected).

It is just a matter of will. OUIs are invented and EUI-64 is big hefty
number. Collision would be less probable than me winning in lottery.
However, this would probably be a task to some other SDO to arrange
than IETF.

[oh-snap]

>>> If the link down/up event has been hidden from the IP stack, then
>>> sitting there doing nothing is exactly what an RFC3315 compliant
>>> implementation would do.  Hence my use of MUST in (2) above.
>> 
>> Sure. Never claimed it to be different. But as said, I cannot control
>> the client side implementation. That is the point.
> 
> But you seem to be making assumptions about the L2 implementation 
> and that, in particular, it knows when a PMIP session is disconnected.

See my earlier notes on L2 sessions.

> I am sorry to be making a big deal about these issues.  I am raising
> them because I think it will be important to get these details right
> when it comes to the DMM solution.  There, I think we will have some

Figured that ;) 

> set of prefixes assigned to the MN at any given time, and some arbitrary
> subset will need to be deprecated and/or torn down proactively upon 
> each handover (change of MAG if a PMIP-style solution is used to 
> re-route the packets).  However, we can discuss more details on the
> DMM list if you prefer (and this may get us a bit into DMM solution
> space.  But, I am trying to think ahead).

Yep, I am familiar with this specific problem space. See e.g.
http://tools.ietf.org/html/draft-korhonen-dmm-local-prefix-00
for one solution approach. This, however, assumes the MN always
has at least on LMA that remains the same as long as the MN is
within the PMIP domain. But that was enough DMM for my needs ;)

Thinking ahead is more than welcome!

- Jouni




> 
> -Pete
> 
> 
>>> 


From Peter.McCann@huawei.com  Tue Nov 27 08:14:32 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72821F8639; Tue, 27 Nov 2012 08:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYSbEbl93+wQ; Tue, 27 Nov 2012 08:14:31 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA3D21F858B; Tue, 27 Nov 2012 08:14:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALY63721; Tue, 27 Nov 2012 16:14:29 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 16:14:02 +0000
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 16:14:09 +0000
Received: from dfweml512-mbx.china.huawei.com ([169.254.1.208]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 27 Nov 2012 08:14:03 -0800
From: Peter McCann 
To: jouni korhonen 
Thread-Topic: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
Thread-Index: AQHNxz3DQQQBC3W/sU+JRgVtIyAvCpfy7olggAC+hYD//3xY0IAAjCcA//97uoCAAJVJgP//ejdQABOHHoAABSeKoAAWNosAAAesqeAAJAylgAC4CjtwABlJU4AACu3TkAAfYuAAAAIsAXA=
Date: Tue, 27 Nov 2012 16:14:02 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E6DA55@dfweml512-mbx.china.huawei.com>
References:  <5963DDF1F751474D8DEEFDCDBEE43AE716E587E9@dfweml512-mbx.china.huawei.com> <9892BC94-F495-405F-93E9-90A33DAF8C96@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E588CF@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E5890E@dfweml512-mbx.china.huawei.com> <4B2145DF-3D42-4EE4-A1F7-E3622F2A74D8@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E58955@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E58A92@dfweml512-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE716E58BDE@dfweml512-mbx.china.huawei.com> <88BBDF91-7A51-427A-BD3C-897B79C17781@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E65D8B@dfweml512-mbb.china.huawei.com> <60EF112E-92B4-45D2-90F3-AD64173E4BD4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E66E4E@dfwem l512-mbb.china.huawei.com> <6362111E-CF9B-4E1A-AE02-A3296AD7D238@gmail.com>
In-Reply-To: <6362111E-CF9B-4E1A-AE02-A3296AD7D238@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.158]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "netext@ietf.org" , "dmm@ietf.org" , Basavaraj Patil , "draft-ietf-netext-pd-pmip@tools.ietf.org" 
Subject: Re: [DMM] [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2012 16:14:32 -0000

Hi, Jouni,

jouni korhonen wrote:
>=20
> Pete,
>=20
> On Nov 26, 2012, at 5:54 PM, Peter McCann wrote:
>=20
> [budget cut scale removal of text]
>=20
>>>> hop router, and traffic is always tunneled directly back to that
>>>> router. In contrast, PMIP has the MAG as the first hop router. This
>>>> is a fundamental difference that IMHO makes it more likely to see a
>>>> link flap on a MAG to MAG handover, even when the same LMA is
>>>> reachable from both.
>>>=20
>>> If the LMA stays the same, the link does not flap.
>>=20
>> I don't see how you can make a blanket statement like this for all
>> link layers that might be used for PMIP.  In particular, it seems
>> to require a knowledge, at the L2, of whether the current MAG can
>> see the same LMA.  This knowledge needs to be propagated across the
>> link to the client, and used to determine whether the link down/up
>> event propagates through the IP stack.  Perhaps your particular
>> implementation experience involved carrying such a signal but I
>> cannot imagine that it holds true for every L2, especially if they
>> were not designed with PMIP in mind.
>=20
> I am just reflecting the nature of existing point-to-point L2
> technologies. They tend to be session oriented, ref PPP and 3GPP
> stuff. Even when a WLAN type of technology is twisted to resemble
> point-to-point (and with authentication) you can make it session
> aware.. with limitations. And if the whole user session is between
> UE and the LMA, then any leg losing the session usually torn down
> the whole pipe including your L2.

My point is that L2 is torn down/rebuilt even when the LMA is=20
reachable and the PMIP session stays up.

> I am curious to learn what point-to-point L2 technologies you have
> in mind? Something already on the field or on the drawing board?

Take PPP as an example.  The PPP session would be between the=20
MN and the MAG.  There would clearly need to be a new LCP/IPCP
exchange between the MN and a new MAG, even if the new MAG could
get back to the same LMA.  In this case PPP experiences link down/
up but the PMIP session is preserved.

This is distinct from the 3GPP link layer where the p2p session
is between MN and PGW.  The PGW is the first hop router.

PMIP has the MAG as the first hop router.  When you disconnect
from one first hop router and connect to another first hop
router, the link flaps unless you have taken special measures
to hide this event from the IP stack.

> [smaller cost cut scale removal of text]
>=20
>>> I repeat what I said earlier. If the LMA changes the L2 session goes
>>> down, prefixes may change etc. It is a bit more than just link up/down
>>> because it also involves setting up a new PMIP session & L2 session.
>>> (on L2 technologies I am concerned with).
>>=20
>> You seem to be implying that the L2 technology has a notion of a PMIP
>> session.  The layered protocol model would seem to discourage this,
>> and I can imagine that many link layers are designed without PMIP
>> in mind.
>=20
> I do not have a PMIP aware L2 in mind. See above. Just a point-to-point
> L2 that has a notion of session itself i.e. one has to explicitly set it
> up and it can be disconnected at will by either end.

But in PMIP the L2 is terminated between MN and MAG.  Change of MAG means
tearing down one L2 session and establishing a new one.  Hence it seems
more natural to me to experience a link flap than to go to the extra
effort to hide this from the IP stack in some special cases (which=20
involve the network topology behind the MAG, something that is usually
not visible to L2).

> [snip]
>=20
>>>>> Assuming RFC6543 is not used and we do assign different link-
>>>>> locals, then it is up to the LMA decide when to use which
>>>>> link-local. Two examples: each LMA has its own or each PMIP session
>>>>> gets its own "unique" link-local. Both cases have possibility of
>>>>> address collisions but are quite unlikely. I do not really care
>>>>> about coverage areas rather the case when something happened on the
>>>>> emulated home link and for that case the two examples would be
>>>>> sufficient. Note that I am not prompting such "solution".
>>>>=20
>>>> Did you mean to say "up to the MAG"?  I am not sure I like the idea
>>>> of the LMA controlling the MAG's link-local address.
>>>=20
>>> No.. or lets say my wording was imprecise. Whether this feature is
>>> enabled depends on the MAG configuration. If MAG allows the LMA to
>>> generate the link-local, then LMA does it and MAG uses that address.
>>> In that case the LMA decides when to use which link-local address.
>>=20
>> It would still require coordination between the old LMA and the new
>> LMA, precisely in those situations where no such coordination is
>> possible (the PMIP domains are distinct and unconnected).
>=20
> It is just a matter of will. OUIs are invented and EUI-64 is big hefty
> number. Collision would be less probable than me winning in lottery.
> However, this would probably be a task to some other SDO to arrange
> than IETF.

Sure, I agree this is possible.  But, it seems even more natural to
me to allow every MAG to have its own link-local address that is
globally unique.  I guess I am calling into question the assumption
that all MAGs in a PMIP domain have the same link-local address.
Perhaps that was a PMIP design mistake.  If the IP stack is going
to see a link flap anyway, we might as well deal with a proper change
of first-hop router (although that router might still advertise the
same prefix.  It is as if one router became unreachable but another
router pops up to take its place.  MNs should be able to handle this).

> [oh-snap]
>=20
>>>> If the link down/up event has been hidden from the IP stack, then
>>>> sitting there doing nothing is exactly what an RFC3315 compliant
>>>> implementation would do.  Hence my use of MUST in (2) above.
>>>=20
>>> Sure. Never claimed it to be different. But as said, I cannot control
>>> the client side implementation. That is the point.
>>=20
>> But you seem to be making assumptions about the L2 implementation
>> and that, in particular, it knows when a PMIP session is
> disconnected.
>=20
> See my earlier notes on L2 sessions.
>=20
>> I am sorry to be making a big deal about these issues.  I am raising
>> them because I think it will be important to get these details right
>> when it comes to the DMM solution.  There, I think we will have some
>=20
> Figured that ;)
>=20
>> set of prefixes assigned to the MN at any given time, and some
>> arbitrary subset will need to be deprecated and/or torn down
>> proactively upon each handover (change of MAG if a PMIP-style solution
>> is used to re-route the packets).  However, we can discuss more details
>> on the DMM list if you prefer (and this may get us a bit into DMM
>> solution space.  But, I am trying to think ahead).
>=20
> Yep, I am familiar with this specific problem space. See e.g.
> http://tools.ietf.org/html/draft-korhonen-dmm-local-prefix-00 for one
> solution approach. This, however, assumes the MN always has at least on
> LMA that remains the same as long as the MN is within the PMIP domain.
> But that was enough DMM for my needs ;)

Ok, just read your draft.  It raises the right issues, I think.  However,
I wonder if we could make it more general by decoupling the MN-visible
events like RAs and DHCP interaction and link flaps from the PMIP
protocol used to re-route packets and transfer context.
There are many ways to re-route packets and many ways to get the
context about the old prefixes from one AR to another AR.

Also, we should deal with cases where the old LMA is not reachable
and the DHCP server changes.

> Thinking ahead is more than welcome!

Good to hear.  Feel free to snip the netext mailing list from the
CC line when you think it's appropriate.

-Pete


From h.anthony.chan@huawei.com  Tue Nov 27 16:17:20 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEAA1F0C7F; Tue, 27 Nov 2012 16:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN8JQ6IToWXH; Tue, 27 Nov 2012 16:17:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E7A3D1F0C61; Tue, 27 Nov 2012 16:17:16 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANF86173; Wed, 28 Nov 2012 00:17:15 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 00:14:59 +0000
Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 08:15:06 +0800
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.162]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Wed, 28 Nov 2012 08:15:00 +0800
From: h chan 
To: "luo.wen@zte.com.cn" 
Thread-Topic: Re: [DMM] Multicast requirements
Thread-Index: AQHNyGAVd2rLH1NA5UuMxN/rIM/xHZf+aB9g
Date: Wed, 28 Nov 2012 00:15:00 +0000
Message-ID: <6E31144C030982429702B11D6746B98C364997B1@SZXEML510-MBX.china.huawei.com>
References: <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.78]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C364997B1SZXEML510MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm-bounces@ietf.org" , "dmm@ietf.org" 
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 00:17:20 -0000

--_000_6E31144C030982429702B11D6746B98C364997B1SZXEML510MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzLCBhbmQgSSBhbSB0cnlpbmcgdG8gY29udmVyZ2UgdGhlIGRpZmZlcmVudCBwcm9wb3Nh
bHMuDQpJIHRoaW5rIOKAnFRvIGNvbnNpZGVyIHRoZSBpbXBhY3Qgb2YgbXVsdGljYXN0IG9uIERN
TeKAnSBoYXMgdGhlIHNhbWUgaW50ZW50aW9uIGFzIOKAnHN0dWR5aW5nIHRoZSBwb3NzaWJsZSBw
ZXJmb3JtYW5jZSBwcm9ibGVtcyBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc28gdGhhdCB0aGUg
RE1NIHNvbHV0aW9ucyB3aWxsIGVuYWJsZSBtdWx0aWNhc3Qgc29sdXRpb25zIHRoYXQgd2lsbCBh
dm9pZCB0aG9zZSBwcm9ibGVtcy7igJ0NCg0KSCBBbnRob255IENoYW4NCg0KRnJvbTogbHVvLndl
bkB6dGUuY29tLmNuIFttYWlsdG86bHVvLndlbkB6dGUuY29tLmNuXQ0KU2VudDogV2VkbmVzZGF5
LCBOb3ZlbWJlciAyMSwgMjAxMiA5OjE4IFBNDQpUbzogaCBjaGFuDQpDYzogZG1tQGlldGYub3Jn
OyBkbW0tYm91bmNlc0BpZXRmLm9yZzsgcGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbTsgU2VpbCBK
ZW9uDQpTdWJqZWN0OiDnrZTlpI06IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRzDQoN
Cg0KSGkgQW50aG9ueSwNCg0KVGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gQW5kIEkgdGhpbmsgdGhl
IG1vdGl2YXRpb24gc2hvdWxkIGJlIGFsc28gaW5jbHVkZWQuIFRvIG1lLCB0aGUgdGV4dCBmcm9t
IEp1YW5DYXJsb3MgaXMgcmVzYW9uYWJsZQ0KDQo+IE1vdGl2YXRpb246IFRoZSBwdXJwb3NlIG9m
IHRoaXMgcmVxdWlyZW1lbnQgaXMgdG8gZW5jb3VyYWdlIHBlb3BsZSB0bw0KPiAgICAgICAgIGNv
bnNpZGVyIHRoZSBpbXBhY3RzIG9mIHJ1bm5pbmcgbXVsdGljYXN0IHNlcnZpY2VzIGluIGEgRE1N
DQo+ZW52aXJvbm1lbnQNCu+8niAgICAgICAgICBmcm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGRl
dmVsb3BtZW50LCB0aGVyZWJ5IGF2b2lkaW5nIHRoZQ0K77ye44CAbmVlZCB0bw0K77yeICAgICAg
ICAgbWFrZSBwcm90b2NvbCBleHRlbnNpb25zIGluIHRoZSBmdXR1cmUgdG8gc3VwcG9ydCB0aGlz
IGtpbmQgb2YNCu+8niAgICAgICAgIGZ1bmN0aW9uYWxpdHkuDQoNClRoYW5rcw0KTHVvd2VuDQoN
Cg0KaCBjaGFuIDxoLmFudGhvbnkuY2hhbkBodWF3ZWkuY29tPg0K5Y+R5Lu25Lq6OiAgZG1tLWJv
dW5jZXNAaWV0Zi5vcmcNCg0KMjAxMi8xMS8yMCAwNjoyOA0KDQrmlLbku7bkuroNCg0KU2VpbCBK
ZW9uIDxzZWlsamVvbkBhdi5pdC5wdD4sICJwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tIiA8cGll
cnJpY2suc2VpdGVAb3JhbmdlLmNvbT4NCg0K5oqE6YCBDQoNCiJkbW1AaWV0Zi5vcmciIDxkbW1A
aWV0Zi5vcmc+DQoNCuS4u+mimA0KDQpSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50cw0K
DQoNCg0KDQoNCg0KDQpUaGVyZSBhcmUgMyBwcm9wb3NhbHMgZm9yIG11bHRpY2FzdCByZXF1aXJl
bWVudHMuIEJlZm9yZSBjb21wYXJpbmcgdGhlc2UgcHJvcG9zYWxzLCBsZXQgdXMgdW5kZXJzdGFu
ZCB3aGF0IGFyZSB0aGUgcHJvYmxlbXMgZmlyc3QuIFR3byBwcm9ibGVtIHN0YXRlbWVudHMgaGF2
ZSBiZWVuIHByb3Bvc2VkOg0KDQpQUzEgKHJldmlzZWQpOiBOb24tb3B0aW1hbCByb3V0ZXMNClJv
dXRpbmcgdmlhIGEgY2VudHJhbGl6ZWQgYW5jaG9yIG9mdGVuIHJlc3VsdHMgaW4gYSBsb25nZXIg
cm91dGUuIFRoZSBwcm9ibGVtIGlzIGVzcGVjaWFsbHkgbWFuaWZlc3RlZCB3aGVuIGFjY2Vzc2lu
ZyBhIGxvY2FsIHNlcnZlciBvciBzZXJ2ZXJzIG9mIGEgQ29udGVudCBEZWxpdmVyeSBOZXR3b3Jr
IChDRE4pLCBvciB3aGVuIHJlY2VpdmluZyAvIHNlbmRpbmcgSVAgbXVsdGljYXN0IHBhY2tldHMu
DQpQUzY6IER1cGxpY2F0ZSBtdWx0aWNhc3QgdHJhZmZpYw0KSVAgbXVsdGljYXN0IGRpc3RyaWJ1
dGlvbiBvdmVyIGFyY2hpdGVjdHVyZXMgdXNpbmcgSVAgbW9iaWxpdHkgc29sdXRpb25zICBtYXkg
bGVhZCB0byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBzdWJzY3JpcHRpb25z
IHRvd2FyZHMgdGhlIHR1bm5lbOKAmXMgZG93bnN0cmVhbSBlbnRpdHkgKGUuZy4gTUFHIGluIFBN
SVB2NikuICBDb25jcmV0ZWx5LCB3aGVuIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGluZGl2
aWR1YWwgbW9iaWxlIG5vZGVzIGlzIGNvdXBsZWQgd2l0aCBtb2JpbGl0eSB0dW5uZWxzLCBkdXBs
aWNhdGUgbXVsdGljYXN0IHN1YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSByZWNlaXZlZCB0
aHJvdWdoIGRpZmZlcmVudCB1cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlh
bGx5IG1vcmUgc2V2ZXJlIGluIGEgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgZW52aXJvbm1lbnQgW2Ry
YWZ0LXNmaWd1ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wM10uDQoNClRoZW4sIGxldCB1
cyBzZWUgd2hldGhlciBhbGwgdGhlIDMgUkVRIHByb3Bvc2FscyBoYXZlIHRoZSBzYW1lIGludGVu
dGlvbi4gSW4gdGhlIGZvbGxvd2luZywgSSByZXBocmFzZSB0aGVtIHRvIGhpZ2hsaWdodCB0aGVp
ciBzaW1pbGFyaXRpZXMuDQoNClJFUTcuMTogRmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlv
bg0KRE1NIHNvbHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxlIG11bHRp
Y2FzdCBkaXN0cmlidXRpb24gc2NlbmFyaW8uIEV0Yy4NClRoZSBNb3RpdmF0aW9uIGlzIHRvIGFs
bG93IGZsZXhpYmlsaXR5IGluIChlbmFibGUpIG11bHRpY2FzdCBzb2x1dGlvbnMgdG8gc29sdmUg
dGhlIHByb2JsZW1zIFBTMSBhbmQgUFM2IGFzIGV4cGxhaW5lZCBpbiB1c2UgY2FzZXMgYWxyZWFk
eSBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCBpbiBtdWx0aW1vYiB3Zy4NCg0KUkVRNy4yOg0KRE1N
IHNvbHV0aW9ucyBzaG91bGQgZW5hYmxlIHNvbHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCB0
cmFmZmljLg0KDQooT3JpZ2luYWwgd29yZGluZyB3YXMgIlRoZSBETU0gKHVuaWNhc3QpIHNvbHV0
aW9uIE1VU1QgYmUgc3BlY2lmaWVkIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgZXh0ZW5k
ZWQgdG8gYWxzbyBzdXBwb3J0IG11bHRpY2FzdCB0cmFmZmljLiIgSSByZXBocmFzZSBpdCB0byBo
aWdobGlnaHQgdGhlIHNpbWlsYXJpdHkgd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxzIGFuZCBhbHNv
IGNoYW5nZWQgdGhlIG11c3QgdG8gc2hvdWxkLikNCg0KUkVRNy4zOg0KRE1NIHNvbHV0aW9ucyBz
aG91bGQgZW5hYmxlIHNvbHV0aW9ucyB0byBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcy4NCg0K
T3JpZ2luYWwgd29yZGluZyB3YXMg4oCcRE1NIHNvbHV0aW9ucyBzaG91bGQgc3VwcG9ydCBtdWx0
aWNhc3Qgc2VydmljZXMg4oCmIGV0Yy4gR2l2ZW4gdGhhdCBpdCBpcyB0aGUgc2NvcGUgb2YgbXVs
dGltb2IgYW5kIG5vdCBkbW0gd2cgdG8gcHJvdmlkZSB0aGUgbXVsdGljYXN0IHNvbHV0aW9uLCBJ
IHRoaW5rIOKAnHN1cHBvcnTigJ0gaGVyZSBtZWFucyDigJxlbmFibGXigJ0gc29sdXRpb25zIHRv
IGJlIGRldmVsb3BlZCAoYnkgbXVsdGltb2IpLg0KDQpTaW1pbGFyaXR5IGFuZCBzdWJ0bGUgZGlm
ZmVyZW5jZXM6IEJvdGggUkVRNy4yIGFuZCBSRVE3LjMgd2FudCB0byBlbmFibGUgbXVsdGljYXN0
IHNlcnZpY2VzLiBZZXQgdGhlIGV4cGxhbmF0aW9uIGluIFJFUTcuMSBzZWVtcyB0byBpbmRpY2F0
ZSBub3QganVzdCB0byBlbmFibGUgYW55IG9uZSBtdWx0aWNhc3Qgc29sdXRpb24gYnV0IGFsc28g
bmVlZHMgdGhlIGZsZXhpYmlsaXR5IGluIG11bHRpY2FzdCBzb2x1dGlvbi4gTm90IGFsbCBtdWx0
aWNhc3Qgc29sdXRpb25zIGFyZSB0aGUgc2FtZS4gU29tZSBvZiB0aGVtIHJlc3VsdHMgaW4gUFMx
IG9yIFBTNi4NCg0KQXJlIHRoZXJlIGFueSBhcmUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdl
ZW46DQpJbiBSRVE3LjEsIERNTSBzb2x1dGlvbnMgc2hvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBm
bGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvLCBldGMuDQpWZXJzdXMNCkRN
TSBzb2x1dGlvbnMgc2hvdWxkIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMgd2hpY2ggYXJlIGNv
bXBhdGlibGUgd2l0aCBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlvLCBldGMuDQoNCkgg
QW50aG9ueSBDaGFuDQoNCkZyb206IGRtbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZG1tLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTZWlsIEplb24NClNlbnQ6IE1vbmRheSwgTm92
ZW1iZXIgMTksIDIwMTIgNToxNSBBTQ0KVG86IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20NCkNj
OiBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1lbnRz
DQoNCkhpIFBpZXJyaWNrLA0KDQpJ4oCZdmUgbWFueSB0aW1lcyB0aG91Z2h0IGFib3V0IHlvdXIg
cXVlc3Rpb24uIEkgd291bGQgc2F5IGhvdyBlZmZlY3RpdmVseSBzaG91bGQgd2UgZGVwbG95L3N1
cHBvcnQgbXVsdGljYXN0IG92ZXIgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgcmF0aGVyIHRoYW4gZGlz
dHJpYnV0ZWQgbW9iaWxlIG11bHRpY2FzdC4gQXMgYSByZXN1bHQsIHlvdSBjYW4gZmluZCB0aGlz
IGRlcGxveW1lbnQgdXNlIGNhc2UgYW5kIGdhcCBhbmFseXNpcyBhdCBodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDMgcHJl
c2VudGVkIGluIG11bHRpbW9iIHNldmVyYWwgdGltZXMuDQoNCkluIHVuaWNhc3QgRE1NLCBtYWlu
IGlubm92YXRpb24gaXMgdG8gZGlzdHJpYnV0ZSB0aGUgYW5jaG9yIGZ1bmN0aW9uIGF0IG1hbnkg
YWNjZXNzIHJvdXRlcnMgZnJvbSBzaW5nbGUgY29yZS4gRm9sbG93aW5nIGFyY2hpdGVjdHVyYWwg
Y29uY2VwdCBvZiBETU0sIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24gaXMgb25lIG9m
IG11bHRpY2FzdCByZXF1aXJlbWVudCByZXN1bHRlZCBmcm9tIHRoZSBkcmFmdCBkZXNjcmliZWQg
YWJvdmUuDQoNClJFUTg6IEZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb24NCiJETU0gc29s
dXRpb25zIFNIT1VMRCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3Ry
aWJ1dGlvbiBzY2VuYXJpb3MuIFRoaXMgZmxleGliaWxpdHkgZW5hYmxlcyBkaWZmZXJlbnQgSVAg
bXVsdGljYXN0IGZsb3dzIHdpdGggcmVzcGVjdCB0byBhIG1vYmlsZSBob3N0IHRvIGJlIG1hbmFn
ZWQgKGUuZy4sIHN1YnNjcmliZWQsIHJlY2VpdmVkIGFuZC9vciB0cmFuc21pdHRlZCkgdXNpbmcg
bXVsdGlwbGUgZW5kcG9pbnRzIi4NCg0KTW90aXZhdGlvbjogVGhlIG1vdGl2YXRpb24gZm9yIHRo
aXMgcmVxdWlyZW1lbnQgaXMgdG8gZW5hYmxlIGZsZXhpYmlsaXR5IGluIG11bHRpY2FzdCBkaXN0
cmlidXRpb24uIFRoZSBtdWx0aWNhc3Qgc29sdXRpb24gbWF5IHRoZXJlZm9yZSBhdm9pZCBoYXZp
bmcgbXVsdGljYXN0LWNhcGFibGUgYWNjZXNzIHJvdXRlcnMgYmVpbmcgcmVzdHJpY3RlZCB0byBt
YW5hZ2UgYWxsIElQIG11bHRpY2FzdCB0cmFmZmljIHJlbGF0aXZlIHRvIGEgaG9zdCB2aWEgYSBz
aW5nbGUgZW5kcG9pbnQgKGUuZy4gcmVndWxhciBvciB0dW5uZWwgaW50ZXJmYWNlKSwgd2hpY2gg
d291bGQgbGVhZCB0byB0aGUgcHJvYmxlbXMgZGVzY3JpYmVkIGluIFBTMSBhbmQgUFM2Lg0KUFM2
OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRyYWZmaWMNCklQIG11bHRpY2FzdCBkaXN0cmlidXRpb24g
b3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9ucyAgbWF5IGxlYWQg
dG8gY29udmVyZ2VuY2Ugb2YgZHVwbGljYXRlZCBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9ucyB0b3dh
cmRzIHRoZSB0dW5uZWzigJlzIGRvd25zdHJlYW0gZW50aXR5IChlLmcuIE1BRyBpbiBQTUlQdjYp
LiAgQ29uY3JldGVseSwgd2hlbiBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uIGZvciBpbmRpdmlkdWFs
IG1vYmlsZSBub2RlcyBpcyBjb3VwbGVkIHdpdGggbW9iaWxpdHkgdHVubmVscywgZHVwbGljYXRl
IG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJvbmUgdG8gYmUgcmVjZWl2ZWQgdGhyb3Vn
aCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMgcHJvYmxlbSBpcyBwb3RlbnRpYWxseSBt
b3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IGVudmlyb25tZW50IFtkcmFmdC1z
ZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0tMDNdLg0KDQpSZWdhcmRzLA0KDQpTZWls
DQoNCkZyb206IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20gW21haWx0bzpwaWVycmljay5zZWl0
ZUBvcmFuZ2UuY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxMiA4OjU1IEFNDQpU
bzogJ2thcmFnaWFuQGNzLnV0d2VudGUubmwnOyBzZWlsamVvbkBhdi5pdC5wdDsgSnVhbkNhcmxv
cy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbQ0KQ2M6IGRtbUBpZXRmLm9yZw0KU3ViamVjdDogUkU6
IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMNCg0KSGkgYWxsLA0KDQpJIHRlbmQgdG8gYWdy
ZWUgd2l0aCBHZW9yZ2lvdXMsIGhvd2V2ZXIgSSBzdGlsbCBkbyBub3QgZmlndXJlIG91dCB3aGF0
IGlzIHRoZSB1c2UtY2FzZSBmb3IgZGlzdHJpYnV0ZWQgbW9iaWxlIG11bHRpY2FzdCAob3RoZXIg
dGhhbiBhY2FkZW1pYyBjb25zaWRlcmF0aW9ucyk/IENhbiBzb21lb25lIGdpdmUgY29uY3JldGUg
ZXhhbXBsZT8NCg0KSSBoYXZlbuKAmXQgcmVhbCBhbGwgbWVzc2FnZXMgZnJvbSB0aGlzIHRocmVh
ZC4gU28sIG1heWJlIEkgbWlzc2VkIGltcG9ydGFudCBwb2ludHMuDQoNCkJSLA0KUGllcnJpY2sN
Cg0KRGUgOiBkbW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+
IFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUga2FyYWdpYW5AY3Mu
dXR3ZW50ZS5ubDxtYWlsdG86a2FyYWdpYW5AY3MudXR3ZW50ZS5ubD4NCkVudm95w6kgOiBzYW1l
ZGkgMTcgbm92ZW1icmUgMjAxMiAxMzowMQ0Kw4AgOiBzZWlsamVvbkBhdi5pdC5wdDxtYWlsdG86
c2VpbGplb25AYXYuaXQucHQ+OyBKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29tPG1h
aWx0bzpKdWFuQ2FybG9zLlp1bmlnYUBJbnRlckRpZ2l0YWwuY29tPg0KQ2MgOiBkbW1AaWV0Zi5v
cmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtETU1dIE11bHRpY2FzdCByZXF1
aXJlbWVudHMNCg0KSGkgYWxsLA0KDQpJIGFsc28gYWdyZWUgdGhhdCB0aGUgRE1NIHNvbHV0aW9u
IHNob3VsZCBzb21laG93IGNvbnNpZGVyIG11dGljYXN0IGRlcGxveW1lbnQuIEhvd2V2ZXIsIEkg
ZG8gbm90IHRobmsgdGhhdCB0aGUgRE1NIFdHIGlzIHRoZSByaWdodCBXRyB0byBwcm92aWRlIHRo
ZSBtdWx0aWNhc3QgYmFzZWQgRE1NIHNvbHV0aW9uIQ0KDQpPbmUgYWx0ZXJuYXRpdmUgc29sdXRp
b24gd2lsbCBiZSB0byBoYXZlIGEgbXVsdGljYXN0IHJlcXVpcmVtZW50IHRoYXQgZW1waGFzaXpl
cyB0aGUgbmVlZCBvZiBoYXZpbmcgZXh0ZW5zaWJpbGl0eSBob29rcyAocG9zc2liaWxpdGllcykg
dGhhdCBjYW4gYmUgdXNlZCBsYXRlciBvbiBieSB0aGUgbXVsdGltb2IgV0cgdG8gcHJvdmlkZSBh
DQphIG11bHRpY2FzdCBlbmFibGVkIERNTSBzb2x1dGlvbiENCg0KDQpTbyBhIHJlcXVpcmVtZW50
IHRoYXQgc3BlY2lmaWVzIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgY291bGQgYmUgdXNl
ZCBmb3IgdGhpcyBwdXJwb3NlOg0KDQoiVGhlIERNTSAodW5pY2FzdCkgc29sdXRpb24gTVVTVCBi
ZSBzcGVjaWZpZWQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSBleHRlbmRlZCB0byBhbHNv
IHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuIg0KDQoNCkJlc3QgcmVnYXJkcywNCkdlb3JnaW9z
DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClZhbjogZG1tLWJv
dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPiBbZG1tLWJvdW5jZXNA
aWV0Zi5vcmddIG5hbWVucyBTZWlsIEplb24gW3NlaWxqZW9uQGF2Lml0LnB0XQ0KVmVyem9uZGVu
OiB2cmlqZGFnIDE2IG5vdmVtYmVyIDIwMTIgMjI6MjUNClRvOiAnWnVuaWdhLCBKdWFuIENhcmxv
cycNCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCk9uZGVyd2VycDogUmU6
IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHMNCkhpIEp1YW4sDQoNCkkndmUgYmVlbiBsb29r
ZWQgYXQgY2hhbmdlZCBmbG93IG9mIHlvdXIgcHJvcG9zZWQgdGV4dCBidXQgc29ycnkgbm93IHRo
YXQgbXkNCmNvbW1lbnQgaXMgcG9zdGVkLg0KQXQgZmlyc3QgdGltZSwgSSBjb3VsZG4ndCBtYWtl
IHN1cmUgaG93ZXZlciwgb24gaGVhcmluZyBTdGlnJ3MgZGVzY3JpcHRpb24sDQppdCBzZWVtcyBx
dWl0ZSByZWFzb25hYmxlIGF0IHRoZSBmaXJzdCBzdGVwLCBub3QgZ2l2aW5nIGFueSByZXN0cmlj
dGlvbnMgYnV0DQpsZWF2aW5nIHNvbWUtc3BlY2lmaWMgZm9yIHRoZSBETU0gc29sdXRpb24gaXQg
ZG9lcyBub3Qgc3VwcG9ydCBtdWx0aWNhc3QuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpdCByZW1h
aW5zIGF0IGEgYmFzaWMgc3RhZ2UgZm9yIHRoZSBETU0gc29sdXRpb24gdG8NCnN1cHBvcnQgbXVs
dGljYXN0Lg0KU28gSSB0aGluayBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIG1h
ZGUgZm9yIHRoZSBETU0gc29sdXRpb24sDQphY2NvcmRpbmdseS4gQnV0IG9mIGNvdXJzZSwgdGhp
cyBzaG91bGQgbm90IGFsc28gZ2l2ZSBhbnkgc3BlY2lmaWMNCmxpbWl0YXRpb24gYW5kIHJlc3Ry
aWN0aW9uIGJ1dCBzaG91bGQgYmUgbWFkZSB0b3dhcmRzIHRoZSBkaXJlY3Rpb24gbm90DQpsaW1p
dGluZyB0aGUgYmVuZWZpdHMgcHJvdmlkZWQgYnkgZGlzdHJpYnV0ZWQgZGVwbG95bWVudC4NCg0K
SSBob3BlIHRvIGdldCBtb3JlIGNvbW1lbnRzIG9uIHRoaXMuDQoNClJlZ2FyZHMsDQoNClNlaWwN
Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZG1tLWJvdW5jZXNAaWV0Zi5v
cmc8bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YNClp1bmlnYSwgSnVhbiBDYXJsb3MNClNlbnQ6IEZyaWRheSwgTm92
ZW1iZXIgMTYsIDIwMTIgODoxNCBQTQ0KVG86IFN0aWcgVmVuYWFzOyBkbW1AaWV0Zi5vcmc8bWFp
bHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1l
bnRzDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGlnIFZlbmFh
cyBbbWFpbHRvOnN0aWdAdmVuYWFzLmNvbV0NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNiwg
MjAxMiAzOjAxIFBNDQo+IFRvOiBqb3VuaSBrb3Job25lbg0KPiBDYzogc2FyaWtheWFAaWVlZS5v
cmc8bWFpbHRvOnNhcmlrYXlhQGllZWUub3JnPjsgWnVuaWdhLCBKdWFuIENhcmxvczsgS29uc3Rh
bnRpbm9zIFBlbnRpa291c2lzOw0KPiBQZXRlciBNY0Nhbm47IGRtbUBpZXRmLm9yZzxtYWlsdG86
ZG1tQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW0RNTV0gTXVsdGljYXN0IHJlcXVpcmVtZW50
cw0KPg0KPiBPbiAxMS8xNS8yMDEyIDM6MTcgQU0sIGpvdW5pIGtvcmhvbmVuIHdyb3RlOg0KPiA+
DQo+ID4gT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFNLCBCZWhjZXQgU2FyaWtheWEgd3JvdGU6
DQo+ID4NCj4gPj4NCj4gPj4gSSB0aGluayB3ZSBhcmUgcmVhZGluZyB0b28gbXVjaCBpbnRvIG11
bHRpY2FzdCBhbmQgdW5pY2FzdCBzaG91bGQNCmJlDQo+ID4+IGRlc2lnbmVkIGluIGFuIGludGVn
cmF0ZWQgbWFubmVyLg0KPiA+Pg0KPiA+PiBUaGUgZmFjdCBpcyB0aGF0IG11bHRpY2FzdCBpcyBj
b25zaWRlcmVkIGFzIGFuIGFyZWEgb2YNCj4gc3BlY2lhbGl6YXRpb24sDQo+ID4+IGl0IHJlcXVp
cmVzIGtub3dsZWRnZSBvZiB2ZXJ5IGRpZmZlcmVudCBwcm90b2NvbHMgdGhhbiB3ZSBhcmUNCj4g
Pj4gYWNjdXN0b21lZCB0byBpbiBtb2JpbGl0eS4NCj4gPg0KPiA+ICJSZXF1aXJlbWVudDogRE1N
IHNvbHV0aW9ucyBTSE9VTEQgc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMuIElmIGENCj4gc3Bl
Y2lmaWMgRE1NIHNvbHV0aW9uIGRvZXMgbm90IHN1cHBvcnQgbXVsdGljYXN0IHNlcnZpY2VzLCBh
bg0KPiBleHBsYW5hdGlvbiBNVVNUIGJlIHByb3ZpZGVkLiINCj4NCj4gVGhpcyBzb3VuZHMgZ29v
ZCB0byBtZS4NCj4NCj4gVGhlIG1haW4gdGhpbmcgSSB3YW50IHRvIGFjaGlldmUgaXMgd2hhdCB3
YXMgZGVzY3JpYmVzIGFzIG1vdGl2YXRpb24NCj4gZWFybGllciBpbiB0aGlzIHRocmVhZC4gTXVs
dGljYXN0IHNob3VsZCBhdCBsZWFzdCBiZSBjb25zaWRlcmVkIHdoZW4NCj4gbG9va2luZyBpbnRv
IERNTSBzb2x1dGlvbnMsIGFuZCBub3QganVzdCBhbiBhZnRlcnRob3VnaHQgb25jZSB0aGUNCj4g
c29sdXRpb24gaXMgZGVjaWRlZC4NCj4NCj4gU3RpZw0KDQpbSkNaXSBJIGZ1bGx5IGFncmVlIHdp
dGggdGhpcy4gVGhhdCB3YXMgdGhlIGludGVudGlvbiBvZiB0aGUgcHJvcG9zZWQgdGV4dC4NCg0K
UmVnYXJkcywNCg0KSnVhbiBDYXJsb3MNCg0KPg0KPiA+IFRvIG1lIHRoYXQgcmVhZHMgYmFzaWNh
bGx5ICJkbyBub3QgYnJlYWsgZm91bmRhdGlvbnMgZm9yIG11bHRpY2FzdA0KPiB1bmxlc3MgeW91
IGhhdmUgYSB2YWxpZCAmIGRvY3VtZW50ZWQgcmVhc29uIGZvciBpdCIuICBJZiB3ZSBsb29rIGUu
Zy4NCj4gaW50byBSRkM2MjUgbXVsdGljYXN0IHdvcmRpbmcgdGhhdCBpcyB0aGVyZSB2ZXJ5IGJy
aWVmbHkgYnV0IGdpdmVzIGENCj4gaGludCB0byBhIGRldmVsb3BlciB3aGVyZSB0byBoZWFkIHRv
LiBUaGF0IGlzIHRoZSBsZXZlbCBJIHdvdWxkIGV4cGVjdA0KPiBETU0gZG9jdW1lbnRzIHNob3Vs
ZCBhaW0gdG8uDQo+ID4NCj4gPiAtIEpvdW5pDQo+ID4NCj4gPg0KPiA+PiBMZXQgZG1tIGRlYWwg
d2l0aCBpdHMgY3VycmVudCBjaGFydGVyIHRoYXQgZG9lcyBub3QgaW5jbHVkZSBhIHdvcmQNCj4g
b2YNCj4gPj4gbXVsdGljYXN0IGFuZCBpZiBldmVyeXRoaW5nIGdvZXMgd2VsbCB3ZSBjYW4gY29t
ZSBiYWNrIGFuZCBkaXNjdXNzDQo+IGRtbQ0KPiA+PiBtdWx0aWNhc3QuDQo+ID4+DQo+ID4+IFJl
Z2FyZHMsDQo+ID4+DQo+ID4+IEJlaGNldA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt
bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1t
IG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdl
IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg
Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBl
dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2
b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy
DQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu
dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl
cmF0aW9uLA0KRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp
bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy
Y2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp
ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi
eSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp
dGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVs
ZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt
b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBp
ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg==

--_000_6E31144C030982429702B11D6746B98C364997B1SZXEML510MBXchi_
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
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu
dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i
R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+
DQo8IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9
DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwo
I2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwv
c3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEg
MSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v
c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg
MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkiOw0K
CXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IlxATWljcm9zb2Z0IFlhSGVpIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K
YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N
c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy
cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl
OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnR0DQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw
YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsIGFuZCBJIGFtIHRyeWluZyB0byBjb252
ZXJnZSB0aGUgZGlmZmVyZW50IHByb3Bvc2Fscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsg4oCcVG8gY29uc2lkZXIg
dGhlIGltcGFjdCBvZiBtdWx0aWNhc3Qgb24gRE1N4oCdIGhhcyB0aGUgc2FtZSBpbnRlbnRpb24g
YXMg4oCcc3R1ZHlpbmcgdGhlIHBvc3NpYmxlIHBlcmZvcm1hbmNlIHByb2JsZW1zIGluIHRoZSBw
cm9ibGVtIHN0YXRlbWVudCBzbyB0aGF0DQogdGhlIERNTSBzb2x1dGlvbnMgd2lsbCBlbmFibGUg
bXVsdGljYXN0IHNvbHV0aW9ucyB0aGF0IHdpbGwgYXZvaWQgdGhvc2UgcHJvYmxlbXMu4oCdDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkggQW50aG9ueSBDaGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBsdW8ud2VuQHp0ZS5jb20uY24g
W21haWx0bzpsdW8ud2VuQHp0ZS5jb20uY25dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5
LCBOb3ZlbWJlciAyMSwgMjAxMiA5OjE4IFBNPGJyPg0KPGI+VG86PC9iPiBoIGNoYW48YnI+DQo8
Yj5DYzo8L2I+IGRtbUBpZXRmLm9yZzsgZG1tLWJvdW5jZXNAaWV0Zi5vcmc7IHBpZXJyaWNrLnNl
aXRlQG9yYW5nZS5jb207IFNlaWwgSmVvbjxicj4NCjxiPlN1YmplY3Q6PC9iPiA8L3NwYW4+PHNw
YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+562U5aSNPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46IFJlOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1l
bnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgQW50aG9u
eSw8L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3Mg
Zm9yIHRoZSBzdW1tYXJ5LiBBbmQgSSB0aGluayB0aGUgbW90aXZhdGlvbiBzaG91bGQgYmUgYWxz
byBpbmNsdWRlZC4gVG8gbWUsIHRoZSB0ZXh0IGZyb20gSnVhbkNhcmxvcyBpcyByZXNhb25hYmxl
PC9zcGFuPg0KPGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m
Z3Q7IE1vdGl2YXRpb246IFRoZSBwdXJwb3NlIG9mIHRoaXMgcmVxdWlyZW1lbnQgaXMgdG8gZW5j
b3VyYWdlIHBlb3BsZSB0bzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uc2lkZXIgdGhlIGltcGFjdHMgb2YgcnVubmluZyBt
dWx0aWNhc3Qgc2VydmljZXMgaW4gYSBETU08L3R0Pjxicj4NCjx0dD4mZ3Q7ZW52aXJvbm1lbnQ8
L3R0Pjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+77yePC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Zy
b20gdGhlIGJlZ2lubmluZyBvZiB0aGUgZGV2ZWxvcG1lbnQsIHRoZXJlYnkgYXZvaWRpbmcgdGhl
PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iWkgtQ04i
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+77ye44CAPC9zcGFu
PjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5uZWVkIHRvPC9zcGFuPjwv
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+77yePC9zcGFuPjwvdHQ+PHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IG1ha2UgcHJvdG9jb2wgZXh0ZW5zaW9ucyBpbiB0aGUgZnV0dXJlIHRvIHN1cHBvcnQgdGhpcyBr
aW5kIG9mPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0i
WkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+77yePC9z
cGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IGZ1bmN0aW9uYWxpdHkuPC9zcGFuPjwvdHQ+DQo8YnI+DQo8YnI+DQo8
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoYW5rczwvc3Bhbj48L3R0PiA8YnI+
DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkx1b3dlbjwvc3Bhbj48L3R0PiA8
YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs
VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i
MTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjQw
JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo0MC4wJTtwYWRkaW5nOi43NXB0IC43NXB0IC43
NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+aCBjaGFuICZsdDtoLmFudGhvbnkuY2hhbkBodWF3ZWkuY29tJmd0Ozwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48YnI+DQo8c3BhbiBsYW5nPSJaSC1D
TiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpTaW1TdW4iPuWPkeS7tuS6ujwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogJm5ic3A7ZG1tLWJvdW5jZXNAaWV0Zi5v
cmc8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
MjAxMi8xMS8yMCAwNjoyODwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0
aD0iNTklIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjU5LjAlO3BhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw
IiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk
dGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp
bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249
InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl
PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7mlLbku7bkuro8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVw
dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPlNlaWwgSmVvbiAmbHQ7c2VpbGplb25AYXYuaXQucHQmZ3Q7LCAmcXVvdDtw
aWVycmljay5zZWl0ZUBvcmFuZ2UuY29tJnF1b3Q7ICZsdDtwaWVycmljay5zZWl0ZUBvcmFuZ2Uu
Y29tJmd0Ozwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg
dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQi
PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+5oqE6YCBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRv
cCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtkbW1AaWV0Zi5vcmcmcXVv
dDsgJmx0O2RtbUBpZXRmLm9yZyZndDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAu
NzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0
ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVw
dDtmb250LWZhbWlseTpTaW1TdW4iPuS4u+mimDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+
DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtE
TU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl
bGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWdu
PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRk
IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90
ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv
dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIDMgcHJvcG9zYWxzIGZv
ciBtdWx0aWNhc3QgcmVxdWlyZW1lbnRzLiBCZWZvcmUgY29tcGFyaW5nIHRoZXNlIHByb3Bvc2Fs
cywgbGV0IHVzIHVuZGVyc3RhbmQgd2hhdCBhcmUgdGhlIHByb2JsZW1zIGZpcnN0LiBUd28gcHJv
YmxlbSBzdGF0ZW1lbnRzIGhhdmUgYmVlbiBwcm9wb3NlZDo8L3NwYW4+DQo8YnI+DQo8c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBTMSAocmV2aXNlZCk6
IE5vbi1vcHRpbWFsIHJvdXRlczwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMzMzMzk5Ij5Sb3V0aW5nIHZpYSBhIGNlbnRyYWxpemVkIGFuY2hvciBvZnRl
biByZXN1bHRzIGluIGEgbG9uZ2VyIHJvdXRlLiBUaGUgcHJvYmxlbSBpcyBlc3BlY2lhbGx5IG1h
bmlmZXN0ZWQgd2hlbiBhY2Nlc3NpbmcgYSBsb2NhbCBzZXJ2ZXIgb3Igc2VydmVycyBvZiBhIENv
bnRlbnQgRGVsaXZlcnkgTmV0d29yayAoQ0ROKSwNCjxiPm9yIHdoZW4gcmVjZWl2aW5nIC8gc2Vu
ZGluZyBJUCBtdWx0aWNhc3QgcGFja2V0czwvYj4uIDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzM5OSI+UFM2OiBEdXBsaWNhdGUgbXVsdGljYXN0IHRy
YWZmaWM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz
MzM5OSI+SVAgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBvdmVyIGFyY2hpdGVjdHVyZXMgdXNpbmcg
SVAgbW9iaWxpdHkgc29sdXRpb25zICZuYnNwO21heSBsZWFkIHRvIGNvbnZlcmdlbmNlIG9mIGR1
cGxpY2F0ZWQgbXVsdGljYXN0IHN1YnNjcmlwdGlvbnMgdG93YXJkcyB0aGUgdHVubmVs4oCZcyBk
b3duc3RyZWFtIGVudGl0eSAoZS5nLg0KIE1BRyBpbiBQTUlQdjYpLiAmbmJzcDtDb25jcmV0ZWx5
LCB3aGVuIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gZm9yIGluZGl2aWR1YWwgbW9iaWxlIG5vZGVz
IGlzIGNvdXBsZWQgd2l0aCBtb2JpbGl0eSB0dW5uZWxzLCBkdXBsaWNhdGUgbXVsdGljYXN0IHN1
YnNjcmlwdGlvbihzKSBpcyBwcm9uZSB0byBiZSByZWNlaXZlZCB0aHJvdWdoIGRpZmZlcmVudCB1
cHN0cmVhbSBwYXRocy4gVGhpcyBwcm9ibGVtIGlzIHBvdGVudGlhbGx5IG1vcmUgc2V2ZXJlIGlu
DQogYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBlbnZpcm9ubWVudCBbZHJhZnQtc2ZpZ3VlaXJlZG8t
bXVsdGltb2ItdXNlLWNhc2UtZG1tLTAzXS48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZW4sIGxldCB1cyBzZWUgd2hldGhl
ciBhbGwgdGhlIDMgUkVRIHByb3Bvc2FscyBoYXZlIHRoZSBzYW1lIGludGVudGlvbi4gSW4gdGhl
IGZvbGxvd2luZywgSSByZXBocmFzZSB0aGVtIHRvIGhpZ2hsaWdodCB0aGVpciBzaW1pbGFyaXRp
ZXMuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5SRVE3LjE6IEZsZXhpYmxlIG11bHRpY2FzdCBkaXN0cmlidXRpb248L3NwYW4+
DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RE1NIHNv
bHV0aW9ucyBzaG91bGQgYmUgY29tcGF0aWJsZSB3aXRoIGZsZXhpYmxlIG11bHRpY2FzdCBkaXN0
cmlidXRpb24gc2NlbmFyaW8uIEV0Yy4NCjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIE1vdGl2YXRpb24gaXMgdG8gYWxsb3cgZmxleGli
aWxpdHkgaW4gKGVuYWJsZSkgbXVsdGljYXN0IHNvbHV0aW9ucyB0byBzb2x2ZSB0aGUgcHJvYmxl
bXMgUFMxIGFuZCBQUzYgYXMgZXhwbGFpbmVkIGluIHVzZSBjYXNlcyBhbHJlYWR5IHByZXNlbnRl
ZCBhbmQgZGlzY3Vzc2VkIGluIG11bHRpbW9iIHdnLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UkVRNy4yOg0KPC9zcGFuPjxi
cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ETU0gc29sdXRp
b25zIHNob3VsZCBlbmFibGUgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMu
DQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4oT3JpZ2luYWwgd29yZGluZyB3YXMgJnF1b3Q7VGhlIERNTSAodW5pY2FzdCkgc29s
dXRpb24gTVVTVCBiZSBzcGVjaWZpZWQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSBleHRl
bmRlZCB0byBhbHNvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuJnF1b3Q7IEkgcmVwaHJhc2Ug
aXQgdG8gaGlnaGxpZ2h0IHRoZSBzaW1pbGFyaXR5DQogd2l0aCB0aGUgb3RoZXIgcHJvcG9zYWxz
IGFuZCBhbHNvIGNoYW5nZWQgdGhlIG11c3QgdG8gc2hvdWxkLik8L3NwYW4+IDxicj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8YnI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UkVRNy4zOjwvc3Bh
bj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ETU0g
c29sdXRpb25zIHNob3VsZCBlbmFibGUgc29sdXRpb25zIHRvIHN1cHBvcnQgbXVsdGljYXN0IHNl
cnZpY2VzLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+T3JpZ2luYWwgd29yZGluZyB3YXMg4oCcRE1NIHNvbHV0aW9ucyBzaG91
bGQgc3VwcG9ydCBtdWx0aWNhc3Qgc2VydmljZXMg4oCmIGV0Yy4gR2l2ZW4gdGhhdCBpdCBpcyB0
aGUgc2NvcGUgb2YgbXVsdGltb2IgYW5kIG5vdCBkbW0gd2cgdG8gcHJvdmlkZSB0aGUgbXVsdGlj
YXN0IHNvbHV0aW9uLCBJIHRoaW5rIOKAnHN1cHBvcnTigJ0NCiBoZXJlIG1lYW5zIOKAnGVuYWJs
ZeKAnSBzb2x1dGlvbnMgdG8gYmUgZGV2ZWxvcGVkIChieSBtdWx0aW1vYikuPC9zcGFuPiA8YnI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbWls
YXJpdHkgYW5kIHN1YnRsZSBkaWZmZXJlbmNlczogQm90aCBSRVE3LjIgYW5kIFJFUTcuMyB3YW50
IHRvIGVuYWJsZSBtdWx0aWNhc3Qgc2VydmljZXMuIFlldCB0aGUgZXhwbGFuYXRpb24gaW4gUkVR
Ny4xIHNlZW1zIHRvIGluZGljYXRlIG5vdCBqdXN0IHRvIGVuYWJsZSBhbnkgb25lIG11bHRpY2Fz
dA0KIHNvbHV0aW9uIGJ1dCBhbHNvIG5lZWRzIHRoZSBmbGV4aWJpbGl0eSBpbiBtdWx0aWNhc3Qg
c29sdXRpb24uIE5vdCBhbGwgbXVsdGljYXN0IHNvbHV0aW9ucyBhcmUgdGhlIHNhbWUuIFNvbWUg
b2YgdGhlbSByZXN1bHRzIGluIFBTMSBvciBQUzYuDQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj4NCjxicj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcmUgdGhlcmUgYW55IGFyZSBl
c3NlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2Vlbjo8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gUkVRNy4xLCBETU0gc29sdXRpb25zIHNo
b3VsZCBiZSBjb21wYXRpYmxlIHdpdGggZmxleGlibGUgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiBz
Y2VuYXJpbywgZXRjLg0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5WZXJzdXM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+RE1NIHNvbHV0aW9ucyBzaG91bGQgZW5hYmxlIG11bHRpY2Fz
dCBzZXJ2aWNlcyB3aGljaCBhcmUgY29tcGF0aWJsZSB3aXRoIG11bHRpY2FzdCBkaXN0cmlidXRp
b24gc2NlbmFyaW8sIGV0Yy48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkggQW50aG9ueSBDaGFuDQo8L3NwYW4+PGJyPg0KPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj4NCjxi
cj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkbW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtbS1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TZWlsIEplb248Yj48YnI+DQpT
ZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxMiA1OjE1IEFNPGI+PGJyPg0KVG86PC9i
PiBwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPGI+PGJyPg0KQ2M6PC9iPiBkbW1AaWV0Zi5vcmc8
Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8L3Nw
YW4+IDxicj4NCiZuYnNwOyA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBQaWVy
cmljayw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw
YW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPknigJl2ZSBtYW55IHRpbWVzIHRo
b3VnaHQgYWJvdXQgeW91ciBxdWVzdGlvbi4gSSB3b3VsZCBzYXkgaG93IGVmZmVjdGl2ZWx5IHNo
b3VsZCB3ZSBkZXBsb3kvc3VwcG9ydCBtdWx0aWNhc3Qgb3ZlciBkaXN0cmlidXRlZCBtb2JpbGl0
eSByYXRoZXIgdGhhbiBkaXN0cmlidXRlZCBtb2JpbGUgbXVsdGljYXN0LiBBcyBhIHJlc3VsdCwg
eW91DQogY2FuIGZpbmQgdGhpcyBkZXBsb3ltZW50IHVzZSBjYXNlIGFuZCBnYXAgYW5hbHlzaXMg
YXQgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNmaWd1
ZWlyZWRvLW11bHRpbW9iLXVzZS1jYXNlLWRtbS0wMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ZpZ3VlaXJlZG8tbXVsdGltb2It
dXNlLWNhc2UtZG1tLTAzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBw
cmVzZW50ZWQgaW4gbXVsdGltb2Igc2V2ZXJhbCB0aW1lcy48L3NwYW4+IDxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+SW4gdW5pY2FzdCBETU0sIG1haW4gaW5ub3ZhdGlvbiBpcyB0byBkaXN0cmlidXRl
IHRoZSBhbmNob3IgZnVuY3Rpb24gYXQgbWFueSBhY2Nlc3Mgcm91dGVycyBmcm9tIHNpbmdsZSBj
b3JlLiBGb2xsb3dpbmcgYXJjaGl0ZWN0dXJhbCBjb25jZXB0IG9mIERNTSwgZmxleGlibGUgbXVs
dGljYXN0IGRpc3RyaWJ1dGlvbiBpcyBvbmUgb2YgbXVsdGljYXN0DQogcmVxdWlyZW1lbnQgcmVz
dWx0ZWQgZnJvbSB0aGUgZHJhZnQgZGVzY3JpYmVkIGFib3ZlLiA8L3NwYW4+PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQpSRVE4OiBGbGV4aWJsZSBt
dWx0aWNhc3QgZGlzdHJpYnV0aW9uIDxicj4NCiZxdW90O0RNTSBzb2x1dGlvbnMgU0hPVUxEIGJl
IGNvbXBhdGlibGUgd2l0aCBmbGV4aWJsZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHNjZW5hcmlv
cy4gVGhpcyBmbGV4aWJpbGl0eSBlbmFibGVzIGRpZmZlcmVudCBJUCBtdWx0aWNhc3QgZmxvd3Mg
d2l0aCByZXNwZWN0IHRvIGEgbW9iaWxlIGhvc3QgdG8gYmUgbWFuYWdlZCAoZS5nLiwgc3Vic2Ny
aWJlZCwgcmVjZWl2ZWQgYW5kL29yIHRyYW5zbWl0dGVkKSB1c2luZyBtdWx0aXBsZSBlbmRwb2lu
dHMmcXVvdDsuDQo8YnI+DQo8YnI+DQpNb3RpdmF0aW9uOiBUaGUgbW90aXZhdGlvbiBmb3IgdGhp
cyByZXF1aXJlbWVudCBpcyB0byBlbmFibGUgZmxleGliaWxpdHkgaW4gbXVsdGljYXN0IGRpc3Ry
aWJ1dGlvbi4gVGhlIG11bHRpY2FzdCBzb2x1dGlvbiBtYXkgdGhlcmVmb3JlIGF2b2lkIGhhdmlu
ZyBtdWx0aWNhc3QtY2FwYWJsZSBhY2Nlc3Mgcm91dGVycyBiZWluZyByZXN0cmljdGVkIHRvIG1h
bmFnZSBhbGwgSVAgbXVsdGljYXN0IHRyYWZmaWMgcmVsYXRpdmUgdG8gYSBob3N0IHZpYQ0KIGEg
c2luZ2xlIGVuZHBvaW50IChlLmcuIHJlZ3VsYXIgb3IgdHVubmVsIGludGVyZmFjZSksIHdoaWNo
IHdvdWxkIGxlYWQgdG8gdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiBQUzEgYW5kIFBTNi4NCjxi
cj4NClBTNjogRHVwbGljYXRlIG11bHRpY2FzdCB0cmFmZmljIDxicj4NCklQIG11bHRpY2FzdCBk
aXN0cmlidXRpb24gb3ZlciBhcmNoaXRlY3R1cmVzIHVzaW5nIElQIG1vYmlsaXR5IHNvbHV0aW9u
cyAmbmJzcDttYXkgbGVhZCB0byBjb252ZXJnZW5jZSBvZiBkdXBsaWNhdGVkIG11bHRpY2FzdCBz
dWJzY3JpcHRpb25zIHRvd2FyZHMgdGhlIHR1bm5lbOKAmXMgZG93bnN0cmVhbSBlbnRpdHkgKGUu
Zy4gTUFHIGluIFBNSVB2NikuICZuYnNwO0NvbmNyZXRlbHksIHdoZW4gbXVsdGljYXN0IHN1YnNj
cmlwdGlvbiBmb3IgaW5kaXZpZHVhbCBtb2JpbGUNCiBub2RlcyBpcyBjb3VwbGVkIHdpdGggbW9i
aWxpdHkgdHVubmVscywgZHVwbGljYXRlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24ocykgaXMgcHJv
bmUgdG8gYmUgcmVjZWl2ZWQgdGhyb3VnaCBkaWZmZXJlbnQgdXBzdHJlYW0gcGF0aHMuIFRoaXMg
cHJvYmxlbSBpcyBwb3RlbnRpYWxseSBtb3JlIHNldmVyZSBpbiBhIGRpc3RyaWJ1dGVkIG1vYmls
aXR5IGVudmlyb25tZW50IFtkcmFmdC1zZmlndWVpcmVkby1tdWx0aW1vYi11c2UtY2FzZS1kbW0t
MDNdLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPC9zcGFu
PiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlaWw8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHBpZXJy
aWNrLnNlaXRlQG9yYW5nZS5jb20gW21haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tXQ0K
PGI+PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIgODo1NSBBTTxiPjxi
cj4NClRvOjwvYj4gJ2thcmFnaWFuQGNzLnV0d2VudGUubmwnOyBzZWlsamVvbkBhdi5pdC5wdDsg
SnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbTxiPjxicj4NCkNjOjwvYj4gZG1tQGll
dGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJFOiBbRE1NXSBNdWx0aWNhc3QgcmVxdWlyZW1l
bnRzPC9zcGFuPiA8YnI+DQombmJzcDsgPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGVuZCB0byBhZ3JlZSB3aXRoIEdlb3Jn
aW91cywgaG93ZXZlciBJIHN0aWxsIGRvIG5vdCBmaWd1cmUgb3V0IHdoYXQgaXMgdGhlIHVzZS1j
YXNlIGZvciBkaXN0cmlidXRlZCBtb2JpbGUgbXVsdGljYXN0IChvdGhlciB0aGFuIGFjYWRlbWlj
IGNvbnNpZGVyYXRpb25zKT8gQ2FuIHNvbWVvbmUgZ2l2ZSBjb25jcmV0ZQ0KIGV4YW1wbGU/IDwv
c3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgaGF2ZW7igJl0IHJlYWwgYWxsIG1lc3NhZ2VzIGZyb20gdGhpcyB0aHJlYWQuIFNvLCBt
YXliZSBJIG1pc3NlZCBpbXBvcnRhbnQgcG9pbnRzLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsPC9zcGFuPg0KPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBpZXJyaWNrPC9zcGFu
Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSA6PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv
OmRtbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZG1tLWJv
dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWzwv
c3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5tYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiA8L3NwYW4+PGEg
aHJlZj0ibWFpbHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5rYXJhZ2lhbkBjcy51dHdlbnRlLm5sPC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+PGJyPg0KRW52b3nDqSA6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+IHNhbWVkaSAxNyBub3ZlbWJyZSAyMDEyIDEzOjAxPGI+PGJyPg0Kw4AgOjwv
Yj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZWlsamVvbkBhdi5pdC5wdCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPnNlaWxqZW9uQGF2Lml0LnB0PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpKdWFuQ2FybG9zLlp1bmln
YUBJbnRlckRpZ2l0YWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SnVhbkNhcmxv
cy5adW5pZ2FASW50ZXJEaWdpdGFsLmNvbTwvc3Bhbj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxicj4NCkNjIDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4gPC9zcGFuPg0KPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxicj4NCk9iamV0IDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4gUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8L3NwYW4+DQo8YnI+DQombmJz
cDsgPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIGFsbCw8L3NwYW4+IDxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGFsc28gYWdyZWUgdGhhdCB0aGUgRE1NIHNvbHV0aW9uIHNo
b3VsZCBzb21laG93IGNvbnNpZGVyIG11dGljYXN0IGRlcGxveW1lbnQuIEhvd2V2ZXIsIEkgZG8g
bm90IHRobmsgdGhhdCB0aGUgRE1NIFdHIGlzIHRoZSByaWdodCBXRyB0byBwcm92aWRlIHRoZSBt
dWx0aWNhc3QgYmFzZWQgRE1NIHNvbHV0aW9uITwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5PbmUgYWx0ZXJuYXRpdmUgc29sdXRpb24gd2lsbCBiZSB0byBoYXZlIGEgbXVsdGljYXN0
IHJlcXVpcmVtZW50IHRoYXQgZW1waGFzaXplcyB0aGUgbmVlZCBvZiBoYXZpbmcgZXh0ZW5zaWJp
bGl0eSBob29rcyAocG9zc2liaWxpdGllcykgdGhhdCBjYW4gYmUgdXNlZCBsYXRlciBvbiBieSB0
aGUgbXVsdGltb2IgV0cgdG8gcHJvdmlkZQ0KIGEgPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5hIG11bHRpY2FzdCBlbmFibGVkIERNTSBzb2x1dGlvbiE8L3NwYW4+DQo8
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+U28gYSByZXF1aXJlbWVudCB0aGF0IHNwZWNpZmllcyBzb21ldGhpbmcg
bGlrZSB0aGUgZm9sbG93aW5nIGNvdWxkIGJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZTo8L3NwYW4+
DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7VGhlIERNTSAodW5pY2FzdCkgc29sdXRp
b24gTVVTVCBiZSBzcGVjaWZpZWQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSBleHRlbmRl
ZCB0byBhbHNvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWZmaWMuJnF1b3Q7PC9zcGFuPg0KPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+R2Vvcmdpb3M8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8
L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9
InRleHQtYWxpZ246Y2VudGVyIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1z
b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBz
aXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPlZhbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kbW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBbZG1tLWJvdW5jZXNAaWV0Zi5vcmddIG5hbWVucyBT
ZWlsIEplb24gW3NlaWxqZW9uQGF2Lml0LnB0XTxiPjxicj4NClZlcnpvbmRlbjo8L2I+IHZyaWpk
YWcgMTYgbm92ZW1iZXIgMjAxMiAyMjoyNTxiPjxicj4NClRvOjwvYj4gJ1p1bmlnYSwgSnVhbiBD
YXJsb3MnPGI+PGJyPg0KQ2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9y
ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9uZGVyd2VycDo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUmU6IFtETU1dIE11bHRpY2FzdCByZXF1aXJlbWVu
dHM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgSnVhbiw8YnI+
DQo8YnI+DQpJJ3ZlIGJlZW4gbG9va2VkIGF0IGNoYW5nZWQgZmxvdyBvZiB5b3VyIHByb3Bvc2Vk
IHRleHQgYnV0IHNvcnJ5IG5vdyB0aGF0IG15PGJyPg0KY29tbWVudCBpcyBwb3N0ZWQuPGJyPg0K
QXQgZmlyc3QgdGltZSwgSSBjb3VsZG4ndCBtYWtlIHN1cmUgaG93ZXZlciwgb24gaGVhcmluZyBT
dGlnJ3MgZGVzY3JpcHRpb24sPGJyPg0KaXQgc2VlbXMgcXVpdGUgcmVhc29uYWJsZSBhdCB0aGUg
Zmlyc3Qgc3RlcCwgbm90IGdpdmluZyBhbnkgcmVzdHJpY3Rpb25zIGJ1dDxicj4NCmxlYXZpbmcg
c29tZS1zcGVjaWZpYyBmb3IgdGhlIERNTSBzb2x1dGlvbiBpdCBkb2VzIG5vdCBzdXBwb3J0IG11
bHRpY2FzdC48YnI+DQo8YnI+DQpPbiB0aGUgb3RoZXIgaGFuZCwgaXQgcmVtYWlucyBhdCBhIGJh
c2ljIHN0YWdlIGZvciB0aGUgRE1NIHNvbHV0aW9uIHRvPGJyPg0Kc3VwcG9ydCBtdWx0aWNhc3Qu
PGJyPg0KU28gSSB0aGluayBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIG1hZGUg
Zm9yIHRoZSBETU0gc29sdXRpb24sPGJyPg0KYWNjb3JkaW5nbHkuIEJ1dCBvZiBjb3Vyc2UsIHRo
aXMgc2hvdWxkIG5vdCBhbHNvIGdpdmUgYW55IHNwZWNpZmljPGJyPg0KbGltaXRhdGlvbiBhbmQg
cmVzdHJpY3Rpb24gYnV0IHNob3VsZCBiZSBtYWRlIHRvd2FyZHMgdGhlIGRpcmVjdGlvbiBub3Q8
YnI+DQpsaW1pdGluZyB0aGUgYmVuZWZpdHMgcHJvdmlkZWQgYnkgZGlzdHJpYnV0ZWQgZGVwbG95
bWVudC48YnI+DQo8YnI+DQpJIGhvcGUgdG8gZ2V0IG1vcmUgY29tbWVudHMgb24gdGhpcy48YnI+
DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NClNlaWw8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG1t
LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kbW0tYm91bmNl
c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBbPC9zcGFu
PjxhIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw
YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQogT24gQmVoYWxmIE9mPGJyPg0K
WnVuaWdhLCBKdWFuIENhcmxvczxicj4NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIg
ODoxNCBQTTxicj4NClRvOiBTdGlnIFZlbmFhczsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkbW1A
aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kbW1AaWV0Zi5vcmc8L3NwYW4+
PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpTdWJqZWN0OiBSZTogW0RNTV0g
TXVsdGljYXN0IHJlcXVpcmVtZW50czxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFN0aWcgVmVuYWFzIFs8L3NwYW4+PGEgaHJl
Zj0ibWFpbHRvOnN0aWdAdmVuYWFzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5tYWlsdG86c3RpZ0B2ZW5hYXMuY29tPC9zcGFuPjwvYT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+XTxicj4NCiZndDsgU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNiwg
MjAxMiAzOjAxIFBNPGJyPg0KJmd0OyBUbzogam91bmkga29yaG9uZW48YnI+DQomZ3Q7IENjOiA8
L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNhcmlrYXlhQGllZWUub3JnIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+c2FyaWtheWFAaWVlZS5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij47IFp1bmlnYSwgSnVhbiBDYXJsb3M7IEtvbnN0YW50aW5vcyBQZW50aWtvdXNp
czsNCjxicj4NCiZndDsgUGV0ZXIgTWNDYW5uOyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbUBp
ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtE
TU1dIE11bHRpY2FzdCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTEvMTUv
MjAxMiAzOjE3IEFNLCBqb3VuaSBrb3Job25lbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDsgT24gTm92IDE1LCAyMDEyLCBhdCAxOjAzIEFNLCBCZWhjZXQgU2FyaWtheWEgd3Jv
dGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsg
SSB0aGluayB3ZSBhcmUgcmVhZGluZyB0b28gbXVjaCBpbnRvIG11bHRpY2FzdCBhbmQgdW5pY2Fz
dCBzaG91bGQ8YnI+DQpiZTxicj4NCiZndDsgJmd0OyZndDsgZGVzaWduZWQgaW4gYW4gaW50ZWdy
YXRlZCBtYW5uZXIuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhlIGZh
Y3QgaXMgdGhhdCBtdWx0aWNhc3QgaXMgY29uc2lkZXJlZCBhcyBhbiBhcmVhIG9mPGJyPg0KJmd0
OyBzcGVjaWFsaXphdGlvbiw8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0IHJlcXVpcmVzIGtub3dsZWRn
ZSBvZiB2ZXJ5IGRpZmZlcmVudCBwcm90b2NvbHMgdGhhbiB3ZSBhcmUgPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyBhY2N1c3RvbWVkIHRvIGluIG1vYmlsaXR5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0OyAmcXVvdDtSZXF1aXJlbWVudDogRE1NIHNvbHV0aW9ucyBTSE9VTEQgc3VwcG9ydCBtdWx0
aWNhc3Qgc2VydmljZXMuIElmIGE8YnI+DQomZ3Q7IHNwZWNpZmljIERNTSBzb2x1dGlvbiBkb2Vz
IG5vdCBzdXBwb3J0IG11bHRpY2FzdCBzZXJ2aWNlcywgYW4gPGJyPg0KJmd0OyBleHBsYW5hdGlv
biBNVVNUIGJlIHByb3ZpZGVkLiZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIHNvdW5k
cyBnb29kIHRvIG1lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbWFpbiB0aGluZyBJIHdhbnQg
dG8gYWNoaWV2ZSBpcyB3aGF0IHdhcyBkZXNjcmliZXMgYXMgbW90aXZhdGlvbiA8YnI+DQomZ3Q7
IGVhcmxpZXIgaW4gdGhpcyB0aHJlYWQuIE11bHRpY2FzdCBzaG91bGQgYXQgbGVhc3QgYmUgY29u
c2lkZXJlZCB3aGVuIDxicj4NCiZndDsgbG9va2luZyBpbnRvIERNTSBzb2x1dGlvbnMsIGFuZCBu
b3QganVzdCBhbiBhZnRlcnRob3VnaHQgb25jZSB0aGUgPGJyPg0KJmd0OyBzb2x1dGlvbiBpcyBk
ZWNpZGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdGlnPGJyPg0KPGJyPg0KW0pDWl0gSSBmdWxs
eSBhZ3JlZSB3aXRoIHRoaXMuIFRoYXQgd2FzIHRoZSBpbnRlbnRpb24gb2YgdGhlIHByb3Bvc2Vk
IHRleHQuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpKdWFuIENhcmxvczxicj4NCjxi
cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvIG1lIHRoYXQgcmVhZHMgYmFzaWNhbGx5ICZxdW90
O2RvIG5vdCBicmVhayBmb3VuZGF0aW9ucyBmb3IgbXVsdGljYXN0PGJyPg0KJmd0OyB1bmxlc3Mg
eW91IGhhdmUgYSB2YWxpZCAmYW1wOyBkb2N1bWVudGVkIHJlYXNvbiBmb3IgaXQmcXVvdDsuICZu
YnNwO0lmIHdlIGxvb2sgZS5nLjxicj4NCiZndDsgaW50byBSRkM2MjUgbXVsdGljYXN0IHdvcmRp
bmcgdGhhdCBpcyB0aGVyZSB2ZXJ5IGJyaWVmbHkgYnV0IGdpdmVzIGEgPGJyPg0KJmd0OyBoaW50
IHRvIGEgZGV2ZWxvcGVyIHdoZXJlIHRvIGhlYWQgdG8uIFRoYXQgaXMgdGhlIGxldmVsIEkgd291
bGQgZXhwZWN0IDxicj4NCiZndDsgRE1NIGRvY3VtZW50cyBzaG91bGQgYWltIHRvLjxicj4NCiZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtIEpvdW5pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBMZXQgZG1tIGRlYWwgd2l0aCBpdHMgY3VycmVudCBjaGFy
dGVyIHRoYXQgZG9lcyBub3QgaW5jbHVkZSBhIHdvcmQ8YnI+DQomZ3Q7IG9mPGJyPg0KJmd0OyAm
Z3Q7Jmd0OyBtdWx0aWNhc3QgYW5kIGlmIGV2ZXJ5dGhpbmcgZ29lcyB3ZWxsIHdlIGNhbiBjb21l
IGJhY2sgYW5kIGRpc2N1c3M8YnI+DQomZ3Q7IGRtbTxicj4NCiZndDsgJmd0OyZndDsgbXVsdGlj
YXN0Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0K
Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgQmVoY2V0PGJyPg0KPGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGlu
ZyBsaXN0PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+PC9zcGFu
PjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L3NwYW4+
PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8
dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48L3NwYW4+PGEgaHJl
Zj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRtbUBp
ZXRmLm9yZzwvc3Bhbj48L2E+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1
ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvc3Bhbj48L2E+DQo8
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw
YW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2
ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn
aWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cGFzIGV0cmUg
ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg
YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8L3Nw
YW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg
cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg
c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJhbmNl
IFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz
YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPg0KPGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk
IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PC9zcGFuPg0KPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg
d2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg
YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L3NwYW4+DQo8YnI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9y
YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg
Y2hhbmdlZCBvciBmYWxzaWZpZWQuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rIHlvdS48
dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxi
cj4NCjx0dD5kbW0gbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+ZG1tQGlldGYub3JnPC90dD48
YnI+DQo8dHQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L3R0Pjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6E31144C030982429702B11D6746B98C364997B1SZXEML510MBXchi_--

From h.anthony.chan@huawei.com  Tue Nov 27 16:45:01 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81E921F85E8 for ; Tue, 27 Nov 2012 16:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dajtluPdQ-Ey for ; Tue, 27 Nov 2012 16:44:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEE121F85D5 for ; Tue, 27 Nov 2012 16:44:52 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALY85785; Wed, 28 Nov 2012 00:44:45 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 00:44:35 +0000
Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 08:44:43 +0800
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.162]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.01.0323.003; Wed, 28 Nov 2012 08:44:39 +0800
From: h chan 
To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= , "dmm@ietf.org" 
Thread-Topic: [DMM] Multicast requirements
Thread-Index: AQHNxqz10Lpebwr8wEqNc0MI7ktPh5f+cZaA
Date: Wed, 28 Nov 2012 00:44:39 +0000
Message-ID: <6E31144C030982429702B11D6746B98C364997C8@SZXEML510-MBX.china.huawei.com>
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EE602@szxeml545-mbx.china.huawei.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt> 	<23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huaw	ei.com> <50AABF7D.9020003@av.it.pt>
In-Reply-To: <50AABF7D.9020003@av.it.pt>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.78]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C364997C8SZXEML510MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 00:45:01 -0000

--_000_6E31144C030982429702B11D6746B98C364997C8SZXEML510MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

So, if we rephrase 7.1 as
REQ7.1: Flexible multicast distribution
DMM solutions should enable multicast services which are compatible with (f=
lexible?) multicast distribution scenario. Etc.

It will have the same intention as REQ7.2 and REQ7.3.

Is that right?

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of S=E9r=
gio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.

As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should =
enable multicast services which are compatible with multicast distribution =
scenario, etc.". It seems like there is no major difference between this an=
d the "DMM solutions should enable solutions to support multicast services.=
" requirement? Aren't both expressing the need to enable multicast in a DMM=
 solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the P=
Ss you referred.  So, while 7.2 and 7.3 express the need for DMM solutions =
to allow deployment of multicast services, 7.1 concerns  "how" IP multicast=
 should be enabled in order to avoid the aforementioned PSs. The usage of t=
he word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mo=
bile host to be managed (e.g., subscribed, received and/or transmitted) usi=
ng multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn'=
t necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these pr=
oposals, let us understand what are the problems first. Two problem stateme=
nts have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. I=
n the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution sce=
nario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to s=
olve the problems PS1 and PS6 as explained in use cases already presented a=
nd discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such=
 a way that it can be extended to also support multicast traffic." I rephra=
se it to highlight the similarity with the other proposals and also changed=
 the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was "DMM solutions should support multicast services ... e=
tc. Given that it is the scope of multimob and not dmm wg to provide the mu=
lticast solution, I think "support" here means "enable" solutions to be dev=
eloped (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable mu=
lticast services. Yet the explanation in REQ7.1 seems to indicate not just =
to enable any one multicast solution but also needs the flexibility in mult=
icast solution. Not all multicast solutions are the same. Some of them resu=
lts in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distr=
ibution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with mu=
lticast distribution scenario, etc.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively sh=
ould we deploy/support multicast over distributed mobility rather than dist=
ributed mobile multicast. As a result, you can find this deployment use cas=
e and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob=
-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at man=
y access routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted fr=
om the draft described above.


REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution sc=
enarios. This flexibility enables different IP multicast flows with respect=
 to a mobile host to be managed (e.g., subscribed, received and/or transmit=
ted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via a single endpoint (e.g. regular or tunnel =
interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].


Regards,

Seil

From: pierrick.seite@orange.com [mailto:p=
ierrick.seite@orange.com]
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it=
.pt; JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterD=
igital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that m=
y
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions bu=
t
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.




_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm


--_000_6E31144C030982429702B11D6746B98C364997C8SZXEML510MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











So, if we rephrase 7.1 as=



REQ7.1: Flexible multicas=
t distribution


DMM solutions should enab=
le multicast services which are compatible with (flexible?) multicast distr=
ibution scenario. Etc.



 <=
/p>

It will have the same int=
ention as REQ7.2 and REQ7.3.


 <=
/p>

Is that right?=



 <=
/p>



H Anthony Chan=





 <=
/p>





From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org=
]
On Behalf Of S=E9rgio Figueiredo

Sent: Monday, November 19, 2012 5:24 PM

To: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.



As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should enable multicast services which
 are compatible with multicast distribution scenario, etc.". It=
 seems like there is no major difference between this and the "DMM solutions should enable solutions to support
 multicast services." requirement? Aren't both expressing the n=
eed to enable multicast in a DMM solution?



As you stated, "neglecting" the requirement 7.1 we proposed, lead=
s to the PSs you referred.  So, while 7.2 and 7.3 express the need for=
 DMM solutions to allow deployment of multicast services, 7.1 concerns =
; "how" IP multicast should be enabled in order to avoid
 the aforementioned PSs. The usage of the word "flexible"is expla=
ined by: 



"This flexibility enables different I=
P multicast flows with respect to a mobile host to be managed (e.g., subscr=
ibed, received and/or transmitted) using
multiple endpoints". 



In other words, compatibility with "multicast distribution scenario&qu=
ot; doesn't necessarily avoid PS1 and PS6.



Thank you and best regards,

S=E9rgio



On 11/19/2012 10:28 PM, h chan wrote:






There are 3 proposals for=
 multicast requirements. Before comparing these proposals, let us understan=
d what are the problems first. Two problem statements have
 been proposed:


 <=
/p>

PS1 (revised): Non-optima=
l routes


Routing via a centrali=
zed anchor often results in a longer route. The problem is especially manif=
ested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



PS6: Duplicate multicast traffic=



IP multicast distribution=
 over architectures using IP mobility solutions  may lead to convergen=
ce of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 <=
/p>

Then, let us see whether =
all the 3 REQ proposals have the same intention. In the following, I rephra=
se them to highlight their similarities.


 <=
/p>

REQ7.1: Flexible multicas=
t distribution


DMM solutions should be c=
ompatible with flexible multicast distribution scenario. Etc.



The Motivation is to allo=
w flexibility in (enable) multicast solutions to solve the problems PS1 and=
 PS6 as explained in use cases already presented and discussed
 in multimob wg.


 <=
/p>

REQ7.2:



DMM solutions should enab=
le solutions to support multicast traffic.



 <=
/p>

(Original wording was &qu=
ot;The DMM (unicast) solution MUST be specified in such a way that it can b=
e extended to also support multicast traffic." I rephrase it
 to highlight the similarity with the other proposals and also changed the =
must to should.)


 <=
/p>

REQ7.3:=



DMM solutions should enab=
le solutions to support multicast services.


 <=
/p>

Original wording was R=
20;DMM solutions should support multicast services … etc. Given that =
it is the scope of multimob and not dmm wg to provide the multicast
 solution, I think “support” here means “enable” so=
lutions to be developed (by multimob).


 <=
/p>

Similarity and subtle dif=
ferences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet the=
 explanation in REQ7.1 seems to indicate not just to enable
 any one multicast solution but also needs the flexibility in multicast sol=
ution. Not all multicast solutions are the same. Some of them results in PS=
1 or PS6.



 <=
/p>



Are there any are essenti=
al differences between:


In REQ7.1, DMM solutions =
should be compatible with flexible multicast distribution scenario, etc.



Versus<=
/p>

DMM solutions should enab=
le multicast services which are compatible with multicast distribution scen=
ario, etc.


 <=
/p>

H Anthony Chan




 <=
/p>





From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Seil Jeon

Sent: Monday, November 19, 2012 5:15 AM

To: pierrick.seite@oran=
ge.com

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 


Hi Pierrick,


 


I’ve many times thought about your =
question. I would say how effectively should we deploy/support multicast ov=
er distributed mobility rather than distributed mobile multicast.
 As a result, you can find this deployment use case and gap analysis at 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 p=
resented in multimob several times.


 


In unicast DMM, main innovation is to dis=
tribute the anchor function at many access routers from single core. Follow=
ing architectural concept of DMM, flexible multicast distribution
 is one of multicast requirement resulted from the draft described above. <=
/span>



 


REQ8: Flexible multicast distribution<=
/p>

"DMM solutions SHOULD be compatible with flexible multicast d=
istribution scenarios. This flexibility enables different IP multicast flow=
s with respect to a mobile host to be managed
 (e.g., subscribed, received and/or transmitted) using multiple endpoints&q=
uot;. 



Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via
 a single endpoint (e.g. regular or tunnel interface), which would lead to =
the problems described in PS1 and PS6.


PS6: Duplicate multicast traffic


IP multicast distribu=
tion over architectures using IP mobility solutions  may lead to conve=
rgence of duplicated multicast subscriptions towards the tunnel’s dow=
nstream entity (e.g. MAG in PMIPv6).  Concretely,
 when multicast subscription for individual mobile nodes is coupled with mo=
bility tunnels, duplicate multicast subscription(s) is prone to be received=
 through different upstream paths. This problem is potentially more severe =
in a distributed mobility environment
 [draft-sfigueiredo-multimob-use-case-dmm-03].








Regards,


 


Seil


 






From:
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.=
com]


Sent: Monday, November 19, 2012 8:55 AM

To: 'karagian@cs.utwente.n=
l'; 
seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc: dmm@ietf.org

Subject: RE: [DMM] Multicast requirements






 


Hi all,


 =



I tend to agree with Geor=
gious, however I still do not figure out what is the use-case for distribut=
ed mobile multicast (other than academic considerations)?
 Can someone give concrete example? 


 <=
/p>

I haven’t real all =
messages from this thread. So, maybe I missed important points.=



 <=
/p>

BR,


Pierrick


 <=
/p>







De :
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.=
utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; 
JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should someho=
w consider muticast deployment. However, I do not thnk that the DMM WG is t=
he right WG to provide the multicast based DMM solution!<=
/p>

 


One alternative solution will be to have a multi=
cast requirement that emphasizes the need of having extensibility hooks (po=
ssibilities) that can be used later on by the multimob WG
 to provide a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like t=
he following could be used for this purpose:


 


"The DMM (unicast) solution MUST be sp=
ecified in such a way that it can be extended to also support multicast tra=
ffic."


 


 


Best regards,


Georgios


 


 


 





Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
[mailto:dmm-bounces@i=
etf.org]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.co=
m]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; Zun=
iga, Juan
 Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org

> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

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



_______________________________________________

dmm mailing list

dmm@ietf.org

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








____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.











_______________________________________________


dmm mailing list


dmm@ietf.org


https://www.ietf=
.org/mailman/listinfo/dmm




 






--_000_6E31144C030982429702B11D6746B98C364997C8SZXEML510MBXchi_--

From sfigueiredo@av.it.pt  Thu Nov 29 03:14:12 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9963721F8A03 for ; Thu, 29 Nov 2012 03:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIXxVVj6u-NF for ; Thu, 29 Nov 2012 03:14:05 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 94C3521F89F9 for ; Thu, 29 Nov 2012 03:14:03 -0800 (PST)
Received: from [193.55.113.196] (account sfigueiredo@av.it.pt HELO [172.24.10.15]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 67160961; Thu, 29 Nov 2012 11:14:00 +0000
Message-ID: <50B74378.6020300@av.it.pt>
Date: Thu, 29 Nov 2012 11:14:00 +0000
From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: h chan 
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt> 	<23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huaw	ei.com> <50AABF7D.9020003@av.it.pt> <6E31144C030982429702B11D6746B98C364997C8@SZXEML510-MBX.china.huawei.com>
In-Reply-To: <6E31144C030982429702B11D6746B98C364997C8@SZXEML510-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------060208090500080802070707"
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2012 11:14:12 -0000

This is a multi-part message in MIME format.
--------------060208090500080802070707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Anthony,

Sorry for the late answer. Please check my comments:

On 11/28/2012 12:44 AM, h chan wrote:
>
> So, if we rephrase 7.1 as
>
> REQ7.1: Flexible multicast distribution
>
> DMM solutions should enable multicast services which are compatible 
> with (flexible?) multicast distribution scenario. Etc.
>
SF: It is not clear to me why you are introducing the redundancy in the 
description. Do you mean it as it is?

> It will have the same intention as REQ7.2 and REQ7.3.
>
> Is that right?
>
I would say that REQ7.1 has the major intention of avoiding the referred 
problems, while REQ7.2 and REQ7.3 serve the purpose of stating multicast 
should "somehow" be supported in DMM solutions.

With REQ7.1, we want to assure the identified problems are avoided in a 
future DMM solution.

Best regards,
Sérgio
>
> H Anthony Chan
>
> *From:*dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] *On Behalf 
> Of *Sérgio Figueiredo
> *Sent:* Monday, November 19, 2012 5:24 PM
> *To:* dmm@ietf.org
> *Subject:* Re: [DMM] Multicast requirements
>
> Hi Anthony,
>
> Thank you for trying to progress on this matter. I mostly agree with 
> your analysis.
>
> As for the question you posed, first I would like to exactly 
> understand what you mean with "multicast distribution scenario" in 
> "DMM solutions should enable multicast services which are compatible 
> with multicast distribution scenario, etc.". It seems like there is no 
> major difference between this and the "DMM solutions should enable 
> solutions to support multicast services." requirement? Aren't both 
> expressing the need to enable multicast in a DMM solution?
>
> As you stated, "neglecting" the requirement 7.1 we proposed, leads to 
> the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 
> solutions to allow deployment of multicast services, 7.1 concerns  
> "how" IP multicast should be enabled in order to avoid the 
> aforementioned PSs. The usage of the word "flexible"is explained by:
>
> "This flexibility enables different IP multicast flows with respect to 
> a mobile host to be managed (e.g., subscribed, received and/or 
> transmitted) using multiple endpoints".
>
> In other words, compatibility with "multicast distribution scenario" 
> doesn't necessarily avoid PS1 and PS6.
>
> Thank you and best regards,
> Sérgio
>
> On 11/19/2012 10:28 PM, h chan wrote:
>
>     There are 3 proposals for multicast requirements. Before comparing
>     these proposals, let us understand what are the problems first.
>     Two problem statements have been proposed:
>
>     PS1 (revised): Non-optimal routes
>
>     Routing via a centralized anchor often results in a longer route.
>     The problem is especially manifested when accessing a local server
>     or servers of a Content Delivery Network (CDN), *or when receiving
>     / sending IP multicast packets*.
>
>     PS6: Duplicate multicast traffic
>
>     IP multicast distribution over architectures using IP mobility
>     solutions  may lead to convergence of duplicated multicast
>     subscriptions towards the tunnel's downstream entity (e.g. MAG in
>     PMIPv6).  Concretely, when multicast subscription for individual
>     mobile nodes is coupled with mobility tunnels, duplicate multicast
>     subscription(s) is prone to be received through different upstream
>     paths. This problem is potentially more severe in a distributed
>     mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>     Then, let us see whether all the 3 REQ proposals have the same
>     intention. In the following, I rephrase them to highlight their
>     similarities.
>
>     REQ7.1: Flexible multicast distribution
>
>     DMM solutions should be compatible with flexible multicast
>     distribution scenario. Etc.
>
>     The Motivation is to allow flexibility in (enable) multicast
>     solutions to solve the problems PS1 and PS6 as explained in use
>     cases already presented and discussed in multimob wg.
>
>     REQ7.2:
>
>     DMM solutions should enable solutions to support multicast traffic.
>
>     (Original wording was "The DMM (unicast) solution MUST be
>     specified in such a way that it can be extended to also support
>     multicast traffic." I rephrase it to highlight the similarity with
>     the other proposals and also changed the must to should.)
>
>     REQ7.3:
>
>     DMM solutions should enable solutions to support multicast services.
>
>     Original wording was "DMM solutions should support multicast
>     services ... etc. Given that it is the scope of multimob and not
>     dmm wg to provide the multicast solution, I think "support" here
>     means "enable" solutions to be developed (by multimob).
>
>     Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to
>     enable multicast services. Yet the explanation in REQ7.1 seems to
>     indicate not just to enable any one multicast solution but also
>     needs the flexibility in multicast solution. Not all multicast
>     solutions are the same. Some of them results in PS1 or PS6.
>
>     Are there any are essential differences between:
>
>     In REQ7.1, DMM solutions should be compatible with flexible
>     multicast distribution scenario, etc.
>
>     Versus
>
>     DMM solutions should enable multicast services which are
>     compatible with multicast distribution scenario, etc.
>
>     H Anthony Chan
>
>     *From:*dmm-bounces@ietf.org 
>     [mailto:dmm-bounces@ietf.org] *On Behalf Of *Seil Jeon
>     *Sent:* Monday, November 19, 2012 5:15 AM
>     *To:* pierrick.seite@orange.com 
>     *Cc:* dmm@ietf.org 
>     *Subject:* Re: [DMM] Multicast requirements
>
>     Hi Pierrick,
>
>     I've many times thought about your question. I would say how
>     effectively should we deploy/support multicast over distributed
>     mobility rather than distributed mobile multicast. As a result,
>     you can find this deployment use case and gap analysis at
>     http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
>     presented in multimob several times.
>
>     In unicast DMM, main innovation is to distribute the anchor
>     function at many access routers from single core. Following
>     architectural concept of DMM, flexible multicast distribution is
>     one of multicast requirement resulted from the draft described above.
>
>     REQ8: Flexible multicast distribution
>
>     "DMM solutions SHOULD be compatible with flexible multicast
>     distribution scenarios. This flexibility enables different IP
>     multicast flows with respect to a mobile host to be managed (e.g.,
>     subscribed, received and/or transmitted) using multiple endpoints".
>
>     Motivation: The motivation for this requirement is to enable
>     flexibility in multicast distribution. The multicast solution may
>     therefore avoid having multicast-capable access routers being
>     restricted to manage all IP multicast traffic relative to a host
>     via a single endpoint (e.g. regular or tunnel interface), which
>     would lead to the problems described in PS1 and PS6.
>
>     PS6: Duplicate multicast traffic
>
>     IP multicast distribution over architectures using IP mobility
>     solutions may lead to convergence of duplicated multicast
>     subscriptions towards the tunnel's downstream entity (e.g. MAG in
>     PMIPv6).  Concretely, when multicast subscription for individual
>     mobile nodes is coupled with mobility tunnels, duplicate multicast
>     subscription(s) is prone to be received through different upstream
>     paths. This problem is potentially more severe in a distributed
>     mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>
>     Regards,
>
>     Seil
>
>     *From:*pierrick.seite@orange.com
>      [mailto:pierrick.seite@orange.com]
>     *Sent:* Monday, November 19, 2012 8:55 AM
>     *To:* 'karagian@cs.utwente.nl ';
>     seiljeon@av.it.pt ;
>     JuanCarlos.Zuniga@InterDigital.com
>     
>     *Cc:* dmm@ietf.org 
>     *Subject:* RE: [DMM] Multicast requirements
>
>     Hi all,
>
>     I tend to agree with Georgious, however I still do not figure out
>     what is the use-case for distributed mobile multicast (other than
>     academic considerations)? Can someone give concrete example?
>
>     I haven't real all messages from this thread. So, maybe I missed
>     important points.
>
>     BR,
>
>     Pierrick
>
>     *De :*dmm-bounces@ietf.org 
>     [mailto:dmm-bounces@ietf.org] *De la part de*
>     karagian@cs.utwente.nl 
>     *Envoyé :* samedi 17 novembre 2012 13:01
>     *À :* seiljeon@av.it.pt ;
>     JuanCarlos.Zuniga@InterDigital.com
>     
>     *Cc :* dmm@ietf.org 
>     *Objet :* Re: [DMM] Multicast requirements
>
>     Hi all,
>
>     I also agree that the DMM solution should somehow consider
>     muticast deployment. However, I do not thnk that the DMM WG is the
>     right WG to provide the multicast based DMM solution!
>
>     One alternative solution will be to have a multicast requirement
>     that emphasizes the need of having extensibility hooks
>     (possibilities) that can be used later on by the multimob WG to
>     provide a
>
>     a multicast enabled DMM solution!
>
>     So a requirement that specifies something like the following could
>     be used for this purpose:
>
>     "The DMM (unicast) solution MUST be specified in such a way that
>     it can be extended to also support multicast traffic."
>
>     Best regards,
>
>     Georgios
>
>     ------------------------------------------------------------------------
>
>     *Van:*dmm-bounces@ietf.org
>     [dmm-bounces@ietf.org
>     ] namens Seil Jeon [seiljeon@av.it.pt
>     ]
>     *Verzonden:* vrijdag 16 november 2012 22:25
>     *To:* 'Zuniga, Juan Carlos'
>     *Cc:* dmm@ietf.org 
>     *Onderwerp:* Re: [DMM] Multicast requirements
>
>     Hi Juan,
>
>     I've been looked at changed flow of your proposed text but sorry
>     now that my
>     comment is posted.
>     At first time, I couldn't make sure however, on hearing Stig's
>     description,
>     it seems quite reasonable at the first step, not giving any
>     restrictions but
>     leaving some-specific for the DMM solution it does not support
>     multicast.
>
>     On the other hand, it remains at a basic stage for the DMM solution to
>     support multicast.
>     So I think additional requirements need to be made for the DMM
>     solution,
>     accordingly. But of course, this should not also give any specific
>     limitation and restriction but should be made towards the
>     direction not
>     limiting the benefits provided by distributed deployment.
>
>     I hope to get more comments on this.
>
>     Regards,
>
>     Seil
>
>
>     -----Original Message-----
>     From: dmm-bounces@ietf.org
>     [mailto:dmm-bounces@ietf.org] On
>     Behalf Of
>     Zuniga, Juan Carlos
>     Sent: Friday, November 16, 2012 8:14 PM
>     To: Stig Venaas; dmm@ietf.org 
>     Subject: Re: [DMM] Multicast requirements
>
>
>     > -----Original Message-----
>     > From: Stig Venaas [mailto:stig@venaas.com]
>     > Sent: Friday, November 16, 2012 3:01 PM
>     > To: jouni korhonen
>     > Cc: sarikaya@ieee.org ; Zuniga, Juan
>     Carlos; Konstantinos Pentikousis;
>     > Peter McCann; dmm@ietf.org 
>     > Subject: Re: [DMM] Multicast requirements
>     >
>     > On 11/15/2012 3:17 AM, jouni korhonen wrote:
>     > >
>     > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
>     > >
>     > >>
>     > >> I think we are reading too much into multicast and unicast should
>     be
>     > >> designed in an integrated manner.
>     > >>
>     > >> The fact is that multicast is considered as an area of
>     > specialization,
>     > >> it requires knowledge of very different protocols than we are
>     > >> accustomed to in mobility.
>     > >
>     > > "Requirement: DMM solutions SHOULD support multicast services.
>     If a
>     > specific DMM solution does not support multicast services, an
>     > explanation MUST be provided."
>     >
>     > This sounds good to me.
>     >
>     > The main thing I want to achieve is what was describes as
>     motivation
>     > earlier in this thread. Multicast should at least be considered
>     when
>     > looking into DMM solutions, and not just an afterthought once the
>     > solution is decided.
>     >
>     > Stig
>
>     [JCZ] I fully agree with this. That was the intention of the
>     proposed text.
>
>     Regards,
>
>     Juan Carlos
>
>     >
>     > > To me that reads basically "do not break foundations for multicast
>     > unless you have a valid & documented reason for it".  If we look
>     e.g.
>     > into RFC625 multicast wording that is there very briefly but
>     gives a
>     > hint to a developer where to head to. That is the level I would
>     expect
>     > DMM documents should aim to.
>     > >
>     > > - Jouni
>     > >
>     > >
>     > >> Let dmm deal with its current charter that does not include a
>     word
>     > of
>     > >> multicast and if everything goes well we can come back and
>     discuss
>     > dmm
>     > >> multicast.
>     > >>
>     > >> Regards,
>     > >>
>     > >> Behcet
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dmm
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dmm
>
>     _________________________________________________________________________________________________________________________
>
>       
>
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
>     France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>       
>
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>
>     they should not be distributed, used or copied without authorisation.
>
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>
>     As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
>
>     Thank you.
>
>
>
>
>     _______________________________________________
>
>     dmm mailing list
>
>     dmm@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/dmm
>


--------------060208090500080802070707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Anthony,

      

      Sorry for the late answer. Please check my comments:

      

      On 11/28/2012 12:44 AM, h chan wrote:

    

    

      
      
      
      
      

        
So,
            if we rephrase 7.1 as

        
REQ7.1:
            Flexible multicast distribution

        
DMM
            solutions should enable multicast services which are
            compatible with (flexible?) multicast distribution scenario.
            Etc.
          

      

    

    SF: It is not clear to me why you are introducing the redundancy in
    the description. Do you mean it as it is?

    

    

      

        

        
 

        
It
            will have the same intention as REQ7.2 and REQ7.3.

        
 

        
Is
            that right?

        
 

      

    

    I would say that REQ7.1 has the major intention of avoiding the
    referred problems, while REQ7.2 and REQ7.3 serve the purpose of
    stating multicast should "somehow" be supported in DMM solutions. 

    

    With REQ7.1, we want to assure the identified problems are avoided
    in a future DMM solution.

    

    Best regards,

    Sérgio

    

      

        

          
H
              Anthony Chan

        

        
 

        

          

            
From:
                dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
                On Behalf Of Sérgio Figueiredo

                Sent: Monday, November 19, 2012 5:24 PM

                To: dmm@ietf.org

                Subject: Re: [DMM] Multicast requirements

          

        

        
 

        

          
Hi Anthony,

            

            Thank you for trying to progress on this matter. I mostly
            agree with your analysis.

            

            As for the question you posed, first I would like to exactly
            understand what you mean with "multicast distribution
            scenario" in "DMM
              solutions should enable multicast services which are
              compatible with multicast distribution scenario, etc.".
            It seems like there is no major difference between this and
            the "DMM
              solutions should enable solutions to support multicast
              services." requirement? Aren't both expressing the
            need to enable multicast in a DMM solution?

            

            As you stated, "neglecting" the requirement 7.1 we proposed,
            leads to the PSs you referred.  So, while 7.2 and 7.3
            express the need for DMM solutions to allow deployment of
            multicast services, 7.1 concerns  "how" IP multicast should
            be enabled in order to avoid the aforementioned PSs. The
            usage of the word "flexible"is explained by: 

            

            "This flexibility enables
              different IP multicast flows with respect to a mobile host
              to be managed (e.g., subscribed, received and/or
              transmitted) using
            multiple endpoints". 

            

            In other words, compatibility with "multicast distribution
            scenario" doesn't necessarily avoid PS1 and PS6.

            

            Thank you and best regards,

            Sérgio

            

            On 11/19/2012 10:28 PM, h chan wrote:

        

        

          
There
              are 3 proposals for multicast requirements. Before
              comparing these proposals, let us understand what are the
              problems first. Two problem statements have been proposed:

          
 

          
PS1
              (revised): Non-optimal routes

          
Routing
              via a centralized anchor often results in a longer route.
              The problem is especially manifested when accessing a
              local server or servers of a Content Delivery Network
              (CDN), or when receiving / sending IP multicast
                packets.
            

          
PS6:
              Duplicate multicast traffic

          
IP
              multicast distribution over architectures using IP
              mobility solutions  may lead to convergence of duplicated
              multicast subscriptions towards the tunnel’s downstream
              entity (e.g. MAG in PMIPv6).  Concretely, when multicast
              subscription for individual mobile nodes is coupled with
              mobility tunnels, duplicate multicast subscription(s) is
              prone to be received through different upstream paths.
              This problem is potentially more severe in a distributed
              mobility environment
              [draft-sfigueiredo-multimob-use-case-dmm-03].

          
 

          
Then,
              let us see whether all the 3 REQ proposals have the same
              intention. In the following, I rephrase them to highlight
              their similarities.

          
 

          
REQ7.1:
              Flexible multicast distribution

          
DMM
              solutions should be compatible with flexible multicast
              distribution scenario. Etc.
            

          
The
              Motivation is to allow flexibility in (enable) multicast
              solutions to solve the problems PS1 and PS6 as explained
              in use cases already presented and discussed in multimob
              wg.

          
 

          
REQ7.2:
            

          
DMM
              solutions should enable solutions to support multicast
              traffic.
            

          
 

          
(Original
              wording was "The DMM (unicast) solution MUST be specified
              in such a way that it can be extended to also support
              multicast traffic." I rephrase it to highlight the
              similarity with the other proposals and also changed the
              must to should.)

          
 

          
REQ7.3:

          
DMM
              solutions should enable solutions to support multicast
              services.

          
 

          
Original
              wording was “DMM solutions should support multicast
              services … etc. Given that it is the scope of multimob and
              not dmm wg to provide the multicast solution, I think
              “support” here means “enable” solutions to be developed
              (by multimob).

          
 

          
Similarity
              and subtle differences: Both REQ7.2 and REQ7.3 want to
              enable multicast services. Yet the explanation in REQ7.1
              seems to indicate not just to enable any one multicast
              solution but also needs the flexibility in multicast
              solution. Not all multicast solutions are the same. Some
              of them results in PS1 or PS6.
            

          
 

          

            
Are
                there any are essential differences between:

            
In
                REQ7.1, DMM solutions should be compatible with flexible
                multicast distribution scenario, etc.
              

            
Versus

            
DMM
                solutions should enable multicast services which are
                compatible with multicast distribution scenario, etc.

            
 

            
H
                Anthony Chan

          

          
 

          

            

              
From:
                  dmm-bounces@ietf.org
                  [mailto:dmm-bounces@ietf.org]
                  On Behalf Of Seil Jeon

                  Sent: Monday, November 19, 2012 5:15 AM

                  To: pierrick.seite@orange.com

                  Cc: dmm@ietf.org

                  Subject: Re: [DMM] Multicast requirements

            

          

          
 

          
Hi
              Pierrick,

          
 

          
I’ve
              many times thought about your question. I would say how
              effectively should we deploy/support multicast over
              distributed mobility rather than distributed mobile
              multicast. As a result, you can find this deployment use
              case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
              presented in multimob several times.

          
 

          
In
              unicast DMM, main innovation is to distribute the anchor
              function at many access routers from single core.
              Following architectural concept of DMM, flexible multicast
              distribution is one of multicast requirement resulted from
              the draft described above. 
            

          
 

          
REQ8: Flexible multicast distribution

          
"DMM
            solutions SHOULD be compatible with flexible multicast
            distribution scenarios. This flexibility enables different
            IP multicast flows with respect to a mobile host to be
            managed (e.g., subscribed, received and/or transmitted)
            using multiple endpoints". 

            

            Motivation: The motivation for this requirement is to enable
            flexibility in multicast distribution. The multicast
            solution may therefore avoid having multicast-capable access
            routers being restricted to manage all IP multicast traffic
            relative to a host via a single endpoint (e.g. regular or
            tunnel interface), which would lead to the problems
            described in PS1 and PS6.

          
PS6:
            Duplicate multicast traffic

          
IP multicast
            distribution over architectures using IP mobility solutions 
            may lead to convergence of duplicated multicast
            subscriptions towards the tunnel’s downstream entity (e.g.
            MAG in PMIPv6).  Concretely, when multicast subscription for
            individual mobile nodes is coupled with mobility tunnels,
            duplicate multicast subscription(s) is prone to be received
            through different upstream paths. This problem is
            potentially more severe in a distributed mobility
            environment [draft-sfigueiredo-multimob-use-case-dmm-03].

            

            

            

          
Regards,

          
 

          
Seil

          
 

          

            

              
From:
                  pierrick.seite@orange.com
                  [mailto:pierrick.seite@orange.com]
                  

                  Sent: Monday, November 19, 2012 8:55 AM

                  To: 'karagian@cs.utwente.nl';
                  
                    seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

                  Cc: dmm@ietf.org

                  Subject: RE: [DMM] Multicast requirements

            

          

          
 

          
Hi all,

          
 

          
I
              tend to agree with Georgious, however I still do not
              figure out what is the use-case for distributed mobile
              multicast (other than academic considerations)? Can
              someone give concrete example? 

          
 

          
I
              haven’t real all messages from this thread. So, maybe I
              missed important points.

          
 

          
BR,

          
Pierrick

          
 

          

            

              

                
De :
                    dmm-bounces@ietf.org
                    [mailto:dmm-bounces@ietf.org]
                    De la part de karagian@cs.utwente.nl

                    Envoyé : samedi 17 novembre 2012 13:01

                    À : seiljeon@av.it.pt;
                    
                      JuanCarlos.Zuniga@InterDigital.com

                    Cc : dmm@ietf.org

                    Objet : Re: [DMM] Multicast requirements

              

            

            
 

            

              
Hi all,

              
 

              
I also agree that the DMM solution should
                  somehow consider muticast deployment. However, I do
                  not thnk that the DMM WG is the right WG to provide
                  the multicast based DMM solution!

              
 

              
One alternative solution will be to have a
                  multicast requirement that emphasizes the need of
                  having extensibility hooks (possibilities) that can be
                  used later on by the multimob WG to provide a 

              
a multicast enabled DMM solution!

              
 

              
 

              
So a requirement that specifies something
                  like the following could be used for this purpose:

              
 

              
"The DMM (unicast) solution MUST be
                  specified in such a way that it can be extended to
                  also support multicast traffic."

              
 

              
 

              
Best regards,

              
Georgios

              
 

              
 

              
 

              

                

                    

                  

                

                  
Van:
                    dmm-bounces@ietf.org
                      [dmm-bounces@ietf.org]
                      namens Seil Jeon [seiljeon@av.it.pt]

                      Verzonden: vrijdag 16 november 2012 22:25

                      To: 'Zuniga, Juan Carlos'

                      Cc: dmm@ietf.org

                      Onderwerp: Re: [DMM] Multicast requirements

                

              

              

                
Hi Juan,

                    

                    I've been looked at changed flow of your proposed
                    text but sorry now that my

                    comment is posted.

                    At first time, I couldn't make sure however, on
                    hearing Stig's description,

                    it seems quite reasonable at the first step, not
                    giving any restrictions but

                    leaving some-specific for the DMM solution it does
                    not support multicast.

                    

                    On the other hand, it remains at a basic stage for
                    the DMM solution to

                    support multicast.

                    So I think additional requirements need to be made
                    for the DMM solution,

                    accordingly. But of course, this should not also
                    give any specific

                    limitation and restriction but should be made
                    towards the direction not

                    limiting the benefits provided by distributed
                    deployment.

                    

                    I hope to get more comments on this.

                    

                  Regards,

                    

                    Seil

                    

                    

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

                    From: dmm-bounces@ietf.org
                  [mailto:dmm-bounces@ietf.org]
                    On Behalf Of

                    Zuniga, Juan Carlos

                    Sent: Friday, November 16, 2012 8:14 PM

                    To: Stig Venaas; dmm@ietf.org

                    Subject: Re: [DMM] Multicast requirements

                    

                    

                    > -----Original Message-----

                    > From: Stig Venaas [mailto:stig@venaas.com]

                    > Sent: Friday, November 16, 2012 3:01 PM

                    > To: jouni korhonen

                    > Cc: sarikaya@ieee.org;
                    Zuniga, Juan Carlos; Konstantinos Pentikousis; 

                    > Peter McCann; dmm@ietf.org

                    > Subject: Re: [DMM] Multicast requirements

                    > 

                    > On 11/15/2012 3:17 AM, jouni korhonen wrote:

                    > >

                    > > On Nov 15, 2012, at 1:03 AM, Behcet
                    Sarikaya wrote:

                    > >

                    > >>

                    > >> I think we are reading too much into
                    multicast and unicast should

                    be

                    > >> designed in an integrated manner.

                  > >>

                    > >> The fact is that multicast is
                    considered as an area of

                    > specialization,

                    > >> it requires knowledge of very
                    different protocols than we are 

                    > >> accustomed to in mobility.

                    > >

                    > > "Requirement: DMM solutions SHOULD support
                    multicast services. If a

                    > specific DMM solution does not support
                    multicast services, an 

                    > explanation MUST be provided."

                    > 

                    > This sounds good to me.

                    > 

                    > The main thing I want to achieve is what was
                    describes as motivation 

                    > earlier in this thread. Multicast should at
                    least be considered when 

                    > looking into DMM solutions, and not just an
                    afterthought once the 

                    > solution is decided.

                    > 

                    > Stig

                    

                    [JCZ] I fully agree with this. That was the
                    intention of the proposed text.

                    

                    Regards,

                    

                    Juan Carlos

                     

                    > 

                    > > To me that reads basically "do not break
                    foundations for multicast

                    > unless you have a valid & documented reason
                    for it".  If we look e.g.

                    > into RFC625 multicast wording that is there
                    very briefly but gives a 

                    > hint to a developer where to head to. That is
                    the level I would expect 

                    > DMM documents should aim to.

                    > >

                    > > - Jouni

                    > >

                    > >

                    > >> Let dmm deal with its current charter
                    that does not include a word

                    > of

                    > >> multicast and if everything goes well
                    we can come back and discuss

                    > dmm

                    > >> multicast.

                  >
                    >>

                    > >> Regards,

                    > >>

                    > >> Behcet

                    

                    _______________________________________________

                    dmm mailing list

                  dmm@ietf.org

                  https://www.ietf.org/mailman/listinfo/dmm

                    

                    _______________________________________________

                    dmm mailing list

                  dmm@ietf.org

                  https://www.ietf.org/mailman/listinfo/dmm

              

            

          

          
_________________________________________________________________________________________________________________________

          
 

          
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

          
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

          
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

          
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

          
 

          
This message and its attachments may contain confidential or privileged information that may be protected by law;

          
they should not be distributed, used or copied without authorisation.

          
If you have received this email in error, please notify the sender and delete this message and its attachments.

          
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.

          
Thank you.

          


            

            

            

          
_______________________________________________

          
dmm mailing list

          
dmm@ietf.org

          
https://www.ietf.org/mailman/listinfo/dmm

        

        
 

      

    

    

  


--------------060208090500080802070707--

From h.anthony.chan@huawei.com  Thu Nov 29 07:52:12 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7799521F87B6 for ; Thu, 29 Nov 2012 07:52:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.411
X-Spam-Level: 
X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3YWJO-RHX30 for ; Thu, 29 Nov 2012 07:52:03 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 98C1A21F888D for ; Thu, 29 Nov 2012 07:52:01 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMA44401; Thu, 29 Nov 2012 15:51:33 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 15:51:18 +0000
Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 15:51:31 +0000
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.230]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.003; Thu, 29 Nov 2012 23:51:28 +0800
From: h chan 
To: =?iso-8859-1?Q?S=E9rgio_Figueiredo?= 
Thread-Topic: [DMM] Multicast requirements
Thread-Index: AQHNziNdgoKnfd0evEGyVfzIxNahDJgA89SQ
Date: Thu, 29 Nov 2012 15:51:27 +0000
Message-ID: <6E31144C030982429702B11D6746B98C3649E619@SZXEML510-MBS.china.huawei.com>
References: <2D141E08-F92E-441F-B087-8131006CD1DA@gmail.com> <61CEE523-F244-486B-AA95-591828D53EED@gmail.com>  <8D38716F0C1A444BA0CD7E96454366C23A4EEAD9@szxeml545-mbx.china.huawei.com>   <500AAC16-8FB4-4E63-A76E-CB9AEF635D63@gmail.com> <50A69B8C.6050309@venaas.com> , <000601cdc440$ef947f50$cebd7df0$@av.it.pt> 	<23120_1353315327_ 50A9F3FF_23120_281_1_8 1C77F07008CA24F9783A98CFD706F7106F2F7@PEXCVZYM12.corporate.adroot.infra.ftgroup> <008801cdc647$16916f20$43b44d60$@av.it.pt> <6E31144C030982429702B11D6746B98C36494729@SZXEML510-MBS.china.huaw	ei.com> <50AABF7D.9020003@av.it.pt> <6E31144C030982429702B11D6746B98C364997C8@SZXEML510-MBX.china.huawei.com> <50B74378.6020300@av.it.pt>
In-Reply-To: <50B74378.6020300@av.it.pt>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.154.82]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C3649E619SZXEML510MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Multicast requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2012 15:52:12 -0000

--_000_6E31144C030982429702B11D6746B98C3649E619SZXEML510MBSchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sergio,

The intentions of both 7.2 and 7.3 are to enable multicast solutions can be=
 developed by the multimob wg after dmm solutions have been developed by dm=
m wg.
In addition, I think multimob wg is concerned not only to be able to develo=
p "any" multicast solutions, but the multicast solutions that will not have=
 performance problems as investigated in the problem statements.

Therefore, I guess we can converge all three requirements 7.1, 7.2, and 7.3=
 into one single requirement by taking into consideration all these three r=
equirements.

H Anthony Chan

From: S=E9rgio Figueiredo [mailto:sfigueiredo@av.it.pt]
Sent: Thursday, November 29, 2012 5:14 AM
To: h chan
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Sorry for the late answer. Please check my comments:

On 11/28/2012 12:44 AM, h chan wrote:
So, if we rephrase 7.1 as
REQ7.1: Flexible multicast distribution
DMM solutions should enable multicast services which are compatible with (f=
lexible?) multicast distribution scenario. Etc.
SF: It is not clear to me why you are introducing the redundancy in the des=
cription. Do you mean it as it is?



It will have the same intention as REQ7.2 and REQ7.3.

Is that right?

I would say that REQ7.1 has the major intention of avoiding the referred pr=
oblems, while REQ7.2 and REQ7.3 serve the purpose of stating multicast shou=
ld "somehow" be supported in DMM solutions.

With REQ7.1, we want to assure the identified problems are avoided in a fut=
ure DMM solution.

Best regards,
S=E9rgio

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of S=E9rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.

As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should =
enable multicast services which are compatible with multicast distribution =
scenario, etc.". It seems like there is no major difference between this an=
d the "DMM solutions should enable solutions to support multicast services.=
" requirement? Aren't both expressing the need to enable multicast in a DMM=
 solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the P=
Ss you referred.  So, while 7.2 and 7.3 express the need for DMM solutions =
to allow deployment of multicast services, 7.1 concerns  "how" IP multicast=
 should be enabled in order to avoid the aforementioned PSs. The usage of t=
he word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mo=
bile host to be managed (e.g., subscribed, received and/or transmitted) usi=
ng multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn'=
t necessarily avoid PS1 and PS6.

Thank you and best regards,
S=E9rgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these pr=
oposals, let us understand what are the problems first. Two problem stateme=
nts have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The probl=
em is especially manifested when accessing a local server or servers of a C=
ontent Delivery Network (CDN), or when receiving / sending IP multicast pac=
kets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. I=
n the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution sce=
nario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to s=
olve the problems PS1 and PS6 as explained in use cases already presented a=
nd discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such=
 a way that it can be extended to also support multicast traffic." I rephra=
se it to highlight the similarity with the other proposals and also changed=
 the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was "DMM solutions should support multicast services ... e=
tc. Given that it is the scope of multimob and not dmm wg to provide the mu=
lticast solution, I think "support" here means "enable" solutions to be dev=
eloped (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable mu=
lticast services. Yet the explanation in REQ7.1 seems to indicate not just =
to enable any one multicast solution but also needs the flexibility in mult=
icast solution. Not all multicast solutions are the same. Some of them resu=
lts in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distr=
ibution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with mu=
lticast distribution scenario, etc.

H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.seite@orange.com
Cc: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively sh=
ould we deploy/support multicast over distributed mobility rather than dist=
ributed mobile multicast. As a result, you can find this deployment use cas=
e and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob=
-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at man=
y access routers from single core. Following architectural concept of DMM, =
flexible multicast distribution is one of multicast requirement resulted fr=
om the draft described above.


REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution sc=
enarios. This flexibility enables different IP multicast flows with respect=
 to a mobile host to be managed (e.g., subscribed, received and/or transmit=
ted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via a single endpoint (e.g. regular or tunnel =
interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  m=
ay lead to convergence of duplicated multicast subscriptions towards the tu=
nnel's downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast =
subscription for individual mobile nodes is coupled with mobility tunnels, =
duplicate multicast subscription(s) is prone to be received through differe=
nt upstream paths. This problem is potentially more severe in a distributed=
 mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].



Regards,

Seil

From: pierrick.seite@orange.com [mailto:p=
ierrick.seite@orange.com]
Sent: Monday, November 19, 2012 8:55 AM
To: 'karagian@cs.utwente.nl'; seiljeon@av.it=
.pt; JuanCarlos.Zuniga@InterDigital.com
Cc: dmm@ietf.org
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is t=
he use-case for distributed mobile multicast (other than academic considera=
tions)? Can someone give concrete example?

I haven't real all messages from this thread. So, maybe I missed important =
points.

BR,
Pierrick

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : samedi 17 novembre 2012 13:01
=C0 : seiljeon@av.it.pt; JuanCarlos.Zuniga@InterD=
igital.com
Cc : dmm@ietf.org
Objet : Re: [DMM] Multicast requirements


Hi all,



I also agree that the DMM solution should somehow consider muticast deploym=
ent. However, I do not thnk that the DMM WG is the right WG to provide the =
multicast based DMM solution!



One alternative solution will be to have a multicast requirement that empha=
sizes the need of having extensibility hooks (possibilities) that can be us=
ed later on by the multimob WG to provide a

a multicast enabled DMM solution!





So a requirement that specifies something like the following could be used =
for this purpose:



"The DMM (unicast) solution MUST be specified in such a way that it can be =
extended to also support multicast traffic."





Best regards,

Georgios







________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.or=
g] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that m=
y
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions bu=
t
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil


-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements


> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: sarikaya@ieee.org; Zuniga, Juan Carlos; Kon=
stantinos Pentikousis;
> Peter McCann; dmm@ietf.org
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.





_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm



--_000_6E31144C030982429702B11D6746B98C3649E619SZXEML510MBSchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Sergio,=



 <=
/p>

The intentions of both 7.=
2 and 7.3 are to enable multicast solutions can be developed by the multimo=
b wg after dmm solutions have been developed by dmm wg.



In addition, I think mult=
imob wg is concerned not only to be able to develop “any” multi=
cast solutions, but the multicast solutions that will not have performance
 problems as investigated in the problem statements. 


 <=
/p>

Therefore, I guess we can=
 converge all three requirements 7.1, 7.2, and 7.3 into one single requirem=
ent by taking into consideration all these three requirements.



 <=
/p>



H Anthony Chan=





 <=
/p>





From: S=E9rgio Figueiredo [mailto:sfigueiredo@av.it.pt]


Sent: Thursday, November 29, 2012 5:14 AM

To: h chan

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Sorry for the late answer. Please check my comments:



On 11/28/2012 12:44 AM, h chan wrote:






So, if we rephrase 7.1 as=



REQ7.1: Flexible multicas=
t distribution


DMM solutions should enab=
le multicast services which are compatible with (flexible?) multicast distr=
ibution scenario. Etc.





SF: It is not clear to me why you are introducing th=
e redundancy in the description. Do you mean it as it is?








 <=
/p>

It will have the same int=
ention as REQ7.2 and REQ7.3.


 <=
/p>

Is that right?


 <=
/p>

I would say that REQ7.1 has the major intention of a=
voiding the referred problems, while REQ7.2 and REQ7.3 serve the purpose of=
 stating multicast should "somehow" be supported in DMM solutions=
.




With REQ7.1, we want to assure the identified problems are avoided in a fut=
ure DMM solution.



Best regards,

S=E9rgio








H Anthony Chan




 <=
/p>





From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of S=E9rgio Figueiredo

Sent: Monday, November 19, 2012 5:24 PM

To: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 




Hi Anthony,



Thank you for trying to progress on this matter. I mostly agree with your a=
nalysis.



As for the question you posed, first I would like to exactly understand wha=
t you mean with "multicast distribution scenario" in "DMM solutions should enable multicast services which
 are compatible with multicast distribution scenario, etc.". It=
 seems like there is no major difference between this and the "DMM solutions should enable solutions to support
 multicast services." requirement? Aren't both expressing the n=
eed to enable multicast in a DMM solution?



As you stated, "neglecting" the requirement 7.1 we proposed, lead=
s to the PSs you referred.  So, while 7.2 and 7.3 express the need for=
 DMM solutions to allow deployment of multicast services, 7.1 concerns =
; "how" IP multicast should be enabled in order to avoid
 the aforementioned PSs. The usage of the word "flexible"is expla=
ined by: 



"This flexibility enables different I=
P multicast flows with respect to a mobile host to be managed (e.g., subscr=
ibed, received and/or transmitted) using
multiple endpoints". 



In other words, compatibility with "multicast distribution scenario&qu=
ot; doesn't necessarily avoid PS1 and PS6.



Thank you and best regards,

S=E9rgio



On 11/19/2012 10:28 PM, h chan wrote:






There are 3 proposals for=
 multicast requirements. Before comparing these proposals, let us understan=
d what are the problems first. Two problem statements have
 been proposed:


 <=
/p>

PS1 (revised): Non-optima=
l routes


Routing via a centrali=
zed anchor often results in a longer route. The problem is especially manif=
ested when accessing a local server or servers of a Content
 Delivery Network (CDN), or when receiving / sending IP multicast packet=
s.



PS6: Duplicate multicast traffic=



IP multicast distribution=
 over architectures using IP mobility solutions  may lead to convergen=
ce of duplicated multicast subscriptions towards the tunnel’s
 downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast s=
ubscription for individual mobile nodes is coupled with mobility tunnels, d=
uplicate multicast subscription(s) is prone to be received through differen=
t upstream paths. This problem is potentially
 more severe in a distributed mobility environment [draft-sfigueiredo-multi=
mob-use-case-dmm-03].


 <=
/p>

Then, let us see whether =
all the 3 REQ proposals have the same intention. In the following, I rephra=
se them to highlight their similarities.


 <=
/p>

REQ7.1: Flexible multicas=
t distribution


DMM solutions should be c=
ompatible with flexible multicast distribution scenario. Etc.



The Motivation is to allo=
w flexibility in (enable) multicast solutions to solve the problems PS1 and=
 PS6 as explained in use cases already presented and discussed
 in multimob wg.


 <=
/p>

REQ7.2:



DMM solutions should enab=
le solutions to support multicast traffic.



 <=
/p>

(Original wording was &qu=
ot;The DMM (unicast) solution MUST be specified in such a way that it can b=
e extended to also support multicast traffic." I rephrase it
 to highlight the similarity with the other proposals and also changed the =
must to should.)


 <=
/p>

REQ7.3:=



DMM solutions should enab=
le solutions to support multicast services.


 <=
/p>

Original wording was R=
20;DMM solutions should support multicast services … etc. Given that =
it is the scope of multimob and not dmm wg to provide the multicast
 solution, I think “support” here means “enable” so=
lutions to be developed (by multimob).


 <=
/p>

Similarity and subtle dif=
ferences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet the=
 explanation in REQ7.1 seems to indicate not just to enable
 any one multicast solution but also needs the flexibility in multicast sol=
ution. Not all multicast solutions are the same. Some of them results in PS=
1 or PS6.



 <=
/p>



Are there any are essenti=
al differences between:


In REQ7.1, DMM solutions =
should be compatible with flexible multicast distribution scenario, etc.



Versus<=
/p>

DMM solutions should enab=
le multicast services which are compatible with multicast distribution scen=
ario, etc.


 <=
/p>

H Anthony Chan




 <=
/p>





From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Seil Jeon

Sent: Monday, November 19, 2012 5:15 AM

To: pierrick.seite@oran=
ge.com

Cc: dmm@ietf.org

Subject: Re: [DMM] Multicast requirements






 


Hi Pierrick,


 


I’ve many times thought about your =
question. I would say how effectively should we deploy/support multicast ov=
er distributed mobility rather than distributed mobile multicast.
 As a result, you can find this deployment use case and gap analysis at 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 p=
resented in multimob several times.


 


In unicast DMM, main innovation is to dis=
tribute the anchor function at many access routers from single core. Follow=
ing architectural concept of DMM, flexible multicast distribution
 is one of multicast requirement resulted from the draft described above. <=
/span>



 


REQ8: Flexible multicast distribution<=
/p>

"DMM solutions SHOULD be compatible with flexible multicast d=
istribution scenarios. This flexibility enables different IP multicast flow=
s with respect to a mobile host to be managed
 (e.g., subscribed, received and/or transmitted) using multiple endpoints&q=
uot;. 



Motivation: The motivation for this requirement is to enable flexibility in=
 multicast distribution. The multicast solution may therefore avoid having =
multicast-capable access routers being restricted to manage all IP multicas=
t traffic relative to a host via
 a single endpoint (e.g. regular or tunnel interface), which would lead to =
the problems described in PS1 and PS6.


PS6: Duplicate multicast traffic


IP multicast distribu=
tion over architectures using IP mobility solutions  may lead to conve=
rgence of duplicated multicast subscriptions towards the tunnel’s dow=
nstream entity (e.g. MAG in PMIPv6).  Concretely,
 when multicast subscription for individual mobile nodes is coupled with mo=
bility tunnels, duplicate multicast subscription(s) is prone to be received=
 through different upstream paths. This problem is potentially more severe =
in a distributed mobility environment
 [draft-sfigueiredo-multimob-use-case-dmm-03].










Regards,


 


Seil


 






From:
pierrick.seite@orange.com =
[mailto:pierrick.seite@orange.=
com]


Sent: Monday, November 19, 2012 8:55 AM

To: 'karagian@cs.utwente.n=
l'; 
seiljeon@av.it.pt; JuanCarlos.Zuniga@InterDigital.com

Cc: dmm@ietf.org

Subject: RE: [DMM] Multicast requirements






 


Hi all,


 =



I tend to agree with Geor=
gious, however I still do not figure out what is the use-case for distribut=
ed mobile multicast (other than academic considerations)?
 Can someone give concrete example? 


 <=
/p>

I haven’t real all =
messages from this thread. So, maybe I missed important points.=



 <=
/p>

BR,


Pierrick


 <=
/p>







De :
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
De la part de karagian@cs.=
utwente.nl

Envoy=E9 : samedi 17 novembre 2012 13:01

=C0 : seiljeon@av.it.pt; 
JuanCarlos.Zuniga@InterDigital.com

Cc : dmm@ietf.org

Objet : Re: [DMM] Multicast requirements






 




Hi all,


 


I also agree that the DMM solution should someho=
w consider muticast deployment. However, I do not thnk that the DMM WG is t=
he right WG to provide the multicast based DMM solution!<=
/p>

 


One alternative solution will be to have a multi=
cast requirement that emphasizes the need of having extensibility hooks (po=
ssibilities) that can be used later on by the multimob WG
 to provide a 


a multicast enabled DMM solution!


 


 


So a requirement that specifies something like t=
he following could be used for this purpose:


 


"The DMM (unicast) solution MUST be sp=
ecified in such a way that it can be extended to also support multicast tra=
ffic."


 


 


Best regards,


Georgios


 


 


 












Van:
dmm-bounces@ietf.org
[dmm-bounces@iet=
f.org] namens Seil Jeon [seiljeon@=
av.it.pt]

Verzonden: vrijdag 16 november 2012 22:25

To: 'Zuniga, Juan Carlos'

Cc: <=
span lang=3D"EN-US">dmm@ietf.org

Onderwerp: Re: [DMM] Multicast requirements








Hi Juan,



I've been looked at changed flow of your proposed text but sorry now that m=
y

comment is posted.

At first time, I couldn't make sure however, on hearing Stig's description,=


it seems quite reasonable at the first step, not giving any restrictions bu=
t

leaving some-specific for the DMM solution it does not support multicast.


On the other hand, it remains at a basic stage for the DMM solution to

support multicast.

So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific

limitation and restriction but should be made towards the direction not

limiting the benefits provided by distributed deployment.



I hope to get more comments on this.



Regards,



Seil





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

From: dmm-bounces@ietf.org
[mailto:dmm-bounces@i=
etf.org]
 On Behalf Of

Zuniga, Juan Carlos

Sent: Friday, November 16, 2012 8:14 PM

To: Stig Venaas; dmm@ietf.org

Subject: Re: [DMM] Multicast requirements





> -----Original Message-----

> From: Stig Venaas [mailto:stig@venaas.co=
m]

> Sent: Friday, November 16, 2012 3:01 PM

> To: jouni korhonen

> Cc: sarikaya@ieee.org; Zun=
iga, Juan
 Carlos; Konstantinos Pentikousis; 

> Peter McCann; dmm@ietf.org

> Subject: Re: [DMM] Multicast requirements

> 

> On 11/15/2012 3:17 AM, jouni korhonen wrote:

> >

> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:

> >

> >>

> >> I think we are reading too much into multicast and unicast sh=
ould

be

> >> designed in an integrated manner.

> >>

> >> The fact is that multicast is considered as an area of

> specialization,

> >> it requires knowledge of very different protocols than we are=
 

> >> accustomed to in mobility.

> >

> > "Requirement: DMM solutions SHOULD support multicast service=
s. If a

> specific DMM solution does not support multicast services, an 

> explanation MUST be provided."

> 

> This sounds good to me.

> 

> The main thing I want to achieve is what was describes as motivation <=
br>
> earlier in this thread. Multicast should at least be considered when <=
br>
> looking into DMM solutions, and not just an afterthought once the 

> solution is decided.

> 

> Stig



[JCZ] I fully agree with this. That was the intention of the proposed text.=




Regards,



Juan Carlos

 

> 

> > To me that reads basically "do not break foundations for mul=
ticast

> unless you have a valid & documented reason for it".  If=
 we look e.g.

> into RFC625 multicast wording that is there very briefly but gives a <=
br>
> hint to a developer where to head to. That is the level I would expect=
 

> DMM documents should aim to.

> >

> > - Jouni

> >

> >

> >> Let dmm deal with its current charter that does not include a=
 word

> of

> >> multicast and if everything goes well we can come back and di=
scuss

> dmm

> >> multicast.

> >>

> >> Regards,

> >>

> >> Behcet



_______________________________________________

dmm mailing list

dmm@ietf.org

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



_______________________________________________

dmm mailing list

dmm@ietf.org

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








____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.













_______________________________________________


dmm mailing list


dmm@ietf.org


https://www.ietf=
.org/mailman/listinfo/dmm




 


 






--_000_6E31144C030982429702B11D6746B98C3649E619SZXEML510MBSchi_--

From sarikaya2012@gmail.com  Thu Nov 29 12:23:58 2012
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4510D21F8B60 for ; Thu, 29 Nov 2012 12:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.582
X-Spam-Level: 
X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEARPiWkdw14 for ; Thu, 29 Nov 2012 12:23:44 -0800 (PST)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D34B321F8A9C for ; Thu, 29 Nov 2012 12:23:41 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id j26so12176836iaf.31 for ; Thu, 29 Nov 2012 12:23:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MH4Uio46+xGPxhRe8M5V7dsYdu1hKS1FbZXhmMFPN2o=; b=JaplK/xylLc21dQWkP9QGn941McpWHyNxzKW9fdPix4QkbtM5gTjzqVUTnUhGv2Kkb xotCooiqv5+s7iGgn9X5e8HaHQO/A4vU13u010EUilASUMKC8WEanWB712lRpEtRaj1w Trz08xWdLD356HpV6lv+VeVwO+1WO7igs60EgwRkINgjbTrsHNVDX8VWrOMv8+uRfKbw wrP4ma7gWoWt6QcGHZqQeA/6dzZRbsaTYWR9W4euxnMZ46rZFuFodPo9S0dRBXj2EGP4 SUrZhbHTzObIHxEWwSAA+HZfIia8LeX/2qTmQKW6i0H3U9T5XCAh4XfVe7tXi0HSM1AW 9XWQ==
MIME-Version: 1.0
Received: by 10.50.152.240 with SMTP id vb16mr24570014igb.45.1354220620474; Thu, 29 Nov 2012 12:23:40 -0800 (PST)
Received: by 10.231.10.204 with HTTP; Thu, 29 Nov 2012 12:23:40 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 29 Nov 2012 14:23:40 -0600
Message-ID: 
From: Behcet Sarikaya 
To: karagian@cs.utwente.nl
Content-Type: multipart/alternative; boundary=e89a8f3ba01b07ea0304cfa80fbe
Cc: dmm@ietf.org
Subject: Re: [DMM] Requirements on cmm
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2012 20:23:58 -0000

--e89a8f3ba01b07ea0304cfa80fbe
Content-Type: text/plain; charset=ISO-8859-1

I suggest rewording these tow requirements as follows:

Requirement 1.
"The DMM solution MAY have the ability to be applied in virtualized
architectures."

Requirement 2.

The DMM solution MAY have the ability support more than one virtual
networks in the same DMM domain.


Regards,

Behcet

--e89a8f3ba01b07ea0304cfa80fbe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I suggest rewording these tow requirements as follows:

Requirement 1=
.
"The DMM solution MAY have the ability to be applied in virtualiz=
ed=A0 architectures."

Requirement 2.

The DMM solution MA=
Y have the ability support more than one virtual networks in the same DMM d=
omain.



Regards,

Behcet




--e89a8f3ba01b07ea0304cfa80fbe--