From alper.yegin@yegin.org Tue Nov 3 01:48:23 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3B43A69A4 for ; Tue, 3 Nov 2009 01:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W+zVXMe9CCK for ; Tue, 3 Nov 2009 01:48:22 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 297D43A687D for ; Tue, 3 Nov 2009 01:48:22 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MIL5z-1N17fi1Cal-0040n8; Tue, 03 Nov 2009 04:48:39 -0500 From: "Alper Yegin" To: "'Sri Gundavelli'" , "'Jari Arkko'" References: In-Reply-To: Date: Tue, 3 Nov 2009 11:48:32 +0200 Message-ID: <011c01ca5c6a$d20badf0$762309d0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpXf5VAyIJ/G7WqRcGfCWlvcZWDvQE6v97Q Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1/VlTlwdSwKsAp8YWa/+J5XinniNkXsZU1yihz HhUzKAgLIsTA1cXSsXjGoYsDQdnbY3q5AGxWqxEI+B7FGLmKor 6n0b54Mf+l9kGWnYLoTpQ== Cc: netext@ietf.org Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:48:23 -0000 I agree. Also, I don't quite understand how a L2-only solution would help with inter-technology handovers between two distinct access technology. A handover between IEEE 802.11b and 11a is one thing, between 11b and 16 is another. So, I'm not sure if option 1 really solves the problem. Alper > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Sri Gundavelli > Sent: Wednesday, October 28, 2009 5:35 AM > To: Jari Arkko > Cc: netext@ietf.org > Subject: Re: [netext] NETEXT2 BOF conclusion > > > Hi Jari, > > Thanks for the mail presenting your views on how to move forward. > Few comments below. > > > > > > I also personally believe that #2 and #3 are functionally > > similar enough that there's no requirement that forces us to > > pick #3. > > > > This would certainly be a key point of debate. Its unfortunate > that few folks who are in the client-mobility camp managed to > make it appear option#2 and option#3 are almost the same and > hence go for client-based mobility protocols. But, if we look at > the details and place them side-by-side, however I look at it, > to the point of hypnotising myself to be part of a client > mobility camp, I cannot convince myself that option #2 and option > #3 are equal. To me and having been involved in Mobile IPv6 > development and having some understanding of both the protocols, > I'm not able equate the complexities involved in each of those > appraoches. > > > > Option-2: focussing on MIPv6 stack requirements: > a.) Implementation of MIPv6, IKEv2, DSMIP6, MCOA specs and on > million > platforms. > b.) Requires the host to be involved in mobility management, > tunnel > management. > c.) Requires significant amount of system resources, CPU, Memory > ..etc > d.) And we have one or two vendors who ship those stacks. With no > industry experience on the client stack, or with close to one or > two > serious interoperability attempts and years back. > > > > Option-3: identifying the minimal needed signaling giving the > ability > for the stack to deliver certain handoff hints to the affect: > a.) a given attachment is a new interface attachment and these are > the interface properties > b.) a given attachment is due to a handoff between IF-1 and IF-2 > c.) a given flow with the following flow parameters, should be > moved > from IF-1 to IF-2. > > These minor data elements are the attachment preferences, gives > the > network the ability to determine if the given attachment is due to > multi-homing or due to inter-technology handoff and to perform > flow management. > > > Jari, With Proxy Mobile IPv6, we practically built 90% of the > features that client-based mobility can offer and with zero > changes > to the host. Its the basic design choice of client complexity that > to > most part kept the Mobile IP technology as a failed protocol with > no > deployments or commercial success. Proxy Mobile IPv6 atleast has a > ray > of hope to be deployed. These two features flow mobility and > inter-tech > handoffs (with client expressed preference), will give the > protocol the > completeness and for the valid reasons that these attach > preferences > have to come from the host and not from the network, we need the > host > to deliver those hints. But, moving to client-based mobility for > fixing > this gap wont help this protocol, but will certainly keep the > client-based mobility in business, the last hope. > > Now, focussing on option-1, building virtualized interface, hiding > the physical interface variants, does give the ability to perform > inter-tech handoffs and multi-homing, as supported by RFC5213. > But, > it wont give the needed hints from the client and does not allow > us > to build flow mobility support. But, either way, this requires us > to specify how host stack can achieve that and it certainly helps > if we can move that work forward while we are discussing this. > > Bottom line, I believe, there are enough folks who wants to use > network-based mobility technology and they should have the choice, > however difficult it may be for folks in the client-based mobility > camp. My humble 2c. > > > Regards > Sri > > > ----- Original Message ---- > > From: Jari Arkko > > To: netext at ietf.org > > Sent: Wed, October 21, 2009 4:29:00 PM > > Subject: [netext] NETEXT2 BOF conclusion > > > > I have been trying to come up with a way forward on this, but its > hard. > > To recap, there are a few different technical possibilities for > > multi-interface mobility: > > > > 1) Link layer hides interface variants behind one logical > interface. For > > instance, an IP stack does not see the change from GSM to UMTS > radio or > > 802.11b to 802.11g; its handled as a part of the link layer. Such > link > > layer operations need to be supported both by the host and the > network. > > This approach has the minimum impacts on IP stack, but requires > > specification of the link layer mechanisms across the used > interfaces. > > > > 2) Different interfaces are handled via existing host-based > mobility > > mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within > one > > interface the link layer handles mobility, possibly using Proxy MIP > > internally. Both the host and the network need to support the host- > based > > mobility mechanism, but the link layer does not have to aware of > the > > other interfaces in any way. > > > > 3) We extend Proxy MIP with capabilities to handle cross-interface > > handovers. This is similar to approach #1, but the signaling > messages > > are at the IP layer. The benefit is that this could be used across > > different types of link layers even if they do not support > handovers. > > The downside is that just as with approach #2, the IP stack has to > be > > capable of these operations. > > > > The big argument we have been stuck with since San Francisco is > between > > #2 and #3. One group believes that existing mechanisms are > sufficient, > > and they are -- it is indeed possible to do this. Another group > believes > > that they need a different solution based on Proxy MIP. Such a > solution > > is also of course possible. But we've made very little headway in > > resolving the question on what should be done. In particular, we've > not > > been able to describe very well why some technical reasons would > dictate > > one or the other solution. I believe that is likely because they > are > > really very similar solutions. > > > > At this point I do not believe we have consensus to go forward. We > left > > the BOF with the idea that requirements work would solve this > issue. If > > I'm right the solutions really are very similar, this work may not > be > > able to resolve the conflict, and it would take a long time. I > think it > > would actually serve as better if we were to decide now, as opposed > to > > pretending that more details will make the decision easier. > > > > With this in mind, I have a proposal for a way forward. Given that > I do > > not see consensus for approach #3, I do not think we can go ahead > with > > that. I also personally believe that #2 and #3 are functionally > similar > > enough that there's no requirement that forces us to pick #3. In > > addition, approach makes mobility end-to-end between the host and a > > network node; approach #3 ties the use of mobility to a particular > link. > > If the router on that link does not support the mobility mechanism, > > mobility service is not possible. I think it would be > architecturally > > better to separate access and mobility. > > > > However, I would like to move forward with a different work item. > The > > IETF has never really explored approach #1, even if it is commonly > used. > > Of course, the IETF's role is not to design these link layer > mechanisms, > > but I believe it would be valuable for the IETF to publish an > > informational document on considerations for building such > mechanisms. > > This document would talk about the requirements that the mechanisms > must > > fulfill in order for IP to work correctly, when such mechanisms are > > recommended and when not, what their advantages and downsides are, > what > > happens if MTUs or routers differ, and so on. At the same time this > > document would describe the "virtual link" model that some people > have > > been using in the context of Proxy MIP. The idea is to add this > work > > to the NETEXT WG charter. > > > > I realize this does not make everyone happy, but I'm not sure there > > is an outcome that does. What we lose by not doing solution 3 is > > a design that that simultaneously allows something to be done > > in a link-layer agnostic manner _and_ employs PMIP as a part of the > > solution. > > > > Thoughts? > > > > Jari > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Wed Nov 4 18:44:30 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312F33A67E6 for ; Wed, 4 Nov 2009 18:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IdxnLXI1WTa for ; Wed, 4 Nov 2009 18:44:29 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 84AC13A6939 for ; Wed, 4 Nov 2009 18:44:29 -0800 (PST) X-ASG-Debug-ID: 1257389089-343900190006-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 96922EFCA3C for ; Wed, 4 Nov 2009 21:44:50 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id GaRKMcH1gCKWGaFX for ; Wed, 04 Nov 2009 21:44:50 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Nov 2009 21:44:17 -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 X-ASG-Orig-Subj: Meeting next week Date: Wed, 4 Nov 2009 21:36:22 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382B4C@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting next week Thread-Index: AcpdwMM+lhLaCNS7RkOAuEX2TFlA+g== From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 05 Nov 2009 02:44:17.0507 (UTC) FILETIME=[DE6A7330:01CA5DC1] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1257389090 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: [netext] Meeting next week X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 02:44:30 -0000 =20 Hello folks, =20 in order to make the best use of the meeting time, please go over the = topics on the agenda and discuss the issues you think need additional = time (which may not be available during the meeting). Please see that = the issues that were raised during the last meeting and on the ML have = been incorporated into the WG docs. As an example, please verify that = roaming issue for localized routing is addressed in the PS document. =20 Regards, =20 -Rajeev =20 =20 From rkoodli@starentnetworks.com Sun Nov 8 17:53:21 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B7C3A686D for ; Sun, 8 Nov 2009 17:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71K13VIiXNDd for ; Sun, 8 Nov 2009 17:53:21 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 3D3E63A635F for ; Sun, 8 Nov 2009 17:53:21 -0800 (PST) X-ASG-Debug-ID: 1257731626-100100460000-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 91252EFC978 for ; Sun, 8 Nov 2009 20:53:46 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id oGGEOEYioR303XDD for ; Sun, 08 Nov 2009 20:53:46 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Nov 2009 20:53:07 -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 X-ASG-Orig-Subj: Slides for the meeting Date: Sun, 8 Nov 2009 20:53:07 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382B62@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for the meeting Thread-Index: Acpg32IBMjwF6w84R3u5+3RcZu9Kog== From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 09 Nov 2009 01:53:07.0577 (UTC) FILETIME=[623F4E90:01CA60DF] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1257731626 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: [netext] Slides for the meeting X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:53:22 -0000 =20 Folks who are presenting: =20 please send your slides by Tuesday am. Please prepare the slides based = on the allocated time. =20 thanks, =20 -Rajeev =20 From trungtm2909@gmail.com Sun Nov 8 18:02:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBBA3A6841 for ; Sun, 8 Nov 2009 18:02:11 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZnvaRoZRbmd for ; Sun, 8 Nov 2009 18:02:10 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 48DD83A67A8 for ; Sun, 8 Nov 2009 18:02:09 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1134763fga.13 for ; Sun, 08 Nov 2009 18:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nUOdfadKWHQd9rppTjKNuEPKaIZXOzaQ/hE+AVRAnB8=; b=aZ0KHxgnnjdqeJUAvYrmnYixFDzeVA3DBa9STHKDy7c/Kuw+1NmATpYrT4K8/dd+c9 edYTuX6XDaC+bK2lZsDHuCyLHgLmF7rcvnlwAzZf980nxIaZ7DIsVrDa/joZf/mWwwwf 5ZJh8Ccz2YjqJIkOti9uq5gpcDFsJkYLvZjGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X/Nzqt28O7pqcZHzmpP2V91p45WbrBfBlLcHylyfwfF4xmyPyjnse52lU9j/U+ODrf W2DdAVk39NZuHQvflK6UtsTG1ej/AdXD3ACDcTYrNKxMDLQ9FUmPbCTr2zVU3PErP3fa p1do9uKgR+6fU9AFwoDqjVg83CPAwhU7WR2JI= MIME-Version: 1.0 Received: by 10.87.76.8 with SMTP id d8mr7697820fgl.66.1257732150690; Sun, 08 Nov 2009 18:02:30 -0800 (PST) In-Reply-To: <4D35478224365146822AE9E3AD4A266609382B62@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A266609382B62@exchtewks3.starentnetworks.com> Date: Mon, 9 Nov 2009 11:02:30 +0900 Message-ID: From: Tran Minh Trung To: "Koodli, Rajeev" Content-Type: multipart/mixed; boundary=001485f8d1821086f40477e696a9 Cc: netext@ietf.org Subject: Re: [netext] Slides for the meeting X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:02:11 -0000 --001485f8d1821086f40477e696a9 Content-Type: multipart/alternative; boundary=001485f8d1821086ed0477e696a7 --001485f8d1821086ed0477e696a7 Content-Type: text/plain; charset=ISO-8859-1 Hi Rajeev, The attached file is my slide for the virtual interface Internet draft (draft-trung-netext-virtual-interface-01). Best regards, TrungTM On Mon, Nov 9, 2009 at 10:53 AM, Koodli, Rajeev wrote: > > Folks who are presenting: > > please send your slides by Tuesday am. Please prepare the slides based on > the allocated time. > > thanks, > > -Rajeev > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > -- Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 --001485f8d1821086ed0477e696a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rajeev,

The attached file is my slide for the virtual= interface Internet draft (draft-trung-netext-virtual-interface-01).
<= div>
Best regards,
TrungTM

On Mon, Nov 9, 2009 at 10:53 AM, Koodli, Rajeev <rkoodli@starent= networks.com> wrote:

Folks who are presenting:

please send your slides by Tuesday am. Please prepare the slides based on t= he allocated time.

thanks,

-Rajeev

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



--
Ph.D., Senior Member Electronics and Telecommunications Research Institute
Standards Resear= ch Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel := +82-42-860-1132, =A0 Fax : +82-42-861-5404
--001485f8d1821086ed0477e696a7-- --001485f8d1821086f40477e696a9 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="draft-trung-netext-virtual-interface-01.pptx" Content-Disposition: attachment; filename="draft-trung-netext-virtual-interface-01.pptx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1sl7z9s0 UEsDBBQABgAIAAAAIQCbNI5YkwIAAIEUAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM WNuOmzAQfa/Uf0C8VsHJtt1uq5B96OWpl5V2+wEuTBJasC3bSTd/X2MS8EYOdopR9iWEi2cOM+Mz Z5jfPlZltAUuCkrSeJZM4whIRvOCrNL458OXyU0cCYlJjktKII13IOLbxcsX84cdAxGp1USk8VpK 9gEhka2hwiKhDIi6s6S8wlKd8hViOPuDV4CuptNrlFEigciJrG3Ei/kPBYAXOUR3mMvvuFJ+EGMS iVJdFM3hbaIsxtHHZmntPY0xY2WRYamwoy3Jj/xO6HJZZJDTbFMpbwnjINRRP16ViTb+qjaK/BBc Xw7BV7yjG7mPRHPybhQ0jW2vqFgw3VwQE6ESxH1TMN3/WWhEnWlXkLonBer+Xz03QK/HB/QJlnhT yujzo9r1DdEwsjray0VV00N93bUdv2EhFWE1tNCcBE+zJofGtivPJkkFD+bZJPUmdDq9ENTUescp E6G9t4a9smChpHHiMYwmx2llwzCN09z8MEmlGgDp3+H0qM14VcueQcbhjnMQDH/p/5E2RtSHh8A/ 6pY9Os77+9WepjcLpnGY/CkmS1/8zcDeGPUN1RktaziU4qiZOoTxXownaqVWw2JdMHGoWIuHfuXt kNBmbY7RHg6SPqlwQQ4vcWqi0ELsICCMk+E7wHxNNV0Ytl2YTpVgcEyGoz5MamDSvRypKhqcMKg1 Xw75hCl5AFwW0BbaqRxJ/KuEe7krIbicMEz3RaCdPS3EMLtUWnpBTQcn6qh+PWulBtUNN+agE1xQ dG5cqeueNAEFH5g7Ny5AOph7uREchjbuQrAt4O8oAr017EJgFNST7xjvn13lBh8Z/Aule9Ks3ODz QuemL2ttH8goh/OzdBAZ9WoL+yP9AXHxDwAA//8DAFBLAwQUAAYACAAAACEAaPh0oQUBAADiAgAA CwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyS20oDMRCG7wXfIcx9N9sqItJsb0Toncj6AGMyuxvdHEim 0r69oeBhYS2CvZzTP1/yz3qzd6N4p5Rt8AqWVQ2CvA7G+l7Bc/uwuAWRGb3BMXhScKAMm+byYv1E I3IZyoONWRQVnxUMzPFOyqwHcpirEMmXSheSQy5h6mVE/YY9yVVd38j0UwOaiabYGgVpa65AtIdY Nv9HWzpiNMgodUi0iKmQJbblLaLF1BMrMEE/lnQ+dlSFGuQ80Oq8QDzs3ItHO86gfNWq10j9b0DL vwOFrrOa7oPeOfI8Y4KcdnwzxcgyJspl7Gj7qR+6PicQ7Zm8IXPaNIzxk0hOLrP5AAAA//8DAFBL AwQUAAYACAAAACEA2AOCa9cAAADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5y ZWxzrJHBasMwDIbvg72D0X1W0kMZo04vo1Doae0ewNhKYpbYxnLH8vZzL8WBwi676ZfQpw+02//M k/imxC54Ba1sQJA3wTo/KPi8HF5eQXDW3uopeFKwEMO+e37afdCkc1ni0UUWheJZwZhzfENkM9Ks WYZIvkz6kGadS0wDRm2+9EC4aZotppoB3YopjlZBOtoNiMsSy+W/2aHvnaH3YK4z+fzgBPqQic+T s1SoOg2UFUhZtbmqW1ncAR9rtf+pxTejk17CNa+8qj5jFe5muPpC9wsAAP//AwBQSwMEFAAGAAgA AAAhACPzcKTXAAAAzgEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc6yRwWrD MAyG74O9g9F9VppDGaNOL2NQ2GntHsDYSmKW2MZyS/P2cy/FgcIuu+mX0KcPtNtf50lcKLELXsFG NiDIm2CdHxR8nz5eXkFw1t7qKXhSsBDDvnt+2n3RpHNZ4tFFFoXiWcGYc3xDZDPSrFmGSL5M+pBm nUtMA0ZtfvRA2DbNFlPNgG7FFAerIB1sC+K0xHL5b3boe2foPZjzTD4/OIE+ZOLj5CwVqk4DZQVS Vm2u6lYWd8DHWpv/1OKb0adewjmvvKo+YxXuZrj6QvcLAAD//wMAUEsDBBQABgAIAAAAIQBjc4me +AAAANwCAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOsks9KxDAQxu+C7xDm btJ2RUQ23YsIC550fYDQTNNg84dMVuzbGxHZFtb10tvMF+b7fsxku/t0I/vARDZ4CTWvgKHvgrbe SHg7PN3cA6OsvFZj8ChhQoJde321fcFR5TJEg43EiosnCUPO8UEI6gZ0iniI6MtLH5JTubTJiKi6 d2VQNFV1J9LcA9qFJ9trCWmvN8AOUyzJ/3uHvrcdPobu6NDnMxHCupJdDFUymCVwLhxqq370mkdv QJzHaNbE8CEjvY5WL1lOMolTveFlhX9h1Wti0TfRs5rCMS92NNNJzJrmEtntmmQX79b83k0s/mT7 BQAA//8DAFBLAwQUAAYACAAAACEASoytlNkAAADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU1LnhtbC5yZWxzrJHBasMwDIbvg72D0b12GugYo04vpVDYaesewNhKYppYxnLH8vbzDgMHCrvs pl9Cnz7Q/vA1T+ITE3sKGrayAYHBkvNh0PBxOW2eQXA2wZmJAmpYkOHQPT7s33AyuSzx6COLQgms Ycw5vijFdsTZsKSIoUx6SrPJJaZBRWOvZkDVNs2TSjUDuhVTnJ2GdHYtiMsSy+W/2dT33uKR7G3G kO+cUIEy8vvkHRaqSQNmDVJWba7qnSzuoO5rbf9Ti3+MXs1Ct7zyqvqsqtD+mqnVF7pvAAAA//8D AFBLAwQUAAYACAAAACEACgWNeVkBAACJBwAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1s LnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8lU1OwzAQhfdI3CHynjpO /wA16QYhdYGEoBzAJNM0IrEtjyn09lhpFdyqGjYWm0jzksx8epnnLJbfXZvswGKjVc7EKGUJqFJX japz9rZ+vLllCTqpKtlqBTnbA7JlcX21eIFWOv8SbhuDie+iMGdb58w951huoZM40gaUv7PRtpPO l7bmRpYfsgaepemM27AHK056JqsqZ3ZV+fnrvfGT/+6tN5umhAddfnag3IURHNumAt9Q2hpczvoS D+p85EkZvwwhxjEpnHxv4dXtW+/lwBKIFElUEMKOjIKYx3SDgJhRECKLSeH8xgab0Ze8vwoKIioD 4QQJIWIa0UM8SXRgf5czEI9xOTxBYs2iY50BHVGm1AcSUc3ZNfD1bLUJcjtIFMX0n6yYUBDCn+3x jlJjAc+sGCSKYhITgkjMmIK4iwmhtAM8T0wgIg+KITH85Ada/AAAAP//AwBQSwMEFAAGAAgAAAAh AJnVQQPYAAAAzgEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc6yRwWrDMAyG 74O+g9G9dppDGaNOL6VQ2GnrHsDYSmKayMZyx/L28w4DBwq77KZfQp8+0OH4NU/iExP7QBp2sgGB ZIPzNGj4uJ63zyA4G3JmCoQaFmQ4dpunwxtOJpclHn1kUSjEGsac44tSbEecDcsQkcqkD2k2ucQ0 qGjszQyo2qbZq1QzoFsxxcVpSBfXgrgusVz+mx363ls8BXufkfKDE4pCRn6fvMNCNWnArEHKqs1V vZfFHdRjrd1/avGP0atZwj2vvKo+qyq0v2Zq9YXuGwAA//8DAFBLAwQUAAYACAAAACEAFx81x9kA AADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzrJHBasMwDIbvg72D0b12 mkM3Rp1eSqGw09Y9gLGVxDSxjOWO5e3nHQYOFHbZTb+EPn2g/eFrnsQnJvYUNGxlAwKDJefDoOHj cto8g+BsgjMTBdSwIMOhe3zYv+Fkclni0UcWhRJYw5hzfFGK7YizYUkRQ5n0lGaTS0yDisZezYCq bZqdSjUDuhVTnJ2GdHYtiMsSy+W/2dT33uKR7G3GkO+cUIEy8vvkHRaqSQNmDVJWba7qJ1ncQd3X 2v6nFv8YvZqFbnnlVfVZVaH9NVOrL3TfAAAA//8DAFBLAwQUAAYACAAAACEA+4hR6O8AAABVAgAA IAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5yZWxzrJJNSwMxEIbvgv8hzN3Mdisi0mwv Uih40voDwmZ2N7j5IJMW998bEekuVLz0lnlDnvdhyGb76UZxosQ2eAUrWYEg3wZjfa/g/bC7ewTB WXujx+BJwUQM2+b2ZvNKo87lEQ82sigUzwqGnOMTIrcDOc0yRPLlpgvJ6VzG1GPU7YfuCeuqesA0 Z0CzYIq9UZD2Zg3iMMXS/D87dJ1t6Tm0R0c+X6hA60p3AerUU1YgJToyVv/kaxl9D3hZo76mhg+Z +G20ZulyjhnP53tZVviX1uqaWvxt9KKncMyLHc1yxtlQ/5rh4jM0XwAAAP//AwBQSwMEFAAGAAgA AAAhACJkNq6DAgAAnQ0AABQAAABwcHQvcHJlc2VudGF0aW9uLnhtbOyX3W7iMBCF71fad4h8u6Ih IX9EhEq7q0qVWAmV9gHcZChRHSeyDQt9+h07hriwF32A3GEfz/HMx9iYxf2xYd4BhKxbXpDgbko8 4GVb1fytIC/PD5OMeFJRXlHWcijICSS5X37/tujyToAErqjCUA9tuMxpQXZKdbnvy3IHDZV3bQcc tW0rGqpwKN78StC/aN8wP5xOE7+hNSc2Xnwlvt1u6xJ+t+W+we17EwHM5CF3dSfPbt1X3NwqPqck 6QE2+1cJ6qHlSiIdssSyJav+UKlAPFYrqa5mvLoqSBhEaZTNkgjZiVzP4NqA+MuF/79w3iqQV5af 5gaTuTX5JA9ZuBk9Vn0uceIkEep4k8NFTh15diu7JUQ3chI40fGNHM8dObmRE2y2C5/0Vg4dOdNy j8+tcvPhlceCzIMomk7RrjwVJMnizAzUqcOOlaUA4NHRFmfQ2bDLSh129jCEKtjSPVPPcFQbdWKw XNAc59ZrYT89rYXHqD4kwCcvG5Odu4QdWNDhmoaKVUEwM8re8IAx4qHNM33dfJx3xCIVM0uArvhP 8a4bDb1Vze0Qo3e4FZ6Z9Z6Xqm9Es5nOQqJTgAUT7x2EPsN4qrBRaS5bVlcPNWNmoM8j/GLCO1Dc TR37frxaZXb1NLctLZHdj4ZPmNLF0RzolQC0F0p5JZRywIEZ4vdGc8tDG+HHcEATxalOeORjoFg+ s4FP35YjnwPTUCyfaOATzNIgGRtInypNxQKKHUBZmJnrYbyBNBULKBkAhWGGDTReQdhBmooFlDqA 0mg23tHmh0tTsYCyAZCmg++P8ZI+ME3FApo7gJI4HS9p00GainnJ3j4x8Xnr/htZ/gMAAP//AwBQ SwMEFAAGAAgAAAAhAK++1DbACAAAuyUAABUAAABwcHQvc2xpZGVzL3NsaWRlMy54bWzsWl1v2zgW fV9g/wOh10UnlmL5C3UGaWbSKZB2jCT9AbRExdpQlEDSTtJfv+eSlGwrTqYpulMUk5eElvh5ec+5 h5d6++t9JdlGaFPWah7FvwwiJlRW56W6mUefr8/fTCJmLFc5l7US8+hBmOjXk3//620zMzJnaK3M jM+jlbXN7OjIZCtRcfNL3QiFd0WtK27xU98c5ZrfoddKHiWDweio4qWKQnv9Ne3roigz8VudrSuh rO9EC8ktZm5WZWPa3pqv6a3RwqAb13pvSidYWXYlc/pvmmstBJXU5r1urpqFdq8/bRaalTnsFTHF K5glOgovQjX3U6EaCke95jdtT3x2X+jq5C2fYW3sfh7B+A/0F434TNxblvmH2fZptvrzQN1s9fuB 2kftAJhBNyityq/o8XKStF3Ppciw6TdSsGTYrY0aPFpY24txxmlH7JaUHqfjSQwnwhLidByP4mR/ ecfpYDAcJRGjRR6PJ6MkdiN2k+ezRhv7XtQVo8I80phbRBbimwtjycDbKvTY1LLMz0sp3Q9ySHEm NdtwOY+WN7FrKtfVxzr3z6aYgbM5+nH+S9Vdr3s9ScXusIZkjMrfMsz4a4bBFKRyLuPtid2yDxIu SM8vRQGvg0skfgL7S+NZBof2yzMrngu/Ohr18Opch9RzAVt1fYcODvftjR3qU1NRFNiNrnGwzHON uxZu5FptG1elqvWhlUmsKozs63sDecM0M3v/rs4fqLsl/gOZ2sqzGpsNOHGVrWrQS2a1dztp7BU1 RH/wGvcHLbi8Aft1lYTKF1zzS7yRQME8EurN56swBzQCntpBUfR4egZVLaiuSwtAubWAYz5tPHTg dM1Fnd0apur3GuTlF7tTg/jDM0+zYvahAd9Y6spNqH3pWGYXjFjhdpqtbdyyH9sA7s5nurdctnQE l5faOv5hprJnUnBYKlCUPVnouqmNyBmgsiYmJjBaWAjdUZ9PWLLftd/dF1v2uLXsGfwCzs8Wkmdi VctcaOZ4ZseKL7SzA1q7Fd7+j0xMK+xReDJJx4nn8YN0NwQe0+nQ010McjxO3ERhsLanPdbpCOk7 8dc0BcnTvF86yjfSV4uT1gFpaMC8Ol3buigtK7BzVxmX8OlpAttETKqrJrsU+Tojf4IL7hCYBzj1 8diHEX92cEx1lutP0CzBtwhAwSkfOfqzLv5HCSrtufVhvHTdOJTZEy4lsyvBshVIBNKH1QVrVg+m xHpZCY/VBdzVsEIjtvGmkXhBa2ZGGNJjpj/sU2jqBu5DFF71YlDBH4OouYYEeVffs2SfshjtKaJQ eLqrcnb5h8zdunTQNzvgSAcJQv3Uk3Irdb4CHP9oLdAHEwl3CCJEuC/AzQdlAKJ4OASIrPsx9Fyk d98s9950kZJ26/+Hy4rrC6i7YTIlhJcqB1nPozftg234pWmYJnsnilBaZNYzHw4NWx0TapB7P4dr 8wWDomHEnkQIRSsowbJ4YIuPHxabEcPRRftDBchJM7Numlpbgu8GkXAN6H5oodtjhafgeWAa3xjw khdEvC1MvSmdxqBxd2KiFw/+oQp6hASNN+rT6D1O4yl4+Rn0TgFvhDm/zrajV/DuytSfE7yA8qWT 1nLjJfYzaGa5KK758gowdLwEIEKbu9aCX6h3+tYpTNIAp06Bc6gCMBngp8JrNAnRc7FWGUgjnN9I JPQpwimF9qzjZMTL6MRRz2kB+epKC2s89bRdgpjC2+UaR8Tre3g3qYyrL13xHEtxEp0i+zw61SWX EWtKm63OeVVKOuOS+FtxbQRWEyDUKRXQEV9euFMtn8F6OIJ4CPV57nZdlVX939Jvxc4hhW3ZBvqd 2Nb9Xc8jBTFEyRxd3mJqqr5ypYjdCk0yy/FkxnEACRWbzLWkqMBl+UX84X4uuRGypFQQ+lY1DgB1 4cqHKZYsRCdaii50Jver8U+ek6D23mvvnlD1p8fWQOsLFSy/pr5D2bnPzib8p1JvpA1cxXsvBPcv MtN7kZlAXlCLNH178tngSB1CQKfeGLd9lbbs1OHrJsFwf98mQQ4E29OGPVL5W2AcdlWHZntCir0X 2F83lLI8PwZ1Vb0skTVRdS72duWbjjZEWS5f+1t9p9ip1vUdi90hpBNF8IKXqaLBdDoaQZcRtQ/i 6QD87jypPdRQQiAd+QP/kA49k0AsT6iiHFNzM4vIi79TjnNCacAwbpdScGmaPRJ+zXG2Uec1x7lN HuLE8Jc5zu4mZAdZyIM5NIVU54uRFQ9wdwC1BGQNU1wN+PPE9mbkFVnEiDsAxq/X24PtHY5X7z/F 7UFT4jTj4k6Zkd504QgJTbpkTAZpl5JblJlda8FcjPGVfANkQsqsvUY4oyOTODUNorY7Yak6PKKI txI8R6bIM91uH/txD0P5mSxl2ZC8pnBEZaZnoloKzEx/yBH4MtwPW5wHGg1V7GOf0cjgZnQ3B/+0 WuD4Q0VPqu45OW77AvyyHcOnH9jyDlkZdOpOhNS2jZYhlYirRIQ0f6+YojQe9O4VKdeYgoHcvWIc TwaD6fj5wPtX94rdAYZQRneBXS59501VIq3LZFnNIwwZgi6fkc1/V7kziOWl9OU+XmGI4AjhH3Kr 7S6ARLf+AFL0OgavnT+MOqYNDX6UP9Dh9of4wyhFchFRCMECmz1MJ05mbYNFMk2G8RgX3O6eOTkm RfTz+MMzt4uQlt4XLus1Eqs527m7Tzu3oMz8SwNwOjqOB8jRk02T6SQexyFd0Upb2HQyTQFCsilS u2NsAAaBW7do7Wf8aIo0v++pbbv7e6hl2ax4L2nTXkY/qXang/TQjb6+WXafDZyft1Am3tp+X9AH MMjr9br+Jwi4TtH6b3tQbD/3yaT+yJs/N+64j6+YwOTwADxqkP0nv0bVbRXo4xKfLNy4a3aFwzEV Gu6D97Vqvw/K1/j8gHKkRakQG5ABFeBHurZRAhlgyqHl4tpf6leXde0iKAUC6gn/re+aSmE4FPHp 1cn/AAAA//8DAFBLAwQUAAYACAAAACEAnnuubAQDAABaBwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU3 LnhtbKRVTW8aMRC9V+p/sHzoLVk+AglbIEppE1XKBw1UPZu1Aatee2UbAv++z95dUEhIU/UCXnvm zcyb53H/cpMrshbWSaMHtHnaoETozHCpFwP6c3p9ckGJ80xzpowWA7oVjl4OP37oF6lTnMBbu5QN 6NL7Ik0Sly1FztypKYTG2dzYnHl82kXCLXsCaq6SVqPRTXImNa387Xv8zXwuM/HVZKtcaF+CWKGY R+ZuKQtXoxXvQSuscICJ3s9SGqKybKJ4+HfF1AoRVnp9Y4tJMbbx+H49tkRy8EWJZjlooUl1UJnF Tw0zLJID90WNxNLN3ObDPktRG9kMKMjfhl84sVRsPMnKzWy/my0fXrHNlt9esU7qAMhgFzRUVVb0 spxWXc5UeiVIc1dVacrgemuy345ogzpD+WV52f26Bgs1B/hiSfy2ADM+QFV25WHko7Z34DSS5Tdf DN+Gwmf4j5ssVc5P/FaJSAjSZinA8QP6FQsKFfrk54SSWWwFl9ZHpojL/UgJBkVXZPrhj5VwUSrk E8uLz+RKuyfIvg+SPHpUIQvNx8yyx78ECGWzFAmhljpxLEtmj/PbrvkdGe2hPjJWLBNLo7iwpPV/ bEsOrdQNOUJ04O5Acs1257zVK4XXuuicn/W6IY+9/Lqds3a3B2UEEQbrdqsd27mHckZJfi2VCn5x AoiRsmTN1IDOFk0attUqvzO83Ot1Go3YF3C4M4+MPkNSOuL9I/jFe8AROKDHlpV6rbtYyy+E1phe Vytv5tKXDS+VGct5IUzomDC1gOQyb2PJs9U9RmYllRDlmHrf1O2IabKGsFdMEQnV2DkkQ2aCMG4K Lzg5UPDs9RtyNAaoqFxigofCP+oXrg1zhJFfN+S7F/nlQR7HbtIO8I07FPtSjl4s62mcKXvHiod1 LBCPDLiAzLBV4FkJaDDdm+BiyhwHYRh5fetwyTGVGJxhNtX1+OYrPD5SczGXWnpBCd4Fz6wfUC3w LOLCGi6m5STLH43xUfsVEiJW0GFVhcMSL+PwDwAAAP//AwBQSwMEFAAGAAgAAAAhAMghC+dkAwAA vwoAABUAAABwcHQvc2xpZGVzL3NsaWRlNi54bWzMVl1v0zAUfUfiP1zlmdGtSAiitWhsDCGt27R2 4hF5trNYOHZkO137zB/hH/IXOHaSQUu3lU/Rh8aJr8/1Off6Xu+/WlSa5tJ5Zc0o23u6m5E03Apl rkfZ5ex450VGPjAjmLZGjrKl9Nmr8eNH+3XutSCsNj5no6wMoc4HA89LWTH/1NbSYK6wrmIBr+56 IBy7AWqlB8Pd3eeDiimTdevdNuttUSgujyxvKmlCC+KkZgE796WqfY9Wb4NWO+kBk1avbGkMZnyq RXz6euakjCMzf+vqaX3u0vTp/NyREtArI8MqyJINuonOLL0amGEwWFt+3SOxfFG4arzPcnCjxSiD +Mv4j0Usl4tAvP3Iv33l5dkGW16+2WA96B1gB7dOI6uW0Y90hj2dmQpa0t4tq9aUYemJ5R89GQue kX5Lj5/Oe7DIOcLXJYVlDWVChOrs2smkR2/voWkSKyxeW7GMxK/wjCAsN0ifgybYQgUqrAlTzjQg X+7ilyC/N9Y+TMNSyyQeKLI8YTiESrOYzdLsXE4zukphE8qFpCr5KhxqyZD9nfBhfCq59J65JfES S6UnZehkckBIa9cm3D7EDYht50Uacc4cu1h3dusmCsVybAvse6oYtrG4OyLP+ogcgj7ylc4147K0 WkhHw6gBsrVX/yfjowSyqw/hz4QmKbyt3LcKbBL6tTKx0tAhQ92gNyZA8iMWGE2Da3honCRf2gaF 5koSDgRkloJuVChpLQC/HOtjbW923gloqwol3Vaw6uEU2m5/94qD7Wixsp82g1Ia3ZXd9yJukvvE 2o9NTY2PcVjxdpeLLQ7QmqiruL/L4sI2ISUN6r7COWgPJE0upzO6Yl6SNasO/xyRFX1WeKCMkZ7r 7kDd5fHe6ExOP7w7ekIHQqA3+ScURcSXve3IbIaOZdAvq1SLC1SOUfYe0sUzh3ZZq8DLY1YpjUqI 2o9i57wMcdyWK9TOCBDGXz59psnB270V/mhRD1W99TP/jyQb/j+SDf+qZA8G4J62k7pPe7/BsL/y cO0mrD6bp8DjJhekO0yfauRMRIPpNxP0MlVhIrahYE48OiJaP8NimM1Mf0cSDW54KPWyUEYFmRES PDCHTDMSd0/0OCvkrL0uVBfWhpR/HRI8dtBx1LnDENfP8VcAAAD//wMAUEsDBBQABgAIAAAAIQD8 GvKqDQMAAAgJAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTUueG1srFZhb9MwEP2OxH845fvoNiQE0doJ xoaQxqho9wM8+7JYOHZku13773l2ko3CugWxfmic+O7Z7935zienm8bQmn3Qzk6LozeHBbGVTml7 Oy2ulxcH7wsKUVgljLM8LbYcitPZ61cnbRmMInjbUIppUcfYlpNJkDU3IrxxLVvMVc43IuLV306U F3dAbczk+PDw3aQR2ha9vx/j76pKS/7s5KphGzsQz0ZE7DzUug0DWjsGrfUcAJO9d7Y0AzO5MCo9 Q7v0zGlk1198u2jnPk9freeetIJeBVnRQJZi0k/0ZvnVwgyDyR/utwOSKDeVb2YnogQ32kwLiL9N /3ASJW8iye6jfPgq6++P2Mr6/BHrybAAdnC/aGLVMfqbzvFAZ6mjYTq6Z9WZCrheOvkzkHXgmeh3 9OTVegBLnBN8W1PctlAmJqjerpvMegz2AZpmseLmk1PbRPwGzwQiSov0+biKrtKRKmfjQgoDyA+H +GXI341NiIu4NZzFA0VRZgyPUBmRspntwfWioJscNqV9zKpSaOKZYYHs74WPsyuWHILwW5I1XDmQ tvTt4xdCWvsu4U4gbkRs+1XYqrnw4scziyW5RInNQYOBMIZdRPbH5e0QlzOIgKyluRGSa2cUezpO SiBnhxj8Y5S0Qo4NgfyXAGWdx4r+pNxnzhiWMVBgv8YZp8q4O5wvMNWVBsW7mqH/FUH9VFECiRiF rFMdoLUWiO82CbETk07nLPZ/ZMInbVMppOtWich0qUOkcxuRGTuL7VvhSdqhdiuU0BsmHHUkECu6 07Eehzwiiy+g4sHXexX/f8OEYBi1g/MyKs+922zpD62bdARveZwcY4TWVpqVGgk4Vt+HLN3RZV9C 6OeLzwsQ1rZrvOiMO7vaida+krVXyn2VKxewrlFiOPROafw30X5f5yKMK0Fkf5Y/tThPqQ7C9MEE 5VA3mEiVLNrLgNKKHiJyK5FLOzRbtcJVAUeSK2115ILQxaPwcVpYxiUGZdIpXnZ9p/nhXOwbT0bC ij10GvXLYYh7zOwXAAAA//8DAFBLAwQUAAYACAAAACEAV4TQQ8AFAABDFgAAFQAAAHBwdC9zbGlk ZXMvc2xpZGU0LnhtbOxYXU/jOBR9X2n/g5XnnWmTNk0bUUYMOx0hDUwFzL67idtE69iR7RbYX7/H dpK2UFhgRpodCR4gJNfX9+Mc+9579OG24mTDlC6lmAbh+35AmMhkXorVNPh2PXs3Dog2VOSUS8Gm wR3TwYfj3387qlPNc4LVQqd0GhTG1Gmvp7OCVVS/lzUT+LaUqqIG/6pVL1f0Blor3ov6/VGvoqUI mvXqOevlcllm7E+ZrSsmjFeiGKcGluuirHWrrX6OtloxDTVu9Z5Jx/Asu+K5/avra8WYfRKbz6q+ qufKfb7YzBUpc8QrIIJWCEvQaz40Yu5fATE89O4tX7WaaHq7VNXxEU3hG7mdBgj+nf2NRTRlt4Zk /mW2fZsVXw/IZsWnA9K9dgNY0G1ap3WZeZfmZfbAof6g8wmfzVoxknTONQuoVfFFZn9rIuRpQcWK neiaZcYHpH2llLwpGM21fe3jkCFy7aa70eleLnhZz0rObQDsM1EpqxYMoVZn+SAgGbBoEO9alcL4 OGmVXWJvFzNtFDNZYVcvoaV5jzh0HxCK7R42w8jk4uZc5lBK10YGdu29tESDOBlGiAvSECbheNKP 91MUD6NJNJ7APEgMB/Fg0I+cx1tVtdLmM5MVsQ/wBha7rejmi7a2w8ZWxFogpI2C84kLcjMNJnEU uwU7X6rSMEV4WU2Dcd/+eKtszD+J3C02tOT+GRtw4cBofXYPyKIFgq49HB7CO2rhfV0azojLIthx sfGiCGvdwgC430tzq8xm2aqvC2LuagTZWFUuOJYWjSWi0egTAsvr1Nx+lPmdwwH+WjkbFVWdIEnL 0pClFOYqoxwqJ63v8HHRCXNtrswdZy4OcJGmTodCwjkgOw2YePftKiALh9q8VMaxjOjKnHJGcRo2 8TTH8/Oz+WZE1pquGNEZE1SVktyUpiAbrFtTTgBHppY0Y4QaYgpGzi9sTo3LrNuYiXxOFb38j/1h rsWCS1AbA4DWJ+nxVIUdbS3o4Z/Nl3OgS5gL6y7r2hxpB4gtVpvTKI5GCdDuYD8cTsJoMNmHPVA+ SELLSkRuMBjH8fD7UK8lL/OW/u4qYadckQ3l02CxCgObRL6uwFb/bhI3oEfEOnEXvz1NFvcQeKHy 5DnKsfEeqx7iltwoCmoI3J7Ofl1bBM/KhvQvx6v+B4AdgexkPQ20WAXkSeyen3w+ie5B8TARtoqf VJiSF2p7BsFQEUxSAGyYxqNknH7Ezws3edrkdD8CryJYdxjuEGz/RHwpwUCZZBJ7fgFscXLv5n/j lwXBL8Cv8IeC9Vfk134EXsUv3CO+lt7hl6uiXn+BJSFo5S+wGDXcOBrtX2BRMhxFIzDw7QLzldeh wutnX2B/nc3e6BXvheBV/EJ74vl1jc7yo7wlKO3cjdXU88RWm+g3mzvtBYUiup9JmLh7LB734/7k 3j0W4WYbDiHwv6eZ7bRCtHd9X6rtVYxqteiK0dlsp+XYKSx/6nX1ZAl0Ngv/IGezKCUXkqy4XKBn OZsTmucYhOjvRleEcrQ5veVa5CwnO6e4axtefYqPBnE4joBeNBlRPx70w3uneBIOB2Psb9Fla/aR +45UtG1821i3vbe10JrnkvxIA76T1J3e4hmtCE0prwvqJVGmOy7AmCf7kx+PO21bX9cviUu2xLAK zI48qu2IbttX0Qz9rPG9lS5ozrzlNpCHTedWodXsJyyN7kbBYd2+p23k7VK2XCL+nWEN3Z5a3K1w O6P37xZXJcYChzzj8KrZ2cu7nroJzIFGTRl+KtFpAkpUZIXEVDIzylcMD4cJdnBE+Qpjgk7okQ7f 23Cwo3eNvZ8x4rEdO2ZcndP660ZZXzFNxWQBJw9e1ZifWm0Q3YrAkxIxWLm7W2Ca5MYtFIshdi3a OWW+hj8lqLksBeZGAQHvDVWYRQmG+S/oixnYtR/RVJdSuukadqqtJvw1XrV9arbDI0bAx/8CAAD/ /wMAUEsDBBQABgAIAAAAIQCF2rag2QYAAG0YAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1s7Fld bhs3EH4v0DsQ+1o4sv5sSbAcOG6dBrATwXIOQO1yJdZccktStuyn3qE36NF6kn5D7q4sRU7sJAhQ wC/W7nI4nBnOfPPjo9erQrEbYZ00epy0X+0nTOjUZFLPx8nHq7O9QcKc5zrjymgxTu6ES14f//zT UTlyKmPYrd2Ij5OF9+Wo1XLpQhTcvTKl0FjLjS24x6udtzLLb8G1UK3O/v5Bq+BSJ9V++5T9Js9l Kn416bIQ2kcmVijuIblbyNLV3MqncCutcGATdm+IdAzN0qnK6NeVV1YIetI3b205LSc2LL+/mVgm M9grYZoXMEvSqhYqsvCqQYaH1tb2ec2Jj1a5LY6P+Ai6sdU4gfHv6C828ZFYeZbGj+n6a7r4sIM2 Xfy2g7pVHwAJmkNJq6jRp+p0anWupFeCtRutIinH1nOTXjumDfQk9aN66fubmhnpTOzLBfN3JSzj iVVFFxeDPWp6B5sGY/nVG5PdkeIz/IaPfKScn/o7JYJBIDYfgTn+wPyKk4cKvfdxmrBZuIpMWh8s xVzhT5Xg8OjKmP54Ys1MiYKc2QvyIHcE+3hcT8VU6GzCLb/8Am/SmI8gC9SoZcZjNOrjpu3Wpj01 2uN0NlE8FQujMmFZ59sMLTO4SX0Xj9iYzLblbb3+ISIxuFz7oD0YHHRJjLXjDTqd4QERkPu1h4ft g8ODcJFrTs4omZ1JpWhfiH1xqiy74WqczObthD6rZXFhsvht2N8Hw2jChjwYdIOT0oHfM5kfPoU5 7o64hxuLnlpfYu14dLQGbp0svcmlZ0pPy/RSZMuUkAaWgAq1DtFVg5bfz1PfwUHsnhfpQhtl5nds Afg1wGhmxZ9LaXd4b/TI4Jb4Qx58gxsILvFYyHw2WC5FgQMZV4q9m7CtQNkdgg2/4EP+mGcZINa1 ALS5XDHumV8IBn9/JrtdsSzJQjniZ0Oy72+EYG33TIEr/UlbLW5ZIyvzhi2dCGZwSBpY9bfGXrPK QrfSAzMrGyHXbh77NZjTezrmMIqCgCIh8iLMU5wiGW6Ce/yoG8AnAKc92+Ay6A/2IQCgowcQ6Q8D dDwLXErr/FthChjI+XFiReoDoPCbc+dJDLh6RRKEfiZc/B+wiCozqL4w9j5h6p1242TY7vWAyT68 BAhPmH24MttY8erUAAr2g+UewFq03+fwi2Ck4PZ8nHR7nSHlAbxdEquILviVOkMqGyd7NQVXcyCk Slgm8is+m95X8oLW+iAGE/xcv7HXhE4sRy48CVs4wBZ8UY7pahlbgHtzVIyTpU5xSJVNCI2jj6aT 1Me0EiC5xuSA1xXFG5Fv0yLlNfDtynRNcZKjGKASJ514F/nWLPGtWp0tkd+uVrAe0sVyet88nkGV UPEQLI2TEys5zFBKny7OeCEV4qCLcEgX3DoBbQJr4nGKL+HzOPn3r39iBvZ8Fl2cj2BIVCSVt8dI a/D3elnIwvwh4508rIccDN8NyT1WRpFkOU40gIUKeiuvIaU20/CUsGthKbWFLSlHaVcRlmlgTo7D lbwXv4fXGXdCSWoHcEvaoLQyeXhuksAGapOxYkrXhoqFqM2Xk7xfxaIGl/IwtkWeAwpqAy3PdXUJ S+JdPQdPenAfvxR6T/loXcG3FgSPC6nbWkgdLQBnUHCSEk0VuVk7fpJ4YtgcImz6MNBm2MDtm7Dp DPooWhLk2Zew+Zaw+Tve3xPDZqNzoEjpDAjddvtuiHR/fGFmUkl/xxxqGmo4Gbci5na7LL3INioR pLl1M/H5KI1nI0ohwUuUfluUro0eiwMK2dA0rlPZS0z+qFT2vJh8CRL46o9NZRdL5eXCFKiwWE4l FmCNSQccdByTkk1E+5r2o1+3H5dyvvDsxFpzy3oE1U1TEZ4fjskejoUofKmrYNagYOr3qHCLdWw1 Luu1OwfdNo4JxdVwMOj2YyKoR2eD9nDYRcINA4wOCufe9gCjbiDqHoMkDYJ+z05j8JTBBJVI7JZq sMNKy42ip5mWPD5c+cr5h6MBWyzRLkWOsSbawE5Qf+tMnqao9mMZ7hY8E1EUUq4plGn8SyOgAMBK gyFxzlGYNbwrBjVlZFLzjuVWRU9bY7HXbI73/4hgcXOzI5yMsrzZDFc3dpdmClpVJ0d6iI+RXjTM esxXT4iol6m6KsZ1iu5snKTeRt9TnwyCKPvECq8hWmeqjTlmlGHnbDEMrOI0mnryakCdKnvByw83 sDcfYe6OsQiMj08lopq4gXRNAk0khTsFoNcooMOglmMzyK4Q/FnoyrIl9KEaNZdaerQLmON4Tn2o FuhHqeLPxFUc7haXxoSyGieVxAm/FWt6qo7DI/5ZcPwfAAAA//8DAFBLAwQUAAYACAAAACEAw6Ee YvMDAABSDAAAFQAAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbNxW227jNhB9L9B/IPRcx5YtX2LE3nZT Nxtgkw1ib9E+MhRtC6VIgaS99n59z1CSL7GzXeylKAoYMiXODGfOnBnO1atNrthaWpcZPYrii1bE pBYmzfRiFL2f/dYYRMx5rlOujJajaCtd9Gr84w9XxdCplEFbuyEfRUvvi2Gz6cRS5txdmEJq7M2N zbnHq100U8s/wGqumu1Wq9fMeaajSt9+jr6ZzzMhfzVilUvtSyNWKu7huVtmhautFZ9jrbDSwUzQ PnJpjMjEVKX074qZlZJWen1ji2nxYMP2/frBsiwFXhHTPAcsUbPaqMTCq4YYFs1n6ovaEh9u5jYf X/EhYmObUQTwt/SEEh/KjWei/Cj2X8Xy3RlZsZyckW7WB8CD3aEUVRnRaTjtOpxZ5pVk8S6qUpRD 9a0RfzmmDeKk8MvwxP26NkYxk/liyfy2ADLC22CtEi33AyS1igOsAS+/eW3SLcX+hH+yw4fa/LLy Zp55OulwQzk/9VslA1aIiA+DvEVmFCfySt14PwV5P46ipNUCtGlm/R5IP/4d7yuuWKa9tHMuJANd mVsVhbEeTGX5SvlsaXJaowJKQealWGqjzGLLlvhqUDzkmQ/+wQes4Q4irMPBsoT8ZeA7NfDT1ZMP 2Le/BfZu9VRiD7KCSXW6XsgBYfiMkHGnH/cIO+DWGQx6qFzya0/OXrfbvxz0IkYU7cVJpx8EDplH 6SVG1HAcJlGjP3yD/LYH5/KLhjP3DW9XetHQ0qOeGusy5Y1dyhut+KuTl/xD8hhFHuAn5KoSIjqj 0RwXTvlR74qphO40K0l70G+jMQPzpJd0kqT3iazE3VYrvhyQxC4toKh1/kaanNFiFFkpfETu8fVb V9VaLRI8fSmLdHdAf2nsx4ipW+1G0WWcJKCMDy9Jt9/Giz3ceTra8eraKOp6dPwBIVCN2k8FV2gi XcQAK0pPC/Eo05Wgpj+KQMeSkAhs3zJOOwMYyNQ6HMK4WkATXSmc5wrxWs7LvIgH4dmaQ+zQbi1B ZV22JLAZzeZcn+lQfez7DHO5v1aS47yqbPx41jji26e61nNr0uKexI1zxurdxYxo/sWmz5j8if35 XVy9uXhjTjyVOn3glj9+AaiUF0pI+fjvJHoye7w9ysd3dPR/CN/tBLNnv8fuJ7PJHzN2J2W4kn9+ k1mDaS/n/xa2X1Xt6AeXF3GM3xl3T0eEMCmUIyddDtUUKpS948W7dfAEwzWmlevwqcBgUt0jexFc tBlNLOHK1WjmYRrjUIbFma7H1nSFZpLpVM4znXmJDi0x5lMr1xItHVeaSeUsTHA+fzTGh/sDcx1Z Is9L07SqjiPnMTb/DQAA//8DAFBLAwQUAAYACAAAACEA4w5GfG8FAACSGwAAIQAAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbOxZ25LaRhB9T1X+QaU8YxjdRS24Frzkxd7dCvgDBmlY FEsaRRrYJalU+beSz/GXpHukAXHzCpYHV4UXEOLoqC/TRz2tm/cvSawtWV5EPO3p5F1H11ga8DBK n3r658mo5elaIWga0pinrKevWKG/7//8003WLeLwI13xhdCAIy26tKfPhci67XYRzFlCi3c8Yyn8 N+N5QgX8zJ/aYU6fgTuJ20an47QTGqV6dX3e5Ho+m0UB+8CDRcJSUZLkLKYC7C/mUVYotqwJW5az Amjk1dsmiVUG3opnPnmZPPOH6e+6JsH5Ek4TvQ/+B+M41FKawIkhTzKaRwVP5T9FNskZQ0y6/DXP xtljLi+4Xz7mWhQiQXWh3q7+qGDyZwowOGjvXP6kmGj3ZZYn/RvahWhoLz0dkrbCT7iIdtmL0ILy ZLA5G8wfDmCD+d0BdFvdACxY3xTynZUe7btjKHcmkYiZRtZelVAKl37kwZdCSzn4ie6X7gX3S0WG PiN9Nteq0CNVhSv/lPFQ+AJiKoMlXgY8XKHjU/iWJ2k3LsRYrGJIARwvYyITQLshm/1WhrZ2Gryt w8FJ2gVT4AOSFVOsA5a2Po+hDhIxjBmFOqlCLfrDOAq+aIJrLIyE9okWguWakFEo0IAbYBeQyoqS peEjzSkYscWM0aBduDO4qPyBwzLgx8NursOOOX+MacDmPA7BAuMSGcB46rBcYS2phB1JBEZrZ0la tgsFLtclsU2bEBNN2qxOq2N1iAfigmvUMX3XkTZDGEoi6X65JFREVIY1mgZzDmoxLSnr2auSrSU0 /yjrIkpDKHA8xLtPF/egYtKQci1oxZ893bDQ0qlys7Y25KEBq6ciVF41Yu3ssyIV2gFmmhtWn1jS giasxNtnRaqK1dqwEtMlDoIb0UrkdgiQq6K1a7Se4UkbzqVFrorW2dAahgcmvMFa5Kpo3Rqta5ly HZ5rLXJVtN6GFjmbp+xAbJGrovVrtI7tvillyCW1pF4TUtHwJrDq1tIl736+wqHgSIErthTuHBWz lIoNeSqgVreETKoGPGrVg+LERwlW95zGs0rGSonBx6oMEx7UnyeYkOMyZhDX8lz7OzJm+jaB4kBE Ex2TMlRP1N6TaqNOJWUNAIdKTOpKhiW0xioAYJVE1LBSSdZYBQCsqvs6FlflGqsAgFXFfBSrAIBV FXoUqwCAVWV3FKsAgFW1dBSrAIAtC0R1AjK+UiTXvv0YFSSbAfhQRSufvye0JWMW8DTUYrZk8YEC 3aWXdXEC/WQe5c3Zqyd/Y8UZ8UUu5o2Nt8qKbE4fzQ6yQ29y0e7MVro22e3OpMXni1rZH5fdGQrc HwuaQ9tZaZyMtmyVG2ucY9kdA8yFTuxYr0ZcUL5rr9bTr70a9MvXXq2nm//HXs1RmnaoV5Ot0fmy ti9lUifPlrJj/dpGyq79GsZ8u/+59mtHZjrf3fHsNlTXfg1HaOVucDc2P2q/5ipt+0AF29qEOthh ni9sZb8WChggbm9HSbmnOroflXfdnX7Byc3AUv6Q+/sZzKJxsvyXTQYOsW9Jy7wjfstyfKM1GNhe q+MMiOkPyK1/O/pbr4asIbgqooSNoqdFzh4WQkf218cCsDGRtxZ9Qto+TuH9zTYDTEGWy3bTMCks R+0jznHGWp92upfIz0xAB73/DCKvjD5PydFlI+KriIzjKGTa/SKZ7sRFTiLeum7hLQ9QHwzNK+OU U0KzXr6mM/Atw3da1t2t17JGjt2CaaPVGhhDcud7w453666Xb4Gep2Ddqav229d/fvn29d8LrFk5 py7f9sAhvhKSUhHnn2j2sJSbUngTBit2KE9l8O4L4oLQDQQ51Lu0/n8AAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgu eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQRO+C/xD2 btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnO gPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB AAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj 6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFF FoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfo EMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV 0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJl bHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A1 1LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT 5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqk nN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGm XkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZP Gt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5W QzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMA UEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB 4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQ c9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/ VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOEj8EK wjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E 63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKa O/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ 3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0 A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+X i+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1 HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDkueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa /WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWag CVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUz cqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAt AAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzhI/BCsIwEETv gv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2 Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZV tVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbq a277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhAPCJRJ7VAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTUueG1s LnJlbHOskMFqwzAMhu+DvYPRfXZS6BijTi9j0MMupX0AYyuJWSIbSxvr289QCgkUdtlJ/BL69KHd /mee1DcWjokstLoBheRTiDRYOJ/en15AsTgKbkqEFi7IsO8eH3ZHnJzUJR5jZlUpxBZGkfxqDPsR Z8c6ZaQ66VOZndRYBpOd/3QDmk3TPJuyZEC3YqpDsFAOYQPqdMn18t/s1PfR41vyXzOS3DlheIoB K9CVAcWC1tcOX8tWV1kw9z3a//SgJMgfjgXLymbRZ7MI7c3MrN7e/QIAAP//AwBQSwMEFAAGAAgA AAAhAH5DMFrVAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTQueG1s LnJlbHOskMFqwzAMhu+DvYPRfXZSyhijTi9j0MMupX0AYyuJWSIbSxvr289QCgkUdtlJ/BL69KHd /mee1DcWjokstLoBheRTiDRYOJ/en15AsTgKbkqEFi7IsO8eH3ZHnJzUJR5jZlUpxBZGkfxqDPsR Z8c6ZaQ66VOZndRYBpOd/3QDmk3TPJuyZEC3YqpDsFAOYQPqdMn18t/s1PfR41vyXzOS3DlheIoB K9CVAcWC1tcOX8tWV1kw9z3a//SgJMgfjgXLymbRZ7MI7c3MrN7e/QIAAP//AwBQSwMEFAAGAAgA AAAhABc87WrVAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTMueG1s LnJlbHOskMFqwzAMhu+DvYPRfXbSwhijTi9j0MMupX0AYyuJWSIbSxvr289QCgkUdtlJ/BL69KHd /mee1DcWjokstLoBheRTiDRYOJ/en15AsTgKbkqEFi7IsO8eH3ZHnJzUJR5jZlUpxBZGkfxqDPsR Z8c6ZaQ66VOZndRYBpOd/3QDmk3TPJuyZEC3YqpDsFAOYQPqdMn18t/s1PfR41vyXzOS3DlheIoB K9CVAcWC1tcOX8tWV1kw9z3a//SgJMgfjgXLymbRZ7MI7c3MrN7e/QIAAP//AwBQSwMEFAAGAAgA AAAhAK0a3M3VAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTcueG1s LnJlbHOskMFqwzAMhu+DvYPRfXbSQzdGnV7GoIddSvsAxlYSs0Q2ljbWt5+hFBIo7LKT+CX06UO7 /c88qW8sHBNZaHUDCsmnEGmwcD69P72AYnEU3JQILVyQYd89PuyOODmpSzzGzKpSiC2MIvnVGPYj zo51ykh10qcyO6mxDCY7/+kGNJum2ZqyZEC3YqpDsFAOYQPqdMn18t/s1PfR41vyXzOS3DlheIoB K9CVAcWC1tcOX8uzrrJg7nu0/+lBSZA/HAuWlc2iz2YR2puZWb29+wUAAP//AwBQSwMEFAAGAAgA AAAhAJn2ma7VAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTIueG1s LnJlbHOskMFqwzAMhu+DvYPRfVaSwxijTi9j0MMuo3sAYyuJaWIbSy3r289QBgkUdtlJ/BL69KHd /nuZ1YUKhxQNtLoBRdElH+Jo4Ov4/vQCisVGb+cUycCVGPb948Puk2YrdYmnkFlVSmQDk0h+RWQ3 0WJZp0yxToZUFis1lhGzdSc7EnZN84xlzYB+w1QHb6AcfAfqeM318t/sNAzB0Vty54Wi3DmBPAdP FWjLSGJA61uHb6XTVRbwvkf7nx4xCfGHZaGysVn1GVeh/TXDzdv7HwAAAP//AwBQSwMEFAAGAAgA AAAhAKNy5/E2BAAAYBAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMWNtu 4zYQfS/QfyDUZ611vyH2wvbGfckmQZ39AEaibWGpSynatVsU2N9qP2e/pDOkaDmpi00Lo/CLQ1HD 0Zk5M5yZ3LzfV5zsmOjKph5b7jvHIqzOm6Ks12Pr09PCTizSSVoXlDc1G1sH1lnvJ99/d9NmHS/u 6KHZSgI66i6jY2sjZZuNRl2+YRXt3jUtq+HdqhEVlfAo1qNC0F9Ad8VHnuNEo4qWtdWfF28536xW Zc4+NPm2YrXUSgTjVAL+blO2ndHWvkVbK1gHatTpl5DkoQVrZSk5s4gSEzvYcK0JWJ4veUFqWsHG E0qQJS8Lpl517ZNgDIXq3Y+iXbaPQp243z0KUhaooT9pjfoXvZh6rEEMFqNXx9dGE832K1FNbmgG jiD7sQV8HfAXDtGM7SXJ9WY+7OabhzOy+eb2jPTIfAAQHD8KVLfaor+b4xlztCPco1ValMLRuyb/ 3JG6ATvRfG1efr8zytBmVN9uiPZ6LoXS1ovq98ol5kin3GqwHp0RJWHiaI94ru8EXvjSL3EcewEK oHfcIHYcLXFqtVbdZnI/a4oDevUZ/ipWaMY7uZQHzpS3wSc0A+TwA9xyihnDavvTEjKmknPOKGRU z4yczHmZfyayIawoJflIO8kEkSp6OlR5AyAkMN+rZHXxSAX96ZVmdB7N4MvgDoMQlpqff2bJNywt t8/6m94liOq2z5ooiGwIO8Pt2wlz/diNesb8JIngTnjJWAR0KUoVY3HoobR2gk4EZbyOH+OPs4wh TXzHXQgcUlFxpzKnrAvIfrWkfA1sQeRBFoOC7T3cdorlgq2ABNzsGsjyRcm5esArjs25IDvK4aLY 480ADJa11Dtx6ByhqvsQhRV7J3qAS6Mflj0+1ANLb4AahDF6hlwfXgTZ4/UHvKkbqDS7PrwIsscb DHiPYXh9gBFlDzg8AZx4iUqL6wOMKHvA0QDY8xLI3KsMYUTZA45PAMeBf6U5hyh7wMkAGNFeadIh yh5wegI4CmN1919fDCNKdVWbeo/oL1DuoV7+XxU/MBX/A5WMPHKas03DC+g5/EtU/kJCk/MrtNiU r6AuqeqvCzN2rsp7uFgqR2J/ohqooWc5W6OHrmoF/TU2y7+F7ixyw6lr+7duagdR6tmzWZjYTjRz /XTmTtPp4ner7xsLMFWWFVuU661gD1tpIW/fbs40OGy/XHeU4kyRDt0YQEEtl+3HQsPOommwDzzl J7gEPytoZBRBP2+pgC8Yjr7RogEDb+bosh6JjEfUKEXut9XzK7+oXh5mLzM4/KfRAmZWUH3WNaoj VlPG5cLXj2Zp4KWRHdxOEztYRKENZTuwZ97cvU2TuZNM42P4djhE1oDu30bt1y9//PD1y58XiFnV TesBFpY45qoZlYuPtH3YqUsc5nqIJ+hlYauFSR6bcRAdRFCH+c/A5C8AAAD//wMAUEsDBBQABgAI AAAAIQBKr3U51AAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGUxLnht bC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04vY9BDL6V7AGEriWliG8sb7dvXUBgJFHbZSfwS+vSh 7e4yT+qHs/gYDLS6AcXBRufDYODr9PnyBkoKBUdTDGzgygK77vlpe+SJSl2S0SdRlRLEwFhKekcU O/JMomPiUCd9zDOVGvOAieyZBsZN07xiXjKgWzHV3hnIe7cBdbqmevlvdux7b/kj2u+ZQ3lwAmXy jiuQ8sDFgNb3jtxLq6ss4GOP9j89QiwsB5LCeWWz6Asuwq8Zrt7e3QAAAP//AwBQSwMEFAAGAAgA AAAhAE5Gp9dLAwAA8QoAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWysVlty 2jAU/e9M96Bxvx1jXsUeIIMJ9CcPppAFKLaM3ciSKwkX2ulMttUuJyvplWyThtAZKPz4IV8d3Xvu 8ZH6l+uMooIImXI2sNyLhoUIC3mUsuXAul9M7Z6FpMIswpQzMrA2RFqXw/fv+rkvaXSNN3ylEGAw 6eOBlSiV+44jw4RkWF7wnDD4FnORYQWvYulEAn8D7Iw6zUaj62Q4ZVY1Xxwyn8dxGpIrHq4ywlQJ IgjFCvKXSZrLGi0/BC0XRAKMmf06JbXJoVr+8MVCJkgU8OpaQ6g7nNMIMZzBwCJVlCBgB405U4Bk AmS+EIToUFZ8Evk8nwkz77aYCZRGGqeabznVhyrMvDIIgwdnZ/qyRsL+OhbZsI99IAOtBxb0bKOv MAn7ZK1QWA6GL6NhcrcnNkwme6KdegHIYLsotDsvK3pbTrMup6TD3VZVhmKYes3DR4kYhzp1+WV5 4W1Rg+maNXyeoJJ5pZmt4sqPho86XgKnhiy1Dni00YU/wN0MYp9KNVcbSgwhkDb2ARwuQD/FWtiE 2fdzEHamxpRgEH5FnhqOaRo+IsURiVKFbrBURCCTDPwGANkHdhQ0p4IkLJphgT/vIOv6sA8rQ9J1 hvBYUvhvIls1kZWa0IzikCScRpBE8zRa0whEUTN/BkahAYgWdEvdiQxr2RqC5SuGSxYNlXCplzRl HNHUOQk5/KOUFIQeAG+YPgJ+kaTicPSW7uMR6FO+Eio5OPn2sfBpvBcdnOSs2m7X2r7CirwStiEE bLV2g//yi0jB7/wdPB/T2AKT1WI3P7WxDW0uJ/lHDJavnftHxw26bmfk2q2J69ntrte0g6DTsxvd wG15gTvyRtOfVmViEZSq0oxM0+VKkLuV3h6g8ztm8daGSnPTRuO6jqc3Oe9FtpCKRjlvdzp1d6ac a8f723iMok7tT6xE2aCvKyxghbpHZ3Sk8zLSrRmZ0zQi6HaVPezw0jnNkMt9Dg5RAL2XGmNDZ5Zv qxt47abXtduTUc9uT7sdu9dotO2gOXYnXm/c6I0+buUrdeUMsjtWtc9Pvz48P/0+g2bNplmepuBR n7zMgYmKG5zfFWbPgYMm6GlshnI4Wuq9F0JfQjRGfVQd/gEAAP//AwBQSwMEFAAGAAgAAAAhAByY O5oSBAAAwxEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWzsWN1y2jgUvt+Z fQeN99r1D7ZjewIdoGFv2iRT6AMothy8lS2vJAh0Z2f6WruP0yfpkWwRQsgCGy5zkxj50yed7/zo WJfvVxVFS8JFyeq+5b1zLUTqjOVlfd+3vswmdmwhIXGdY8pq0rfWRFjvB7/+ctmkguYf8ZotJAKO WqS4b82lbFLHEdmcVFi8Yw2p4V3BeIUl/OT3Ts7xA3BX1PFdN3IqXNZWN58fM58VRZmRDyxbVKSW LQknFEvYv5iXjTBszTFsDScCaPTsp1uS6waslQ/s5u4PC2kcX8KIZw3A9GxKc1TjCgZmDwyNWS2B Rr8SzYwTokD18nfeTJtbrmdcL285KnPF0M20nO5FB9M/a4DBg7Mz/d4w4XRV8GpwiVNQAq36Fjhs rf7CJJySlURZO5g9jmbzmz3YbH61B+2YBWAHm0XB101r0XNzfGPOrJSUIG9jVQvFMPUjy74KVDOw U5nfmpddLw2ZslnRN3PUya6oOlz7Uuth8AI01WLJ1Yjla2X4HfzXgzilQk7lmhItCGwbp0AOf0B+ ilVUk9r+MoWoruSYEgxR34knB2NaZl+RZIjkpUSfsJCEI6ntEoryEtSR4JyOktT5Leb48w6zsg+n sDJs2uwQHlsJXxayZ4TsogndUpyROaM5bMJ/naziG2QDpoUFEQjhYXzwgrZKrp0oC8ILyFcdal7k uupZ62sCLnB7MYxbSIVdEPphEvW0Aw2TFqB1s9Fkr9fU2nRJPZ02OM1JoeRV+/fjdlHQdgsAj/4e bLCNNQDA9vZg3W2sAQA2eI71nuzBAAAbHsIaAGCjQ1gDAOzFIawBADY+hDUAwCaHsC1Aad2lk3KM ziaYiYBhkzavzC4VQTq5xJPsajNod0kduCck9JRkrM4RJUtCj6DXWXYC/Wxe8uPZdUKcwD5hCy7n R28+aDPyaHdMymIvO5wiZ61rwX/VNa0JnKfmMDjxuNipa9p/+qhQlUY/bJ8Z++paFMRvhQ1OhLfC lr4Vtk0j9FbYjmjYQlPYPmBJnnRruhT//6rWNsG5hB51p2/TDnq5wJ3SFBfwBaM+R/4KvVHkhUPP 7l15iR1EiW+PRmFsu9HI6yUjb5gMJ39bXWeeg6myrMikvF9wcrNQ3zxwpO10wM97a8gt3S/Kgec5 ifpsSx7PY9iKYjnvsRMZ70wYU238djcdqqPytf4pJG8d9OcCc1jB9NYHmutTfHReRS6MIlNa5gRd L6q7HV2ic+gC1wJAvVeaA+fzKdJswrcXjZLATyI7uBrGdjCJQhvOssAe+WPvKonHbjy82ISvUJbX sLtTo/bH939++/H93zPErC4s7RUBPKqLBB2KlH/Czc1Sd29wdQLxNNZDDVyWgC4K+ghRHObyZfAT AAD//wMAUEsDBBQABgAIAAAAIQBpol8hHgEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVs cy9zbGlkZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAUB/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPlii onYsbz8pDBIojkLAm4CK5/z4K+Z4+hl68o3GdkoyyJIUCMpKiU42DD4vby87INZxKXivJDIY0cKp fH46fmDPnd9k205b4qtIy6B1Th8otVWLA7eJ0ij9Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2Bg zsL3v4zad/6/tqrrrsJXVV0HlO5OC2r7TuA7H9XV+bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZs G5Jl+ZI0568Zzg7yNkNv3yzkWJTx6K3KQ7JsyYAelQUzK2LKimBmcUMLpraJmdommJp/6+M9rVka sq1j0tYh2T6mbP8no7Pfb/kLAAD//wMAUEsDBBQABgAIAAAAIQBBeVM61gIAABQIAAAhAAAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1srFXRbtowFH2ftH+wvOc0CQRGIqAiFPbSFjTa D3ATh0R17Mw2DDpN6m9tn9Mv2bWTtF3XSZ2WF3Dse4/vOffYHp8eSob2VKpC8An2TzyMKE9EWvDt BF9fLZ0RRkoTnhImOJ3gI1X4dPr+3biKFEvPyVHsNAIMriIywbnWVeS6KslpSdSJqCiHtUzIkmj4 lFs3leQrYJfM7Xne0C1JwXGTL9+SL7KsSOiZSHYl5boGkZQRDfWrvKhUi1a9Ba2SVAGMzf69JH2s gK0uNKMrzo4Y2VC5h0kfT4F9smEp4qSEiSsThWyYWVHVlaTUjPj+k6w21VrahMv9WqIiNQBNInab hSbMfnIIg4H7In3bIpHokMlyOiYRaIEOEwwtO5pfSCIRPWiU1JPJ02ySr16JTfLFK9FuuwFU8Lip YVUz+pNOr6VT6+A/sqpDCaSei+RWIS6Ap6Ff00su9y2Y4Wzgqxw9E76JqxetHm28Ak2tWPoQi/Ro iN/Av50kEVN6o4+MWkGgbBIBOPyA/IwYX1PuXG/A16WeM0rA9414ejpnRXKLtEA0LTS6IEpTiawL 4BQA5BjU0dCcBpLydE0k+fwC2fAjEewMRbcVwrCW8O9C9lshz4imaM1IQnPBUqig14WmqQbKd3As CMswGBFc4lviVlrTgP/SOIPzYNz9beDHQ38w853+wg+dYBj2nDgejBxvGPv9MPZn4Wz5HTeNToGq Lkq6LLY7SVc7jd/WqtoAphm+74bmHgifegOlGJRuuxO03VkKYVzxvD/9LvqTaVk36MuOSNih7VF7 Xjo4B90qMmgV2bAipehyV9680CXoQhd4ZwD6VWnsuejYvv1hHAa9cOgEi9nICZbDgTPyvMCJe3N/ EY7m3mj28dG+yjDnUN2/uvbh/seHh/ufHXjWXiz1iwND8yzZR4XJC1Kt9vbmg7cY/DS3UxW8vs39 +xRiMNrXfPoLAAD//wMAUEsDBBQABgAIAAAAIQDKLH6tkgcAADIvAAAhAAAAcHB0L3NsaWRlTWFz dGVycy9zbGlkZU1hc3RlcjEueG1s7FrdbuM2Fr5foO8gqJcL19avZWOcIk7H3QHSadCkD0BLdKwN LWkl2k26KDDv0DfoW3T3ro8yT9LvkJQsJ/aMgzhAJjAQ2BR5eESe7/zHb769XQhrxcsqzbOR7XzT sy2exXmSZtcj++erSSeyrUqyLGEiz/jIvuOV/e3JV/94UwwrkfzAKslLCzyyashG9lzKYtjtVvGc L1j1TV7wDGuzvFwwicfyupuU7BfwXoiu2+uF3QVLM9vsL/fZn89macy/y+PlgmdSMym5YBLnr+Zp UdXcin24FSWvwEbt3jjSCe4XX4qEvqfX+vMnPrPS5BZS6vUc++QNG6p78jNRWismRvb02rG7J2+6 tAXEZkSbq+Kq5JxG2er7srgsLkp6iN+vLkrwBEvbytgC8iUGasGQqccMZJrxxvbrmhMb3s7KBZ0I 4rFwQqB4R5/YxIb8VlqxnozXs/H8xy208fztFupu/QJcrXkp3Urf6OF13Po6V6kU3LoQLObzXCTQ FSUidUO9DVIszvP4prKyHHcmUeirQjg1Y7o/vaqYW/KugJQksTV0ehEnyxr6Ssm3PnQjFT/oQ+mU aNy+H3rRpnwi1x2EtE5Schzf6+GBzrJmVJSV/J7nC4sGI7vksVSKwFbnldSkNYlCXx+kGMrbcZ7c ERhTfANzWBz2z/PyV9sS77JqZA8c38e7pXpQJ7Wtsr0y3ViR4iyHymEHy2LwGdmxLNVZMljb6VLm s9ScSL+SXi4qeSnvBFdqAfDYEGLFBw4kGBk8zzo/X8LgF/JMcAaHYFRInpyJNL6xZG7xJJWWsXsF A9wDWJKUpJKVYsmz5IKV7Kd7nI2IlGxqmQA5rUi71clr1Il0ua1NLgH0VG0iAdnGtJ+iVA60hxRM ibe2ug2t8gM3GITey9cqUotHKRIszhIrpZHq+k9ULJKe0qtqQ7GgZEpt9Uf9SuUxHqHLlzzOs8QS fMXFHuyVjj2C/dU8LffnrpThEdwn+bKU870P72tt3BuOSTrbyh1h5KAm7dcm/R2TmwFCCeSpJp1I eLFf4WGZmBnTVjCqMEHB5JHxIvQC/N0zbdfxvCZgeGHguMHLt+yNeKFMtY4KKkKshEOmzMQ1vL+w aS7hM/LjJE6H3BvNVblIk0kqhHqgdG+dBslbnR3JNJM6MeoH61Da5EwqWLT4wLb1m9QCfAkdRI9N 2KJ3KcufiURlTf8NnHHoBKdOx3vrDDp+OHA743EQdXrh2PEGY+d0cDr5DUFVJQ0JNE2mCz5Jr5cl /3GpQ/fngx+OoeQkTxynO6CUc7D2GjgKHeuwxhHUxjHJc8qv2xFPGfRTzWOGXEEB+p8lK/EGYyI6 MFEmta+JeI7r1znVdhuJBsGrtpE67Xp5VnJYnQxrnbyE5XPr/XIxvaeZyvk9VTNRVIL1NuVUiv8o /x0Ggfdp5XztDlxXBC9PNRsH7oXjgY+yq+O/PY06/iQMOlGv53fG7pnzdhCd9aLTfuPAK9K8DNpB Hvcxfvvjhz+//vjhfwfw2qpY0bU8hnWHIBblD6ywUP8jZkrU8giBIzu5wWh67dIcCmJ5i1FygxGL YzQdQGEG9QzW9UxD49UzqID0kl/PIIHSM0E9g6ihZ8J6BjY7F2l2gzyIvmxrlot/6Yl6RAmLauWc s7t8Kd8lKGTvzahQ6zp+34+80B+gLB1Sy6J8l5haHjZb796gRb60pjWV2k5ayKrha1LAnbSQT0Nr 4uFOWkiuoTUeaictZNrQhg8ks3k3SLuh7X+GFjg0tKrpsCHxTb79Fu3gM3zRm2v4Oio5/QTjDeDq JktLFAZ4eataBBUpgarv1SNZnEnJTG5Icc+CZ7li00tkhqp9QXhL3ZXg7Dwbl9A84Erducw8gmSO VgNagBfLLEYPxHTSinhMHTPqBsUXsckb1ZWQF2LOrE6X79GGVOlYy6uhcwK+N7ykFua+KSqYEOt2 IqsOqrLFGRpWI/ufi393hCQQkOGxewuc6YW4urcQV7SwK53dlCpahWg+PBDxgpXnI9uDZ6SLpRnc HkTVqSfq7Py55Q9R6nbGPQwmOTJ7Sqq1mE7LlAnbKlIZzydskQr0zzzYUjxnZcVxcFM3TZdnmFHT I/vjhz+0/Fo46mj9HDhmu3DMOjtwzDqfxFGZg0ulksaqD6zI3zVYuVGAsgcu2VRSXzZWvz/AykWc fh6bOyBWBJBxXd4aq7q32wLLjVSR8jrAemhY7rM5yAOCRQgZsPwWWKap+lrB2mJZ5HSfJZodECxC yIAVrMFye0FfqdraDb4iy/rr/w+94JeAFQFksApbWAWOr5zeq8RqW3pB6cyLNyxCyIDVb4E16Dsq 4B7B+lTbea+c/oBekBAyYEVrsHSaDlU7gvWSwCKEDFiDFlhRFKom4RGslwQWIYQieqM+Loa5nPOy qZZROV5oSE0N2f4RQ1OCG5K6e6HLNRjn4XP9ViWrnfUXWcnWv5I5ymd79Vh3uo7y2VGweX36IczR wFZie5HkRG6kcrmjBu2oTFTNeNQghKwd1UDf163SowbtyMCR0ak+xFFAO7LeMOgfnbRq4jeZZju5 ROK5/kcY/dO3/q37yd8AAAD//wMAUEsDBBQABgAIAAAAIQDmEGt4YwIAAMgFAAAfAAAAcHB0L25v dGVzU2xpZGVzL25vdGVzU2xpZGUxLnhtbKxUW2/aMBR+n7T/YPk9DZcOaESogMJUaaOotD/AdRwS zbfZhkGn/fcdOwllbTe6aS9wcu7fd47P8HInONoyY0slU9w+a2HEJFVZKdcpvr+bRwOMrCMyI1xJ luI9s/hy9P7dUCdSOWYRxEubkBQXzukkji0tmCD2TGkmwZYrI4iDT7OOM0O+QV7B406r1YsFKSWu 481b4lWel5RdKboRTLoqiWGcOOjdFqW2TTb9lmzaMAtpQvQvLY0AG13xzP9bfWcY85LcfjR6pZcm mBfbpUFlBoxhJIkAYnBcG2q38CnBDYT4Wfi6yUSSXW7EaEgSwIZ2KQb69/4XgkjCdg7RSkmftLS4 ecWXFrNXvOOmAHRwKOpRVYhewuk0cFa8zBi6FmTN0JITygrFM2ZQ+4CzCiaQ7JOiXyySCpBXhKhb 5WppWhC5ZmOrGQ2qig262Da1PUW+G10gt9dApOXZtVj7MoE2bw1CE2BhBpWxgvF7MN0GzCJs6jGM zmkYpzt9UNkewxbAiAItf+xXJ243gQA/WB/ocRF4Q0aMN07lpfP1jk3cupXbcwZ6ksDAYB9ktiSG 3MLqcWA1xUxG96vAVPCA+k0NEE+xc96wU416sREPMN9jkrr/gyQYJ6SGI/KY4q8bYhwzDWdhzf+S tMDGS2pynoXn+L0/mc17F51xNLlq96Lz8cU8msxb02jW7w8+dCbdQW/c+oEPqwZLLqE7z655Riuy wk05I3AW6/dYLR5J3KjtR+XCwKDyv80mjKi6LiA2B4dy85nom23YDrijQNc0qDRcznoln1w8eX63 Rz8BAAD//wMAUEsDBBQABgAIAAAAIQDAsvQ6rgMAAAgMAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDExLnhtbLRW3ZLSMBS+d8Z3yNTrbmlpC+0sOICLN/s3gt7HNmw7pklNAoKOM76W Po5P4knasC6LI7h4U0pzzpdzvu+ck5y/XFcUrYiQJWcDxz/rOIiwjOcluxs4b+dTt+8gqTDLMeWM DJwNkc7L4fNn53UqaX6JN3ypEGAwmeKBUyhVp54ns4JUWJ7xmjBYW3BRYQV/xZ2XC/wJsCvqBZ1O 7FW4ZE7rLw7x54tFmZFXPFtWhKkGRBCKFcQvi7KWFq0+BK0WRAKM8X4YktrUkC0Qo+alomTE8vna QcZerGDFd4ZAQTajOWK4gg/vwLTMMEXGHgFjaE7WypjJei4I0Q5s9VrUs/pWGO/r1a1AZa7RWhTH axdaM/OXgRm8eDvudxYJp+uFqIbnOAV20HrggIgb/QQnnEIQKGs+Zvdfs+Jmj21WXOyx9uwGEMF2 U9C/bjJ6nE5g09khxd+m1/hgwLjk2QeJGIeENQ9Nntn1yqLq5PU+dYEaTZTWw0FclKBcI1Hr1Zga mqy3NFTb+LcExXGQhJ2GpqAXxt3+Q66CTtQz65qxqB/5URCZTSwSbNJA16laj3m+0Uy/h18QVBfN wCFYJ9/AUqlmakOJ0QNYwymkBA8wplg3GmHu2xk0WqUmlGBoxFY7NZzQMvuAFEckLxW6wlIRgQwF 0JYAeQ7iKKiNFpKw/BYL/GYHWbOKU9gZ4rbxmhQ0s3/WsftYR11NtxRnpOA0h1ACnSE0ghXsnyTV xO0oCm0BNWvr4XBlw6gHg8XU/z5h446f9PX6/xIW6g3RFd0q+EShNd1GZ/lA6EZMoyg87JaGrSNq a0YyDmOKkhWhB8AbqY+AnxelOBy927TKwXxN+VKo4uDgw2Phy8VedJinJ22x0LbYK6zIg84yhDy1 s3IFU+UzHIWYLpy2p8xsMVNST1bz8vu4NP1sh4QdamZyPR5jCzj+9Pn1JfLHsR+NfLd74SduGCeB Ox5HfbcTj/1uMvZHyWj61WkneA6pqrIi0/JuKcjNUh+Sh0xDKHQThxr6vpfosz+5L1sIRaOcVp3I qjPlXA/e3yefqain6rNQohHo4xIL2MFq9JfBd4xGp2UktozMaJkTdL2s3u/wYg7Kp/ICd0uA3kuN GUMnLt9uPE7CIInd8GLUd8NpHLlwSoTuOJj4F0l/0umPetvylTpzBtEdW7U/v31/8fPbjxPUrDm7 mzslvOpbqDmEqbjC9c3KzFC4f0M9TcynGm7cUDLa9N5EY9gb/PAXAAAA//8DAFBLAwQUAAYACAAA ACEA7irsdmMDAAAoCwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWysVs1y 2jAQvnem76Bxz44xPy72ABlMQi9NwhTSu2LL2BPZciXhQjudyWu1j5Mn6Uq2SEnJDCRcjJF3P+1+ u/tJg/N1TlFFuMhYMbTcs5aFSBGxOCuWQ+t2MbX7FhISFzGmrCBDa0OEdT56/25QBoLGn/GGrSQC jEIEeGilUpaB44goJTkWZ6wkBXxLGM+xhL986cQcfwfsnDrtVstzcpwVVuPPD/FnSZJF5IJFq5wU sgbhhGIJ8Ys0K4VBKw9BKzkRAKO9d0OSmxKyBWLkYm0hbccrWHGtEaQezWmMCpzDwiKTlCAgCH0F 4yzCFC3IWmozUS44IcqhqD7xcl7OuPa+rmYcZbFCa1Asp/nQmOm/BZjBi/PMfWmQcLBOeD4a4ABY QeuhBcXbqCc44QCCQFG9GD2tRunNHtsovdxj7ZgNIILtplD3ss7o/3TaJp2aFHebVW2KwfUzi+4F KhjkqdKv04uuKwOmclbwZYrqEkjFb2NXf9R8GHsBnGqy5Dpk8UYlfge/ehEHVMi53FCiCYGwcQDg 8AD6KVYdTgr7dg4dnssJJRgmoCFPjiY0i+6RZIjEmURXWEjCkQ4G5gEgB8COhOI0kKSIZ5jjL8+Q VX44gJ0haBMhvNYUvkxkxxC501NoRnFEUkZjCKV9CnIVVRZiPIMhqLvdgr6EpjGVOYZxJSOAQrAK WkW3j38oF6IV3RL9xnqoJtflEDv1qDnXxMPDbKmTOqIF5iRiMNeUVIQeAK8rcgT8Is344eidmtGD +ZqyFZfpwcF3j4XPkr3ooDsnnYSumYQLLMnOAGhCQIqNdrxKXWIJw/8DjgpME9P6WgK0yCgpepPa JHBMKJ3/2XNDz+2NXbtz6fp21/Pbdhj2+nbLC92OH7pjfzz9ZTWSF0OqMsvJNFuuOLlZqcPkENGq pVDJkus6vjob/ae2hVAUymmr0zPVmTKm9PFfgdId9db6JJLXBfq2whx2MDV6jT69oEinZcQzjMxp FhN0vcrvnvHSO4Vww90LoPdSo2XoxO3b8UK/2/Y9u3s57tvdqdez+61W1w7bE/fS709a/fHHbfsK lXkB0R3btY8Pvz88Pvw5Qc/qI7a+e8Gruq3p6xXlV7i8qbSGwv0U+mmil0q4kaqTGkyfTBSGueGO /gIAAP//AwBQSwMEFAAGAAgAAAAhAICQ5aqrBAAAjBEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0OS54bWysWNuS2kYQfU9V/mFKeZZhdJdqwQV4yct6lwr4AwZpAJV1izRgcCpV/q3k c/wl6R5pAK3ZLIv1AkL0nJnuPn26pbv3+zQhO15WcZ4NNPqurxGehXkUZ+uB9mkx1T2NVIJlEUvy jA+0A6+098Nff7krgiqJHtgh3woCGFkVsIG2EaIIer0q3PCUVe/ygmfw3yovUybgZ7nuRSX7Athp 0jP6faeXsjjTmvXlNevz1SoO+Yc83KY8EzVIyRMm4PzVJi4qhVZcg1aUvAIYubp9JHEowNsiDhd7 jUizcgc3qDYEz8N5EpGMpXBjFodiW3LyJRYbMmEFnkPaVMWi5Byts93vZTEvZqVc+riblSSOEKqB 0HrNH42Z/JmBGVz0ni1fKyQW7FdlOrxjAUSE7AcaJO6An7CIBXwvSFjfDE93w83TBdtwc3/Buqc2 gBMcN4WcF7VHP7pjKHcWsUg4oUevalMGSx/y8HNFshz8RPdr98LHnQJDnxG+2JA6/AKhGrv6TxkP ZV/JmKqDHiNBXd8wPOAteG55wLL+s6jYludYcJNgbGzHcU1PbqKQYJMaugjEfpxHBwzpEr4hcywL NzkwdYkrWJBUYi4OCeQZrncJhRMRlqyhlBJgAQsivvoDblVfBxrwHbZcKs+P9pDkNg6EmAUQCPiA pQnDSuSZ/mkOlZiKScIZwDcuieEkicPPROSER7EgH1kleElk4KBu4WSILuQeEpJn0YyVDA91joy5 YAHsDL4rn2UYMB8vJ91USVdlMEtYyDd5EsEhDAwRFItK8E0UgArUoFyAy4owtxHBoYbr2nXSVHW0 eGBRimS5lggvZj9l5YOsxjiLQFrwElO53D6CfspVZ5wwgRTNjg170BYuDSRSDWXZLlqRa/CMkwcN SINnnvB8aknyX4WHljU3AA9BGjzrhEdNl2KJXXdALIIjIKI0gPYZoAfVexsgojSAzgkQ1AAOeNMJ EaUBdM8AXUtm7gaXEaUB9E6AiHZ9UloxRJQG0D8DdGz3xqQgymVN6lY7LKUdC6zHc+EwkSE/Kxyo 1yCYILwblqwaDZGSJHuI9BGb61y6qxRftYCLzcQ2oVXUveLUYlsi4vWhtdSbKKT/aSZSDS51kDdp CG3VKHaghg43aghtaRKCNHg3aght0bUDDfE7lpAWXgcK0sLrQEBaeB3oRwuvA/lo4b2sHkAkAk3k OLpIWt0+4aBoyAGnak04t0wxtlKiD0zwlhJZXShRJH7QIVo3QdSfi0Ik9U/NYWr2bMmF/CEnxRU8 i+DzxF82HTvUHlHdvKe+bjm+oY/Htqf3nTE1/TEd+aPp31ozWkfgqohTPo3X8PjytBUaVvnr6YAs yq3FkNKej89f/in+cBRE6bZPOCo70zzH2fa8U8iB7mc7xUqUdYL+3LISdlDz5isD51ty1G1EXBWR eRJHnDxu0+WzuDhd8Bae7wH6Ymhe6aNvCc2RvqYz9i3Dd3TrfuTp1tSxdZgCLX1sTOi970363sg9 0rdCzzM43VtZ+/3bP799//ZvB5yVjb1+xodLfCUgh5ak/MiKp51UN3gHAnyayFsFvPWAuKDpyQQx 1FuU4X8AAAD//wMAUEsDBBQABgAIAAAAIQCTYnka7QQAAB0SAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDgueG1szFjdctpGFL7vTN9hR70msPpD0hgyhpjeOLankAdYpMVSs/qptBBo pzN5reZx8iQ5Z6XFgpAgbF/0BoT49tvz+52Vrt5uU0E2vKySPBsZ9M3AIDwL8yjJHkfGh8Ws5xmk kiyLmMgzPjJ2vDLejn/95aoIKhHdsl2+lgQ4sipgIyOWsgj6/SqMecqqN3nBM/hvlZcpk/CzfOxH JfsE3Knom4OB209ZkhnN+rLL+ny1SkL+Lg/XKc9kTVJywSTYX8VJUWm2ogtbUfIKaNTqQ5PkrgBv 8+Wfi61BFKzcwA1qjMHzcC4ikrEUbkzzTAID+ZTImExZgXYoTFUsSs4RnW1+L4t58VCqpXebh5Ik EVI1FEa/+aOBqZ8ZwOCif7T8UTOxYLsq0/EVCyAiZDsyIHE7/IRFLOBbScL6Zvh0N4zvT2DD+OYE uq83AAv2m0LOi9qj790xtTuLRApO6N6rGspg6W0efqxIloOf6H7tXni30WToM9IXManDL5GqwdV/ qnhofKViqg3dR8J2hlBbKhzm0Bo4RzGxBgPPopZBMDKUumaDaHtcMxeB3E7yaIcRXcI3JI5lYZxD oS7rOItKzuVOQJpZIDaCgkGEiUfoJAFFwIKIr/6AW9XfIwNMApuW2vE9HnIM1y0eiDALIA7wAUsF w0bkWe/DHBoxlVPBGdA3PsnxVCThRyJzwqNEkveskrwkKm7QtmAZsku1h6LkWfTASoZGtZkxFSyA nSG+2me4rLP945xDEA+74EGwkMe5iMAI82UVkERQv7pIuiffcoYOJhSb4VT2HUopIOrsO55jUSiF 2v26oZTbdR3qSOjsq9Zqp6pJ+VGmLay+mrIFgEuzqdd2VXhtrAYA1jqBtdtYDQCsfQKL1ba3QQMA 65zDagBg3XNYDQDs8BxWAwDrncNqAGD9c9gacKqHYCUBhn2zvLCnUFNVS1UHPVX3jWoe+NBbqsK9 oI3nPMyziAi+4aIDveqtC+gXcVJ2Z1cNcQH7LF+XMP26Gm9jYV5Cn6xOssOYe1U1s7WaLTDVbSlT AYGxr0fVs4YZThCQcBgFMRMrA84AIHAqkWqooeSoi7mqeBRfvPWz6UZty6F1nz+N/IPxZrs+Hbgv FjiSsvJWHTGSLILTDl6iacv1HRwKVTZbmkYPdApnImKhE1HeGio9ozvxHejpkUY2fD61cVfSie9A G490tOGj1pC6XQn9n2it5vNMD6W+k4EHfEd63PCZpgfmPYfvSLM139BWY+ty+450veFDss4JOfD3 SPs1n+sMn5eP/8d8gM7Wpwl1wMBj7o/PVY5WondM8gMlUtr5UiWK5Hc6ROvTAj5tnBQi6PEnD06e h5QKqLPrCh6O8AHnH4dOXOpc0551Q/0eaJHZm0wcrzdwJ9TyJ/Tav579azRn/QhclUnKZ8njuuT3 a6kU5vwRGDRFbS3HlPZ9fCD0nwYomILa87pzwtXZmeU5nrbbk8LB2fbS/KxkWSforzUrYYdmVtAz p+FLcvS6ERnqiMxFEnFyt06XR3FxXyMu8MIBqE+G5swcvSQ0+/K13Ilvm77bs2+uvZ49c50eSLjd m5hTeuN704F3PdyXb4WeZ2Ad1tslVfv183+/ff385RVqVglL/dIBLvEdhSpFUb5nxf1GDWF4KQP1 NFW3CngNA3FB6BMEOfRrnfE3AAAA//8DAFBLAwQUAAYACAAAACEA/A0qSqcCAADCBgAAIQAAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbKxVW27bMBD8L9A7EOy3IskP1RJsB5Zj9ydN jDo5wEaibCEUqZK0a6cokGu1x8lJuqSspE1TIEX9Y1Or3eHOzJIanu4qTrZM6VKKEQ1PAkqYyGRe itWIXl/NvQEl2oDIgUvBRnTPND0dv30zrBPN83PYy40hiCF0AiO6NqZOfF9na1aBPpE1E/iukKoC g49q5ecKviB2xf1OEER+BaWgh3r1mnpZFGXGzmS2qZgwDYhiHAz2r9dlrVu0+jVotWIaYVz17y2Z fY1sbziIW0pcmtpiIKRjZJ4teU4EVBhIXYYN6vpKMWZXYvtB1ct6oVzuxXahSJnb2kMN9Q8vDmnu UWAaLvxn5asWCZJdoarxEBKUgOxGFJ3a218sgoTtDMmaYPYUzdaXL+Rm69kL2X67AXbwuKll1TD6 k06npXMGhpEFh4ytJc+ZIuEjwaYKEOVcZreaCImUrRIN0+xi2+Ja+nanek0a6XODg3eHJgIvKOqH 5EJH1ilkk92irdcot9PR7FKZ760mN/jvgpBwbZZmz5nTChlBUqCD1pSv/TCNwv4k9LqzMPZ6Udzx 0rQ/8IIoDbtxGk7iyfwbbZtCqqas2LxcbRS73BgcB0gUGoxjgAeGCe96iX1XZsoZ4IE62NM0B4kZ h6Ef26mNhyi4QRKuFWehyBeg4NMzMKsUJNgz0m254bLx5e/udFt35lIa9ORXfzrH8KcwqjHo8wYU 7tB61HrbGPpfHrGjKtJrFVnyMmfkYlPdPNOlewxd8FZE6Belcbo7RY43vt0ojXudOPJ6s8nA682j vjcIgp6XdqbhLB5Mg8Hk/eP4astcYHf/OrUP99/fPdz/OMLMutFtLkpc2ovU3YVcfYT6counGhL8 cuA8TV2oxm/F4a54SrEY7bdn/BMAAP//AwBQSwMEFAAGAAgAAAAhANzm9shjAgAAyAUAAB8AAABw cHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTMueG1srFRbb9owFH6ftP9g+T0Nlw5oRKiAwlRpo6i0 P8B1HBLNt9mGQaf99x07CWVtN7ppL3By7t93js/wcic42jJjSyVT3D5rYcQkVVkp1ym+v5tHA4ys IzIjXEmW4j2z+HL0/t1QJ1I5ZhHES5uQFBfO6SSOLS2YIPZMaSbBlisjiINPs44zQ75BXsHjTqvV iwUpJa7jzVviVZ6XlF0puhFMuiqJYZw46N0WpbZNNv2WbNowC2lC9C8tjQAbXfHM/1t9Zxjzktx+ NHqllyaYF9ulQWUGjGEkiQBicFwbarfwKcENhPhZ+LrJRJJdbsRoSBLAhnYpBvr3/heCSMJ2DtFK SZ+0tLh5xZcWs1e846YAdHAo6lFViF7C6TRwVrzMGLoWZM3QkhPKCsUzZlD7gLMKJpDsk6JfLJIK kFeEqFvlamlaELlmY6sZDaqKDbrYNrU9Rb4bXSC310Ck5dm1WPsygTZvDUITYGEGlbGC8Xsw3QbM ImzqMYzOaRinO31Q2R7DFsCIAi1/7FcnbjeBAD9YH+hxEXhDRow3TuWl8/WOTdy6ldtzBnqSwMBg H2S2JIbcwupxYDXFTEb3q8BU8ID6TQ0QT7Fz3rBTjXqxEQ8w32OSuv+DJBgnpIYj8pjirxtiHDMN Z2HN/5K0wMZLanKehef4vT+ZzXsXnXE0uWr3ovPxxTyazFvTaNbvDz50Jt1Bb9z6gQ+rBksuoTvP rnlGK7LCTTkjcBbr91gtHkncqOtH5cLAoPK/zSaMqLouIDYHh3LzmeibbdgOuKNA1zSoNFzOeiWf XDx5frdHPwEAAP//AwBQSwMEFAAGAAgAAAAhAMEduJBjAgAAyAUAAB8AAABwcHQvbm90ZXNTbGlk ZXMvbm90ZXNTbGlkZTIueG1srFTdbtowFL6ftHewfE8DoQMaESqgMFXaKCrtA7iOSaL5b7Zh0Gnv vmMnoaztRjftBk7O//ed4zO83AmOtszYUskUd87aGDFJVVbKPMX3d/PWACPriMwIV5KleM8svhy9 fzfUiVSOWQTx0iYkxYVzOokiSwsmiD1TmkmwrZURxMGnyaPMkG+QV/Aobrd7kSClxHW8eUu8Wq9L yq4U3QgmXZXEME4c9G6LUtsmm35LNm2YhTQh+peWRoCNrnjm/62+M4x5SW4/Gr3SSxPMi+3SoDID xjCSRAAxOKoNtVv4lOAGQvQsPG8ykWS3NmI0JAlgQ7sUA/17/wtBJGE7h2ilpE9aWty84kuL2Sve UVMAOjgU9agqRC/hxA2cFS8zhq4FyRlackJZoXjGDOoccFbBBJJ9UvSLRVIB8ooQdatcLU0LInM2 tprRoKrYoIttU9tT5LvRBXJ7DURanl2L3JcJtHlrEJoACzOojBWM34PpNmAWYVOPYcSnYZzu9EFl ewxbACMKtPyxX5243QQC/GB9oMdF4A0ZMd44tS6dr3ds4tat3J4z0JMEBgb7ILMlMeQWVo8Dqylm snW/CkwFD6jf1ADxFDvnDTvVqBcb8QDzPSap+z9IgnFCajgijyn+uiHGMdNwFtb8L0kLbLykZs2z 8By/9yezee8iHrcmV51e63x8MW9N5u1pa9bvDz7Ek+6gN27/wIdVgyWX0J1n1zyjFVnhppwROIv1 e6wWjyRuFPtRuTAwqPxvswkjqq4LiM3Bodx8JvpmG7YD7ijQNQ0qDZezXsknF0+e3+3RTwAAAP// AwBQSwMEFAAGAAgAAAAhAOkMvHJjAgAAyAUAAB8AAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlk ZTcueG1srFRbb9owFH6ftP9g+T0Nlw5oRKiAwlRpo6i0P8B1HBLNt9mGQaf99x07CWVtN7ppL3By 7t93js/wcic42jJjSyVT3D5rYcQkVVkp1ym+v5tHA4ysIzIjXEmW4j2z+HL0/t1QJ1I5ZhHES5uQ FBfO6SSOLS2YIPZMaSbBlisjiINPs44zQ75BXsHjTqvViwUpJa7jzVviVZ6XlF0puhFMuiqJYZw4 6N0WpbZNNv2WbNowC2lC9C8tjQAbXfHM/1t9Zxjzktx+NHqllyaYF9ulQWUGjGEkiQBicFwbarfw KcENhPhZ+LrJRJJdbsRoSBLAhnYpBvr3/heCSMJ2DtFKSZ+0tLh5xZcWs1e846YAdHAo6lFViF7C 6TRwVrzMGLoWZM3QkhPKCsUzZlD7gLMKJpDsk6JfLJIKkFeEqFvlamlaELlmY6sZDaqKDbrYNrU9 Rb4bXSC310Ck5dm1WPsygTZvDUITYGEGlbGC8Xsw3QbMImzqMYzOaRinO31Q2R7DFsCIAi1/7Fcn bjeBAD9YH+hxEXhDRow3TuWl8/WOTdy6ldtzBnqSwMBgH2S2JIbcwupxYDXFTEb3q8BU8ID6TQ0Q T7Fz3rBTjXqxEQ8w32OSuv+DJBgnpIYj8pjirxtiHDMNZ2HN/5K0wMZLanKehef4vT+ZzXsXnXE0 uWr3ovPxxTyazFvTaNbvDz50Jt1Bb9z6gQ+rBksuoTvPrnlGK7LCTTkjcBbr91gtHkncqO9H5cLA oPK/zSaMqLouIDYHh3LzmeibbdgOuKNA1zSoNFzOeiWfXDx5frdHPwEAAP//AwBQSwMEFAAGAAgA AAAhAPT38ipjAgAAyAUAAB8AAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTYueG1srFRbb9ow FH6ftP9g+T0Nlw5oRKiAwlRpo6i0P8B1HBLNt9mGQaf99x07CWVtN7ppL3By7t93js/wcic42jJj SyVT3D5rYcQkVVkp1ym+v5tHA4ysIzIjXEmW4j2z+HL0/t1QJ1I5ZhHES5uQFBfO6SSOLS2YIPZM aSbBlisjiINPs44zQ75BXsHjTqvViwUpJa7jzVviVZ6XlF0puhFMuiqJYZw46N0WpbZNNv2WbNow C2lC9C8tjQAbXfHM/1t9Zxjzktx+NHqllyaYF9ulQWUGjGEkiQBicFwbarfwKcENhPhZ+LrJRJJd bsRoSBLAhnYpBvr3/heCSMJ2DtFKSZ+0tLh5xZcWs1e846YAdHAo6lFViF7C6TRwVrzMGLoWZM3Q khPKCsUzZlD7gLMKJpDsk6JfLJIKkFeEqFvlamlaELlmY6sZDaqKDbrYNrU9Rb4bXSC310Ck5dm1 WPsygTZvDUITYGEGlbGC8Xsw3QbMImzqMYzOaRinO31Q2R7DFsCIAi1/7FcnbjeBAD9YH+hxEXhD Row3TuWl8/WOTdy6ldtzBnqSwMBgH2S2JIbcwupxYDXFTEb3q8BU8ID6TQ0QT7Fz3rBTjXqxEQ8w 32OSuv+DJBgnpIYj8pjirxtiHDMNZ2HN/5K0wMZLanKehef4vT+ZzXsXnXE0uWr3ovPxxTyazFvT aNbvDz50Jt1Bb9z6gQ+rBksuoTvPrnlGK7LCTTkjcBbr91gtHkncqOdH5cLAoPK/zSaMqLouIDYH h3LzmeibbdgOuKNA1zSoNFzOeiWfXDx5frdHPwEAAP//AwBQSwMEFAAGAAgAAAAhAC/fniqHBAAA tBAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWzMWNty4kYQfU9V/mFKeWaR hNCtDFvAmuTBa7uC9wPG0mBUO7pkNBDYVKr2t5LP2S/J6ZEE2HFqie1y+QXEXLpPnz490+Ls/TaX bCNUnZXFyHLe2RYTRVKmWXE3sj7dzHuhxWrNi5TLshAjaydq6/34xx/OqriW6QXflWvNYKOoYz6y VlpXcb9fJyuR8/pdWYkCc8tS5Vzjp7rrp4r/Dtu57Lu27fdznhVWu1+dsr9cLrNEfCiTdS4K3RhR QnIN/PUqq+rOWnWKtUqJGmbM7vuQ9K5CtLVIfhE8tZhZqDYYcqwxYk8WMmUFzzGwEAk5Z7RQKDNb VzdKCFpXbH5W1aK6VmbT5eZasSwlI+1mq99OtMvMzwLL8NB/sP2us8Tj7VLl4zMegw22HVlI2o4+ sYnHYqtZ0gwmh9FkdfXI2mR1/sjqfucACPZOke+qiejf4bhdODeZloI5+6iapRxbL8rkc82KEnFS +E14yeWmM0Yxk/lqxRrqNZlq1zWTho9ufW047YDumQhcd+AMDB2eZ/uR/YCUIAhcD4OMqHEGvmsH Q+OkswQnjekq1ttpme6I0lt8I3O8SFYlVKppB49lrRd6J5FnPG+kA0SMyzuUkYQKeJyK5a8Yqr+M LLiEz1uT+ISDAS5l67bdiXTftwiyeQxK8AEjklM9iqL3aYF6zPVMCg5HbXR6PJNZ8pnpkok00+wj r7VQzFCI6gVGsq6ND2NSFOk1V5zgHVumrPAYnsFCF70hhDLz3+kH300p3JD2riVPxKqUKAbmUpCo li7PT1ICsW+hbKDpTjhPEoQb2X4AcZjkdVVyXxBD23bCoM1MU2SnCOK2sfmYIHKuLkyBZkWKk4Ye Kae360scpwbJkUxwJDbTdSmzdJ5JSWvNaSpmUrENl1Dflo4gpDMrdDMSALZRApK3X2xSeWQHc40n M7FXnZGuS9JtkHrDAChA9wlwnfAV4RJGChvIBwe4kYMyPxWu/4pwCWML1zvAdQaBQyhOo5ciMwJ4 BTUQyBbv8Ahv6IaU5LeHl0C2eP0DXtcNQe9bxEsgW7zBEd7AG5xebq+pBwLZ4g0PeAns6fX2mngJ ZIs3OsLrD4O3WW8EsjmJj7oIc+cTehxy+8vdhPX0HoAuOtMC1Pd6gKfc8153z3/gWty7582l+tx7 PtVobdAsrbhcdvd9c61RI2zoooeFYa5p00x30XUqXZ9mbtXuLjY/DK9LdOzUe/8xdKa+M5w4vcG5 E/U8P3J70+kw7Nn+1BlEU2cSTeZ/Wm0bmiJUneVint2tlbhaa4tU9v10AKRxrceO04/oPSU68A8o ZOVlu7Bhl515WVL3d9yHedSgPDc/S62aBP225goeuhx9pykznk/M0csy4neMLNBNCXa5zm8f8GJ6 /+fygvdgmH6UGtP/ooN8SfkO/GnkuZHf884nYc+b+8MermivN3VnznkUzuxwEuzlW1PkBdD9X9V+ +/rXT9++/v0CmjUNdPM+jEd6cTZSlOojr6425nTDfwXQEzpcDFX4dwCSoaWHJWSj+7dh/A8AAAD/ /wMAUEsDBBQABgAIAAAAIQDT+iHCYwIAAMgFAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xp ZGU1LnhtbKxUW2/aMBR+n7T/YPk9DZcWaESogMJUaaOotD/AdRwSzbfZhsGm/fcdOwllbTe6aS9w cu7fd47P8GonONoyY0slU9w+a2HEJFVZKdcpfrifRwOMrCMyI1xJluI9s/hq9P7dUCdSOWYRxEub kBQXzukkji0tmCD2TGkmwZYrI4iDT7OOM0O+Ql7B406r1YsFKSWu481b4lWel5RdK7oRTLoqiWGc OOjdFqW2TTb9lmzaMAtpQvQvLY0AG13xzP9bfW8Y85LcfjB6pZcmmBfbpUFlBoxhJIkAYnBcG2q3 8CnBDYT4Wfi6yUSSXW7EaEgSwIZ2KQb69/4XgkjCdg7RSkmftLS4fcWXFrNXvOOmAHRwKOpRVYhe wuk0cFa8zBi6EWTN0JITygrFM2ZQ+4CzCiaQ7KOiny2SCpBXhKg75WppWhC5ZmOrGQ2qig262Da1 PUW+G10gt9dApOXZjVj7MoE2bw1CE2BhBpWxgvF7MN0GzCJs6jGMzmkYpzt9VNkewxbAiAItf+xX J243gQA/WB/ocRF4Q0aMN07lpfP1jk3cupXbcwZ6ksDAYB9ktiSG3MHqcWA1xUxGD6vAVPCA+k0N EE+xc96wU416sRGPMN9jkrr/gyQYJ6SGI/ItxV82xDhmGs7Cmv8laYGNl9TkPAvP8Xt/Mpv3Ljvj aHLd7kXn48t5NJm3ptGs3x9cdCbdQW/c+oEPqwZLLqE7z655Riuywk05I3AW6/dYLR5J3OjCj8qF gUHlf5tNGFF1XUBsDg7l5hPRt9uwHXBHga5pUGm4nPVKPrl48vxuj34CAAD//wMAUEsDBBQABgAI AAAAIQDOAW+aYwIAAMgFAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGU0LnhtbKxUW2/a MBR+n7T/YPk9DbcBjRoqoDBV2igq7Q9wHYdE8222YdBp/33HTkJZ241u2gucnPv3neNzcbkTHG2Z saWSKW6ftTBikqqslOsU39/NoyFG1hGZEa4kS/GeWXw5ev/uQidSOWYRxEubkBQXzukkji0tmCD2 TGkmwZYrI4iDT7OOM0O+QV7B406r1Y8FKSWu481b4lWel5RdKboRTLoqiWGcOOjdFqW2TTb9lmza MAtpQvQvLY0AG13xzP9bfWcY85LcfjR6pZcmmBfbpUFlBoxhJIkAYnBcG2q38CnBDYT4Wfi6yUSS XW7E6IIkgA3tUgz07/0vBJGE7RyilZI+aWlx84ovLWaveMdNAejgUNSjqhC9hNNp4Kx4mTF0Lcia oSUnlBWKZ8yg9gFnFUwg2SdFv1gkFSCvCFG3ytXStCByzcZWMxpUFRt0sW1qe4p8N7pAbq+BSMuz a7H2ZQJt3hqEJsDCDCpjBeP3YLoNmEXY1GMYndMwTnf6oLI9hi2AEQVa/tivTtxuAgF+sD7Q4yLw howYb5zKS+frHZu4dSu35wz0JIGBwT7IbEkMuYXV48BqipmM7leBqeAB9ZsaIJ5ip9ewU416sREP MN9jkrr/gyQYJ6SGI/KY4q8bYhwzDWdhzf+StMDGS2pynoXn+H0wmc37551xNLlq96Pe+HweTeat aTQbDIYfOpPusD9u/cCHVYMll9CdZ9c8oxVZ4aacETiL9XusFo8kbtTzo3JhYFD532YTRlRdFxCb g0O5+Uz0zTZsB9xRoGsaVBouZ72STy6ePL/bo58AAAD//wMAUEsDBBQABgAIAAAAIQAj0KgJ1QAA AL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGU2LnhtbC5yZWxzrJDBasMw DIbvhb6D0X120kMZpU4vY9DDLqN7AGEriVliG0sb69vPUAoJFHbZSfwS+vSh4+lnntQ3FQ4pWmh1 A4qiSz7EwcLH5fXpGRQLRo9TimThSgynbrs5vtOEUpd4DJlVpUS2MIrkgzHsRpqRdcoU66RPZUap sQwmo/vEgcyuafamLBnQrZjq7C2Us9+Bulxzvfw3O/V9cPSS3NdMUR6cMDwFTxWIZSCxoPWtw7ey 11UWzGOP9j89YhLiN2ShsrJZ9NksQns3M6u3d78AAAD//wMAUEsDBBQABgAIAAAAIQDy3k82BgYA AD8dAAAhAAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1s7Fnrjho3FP5fqe8wmv6s CMyFYUALEeyGJtImWYXNA5gZAyM8nqnHEDZVpbxW+zh5kp7jCwPspoFkG7UNisR6fDm2P3/nO8fO xdNNzpw1FVVW8L7rPWm5DuVJkWZ83nff3o4bsetUkvCUsILTvntHK/fp4McfLsoeLyStXpJKUuGA FV71SN9dSFn2ms0qWdCcVE+KknJomxUiJxI+xbyZCvIOrOes6bdaUTMnGXfNeHHM+GI2yxJ6VSSr nHKpjQjKiIQdVIusrKy18hhrpaAVmFGj95Y0gB0mE5bi3+lc/76hMydLN4BTq+W5gwvSU/ukl0w4 a8L67nTuuc3BRROHQGdTwsFVeSsoxRJf/yLKSXkj8CN5tb4RYBNMug4nOSCMBlSD6aY+OXTThveG z60l0tvMRI4rAngcWCGc4x3+wiDSoxvpJLoyqWuTxesH+iaLZw/0btoJYGvbSXFXekf3t+Pb7Tyn JAWC3DCS0EXBsKwwUlvU4wDG8rpIlpXDC9g0YqH3CuhYywgAzlUuHHlXAkyLVAAz3/fdX1dEAAXN EN0PVsm3QyuFtd3A3yPkdzte3ALwEKew3QGKKsP16FJU8hda5A4W+q6giVRMIOvrSuKySc92Ucev Zy97cjMq0js8jSn8hUMHp4Pxi0K8dx32gld9t+uFIUwt1Yea3HXEbst0r0WyywI4Z86YVXIi7xhQ jPTYmnmwaYewOTg1U+tL6ewNVCFiXr0r01Mte9cCnCvQhqc3RBAcxgjqAeWNtxODB/QAlO2uoKi5 8GlGBJYRV0TSPT74aPJr+ZBK1/jmyUwI4jiMPFhf7RvWY/6PfBBfyocZS5VU/RYNW2E3GF41gpEf NcIwGjWG7bjdiLqR3wqGnau4e/U7EFk5agrHLbOcjrP5StDXK+0u4oBUTpXLS0YJ8NUQGgisxEsO PK/ZRZ3vonNJxVVYyuMzNLQMnbAspc6LnMz3iRp8nqggYW8K8GuU8+JyAW5Dh1UJInGcqlUsfZHP DZOVXygpQ+1TBSuHn9A0zwuDFsoXMDmK26hkCkNLZ61oRt6C0O9iZy1aNn5Y8TpK3wgkAeOMMTUJ 4847FJcO2MTDqQqAEVvxA83WYRKCwdLMu9MLTpdxtdFvIJoO4QmIb99NpIodMLdRULWZf0AA25Ze rzBx2lPA8PPEwlPa0UgMcAcREePKfkjUgqhYexKNDHWQRWEA/w5p1A7jCCt1lATSGaJts4Q6Bh5F I1jcNzhxpCGHRHS4ksUsM7FaB2Nsun/8GEIhQG4VCZyQ9D4vXHJwybJk6cjCoWkmHZMiS3TCCkN0 VesY+jWApTxE/dgpVQoEsx075YQmBU8dRteUHWFeScsJ5m8XmTjeumLcCdbHxUrIxdGLV95yivls 9qD1x85wIuvg4wI8fD/nbT+Gh89AqvZyXu3gCo+THFxHiBj83Ie8RwmeDRH/yYxnK+ZTvRnry+g9 /8pkuGOpolONV6t8ekCY6DEIA+kEmH6IM4qPJ3FmN0v+Hpnz9WlzZ/RsHHX9YWN05UHaPOyOG6Nx 67LxrNMBRxwFMeTV27S5whyUw+EdFwHqbPnjhz9++vjhzzoIfHGurMKyfraAon0MSZh4SUoHnjrg aikhz5UbKKVLKE3nPtbB3V9uoJQuoUSSBN5XoIcp2Bpo1zXbPoGtgZuYbgptDWTmuqZtayCZ0jWR rQH1XbCML+FOjX9cZ1aw57rClrRLqXere3flnIhrjPTbS7MDN+ZbMp3AhVldzKFJSJUMOJRc85GA mWDP+PDEzSd0wYwfXrduVlyn/Hh6h1dvZ0kFPrbhNRzbd1Lgey9KAC6uGpKEvV5qVnXBmsG7St/9 OecNJrX4UXLQQIluSKqDhqQytvUK1TTbFwGlnD7mQBoa8xpyxochKCayBDU+liT20eX75Q+CYvAJ a3y8oONFeGk4A4SoGIDaOwDFfqzeHs8AISoGoKgGyPdjINCZQSDRiIoBqLMDUCcMMKicXYwhKgag uAYI0VEPF2cXQ1QMQN0dgKJ25yzSKvVBVNSb226+iDem+r89B38BAAD//wMAUEsDBBQABgAIAAAA IQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoH dYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0jS BtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAznpC2NyPSu7H1 /nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq6ysxpomHEhwD 2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4pDzEsFUy0vZr5 eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6BoB9HzS1spRp Nvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAsvrmAb3S2u911 B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLME7Us1mL8kIs+ ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv37x8jt68fHb8 +MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz 3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidYc6mg31ORg74z wwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzLuAOMD6t4 d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphWmmRIR040zRft 0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGVkIOZ8Mu4nlTg 6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ+4GcQIhitM9V FXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p85oq8LWhlSuyeqMPLcCer b5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk0y7HS7vlMWVsoGaM3Jam YZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHMSIcSpVzCIc8MV9LWeGjY lT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4bZnUt1Jm51Y1optQ53AqV wYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYjrfeij+rGSXmsmFsBiJ0K H+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ01PZazdWmh3yctr0xnG/h MU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWDZWRDw0xlIcASzcnKv9oE s16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7QiE3FAQb361AFfQIq4ZrC VAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhWKbtR7vyqmJS/IFXKYfw/ U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCCi2XzX5BD/d/mnKVh0hpO fuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHrem/3UAShbqpJVgYM7mT8 ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9t6yInpi3WY08K4BZaSto ZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrkB1BbEXx00MQgbCCqr9jG A+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLnsnFy8SGNnFnZsbceWmho8 ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvRLN36CwAA//8DAFBLAwQK AAAAAAAAACEA6JAgMawQAACsEAAAFAAAAHBwdC9tZWRpYS9pbWFnZTEucG5niVBORw0KGgoAAAAN SUhEUgAAAVMAAACMCAIAAABONt1tAAAAAXNSR0IArs4c6QAAEGZJREFUeF7tnT1y2zoQx+V3EmXc pPAh5EmjTFrfwG48aeXJGTJWm0lj3yCtJ2oy1iFSpMlEN/HDJ4lvAiRIEOKf1YtBALu/xWIB6GF5 8fb2tsIDAiCwMAL/LUxfqAsCIEAJwPMxDkBgiQTg+Uu0OnQGAXg+xgAILJEAPH+JVofOIADPxxgA gSUS6PD848PFxcOxLjA1ylwXYUhbC4GAL4Q9//T392r1+++pFkWpnDXKXBNfyFoPgZAvYLVfjx0h KQjkIwDPz8cSLYFARQTI/71rPq87n/y7V/ruv6et/cL26R9vp0xpjTKXYoV+2fAtPGLHs0KcLyDm VzRLQ1QQyEbgInhj5/T88d3d6unfz9t1th7HbqhGmcdmgvaXSSDkC4j5yxwT0HrpBOD5Sx8B0H+Z BMKev768qg5LjTJXBxkCV0Eg5AvhfX4V6kFIEACBZAJY7ScjQwUQOAMC8PwzMCJUAIFkAvD8ZGSo AAJnQACefwZGhAogkEwAnp+MDBVA4AwIwPPPwIhQAQSSCcDzk5GhAgicAQF4/hkYESqAQDKBjpw8 zx8vLj4+n5KbLViB3FKoR2YmrHjiOTe14qsYBunXb0Gr+uR3EhjOZz6aDpIk5AtTx3yaGMx+aKo/ dTCmO8MgQGNXVpQmI5X+q7fLji1qd/t+C5K6LiPGKms0XDGibogzeGNqz09T+XD3rroEoI7odL1v /kg0Uv61Wt/+9GYz8aOitZwJUKLp9us3unn9RaJzDzc+/PjlX2uGCQzn01PTmqpN7fmbRyVzT5MV 5XGzok7ARnPzx7c3llxkf11b8l/F/seHd3eH1YrnMgrkLPIPGTUSOkCoQVYrNqNvNoh+CxIlqM8x qyka038H3VgozxtuE8oc7r6RpaD26IsnE5q/tC1hGOQ/FSbagsNiZa1ztJksXDrX2WBqz0/isHlk c8H+xRwBSa0UfPn4QqI9mcrozCYfFm7jUp3QIaWuEPbXRg70w901nVjEQ4qbEXn8phTQclKYzfmT iLL8r9GPJGYbnk5l2uJJVZ1tM/ylavcEqnxx/5UdYRl1GavWta1STZdwabTaBV6cteeTGPLhhrh+ ZXm/DTNeXa57Gfb4wEZoGz2dS6B2icRi6909P4+VkVksNFjVKTHSSYo/bNGzvfkQA+H0/JVOleRl bvh2zj8937N2ZLZHZW3AfDdUKmgIfARqg5ROwLyustJk644G5Or0R+vX2GaFS3vZfaJKM/f8iShM 1E14SWkIwWKltl4QSyDVgXev7eph86ivq9Xe1JXDRMo23VCnilvjnH79oCsYerrDJ4yViMorXmJr yzsJl+r6Uq9Xl2Bqn3KyYrTkBmXzmaw7mUhiJvvzRVmzhUunRp3S39w9n82pfaNmCojZvcs0T3vW 72VSZHOfkNZOhreVfX6c1zcOrHceOCBotXXJ6yndfdqkaidOQ5tVBl3OtJuBcGlqXxO+P2vPJ5so Ov1u368nJJKzq80nssreX8txwpbg8hhTDTyuPlldEmva3bk4LlTnQRkTWeTjS15azHbLA44VczKI bosdTWirboqKn/OJxT/fl7NHaMv+O1waFoDX1WCJHRKfsdhJKbOBerQpJ6RwabTqRV505Ns3zqE1 YwRfjyh05wKng9T3M1Vq9+YPBBFCjfiKRyuulC8xuvRZV3kIVTOC/T/5sY67+g3y8FvQ9bGFSOtp ArM61l/8WeTp+8FSZ6HnyKB1Qv6CB6UwUbh0xHEV13TIF2Yd89lUHL1YLDJxdnXq+mmZDKk4pUiU 0YaWuUelEVIZ1XSo8pUE6VUd7bvXYb/+dyk5SbkBY/v0qn7wJVwaFpAGc2tyUM8UjOotZ1e74dJJ UEV1gnz7UZjwEghUSAD59is0GkQGgVEJIPfuqHjROAjMlMDM9/kzpQaxQKB2AvD82i0I+UGgDwF4 fh9qqAMCtROA59duQcgPAn0IwPP7UEMdEKidADy/dgtCfhDoQwCe34ca6oBA7QQ6PJ/e+SqT0KE/ 2Bpl7q8taoKAn0DAFzpy79I74lMmdMhgRXavvTKZM6iNJkDAIhDyBaz2MWBAYIkE4PlLtDp0BoGV 46Kv/64zv5XsvPLZXHcuU1qjzPMkCanYrFB4PA+xQpwvIOZj9geBJRLA/fwlWh06L4MA7ucvw87Q EgTiCWC1H88Kb4LA+RAIe/768qo6VWuUuTrIELgKAiFfQE6eKkwIIUEgMwGs9jMDRXMgUAUBeH4V ZoKQIJCZADw/M1A0BwJVEIDnV2EmCAkCmQnA8zMDRXMgUAUBeH4VZoKQIJCZADw/M1A0BwJVEIDn V2EmCAkCmQl05OShHw+XX3/P3PNYzbFPmveRmWYuEo+jOmuWP8mlK6XpHrnNAhqFZVZKfTnVpFop wNRmvURWqtKydbumiVPB3M+KYw2rEdv12TeSc0CyoC8EP8Sd+C167WKw4xPx5Hp/8Ovr3ovFkV9h Z7okysz1t5MK6F2akskv3PPaaaX00+BRjwOnWi8ssyNNgk2xfSmFsG0ms7bVuVC5x4fsY2CFmx2v NMqK/pc67OvwlRQrdfkCVvt0yjx+uzsoyRioSQ53345yNj0+XO+bYjaq91+fT3Glp+evbV0+SaiV Y0LJdkt6tJ4OmU9/iEat2zCVfvxqhKbNnZ7vqdr9Hs0jf96ulVaOD+9Yu8orj5u2XPkzG/tXl6Ly 8UUlJSbU/UtjhjRBD3fvAguZ8UrTpKRvu+0r2glwTu9Jq5Ez5jfxT5ubeAAwpitfZLb+nhzCkyuI oK0KqLdhtphSai9B6Gh3wbD+2ljGrZHZTlBvbgPXSmX79ETdzxFNROC2S5i/emOx09zuUWY0ZArJ ij3LCUsqUyi98nil2prRE5O9JJXKjqphzjELjtCYyB7zN5+MgHn69YNGny9aWOiertgWpcemuLtl xxubx7e3Nm6JmNXEIhY+m3+tVuwG1OGPiJ/hUt5ZE22JVnT50FTuJS2vFJZZNCy3zSwI7z4pkZev Y6hdLnsJsb92H3sIc9+s7v2nIqJDFuMVoda3X+iKqGmYCpg8bqTiNAOz92E5aUcp7cUyVMnHeXhH uWO+3DPLmMA3M1aECMb8RquYTZ6pQJ+Y37bR7FDNNakqijYZWzOzM74YhkpSrEsjl8xCI3XDrUYV scVkYjhDa2hYODbOrT6uNIzuUOgIaXbL0aBcu3l9s2P6Sp7SmNDb8Y7PvkHOUf1OGvNJSORTN98J i73bZyXaDJ+txmqBJS8SO1R1ZzqsPxKcWxvuXp0HTv17CMu8vv3ZnEGSra1YQ/GzB/KwgMJif3jf q4tHVxvtw/Sxd+PCr9jYMw8YWHNmxKfnDkwsLWaknoloku6vQ4vG8Ur7W1OrGcW5d1/ZV/tUEr7i J+dJ3JbJKzYaI1yxo7eWMRXJbyh8TUzioO726/dk9Crf7mBrxe37NW81XMrfaW346YUdFsrKMYIF 3vHLbFTaPDKeY3yAZPNZa5kng9i9CoQ8DDh2N7bjr8ShpIS/eWTHknJXFYNKXSFYJ7HawjNvaYxs Q98xOA9tbjWK56+YlCSM2NvLaIFZtMoXeMP90u2wPL63+1x/uKHa3PPjfH4ivr35ID0/WKr2K3tJ nwpd0odlNj+rxLff4pErAR645WpfP6D3AbPOX3jL7TEImwnbNQDzcPtxOD6fQ5XVA18v9p0kmdW8 z3il0SO8e0hq51wm58H95N/nK+OJSGfs8dxrXd/PvdG7PEWLrl2xrbBneWHt7BXW8b/nW43Hn6KH WHXI7C62cAZ/UXafSEe0HLFbdx9bO9q2aLmkCmygvP8LCTPmwFLreCjtbD/oCxGcu7f6E+/zuYOw FX+Plf7gqSxbA+rSWKyWedvEvvrCIFSqpUKjrucIrflSB0qZSVQ3hg4dlGlLKLdUdL2gD1mrZe1g g7mX2THbL2k/NTCwptSkpkUrhZWjZ332DgBJqxuWKkVmdV3WwXnYSEe+/WH8UBsE5ksA+fbnaxtI BgJlCCD3bhnu6BUEyhIY52y/rE7oHQRAoIsAPL+LEMpB4BwJwPPP0arQCQS6CMDzuwihHATOkQA8 /xytCp1AoIsAPL+LEMpB4BwJzDMPX+9cesREQ+qeo4Wh03IJhHwhf8x3ZlmUdw/chU0aRlnM78ri mRmBNj1mm+fK9beZiQ1xXATye34OzsHMZDk6QBvDCDQ3F4c1g9rlCOT3fHkXXb8nJO5GkELr/pBy tUTW/X5Tjgh69hKgt3WktaTvr2+/0/v55NqOms6syV+uXDSVCzqSLaNdKJipM7RF4VTJ2BZp8vye H41x0kx70VLhxQgC292OZixosxO3dajrsiw/4qFpfwwPfhG5eekbpLgpbfIXKHVTvgMQITheaQgU 8nyStYNnwCEPyxMRlxYChpsJgfefebJMO2TzvJ40v1+b9oO/Jy/v7vcrWcwz4/C82iLjCblM3Dzk liq2FWNZvJDnj6UO2p2KAM+VZfg+z1Ompi9wpAFrMnWJLMZcYpE0iIaE5uEZAo2vBEyl4Ln3U8jz i2TaO3dbTqyf9P37H03HLJMenioIFPL8ZpWfliamCqTLEZInhTwcGncXH1uQOX4JCfPbBV44IjGe I/8aNoLjjKjsefiGZNoL1u1OO8beSM/DF9kwXlMTIqtZtcnIbDLQ+fPeKyXWNxfbxP/2KE/9mBzs 1BAokodvnHkKrc6MgPhRr5VK/m4r/2InMfdqQH/TtSaO3Sti/ig2Rx6+UbCiURCYAQHk4ZuBESAC CMyKAPLwzcocEAYEJiJQ8Gx/Ig3RDQiAgE0Ano9RAQJLJADPX6LVoTMIwPMxBkBgiQTg+Uu0OnQG AXg+xgAILJHADPPwKckZ+tzORh6+JY5j6OwiUE8ePpasRcnrQO5s9nF+DINxCCAP3zhci7Q6r9X+ 8RvN1qHd/nBnfinCCp02BJAwo/rBkN/zh+Thozi3T99v15wrvwX6+++pesznoQDy8J2HHZkW+T0/ Go4jDx+dNdREjixh19WlmAiiW8aLIxNAHr6RAU/QfCHP78zD12z4ldxNE+BAF3EEkIcvjtOM3yrk +WEi7HIhTfRCLncjac88Rw/y8M3TLtFSFfL8QB4+8qMec/uElA7R2uLFjASQhy8jzOmbKuT5VFGW bVsP6XKNTycGBPvpR0Nij8jDlwhsVq/PKA+f8rEdFZEjKWNIaOThGy8RnWIh5OEbD3O2livPw4df 9WYVKnRhkIdvxsYJioY8fLVaDnKDQBcB5OHrIoRyEFgaAeThW5rFoS8IUAIFz/ZhABAAgWIE4PnF 0KNjEChIAJ5fED66BoFiBOD5xdCjYxAoSACeXxA+ugaBYgTg+cXQo2MQKEgAnl8QProGgWIEOjyf ZsN8OBaTrlfHNcrcS1FUAoEOAgFf6Mi9+/d3ddmwThXKjBEMAmMQCPkCVvtjEEebIDB3AvD8uVsI 8oHAKAQcd4Ffd76e+KVs5z36JlV2mdIaZZ4nSUjFRn/h8TzECnG+gJg/ynyKRkFg5gRwP3/mBoJ4 INCbAO7n90aHiiBwpgSw2j9Tw0ItEAgSCHv++vKqOn41ylwdZAhcBYGQLyAnTxUmhJAgkJkAVvuZ gaI5EKiCADy/CjNBSBDITOB/Xf0zjywebAgAAAAASUVORK5CYIJQSwMECgAAAAAAAAAhANgB8Z9J HgAASR4AABQAAABwcHQvbWVkaWEvaW1hZ2UyLnBuZ4lQTkcNChoKAAAADUlIRFIAAAEzAAABVAgC AAAAx8tM6wAAAAFzUkdCAK7OHOkAAB4DSURBVHhe7Z09cts6F4blbyXypEmRRciTRp603oHVZNLK c9eQsVrPbewduPVYjcdaRAo3GWsn9wPAP5AESBAkKFB8WNkifs55Dl78UCJw8d9//y24IACByAj8 LzJ7MAcCEJAEUCbtAAIxEkCZMUYFmyCAMmkDEIiRAMqMMSrYBAGzMg93Fxd3B+hAAALhCDSrzKjM 498/i8Wfv8dwRlEyBOZOoEVlzGbn3kDwP04CKDPOuGDV7AmI3wCl1/vWBmP7LpN8Pq7rCdaPn0l2 7go40NBbCDQMNNpUlsuRMXP2fTMAoiRwYfrd7PHp+nKzePx8vV1GaTRGQWD6BFpUxpg5/RDjwTkS QJnnGFV8mj4BozKXX75N3zM8gEDUBFpUZlxnRu0QxkFgDgSYzc4hyvg4PQIoc3oxw+I5EECZc4gy Pk6PAMqcXsyweA4EUOYcooyP0yOAMqcXMyyeAwGUOYco4+P0CKDM6cUMi+dAwLynwdP1xcX103EO AE7io/gx80V22TjLvShC7Pkiy22Kbah6TwI65kpVI7BHgjHTFrykhbYKKObYW23bf9Drxh44lOkY of3z23CteXn7an3bPLNndS+T3K8c7Rss2anqHcyBMykIZdoCmbTQ4hX0/ebhkKTN56LXTwdtWppu Nth816XZtM919fH87iDTZ7MiPW9tNqyyXe2EDburfDJQ7JHYtd7Ml8waUVJRBFsvuoS6IQ3KbAR4 eBHtWOyaofZS2b2k0syy7DdXm32eX7T20qqh+a533GTjV+pKr93VZWHE4UEzSCYQRg2kEam/cr21 VfDLXWHKcBV7k5p4xmIfoOIv1Q7zXVxMKebxWbK3kQKR/JlsiKRPRAtKyeia/J9timS+m8Nr5my8 m5asB6ehFGVTJZDqs8KReiSN5aVzhyJf+YPq7SquebSXbl62qIwx096zHt+e5Yi431xeXCSDwe53 +YH19r3YkGV1L5unvhxtvuvXox8/hB16wYuFWrQWdugzXX2M86svzaX2RhUSL5a9q3vVsvRdibfv +W3e8O2FW2ZGmVaEqTBL9xufAy2/GjYXzLM33+0dSFVAdcY5TKmiFNUhcI1JAGXaaKslW2kmKAeJ 4jmQzLe7KlaWh2SR9e3LMiux+a5flJW+d1eltaN67CI/UatifaJq3Gq0VHGet9mc1Q85H9hcFvXW 3fVziFw2AqwzDQRKLVpbZ6YQs0dCdaapLCyKSO/athxNbjfftd6Xme1C1HoYQ/mqYp96axYn9WhF NS1ouy3Lzi4168xwvfL68V3bHVs2Qv3rx+a73laJb3OqCpR6kDWLFaeur+27SarpAjGrv2q11a5q vc4ZvT2deUbGTK/O2OOxqlc9ZDpbAoyZg3e9cm2m1pTqqW31W73mu4MbQ4FnSsC8q2X5OfyZuo5b EDglgcq3XVVT2NXylMGhbgjYCPCtCW0DAjESQJkxRgWbIIAyaQMQiJEAyowxKtgEAZRJG4BAjARQ ZoxRwSYImJUp31kY6IVbEEMAAkYCzSoz750n38bT37wDLQQgMDAB9c6rXWXMZgfmTXEQGIQAyhwE I4VAYGgCxU/5bS/oZS/jGt/+y1/8466IDDT05gkNA402leV6ZMwcuqujPAgMQcD4i3bxItPlZvH4 WWz7NERVlAEBCBQEWlTGmEljgUCMBFBmjFHBJgiY35z+8g0yEIBAUAIte/Ly5nRQ+hQOAU8CzGY9 wZENAkEJoMygeCkcAp4EUKYnOLJBICgBlBkUL4VDwJMAyvQERzYIBCWAMoPipXAIeBJAmZ7gyAaB oARQZlC8IxQu34wvnUI/Qp1UEZ6AeU8DeSAj0Q5Pv38Nx6ff4sxM7dDO/kVSwjgE1NGldpUxZgYI g34guzySqLi0zZW0RCI8xZ4wKmDVyxbA9PjdXyvhRZExr0Ur6/q6Xmyp1E71BoBGkWUCKPMULaJy ars4U+xKjHwNOy+JFCZxqkOm1zffl35OyLPMmjdis9TrVx25uhBAmV1odUmrTlvWzkgsXmY/3Ekd 6ifN6y+6yyOi1P/acc3y//3z27FcfzKT3f5zmwhTZEyrU0No8tG/8uhdubnA62t2V54KrS5VS36y vHu9XSiQ1pcAyvQl550vGehK76WvfkkBWVeLape12qXPZL2MSU+f3r0cLNnN9XrVRaauBFBmV2LD pK+oUJ2lqB8lr0azbLWpjtGtTlp7zmSTMfX7jegRKrPolnqH8Z9S2gigzDZCHvdX92KuWNHZwvih Y+FqOppOWpMslZmsYzldk9Xr7VoC6X0JoExfcv3yOeyzra0zaxsy9Z7JptYfP8RoXBm/m+rt5zS5 OxBAmR1gDZN09UM+z9lc6k9FW77bqlZsm8mq1+T3m59Px2xk/SknwpYFrKhUPopaf10O4xilDEqg 2G+2+Et7omi6zWcOBOr7ilaetdajmCSobdybb9ua1Zqk0IrTzDFs+5vkN+4HLIqxbwpbq9fBa5K4 E2hRGWPmoP2cY2FyzVmWrpRBdWVqKaxxJpt/95FmFvpt2Ju0+a6jMyQLQ4Ax072XiyKlUjTjWRSx 6GUEY2aYHu1UparvGPNfF5zKCuoNToC984IjpgIIeBBgnekBjSwQCE4AZQZHTAUQ8CCAMj2gkQUC wQmgzOCIqQACHgRQpgc0skAgOAGUGRwxFUDAgwDK9IBGFggEJ2BWZrErTXADqAACMyXQrDLz3nny dyYO7ynNlChuQ2AAAurXXHaVMZsdgDFFQGBwAihzcKQUCIEhCBQ/l6+/UZiVb3lxUN62v97H3Wp4 YKUTmSmNNpXlemTMHKJ7owwIDE3A+K6J2IbicrMo7bs4dL2UB4GZE2hRGWPmzNsH7kdKAGVGGhjM mjkBozLVFmxcEIBAQAItKmNPg4DsKRoC3gSYzXqjIyMEAhJAmQHhUjQEvAmgTG90ZIRAQAIoMyBc ioaANwGU6Y2OjBAISABlBoRL0RDwJoAyvdGREQIBCaDMgHApGgLeBMx7GjxdX1xcZ4cwepdNRghA wEqg5cxUxsyJtR25eUz9Sk/JVcGuXnSxEwtxYi7KnGTYuhgtjrdGnF2AxZEWZcYRB2cr5KG4+dHU +b4A6aG4+bm2lfOt989vR+caSBgFAZQZRRjCGaF2aOOaHgGUOb2YOVi8u8pWm5ebvdit6eb70iEX SSIigDIjCkYQU+SM9/UWYQaBG7BQlBkQ7umK1taZqPJ0YehTM8rsQ4+8EAhFAGWGIhuo3Oz7TLV+ FF+IJOtJ7fvMq52oOVtn8nVJoDCELxZlhmdMDRDoTgBldmd20hzZ95nF3vryL+37zNINFpknDVaf ylFmH3rkhUAoAuydF4os5UKgDwHGzD70yAuBUARQZiiylAuBPgRQZh965IVAKAIoMxRZyoVAHwIo sw898kIgFAGUGYos5UKgDwGU2YceeSEQioBZmfLHmelPMUNVTLkQmDmBZpWZ986T78H/+XucOTnc h0BAAmq3CbvKmM0GZE/REPAmgDK90ZERAiEJFK8mvG9t9SRvyH8+rusJ8t3buCvgQENvIdAw0GhT Wa5HxsyQ3R5lQ8CXgPFdE7HV9+Vm8fjJ232+WMkHgTYCLSpjzGwDyH0InIIAyjwFdeqEQBsBozKX X7615eM+BCDQi0CLytjToBddMkMgEAFms4HAUiwEehFAmb3wkRkCgQigzEBgKRYCvQigzF74yAyB QARQZiCwFAuBXgRQZi98ZIZAIAIoMxBYioVALwIosxc+MkMgEAHzngZP1xcXsR3wlhxP57MHisw5 vDfiB8nZiesBSm8OdxiPsjqzgwAT94Yn16cpK+qjmBS8ppYKTj1mllpBQrz0kY8STZHff8iiI7nK TT/Td0dXA3kk2os6gTO/AtXjFYrj0095bOi3L8tKMzG3nEbO5ptFV6R+PLff/FRt8gTXqZXp7nJy PF16HJ17tmApl7ev1vfJg1UavuDjh2j62mHyMSE/PEhdbt/HaQSre/mW837zcAhP3VRD+RzG5D+1 P0H+RropxaCfqde8S9UlGyRkH+nbJdSsKt4RV80p+zdtW8Y3yEsJtVaYJs6bZXWbhlJ7zQj0YWXI q9lfVK9XbPcos6iUomRzM6vmXSlqW1rUaegVb99lcVq07FY5t6WkiBqMhpaTFm2LUe3z6gf1Gp2N bU/Y0nJiGDNXPyp90/HtWfaN/9yKSUuXS0xQspnY7nfvWUjSQ2uXOGK944yzi/GVtC936rx3dblX LNcupcmoyGpelXVl1UKjWvHuqjB/4W5VE7DDi5xlb3+sikRDtRy15DPEVpW/2L2cZNSMYMzMthjK ekNLT9XQx1QGg4pP6q5pwKvdsKbMRuP6RGLgMbMY9itDd33wq3tUnmooCvX5SDOrJINxdlCiWi43 HW51OgUXJ6sch5jaTC4p3LPllGcJJqcNtrdb6phiAmPmYrG8/Uc0iHScU33j+vGX1je6jT0S7bBL EP0pQfm5iJtF/qm0xZTz27LJVEOsjC7zh8bJALp/fjtWTPFhZaeRLk713WnUMlx+0MWqJl6qjuTh j3YN03Ks9SbsT/IQLIbZrOSSzEtECzo+/RaNqftMtjLP8ddEllO2w3HV2N9m5xJKc0KXXKensfwq R8f6zsl9W44c6I1LbIlF7da8WH8tdwcuwHqniUWZi9UvMS8R3b1annRuOB04VNcUeazL3xeokVuf 4Fij16HuMEkzj5bfb/SpnTap6r3VWgsNpZrdVWmlNrRV1uFrgJajBnjTdMs8UIcJY7XUKNaZiRHZ Cqi8mLNt0Jmoxni3sho0pGnYQVcCErftQlSlN1vVstIwZy4/Ms4eTWtpi37C6pHFrARIC6ump74t NKw8GoLU/em//UmpueVYgmR7bG9YZ8792WzWWSRPwrxmso292Oq+1LCKJZboKrXmKJqv9l/5ntBq TGOm1SP5pW9NYdv33mNmKw1RcRWQ7A6ScWggq+xPSgO1HMPT4HGGS1VLRGOm4zMtks2WQCr+9kfH QxBKerhwX+tP4tnsiD0RVU2YwPL2X/ktySjH1KmHP+vHf7t+qT4UXvbOG4ok5UBgSALRPJsd0inK gsDkCaDMyYcQB86SAMo8y7Di1OQJoMzJhxAHzpIAyjzLsOLU5AmgzMmHEAfOkgDKPMuw4tTkCZiV Kd8sGO8l4clDxAEIeBBoVpl57zz584dRfmjh4Q9ZIHAWBNSPjOwqYzZ7FlHGibMjgDLPLqQ4dB4E il/l2145zF4gbt5bjbuiPeQvJkADGpX+IW0bbSrL9ciYeR4dLF6cGwHjuyZio4jLzeLxs/cLt+dG C38gMBiBFpUxZg5GmoIgMCABlDkgTIqCwGAEjMp03uF0MDMoCAJzI9CiMvY0mFuDwN9pEGA2O404 YeXcCKDMuUUcf6dBAGVOI05YOTcCKHNuEcffaRBAmdOIE1bOjQDKnFvE8XcaBFDmNOKElXMjgDLn FnH8nQYB854G8tj666djowvqfMS2RN0gWIocoCanIpwSdfBIO6O5wmmAmgYoooMrp086gL8DFOHI wammlkS+Y+bx6ac8grY4nFs/Krw4jDzdTMh8UyRLWmx2W51qW7/Uz5j2m58tXYUjNVuyQT1aSOza idXiyF5dnON41BPImWUfNr7NcIaIr6cyDw/qaOh30zm9/hFdr+WZyfVrdS/fN91vHg7+ZbflHNaj pLT8Reqa+WN41ObxvO4PG982dgPE10+ZhiM/5eml8iqfCpgqNzv3VD+MUHvtP8v7743NY/uhpm2M HO8P7JGsVTvhTR1YXt6NKbhHjo7PJNmQ8c2meGJCqGak6qpuNdk7vl7K7HUWr3Km85aZvR1tboFD eyT7muK988OdmqcXU39pTGCPZqI4RzeHjm9S7UsSV3XtriqNum98fZSptuNbrL8uHbEUycRy6yJz RhwwrrfetrKWX+VMN9BWmwE9yhectal/UI/acM7r/rDxFd2u2s1nt1u8p9v2qAng7uWgY+0ZXy9l fsiOojwCBI908jbb/uMYoqZjII/UhhISlji/vLYkD+pRCErTLTNMfLW+1vSuZc/4+ijTvzOQ60zj tnLtQffv9trLXgTxSCxHlCyFKuuyFEYF9cjB6RklCRLfNn494+ulzF7Dl5rFdn+mG6bbS+n2694M HmVzWNkV2XwN6lFbs5nX/cHj64Kvb3yL/WaLv8rPVw0pkk0z5WCQX+Z9NNMktZulrMmsvXYZii9n M5lu+WxcjyzTApPT4Tyy00nN0x+Ua4lPdbclmq0RbM4/ZIvVmmvCUPugiKehxrKJLR75jJkneK7Y 69maSwfX90maSx2lx1fBPXKxaD5pxohviWb/+HqNmenXlpVhs8MY1i1p0v1Y+ninohx63HSs8B7E nOzIEo3iUSeLYk/sEMFmF6KLb5Axc7FY3v5b+/I8VA+sltLa9/Zh6jk/j8JwmmqpU4sve+dNtaVh 93kT8FtnnjcTvIPA6QmgzNPHAAsgUCeAMmkVEIiRAMqMMSrYBAGUSRuAQIwEUGaMUcEmCKBM2gAE YiRgVqZ8a7vzy80xupfbhEdRh8fBuLlF0Lx3nvzRTaCXlB1iECCJ+hkRHgUgO1aRs4sgs9mxmhb1 QKALAZTZhRZpITAagbY3LKUhyfsXxrcO8xdAYrxrfu/znD2K/Y2RrvbNOIKMmaP1gVQEgS4EPN/P 7Nr5nTh977f7Tmx/vfrz88jh9co+r+hOLYKMmV26MdJCYCwCKHMs0tQDgS4EjMo07Z7ZpdD40uJR fDHpZtHsIsieBt0aCKkhMA4BZrPjcKYWCHQjgDK78SI1BMYhgDLH4UwtEOhGAGV240VqCIxDAGWO w5laINCNAMrsxovUEBiHAMochzO1QKAbAZTZjRepITAOgZGVKc+VvLh+Oo7j3Bi1nJ9HY1CLqY5I IziyMmOKCLZAIGICKDPi4GDajAmgzBkHH9cjJoAyIw4Ops2YAMqccfBxPWICKDPi4GDajAmgzBkH H9cjJoAyIw4Ops2YAMqccfBxPWICKDPi4GDajAmgzBkHH9cjJoAyIw4Ops2YAHvnzTj4uB4xAcbM iIODaTMmgDJnHHxcj5gAyow4OJg2YwIoc8bBx/WICaDMiIODaTMmgDJnHHxcj5gAyuwXnMPdhbju Dj6l9MnrUx95pkTATZlqE6PsUhtslT6RDTNpZtVL3ClS6u03/1SUVsla2sBLu5d8XvsgBG0Hfxur NcMQcM5qc7IQ5Icvs9xg5H+lRllp17L+fi12KA/clDlMbbuXfGg5vj3vbYXun9+kBKdxre7lKeP3 Kx9r++T1qW9+eaQOr3a53/vNpfzvz19j+xJ3q5Ofk7ZY1+Pr37fCwe17Obnhw8/H9WKxfvzUE6pk 6/U6z68+kJdWYP5ZrR5VZFZomqxqiasbzula/U2tUm5U/JWV1DjoH7TkdTaShE0E0qaiBSf5JPmg GqBSw+rZYoeIi/OYufwq5KF6m2J5dPz7R/j5denUGX+7uVnvficz0pfd+vExU2eSW3ymmClgWl8l bi1vXyUp0addX1/LTk8k8xulnAxNEvX2N6tLzY38FqIdzCVpjUDWol5v8wa6+iVb17cvpha7uq82 Pf8WO0Q0nJWZV6YcrorHxZQv32/WaqYqhXnz/Yue5/j0Wyru5vtyKVLVS0+x7fdiDrx911i7VNwv jc1f0V/kY6OtBjlButwk83aVPrXcJW8/q8mdEKioUIG39epJ09Pmun1abO8AOCtz+eWbGLY+jrKh bt/FGCY8OH6IRmfugUyGLW//2QppPilhlrqtdNkpG3LaktPRtShG1aUuyzKhN4pyAQP4O7BFFDc6 gV4ttqe1zspMpneLv2ICK+av4p/988NLh8mssnP1Y7vfbGzCLLlSeg4kZoTJLFZOgYV+x5gcDuGv XNHoa8qewSJ7ZwKdunHDSOPbYjsbWsvQQZly0NxtNvtszrn/I4TZYchMpZlMWnVDDg9iwld6iCJb 837zcEhSHe7kjFAkeL29TRcDV+FXbmrQ7OuvsL5xAtU/gJRgIyBEVevGG84wyXr/ymMTVUrXFjtI UNwfI5UfdWVDQfaQVH+0Whi2fS8PGUlqc9r0oZl9jJHiLWUN+4C20V+bCxYHS5Y253UPCCnbCNga pXUiU5/kdG2xhsf0bVaa77uPmel0Nhsk1ZDi/mR2kF5k3EKS6ex8/B2X7ii1yW+My+qUwrE9ARIi HPXZYjMC9jQYpYlQCQQ6EugwZnYsmeQQgIA/AZTpz46cEAhHAGWGY0vJEPAngDL92ZETAuEIoMxw bCkZAv4EUKY/O3JCIBwBlBmOLSVDwJ8AyvRnR04IhCMwsjIbfrcYzsegJZ+fR0FxRVh4pBEcWZkR BgaTIBAjAZQZY1SwCQIokzYAgRgJoMwYo4JNEECZtAEIxEgAZcYYFWyCAMqkDUAgRgIoM8aoYBME UCZtAAIxEkCZMUYFmyCAMmkDEIiRAMqMMSrYBAH2zqMNQCBGAoyZMUYFmyCAMmkDEIiRAMqMMSrY BAGUSRuAQIwEUGaMUcEmCKBM2gAEYiSAMmOMCjZBwKzMw91F+KNjgQ+BWRNoVplRmUdx5Pui0zna syaM8xDwINCiMmazHkzJAoHgBFBmcMRUAAEfAsUh8eZD7WWZyVn1n4/qdPTylR9Lz10BBhp664CG gUabynI9Mmb6dGfkgUBoAsZ3TcR+8pebxePn6+0ydP2UD4GZEmhRGWPmTNsFbkdOAGVGHiDMmykB ozKXX77NFAduQ2AsAi0qY0+DsQJBPRDoQoDZbBdapIXAWARQ5likqQcCXQigzC60SAuBsQigzLFI Uw8EuhBAmV1okRYCYxFAmWORph4IdCGAMrvQIi0ExiKAMsciTT0Q6ELAvKfB0/XFxfXTsUtBpD0L AnIHjFEjLytU193hLAC6OyF+0d7Ees5jZt4okqYxaoN0D+D4Kfcf9MnjU6/WOGdlVljsn99okaO3 yNX9f//Z3yYe3Zx4KpyzMmWj0JvFfvNQm1Hp4+rdQU5A9KG18W5pSK7N1SoDdmXIbr5raT5ZJlGX mikZJ4l2q9Sdq50ofHeVZk7nmFqezI+igmIaWqahGVncUNk1O7VEWqXVCYwXjXg05mfJnJWpiB1e RFsU+2Ko3VJ2L7o0ZetTLTW9dleXm33+X+Pd6k3Z2AtJ1+6WYtd81yXML3eFoaLivFdotsqlZGsa KZ4yK8vKUSTM0u1+OzzK6E+jl18nzFzsA1T8pVppvouLKcW5fJbsXqRcTf5MtjzStj3SMWhc0m2P zHe1UrPS1IQtS136J9thKS+q+W4z+XRemHuhO9VmlSpZFVBAKMEoMFX+yqajRb6qHaW5Sa34rFJT u+tDI+5W2qKyxayVadhWrCyQehtNeVlasK5pQ3ebFV6tt1xN893G5lYzq/jAuIWaslHvXmx+Zc2o 6JGq3VSlJ6+1u0SsRqCJ+taiZzTc7kFj0sqc9Wz2+PZczE5TIY3yHGh5+1qMUKJiucYqJrvNd08z v1Kv+e4/3gSx9Xa7FpTePgS7b1+Wwp6j/NPp2v5Y2dLt96KQ3VXtCXmMNJx87Zlozso8PIhlY6mr l/1z9hxo+VUuPK9Kj27Ucw/1SdPd5feb8sQ477uTLc+KUpJnUMlMOusSmu/6h7vNKlPJhS2L1Q8x sP15FsK8+fXrRkjzWezjnwpN3dtvLgtWh2SlmwjX7RLDpRw7RTG6OEPRcLPppKlmOpstzZG0dWYa C/WJ5WF+OuNqvGu5mXQDlnllWm7z3aYJmlZpUpH2gSq80aqkZEOSsl06K61XMxWdTU2N1ZbW3Pk8 N0vavFWtZVIc9+S1Zl3LOnPOY2ZbjyhGtKpMZIu5TyZkjXeN39Jt363bhGrlGqxqvtvmRnHfwarV fcllKa7U33TMVcOg/ndSfJWGltHVvr+VR+G2fEPRcLXrROnYb/ZE4Kl27gTYb3buLQD/J0mAvfMm GTaMPnsCrDPPPsQ4OEkCKHOSYcPosyeAMs8+xDg4SQIoc5Jhw+izJ4Ayzz7EODhJAihzkmHD6LMn gDLPPsQ4OEkCZmXK92Bnt2PSJOOH0dMl0Kwy8955f8V7BH/+HqfrNJZDIHYCx2aVMZuNPYDYN08C KHOeccfr6AkUr43Z9xZMXrQzvjjY/CIdd/X4QwMaDTt4VnZaYcyMvu/EwFkS4P3MWYYdp09PgPcz Tx8DLIBAZwLMZjsjIwMERiBgVKbawpALAhAISKBFZexpEJA9RUPAmwCzWW90ZIRAQAIoMyBcioaA NwGU6Y2OjBAISOD/UQ/BO5DSmy0AAAAASUVORK5CYIJQSwMEFAAGAAgAAAAhAPnPCTmDBgAAXBsA ABQAAABwcHQvdGhlbWUvdGhlbWUyLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixm61NG8Ruhx5p iZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8mW4etA/oV9khKshjLSNIG27DFh0Qif3z/3+Mj df3Go5ihQyIk5Unbq1+teYgkPg9oEra9e8P+lQ0PSYWTADOekLY3I9K7sfX+e9fxpopITBCsT+Qm bnuRUunmyor0YRjLqzwlCcyNuYixglcRrgQCHwHdmK2s1mrrKzGmiYcSHAPZu+Mx9QkaapLeVk68 x+A1UVIP+EwMNGnirDDYYFLXCDmTXSbQIWZtD/gE/GhIHikPMSwVTLS9mvl5K1vXV/BmtoipJWtL 6/rml63LFgSTVcNThKOCab3faF3bKegbAFOLuF6v1+3VC3oGgH0fNLWylGk2+hv1Tk6zBLKPi7S7 tWat4eJL9NcWZG51Op1mK5PFEjUg+9hYwG/U1hvbqw7egCy+uYBvdLa73XUHb0AWv76A719rrTdc vAFFjCaTBbR2aL+fUS8gY852K+EbAN+oZfA5CqKhiC7NYswTtSzWYvyQiz4ANJBhRROkZikZYx+i uIsZHQmqGeBNgkszdsiXC0OaF5K+oKlqex+mGDJiTu/Ny+/fvHyO3rx8dvz4xfHjn46fPDl+/KOl 5SzcxUlYXvj628/+/Ppj9Mfzb14//aIaL8v4X3/45JefP68GQgbNJXr15bPfXjx79dWnv3/3tAK+ LfCoDB/SmEh0hxyhAx6DbsYwruRkJM63YhhhWl6xnYQSJ1hzqaDfU5GDvjPDDFfgOsS14H0BFaQK eHP60BF4EImpylzuaHYrih3gHuesw0WlFW5pXiUzD6dJWM1cTMu4A4wPq3h3ceL4tzdNoXTSKpLd iDhi7jOcKByShCik5/iEkAp7PaDUsese9QWXfKzQA4o6mFaaZEhHTjTNF+3SGPwyqxIQ/O3YZu8+ 6nBWpfUOOXSRkBWYVQg/JMwx4008VTiuIjnEMSsb/DZWUZWQg5nwy7ieVODpkDCOegGRsmrNXQH6 lpx+C6pHtdv32Cx2kULRSRXN25jzMnKHT7oRjtMq7IAmURn7gZxAiGK0z1UVfI+7GaLfwQ84Weru +5Q47j69GtyjoSPSPED0zFRoX0K1dopwTJPLinzmirwtaGVK7J6ow8twJ6tvl4uA/vuL7w6eJvsE 4n1xB7qsvZe11/vP195l+XzWijsvslB/dZ9jG2TTLsdLu+UxZWygZozclqZhlrBhBH0Y1OvMSZEU p6c0gseswDu4UGCzBgmuPqIqGkQ4hWa77mkiocxIhxKlXMIhzwxX0tZ4aNiVPSI29eHB1gOJ1R4P 7PCaHs7PCAUZs+2E5iCaM1rTBM7KbO1aRhTUfhtmdS3UmbnVjWim1DncCpXBh4uqwWBhTehEEPQv YOV1OKtr1nBIwYwE2u52E87dYrxwkS6SEQ5I5iOt96KP6sZJeayYWwGInQof6QPfKVYrcWtpsu/A 7SxOKrNrLGGXe+9dvJRH8NxLOm9PpCNLysnJEnTU9lrN1aaHfJy2vTGcb+ExTsHrUjd/mIVwSeQr YcP+1GQ2WT73ZitXzE2COlxZWLsvKOzUgVRItYNlZEPDTGUhwBLNycq/2gSzXpQCNtLfQoq1DQiG f0wKsKPrWjIeE1+VnV0a0bazr1kp5VNFxCAKjtCITcUBBvfrUAV9AirhmsJUBP0Cd2ra2mbKLc5Z 0pVvsgzOjmOWRjgrtzpF80y2cJPHhQzmrSQe6FYpu1Hu/KqYlL8gVcph/D9TRe8ncGWwFmgP+HCl KzDS+dr2uFARhyqURtTvC2gcTO2AaIF7WZiGoIKLZfNfkEP93+acpWHSGk5+6oCGSFDYj1QkCNmH smSi7xRi9WzvsiRZRshEVElcmVqxR+SQsKGuget6b/dQBKFuqklWBgzuZPy571kGjULd5JTzzakh xd5rc+Dv7nxsMoNSbh02DU1u/0LEil3VrjfL8723rIiemLdZjTwrgFlpK2hlaf+WIpxzq7UVa0Hj 1WYuHHhxUWMYLBqiFC5+kP4D+x8VPrNfKfSGOuQHUFsRfHTQxCBsIKqv2MYD6QJpB0fQONlBG0ya lDVt1jppq+Wb9QV3ugXfE8bWkp3F3+c0dtGcueycXLxIY2cWdmxtx5aaGjx7MkVhaJwfZIxjzOet 8hcoPnoIjt6Bu/4pU9IEE3xfEhhaz4HJA0h+y9Es3foLAAD//wMAUEsDBBQABgAIAAAAIQC0z1gZ uwAAACQBAAAsAAAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHOE j8EKwjAQRO+C/xD2btL2ICJNehGhV6kfENJtGmyTkESxf2+gFwuCl4WZZd/M1s17nsgLQzTOcihp AQStcr2xmsO9ux5OQGKStpeTs8hhwQiN2O/qG04y5aM4Gh9JptjIYUzJnxmLasRZRuo82rwZXJhl yjJo5qV6SI2sKoojC98MEBsmaXsOoe1LIN3ic/J/thsGo/Di1HNGm35EsJR7YQbKoDFxoHR11lnR 3BWYqNnmN/EBAAD//wMAUEsDBAoAAAAAAAAAIQANfWJvWzsAAFs7AAAUAAAAcHB0L21lZGlhL2lt YWdlMy5wbmeJUE5HDQoaCgAAAA1JSERSAAACJgAAAbkIAgAAADV0aBoAAAABc1JHQgCuzhzpAAA7 FUlEQVR4Xu2dO3LbPBdA5X8l8rhJ4UXIk0aZtN6B1WTSypM1ZKw28zX2DtxmosZjLyJFmky0E/94 kBSfIEiCJEAcNomF173nArgACAIX7+/vKx4IQAACEIDA+AT+N34RlAABCEAAAhCQBHA51AMIQAAC EJiIAC5nItAUAwHfCZyePl2o59PTySzr272Mdv/WX6Omsobn3F+mppRSplYkDYmHpHWviQ854nJ8 sAIyLJGA7j1zz7mLzjrcQred74ZLiZt6PB976CXacnX80+KFDVoPSbs8mLic5dkUjQIicPiZTRVO L8/HJsmPzy+1Xd76w3a12n5YO9F4fffr/d+jyLD12TyIbUfvD5vWiI0RmsoannN/mUg5BQFczhSU KSNGArr3fN0L3fevxS5adLjq9+12m/mctx877XH2r7/u1rnE6sfj7kfmm3Iw11fXDWgrc6xOS0Pn aVhp/SwfUMwxLVDM5eoncVLQnFRleYblXBQ4K8Zu7a+ZlQq5OQjJDzfZfLVutqoDC8W1pC3SGLZM GVLzwuWEZC1kXRiB69vb7eG7enPy9vOwfXyUfuj8iN+EW3r8p6YeuflQicL11br4i+x/VT/Z8znu bhL3JzMQnW0nd/Xz/jJLLdJm3XBJqmIhVpI25Sw693ORUuAOyg9hlY0SUunz6rZoVCm3K2YrYh5G wuV4aBREiobA1cfbrVo0kx7n9uNVXvHT03fpcW4/rtciVoPPEStr1XW10x8xXxKuSk6t5GO3WlaA fk4tp2PH3ZdkR4FcEKvPUczL1MztcFipOV0aK3GVp6cv0hEV880XOSBnySmZSeZkk1PL9rU/Mys1 2cxNVJVaWaZ6Kpo9Kt7vv3IAIR9TWk0jZyJVyhnzghsALmfBxkU1/wioBaDcpGF9920vfM6T8jiF yUryaue4u7xIxvDJfKiglOioxTJcSc/NVzEtUgn1c/nn2/t7NVozHbW2l/Wcyuk0vEyq5rF/zbrk 3LKf1qaabxcLmXM+l5qsWtplPZBVfk3Ofm6Vt21qJJXaHrOddh7GwuV4aBREionA5vP+uNs1eZwC CesOKZkx6PG5eOSLiE6LY0W3JvcojPCovQ+zP/1ZSXdj72ZmV9QTAXA5nhgCMaIlIHyOXj/LE1Cv CQoLL3J1rGETQQmdmkmpVyjpyo9Kaz1PES5Kv19ST7IiVnlh1M1eydpgNd9u2dTETnK+yb8zsncE 3VllKdSbNr0xxHb9Mk2rZS4kTvLoMhcdjG6eDAqLkfwBAQi4IpBOMdoatu61mmIrt1N4GVNwRHXC Nry6yfeOtToaXvkkaZuElMG5MC1h7geVvJmHiD9Czq36Sgg2rGpkk3k348pZqCFtI41W47qqnbPl wyynrUMgHALhE5A9Wfur9FTPogvolraZlZhy5Xvp7eOr1TdAFvArOZd2/llkkYtS0XfzUPAu6baE dKd7knT/WueDGtLqCWjFH+XfdXUTOpzYF8LZhSMtkkIAAhBoIyBesoilNeEa7L1sW5aEuyLALMcV SfKBAARmI1D4mlO+ytk+ft3MJg0FNxPA5VA7IACBhREQa2MRvIcP02gsrIVpN6SGAAQgECABZjkB Gg2RIQABCIRJAJcTpt2QGgIQgECABHA5ARoNkSEAAQiESQCXE6bdkBoCEIBAgARwOQEaDZEhAAEI hEkAlxOm3ZAaAhCAQIAEcDkBGm0qkeXndXbXKk4lkSzHT6mmJEBZEAiXAC4nXNuNLfnp7+/8jVNj F2eZv59SWQpPNAjETgCXE3sNQH8IQAACkxHA5UyGmoIgAAEIRE9gtmsTKNhPAs23muj7R2pvCclu +RgrtE0qP1mORWMuK1Cu8hej13Y/a7MjqZjlRD/oAAAEIACBqQhwrOdUpMMrR9yae7lb+XYmr59S hWddJIbALASY5cyCnUIhAAEIxEgAlxOj1dEZAhCAwCwEcDmzYA+i0PXVtYdy+imVh6AQCQI+EuBd jo9WQSYIQAACiyTALGeRZkUpCEAAAj4SwOX4aBVkggAEILBIAricRZoVpSAAAQj4SACX46NVkAkC EIDAIgngchZpVpSCAAQg4CMBXI6PVkEmCEAAAoskgMtZpFlRCgIQgICPBHA5PloFmSAAAQgskgAu Z5FmdaKUOEDz4uLT08lJZs4y8VMqZ+otJyNlKPnUViFz6JQUMkmaRB0qTGw1tkVfXM7QChVX+rd7 3Y1kz/1bCuDcdM+/rVb5rqWU2Dtv5tKULTQyfmcI5xQWYCp2UBlK8PkeNC3FIkM73UO0YD2qsfxL jmNa8OXuaEd37FhuWmiOp6hX8q+kelnqi8sZ284R5n/4efZDL8+N7e34/OLZDGoUW5lpHHdfxp9H HneXyh25fowWXN/9qr/PT0lhDnUtqCk/KUnT1YNO5Nhut07ySTPRXfsge/ZtodJp3RwybUS9yv2V /tymr6Or3shmeQTUnZbZDYh5/dQdnfqS0MKjfpc1Lg3LLvPMRc5f8FmTRxvHZqnaUk4d3kLjfGVo yriHarVJyj8mxHvArkdmtGAucPv4Wq5CzaHnECVn+qcToSuUarAZ4Nfqm/sxlTF3CWxe7B5mNVbV XDG1rdOUeFALralHdbq16Mssx+kAhMxWq+vb2+3huxq6v/08bB8fpR86P+I35chUxcyNthaKroXG dr/fro67HyNMQc5ANw9OYTdbsDIIvsmvKZlDC3XkPhtLJzXJUe1QS0ud5gdySpEfyR9uOmbgSPJc Nnpapvp/OX3t/r61ZwtN7f6wOQujZPl1t+6gJS6nAyyiWhG4+ni7VUsu0uPcfrzKJzo9fZce5/bj ei1ixeBzTDQEmQ9fv4m+43DTqR+0MkM+kob9+68cBwx8mi14evoiPcx55J2fHYh3TKbQ1WrzkPaj hxvRx2fThG79mUE52T2nr1Vse8q3e+VuznMWpZKyVuLHpbYPa73RZnX3Kx3h57vlPsDr3sgV92Eo XnnH06EGDWih11dd3Eud6ricPhWCNAUC5S0q67tve+FznpTHKdTQk361owZnuvm7HcX6aJhmGlra zYPsx8Z2Oq7INFtQh+xfzz5Ca6Yfc2hROtnDD+2zneh7+vtbudCzMImjUc5b+XE5ttK6Zf8rV3on ojRkohyPXmmT8y/bGZiLFlrYltHB3+FyxqwQ0ea9+bw/7nZNHqeAJYJNBA00Mgyp0/nyPFqFOf0R neLwEWriOYpiGiy4/mB6c94Quv+8GYODnI/kXoPYFKGoNT/qtsDjnxfhceQCqeDw4giz2l1ReWom fKrf14M3PRWzddXztVBcjk3VI05XAqJG6/WzfMK3H6JtFN54yi5g7DcZXUUfIX4tjXw5m69yoHo8 jrObVsxC5frQ9kPBGn30NFkwWSnVb/HUk6ylqf+bQ/vI0ieN6slte2UxAZW1WEzJz2P4t3vVvyfO W4X/fhYe5/brV7ma/CxmRSN5zLK6epKRW/ezV0tl1b2FqhSHm3TH/XmCVZgHtptl6m08lBcMgbqd J4XleUPt0kOuptjK7RRGnPZbb1zv/xnHHMXhtJFG8qIgTWFHop6szKppIF+TbxLVclNY1V6VX5pr hyzdGFobOFjm2kpY0LdJqMqey1xlP2eQEMjX54ZXWVlyS9qGatl3x1qHOqkHhhX7NtStROXmOllQ hllOu1cmBgTGJ7C++08tyY/yiH6uuiqTvl7pODw2CCgGvvleKdkknSYwh9rp7V7mlnJLQqvlqzMw PXfTk578/+2U6RlLLffpbt7Z3go7Ueo+phKCdJPiQshtVxyxYiMg1mMud6uuNWpsSn5KNbbWY+Qv lmZuDqILdedyxpCymGeIMo9PJagSmOUEZS6EhYArAvIzi+3j142r/KbIJ0SZp+ASUhnMckKyFrJC wBUBOVv88y2oKY48Py44mV3ZazH54HIWY0oUWQgBtXhk0qXz8vlCwKDGEgiwsLYEK6IDBCAAgSAI MMsJwkwICQEIQGAJBJjlLMGK6AABCEAgCAK4nCDMhJAQgAAElkAAl7MEK6IDBCAAgSAI4HKCMBNC QiA0AvkryKuym0On1DV/T4CzG7szBYrXNk+p1zxlteuLy5nHMkGUKqtPh1PJJ9LJT6nKyrfcMy+P ZFTPuZM7p7Do+Aonx2eZSWPV3bRikaGd8UrFOsvXrvR+sepR9bjZrHPx1Wub5wXWUieFcDb2LToV +VeqlZ2+uJzOFSmaBOq2ECfXerlE5qdUBg3N98wfd1/ORy+75JTPS95PNMbYwXjxRN2BXGehzKFj gajLN7knoOO9BhYSqmO3zyeny1MvnZyarvv8QfY018lMt4p9q04l9wWZrb7jHKRLrgsg4OeZzX5K VWfulnvmz31cevhwD9Vqk5R/rLmzflD1zB8ZXDkYOReYHOuZPw+6OfQcorJM/xx+8HJ6h1lejBps Bvi1+uZ+TGXMeS35k4zRUmgvM/Q9STo7Vnu73WYXnWZq5EA32bemHuWpWerLLMdiuEIUCPQl0HLP vLzay83Y1yBgcpVlbmjbVxuVTh50JvtS1d0UMq0Mgm/U5WHJYw7Ni5Q7f8HtrbFqaanT/EBOKfJn Qci7Ny0zkBfKnA9ZLt60M8QAelqm+n91vW7xgmqLnFvqZJN909/zx8Dmb/S21beXnyXRcgk032qi x0G1CxDZYG6s0DapfLSHknn/KpEk18WIf5Ifc0NvrVp21Y3dfTmpvlaznLpxfm9g2sK5+1Sy4XH+ 8hiVfWI0rZE5NBGnNNXpLWQpYd1NMeW8a0lWxvX5H84p6v6Xzz8r33rOZm5H57xr5lpGaC11MrNT nX3PVbfNLkZ9meVYjAqIAoH+BJrvmdd5ptdQW46d+wviJKW+sEYPr/UFyOk8JL3K5jyw15rpxxxa FK14J40Tsftlot4bFu68TCaM6g2nuiBHvu7QumX/K12Gq27bSG6Kdn5PxPlqTnFfp/0rnuY62Wzf MsLCVoNc5W3TF5fTrzIuN5WqxOopj/t0ezHfyj5WaJtUXtuj4Z75TObU6Xx5Hk0Nda1Xcn3ykEKS HqmQhWETwfqD6da5htCRbnKWA/eOewQUteZnfXUtPM2fF+Fx5AKp4PBSxiz6ZeVvunpRczs6i6T6 /cyjiUZr69Qa6mRH+1bYWOiLyxnSAEkLARsCtffM5xNuvsrlquPR2MPZlFQbR4w75euI7Yd17yyS hGpTUmHpT3bieh+WvhUz/+7l9PQle5djDh0ql2161ZPb9spiAvpZ7TK7PI/hi29kVPjvZ+Fxbr9+ vRU+51nMijKPmb67krzsy7RVRU8y1GsmvVzXsYjaOmmyr6ZxuEm3RJ8nWMk80FbftmU5wqMl0GMD 1QSs/JSq9s1A1nvoPqHhfVSyvp8OwO3e5TTfM980kK/JN4lq+YKhkHFurT/RMnld1dBjtobWKjRY 5lrsBX2bXhKmkerCzxnkX1CVXlY12MEStqkh9d2xVvdGq0n9evs26FSNfK4FVX2Z5diOKuKLp9YN vHv8lGo4pvXdf+rF/CiPaPjVC+rT1ysdh8cGAcXAN98rJZuk0wTmUDu93cvcUm5J6NIKmZ676RXL /P+bM3XwnZta7tPeuGpUO4w9Y9V9TNVyeVNVXy4v6EmfZBAInIDaiiyckTuXMz6QEGUen0pQJTDL CcpcCAsBVwTkZxbbx68bV/lNkU+IMk/BJaQycDkhWQtZIeCKgNwAvP92J1aEwnlClDkcuhNJysLa RKApBgKWBHLf3tenaFk+tyyGaBCYgwCznDmoUyYEIACBKAkwy4nS7CgNAQhAYA4CzHLmoE6ZEIAA BKIkgMuJ0uwoDQEIQGAOAricOagvqsz8vYBVxQqhHaIuChHKQAACCQFcDlVhEIHT03dxzFPTgZGl UHmOY/PFiObQQVKSGAIQ8IMALscPO4QqRXIOYMMHheVQeWZ68eTHvN7m0FAJITcEIJAjgMuhOgwg oC8KvP24rs2jJlQdmdx42r05dICcJIUABPwggMvxww5BSqGXzZo+Ya8P1fdaqdPuax5zaJCQEBoC EGCWQx1wQKDbolpaIItrDtCTBQRCJcAsJ1TLzS5350W1VGK9fNY00TGHzq41AkAAAkMI4HKG0Is4 bZ9FtdJE52fD4preY9AQGjFyVIfAAgjgchZgxBlU6Leolgmq77T9/nSqFd0cOoO2FAkBCDgigMtx BDKubHovqrG4FldFQVsIlAjgcqgSnQkMWVQrLa41THT4RKezUUgAgSAI4HKCMJNXQg5cVCtOdJ5f GhbXjB/weMUDYSAAAWsCuBxrVETUBAYvqmUTHT7RoU5BIDYCuJzYLD5UX3kZcPMNxubQUtl6+ez3 3/p5jjl0qBqkhwAE5iDAFW1zUKdMCEAAAlESYJYTpdlRGgIQgMAcBHA5c1CnTAhAAAJREsDlRGl2 lIYABCAwBwFczhzUKRMCEIBAlARwOVGaHaUhAAEIzEEAlzMH9cDKfLu/uPjUcB6a+E7HGNpB1YmK 6SARUSEAAccEcDmOgS4vO328zfXVulY1c2gnGusPhjsNVubQTgURGQIQmItAdC5HDqXv3+bCHWC5 jo63sdCcy9ssIE0XhZYyHeuYSorN5aiv45u+d4/J8La6OjvexqZAfT0bx67ZsBo7Di1lbMKR5h+b y4nUzH3VdnFmdJey1xy71gUXcSEQHAFcTnAmm1Dg6RbVUqVYXJvQvBQFgRkIvMfwvIrTI+uf/avU /59Yz6k828d/mk1soVmNUNgyDOWKUhs6hFVSgM5CG6b6NIQOKZe0ZzO3tZQYegt0HJUAs5wZ3HwY RU69qFaa6Px8q8WUTIMaQsMgi5QQiJjAqA7Nv8zViLZx4O6fvPNJ1GOK40zYOct2pkTgGdFSAjeg r+Izy4l4uGFSfdKdamVB9M613Y/6iY45FHtCAAIeE8DleGyc+USba1GNXQTz2ZySITAFgdhczvrq egqsgZcx/U61CjA+0Zm5DtFSZjbAUouPzeWsNg/v77/u1ku1pxO9Zl1UyyY6fKLjxJi9M6Gl9EZH QgOB6FwOtaGVgPrufP+twS+bQ1szt4+g96Y1nRRhDrUvhZgQgMCUBC7EvoYpy6MsCEAAAhCIlgCz nGhNj+IQgAAEpiaAy5maOOVBAAIQiJYALida06M4BCAAgakJ4HKmJk55EIAABKIlgMuJ1vQoDgEI QGBqAricqYl7WZ68AfLT06lBNnPoRAoFIOJEJCgGAgETiNTlnJ4+mfrYgA3aR3R9vM311bo2sTm0 T3m90qw/GI5dW5lDexUYayLaRqyWn0bvKF3O6enL7tjcx05D3p9SPDjexgIGl7dZQHIRRZ10c9x9 aZz0uiiEPKIlEKPLUV2suAPsYROt2fOKe3G8jY0lOHbNhtLwOJsHeXlE40Hewwsgh5gJROhyVBe7 2n/G4ciKP/eZ0V0a35pj17rg6h9381neB3vgHrz+CEnZRCA+l4PHKUxx5Ixv+/i13v+al9ymb1Us rk3EHJ8zEegIi4nO5ahTKVfbD+sIjV1VOZhFtVR0Lm+bpt7K7RjNZ6pOIwOlLJJAfC7nj3iP07g7 a5E2blQqpEW1VIlkotOw5mMOjcu6g7TVt+Uc/5wG5UJiCFQIROdyGL5ldSCMnWqVKqsWfQ7fGzZU mUPpASwJsBhgCYpoXQnE53IYviV1JLhFNRbXurbu/vFPLAb0h0dKIwFxX05kj9wBKvdIR6Z2Sd1/ j3KxvomCOXR+csqG28d/9ZKYQ+eX3n8JaCP+2yhUCaOb5axW7MYR3XWgi2rFic7zS/2rBvMHPIxB Wwmwq7MVERH6EojQ5axUj7Q63Ny/9aUWfLpgF9VS8nyiM14dfLu/EV+uNe6cH69gco6BQIwuZ7W+ +086nd9/6wfJy7e7ejm8/3a3rlXVHOoJHb03rcmE5lBPVPBUDGX+7eN/DbXDU6kRKxQCF2JFMBRZ kRMCEIAABIImEOUsJ2iLITwEIACBYAngcoI1HYJDAAIQCI0ALic0iyEvBCAAgWAJ4HKCNR2CQwAC EAiNAC4nNIshLwQgAIFgCeBygjVdN8Hf7k03b5tDu5U0S+yFqzcLUwqFwAgEInU5sd3vrs+Mvr5a 11Yhc+gItc59lvK01uZ7LM2h7qUJOsfY2kbQxgpQ+Chdzunpi7yKuqkHDtCMLSIHfryNhUG4vM0C kl0UdW/Bcfel4ahuu0yIBYEGAjG6HNUBixMtHzaRVIvgj7exsZP5YDWOXbNhqONsHuSpns1zRvuc iAmBCoEIXU5sZxaGeBFbn5bKsWt9qNWm4eRbZyjJqEwgPpcTm8dZ/qJaWqdZXHPWv+FznKEkoxKB 6FxObNcdRrGollZqvXy2+/FWP3Y3htI15AlweS71YSQC8bmcqK47jGVRrTTR+Vnvc5JpUEPoSC0s zGzVHoLV8c8pTPGR2l8C0bmcqIZv8SyqZS1MLQkdvjdstzKH+ttMJ5cstsWAyQHHW2B8Liei4VtU i2osrrnsxU5RLQa4JEdebQRCvUG7v9yx3Ov+T15DJ/aC15Myh/an60NKZeHt4796WcyhPsg/vwyx tJH5SccnQXSzHPHZgVx6WR2WvqIf4aJacaLz/FL/IoJPdNqGoavYdnW2AiGCOwIRupyV6nNWh5v7 +pfM7uDOmVOUi2rZLoKPt4ada+YPeOY0mh9lv93fiNORto9fN37IgxSLIhCjy1mt7/6TTuf33/ph 8BIMrF7/7r813F9vDl2A/npvWpOBzaELUH+QCqpybB//a6g7g/ImMQQuxFoiFCAAAQhAAAITEIhy ljMBV4qAAAQgAIEKAVwOlQICEIAABCYigMuZCDTFQAACEIAALoc6AAEIQAACExHA5UwEmmIgAAEI QACXs5g68HZ/cfGp8SpHc+hiINQrApqFGxj1wiGAywnHVkZJ9ZnRTXdrm0MXgqBZDXmWa/Mtl+bQ xcNBQQhMSSA6lyMHvAs8diDi420smguXt1lAKkdZaEvpQYIkLgnE5nLUp9XLO3Yg6uNtbNqD+WA1 jl2rMlxoS7GpLMQZk0BsLmdMlrPlHdtFbH1Amw9W49i1PkxJA4HuBHA53Zn5loJFNRuLsLhmQ4k4 EBibQBT3NejrP+oefZ2Mvjym9GQXrvgZmhmux+0wfmo0nlQJq143CI0nlY85t7WUKLoLlByTALOc sX36yPmzqGYPOJnoNNyUZA61L4WYEICAgcCY/szDvNXIsvHCSA8FbhGpxxQnPCUdSgwvW5hLaym2 ehNvZALMcoIekLBTraP59N603Y+32nTm0I5FER0CEKgSwOUEXCtYVOtuPHYRdGdGCgi4IxCby1lf XbuDN3NO7FTrZQA+0bHCtqSWYqUwkaYhEJvLWW0e3t9/LeKOXRbVejYRPtGxAreclmKlLpEmIhCd y5mI6/jFqK/D998avKc5dHzpvC5BL641nUFhDvVaMYSDgPcELsT2BO+FREAIQAACEFgCAWY5S7Ai OkAAAhAIggAuJwgzISQEIACBJRDA5SzBiugAAQhAIAgCuJwgzISQEIAABJZAAJezBCuiAwQgAIEg COBygjCTFlLe0/jp6dQgsTk0IDWnFhWsUxOnvIgJ4HKCMb4+3ub6al0rsTk0GCXnEHT9wXDs2soc Ooe8lAmBgAngckIxHsfbjGUpjl0biyz5QqBCAJcTSKXgeJsRDcWxayPCJWsI5AngcoKoD5wZPa6Z OHZtXL7kDoGUAC4nhLrAotrYVmJxbWzC5A8BRQCXE0BFYFFtAiNxedsEkCkCArgc7+sAi2rTmCiZ 6Px8qy3OHDqNhJQCgfAJ4HJ8tyGLapNZaPNZ3Glw+N7w5ZM5dDIhKQgCQRPA5XhuPhbVJjQQi2sT wqaoOAngcry2O4tq05qHXQTT8qa0+Ajgcny2OYtqk1uHT3QmR06BURHA5XhsbhbVZjAOn+jMAJ0i 4yGAy/HX1qe/v1er/be7da2I5lB/tfJeMr249vvvqVZSc6j3yiEgBGYmcPH+/j6zCBQPAQhAAAJx EGCWE4ed0RICEICABwRwOR4YAREgAAEIxEEAlxOHndESAhCAgAcEcDkeGAERIAABCMRBAJcTh53R EgIQgIAHBHA5HhjhLMLb/cXFp4YzvlYrc6hXiixHGEyyHFuiiQcEcDn2Rjg9fTI5BPuMmmLq422u r9a1Ecyhw0snh1oC6w/b1XH3460ejzk0WKTSzyZP8wgoWO0QfFYC4rucQJ5/j9sqqe3jv7z4r+Ij vuQRIfKv/Wu7erlUMnEpz/dCcDmwPXfrGKqcxvzNodaFELEzgVnsMlttf6+WPGKd72wMEoROIPRZ znF3mQ7D5MjsRswSkkeEyL+aviI3+Pnj88upLni7rfF57sYLHG/jjqXTnPw5dm2K2q7O9TuPfKS/ bZ7kOeVMZnEQCMtnqgFnbuJyHoAmU5HcgEz/kh+h5acr1dmPOVRwUsO/sUZ8emzZNCczh4ZlwwCl nck4s9R2WWi+ko9a6wOsC4g8kMBqYPqJk5caoe4KZAOpW/xQoWknXlo8U+OJQgef5tDcvYzZ+GZZ vJnYeCEXN4t9Zq3t2lpJs7FZng7ZvMg+HYEQXU5p+qmGZOUBYYlgpeWUfzg7r2Qtu6aRjehyZunR pqtlCyhpjolO3TBpstqezOorQ7MF2BIV5iQQuMvJVgDMLqfOWRR+q3lZW11BG83lzNGdzVnpwizb XMVaxjy9VC67nClre9YimOD0sh2JmgiEuH0g1wh+FU72b9wqcPoj3ogantPLcyVC0yYC96/4uIjN PdMRctx8Fm85Dt8bvpoyhw4QZ47aLnbiXMpNBLLsh80A4UkKgQqBsLxx81iyZtE5NysxL6xVl7Vq 5x0jzXJYVAulDk49G52ltqfTm7H2yYRibOQciUBAC2uVxa/mb3JyjrVt+0AhV5Vj5Ze6JXW7D34s jDZ1N2YhElEaCUw3PJiptr/WffzmrLJTsyDwHuLCWsNcdfOQbbBJYkgPkq4LiNBCK/ZkzYBFtaBW Hvz5RGfa2t7j67ag7Iqw0xHgVtDpWNeUJBbNbw7CMxbfSaURzaGzCh5t4eLUI/GaQwxYat9xmEOj hYbiEMgILGiWE6BVT39/i0WLb4U9EGc1zKEBqrsEkdd338QugqZRvzl0CfqjAwSGEWCWM4wfqSEA AQhAwJoAsxxrVESEAAQgAIFhBHA5w/iRGgIQgAAErAngcqxRERECEIAABIYRwOUM40dqCEAAAhCw JoDLsUZFRAhAAAIQGEYAlzOMH6khAAEIQMCaAC7HGhURIQABCEBgGAFcTgd+8qrr+7cOCSaJ6qdU k6juuBA/SfoplWP0ZBcNAVyOvanVaQDenTblp1T2VP2J6SdJP6Xyx2pIEhgBXE5gBkNcCEAAAuES wOWEazskhwAEIBAaAS5waCFQf1uONLO+iqfmDuvVKrvKZ6zQNqkwqy2BNpJjWdBcc9qkstWOeBDw jACznNDGCMgLAQhAIFgCnCRtbzp1Gcqq6XIb+3zcxvRTKrc6TpObnyT9lGoai1DKAgkwy1mgUVEJ AhCAgJ8EcDl+2gWpIAABCCyQAC7H3qjrq2v7yJPF9FOqydR3WJCfJP2UyiF2soqLAO9y4rI32kIA AhCYkQCznBnhUzQEIACBuAjgcuKyN9pCAAIQmJEALmdG+BQNAQhAIC4CuJy47I22EIAABGYkgMuZ ET5FQwACEIiLAC4nLnujLQQgAIEZCeByZoRP0RCAAATiIoDLicveaAsBCEBgRgIOXI44d/Di4tPT aUYtLIp2IKWDLCwErUYxlzuXVL1U8TrRLCTlNdPJU9+GHEjVJwstV79r15vS9pHD6xqDcD0IDHY5 p6cvu+NqdX21Xq1UlSo0oMIvsv7mWtg5qqzZ55j5ap79KppjKWmhgVYabuUHdW7IcffFpWscJnNq raKo8q9EtTTgUgLmmZ7AyPZVdf7mkOl13F2OMXLr2EKNmOubr2jJVoKP0QanrxWUOIzAUJfz9kP2 h/vXh80wOXKpDz+Fa9LP6eW5sbc9Pr90mlhtHuS1V8fdjyx3ZxKvVn1lrnY6uS4olW+73ToUlax6 EBjFvrrtZLf5jVQ9e7bQzYO82atfs25MO2ob7GFWksxBYNiVcfryQn09pnrUD7m/m35Udy1mrS2X VvavafrsasRyAQmoYjnJ9Y060yRpMUZF2m7KO5e5Rsi6Mup+O0tuDu2mYdyxp7avNH++CdRbcqB9 u7fQ/DWopRaa3YLbJHZL2qxhlnuIuCteXNoPm+W8/ZTLAvvP5ynO+oNwJb//ivnHeUH39Pe3aFsf 1lYe9fr2dnv4rpa/RO7bx0fl1LJHlSgqvKrbubGniLC++6UHipefPn2SkwURrThK23yWmRVTWQnV EqmnzKkueSGFEu/vv+7sWLmQnTzaCYxkXzkZOJv67V4toKoVanfPCC00FU4tO3Z+2TNWG3SHjJzG JTDI5Shf0uBMdF3v0b9ffbzdqkUz6XFuP17l9T89fZeu5Pbjei1iVXPfPChXdDyqxb5qz60covaI Tp8BMjvuYpyqRWYJgbHtm62vOl2hFsL3aaFq1PP+np+wVCqCGNddpK8Y86Mki7RjtUEqayAEhrmc P/JNS6HT1G8I/5ykx9m/ilmH6N9PMpp917q++7YXPudJeZzCkC95tSPre1Lhk/nQGbYqSz11jkXf PSLEc22dQTInwhRezXYePbrWiPzyBMa0r7ppWtZasdrU791Js610c3DdQgfVjdHa4CCpSDwZgUEu p27Aon/7K+Y/YilN/HF8/vGzw7qaUlxMvo+7XZPHKbApbCIQjVcvqMnVOOGYKv22adA3EHlfmQcW S/KJCIxkXzHOUP5Gvtxw7W8EmbFaqHyXY5wGGbygYWlkIltSzJwEhrmcmkmDGsQcdrtjuvx1/C1X 3+wnOYnP0etneTRq603hfaas9OctaHoxXET4dXenF9gON6W15ppBnzP4apG6k8wqxeEm3V+q9vmk L4tH6H6caRpnRu7tmy6nyTo9kr3rphROWqh0Z3IBrrvcY7bBOGtmaFoP2y1Rswcs2YaV+IZ0KFTZ hFbgtH8tDpl07GzDWompyrp5jCWDC0mz7TGOd6wNk9kwUEzY1etf3uwzcEfTMPsvKnWZ5Lj2bajA lb1cA+3btYU2NbqGJlkQ15w2ty21sqd1UfUIZYwEBs1y1BKY8AeFPWB6Lp9Oa5Kb2233q43qsKu7 d0YtziJzOVAsdz1qmlaY3llkRBQvCfSwr+u9LZ61UP/aoJcVZ9FCDXXJSY/p/0Z7PQSr+dDAmsDA 8aZ1Od0i+ilVNx38iO0nycFSedRCh7dBP2oKUgwgMHCWI1d0/5OvTVwPzpy7ef1x0ON/TCCcoyVD rwn400Jpg15XlImEuxDuaqKiKAYCEIAABOImMHiWEzc+tIcABCAAAXsCuBx7VsSEAAQgAIFBBHA5 g/CRGAIQgAAE7AngcuxZERMCEIAABAYRwOUMwkdiCEAAAhCwJ4DLsWdFTAhAAAIQGEQAlzMIH4kh AAEIQMCeAC7HnpW6dc6/WwX8lKoDVm+i+knST6m8MRqCBEYAl2NvMPXxtHfHLPgplT1Vf2L6SdJP qfyxGpIERgCXE5jBEBcCEIBAuARwOeHaDskhAAEIhEZgwJGgcSRtugRE3+TYcHFPdmB17a0oDkLb pIrDNi60bCM5lgXNNadNKheakwcEZiDALCe0MQLyQgACEAiWACdJ25tOXBx8uVv5doOan1LZU/Un pp8k/ZTKH6shSWAEmOUEZjDEhQAEIBAuAVxOuLZDcghAAAKBEcDl2BtsfXVtH3mymH5KNZn6Dgvy k6SfUjnETlZxEeBdTlz2RlsIQAACMxJgljMjfIqGAAQgEBcBXE5c9kZbCEAAAjMSwOXMCJ+iIQAB CMRFAJcTl73RFgIQgMCMBHA5M8KnaAhAAAJxEcDlxGVvtIUABCAwIwFczozwKRoCEIBAXARwOXPa W174+OnpNKcIlO2WACZ1y5PclkbAT5cjjjIc2hd3z0J2FslTcgPd87KsJusP29Vx9+PNMjrRfCdw evp+WK2ur9a+C6ouVa+v7V1E794yZmhlXRQi7vgEyhcmnK8H0dfB6Cf7VVz1UrrKI7v8JZ9TLk6S QkdrSVsIrs3Y8n6HRN5MBfOlJ3VXlxRK13INEahJbpXzGBlbgiKaSwLW1py1lZ1bc9a99KuBwbQy lzYmr4EEVs0uJ7mCrHgNWdXlVDrM2u49iVW+eapU1dPg7XY7qCPW+eR8Zr1MWRkll1JJnvrKvBce CL7gzPu1eEcSkI0rAtYeJ9/pn+vUuZJO0cqyOldT2+2ABNTK7BQi1hQEKi4nnYrIXj9tDZmjyHW5 eeeR74mT3ytTpHyv2pS2OKnq3w/XNyL1a1mD8+QrX5xq/MXyezfMNivqjmYEZ9ZWMOFuCXQ0pPZP c7QyWXJLbbchE1Qrs1GIOJMQaHQ5+0fRFWYd8vbxsdhhpwO6cjuzGeg1pT0rXNPld6DR4B1KLkdL XufXarxmtiY4hmuwYdZBfaLOQqCrFXV1nLOVaUz1tb0dYWitrF0jYkxCoHn7wNXH2+3x+eW0evt5 2N5+vMq/VtJvScWv67WItVodfhbegBtfn7akHf726vT3t/QlH2pf4R5u0peml7ujVqFQonwfeiN0 E9OOh00hRL7qX61+/z0Nl7CUw+ar8H7sInDOddIMRSupqU6tIszbyppre6vgwbWyVo2IMBGBGseW TQfEf9T0Rk4F8nOEmjcj6WyhNJXIL6HpxSNDWkeznKYlsIIstROcTLbaucxoS2vpUHOMGdQk4xYK 6biols0upMnnamXm2t5m0xBbWZtOhE9BwLhJevN5f9zt5BynMBU4vTyLCULxUfMhi2dIWovsZRTj dCTXrf+6K2gldm+qiY+MUZrgqIKNwzpL0RqjCdJirvidT3SGgpwn/dsPUXO2j1+L82JLWWZpZW21 vVX2EFtZq1JEmICA+bsc1ROWPU7Svv4VJyXJwpDuO2/SD1s2D+nERkyDREduTOtIXX2N4vGPlQvU ZaYLDHKuVuduVJw/0s+O9ckFi2uOrD9HNj0X1VJRp25lNrW9FWOQraxVKyJMQKA0lSque+k5QXlF KpVKLaYVEshfGvYjbx9f1fv65KlPW19S5wWn6qS/IlRlx04VdbHYMZfVcu9x+2/Tm2JOTBk1BHos qs3ZygrN8FzrOzeypFuo/Xqv0MoTZA39wtStjCo8NwH3pw+s735V3I7oSEvLWKM6UzVsLO9p6Fxi YaeAGsiu9p83nbOxTqAnOpYLlNa5EnFkAoMW1XrL5ryVdd8XE2Yr602chK4IzO3zxim//F30wFL0 FGf0GUiP8fJAxUg+lEDXvdFDy/MpfZitzCeCMcrifpbjyhcOymd9959cxus+dKstVe0c2D7+V9xv MEjA2sTru2/CtzkS2r145FgloKrG/tvYNcNP9GG2Mj9ZxiPVhfCz8WiLphCAAAQgMCOBhc5yZiRK 0RCAAAQg0EAAl0PVgAAEIACBiQjgciYCTTEQgAAEIIDLoQ5AAAIQgMBEBHA5E4GmGAhAAAIQwOX4 Wwfknb2lK7H9FTYeyTBLPLZGU/cEcDnumbrKUZ6cyJ0Grmg6ykffvTHWUXuOhCQbCHhLAJfjrWlW +stQzpf2yULzHG/jEwFkgcAgAricQfhGTsyxayMD7pr9wDOjuxZHfAgsjgAux2uTqktXWVzzxEZ6 US3W4208MQJiBE4Al+O3AVlc88c+LKr5YwskCZYALsd303F5mycWYlHNE0MgRtAEcDnemy+Z6Px8 817SJQvIotqSrYtu0xHA5UzHundJ+nbv70+n3jmQcCABFtUGAiQ5BDQBXE4INYHFtZmtxKLazAag +MUQwOUEYUp2EcxpJhbV5qRP2csigMsJxJ58ojOboVhUmw09BS+PAC4nFJvyic5MlmJRbSbwFLtI AricYMyqF9d+/2UTwaQmO/39zeefkxKnsEUTuHh/f1+0gigHAQhAAAK+EGCW44slkAMCEIDA4gng chZvYhSEAAQg4AsBXI4vlkAOCEAAAosngMtZvIlREAIQgIAvBHA5vlgCOSAAAQgsngAuJ1QTv91f XHzi2LUxzAfaMaiSJwQkAVxOqPVg/SGAy9tOT586OkbZ3SdPyaF2z6ufafXxNtdX637JSQUBCBgI 4HJCrR4BHLt2evqyO+Z6b+U0yk/OscjwG9HdJ89xd5n3Ouur65W4IfXLyDM7jrcJtUUgdxAEcDlB mKlWSN+PXVOd92r/+rAxMT47Fh1/+/hPfJ4snldx1kLhDu7NQ+Un98bjeBv3TMkRAmcCuJyAa4Pf x66pznu1/3x2OOu7X8qRCDekvUrqWJ5fTokZto//3SUrWsqjFg/4URcHrQ7j3VbHmdEBNwdED4IA LicIMzUI6fPiWtXj1CmhTjBLns3D+/uv1OGs3u4vC6tyKtLIPodFtZBbA7IHQQCXE4SZGoX09vI2 7Uu2H5IpS1GBw036Rke5le3tx2K07KVOZVVObpoY7WxTFtXCbgxIHwIBXE4IVjLImEx0xltr6snn 9Ef4Eot9X/LVzXlqIwsT/kY5Irn8VnkNpPYQrI5/Tj3FMiRjUc09U3KEQJkALif4OqEWmw7fR97I 1RWTcTqSe5dTdDdiOe1C+RsZo27bgXHy1FXGQnwW1QbhIzEE7Ajgcuw4+RzLy8W1HtORdDlNTnya drnZTp4624tFtc7ISACBPgSyrUP8J2ACah9Ytr3YD0WUTPnNae//5Ba0/JOXuBKoI+YmRMn+tvJv LrTVhRfLcpEveUAAAkUCzHL6+Gnv0vj4iY6b3WWFW1DtdsF1tw6Lat2ZkQICvQhwK2gvbP4l0i/d 6964zydrshHAlVDiPY84m0DMjErvfwYrqDIeId/BgpEBBBZHgFnOQkyqd64V5gSza7a++6/yNWd/ odTOgdynov1zKqVUGe+/ZV8EOcuYjCAAgTIBZjnUCQhAAAIQmIgAs5yJQFMMBCAAAQjgcqgDEIAA BCAwEQFczkSgKQYCEIAABHA51AEIQAACEJiIAC5nItAUAwEIQAACuJxl1gF5n3PpIudlKtpPK/D0 40YqCAwlgMsZStDP9PJUzcKVmn6KOY9U+szo66v1PMVTKgQiJoDLcWZ8OXK+f3OW3bCMfL68bZhm w1MHdryNV/VqOH1yiJwALsdVBVDfsHv09b+Px665Yj0on8DOjPatXg1iT2II4HIWWwfWH29ZXKtY l4vYFlvhUSwIAricIMzUS0gW16rYAltU62V3EkHAZwLc5jCIgL4Upu7Rl6/U3gKTXRMzXmiiVMM9 MOOV62fOmYlr7xXyUea2ejWo0pIYAvMRYJbj83hgsGzJROfn2+CclpABi2pLsCI6hE2Ak6Rd2U9d DrNyf5nLUPm4DCYlGCYJX+vV0HpJ+kgJMMtZuuH1zrXdj+gnOoHtVFt6vUS/SAngchZveHYRSBOz qLb4io6CQRDA5bgy0/rq2lVWrvPhE51VuDvVPK5Xrusp+cVAgHc5MVhZjPHFi6aj2ET3sIlC37KS Yb7GidJUKL1wAsxyFm5grZ5eXPPobIRpqasv+Pff7tbTFktpEIBAmQCzHOoEBCAAAQhMRIBZzkSg KQYCEIAABHA51AEIQAACEJiIAC5nItAUAwEIQAACuBzqAAQgAAEITEQAlzMRaIqBAAQgAAFcDnUA AhCAAAQmIoDLcQVafG15cfHp6eQqv3M+5pzHK9esCeU6sbS8Zjp56ivPXJydaEcmECgTwOWMWydy PUrWtVxc3L+pUusDRTzd+aTB4tyAcYV0k3tBm6IGSnWh9BAaboR0ncsgjaQ3uTlkIh13l6MMWVzr TH4QGEAAlzMA3kRJt9vtRCVRzJQE1Llvq+y+PnkrGyd+T2kAypqDAC5nXOqbB339nrp5MutdkpPO RGDx9+I1omna/27HldFR7lLc7NbNX+pwmVRBpblQeggNR1I6zmaoRtvH/9JjeNThq/EeSuTYMGTn KwFcjieWUUv2yYKbJyL1EGPzuTRUP708i5F85+PNlkEjD7BGI+mutGuWz9u9WkC9vkp/6IGfJBDw ngAuxwMTiUX8i/SFzfruV74j6iud6uHKT/amYEioWSI9VD+kN1/rtaP9500HPXrRGKKROW0HyZui tmqUvdTZv0Z61LcDymQRBgFcThh2CkbKwoVw+iLOx69dPE4wmroSVF8sIXKL924JVyjJJwACuBwP jCTfdKiXOu4eNVkqP9kqzpDQVhn14trzy6nnRZy9aAzRyJy2Vd/2CAaNxI435W+Eu4n1LqN2fsRY EgFcjifWVP3eMlZV9CWku0vdl3ZaVEuNsSAaiUo1GqXLacneCk8qImJAYFQCuJxR8Ra/rZFr+ukn KrLYdIhb/j0RqfBdTkOccaXvmbteXJNPaVHNqFELjZ6yjJysv0anpy/J91aZaZOvl0YWmewhMCcB XM6c9Bdbtlpc67FTbbFArBWL9uZWa0JEDJsALmdc+6XfbRRfq5y/y6n9PRHJmHZcsQfnrmUvLxQO oTFYpFEy6K9R7RskF5sVR9GTTCHgiAAuxxFIsoEABCAAgTYCF2Is2haHcAhAAAIQgIADAsxyHEAk CwhAAAIQsCGAy7GhRBwIQAACEHBAAJfjACJZQAACEICADQFcjg0l4kAAAhCAgAMCuBwHEMkCAhCA AARsCOBybCgRBwIQgAAEHBDA5TiAqLLgjnpXJMknT4B6RX1YFAFczqLMiTIQgAAEfCaAy/HZOsgG AQhAYFEEcDmLMifKQAACEPCZAC7HZ+sgGwQgAIFFEcDljGtO9fK3/Hx6OulSCRVooJGvHxmNcesl uUNgJgK4nJnAUywEIACB+AhwkrQrm4sZy+Vu9fjv193aVZbkAwE5E6ZeUQ+WQ4BZznJsiSYQgAAE PCeAy/HcQIgHAQhAYDkEcDnLsSWaQAACEPCcAC7HcwMhHgQgAIHlEMDlLMeWaAIBCEDAcwLsWPPc QIgHAQhAYDkEmOUsx5ZoAgEIQMBzArgczw2EeBCAAASWQwCXsxxbogkEIAABzwngcjw3EOJBAAIQ WA4BXM5ybIkmEIAABDwngMvx3ECIBwEIQGA5BHA5rmzJHfWuSJJPngD1ivqwKAK4nEWZc05lzpf/ 3L+d5aheCXS+EeYcxi0xc1qOsiEwHQFcznSsoynp8DPzOaeX52NJ7+PuS3pFXTREUBQCENAEcDnU BEcE1ne/Xvcir+12m/mctx877XH2r+/v7/8et+qP1Oms7/6Tv2y5ZMiRCcgGAt4TwOV4b6LQBLy+ vd0evquJzNvPw/bxUfqh87Pd77fC6fzIJkKh6Ye8EIBAfwK4nP7sSFlP4Orj7fb4/HJSHuf241Up 1oev34QTOtzk3/iAEgIQiIMALicOO0+q5fru2174nCflcdbVojcPcgUOpzOpUSgMAl4QwOV4YYal CbH5vD/udg0eRyibOp0vz0vTHH0gAAETAVwO9WMMAsLniH0BtXMcXdzmq9w5cDyW97ONIQx5QgAC vhDA5fhiidDlkB/Z3ByEFoebi4uL+9XD+/uvqx/iv+cfL+X2tePuUr3FSbarha428kMAAl0I4HK6 0CKuSwI4HZc0yQsCQRDA5QRhpgCEFJ/liE9v0udho1bPxFSn5tGBaqYj0/y6WwegHyJCAAIOCOBy HEAkCwhAAAIQsCFwIUaZNvGIAwEIQAACEBhIgFnOQIAkhwAEIAABWwK4HFtSxIMABCAAgYEEcDkD AZIcAhCAAARsCeBybEkRDwIQgAAEBhLA5QwESHIIQAACELAlgMuxJUU8CEAAAhAYSACXMxAgySEA AQhAwJYALseWVGu8t3txtNhbazQiQKATAepVJ1xE9pwALseVgU5/f69Wv/+eXOVHPhCQBKhX1INF EcDlLMqcKAMBCEDAZwK4HJ+tg2wQgAAElkWg9qhffrQlIG9Urn/2rzKPf/IisvKzffyn8ydUoIFG vn4kNNrqlW39JB4EPCPALGdZIwi0gQAEIOAxAU6SdmUccSvm5W71+I/bX1wRJR9JgHpFPVgUAWY5 izInykAAAhDwmQAux2frIBsEIACBRRHA5bgy5/rq2lVW5AOBjAD1isqwKAK8y1mUOVEGAhCAgM8E mOX4bB1kgwAEILAoAricRZkTZSAAAQj4TACX47N1kA0CEIDAogjgchZlTpSBAAQg4DMBXI7P1kE2 CEAAAosigMtZlDlRBgIQgIDPBP4PtqxDwxxVr30AAAAASUVORK5CYIJQSwMECgAAAAAAAAAhAEgt /FgAgAAAAIAAABcAAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ//Y/+AAEEpGSUYAAQEBAGAAYAAA /9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgAwAEAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEB AAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpj ZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgME BQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkj M1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ 2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4ooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiivz98Rft9eG/AXgT/AIKBeLfiN4Fn8Mat+wPq+tDXPCtp4l/tm8+J3g+8+Enhn4tf CXxV4buT4d019Pn+K9v4lHgrT9ESw1v+yfHmi67oEGqa7JYGWTOdWFNYiUlN/VsDiMxqqnSq1Z/V cNXweGqulCnCc8RiPbY7DRpYLDxq4yvGVWrQw9SlhsTOjrSo1K06FOmoynicXQwVJOcI/v8AEU69 Sk6jnKMaGH5cPUjUxld08JRqyoUa1enWxWGhW/QKivzbuv8AgpZ8H/hgniqD9p+70D4R+IvDnxW+ D3wAj8D/AA8t/j1+0B44uP2gPip+zboP7RY+DTeHPCH7OGiXOteM30vUNU0r4fQfDGT4m2fxJjtv D1nDdeG/ih4pi+Emmc74H/4KvfAjxH8Wv2wfAXizwT8d/hj4K/ZB+HWhfFjxT8VfHH7NH7WXhrQb 3wE3wwuvif451TxJa+K/2ePDNr8P9V8K6XazReHPCOq67qXjD4qWsF7qfgHQtTSwu7WLapH2Xtea dKUaFNVqtWjWo16EKLwVHMlWeIoTqUHReXYnD49VY1HTeDr0sTzexqQm8KL+sRwkqUKr+vwoVMHC VGrTrYiOKrzwuH9nQqwhWlKtiqdXC04ezU5YqlUw6j7anOEf1Gor5n8Zfthfs7eAdT13RPFHj65t dc8PfCbwT8bbvQtO8EfELxDrmo/D/wCJXjC9+Hvw7l8LaN4c8KatqfjXxj478d2Eng3wf8L/AAda 678T/Enia60rRNH8HXmo63o1vf8Azj4j/wCCgvhXxhc/sc6r+znfWPinwn8dv22tc/ZN+Ldn8Svh z8U/hv8AEf4b3fhX4GfH34keJvD2qfDP4i2Hw0+Inwx+Jel+Jfhd4UDaX8S/BStP4N146ta+Hrmy 8ReHPEMZGE51KVKMJOVXGUsCrRbVPEVc3hkTjVaX7uNDN5vAYmUrfV8VCrh6ijWpyppOpTVCtiee HsaODxOOc1KNqlHDZHU4kaou9qtWtklN5lhacG5YjBzpYmnehUjUf6TUV8R/G/8Abw+B/wCzV8QP ilovx48beCfh58O/hJ8Ifgf8UfGHjG6ufijrPinQx8e/jR4s+B/gb+2/COifBy+8I2vg3VfGHhuL TbPxVpPxW1/xDZahJq83jX4f+CfB+l6b418RfOHxY/4LGfs0+BfD/wAMfEXgfwr8fvienjD9qfwt +y74+8L2n7Kv7Y3hv4nfCDXdd8J6d44u9Q8W/B+8/Zr1H4rW/iB/CviHwprvgLwHrHg3w5q3xe0r W7q9+HF/rkXh3XfsedKcK/sPZSjUWIxdHAwcWmoYmvm2HyOnDESvbCwWaYvC4WpXxTo0KP1mhXrV aeGq060takZUnXVSMovD0K+IqRafM6eGyaPENZUo25sRVhk0o5gsPh1VrzoyiqdKVSSg/wBa6K+O Nc/b6/ZW8N/F7T/gbrXj3xPY+PrrUvh1oGqyt8GfjhN8PfAXi/4u2tnd/C74ffF74yW3w4m+D3wV +J/xAi1XQI/CPwv+LvjvwT8Qtdu/FXg2w0/w1PfeM/CtvrHyD+1l/wAFgvgR8KvgF+1J40/Z+f4g fGH4p/s+694k+EF6NN/ZW/a38cfB/wAHfHzSvH//AAqi68J/Efx94F+EyeEXl8F+L5oNa8TeD9N+ IOjeJPEHhSTQbvw9qVpYfEHwN4i1Um3GLajKcuXEONOLip1HhfqyxEIc8oQ5qMsbgoVeacY0ZYzC qrKmq9JyIpS5G5RhCf1V+1lzOmoY2GIq4So3CM5OGIo4TF1qDhGTr0sJiZ0VUVCpy/sLRX5+fDf9 vf4NWF/8GPhD8Y/ilqupfHD4lS+FPC8vimw/Y5/at/Z6+EUnxP8AHPh648aeDvhh4pl+Kmk+PvDf 7Ofxj8S+EH0rUtG/Z6+OPxus/jRfLrXhmSHw28njbwnY6h21v/wUG/ZEn8f/ABI+HcvxXn0u9+Es HxJk8d+OvEPw6+Kvhn4E6be/BrTRrHxe8O6X+0n4i8D6X+z14r8Z/CzTE1G9+I3gXwj8T9d8ZeCo fDvjA+JNC00+CvFo0WqrhS9s5VIOnRpY3ETrXlCmsLlvsHj8U3VjTlDD4OOKws8XVqxgsLHFYd4j 2TrU1KKfNU9ilCSnXWB9nSfLKpKWZOtHL4RVOU41JY2eGxMMJ7OU44qeHrrDyq+ym19m0V80fs8f tefAf9qUeI4/hBr/AI0k1XwnYeGNa13wt8Tvg18afgF46t/DPjeDUbjwV42tfAHx7+Hvwz8bat8P vGQ0XXrfwn8QtI0C/wDBPiS/8O+JNM0XX77UfDutWth8cfHH/goNqHgL/goL4K/ZMtNZ034V/C/w T8BvE37RH7RvxW+KX7LX7SfjLwbceFdP1GxNlpXh34+6Dqnw6+AvwK8J6B4W03xhr/jf4/fEzW/i L8N9N1+LR/hq+mad43i1LTyVP3GKw2DxH+zVcS8U08T+4hRpYHLsZm2MxFeVTldOjh8BgMTXk0pT qOMKNCnVr1qNKZFqdDFYmm1VpYOFCdb2X7ySeKxWDwOFpxjC7c8Ri8fg6MW7U6UcRHE4ipRwlOti Kf6vUV+eY/4Kp/sMW3gH4g/EzxL8WfFnw38KfC7S/hb4i8af8Lk/Z+/aQ+CXiey8HfGrxxb/AA2+ F3xD0nwF8XfhH4K8d+K/hf4v8c3K+G7H4o+EvDeufD21v7e//tPxLYwaZqM1r9RQ/tCfC0fArUv2 kta1HxX4F+EeieDfEXj/AF7V/ip8Mfih8IvFXh7wn4Vi1G41vUvEfwv+KHg3wj8U/D01vbaVd3Vp pOs+C7HWdWtDZ3WkaffW+p6bJdupGVKnWq1U6dLDTdPEVaicKdCooSqOFacrRpTVOEpuM3GShGUr cqbTgnVqUqVNe0q1pzp0aUPfqVZw+r88KUI3lUnD63heeME3H6zh7pe2p83tVFfLnhj9sj4E+J9I +FmstefFXwVF8a/i3cfA34YaT8Yv2cf2jfgT4s8U/Eu28C+J/iU2kQ+CPjT8KPAPjLTNGn8F+DPF Gr2PjbW9C03wLqUujXekaf4kutb8rTZPOvF//BSb9jjwTq1h4b1T4meKNY8X6z4v+OPgDw54E8A/ A74/fFL4ieL/ABp+zb4n8K+Evjh4b8D/AA8+Gnwv8W+NvHGqfD3U/GWi3+rW/hHQNaN14Th8RePN IOo+B/BvjDxDoUtqNR0pNRqqFao6b0qKnh6WDr16jg/e5KFHMcvrVpW5adLH4OpNxhiqDmotSjCU WpRq8vspR1jU5/7QUORrSfO8ozXl5b839mZha/1LE+y+6KK/PHxH/wAFWP2DfDdlod8/xr1XxPF4 g+DXhr9oi0h+GnwX+Pfxc1DT/gV4n1PxroafFvxRpXws+F/jHVPBngDwrrvw+8U6B8UfE3i+z0PS /g5r1rpmifFm48F6p4l8M2msdv4u/wCCiX7Hngn4gaf8ONZ+Ldze6jdz/DKz1Lxp4R+Gvxa+IHwQ 8E6j8aX0tfhJpHxU/aM8B+BPEnwA+D+t/EmHxB4Xv/BeifFT4l+DtW8Q6R4x8D61plncaT428J3u sXGE5VY0IwlKtLEvBRoxi3VljFiJYR4SNNLneJWKhPDOgl7X6xGVHk9pFxSlKMVJylGKhh4Yubk0 lDC1KVCvTxMm3aOHnQxWGrQrO1OVLEUKkZOFam5fa9Ffkx+0R/wWL/Zg+D/ws+Pfj34baX8Xv2gN c/Z2+Ij/AAl+Ieh+A/2ef2p7nwVoXxK0f4r2fwp8aeBde+M3hz9n3xp8OtD8V+E9QlutXl0KTUbu /wBV0uXwpqGnwtofxA8G65q/r/jP/gpJ+zv8MNQ8Ya/8WPFVt8K/hD4M+B3wI+M+u+JPiL4K/aL8 DfFnw1aftCfGfxd8EPAMPj34G+Mv2evD2o+BtA1Pxh4aj02K/wBW8YSeOtH1GXVpfH3ww8B+ENM0 vxp4jzjOE44ecJxlTxbpxw1VSXsa8q2ErY6gqda/spPEYXD1q2GSnfEqKjQ9pOcIy0lCcZ1qcoSV XD1I0a1HlftqdaWYYbKfZSo29qqkcyxmGwU4cnNTxFaFOooybt+hFFfB1l/wUt/Y+v8A4ea18SLf xr8TVtNA+LenfAfUvh5d/sxftSWH7Qw+L+r+D7P4iaZ4CsP2Wb/4MW37Susa3ffDu9T4h2y6P8J7 +1l8A2mreNVuf+EY0PWdVsPob9nj9ob4U/tU/CPwp8dfgjq/iPxB8MPG8d/P4V17xP8ADn4k/CzU NYtNO1G60qe/g8JfFjwj4I8ZQ6ZNeWdwNO1O68Pwafq9qqahpNze2E0F1JooTkqkoxlKNJYeVWSi 2qccXh6GMwsqjStBYnCYnDYrDuVlWw+IoV6fNSq05Szc4L2V5xXtlUdG8l+9VKticNVdLX94qeIw eLoVHG/JWwuJpStOhVjH2uiiipKCiiigAooooAKKKKACvym/ag/YM+Jnxq/bR+EPxi8IeKPh1pv7 OfizRfhro/7bXw98Tf8ACQf8Jf8AEtf2WvibffHH9lZ/Aljp+i3/AIX1SOD4keIvEujfFWPxdqWj G88BtpVhprau0DafH9Y6r+3T+xHoXifxR4J1v9sb9lfR/GfgjRfGniTxp4R1X9oT4Saf4n8I+Hfh xqms6J8Q9e8UaDd+LodV0DRfAWteHPEOkeNNU1W0tLHwtqmg6zp+uT2N3pd9FB6h4M+PXwM+I1r8 P734e/Gf4T+PLP4s+G/EXjL4WXfgz4i+EPFFr8S/CHhC70jT/Fniv4f3Gh6xfReMvDfhe/1/QbLx Frnhx9S0vRLvW9IttSurabUrNJlSajicvzCm1KpgMRHMcHK/PQdWOHzGnRrVKetLEUqcaGOxFKNV To+2y+pWcZPB1OQq60MdgKnuwxtGpgMVTfuVkqVXB4mcac1athsRQrPA1faUZU69J1KF5KFdRn+c evfsC/GHVP2u9R+Ptv4k+GieDrv/AIKM/Cr9ryPTZtY8UL4mX4a+Bv8AgnJqn7IOraI9mng2TSx4 4uPiVexa5p2mrrLaBN4GWTUrnxNaa+F8Mv0HxV/Yl+MPxG+JH/BSLw7HqXw0svgd/wAFCf2Z9L+G UvxAfxX4oX4r/Cb4g6P8GvE/wSiso/hIvw6uPCHjjwbfaXr8fi+Txc3xr8Ja3YX9u/hhfAWoW7r4 mFf48/8ABX39lz9nHxR8Sbn4i+JvBlz8EvBPwD/Z4+Nfhj4zeFfiz8O9R0/4p6h+0H8ZPjJ8JNO8 D+ArLXdW8M+EtaufDcfwf1Pxpeatp/xHv59R8O/8JHJBoVsvhK4uNT9G+On/AAUh+Evwy8Fv45+G sXhP47+GJLL9k7xHpPjXwV8cPgxdeAfEHgj9qz9p/R/2a9F8U6NeeGPF/jf4iS6Z4cuLrW/Gdt4n vfhfY/CvxvDoVx4U8L/E+fxHZeK4fCODo0sTl+FytybwWLqRyOkuf2SeIhlVDg+jh8RiHyvB1adL h6i6U69TDRniMJ9ZlKphMQ41uhV62EzKGKX7vMMrw2UKk+RTdPDvMYcQYCpSpNTp4pVq3E8IVpQj XVOnjVh6ioYnDSlQ+F/Ev7EX/BTv4h6t43+KGseLv2Zfg/8AELUP2cf2WP2dNL8GfAb9on9ojw2f GPg74JfHWf4jfGHR9T/aatPgB4Z+J3wXT46+Ctf8V+F9H8Y/Cr4Z6h4/+DzXFlDouueJ9SY+MbLp v2bf+Caf7Q/wzsPg/deNtc+GtnqPg/8A4Kl+N/26vEWjJ8f/ANoT9ovUdN+Fvi39kzxt8DbLwLB8 cPj14Ng+K3xb+I+h+L/E9gbrxJ8QE0Cz17wxY3GuRXmgXTWPgWy/UXTP2zP2P9a+DXiH9ozRv2rf 2bNW/Z78I6uPD/iz47aZ8dPhff8Awa8Ma8b7SNMGieIfifa+KZfBGi6udS8QaDp403Utctr37dre kWnk+fqVnHNT8S/tu/sX+DPAHg/4r+MP2u/2YPCnwt+IWiaj4l8AfErxL8ffhToXgDxx4c0jWdC8 Oat4g8H+MdU8WWvh3xNoml+IfFHhnQtR1XRdRvbCy1nxFoWl3M8V9q+nwXHdDETw9aVf3Y1frEpy nNJP6xmfEuE49lB7WhjM5y+nmeFwWmEw1Gpj5ZXhsLTzLMZ4rheGp1KDwkIyVCeGrYONKm5NLDYD hbE8FTpwXvXqYDIsfUweJxb5sdVmsFLNMTifqGXQw3xV+2B+wL8Yf2gfjl8V/ib4N8SfDTTNB8df D3/gnJ4T0i08Tax4ostXttR/ZB/b08U/tR/EqfUbfSvButWcNlrnw/1u00fwNJbX95PqXjGO40/X 7bwzoqR+IJcL44/sHftD6/8AF743/HP4Y3vwX17xDrH7an7HX7Vvwq8C+PPHfjjwJo3iTSv2ePgl o3wl8YeDfiD438P/AAl+JV98PdQ1a6/tnWvDWr+HPA3xRtrm3stMstUstJk1a7uNF+6tS/bW/Zc/ sr4zz+Cvjx8E/ir4r+AvwtvvjD8SPht8Pvjp8DZ/G/hzwPB4WTxhpes+JE8U/Enwr4W+H+ieJdEu NPvND8ZfFHxR4E+H32LVdP1nWPF+keHppNYhvS/tm/snad448IfCjxN+0p+z/wCDfjP451DQ9C8O fBPxR8cvhFZfFnUvFniDQPC/ifTfBmm+C7Txtf6lr3imfQ/GvhHU7fTPDQ1sajpvibw9qukT6jpO vaPf32OGpzofUsPh1ONTCZtSz3BR5U6s8fiM7y/OKNWjCcX9aprNeGMNenThVp01Rnh6ySxMIz3q 1ITnmGIrKE4ZjgMRl+YJyapfUaGQYDh3FU6sqcoywqeU4rB05VXUo1HUxCr0ZqesPy98Z/8ABMH4 g61+1h8X/iJr3gDwv8bvgR+0V8d/g7+0D4x0PWf+ClP7e/7M8Hws8U+D/Dnwp8O+JNMj/ZZ+C3gX xR+zP+09H4d1j4R6D8SPAniL4jH4T614i1Ge08CeNRBpXhnR/Fbez+IP2BvjDq37C/7Uv7Mlv4k+ GqePfjd+1r8dPjz4U1efWPFC+EdP8IfE79s68/aK0HTfEN/H4Nk1m08SWngm4TS9Xs9N0DVtLt/F IaystY1DSQNcb7lH7Y/7IjfG0/s0L+1T+zg37Ry6gdJP7P4+OPwxPxtGqjRf+ElOmH4VDxR/wnY1 AeHP+J+bI6D9pGi/8TUx/Yf39e2eMPGPhH4e+FfEXjvx/wCKvDngfwR4Q0bUfEfi3xl4w1zTPDPh Xwv4e0i1kvtW17xF4h1q6stI0TRtLsoZrzUdU1O8trGytYpLi5niijZwqM4YbBYd0uSngKGWzy/C zUnHC08rhHJfZUqcuZUJrC4bIcrorGy58ZXoUVPH4rF1Ze2FVhPEYipSq89TFzzKhmeIg4p4qrma pZ3hZYislH23PiqmeZpUnh1y4aOIqWwlDDxpukfif8ev+Cf37Z/xm/bS8NfFzVPiF4V8S/BnwR+2 V+zp+0R4D1HxD+17+1P4Zj8E/Bv4SWHgN/EfwI039hrwb8PY/wBlPxD4sm8Yab478c6J+0F448Ze JvH+py67Z+Gryz8O2selax4T6I/sE/tY63+zp+1P/wAE/tZ1v9nrw9+yt8YV/bHvPA3x90jxb8Uf Ef7Qrt+01458a/E7wf4c8UfBP/hAvA3gPwkfhx40+JOsReI/Hnh74+eL7nx14Z8I6ZYaL4E+Hmte MLjX/BH6RP8Atj/siRfCXw/8fZP2qf2cI/gT4svdc0zwr8an+OPwxT4S+JdS8MWXifUvEun+H/iO 3igeDtZvfD2neCfGd/rlpp2s3M+k2XhHxPdX8dvBoGqyWkWt/tmfsg+G/hb4I+OOv/tVfs26L8GP idq6eHvhn8XNX+Ofww0z4YfEbxDLJqkMOgeBfH974oh8KeLdZmn0PWYItM8P6rqN88ukapGkDPp9 2sWMqMKGXYjLKntPqlNYvDYqnNSlVeKzjAZLlyqVeWPtHmlWhw9l86NVJYvMMZ9exeN/tDF5nmFX FaPESljaOYxnCGJpTw2Nw9WLjyU6eSYvO8TUdOMnKn9Ro188zSlXotPCYCh9XweDhgMNl2Bo4b5S /YF/ZD8dfAvxh49+Jnxm+EHhrwh8Vtf+H3gT4bx/EXSv+Clf7dn/AAUF1Txd4Z8Pan4h16/0J7P9 tLwD4Qn+DfhvSvEWqSa54f0TwZrXjM6lP4g1eHV7+0bSre71yH9r39gXxh+1P8Tv2hdVHjfw14N8 DfG3/gnd4s/Y/sNVMOqaz4s8N/EPXviVqnjXTfFt34X+w6fo+r+DNOtrqyN9bQ+MtN1zUp4brTLe HTI5otbh+s/2Q/2hx+1V+zJ8IP2jT4Q/4QIfFbweniw+Dv8AhIF8T/2AGvb6zNh/wkT6N4aTU8Cy 8z7W+jaWv7za0KhDI3A2f/BQv9jnT/A3wz8afFX9o39n/wCANx8V/DHhDxb4U8IfGH9pD9m3TfEF 5pPj+bxFb+CpbDVvB3xf8a/D7xZB4rm8I+KYvDWr/D/xx4w8O+I5PDmvR6DrOpSaLqiWnXiVUrYu lGTlSxOAeOwNClh5ezVGvxFl3EGU4qGEowbpxq4uGZZ3iIUsHFUqeOqSxMKUJSgp44dRwlHEukkq FSWV4uvOqlU5YZHj8lx+BlXr1FKpUp0K+TZXSnVxlSrUnh4LDTquk4Rh8DfGD9hX9tT9rHWIfij8 cov2WfhN8RvCfhv9l/4b+DvA3wn+J3xQ+Kfg7XPDvwz/AG1vgF+1X8ZfiD4o+Jfi34A/CbxRo+r6 9pPwS0/wr8LvhPY/D7xJpHh/UzqN/wCIPitqEXi2V/Cf65fHjwjdeP8A4M/E3wNZ/DX4b/GSTxj4 M13wxL8K/jB4n1HwZ8MPH9jrtlJpmpeFvHPinSPh78WNT0Tw7q2n3N1bX99ZfDjxhcJG+1NGn374 /BPhl/wUI/ZL+Lf7Tfx4/ZE8HfGT4f3Xxy/Z6bSh4y8Iv8Q/hpPqmri40VtY8UyeFNA0vxrqXi+/ j+F0wj0D4qNqvhrRB4J8STwaVqO5pVlr0Hwd+2Z+x/8AET4e+Ifi38P/ANq39mzx18KfCXibSPBX iv4m+Dvjp8L/ABP8PfDPjLxBf6NpWg+EvEPjTRPFN94b0XxNreqeI/D2m6RoOpalbarqV/r2jWdl aTXGqWMc+FWVOtlk8DajHLqs8wzVRjCjOh/xkOIhDHYqKqxq0Z4XH5lGpOnCcZ4KOKr1cHhaVPCx o4OjphozwuMhVpe1WLhiMDhY+/WjXVfKsBhMJgMJF05wrwxGEyvA4OjHklHGzpYeOLr1auKqVsVU /NXQf2F/2z/D3wT+CtxbeIvhfr/xZ/Zv/bfg/ae+CfwI+KP7Uf7RXxr+Gvhb4SP8IvFvwQ1D4A6j +2t8Ufg/4h/aL8UMum/EXx78U/DPjrxd8D/ET+E9e1TSPhLY+HbnwB4e0zW4flLw/wDA/wDbg/Zp /bU/ZBj0zTP2VPiX+0L8Rm/4K+ftA+JPBt/8Q/i78N/g1d+F/jd8XP2OfFlz4U0T4pW/wm+JXjfw tr/gy+1exlg1q/8Ag54307xbaeHrvSZNK8JTeLYde8F/up43/bA/Zt8E/sweLP2yG+Mfw28V/s4+ FPBGvePB8VvBfxC8B674F8T6VoU13p4svCPjk+JrTwJrWr614itP+EP0C2Hii2ttR8X3Nr4f+2Q3 02xeD8Of8FFv2G9d/Z5+HH7U+p/tYfs6eBfgb8Un03TfDPxA+IHx2+EHhjwsPGV7o8ms3vw0vfFd x43m8ID4leHIbbUrTxN4N0/xDqGq6Pf6PrFvNG66fPKutJzhmGJxCnV9vgcNVy/MITqVJYqlR4hy bBcN04VsRXlUxLxOPrcL5TUxGKxUsTjcTjMFiP39DHZxWxdXKVOnOjgU4QlRrVsXiMB7KMadCrLA TzzMKkcPDDKnRp0cshxtm1fDUMLGhSoYfF0FyVMLl2HpUPxF+GX7M/7a/wAEP2j/AIr/ALNPwQP7 KnxG+KPiL/glh8K9I+NGs/FXxD8Sfhn8OPDHxF+Pv7VP7f3j7WvG/wAL7Twj8MPileeNPAnw+8ce OfFWk6X8H/FfhzwHefEDwi/h+a7+K3w9vtH1LTvEP03b/wDBML9pX4efCf43/sT/AAv8R/ArxB+y j+0rcfA+48Z/HL4g+KfG2lftB/Cyx8A/Bn4G/BD4kaJ4X+Bej/CfxH8M/infeL/DfwE0zV/AnjDU /jl8JH+HniDx3eXOpeFPHEfgKwXxp+wnj79pf9nH4VeIPhj4S+KH7QHwS+G/ir42ahb6R8GfDPj7 4reBPB/iD4uard3mkafa6Z8MdF8Q69p2pePdQub/AMQaDY29l4VttWuZrzW9Ito4mm1KzSb58/Zs /wCCg3wH+P3izxZ8KdW8efCP4b/HzRPjR+0v8MvD37P+o/Gjwbq3xf8AGnhH9nL4x/Eb4T3XxW0b 4f3K+HfGcvhzxJF8Nta8S3C2PhzU9M8NRwappkniPWF0W71SR4Wf1WpWdCMKdWpRzOWYpLlw+Lyz LuKcTxHUyucJtqlhMnzPPKdTEUaNWOYTp+0+t15ZVS+p4QxlsQo4rETcsO8TlMMvk3FywmZ4rhTB 5DDMYyglCrXzbL+Fa/sa1eg8uor/AGXDUo4yvKvjvn3xD+wL8X9W/YP/AGt/2ZrbxN8Nk+JHxp/a a/aS/aA+HmoT6t4nTwQtn8Rv2tda/aR+HXhjxnrMfhCXXvD11eaVJpPhfxrqmh+FPGEXhXULrUdQ 0Ky8cW2m21vq3K/tGfsIftK/tH/EXxr8WdTm+BvgPXfiJ8Jf+Ca3hnVvCFj8RvH3jHSfDfjD9kX9 u3xN+1L8XLPTvF1x8F/CF54j8Naj4I1y30L4c+ILnwh4b1TxF4qhmt/E3hbwNpGzV2/Rf4V/tcfs o/HXxVrHgX4I/tOfs9fGPxv4e8N6d4y1/wAHfCv40fDf4heKtD8IaxDpdzpHivWPD3hHxLq+r6Z4 b1S31zRZ9O1y9s4NLvodY0uW2upU1C0abwH4k/8ABSD9m+x+BviD43fs5/FL4I/tcaZ4S+M/7Ovw Z8V2HwU+O3gPxdY+GNW/aB+O3w6+C9pP4h8QeBZPH1vouo+H7fx7N4ut/D+pWNtc+IodCl0mK70p LxtYsJw8ZU8XkM6Sc8Rl2I4chk6abjGpQnHhzKZStaM6OLxNfD4OtiMQ/q/1ijBqrh0sS6l137SO a06vurMcwxeIzJfDKWOxGcUOKp0mnd0Z0sZgpYilQgoTeFnXhONWCpSo/j1/wU7+HvxI/Zz/AGmv D/x/T9oP4e/s5Q/Hr9tTwv8AEX4WfGXxb8Z/A/7PPw88AJ8Mv+CdXjv4IeIfDvxk+P3x0/Zd/ap+ Dvw28ReOLufXk+G/hK9+Afxhl+JdrFcW2map8Ptd0uXXNG/YT/glr4o8P+Kv2F/ghceFfA2p+BfD uiW/jPwhpZvviKPjDp3xCj8IeP8AxR4euvjb4R+L/wDwiXw+PxY8CfHTUNPu/i54M+Ji/DzwDZ+O vD3jGx8TaR4Q0TRNS022r6Utf2m/2bb742ah+zTZftB/A+8/aN0rTxq2qfAC1+LHgO4+Nmm6U2jW fiJdT1D4VRa+/jqz09vD+oWGui9uNBjtjo19Z6oJPsVzDO/nelft9fsJ674q8YeBdD/bU/ZK1nxv 8PDqK+P/AAdpX7R3wd1HxV4GbR/Edh4P1dfGHh608ZTav4ZOleLdV0zwtqI1qzsjY+I9SsNEufK1 O8t7WRYT3KNSgv8AaFjKeFxGBa1dPBZVgaOXynQ5VKVejGFCUq9aEo0IznN1YSqRhUgYr35YWq/3 DwUIYLESltVji6uJxuFoVL8qpSnPGxrYWMuapKLm6LUMVV5vrSiuatPGng6/8W634BsPFnhq98de GdE8P+JvEngq013S7nxb4f8ADfiy716w8K+INb8OQ3T6xpWieJb7wr4nsvD+q39nb2Gs3fhzXrbT ri5m0fUEt+lo8+jvZ97Np/c00+zTW6B6SlF6Sjy80X8UeenCrDmW656VSnUjf4qc4TV4yi2UUUUA FFFFABRRRQB+CHhL/gn98S7eb9ny48QfATwfLceGf+C4f7Wf7cPxGnu5/hZfTD4V+M/+Gvf+FO/G bU5RrNw+veIv+Ku+BP8AYthbNqXxI8LfZvDX2zRdG/4Qu5/sLE8D/s2/tgfs4/FP4UfHnQP2ZPEX xpj8D/H7/gr/AKRJ8JfAvxS+BfhnxRp/w9/bV/ac0L40fAr4o2uofEb4leEPAkHgGay+HdmvjfQL HxJN8TvC8Xj2z1Cz+G+v6tpWvaBB/QVRWVKlGjSoUoOXLh8FWwFNuzaw+IyDIOGcRdW5PaVsm4ew 2FdRRUqf1vHToeym8G8HeJn9arzxFWMeepmFTMnGPNGP1ieY8aZokvecvZU8Xx1msoQcm3DC5bGp KfssY8b/ACyeEP8AgnB+2ppX7MXxD8Dax8HrCHx5N/wTV/Y1+EGneHtN+JXw3v7fxF8afgL+2F+0 J8cvHvwy8Pa3deJtL08X0/g3xP4VXwx4q8Vnwj4E1XU/E2m2mpeJtDNj4lbw/wDUP7Zv7In7Qv7W PxD+LnjuD9m/VIPBnxn+A3/BKzwtqHw3+KHij4EXuqQ3vwM/4KKeM/jr+0F8PfHOlaN8T/GXgjUZ fBXwc1231jXP7L8ReJvBnjFLqfw54J13xjrAm0uv36orpjUccZlmN5YuplOa1M3wkGn7JYitmOcZ nWp1Ump1MPUr5zWg4uaqRo4XCRhVhNYqpis6idSOYRlOSeZU8np4qpG0Zv8AsOHDUMDOnZctOduF 8HKs4x5ZyxeP5YwUsGsF+CXxX/ZI/aQ8Lftn+P8A9q/wb+z/AHnxf+Hvgz9uT4N/tD6F8G/CfjL4 N6B4s+MHh9P+Cf2qfss+JvHvgC0+JHj7wX8O7D4jfCz4g+IbHWILP4seKfhlda54e8OazeeF/FLX 8Hhyx8QL+zz+w98bIP2yPhT+0z8S/gD4d8EeDNX8X/8ABTb4zjwFqfiD4a+KtZ/Zy1z9qdv2SdA+ H/h7WV0XxN4i0Nvip8TdK+Gvxm8bfFDUfgzqfjPwFoXiTx9448PSePtestci13xV+9lFcaw1NQqx bnJ1MnzLIlNtJ0stzXI8qyHF0acIxjSdT6vk2AxVLEVadWvTxVFU1UeXqGAhVV+1+rJpQWFrYbER UNPa1sJLPXQnVb5pWjDiPNacqdOVOlUVaM505VourL+YGT/gmz+1Bof7EH7K/wAF/BnwI0jQPG/g X/gjZ/wUV/Zc+JXhTQPFnwk0O2tP2i/2ifCHwBufBPgy+v7PxdZ+H9dufH3j/wAKeONY1Txhp+oa n4PtNet7vxB4s8TadPq1nf3/ALt43/YH+OureCf+Cg9xpfwW0Sf4jfHL9pT/AIJq+OvhhrK678Mo PEPinwT+zF4I/YytvFWonxHN4jin0aL4ZeKfh78ZJ9A0zxFqOk6i1/Bq+p+DLG+HinTrrWv6CKK9 BYmosZiMclH22JblJWlyU5f644vjdSpLm54Sjm+Mq0Ytzk1gI06f+8qWLlNSKqwwkJJKOE/tFRUU l7ZZnh8nw2IVdO6qKNPJMG6SSjaUq/P7SMqUaX8s/wDwT78Z+JYv2o/gH4x+L+n+MLr4J+Pf2o/+ CmuhfsT/ABT8B/BT4S6V4E+JXxI+Onxk+M3xW8bR/ED4s2X7XvxA/aJ8Z6Vb+AfhR42Xw6/ir9iH 9mjw3HrGh2l54z8R+Kn0DwNr+t/uR+35oPx88Sfs26vp37NvhWPxh8SofiJ8FtZbSrDR/gtrvj2y 8IeHfi74L1/xr4o+C9h+0heWH7P6fHfwV4b02/8AF/wb1L4xXB8C6L8QNE0LWNTtr2extLOf0fwd +yX+yh8Lfil4t+P3w6/Zi/Z78AfG/wAZ/wDCR3Xjf4y+B/gt8NvCvxY8YSeKdRj13xXJ4n+ImheG 9P8AF3iCXxNrFvDq2vvq+s3TazqkMN/qTXF1Gky7v7N3x58IftRfAT4RftE+ANN8SaP4J+NHgLw7 8RPC+l+MLPS9P8U2GieJrCLUbC11+y0XWPEGk2uqQwSqt3Bp2t6raRyhlhvrhAHPHTp8+AwGFU6i qZLDKY1atKVqlNLFYjF5fTrYhr2mKnXqZbjoPFqGFnPDUlh6eHw0sLDE19JTtj8wxcYQdPMK+OxM qdSPNF4rGzrzxmIpUk1TwlN/WaNSlgoyxKoYuFfFfW6tPFQwmD/C79n39hb9qW8s/gtq3xu+EfjT W7nTf+C1XjD9t/xU3x88Q/sk658TLT4Q3v7IvjXwf4K+KvxD079nOTRvgT/wsfSvi9feF7e78PfB /Q7m88P+LLaPxHocWs6Tpf8Awnt7ueC/2WP2qv2df2gLD4+WP7I2qftCeFbf4s/8FWfDOlfB/wAI fET9nrQNY8K+Gf2w/j18K/ix8LPjHYr8T/iX4M8D23gXxhpHw78ReHPihpllrd98U/D1r4vsLq0+ F/iKS58UabH/AEQ0VShCLo8sIRhRyXEZDCioR9h9RxfD/C3C+JvRt7P21XJuE8FhvaKKVJ43MalC FKUsC8BFRyqycqkpym8wp5o58841Xi6Ob8X55Rmq0Wq0VTzHjTMqnuzjKrSwmAoV5VaX9oQzD4R/ 4JtfBL4h/s7/ALAX7M/wJ+KXhTSvBHxG+GvwptPCXijwfoWs6Rr2ieH9VtLvUyulaPrWiFdI1DSr eCa3XT7m0jtY2tDCJbOwmWWzg/IP4Kf8E2f2jNE/Z7+Jvhb4gfALQJPiJq3/AAQW+Ff7DnhVNU8R fCPXNR/4Xvp+oftRal47+EVprkPinULXTdMuL3xb8JL7VfEEuo2nw51u7XRrhfEd/P4Yun0j9+/g V8fPB37QWlfEbV/Bmm+JdMtvhj8bPiv8B9fTxPZ6XZT3fi/4O+K7vwf4m1LSF0rWdajuPDd9qdlL PoV5ey6fqd1YtHLqGj6ZcFrVPb6jG0lmUMfiKs6kY8R5fRxLrUpNSeDzbh/iPB4bFYSdRVJx+s5V xrjcTTnVdVymsDOacIYilidsHXnl7VClGDll2PwdKpCpBLkxnDXEWV5k8PUjS9lBezzTh2jhcVCn GEfY/WadF0pypVqX4CeK/wBjP9qrxf4R/wCCjXwGj8Aa5oM37av7C3wT8E+AvjxL41+GNz8OPDHx T+Hv7OF58GfFHws+JtunjjUPi3a65r3iO4a4/wCEi8NfCH4ifDS58HXl5eaj4mvNVD+ErzxTU/2C /jz8b/g78Xrjx38H/wBt/XPix42m/wCCc3wz8ReBP20df/4JMr8LPFHwR/Z9/bH8I/GLxhoPgPRf 2Dj4X8L67pPwz8HS/EyW5f426Fo+s6/4X1618L+BdE1K91DUPDtn/TNRXfUxc6uc188nCk8ZWzPB Ztycr+rUcXgM0zHMqTo0eb3YTp5niMrqc0p1FlijCjUpYurisZiOClhoUcswGU05VFhcvpU6NGXM vbTp045JJRrzUUqieKyDAY9xUYxjjVKrBQhTwtPDeMftFeANa+KP7PPx1+FvhU6fD4i+IvwY+J3g Dw4dSmez0qLWvF3gfXPDujm/uIILmS009L7ULf7VNDa3DwWwkkjglZBG34b/ABD/AGb/ANtLXLH/ AIJ1fG7w38Kf2xfhhrf7P37KfxP/AGVfir8IfgR4k/4Je67+0Z4W13xFafBO1tviBoj/ALWviP41 /sm678LPGlv8HdW0rxBL4U+JXhT40Wumaz4EE+m3OmXHjnwton9F9FefGjCNXFVrylLFrBKrGVpU 7YLAcT5Xy8jXLOGKy/i/OsLi6db2tOpCrRnCFKrRVR9kp81LC0eWChhPrvsuWPLK2Or5Fi5rmTUq bo4zhzKMTQnQdKpGWHnRqTq4TEYjD1PwI+Cf7KfxX/ZJ8e+HtL8IfsZfFj9qv4LfFf8AYg/ZJ/Zi 0a3+N3xM/ZAj8Z/s5n4LeN/ixqPiLwF+1Er+NrTwfqHw9Ok/F3RddvLr9krwl8ctGj1T4e63o/h/ 4balDb+DNT8Qa/g79hj40+G9L+EV9afBzRNH8WaR/wAFr/2p/wBsbxzqun6z8N7bWJPgl8Tte/am 0vwv8UNS1ey19Z9Zv/EHw+8cfDPQJ9Biur7x7aeHLmw8O6xoFnaaDf2Gl/vBRV4qCxk/aVnL2rr1 606kHyucK/FeWcYPDuCXslh4ZllWHoWhTjUrYOpiXi6uIx9VY+GMoKWGxGEbkqWJoUqNTW9ROlwd mvBDrRqSUpe2q5Tm+Irz53OlHHUcNOjSpYOFTBVf5grz/gll+0rrX7FH7Dn7PnhT4Z+EfhR488D/ APBNH9tn9nD4xXh8ReBdN0Hwp8Xfj/4I+Ek2neGPFmoeB9V1a88S6J8SPiD4e8U3XjbxF4KsPHOm fbH1HxNrsepXV7apqvqvx2/Zj/au/ax8SwfGDRf2Nde/ZiPhD4efsRfBj/hVfjz4kfs53njz4gp8 KP8AgoF8Af2j/F3iGwuPgt8YviH8K7b4RfAT4Z+AvHI+HB8R+MdC+JHiLVfHHjvStF+GOgo2lR+L /wCiiiutYmos2w+ctReJwmaLOMLTtKOHo4x4zP8AF1bU4SjOrSrLiXM8NKniKlZUaM41MK8PjJYj FV6rL2+FeEnpTm37Wcf4taP1zIseozlLmSSxfDmV1nKlGnUn7KdKrOpRlGnD+dDV/wBnf9ovwN8P dO+Cfiz4AnwZ4a/Z4/b8+NX/AAUC8R/t9a58QvhV/wAKs1j4YS/FL4w/H661nw1o3hDx1rv7U0fx z8S+BviEnwJ8eaX4q+B9h4SsPDJ+I13afE3xjo1t4V0rxl85f8E3PhbffGD4f+E/2X/2v/DPjzwt r37Rf/BIjRPgb+z5qWlfA/4LfDH4ZeL/ANl7wRaeHI/GPxA/t74W/tl/tXeN/E/xHsvEHx2+HviD w74p+K/g39lJLe21Ce98N/Bvw54w13xlpWm/1dsqsrKyhlYFWVgCrKRgqwOQQQSCCMEcGvnf4M/s g/smfs5T+LLr9nr9l79nb4D3Pjy2tLLxzcfBn4KfDX4Xz+M7Owe+ksbTxZN4I8M6HJ4itrKTU9Se 0g1hryK2fUL5oURrucyedhqH1fD5hhNZ0MZgoQU41Z0cU8dHhDNuDp4r2tNKGCq1suxOWUlWy6lh 6WGweHzbB0MDbNqdbL969adSvQxlKXscVSxkK8v3cKtB0Y8UYfiylT5Kqk60MLmsszxaoY3608Xi sTl9WeJwyytwx358/wDBFmy+LXxB/Z38W/tf/tD/ANmXPxy/al8VaLBrOoaTdrqGmP8ADz9nPwpp n7PfgSTQr+PMV34Y8ba54G+IPxy0G4hZ4biL4zXF3GxW5r9j65rwb4L8HfDnwp4e8B/D3wn4Z8Ce B/CWk2eg+FPBng3QdL8L+FPDOh6dCtvp+i+HvDuiWtjpGi6TYW6JBZ6dptnbWdrCqxQQoihR0tej iq/1is6lo2jToUIyVKnRlUhhqFPDQrVqdL939ZrwpRrYqUNKmJnVqfbOPD0IYen7KnH2dP2lepTo qc6lPDQrV6laGEoTqXq/VcJGosNhI1ZTqQw1KlCpUqTjKciiiiuc2CiiigAooooAKKKKACiiigAo oooAKKKKAK14rNaXSqpZmtp1VVBLMxiYBVAySSSAABkngV/JT8Fv2TPiH+yX+zn+w38XPgj+xP8A Em9+Puq/8Esv2wPDH7UWgaNovxa+G/xS+KHjyL4ffBDXPhh8Kfjh8SPDlvb/ABX0bxVp+v6TrOjf BbQrjVbLx34KsNFm8CfBCDw7b6XYaPZf1v0Vj7FRePnBqNXHYalhXUaknTpQy7iTLatNSpzp1JUs TS4jrPEU41KaqLC0oOVpya3o1vZVMO5wVWlRxWHxUqEm1Tq1MNiMPiaLktUpU6mHTpVOVypSk5wt JJn8eHgP9mP4leLfgJ/wUK+GHh39nnxBoXwX+Kn7Qn/BJXX/AAV4J+AX/BPn9qH/AIJt/DTxLFo/ 7SngW2/aR8Z/DT9mb4keMfFPxT8I6/4b8K+EdOk+MPxW06/8K6vf6R4Q0Xx9eWml+HbLw74o1L6C +KP7JGg/Bj4xfFL4fR/seeML7/gmN4f/AOCiXwL+JvxJ/Zm+Dv7NHjT4h/CHxf4C8QfsAX/he48V +Gv2aPhj4J8Rp8Zfhh4a/atg+GHiP4neCvhz8PPGenWHj3RLXx9r3h5bzwfr+o2/9RtFdDk4zqVK ahz1sZgsXWdWEZ+1jgv9TpUsNUdNUJOjTq8H4ethpKSrYWtjKlelVWJoUq75KFP2WGlhqk6lVPDZ vQp1VJU6tCtnGDzDBV8fQ92dOjjVSx8pSqU6caNWVNU3QhhpfV4/yS/BH4BeD/DN38PNT/at/YT+ Pvin/gntL8bf+CkmueDP2ZvF/wCx98Xv2kYPh58Q/iT8aPhx4n/Zi+IXj79kfwT4J+LnjGPSn+A9 t8U/Cnwq8aXvw98SaF8GTrWp+CZ734a6n4ngsdR1NK/ZJ/a+8OeGP2c/2frn4Q/GFvh3/wAFG/hb 4K+BH7VcusTah451D9m74Rfs5/tDa/4+8K6V8cPHOmza1pul+K/iH/wT+8d6r+y5c63rWv3S3vjX 4deEPCx1bWdWNo1//WNRTwslhaWSUFz1qWSRyWkoYifPHOsPk+DzHCKnxHyxg82nWhmdanSq3wzw OFw+Dw2FjD2VariKqqVSpm1aLjQrZtPM8Qp0Iun/AGTjMdmFDMqFbI0pf8J1LC4vC0MRWw6dWOY4 iWLq4uclja8Jfyzfsqfsx/FzRv27P+Ej+Kt5J8Lf2hvD/wC2B+07448T/ELw9/wSt/a41fx9+0H8 DfEM/wAVf+Fa/C/xz/wVU0r4ta/+yhr/AOzxqHwc1n4b3Hgf4W654L8LWfwz8RfDv4dfDfTPAnhn 4o+BtMef9SP+CNf7Lng/9mb9gH9m62i+CEHwc+NHjf4LfDLU/wBoGXX/AAde+Gvi94m8eaZoMkSW 3xZ1DxJaQ+O9R1LwdFf3fh7wzoPiu5kh8AeHI7Xwd4X07QfDem2Gj2v6o0VGDbweB+pQbaeDyXBO o3eUaOS0MVQhSpSnz1qeExPtqGIqYD28sFQxmGeJwlChPEVkytGNbF18U4xSrV6mIjSSShSq1MRj 68XGEOShzYeOZYvDYeuqEcWsJVeHxGJxEIw5SiiigoKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigDg/ihfeJ9M+HvjC/8GRXUvie00G+m0j+z7BNW1KKdIj5l1pWkSW93Hq+rWdv513pWkSW l3HqmowW1g9rcLcGF/kn4R23xSHinX7218V/GmXwKLv4j+N5bjxP8LvDfg/xX8S9Xjs/AWmeHrPW 7XxN8KPC7aC5txriabpmh+G/B91qk2mWl3NLNaWuo/2l95UVmoSjWqVozlGU8FicHFbxj9Y5ZKrK MrqcqFelh69OFo05VKMXWjV5aXsbclKlClKKcY4uhim9pN0G4umpJJxjWo1MRQqS1moVn7KVP96q 35n+FdF+MPx10X4dp8TLv4o6bD4b/aCub6zm174f+GJNSg0S2+CGoa5o2v6zb/EH9mD4Y6dI3hr4 gPc6LouvRfC/StMtNZ1Fre01fxFrFh4b8QWfYQT/AB5uP2dvAy3WufFfTX0NfhVe+I/Hljbate/t C3+oWXjvw5ZfEPQdV+E2ofs/Mb/w/oWmSa/cWWtadceJdX8aaVoGmXOq2vizRte1qfWf0AorfmUa nNCEYwdfL8S6Wrg62AjGKcndTccQ4xeIXMpVPZ04ylKHtI1coxfuc8pTcISpc2il7KdbEVnFXTjz L6w4QlOM4U1zSp041HTnS+OYfFHxh8G+FPD/AIt8Ua18SvFP9v8AjX4kWms6NZfCmHWdS8MaQll4 1s/hxaWXhbwH8PpPFy6M97pnhu6vtd1aHVJJr7UIru+vrHw9e/Y7bzbVvGH7TGi+FNQ8Yah4n8a2 15fQX3h2Dw9dfDrw1baXoMzfDXwzqeleJLb7N8PNU8UXPibUPiFd6loOnKYvFGkXV3dR+HtJ+Gni nxDbWmlah+h9ZWuaDofifSNQ8P8AiXRtK8Q6Dq1u9nqmia5p1nq2kalaSEF7XUNNv4bizvLdyAXg uIZImIGVOBWKjKKxbUnKdfCQwtFTfuYd02nGvBWl/tE0506te3PODhK3taftJ6Jxf1SMlaNDFSxN ZwT5sRzq06Mry/3eLUJ0qDk4wkqkLulU5IfG/hrxh+0BffA2/wBU8P6xD458SvaeN1v/ABbrNrqe lfEPwZ4ns9WvrXQ/Cmn/AAluP2dfhnH4s/sa2j06LUdQ8TaH8OtR1JprvV7bw9Jp02mQvynirxV+ 1H4X8Y+H/Dmn6v4v1zwxpvjPVtMTxhrHgi6lvPGMP27wldWUPi+L4W/s1/ETTo/DdvY6lrNjb6np dj8FbS5WF2l+IVzfaXqMlv8Adnhvwx4a8G6LZeG/CHh7Q/Cvh3TVmXTtB8N6TYaHotgtxPLdTrZa Xplva2Nqs91PNczCCCMSTzSzPukkdjuVteMcVTrJOVKFN05UJq1Or79OSnKKb5J04RqU6bi3NqpG WJqYqpCU6uTjKVCpSb5ZzqyqxrQb9pTTjWXIpP4oylUpzqRtGjF03HCUcHCVONH80/8AhJv2mPCu v6Noel+Ivipr+kRfFP4mW+rar438BeIZkuyPiUn/AAjWjS3ngr9l34gPqHw3ufAdxaaxYaxp1/8A DvRob3WdT0rSPijY6f4bTwv4V62bXvj7qvi3wxfaprnxf0nR9F+MC22h6Xovw2i0bQ/GXw61PR/i hbeEtW+JV5Z+AfHes6d/a3iWy0Pw142VtL8PWngrw1N4f8fX/hfwzrGq6VrOl/f9FZwTjToQbcpU ZNyqu3PNSqUamqalFul7OpSo+1jWpqjV5a1LEVYutO5+/PESS5VXTtBN8lNuOIpySs4yUJxrxqVF TlTn9YpQnSqUqSjh4/Kuq698fJvF9r4Y1Xw9b6dpmueHbvxdqdz4YT/hO/COhwaFo/irSNV8A2/i nWfAnhaTU7/xLrc/w61uxttX8OWur3Vpf+NrLSjNp+hx3CeTjTfje/wf1TWb/wAb/F/wXJofjD4K 2GjeD/h18M/CNje+H/AukN8NW8XyeH/DGnfCrXPFGuIq6j4onvtJs7TUdJ+yaDD4ah8OvpNtr2l6 z+gVFOl+6q1a1lJ1HhZqnLmlShUwmPeLpyjGUpO0qFsFOPNb2bq1ouNatUkyp+8VCLvFUKk3eHLG dSlVw8KVSlKSik714yxKqOMp3dOjJyo4ejCP5+eL/iv8cYtG1PTtL0/4xJrOgRa/pet6po3ws1jS lXVm+K9tZeG9W0rWLn9nr4vWfibR2+H/AJktxL4C+HnjgmznW4v4NKvkutX0zrvh7e/HC9tL3xNe +BbG91vxd8Jfg6/jifxlca74MvbXVo/CviWTxENC8Nj4aavaeJfENnqV6yaj4Q1KDwVb21xNb2V2 2nLdC1t/tWispUufBVsJKUnKtKbeIf8AFhGpLETnSi91SviHCCUlUhRpUaaqN0qc43Tm6eKo4lRj y0o017DX2cpUoUIQqO7leo1RU6rnzxqV6lWo4pVJwl+cV7B+0lL8N9ajsPEXxN8OG48HeJ/DGheE PCHw58IeHU8KwaB8EtG8R6BfeHfsfw+fxDYazqPjm3v/AAjZG11CHS7e2vX0Lw5o2neJtP07V7RF 8d/tQSa54/07SdU8dTabF4HvH8BXviD4X+Ik1O5jHh7QJPDfiuTR1/Zl8OeE4vHt/qMt3e+JfDWs fF8+S9zqOkx/CTwtf2C2em/o9RXROftK06sl7s8KsPKmm1ep7LkninNWqfWZVP3qqKScXUrJ80nQ nh8IQ5KVOnGXvU8ROvGo0m+SVWlKOG5JJw+rxp0/Z+ztZ2jLSLr08R+fPxT8IfETwL448afEXRtc +LXjXxPYfC74Q+C/Dni2y8FfD+81izOp+N/Gj+Mp7PUPCv7MXxS1aKGK30zStS8UaX4U+HWvhh4i t5tR0ezsIPDWp+FmXPxD/aIuPDlleT3PxU0X4gSfBHwdrfhrwppnweuLvwP4m8Xal4S1K48c33j7 xO3wf8TXvhPxZ4d1WG4uNJ8I/bPBV1NqFjotjF8P/FT6wnh3VP0JorJKXsqtPm/iVZ1Kc1FRlQjU pYhSpUlG0eR4nESxTvF+/ZR5ZQo1KOt17SNTl0VGnSnBtyVWVJYeEKlSUr1HL2GHjRbU1Npt8+tS NT4XtfFH7SesfAfVbj+yZNVu2ttfTU/E51D4heGvjLbaNbanE9xD4f8AAeofsz/Be48QeJJNCOpW 2lano/h7wBciUadN4c0/XtZhju9RzdP1vW/D918OL20v/wBpibwWPjbrknhnRNS8FfHTxPqM3w2m 8JQadd3nxOuNY8Iav8TI7Sx8eXWq/wDCNad8UNZt4ZtJ1CPWLbSr/SdB8P6j4e++qK1jJRxFOuoq 0IYeEqf2avsMRRxDnUVuSVW9BUaU3BulQxGMTVWtiPb04knKhUouWs3impu7dP6zhcThf3V3zQ5V ifatKfLKpQw6jGnSpezkUUUVBQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXyL8YP2 hviR8JPjj4K8JXHwj0TxL8Cda+GXi3x54u+JHhXxH8Z/Hfx00HVPCnirwf4Ofw/4Q/Zc+Ev7M/xN 1H4i6fd6v8S/h9cTeIbT4paDPo2hzeOde1jQLTTfBdtN4m+uqKI6VaM371OEqjq0Xoq0Z4evShFz Vp03RrVKWKhKD96ph4U6inQqVacx6wnFaSlGKjNfFTaqQm5RTvBuUYypNTjOKhUk4pVFCcPzW+EH /BQDWfjT4gj8CeG/hF4X8O/EC9+E/wATfFOmaX48+MV14f8ADdx8W/DOq+FLz4c/B+bxBY/CvW9W dPH/AMK/HHhD4x6/4q0Twnr2r+BfBniXRpLHwD45kmvJLHi9I/4Kq+B/Bng74faj+1B8NW+C/i/4 g+HfAWoaHa+D/il4D+I/w88V+MviLY+FvFelfCX4YeJ/G0vwO+KPj74k+Hfhn468IfEPxppk3wK8 MaPbaTceJoPBeueO/wDhCvEF3b/q7RURjJUYU5Tcqv8Asvta/LGMpKGKxtbG+yppOnSlicPiqGEw 7qRrxwkMuwlacMXWqY+eNtOm68pyhJUHOU1QpzUZxV6Sp01WnCrenyUU6zdN1albE46dOrQpTwFD Lfz0/Z5/4KQ/CP8AaF+MfiX4F2vgL4i/Crx74O8PWF/4qsfir4o/ZzhfQfGepeItU8O2fwnvdI+H Hx8+JHi2Tx1eyaF4g1TQ9RsfDV58NvF+leGvFLeCfiD4l1Hwt4h07TPLfj7/AMFQNO/Z5+Ani74s fEb4ZaP8PNe8LXuvW13e/Fvxh8T/AAj+zPo1t4F1nWvB3jy58ZftU+C/2d/iloGna0/xF8EeO/Af ws+FXgnwF8Rvjx8WNYk+Fs+m/CbRLL4mtN4S+N/B3ir9ufxHqnjj9r7wF+y7+z/4f+Out6b8ZvCP iOy8Vf8ABJ/4hfDf9qvxL4h+EfxJ8G/CD4UaHB8YPGf7f3gvTfiZ4D1jwX4+vvGHw+8VeLPE3ww8 JfEDwF4I1+Qaj8FtH1XxFcfDX9nv2VviB8Xfih8DvB3jT46+BYvhv8UNVTUV8TeD4PD/AIj8MQ6V cWeo3NpCsOj+K7u/1uCKeCGOeOW5u7iK5SQT2ssttJFIwlUxODoV6MoYWtVwix84VIOpTWGzDNcf Uy+lhk5wdatg8DQwmFx1X2tSnUwmJpVoU6WJxVDHQltYaq44hfWqSxkMpU6D9k/7SwWUzjmVarB+ 1nRwOJx2Gx+IwUZxc4V6FGlLFVMO54Sp87+O/wDgov8ADHwB4g+HOi3fh3xF4t0/4g/D3RviCvjL 4beHfib468A6DaLb+PrvxtpniTx3pfwtTwd4D1Pw7B4Fmg8MaV8Xte+F/iL4iazd3fhvQ9AtfEWg 6tpcPz3H/wAFtP2dbrwb4J8daZ8HvjjrXh/4jahpHhvwPqWieM/2M9V0Lxb4+v8AxTpfhbU/h34U 8b2X7XMvw78XeJ9Ck8QeG9Shu/CfjDXPCPxCi8RaToHwa8U/EzxzJc+ErX9k681+KPwY+D3xx0TS vDXxq+FHw1+MHhzQfEukeNND8P8AxR8C+F/iBomjeMfD5nbQfFmlaV4s0rVrDTvEuiNdXJ0jXbOC HVNNNxObO6hM0m7oUqSxCn7KTw8s4hinRlVblTyd1asamWRnGEHVq08PUpThi5OnVrYnDWlKhQxE oUcZxqyUnGrGD/smWFilTunmsMLCNLM+aU5OEa2MpuricK1WoRoV6tPDwhOFGcfSqKKKyNQooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK4D4m6/4q8M+Ezq3gzRf+Eg13/h J/AWmf2b/Zuo6t/xJte8eeGtC8Uah9j0qa3vP+JN4Y1LWNZ+1+Z9l077B/aOoxzafa3UMn43+HP2 n/8Agqr448Aaz8SvC3gHwrYT2KfHnRU+CPjj/gnD8cPAnxYPjT4ffFvwT8OPAVr4a13x5/wUX8Hf D/xt4S8X6D44ufiL4R8a67qHwn8NfFDwp4D1rUrrVvg1Yalr978NM3UtOVNQqTlDB43GtQjzt08F CnKdOMYtzdWtKrTpUFy8k604U51ISnDmtQvGEnOEVUxeHwceeXKva4iGIqRlKTShClTp4atUqznK PLGPuqbdj9z6K/Jj9pn9ob/gop4G8ESeNfgv8F9Ctr7wp8NfiOvinwP8Vf2cvGXxL1Dxh488OL4K 8PeFvil4N1X9kL9q345eJ9I+G2p+JPiBF4uj+Adn8LPib+0B4n8AfDD4pWWjX2meII/Cs+s8H8Xf 21/2+vAvww1Xxj4a/ZX8VeJ5pPgh4L8faFfeGf2XPi5468aw+NV+D/hDxn8SvC2p/s52fxl8J+Ir vxIPFni9NP8Ah58OY/i9pF3qGpeGPG3ww8VeP9C8T+HovFGq3WlGjTxVXmhUhhaaqzlTlFwnTlHO JwlCtJxoRcoZJinyV6tGpCvVw2Bqxp5jKtg6M0YyrTwsFGUHipulDnTUo1I1ssw9SEqaUq0/ZVs1 oRnOhTrUvY0sTjYzlgKSxU/2jor8VNe/aZ/4KO+APFvw5t/Fdh4X8Z+AfiX8VJvDtl4o+GX/AAS4 /av1TUfAnge1/Z+8O/GG31b4u+G9P/bf8WeJPAtnr/inxHffCz/hNLPQfFDeFviB4LufB1z8N/EO q+KL65+Hn1d+yN8Rv22fih4y1/xJ+0X4f+HXwv8AhzefDbwzr+jfBiz+BPxI8N/E/wCHfxI1zxn4 88P+Jfh94j+P+ufHjxR8OfjFB8ObPwDG934n8A/Bfwbonj208eeFPGfhq80/wm+kyeL9vZS5q8W1 FYadOlXnLmjGFatgaOPpUVFxVSpUlCt7CrGlCaweIjFY94WjisBWxePtYunhqiTlHF0I4nDJWTq0 XiZ4eU1zNKPIqcq8oTcajofw4TqqVKP37RX4j/ET/goX+3r8IPD/AIV8T3v/AAT0+KHx3P2rSPCX jbwb8IPh18TdA8QjxP40+LXw1j0bxf4c1DU4PHUUPgLwB8A/Hx1zxtb3mial/bXxW0bxV4Yk8XfD zRvh544vdMi8C/8ABRv9vv4o6sZtG/4Jl+OPhTpEPxD+IngHTvD/AMb7r44aP4i8Xjwj458R+B/D fjG48SeGf2dtZ8H/AAy+F/iq0vvhz461Dx5rD+MdZ07RX8ZWXw8+Hfxj8Padd/Ebw7z0aka9OlUh zWq08yq8jhNVIU8qhga2LlKm487f1bM8vxNCnTVSriaeIqU6EJ4nAZnQwW1eLw9PGValuTBU6FWb jKMlWWIqY+jTWHafLU/fZXmNOU24UUsNCv7R4bHZZXxv7e0V+Yv7Gf8AwUXuP2trT9ryZPhJpfhr WP2SvEFl4K8SfD7wp4/8W+O/inL8QrfwZf8AijxV8PvFvgnxH8FvhYfCninTL21tNI8Ox+GtW+JG k+Jm1Fra71bw34w0PxR4J0L4X/Y5/wCCo37b/wC0HpXjHxFZfBX4YftReDbb40+KfhjpnxE/Y78B eI9N8E/DO20fxT4a0i5j+K2p/Gb9oW1j8X6r8PtKvtTuPiO3wTn8Yapq19f6PqPwn8G+PvAFm/jr XNoU5VK8qEeVyjl2X5r7RThKhLA5rWwdLLa8MRGUqMqWLjjqWIhWU/YUsLGdfEVaMPZ+0irJUaXt qilGP9pY7KXBxkq0cflkcS8fhnRaVT22HlhK1N0VF1q0oVJYenWp4fFVKH9EVFfib49/4KU/tnfC bwlpF/4g/wCCcXxF+JGv6h4P8XaxY2vw10b9rK+1DW9X8LJb6PaDWPC/gr9jL4yaR8LbfxB4tsfE Eh8O+IPif4l8X2/gTUvhz4t8Bad8XJ9d+IWjfCnrNN/bR/4KNsEtD+wD4R1zXzpnhFzZ3vxH+PXw 68GuniHVNOtx4jHj6f8AZW+IWpwar9h8c+CJPFvwnm+HJk+Fv/CIfGW9k+LHxGTw3pVjfYe2p+xp V7v2NahLEwqck7KlDExwk/aLl5qVWGIkoTw9WMMRTjGpWqUoYehXq09Z05QniKUre1wuJjhKlNSi 268q+Bw8o05c3s6sacsywk51YTdJQqJRnKo4U5fsNRXxb+yj+1H8Tv2hvG37SHhbx/8AsufE79nv Rvgn428FeGfAfjDx9YeObDSPjlo3inwBpPizWPEfhFPG3wv+G+U8EeJLzVPAXiAeHLjxv4cl1XSB f6X4tvbW/hjj+0q6KtKpRlGNRJOdHD4iKU4TvSxVCniaLbhKSjKVGrCU6cmqlKTdKrCFWE4Rxp1I 1FJwvaFWtRlzRnBqph606FWPLOMZe7VpzipW5ZpKcHKEoyZRRRWZYUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAYXii9u9N8NeItRsJjbX1hoWr3tlcDw3rPjIwXdrp9xPbTD wh4cubLxD4qMU0aOPDeg3lprOubf7M0u5gvrqCVPwjtf2/8A/goTfeHvDep2/wAFdZtbvWPAXhbW LyLWf+CYH7e+nalpet36WGqaVe674ZtvifqjaHffFfU7q++DGqfCjT/Evi3VP2RvE2i3nx0+LHxK +KHwQvtCl1b9+aKUE41lUcm4qrhKnKuVtRw8caqiiqqq0HKs8VSuq2Hr4ZqhfE4XFVFg6mBcmnTl DlTk6OJppy5kuavLCOnNulKjXXslh6lnTxFOsnW/cV8NB4uGM/I74Qfto/tU+Lf2afEfxK+JnwU8 d/D34qeFv2ovDHw+/wCEbuP2Hf2pZh41+CV38YPCfgvxL4o8E/C/SPF3ij4mtYLodx4+i8K/GTxD PpFvN4e8NaB8e/HfwC8AeD/Flr8ObX1h/wBqb4xQ/BLxD4ubwx4wuPiH4O/agh+Hmq2cP7CP7YaW /iX4NS/tOSfD9NV8JfDYTz+N7+9k+C6trUnxl0TXPF3wzsL+2/4Wxd+FR8PNRtPC0f6M0VVNqCwy lFSVCGCjU5eZOvUwtLJqU68nVdaXPif7NxlStSquthJ1cynOphqtsasyiqnONeMJOEqlepVpVGou VOnVjnEZ4WoqSo050FLNKNSlOhDCYqjLLMEqWIjTo0YUPnv9mr4leNfif4I8Var8QNO1DT/EXhz4 xfGXwLFJe/BP4r/AWDVvC/hD4jeINK8Ca1pXg74w3WoeI9Y0/UvA0fh2dviBouqah4I8fal/aHiX wcdM0a+g0HSfoSiikvhpJ6yhRoU6kv8An5Vp0YQq1kvsqtVjOqoNzdNT5HUqOLnKnrUxE1pGti8Z iKdP7OHpYnFVsRRwtN7ulhKVSGFpN+86VGDl7zYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAf//ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEsDBBQABgAIAAAAIQABu/qHhQEAAEcDAAAR AAAAcHB0L3ZpZXdQcm9wcy54bWyMUrtuwjAU3Sv1HyzvkBBoSCMCS9WJoRK0u+U4wZJjW7YJga/v dUIgPAa2+zyPay9WTSVQzYzlSmZ4Mg4xYpKqnMsyw7/b71GCkXVE5kQoyTJ8ZBavlu9vC53WnB1+ DAIAaVOS4Z1zOg0CS3esInasNJPQK5SpiIPUlEFuyAGAKxFEYRgHFeESn/fNK/uqKDhlX4ruKyZd B2KYIA7E2x3XtkfTr6BpwyzAtNs3kpZgTnrZ4q+16HOYdcqwfM0Kh+wJTvURRyEOhr2t0m3rcxbH bSt4xLGC5+wKSzciH2RdiGpiNpQIOPcEewLrk+WCpLZB8EpJhFEOvbAlgerxsQrU5y2dKsNLLlGT 4RGoxugIQTLz2mGKXunLPWhbW+cp2xjBJlwIjqnMCSOtbIajSeetH+mKSdIbvoJ48IE9r+jWvFSO 2S1r3FXCQM2dae/2ieu7sifpjjW0DZvguVd44YDhJxJKw/ONJhQ+KqJws/l0PoWnBgwKIJesu17d fZB/AAAA//8DAFBLAwQUAAYACAAAACEAWJuQwqoAAAAfAQAAEQAAAHBwdC9wcmVzUHJvcHMueG1s jI87DsIwDEB3JO4QZacpDAhV/SyImQEOEKVuGylxIjv8bk/ER4Kto2W95+e6u3snrkBsAzZyXZRS AJrQWxwbeT4dVjspOGnstQsIjXwAy65dLupYRQIGTDpl9Egii5Ar3cgppVgpxWYCr7kIETDvhkBe pzzSqHrSt3zAO7Upy63y2qL88DSHD8NgDeyDufgc8JYQuFcJTzby1xbn2H7/+EtS7RMAAP//AwBQ SwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDh vYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA 1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705Uk gecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYA CAAAACEAWhskM5UBAADjAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJJLj9sgFIX3lfofEHsHO9NEE8vxSG01q0aqVPeh2SG4sdHwEuDJ 5N/3YiduRu2iO+Acvns5l+bh1WjyAiEqZ/e0WpWUgBVOKtvv6ffusbinJCZuJdfOwp6eIdKH9v27 RvhauABfg/MQkoJIkGRjLfyeDin5mrEoBjA8rtBhUTy6YHjCbeiZ5+KZ98DWZbllBhKXPHGWgYVf iPSClGJB+jHoCSAFAw0GbIqsWlXsjzdBMPGfFyblxmlUOnt806XdW7YUs7i4X6NajKfTaXW6m9rA /iv26/Dl2/TUQtmclQDaNlLUSSUN7Q8V0sg1URbrH7kAgkGQOHrvMDfbEzPqpAZn8hqDno0kgRis 064/kwFPHc6oYQs040UAnlxou8AtOSg7kC6Mtp9cVy2PSfOYDjjRowL58Yx2NHWHhv0tZXeAF5U/ Q7vbTpZljyWnAOe6IAlGUs8BXpWfd58+d4+0xVR2RVUV5borN3VZ1evNU27rzf0c0XxgLs39D3HX IW6zrT/c3xCvgHbq+O23bH8DAAD//wMAUEsDBBQABgAIAAAAIQA76K2mnQIAANQFAAAQAAgBZG9j UHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxU30/bMBB+ n7T/wcrDtD1AQlcx1LlGVRkDiUK3BvZsnGtjzbEtn1sof/0uCS3tiDZtebpf+e7uO9/x08fKsBUE 1M4Ok6PDLGFglSu0XQyT2/z84CRhGKUtpHEWhskaMDkVb9/waXAeQtSAjCAsDpMyRj9IU1QlVBIP yW3JM3ehkpHUsEjdfK4VnDm1rMDGtJdlxyk8RrAFFAd+C5i0iINV/F/Qwqm6PrzL154KFjx3UZpc VyBOsiOevqj8hwsFil7W42kr8pH3RisZiREx0So4dPPIbpra2dQ9QJg6bSNPdwOJD0BqqvntvOlZ 3NgDVAHAslnpHtj7/uDjB552BPKpDHIRpC9R9KmQHZXPjC4AxSeePkv82sXW0Ar8QhcF2GdvxtM9 nU8mY6M9CnJsRD5T0sCYCBJzaRAIemvgFyDr4U+lDij4Kg5WoKILDPUTjb+fsHuJUNM6TFYyaGkj 0VuHtUojG48xiJzeAWGTr9UbcTdsV9Z9QXOhWBL+GNhiNd2yXEcD+A8piMWuFLWxbZNy7xPQpriZ 00hiBx+0HS98NKW1bLRVPr+ZV0RsKbnTIS6lYfScIMylAkbrwnDpvaPVsgtWLU3UpatqmZawDWQR VGmdcYs1K8nqaH93SdjC0w7cG6jqBY40Cxv3uNoN8w6hYOjMsn723WCTy+nqmC1RLoChAksDd+xB x5KtXrUhI4slsMl1J9Q1KECUYc0U1b+gE6Itm4y+svqkNBvUXWjnf1eT0d/++7YErPtC9k5W/jMb WaQt3sux9wR+G/rYVV7atfiSf7/k6UbjV9r+xFufuzNid7NJ+0Y+K2WAgi7exv9i4Be0RMHUIOOG hWIT89pR36S79kiLo95hRl9zfja2+qpszrH4BQAA//8DAFBLAQItABQABgAIAAAAIQCbNI5YkwIA AIEUAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh AGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAAAAAAzAQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh ANgDgmvXAAAAzgEAACAAAAAAAAAAAAAAAAAAAggAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhACPzcKTXAAAAzgEAACAAAAAAAAAAAAAAAAAAFwkAAHBwdC9z bGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNziZ74AAAA3AIAACAA AAAAAAAAAAAAAAAALAoAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAEqMrZTZAAAAzgEAACAAAAAAAAAAAAAAAAAAYgsAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAAoFjXlZAQAAiQcAAB8AAAAAAAAAAAAAAAAAeQwA AHBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEAmdVBA9gAAADO AQAAIAAAAAAAAAAAAAAAAAAXDwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAFx81x9kAAADOAQAAIAAAAAAAAAAAAAAAAAAtEAAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTcueG1sLnJlbHNQSwECLQAUAAYACAAAACEA+4hR6O8AAABVAgAAIAAAAAAAAAAAAAAA AABEEQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAImQ2 roMCAACdDQAAFAAAAAAAAAAAAAAAAABxEgAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYA CAAAACEAr77UNsAIAAC7JQAAFQAAAAAAAAAAAAAAAAAmFQAAcHB0L3NsaWRlcy9zbGlkZTMueG1s UEsBAi0AFAAGAAgAAAAhAJ57rmwEAwAAWgcAABUAAAAAAAAAAAAAAAAAGR4AAHBwdC9zbGlkZXMv c2xpZGU3LnhtbFBLAQItABQABgAIAAAAIQDIIQvnZAMAAL8KAAAVAAAAAAAAAAAAAAAAAFAhAABw cHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAAACEA/Bryqg0DAAAICQAAFQAAAAAAAAAA AAAAAADnJAAAcHB0L3NsaWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAFeE0EPABQAAQxYA ABUAAAAAAAAAAAAAAAAAJygAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbFBLAQItABQABgAIAAAAIQCF 2rag2QYAAG0YAAAVAAAAAAAAAAAAAAAAABouAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQSwECLQAU AAYACAAAACEAw6EeYvMDAABSDAAAFQAAAAAAAAAAAAAAAAAmNQAAcHB0L3NsaWRlcy9zbGlkZTEu eG1sUEsBAi0AFAAGAAgAAAAhAOMORnxvBQAAkhsAACEAAAAAAAAAAAAAAAAATDkAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA AAAAAAAAAAAAAPo+AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVs c1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAAJAAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAAAAAAAAAAAAAAApBAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAABJCAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAABpDAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAA AAAAACJEAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc1BLAQIt ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAACpFAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAAAAAAAAAAAAAADJGAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwu cmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADpHAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLx vgAAADcBAAAtAAAAAAAAAAAAAAAAAEJIAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAABL SQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPCJRJ7VAAAAvwEAACoAAAAAAAAAAAAAAAAAVEoAAHBwdC9ub3Rlc1NsaWRlcy9fcmVs cy9ub3Rlc1NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQB+QzBa1QAAAL8BAAAqAAAAAAAA AAAAAAAAAHFLAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTQueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAFzztatUAAAC/AQAAKgAAAAAAAAAAAAAAAACOTAAAcHB0L25vdGVzU2xpZGVz L19yZWxzL25vdGVzU2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAK0a3M3VAAAAvwEAACoA AAAAAAAAAAAAAAAAq00AAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlNy54bWwucmVs c1BLAQItABQABgAIAAAAIQCZ9pmu1QAAAL8BAAAqAAAAAAAAAAAAAAAAAMhOAABwcHQvbm90ZXNT bGlkZXMvX3JlbHMvbm90ZXNTbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAo3Ln8TYEAABg EAAAIQAAAAAAAAAAAAAAAADlTwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsB Ai0AFAAGAAgAAAAhAEqvdTnUAAAAvwEAACoAAAAAAAAAAAAAAAAAWlQAAHBwdC9ub3Rlc1NsaWRl cy9fcmVscy9ub3Rlc1NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBORqfXSwMAAPEKAAAh AAAAAAAAAAAAAAAAAHZVAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAU AAYACAAAACEAHJg7mhIEAADDEQAAIQAAAAAAAAAAAAAAAAAAWQAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAAAAAAAAAAAAAAAA UV0AAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAEF5UzrWAgAAFAgAACEAAAAAAAAAAAAAAAAAuV4AAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQDKLH6tkgcAADIvAAAhAAAAAAAAAAAAAAAAAM5h AABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA5hBreGMC AADIBQAAHwAAAAAAAAAAAAAAAACfaQAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUxLnhtbFBL AQItABQABgAIAAAAIQDAsvQ6rgMAAAgMAAAiAAAAAAAAAAAAAAAAAD9sAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MTEueG1sUEsBAi0AFAAGAAgAAAAhAO4q7HZjAwAAKAsAACIAAAAAAAAA AAAAAAAALXAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAA ACEAgJDlqqsEAACMEQAAIQAAAAAAAAAAAAAAAADQcwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDkueG1sUEsBAi0AFAAGAAgAAAAhAJNieRrtBAAAHRIAACEAAAAAAAAAAAAAAAAAungAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbFBLAQItABQABgAIAAAAIQD8DSpKpwIAAMIG AAAhAAAAAAAAAAAAAAAAAOZ9AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWxQSwEC LQAUAAYACAAAACEA3Ob2yGMCAADIBQAAHwAAAAAAAAAAAAAAAADMgAAAcHB0L25vdGVzU2xpZGVz L25vdGVzU2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQDBHbiQYwIAAMgFAAAfAAAAAAAAAAAAAAAA AGyDAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhAOkMvHJj AgAAyAUAAB8AAAAAAAAAAAAAAAAADIYAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNy54bWxQ SwECLQAUAAYACAAAACEA9PfyKmMCAADIBQAAHwAAAAAAAAAAAAAAAACsiAAAcHB0L25vdGVzU2xp ZGVzL25vdGVzU2xpZGU2LnhtbFBLAQItABQABgAIAAAAIQAv354qhwQAALQQAAAhAAAAAAAAAAAA AAAAAEyLAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQSwECLQAUAAYACAAAACEA 0/ohwmMCAADIBQAAHwAAAAAAAAAAAAAAAAASkAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGU1 LnhtbFBLAQItABQABgAIAAAAIQDOAW+aYwIAAMgFAAAfAAAAAAAAAAAAAAAAALKSAABwcHQvbm90 ZXNTbGlkZXMvbm90ZXNTbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhACPQqAnVAAAAvwEAACoAAAAA AAAAAAAAAAAAUpUAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlNi54bWwucmVsc1BL AQItABQABgAIAAAAIQDy3k82BgYAAD8dAAAhAAAAAAAAAAAAAAAAAG+WAABwcHQvbm90ZXNNYXN0 ZXJzL25vdGVzTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA+c8JOYMGAABcGwAAFAAAAAAAAAAA AAAAAAC0nAAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEA6JAgMawQAACsEAAA FAAAAAAAAAAAAAAAAABpowAAcHB0L21lZGlhL2ltYWdlMS5wbmdQSwECLQAKAAAAAAAAACEA2AHx n0keAABJHgAAFAAAAAAAAAAAAAAAAABHtAAAcHB0L21lZGlhL2ltYWdlMi5wbmdQSwECLQAUAAYA CAAAACEA+c8JOYMGAABcGwAAFAAAAAAAAAAAAAAAAADC0gAAcHB0L3RoZW1lL3RoZW1lMi54bWxQ SwECLQAUAAYACAAAACEAtM9YGbsAAAAkAQAALAAAAAAAAAAAAAAAAAB32QAAcHB0L25vdGVzTWFz dGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAKAAAAAAAAACEADX1ib1s7AABb OwAAFAAAAAAAAAAAAAAAAAB82gAAcHB0L21lZGlhL2ltYWdlMy5wbmdQSwECLQAKAAAAAAAAACEA SC38WACAAAAAgAAAFwAAAAAAAAAAAAAAAAAJFgEAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwEC LQAUAAYACAAAACEAAbv6h4UBAABHAwAAEQAAAAAAAAAAAAAAAAA+lgEAcHB0L3ZpZXdQcm9wcy54 bWxQSwECLQAUAAYACAAAACEAWJuQwqoAAAAfAQAAEQAAAAAAAAAAAAAAAADylwEAcHB0L3ByZXNQ cm9wcy54bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAADLmAEAcHB0 L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQBaGyQzlQEAAOMCAAARAAAAAAAAAAAAAAAA AKiZAQBkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQA76K2mnQIAANQFAAAQAAAAAAAA AAAAAAAAAHScAQBkb2NQcm9wcy9hcHAueG1sUEsFBgAAAABFAEUA5xQAAEegAQAAAA== --001485f8d1821086f40477e696a9-- From huimin.cmcc@gmail.com Wed Nov 11 18:37:54 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0993A6999 for ; Wed, 11 Nov 2009 18:37:54 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnj4PnmrCEDx for ; Wed, 11 Nov 2009 18:37:53 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 780EA3A6991 for ; Wed, 11 Nov 2009 18:37:53 -0800 (PST) Received: by pwi6 with SMTP id 6so1171147pwi.29 for ; Wed, 11 Nov 2009 18:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qj+rLJB/G24E19MM/C03U72pKhvDzaPSn70ZYRq8DlI=; b=vUW3MxjZj3m0CO6HiFcKFM0Wp73/IQlQOZUxY/STnecx+ZOuxuQxwoK7Rt4auIhQ70 AsffFPz/+BmJLxRJOeXKbc35tTV3wdgr2hn46bz4ET0DgF53HUpb71G0qamYghjNlIof iuUhVxhp1pFLgkr6p+yyvkXd0UZWLmTSwv2rA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nrdv2ob2cAXs5s6PR0gRwyOMZAuceS7FV9CvWel7zcyiSfwt0L54kBxLHQR+qYrgxm 2LhZ9bokga4x2SS9GkNV+lgS4xNaJICr/AYSVSMuTpDasLNy4VNPU9PRnS9JOOLEe56f 7+JbIgRImWFI92U1D8Wq8VQvzzdPAUV8z7S08= MIME-Version: 1.0 Received: by 10.115.103.17 with SMTP id f17mr4875732wam.166.1257993499002; Wed, 11 Nov 2009 18:38:19 -0800 (PST) In-Reply-To: <200910221022078595121@gmail.com> References: <200910221022078595121@gmail.com> Date: Thu, 12 Nov 2009 10:38:18 +0800 Message-ID: <5dca10d30911111838t110068a8y68ae110eeadda6a4@mail.gmail.com> From: Min Hui To: wudiyetc Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: netext Subject: Re: [netext] Question about the draft-hui-netext-multihoming X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:37:54 -0000 Hi Wudi, Sorry for the late reply, for I didn't see it in so many mails. When the video telephony traffic is directed to different interfaces, it means the video data uses one IF while the audio data uses another. So the service identifier can identify these two different kinds of data. However, it's indeed complicated to distinguish the video and audio data in the same application, maybe the use case in section 2 is not very suitable to illustrate the multihoming extension. It's better to cite a use case with different IP flows, it will be improved in the updated draft. Thanks very much for your comment. -Hui Min 2009/10/22 wudiyetc : > > Hi =A3=AChui > > I have read you draft, but I have some questions, please see inline. > > Wudi= Ye > In section 2 >>The bandwidth of any of IF1 or IF2 is not enough to maintain the >>video telephony traffic, so a possible solution is to enable the MN >>to send and receive the traffic addressed to HNP1 via IF1 and IF2 >>simultaneously. > > I guess you mean divide a flow to more than one interface. > > In section 4.1 > >1) Service Flow Identifier, an additional sub-field. A service > > flow identifier is used to indicate one of the flows binding to the > > MAG associated with the set. When flows are binding to the MAG, the > > sub-field would include multiple flow identifiers. The detailed > > format of service flow Identifier is out of the scope of this > > document, more information can be found in [draft-hui-netext-service- > > flow-identifier]. > but every packets of each flow has the same property. So if use the Flow > Identifier, > each flow can only bind to one MAG, how to divide one flow to more than o= ne > interface? > From Mohana.Jeyatharan@sg.panasonic.com Sun Nov 15 18:00:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F2B3A6A30 for ; Sun, 15 Nov 2009 18:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.71 X-Spam-Level: * X-Spam-Status: No, score=1.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzA1+7NChKbD for ; Sun, 15 Nov 2009 18:00:10 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 731DE3A62C1 for ; Sun, 15 Nov 2009 18:00:07 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id nAG200ZS005689; Mon, 16 Nov 2009 11:00:00 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id nAG1xtO13737; Mon, 16 Nov 2009 10:59:56 +0900 (JST) 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, 16 Nov 2009 09:59:25 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> In-Reply-To: <20091026083001.DC4873A679C@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on :draft-wu-netext-local-ro-04.txt Thread-Index: AcpWFgGnyDJ7bKa6TH6EiRT+Q556ggQQBXeQ References: <20091026083001.DC4873A679C@core3.amsl.com> From: "Mohana Jeyatharan" To: "Qin Wu" Cc: netext@ietf.org Subject: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 02:00:11 -0000 Hi Qin, Read your ID. I have few comments. Please see below. BR, Mohana In abstract,=20 "In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways attached by the correspondent node to the mobile access gateway attached by the=20 mobile node afterwards." <<<[Mohana] In abstract it is not very clear which entitiy notifies CN's MAG to MN's MAG. Perhaps a rewording may be useful>>> In abstract, Mobile access gateways create and refresh bindings=20 using proxy binding update and acknowledgement messages. <<<[Mohana] What is the reason for this. Is this refering to PBU to LMA or PBU to MAG? Perhaps more clarity on this will help.>>> In conventions used section it is mentioned Local routing: Traffic between MN and CN does not pass through LMA and is locally routed in the same PMIPv6 domain. <<<[Mohana] Perhaps a re-wording may be necessary when referring to PMIPv6 domain. This should be aligned with the PS draft terminology. It should be same provider domain running PMIPv6 or some thing like that.>>> In conventions used section it is mentioned Local Routing Optimization Request (LROREQ): A message initiated by the MAG or LMA requesting the MAG or LMA to establish local routing optimization path between MN and at least one pair of CNs who communicate with MN. <<<[Mohana] why is there reference to at least one pair of CN. Are u saying at least a single CN? Not very clear>>> In section 3 Scenario analysis for PMIPv6 local routing <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. Again I think this should be single administrative/provider domain running PMIpv6.>>> In figure 1,=20 <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to LMA.>>>=20 In last para in section 3 which is In all the above scenarios, MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or move from one PMIPv6 domains(i.e., MN's visited domains)to another. CN should stay with MN within the same PMIPv6 domain, e.g., MN moves to the visited domain to which CN belongs. Another example is MN and CN move to the same visited domain to which MN's LMA or CN's LMA does not belong. <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative domain. Probably re-writing with respect to MN in home or visited domain and CN inhome or visited domain may be useful. Currently the text is not very clear>>> In section 4,=20 <<<[Mohana] the first bullet should be changed to administrative domain instaed of PMIPv6 domain. The second bullet says MN and CN attached to same LMA. But in section 3 it is mentioned inter LMA scenario as well. So, I am a bit confused as to whether the solution is not handling inter LMA scenario.>>> In section 4.1 <<<[Mohana] In this section there is reference to three different types of flags such as intra-LMA local routing flag, intra-MAG local routing flag, Enable detect local routing flag. A description of these in section 2 would be better for easy understanding.>>> In section 4.1, para 3, it is mentioned After successful local routing optimization process, if MN and CN attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA localrouting flag is set to value one, the MAG1 to which the MN attaches may send PBU message to the MAG2 which the CN attaches to. <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I think you are referring to MN connected to MAG 1 and CN connected to MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between th etwo MAGs. The sentence is not clear.>>> In section 4.1, in para 3 it is mentioned that MN's MAG is informed of CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's MAG is informed of Mn'sMAG via LRO response and both MN's Mag and CN's MAGs are engaged in bi-ditectional PBU/PBA. <<<[Mohana]Here I have some comments. Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new option. Then MN's MAG can start PBU with CN's MAG. But the question I have is how does CN's MAG create the routing state for MN prefix. How does the CN's MAG know that this prefix is owned by MN and MN's MAG is actually proxying that prefix? The same when CN's MAG does PBU to MN's MAG. Probably, after getting the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But again to create the the routing state for CN's prefix at MN's MAG the MN's MAG should know the prefix CN owns is valid prefix. Otherwise, I don't see how a valid routing state can be created. So, by reading this I feel a prefix ownership kind of information is needed in the PBU.>>> In the handover mechanims in section 4.1.1, it is mentioned that the nMAG1 will get context from old MAG (pMAG1).=20 <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's MAG, how can CN's MAG know that this prefix of MN is valid and nMAG1 is proxying the preifx. Bcos during handoff, the LMA is not involved. nMAG1 has no issue in knowing that MN;s prefix is given by LMA because when it does PBU to LMA it will know that this is a valid prefix. But that is not the case with CN's MAG.>>> Also in section 4.1 in second paragraph it is mentioned that MAG can send LRO req to LMA when Mn and CN are not attached to same MAG.=20 <<<[Mohana] In this case, how does MAG know the CN address. What value will be attached in the Mn-CN pair mobility option. Is there some L2 message sent from Mn to MAG and all CN addresses are given in these. Probably such mentioning will be useful>>> I have more comments. But rather than sending all at once I thought I will stop here for now. Thanks. > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 26, 2009 4:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-wu-netext-local-ro-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Proxy MIP extension for local routing optimization > Author(s) : W. Wu, B. Sarikaya > Filename : draft-wu-netext-local-ro-04.txt > Pages : 32 > Date : 2009-10-26 >=20 > This document extends local routing in proxy Mobile IPv6 and defines > a localized routing optimization protocol within one PMIPv6 domain. > The protocol supports IPv4 transport network operation, IPv4 home > address mobility and handover. The Local mobility anchor/mobile > access gateway initiates local routing for the mobile and > correspondent node by sending messages to each mobile access > gateway/local mobility anchor. In case the correspondent node is > connected to another local mobility anchor, the local mobility > anchors connected by the correspondent node needs to be discovered > firstly so that it can notify its mobile access gateways attached by > the correspondent node to the mobile access gateway attached by the > mobile node afterwards. Mobile access gateways create and refresh > bindings > using proxy binding update and acknowledgement messages. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From Marco.Liebsch@nw.neclab.eu Thu Nov 19 09:17:02 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A033A6849 for ; Thu, 19 Nov 2009 09:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Mg6-5BRc1ZK for ; Thu, 19 Nov 2009 09:17:01 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B35013A6882 for ; Thu, 19 Nov 2009 09:17:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 045E42C00C525; Thu, 19 Nov 2009 18:16:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 322RI62xWB85; Thu, 19 Nov 2009 18:16:57 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id C6F0E2C0002FE; Thu, 19 Nov 2009 18:16:42 +0100 (CET) Received: from [10.1.2.187] ([10.1.2.187]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 18:16:42 +0100 Message-ID: <4B057D7A.10705@nw.neclab.eu> Date: Thu, 19 Nov 2009 18:16:42 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mohana Jeyatharan References: <5F09D220B62F79418461A978CA0921BD039D908A@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD039D908A@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2009 17:16:42.0858 (UTC) FILETIME=[1075A4A0:01CA693C] Cc: netext@ietf.org Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:17:02 -0000 Hi Mohana, thanks again for your comments. All of them are valuable and, as said during last week's meeting, we'll take them in the next update into account. Please see in-line for specific feedback. Mohana Jeyatharan schrieb: > > Hi all, > > > > I went through the draft and have few comments. > > > > > > 1)Introduction first para says > > " Even though two communicating MNs might be attached to the > > same MAG or to different MAGs of the same local mobility domain, > > packets will traverse the MNs' LMA(s)." > > [Mohana] Mn and CN may be better word. Bcos later in draft communication > > End points are defined as MN and CN. > Yes, definitely we should keep this consistent. > > > 2)Introduction second para says > > " Objectives of designing a solution for localized routing in PMIPv6 > > are to specify protocol messages and enable associated protocol > > operation between PMIPv6 components to support the set up of a direct > > routing path for data packets between the MNs' MAGs without > > forwarding these packets through the MNs' LMA(s) and to maintain > > localized routing in case one or both MNs handover to a different > > MAG." > > > > [Mohana] Here again it says that direct path between MN's MAGs. I > think it is between Mn's MAG and CN's MAG. > True. > > > 3)In the conventions and terminology section > > > > The second bullet: > > > > Correspondent Node (CN): Correspondent Node with or without IP > > mobility support. The CN represents the communication peer of an > > MN, which is attached to a MAG and registered with an LMA > > according to the PMIPv6 specification. > > > > [Mohana]The usage of "an" in front of MN and LMA should be changed to a. > Ok. > > > 4)In the conventions and terminology section > > > > The third bullet: there is mentioning about a single PMIPv6 domain. > > [Mohana] Is it MN and CN placed in single operator/provider domain > running PMIPv6? > Yes, true. This is still from the previous understanding of the localized routing scope. We'll update the description. > > > 5)In the conventions and terminology section > > Fourth bullet mentions about IDs > > > > [Mohana] Is it only ID? What other information stored. What are these > IDs? > > Perhaps a description will be good. > One example could be the MNID as per RFC5213, which is stored together with localized routing states. Could also be localized routing specific IDs which serve as a key to the MN's states, but we should not assume anything from a solution here. So, do you think describing the MNID as specific example is sufficient? > > > 6)In section 3.1 general observation section 1st para > > > > " Following the architecture of PMIPv6, rather entities of the network > > infrastructure are dedicated to perform signaling to set up a more > > direct route between an MN and a CN." > > > > [Mohana] I am not sure the meaning of this. Does it mean that when > PMIP is present, RO needs to be established by using signaling between > network entities? Perhaps a rewording is useful. > It means that MNs cannot perform mobility signaling as per requirement of NetLMM, which applies also for localized routing set up. The paragraph just explains that network components, most probably PMIPv6 specific components (MAG, LMA) need to take over this responsibility and perform signaling to set up a MN's localized routing path. I'll try to find better wording, assumed you agree to the explanation above. > > > 7)In section 3.1 general observation section last paragraph > > [Mohana] It is mentioned two benefits of loacl MAG routing.There is > mentioning about lower cost, lower delay, lower packet loss. But > clear indication as to the two benefits was not present. > They're in, but not so obvious, as I must admit. One is the costs aspect (MAG-LMA more costly), the other is the benefit for the user (delay). I'll write to find clearer text. > > > 8) In section 3.2 all mentioning is about "PMIPv6 domain". > > [Mohana] I do not want to start the discussion again. But, isn't it > better to say what this PMIPv6 domain is. MN and CN in same operator > domain or something like that. Bcos there is another section on > roaming which is different from this. > Yes, same as above and still not yet updated in this version. Thanks for the hint, we'll rewrite this for the update. > > > 9) [Mohana]Again in section 3.2, there is mentioning about some race > issue in multiple LMA > > Case, when there is handoff. But no clear description of such issue > is highlighted. A small description will be good. > Ok, I'll add text here. > > > 10) In section 3.2, the local MAG issues are highlighted into > cases(case A11, A..) and again some issues (multiple LMA, handoff in > multiple LMA) are captured in bullet form. I am not sure whether > there are any overlap in text here. > Maybe there is some overlap. A11 etc. analyze issues that come with a particular topology (multi-LMA etc). The bullet list summarizes general problems, which may also cover one or the other issue from above. I think it makes sense to have problems summarized in one place, even though they may appear at a different place already with details about where the problem comes from. > > > 11)Section on IPv4 considerations. I think the current text is fine. > It is not too complex and highlights how local MAG routing canbe done > when there is IPv4 HoA or IPv4 transport. > Ok, thanks. Your review is based on version 00. For the latest update, we had to remove the NAT and the private IPv4 address conflict,.as the solution will not address them. Hope the text is still clear in version1. Thanks and best regards, marco > > > BR, > > Mohana > > > From sunseawq@huawei.com Thu Nov 19 18:19:46 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8963A67D6 for ; Thu, 19 Nov 2009 18:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.305 X-Spam-Level: * X-Spam-Status: No, score=1.305 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYoF35Lmm81X for ; Thu, 19 Nov 2009 18:19:44 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 46C433A6935 for ; Thu, 19 Nov 2009 18:19:44 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTD005HRYGJPV@szxga01-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 10:19:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTD00MDVYGJGW@szxga01-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 10:19:31 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTD00077YGEBM@szxml04-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 10:19:31 +0800 (CST) Date: Fri, 20 Nov 2009 10:19:25 +0800 From: Qin Wu To: Mohana Jeyatharan Message-id: <006601ca6987$e49609a0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 02:19:46 -0000 Hi, Mohana: Sorry for my late reply. Also thank you for your review and comments. please see my reply inline. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: "Qin Wu" Cc: Sent: Monday, November 16, 2009 9:59 AM Subject: Comments on :draft-wu-netext-local-ro-04.txt Hi Qin, Read your ID. I have few comments. Please see below. BR, Mohana In abstract, "In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways attached by the correspondent node to the mobile access gateway attached by the mobile node afterwards." <<<[Mohana] In abstract it is not very clear which entitiy notifies CN's MAG to MN's MAG. Perhaps a rewording may be useful>>> [Qin]: Yes, what we are really saying here is CN's LMA will notify CN's MAG to MN's MAG when MN's MAG communicate with CN's LMA using normal PBU/PBA. Maybe the proper way to say would be " so that the discovered local mobility anchor notity its mobile access gateways attached by the correspondent node...... " In abstract, Mobile access gateways create and refresh bindings using proxy binding update and acknowledgement messages. <<<[Mohana] What is the reason for this. Is this refering to PBU to LMA or PBU to MAG? Perhaps more clarity on this will help.>>> [Qin]: Okay, actually PBU/PBA will be used between MAGs to create binding when it is the first time for MAGs to setup localized routing path. during handover case, PBU/PBA will be used between MAGs to refresh binding. The reason to create and refresh bindings between MAGs attached by mobile node and correspondent node is quite similar to correspondent registration in the Mobile IPv6 Routing optimization between mobile node and correspondent node described in the section 11.7.2 of RFC3775. i.e., allowing correspondent node to cache mobile node's proxy care-of address or allowing mobile node to cache correspondent node' proxy care-of address, In conventions used section it is mentioned Local routing: Traffic between MN and CN does not pass through LMA and is locally routed in the same PMIPv6 domain. <<<[Mohana] Perhaps a re-wording may be necessary when referring to PMIPv6 domain. This should be aligned with the PS draft terminology. It should be same provider domain running PMIPv6 or some thing like that.>>> [Qin]: Okay, will check the wording to be consistent with PS draft. In conventions used section it is mentioned Local Routing Optimization Request (LROREQ): A message initiated by the MAG or LMA requesting the MAG or LMA to establish local routing optimization path between MN and at least one pair of CNs who communicate with MN. <<<[Mohana] why is there reference to at least one pair of CN. Are u saying at least a single CN? Not very clear>>> [Qin]: Right, thank for your good catching and correction. The reason to say at least one CN is in some cases, maybe MN will communicate with more than one CN, in this sense, LROREQ message may be sent from MN's LMA to each MAGs attached by serveral CNs which is communicating with MN. or sent from MN's MAG to each LMA which is registered by more than one CNs which is communicating with MN during inter-LMA handover case. In section 3 Scenario analysis for PMIPv6 local routing <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. Again I think this should be single administrative/provider domain running PMIpv6.>>> [Qin]: Okay. In figure 1, <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to LMA.>>> [Qin]: I am okay with this change in the figure 1. In last para in section 3 which is In all the above scenarios, MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or move from one PMIPv6 domains(i.e., MN's visited domains)to another. CN should stay with MN within the same PMIPv6 domain, e.g., MN moves to the visited domain to which CN belongs. Another example is MN and CN move to the same visited domain to which MN's LMA or CN's LMA does not belong. <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative domain. Probably re-writing with respect to MN in home or visited domain and CN inhome or visited domain may be useful. Currently the text is not very clear>>> [Qin]: Agree there is room for improvement here, this paragraph will be reworded in accordance with the terminologies used in the PS draft In section 4, <<<[Mohana] the first bullet should be changed to administrative domain instaed of PMIPv6 domain. The second bullet says MN and CN attached to same LMA. But in section 3 it is mentioned inter LMA scenario as well. So, I am a bit confused as to whether the solution is not handling inter LMA scenario.>>> [Qin]: Yes, inter LMA scenario will be handled in one separate section of our Solution I-D. Our solution I-D mainly focuses on specifying the localize drouting protocol based on the first two scenarios described in the section 3. the common aspect of the first two scenarios is it does not require PMIP6 mobility entities discovery described in the PS draft. As regarding to the inter-LMA local routing scenario, it depends on PMIP6 mobility entities discovery, extra extended PMIP6 signaling is required between MN's MAG and CN's LMA. Therefore inter-LMA local routing case is separated from section 4 which is concentrating on the first two scenarios and addressed in the independent section, i.e., section 7. In section 4.1 <<<[Mohana] In this section there is reference to three different types of flags such as intra-LMA local routing flag, intra-MAG local routing flag, Enable detect local routing flag. A description of these in section 2 would be better for easy understanding.>>> [Qin]: Okay. Thank for your suggestion. In section 4.1, para 3, it is mentioned After successful local routing optimization process, if MN and CN attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA localrouting flag is set to value one, the MAG1 to which the MN attaches may send PBU message to the MAG2 which the CN attaches to. <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I think you are referring to MN connected to MAG 1 and CN connected to MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between th etwo MAGs. The sentence is not clear.>>> [Qin]: Okay, maybe we could say: " MAG1 to which the MN is connected may send PBU message to the MAG2 to which the CN is connected. " In section 4.1, in para 3 it is mentioned that MN's MAG is informed of CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's MAG is informed of Mn'sMAG via LRO response and both MN's Mag and CN's MAGs are engaged in bi-ditectional PBU/PBA. <<<[Mohana]Here I have some comments. Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new option. Then MN's MAG can start PBU with CN's MAG. But the question I have is how does CN's MAG create the routing state for MN prefix. How does the CN's MAG know that this prefix is owned by MN and MN's MAG is actually proxying that prefix? The same when CN's MAG does PBU to MN's MAG. Probably, after getting the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But again to create the the routing state for CN's prefix at MN's MAG the MN's MAG should know the prefix CN owns is valid prefix. Otherwise, I don't see how a valid routing state can be created. So, by reading this I feel a prefix ownership kind of information is needed in the PBU.>>> [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's MAG must believe the prefix sent from MN's MAG is owned by MN. Because MN's MAG can check whether prefix is ownd by MN and used to create a valid routing before it send the prefix to the CN's MAG. That is to say we can assume there is a trust relationship between MN's MAG and CN's MAG. In oder for this, two possible ways in my mind are, 1) we assume a prior agreement between MN's MAG and CN's MAG. 2) the second way is we use IPSEC to setup Security association between MN's MAG and CN's MAG. By these two ways mentioned above, we can have trust relationship between MAGs, But what if MN's MAG establish trust relationship with CN's MAG and send the forged MN's prefix to CN's MAG, I think the prefix ownership validation may be useful in this scenario to help create valid routing state at CN's MAGs Therefore I would like to address this security threat in our solution I-D.Thanks for your good points. In the handover mechanims in section 4.1.1, it is mentioned that the nMAG1 will get context from old MAG (pMAG1). <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's MAG, how can CN's MAG know that this prefix of MN is valid and nMAG1 is proxying the preifx. Bcos during handoff, the LMA is not involved. nMAG1 has no issue in knowing that MN;s prefix is given by LMA because when it does PBU to LMA it will know that this is a valid prefix. But that is not the case with CN's MAG.>>> [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and keeps on communication with CN, there is no trust relationship beforehand between nMAG1 and MAG2 to which CN is connected. That is true. But I think MN's prefix will keep unchanged during handover. The only change to MN is MN's Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to validate MN's prefix ownership each time MN hands over? In my understanding, prefix ownership validation can be understood as routing reachability test(RRT) procedure defined in the RFC3775. But I am not sure RRT procedure will be done each time MN hands over according to RFC3775. Also in section 4.1 in second paragraph it is mentioned that MAG can send LRO req to LMA when Mn and CN are not attached to same MAG. <<<[Mohana] In this case, how does MAG know the CN address. What value will be attached in the Mn-CN pair mobility option. Is there some L2 message sent from Mn to MAG and all CN addresses are given in these. Probably such mentioning will be useful>>> [Qin]: How MAG know the CN address actually is beyond scope of this solution I-D. The possible way is MAG may look at data packet' destination address to know CN address.For the case where one MN communicates with one CN, MN-CN pair mobility option may include one MN's info and one CN's info. MN's. For the case where one MN communciates with several CNs, MN-CN pair mobility option may include one MN's info and several CNs' info. I have more comments. But rather than sending all at once I thought I will stop here for now. Thanks. > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 26, 2009 4:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Proxy MIP extension for local routing optimization > Author(s) : W. Wu, B. Sarikaya > Filename : draft-wu-netext-local-ro-04.txt > Pages : 32 > Date : 2009-10-26 > > This document extends local routing in proxy Mobile IPv6 and defines > a localized routing optimization protocol within one PMIPv6 domain. > The protocol supports IPv4 transport network operation, IPv4 home > address mobility and handover. The Local mobility anchor/mobile > access gateway initiates local routing for the mobile and > correspondent node by sending messages to each mobile access > gateway/local mobility anchor. In case the correspondent node is > connected to another local mobility anchor, the local mobility > anchors connected by the correspondent node needs to be discovered > firstly so that it can notify its mobile access gateways attached by > the correspondent node to the mobile access gateway attached by the > mobile node afterwards. Mobile access gateways create and refresh > bindings > using proxy binding update and acknowledgement messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From Mohana.Jeyatharan@sg.panasonic.com Thu Nov 19 19:23:02 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42613A67B0 for ; Thu, 19 Nov 2009 19:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.71 X-Spam-Level: * X-Spam-Status: No, score=1.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_26=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqjtk2Ivcqd3 for ; Thu, 19 Nov 2009 19:23:01 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 65BDB3A67D8 for ; Thu, 19 Nov 2009 19:23:01 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id nAK3Mslq012160; Fri, 20 Nov 2009 12:22:54 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id nAK3MnP27675; Fri, 20 Nov 2009 12:22:50 +0900 (JST) 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, 20 Nov 2009 11:22:47 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FB6C@pslexc01.psl.local> In-Reply-To: <4B057D7A.10705@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt Thread-Index: AcppPBl9DBGOU++ERqKnAXKVgVkIAAAUkwOA References: <5F09D220B62F79418461A978CA0921BD039D908A@pslexc01.psl.local> <4B057D7A.10705@nw.neclab.eu> From: "Mohana Jeyatharan" To: "Marco Liebsch" Cc: netext@ietf.org Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 03:23:02 -0000 Hi Marco, Thanks for reply. Please see few minor comments in line. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Marco Liebsch > Sent: Friday, November 20, 2009 1:17 AM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps- > 00.txt >=20 > Hi Mohana, >=20 > thanks again for your comments. All of them are valuable and, as said > during > last week's meeting, we'll take them in the next update into account. > Please see in-line for specific feedback. >=20 >=20 > Mohana Jeyatharan schrieb: > > > > Hi all, > > > > > > > > I went through the draft and have few comments. > > > > > > > > > > > > 1)Introduction first para says > > > > " Even though two communicating MNs might be attached to the > > > > same MAG or to different MAGs of the same local mobility domain, > > > > packets will traverse the MNs' LMA(s)." > > > > [Mohana] Mn and CN may be better word. Bcos later in draft communication > > > > End points are defined as MN and CN. > > > Yes, definitely we should keep this consistent. >=20 > > > > > > 2)Introduction second para says > > > > " Objectives of designing a solution for localized routing in PMIPv6 > > > > are to specify protocol messages and enable associated protocol > > > > operation between PMIPv6 components to support the set up of a direct > > > > routing path for data packets between the MNs' MAGs without > > > > forwarding these packets through the MNs' LMA(s) and to maintain > > > > localized routing in case one or both MNs handover to a different > > > > MAG." > > > > > > > > [Mohana] Here again it says that direct path between MN's MAGs. I > > think it is between Mn's MAG and CN's MAG. > > > True. >=20 > > > > > > 3)In the conventions and terminology section > > > > > > > > The second bullet: > > > > > > > > Correspondent Node (CN): Correspondent Node with or without IP > > > > mobility support. The CN represents the communication peer of an > > > > MN, which is attached to a MAG and registered with an LMA > > > > according to the PMIPv6 specification. > > > > > > > > [Mohana]The usage of "an" in front of MN and LMA should be changed to a. > > > Ok. [Mohana] Here my initial thinking was, if it is a mobile node and a local mobility anchor then the usage of a appropriate. But if you consider it as a MN(making sound "em") and LMA(making sound "el"), then usage of an is also possible. So, I will leave it to your'll to decide. >=20 > > > > > > 4)In the conventions and terminology section > > > > > > > > The third bullet: there is mentioning about a single PMIPv6 domain. > > > > [Mohana] Is it MN and CN placed in single operator/provider domain > > running PMIPv6? > > > Yes, true. This is still from the previous understanding of the > localized routing scope. > We'll update the description. >=20 > > > > > > 5)In the conventions and terminology section > > > > Fourth bullet mentions about IDs > > > > > > > > [Mohana] Is it only ID? What other information stored. What are these > > IDs? > > > > Perhaps a description will be good. > > > One example could be the MNID as per RFC5213, which is stored together > with > localized routing states. Could also be localized routing specific IDs > which serve > as a key to the MN's states, but we should not assume anything from a > solution > here. So, do you think describing the MNID as specific example is > sufficient? >=20 [Mohana] Probably MNID as defined in RFC 5213 will suffice. But I=20 Think some more parameters are needed in the MAG. Such as CN prefix and CN MAG address. I leave it to your'll to decide whether this needs to be captured in conventions and terminology section. When we are talking about routing state, then probably these needs to be captured as well. > > > > 6)In section 3.1 general observation section 1st para > > > > > > > > " Following the architecture of PMIPv6, rather entities of the network > > > > infrastructure are dedicated to perform signaling to set up a more > > > > direct route between an MN and a CN." > > > > > > > > [Mohana] I am not sure the meaning of this. Does it mean that when > > PMIP is present, RO needs to be established by using signaling between > > network entities? Perhaps a rewording is useful. > > > It means that MNs cannot perform mobility signaling as per requirement > of NetLMM, which applies > also for localized routing set up. The paragraph just explains that > network components, most probably > PMIPv6 specific components (MAG, LMA) need to take over this > responsibility and perform signaling > to set up a MN's localized routing path. >=20 > I'll try to find better wording, assumed you agree to the explanation > above. [Mohana] Ok, thanks. Marco I understood your intention but the wording was not clear when I read. As you mentioned a re-wording might be useful. > > > > > > 7)In section 3.1 general observation section last paragraph > > > > [Mohana] It is mentioned two benefits of loacl MAG routing.There is > > mentioning about lower cost, lower delay, lower packet loss. But > > clear indication as to the two benefits was not present. > > > They're in, but not so obvious, as I must admit. One is the costs aspect > (MAG-LMA > more costly), the other is the benefit for the user (delay). I'll write > to find clearer text. >=20 > > > > > > 8) In section 3.2 all mentioning is about "PMIPv6 domain". > > > > [Mohana] I do not want to start the discussion again. But, isn't it > > better to say what this PMIPv6 domain is. MN and CN in same operator > > domain or something like that. Bcos there is another section on > > roaming which is different from this. > > > Yes, same as above and still not yet updated in this version. > Thanks for the hint, we'll rewrite this for the update. >=20 > > > > > > 9) [Mohana]Again in section 3.2, there is mentioning about some race > > issue in multiple LMA > > > > Case, when there is handoff. But no clear description of such issue > > is highlighted. A small description will be good. > > > Ok, I'll add text here. [Mohana] Thanks. Going through the solution drafts we have, I could not find clear description of the racing issue. Perhaps your solution draft covered this. > > > > > > 10) In section 3.2, the local MAG issues are highlighted into > > cases(case A11, A..) and again some issues (multiple LMA, handoff in > > multiple LMA) are captured in bullet form. I am not sure whether > > there are any overlap in text here. > > > Maybe there is some overlap. A11 etc. analyze issues that come with a > particular > topology (multi-LMA etc). The bullet list summarizes general problems, > which may > also cover one or the other issue from above. I think it makes sense to > have > problems summarized in one place, even though they may appear at a > different > place already with details about where the problem comes from. >=20 [Mohana] Ok, thanks. That is good. > > > > > > 11)Section on IPv4 considerations. I think the current text is fine. > > It is not too complex and highlights how local MAG routing canbe done > > when there is IPv4 HoA or IPv4 transport. > > > Ok, thanks. Your review is based on version 00. For the latest update, > we had to > remove the NAT and the private IPv4 address conflict,.as the solution > will not > address them. Hope the text is still clear in version1. [Mohana] Saw some text removal in the revised version. I will wait for the revised version. > Thanks and best regards, > marco >=20 > > > > > > BR, > > > > Mohana > > > > > > >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Mohana.Jeyatharan@sg.panasonic.com Thu Nov 19 20:11:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D3F3A6890 for ; Thu, 19 Nov 2009 20:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.31 X-Spam-Level: ** X-Spam-Status: No, score=2.31 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm5MWN1B5P6R for ; Thu, 19 Nov 2009 20:11:11 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 881173A685E for ; Thu, 19 Nov 2009 20:11:09 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAK4AvRj004852; Fri, 20 Nov 2009 13:10:57 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id nAK4App28365; Fri, 20 Nov 2009 13:10:52 +0900 (JST) 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, 20 Nov 2009 12:10:50 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FB9A@pslexc01.psl.local> In-Reply-To: <006601ca6987$e49609a0$420ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on :draft-wu-netext-local-ro-04.txt Thread-Index: Acpph+SoTpsbGDNcToeEBkJj7eWZvwACN5mg References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> <006601ca6987$e49609a0$420ca40a@china.huawei.com> From: "Mohana Jeyatharan" To: "Qin Wu" Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 04:11:13 -0000 Hi Qin, Thanks for reply. Please see some replies in-line. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, November 20, 2009 10:19 AM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt >=20 > Hi, Mohana: > Sorry for my late reply. Also thank you for your review and comments. > please see my reply inline. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" > Cc: > Sent: Monday, November 16, 2009 9:59 AM > Subject: Comments on :draft-wu-netext-local-ro-04.txt >=20 >=20 >=20 > Hi Qin, >=20 > Read your ID. I have few comments. >=20 > Please see below. >=20 > BR, > Mohana >=20 > In abstract, > "In case the correspondent node is > connected to another local mobility anchor, the local mobility > anchors connected by the correspondent node needs to be discovered > firstly so that it can notify its mobile access gateways attached by > the correspondent node to the mobile access gateway attached by the > mobile node afterwards." >=20 > <<<[Mohana] In abstract it is not very clear which entitiy notifies CN's > MAG to MN's MAG. Perhaps a rewording may be useful>>> >=20 > [Qin]: Yes, what we are really saying here is CN's LMA will notify CN's > MAG to MN's MAG when MN's MAG > communicate with CN's LMA using normal PBU/PBA. Maybe the proper way to > say would be > " > so that the discovered local mobility anchor notity its mobile access > gateways attached by the correspondent node...... > " [Mohana] So, the description is tied to CN's LMA notifying MN's MAG to CN's MAG. Ok, understand. But some description on MN's LMA notifying CN's MAG to MN's MAG will be also useful in the inter-LMA scenario. What I am not clear is why is MN's MAG connected to CN's LMA? Probably this is another scenario addressed in scetion 7(inter LMA case). Anyway I will leave it for now. If MN's MAG is connected to CN's LMA, then such passing (CN's LMA passing CN MAG address to MN's MAG)is propoer. Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA. > In abstract, Mobile access gateways create and refresh bindings > using proxy binding update and acknowledgement messages. >=20 > <<<[Mohana] What is the reason for this. Is this refering to PBU to LMA > or PBU to MAG? Perhaps more clarity on this will help.>>> >=20 > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create binding > when it is the first time for MAGs to setup localized routing path. > during handover case, PBU/PBA will be used between MAGs to refresh binding. > The reason to create and refresh bindings between MAGs attached by mobile > node and correspondent node is quite similar to correspondent registration > in the Mobile IPv6 Routing optimization between mobile node and > correspondent node described in the section 11.7.2 of RFC3775. > i.e., allowing correspondent node to cache mobile node's proxy care-of > address or allowing mobile node to cache correspondent node' proxy care-of > address, [Mohana]I agree with your approach of using PBU/PBA for routing state setup and tunnel setup between MAGs and think that is a good approach and tied to RFC 5213 way. From further reading of your draft I understand this. All I wanted to say is that in abstract, a mentioning of PBU/PBA from MAG to MAG introduces more clarity. That is all. >=20 > In conventions used section it is mentioned >=20 > Local routing: Traffic between MN and CN does not pass through LMA > and is locally routed in the same PMIPv6 domain. >=20 > <<<[Mohana] Perhaps a re-wording may be necessary when referring to > PMIPv6 domain. This should be aligned with the PS draft terminology. It > should be same provider domain running PMIPv6 or some thing like > that.>>> >=20 > [Qin]: Okay, will check the wording to be consistent with PS draft. >=20 > In conventions used section it is mentioned > Local Routing Optimization Request (LROREQ): A message initiated by > the MAG or LMA requesting the MAG or LMA to establish local routing > optimization path between MN and at least one pair of CNs who > communicate with MN. > <<<[Mohana] why is there reference to at least one pair of CN. Are u > saying at least a single CN? Not very clear>>> >=20 > [Qin]: Right, thank for your good catching and correction. The reason to > say at least one CN is > in some cases, maybe MN will communicate with more than one CN, in this > sense, LROREQ > message may be sent from MN's LMA to each MAGs attached by serveral CNs > which is communicating with MN. > or sent from MN's MAG to each LMA which is registered by more than one CNs > which is communicating with MN during inter-LMA handover case. >=20 [Mohana]Ok, sure I understand your intention proabably a minor re-wording would do. > In section 3 Scenario analysis for PMIPv6 local routing >=20 > <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. > Again I think this should be single administrative/provider domain > running PMIpv6.>>> >=20 > [Qin]: Okay. >=20 > In figure 1, > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to > LMA.>>> >=20 > [Qin]: I am okay with this change in the figure 1. >=20 > In last para in section 3 which is > In all the above scenarios, MN is allowed to roam within its PMIPv6 > domain (i.e, MN's home domain in which MN's LMA is located) or move > from one PMIPv6 domains(i.e., MN's visited domains)to another. CN > should stay with MN within the same PMIPv6 domain, e.g., MN moves to > the visited domain to which CN belongs. Another example is MN and CN > move to the same visited domain to which MN's LMA or CN's LMA does > not belong. > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative > domain. Probably re-writing with respect to MN in home or visited domain > and CN inhome or visited domain may be useful. Currently the text is > not very clear>>> >=20 > [Qin]: Agree there is room for improvement here, this paragraph will be > reworded in accordance with the > terminologies used in the PS draft [Mohana] Ok, thanks. > In section 4, > <<<[Mohana] the first bullet should be changed to administrative domain > instaed of PMIPv6 domain. The second bullet says MN and CN attached to > same LMA. But in section 3 it is mentioned inter LMA scenario as well. > So, I am a bit confused as to whether the solution is not handling inter > LMA scenario.>>> >=20 > [Qin]: Yes, inter LMA scenario will be handled in one separate section of > our Solution I-D. Our solution I-D mainly focuses on specifying the > localize drouting protocol based on the first two scenarios described in > the section 3. the common aspect of the first two scenarios is it does not > require PMIP6 mobility entities discovery described in the PS draft. As > regarding to the inter-LMA local routing scenario, it depends on PMIP6 > mobility entities discovery, extra extended PMIP6 signaling is required > between MN's MAG and CN's LMA. Therefore inter-LMA local routing case is > separated from section 4 which is concentrating on the first two scenarios > and addressed in the independent section, i.e., section 7. [Mohana] Ok, understand. Do not know why I got confused. Probably a section outline may be helpful and I leave it to you to handle. >=20 > In section 4.1 > <<<[Mohana] In this section there is reference to three different types > of flags such as intra-LMA local routing flag, intra-MAG local routing > flag, Enable detect local routing flag. A description of these in > section 2 would be better for easy understanding.>>> >=20 > [Qin]: Okay. Thank for your suggestion. >=20 > In section 4.1, para 3, it is mentioned After successful local routing > optimization process, if MN and CN > attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA > localrouting flag is set to value one, the MAG1 to which the MN > attaches may send PBU message to the MAG2 which the CN attaches to. > <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I > think you are referring to MN connected to MAG 1 and CN connected to > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between > th etwo MAGs. The sentence is not clear.>>> >=20 > [Qin]: Okay, maybe we could say: > " > MAG1 to which the MN is connected may send PBU message to the MAG2 to > which the CN > is connected. > " [Mohana] probably somewords along the above lines may be useful. > In section 4.1, in para 3 it is mentioned that MN's MAG is informed of > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's MAG > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's MAGs > are engaged in bi-ditectional PBU/PBA. >=20 > <<<[Mohana]Here I have some comments. > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new > option. Then MN's MAG can start PBU with CN's MAG. But the question I > have is how does CN's MAG create the routing state for MN prefix. How > does the CN's MAG know that this prefix is owned by MN and MN's MAG is > actually proxying that prefix? >=20 >=20 > The same when CN's MAG does PBU to MN's MAG. Probably, after getting > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But again > to create the the routing state for CN's prefix at MN's MAG the MN's MAG > should know the prefix CN owns is valid prefix. Otherwise, I don't see > how a valid routing state can be created. >=20 > So, by reading this I feel a prefix ownership kind of information is > needed in the PBU.>>> >=20 > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's MAG must > believe the prefix sent from MN's MAG is owned by MN. Because MN's MAG can > check whether prefix is ownd by MN and used to create a valid routing > before it send the prefix to the CN's MAG. That is to say we can assume > there is a trust relationship between MN's MAG and CN's MAG. In oder for > this, two possible ways in my mind are, > 1) we assume a prior agreement between MN's MAG and CN's MAG. > 2) the second way is we use IPSEC to setup Security association between > MN's MAG and CN's MAG. > By these two ways mentioned above, we can have trust relationship between > MAGs, But what if MN's MAG establish trust relationship with CN's MAG and > send the forged MN's prefix to CN's MAG, I think the prefix ownership > validation may be useful in this scenario to help create valid routing > state at CN's MAGs > Therefore I would like to address this security threat in our solution I- > D.Thanks for your good points. [Mohana] Thanks Qin. Although I liked the Pbu way of establishing tunnel between MAGs, this prefix validation seemed important to address the security part. In RFC 5213, LMA is the prefix delegator so such issue is not needed. But here, the CN's MAG need such validation. Thanks for addressing this part. >=20 > In the handover mechanims in section 4.1.1, it is mentioned that the > nMAG1 will get context from old MAG (pMAG1). >=20 > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's MAG, > how can CN's MAG know that this prefix of MN is valid and nMAG1 is > proxying the preifx. Bcos during handoff, the LMA is not involved. > nMAG1 has no issue in knowing that MN;s prefix is given by LMA because > when it does PBU to LMA it will know that this is a valid prefix. But > that is not the case with CN's MAG.>>> >=20 > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and keeps on > communication with CN, there is no trust relationship beforehand between > nMAG1 and MAG2 to which CN is connected. That is true. But I think MN's > prefix will keep unchanged during handover. The only change to MN is MN's > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to validate > MN's prefix ownership each time MN hands over? In my understanding, prefix > ownership validation can be understood as routing reachability test(RRT) > procedure defined in the RFC3775. But I am not sure RRT procedure will be > done each time MN hands over according to RFC3775. [Mohana] For the handover case, just as in new establishment, the CN needs to know that the nMAG is proxying the prefix. So the prefix validation method as for new connection can be used here. The RFC 3775 way of prefix validation is one way but there is more signaling. Probably some assurance from LMA will be good regarding prefix validity. I think this is critical bcos in handover case, LMA is not involved. So to assure fast handoff one would not want the LMA to be involved. Furthermore, using your method a distributed handoff management can be done without the involvement of pMAG of MN notifying anything to CN'MAG. What I am saying is nMAG of MN can handle the PBU with CN's MAG without old MAG of MN being involved and this will expedite handover state convergence. The only thing that is needed in MN's nMAG to tell CN I own/proxy this prefix and prefix is valid. > Also in section 4.1 in second paragraph it is mentioned that MAG can > send LRO req to LMA when Mn and CN are not attached to same MAG. > <<<[Mohana] In this case, how does MAG know the CN address. What value > will be attached in the Mn-CN pair mobility option. Is there some L2 > message sent from Mn to MAG and all CN addresses are given in these. > Probably such mentioning will be useful>>> >=20 > [Qin]: How MAG know the CN address actually is beyond scope of this > solution I-D. The possible way is MAG may look at data packet' destination > address to know CN address.For the case where one MN communicates with one > CN, MN-CN pair mobility option may include one MN's info and one CN's info. > MN's. For the case where one MN communciates with several CNs, MN-CN pair > mobility option may include one MN's info and several CNs' info. [Mohana] Ok, thanks. I was just analyzing the benefits of MAG initiated RO as opposed to LMA initiated RO and wanted to highlight some benefits when MAG initiates RO. I guess how MAG gets the information need not be covered in the draft and it can be out of bound signaling. > I have more comments. But rather than sending all at once I thought I > will stop here for now. > Thanks. >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Monday, October 26, 2009 4:30 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Proxy MIP extension for local routing > optimization > > Author(s) : W. Wu, B. Sarikaya > > Filename : draft-wu-netext-local-ro-04.txt > > Pages : 32 > > Date : 2009-10-26 > > > > This document extends local routing in proxy Mobile IPv6 and defines > > a localized routing optimization protocol within one PMIPv6 domain. > > The protocol supports IPv4 transport network operation, IPv4 home > > address mobility and handover. The Local mobility anchor/mobile > > access gateway initiates local routing for the mobile and > > correspondent node by sending messages to each mobile access > > gateway/local mobility anchor. In case the correspondent node is > > connected to another local mobility anchor, the local mobility > > anchors connected by the correspondent node needs to be discovered > > firstly so that it can notify its mobile access gateways attached by > > the correspondent node to the mobile access gateway attached by the > > mobile node afterwards. Mobile access gateways create and refresh > > bindings > > using proxy binding update and acknowledgement messages. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. From Mohana.Jeyatharan@sg.panasonic.com Thu Nov 19 22:46:54 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F76D3A6909 for ; Thu, 19 Nov 2009 22:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.01 X-Spam-Level: * X-Spam-Status: No, score=1.01 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpL6AMWD1J4P for ; Thu, 19 Nov 2009 22:46:53 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 6ACB33A68F0 for ; Thu, 19 Nov 2009 22:46:52 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAK6kj1X010745 for ; Fri, 20 Nov 2009 15:46:45 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id nAK6khD00595 for ; Fri, 20 Nov 2009 15:46:44 +0900 (JST) 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, 20 Nov 2009 14:46:38 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FC29@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on bulk-PBU-bitmap-ID Thread-Index: AcpprTVrfYhSd9hASXOQ38aDTcznjw== From: "Mohana Jeyatharan" To: Subject: [netext] Follow up on bulk-PBU-bitmap-ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 06:46:54 -0000 Hi all, After the netext meeting the Chairs asked us to put some scenarios in the ML where the bitmap-bulk-PBU method can be used and to get general consensus from the group regarding applicability. I am highlighting the scenarios we presented in the Netext meeting in this mail. As presented in the meeting and also described in the draft-jeyatharan-netext-pmip-bulkPBU-bitmap-00, this method can be used to optimize bulk PBU in some scenarios. Please look at the scenarios below and give your feedback regarding scenario validity and the need for such method to address optimization in these scenarios. Ofcourse we are proposing this as an optional feature. A deployment may or may not use it. The scenarios are: Scenario 1:=20 Multiple new attachment requests arriving at MAG simultaneously and MAG performing multiple initial registration PBUs Scenario 2: Multiple MN re-registrations at a new LMA due to shut down of the previous serving LMA in a LMA failure scenario Scenario 3:=20 Multiple handoff requests arriving at MAG simultaneously and MAG performing multiple handoff registration PBUs. Scenario 4:=20 Multiple detachment events detected at MAG simultaneously and MAG performing multiple de-registration PBUs. Scenario 5:=20 Multiple initial registrations, handoff registrations and re-registration events happening simultaneously at MAG and MAG performing multiple PBUs tied to different type of events. Scenario 6:=20 MNs moving in group into MAG service area. As a result, MAG performing multiple handoff or multiple new attachment PBUs for MNs tied to group mobility. Scenario 7:=20 MAG offloading some MNs binding lists to another MAG for load balancing purpose. New MAG sends multiple PBU registrations for all the MNs that were transferred. Thanks. BR, Mohana From sunseawq@huawei.com Fri Nov 20 00:25:55 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC283A67AE for ; Fri, 20 Nov 2009 00:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZl0N4087d+8 for ; Fri, 20 Nov 2009 00:25:53 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 4B37F3A6839 for ; Fri, 20 Nov 2009 00:25:52 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTE00LWZFEPFT@szxga02-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 16:25:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTE007XQFEPX3@szxga02-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 16:25:37 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTE00NQFFEM3A@szxml04-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 16:25:35 +0800 (CST) Date: Fri, 20 Nov 2009 16:25:34 +0800 From: Qin Wu To: Mohana Jeyatharan Message-id: <04e701ca69bb$07ef6210$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> <006601ca6987$e49609a0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FB9A@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 08:25:55 -0000 Hi, Mohana: Thank for your quick response, please see my feedback inline. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: "Qin Wu" Cc: Sent: Friday, November 20, 2009 12:10 PM Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt Hi Qin, Thanks for reply. Please see some replies in-line. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, November 20, 2009 10:19 AM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > Hi, Mohana: > Sorry for my late reply. Also thank you for your review and comments. > please see my reply inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" > Cc: > Sent: Monday, November 16, 2009 9:59 AM > Subject: Comments on :draft-wu-netext-local-ro-04.txt > > > > Hi Qin, > > Read your ID. I have few comments. > > Please see below. > > BR, > Mohana > > In abstract, > "In case the correspondent node is > connected to another local mobility anchor, the local mobility > anchors connected by the correspondent node needs to be discovered > firstly so that it can notify its mobile access gateways attached by > the correspondent node to the mobile access gateway attached by the > mobile node afterwards." > > <<<[Mohana] In abstract it is not very clear which entitiy notifies CN's > MAG to MN's MAG. Perhaps a rewording may be useful>>> > > [Qin]: Yes, what we are really saying here is CN's LMA will notify CN's > MAG to MN's MAG when MN's MAG > communicate with CN's LMA using normal PBU/PBA. Maybe the proper way to > say would be > " > so that the discovered local mobility anchor notity its mobile access > gateways attached by the correspondent node...... > " [Mohana] So, the description is tied to CN's LMA notifying MN's MAG to CN's MAG. Ok, understand. But some description on MN's LMA notifying CN's MAG to MN's MAG will be also useful in the inter-LMA scenario. What I am not clear is why is MN's MAG connected to CN's LMA? Probably this is another scenario addressed in scetion 7(inter LMA case). Anyway I will leave it for now. If MN's MAG is connected to CN's LMA, then such passing (CN's LMA passing CN MAG address to MN's MAG)is propoer. Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA. [Qin]: Your understanding is correct. In the Inter-LMA local routing scenario, MN and CN attach to different MAGs and registers to different LMA respectively. In this scenario, MN's LMA does not know CN's MAG address, what we can do here is to let MN's MAG talk with CN's LMA, then CN's LMA can tell MN's MAG about CN's MAG address. but if MN and CN share the same LMA, then it does not matter whether MN's LMA or CN's LMA notitfy CN's MAG to MN's MAG, because MN's LMA is CN's LMA. > In abstract, Mobile access gateways create and refresh bindings > using proxy binding update and acknowledgement messages. > > <<<[Mohana] What is the reason for this. Is this refering to PBU to LMA > or PBU to MAG? Perhaps more clarity on this will help.>>> > > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create binding > when it is the first time for MAGs to setup localized routing path. > during handover case, PBU/PBA will be used between MAGs to refresh binding. > The reason to create and refresh bindings between MAGs attached by mobile > node and correspondent node is quite similar to correspondent registration > in the Mobile IPv6 Routing optimization between mobile node and > correspondent node described in the section 11.7.2 of RFC3775. > i.e., allowing correspondent node to cache mobile node's proxy care-of > address or allowing mobile node to cache correspondent node' proxy care-of > address, [Mohana]I agree with your approach of using PBU/PBA for routing state setup and tunnel setup between MAGs and think that is a good approach and tied to RFC 5213 way. From further reading of your draft I understand this. All I wanted to say is that in abstract, a mentioning of PBU/PBA from MAG to MAG introduces more clarity. That is all. [Qin]: Okay, agree. > > In conventions used section it is mentioned > > Local routing: Traffic between MN and CN does not pass through LMA > and is locally routed in the same PMIPv6 domain. > > <<<[Mohana] Perhaps a re-wording may be necessary when referring to > PMIPv6 domain. This should be aligned with the PS draft terminology. It > should be same provider domain running PMIPv6 or some thing like > that.>>> > > [Qin]: Okay, will check the wording to be consistent with PS draft. > > In conventions used section it is mentioned > Local Routing Optimization Request (LROREQ): A message initiated by > the MAG or LMA requesting the MAG or LMA to establish local routing > optimization path between MN and at least one pair of CNs who > communicate with MN. > <<<[Mohana] why is there reference to at least one pair of CN. Are u > saying at least a single CN? Not very clear>>> > > [Qin]: Right, thank for your good catching and correction. The reason to > say at least one CN is > in some cases, maybe MN will communicate with more than one CN, in this > sense, LROREQ > message may be sent from MN's LMA to each MAGs attached by serveral CNs > which is communicating with MN. > or sent from MN's MAG to each LMA which is registered by more than one CNs > which is communicating with MN during inter-LMA handover case. > [Mohana]Ok, sure I understand your intention proabably a minor re-wording would do. [Qin]: Right. > In section 3 Scenario analysis for PMIPv6 local routing > > <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. > Again I think this should be single administrative/provider domain > running PMIpv6.>>> > > [Qin]: Okay. > > In figure 1, > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to > LMA.>>> > > [Qin]: I am okay with this change in the figure 1. > > In last para in section 3 which is > In all the above scenarios, MN is allowed to roam within its PMIPv6 > domain (i.e, MN's home domain in which MN's LMA is located) or move > from one PMIPv6 domains(i.e., MN's visited domains)to another. CN > should stay with MN within the same PMIPv6 domain, e.g., MN moves to > the visited domain to which CN belongs. Another example is MN and CN > move to the same visited domain to which MN's LMA or CN's LMA does > not belong. > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative > domain. Probably re-writing with respect to MN in home or visited domain > and CN inhome or visited domain may be useful. Currently the text is > not very clear>>> > > [Qin]: Agree there is room for improvement here, this paragraph will be > reworded in accordance with the > terminologies used in the PS draft [Mohana] Ok, thanks. > In section 4, > <<<[Mohana] the first bullet should be changed to administrative domain > instaed of PMIPv6 domain. The second bullet says MN and CN attached to > same LMA. But in section 3 it is mentioned inter LMA scenario as well. > So, I am a bit confused as to whether the solution is not handling inter > LMA scenario.>>> > > [Qin]: Yes, inter LMA scenario will be handled in one separate section of > our Solution I-D. Our solution I-D mainly focuses on specifying the > localize drouting protocol based on the first two scenarios described in > the section 3. the common aspect of the first two scenarios is it does not > require PMIP6 mobility entities discovery described in the PS draft. As > regarding to the inter-LMA local routing scenario, it depends on PMIP6 > mobility entities discovery, extra extended PMIP6 signaling is required > between MN's MAG and CN's LMA. Therefore inter-LMA local routing case is > separated from section 4 which is concentrating on the first two scenarios > and addressed in the independent section, i.e., section 7. [Mohana] Ok, understand. Do not know why I got confused. Probably a section outline may be helpful and I leave it to you to handle. [Qin]: Okay. > > In section 4.1 > <<<[Mohana] In this section there is reference to three different types > of flags such as intra-LMA local routing flag, intra-MAG local routing > flag, Enable detect local routing flag. A description of these in > section 2 would be better for easy understanding.>>> > > [Qin]: Okay. Thank for your suggestion. > > In section 4.1, para 3, it is mentioned After successful local routing > optimization process, if MN and CN > attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA > localrouting flag is set to value one, the MAG1 to which the MN > attaches may send PBU message to the MAG2 which the CN attaches to. > <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I > think you are referring to MN connected to MAG 1 and CN connected to > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between > th etwo MAGs. The sentence is not clear.>>> > > [Qin]: Okay, maybe we could say: > " > MAG1 to which the MN is connected may send PBU message to the MAG2 to > which the CN > is connected. > " [Mohana] probably somewords along the above lines may be useful. > In section 4.1, in para 3 it is mentioned that MN's MAG is informed of > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's MAG > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's MAGs > are engaged in bi-ditectional PBU/PBA. > > <<<[Mohana]Here I have some comments. > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new > option. Then MN's MAG can start PBU with CN's MAG. But the question I > have is how does CN's MAG create the routing state for MN prefix. How > does the CN's MAG know that this prefix is owned by MN and MN's MAG is > actually proxying that prefix? > > > The same when CN's MAG does PBU to MN's MAG. Probably, after getting > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But again > to create the the routing state for CN's prefix at MN's MAG the MN's MAG > should know the prefix CN owns is valid prefix. Otherwise, I don't see > how a valid routing state can be created. > > So, by reading this I feel a prefix ownership kind of information is > needed in the PBU.>>> > > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's MAG must > believe the prefix sent from MN's MAG is owned by MN. Because MN's MAG can > check whether prefix is ownd by MN and used to create a valid routing > before it send the prefix to the CN's MAG. That is to say we can assume > there is a trust relationship between MN's MAG and CN's MAG. In oder for > this, two possible ways in my mind are, > 1) we assume a prior agreement between MN's MAG and CN's MAG. > 2) the second way is we use IPSEC to setup Security association between > MN's MAG and CN's MAG. > By these two ways mentioned above, we can have trust relationship between > MAGs, But what if MN's MAG establish trust relationship with CN's MAG and > send the forged MN's prefix to CN's MAG, I think the prefix ownership > validation may be useful in this scenario to help create valid routing > state at CN's MAGs > Therefore I would like to address this security threat in our solution I- > D.Thanks for your good points. [Mohana] Thanks Qin. Although I liked the Pbu way of establishing tunnel between MAGs, this prefix validation seemed important to address the security part. In RFC 5213, LMA is the prefix delegator so such issue is not needed. But here, the CN's MAG need such validation. Thanks for addressing this part. [Qin]Agree. > > In the handover mechanims in section 4.1.1, it is mentioned that the > nMAG1 will get context from old MAG (pMAG1). > > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's MAG, > how can CN's MAG know that this prefix of MN is valid and nMAG1 is > proxying the preifx. Bcos during handoff, the LMA is not involved. > nMAG1 has no issue in knowing that MN;s prefix is given by LMA because > when it does PBU to LMA it will know that this is a valid prefix. But > that is not the case with CN's MAG.>>> > > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and keeps on > communication with CN, there is no trust relationship beforehand between > nMAG1 and MAG2 to which CN is connected. That is true. But I think MN's > prefix will keep unchanged during handover. The only change to MN is MN's > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to validate > MN's prefix ownership each time MN hands over? In my understanding, prefix > ownership validation can be understood as routing reachability test(RRT) > procedure defined in the RFC3775. But I am not sure RRT procedure will be > done each time MN hands over according to RFC3775. [Mohana] For the handover case, just as in new establishment, the CN needs to know that the nMAG is proxying the prefix. So the prefix validation method as for new connection can be used here. The RFC 3775 way of prefix validation is one way but there is more signaling. Probably some assurance from LMA will be good regarding prefix validity. I think this is critical bcos in handover case, LMA is not involved. So to assure fast handoff one would not want the LMA to be involved. Furthermore, using your method a distributed handoff management can be done without the involvement of pMAG of MN notifying anything to CN'MAG. What I am saying is nMAG of MN can handle the PBU with CN's MAG without old MAG of MN being involved and this will expedite handover state convergence. The only thing that is needed in MN's nMAG to tell CN I own/proxy this prefix and prefix is valid. [Qin]: Okay, let me try to understand what you are explaining about prefix ownership validation. It seems to me, there are three possible ways to do this task: 1) pMAG of MN notify CN's MAG that MN's prefix is valid. 2) LMA of CN notify CN's MAG that MN's prefix is valid. 3) nMAG of MN itself notify CN's MAG that MN's prefix is valid In these three ways, the 3) seems more straightforward and efficient than 1) and 2) to fulfill prefix owndership validation during handover. But in some cases, e.g., MN and CN register to the same LMA, LMA may notify both MAGs associated with MN and CN that MN's prefix and CN's prefix are valid before PBU/PBA exchange between MN's MAG and CN's MAG happens. That is to say, prefix owndership validation also can be done during LROREQ/LRORSP exhange between MAG and LMA. Anyway, I think prefix ownership validation is necessary and useful feature that can be used to create valid routing. > Also in section 4.1 in second paragraph it is mentioned that MAG can > send LRO req to LMA when Mn and CN are not attached to same MAG. > <<<[Mohana] In this case, how does MAG know the CN address. What value > will be attached in the Mn-CN pair mobility option. Is there some L2 > message sent from Mn to MAG and all CN addresses are given in these. > Probably such mentioning will be useful>>> > > [Qin]: How MAG know the CN address actually is beyond scope of this > solution I-D. The possible way is MAG may look at data packet' destination > address to know CN address.For the case where one MN communicates with one > CN, MN-CN pair mobility option may include one MN's info and one CN's info. > MN's. For the case where one MN communciates with several CNs, MN-CN pair > mobility option may include one MN's info and several CNs' info. [Mohana] Ok, thanks. I was just analyzing the benefits of MAG initiated RO as opposed to LMA initiated RO and wanted to highlight some benefits when MAG initiates RO. I guess how MAG gets the information need not be covered in the draft and it can be out of bound signaling. [Qin]: Okay, understand. In my opinion, MAG initiated RO is more applicable to the local routing described in RFC 5213 than LMA initiated RO. But we can not exclude LMA to initiate RO as well. > I have more comments. But rather than sending all at once I thought I > will stop here for now. > Thanks. > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Monday, October 26, 2009 4:30 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Proxy MIP extension for local routing > optimization > > Author(s) : W. Wu, B. Sarikaya > > Filename : draft-wu-netext-local-ro-04.txt > > Pages : 32 > > Date : 2009-10-26 > > > > This document extends local routing in proxy Mobile IPv6 and defines > > a localized routing optimization protocol within one PMIPv6 domain. > > The protocol supports IPv4 transport network operation, IPv4 home > > address mobility and handover. The Local mobility anchor/mobile > > access gateway initiates local routing for the mobile and > > correspondent node by sending messages to each mobile access > > gateway/local mobility anchor. In case the correspondent node is > > connected to another local mobility anchor, the local mobility > > anchors connected by the correspondent node needs to be discovered > > firstly so that it can notify its mobile access gateways attached by > > the correspondent node to the mobile access gateway attached by the > > mobile node afterwards. Mobile access gateways create and refresh > > bindings > > using proxy binding update and acknowledgement messages. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. From sunseawq@huawei.com Fri Nov 20 01:35:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFA63A6A6D for ; Fri, 20 Nov 2009 01:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.179 X-Spam-Level: X-Spam-Status: No, score=0.179 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5-+fg6jy54m for ; Fri, 20 Nov 2009 01:35:56 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7666A3A6A7F for ; Fri, 20 Nov 2009 01:35:56 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTE00C5RILOHD@szxga03-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 17:34:37 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTE009HEILOJU@szxga03-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 17:34:36 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTE00C3HILOR9@szxml06-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 17:34:36 +0800 (CST) Date: Fri, 20 Nov 2009 17:34:35 +0800 From: Qin Wu To: Mohana Jeyatharan , netext@ietf.org Message-id: <051f01ca69c4$ac4db240$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5F09D220B62F79418461A978CA0921BD03B3FC29@pslexc01.psl.local> Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:35:57 -0000 Hi, Mohana: Take a look at the scenarios you summarized, I would like to make some comments, please see inline. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: Sent: Friday, November 20, 2009 2:46 PM Subject: [netext] Follow up on bulk-PBU-bitmap-ID > Hi all, > > After the netext meeting the Chairs asked us to put some scenarios in > the ML where the bitmap-bulk-PBU method can be used and to get general > consensus from the group regarding applicability. I am highlighting the > scenarios we presented in the Netext meeting in this mail. > > As presented in the meeting and also described in the > draft-jeyatharan-netext-pmip-bulkPBU-bitmap-00, this method can be used > to optimize bulk PBU in some scenarios. > > Please look at the scenarios below and give your feedback regarding > scenario validity and the need for such method to address optimization > in these scenarios. Ofcourse we are proposing this as an optional > feature. A deployment may or may not use it. [Qin]: I agree bitmap based Bulk PBU is optional feature and quite useful when a set of mobile node tied to one MAG has not formed one or several group. > The scenarios are: > Scenario 1: > Multiple new attachment requests arriving at MAG simultaneously and MAG > performing multiple initial registration PBUs [Qin]: In this scenario, You should require multiple new PBUs to be sent to the same LMA, right? > Scenario 2: > Multiple MN re-registrations at a new LMA due to shut down of the > previous serving LMA in a LMA failure scenario [Qin]: This scenario seems overlapped with bulk re-registration draft. In this scenario, the problem is how does MAG know the previous serving LMA is shut down. whether MN group has already formed on the MAG. > Scenario 3: > Multiple handoff requests arriving at MAG simultaneously and MAG > performing multiple handoff registration PBUs. [Qin]: I am wondering what's the difference between scenario 2 and scenario 3? In my understanding, when MN handover from previous MAG to the new MAG, MAG should also perform re-registration to the same LMA, what am I missing? I also found the handoff case is not covered by bulk re-registration draft. What's the reason? > Scenario 4: > Multiple detachment events detected at MAG simultaneously and MAG > performing multiple de-registration PBUs. [Qin]: This scenario is only useful when goups for a set of MN has not formed before de-registration happens. If MN's group ID has already been created, MAG can perform bulk de-registration PBU using MN's group ID. > Scenario 5: > Multiple initial registrations, handoff registrations and > re-registration events happening simultaneously at MAG and MAG > performing multiple PBUs tied to different type of events. [Qin]: It seems to me scenario5 is one combined case using scenario 1,2,3. I am wondering how does MAG handle PBUs for initial registration, handoff registration, re-registration in one message. Also I am difficult to understand that how LMA will process this message for different purposes at the same time. Therefore It is a good idea to consider this scenario. > Scenario 6: > MNs moving in group into MAG service area. As a result, MAG performing > multiple handoff or multiple new attachment PBUs for MNs tied to group > mobility. [Qin]: It seems to me this sccenario seems like NEMO scenario. I think this scenario is quite useful scenario. Suppose a set of MNs moving as one in one vechicle, How the MAG in the vechicle perform multiple new attachment PBUs when the vechicle is moving. Bitmap based bulk PBU is quite fit into this scenario. > Scenario 7: > MAG offloading some MNs binding lists to another MAG for load balancing > purpose. New MAG sends multiple PBU registrations for all the MNs that > were transferred. [Qin]: In my understanding, load balancing between LMAs is required. Because LMA is easier to be overloaded than MAGs. But I am not sure there is some requirement for load balancing between MAGs. Can you tell where this requirement come from? > Thanks. > > BR, > Mohana > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Fri Nov 20 01:44:20 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0323A6AAF for ; Fri, 20 Nov 2009 01:44:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m-4ueKBFJeE for ; Fri, 20 Nov 2009 01:44:20 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E0D7A3A6AAD for ; Fri, 20 Nov 2009 01:44:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id CBE852C0012CA for ; Fri, 20 Nov 2009 10:44:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm1zpud9fVei for ; Fri, 20 Nov 2009 10:44:09 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id ABF2E2C0002FE for ; Fri, 20 Nov 2009 10:44:04 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:44:05 +0100 Message-ID: <4B0664E5.6060901@nw.neclab.eu> Date: Fri, 20 Nov 2009 10:44:05 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2009 09:44:05.0331 (UTC) FILETIME=[FFB9A230:01CA69C5] Subject: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:44:21 -0000 Folks, as a follow up of our discussion about localized routing in a multi-LMA setup, I'd like to initiate a general and clarifying discussion about signaling paths to set up and maintain a localized routing path, as current solution proposals cover different approaches. We had the discussion about PMIPv6 domains vs provider domains and came to the conclusion that it's not mandatory for MN and CN to share the same PMIPv6 domain. Assume MN connects to MAG1 and LMA1, whereas CN connects to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 shares a PMIP domain with LMA2. We cannot assume that MAG1 shares a PMIP domain with LMA2. Now, there are two questions to solve: (1) Who detects and initiates localized routing, MAG or LMA (2) How to synchronize distributed states? Will LMA1 contact LMA2 or will MAG1 contact LMA2 If an existing SA is the only indicator to set up a PMIPv6 domain, then one solution could be to set up an SA dynamically between MAG1 and LMA2, which needs to be re-done every time MN1 performs a handover to a different MAG, say MAG1*. This may be a disadvantage and will blow up PMIPv6 domains, which are rather administratively configured, in my opinion. The other alternative is that PMIPv6 domain stractures are not touched and LMA1 will signal with LMA2 to synchronize states of MN and CN. Advantage would be that LMAs do not change during a handover and will keep states on one place. Any opinions? marco From Mohana.Jeyatharan@sg.panasonic.com Fri Nov 20 01:44:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59EE228C119 for ; Fri, 20 Nov 2009 01:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.235 X-Spam-Level: ** X-Spam-Status: No, score=2.235 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSpkznRtvVOv for ; Fri, 20 Nov 2009 01:44:43 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 5451F28C124 for ; Fri, 20 Nov 2009 01:44:41 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id nAK9iSaP009006; Fri, 20 Nov 2009 18:44:28 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id nAK9iNO06598; Fri, 20 Nov 2009 18:44:24 +0900 (JST) 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, 20 Nov 2009 17:44:22 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FCDA@pslexc01.psl.local> In-Reply-To: <04e701ca69bb$07ef6210$420ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on :draft-wu-netext-local-ro-04.txt Thread-Index: Acppuw2wjzqKF+y+THC1iKkmg0+VWwACSOgQ References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> <006601ca6987$e49609a0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FB9A@pslexc01.psl.local> <04e701ca69bb$07ef6210$420ca40a@china.huawei.com> From: "Mohana Jeyatharan" To: "Qin Wu" Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:44:45 -0000 Hi Qin, Please see my short comments below. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, November 20, 2009 4:26 PM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt >=20 > Hi, Mohana: > Thank for your quick response, please see my feedback inline. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" > Cc: > Sent: Friday, November 20, 2009 12:10 PM > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt >=20 >=20 > Hi Qin, >=20 > Thanks for reply. Please see some replies in-line. >=20 > BR, > Mohana >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Friday, November 20, 2009 10:19 AM > > To: Mohana Jeyatharan > > Cc: netext@ietf.org > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > > > Hi, Mohana: > > Sorry for my late reply. Also thank you for your review and comments. > > please see my reply inline. > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Mohana Jeyatharan" > > To: "Qin Wu" > > Cc: > > Sent: Monday, November 16, 2009 9:59 AM > > Subject: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > > > Hi Qin, > > > > Read your ID. I have few comments. > > > > Please see below. > > > > BR, > > Mohana > > > > In abstract, > > "In case the correspondent node is > > connected to another local mobility anchor, the local mobility > > anchors connected by the correspondent node needs to be discovered > > firstly so that it can notify its mobile access gateways attached > by > > the correspondent node to the mobile access gateway attached by > the > > mobile node afterwards." > > > > <<<[Mohana] In abstract it is not very clear which entitiy notifies > CN's > > MAG to MN's MAG. Perhaps a rewording may be useful>>> > > > > [Qin]: Yes, what we are really saying here is CN's LMA will notify > CN's > > MAG to MN's MAG when MN's MAG > > communicate with CN's LMA using normal PBU/PBA. Maybe the proper way > to > > say would be > > " > > so that the discovered local mobility anchor notity its mobile access > > gateways attached by the correspondent node...... > > " > [Mohana] So, the description is tied to CN's LMA notifying MN's MAG to > CN's MAG. Ok, understand. But some description on MN's LMA notifying > CN's MAG to MN's MAG will be also useful in the inter-LMA scenario. > What I am not clear is why is MN's MAG connected to CN's LMA? Probably > this is another scenario addressed in scetion 7(inter LMA case). Anyway > I will leave it for now. If MN's MAG is connected to CN's LMA, then > such passing (CN's LMA passing CN MAG address to MN's MAG)is propoer. > Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA. >=20 > [Qin]: Your understanding is correct. In the Inter-LMA local routing > scenario, > MN and CN attach to different MAGs and registers to different LMA > respectively. > In this scenario, MN's LMA does not know CN's MAG address, what we can do > here > is to let MN's MAG talk with CN's LMA, then CN's LMA can tell MN's MAG > about > CN's MAG address. > but if MN and CN share the same LMA, then it does not matter whether MN's > LMA or > CN's LMA notitfy CN's MAG to MN's MAG, > because MN's LMA is CN's LMA. [Mohana] Ok, do not want to dwell on this too much. So you are saying that CN MAG address is passed to MN MAG by CN LMA. A short question I have is how does CN LMA address is known to MN MAG. Anyway, I need to read the inter-LMA part in more detail. >=20 > > In abstract, Mobile access gateways create and refresh bindings > > using proxy binding update and acknowledgement messages. > > > > <<<[Mohana] What is the reason for this. Is this refering to PBU to > LMA > > or PBU to MAG? Perhaps more clarity on this will help.>>> > > > > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create > binding > > when it is the first time for MAGs to setup localized routing path. > > during handover case, PBU/PBA will be used between MAGs to refresh > binding. > > The reason to create and refresh bindings between MAGs attached by > mobile > > node and correspondent node is quite similar to correspondent > registration > > in the Mobile IPv6 Routing optimization between mobile node and > > correspondent node described in the section 11.7.2 of RFC3775. > > i.e., allowing correspondent node to cache mobile node's proxy care-of > > address or allowing mobile node to cache correspondent node' proxy > care-of > > address, > [Mohana]I agree with your approach of using PBU/PBA for routing state > setup and tunnel setup between MAGs and think that is a good approach > and tied to RFC 5213 way. From further reading of your draft I > understand this. All I wanted to say is that in abstract, a mentioning > of PBU/PBA from MAG to MAG introduces more clarity. That is all. >=20 > [Qin]: Okay, agree. >=20 > > > > In conventions used section it is mentioned > > > > Local routing: Traffic between MN and CN does not pass through LMA > > and is locally routed in the same PMIPv6 domain. > > > > <<<[Mohana] Perhaps a re-wording may be necessary when referring to > > PMIPv6 domain. This should be aligned with the PS draft terminology. > It > > should be same provider domain running PMIPv6 or some thing like > > that.>>> > > > > [Qin]: Okay, will check the wording to be consistent with PS draft. > > > > In conventions used section it is mentioned > > Local Routing Optimization Request (LROREQ): A message initiated by > > the MAG or LMA requesting the MAG or LMA to establish local routing > > optimization path between MN and at least one pair of CNs who > > communicate with MN. > > <<<[Mohana] why is there reference to at least one pair of CN. Are u > > saying at least a single CN? Not very clear>>> > > > > [Qin]: Right, thank for your good catching and correction. The reason > to > > say at least one CN is > > in some cases, maybe MN will communicate with more than one CN, in > this > > sense, LROREQ > > message may be sent from MN's LMA to each MAGs attached by serveral > CNs > > which is communicating with MN. > > or sent from MN's MAG to each LMA which is registered by more than one > CNs > > which is communicating with MN during inter-LMA handover case. > > > [Mohana]Ok, sure I understand your intention proabably a minor > re-wording would do. >=20 > [Qin]: Right. >=20 > > In section 3 Scenario analysis for PMIPv6 local routing > > > > <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. > > Again I think this should be single administrative/provider domain > > running PMIpv6.>>> > > > > [Qin]: Okay. > > > > In figure 1, > > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to > > LMA.>>> > > > > [Qin]: I am okay with this change in the figure 1. > > > > In last para in section 3 which is > > In all the above scenarios, MN is allowed to roam within its PMIPv6 > > domain (i.e, MN's home domain in which MN's LMA is located) or move > > from one PMIPv6 domains(i.e., MN's visited domains)to another. CN > > should stay with MN within the same PMIPv6 domain, e.g., MN moves > to > > the visited domain to which CN belongs. Another example is MN and > CN > > move to the same visited domain to which MN's LMA or CN's LMA does > > not belong. > > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative > > domain. Probably re-writing with respect to MN in home or visited > domain > > and CN inhome or visited domain may be useful. Currently the text is > > not very clear>>> > > > > [Qin]: Agree there is room for improvement here, this paragraph will > be > > reworded in accordance with the > > terminologies used in the PS draft > [Mohana] Ok, thanks. >=20 > > In section 4, > > <<<[Mohana] the first bullet should be changed to administrative > domain > > instaed of PMIPv6 domain. The second bullet says MN and CN attached > to > > same LMA. But in section 3 it is mentioned inter LMA scenario as > well. > > So, I am a bit confused as to whether the solution is not handling > inter > > LMA scenario.>>> > > > > [Qin]: Yes, inter LMA scenario will be handled in one separate section > of > > our Solution I-D. Our solution I-D mainly focuses on specifying the > > localize drouting protocol based on the first two scenarios described > in > > the section 3. the common aspect of the first two scenarios is it does > not > > require PMIP6 mobility entities discovery described in the PS draft. > As > > regarding to the inter-LMA local routing scenario, it depends on PMIP6 > > mobility entities discovery, extra extended PMIP6 signaling is > required > > between MN's MAG and CN's LMA. Therefore inter-LMA local routing case > is > > separated from section 4 which is concentrating on the first two > scenarios > > and addressed in the independent section, i.e., section 7. >=20 >=20 > [Mohana] Ok, understand. Do not know why I got confused. Probably a > section outline may be helpful and I leave it to you to handle. >=20 > [Qin]: Okay. >=20 > > > > In section 4.1 > > <<<[Mohana] In this section there is reference to three different > types > > of flags such as intra-LMA local routing flag, intra-MAG local routing > > flag, Enable detect local routing flag. A description of these in > > section 2 would be better for easy understanding.>>> > > > > [Qin]: Okay. Thank for your suggestion. > > > > In section 4.1, para 3, it is mentioned After successful local routing > > optimization process, if MN and CN > > attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA > > localrouting flag is set to value one, the MAG1 to which the MN > > attaches may send PBU message to the MAG2 which the CN attaches to. > > <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I > > think you are referring to MN connected to MAG 1 and CN connected to > > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between > > th etwo MAGs. The sentence is not clear.>>> > > > > [Qin]: Okay, maybe we could say: > > " > > MAG1 to which the MN is connected may send PBU message to the MAG2 to > > which the CN > > is connected. > > " > [Mohana] probably somewords along the above lines may be useful. >=20 > > In section 4.1, in para 3 it is mentioned that MN's MAG is informed of > > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's > MAG > > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's > MAGs > > are engaged in bi-ditectional PBU/PBA. > > > > <<<[Mohana]Here I have some comments. > > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new > > option. Then MN's MAG can start PBU with CN's MAG. But the question > I > > have is how does CN's MAG create the routing state for MN prefix. How > > does the CN's MAG know that this prefix is owned by MN and MN's MAG is > > actually proxying that prefix? > > > > > > The same when CN's MAG does PBU to MN's MAG. Probably, after getting > > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But > again > > to create the the routing state for CN's prefix at MN's MAG the MN's > MAG > > should know the prefix CN owns is valid prefix. Otherwise, I don't see > > how a valid routing state can be created. > > > > So, by reading this I feel a prefix ownership kind of information is > > needed in the PBU.>>> > > > > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's MAG > must > > believe the prefix sent from MN's MAG is owned by MN. Because MN's MAG > can > > check whether prefix is ownd by MN and used to create a valid routing > > before it send the prefix to the CN's MAG. That is to say we can > assume > > there is a trust relationship between MN's MAG and CN's MAG. In oder > for > > this, two possible ways in my mind are, > > 1) we assume a prior agreement between MN's MAG and CN's MAG. > > 2) the second way is we use IPSEC to setup Security association > between > > MN's MAG and CN's MAG. > > By these two ways mentioned above, we can have trust relationship > between > > MAGs, But what if MN's MAG establish trust relationship with CN's MAG > and > > send the forged MN's prefix to CN's MAG, I think the prefix ownership > > validation may be useful in this scenario to help create valid routing > > state at CN's MAGs > > Therefore I would like to address this security threat in our solution > I- > > D.Thanks for your good points. >=20 >=20 > [Mohana] Thanks Qin. Although I liked the Pbu way of establishing > tunnel between MAGs, this prefix validation seemed important to address > the security part. In RFC 5213, LMA is the prefix delegator so such > issue is not needed. But here, the CN's MAG need such validation. > Thanks for addressing this part. >=20 > [Qin]Agree. > > > > In the handover mechanims in section 4.1.1, it is mentioned that the > > nMAG1 will get context from old MAG (pMAG1). > > > > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's > MAG, > > how can CN's MAG know that this prefix of MN is valid and nMAG1 is > > proxying the preifx. Bcos during handoff, the LMA is not involved. > > nMAG1 has no issue in knowing that MN;s prefix is given by LMA because > > when it does PBU to LMA it will know that this is a valid prefix. But > > that is not the case with CN's MAG.>>> > > > > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and keeps > on > > communication with CN, there is no trust relationship beforehand > between > > nMAG1 and MAG2 to which CN is connected. That is true. But I think > MN's > > prefix will keep unchanged during handover. The only change to MN is > MN's > > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to validate > > MN's prefix ownership each time MN hands over? In my understanding, > prefix > > ownership validation can be understood as routing reachability > test(RRT) > > procedure defined in the RFC3775. But I am not sure RRT procedure will > be > > done each time MN hands over according to RFC3775. >=20 > [Mohana] For the handover case, just as in new establishment, the CN > needs to know that the nMAG is proxying the prefix. So the prefix > validation method as for new connection can be used here. The RFC 3775 > way of prefix validation is one way but there is more signaling. > Probably some assurance from LMA will be good regarding prefix validity. > I think this is critical bcos in handover case, LMA is not involved. So > to assure fast handoff one would not want the LMA to be involved. > Furthermore, using your method a distributed handoff management can be > done without the involvement of pMAG of MN notifying anything to CN'MAG. > What I am saying is nMAG of MN can handle the PBU with CN's MAG without > old MAG of MN being involved and this will expedite handover state > convergence. The only thing that is needed in MN's nMAG to tell CN I > own/proxy this prefix and prefix is valid. >=20 > [Qin]: Okay, let me try to understand what you are explaining about prefix > ownership validation. > It seems to me, there are three possible ways to do this task: > 1) pMAG of MN notify CN's MAG that MN's prefix is valid. > 2) LMA of CN notify CN's MAG that MN's prefix is valid. > 3) nMAG of MN itself notify CN's MAG that MN's prefix is valid > In these three ways, the 3) seems more straightforward and efficient than > 1) and 2) to fulfill prefix owndership validation during handover. > But in some cases, e.g., MN and CN register to the same LMA, LMA may > notify both MAGs associated with MN and CN that MN's prefix and CN's > prefix are valid before PBU/PBA exchange between MN's MAG and CN's MAG > happens. That is to say, prefix owndership validation also can be done > during LROREQ/LRORSP exhange between MAG and LMA. > Anyway, I think prefix ownership validation is necessary and useful > feature that can be used to create valid routing. >=20 [Mohana] Thanks for the good break down and analysis. As you have identified 3) seems more straightforward and efficient. When you are refering to LMA involved in prefix validation, I think you are refering to LMA initaited RO case. I need to further look at your ID for LMA initiated RO scenario and how LMA is involved during handoff procedures. I will get back to you soon on this with a little more comments on this procedure. Thanks. > > Also in section 4.1 in second paragraph it is mentioned that MAG can > > send LRO req to LMA when Mn and CN are not attached to same MAG. > > <<<[Mohana] In this case, how does MAG know the CN address. What > value > > will be attached in the Mn-CN pair mobility option. Is there some L2 > > message sent from Mn to MAG and all CN addresses are given in these. > > Probably such mentioning will be useful>>> > > > > [Qin]: How MAG know the CN address actually is beyond scope of this > > solution I-D. The possible way is MAG may look at data packet' > destination > > address to know CN address.For the case where one MN communicates with > one > > CN, MN-CN pair mobility option may include one MN's info and one CN's > info. > > MN's. For the case where one MN communciates with several CNs, MN-CN > pair > > mobility option may include one MN's info and several CNs' info. >=20 > [Mohana] Ok, thanks. I was just analyzing the benefits of MAG initiated > RO as opposed to LMA initiated RO and wanted to highlight some benefits > when MAG initiates RO. I guess how MAG gets the information need not be > covered in the draft and it can be out of bound signaling. >=20 > [Qin]: Okay, understand. In my opinion, MAG initiated RO is more > applicable to the local routing > described in RFC 5213 than LMA initiated RO. But we can not exclude LMA to > initiate RO as well. >=20 >=20 > > I have more comments. But rather than sending all at once I thought I > > will stop here for now. >=20 > > Thanks. > > > > > -----Original Message----- > > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] > > > On Behalf Of Internet-Drafts@ietf.org > > > Sent: Monday, October 26, 2009 4:30 PM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > Title : Proxy MIP extension for local routing > > optimization > > > Author(s) : W. Wu, B. Sarikaya > > > Filename : draft-wu-netext-local-ro-04.txt > > > Pages : 32 > > > Date : 2009-10-26 > > > > > > This document extends local routing in proxy Mobile IPv6 and defines > > > a localized routing optimization protocol within one PMIPv6 domain. > > > The protocol supports IPv4 transport network operation, IPv4 home > > > address mobility and handover. The Local mobility anchor/mobile > > > access gateway initiates local routing for the mobile and > > > correspondent node by sending messages to each mobile access > > > gateway/local mobility anchor. In case the correspondent node is > > > connected to another local mobility anchor, the local mobility > > > anchors connected by the correspondent node needs to be discovered > > > firstly so that it can notify its mobile access gateways attached > by > > > the correspondent node to the mobile access gateway attached by the > > > mobile node afterwards. Mobile access gateways create and refresh > > > bindings > > > using proxy binding update and acknowledgement messages. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. From Marco.Liebsch@nw.neclab.eu Fri Nov 20 02:09:29 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E6C3A6A62 for ; Fri, 20 Nov 2009 02:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPzlr+v1lvcf for ; Fri, 20 Nov 2009 02:09:28 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DF1E03A69A7 for ; Fri, 20 Nov 2009 02:09:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3DBDF2C0012CA; Fri, 20 Nov 2009 11:09:25 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAIrJ38+qp7I; Fri, 20 Nov 2009 11:09:25 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 0BBD72C0002FE; Fri, 20 Nov 2009 11:09:15 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 11:09:15 +0100 Message-ID: <4B066ACB.7060306@nw.neclab.eu> Date: Fri, 20 Nov 2009 11:09:15 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mohana Jeyatharan References: <5F09D220B62F79418461A978CA0921BD039D908A@pslexc01.psl.local> <4B057D7A.10705@nw.neclab.eu> <5F09D220B62F79418461A978CA0921BD03B3FB6C@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03B3FB6C@pslexc01.psl.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2009 10:09:15.0692 (UTC) FILETIME=[83F86EC0:01CA69C9] Cc: netext@ietf.org Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 10:09:29 -0000 Hi Mohana, please see in-line. Mohana Jeyatharan wrote: > Hi Marco, > > Thanks for reply. Please see few minor comments in line. > > BR, > Mohana > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> > Behalf > >> Of Marco Liebsch >> Sent: Friday, November 20, 2009 1:17 AM >> To: Mohana Jeyatharan >> Cc: netext@ietf.org >> Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps- >> 00.txt >> >> Hi Mohana, >> >> thanks again for your comments. All of them are valuable and, as said >> during >> last week's meeting, we'll take them in the next update into account. >> Please see in-line for specific feedback. >> >> >> Mohana Jeyatharan schrieb: >> >>> Hi all, >>> >>> >>> >>> I went through the draft and have few comments. >>> >>> >>> >>> >>> >>> 1)Introduction first para says >>> >>> " Even though two communicating MNs might be attached to the >>> >>> same MAG or to different MAGs of the same local mobility domain, >>> >>> packets will traverse the MNs' LMA(s)." >>> >>> [Mohana] Mn and CN may be better word. Bcos later in draft >>> > communication > >>> End points are defined as MN and CN. >>> >>> >> Yes, definitely we should keep this consistent. >> >> >>> 2)Introduction second para says >>> >>> " Objectives of designing a solution for localized routing in PMIPv6 >>> >>> are to specify protocol messages and enable associated protocol >>> >>> operation between PMIPv6 components to support the set up of a >>> > direct > >>> routing path for data packets between the MNs' MAGs without >>> >>> forwarding these packets through the MNs' LMA(s) and to maintain >>> >>> localized routing in case one or both MNs handover to a different >>> >>> MAG." >>> >>> >>> >>> [Mohana] Here again it says that direct path between MN's MAGs. I >>> think it is between Mn's MAG and CN's MAG. >>> >>> >> True. >> >> >>> 3)In the conventions and terminology section >>> >>> >>> >>> The second bullet: >>> >>> >>> >>> Correspondent Node (CN): Correspondent Node with or without IP >>> >>> mobility support. The CN represents the communication peer of >>> > an > >>> MN, which is attached to a MAG and registered with an LMA >>> >>> according to the PMIPv6 specification. >>> >>> >>> >>> [Mohana]The usage of "an" in front of MN and LMA should be changed >>> > to a. > >> Ok. >> > > [Mohana] Here my initial thinking was, if it is a mobile node and a > local mobility anchor then the usage of a appropriate. But if you > consider it as a MN(making sound "em") and LMA(making sound "el"), then > usage of an is also possible. > So, I will leave it to your'll to decide. > Since it's abbreviated, I thought s about the latter one :-) >>> 4)In the conventions and terminology section >>> >>> >>> >>> The third bullet: there is mentioning about a single PMIPv6 domain. >>> >>> [Mohana] Is it MN and CN placed in single operator/provider domain >>> running PMIPv6? >>> >>> >> Yes, true. This is still from the previous understanding of the >> localized routing scope. >> We'll update the description. >> >> >>> 5)In the conventions and terminology section >>> >>> Fourth bullet mentions about IDs >>> >>> >>> >>> [Mohana] Is it only ID? What other information stored. What are >>> > these > >>> IDs? >>> >>> Perhaps a description will be good. >>> >>> >> One example could be the MNID as per RFC5213, which is stored together >> with >> localized routing states. Could also be localized routing specific IDs >> which serve >> as a key to the MN's states, but we should not assume anything from a >> solution >> here. So, do you think describing the MNID as specific example is >> sufficient? >> >> > [Mohana] Probably MNID as defined in RFC 5213 will suffice. But I > Think some more parameters are needed in the MAG. Such as CN prefix and > CN MAG address. I leave it to your'll to decide whether this needs to be > captured in conventions and terminology section. When we are talking > about routing state, then probably these needs to be captured as well. > Of course prefixes are needed, but I did not consider them to be IDs. The term section was just to provide examples what we mean with localized routing states. But I agree that it's obvious to have prefixes and tunnel endpoints (MAGs) in the conceptual data structures to maintain localized routing states, I can add them for clarification. Thanks. for the hint. > >>> 6)In section 3.1 general observation section 1st para >>> >>> >>> >>> " Following the architecture of PMIPv6, rather entities of the >>> > network > >>> infrastructure are dedicated to perform signaling to set up a >>> > more > >>> direct route between an MN and a CN." >>> >>> >>> >>> [Mohana] I am not sure the meaning of this. Does it mean that when >>> PMIP is present, RO needs to be established by using signaling >>> > between > >>> network entities? Perhaps a rewording is useful. >>> >>> >> It means that MNs cannot perform mobility signaling as per requirement >> of NetLMM, which applies >> also for localized routing set up. The paragraph just explains that >> network components, most probably >> PMIPv6 specific components (MAG, LMA) need to take over this >> responsibility and perform signaling >> to set up a MN's localized routing path. >> >> I'll try to find better wording, assumed you agree to the explanation >> above. >> > [Mohana] Ok, thanks. Marco I understood your intention but the wording > was not clear when I read. As you mentioned a re-wording might be > useful. > yes. >>> 7)In section 3.1 general observation section last paragraph >>> >>> [Mohana] It is mentioned two benefits of loacl MAG routing.There is >>> mentioning about lower cost, lower delay, lower packet loss. But >>> clear indication as to the two benefits was not present. >>> >>> >> They're in, but not so obvious, as I must admit. One is the costs >> > aspect > >> (MAG-LMA >> more costly), the other is the benefit for the user (delay). I'll >> > write > >> to find clearer text. >> >> >>> 8) In section 3.2 all mentioning is about "PMIPv6 domain". >>> >>> [Mohana] I do not want to start the discussion again. But, isn't it >>> better to say what this PMIPv6 domain is. MN and CN in same operator >>> domain or something like that. Bcos there is another section on >>> roaming which is different from this. >>> >>> >> Yes, same as above and still not yet updated in this version. >> Thanks for the hint, we'll rewrite this for the update. >> >> >>> 9) [Mohana]Again in section 3.2, there is mentioning about some race >>> issue in multiple LMA >>> >>> Case, when there is handoff. But no clear description of such issue >>> is highlighted. A small description will be good. >>> >>> >> Ok, I'll add text here. >> > > [Mohana] Thanks. Going through the solution drafts we have, I could not > find clear description of the racing issue. Perhaps your solution draft > covered this. > Just assume MN is attached to MAG1 and CN is attached to MAG2. MAGs have a direct tunnel for localized routing established. If MN moves to MAG1* and CN moves to MAG2*, each side does not know about the other side's move. Hence, dependent on signaling operation, MAG1/MAG1* may try to update MAG2 according to MN1's move, even though CN moved to MAG2*. Same applies to the other direction. This is what I mean with race condition and these things could be resolved by a kind of rendezvous point. >>> 10) In section 3.2, the local MAG issues are highlighted into >>> cases(case A11, A..) and again some issues (multiple LMA, handoff in >>> multiple LMA) are captured in bullet form. I am not sure whether >>> there are any overlap in text here. >>> >>> >> Maybe there is some overlap. A11 etc. analyze issues that come with a >> particular >> topology (multi-LMA etc). The bullet list summarizes general problems, >> which may >> also cover one or the other issue from above. I think it makes sense >> > to > >> have >> problems summarized in one place, even though they may appear at a >> different >> place already with details about where the problem comes from. >> >> > [Mohana] Ok, thanks. That is good. > >>> 11)Section on IPv4 considerations. I think the current text is fine. >>> It is not too complex and highlights how local MAG routing canbe >>> > done > >>> when there is IPv4 HoA or IPv4 transport. >>> >>> >> Ok, thanks. Your review is based on version 00. For the latest update, >> we had to >> remove the NAT and the private IPv4 address conflict,.as the solution >> will not >> address them. Hope the text is still clear in version1. >> > [Mohana] Saw some text removal in the revised version. I will wait for > the revised version. > Ok. Thanks, marco > >> Thanks and best regards, >> marco >> >> >>> BR, >>> >>> Mohana >>> >>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> From Mohana.Jeyatharan@sg.panasonic.com Fri Nov 20 02:24:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82743A6A6E for ; Fri, 20 Nov 2009 02:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.17 X-Spam-Level: * X-Spam-Status: No, score=1.17 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zzDMs3B0bPO for ; Fri, 20 Nov 2009 02:24:56 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 21EE23A6A69 for ; Fri, 20 Nov 2009 02:24:54 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id nAKAOEVo012357; Fri, 20 Nov 2009 19:24:14 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id nAKAO9H13755; Fri, 20 Nov 2009 19:24:10 +0900 (JST) 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, 20 Nov 2009 18:24:11 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FCFA@pslexc01.psl.local> In-Reply-To: <051f01ca69c4$ac4db240$420ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Follow up on bulk-PBU-bitmap-ID Thread-Index: AcppxNbzGMNpSxJvQtS74QDZnq/emAAAZyKQ References: <5F09D220B62F79418461A978CA0921BD03B3FC29@pslexc01.psl.local> <051f01ca69c4$ac4db240$420ca40a@china.huawei.com> From: "Mohana Jeyatharan" To: "Qin Wu" , Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 10:24:57 -0000 Hi Qin, Thank you for your comments on the scenarios we proposed. Please see some replies below. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, November 20, 2009 5:35 PM > To: Mohana Jeyatharan; netext@ietf.org > Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID >=20 > Hi, Mohana: > Take a look at the scenarios you summarized, I would like to make some > comments, > please see inline. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: > Sent: Friday, November 20, 2009 2:46 PM > Subject: [netext] Follow up on bulk-PBU-bitmap-ID >=20 >=20 > > Hi all, > > > > After the netext meeting the Chairs asked us to put some scenarios in > > the ML where the bitmap-bulk-PBU method can be used and to get general > > consensus from the group regarding applicability. I am highlighting the > > scenarios we presented in the Netext meeting in this mail. > > > > As presented in the meeting and also described in the > > draft-jeyatharan-netext-pmip-bulkPBU-bitmap-00, this method can be used > > to optimize bulk PBU in some scenarios. > > > > Please look at the scenarios below and give your feedback regarding > > scenario validity and the need for such method to address optimization > > in these scenarios. Ofcourse we are proposing this as an optional > > feature. A deployment may or may not use it. >=20 > [Qin]: I agree bitmap based Bulk PBU is optional feature and quite useful > when > a set of mobile node tied to one MAG has not formed one or several group. [Mohana] Thanks for this comment. Bcos, in some heavily populated urban areas the MAGs may get multiple attach/ handoff attach requests triggered within a very short time span and the bitmap approach can be used before grouping. Anyway there are more scenarios below which can be used in our discussion. > > The scenarios are: > > Scenario 1: > > Multiple new attachment requests arriving at MAG simultaneously and MAG > > performing multiple initial registration PBUs >=20 > [Qin]: In this scenario, You should require multiple new PBUs to be sent > to the same LMA, right? [Mohana]well this scenario is like multiple new attachment requests arriving within a very minute time frame. So, instead of sending multiple PBUs probably a single PBU can be sent without any significant impact on the new attachemnt establishment time for any given MN. >=20 > > Scenario 2: > > Multiple MN re-registrations at a new LMA due to shut down of the > > previous serving LMA in a LMA failure scenario >=20 > [Qin]: This scenario seems overlapped with bulk re-registration draft. In > this scenario, > the problem is how does MAG know the previous serving LMA is shut down. > whether MN group has already formed on the MAG. [Mohana] From my reading of the bulk reregistration draft, this scenario was not mentioned. I think the older version had this. The MAG fist needs to make the regsitration at the new LMA. After such regsitration, the new LMA will assign the group ID. But the initial registrations at the new LMA can be optimized using the bitmap approach. MAG has binding list tied to many MNs. So it can use bitmap to tranfer to new LMA. The failure can be identified by refresh PBU failure. > > Scenario 3: > > Multiple handoff requests arriving at MAG simultaneously and MAG > > performing multiple handoff registration PBUs. >=20 > [Qin]: I am wondering what's the difference between scenario 2 and > scenario 3? > In my understanding, when MN handover from previous MAG to the new MAG, > MAG should also perform re-registration to the same LMA, what am I > missing? [Mohana] Well in RFC 5213, re-registration is defined more like refreshing the PBU from the same MAG. Handoff is a change in MAG. So, in that sense, they are different. I think you are considering handoff also has re-regsitartion. Well w.r.t. LMA handoff is also like re-registration. > I also found the handoff case is not covered by bulk re-registration draft. > What's the reason? [Mohana] handoff case is not covered bcos the focus is using group ID to perform re-reg and revocation. >=20 > > Scenario 4: > > Multiple detachment events detected at MAG simultaneously and MAG > > performing multiple de-registration PBUs. >=20 > [Qin]: This scenario is only useful when goups for a set of MN has not > formed before de-registration happens. > If MN's group ID has already been created, MAG can perform bulk de- > registration PBU using MN's group ID. [Mohana] I understand your comment here. But, the scenario we mention here is that what if some nodes belonging to groups decide to detach. Not all nodes and hence grouping cannot be used. So this is more like random events. > > Scenario 5: > > Multiple initial registrations, handoff registrations and > > re-registration events happening simultaneously at MAG and MAG > > performing multiple PBUs tied to different type of events. >=20 > [Qin]: It seems to me scenario5 is one combined case using scenario 1,2,3. > I am wondering how does MAG handle PBUs for initial registration, handoff > registration, re-registration in one message. > Also I am difficult to understand that how LMA will process this message > for different purposes at the same time. > Therefore It is a good idea to consider this scenario. [Mohana] Ok, so you are saying that this scenario is a bit more complicated. Agree it is athe combination of the scenarios you mentioned. Well re-regi, new reg and handoff reg are all handled by means of HI mobility option. So combining is not a problem However, the LMA needs to understand that this is bulk PBU handling multiple event tied to multiple Mns and need to update the binding entries accordingly. Perhaps we need to think whether it creates more complexity in LMA behaviour. However, just wanted to highlight usage of the bitmap approach in these scenarios. Agree need to consider whether combining makes LMA processing very complicated. > > Scenario 6: > > MNs moving in group into MAG service area. As a result, MAG performing > > multiple handoff or multiple new attachment PBUs for MNs tied to group > > mobility. >=20 > [Qin]: It seems to me this sccenario seems like NEMO scenario. I think > this scenario is quite useful scenario. Suppose a set of MNs moving as one > in one vechicle, > How the MAG in the vechicle perform multiple new attachment PBUs when the > vechicle is moving. Bitmap based bulk PBU is quite fit into this scenario. [Mohana] exactly. Thanks for mentioning about the NEMO case. So, this is something like a MR or a central contoller performing bulk registration at the MAG instead of each individual MNs. So, in such scenario the bulk method is useful. Here you don't get individual regsitartions but a cntral entity gives combined registrations to the MAG. > > Scenario 7: > > MAG offloading some MNs binding lists to another MAG for load balancing > > purpose. New MAG sends multiple PBU registrations for all the MNs that > > were transferred. >=20 > [Qin]: In my understanding, load balancing between LMAs is required. > Because LMA is easier to be overloaded than MAGs. But I am not sure > there is some requirement for load balancing between MAGs. Can you tell > where this requirement come from? [Mohana] I cannot pin point a specifc document. But in any GW deployments there is usually multiple entities handling registrations for load balancing. In 3GPP there is multiple S-GWs, multiple MMEs, multipe P-GWs and so on. So, this scenario is practical because suppose many nodes attach to one MAG and another MAG does not have many Mn registrations bos Mn regsitartions are removed due to mobility, then the overloaded MAG can transfer some load to another MAG(not so overloaded MAG). >=20 > > Thanks. > > > > BR, > > Mohana > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext From Mohana.Jeyatharan@sg.panasonic.com Fri Nov 20 02:35:37 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53BB3A68B8 for ; Fri, 20 Nov 2009 02:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.66 X-Spam-Level: * X-Spam-Status: No, score=1.66 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_26=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNYQL+idX4UY for ; Fri, 20 Nov 2009 02:35:36 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 550473A690D for ; Fri, 20 Nov 2009 02:35:36 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id nAKAZWxI022270; Fri, 20 Nov 2009 19:35:32 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id nAKAZWx06777; Fri, 20 Nov 2009 19:35:33 +0900 (JST) 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, 20 Nov 2009 18:35:34 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FD00@pslexc01.psl.local> In-Reply-To: <4B066ACB.7060306@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt Thread-Index: AcppyY3AuSn+/mm1QTSIjqinAGko+AAAo2uw References: <5F09D220B62F79418461A978CA0921BD039D908A@pslexc01.psl.local> <4B057D7A.10705@nw.neclab.eu> <5F09D220B62F79418461A978CA0921BD03B3FB6C@pslexc01.psl.local> <4B066ACB.7060306@nw.neclab.eu> From: "Mohana Jeyatharan" To: "Marco Liebsch" Cc: netext@ietf.org Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 10:35:37 -0000 Hi Marco, Thanks for reply. Pease see replies below. BR, Mohana > -----Original Message----- > From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] > Sent: Friday, November 20, 2009 6:09 PM > To: Mohana Jeyatharan > Cc: Marco Liebsch; netext@ietf.org > Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps- > 00.txt >=20 > Hi Mohana, >=20 > please see in-line. >=20 > Mohana Jeyatharan wrote: > > Hi Marco, > > > > Thanks for reply. Please see few minor comments in line. > > > > BR, > > Mohana > > > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >> > > Behalf > > > >> Of Marco Liebsch > >> Sent: Friday, November 20, 2009 1:17 AM > >> To: Mohana Jeyatharan > >> Cc: netext@ietf.org > >> Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps- > >> 00.txt > >> > >> Hi Mohana, > >> > >> thanks again for your comments. All of them are valuable and, as said > >> during > >> last week's meeting, we'll take them in the next update into account. > >> Please see in-line for specific feedback. > >> > >> > >> Mohana Jeyatharan schrieb: > >> > >>> Hi all, > >>> > >>> > >>> > >>> I went through the draft and have few comments. > >>> > >>> > >>> > >>> > >>> > >>> 1)Introduction first para says > >>> > >>> " Even though two communicating MNs might be attached to the > >>> > >>> same MAG or to different MAGs of the same local mobility domain, > >>> > >>> packets will traverse the MNs' LMA(s)." > >>> > >>> [Mohana] Mn and CN may be better word. Bcos later in draft > >>> > > communication > > > >>> End points are defined as MN and CN. > >>> > >>> > >> Yes, definitely we should keep this consistent. > >> > >> > >>> 2)Introduction second para says > >>> > >>> " Objectives of designing a solution for localized routing in PMIPv6 > >>> > >>> are to specify protocol messages and enable associated protocol > >>> > >>> operation between PMIPv6 components to support the set up of a > >>> > > direct > > > >>> routing path for data packets between the MNs' MAGs without > >>> > >>> forwarding these packets through the MNs' LMA(s) and to maintain > >>> > >>> localized routing in case one or both MNs handover to a different > >>> > >>> MAG." > >>> > >>> > >>> > >>> [Mohana] Here again it says that direct path between MN's MAGs. I > >>> think it is between Mn's MAG and CN's MAG. > >>> > >>> > >> True. > >> > >> > >>> 3)In the conventions and terminology section > >>> > >>> > >>> > >>> The second bullet: > >>> > >>> > >>> > >>> Correspondent Node (CN): Correspondent Node with or without IP > >>> > >>> mobility support. The CN represents the communication peer of > >>> > > an > > > >>> MN, which is attached to a MAG and registered with an LMA > >>> > >>> according to the PMIPv6 specification. > >>> > >>> > >>> > >>> [Mohana]The usage of "an" in front of MN and LMA should be changed > >>> > > to a. > > > >> Ok. > >> > > > > [Mohana] Here my initial thinking was, if it is a mobile node and a > > local mobility anchor then the usage of a appropriate. But if you > > consider it as a MN(making sound "em") and LMA(making sound "el"), then > > usage of an is also possible. > > So, I will leave it to your'll to decide. > > > Since it's abbreviated, I thought s about the latter one :-) >=20 > >>> 4)In the conventions and terminology section > >>> > >>> > >>> > >>> The third bullet: there is mentioning about a single PMIPv6 domain. > >>> > >>> [Mohana] Is it MN and CN placed in single operator/provider domain > >>> running PMIPv6? > >>> > >>> > >> Yes, true. This is still from the previous understanding of the > >> localized routing scope. > >> We'll update the description. > >> > >> > >>> 5)In the conventions and terminology section > >>> > >>> Fourth bullet mentions about IDs > >>> > >>> > >>> > >>> [Mohana] Is it only ID? What other information stored. What are > >>> > > these > > > >>> IDs? > >>> > >>> Perhaps a description will be good. > >>> > >>> > >> One example could be the MNID as per RFC5213, which is stored together > >> with > >> localized routing states. Could also be localized routing specific IDs > >> which serve > >> as a key to the MN's states, but we should not assume anything from a > >> solution > >> here. So, do you think describing the MNID as specific example is > >> sufficient? > >> > >> > > [Mohana] Probably MNID as defined in RFC 5213 will suffice. But I > > Think some more parameters are needed in the MAG. Such as CN prefix and > > CN MAG address. I leave it to your'll to decide whether this needs to be > > captured in conventions and terminology section. When we are talking > > about routing state, then probably these needs to be captured as well. > > > Of course prefixes are needed, but I did not consider them to > be IDs. The term section was just to provide examples what we > mean with localized routing states. But I agree that it's obvious > to have prefixes and tunnel endpoints (MAGs) in the conceptual > data structures to maintain localized routing states, I can add > them for clarification. Thanks. for the hint. > > [Mohana] Ok, this is not a major thing. But if possible some inclusion will be good. > >>> 6)In section 3.1 general observation section 1st para > >>> > >>> > >>> > >>> " Following the architecture of PMIPv6, rather entities of the > >>> > > network > > > >>> infrastructure are dedicated to perform signaling to set up a > >>> > > more > > > >>> direct route between an MN and a CN." > >>> > >>> > >>> > >>> [Mohana] I am not sure the meaning of this. Does it mean that when > >>> PMIP is present, RO needs to be established by using signaling > >>> > > between > > > >>> network entities? Perhaps a rewording is useful. > >>> > >>> > >> It means that MNs cannot perform mobility signaling as per requirement > >> of NetLMM, which applies > >> also for localized routing set up. The paragraph just explains that > >> network components, most probably > >> PMIPv6 specific components (MAG, LMA) need to take over this > >> responsibility and perform signaling > >> to set up a MN's localized routing path. > >> > >> I'll try to find better wording, assumed you agree to the explanation > >> above. > >> > > [Mohana] Ok, thanks. Marco I understood your intention but the wording > > was not clear when I read. As you mentioned a re-wording might be > > useful. > > > yes. > >>> 7)In section 3.1 general observation section last paragraph > >>> > >>> [Mohana] It is mentioned two benefits of loacl MAG routing.There is > >>> mentioning about lower cost, lower delay, lower packet loss. But > >>> clear indication as to the two benefits was not present. > >>> > >>> > >> They're in, but not so obvious, as I must admit. One is the costs > >> > > aspect > > > >> (MAG-LMA > >> more costly), the other is the benefit for the user (delay). I'll > >> > > write > > > >> to find clearer text. > >> > >> > >>> 8) In section 3.2 all mentioning is about "PMIPv6 domain". > >>> > >>> [Mohana] I do not want to start the discussion again. But, isn't it > >>> better to say what this PMIPv6 domain is. MN and CN in same operator > >>> domain or something like that. Bcos there is another section on > >>> roaming which is different from this. > >>> > >>> > >> Yes, same as above and still not yet updated in this version. > >> Thanks for the hint, we'll rewrite this for the update. > >> > >> > >>> 9) [Mohana]Again in section 3.2, there is mentioning about some race > >>> issue in multiple LMA > >>> > >>> Case, when there is handoff. But no clear description of such issue > >>> is highlighted. A small description will be good. > >>> > >>> > >> Ok, I'll add text here. > >> > > > > [Mohana] Thanks. Going through the solution drafts we have, I could not > > find clear description of the racing issue. Perhaps your solution draft > > covered this. > > > Just assume MN is attached to MAG1 and CN is attached to MAG2. > MAGs have a direct tunnel for localized routing established. If MN > moves to MAG1* and CN moves to MAG2*, each side does not > know about the other side's move. Hence, dependent on signaling > operation, MAG1/MAG1* may try to update MAG2 according to > MN1's move, even though CN moved to MAG2*. Same applies to > the other direction. This is what I mean with race condition and > these things could be resolved by a kind of rendezvous point. [Mohana] ok, looking at this I was reminded of the simultanoeus mobility issue that was presented in the MEXT wg. I think there is similarity here bcos the upadtes goes to wrong nodes. > >>> 10) In section 3.2, the local MAG issues are highlighted into > >>> cases(case A11, A..) and again some issues (multiple LMA, handoff in > >>> multiple LMA) are captured in bullet form. I am not sure whether > >>> there are any overlap in text here. > >>> > >>> > >> Maybe there is some overlap. A11 etc. analyze issues that come with a > >> particular > >> topology (multi-LMA etc). The bullet list summarizes general problems, > >> which may > >> also cover one or the other issue from above. I think it makes sense > >> > > to > > > >> have > >> problems summarized in one place, even though they may appear at a > >> different > >> place already with details about where the problem comes from. > >> > >> > > [Mohana] Ok, thanks. That is good. > > > >>> 11)Section on IPv4 considerations. I think the current text is fine. > >>> It is not too complex and highlights how local MAG routing canbe > >>> > > done > > > >>> when there is IPv4 HoA or IPv4 transport. > >>> > >>> > >> Ok, thanks. Your review is based on version 00. For the latest update, > >> we had to > >> remove the NAT and the private IPv4 address conflict,.as the solution > >> will not > >> address them. Hope the text is still clear in version1. > >> > > [Mohana] Saw some text removal in the revised version. I will wait for > > the revised version. > > > Ok. >=20 > Thanks, > marco >=20 > > > >> Thanks and best regards, > >> marco > >> > >> > >>> BR, > >>> > >>> Mohana > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> From conny.larsson@ericsson.com Fri Nov 20 03:05:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AA13A6887 for ; Fri, 20 Nov 2009 03:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymHZkLCo3U-A for ; Fri, 20 Nov 2009 03:05:06 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3AE203A682D for ; Fri, 20 Nov 2009 03:05:05 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-0d-4b0677dd6640 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0F.E6.24094.DD7760B4; Fri, 20 Nov 2009 12:05:01 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 12:04:57 +0100 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 12:04:57 +0100 Message-ID: <4B0677D8.9000001@ericsson.com> Date: Fri, 20 Nov 2009 12:04:56 +0100 From: Conny Larsson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mohana Jeyatharan References: <5F09D220B62F79418461A978CA0921BD03B3FC29@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03B3FC29@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2009 11:04:57.0812 (UTC) FILETIME=[4C077940:01CA69D1] X-Brightmail-Tracker: AAAAAA== Cc: netext@ietf.org Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 11:05:07 -0000 Hi Mohana, In the below scenarios (4 out of 7) you are using the word "simultaneously". How would you define simultaneously? Depending on the time interval you define there will be a delay introduced. Is this a correct interpretation of the scenarios or did you have anything else in mind? Regards Conny Mohana Jeyatharan wrote: > Hi all, > > After the netext meeting the Chairs asked us to put some scenarios in > the ML where the bitmap-bulk-PBU method can be used and to get general > consensus from the group regarding applicability. I am highlighting the > scenarios we presented in the Netext meeting in this mail. > > As presented in the meeting and also described in the > draft-jeyatharan-netext-pmip-bulkPBU-bitmap-00, this method can be used > to optimize bulk PBU in some scenarios. > > Please look at the scenarios below and give your feedback regarding > scenario validity and the need for such method to address optimization > in these scenarios. Ofcourse we are proposing this as an optional > feature. A deployment may or may not use it. > > The scenarios are: > Scenario 1: > Multiple new attachment requests arriving at MAG simultaneously and MAG > performing multiple initial registration PBUs > > Scenario 2: > Multiple MN re-registrations at a new LMA due to shut down of the > previous serving LMA in a LMA failure scenario > > Scenario 3: > Multiple handoff requests arriving at MAG simultaneously and MAG > performing multiple handoff registration PBUs. > > Scenario 4: > Multiple detachment events detected at MAG simultaneously and MAG > performing multiple de-registration PBUs. > > Scenario 5: > Multiple initial registrations, handoff registrations and > re-registration events happening simultaneously at MAG and MAG > performing multiple PBUs tied to different type of events. > > Scenario 6: > MNs moving in group into MAG service area. As a result, MAG performing > multiple handoff or multiple new attachment PBUs for MNs tied to group > mobility. > > Scenario 7: > MAG offloading some MNs binding lists to another MAG for load balancing > purpose. New MAG sends multiple PBU registrations for all the MNs that > were transferred. > > Thanks. > > BR, > Mohana > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Mohana.Jeyatharan@sg.panasonic.com Sun Nov 22 16:36:01 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1EE23A6855 for ; Sun, 22 Nov 2009 16:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E8KZBxGsSf7 for ; Sun, 22 Nov 2009 16:36:01 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id DEF373A6828 for ; Sun, 22 Nov 2009 16:35:59 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAN0ZpCQ011648; Mon, 23 Nov 2009 09:35:51 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id nAN0Zqx10148; Mon, 23 Nov 2009 09:35:52 +0900 (JST) 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, 23 Nov 2009 08:35:57 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FD5F@pslexc01.psl.local> In-Reply-To: <4B0677D8.9000001@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Follow up on bulk-PBU-bitmap-ID Thread-Index: Acpp0UrTOgsiS1SETRiZ1WqcCUZHGgCAdjqg References: <5F09D220B62F79418461A978CA0921BD03B3FC29@pslexc01.psl.local> <4B0677D8.9000001@ericsson.com> From: "Mohana Jeyatharan" To: "Conny Larsson" Cc: netext@ietf.org Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 00:36:02 -0000 Hi Conny, Thanks for your response. Well simultaneously means many new call registrations or handoff registrations being triggered at a MAG within a very short time frame. I agree with you that there will be some delay. Since the assumption is that many arrive within a short time frame, MAG grouping these in a single PBU does not really cause so much delay. Bcos in some handoff cases, one may not have any on-going session. Also during initial attach there can be a some delay that can be accepted to applications bcos a Mn may not send or receive data immediately after attach. Thus such minute delay in grouping the initial attach registrations or handoff registrations does not cause any harm as far the MN performance is concerned. So, was thinking of such cases, where a minute delay can be tolerable and also beneficial to the operator. However, if the SLA(service level agreement) is such that this delay cannot be tolerated, then the operator MUST not do such bulk registration. Considering the traffic will increase many folds in future, such optimization may be needed. It gives the flexibility to the operators. Also please look at scenario 6 where we highlight group mobility or group registration. In such case, it is very probable that simultaneous registrations of multiple MNs are given to the network by a single entity(central controller of group or MR). In such case, there will not be any delay in the registrations at the MAG. Thanks. BR, Mohana > -----Original Message----- > From: Conny Larsson [mailto:conny.larsson@ericsson.com] > Sent: Friday, November 20, 2009 7:05 PM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: [netext] Follow up on bulk-PBU-bitmap-ID >=20 > Hi Mohana, >=20 > In the below scenarios (4 out of 7) you are using the word > "simultaneously". How would you define simultaneously? Depending on the > time interval you define there will be a delay introduced. Is this a > correct interpretation of the scenarios or did you have anything else in > mind? >=20 > Regards > Conny >=20 > Mohana Jeyatharan wrote: > > Hi all, > > > > After the netext meeting the Chairs asked us to put some scenarios in > > the ML where the bitmap-bulk-PBU method can be used and to get general > > consensus from the group regarding applicability. I am highlighting the > > scenarios we presented in the Netext meeting in this mail. > > > > As presented in the meeting and also described in the > > draft-jeyatharan-netext-pmip-bulkPBU-bitmap-00, this method can be used > > to optimize bulk PBU in some scenarios. > > > > Please look at the scenarios below and give your feedback regarding > > scenario validity and the need for such method to address optimization > > in these scenarios. Ofcourse we are proposing this as an optional > > feature. A deployment may or may not use it. > > > > The scenarios are: > > Scenario 1: > > Multiple new attachment requests arriving at MAG simultaneously and MAG > > performing multiple initial registration PBUs > > > > Scenario 2: > > Multiple MN re-registrations at a new LMA due to shut down of the > > previous serving LMA in a LMA failure scenario > > > > Scenario 3: > > Multiple handoff requests arriving at MAG simultaneously and MAG > > performing multiple handoff registration PBUs. > > > > Scenario 4: > > Multiple detachment events detected at MAG simultaneously and MAG > > performing multiple de-registration PBUs. > > > > Scenario 5: > > Multiple initial registrations, handoff registrations and > > re-registration events happening simultaneously at MAG and MAG > > performing multiple PBUs tied to different type of events. > > > > Scenario 6: > > MNs moving in group into MAG service area. As a result, MAG performing > > multiple handoff or multiple new attachment PBUs for MNs tied to group > > mobility. > > > > Scenario 7: > > MAG offloading some MNs binding lists to another MAG for load balancing > > purpose. New MAG sends multiple PBU registrations for all the MNs that > > were transferred. > > > > Thanks. > > > > BR, > > Mohana > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > From sunseawq@huawei.com Sun Nov 22 19:13:55 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1D73A69FD for ; Sun, 22 Nov 2009 19:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.332 X-Spam-Level: * X-Spam-Status: No, score=1.332 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_20=-0.74, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwuO38PsUpb8 for ; Sun, 22 Nov 2009 19:13:53 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F326F3A68DB for ; Sun, 22 Nov 2009 19:13:48 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ009PEKYVOZ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 11:13:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ002H8KYV22@szxga03-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 11:13:43 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTJ00I6PKYUJP@szxml06-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 11:13:43 +0800 (CST) Date: Mon, 23 Nov 2009 11:13:42 +0800 From: Qin Wu To: Mohana Jeyatharan Message-id: <00f701ca6bea$f626fcf0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> <006601ca6987$e49609a0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FB9A@pslexc01.psl.local> <04e701ca69bb$07ef6210$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FCDA@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 03:13:56 -0000 ----- Original Message ----- From: "Mohana Jeyatharan" To: "Qin Wu" Cc: Sent: Friday, November 20, 2009 5:44 PM Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt Hi Qin, Please see my short comments below. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, November 20, 2009 4:26 PM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > Hi, Mohana: > Thank for your quick response, please see my feedback inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" > Cc: > Sent: Friday, November 20, 2009 12:10 PM > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt > > > Hi Qin, > > Thanks for reply. Please see some replies in-line. > > BR, > Mohana > > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Friday, November 20, 2009 10:19 AM > > To: Mohana Jeyatharan > > Cc: netext@ietf.org > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > > > Hi, Mohana: > > Sorry for my late reply. Also thank you for your review and comments. > > please see my reply inline. > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Mohana Jeyatharan" > > To: "Qin Wu" > > Cc: > > Sent: Monday, November 16, 2009 9:59 AM > > Subject: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > > > Hi Qin, > > > > Read your ID. I have few comments. > > > > Please see below. > > > > BR, > > Mohana > > > > In abstract, > > "In case the correspondent node is > > connected to another local mobility anchor, the local mobility > > anchors connected by the correspondent node needs to be discovered > > firstly so that it can notify its mobile access gateways attached > by > > the correspondent node to the mobile access gateway attached by > the > > mobile node afterwards." > > > > <<<[Mohana] In abstract it is not very clear which entitiy notifies > CN's > > MAG to MN's MAG. Perhaps a rewording may be useful>>> > > > > [Qin]: Yes, what we are really saying here is CN's LMA will notify > CN's > > MAG to MN's MAG when MN's MAG > > communicate with CN's LMA using normal PBU/PBA. Maybe the proper way > to > > say would be > > " > > so that the discovered local mobility anchor notity its mobile access > > gateways attached by the correspondent node...... > > " > [Mohana] So, the description is tied to CN's LMA notifying MN's MAG to > CN's MAG. Ok, understand. But some description on MN's LMA notifying > CN's MAG to MN's MAG will be also useful in the inter-LMA scenario. > What I am not clear is why is MN's MAG connected to CN's LMA? Probably > this is another scenario addressed in scetion 7(inter LMA case). Anyway > I will leave it for now. If MN's MAG is connected to CN's LMA, then > such passing (CN's LMA passing CN MAG address to MN's MAG)is propoer. > Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA. > > [Qin]: Your understanding is correct. In the Inter-LMA local routing > scenario, > MN and CN attach to different MAGs and registers to different LMA > respectively. > In this scenario, MN's LMA does not know CN's MAG address, what we can do > here > is to let MN's MAG talk with CN's LMA, then CN's LMA can tell MN's MAG > about > CN's MAG address. > but if MN and CN share the same LMA, then it does not matter whether MN's > LMA or > CN's LMA notitfy CN's MAG to MN's MAG, > because MN's LMA is CN's LMA. [Mohana] Ok, do not want to dwell on this too much. So you are saying that CN MAG address is passed to MN MAG by CN LMA. A short question I have is how does CN LMA address is known to MN MAG. Anyway, I need to read the inter-LMA part in more detail. [Qin]: PMIP6 mobility entities discovery( i.e., LMA) described in PS draft will be used to obtain CN LMA address. In our solution I-D, one AAA mechanism can be adopted to perform PMIP6 mobility entities discovery. The details can be read in another I-D,i.e., draft-wu-dime-pmip6-lr-01. > > > In abstract, Mobile access gateways create and refresh bindings > > using proxy binding update and acknowledgement messages. > > > > <<<[Mohana] What is the reason for this. Is this refering to PBU to > LMA > > or PBU to MAG? Perhaps more clarity on this will help.>>> > > > > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create > binding > > when it is the first time for MAGs to setup localized routing path. > > during handover case, PBU/PBA will be used between MAGs to refresh > binding. > > The reason to create and refresh bindings between MAGs attached by > mobile > > node and correspondent node is quite similar to correspondent > registration > > in the Mobile IPv6 Routing optimization between mobile node and > > correspondent node described in the section 11.7.2 of RFC3775. > > i.e., allowing correspondent node to cache mobile node's proxy care-of > > address or allowing mobile node to cache correspondent node' proxy > care-of > > address, > [Mohana]I agree with your approach of using PBU/PBA for routing state > setup and tunnel setup between MAGs and think that is a good approach > and tied to RFC 5213 way. From further reading of your draft I > understand this. All I wanted to say is that in abstract, a mentioning > of PBU/PBA from MAG to MAG introduces more clarity. That is all. > > [Qin]: Okay, agree. > > > > > In conventions used section it is mentioned > > > > Local routing: Traffic between MN and CN does not pass through LMA > > and is locally routed in the same PMIPv6 domain. > > > > <<<[Mohana] Perhaps a re-wording may be necessary when referring to > > PMIPv6 domain. This should be aligned with the PS draft terminology. > It > > should be same provider domain running PMIPv6 or some thing like > > that.>>> > > > > [Qin]: Okay, will check the wording to be consistent with PS draft. > > > > In conventions used section it is mentioned > > Local Routing Optimization Request (LROREQ): A message initiated by > > the MAG or LMA requesting the MAG or LMA to establish local routing > > optimization path between MN and at least one pair of CNs who > > communicate with MN. > > <<<[Mohana] why is there reference to at least one pair of CN. Are u > > saying at least a single CN? Not very clear>>> > > > > [Qin]: Right, thank for your good catching and correction. The reason > to > > say at least one CN is > > in some cases, maybe MN will communicate with more than one CN, in > this > > sense, LROREQ > > message may be sent from MN's LMA to each MAGs attached by serveral > CNs > > which is communicating with MN. > > or sent from MN's MAG to each LMA which is registered by more than one > CNs > > which is communicating with MN during inter-LMA handover case. > > > [Mohana]Ok, sure I understand your intention proabably a minor > re-wording would do. > > [Qin]: Right. > > > In section 3 Scenario analysis for PMIPv6 local routing > > > > <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. > > Again I think this should be single administrative/provider domain > > running PMIpv6.>>> > > > > [Qin]: Okay. > > > > In figure 1, > > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to > > LMA.>>> > > > > [Qin]: I am okay with this change in the figure 1. > > > > In last para in section 3 which is > > In all the above scenarios, MN is allowed to roam within its PMIPv6 > > domain (i.e, MN's home domain in which MN's LMA is located) or move > > from one PMIPv6 domains(i.e., MN's visited domains)to another. CN > > should stay with MN within the same PMIPv6 domain, e.g., MN moves > to > > the visited domain to which CN belongs. Another example is MN and > CN > > move to the same visited domain to which MN's LMA or CN's LMA does > > not belong. > > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative > > domain. Probably re-writing with respect to MN in home or visited > domain > > and CN inhome or visited domain may be useful. Currently the text is > > not very clear>>> > > > > [Qin]: Agree there is room for improvement here, this paragraph will > be > > reworded in accordance with the > > terminologies used in the PS draft > [Mohana] Ok, thanks. > > > In section 4, > > <<<[Mohana] the first bullet should be changed to administrative > domain > > instaed of PMIPv6 domain. The second bullet says MN and CN attached > to > > same LMA. But in section 3 it is mentioned inter LMA scenario as > well. > > So, I am a bit confused as to whether the solution is not handling > inter > > LMA scenario.>>> > > > > [Qin]: Yes, inter LMA scenario will be handled in one separate section > of > > our Solution I-D. Our solution I-D mainly focuses on specifying the > > localize drouting protocol based on the first two scenarios described > in > > the section 3. the common aspect of the first two scenarios is it does > not > > require PMIP6 mobility entities discovery described in the PS draft. > As > > regarding to the inter-LMA local routing scenario, it depends on PMIP6 > > mobility entities discovery, extra extended PMIP6 signaling is > required > > between MN's MAG and CN's LMA. Therefore inter-LMA local routing case > is > > separated from section 4 which is concentrating on the first two > scenarios > > and addressed in the independent section, i.e., section 7. > > > [Mohana] Ok, understand. Do not know why I got confused. Probably a > section outline may be helpful and I leave it to you to handle. > > [Qin]: Okay. > > > > > In section 4.1 > > <<<[Mohana] In this section there is reference to three different > types > > of flags such as intra-LMA local routing flag, intra-MAG local routing > > flag, Enable detect local routing flag. A description of these in > > section 2 would be better for easy understanding.>>> > > > > [Qin]: Okay. Thank for your suggestion. > > > > In section 4.1, para 3, it is mentioned After successful local routing > > optimization process, if MN and CN > > attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA > > localrouting flag is set to value one, the MAG1 to which the MN > > attaches may send PBU message to the MAG2 which the CN attaches to. > > <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I > > think you are referring to MN connected to MAG 1 and CN connected to > > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between > > th etwo MAGs. The sentence is not clear.>>> > > > > [Qin]: Okay, maybe we could say: > > " > > MAG1 to which the MN is connected may send PBU message to the MAG2 to > > which the CN > > is connected. > > " > [Mohana] probably somewords along the above lines may be useful. > > > In section 4.1, in para 3 it is mentioned that MN's MAG is informed of > > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's > MAG > > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's > MAGs > > are engaged in bi-ditectional PBU/PBA. > > > > <<<[Mohana]Here I have some comments. > > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new > > option. Then MN's MAG can start PBU with CN's MAG. But the question > I > > have is how does CN's MAG create the routing state for MN prefix. How > > does the CN's MAG know that this prefix is owned by MN and MN's MAG is > > actually proxying that prefix? > > > > > > The same when CN's MAG does PBU to MN's MAG. Probably, after getting > > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But > again > > to create the the routing state for CN's prefix at MN's MAG the MN's > MAG > > should know the prefix CN owns is valid prefix. Otherwise, I don't see > > how a valid routing state can be created. > > > > So, by reading this I feel a prefix ownership kind of information is > > needed in the PBU.>>> > > > > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's MAG > must > > believe the prefix sent from MN's MAG is owned by MN. Because MN's MAG > can > > check whether prefix is ownd by MN and used to create a valid routing > > before it send the prefix to the CN's MAG. That is to say we can > assume > > there is a trust relationship between MN's MAG and CN's MAG. In oder > for > > this, two possible ways in my mind are, > > 1) we assume a prior agreement between MN's MAG and CN's MAG. > > 2) the second way is we use IPSEC to setup Security association > between > > MN's MAG and CN's MAG. > > By these two ways mentioned above, we can have trust relationship > between > > MAGs, But what if MN's MAG establish trust relationship with CN's MAG > and > > send the forged MN's prefix to CN's MAG, I think the prefix ownership > > validation may be useful in this scenario to help create valid routing > > state at CN's MAGs > > Therefore I would like to address this security threat in our solution > I- > > D.Thanks for your good points. > > > [Mohana] Thanks Qin. Although I liked the Pbu way of establishing > tunnel between MAGs, this prefix validation seemed important to address > the security part. In RFC 5213, LMA is the prefix delegator so such > issue is not needed. But here, the CN's MAG need such validation. > Thanks for addressing this part. > > [Qin]Agree. > > > > In the handover mechanims in section 4.1.1, it is mentioned that the > > nMAG1 will get context from old MAG (pMAG1). > > > > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's > MAG, > > how can CN's MAG know that this prefix of MN is valid and nMAG1 is > > proxying the preifx. Bcos during handoff, the LMA is not involved. > > nMAG1 has no issue in knowing that MN;s prefix is given by LMA because > > when it does PBU to LMA it will know that this is a valid prefix. But > > that is not the case with CN's MAG.>>> > > > > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and keeps > on > > communication with CN, there is no trust relationship beforehand > between > > nMAG1 and MAG2 to which CN is connected. That is true. But I think > MN's > > prefix will keep unchanged during handover. The only change to MN is > MN's > > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to validate > > MN's prefix ownership each time MN hands over? In my understanding, > prefix > > ownership validation can be understood as routing reachability > test(RRT) > > procedure defined in the RFC3775. But I am not sure RRT procedure will > be > > done each time MN hands over according to RFC3775. > > [Mohana] For the handover case, just as in new establishment, the CN > needs to know that the nMAG is proxying the prefix. So the prefix > validation method as for new connection can be used here. The RFC 3775 > way of prefix validation is one way but there is more signaling. > Probably some assurance from LMA will be good regarding prefix validity. > I think this is critical bcos in handover case, LMA is not involved. So > to assure fast handoff one would not want the LMA to be involved. > Furthermore, using your method a distributed handoff management can be > done without the involvement of pMAG of MN notifying anything to CN'MAG. > What I am saying is nMAG of MN can handle the PBU with CN's MAG without > old MAG of MN being involved and this will expedite handover state > convergence. The only thing that is needed in MN's nMAG to tell CN I > own/proxy this prefix and prefix is valid. > > [Qin]: Okay, let me try to understand what you are explaining about prefix > ownership validation. > It seems to me, there are three possible ways to do this task: > 1) pMAG of MN notify CN's MAG that MN's prefix is valid. > 2) LMA of CN notify CN's MAG that MN's prefix is valid. > 3) nMAG of MN itself notify CN's MAG that MN's prefix is valid > In these three ways, the 3) seems more straightforward and efficient than > 1) and 2) to fulfill prefix owndership validation during handover. > But in some cases, e.g., MN and CN register to the same LMA, LMA may > notify both MAGs associated with MN and CN that MN's prefix and CN's > prefix are valid before PBU/PBA exchange between MN's MAG and CN's MAG > happens. That is to say, prefix owndership validation also can be done > during LROREQ/LRORSP exhange between MAG and LMA. > Anyway, I think prefix ownership validation is necessary and useful > feature that can be used to create valid routing. > [Mohana] Thanks for the good break down and analysis. As you have identified 3) seems more straightforward and efficient. When you are refering to LMA involved in prefix validation, I think you are refering to LMA initaited RO case. I need to further look at your ID for LMA initiated RO scenario and how LMA is involved during handoff procedures. I will get back to you soon on this with a little more comments on this procedure. Thanks. [Qin]: As regarding to LMA involved prefix validation, I think it also can be applicable to MAG Initiated RO case. But one more message from LMA is required to notify the CN's MAG MN's prefix is valid upon LMA receiving LROREQ message from MAG. In other words, e.g., MN's MAG requests CN's LMA to validate CN's prefix ownership by sending LROREQ message including MN-CN pair mobility option, LMA respond to MN's MAG with LRORSP, at the same time, LMA notify CN's MAG that MN's prefix is valid by sending LROREQ to CN's MAG. > > Also in section 4.1 in second paragraph it is mentioned that MAG can > > send LRO req to LMA when Mn and CN are not attached to same MAG. > > <<<[Mohana] In this case, how does MAG know the CN address. What > value > > will be attached in the Mn-CN pair mobility option. Is there some L2 > > message sent from Mn to MAG and all CN addresses are given in these. > > Probably such mentioning will be useful>>> > > > > [Qin]: How MAG know the CN address actually is beyond scope of this > > solution I-D. The possible way is MAG may look at data packet' > destination > > address to know CN address.For the case where one MN communicates with > one > > CN, MN-CN pair mobility option may include one MN's info and one CN's > info. > > MN's. For the case where one MN communciates with several CNs, MN-CN > pair > > mobility option may include one MN's info and several CNs' info. > > [Mohana] Ok, thanks. I was just analyzing the benefits of MAG initiated > RO as opposed to LMA initiated RO and wanted to highlight some benefits > when MAG initiates RO. I guess how MAG gets the information need not be > covered in the draft and it can be out of bound signaling. > > [Qin]: Okay, understand. In my opinion, MAG initiated RO is more > applicable to the local routing > described in RFC 5213 than LMA initiated RO. But we can not exclude LMA to > initiate RO as well. > > > > I have more comments. But rather than sending all at once I thought I > > will stop here for now. > > > Thanks. > > > > > -----Original Message----- > > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] > > > On Behalf Of Internet-Drafts@ietf.org > > > Sent: Monday, October 26, 2009 4:30 PM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > Title : Proxy MIP extension for local routing > > optimization > > > Author(s) : W. Wu, B. Sarikaya > > > Filename : draft-wu-netext-local-ro-04.txt > > > Pages : 32 > > > Date : 2009-10-26 > > > > > > This document extends local routing in proxy Mobile IPv6 and defines > > > a localized routing optimization protocol within one PMIPv6 domain. > > > The protocol supports IPv4 transport network operation, IPv4 home > > > address mobility and handover. The Local mobility anchor/mobile > > > access gateway initiates local routing for the mobile and > > > correspondent node by sending messages to each mobile access > > > gateway/local mobility anchor. In case the correspondent node is > > > connected to another local mobility anchor, the local mobility > > > anchors connected by the correspondent node needs to be discovered > > > firstly so that it can notify its mobile access gateways attached > by > > > the correspondent node to the mobile access gateway attached by the > > > mobile node afterwards. Mobile access gateways create and refresh > > > bindings > > > using proxy binding update and acknowledgement messages. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. From Mohana.Jeyatharan@sg.panasonic.com Sun Nov 22 21:58:47 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6C83A681A for ; Sun, 22 Nov 2009 21:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.36 X-Spam-Level: ** X-Spam-Status: No, score=2.36 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htaJjo5v1IYX for ; Sun, 22 Nov 2009 21:58:45 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 2572A3A6827 for ; Sun, 22 Nov 2009 21:58:44 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAN5tRGf014737; Mon, 23 Nov 2009 14:55:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id nAN5tMO14844; Mon, 23 Nov 2009 14:55:23 +0900 (JST) 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, 23 Nov 2009 13:55:25 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B3FE81@pslexc01.psl.local> In-Reply-To: <00f701ca6bea$f626fcf0$420ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments on :draft-wu-netext-local-ro-04.txt Thread-Index: Acpr6vseovTb3N0QQcK2AO+dJgatWAACHSOw References: <20091026083001.DC4873A679C@core3.amsl.com><5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local><006601ca6987$e49609a0$420ca40a@china.huawei.com><5F09D220B62F79418461A978CA0921BD03B3FB9A@pslexc01.psl.local><04e701ca69bb$07ef6210$420ca40a@china.huawei.com><5F09D220B62F79418461A978CA0921BD03B3FCDA@pslexc01.psl.local> <00f701ca6bea$f626fcf0$420ca40a@china.huawei.com> From: "Mohana Jeyatharan" To: "Qin Wu" Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:58:47 -0000 Hi Qin, Please see some replies below. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Qin Wu > Sent: Monday, November 23, 2009 11:14 AM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt >=20 >=20 > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" > Cc: > Sent: Friday, November 20, 2009 5:44 PM > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt >=20 >=20 > Hi Qin, >=20 > Please see my short comments below. >=20 > BR, > Mohana >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Friday, November 20, 2009 4:26 PM > > To: Mohana Jeyatharan > > Cc: netext@ietf.org > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > > > Hi, Mohana: > > Thank for your quick response, please see my feedback inline. > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Mohana Jeyatharan" > > To: "Qin Wu" > > Cc: > > Sent: Friday, November 20, 2009 12:10 PM > > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > Hi Qin, > > > > Thanks for reply. Please see some replies in-line. > > > > BR, > > Mohana > > > > > -----Original Message----- > > > From: Qin Wu [mailto:sunseawq@huawei.com] > > > Sent: Friday, November 20, 2009 10:19 AM > > > To: Mohana Jeyatharan > > > Cc: netext@ietf.org > > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > Hi, Mohana: > > > Sorry for my late reply. Also thank you for your review and > comments. > > > please see my reply inline. > > > > > > Regards! > > > -Qin > > > ----- Original Message ----- > > > From: "Mohana Jeyatharan" > > > To: "Qin Wu" > > > Cc: > > > Sent: Monday, November 16, 2009 9:59 AM > > > Subject: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > > > > > > > Hi Qin, > > > > > > Read your ID. I have few comments. > > > > > > Please see below. > > > > > > BR, > > > Mohana > > > > > > In abstract, > > > "In case the correspondent node is > > > connected to another local mobility anchor, the local mobility > > > anchors connected by the correspondent node needs to be > discovered > > > firstly so that it can notify its mobile access gateways > attached > > by > > > the correspondent node to the mobile access gateway attached by > > the > > > mobile node afterwards." > > > > > > <<<[Mohana] In abstract it is not very clear which entitiy notifies > > CN's > > > MAG to MN's MAG. Perhaps a rewording may be useful>>> > > > > > > [Qin]: Yes, what we are really saying here is CN's LMA will notify > > CN's > > > MAG to MN's MAG when MN's MAG > > > communicate with CN's LMA using normal PBU/PBA. Maybe the proper way > > to > > > say would be > > > " > > > so that the discovered local mobility anchor notity its mobile > access > > > gateways attached by the correspondent node...... > > > " > > [Mohana] So, the description is tied to CN's LMA notifying MN's MAG to > > CN's MAG. Ok, understand. But some description on MN's LMA notifying > > CN's MAG to MN's MAG will be also useful in the inter-LMA scenario. > > What I am not clear is why is MN's MAG connected to CN's LMA? > Probably > > this is another scenario addressed in scetion 7(inter LMA case). > Anyway > > I will leave it for now. If MN's MAG is connected to CN's LMA, then > > such passing (CN's LMA passing CN MAG address to MN's MAG)is propoer. > > Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA. > > > > [Qin]: Your understanding is correct. In the Inter-LMA local routing > > scenario, > > MN and CN attach to different MAGs and registers to different LMA > > respectively. > > In this scenario, MN's LMA does not know CN's MAG address, what we can > do > > here > > is to let MN's MAG talk with CN's LMA, then CN's LMA can tell MN's MAG > > about > > CN's MAG address. > > but if MN and CN share the same LMA, then it does not matter whether > MN's > > LMA or > > CN's LMA notitfy CN's MAG to MN's MAG, > > because MN's LMA is CN's LMA. >=20 > [Mohana] Ok, do not want to dwell on this too much. So you are saying > that CN MAG address is passed to MN MAG by CN LMA. A short question I > have is how does CN LMA address is known to MN MAG. Anyway, I need to > read the inter-LMA part in more detail. >=20 > [Qin]: PMIP6 mobility entities discovery( i.e., LMA) described in PS draft > will be used to > obtain CN LMA address. In our solution I-D, one AAA mechanism can be > adopted to perform > PMIP6 mobility entities discovery. The details can be read in another I- > D,i.e., draft-wu-dime-pmip6-lr-01. >=20 > > [Mohana] Ok, so when LMA1(MAG1(Mn)) and LMA2(MAG2(CN)) are in the same domain, I guess this mechanism AAA based can be used to find CN LMA address. But when LMA of Mn and LMA of CN are in different domains, and MN and CN placed in another visited domain, then discovery of CN LMA address may be more difficult using the AAA. Am I right to say that? Also it depends whether the solution space is looking at LMAs placed in different provider domains and MN and CN placed in another visited domain. > > > In abstract, Mobile access gateways create and refresh bindings > > > using proxy binding update and acknowledgement messages. > > > > > > <<<[Mohana] What is the reason for this. Is this refering to PBU to > > LMA > > > or PBU to MAG? Perhaps more clarity on this will help.>>> > > > > > > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create > > binding > > > when it is the first time for MAGs to setup localized routing path. > > > during handover case, PBU/PBA will be used between MAGs to refresh > > binding. > > > The reason to create and refresh bindings between MAGs attached by > > mobile > > > node and correspondent node is quite similar to correspondent > > registration > > > in the Mobile IPv6 Routing optimization between mobile node and > > > correspondent node described in the section 11.7.2 of RFC3775. > > > i.e., allowing correspondent node to cache mobile node's proxy > care-of > > > address or allowing mobile node to cache correspondent node' proxy > > care-of > > > address, > > [Mohana]I agree with your approach of using PBU/PBA for routing state > > setup and tunnel setup between MAGs and think that is a good approach > > and tied to RFC 5213 way. From further reading of your draft I > > understand this. All I wanted to say is that in abstract, a > mentioning > > of PBU/PBA from MAG to MAG introduces more clarity. That is all. > > > > [Qin]: Okay, agree. > > > > > > > > In conventions used section it is mentioned > > > > > > Local routing: Traffic between MN and CN does not pass through LMA > > > and is locally routed in the same PMIPv6 domain. > > > > > > <<<[Mohana] Perhaps a re-wording may be necessary when referring to > > > PMIPv6 domain. This should be aligned with the PS draft terminology. > > It > > > should be same provider domain running PMIPv6 or some thing like > > > that.>>> > > > > > > [Qin]: Okay, will check the wording to be consistent with PS draft. > > > > > > In conventions used section it is mentioned > > > Local Routing Optimization Request (LROREQ): A message initiated by > > > the MAG or LMA requesting the MAG or LMA to establish local > routing > > > optimization path between MN and at least one pair of CNs who > > > communicate with MN. > > > <<<[Mohana] why is there reference to at least one pair of CN. Are > u > > > saying at least a single CN? Not very clear>>> > > > > > > [Qin]: Right, thank for your good catching and correction. The > reason > > to > > > say at least one CN is > > > in some cases, maybe MN will communicate with more than one CN, in > > this > > > sense, LROREQ > > > message may be sent from MN's LMA to each MAGs attached by serveral > > CNs > > > which is communicating with MN. > > > or sent from MN's MAG to each LMA which is registered by more than > one > > CNs > > > which is communicating with MN during inter-LMA handover case. > > > > > [Mohana]Ok, sure I understand your intention proabably a minor > > re-wording would do. > > > > [Qin]: Right. > > > > > In section 3 Scenario analysis for PMIPv6 local routing > > > > > > <<<[Mohana]The text before the figure 1 is refering to PMIPv6 > domain. > > > Again I think this should be single administrative/provider domain > > > running PMIpv6.>>> > > > > > > [Qin]: Okay. > > > > > > In figure 1, > > > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport > to > > > LMA.>>> > > > > > > [Qin]: I am okay with this change in the figure 1. > > > > > > In last para in section 3 which is > > > In all the above scenarios, MN is allowed to roam within its PMIPv6 > > > domain (i.e, MN's home domain in which MN's LMA is located) or > move > > > from one PMIPv6 domains(i.e., MN's visited domains)to another. CN > > > should stay with MN within the same PMIPv6 domain, e.g., MN moves > > to > > > the visited domain to which CN belongs. Another example is MN and > > CN > > > move to the same visited domain to which MN's LMA or CN's LMA > does > > > not belong. > > > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative > > > domain. Probably re-writing with respect to MN in home or visited > > domain > > > and CN inhome or visited domain may be useful. Currently the text > is > > > not very clear>>> > > > > > > [Qin]: Agree there is room for improvement here, this paragraph will > > be > > > reworded in accordance with the > > > terminologies used in the PS draft > > [Mohana] Ok, thanks. > > > > > In section 4, > > > <<<[Mohana] the first bullet should be changed to administrative > > domain > > > instaed of PMIPv6 domain. The second bullet says MN and CN attached > > to > > > same LMA. But in section 3 it is mentioned inter LMA scenario as > > well. > > > So, I am a bit confused as to whether the solution is not handling > > inter > > > LMA scenario.>>> > > > > > > [Qin]: Yes, inter LMA scenario will be handled in one separate > section > > of > > > our Solution I-D. Our solution I-D mainly focuses on specifying the > > > localize drouting protocol based on the first two scenarios > described > > in > > > the section 3. the common aspect of the first two scenarios is it > does > > not > > > require PMIP6 mobility entities discovery described in the PS draft. > > As > > > regarding to the inter-LMA local routing scenario, it depends on > PMIP6 > > > mobility entities discovery, extra extended PMIP6 signaling is > > required > > > between MN's MAG and CN's LMA. Therefore inter-LMA local routing > case > > is > > > separated from section 4 which is concentrating on the first two > > scenarios > > > and addressed in the independent section, i.e., section 7. > > > > > > [Mohana] Ok, understand. Do not know why I got confused. Probably a > > section outline may be helpful and I leave it to you to handle. > > > > [Qin]: Okay. > > > > > > > > In section 4.1 > > > <<<[Mohana] In this section there is reference to three different > > types > > > of flags such as intra-LMA local routing flag, intra-MAG local > routing > > > flag, Enable detect local routing flag. A description of these in > > > section 2 would be better for easy understanding.>>> > > > > > > [Qin]: Okay. Thank for your suggestion. > > > > > > In section 4.1, para 3, it is mentioned After successful local > routing > > > optimization process, if MN and CN > > > attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA > > > localrouting flag is set to value one, the MAG1 to which the MN > > > attaches may send PBU message to the MAG2 which the CN attaches > to. > > > <<<[Mohana]Here I think there needs to be a rephrasing of sentence. > I > > > think you are referring to MN connected to MAG 1 and CN connected to > > > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange > between > > > th etwo MAGs. The sentence is not clear.>>> > > > > > > [Qin]: Okay, maybe we could say: > > > " > > > MAG1 to which the MN is connected may send PBU message to the MAG2 > to > > > which the CN > > > is connected. > > > " > > [Mohana] probably somewords along the above lines may be useful. > > > > > In section 4.1, in para 3 it is mentioned that MN's MAG is informed > of > > > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's > > MAG > > > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's > > MAGs > > > are engaged in bi-ditectional PBU/PBA. > > > > > > <<<[Mohana]Here I have some comments. > > > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new > > > option. Then MN's MAG can start PBU with CN's MAG. But the > question > > I > > > have is how does CN's MAG create the routing state for MN prefix. > How > > > does the CN's MAG know that this prefix is owned by MN and MN's MAG > is > > > actually proxying that prefix? > > > > > > > > > The same when CN's MAG does PBU to MN's MAG. Probably, after > getting > > > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But > > again > > > to create the the routing state for CN's prefix at MN's MAG the MN's > > MAG > > > should know the prefix CN owns is valid prefix. Otherwise, I don't > see > > > how a valid routing state can be created. > > > > > > So, by reading this I feel a prefix ownership kind of information is > > > needed in the PBU.>>> > > > > > > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's > MAG > > must > > > believe the prefix sent from MN's MAG is owned by MN. Because MN's > MAG > > can > > > check whether prefix is ownd by MN and used to create a valid > routing > > > before it send the prefix to the CN's MAG. That is to say we can > > assume > > > there is a trust relationship between MN's MAG and CN's MAG. In oder > > for > > > this, two possible ways in my mind are, > > > 1) we assume a prior agreement between MN's MAG and CN's MAG. > > > 2) the second way is we use IPSEC to setup Security association > > between > > > MN's MAG and CN's MAG. > > > By these two ways mentioned above, we can have trust relationship > > between > > > MAGs, But what if MN's MAG establish trust relationship with CN's > MAG > > and > > > send the forged MN's prefix to CN's MAG, I think the prefix > ownership > > > validation may be useful in this scenario to help create valid > routing > > > state at CN's MAGs > > > Therefore I would like to address this security threat in our > solution > > I- > > > D.Thanks for your good points. > > > > > > [Mohana] Thanks Qin. Although I liked the Pbu way of establishing > > tunnel between MAGs, this prefix validation seemed important to > address > > the security part. In RFC 5213, LMA is the prefix delegator so such > > issue is not needed. But here, the CN's MAG need such validation. > > Thanks for addressing this part. > > > > [Qin]Agree. > > > > > > In the handover mechanims in section 4.1.1, it is mentioned that the > > > nMAG1 will get context from old MAG (pMAG1). > > > > > > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's > > MAG, > > > how can CN's MAG know that this prefix of MN is valid and nMAG1 is > > > proxying the preifx. Bcos during handoff, the LMA is not involved. > > > nMAG1 has no issue in knowing that MN;s prefix is given by LMA > because > > > when it does PBU to LMA it will know that this is a valid prefix. > But > > > that is not the case with CN's MAG.>>> > > > > > > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and > keeps > > on > > > communication with CN, there is no trust relationship beforehand > > between > > > nMAG1 and MAG2 to which CN is connected. That is true. But I think > > MN's > > > prefix will keep unchanged during handover. The only change to MN is > > MN's > > > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to > validate > > > MN's prefix ownership each time MN hands over? In my understanding, > > prefix > > > ownership validation can be understood as routing reachability > > test(RRT) > > > procedure defined in the RFC3775. But I am not sure RRT procedure > will > > be > > > done each time MN hands over according to RFC3775. > > > > [Mohana] For the handover case, just as in new establishment, the CN > > needs to know that the nMAG is proxying the prefix. So the prefix > > validation method as for new connection can be used here. The RFC 3775 > > way of prefix validation is one way but there is more signaling. > > Probably some assurance from LMA will be good regarding prefix > validity. > > I think this is critical bcos in handover case, LMA is not involved. > So > > to assure fast handoff one would not want the LMA to be involved. > > Furthermore, using your method a distributed handoff management can be > > done without the involvement of pMAG of MN notifying anything to > CN'MAG. > > What I am saying is nMAG of MN can handle the PBU with CN's MAG > without > > old MAG of MN being involved and this will expedite handover state > > convergence. The only thing that is needed in MN's nMAG to tell CN I > > own/proxy this prefix and prefix is valid. > > > > [Qin]: Okay, let me try to understand what you are explaining about > prefix > > ownership validation. > > It seems to me, there are three possible ways to do this task: > > 1) pMAG of MN notify CN's MAG that MN's prefix is valid. > > 2) LMA of CN notify CN's MAG that MN's prefix is valid. > > 3) nMAG of MN itself notify CN's MAG that MN's prefix is valid > > In these three ways, the 3) seems more straightforward and efficient > than > > 1) and 2) to fulfill prefix owndership validation during handover. > > But in some cases, e.g., MN and CN register to the same LMA, LMA may > > notify both MAGs associated with MN and CN that MN's prefix and CN's > > prefix are valid before PBU/PBA exchange between MN's MAG and CN's MAG > > happens. That is to say, prefix owndership validation also can be done > > during LROREQ/LRORSP exhange between MAG and LMA. > > Anyway, I think prefix ownership validation is necessary and useful > > feature that can be used to create valid routing. > > > [Mohana] Thanks for the good break down and analysis. As you have > identified > 3) seems more straightforward and efficient. When you are refering to > LMA involved in prefix validation, I think you are refering to LMA > initaited RO case. I need to further look at your ID for LMA initiated > RO scenario and how LMA is involved during handoff procedures. I will > get back to you soon on this with a little more comments on this > procedure. Thanks. >=20 > [Qin]: As regarding to LMA involved prefix validation, I think it also can > be applicable to MAG Initiated RO case. But one more message from LMA is > required to notify the CN's MAG MN's prefix is valid upon LMA receiving > LROREQ message from MAG. In other words, e.g., MN's MAG requests CN's LMA > to validate CN's prefix ownership by sending LROREQ message including MN- > CN pair mobility option, LMA respond to MN's MAG with LRORSP, at the same > time, LMA notify CN's MAG that MN's prefix is valid by sending LROREQ to > CN's MAG. [Mohana] Ok, agree that even in MAG initiated RO case, LMA can be involved in giving prefix validation. But then again as you have said there is additional signaling from LMA to CN.MAG which can be avoided using method [3]. >=20 > > > Also in section 4.1 in second paragraph it is mentioned that MAG can > > > send LRO req to LMA when Mn and CN are not attached to same MAG. > > > <<<[Mohana] In this case, how does MAG know the CN address. What > > value > > > will be attached in the Mn-CN pair mobility option. Is there some > L2 > > > message sent from Mn to MAG and all CN addresses are given in these. > > > Probably such mentioning will be useful>>> > > > > > > [Qin]: How MAG know the CN address actually is beyond scope of this > > > solution I-D. The possible way is MAG may look at data packet' > > destination > > > address to know CN address.For the case where one MN communicates > with > > one > > > CN, MN-CN pair mobility option may include one MN's info and one > CN's > > info. > > > MN's. For the case where one MN communciates with several CNs, MN-CN > > pair > > > mobility option may include one MN's info and several CNs' info. > > > > [Mohana] Ok, thanks. I was just analyzing the benefits of MAG > initiated > > RO as opposed to LMA initiated RO and wanted to highlight some > benefits > > when MAG initiates RO. I guess how MAG gets the information need not > be > > covered in the draft and it can be out of bound signaling. > > > > [Qin]: Okay, understand. In my opinion, MAG initiated RO is more > > applicable to the local routing > > described in RFC 5213 than LMA initiated RO. But we can not exclude > LMA to > > initiate RO as well. > > > > > > > I have more comments. But rather than sending all at once I thought > I > > > will stop here for now. > > > > > Thanks. > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org > > > [mailto:i-d-announce-bounces@ietf.org] > > > > On Behalf Of Internet-Drafts@ietf.org > > > > Sent: Monday, October 26, 2009 4:30 PM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > Title : Proxy MIP extension for local routing > > > optimization > > > > Author(s) : W. Wu, B. Sarikaya > > > > Filename : draft-wu-netext-local-ro-04.txt > > > > Pages : 32 > > > > Date : 2009-10-26 > > > > > > > > This document extends local routing in proxy Mobile IPv6 and > defines > > > > a localized routing optimization protocol within one PMIPv6 > domain. > > > > The protocol supports IPv4 transport network operation, IPv4 home > > > > address mobility and handover. The Local mobility anchor/mobile > > > > access gateway initiates local routing for the mobile and > > > > correspondent node by sending messages to each mobile access > > > > gateway/local mobility anchor. In case the correspondent node is > > > > connected to another local mobility anchor, the local mobility > > > > anchors connected by the correspondent node needs to be > discovered > > > > firstly so that it can notify its mobile access gateways attached > > by > > > > the correspondent node to the mobile access gateway attached by > the > > > > mobile node afterwards. Mobile access gateways create and refresh > > > > bindings > > > > using proxy binding update and acknowledgement messages. > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII version of the > > > > Internet-Draft. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Sun Nov 22 22:25:54 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB163A683B for ; Sun, 22 Nov 2009 22:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qme2clh3PKEJ for ; Sun, 22 Nov 2009 22:25:53 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D4B113A67F0 for ; Sun, 22 Nov 2009 22:25:52 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ009B8TQOOZ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 14:23:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ000MJTQOKD@szxga03-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 14:23:12 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTJ00N99TQN0T@szxml06-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 14:23:12 +0800 (CST) Date: Mon, 23 Nov 2009 14:23:11 +0800 From: Qin Wu To: Marco Liebsch , netext@ietf.org Message-id: <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B0664E5.6060901@nw.neclab.eu> Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 06:25:54 -0000 Hi, Marco: Thank for your raising discussion on Multi-LMA issue. Please see my comments inline! Regards! -Qin ----- Original Message ----- From: "Marco Liebsch" To: Sent: Friday, November 20, 2009 5:44 PM Subject: [netext] multi-LMA : how to handle > Folks, > > as a follow up of our discussion about localized routing in a > multi-LMA setup, I'd like to initiate a general and clarifying > discussion about signaling paths to set up and maintain a > localized routing path, as current solution proposals cover > different approaches. > > We had the discussion about PMIPv6 domains vs provider domains > and came to the conclusion that it's not mandatory for MN and CN > to share the same PMIPv6 domain. > > Assume MN connects to MAG1 and LMA1, whereas CN connects > to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 > and MAG2 shares a PMIP domain with LMA2. We cannot assume > that MAG1 shares a PMIP domain with LMA2. > > Now, there are two questions to solve: > (1) Who detects and initiates localized routing, MAG or LMA [Qin]: I think Both have its value and are applicable to different scenarios. Whether using MAG initiated or using LMA initiated depends on who detects localized routing, in other words, if MAG detects local routing is possible, then MAG initiated is more appropriate. e.g., As described in RFC5213, in the scenario where MN and CN attach to the same MAG, MAG initiated local routing can be used to negotiate with LMA and enfoce local routing on the MAG. If LMA is responsible for local routing, then LMA inititated and MAG initiate both can be used. e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA. > (2) How to synchronize distributed states? Will LMA1 contact > LMA2 or will MAG1 contact LMA2 > > If an existing SA is the only indicator to set up a PMIPv6 > domain, then one solution could be to set up an SA dynamically > between MAG1 and LMA2, which needs to be re-done every time > MN1 performs a handover to a different MAG, say MAG1*. This > may be a disadvantage and will blow up PMIPv6 domains, which > are rather administratively configured, in my opinion. [Qin]: It seems to me SA setup each time MN handover to the new MAG is one generic issue we should face for all the Multi-LMA cases. In other words,When using LMA1 to signal with LMA2 for states synchroizing, it has the same problem. Suppose MN connect to the LMA1, each time the MN handover from previous MAG to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again. >From the other aspect, in the Multi-LMA scenario, when MAG1 talks with LMA2, if there is no SA between MAG1 and LMA2, we can ask LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2. Also since SA is setup between one MAG and one LMA, upon the first MN who is attaching to the MAG triggers this MAG to setup SA with LMA, the SA can also be used by the other MN who attach to the same MAG to protect the data traffic between MAG and LMA Therefore the second MN who is attaching to the same MAG may not setup SA again. Because all the existing SA can be reused. Therefore SA setup is not a big issue, the biggest issue is: 1) who discover CN's LMA address? 2) how does he discover CN's LMA address? One example is , If AAA based CN's LMA discovery can be used, we can ask AAA server push the keying materails which is used to protect the trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's LMA respectively. In this sense, the trust relationship between MN's MAG and CN's LMA can be easily setup. > The other alternative is that PMIPv6 domain stractures are not touched > and LMA1 will signal with LMA2 to synchronize states of MN and CN. > Advantage would be that LMAs do not change during a handover and > will keep states on one place. [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address? > Any opinions? > > marco > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Sun Nov 22 22:45:31 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9A93A6850 for ; Sun, 22 Nov 2009 22:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4-1+K9viV3G for ; Sun, 22 Nov 2009 22:45:29 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 19DAE3A67F0 for ; Sun, 22 Nov 2009 22:45:29 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ0034WUNGCR@szxga03-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 14:42:52 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ0047VUNGP1@szxga03-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 14:42:52 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTJ000QGUNGOZ@szxml04-in.huawei.com> for netext@ietf.org; Mon, 23 Nov 2009 14:42:52 +0800 (CST) Date: Mon, 23 Nov 2009 14:42:51 +0800 From: Qin Wu To: Mohana Jeyatharan Message-id: <019401ca6c08$2e2e60d0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local> <006601ca6987$e49609a0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FB9A@pslexc01.psl.local> <04e701ca69bb$07ef6210$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FCDA@pslexc01.psl.local> <00f701ca6bea$f626fcf0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B3FE81@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 06:45:32 -0000 Hi, Mohana: Please see my comments inline. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: "Qin Wu" Cc: Sent: Monday, November 23, 2009 1:55 PM Subject: RE: [netext] Comments on :draft-wu-netext-local-ro-04.txt Hi Qin, Please see some replies below. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Qin Wu > Sent: Monday, November 23, 2009 11:14 AM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt > > > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" > Cc: > Sent: Friday, November 20, 2009 5:44 PM > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt > > > Hi Qin, > > Please see my short comments below. > > BR, > Mohana > > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Friday, November 20, 2009 4:26 PM > > To: Mohana Jeyatharan > > Cc: netext@ietf.org > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > > > Hi, Mohana: > > Thank for your quick response, please see my feedback inline. > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Mohana Jeyatharan" > > To: "Qin Wu" > > Cc: > > Sent: Friday, November 20, 2009 12:10 PM > > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > Hi Qin, > > > > Thanks for reply. Please see some replies in-line. > > > > BR, > > Mohana > > > > > -----Original Message----- > > > From: Qin Wu [mailto:sunseawq@huawei.com] > > > Sent: Friday, November 20, 2009 10:19 AM > > > To: Mohana Jeyatharan > > > Cc: netext@ietf.org > > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > Hi, Mohana: > > > Sorry for my late reply. Also thank you for your review and > comments. > > > please see my reply inline. > > > > > > Regards! > > > -Qin > > > ----- Original Message ----- > > > From: "Mohana Jeyatharan" > > > To: "Qin Wu" > > > Cc: > > > Sent: Monday, November 16, 2009 9:59 AM > > > Subject: Comments on :draft-wu-netext-local-ro-04.txt > > > > > > > > > > > > Hi Qin, > > > > > > Read your ID. I have few comments. > > > > > > Please see below. > > > > > > BR, > > > Mohana > > > > > > In abstract, > > > "In case the correspondent node is > > > connected to another local mobility anchor, the local mobility > > > anchors connected by the correspondent node needs to be > discovered > > > firstly so that it can notify its mobile access gateways > attached > > by > > > the correspondent node to the mobile access gateway attached by > > the > > > mobile node afterwards." > > > > > > <<<[Mohana] In abstract it is not very clear which entitiy notifies > > CN's > > > MAG to MN's MAG. Perhaps a rewording may be useful>>> > > > > > > [Qin]: Yes, what we are really saying here is CN's LMA will notify > > CN's > > > MAG to MN's MAG when MN's MAG > > > communicate with CN's LMA using normal PBU/PBA. Maybe the proper way > > to > > > say would be > > > " > > > so that the discovered local mobility anchor notity its mobile > access > > > gateways attached by the correspondent node...... > > > " > > [Mohana] So, the description is tied to CN's LMA notifying MN's MAG to > > CN's MAG. Ok, understand. But some description on MN's LMA notifying > > CN's MAG to MN's MAG will be also useful in the inter-LMA scenario. > > What I am not clear is why is MN's MAG connected to CN's LMA? > Probably > > this is another scenario addressed in scetion 7(inter LMA case). > Anyway > > I will leave it for now. If MN's MAG is connected to CN's LMA, then > > such passing (CN's LMA passing CN MAG address to MN's MAG)is propoer. > > Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA. > > > > [Qin]: Your understanding is correct. In the Inter-LMA local routing > > scenario, > > MN and CN attach to different MAGs and registers to different LMA > > respectively. > > In this scenario, MN's LMA does not know CN's MAG address, what we can > do > > here > > is to let MN's MAG talk with CN's LMA, then CN's LMA can tell MN's MAG > > about > > CN's MAG address. > > but if MN and CN share the same LMA, then it does not matter whether > MN's > > LMA or > > CN's LMA notitfy CN's MAG to MN's MAG, > > because MN's LMA is CN's LMA. > > [Mohana] Ok, do not want to dwell on this too much. So you are saying > that CN MAG address is passed to MN MAG by CN LMA. A short question I > have is how does CN LMA address is known to MN MAG. Anyway, I need to > read the inter-LMA part in more detail. > > [Qin]: PMIP6 mobility entities discovery( i.e., LMA) described in PS draft > will be used to > obtain CN LMA address. In our solution I-D, one AAA mechanism can be > adopted to perform > PMIP6 mobility entities discovery. The details can be read in another I- > D,i.e., draft-wu-dime-pmip6-lr-01. > > > [Mohana] Ok, so when LMA1(MAG1(Mn)) and LMA2(MAG2(CN)) are in the same domain, I guess this mechanism AAA based can be used to find CN LMA address. But when LMA of Mn and LMA of CN are in different domains, and MN and CN placed in another visited domain, then discovery of CN LMA address may be more difficult using the AAA. Am I right to say that? Also it depends whether the solution space is looking at LMAs placed in different provider domains and MN and CN placed in another visited domain. [Qin]: Even LMA1 and LMA2 are located in the different domains, AAA mechanism also can be used to find CN's LMA address. Because AAA mechanism has its scalability and flexibility. AAA server can be depolyed in the home and visited domain. Also the AAA server in one domain can communicate with the AAA server in another domain. Therefore it is not difficult to use AAA mechanism to discover CN's LMA in one domain different from MN's LMA. Because the AAA message can be routed or redirected to the right domain in which CN's home AAA server is located. > > > In abstract, Mobile access gateways create and refresh bindings > > > using proxy binding update and acknowledgement messages. > > > > > > <<<[Mohana] What is the reason for this. Is this refering to PBU to > > LMA > > > or PBU to MAG? Perhaps more clarity on this will help.>>> > > > > > > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create > > binding > > > when it is the first time for MAGs to setup localized routing path. > > > during handover case, PBU/PBA will be used between MAGs to refresh > > binding. > > > The reason to create and refresh bindings between MAGs attached by > > mobile > > > node and correspondent node is quite similar to correspondent > > registration > > > in the Mobile IPv6 Routing optimization between mobile node and > > > correspondent node described in the section 11.7.2 of RFC3775. > > > i.e., allowing correspondent node to cache mobile node's proxy > care-of > > > address or allowing mobile node to cache correspondent node' proxy > > care-of > > > address, > > [Mohana]I agree with your approach of using PBU/PBA for routing state > > setup and tunnel setup between MAGs and think that is a good approach > > and tied to RFC 5213 way. From further reading of your draft I > > understand this. All I wanted to say is that in abstract, a > mentioning > > of PBU/PBA from MAG to MAG introduces more clarity. That is all. > > > > [Qin]: Okay, agree. > > > > > > > > In conventions used section it is mentioned > > > > > > Local routing: Traffic between MN and CN does not pass through LMA > > > and is locally routed in the same PMIPv6 domain. > > > > > > <<<[Mohana] Perhaps a re-wording may be necessary when referring to > > > PMIPv6 domain. This should be aligned with the PS draft terminology. > > It > > > should be same provider domain running PMIPv6 or some thing like > > > that.>>> > > > > > > [Qin]: Okay, will check the wording to be consistent with PS draft. > > > > > > In conventions used section it is mentioned > > > Local Routing Optimization Request (LROREQ): A message initiated by > > > the MAG or LMA requesting the MAG or LMA to establish local > routing > > > optimization path between MN and at least one pair of CNs who > > > communicate with MN. > > > <<<[Mohana] why is there reference to at least one pair of CN. Are > u > > > saying at least a single CN? Not very clear>>> > > > > > > [Qin]: Right, thank for your good catching and correction. The > reason > > to > > > say at least one CN is > > > in some cases, maybe MN will communicate with more than one CN, in > > this > > > sense, LROREQ > > > message may be sent from MN's LMA to each MAGs attached by serveral > > CNs > > > which is communicating with MN. > > > or sent from MN's MAG to each LMA which is registered by more than > one > > CNs > > > which is communicating with MN during inter-LMA handover case. > > > > > [Mohana]Ok, sure I understand your intention proabably a minor > > re-wording would do. > > > > [Qin]: Right. > > > > > In section 3 Scenario analysis for PMIPv6 local routing > > > > > > <<<[Mohana]The text before the figure 1 is refering to PMIPv6 > domain. > > > Again I think this should be single administrative/provider domain > > > running PMIpv6.>>> > > > > > > [Qin]: Okay. > > > > > > In figure 1, > > > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport > to > > > LMA.>>> > > > > > > [Qin]: I am okay with this change in the figure 1. > > > > > > In last para in section 3 which is > > > In all the above scenarios, MN is allowed to roam within its PMIPv6 > > > domain (i.e, MN's home domain in which MN's LMA is located) or > move > > > from one PMIPv6 domains(i.e., MN's visited domains)to another. CN > > > should stay with MN within the same PMIPv6 domain, e.g., MN moves > > to > > > the visited domain to which CN belongs. Another example is MN and > > CN > > > move to the same visited domain to which MN's LMA or CN's LMA > does > > > not belong. > > > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative > > > domain. Probably re-writing with respect to MN in home or visited > > domain > > > and CN inhome or visited domain may be useful. Currently the text > is > > > not very clear>>> > > > > > > [Qin]: Agree there is room for improvement here, this paragraph will > > be > > > reworded in accordance with the > > > terminologies used in the PS draft > > [Mohana] Ok, thanks. > > > > > In section 4, > > > <<<[Mohana] the first bullet should be changed to administrative > > domain > > > instaed of PMIPv6 domain. The second bullet says MN and CN attached > > to > > > same LMA. But in section 3 it is mentioned inter LMA scenario as > > well. > > > So, I am a bit confused as to whether the solution is not handling > > inter > > > LMA scenario.>>> > > > > > > [Qin]: Yes, inter LMA scenario will be handled in one separate > section > > of > > > our Solution I-D. Our solution I-D mainly focuses on specifying the > > > localize drouting protocol based on the first two scenarios > described > > in > > > the section 3. the common aspect of the first two scenarios is it > does > > not > > > require PMIP6 mobility entities discovery described in the PS draft. > > As > > > regarding to the inter-LMA local routing scenario, it depends on > PMIP6 > > > mobility entities discovery, extra extended PMIP6 signaling is > > required > > > between MN's MAG and CN's LMA. Therefore inter-LMA local routing > case > > is > > > separated from section 4 which is concentrating on the first two > > scenarios > > > and addressed in the independent section, i.e., section 7. > > > > > > [Mohana] Ok, understand. Do not know why I got confused. Probably a > > section outline may be helpful and I leave it to you to handle. > > > > [Qin]: Okay. > > > > > > > > In section 4.1 > > > <<<[Mohana] In this section there is reference to three different > > types > > > of flags such as intra-LMA local routing flag, intra-MAG local > routing > > > flag, Enable detect local routing flag. A description of these in > > > section 2 would be better for easy understanding.>>> > > > > > > [Qin]: Okay. Thank for your suggestion. > > > > > > In section 4.1, para 3, it is mentioned After successful local > routing > > > optimization process, if MN and CN > > > attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA > > > localrouting flag is set to value one, the MAG1 to which the MN > > > attaches may send PBU message to the MAG2 which the CN attaches > to. > > > <<<[Mohana]Here I think there needs to be a rephrasing of sentence. > I > > > think you are referring to MN connected to MAG 1 and CN connected to > > > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange > between > > > th etwo MAGs. The sentence is not clear.>>> > > > > > > [Qin]: Okay, maybe we could say: > > > " > > > MAG1 to which the MN is connected may send PBU message to the MAG2 > to > > > which the CN > > > is connected. > > > " > > [Mohana] probably somewords along the above lines may be useful. > > > > > In section 4.1, in para 3 it is mentioned that MN's MAG is informed > of > > > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's > > MAG > > > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's > > MAGs > > > are engaged in bi-ditectional PBU/PBA. > > > > > > <<<[Mohana]Here I have some comments. > > > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new > > > option. Then MN's MAG can start PBU with CN's MAG. But the > question > > I > > > have is how does CN's MAG create the routing state for MN prefix. > How > > > does the CN's MAG know that this prefix is owned by MN and MN's MAG > is > > > actually proxying that prefix? > > > > > > > > > The same when CN's MAG does PBU to MN's MAG. Probably, after > getting > > > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But > > again > > > to create the the routing state for CN's prefix at MN's MAG the MN's > > MAG > > > should know the prefix CN owns is valid prefix. Otherwise, I don't > see > > > how a valid routing state can be created. > > > > > > So, by reading this I feel a prefix ownership kind of information is > > > needed in the PBU.>>> > > > > > > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's > MAG > > must > > > believe the prefix sent from MN's MAG is owned by MN. Because MN's > MAG > > can > > > check whether prefix is ownd by MN and used to create a valid > routing > > > before it send the prefix to the CN's MAG. That is to say we can > > assume > > > there is a trust relationship between MN's MAG and CN's MAG. In oder > > for > > > this, two possible ways in my mind are, > > > 1) we assume a prior agreement between MN's MAG and CN's MAG. > > > 2) the second way is we use IPSEC to setup Security association > > between > > > MN's MAG and CN's MAG. > > > By these two ways mentioned above, we can have trust relationship > > between > > > MAGs, But what if MN's MAG establish trust relationship with CN's > MAG > > and > > > send the forged MN's prefix to CN's MAG, I think the prefix > ownership > > > validation may be useful in this scenario to help create valid > routing > > > state at CN's MAGs > > > Therefore I would like to address this security threat in our > solution > > I- > > > D.Thanks for your good points. > > > > > > [Mohana] Thanks Qin. Although I liked the Pbu way of establishing > > tunnel between MAGs, this prefix validation seemed important to > address > > the security part. In RFC 5213, LMA is the prefix delegator so such > > issue is not needed. But here, the CN's MAG need such validation. > > Thanks for addressing this part. > > > > [Qin]Agree. > > > > > > In the handover mechanims in section 4.1.1, it is mentioned that the > > > nMAG1 will get context from old MAG (pMAG1). > > > > > > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's > > MAG, > > > how can CN's MAG know that this prefix of MN is valid and nMAG1 is > > > proxying the preifx. Bcos during handoff, the LMA is not involved. > > > nMAG1 has no issue in knowing that MN;s prefix is given by LMA > because > > > when it does PBU to LMA it will know that this is a valid prefix. > But > > > that is not the case with CN's MAG.>>> > > > > > > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and > keeps > > on > > > communication with CN, there is no trust relationship beforehand > > between > > > nMAG1 and MAG2 to which CN is connected. That is true. But I think > > MN's > > > prefix will keep unchanged during handover. The only change to MN is > > MN's > > > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to > validate > > > MN's prefix ownership each time MN hands over? In my understanding, > > prefix > > > ownership validation can be understood as routing reachability > > test(RRT) > > > procedure defined in the RFC3775. But I am not sure RRT procedure > will > > be > > > done each time MN hands over according to RFC3775. > > > > [Mohana] For the handover case, just as in new establishment, the CN > > needs to know that the nMAG is proxying the prefix. So the prefix > > validation method as for new connection can be used here. The RFC 3775 > > way of prefix validation is one way but there is more signaling. > > Probably some assurance from LMA will be good regarding prefix > validity. > > I think this is critical bcos in handover case, LMA is not involved. > So > > to assure fast handoff one would not want the LMA to be involved. > > Furthermore, using your method a distributed handoff management can be > > done without the involvement of pMAG of MN notifying anything to > CN'MAG. > > What I am saying is nMAG of MN can handle the PBU with CN's MAG > without > > old MAG of MN being involved and this will expedite handover state > > convergence. The only thing that is needed in MN's nMAG to tell CN I > > own/proxy this prefix and prefix is valid. > > > > [Qin]: Okay, let me try to understand what you are explaining about > prefix > > ownership validation. > > It seems to me, there are three possible ways to do this task: > > 1) pMAG of MN notify CN's MAG that MN's prefix is valid. > > 2) LMA of CN notify CN's MAG that MN's prefix is valid. > > 3) nMAG of MN itself notify CN's MAG that MN's prefix is valid > > In these three ways, the 3) seems more straightforward and efficient > than > > 1) and 2) to fulfill prefix owndership validation during handover. > > But in some cases, e.g., MN and CN register to the same LMA, LMA may > > notify both MAGs associated with MN and CN that MN's prefix and CN's > > prefix are valid before PBU/PBA exchange between MN's MAG and CN's MAG > > happens. That is to say, prefix owndership validation also can be done > > during LROREQ/LRORSP exhange between MAG and LMA. > > Anyway, I think prefix ownership validation is necessary and useful > > feature that can be used to create valid routing. > > > [Mohana] Thanks for the good break down and analysis. As you have > identified > 3) seems more straightforward and efficient. When you are refering to > LMA involved in prefix validation, I think you are refering to LMA > initaited RO case. I need to further look at your ID for LMA initiated > RO scenario and how LMA is involved during handoff procedures. I will > get back to you soon on this with a little more comments on this > procedure. Thanks. > > [Qin]: As regarding to LMA involved prefix validation, I think it also can > be applicable to MAG Initiated RO case. But one more message from LMA is > required to notify the CN's MAG MN's prefix is valid upon LMA receiving > LROREQ message from MAG. In other words, e.g., MN's MAG requests CN's LMA > to validate CN's prefix ownership by sending LROREQ message including MN- > CN pair mobility option, LMA respond to MN's MAG with LRORSP, at the same > time, LMA notify CN's MAG that MN's prefix is valid by sending LROREQ to > CN's MAG. [Mohana] Ok, agree that even in MAG initiated RO case, LMA can be involved in giving prefix validation. But then again as you have said there is additional signaling from LMA to CN.MAG which can be avoided using method [3]. [Qin]: Agree. > > > > Also in section 4.1 in second paragraph it is mentioned that MAG can > > > send LRO req to LMA when Mn and CN are not attached to same MAG. > > > <<<[Mohana] In this case, how does MAG know the CN address. What > > value > > > will be attached in the Mn-CN pair mobility option. Is there some > L2 > > > message sent from Mn to MAG and all CN addresses are given in these. > > > Probably such mentioning will be useful>>> > > > > > > [Qin]: How MAG know the CN address actually is beyond scope of this > > > solution I-D. The possible way is MAG may look at data packet' > > destination > > > address to know CN address.For the case where one MN communicates > with > > one > > > CN, MN-CN pair mobility option may include one MN's info and one > CN's > > info. > > > MN's. For the case where one MN communciates with several CNs, MN-CN > > pair > > > mobility option may include one MN's info and several CNs' info. > > > > [Mohana] Ok, thanks. I was just analyzing the benefits of MAG > initiated > > RO as opposed to LMA initiated RO and wanted to highlight some > benefits > > when MAG initiates RO. I guess how MAG gets the information need not > be > > covered in the draft and it can be out of bound signaling. > > > > [Qin]: Okay, understand. In my opinion, MAG initiated RO is more > > applicable to the local routing > > described in RFC 5213 than LMA initiated RO. But we can not exclude > LMA to > > initiate RO as well. > > > > > > > I have more comments. But rather than sending all at once I thought > I > > > will stop here for now. > > > > > Thanks. > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org > > > [mailto:i-d-announce-bounces@ietf.org] > > > > On Behalf Of Internet-Drafts@ietf.org > > > > Sent: Monday, October 26, 2009 4:30 PM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > Title : Proxy MIP extension for local routing > > > optimization > > > > Author(s) : W. Wu, B. Sarikaya > > > > Filename : draft-wu-netext-local-ro-04.txt > > > > Pages : 32 > > > > Date : 2009-10-26 > > > > > > > > This document extends local routing in proxy Mobile IPv6 and > defines > > > > a localized routing optimization protocol within one PMIPv6 > domain. > > > > The protocol supports IPv4 transport network operation, IPv4 home > > > > address mobility and handover. The Local mobility anchor/mobile > > > > access gateway initiates local routing for the mobile and > > > > correspondent node by sending messages to each mobile access > > > > gateway/local mobility anchor. In case the correspondent node is > > > > connected to another local mobility anchor, the local mobility > > > > anchors connected by the correspondent node needs to be > discovered > > > > firstly so that it can notify its mobile access gateways attached > > by > > > > the correspondent node to the mobile access gateway attached by > the > > > > mobile node afterwards. Mobile access gateways create and refresh > > > > bindings > > > > using proxy binding update and acknowledgement messages. > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII version of the > > > > Internet-Draft. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Mon Nov 23 01:47:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190703A6784 for ; Mon, 23 Nov 2009 01:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-AubkzXJZda for ; Mon, 23 Nov 2009 01:47:12 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id AD0043A68A5 for ; Mon, 23 Nov 2009 01:47:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B67082C01898B; Mon, 23 Nov 2009 10:47:07 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urQBqUR7+MDr; Mon, 23 Nov 2009 10:47:07 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 882B02C0002FE; Mon, 23 Nov 2009 10:46:57 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 10:46:57 +0100 Message-ID: <4B0A5A0D.9030401@nw.neclab.eu> Date: Mon, 23 Nov 2009 10:46:53 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Qin Wu References: <4B0664E5.6060901@nw.neclab.eu> <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> In-Reply-To: <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2009 09:46:57.0778 (UTC) FILETIME=[E5C03520:01CA6C21] Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:47:13 -0000 Hi Qin, please find my comments inline. Qin Wu wrote: > Hi, Marco: > Thank for your raising discussion on Multi-LMA issue. > Please see my comments inline! > > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: > Sent: Friday, November 20, 2009 5:44 PM > Subject: [netext] multi-LMA : how to handle > > > >> Folks, >> >> as a follow up of our discussion about localized routing in a >> multi-LMA setup, I'd like to initiate a general and clarifying >> discussion about signaling paths to set up and maintain a >> localized routing path, as current solution proposals cover >> different approaches. >> >> We had the discussion about PMIPv6 domains vs provider domains >> and came to the conclusion that it's not mandatory for MN and CN >> to share the same PMIPv6 domain. >> >> Assume MN connects to MAG1 and LMA1, whereas CN connects >> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 >> and MAG2 shares a PMIP domain with LMA2. We cannot assume >> that MAG1 shares a PMIP domain with LMA2. >> >> Now, there are two questions to solve: >> (1) Who detects and initiates localized routing, MAG or LMA >> > > [Qin]: I think Both have its value and are applicable to different scenarios. Whether using MAG initiated or using LMA initiated depends on > who detects localized routing, in other words, if MAG detects local routing is possible, then MAG initiated is more appropriate. > e.g., As described in RFC5213, in the scenario where MN and CN attach to the same MAG, MAG initiated local routing can > be used to negotiate with LMA and enfoce local routing on the MAG. > Only in single MAG case it may make sense that the MAG detects and establishes a localized route. However, even in such case, the LMA must control/enforce the setup of the localized route as per RFC5213. So, the LMA is the point of control and my personal opinion is that this is reasonable, as the LMA maintains states beyond a single MAG. And, dependent on the mechanism behind HNP assignment (address pools, delegation, ...), the LMA may know if the setup of a localized route is useful (in case CN is local) or not. > If LMA is responsible for local routing, then LMA inititated and MAG initiate both can be used. > e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA. > Since the LMA needs to enforce localized routing in all cases, I personally see the LMA as detector. If for some reason the MAG may be able to detect, it should inform the LMA of the attached MN to enforce localized routing. > >> (2) How to synchronize distributed states? Will LMA1 contact >> LMA2 or will MAG1 contact LMA2 >> >> If an existing SA is the only indicator to set up a PMIPv6 >> domain, then one solution could be to set up an SA dynamically >> between MAG1 and LMA2, which needs to be re-done every time >> MN1 performs a handover to a different MAG, say MAG1*. This >> may be a disadvantage and will blow up PMIPv6 domains, which >> are rather administratively configured, in my opinion. >> > > [Qin]: It seems to me SA setup each time MN handover to the new MAG is one generic issue we should face for all the Multi-LMA cases. > In other words,When using LMA1 to signal with LMA2 for states synchroizing, it has the same problem. Suppose MN connect to the LMA1, > each time the MN handover from previous MAG to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again. > there is a big difference between localized routing associations between MAGs and handover between MAGs. Handover is between globally adjacent ARs/MAGs, hence, I think an LMA maintains an SA with an MN's MAG and potential handover targets. If you would establish them each time a handover occurs, this would have impact to the handover latency. Don't think this is how PMIP is deployed. Now, localized routing between MN and CN could mean that MN's MAG and CN's MAG are pretty far apart. Different LMAs could serve different PMIPv6 domains. I don't think it's reasonable to merge these PMIP domains dynamically by means of establishing an SA between MN's MAG and CN's LMA. Rather LMAs could take care about the setup of the route between these MAGs. If both LMAs are in different PMIP domains but in the same provider network, such signaling is simple. > From the other aspect, in the Multi-LMA scenario, when MAG1 talks with LMA2, if there is no SA between MAG1 and LMA2, we can ask > LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2. > Who is "we" ("...we can ask LMA2...")? It's MAG1, right? > Also since SA is setup between one MAG and one LMA, upon the first MN who is attaching to the MAG triggers this MAG to setup SA with LMA, > the SA can also be used by the other MN who attach to the same MAG to protect the data traffic between MAG and LMA Therefore the second MN who > is attaching to the same MAG may not setup SA again. Because all the existing SA can be reused. > > Therefore SA setup is not a big issue, the biggest issue is: > 1) who discover CN's LMA address? > 2) how does he discover CN's LMA address? > "Who?" should be the LMA, as you need to discovery only once, whereas if it's the MAG, each handover MAG needs to discover again, unless you make the localized routing protocol dependent on CTX, which is not a good approach. "How?" could be different approaches. Static solutions could be based on the LMA's knowledge about address/HNP pools for HNP assignment to attaching MNs. Dynamic solutions could be based on a AAA infrastructure as you referred to above. I don't think this particular "How?" should be addressed by the localized routing solution. > One example is , If AAA based CN's LMA discovery can be used, we can ask AAA server push the keying materails which is used to protect the trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's LMA respectively. In this sense, the trust relationship between MN's MAG and CN's LMA can be easily setup. > > >> The other alternative is that PMIPv6 domain stractures are not touched >> and LMA1 will signal with LMA2 to synchronize states of MN and CN. >> Advantage would be that LMAs do not change during a handover and >> will keep states on one place. >> > > [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address? > Same as MAG1 may discover LMA2, with many advantages if you do this from LMA1. marco > >> Any opinions? >> >> marco >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> From rkoodli@starentnetworks.com Mon Nov 23 18:59:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EE328C1E1 for ; Mon, 23 Nov 2009 18:59: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqXSFoSs0k4Z for ; Mon, 23 Nov 2009 18:59:50 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 6CFB43A680F for ; Mon, 23 Nov 2009 18:59:50 -0800 (PST) X-ASG-Debug-ID: 1259031585-5c3970d20001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id QHrj9DYm0HLEFTV7 for ; Mon, 23 Nov 2009 21:59:45 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Nov 2009 21:58: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 X-ASG-Orig-Subj: RE: [netext] multi-LMA : how to handle Date: Mon, 23 Nov 2009 22:00:09 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> In-Reply-To: <4B0664E5.6060901@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] multi-LMA : how to handle Thread-Index: AcppxfKXPBIFPDU5R3WLoHm+mK5N9gC67P9w References: <4B0664E5.6060901@nw.neclab.eu> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 24 Nov 2009 02:58:48.0195 (UTC) FILETIME=[0B3C2530:01CA6CB2] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1259031585 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:59:51 -0000 =20 Hi Marco, All, Why do we need to solve this case? (I know we have documented in the PS ID). >From what I can tell, there are two nodes in two different PMIPv6 domains attached to two different MAGs and two different LMAs. What use case will require us to address this scenario?=20 We can still address roaming by considering scenarios A11, A12, A21 in the PS document. What we need is an indication in the LMA that the visiting node(s) are allowed to be offered with LR. We should include that. Thanks, -Rajeev > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch > Sent: Friday, November 20, 2009 1:44 AM > To: netext@ietf.org > Subject: [netext] multi-LMA : how to handle >=20 > Folks, >=20 > as a follow up of our discussion about localized routing in a=20 > multi-LMA setup, I'd like to initiate a general and=20 > clarifying discussion about signaling paths to set up and=20 > maintain a localized routing path, as current solution=20 > proposals cover different approaches. >=20 > We had the discussion about PMIPv6 domains vs provider=20 > domains and came to the conclusion that it's not mandatory=20 > for MN and CN to share the same PMIPv6 domain. >=20 > Assume MN connects to MAG1 and LMA1, whereas CN connects to=20 > MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2=20 > shares a PMIP domain with LMA2. We cannot assume that MAG1=20 > shares a PMIP domain with LMA2. >=20 > Now, there are two questions to solve: > (1) Who detects and initiates localized routing, MAG or LMA > (2) How to synchronize distributed states? Will LMA1 contact > LMA2 or will MAG1 contact LMA2 >=20 > If an existing SA is the only indicator to set up a PMIPv6=20 > domain, then one solution could be to set up an SA=20 > dynamically between MAG1 and LMA2, which needs to be re-done=20 > every time > MN1 performs a handover to a different MAG, say MAG1*. This=20 > may be a disadvantage and will blow up PMIPv6 domains, which=20 > are rather administratively configured, in my opinion. >=20 > The other alternative is that PMIPv6 domain stractures are=20 > not touched and LMA1 will signal with LMA2 to synchronize=20 > states of MN and CN. > Advantage would be that LMAs do not change during a handover=20 > and will keep states on one place. >=20 > Any opinions? >=20 > marco >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From sunseawq@huawei.com Tue Nov 24 00:16:53 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EFB3A6B57 for ; Tue, 24 Nov 2009 00:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAJSYYCAoWWp for ; Tue, 24 Nov 2009 00:16:51 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 828FD3A6867 for ; Tue, 24 Nov 2009 00:16:51 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTL006NITNOER@szxga02-in.huawei.com> for netext@ietf.org; Tue, 24 Nov 2009 16:16:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTL00DAUTNOMS@szxga02-in.huawei.com> for netext@ietf.org; Tue, 24 Nov 2009 16:16:36 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTL00KX2TNO2A@szxml04-in.huawei.com> for netext@ietf.org; Tue, 24 Nov 2009 16:16:36 +0800 (CST) Date: Tue, 24 Nov 2009 16:16:35 +0800 From: Qin Wu To: Marco Liebsch Message-id: <02fb01ca6cde$70cccd10$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B0664E5.6060901@nw.neclab.eu> <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> <4B0A5A0D.9030401@nw.neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:16:53 -0000 Hi, Marco: Thank for your reply, please see my comments inline. Regards! -Qin ----- Original Message ----- From: "Marco Liebsch" To: "Qin Wu" Cc: Sent: Monday, November 23, 2009 5:46 PM Subject: Re: [netext] multi-LMA : how to handle > Hi Qin, > > please find my comments inline. > > Qin Wu wrote: >> Hi, Marco: >> Thank for your raising discussion on Multi-LMA issue. >> Please see my comments inline! >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Marco Liebsch" >> To: >> Sent: Friday, November 20, 2009 5:44 PM >> Subject: [netext] multi-LMA : how to handle >> >> >> >>> Folks, >>> >>> as a follow up of our discussion about localized routing in a >>> multi-LMA setup, I'd like to initiate a general and clarifying >>> discussion about signaling paths to set up and maintain a >>> localized routing path, as current solution proposals cover >>> different approaches. >>> >>> We had the discussion about PMIPv6 domains vs provider domains >>> and came to the conclusion that it's not mandatory for MN and CN >>> to share the same PMIPv6 domain. >>> >>> Assume MN connects to MAG1 and LMA1, whereas CN connects >>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 >>> and MAG2 shares a PMIP domain with LMA2. We cannot assume >>> that MAG1 shares a PMIP domain with LMA2. >>> >>> Now, there are two questions to solve: >>> (1) Who detects and initiates localized routing, MAG or LMA >> [Qin]: I think Both have its value and are applicable to different scenarios. Whether using MAG initiated or using LMA initiated depends on >> who detects localized routing, in other words, if MAG detects local routing is possible, then MAG initiated is more appropriate. >> e.g., As described in RFC5213, in the scenario where MN and CN attach to the same MAG, MAG initiated local routing can >> be used to negotiate with LMA and enfoce local routing on the MAG. > Only in single MAG case it may make sense that the MAG detects and > establishes > a localized route. However, even in such case, the LMA must control/enforce > the setup of the localized route as per RFC5213. So, the LMA > is the point of control and my personal opinion is that this is > reasonable, as the > LMA maintains states beyond a single MAG. And, dependent on the mechanism > behind HNP assignment (address pools, delegation, ...), the LMA may know if > the setup of a localized route is useful (in case CN is local) or not. [Qin]: Right, single MAG case is more appropirate to apply MAG initiated local routing. Also single MAG case can be divided into two sub cases: i.e.,A11 and A12 described in the PS draft. These two sub cases should be taken care in the solution draft. On the other hand, I agree LMA control the setup of localized routing, but it seems to me who initiate localized routing does not depend on who control the setup of the localized route. In the MAG initiate localized routing, MAG can initiate local routing with LMA to see whether localized routing is available. >> If LMA is responsible for local routing, then LMA inititated and MAG initiate both can be used. >> e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA. >> > Since the LMA needs to enforce localized routing in all cases, I > personally see the > LMA as detector. [Qin]: Okay. >If for some reason the MAG may be able to detect, it should > inform the LMA of the attached MN to enforce localized routing. [Qin]: I agee. >>> (2) How to synchronize distributed states? Will LMA1 contact >>> LMA2 or will MAG1 contact LMA2 >>> >>> If an existing SA is the only indicator to set up a PMIPv6 >>> domain, then one solution could be to set up an SA dynamically >>> between MAG1 and LMA2, which needs to be re-done every time >>> MN1 performs a handover to a different MAG, say MAG1*. This >>> may be a disadvantage and will blow up PMIPv6 domains, which >>> are rather administratively configured, in my opinion. >>> >> >> [Qin]: It seems to me SA setup each time MN handover to the new MAG is one generic issue we should face for all the Multi-LMA cases. >> In other words,When using LMA1 to signal with LMA2 for states synchroizing, it has the same problem. Suppose MN connect to the LMA1, >> each time the MN handover from previous MAG to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again. >> > there is a big difference between localized routing associations between > MAGs > and handover between MAGs. [Qin]: No doubt to this. > Handover is between globally adjacent ARs/MAGs, hence, I think an LMA > maintains an SA with an MN's MAG and potential handover targets. [Qin]: How? You can not predict the direction of MN's movement, i.e., to which MAG the MN will move. Therefore you can not expect there is an SA between LMA and handover targets beforehand. > If you > would establish them each time a handover occurs, this would have impact > to the handover latency. Don't think this is how PMIP is deployed. [Qin] As I said in the previous mail, the possible way to fix this issue is SA or tunnel setup for the first MN between MAG and LMA can be shared by the other MNs who are attaching to the same MAG and register to the same LMA as the first MN. that is to say, the SA or tunnel between MAG and LMA is not per-MN or per-CN and can be reused by all the MNs and CNs upon it is setup at the first time. In this sense, it avoid establishing SA each time a handover occurs. If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is not neccessary to be established again if SA between MAG1 and LMA2 has already been setup. >Now, > localized routing between MN and CN could mean that MN's MAG and CN's > MAG are pretty far apart. [Qin] As described in PS draft, We should limit MN's MAG and CN's MAG within the same domain, am I right? >Different LMAs could serve different PMIPv6 > domains. I don't think it's reasonable to merge these PMIP domains > dynamically by means of establishing an SA between MN's MAG and > CN's LMA. [Qin]: Same as above. >Rather LMAs could take care about the setup of the route > between these MAGs. If both LMAs are in different PMIP domains > but in the same provider network, such signaling is simple. > > >> From the other aspect, in the Multi-LMA scenario, when MAG1 talks with LMA2, if there is no SA between MAG1 and LMA2, we can ask >> LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2. >> > Who is "we" ("...we can ask LMA2...")? It's MAG1, right? [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address from LMA2, LMA2 should validate the message from MN's MAG1 using AAA mechanism. >> Also since SA is setup between one MAG and one LMA, upon the first MN who is attaching to the MAG triggers this MAG to setup SA with LMA, >> the SA can also be used by the other MN who attach to the same MAG to protect the data traffic between MAG and LMA Therefore the second MN who >> is attaching to the same MAG may not setup SA again. Because all the existing SA can be reused. >> >> Therefore SA setup is not a big issue, the biggest issue is: >> 1) who discover CN's LMA address? >> 2) how does he discover CN's LMA address? >> > "Who?" should be the LMA, as you need to discovery only once, whereas > if it's the MAG, each handover MAG needs to discover again, unless you > make the localized routing protocol dependent on CTX, which is not > a good approach. [Qin]: For the handover case, If CTX is used with localized routing protocol, discovery is done once as well. But CTX is not the only way. Besides CTX, there is another possible way to deal with handover case for multi-LMA. Since it is MN's MAG or CN's MAG who is responsible for setup localized routing path, LMA still needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to MN's MAG. Therefore when MN handover from MN's previous MAG to the MN's new MAG, it is not MN's LMA but MN's new MAG who is first to know that MN's handover happen, then MN's new MAG can trigger LMA to notify CN's MAG to update MN's MAG address at CN's MAG, then CN's MAG updates localized routing path with MN's new MAG. In this way, discovery is done only once as well. > "How?" could be different approaches. Static solutions could be based on > the LMA's knowledge about address/HNP pools for HNP assignment > to attaching MNs. Dynamic solutions could be based on a AAA infrastructure > as you referred to above. I don't think this particular "How?" should be > addressed > by the localized routing solution. [Qin]: I agree. >> One example is , If AAA based CN's LMA discovery can be used, we can ask AAA server push the keying materails which is used to protect the trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's LMA respectively. In this sense, the trust relationship between MN's MAG and CN's LMA can be easily setup. >> >> >>> The other alternative is that PMIPv6 domain stractures are not touched >>> and LMA1 will signal with LMA2 to synchronize states of MN and CN. >>> Advantage would be that LMAs do not change during a handover and >>> will keep states on one place. >>> >> >> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address? >> > Same as MAG1 may discover LMA2, with many advantages if you do this from > LMA1. > > marco > >> >>> Any opinions? >>> >>> marco >>> >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> > From sunseawq@huawei.com Tue Nov 24 00:33:16 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4BC3A67EC for ; Tue, 24 Nov 2009 00:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=1.441, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJyEfSINZt+Y for ; Tue, 24 Nov 2009 00:33:15 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 48EFD3A62C1 for ; Tue, 24 Nov 2009 00:33:15 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTL00C53UF99I@szxga01-in.huawei.com> for netext@ietf.org; Tue, 24 Nov 2009 16:33:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTL00DFDUF93W@szxga01-in.huawei.com> for netext@ietf.org; Tue, 24 Nov 2009 16:33:09 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTL00DGFUF82J@szxml04-in.huawei.com> for netext@ietf.org; Tue, 24 Nov 2009 16:33:09 +0800 (CST) Date: Tue, 24 Nov 2009 16:33:08 +0800 From: Qin Wu To: "Koodli, Rajeev" , netext@ietf.org Message-id: <032d01ca6ce0$c06b92f0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B0664E5.6060901@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:33:16 -0000 Hi, Rajeev and all: No doubt that A11,A12 and A21 should be addressed in the solution draft. But for A22, One use case in my mind is: Suppose MN's MAG and CN's MAG are in Japan operator network, and MN and CN share the same LMA in USA operator's network, I am wondering whether Localized routing protocol can be used to optimize the path between MN and CN to save the traffic from making the unnecessary USA trip? Regards! -Qin ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Tuesday, November 24, 2009 11:00 AM Subject: Re: [netext] multi-LMA : how to handle > > > Hi Marco, All, > > Why do we need to solve this case? (I know we have documented in the PS > ID). > > From what I can tell, there are two nodes in two different PMIPv6 > domains attached to two different MAGs and two different LMAs. > What use case will require us to address this scenario? > > We can still address roaming by considering scenarios A11, A12, A21 in > the PS document. > What we need is an indication in the LMA that the visiting node(s) are > allowed to be offered with LR. > We should include that. > > Thanks, > > -Rajeev > > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch >> Sent: Friday, November 20, 2009 1:44 AM >> To: netext@ietf.org >> Subject: [netext] multi-LMA : how to handle >> >> Folks, >> >> as a follow up of our discussion about localized routing in a >> multi-LMA setup, I'd like to initiate a general and >> clarifying discussion about signaling paths to set up and >> maintain a localized routing path, as current solution >> proposals cover different approaches. >> >> We had the discussion about PMIPv6 domains vs provider >> domains and came to the conclusion that it's not mandatory >> for MN and CN to share the same PMIPv6 domain. >> >> Assume MN connects to MAG1 and LMA1, whereas CN connects to >> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 >> shares a PMIP domain with LMA2. We cannot assume that MAG1 >> shares a PMIP domain with LMA2. >> >> Now, there are two questions to solve: >> (1) Who detects and initiates localized routing, MAG or LMA >> (2) How to synchronize distributed states? Will LMA1 contact >> LMA2 or will MAG1 contact LMA2 >> >> If an existing SA is the only indicator to set up a PMIPv6 >> domain, then one solution could be to set up an SA >> dynamically between MAG1 and LMA2, which needs to be re-done >> every time >> MN1 performs a handover to a different MAG, say MAG1*. This >> may be a disadvantage and will blow up PMIPv6 domains, which >> are rather administratively configured, in my opinion. >> >> The other alternative is that PMIPv6 domain stractures are >> not touched and LMA1 will signal with LMA2 to synchronize >> states of MN and CN. >> Advantage would be that LMAs do not change during a handover >> and will keep states on one place. >> >> Any opinions? >> >> marco >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Tue Nov 24 02:47:59 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5023A68AA for ; Tue, 24 Nov 2009 02:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkOLwG+CtTBI for ; Tue, 24 Nov 2009 02:47:58 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 832A33A68A5 for ; Tue, 24 Nov 2009 02:47:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E41DB2C00C525; Tue, 24 Nov 2009 11:47:53 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a-jk6Jr60ys; Tue, 24 Nov 2009 11:47:53 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id B87192C0002FE; Tue, 24 Nov 2009 11:47:43 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 11:47:43 +0100 Message-ID: <4B0BB9CE.6010402@nw.neclab.eu> Date: Tue, 24 Nov 2009 11:47:42 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4B0664E5.6060901@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2009 10:47:43.0851 (UTC) FILETIME=[8D648BB0:01CA6CF3] Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 10:47:59 -0000 Hi Rajeev, This is not about the PS or about the use case itself, but about the protocol solution to support the use case. If you have MN connected to MAG1/LMA1 and CN connected to MAG2/LMA2, the PMIP components of MN and CN somehow need to communicate with each other to set up localized routes. If the NetExt protocol solution for localized routing is supposed to support such use case, we need to find answers to the questions about detection (look at data packet and initiate localized routing if appropriate) and the signaling path (who's talking to whom to set up localized routing states). marco Koodli, Rajeev wrote: > > > Hi Marco, All, > > Why do we need to solve this case? (I know we have documented in the PS > ID). > > From what I can tell, there are two nodes in two different PMIPv6 > domains attached to two different MAGs and two different LMAs. > What use case will require us to address this scenario? > > We can still address roaming by considering scenarios A11, A12, A21 in > the PS document. > What we need is an indication in the LMA that the visiting node(s) are > allowed to be offered with LR. > We should include that. > > Thanks, > > -Rajeev > > > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch >> Sent: Friday, November 20, 2009 1:44 AM >> To: netext@ietf.org >> Subject: [netext] multi-LMA : how to handle >> >> Folks, >> >> as a follow up of our discussion about localized routing in a >> multi-LMA setup, I'd like to initiate a general and >> clarifying discussion about signaling paths to set up and >> maintain a localized routing path, as current solution >> proposals cover different approaches. >> >> We had the discussion about PMIPv6 domains vs provider >> domains and came to the conclusion that it's not mandatory >> for MN and CN to share the same PMIPv6 domain. >> >> Assume MN connects to MAG1 and LMA1, whereas CN connects to >> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 >> shares a PMIP domain with LMA2. We cannot assume that MAG1 >> shares a PMIP domain with LMA2. >> >> Now, there are two questions to solve: >> (1) Who detects and initiates localized routing, MAG or LMA >> (2) How to synchronize distributed states? Will LMA1 contact >> LMA2 or will MAG1 contact LMA2 >> >> If an existing SA is the only indicator to set up a PMIPv6 >> domain, then one solution could be to set up an SA >> dynamically between MAG1 and LMA2, which needs to be re-done >> every time >> MN1 performs a handover to a different MAG, say MAG1*. This >> may be a disadvantage and will blow up PMIPv6 domains, which >> are rather administratively configured, in my opinion. >> >> The other alternative is that PMIPv6 domain stractures are >> not touched and LMA1 will signal with LMA2 to synchronize >> states of MN and CN. >> Advantage would be that LMAs do not change during a handover >> and will keep states on one place. >> >> Any opinions? >> >> marco >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Marco.Liebsch@nw.neclab.eu Tue Nov 24 03:22:10 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B5A3A6A0F for ; Tue, 24 Nov 2009 03:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+FAezzm87ie for ; Tue, 24 Nov 2009 03:22:09 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id AB7BB28C107 for ; Tue, 24 Nov 2009 03:22:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1810E2C00C525; Tue, 24 Nov 2009 12:21:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVGLnlUOlUVW; Tue, 24 Nov 2009 12:21:58 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id E05762C0002FE; Tue, 24 Nov 2009 12:21:48 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 12:21:49 +0100 Message-ID: <4B0BC1CF.1050101@nw.neclab.eu> Date: Tue, 24 Nov 2009 12:21:51 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Qin Wu References: <4B0664E5.6060901@nw.neclab.eu> <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> <4B0A5A0D.9030401@nw.neclab.eu> <02fb01ca6cde$70cccd10$420ca40a@china.huawei.com> In-Reply-To: <02fb01ca6cde$70cccd10$420ca40a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2009 11:21:49.0028 (UTC) FILETIME=[5069CA40:01CA6CF8] Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:22:10 -0000 Hi Qin, please see inline for brief comments. Qin Wu wrote: > Hi, Marco: > Thank for your reply, please see my comments inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "Qin Wu" > Cc: > Sent: Monday, November 23, 2009 5:46 PM > Subject: Re: [netext] multi-LMA : how to handle > > > >> Hi Qin, >> >> please find my comments inline. >> >> Qin Wu wrote: >> >>> Hi, Marco: >>> Thank for your raising discussion on Multi-LMA issue. >>> Please see my comments inline! >>> >>> Regards! >>> -Qin >>> ----- Original Message ----- >>> From: "Marco Liebsch" >>> To: >>> Sent: Friday, November 20, 2009 5:44 PM >>> Subject: [netext] multi-LMA : how to handle >>> >>> >>> >>> >>>> Folks, >>>> >>>> as a follow up of our discussion about localized routing in a >>>> multi-LMA setup, I'd like to initiate a general and clarifying >>>> discussion about signaling paths to set up and maintain a >>>> localized routing path, as current solution proposals cover >>>> different approaches. >>>> >>>> We had the discussion about PMIPv6 domains vs provider domains >>>> and came to the conclusion that it's not mandatory for MN and CN >>>> to share the same PMIPv6 domain. >>>> >>>> Assume MN connects to MAG1 and LMA1, whereas CN connects >>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 >>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume >>>> that MAG1 shares a PMIP domain with LMA2. >>>> >>>> Now, there are two questions to solve: >>>> (1) Who detects and initiates localized routing, MAG or LMA >>>> > > >>> [Qin]: I think Both have its value and are applicable to different scenarios. Whether using MAG initiated or using LMA initiated depends on >>> who detects localized routing, in other words, if MAG detects local routing is possible, then MAG initiated is more appropriate. >>> e.g., As described in RFC5213, in the scenario where MN and CN attach to the same MAG, MAG initiated local routing can >>> be used to negotiate with LMA and enfoce local routing on the MAG. >>> > > >> Only in single MAG case it may make sense that the MAG detects and >> establishes >> a localized route. However, even in such case, the LMA must control/enforce >> the setup of the localized route as per RFC5213. So, the LMA >> is the point of control and my personal opinion is that this is >> reasonable, as the >> LMA maintains states beyond a single MAG. And, dependent on the mechanism >> behind HNP assignment (address pools, delegation, ...), the LMA may know if >> the setup of a localized route is useful (in case CN is local) or not. >> > > [Qin]: Right, single MAG case is more appropirate to apply MAG initiated local routing. Also single MAG case can be divided into two sub cases: i.e.,A11 and A12 described in the PS draft. These two sub cases should be taken care in the solution draft. > > On the other hand, I agree LMA control the setup of localized routing, but it seems to me who initiate localized routing does not depend on who control the setup of the localized route. In the MAG initiate localized routing, MAG can initiate local routing with LMA to see whether localized routing is available. > yes, we can have 3 different ways to do this: (1) MAG1 detects and requests LMA1 to set up localized routes (2) MAG1 detects and requests LMA2 to set up localized routes (3) LMA1 detects and sets up localized routes > > >>> If LMA is responsible for local routing, then LMA inititated and MAG initiate both can be used. >>> e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA. >>> >>> >> Since the LMA needs to enforce localized routing in all cases, I >> personally see the >> LMA as detector. >> > > [Qin]: Okay. > > >> If for some reason the MAG may be able to detect, it should >> inform the LMA of the attached MN to enforce localized routing. >> > > [Qin]: I agee. > > >>>> (2) How to synchronize distributed states? Will LMA1 contact >>>> LMA2 or will MAG1 contact LMA2 >>>> >>>> If an existing SA is the only indicator to set up a PMIPv6 >>>> domain, then one solution could be to set up an SA dynamically >>>> between MAG1 and LMA2, which needs to be re-done every time >>>> MN1 performs a handover to a different MAG, say MAG1*. This >>>> may be a disadvantage and will blow up PMIPv6 domains, which >>>> are rather administratively configured, in my opinion. >>>> >>>> >>> [Qin]: It seems to me SA setup each time MN handover to the new MAG is one generic issue we should face for all the Multi-LMA cases. >>> In other words,When using LMA1 to signal with LMA2 for states synchroizing, it has the same problem. Suppose MN connect to the LMA1, >>> each time the MN handover from previous MAG to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again. >>> >>> >> there is a big difference between localized routing associations between >> MAGs >> and handover between MAGs. >> > > [Qin]: No doubt to this. > > >> Handover is between globally adjacent ARs/MAGs, hence, I think an LMA >> maintains an SA with an MN's MAG and potential handover targets. >> > > [Qin]: How? You can not predict the direction of MN's movement, i.e., to which MAG the MN will move. Therefore > you can not expect there is an SA between LMA and handover targets beforehand. > well, don't confuse SA with forwarding tunnel. The SAs between MAG and a particular LMA should be pre-established when the MN arrives, whereas the forwarding tunnel may exist or may be set up dynamically when the MN arrives. > >> If you >> would establish them each time a handover occurs, this would have impact >> to the handover latency. Don't think this is how PMIP is deployed. >> > > [Qin] As I said in the previous mail, the possible way to fix this issue is > SA or tunnel setup for the first MN between MAG and LMA can be shared > by the other MNs who are attaching to the same MAG and register to the same LMA as the first MN. > I understood your point, but I do not agree :-) I do not think that a MAG should establish an SA with any LMA dynamically when the MN arrives, in particular not with an LMA which does not serve the MN but the CN. > that is to say, the SA or tunnel between MAG and LMA is not per-MN or per-CN and can be reused > by all the MNs and CNs upon it is setup at the first time. > In this sense, it avoid establishing SA each time a handover occurs. > If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is not neccessary to be established > again if SA between MAG1 and LMA2 has already been setup. > > >> Now, >> localized routing between MN and CN could mean that MN's MAG and CN's >> MAG are pretty far apart. >> > > [Qin] As described in PS draft, We should limit MN's MAG and CN's MAG within the same domain, am I right? > Even if they are in one provider domain, distance between MAGs can be huge. Multiple LMAs may be used by the provider to distribute load and to be responsible for a smaller region (subset of MAGs). > >> Different LMAs could serve different PMIPv6 >> domains. I don't think it's reasonable to merge these PMIP domains >> dynamically by means of establishing an SA between MN's MAG and >> CN's LMA. >> > > [Qin]: Same as above. > > >> Rather LMAs could take care about the setup of the route >> between these MAGs. If both LMAs are in different PMIP domains >> but in the same provider network, such signaling is simple. >> >> >> >>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks with LMA2, if there is no SA between MAG1 and LMA2, we can ask >>> LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2. >>> >>> >> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? >> > > [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address from LMA2, LMA2 should validate the message from MN's MAG1 using AAA mechanism. > > >>> Also since SA is setup between one MAG and one LMA, upon the first MN who is attaching to the MAG triggers this MAG to setup SA with LMA, >>> the SA can also be used by the other MN who attach to the same MAG to protect the data traffic between MAG and LMA Therefore the second MN who >>> is attaching to the same MAG may not setup SA again. Because all the existing SA can be reused. >>> >>> Therefore SA setup is not a big issue, the biggest issue is: >>> 1) who discover CN's LMA address? >>> 2) how does he discover CN's LMA address? >>> >>> >> "Who?" should be the LMA, as you need to discovery only once, whereas >> if it's the MAG, each handover MAG needs to discover again, unless you >> make the localized routing protocol dependent on CTX, which is not >> a good approach. >> > > [Qin]: For the handover case, If CTX is used with localized routing protocol, discovery is done once as well. > But CTX is not the only way. > Besides CTX, there is another possible way to deal with handover case for multi-LMA. > > Since it is MN's MAG or CN's MAG who is responsible for setup localized routing path, LMA still > needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to MN's MAG. > Therefore when MN handover from MN's previous MAG to the MN's new MAG, it is not MN's LMA but MN's new MAG who is first to know that MN's handover happen, then MN's new MAG can trigger LMA to notify CN's MAG to update MN's MAG address at CN's MAG, > then CN's MAG updates localized routing path with MN's new MAG. > I think the basic assumption for the solutions should be that the MN's handover target MAG does not know more than what PMIPv6 as per RFC5213 requires, which is the LMA where to send the PBU to and does not cover any localized routing information. The information and states about localized routing could be re-established (instead of transferred) by a common anchor, which does not change: The LMA. draft-oulai even sets up localized routing states on both MAGs without any signaling between MAGs at all. We proposed something similar in draft-abeille, which was named 'proxy mode'. Such approach has some advantages if there is no SA between MAGs. marco > In this way, discovery is done only once as well. > > >> "How?" could be different approaches. Static solutions could be based on >> the LMA's knowledge about address/HNP pools for HNP assignment >> to attaching MNs. Dynamic solutions could be based on a AAA infrastructure >> as you referred to above. I don't think this particular "How?" should be >> addressed >> by the localized routing solution. >> > > [Qin]: I agree. > > >>> One example is , If AAA based CN's LMA discovery can be used, we can ask AAA server push the keying materails which is used to protect the trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's LMA respectively. In this sense, the trust relationship between MN's MAG and CN's LMA can be easily setup. >>> >>> >>> >>>> The other alternative is that PMIPv6 domain stractures are not touched >>>> and LMA1 will signal with LMA2 to synchronize states of MN and CN. >>>> Advantage would be that LMAs do not change during a handover and >>>> will keep states on one place. >>>> >>>> >>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address? >>> >>> >> Same as MAG1 may discover LMA2, with many advantages if you do this from >> LMA1. >> >> marco >> >> >>> >>> >>>> Any opinions? >>>> >>>> marco >>>> >>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From rkoodli@starentnetworks.com Tue Nov 24 11:18:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34FC3A6818 for ; Tue, 24 Nov 2009 11:18:03 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Bnic2m93222 for ; Tue, 24 Nov 2009 11:18:02 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 8D5963A67F7 for ; Tue, 24 Nov 2009 11:18:02 -0800 (PST) X-ASG-Debug-ID: 1259090277-5c3903cd0001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id 6YI0IOOvNqx9luzy for ; Tue, 24 Nov 2009 14:17:57 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Nov 2009 14:16:59 -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 X-ASG-Orig-Subj: RE: [netext] multi-LMA : how to handle Date: Tue, 24 Nov 2009 14:13:27 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382B7E@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] multi-LMA : how to handle Thread-Index: Acps83IeMSRDtl0wTtWHFsG2EDE1HwARsFt2 References: <4B0664E5.6060901@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> <4B0BB9CE.6010402@nw.neclab.eu> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 24 Nov 2009 19:16:59.0285 (UTC) FILETIME=[B1D9C450:01CA6D3A] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1259090277 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:18:03 -0000 =20 Hi Marco, =20 I understand it is not about the PS itself. =20 However, we discussed the case involving multiple LMAs, and ruled it = out.=20 I don't think we need to address this issue (multiple MAGs, multiple = LMAs, multiple PMIP6 domains) for protocol solutions. Unless there is a = clear need for this. =20 Thanks, =20 -Rajeev =20 ________________________________ From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] Sent: Tue 11/24/2009 2:47 AM To: Koodli, Rajeev Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle Hi Rajeev, This is not about the PS or about the use case itself, but about the protocol solution to support the use case. If you have MN connected to MAG1/LMA1 and CN connected to MAG2/LMA2, the PMIP components of MN and CN somehow need to communicate with each other to set up localized routes. If the NetExt protocol solution for localized routing is supposed to support such use case, we need to find answers to the questions about detection (look at data packet and initiate localized routing if appropriate) and the signaling path (who's talking to whom to set up localized routing states). marco Koodli, Rajeev wrote: >=20 > > Hi Marco, All, > > Why do we need to solve this case? (I know we have documented in the = PS > ID). > > From what I can tell, there are two nodes in two different PMIPv6 > domains attached to two different MAGs and two different LMAs. > What use case will require us to address this scenario? > > We can still address roaming by considering scenarios A11, A12, A21 in > the PS document. > What we need is an indication in the LMA that the visiting node(s) are > allowed to be offered with LR. > We should include that. > > Thanks, > > -Rajeev > > > > =20 >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch >> Sent: Friday, November 20, 2009 1:44 AM >> To: netext@ietf.org >> Subject: [netext] multi-LMA : how to handle >> >> Folks, >> >> as a follow up of our discussion about localized routing in a >> multi-LMA setup, I'd like to initiate a general and >> clarifying discussion about signaling paths to set up and >> maintain a localized routing path, as current solution >> proposals cover different approaches. >> >> We had the discussion about PMIPv6 domains vs provider >> domains and came to the conclusion that it's not mandatory >> for MN and CN to share the same PMIPv6 domain. >> >> Assume MN connects to MAG1 and LMA1, whereas CN connects to >> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 >> shares a PMIP domain with LMA2. We cannot assume that MAG1 >> shares a PMIP domain with LMA2. >> >> Now, there are two questions to solve: >> (1) Who detects and initiates localized routing, MAG or LMA >> (2) How to synchronize distributed states? Will LMA1 contact >> LMA2 or will MAG1 contact LMA2 >> >> If an existing SA is the only indicator to set up a PMIPv6 >> domain, then one solution could be to set up an SA >> dynamically between MAG1 and LMA2, which needs to be re-done >> every time >> MN1 performs a handover to a different MAG, say MAG1*. This >> may be a disadvantage and will blow up PMIPv6 domains, which >> are rather administratively configured, in my opinion. >> >> The other alternative is that PMIPv6 domain stractures are >> not touched and LMA1 will signal with LMA2 to synchronize >> states of MN and CN. >> Advantage would be that LMAs do not change during a handover >> and will keep states on one place. >> >> Any opinions? >> >> marco >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 From rkoodli@starentnetworks.com Tue Nov 24 11:21:31 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE76F3A690D for ; Tue, 24 Nov 2009 11:21:31 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl0B-iarANJI for ; Tue, 24 Nov 2009 11:21:31 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id C8E5C3A6818 for ; Tue, 24 Nov 2009 11:21:30 -0800 (PST) X-ASG-Debug-ID: 1259090486-5c3804840001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id ws20pGuWKyBPB8H8 for ; Tue, 24 Nov 2009 14:21:26 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Nov 2009 14:20:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] multi-LMA : how to handle Date: Tue, 24 Nov 2009 14:17:47 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382B7F@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] multi-LMA : how to handle Thread-Index: Acps4KDkWz9H5PzvRtKk7XJcfM511gAWi2J6 References: <4B0664E5.6060901@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> <032d01ca6ce0$c06b92f0$420ca40a@china.huawei.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 24 Nov 2009 19:20:27.0639 (UTC) FILETIME=[2E0A1070:01CA6D3B] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1259090486 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:21:32 -0000 =20 Hi Qin, =20 the example you quote below has MN and CN belonging to the same PMIP6 = domain (and sharing the same LMA). As I mentioned below, if the visited = MAG has indication that the roaming user is allowed for LR, the protocol = solution applies.=20 =20 I am saying that multi-LMA, multi-MAG, multi-PMIP6 domain scenario = should be out of scope. =20 Regards, =20 -Rajeev =20 ________________________________ From: Qin Wu [mailto:sunseawq@huawei.com] Sent: Tue 11/24/2009 12:33 AM To: Koodli, Rajeev; netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle Hi, Rajeev and all: No doubt that A11,A12 and A21 should be addressed in the solution draft. But for A22, One use case in my mind is: Suppose MN's MAG and CN's MAG are in Japan operator network, and MN and = CN share the same LMA in USA operator's network, I am wondering whether Localized routing protocol can be used to = optimize the path between MN and CN to save the traffic from making the = unnecessary USA trip? Regards! -Qin ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Tuesday, November 24, 2009 11:00 AM Subject: Re: [netext] multi-LMA : how to handle > > > Hi Marco, All, > > Why do we need to solve this case? (I know we have documented in the = PS > ID). > > From what I can tell, there are two nodes in two different PMIPv6 > domains attached to two different MAGs and two different LMAs. > What use case will require us to address this scenario? > > We can still address roaming by considering scenarios A11, A12, A21 in > the PS document. > What we need is an indication in the LMA that the visiting node(s) are > allowed to be offered with LR. > We should include that. > > Thanks, > > -Rajeev > > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch >> Sent: Friday, November 20, 2009 1:44 AM >> To: netext@ietf.org >> Subject: [netext] multi-LMA : how to handle >> >> Folks, >> >> as a follow up of our discussion about localized routing in a >> multi-LMA setup, I'd like to initiate a general and >> clarifying discussion about signaling paths to set up and >> maintain a localized routing path, as current solution >> proposals cover different approaches. >> >> We had the discussion about PMIPv6 domains vs provider >> domains and came to the conclusion that it's not mandatory >> for MN and CN to share the same PMIPv6 domain. >> >> Assume MN connects to MAG1 and LMA1, whereas CN connects to >> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 >> shares a PMIP domain with LMA2. We cannot assume that MAG1 >> shares a PMIP domain with LMA2. >> >> Now, there are two questions to solve: >> (1) Who detects and initiates localized routing, MAG or LMA >> (2) How to synchronize distributed states? Will LMA1 contact >> LMA2 or will MAG1 contact LMA2 >> >> If an existing SA is the only indicator to set up a PMIPv6 >> domain, then one solution could be to set up an SA >> dynamically between MAG1 and LMA2, which needs to be re-done >> every time >> MN1 performs a handover to a different MAG, say MAG1*. This >> may be a disadvantage and will blow up PMIPv6 domains, which >> are rather administratively configured, in my opinion. >> >> The other alternative is that PMIPv6 domain stractures are >> not touched and LMA1 will signal with LMA2 to synchronize >> states of MN and CN. >> Advantage would be that LMAs do not change during a handover >> and will keep states on one place. >> >> Any opinions? >> >> marco >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Tue Nov 24 18:03:29 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E98728C157 for ; Tue, 24 Nov 2009 18:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEBYZ9DDqblV for ; Tue, 24 Nov 2009 18:03:28 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1630028C155 for ; Tue, 24 Nov 2009 18:03:28 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTN001RO71DZI@szxga02-in.huawei.com> for netext@ietf.org; Wed, 25 Nov 2009 10:03:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTN00KZF71DJE@szxga02-in.huawei.com> for netext@ietf.org; Wed, 25 Nov 2009 10:03:13 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTN000SE71CJB@szxml04-in.huawei.com> for netext@ietf.org; Wed, 25 Nov 2009 10:03:12 +0800 (CST) Date: Wed, 25 Nov 2009 10:03:12 +0800 From: Qin Wu To: "Koodli, Rajeev" , netext@ietf.org Message-id: <008e01ca6d73$71a4e8e0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B0664E5.6060901@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> <032d01ca6ce0$c06b92f0$420ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A266609382B7F@exchtewks3.starentnetworks.com> Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 02:03:29 -0000 Hi, Rajeev: Sorry for my mistake, the example I quote is the case which include single LMA, multi-MAG. Let me give you another example as follows: MN belong to LMA1 in the USA operator A network, CN belong to LMA2 in the USA operator B network, when MN and CN roam to the same Japan NTT network, MN and CN attach to the different MAGs in the Japan NTT network. In this case, MN's MAG and CN's MAG belong to the same operator network and are very close to each other, I am wondering whether Localized routing protocol can be used to optimize the path between MN and CN to save the traffic from making the unnecessary USA trip? Regards! -Qin ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Wednesday, November 25, 2009 3:17 AM Subject: Re: [netext] multi-LMA : how to handle > > Hi Qin, > > the example you quote below has MN and CN belonging to the same PMIP6 domain (and sharing the same LMA). As I mentioned below, if the visited MAG has indication that the roaming user is allowed for LR, the protocol solution applies. > > I am saying that multi-LMA, multi-MAG, multi-PMIP6 domain scenario should be out of scope. > > Regards, > > -Rajeev > > > ________________________________ > > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Tue 11/24/2009 12:33 AM > To: Koodli, Rajeev; netext@ietf.org > Subject: Re: [netext] multi-LMA : how to handle > > > > Hi, Rajeev and all: > No doubt that A11,A12 and A21 should be addressed in the solution draft. > But for A22, One use case in my mind is: > Suppose MN's MAG and CN's MAG are in Japan operator network, and MN and CN share the same LMA in USA operator's network, > I am wondering whether Localized routing protocol can be used to optimize the path between MN and CN to save the traffic from making the unnecessary USA trip? > > Regards! > -Qin > ----- Original Message ----- > From: "Koodli, Rajeev" > To: > Sent: Tuesday, November 24, 2009 11:00 AM > Subject: Re: [netext] multi-LMA : how to handle > > >> >> >> Hi Marco, All, >> >> Why do we need to solve this case? (I know we have documented in the PS >> ID). >> >> From what I can tell, there are two nodes in two different PMIPv6 >> domains attached to two different MAGs and two different LMAs. >> What use case will require us to address this scenario? >> >> We can still address roaming by considering scenarios A11, A12, A21 in >> the PS document. >> What we need is an indication in the LMA that the visiting node(s) are >> allowed to be offered with LR. >> We should include that. >> >> Thanks, >> >> -Rajeev >> >> >> >>> -----Original Message----- >>> From: netext-bounces@ietf.org >>> [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch >>> Sent: Friday, November 20, 2009 1:44 AM >>> To: netext@ietf.org >>> Subject: [netext] multi-LMA : how to handle >>> >>> Folks, >>> >>> as a follow up of our discussion about localized routing in a >>> multi-LMA setup, I'd like to initiate a general and >>> clarifying discussion about signaling paths to set up and >>> maintain a localized routing path, as current solution >>> proposals cover different approaches. >>> >>> We had the discussion about PMIPv6 domains vs provider >>> domains and came to the conclusion that it's not mandatory >>> for MN and CN to share the same PMIPv6 domain. >>> >>> Assume MN connects to MAG1 and LMA1, whereas CN connects to >>> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 >>> shares a PMIP domain with LMA2. We cannot assume that MAG1 >>> shares a PMIP domain with LMA2. >>> >>> Now, there are two questions to solve: >>> (1) Who detects and initiates localized routing, MAG or LMA >>> (2) How to synchronize distributed states? Will LMA1 contact >>> LMA2 or will MAG1 contact LMA2 >>> >>> If an existing SA is the only indicator to set up a PMIPv6 >>> domain, then one solution could be to set up an SA >>> dynamically between MAG1 and LMA2, which needs to be re-done >>> every time >>> MN1 performs a handover to a different MAG, say MAG1*. This >>> may be a disadvantage and will blow up PMIPv6 domains, which >>> are rather administratively configured, in my opinion. >>> >>> The other alternative is that PMIPv6 domain stractures are >>> not touched and LMA1 will signal with LMA2 to synchronize >>> states of MN and CN. >>> Advantage would be that LMAs do not change during a handover >>> and will keep states on one place. >>> >>> Any opinions? >>> >>> marco >>> >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Wed Nov 25 00:46:39 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616553A6895 for ; Wed, 25 Nov 2009 00:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTUu2EOZOad1 for ; Wed, 25 Nov 2009 00:46:38 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 93ED03A686B for ; Wed, 25 Nov 2009 00:46:37 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTN00EENPKSAF@szxga02-in.huawei.com> for netext@ietf.org; Wed, 25 Nov 2009 16:43:40 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTN00GO8PKSKI@szxga02-in.huawei.com> for netext@ietf.org; Wed, 25 Nov 2009 16:43:40 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTN00K49PKQGX@szxml04-in.huawei.com> for netext@ietf.org; Wed, 25 Nov 2009 16:43:39 +0800 (CST) Date: Wed, 25 Nov 2009 16:43:39 +0800 From: Qin Wu To: Marco Liebsch Message-id: <005401ca6dab$629e09c0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B0664E5.6060901@nw.neclab.eu> <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> <4B0A5A0D.9030401@nw.neclab.eu> <02fb01ca6cde$70cccd10$420ca40a@china.huawei.com> <4B0BC1CF.1050101@nw.neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:46:39 -0000 Hi, Marco: please see my comments inline. Regards! -Qin ----- Original Message ----- From: "Marco Liebsch" To: "Qin Wu" Cc: Sent: Tuesday, November 24, 2009 7:21 PM Subject: Re: [netext] multi-LMA : how to handle > Hi Qin, > > please see inline for brief comments. > > Qin Wu wrote: >> Hi, Marco: >> Thank for your reply, please see my comments inline. >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Marco Liebsch" >> To: "Qin Wu" >> Cc: >> Sent: Monday, November 23, 2009 5:46 PM >> Subject: Re: [netext] multi-LMA : how to handle >> >> >> >>> Hi Qin, >>> >>> please find my comments inline. >>> >>> Qin Wu wrote: >>> >>>> Hi, Marco: >>>> Thank for your raising discussion on Multi-LMA issue. >>>> Please see my comments inline! >>>> >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Marco Liebsch" >>>> To: >>>> Sent: Friday, November 20, 2009 5:44 PM >>>> Subject: [netext] multi-LMA : how to handle >>>> >>>> >>>> >>>> >>>>> Folks, >>>>> >>>>> as a follow up of our discussion about localized routing in a >>>>> multi-LMA setup, I'd like to initiate a general and clarifying >>>>> discussion about signaling paths to set up and maintain a >>>>> localized routing path, as current solution proposals cover >>>>> different approaches. >>>>> >>>>> We had the discussion about PMIPv6 domains vs provider domains >>>>> and came to the conclusion that it's not mandatory for MN and CN >>>>> to share the same PMIPv6 domain. >>>>> >>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects >>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 >>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume >>>>> that MAG1 shares a PMIP domain with LMA2. >>>>> >>>>> Now, there are two questions to solve: >>>>> (1) Who detects and initiates localized routing, MAG or LMA >>>>> >> >> >>>> [Qin]: I think Both have its value and are applicable to different scenarios. Whether using MAG initiated or using LMA initiated depends on >>>> who detects localized routing, in other words, if MAG detects local routing is possible, then MAG initiated is more appropriate. >>>> e.g., As described in RFC5213, in the scenario where MN and CN attach to the same MAG, MAG initiated local routing can >>>> be used to negotiate with LMA and enfoce local routing on the MAG. >>>> >> >> >>> Only in single MAG case it may make sense that the MAG detects and >>> establishes >>> a localized route. However, even in such case, the LMA must control/enforce >>> the setup of the localized route as per RFC5213. So, the LMA >>> is the point of control and my personal opinion is that this is >>> reasonable, as the >>> LMA maintains states beyond a single MAG. And, dependent on the mechanism >>> behind HNP assignment (address pools, delegation, ...), the LMA may know if >>> the setup of a localized route is useful (in case CN is local) or not. >>> >> >> [Qin]: Right, single MAG case is more appropirate to apply MAG initiated local routing. Also single MAG case can be divided into two sub cases: i.e.,A11 and A12 described in the PS draft. These two sub cases should be taken care in the solution draft. >> >> On the other hand, I agree LMA control the setup of localized routing, but it seems to me who initiate localized routing does not depend on who control the setup of the localized route. In the MAG initiate localized routing, MAG can initiate local routing with LMA to see whether localized routing is available. >> > yes, we can have 3 different ways to do this: > (1) MAG1 detects and requests LMA1 to set up localized routes > (2) MAG1 detects and requests LMA2 to set up localized routes > (3) LMA1 detects and sets up localized routes [Qin]: Okay. >> >> >>>> If LMA is responsible for local routing, then LMA inititated and MAG initiate both can be used. >>>> e.g., in the scenario where MN and CN attach to the different MAGs but connect to the different LMA or the same LMA. >>>> >>>> >>> Since the LMA needs to enforce localized routing in all cases, I >>> personally see the >>> LMA as detector. >>> >> >> [Qin]: Okay. >> >> >>> If for some reason the MAG may be able to detect, it should >>> inform the LMA of the attached MN to enforce localized routing. >>> >> >> [Qin]: I agee. >> >> >>>>> (2) How to synchronize distributed states? Will LMA1 contact >>>>> LMA2 or will MAG1 contact LMA2 >>>>> >>>>> If an existing SA is the only indicator to set up a PMIPv6 >>>>> domain, then one solution could be to set up an SA dynamically >>>>> between MAG1 and LMA2, which needs to be re-done every time >>>>> MN1 performs a handover to a different MAG, say MAG1*. This >>>>> may be a disadvantage and will blow up PMIPv6 domains, which >>>>> are rather administratively configured, in my opinion. >>>>> >>>>> >>>> [Qin]: It seems to me SA setup each time MN handover to the new MAG is one generic issue we should face for all the Multi-LMA cases. >>>> In other words,When using LMA1 to signal with LMA2 for states synchroizing, it has the same problem. Suppose MN connect to the LMA1, >>>> each time the MN handover from previous MAG to the new MAG, the new MAG needs to setup SA with the LMA1 dynamically again. >>>> >>>> >>> there is a big difference between localized routing associations between >>> MAGs >>> and handover between MAGs. >>> >> >> [Qin]: No doubt to this. >> >> >>> Handover is between globally adjacent ARs/MAGs, hence, I think an LMA >>> maintains an SA with an MN's MAG and potential handover targets. >>> >> >> [Qin]: How? You can not predict the direction of MN's movement, i.e., to which MAG the MN will move. Therefore >> you can not expect there is an SA between LMA and handover targets beforehand. >> > well, don't confuse SA with forwarding tunnel. The SAs between MAG and a > particular LMA > should be pre-established when the MN arrives, whereas the forwarding > tunnel may exist > or may be set up dynamically when the MN arrives. [Qin]: I agree SA and forwarding tunnel are two different things. But the common aspect of both is SA and forwarding tunnel for one MN can be reused by the other MN who arrives at the same MAG and routes the packet to the same tunnel end point, i.e., LMA. Right? >> >>> If you >>> would establish them each time a handover occurs, this would have impact >>> to the handover latency. Don't think this is how PMIP is deployed. >>> >> >> [Qin] As I said in the previous mail, the possible way to fix this issue is >> SA or tunnel setup for the first MN between MAG and LMA can be shared >> by the other MNs who are attaching to the same MAG and register to the same LMA as the first MN. >> > I understood your point, but I do not agree :-) I do not think that a > MAG should establish an SA > with any LMA dynamically when the MN arrives, in particular not with an > LMA which does not > serve the MN but the CN. [Qin]: It seem to me it does not matther whether SA is pre-established or dynamically established. The key point is whether SA can be shared by all the MNs who are using the same path between MAG and LMA. >> that is to say, the SA or tunnel between MAG and LMA is not per-MN or per-CN and can be reused >> by all the MNs and CNs upon it is setup at the first time. >> In this sense, it avoid establishing SA each time a handover occurs. >> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is not neccessary to be established >> again if SA between MAG1 and LMA2 has already been setup. >> >> >>> Now, >>> localized routing between MN and CN could mean that MN's MAG and CN's >>> MAG are pretty far apart. >>> >> >> [Qin] As described in PS draft, We should limit MN's MAG and CN's MAG within the same domain, am I right? >> > Even if they are in one provider domain, distance between MAGs can be > huge. Multiple LMAs may > be used by the provider to distribute load and to be responsible for a > smaller region (subset of MAGs). [Qin]: To me, the physical distance is not big issue. The more important thing is whether communication between MAGs is within the same provider domain or acrosss provider domain. >> >>> Different LMAs could serve different PMIPv6 >>> domains. I don't think it's reasonable to merge these PMIP domains >>> dynamically by means of establishing an SA between MN's MAG and >>> CN's LMA. >>> >> >> [Qin]: Same as above. >> >> >>> Rather LMAs could take care about the setup of the route >>> between these MAGs. If both LMAs are in different PMIP domains >>> but in the same provider network, such signaling is simple. >>> >>> >>> >>>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks with LMA2, if there is no SA between MAG1 and LMA2, we can ask >>>> LMA2 exchange with AAA server to do authorization and validate whether MAG1 can fetch CN's MAG address from LMA2. >>>> >>>> >>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? >>> >> >> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address from LMA2, LMA2 should validate the message from MN's MAG1 using AAA mechanism. >> >> >>>> Also since SA is setup between one MAG and one LMA, upon the first MN who is attaching to the MAG triggers this MAG to setup SA with LMA, >>>> the SA can also be used by the other MN who attach to the same MAG to protect the data traffic between MAG and LMA Therefore the second MN who >>>> is attaching to the same MAG may not setup SA again. Because all the existing SA can be reused. >>>> >>>> Therefore SA setup is not a big issue, the biggest issue is: >>>> 1) who discover CN's LMA address? >>>> 2) how does he discover CN's LMA address? >>>> >>>> >>> "Who?" should be the LMA, as you need to discovery only once, whereas >>> if it's the MAG, each handover MAG needs to discover again, unless you >>> make the localized routing protocol dependent on CTX, which is not >>> a good approach. >>> >> >> [Qin]: For the handover case, If CTX is used with localized routing protocol, discovery is done once as well. >> But CTX is not the only way. >> Besides CTX, there is another possible way to deal with handover case for multi-LMA. >> >> Since it is MN's MAG or CN's MAG who is responsible for setup localized routing path, LMA still >> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to MN's MAG. >> Therefore when MN handover from MN's previous MAG to the MN's new MAG, it is not MN's LMA but MN's new MAG who is first to know that MN's handover happen, then MN's new MAG can trigger LMA to notify CN's MAG to update MN's MAG address at CN's MAG, >> then CN's MAG updates localized routing path with MN's new MAG. >> > I think the basic assumption for the solutions should be that the MN's > handover > target MAG does not know more than what PMIPv6 as per RFC5213 requires, > which is the LMA where to send the PBU to and does not cover any localized > routing information. The information and states about localized routing > could be > re-established (instead of transferred) by a common anchor, which does not > change: The LMA. > draft-oulai even sets up localized routing states on both MAGs without > any signaling between MAGs at all. We proposed something similar in > draft-abeille, which was named 'proxy mode'. Such approach has some > advantages if there is no SA between MAGs. [Qin]: Since localized routing protocol can be used between source MAG(i.e., MN's MAG) and LMA, it also can be used between target MAG and LMA. I don't think it is a big issue. Also in some case, MN's prefix and CN's prefix should be validated to create for valid routing between MAGs. therefore LMA can notify both MAG that MN's prefix or CN's prefix is valid each time handover happens.Also LMA can tell target MAG the information about localized routing. On the other hand, when routing path is established, target MAG need to install localized routing states. This mechanism is quite similar to the routing optimization between MN and CN described in RFC3775 and RFC4866. > marco > > >> In this way, discovery is done only once as well. >> >> >>> "How?" could be different approaches. Static solutions could be based on >>> the LMA's knowledge about address/HNP pools for HNP assignment >>> to attaching MNs. Dynamic solutions could be based on a AAA infrastructure >>> as you referred to above. I don't think this particular "How?" should be >>> addressed >>> by the localized routing solution. >>> >> >> [Qin]: I agree. >> >> >>>> One example is , If AAA based CN's LMA discovery can be used, we can ask AAA server push the keying materails which is used to protect the trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's LMA respectively. In this sense, the trust relationship between MN's MAG and CN's LMA can be easily setup. >>>> >>>> >>>> >>>>> The other alternative is that PMIPv6 domain stractures are not touched >>>>> and LMA1 will signal with LMA2 to synchronize states of MN and CN. >>>>> Advantage would be that LMAs do not change during a handover and >>>>> will keep states on one place. >>>>> >>>>> >>>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how does LMA1 know LMA2 address? >>>> >>>> >>> Same as MAG1 may discover LMA2, with many advantages if you do this from >>> LMA1. >>> >>> marco >>> >>> >>>> >>>> >>>>> Any opinions? >>>>> >>>>> marco >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > From Marco.Liebsch@nw.neclab.eu Wed Nov 25 01:42:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E813A6880 for ; Wed, 25 Nov 2009 01:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIukor05MHIq for ; Wed, 25 Nov 2009 01:42:10 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 005E33A684C for ; Wed, 25 Nov 2009 01:42:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D23BD2C019194; Wed, 25 Nov 2009 10:42:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QesNIRwgrgW8; Wed, 25 Nov 2009 10:42:02 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id A78412C0002FE; Wed, 25 Nov 2009 10:41:52 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:41:52 +0100 Message-ID: <4B0CFBDE.9070808@nw.neclab.eu> Date: Wed, 25 Nov 2009 10:41:50 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4B0664E5.6060901@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660DC16408@exchtewks3.starentnetworks.com> <4B0BB9CE.6010402@nw.neclab.eu> <4D35478224365146822AE9E3AD4A266609382B7E@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382B7E@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2009 09:41:52.0960 (UTC) FILETIME=[84E42C00:01CA6DB3] Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 09:42:11 -0000 Hi Rajeev, Koodli, Rajeev wrote: > > Hi Marco, > > I understand it is not about the PS itself. > > However, we discussed the case involving multiple LMAs, and ruled it out. > That's new for me. Who ruled it out? And when? > I don't think we need to address this issue (multiple MAGs, multiple LMAs, multiple PMIP6 domains) for protocol solutions. Unless there is a clear need for this. > To support only single LMA scenarios is a bad limitation. marco > > Thanks, > > -Rajeev > > > ________________________________ > > From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] > Sent: Tue 11/24/2009 2:47 AM > To: Koodli, Rajeev > Cc: netext@ietf.org > Subject: Re: [netext] multi-LMA : how to handle > > > > Hi Rajeev, > > This is not about the PS or about the use case itself, but about the > protocol solution to support the use case. If you have MN connected > to MAG1/LMA1 and CN connected to MAG2/LMA2, the PMIP > components of MN and CN somehow need to communicate with > each other to set up localized routes. If the NetExt protocol solution > for localized routing is supposed to support such use case, we need > to find answers to the questions about detection (look at data packet > and initiate localized routing if appropriate) and the signaling path > (who's talking to whom to set up localized routing states). > > marco > > > Koodli, Rajeev wrote: > >> Hi Marco, All, >> >> Why do we need to solve this case? (I know we have documented in the PS >> ID). >> >> From what I can tell, there are two nodes in two different PMIPv6 >> domains attached to two different MAGs and two different LMAs. >> What use case will require us to address this scenario? >> >> We can still address roaming by considering scenarios A11, A12, A21 in >> the PS document. >> What we need is an indication in the LMA that the visiting node(s) are >> allowed to be offered with LR. >> We should include that. >> >> Thanks, >> >> -Rajeev >> >> >> >> >> >>> -----Original Message----- >>> From: netext-bounces@ietf.org >>> [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch >>> Sent: Friday, November 20, 2009 1:44 AM >>> To: netext@ietf.org >>> Subject: [netext] multi-LMA : how to handle >>> >>> Folks, >>> >>> as a follow up of our discussion about localized routing in a >>> multi-LMA setup, I'd like to initiate a general and >>> clarifying discussion about signaling paths to set up and >>> maintain a localized routing path, as current solution >>> proposals cover different approaches. >>> >>> We had the discussion about PMIPv6 domains vs provider >>> domains and came to the conclusion that it's not mandatory >>> for MN and CN to share the same PMIPv6 domain. >>> >>> Assume MN connects to MAG1 and LMA1, whereas CN connects to >>> MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 and MAG2 >>> shares a PMIP domain with LMA2. We cannot assume that MAG1 >>> shares a PMIP domain with LMA2. >>> >>> Now, there are two questions to solve: >>> (1) Who detects and initiates localized routing, MAG or LMA >>> (2) How to synchronize distributed states? Will LMA1 contact >>> LMA2 or will MAG1 contact LMA2 >>> >>> If an existing SA is the only indicator to set up a PMIPv6 >>> domain, then one solution could be to set up an SA >>> dynamically between MAG1 and LMA2, which needs to be re-done >>> every time >>> MN1 performs a handover to a different MAG, say MAG1*. This >>> may be a disadvantage and will blow up PMIPv6 domains, which >>> are rather administratively configured, in my opinion. >>> >>> The other alternative is that PMIPv6 domain stractures are >>> not touched and LMA1 will signal with LMA2 to synchronize >>> states of MN and CN. >>> Advantage would be that LMAs do not change during a handover >>> and will keep states on one place. >>> >>> Any opinions? >>> >>> marco >>> >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Mohana.Jeyatharan@sg.panasonic.com Wed Nov 25 02:29:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E8928C105 for ; Wed, 25 Nov 2009 02:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.821 X-Spam-Level: * X-Spam-Status: No, score=1.821 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86RM6-VqQy0U for ; Wed, 25 Nov 2009 02:29:05 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 6F7A93A6976 for ; Wed, 25 Nov 2009 02:29:04 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAPASP6S026820; Wed, 25 Nov 2009 19:28:25 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id nAPASLH03773; Wed, 25 Nov 2009 19:28:22 +0900 (JST) 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, 25 Nov 2009 18:28:26 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B40328@pslexc01.psl.local> In-Reply-To: <005401ca6dab$629e09c0$420ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] multi-LMA : how to handle Thread-Index: Acptq9CRy5ae+xBsT+STRLrhKa88twACpvnQ References: <4B0664E5.6060901@nw.neclab.eu><018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com><4B0A5A0D.9030401@nw.neclab.eu><02fb01ca6cde$70cccd10$420ca40a@china.huawei.com><4B0BC1CF.1050101@nw.neclab.eu> <005401ca6dab$629e09c0$420ca40a@china.huawei.com> From: "Mohana Jeyatharan" To: "Qin Wu" , "Marco Liebsch" Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 10:29:07 -0000 Hi Qin, Marco and all, Have been following the thread and I have one clarifying question. In the multi LMA scenario that is being discussed, is CN.LMA involved during every handoff event in identifying the CN.MAG address and informing to Mn's MAG? =20 If AAA is used as a common trusted entity in identfying CN.LMA address and also helping in creating SA between Mn'MAG and CN'LMA, I am just wondering whether AAA can be used to tell MN's MAG that it owns this prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and when bi-directional tunnels are setup between MAG using PBU/PBA such validation fron AAA can be used to create the routing states at MN's MAG and CN's MAG. Bcos in the multi LMA scenario, AAA will perhaps be the common trusted entity. Just wondering whether CN.LMA needs to be involved during handoff process or CTX and such prefix validation from a common trusted entity (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG RO path. If LMA is configured as the initiator of MAG to MAG RO, then MN.MAG and CN.LMA association may be needed but if MAG is the initiator of RO then perhaps this can be avoided in the handoff case. Also I have few general opinions on MAG initiated RO or LMA initiated RO. Definitely as folks have discussed and identified, LMA is definitely used in detection of CN.MAG and aid in establishing RO, but MAG can be initiator of local MAG RO eventhough MN and CN are not attached to the same MAG. Perhaps the MAG is informed of CN addresses by MN using some L2 mechanism and hence it can initiate RO for a bunch of CNs simultaneously. Thus LMA need not wait for session to be started between every MN and each CN to establish the RO. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Qin Wu > Sent: Wednesday, November 25, 2009 4:44 PM > To: Marco Liebsch > Cc: netext@ietf.org > Subject: Re: [netext] multi-LMA : how to handle >=20 > Hi, Marco: > please see my comments inline. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "Qin Wu" > Cc: > Sent: Tuesday, November 24, 2009 7:21 PM > Subject: Re: [netext] multi-LMA : how to handle >=20 >=20 > > Hi Qin, > > > > please see inline for brief comments. > > > > Qin Wu wrote: > >> Hi, Marco: > >> Thank for your reply, please see my comments inline. > >> > >> Regards! > >> -Qin > >> ----- Original Message ----- > >> From: "Marco Liebsch" > >> To: "Qin Wu" > >> Cc: > >> Sent: Monday, November 23, 2009 5:46 PM > >> Subject: Re: [netext] multi-LMA : how to handle > >> > >> > >> > >>> Hi Qin, > >>> > >>> please find my comments inline. > >>> > >>> Qin Wu wrote: > >>> > >>>> Hi, Marco: > >>>> Thank for your raising discussion on Multi-LMA issue. > >>>> Please see my comments inline! > >>>> > >>>> Regards! > >>>> -Qin > >>>> ----- Original Message ----- > >>>> From: "Marco Liebsch" > >>>> To: > >>>> Sent: Friday, November 20, 2009 5:44 PM > >>>> Subject: [netext] multi-LMA : how to handle > >>>> > >>>> > >>>> > >>>> > >>>>> Folks, > >>>>> > >>>>> as a follow up of our discussion about localized routing in a > >>>>> multi-LMA setup, I'd like to initiate a general and clarifying > >>>>> discussion about signaling paths to set up and maintain a > >>>>> localized routing path, as current solution proposals cover > >>>>> different approaches. > >>>>> > >>>>> We had the discussion about PMIPv6 domains vs provider domains > >>>>> and came to the conclusion that it's not mandatory for MN and CN > >>>>> to share the same PMIPv6 domain. > >>>>> > >>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects > >>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 > >>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume > >>>>> that MAG1 shares a PMIP domain with LMA2. > >>>>> > >>>>> Now, there are two questions to solve: > >>>>> (1) Who detects and initiates localized routing, MAG or LMA > >>>>> > >> > >> > >>>> [Qin]: I think Both have its value and are applicable to different > scenarios. Whether using MAG initiated or using LMA initiated depends on > >>>> who detects localized routing, in other words, if MAG detects local > routing is possible, then MAG initiated is more appropriate. > >>>> e.g., As described in RFC5213, in the scenario where MN and CN attach > to the same MAG, MAG initiated local routing can > >>>> be used to negotiate with LMA and enfoce local routing on the MAG. > >>>> > >> > >> > >>> Only in single MAG case it may make sense that the MAG detects and > >>> establishes > >>> a localized route. However, even in such case, the LMA must > control/enforce > >>> the setup of the localized route as per RFC5213. So, the LMA > >>> is the point of control and my personal opinion is that this is > >>> reasonable, as the > >>> LMA maintains states beyond a single MAG. And, dependent on the > mechanism > >>> behind HNP assignment (address pools, delegation, ...), the LMA may > know if > >>> the setup of a localized route is useful (in case CN is local) or not. > >>> > >> > >> [Qin]: Right, single MAG case is more appropirate to apply MAG > initiated local routing. Also single MAG case can be divided into two sub > cases: i.e.,A11 and A12 described in the PS draft. These two sub cases > should be taken care in the solution draft. > >> > >> On the other hand, I agree LMA control the setup of localized routing, > but it seems to me who initiate localized routing does not depend on who > control the setup of the localized route. In the MAG initiate localized > routing, MAG can initiate local routing with LMA to see whether localized > routing is available. > >> > > yes, we can have 3 different ways to do this: > > (1) MAG1 detects and requests LMA1 to set up localized routes > > (2) MAG1 detects and requests LMA2 to set up localized routes > > (3) LMA1 detects and sets up localized routes >=20 > [Qin]: Okay. > >> > >> > >>>> If LMA is responsible for local routing, then LMA inititated and MAG > initiate both can be used. > >>>> e.g., in the scenario where MN and CN attach to the different MAGs > but connect to the different LMA or the same LMA. > >>>> > >>>> > >>> Since the LMA needs to enforce localized routing in all cases, I > >>> personally see the > >>> LMA as detector. > >>> > >> > >> [Qin]: Okay. > >> > >> > >>> If for some reason the MAG may be able to detect, it should > >>> inform the LMA of the attached MN to enforce localized routing. > >>> > >> > >> [Qin]: I agee. > >> > >> > >>>>> (2) How to synchronize distributed states? Will LMA1 contact > >>>>> LMA2 or will MAG1 contact LMA2 > >>>>> > >>>>> If an existing SA is the only indicator to set up a PMIPv6 > >>>>> domain, then one solution could be to set up an SA dynamically > >>>>> between MAG1 and LMA2, which needs to be re-done every time > >>>>> MN1 performs a handover to a different MAG, say MAG1*. This > >>>>> may be a disadvantage and will blow up PMIPv6 domains, which > >>>>> are rather administratively configured, in my opinion. > >>>>> > >>>>> > >>>> [Qin]: It seems to me SA setup each time MN handover to the new MAG > is one generic issue we should face for all the Multi-LMA cases. > >>>> In other words,When using LMA1 to signal with LMA2 for states > synchroizing, it has the same problem. Suppose MN connect to the LMA1, > >>>> each time the MN handover from previous MAG to the new MAG, the new > MAG needs to setup SA with the LMA1 dynamically again. > >>>> > >>>> > >>> there is a big difference between localized routing associations > between > >>> MAGs > >>> and handover between MAGs. > >>> > >> > >> [Qin]: No doubt to this. > >> > >> > >>> Handover is between globally adjacent ARs/MAGs, hence, I think an LMA > >>> maintains an SA with an MN's MAG and potential handover targets. > >>> > >> > >> [Qin]: How? You can not predict the direction of MN's movement, i.e., > to which MAG the MN will move. Therefore > >> you can not expect there is an SA between LMA and handover targets > beforehand. > >> > > well, don't confuse SA with forwarding tunnel. The SAs between MAG and a > > particular LMA > > should be pre-established when the MN arrives, whereas the forwarding > > tunnel may exist > > or may be set up dynamically when the MN arrives. >=20 > [Qin]: I agree SA and forwarding tunnel are two different things. But the > common aspect of both is > SA and forwarding tunnel for one MN can be reused by the other MN who > arrives at the same MAG > and routes the packet to the same tunnel end point, i.e., LMA. Right? >=20 > >> > >>> If you > >>> would establish them each time a handover occurs, this would have > impact > >>> to the handover latency. Don't think this is how PMIP is deployed. > >>> > >> > >> [Qin] As I said in the previous mail, the possible way to fix this > issue is > >> SA or tunnel setup for the first MN between MAG and LMA can be shared > >> by the other MNs who are attaching to the same MAG and register to the > same LMA as the first MN. > >> > > I understood your point, but I do not agree :-) I do not think that a > > MAG should establish an SA > > with any LMA dynamically when the MN arrives, in particular not with an > > LMA which does not > > serve the MN but the CN. >=20 > [Qin]: It seem to me it does not matther whether SA is pre-established or > dynamically established. > The key point is whether SA can be shared by all the MNs who are using the > same path between MAG and LMA. >=20 > >> that is to say, the SA or tunnel between MAG and LMA is not per-MN or > per-CN and can be reused > >> by all the MNs and CNs upon it is setup at the first time. > >> In this sense, it avoid establishing SA each time a handover occurs. > >> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is not > neccessary to be established > >> again if SA between MAG1 and LMA2 has already been setup. > >> > >> > >>> Now, > >>> localized routing between MN and CN could mean that MN's MAG and CN's > >>> MAG are pretty far apart. > >>> > >> > >> [Qin] As described in PS draft, We should limit MN's MAG and CN's MAG > within the same domain, am I right? > >> > > Even if they are in one provider domain, distance between MAGs can be > > huge. Multiple LMAs may > > be used by the provider to distribute load and to be responsible for a > > smaller region (subset of MAGs). >=20 > [Qin]: To me, the physical distance is not big issue. The more important > thing is whether communication between MAGs is within the > same provider domain or acrosss provider domain. >=20 > >> > >>> Different LMAs could serve different PMIPv6 > >>> domains. I don't think it's reasonable to merge these PMIP domains > >>> dynamically by means of establishing an SA between MN's MAG and > >>> CN's LMA. > >>> > >> > >> [Qin]: Same as above. > >> > >> > >>> Rather LMAs could take care about the setup of the route > >>> between these MAGs. If both LMAs are in different PMIP domains > >>> but in the same provider network, such signaling is simple. > >>> > >>> > >>> > >>>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks > with LMA2, if there is no SA between MAG1 and LMA2, we can ask > >>>> LMA2 exchange with AAA server to do authorization and validate > whether MAG1 can fetch CN's MAG address from LMA2. > >>>> > >>>> > >>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? > >>> > >> > >> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address from > LMA2, LMA2 should validate the message from MN's MAG1 using AAA mechanism. > >> > >> > >>>> Also since SA is setup between one MAG and one LMA, upon the first MN > who is attaching to the MAG triggers this MAG to setup SA with LMA, > >>>> the SA can also be used by the other MN who attach to the same MAG to > protect the data traffic between MAG and LMA Therefore the second MN who > >>>> is attaching to the same MAG may not setup SA again. Because all the > existing SA can be reused. > >>>> > >>>> Therefore SA setup is not a big issue, the biggest issue is: > >>>> 1) who discover CN's LMA address? > >>>> 2) how does he discover CN's LMA address? > >>>> > >>>> > >>> "Who?" should be the LMA, as you need to discovery only once, whereas > >>> if it's the MAG, each handover MAG needs to discover again, unless you > >>> make the localized routing protocol dependent on CTX, which is not > >>> a good approach. > >>> > >> > >> [Qin]: For the handover case, If CTX is used with localized routing > protocol, discovery is done once as well. > >> But CTX is not the only way. > >> Besides CTX, there is another possible way to deal with handover case > for multi-LMA. > >> > >> Since it is MN's MAG or CN's MAG who is responsible for setup localized > routing path, LMA still > >> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to MN's > MAG. > >> Therefore when MN handover from MN's previous MAG to the MN's new MAG, > it is not MN's LMA but MN's new MAG who is first to know that MN's > handover happen, then MN's new MAG can trigger LMA to notify CN's MAG to > update MN's MAG address at CN's MAG, > >> then CN's MAG updates localized routing path with MN's new MAG. > >> > > I think the basic assumption for the solutions should be that the MN's > > handover > > target MAG does not know more than what PMIPv6 as per RFC5213 requires, > > which is the LMA where to send the PBU to and does not cover any > localized > > routing information. The information and states about localized routing > > could be > > re-established (instead of transferred) by a common anchor, which does > not > > change: The LMA. > > draft-oulai even sets up localized routing states on both MAGs without > > any signaling between MAGs at all. We proposed something similar in > > draft-abeille, which was named 'proxy mode'. Such approach has some > > advantages if there is no SA between MAGs. >=20 > [Qin]: Since localized routing protocol can be used between source > MAG(i.e., MN's MAG) and LMA, > it also can be used between target MAG and LMA. I don't think it is a big > issue. > Also in some case, MN's prefix and CN's prefix should be validated to > create for valid routing between MAGs. > therefore LMA can notify both MAG that MN's prefix or CN's prefix is valid > each time handover happens.Also LMA can tell target MAG the information > about localized routing. > On the other hand, when routing path is established, target MAG need to > install localized routing states. This mechanism is quite similar to the > routing optimization between MN and CN described in RFC3775 and RFC4866. >=20 > > marco > > > > > >> In this way, discovery is done only once as well. > >> > >> > >>> "How?" could be different approaches. Static solutions could be based > on > >>> the LMA's knowledge about address/HNP pools for HNP assignment > >>> to attaching MNs. Dynamic solutions could be based on a AAA > infrastructure > >>> as you referred to above. I don't think this particular "How?" should > be > >>> addressed > >>> by the localized routing solution. > >>> > >> > >> [Qin]: I agree. > >> > >> > >>>> One example is , If AAA based CN's LMA discovery can be used, we can > ask AAA server push the keying materails which is used to protect the > trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's > LMA respectively. In this sense, the trust relationship between MN's MAG > and CN's LMA can be easily setup. > >>>> > >>>> > >>>> > >>>>> The other alternative is that PMIPv6 domain stractures are not > touched > >>>>> and LMA1 will signal with LMA2 to synchronize states of MN and CN. > >>>>> Advantage would be that LMAs do not change during a handover and > >>>>> will keep states on one place. > >>>>> > >>>>> > >>>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how > does LMA1 know LMA2 address? > >>>> > >>>> > >>> Same as MAG1 may discover LMA2, with many advantages if you do this > from > >>> LMA1. > >>> > >>> marco > >>> > >>> > >>>> > >>>> > >>>>> Any opinions? > >>>>> > >>>>> marco > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netext mailing list > >>>>> netext@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>> > >>>>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Wed Nov 25 03:08:27 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139A23A6872 for ; Wed, 25 Nov 2009 03:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUoPG+hyEs1K for ; Wed, 25 Nov 2009 03:08:25 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9BEC33A68ED for ; Wed, 25 Nov 2009 03:08:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C04DB2C01D45F; Wed, 25 Nov 2009 12:08:19 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 866bWkScTjxK; Wed, 25 Nov 2009 12:08:19 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 966C32C0002FE; Wed, 25 Nov 2009 12:08:04 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 12:07:52 +0100 Message-ID: <4B0D1014.3050004@nw.neclab.eu> Date: Wed, 25 Nov 2009 12:08:04 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mohana Jeyatharan References: <4B0664E5.6060901@nw.neclab.eu><018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com><4B0A5A0D.9030401@nw.neclab.eu><02fb01ca6cde$70cccd10$420ca40a@china.huawei.com><4B0BC1CF.1050101@nw.neclab.eu> <005401ca6dab$629e09c0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B40328@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03B40328@pslexc01.psl.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2009 11:07:52.0761 (UTC) FILETIME=[885F5290:01CA6DBF] Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:08:27 -0000 Hi Mohana, please see in-line for my answer to your question. Mohana Jeyatharan wrote: > Hi Qin, Marco and all, > > Have been following the thread and I have one clarifying question. > In the multi LMA scenario that is being discussed, is CN.LMA involved > during every handoff event in identifying the CN.MAG address and > informing to Mn's MAG? > Without pointing to a particular solution but arguing more general, I think the LMAs should be involved and have mayor control in setting up as well as in maintaining the localized routing states on the MAG, as they are the only common nodes (common on a per MN basis) which have the most up to date location information about the MN and the CN respectively. This is LMA1 for MN and LMA2 for CN. > If AAA is used as a common trusted entity in identfying CN.LMA address > and also helping in creating SA between Mn'MAG and CN'LMA, I am just > wondering whether AAA can be used to tell MN's MAG that it owns this > prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and > when bi-directional tunnels are setup between MAG using PBU/PBA such > validation fron AAA can be used to create the routing states at MN's MAG > and CN's MAG. Bcos in the multi LMA scenario, AAA will perhaps be the > common trusted entity. > I do not think that the AAA should be used as mobility anchor, even though the AAA might have information about mobility related states. For sure, he'll have information about each MN's assigned LMA. So, I think the AAA *could* be used to find the MN's and the CN's LMA once during the setup of a localized routing path. After the setup, LMA1 and LMA2 should be known. And I do not think that the localized routing solution should be dependent on the AAA server, hence the solution should work without any AAA infrastructure at all. > Just wondering whether CN.LMA needs to be involved during handoff > process or CTX and such prefix validation from a common trusted entity > (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG RO > path. If LMA is configured as the initiator of MAG to MAG RO, then > MN.MAG and CN.LMA association may be needed but if MAG is the initiator > of RO then perhaps this can be avoided in the handoff case. > both LMAs should be involved as they do not change and they have the most recent location information. However, as we propose, even though both LMAs are involved in the signaling, one LMA should have the control (e.g. LMA2). Then the maintenance during handover cannot run into a deadlock situation and the solution does not need the AAA server as common anchor. > Also I have few general opinions on MAG initiated RO or LMA initiated > RO. > Definitely as folks have discussed and identified, LMA is definitely > used in detection of CN.MAG and aid in establishing RO, but MAG can be > initiator of local MAG RO eventhough MN and CN are not attached to the > same MAG. Perhaps the MAG is informed of CN addresses by MN using some > L2 mechanism and hence it can initiate RO for a bunch of CNs > simultaneously. I don't think you need L2 here, as a data packet from MN to CN, which is forwarded by the MN's MAG, carries the CN's IP address. Or did I misunderstand your proposal? > Thus LMA need not wait for session to be started > between every MN and each CN to establish the RO. > Ah, maybe now I get your point. You propose to set up a localized routing path between the MN and a set of potential CNs before data will be sent, right? I think an important question to answer here is how long localized routing states will be kept alive? Our current view (and implementation) sets localized routing states up when the're needed (when data is sent). They are removed when a session terminates, say after a timeout in case no further data packets reset the timer. These states are rather soft-states. If you set them up before there is data, I am wondering when you delete them again? And how should the MN decide if a localized route to CN1, CN2, etc makes sense? Their location is transparent to the MN. What do you think? marco > > Thanks. > > BR, > Mohana > > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> > Behalf > >> Of Qin Wu >> Sent: Wednesday, November 25, 2009 4:44 PM >> To: Marco Liebsch >> Cc: netext@ietf.org >> Subject: Re: [netext] multi-LMA : how to handle >> >> Hi, Marco: >> please see my comments inline. >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Marco Liebsch" >> To: "Qin Wu" >> Cc: >> Sent: Tuesday, November 24, 2009 7:21 PM >> Subject: Re: [netext] multi-LMA : how to handle >> >> >> >>> Hi Qin, >>> >>> please see inline for brief comments. >>> >>> Qin Wu wrote: >>> >>>> Hi, Marco: >>>> Thank for your reply, please see my comments inline. >>>> >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Marco Liebsch" >>>> To: "Qin Wu" >>>> Cc: >>>> Sent: Monday, November 23, 2009 5:46 PM >>>> Subject: Re: [netext] multi-LMA : how to handle >>>> >>>> >>>> >>>> >>>>> Hi Qin, >>>>> >>>>> please find my comments inline. >>>>> >>>>> Qin Wu wrote: >>>>> >>>>> >>>>>> Hi, Marco: >>>>>> Thank for your raising discussion on Multi-LMA issue. >>>>>> Please see my comments inline! >>>>>> >>>>>> Regards! >>>>>> -Qin >>>>>> ----- Original Message ----- >>>>>> From: "Marco Liebsch" >>>>>> To: >>>>>> Sent: Friday, November 20, 2009 5:44 PM >>>>>> Subject: [netext] multi-LMA : how to handle >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> as a follow up of our discussion about localized routing in a >>>>>>> multi-LMA setup, I'd like to initiate a general and clarifying >>>>>>> discussion about signaling paths to set up and maintain a >>>>>>> localized routing path, as current solution proposals cover >>>>>>> different approaches. >>>>>>> >>>>>>> We had the discussion about PMIPv6 domains vs provider domains >>>>>>> and came to the conclusion that it's not mandatory for MN and CN >>>>>>> to share the same PMIPv6 domain. >>>>>>> >>>>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects >>>>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 >>>>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume >>>>>>> that MAG1 shares a PMIP domain with LMA2. >>>>>>> >>>>>>> Now, there are two questions to solve: >>>>>>> (1) Who detects and initiates localized routing, MAG or LMA >>>>>>> >>>>>>> >>>> >>>>>> [Qin]: I think Both have its value and are applicable to >>>>>> > different > >> scenarios. Whether using MAG initiated or using LMA initiated depends >> > on > >>>>>> who detects localized routing, in other words, if MAG detects >>>>>> > local > >> routing is possible, then MAG initiated is more appropriate. >> >>>>>> e.g., As described in RFC5213, in the scenario where MN and CN >>>>>> > attach > >> to the same MAG, MAG initiated local routing can >> >>>>>> be used to negotiate with LMA and enfoce local routing on the >>>>>> > MAG. > >>>> >>>>> Only in single MAG case it may make sense that the MAG detects and >>>>> establishes >>>>> a localized route. However, even in such case, the LMA must >>>>> >> control/enforce >> >>>>> the setup of the localized route as per RFC5213. So, the LMA >>>>> is the point of control and my personal opinion is that this is >>>>> reasonable, as the >>>>> LMA maintains states beyond a single MAG. And, dependent on the >>>>> >> mechanism >> >>>>> behind HNP assignment (address pools, delegation, ...), the LMA >>>>> > may > >> know if >> >>>>> the setup of a localized route is useful (in case CN is local) or >>>>> > not. > >>>> [Qin]: Right, single MAG case is more appropirate to apply MAG >>>> >> initiated local routing. Also single MAG case can be divided into two >> > sub > >> cases: i.e.,A11 and A12 described in the PS draft. These two sub cases >> should be taken care in the solution draft. >> >>>> On the other hand, I agree LMA control the setup of localized >>>> > routing, > >> but it seems to me who initiate localized routing does not depend on >> > who > >> control the setup of the localized route. In the MAG initiate >> > localized > >> routing, MAG can initiate local routing with LMA to see whether >> > localized > >> routing is available. >> >>> yes, we can have 3 different ways to do this: >>> (1) MAG1 detects and requests LMA1 to set up localized routes >>> (2) MAG1 detects and requests LMA2 to set up localized routes >>> (3) LMA1 detects and sets up localized routes >>> >> [Qin]: Okay. >> >>>> >>>>>> If LMA is responsible for local routing, then LMA inititated and >>>>>> > MAG > >> initiate both can be used. >> >>>>>> e.g., in the scenario where MN and CN attach to the different >>>>>> > MAGs > >> but connect to the different LMA or the same LMA. >> >>>>>> >>>>> Since the LMA needs to enforce localized routing in all cases, I >>>>> personally see the >>>>> LMA as detector. >>>>> >>>>> >>>> [Qin]: Okay. >>>> >>>> >>>> >>>>> If for some reason the MAG may be able to detect, it should >>>>> inform the LMA of the attached MN to enforce localized routing. >>>>> >>>>> >>>> [Qin]: I agee. >>>> >>>> >>>> >>>>>>> (2) How to synchronize distributed states? Will LMA1 contact >>>>>>> LMA2 or will MAG1 contact LMA2 >>>>>>> >>>>>>> If an existing SA is the only indicator to set up a PMIPv6 >>>>>>> domain, then one solution could be to set up an SA dynamically >>>>>>> between MAG1 and LMA2, which needs to be re-done every time >>>>>>> MN1 performs a handover to a different MAG, say MAG1*. This >>>>>>> may be a disadvantage and will blow up PMIPv6 domains, which >>>>>>> are rather administratively configured, in my opinion. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: It seems to me SA setup each time MN handover to the new >>>>>> > MAG > >> is one generic issue we should face for all the Multi-LMA cases. >> >>>>>> In other words,When using LMA1 to signal with LMA2 for states >>>>>> >> synchroizing, it has the same problem. Suppose MN connect to the LMA1, >> >>>>>> each time the MN handover from previous MAG to the new MAG, the >>>>>> > new > >> MAG needs to setup SA with the LMA1 dynamically again. >> >>>>>> >>>>> there is a big difference between localized routing associations >>>>> >> between >> >>>>> MAGs >>>>> and handover between MAGs. >>>>> >>>>> >>>> [Qin]: No doubt to this. >>>> >>>> >>>> >>>>> Handover is between globally adjacent ARs/MAGs, hence, I think an >>>>> > LMA > >>>>> maintains an SA with an MN's MAG and potential handover targets. >>>>> >>>>> >>>> [Qin]: How? You can not predict the direction of MN's movement, >>>> > i.e., > >> to which MAG the MN will move. Therefore >> >>>> you can not expect there is an SA between LMA and handover targets >>>> >> beforehand. >> >>> well, don't confuse SA with forwarding tunnel. The SAs between MAG >>> > and a > >>> particular LMA >>> should be pre-established when the MN arrives, whereas the >>> > forwarding > >>> tunnel may exist >>> or may be set up dynamically when the MN arrives. >>> >> [Qin]: I agree SA and forwarding tunnel are two different things. But >> > the > >> common aspect of both is >> SA and forwarding tunnel for one MN can be reused by the other MN who >> arrives at the same MAG >> and routes the packet to the same tunnel end point, i.e., LMA. Right? >> >> >>>>> If you >>>>> would establish them each time a handover occurs, this would have >>>>> >> impact >> >>>>> to the handover latency. Don't think this is how PMIP is deployed. >>>>> >>>>> >>>> [Qin] As I said in the previous mail, the possible way to fix this >>>> >> issue is >> >>>> SA or tunnel setup for the first MN between MAG and LMA can be >>>> > shared > >>>> by the other MNs who are attaching to the same MAG and register to >>>> > the > >> same LMA as the first MN. >> >>> I understood your point, but I do not agree :-) I do not think that >>> > a > >>> MAG should establish an SA >>> with any LMA dynamically when the MN arrives, in particular not with >>> > an > >>> LMA which does not >>> serve the MN but the CN. >>> >> [Qin]: It seem to me it does not matther whether SA is pre-established >> > or > >> dynamically established. >> The key point is whether SA can be shared by all the MNs who are using >> > the > >> same path between MAG and LMA. >> >> >>>> that is to say, the SA or tunnel between MAG and LMA is not per-MN >>>> > or > >> per-CN and can be reused >> >>>> by all the MNs and CNs upon it is setup at the first time. >>>> In this sense, it avoid establishing SA each time a handover >>>> > occurs. > >>>> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is >>>> > not > >> neccessary to be established >> >>>> again if SA between MAG1 and LMA2 has already been setup. >>>> >>>> >>>> >>>>> Now, >>>>> localized routing between MN and CN could mean that MN's MAG and >>>>> > CN's > >>>>> MAG are pretty far apart. >>>>> >>>>> >>>> [Qin] As described in PS draft, We should limit MN's MAG and CN's >>>> > MAG > >> within the same domain, am I right? >> >>> Even if they are in one provider domain, distance between MAGs can >>> > be > >>> huge. Multiple LMAs may >>> be used by the provider to distribute load and to be responsible for >>> > a > >>> smaller region (subset of MAGs). >>> >> [Qin]: To me, the physical distance is not big issue. The more >> > important > >> thing is whether communication between MAGs is within the >> same provider domain or acrosss provider domain. >> >> >>>>> Different LMAs could serve different PMIPv6 >>>>> domains. I don't think it's reasonable to merge these PMIP domains >>>>> dynamically by means of establishing an SA between MN's MAG and >>>>> CN's LMA. >>>>> >>>>> >>>> [Qin]: Same as above. >>>> >>>> >>>> >>>>> Rather LMAs could take care about the setup of the route >>>>> between these MAGs. If both LMAs are in different PMIP domains >>>>> but in the same provider network, such signaling is simple. >>>>> >>>>> >>>>> >>>>> >>>>>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks >>>>>> >> with LMA2, if there is no SA between MAG1 and LMA2, we can ask >> >>>>>> LMA2 exchange with AAA server to do authorization and validate >>>>>> >> whether MAG1 can fetch CN's MAG address from LMA2. >> >>>>>> >>>>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? >>>>> >>>>> >>>> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address >>>> > from > >> LMA2, LMA2 should validate the message from MN's MAG1 using AAA >> > mechanism. > >>>> >>>>>> Also since SA is setup between one MAG and one LMA, upon the >>>>>> > first MN > >> who is attaching to the MAG triggers this MAG to setup SA with LMA, >> >>>>>> the SA can also be used by the other MN who attach to the same >>>>>> > MAG to > >> protect the data traffic between MAG and LMA Therefore the second MN >> > who > >>>>>> is attaching to the same MAG may not setup SA again. Because all >>>>>> > the > >> existing SA can be reused. >> >>>>>> Therefore SA setup is not a big issue, the biggest issue is: >>>>>> 1) who discover CN's LMA address? >>>>>> 2) how does he discover CN's LMA address? >>>>>> >>>>>> >>>>>> >>>>> "Who?" should be the LMA, as you need to discovery only once, >>>>> > whereas > >>>>> if it's the MAG, each handover MAG needs to discover again, unless >>>>> > you > >>>>> make the localized routing protocol dependent on CTX, which is not >>>>> a good approach. >>>>> >>>>> >>>> [Qin]: For the handover case, If CTX is used with localized routing >>>> >> protocol, discovery is done once as well. >> >>>> But CTX is not the only way. >>>> Besides CTX, there is another possible way to deal with handover >>>> > case > >> for multi-LMA. >> >>>> Since it is MN's MAG or CN's MAG who is responsible for setup >>>> > localized > >> routing path, LMA still >> >>>> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to >>>> > MN's > >> MAG. >> >>>> Therefore when MN handover from MN's previous MAG to the MN's new >>>> > MAG, > >> it is not MN's LMA but MN's new MAG who is first to know that MN's >> handover happen, then MN's new MAG can trigger LMA to notify CN's MAG >> > to > >> update MN's MAG address at CN's MAG, >> >>>> then CN's MAG updates localized routing path with MN's new MAG. >>>> >>>> >>> I think the basic assumption for the solutions should be that the >>> > MN's > >>> handover >>> target MAG does not know more than what PMIPv6 as per RFC5213 >>> > requires, > >>> which is the LMA where to send the PBU to and does not cover any >>> >> localized >> >>> routing information. The information and states about localized >>> > routing > >>> could be >>> re-established (instead of transferred) by a common anchor, which >>> > does > >> not >> >>> change: The LMA. >>> draft-oulai even sets up localized routing states on both MAGs >>> > without > >>> any signaling between MAGs at all. We proposed something similar in >>> draft-abeille, which was named 'proxy mode'. Such approach has some >>> advantages if there is no SA between MAGs. >>> >> [Qin]: Since localized routing protocol can be used between source >> MAG(i.e., MN's MAG) and LMA, >> it also can be used between target MAG and LMA. I don't think it is a >> > big > >> issue. >> Also in some case, MN's prefix and CN's prefix should be validated to >> create for valid routing between MAGs. >> therefore LMA can notify both MAG that MN's prefix or CN's prefix is >> > valid > >> each time handover happens.Also LMA can tell target MAG the >> > information > >> about localized routing. >> On the other hand, when routing path is established, target MAG need >> > to > >> install localized routing states. This mechanism is quite similar to >> > the > >> routing optimization between MN and CN described in RFC3775 and >> > RFC4866. > >>> marco >>> >>> >>> >>>> In this way, discovery is done only once as well. >>>> >>>> >>>> >>>>> "How?" could be different approaches. Static solutions could be >>>>> > based > >> on >> >>>>> the LMA's knowledge about address/HNP pools for HNP assignment >>>>> to attaching MNs. Dynamic solutions could be based on a AAA >>>>> >> infrastructure >> >>>>> as you referred to above. I don't think this particular "How?" >>>>> > should > >> be >> >>>>> addressed >>>>> by the localized routing solution. >>>>> >>>>> >>>> [Qin]: I agree. >>>> >>>> >>>> >>>>>> One example is , If AAA based CN's LMA discovery can be used, we >>>>>> > can > >> ask AAA server push the keying materails which is used to protect the >> trust relationship between MN's MAG and CN's LMA to the MN's MAG and >> > CN's > >> LMA respectively. In this sense, the trust relationship between MN's >> > MAG > >> and CN's LMA can be easily setup. >> >>>>>> >>>>>> >>>>>>> The other alternative is that PMIPv6 domain stractures are not >>>>>>> >> touched >> >>>>>>> and LMA1 will signal with LMA2 to synchronize states of MN and >>>>>>> > CN. > >>>>>>> Advantage would be that LMAs do not change during a handover and >>>>>>> will keep states on one place. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, >>>>>> > how > >> does LMA1 know LMA2 address? >> >>>>>> >>>>> Same as MAG1 may discover LMA2, with many advantages if you do >>>>> > this > >> from >> >>>>> LMA1. >>>>> >>>>> marco >>>>> >>>>> >>>>> >>>>>> >>>>>>> Any opinions? >>>>>>> >>>>>>> marco >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netext mailing list >>>>>>> netext@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> From sunseawq@huawei.com Thu Nov 26 00:23:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7315C3A69F1 for ; Thu, 26 Nov 2009 00:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD7SrNyVbj1a for ; Thu, 26 Nov 2009 00:23:24 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3988A3A69DF for ; Thu, 26 Nov 2009 00:23:24 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTP000LMJAFT4@szxga03-in.huawei.com> for netext@ietf.org; Thu, 26 Nov 2009 16:23:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTP00KF3JAFU9@szxga03-in.huawei.com> for netext@ietf.org; Thu, 26 Nov 2009 16:23:03 +0800 (CST) Received: from w53375 ([10.164.12.66]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTP00H3AJAFQ3@szxml06-in.huawei.com> for netext@ietf.org; Thu, 26 Nov 2009 16:23:03 +0800 (CST) Date: Thu, 26 Nov 2009 16:23:02 +0800 From: Qin Wu To: Mohana Jeyatharan , Marco Liebsch Message-id: <01f901ca6e71$ac5127c0$420ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B0664E5.6060901@nw.neclab.eu> <018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com> <4B0A5A0D.9030401@nw.neclab.eu> <02fb01ca6cde$70cccd10$420ca40a@china.huawei.com> <4B0BC1CF.1050101@nw.neclab.eu> <005401ca6dab$629e09c0$420ca40a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD03B40328@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:23:26 -0000 Hi, Mohana: Thank for your feedback, please see my comments below. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: "Qin Wu" ; "Marco Liebsch" Cc: Sent: Wednesday, November 25, 2009 6:28 PM Subject: RE: [netext] multi-LMA : how to handle Hi Qin, Marco and all, Have been following the thread and I have one clarifying question. In the multi LMA scenario that is being discussed, is CN.LMA involved during every handoff event in identifying the CN.MAG address and informing to Mn's MAG? [Qin]: Good question, in our solution I-D, when MN handover to the new MAG, suppose CN's MAG address keeps unchanged during MN's handover, CTX can be used between previous MN's MAG and new MN's MAG to inform the CN's MAG address to the MN's MAG. The big advantage is LMA invlovement can be avoided each time MN's handoff. That is to say, CN's LMA is only involved when MN's MAG does not know CN's MAG. Upon MN's MAG know CN's MAG and CTX is allowed between MAGs, MN's new MAG can fetch CN's MAG from MN's previous MAG and update localized routing path between MN's new MAG and CN's MAG without involvement of CN's LMA. If AAA is used as a common trusted entity in identfying CN.LMA address and also helping in creating SA between Mn'MAG and CN'LMA, I am just wondering whether AAA can be used to tell MN's MAG that it owns this prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and when bi-directional tunnels are setup between MAG using PBU/PBA such validation fron AAA can be used to create the routing states at MN's MAG and CN's MAG. Bcos in the multi LMA scenario, AAA will perhaps be the common trusted entity. [Qin]: No, AAA server can not keep track of MN or CN's movement as LMA do, each time MN or CN handoff, MN's MAG address will differ from the previous one and is updated into MN's LMA. It is the same case with CN's MAG address. But wherever MN or CN moves, the MN's LMA and CN's LMA will keep unchanged. Therefore MN's LMA and CN's LMA can may be maintained as a configured entry in the CN's policy profile located in AAA server. Just wondering whether CN.LMA needs to be involved during handoff process or CTX and such prefix validation from a common trusted entity (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG RO path. If LMA is configured as the initiator of MAG to MAG RO, then MN.MAG and CN.LMA association may be needed but if MAG is the initiator of RO then perhaps this can be avoided in the handoff case. [Qin]: As I said above, if CTX is allowed and CN's MAG keeps unchanged during MN's handover, CN's LMA involvement may be not necessary. But if CTX is not available during MN's handover, the MAG may ask the common trusted entity (AAA) between MN's LMA and CN's LMA to inform MN's LMA and CN's LMA respectively for prefix validation. And then MN's LMA inform MN's MAG that prefix is valid, also CN's LMA informs CN's MAG that prefix is valid, is this your idea? Anyway I think AAA based mechanism should be out of scope of the solution I-D. Also I have few general opinions on MAG initiated RO or LMA initiated RO. Definitely as folks have discussed and identified, LMA is definitely used in detection of CN.MAG and aid in establishing RO, but MAG can be initiator of local MAG RO eventhough MN and CN are not attached to the same MAG. Perhaps the MAG is informed of CN addresses by MN using some L2 mechanism and hence it can initiate RO for a bunch of CNs simultaneously. Thus LMA need not wait for session to be started between every MN and each CN to establish the RO. [Qin]: I am not sure L2 mechanism can be used for detection. I think there are other ways using L3 mechanism. But it should be beyond scope of solution I-D. Besides this, I share your opinion. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Qin Wu > Sent: Wednesday, November 25, 2009 4:44 PM > To: Marco Liebsch > Cc: netext@ietf.org > Subject: Re: [netext] multi-LMA : how to handle > > Hi, Marco: > please see my comments inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "Qin Wu" > Cc: > Sent: Tuesday, November 24, 2009 7:21 PM > Subject: Re: [netext] multi-LMA : how to handle > > > > Hi Qin, > > > > please see inline for brief comments. > > > > Qin Wu wrote: > >> Hi, Marco: > >> Thank for your reply, please see my comments inline. > >> > >> Regards! > >> -Qin > >> ----- Original Message ----- > >> From: "Marco Liebsch" > >> To: "Qin Wu" > >> Cc: > >> Sent: Monday, November 23, 2009 5:46 PM > >> Subject: Re: [netext] multi-LMA : how to handle > >> > >> > >> > >>> Hi Qin, > >>> > >>> please find my comments inline. > >>> > >>> Qin Wu wrote: > >>> > >>>> Hi, Marco: > >>>> Thank for your raising discussion on Multi-LMA issue. > >>>> Please see my comments inline! > >>>> > >>>> Regards! > >>>> -Qin > >>>> ----- Original Message ----- > >>>> From: "Marco Liebsch" > >>>> To: > >>>> Sent: Friday, November 20, 2009 5:44 PM > >>>> Subject: [netext] multi-LMA : how to handle > >>>> > >>>> > >>>> > >>>> > >>>>> Folks, > >>>>> > >>>>> as a follow up of our discussion about localized routing in a > >>>>> multi-LMA setup, I'd like to initiate a general and clarifying > >>>>> discussion about signaling paths to set up and maintain a > >>>>> localized routing path, as current solution proposals cover > >>>>> different approaches. > >>>>> > >>>>> We had the discussion about PMIPv6 domains vs provider domains > >>>>> and came to the conclusion that it's not mandatory for MN and CN > >>>>> to share the same PMIPv6 domain. > >>>>> > >>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects > >>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 > >>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume > >>>>> that MAG1 shares a PMIP domain with LMA2. > >>>>> > >>>>> Now, there are two questions to solve: > >>>>> (1) Who detects and initiates localized routing, MAG or LMA > >>>>> > >> > >> > >>>> [Qin]: I think Both have its value and are applicable to different > scenarios. Whether using MAG initiated or using LMA initiated depends on > >>>> who detects localized routing, in other words, if MAG detects local > routing is possible, then MAG initiated is more appropriate. > >>>> e.g., As described in RFC5213, in the scenario where MN and CN attach > to the same MAG, MAG initiated local routing can > >>>> be used to negotiate with LMA and enfoce local routing on the MAG. > >>>> > >> > >> > >>> Only in single MAG case it may make sense that the MAG detects and > >>> establishes > >>> a localized route. However, even in such case, the LMA must > control/enforce > >>> the setup of the localized route as per RFC5213. So, the LMA > >>> is the point of control and my personal opinion is that this is > >>> reasonable, as the > >>> LMA maintains states beyond a single MAG. And, dependent on the > mechanism > >>> behind HNP assignment (address pools, delegation, ...), the LMA may > know if > >>> the setup of a localized route is useful (in case CN is local) or not. > >>> > >> > >> [Qin]: Right, single MAG case is more appropirate to apply MAG > initiated local routing. Also single MAG case can be divided into two sub > cases: i.e.,A11 and A12 described in the PS draft. These two sub cases > should be taken care in the solution draft. > >> > >> On the other hand, I agree LMA control the setup of localized routing, > but it seems to me who initiate localized routing does not depend on who > control the setup of the localized route. In the MAG initiate localized > routing, MAG can initiate local routing with LMA to see whether localized > routing is available. > >> > > yes, we can have 3 different ways to do this: > > (1) MAG1 detects and requests LMA1 to set up localized routes > > (2) MAG1 detects and requests LMA2 to set up localized routes > > (3) LMA1 detects and sets up localized routes > > [Qin]: Okay. > >> > >> > >>>> If LMA is responsible for local routing, then LMA inititated and MAG > initiate both can be used. > >>>> e.g., in the scenario where MN and CN attach to the different MAGs > but connect to the different LMA or the same LMA. > >>>> > >>>> > >>> Since the LMA needs to enforce localized routing in all cases, I > >>> personally see the > >>> LMA as detector. > >>> > >> > >> [Qin]: Okay. > >> > >> > >>> If for some reason the MAG may be able to detect, it should > >>> inform the LMA of the attached MN to enforce localized routing. > >>> > >> > >> [Qin]: I agee. > >> > >> > >>>>> (2) How to synchronize distributed states? Will LMA1 contact > >>>>> LMA2 or will MAG1 contact LMA2 > >>>>> > >>>>> If an existing SA is the only indicator to set up a PMIPv6 > >>>>> domain, then one solution could be to set up an SA dynamically > >>>>> between MAG1 and LMA2, which needs to be re-done every time > >>>>> MN1 performs a handover to a different MAG, say MAG1*. This > >>>>> may be a disadvantage and will blow up PMIPv6 domains, which > >>>>> are rather administratively configured, in my opinion. > >>>>> > >>>>> > >>>> [Qin]: It seems to me SA setup each time MN handover to the new MAG > is one generic issue we should face for all the Multi-LMA cases. > >>>> In other words,When using LMA1 to signal with LMA2 for states > synchroizing, it has the same problem. Suppose MN connect to the LMA1, > >>>> each time the MN handover from previous MAG to the new MAG, the new > MAG needs to setup SA with the LMA1 dynamically again. > >>>> > >>>> > >>> there is a big difference between localized routing associations > between > >>> MAGs > >>> and handover between MAGs. > >>> > >> > >> [Qin]: No doubt to this. > >> > >> > >>> Handover is between globally adjacent ARs/MAGs, hence, I think an LMA > >>> maintains an SA with an MN's MAG and potential handover targets. > >>> > >> > >> [Qin]: How? You can not predict the direction of MN's movement, i.e., > to which MAG the MN will move. Therefore > >> you can not expect there is an SA between LMA and handover targets > beforehand. > >> > > well, don't confuse SA with forwarding tunnel. The SAs between MAG and a > > particular LMA > > should be pre-established when the MN arrives, whereas the forwarding > > tunnel may exist > > or may be set up dynamically when the MN arrives. > > [Qin]: I agree SA and forwarding tunnel are two different things. But the > common aspect of both is > SA and forwarding tunnel for one MN can be reused by the other MN who > arrives at the same MAG > and routes the packet to the same tunnel end point, i.e., LMA. Right? > > >> > >>> If you > >>> would establish them each time a handover occurs, this would have > impact > >>> to the handover latency. Don't think this is how PMIP is deployed. > >>> > >> > >> [Qin] As I said in the previous mail, the possible way to fix this > issue is > >> SA or tunnel setup for the first MN between MAG and LMA can be shared > >> by the other MNs who are attaching to the same MAG and register to the > same LMA as the first MN. > >> > > I understood your point, but I do not agree :-) I do not think that a > > MAG should establish an SA > > with any LMA dynamically when the MN arrives, in particular not with an > > LMA which does not > > serve the MN but the CN. > > [Qin]: It seem to me it does not matther whether SA is pre-established or > dynamically established. > The key point is whether SA can be shared by all the MNs who are using the > same path between MAG and LMA. > > >> that is to say, the SA or tunnel between MAG and LMA is not per-MN or > per-CN and can be reused > >> by all the MNs and CNs upon it is setup at the first time. > >> In this sense, it avoid establishing SA each time a handover occurs. > >> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is not > neccessary to be established > >> again if SA between MAG1 and LMA2 has already been setup. > >> > >> > >>> Now, > >>> localized routing between MN and CN could mean that MN's MAG and CN's > >>> MAG are pretty far apart. > >>> > >> > >> [Qin] As described in PS draft, We should limit MN's MAG and CN's MAG > within the same domain, am I right? > >> > > Even if they are in one provider domain, distance between MAGs can be > > huge. Multiple LMAs may > > be used by the provider to distribute load and to be responsible for a > > smaller region (subset of MAGs). > > [Qin]: To me, the physical distance is not big issue. The more important > thing is whether communication between MAGs is within the > same provider domain or acrosss provider domain. > > >> > >>> Different LMAs could serve different PMIPv6 > >>> domains. I don't think it's reasonable to merge these PMIP domains > >>> dynamically by means of establishing an SA between MN's MAG and > >>> CN's LMA. > >>> > >> > >> [Qin]: Same as above. > >> > >> > >>> Rather LMAs could take care about the setup of the route > >>> between these MAGs. If both LMAs are in different PMIP domains > >>> but in the same provider network, such signaling is simple. > >>> > >>> > >>> > >>>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks > with LMA2, if there is no SA between MAG1 and LMA2, we can ask > >>>> LMA2 exchange with AAA server to do authorization and validate > whether MAG1 can fetch CN's MAG address from LMA2. > >>>> > >>>> > >>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? > >>> > >> > >> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address from > LMA2, LMA2 should validate the message from MN's MAG1 using AAA mechanism. > >> > >> > >>>> Also since SA is setup between one MAG and one LMA, upon the first MN > who is attaching to the MAG triggers this MAG to setup SA with LMA, > >>>> the SA can also be used by the other MN who attach to the same MAG to > protect the data traffic between MAG and LMA Therefore the second MN who > >>>> is attaching to the same MAG may not setup SA again. Because all the > existing SA can be reused. > >>>> > >>>> Therefore SA setup is not a big issue, the biggest issue is: > >>>> 1) who discover CN's LMA address? > >>>> 2) how does he discover CN's LMA address? > >>>> > >>>> > >>> "Who?" should be the LMA, as you need to discovery only once, whereas > >>> if it's the MAG, each handover MAG needs to discover again, unless you > >>> make the localized routing protocol dependent on CTX, which is not > >>> a good approach. > >>> > >> > >> [Qin]: For the handover case, If CTX is used with localized routing > protocol, discovery is done once as well. > >> But CTX is not the only way. > >> Besides CTX, there is another possible way to deal with handover case > for multi-LMA. > >> > >> Since it is MN's MAG or CN's MAG who is responsible for setup localized > routing path, LMA still > >> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to MN's > MAG. > >> Therefore when MN handover from MN's previous MAG to the MN's new MAG, > it is not MN's LMA but MN's new MAG who is first to know that MN's > handover happen, then MN's new MAG can trigger LMA to notify CN's MAG to > update MN's MAG address at CN's MAG, > >> then CN's MAG updates localized routing path with MN's new MAG. > >> > > I think the basic assumption for the solutions should be that the MN's > > handover > > target MAG does not know more than what PMIPv6 as per RFC5213 requires, > > which is the LMA where to send the PBU to and does not cover any > localized > > routing information. The information and states about localized routing > > could be > > re-established (instead of transferred) by a common anchor, which does > not > > change: The LMA. > > draft-oulai even sets up localized routing states on both MAGs without > > any signaling between MAGs at all. We proposed something similar in > > draft-abeille, which was named 'proxy mode'. Such approach has some > > advantages if there is no SA between MAGs. > > [Qin]: Since localized routing protocol can be used between source > MAG(i.e., MN's MAG) and LMA, > it also can be used between target MAG and LMA. I don't think it is a big > issue. > Also in some case, MN's prefix and CN's prefix should be validated to > create for valid routing between MAGs. > therefore LMA can notify both MAG that MN's prefix or CN's prefix is valid > each time handover happens.Also LMA can tell target MAG the information > about localized routing. > On the other hand, when routing path is established, target MAG need to > install localized routing states. This mechanism is quite similar to the > routing optimization between MN and CN described in RFC3775 and RFC4866. > > > marco > > > > > >> In this way, discovery is done only once as well. > >> > >> > >>> "How?" could be different approaches. Static solutions could be based > on > >>> the LMA's knowledge about address/HNP pools for HNP assignment > >>> to attaching MNs. Dynamic solutions could be based on a AAA > infrastructure > >>> as you referred to above. I don't think this particular "How?" should > be > >>> addressed > >>> by the localized routing solution. > >>> > >> > >> [Qin]: I agree. > >> > >> > >>>> One example is , If AAA based CN's LMA discovery can be used, we can > ask AAA server push the keying materails which is used to protect the > trust relationship between MN's MAG and CN's LMA to the MN's MAG and CN's > LMA respectively. In this sense, the trust relationship between MN's MAG > and CN's LMA can be easily setup. > >>>> > >>>> > >>>> > >>>>> The other alternative is that PMIPv6 domain stractures are not > touched > >>>>> and LMA1 will signal with LMA2 to synchronize states of MN and CN. > >>>>> Advantage would be that LMAs do not change during a handover and > >>>>> will keep states on one place. > >>>>> > >>>>> > >>>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, how > does LMA1 know LMA2 address? > >>>> > >>>> > >>> Same as MAG1 may discover LMA2, with many advantages if you do this > from > >>> LMA1. > >>> > >>> marco > >>> > >>> > >>>> > >>>> > >>>>> Any opinions? > >>>>> > >>>>> marco > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netext mailing list > >>>>> netext@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>> > >>>>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Mohana.Jeyatharan@sg.panasonic.com Thu Nov 26 01:16:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF553A6A3A for ; Thu, 26 Nov 2009 01:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.11 X-Spam-Level: ** X-Spam-Status: No, score=2.11 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0cCfqbRE6th for ; Thu, 26 Nov 2009 01:16:42 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 4C5193A6B9E for ; Thu, 26 Nov 2009 01:16:41 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id nAQ9GViS009191; Thu, 26 Nov 2009 18:16:31 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id nAQ9GLo16554; Thu, 26 Nov 2009 18:16:22 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Nov 2009 17:16:28 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03B40525@pslexc01.psl.local> In-Reply-To: <4B0D1014.3050004@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] multi-LMA : how to handle Thread-Index: Acptv5toVp9M0GL4QCSm3hkjfk26SwAtcDmQ References: <4B0664E5.6060901@nw.neclab.eu><018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com><4B0A5A0D.9030401@nw.neclab.eu><02fb01ca6cde$70cccd10$420ca40a@china.huawei.com><4B0BC1CF.1050101@nw.neclab.eu><005401ca6dab$629e09c0$420ca40a@china.huawei.com><5F09D220B62F79418461A978CA0921BD03B40328@pslexc01.psl.local> <4B0D1014.3050004@nw.neclab.eu> From: "Mohana Jeyatharan" To: "Marco Liebsch" Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:16:44 -0000 Hi Marco, Thanks for reply. Please see some replies in-line. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Marco Liebsch > Sent: Wednesday, November 25, 2009 7:08 PM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: [netext] multi-LMA : how to handle >=20 > Hi Mohana, >=20 > please see in-line for my answer to your question. >=20 > Mohana Jeyatharan wrote: > > Hi Qin, Marco and all, > > > > Have been following the thread and I have one clarifying question. > > In the multi LMA scenario that is being discussed, is CN.LMA involved > > during every handoff event in identifying the CN.MAG address and > > informing to Mn's MAG? > > > Without pointing to a particular solution but arguing more general, I > think > the LMAs should be involved and have mayor control in setting up as > well as in maintaining the localized routing states on the MAG, as they > are the only common nodes (common on a per MN basis) which have the > most up to date location information about the MN and the CN respectively. > This is LMA1 for MN and LMA2 for CN. [Mohana] I agree that setting up routing states, LMA has important role. But I am not so convinced about the involvement of LMA in maintaining routing states (handoff case). Bcos after local MAG RO is set up, packets don't pass through LMA and local mechanims such CTX can be used to handle RO. Ofcourse if CTX is not used for some reason(operator choice) then perhaps LMA control even during handoff (as you propose) can be used. Another point is LMA need not unnecessarily keep state for local MAG RO. If MN MAG and CN MAG are quite close, then involving LMA which can even be in another administrative domain can delay the local MAG path setup especially when you have on going session as in the handoff case. Anyway, I am not saying that LMA involvement should not be there. It all depends. Another scenario is where MN LMA and CN LMA do not have trust. Then what mechanism can be used to set up localized routing? I guess currently such scenario is out of scope of the discussion. =20 > > If AAA is used as a common trusted entity in identfying CN.LMA address > > and also helping in creating SA between Mn'MAG and CN'LMA, I am just > > wondering whether AAA can be used to tell MN's MAG that it owns this > > prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and > > when bi-directional tunnels are setup between MAG using PBU/PBA such > > validation fron AAA can be used to create the routing states at MN's MAG > > and CN's MAG. Bcos in the multi LMA scenario, AAA will perhaps be the > > common trusted entity. > > > I do not think that the AAA should be used as mobility anchor, even though > the AAA might have information about mobility related states. For sure, > he'll have > information about each MN's assigned LMA. So, I think the AAA *could* > be used to find the MN's and the CN's LMA once during the setup of a > localized routing path. After the setup, LMA1 and LMA2 should be known. > And I do not think that the localized routing solution should be > dependent on the AAA server, hence the solution should work without > any AAA infrastructure at all. [Mohana] Ok. Since AAA was discussed I was thinking more along this line. If LMA1 (MN LMA)and LMA2 (CN LMA) have trust then no need of a common trusted anchor. But if they are not then was wondering whether we need a common trusted anchor to securly establish local MAG RO. Perhaps we can keep the scenario where there is loose trust between LMAs out of discussion for now as I mentioned previously. > > Just wondering whethe r CN.LMA needs to be involved during handoff > > process or CTX and such prefix validation from a common trusted entity > > (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG RO > > path. If LMA is configured as the initiator of MAG to MAG RO, then > > MN.MAG and CN.LMA association may be needed but if MAG is the initiator > > of RO then perhaps this can be avoided in the handoff case. > > > both LMAs should be involved as they do not change and they have the > most recent location information. However, as we propose, even though > both LMAs are involved in the signaling, one LMA should have the > control (e.g. LMA2). Then the maintenance during handover cannot run > into a deadlock situation and the solution does not need the AAA server > as common anchor. > > Also I have few general opinions on MAG initiated RO or LMA initiated > > RO. > > Definitely as folks have discussed and identified, LMA is definitely > > used in detection of CN.MAG and aid in establishing RO, but MAG can be > > initiator of local MAG RO eventhough MN and CN are not attached to the > > same MAG. Perhaps the MAG is informed of CN addresses by MN using some > > L2 mechanism and hence it can initiate RO for a bunch of CNs > > simultaneously. > I don't think you need L2 here, as a data packet from MN to CN, which > is forwarded by the MN's MAG, carries the CN's IP address. > Or did I misunderstand your proposal? >=20 > > Thus LMA need not wait for session to be started > > between every MN and each CN to establish the RO. > > > Ah, maybe now I get your point. You propose to set up a localized > routing path between the MN and a set of potential CNs before > data will be sent, right? [Mohana] Yes. I think an important question to answer here > is how long localized routing states will be kept alive? Our current view > (and implementation) sets localized routing states up when the're needed > (when data is sent). They are removed when a session terminates, say > after a timeout in case no further data packets reset the timer. These > states are rather soft-states.=20 [Mohana] My thinking was to setup states if the MAG thinks that communication with certain CNs need to be optimized. Based on application or the type of service domain in which CN is placed the MAG may initiate such local rotuing request. Ofcourse once the session is complete the local MAG RO can be torn down. Suppose you are frequently communicating with such CNs then local MAG RO states can be kept for a long time. If you set them up before there is data, > I am wondering when you delete them again? And how should the > MN decide if a localized route to CN1, CN2, etc makes sense? Their > location is transparent to the MN.=20 [Mohana] are you refering to CNs placed in another provider domain with repect to MN. In such a case, probably localized routing is not essential. MN's MAG does not know anything about where CN is. It just wants RO based on some information given to CN. In such a case LMA needs to assist. Anyway as all of us have agreed LMA definitely needs to play its role in supporting local MAG RO. Thanks. What do you think? >=20 > marco >=20 >=20 >=20 > > > > Thanks. > > > > BR, > > Mohana > > > > > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >> > > Behalf > > > >> Of Qin Wu > >> Sent: Wednesday, November 25, 2009 4:44 PM > >> To: Marco Liebsch > >> Cc: netext@ietf.org > >> Subject: Re: [netext] multi-LMA : how to handle > >> > >> Hi, Marco: > >> please see my comments inline. > >> > >> Regards! > >> -Qin > >> ----- Original Message ----- > >> From: "Marco Liebsch" > >> To: "Qin Wu" > >> Cc: > >> Sent: Tuesday, November 24, 2009 7:21 PM > >> Subject: Re: [netext] multi-LMA : how to handle > >> > >> > >> > >>> Hi Qin, > >>> > >>> please see inline for brief comments. > >>> > >>> Qin Wu wrote: > >>> > >>>> Hi, Marco: > >>>> Thank for your reply, please see my comments inline. > >>>> > >>>> Regards! > >>>> -Qin > >>>> ----- Original Message ----- > >>>> From: "Marco Liebsch" > >>>> To: "Qin Wu" > >>>> Cc: > >>>> Sent: Monday, November 23, 2009 5:46 PM > >>>> Subject: Re: [netext] multi-LMA : how to handle > >>>> > >>>> > >>>> > >>>> > >>>>> Hi Qin, > >>>>> > >>>>> please find my comments inline. > >>>>> > >>>>> Qin Wu wrote: > >>>>> > >>>>> > >>>>>> Hi, Marco: > >>>>>> Thank for your raising discussion on Multi-LMA issue. > >>>>>> Please see my comments inline! > >>>>>> > >>>>>> Regards! > >>>>>> -Qin > >>>>>> ----- Original Message ----- > >>>>>> From: "Marco Liebsch" > >>>>>> To: > >>>>>> Sent: Friday, November 20, 2009 5:44 PM > >>>>>> Subject: [netext] multi-LMA : how to handle > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Folks, > >>>>>>> > >>>>>>> as a follow up of our discussion about localized routing in a > >>>>>>> multi-LMA setup, I'd like to initiate a general and clarifying > >>>>>>> discussion about signaling paths to set up and maintain a > >>>>>>> localized routing path, as current solution proposals cover > >>>>>>> different approaches. > >>>>>>> > >>>>>>> We had the discussion about PMIPv6 domains vs provider domains > >>>>>>> and came to the conclusion that it's not mandatory for MN and CN > >>>>>>> to share the same PMIPv6 domain. > >>>>>>> > >>>>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects > >>>>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 > >>>>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume > >>>>>>> that MAG1 shares a PMIP domain with LMA2. > >>>>>>> > >>>>>>> Now, there are two questions to solve: > >>>>>>> (1) Who detects and initiates localized routing, MAG or LMA > >>>>>>> > >>>>>>> > >>>> > >>>>>> [Qin]: I think Both have its value and are applicable to > >>>>>> > > different > > > >> scenarios. Whether using MAG initiated or using LMA initiated depends > >> > > on > > > >>>>>> who detects localized routing, in other words, if MAG detects > >>>>>> > > local > > > >> routing is possible, then MAG initiated is more appropriate. > >> > >>>>>> e.g., As described in RFC5213, in the scenario where MN and CN > >>>>>> > > attach > > > >> to the same MAG, MAG initiated local routing can > >> > >>>>>> be used to negotiate with LMA and enfoce local routing on the > >>>>>> > > MAG. > > > >>>> > >>>>> Only in single MAG case it may make sense that the MAG detects and > >>>>> establishes > >>>>> a localized route. However, even in such case, the LMA must > >>>>> > >> control/enforce > >> > >>>>> the setup of the localized route as per RFC5213. So, the LMA > >>>>> is the point of control and my personal opinion is that this is > >>>>> reasonable, as the > >>>>> LMA maintains states beyond a single MAG. And, dependent on the > >>>>> > >> mechanism > >> > >>>>> behind HNP assignment (address pools, delegation, ...), the LMA > >>>>> > > may > > > >> know if > >> > >>>>> the setup of a localized route is useful (in case CN is local) or > >>>>> > > not. > > > >>>> [Qin]: Right, single MAG case is more appropirate to apply MAG > >>>> > >> initiated local routing. Also single MAG case can be divided into two > >> > > sub > > > >> cases: i.e.,A11 and A12 described in the PS draft. These two sub cases > >> should be taken care in the solution draft. > >> > >>>> On the other hand, I agree LMA control the setup of localized > >>>> > > routing, > > > >> but it seems to me who initiate localized routing does not depend on > >> > > who > > > >> control the setup of the localized route. In the MAG initiate > >> > > localized > > > >> routing, MAG can initiate local routing with LMA to see whether > >> > > localized > > > >> routing is available. > >> > >>> yes, we can have 3 different ways to do this: > >>> (1) MAG1 detects and requests LMA1 to set up localized routes > >>> (2) MAG1 detects and requests LMA2 to set up localized routes > >>> (3) LMA1 detects and sets up localized routes > >>> > >> [Qin]: Okay. > >> > >>>> > >>>>>> If LMA is responsible for local routing, then LMA inititated and > >>>>>> > > MAG > > > >> initiate both can be used. > >> > >>>>>> e.g., in the scenario where MN and CN attach to the different > >>>>>> > > MAGs > > > >> but connect to the different LMA or the same LMA. > >> > >>>>>> > >>>>> Since the LMA needs to enforce localized routing in all cases, I > >>>>> personally see the > >>>>> LMA as detector. > >>>>> > >>>>> > >>>> [Qin]: Okay. > >>>> > >>>> > >>>> > >>>>> If for some reason the MAG may be able to detect, it should > >>>>> inform the LMA of the attached MN to enforce localized routing. > >>>>> > >>>>> > >>>> [Qin]: I agee. > >>>> > >>>> > >>>> > >>>>>>> (2) How to synchronize distributed states? Will LMA1 contact > >>>>>>> LMA2 or will MAG1 contact LMA2 > >>>>>>> > >>>>>>> If an existing SA is the only indicator to set up a PMIPv6 > >>>>>>> domain, then one solution could be to set up an SA dynamically > >>>>>>> between MAG1 and LMA2, which needs to be re-done every time > >>>>>>> MN1 performs a handover to a different MAG, say MAG1*. This > >>>>>>> may be a disadvantage and will blow up PMIPv6 domains, which > >>>>>>> are rather administratively configured, in my opinion. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> [Qin]: It seems to me SA setup each time MN handover to the new > >>>>>> > > MAG > > > >> is one generic issue we should face for all the Multi-LMA cases. > >> > >>>>>> In other words,When using LMA1 to signal with LMA2 for states > >>>>>> > >> synchroizing, it has the same problem. Suppose MN connect to the LMA1, > >> > >>>>>> each time the MN handover from previous MAG to the new MAG, the > >>>>>> > > new > > > >> MAG needs to setup SA with the LMA1 dynamically again. > >> > >>>>>> > >>>>> there is a big difference between localized routing associations > >>>>> > >> between > >> > >>>>> MAGs > >>>>> and handover between MAGs. > >>>>> > >>>>> > >>>> [Qin]: No doubt to this. > >>>> > >>>> > >>>> > >>>>> Handover is between globally adjacent ARs/MAGs, hence, I think an > >>>>> > > LMA > > > >>>>> maintains an SA with an MN's MAG and potential handover targets. > >>>>> > >>>>> > >>>> [Qin]: How? You can not predict the direction of MN's movement, > >>>> > > i.e., > > > >> to which MAG the MN will move. Therefore > >> > >>>> you can not expect there is an SA between LMA and handover targets > >>>> > >> beforehand. > >> > >>> well, don't confuse SA with forwarding tunnel. The SAs between MAG > >>> > > and a > > > >>> particular LMA > >>> should be pre-established when the MN arrives, whereas the > >>> > > forwarding > > > >>> tunnel may exist > >>> or may be set up dynamically when the MN arrives. > >>> > >> [Qin]: I agree SA and forwarding tunnel are two different things. But > >> > > the > > > >> common aspect of both is > >> SA and forwarding tunnel for one MN can be reused by the other MN who > >> arrives at the same MAG > >> and routes the packet to the same tunnel end point, i.e., LMA. Right? > >> > >> > >>>>> If you > >>>>> would establish them each time a handover occurs, this would have > >>>>> > >> impact > >> > >>>>> to the handover latency. Don't think this is how PMIP is deployed. > >>>>> > >>>>> > >>>> [Qin] As I said in the previous mail, the possible way to fix this > >>>> > >> issue is > >> > >>>> SA or tunnel setup for the first MN between MAG and LMA can be > >>>> > > shared > > > >>>> by the other MNs who are attaching to the same MAG and register to > >>>> > > the > > > >> same LMA as the first MN. > >> > >>> I understood your point, but I do not agree :-) I do not think that > >>> > > a > > > >>> MAG should establish an SA > >>> with any LMA dynamically when the MN arrives, in particular not with > >>> > > an > > > >>> LMA which does not > >>> serve the MN but the CN. > >>> > >> [Qin]: It seem to me it does not matther whether SA is pre-established > >> > > or > > > >> dynamically established. > >> The key point is whether SA can be shared by all the MNs who are using > >> > > the > > > >> same path between MAG and LMA. > >> > >> > >>>> that is to say, the SA or tunnel between MAG and LMA is not per-MN > >>>> > > or > > > >> per-CN and can be reused > >> > >>>> by all the MNs and CNs upon it is setup at the first time. > >>>> In this sense, it avoid establishing SA each time a handover > >>>> > > occurs. > > > >>>> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is > >>>> > > not > > > >> neccessary to be established > >> > >>>> again if SA between MAG1 and LMA2 has already been setup. > >>>> > >>>> > >>>> > >>>>> Now, > >>>>> localized routing between MN and CN could mean that MN's MAG and > >>>>> > > CN's > > > >>>>> MAG are pretty far apart. > >>>>> > >>>>> > >>>> [Qin] As described in PS draft, We should limit MN's MAG and CN's > >>>> > > MAG > > > >> within the same domain, am I right? > >> > >>> Even if they are in one provider domain, distance between MAGs can > >>> > > be > > > >>> huge. Multiple LMAs may > >>> be used by the provider to distribute load and to be responsible for > >>> > > a > > > >>> smaller region (subset of MAGs). > >>> > >> [Qin]: To me, the physical distance is not big issue. The more > >> > > important > > > >> thing is whether communication between MAGs is within the > >> same provider domain or acrosss provider domain. > >> > >> > >>>>> Different LMAs could serve different PMIPv6 > >>>>> domains. I don't think it's reasonable to merge these PMIP domains > >>>>> dynamically by means of establishing an SA between MN's MAG and > >>>>> CN's LMA. > >>>>> > >>>>> > >>>> [Qin]: Same as above. > >>>> > >>>> > >>>> > >>>>> Rather LMAs could take care about the setup of the route > >>>>> between these MAGs. If both LMAs are in different PMIP domains > >>>>> but in the same provider network, such signaling is simple. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> From the other aspect, in the Multi-LMA scenario, when MAG1 talks > >>>>>> > >> with LMA2, if there is no SA between MAG1 and LMA2, we can ask > >> > >>>>>> LMA2 exchange with AAA server to do authorization and validate > >>>>>> > >> whether MAG1 can fetch CN's MAG address from LMA2. > >> > >>>>>> > >>>>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? > >>>>> > >>>>> > >>>> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address > >>>> > > from > > > >> LMA2, LMA2 should validate the message from MN's MAG1 using AAA > >> > > mechanism. > > > >>>> > >>>>>> Also since SA is setup between one MAG and one LMA, upon the > >>>>>> > > first MN > > > >> who is attaching to the MAG triggers this MAG to setup SA with LMA, > >> > >>>>>> the SA can also be used by the other MN who attach to the same > >>>>>> > > MAG to > > > >> protect the data traffic between MAG and LMA Therefore the second MN > >> > > who > > > >>>>>> is attaching to the same MAG may not setup SA again. Because all > >>>>>> > > the > > > >> existing SA can be reused. > >> > >>>>>> Therefore SA setup is not a big issue, the biggest issue is: > >>>>>> 1) who discover CN's LMA address? > >>>>>> 2) how does he discover CN's LMA address? > >>>>>> > >>>>>> > >>>>>> > >>>>> "Who?" should be the LMA, as you need to discovery only once, > >>>>> > > whereas > > > >>>>> if it's the MAG, each handover MAG needs to discover again, unless > >>>>> > > you > > > >>>>> make the localized routing protocol dependent on CTX, which is not > >>>>> a good approach. > >>>>> > >>>>> > >>>> [Qin]: For the handover case, If CTX is used with localized routing > >>>> > >> protocol, discovery is done once as well. > >> > >>>> But CTX is not the only way. > >>>> Besides CTX, there is another possible way to deal with handover > >>>> > > case > > > >> for multi-LMA. > >> > >>>> Since it is MN's MAG or CN's MAG who is responsible for setup > >>>> > > localized > > > >> routing path, LMA still > >> > >>>> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG to > >>>> > > MN's > > > >> MAG. > >> > >>>> Therefore when MN handover from MN's previous MAG to the MN's new > >>>> > > MAG, > > > >> it is not MN's LMA but MN's new MAG who is first to know that MN's > >> handover happen, then MN's new MAG can trigger LMA to notify CN's MAG > >> > > to > > > >> update MN's MAG address at CN's MAG, > >> > >>>> then CN's MAG updates localized routing path with MN's new MAG. > >>>> > >>>> > >>> I think the basic assumption for the solutions should be that the > >>> > > MN's > > > >>> handover > >>> target MAG does not know more than what PMIPv6 as per RFC5213 > >>> > > requires, > > > >>> which is the LMA where to send the PBU to and does not cover any > >>> > >> localized > >> > >>> routing information. The information and states about localized > >>> > > routing > > > >>> could be > >>> re-established (instead of transferred) by a common anchor, which > >>> > > does > > > >> not > >> > >>> change: The LMA. > >>> draft-oulai even sets up localized routing states on both MAGs > >>> > > without > > > >>> any signaling between MAGs at all. We proposed something similar in > >>> draft-abeille, which was named 'proxy mode'. Such approach has some > >>> advantages if there is no SA between MAGs. > >>> > >> [Qin]: Since localized routing protocol can be used between source > >> MAG(i.e., MN's MAG) and LMA, > >> it also can be used between target MAG and LMA. I don't think it is a > >> > > big > > > >> issue. > >> Also in some case, MN's prefix and CN's prefix should be validated to > >> create for valid routing between MAGs. > >> therefore LMA can notify both MAG that MN's prefix or CN's prefix is > >> > > valid > > > >> each time handover happens.Also LMA can tell target MAG the > >> > > information > > > >> about localized routing. > >> On the other hand, when routing path is established, target MAG need > >> > > to > > > >> install localized routing states. This mechanism is quite similar to > >> > > the > > > >> routing optimization between MN and CN described in RFC3775 and > >> > > RFC4866. > > > >>> marco > >>> > >>> > >>> > >>>> In this way, discovery is done only once as well. > >>>> > >>>> > >>>> > >>>>> "How?" could be different approaches. Static solutions could be > >>>>> > > based > > > >> on > >> > >>>>> the LMA's knowledge about address/HNP pools for HNP assignment > >>>>> to attaching MNs. Dynamic solutions could be based on a AAA > >>>>> > >> infrastructure > >> > >>>>> as you referred to above. I don't think this particular "How?" > >>>>> > > should > > > >> be > >> > >>>>> addressed > >>>>> by the localized routing solution. > >>>>> > >>>>> > >>>> [Qin]: I agree. > >>>> > >>>> > >>>> > >>>>>> One example is , If AAA based CN's LMA discovery can be used, we > >>>>>> > > can > > > >> ask AAA server push the keying materails which is used to protect the > >> trust relationship between MN's MAG and CN's LMA to the MN's MAG and > >> > > CN's > > > >> LMA respectively. In this sense, the trust relationship between MN's > >> > > MAG > > > >> and CN's LMA can be easily setup. > >> > >>>>>> > >>>>>> > >>>>>>> The other alternative is that PMIPv6 domain stractures are not > >>>>>>> > >> touched > >> > >>>>>>> and LMA1 will signal with LMA2 to synchronize states of MN and > >>>>>>> > > CN. > > > >>>>>>> Advantage would be that LMAs do not change during a handover and > >>>>>>> will keep states on one place. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> [Qin]: if using LMA1 signaling with LMA2 for state synchronizing, > >>>>>> > > how > > > >> does LMA1 know LMA2 address? > >> > >>>>>> > >>>>> Same as MAG1 may discover LMA2, with many advantages if you do > >>>>> > > this > > > >> from > >> > >>>>> LMA1. > >>>>> > >>>>> marco > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>>> Any opinions? > >>>>>>> > >>>>>>> marco > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> netext mailing list > >>>>>>> netext@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>>>> > >>>>>>> > >>>>>>> > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>> > >>>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Thu Nov 26 03:02:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3D03A6896 for ; Thu, 26 Nov 2009 03:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2ClSZjVbcHz for ; Thu, 26 Nov 2009 03:02:10 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1E9903A686C for ; Thu, 26 Nov 2009 03:02:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D30F42C01C99C; Thu, 26 Nov 2009 12:02:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kn5498wmoO6; Thu, 26 Nov 2009 12:02:03 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A049B2C0002FE; Thu, 26 Nov 2009 12:01:53 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 12:01:45 +0100 Message-ID: <4B0E6016.6010303@nw.neclab.eu> Date: Thu, 26 Nov 2009 12:01:42 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mohana Jeyatharan References: DEFANGED[3762]:<4B0664E5.6060901@nw.neclab.eu><018a01ca6c05$6ebb37c0$420ca40a@china.huawei.com><4B0A5A0D.9030401@nw.neclab.eu><02fb01ca6cde$70cccd10$420ca40a@china.huawei.com><4B0BC1CF.1050101@nw.neclab.eu><005401ca6dab$629e09c0$420ca40a@china.huawei.com><5F09D220B62F794 " " 18461A978CA0921BD03B40328@pslexc01.psl.local> <4B0D1014.3050004@nw.neclab.eu> <5F09D220B62F79418461A978CA0921BD03B40525@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03B40525@pslexc01.psl.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2009 11:01:45.0220 (UTC) FILETIME=[D7B6C440:01CA6E87] Cc: netext@ietf.org Subject: Re: [netext] multi-LMA : how to handle X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:02:13 -0000 Hi Mohana, please see in-line. Mohana Jeyatharan wrote: > Hi Marco, > > Thanks for reply. Please see some replies in-line. > > BR, > Mohana > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> > Behalf > >> Of Marco Liebsch >> Sent: Wednesday, November 25, 2009 7:08 PM >> To: Mohana Jeyatharan >> Cc: netext@ietf.org >> Subject: Re: [netext] multi-LMA : how to handle >> >> Hi Mohana, >> >> please see in-line for my answer to your question. >> >> Mohana Jeyatharan wrote: >> >>> Hi Qin, Marco and all, >>> >>> Have been following the thread and I have one clarifying question. >>> In the multi LMA scenario that is being discussed, is CN.LMA >>> > involved > >>> during every handoff event in identifying the CN.MAG address and >>> informing to Mn's MAG? >>> >>> >> Without pointing to a particular solution but arguing more general, I >> think >> the LMAs should be involved and have mayor control in setting up as >> well as in maintaining the localized routing states on the MAG, as >> > they > >> are the only common nodes (common on a per MN basis) which have the >> most up to date location information about the MN and the CN >> > respectively. > >> This is LMA1 for MN and LMA2 for CN. >> > > [Mohana] I agree that setting up routing states, LMA has important role. > But I am not so convinced about the involvement of LMA in maintaining > routing states (handoff case). Bcos after local MAG RO is set up, > packets don't pass through LMA and local mechanims such CTX can be used > to handle RO. Ofcourse if CTX is not used for some reason(operator > choice) then perhaps LMA control even during handoff (as you propose) > can be used. Another point is LMA need not unnecessarily keep state for > local MAG RO. If MN MAG and CN MAG are quite close, then involving LMA > which can even be in another administrative domain can delay the local > MAG path setup especially when you have on going session as in the > handoff case. Anyway, I am not saying that LMA involvement should not > be there. It all depends. > I don't think CTX solves all problems, as for example during MN's handover, CTX may transfer outdated context of CN's location if CN hands over we well. This may end up in MN's new MAG then contacts CN's previous MAG. I see the use of CTX as optional, if needed at all. I do not think that the protocol solution should depend on CTX. > Another scenario is where MN LMA and CN LMA do not have trust. Then what > mechanism can be used to set up localized routing? I guess currently > such scenario is out of scope of the discussion. > > >>> If AAA is used as a common trusted entity in identfying CN.LMA >>> > address > >>> and also helping in creating SA between Mn'MAG and CN'LMA, I am just >>> wondering whether AAA can be used to tell MN's MAG that it owns this >>> prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and >>> when bi-directional tunnels are setup between MAG using PBU/PBA such >>> validation fron AAA can be used to create the routing states at MN's >>> > MAG > >>> and CN's MAG. Bcos in the multi LMA scenario, AAA will perhaps be >>> > the > >>> common trusted entity. >>> >>> >> I do not think that the AAA should be used as mobility anchor, even >> > though > >> the AAA might have information about mobility related states. For >> > sure, > >> he'll have >> information about each MN's assigned LMA. So, I think the AAA *could* >> be used to find the MN's and the CN's LMA once during the setup of a >> localized routing path. After the setup, LMA1 and LMA2 should be >> > known. > >> And I do not think that the localized routing solution should be >> dependent on the AAA server, hence the solution should work without >> any AAA infrastructure at all. >> > > [Mohana] Ok. Since AAA was discussed I was thinking more along this > line. If LMA1 (MN LMA)and LMA2 (CN LMA) have trust then no need of a > common trusted anchor. But if they are not then was wondering whether > we need a common trusted anchor to securly establish local MAG RO. > Perhaps we can keep the scenario where there is loose trust between LMAs > out of discussion for now as I mentioned previously. > I thought about the AAA in a different context, which is a common entity or infrastructure to maintain MN-LMA bindings. This helps LMAs to find each other. Such function is needed also for two LMAs which share a trust relationship. Just as example: LMA1 has only a registration for MN, but needs to find CN's LMA. On request of LMA1, the AAA infrastructure could resolve CN's assigned IP address into CN's LMA, which is LMA2. > >>> Just wondering whethe r CN.LMA needs to be involved during handoff >>> process or CTX and such prefix validation from a common trusted >>> > entity > >>> (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG >>> > RO > >>> path. If LMA is configured as the initiator of MAG to MAG RO, then >>> MN.MAG and CN.LMA association may be needed but if MAG is the >>> > initiator > >>> of RO then perhaps this can be avoided in the handoff case. >>> >>> >> both LMAs should be involved as they do not change and they have the >> most recent location information. However, as we propose, even though >> both LMAs are involved in the signaling, one LMA should have the >> control (e.g. LMA2). Then the maintenance during handover cannot run >> into a deadlock situation and the solution does not need the AAA >> > server > >> as common anchor. >> >>> Also I have few general opinions on MAG initiated RO or LMA >>> > initiated > >>> RO. >>> Definitely as folks have discussed and identified, LMA is definitely >>> used in detection of CN.MAG and aid in establishing RO, but MAG can >>> > be > >>> initiator of local MAG RO eventhough MN and CN are not attached to >>> > the > >>> same MAG. Perhaps the MAG is informed of CN addresses by MN using >>> > some > >>> L2 mechanism and hence it can initiate RO for a bunch of CNs >>> simultaneously. >>> >> I don't think you need L2 here, as a data packet from MN to CN, which >> is forwarded by the MN's MAG, carries the CN's IP address. >> Or did I misunderstand your proposal? >> >> >>> Thus LMA need not wait for session to be started >>> between every MN and each CN to establish the RO. >>> >>> >> Ah, maybe now I get your point. You propose to set up a localized >> routing path between the MN and a set of potential CNs before >> data will be sent, right? >> > > [Mohana] Yes. > > I think an important question to answer here > >> is how long localized routing states will be kept alive? Our current >> > view > >> (and implementation) sets localized routing states up when the're >> > needed > >> (when data is sent). They are removed when a session terminates, say >> after a timeout in case no further data packets reset the timer. These >> states are rather soft-states. >> > > [Mohana] My thinking was to setup states if the MAG thinks that > communication with certain CNs need to be optimized. Based on > application or the type of service domain in which CN is placed the MAG > may initiate such local rotuing request. Ofcourse once the session is > complete the local MAG RO can be torn down. Suppose you are frequently > communicating with such CNs then local MAG RO states can be kept for a > long time. > I see. This assumes a lot of intelligence at the MAG, but may be useful. > If you set them up before there is data, > >> I am wondering when you delete them again? And how should the >> MN decide if a localized route to CN1, CN2, etc makes sense? Their >> location is transparent to the MN. >> > > [Mohana] are you refering to CNs placed in another provider domain with > repect to MN. In such a case, probably localized routing is not > essential. no, I tried to understand your proposal with L2 signaling. My understanding of your proposal was that the MN signals via L2 to the MAG info about CNs for which the MN would like to have a localized route set up. My comment was about the MN, which actually does not know anything about the CNs' location, hence cannot take a decision if localized routing is useful or even works. > MN's MAG does not know anything about where CN is. It just > wants RO based on some information given to CN. In such a case LMA > needs to assist. Anyway as all of us have agreed LMA definitely needs > to play its role in supporting local MAG RO. > Ok. Thanks and best regards, marco > Thanks. > What do you think? > >> marco >> >> >> >> >>> Thanks. >>> >>> BR, >>> Mohana >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>> >>>> >>> Behalf >>> >>> >>>> Of Qin Wu >>>> Sent: Wednesday, November 25, 2009 4:44 PM >>>> To: Marco Liebsch >>>> Cc: netext@ietf.org >>>> Subject: Re: [netext] multi-LMA : how to handle >>>> >>>> Hi, Marco: >>>> please see my comments inline. >>>> >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Marco Liebsch" >>>> To: "Qin Wu" >>>> Cc: >>>> Sent: Tuesday, November 24, 2009 7:21 PM >>>> Subject: Re: [netext] multi-LMA : how to handle >>>> >>>> >>>> >>>> >>>>> Hi Qin, >>>>> >>>>> please see inline for brief comments. >>>>> >>>>> Qin Wu wrote: >>>>> >>>>> >>>>>> Hi, Marco: >>>>>> Thank for your reply, please see my comments inline. >>>>>> >>>>>> Regards! >>>>>> -Qin >>>>>> ----- Original Message ----- >>>>>> From: "Marco Liebsch" >>>>>> To: "Qin Wu" >>>>>> Cc: >>>>>> Sent: Monday, November 23, 2009 5:46 PM >>>>>> Subject: Re: [netext] multi-LMA : how to handle >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Qin, >>>>>>> >>>>>>> please find my comments inline. >>>>>>> >>>>>>> Qin Wu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, Marco: >>>>>>>> Thank for your raising discussion on Multi-LMA issue. >>>>>>>> Please see my comments inline! >>>>>>>> >>>>>>>> Regards! >>>>>>>> -Qin >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Marco Liebsch" >>>>>>>> To: >>>>>>>> Sent: Friday, November 20, 2009 5:44 PM >>>>>>>> Subject: [netext] multi-LMA : how to handle >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> as a follow up of our discussion about localized routing in a >>>>>>>>> multi-LMA setup, I'd like to initiate a general and clarifying >>>>>>>>> discussion about signaling paths to set up and maintain a >>>>>>>>> localized routing path, as current solution proposals cover >>>>>>>>> different approaches. >>>>>>>>> >>>>>>>>> We had the discussion about PMIPv6 domains vs provider domains >>>>>>>>> and came to the conclusion that it's not mandatory for MN and >>>>>>>>> > CN > >>>>>>>>> to share the same PMIPv6 domain. >>>>>>>>> >>>>>>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects >>>>>>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1 >>>>>>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume >>>>>>>>> that MAG1 shares a PMIP domain with LMA2. >>>>>>>>> >>>>>>>>> Now, there are two questions to solve: >>>>>>>>> (1) Who detects and initiates localized routing, MAG or LMA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> [Qin]: I think Both have its value and are applicable to >>>>>>>> >>>>>>>> >>> different >>> >>> >>>> scenarios. Whether using MAG initiated or using LMA initiated >>>> > depends > >>> on >>> >>> >>>>>>>> who detects localized routing, in other words, if MAG detects >>>>>>>> >>>>>>>> >>> local >>> >>> >>>> routing is possible, then MAG initiated is more appropriate. >>>> >>>> >>>>>>>> e.g., As described in RFC5213, in the scenario where MN and CN >>>>>>>> >>>>>>>> >>> attach >>> >>> >>>> to the same MAG, MAG initiated local routing can >>>> >>>> >>>>>>>> be used to negotiate with LMA and enfoce local routing on the >>>>>>>> >>>>>>>> >>> MAG. >>> >>> >>>>>>> Only in single MAG case it may make sense that the MAG detects >>>>>>> > and > >>>>>>> establishes >>>>>>> a localized route. However, even in such case, the LMA must >>>>>>> >>>>>>> >>>> control/enforce >>>> >>>> >>>>>>> the setup of the localized route as per RFC5213. So, the LMA >>>>>>> is the point of control and my personal opinion is that this is >>>>>>> reasonable, as the >>>>>>> LMA maintains states beyond a single MAG. And, dependent on the >>>>>>> >>>>>>> >>>> mechanism >>>> >>>> >>>>>>> behind HNP assignment (address pools, delegation, ...), the LMA >>>>>>> >>>>>>> >>> may >>> >>> >>>> know if >>>> >>>> >>>>>>> the setup of a localized route is useful (in case CN is local) >>>>>>> > or > >>> not. >>> >>> >>>>>> [Qin]: Right, single MAG case is more appropirate to apply MAG >>>>>> >>>>>> >>>> initiated local routing. Also single MAG case can be divided into >>>> > two > >>> sub >>> >>> >>>> cases: i.e.,A11 and A12 described in the PS draft. These two sub >>>> > cases > >>>> should be taken care in the solution draft. >>>> >>>> >>>>>> On the other hand, I agree LMA control the setup of localized >>>>>> >>>>>> >>> routing, >>> >>> >>>> but it seems to me who initiate localized routing does not depend >>>> > on > >>> who >>> >>> >>>> control the setup of the localized route. In the MAG initiate >>>> >>>> >>> localized >>> >>> >>>> routing, MAG can initiate local routing with LMA to see whether >>>> >>>> >>> localized >>> >>> >>>> routing is available. >>>> >>>> >>>>> yes, we can have 3 different ways to do this: >>>>> (1) MAG1 detects and requests LMA1 to set up localized routes >>>>> (2) MAG1 detects and requests LMA2 to set up localized routes >>>>> (3) LMA1 detects and sets up localized routes >>>>> >>>>> >>>> [Qin]: Okay. >>>> >>>> >>>>>>>> If LMA is responsible for local routing, then LMA inititated >>>>>>>> > and > >>> MAG >>> >>> >>>> initiate both can be used. >>>> >>>> >>>>>>>> e.g., in the scenario where MN and CN attach to the different >>>>>>>> >>>>>>>> >>> MAGs >>> >>> >>>> but connect to the different LMA or the same LMA. >>>> >>>> >>>>>>> Since the LMA needs to enforce localized routing in all cases, I >>>>>>> personally see the >>>>>>> LMA as detector. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: Okay. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> If for some reason the MAG may be able to detect, it should >>>>>>> inform the LMA of the attached MN to enforce localized routing. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: I agee. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> (2) How to synchronize distributed states? Will LMA1 contact >>>>>>>>> LMA2 or will MAG1 contact LMA2 >>>>>>>>> >>>>>>>>> If an existing SA is the only indicator to set up a PMIPv6 >>>>>>>>> domain, then one solution could be to set up an SA dynamically >>>>>>>>> between MAG1 and LMA2, which needs to be re-done every time >>>>>>>>> MN1 performs a handover to a different MAG, say MAG1*. This >>>>>>>>> may be a disadvantage and will blow up PMIPv6 domains, which >>>>>>>>> are rather administratively configured, in my opinion. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> [Qin]: It seems to me SA setup each time MN handover to the new >>>>>>>> >>>>>>>> >>> MAG >>> >>> >>>> is one generic issue we should face for all the Multi-LMA cases. >>>> >>>> >>>>>>>> In other words,When using LMA1 to signal with LMA2 for states >>>>>>>> >>>>>>>> >>>> synchroizing, it has the same problem. Suppose MN connect to the >>>> > LMA1, > >>>>>>>> each time the MN handover from previous MAG to the new MAG, >>>>>>>> > the > >>> new >>> >>> >>>> MAG needs to setup SA with the LMA1 dynamically again. >>>> >>>> >>>>>>> there is a big difference between localized routing associations >>>>>>> >>>>>>> >>>> between >>>> >>>> >>>>>>> MAGs >>>>>>> and handover between MAGs. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: No doubt to this. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Handover is between globally adjacent ARs/MAGs, hence, I think >>>>>>> > an > >>> LMA >>> >>> >>>>>>> maintains an SA with an MN's MAG and potential handover targets. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: How? You can not predict the direction of MN's movement, >>>>>> >>>>>> >>> i.e., >>> >>> >>>> to which MAG the MN will move. Therefore >>>> >>>> >>>>>> you can not expect there is an SA between LMA and handover >>>>>> > targets > >>>> beforehand. >>>> >>>> >>>>> well, don't confuse SA with forwarding tunnel. The SAs between MAG >>>>> >>>>> >>> and a >>> >>> >>>>> particular LMA >>>>> should be pre-established when the MN arrives, whereas the >>>>> >>>>> >>> forwarding >>> >>> >>>>> tunnel may exist >>>>> or may be set up dynamically when the MN arrives. >>>>> >>>>> >>>> [Qin]: I agree SA and forwarding tunnel are two different things. >>>> > But > >>> the >>> >>> >>>> common aspect of both is >>>> SA and forwarding tunnel for one MN can be reused by the other MN >>>> > who > >>>> arrives at the same MAG >>>> and routes the packet to the same tunnel end point, i.e., LMA. >>>> > Right? > >>>> >>>>>>> If you >>>>>>> would establish them each time a handover occurs, this would >>>>>>> > have > >>>> impact >>>> >>>> >>>>>>> to the handover latency. Don't think this is how PMIP is >>>>>>> > deployed. > >>>>>>> >>>>>> [Qin] As I said in the previous mail, the possible way to fix >>>>>> > this > >>>> issue is >>>> >>>> >>>>>> SA or tunnel setup for the first MN between MAG and LMA can be >>>>>> >>>>>> >>> shared >>> >>> >>>>>> by the other MNs who are attaching to the same MAG and register >>>>>> > to > >>> the >>> >>> >>>> same LMA as the first MN. >>>> >>>> >>>>> I understood your point, but I do not agree :-) I do not think >>>>> > that > >>> a >>> >>> >>>>> MAG should establish an SA >>>>> with any LMA dynamically when the MN arrives, in particular not >>>>> > with > >>> an >>> >>> >>>>> LMA which does not >>>>> serve the MN but the CN. >>>>> >>>>> >>>> [Qin]: It seem to me it does not matther whether SA is >>>> > pre-established > >>> or >>> >>> >>>> dynamically established. >>>> The key point is whether SA can be shared by all the MNs who are >>>> > using > >>> the >>> >>> >>>> same path between MAG and LMA. >>>> >>>> >>>> >>>>>> that is to say, the SA or tunnel between MAG and LMA is not >>>>>> > per-MN > >>> or >>> >>> >>>> per-CN and can be reused >>>> >>>> >>>>>> by all the MNs and CNs upon it is setup at the first time. >>>>>> In this sense, it avoid establishing SA each time a handover >>>>>> >>>>>> >>> occurs. >>> >>> >>>>>> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is >>>>>> >>>>>> >>> not >>> >>> >>>> neccessary to be established >>>> >>>> >>>>>> again if SA between MAG1 and LMA2 has already been setup. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Now, >>>>>>> localized routing between MN and CN could mean that MN's MAG and >>>>>>> >>>>>>> >>> CN's >>> >>> >>>>>>> MAG are pretty far apart. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin] As described in PS draft, We should limit MN's MAG and CN's >>>>>> >>>>>> >>> MAG >>> >>> >>>> within the same domain, am I right? >>>> >>>> >>>>> Even if they are in one provider domain, distance between MAGs can >>>>> >>>>> >>> be >>> >>> >>>>> huge. Multiple LMAs may >>>>> be used by the provider to distribute load and to be responsible >>>>> > for > >>> a >>> >>> >>>>> smaller region (subset of MAGs). >>>>> >>>>> >>>> [Qin]: To me, the physical distance is not big issue. The more >>>> >>>> >>> important >>> >>> >>>> thing is whether communication between MAGs is within the >>>> same provider domain or acrosss provider domain. >>>> >>>> >>>> >>>>>>> Different LMAs could serve different PMIPv6 >>>>>>> domains. I don't think it's reasonable to merge these PMIP >>>>>>> > domains > >>>>>>> dynamically by means of establishing an SA between MN's MAG and >>>>>>> CN's LMA. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: Same as above. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Rather LMAs could take care about the setup of the route >>>>>>> between these MAGs. If both LMAs are in different PMIP domains >>>>>>> but in the same provider network, such signaling is simple. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> From the other aspect, in the Multi-LMA scenario, when MAG1 >>>>>>>> > talks > >>>> with LMA2, if there is no SA between MAG1 and LMA2, we can ask >>>> >>>> >>>>>>>> LMA2 exchange with AAA server to do authorization and validate >>>>>>>> >>>>>>>> >>>> whether MAG1 can fetch CN's MAG address from LMA2. >>>> >>>> >>>>>>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right? >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address >>>>>> >>>>>> >>> from >>> >>> >>>> LMA2, LMA2 should validate the message from MN's MAG1 using AAA >>>> >>>> >>> mechanism. >>> >>> >>>>>>>> Also since SA is setup between one MAG and one LMA, upon the >>>>>>>> >>>>>>>> >>> first MN >>> >>> >>>> who is attaching to the MAG triggers this MAG to setup SA with LMA, >>>> >>>> >>>>>>>> the SA can also be used by the other MN who attach to the same >>>>>>>> >>>>>>>> >>> MAG to >>> >>> >>>> protect the data traffic between MAG and LMA Therefore the second >>>> > MN > >>> who >>> >>> >>>>>>>> is attaching to the same MAG may not setup SA again. Because >>>>>>>> > all > >>> the >>> >>> >>>> existing SA can be reused. >>>> >>>> >>>>>>>> Therefore SA setup is not a big issue, the biggest issue is: >>>>>>>> 1) who discover CN's LMA address? >>>>>>>> 2) how does he discover CN's LMA address? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> "Who?" should be the LMA, as you need to discovery only once, >>>>>>> >>>>>>> >>> whereas >>> >>> >>>>>>> if it's the MAG, each handover MAG needs to discover again, >>>>>>> > unless > >>> you >>> >>> >>>>>>> make the localized routing protocol dependent on CTX, which is >>>>>>> > not > >>>>>>> a good approach. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: For the handover case, If CTX is used with localized >>>>>> > routing > >>>> protocol, discovery is done once as well. >>>> >>>> >>>>>> But CTX is not the only way. >>>>>> Besides CTX, there is another possible way to deal with handover >>>>>> >>>>>> >>> case >>> >>> >>>> for multi-LMA. >>>> >>>> >>>>>> Since it is MN's MAG or CN's MAG who is responsible for setup >>>>>> >>>>>> >>> localized >>> >>> >>>> routing path, LMA still >>>> >>>> >>>>>> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG >>>>>> > to > >>> MN's >>> >>> >>>> MAG. >>>> >>>> >>>>>> Therefore when MN handover from MN's previous MAG to the MN's new >>>>>> >>>>>> >>> MAG, >>> >>> >>>> it is not MN's LMA but MN's new MAG who is first to know that MN's >>>> handover happen, then MN's new MAG can trigger LMA to notify CN's >>>> > MAG > >>> to >>> >>> >>>> update MN's MAG address at CN's MAG, >>>> >>>> >>>>>> then CN's MAG updates localized routing path with MN's new MAG. >>>>>> >>>>>> >>>>>> >>>>> I think the basic assumption for the solutions should be that the >>>>> >>>>> >>> MN's >>> >>> >>>>> handover >>>>> target MAG does not know more than what PMIPv6 as per RFC5213 >>>>> >>>>> >>> requires, >>> >>> >>>>> which is the LMA where to send the PBU to and does not cover any >>>>> >>>>> >>>> localized >>>> >>>> >>>>> routing information. The information and states about localized >>>>> >>>>> >>> routing >>> >>> >>>>> could be >>>>> re-established (instead of transferred) by a common anchor, which >>>>> >>>>> >>> does >>> >>> >>>> not >>>> >>>> >>>>> change: The LMA. >>>>> draft-oulai even sets up localized routing states on both MAGs >>>>> >>>>> >>> without >>> >>> >>>>> any signaling between MAGs at all. We proposed something similar >>>>> > in > >>>>> draft-abeille, which was named 'proxy mode'. Such approach has >>>>> > some > >>>>> advantages if there is no SA between MAGs. >>>>> >>>>> >>>> [Qin]: Since localized routing protocol can be used between source >>>> MAG(i.e., MN's MAG) and LMA, >>>> it also can be used between target MAG and LMA. I don't think it is >>>> > a > >>> big >>> >>> >>>> issue. >>>> Also in some case, MN's prefix and CN's prefix should be validated >>>> > to > >>>> create for valid routing between MAGs. >>>> therefore LMA can notify both MAG that MN's prefix or CN's prefix >>>> > is > >>> valid >>> >>> >>>> each time handover happens.Also LMA can tell target MAG the >>>> >>>> >>> information >>> >>> >>>> about localized routing. >>>> On the other hand, when routing path is established, target MAG >>>> > need > >>> to >>> >>> >>>> install localized routing states. This mechanism is quite similar >>>> > to > >>> the >>> >>> >>>> routing optimization between MN and CN described in RFC3775 and >>>> >>>> >>> RFC4866. >>> >>> >>>>> marco >>>>> >>>>> >>>>> >>>>> >>>>>> In this way, discovery is done only once as well. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> "How?" could be different approaches. Static solutions could be >>>>>>> >>>>>>> >>> based >>> >>> >>>> on >>>> >>>> >>>>>>> the LMA's knowledge about address/HNP pools for HNP assignment >>>>>>> to attaching MNs. Dynamic solutions could be based on a AAA >>>>>>> >>>>>>> >>>> infrastructure >>>> >>>> >>>>>>> as you referred to above. I don't think this particular "How?" >>>>>>> >>>>>>> >>> should >>> >>> >>>> be >>>> >>>> >>>>>>> addressed >>>>>>> by the localized routing solution. >>>>>>> >>>>>>> >>>>>>> >>>>>> [Qin]: I agree. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> One example is , If AAA based CN's LMA discovery can be used, >>>>>>>> > we > >>> can >>> >>> >>>> ask AAA server push the keying materails which is used to protect >>>> > the > >>>> trust relationship between MN's MAG and CN's LMA to the MN's MAG >>>> > and > >>> CN's >>> >>> >>>> LMA respectively. In this sense, the trust relationship between >>>> > MN's > >>> MAG >>> >>> >>>> and CN's LMA can be easily setup. >>>> >>>> >>>>>>>> >>>>>>>>> The other alternative is that PMIPv6 domain stractures are not >>>>>>>>> >>>>>>>>> >>>> touched >>>> >>>> >>>>>>>>> and LMA1 will signal with LMA2 to synchronize states of MN and >>>>>>>>> >>>>>>>>> >>> CN. >>> >>> >>>>>>>>> Advantage would be that LMAs do not change during a handover >>>>>>>>> > and > >>>>>>>>> will keep states on one place. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> [Qin]: if using LMA1 signaling with LMA2 for state >>>>>>>> > synchronizing, > >>> how >>> >>> >>>> does LMA1 know LMA2 address? >>>> >>>> >>>>>>> Same as MAG1 may discover LMA2, with many advantages if you do >>>>>>> >>>>>>> >>> this >>> >>> >>>> from >>>> >>>> >>>>>>> LMA1. >>>>>>> >>>>>>> marco >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Any opinions? >>>>>>>>> >>>>>>>>> marco >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> netext mailing list >>>>>>>>> netext@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>