From toby@moncaster.com Wed May 4 02:23:18 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D961E06FA for ; Wed, 4 May 2011 02:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC4n091yHmS4 for ; Wed, 4 May 2011 02:23:16 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id D9DCDE06A2 for ; Wed, 4 May 2011 02:23:15 -0700 (PDT) Received: from TobysHP (host86-136-244-185.range86-136.btcentralplus.com [86.136.244.185]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MANGk-1QT7pT06Kw-00Bfrp; Wed, 04 May 2011 11:23:13 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" References: <4D9448F9.7040309@informatik.uni-tuebingen.de> <002e01cbef88$b1cc7b70$15657250$@com> <4D94EF65.20001@informatik.uni-tuebingen.de> <4D958E90.4060103@informatik.uni-tuebingen.de> <201104011222.p31CMCas029062@bagheera.jungle.bt.co.uk> <003e01cbf074$d2042270$760c6750$@com> <000c01cbfa92$38da9750$aa8fc5f0$@com> <201104150314.p3F3E8HU001775@bagheera.jungle.bt.co.uk> <000c01cbfb47$8c8ef520$a5acdf60$@com> <4DA81828.4090002@informatik.uni-tuebingen.de> <201104151450.p3FEoiab003742@bagheera.jungle.bt.co.uk> <000901cbfc13$ee81e720$cb85b560$@com> <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> In-Reply-To: <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> Date: Wed, 4 May 2011 10:23:09 +0100 Message-ID: <000c01cc0a3c$e2c29420$a847bc60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acv8JidjJNrJ3s6YQ7W23VuGzoCftgOFYgxg Content-Language: en-gb X-Provags-ID: V02:K0:hXXj4f8nggKLrfubPObQ6AIuxKeQk0ApyJyIGM2Sbjr BxyM0EkxyHFgI9wDvgj7Ll/eAxNWCFeVCCVGbJcV/zIno/cM4G PQB1MOvZ4q9j16gZFTTRS6bwb8diZn6Gmg/F/0MBKWMhxykpGR bY//Tzkk8p7jyQ+nTni2xf4bMXf530hujzWjyqnvwcAa4pGqly 9I47yVTE2KGN0l2OGkCUFr7X2+hP9QKyd96+DIf1MM= Cc: pcn@ietf.org Subject: [PCN] Revised 3-in-1 draft and status of RFC5696 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:23:18 -0000 I'll get back to this in the next couple of days and try and release an updated draft early next week... We had more or less converged on what text to include in the new version. Meanwhile, can the working group give their views on what should happen regarding RFC5696. As I see it there are 3 options: 1) have this new RFC update it, but that leaves it as a dead document (in effect, since there will be contradictory definitions for the 01 codepoint) 2) release a bis version of RFC5696 with the EXP codepoint fixed as having to be used for carrying a PCN marking state, and with any other tweaks we think of 3) combine the two by putting in a section in this document about how to use it in single marking schemes (which will take quite a bit of wordsmithing). I personally favour option 2 as it is the cleanest and allows us to keep open the greatest range of future marking schemes. Option 1 is easy, but leaves some potential issues (for instance it will mean there is no standards support for anything similar to the PSDM scheme which Michael and others seem to still be interested in). Option 3 will take a lot of work, but would allow RFC5696 to become obsolete (so is also quite clean from a standards viewpoint). Toby > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: 16 April 2011 12:05 > To: Toby Moncaster > Cc: 'Michael Menth'; pcn@ietf.org > Subject: RE: [PCN] ECN handling with 3-in-1 > > Toby, > > At 09:54 16/04/2011, Toby Moncaster wrote: > >Bob, Michael, > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > Sent: 15 April 2011 15:51 > > > To: Michael Menth > > > Cc: Toby Moncaster; pcn@ietf.org > > > Subject: Re: [PCN] ECN handling with 3-in-1 > > > > > > Toby, Michael, > > > > > > 2/ e2e ECN appendix > > > Now that I'm awake, I've realised the wording of the headings for > the > > > four options we are discussing needs to be completely reframed. > > > > > > End nodes don't ask for PCN control, they ask for admission > control. > > > An operator chooses what mechanism to use for admission control > over > > > their segment of the path, and PCN is just one possible mechanism > > > they might choose. > > > > > > At the outset, we need to list the two main ways that end-nodes > tell > > > the network that they need admission control, which in turn makes > the > > > PCN-ingress remark their traffic with a PCN-compatible DSCP: > > > > > > A) flow signalling associates a filterspec with a need for > admission > > > control (e.g. thru RSVP or some equivalent message down from a SIP > > > server to the ingress), and the PCN ingress remarks traffic > matching > > > that filterspec to a PCN-compatible DSCP, as its chosen admission > > > control mechanism. > > > > > > B) Traffic arrives with a DSCP that implies it requires admission > > > control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, > > > Broadcast TV when used for video on demand, and Multimedia > > > Conferencing [RFC4594, RFC5865]. > > > >You need to re-read the appendix of RFC5696 where we discuss DSCP- > related > >issues. > > I did before writing that email. > > >I am very unkeen to add so much extra text to what should be a simple > >encoding document. This will end up making the appendix nearly as long > as > >the main document. I also have concerns that this sort of thing is > really > >architectural. This document isn't about telling operators which of > their > >traffic they should be doing admission control on. > > > >I would rather we just put a simple paragraph saying what you have in > your > >intro to this point: > > > >" End nodes don't ask for PCN control, they ask for admission control. > > An operator chooses what mechanism to use for admission control over > > their segment of the path, and PCN is just one possible mechanism > > they might choose." > > We need to provide some explanation for why we suddenly started > talking about these four cases. So we do need to say what we mean by > end-nodes asking for admission control. It would be nice to cite > something that explains, but we don't have anything, because RFC5865 > on DSCPs for admission contrl went through after all the PCN RFCs so > far. > > So I think we have to treat this appendix as the latest definitive > word on the two mains ways that end points might use to signal that > they want admission control, even tho it's not really relevant to > this doc. The only alternative would be to update the PCN > architecture RFC, and I don't want to go there. > > > > We need to define two phrases, such as: > > > * "Traffic that requires admission control" as traffic that uses > > > either method A or B. > > > * "Traffic that does not require admission control" as traffic that > > > uses neither of methods A or B. > > > >OK, happy to have those definitions, but we are going to find > ourselves > >tying knots as we try and talk about traffic that doesn't need > admission > >control but which shares the same DSCP... > > [snip] > > > > >>>> ECN traffic not subjected to PCN control but sharing a > PCN- > > > >>>compatible > > > >>>> DSCP: > > > >>>s/sharing a PCN-compatible DSCP/using a PCN-compatible DSCP on > > > >>>arrival at the PCN ingress/ > > > > > > On second thoughts, we should head this item > > > "ECN capable traffic that does not require admission control but > > > carries a DSCP that the PCN-ingress is using for PCN-capable > traffic." > > > > > > HOWEVER, I don't think this case is possible. If traffic arrives > with > > > a DSCP that would be used for PCN, it is signalling that it > requires > > > admission control [RFC5865]. > > > >BUT some of that traffic may in fact be automatically admitted > (because of > >policy), hence it wouldn't use PCN... > > > >My own view is this whole case needn't be mentioned because the > traffic is > >neither ECN nor PCN. If we were to list all negative cases we would > get an > >even longer appendix! > > Well, the traffic *is* ECN and it is confusable with PCN traffic. As > I just said in my mail to Michael, it would only be confusible with > PCN traffic if the PCN operator decided to use weird DSCPs for PCN. > > How about not listing this case as if it is normal, but instead > mention it as a 'footnote' to this appendix, as an abnormal case to > be avoided if possible, perhaps: > > "It is strongly RECOMMENDED that the advice in A.1 of the PCN > baseline encoding [RFC5696] is followed when choosing which DSCP > indicates PCN-compatible traffic. Otherwise nodes within the PCN > region will mistake traffic using e2e ECN for PCN-traffic if it also > happens to use the chosen DSCP. To avoid this confusion, the PCN > ingress would have to remark this traffic to another DSCP, causing > further complication and confusion downstream." > > > > > > > >>>> ECN traffic being subjected to PCN control, receiver > indicates > > > >>>desire > > > >>>> to see PCN marks: > > > > > > We should head this item > > > "Traffic that requires admission control, where the e2e transport > > > somehow indicates it wants to see PCN marks." > > > >s/"somehow indicates"/"signals that" > > If you want. > I was trying to avoid being prescriptive about how it might be done. > > >I'll try and unravel all the changes and send a revised version by > Monday... > >It won't necessarily include all the suggestions (see the inline > comment at > >the top), and there is a chance I may miss a couple! > > Yes, when I prepared the email you just replied to, I tried to pull > together everything that had been said, so I hope that posting will > be useful for you. > > Cheers > > > Bob > > > >Toby > > > > > > > > > > > > > Bob > > > > > > >>>>The > > > >>>PCN- > > > >>>> egress should not zero the ECN field, > > > >>>Don't agree. ECN should never leak into PCN, but PCN might be OK > to > > > >>>leak to ECN receiver. > > > >>I'm not allowing ECN to leak into PCN. I am (in limited > > > circumstances) > > > >>allowing the PCN-domain to over-write the ECN information and > hence > > > leak PCN > > > >>information to the receiver. > > > >> > > > >>>Reasoning: admission of a flow should only depend on PCN marking > > > >>>within the PCN region. It shouldn't depend on ECN marking from > > > queues > > > >>>outside the PCN region, which will not have been configured to > give > > > >>>good signals at the right load levels. > > > >>Oh, I think I see your point. RFC6040 tunnels will set the ECN of > the > > > outer > > > >>header to whatever is in the inner header. BUT you are forgetting > > > that the > > > >>default behaviour of the PCN-ingress is to clear whatever is in > the > > > outer > > > >>header and set it to 10 (if the traffic is PCN) or 00 (if the > traffic > > > is > > > >>not-PCN) > > > > > > > >Mentioning that would be helpful. Also we need to remember that > but > > > >often forget about it and then we wonder about the text ... > > > > > > > >Regards, > > > > > > > > Michael > > > > > > > >>>The reverse argument seems less likely to apply to leaking PCN > to > > > >>>receiver, because any decent level of PCN will usefully trigger > a > > > >>>lower rate, thus potentially avoiding the need to block > admissions. > > > >>> > > > >>>>and the tunnel egress should > > > >>>> use [RFC6040] normal mode (preserving any PCN-marking). > > > >>>There are no modes for an RFC6040 egress. Modes are only for the > > > >>>ingress. > > > >>OK, noted. I did know that really, I was being careless. > > > >> > > > >>>The important point is not what the tunnel egress does (assuming > the > > > >>>arrangement in the Fig below), but that the PCN egress doesn't > zero > > > >>>the outer ECN field. > > > >>Indeed... > > > >> > > > >>>>Note that > > > >>>> this may turn ECT(0) into ECT(1) and so is not > compatible > > > with > > > >>>the > > > >>>> experimental ECN nonce [RFC3540]. > > > >>>s/this/PCN marking on interior nodes/ > > > >>> > > > >>> > > > >>>> In the list above any form of IP-in-IP tunnel can be used > > > unless > > > >>>> specified otherwise. We assume a logical separation of > > > tunneling > > > >>>> and PCN actions in both PCN-ingress and PCN-egress nodes. > > > That > > > >>>is, > > > >>>> any tunneling action happens wholly outside the PCN-domain > as > > > >>>> illustrated in the following figure: > > > >>>> > > > >>>> > > > >>>> , . . . . PCN-domain . . . . . . > . > > > >>>> . ,--------. ,--------. > . > > > >>>> . _| PCN- |___________________| PCN- |_ > . > > > >>>> . / | ingress | | egress | \ > . > > > >>>> .| '---------' '--------' > |. > > > >>>> | . . . . . . . . . . . . . . > .| > > > >>>> ,--------. ,-- > ---- > > > --. > > > >>>> _____| Tunnel | | > > > Tunnel > > > >>>|____ > > > >>>> | Ingress | - - ECN preserved inside tunnel - - | > > > Egress | > > > >>>> '---------' '-- > ---- > > > --' > > > >>>> > > > >>>> > > > >>>> Figure 4: Separation of tunneling and PCN > actions > > > >>>>" > > > >>>nice ASCII art. > > > >>Thanks :) > > > >> > > > >>> > > > >>>>I hope this captures all the key elements from the discussion. > > > >>>> > > > >>>>I am still unsure exactly how we are proceeding with regards to > > > >>>updating > > > >>>>RFC5696. Can this document both update RFC5696 AND be dependent > on > > > it > > > >>>as > > > >>>>well? Currently I am thinking of adding the following as a > > > standalone > > > >>>>section: > > > >>>> > > > >>>>"Section N. Effect on baseline encoding > > > >>>> > > > >>>>The baseline encoding [rfc5696] specified that the 01 codepoint > was > > > >>>for use > > > >>>>in experimental schemes. It also gave guidelines for such > > > experiments. > > > >>>This > > > >>>>document updates the 01 codepoint and fixes its meaning. > > > Consequently > > > >>>this > > > >>>>document updates [rfc5696]. People wishing to use the 01 > codepoint > > > for > > > >>>>experimental schemes as described in [rfc5696] must accept the > risk > > > >>>that > > > >>>>PCN-nodes compatible with this encoding scheme may not be > > > compatible > > > >>>with > > > >>>>their experiment." > > > >>>It would be dangerous for me to respond to this now - I'm too > tired > > > >>>to think straight. But my gut feeling is that the wording should > > > lean > > > >>>more towards "updates", and less towards appearing to encourage > more > > > >>>experimentation, which would run counter to interoperability - > the > > > >>>raison d'etre of a standards body. > > > >>OK, I can probably highlight that we are not recommending people > > > start > > > >>experiments, but if they are already using the EXP codepoint for > > > anything > > > >>else they need to be aware of this clash... > > > >> > > > >>> > > > >>> > > > >>> > > > >>>>Two inline responses to Michael at the end > > > >>>One from me too... > > > >>> > > > >>> > > > >>> > > > >>>>Toby > > > >>>> > > > >>>>>-----Original Message----- > > > >>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf > > > >>>Of > > > >>>>>Toby Moncaster > > > >>>>>Sent: 01 April 2011 14:58 > > > >>>>>To: 'Bob Briscoe'; 'Michael Menth' > > > >>>>>Cc: pcn@ietf.org > > > >>>>>Subject: Re: [PCN] ECN handling with 3-in-1 > > > >>>>> > > > >>>>>I'm not sure if I captured all the changes we intend to do on > this > > > >>>>>draft: > > > >>>>> > > > >>>>>1) add Michael's text on e2e ECN (once it has become stable) > > > >>>>> > > > >>>>>2) add a brief paragraph explaining that this effectively > updates > > > >>>>>RFC5696 > > > >>>>>and that therefore anyone running experiments with that are on > > > >>>their > > > >>>>>own > > > >>>>>(which they kind of are anyway, if they are doing an > experiment!). > > > >>>>> > > > >>>>>3) clarify how to do single marking with this encoding. > > > >>>>> > > > >>>>>I now recall the real reason why I wanted to preserve baseline > > > >>>which is > > > >>>>>that > > > >>>>>this encoding has the RFC6040 dependency. > > > >>>>> > > > >>>>>Is there any mileage in exploring a bis for RFC5696? As I see > it > > > we > > > >>>are > > > >>>>>always going to have a slightly messy situation. For instance > I am > > > >>>not > > > >>>>>sure > > > >>>>>if you are allowed the circular dependency of 3-in-1 encoding > > > being > > > >>>>>dependent on RFC5696 but also updating RFC5696. > > > >>>>> > > > >>>>>Of course we could always revive the option we discussed, > where we > > > >>>>>obsolete > > > >>>>>RFC5696 and incorporate a baseline behaviour within this draft > > > >>>(which > > > >>>>>could > > > >>>>>then be called PCN encodings using a single DSCP)... > > > >>>>> > > > >>>>>Thoughts anyone? > > > >>>>> > > > >>>>>Toby > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > >>>>>>Sent: 01 April 2011 13:22 > > > >>>>>>To: Michael Menth > > > >>>>>>Cc: Toby Moncaster; pcn@ietf.org > > > >>>>>>Subject: Re: [PCN] ECN handling with 3-in-1 > > > >>>>>> > > > >>>>>>Michael, > > > >>>>>> > > > >>>>>>At 09:36 01/04/2011, Michael Menth wrote: > > > >>>>>>>Hi all, > > > >>>>>>> > > > >>>>>>>to quickly see that the case analysis is complete, I suggest > a > > > >>>>>>>slight rewording: > > > >>>>>>> > > > >>>>>>>Handling of ECN traffic > > > >>>>>>>* ECN traffic not being subject to PCN control and not > sharing a > > > >>>>>>>PCN-compatible DSCP > > > >>>>>>> - no action needed > > > >>>>>>>* ECN traffic not being subject to PCN control and sharing a > > > >>>>>>>PCN-compatible DSCP > > > >>>>>>> - ingress tunnels that traffic with an non-PCN- > compatible > > > >>>DSCP > > > >>>>>>>in the outer header (any tunnel may be used) > > > >>>>>>> - alternative: ingress maps the DSCP to a local DSCP > and > > > >>>egress > > > >>>>>>>re-maps it to the original PCN-compatible DSCP > > > >>>>>>> - alternative: ingress tunnels that traffic with not- > PCN > > > in > > > >>>the > > > >>>>>>>outer header (any tunnel may be used); note that this turns > of > > > >>>ECN > > > >>>>>>>for this traffic within the PCN domain. > > > >>>>>>We ought to recommend one: > > > >>>>>>#2 does nothing wrong, whereas the others do, to a certain > > > >>>extent. > > > >>>>>>THe only reason for using #3 would be if you are short of > DSCPs > > > >>>(e.g. > > > >>>>>>MPLS or Ethernet). > > > >>>>>>#1 changes the PHB, whereas #2 doesn't and is otherwise the > same. > > > >>>So > > > >>>>>>#1 can be chucked. > > > >>>>>> > > > >>>>>>>* ECN traffic being subject to PCN control > > > >>>>>>> - ingress drops CE-marked packets and egress zeros ECN > > > >>>field of > > > >>>>>>>PCN packets which disables end-to-end ECN > > > >>>>>>Not recommended > > > >>>>>> > > > >>>>>>> - alternative: ingress tunnels that traffic with a > > > >>>>>>>PCN-compatible DSCP in the outer header and the egress zeros > > > >>>>>>>ECN-field before decapsulation (any tunnel may be used) > > > >>>>>>recommended > > > >>>>>> > > > >>>>>>>* ECN traffic being subject to PCN control, and the receiver > has > > > >>>>>>>indicated to receive PCN marks > > > >>>>>>> - ingress tunnels that traffic with a PCN-compatible > DSCP > > > >>>but > > > >>>>>>>the egress SHOULD NOT zero the ECN field before > decapsulation > > > >>>>>>>according to RFC6040 normal mode; note that this may turn > > > >>>ECT(0) > > > >>>>>>>into ECT(1) so that the nonce is modified. > > > >>>>>>Good point. > > > >>>>>>This needs to be clearly flagged as an experimental only > scheme. > > > >>>>>> > > > >>>>>> > > > >>>>>>>Another two questions > > > >>>>>>>* Traffic may arrive with a non-PCN-compatible DSCP and is > > > >>>subject > > > >>>>>>>to PCN control. Do we care about the original DSCP? This > seems > > > >>>to be > > > >>>>>>>a similar issue. > > > >>>>>>Similar to what? > > > >>>>What Michael means is, if an operator chooses to change the > DSCP of > > > an > > > >>>>arriving packet in order to enable PCN for that packet, should > that > > > >>>change > > > >>>>be reversed on leaving the PCN domain? This is starting to get > > > rather > > > >>>>obscure. Appendix A.1 of RFC5696 discusses the choice of > suitable > > > >>>DSCPs for > > > >>>>PCN and makes it clear that operators should choose to use an > > > existing > > > >>>DSCP > > > >>>>providing suitable scheduling and priority. However, if an > operator > > > >>>chooses > > > >>>>to define a local DSCP instead then they are free to do so. If > I > > > >>>recall > > > >>>>right, DSCPs are not guaranteed to survive between domains > > > anyway... > > > >>>> > > > >>>> > > > >>>>>>>* How is the ECN-field of traffic with a PCN-compatible DSCP > > > >>>>>>>interpreted outside a PCN domain? I guess with ECN > semantics? > > > >>>Have > > > >>>>>>>we stated that somewhere. Do we need to state it? > > > >>>>>>Dunno whether we've said this somewhere. Will need to check. > > > >>>>Is this at all relevant to PCN? I would argue we don't need to > > > state > > > >>>this > > > >>>>anywhere at all since PCN semantics only apply inside a PCN- > domain. > > > IN > > > >>>>appendix A.1 of RFC5696 we make it clear that PCN is a marking > > > >>>behaviour for > > > >>>>use within the PCN-domain and discuss DSCP-related issues > > > >>>Given we are talking about e2e ECN support across a PCN domain, > it > > > >>>would do no harm to reinforce the idea that a DSCP cannot even > be > > > >>>considered PCN-compatible when it is outside a PCN domain - it > has > > > >>>its usual scheulding PHB, but its congestion marking behaviour > is > > > the > > > >>>ECN default, not PCN. > > > >>Would adding the following (in a suitable place) suffice?: > > > >> > > > >>"PCN is in effect a congestion marking behaviour for use with > > > realtime > > > >>traffic in a controlled domain. As such, within the PCN-domain, > PCN > > > marking > > > >>replaces ECN marking for any PCN-enabled DSCPs. Outside the PCN- > > > domain, ECN > > > >>remains the default behaviour for all DSCPs." > > > >> > > > >>Toby > > > >> > > > >>> > > > >>>Bob > > > >>> > > > >>> > > > >>> > > > >>>>>> > > > >>>>>>Bob > > > >>>>>> > > > >>>>>> > > > >>>>>>>Best wishes, > > > >>>>>>> > > > >>>>>>> Michael > > > >>>>>>> > > > >>>>>>>-- > > > >>>>>>>Prof. Dr. habil. Michael Menth > > > >>>>>>>University of Tuebingen > > > >>>>>>>Faculty of Science > > > >>>>>>>Department of Computer Science > > > >>>>>>>Chair of Communication Networks > > > >>>>>>>Sand 13, 72076 Tuebingen, Germany > > > >>>>>>>phone: (+49)-7071/29-70505 > > > >>>>>>>fax: (+49)-7071/29-5220 > > > >>>>>>>mailto:menth@uni-tuebingen.de > > > >>>>>>>http://www-kn.informatik.uni-tuebingen.de > > > > >>>>>>________________________________________________________________ > > > >>>>>>Bob Briscoe, BT Innovate& > Design > > > >>>>>_______________________________________________ > > > >>>>>PCN mailing list > > > >>>>>PCN@ietf.org > > > >>>>>https://www.ietf.org/mailman/listinfo/pcn > > > >>>________________________________________________________________ > > > >>>Bob Briscoe, BT Innovate& Design > > > > > > > >-- > > > >Prof. Dr. habil. Michael Menth > > > >University of Tuebingen > > > >Faculty of Science > > > >Department of Computer Science > > > >Chair of Communication Networks > > > >Sand 13, 72076 Tuebingen, Germany > > > >phone: (+49)-7071/29-70505 > > > >fax: (+49)-7071/29-5220 > > > >mailto:menth@uni-tuebingen.de > > > >http://www-kn.informatik.uni-tuebingen.de > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Wed May 4 07:13:33 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3128E0728 for ; Wed, 4 May 2011 07:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g26bb8bRqhkj for ; Wed, 4 May 2011 07:13:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 82765E06C7 for ; Wed, 4 May 2011 07:13:30 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 4 May 2011 15:13:30 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.135]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 4 May 2011 15:13:28 +0100 From: To: , Date: Wed, 4 May 2011 15:13:27 +0100 Thread-Topic: [PCN] Revised 3-in-1 draft and status of RFC5696 Thread-Index: Acv8JidjJNrJ3s6YQ7W23VuGzoCftgOFYgxgAAo0HVA= Message-ID: <9510D26531EF184D9017DF24659BB87F32A9301EB3@EMV65-UKRD.domain1.systemhost.net> References: <4D9448F9.7040309@informatik.uni-tuebingen.de> <002e01cbef88$b1cc7b70$15657250$@com> <4D94EF65.20001@informatik.uni-tuebingen.de> <4D958E90.4060103@informatik.uni-tuebingen.de> <201104011222.p31CMCas029062@bagheera.jungle.bt.co.uk> <003e01cbf074$d2042270$760c6750$@com> <000c01cbfa92$38da9750$aa8fc5f0$@com> <201104150314.p3F3E8HU001775@bagheera.jungle.bt.co.uk> <000c01cbfb47$8c8ef520$a5acdf60$@com> <4DA81828.4090002@informatik.uni-tuebingen.de> <201104151450.p3FEoiab003742@bagheera.jungle.bt.co.uk> <000901cbfc13$ee81e720$cb85b560$@com> <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> <000c01cc0a3c$e2c29420$a847bc60$@com> In-Reply-To: <000c01cc0a3c$e2c29420$a847bc60$@com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 14:13:33 -0000 Toby Sorry, i didnt follow all the previous thread. I know there was some discus= sion on somewhat peripheral issues (from an encoding perspective - as in em= ails below). However, I cannot remember the conclusion on the substantial issue, ie what= encoding or encodings we want to end up as standardised. Is it:- +--------+----------------------------------------------------+ | | Codepoint in ECN field of IP header | | DSCP | | | +--------------+-------------+-------------+---------+ | | 00 | 10 | 01 | 11 | +--------+--------------+-------------+-------------+---------+ | DSCP n | Not-PCN | NM | ThM | ETM | +--------+--------------+-------------+-------------+---------+ Or, in the case of single marking: +--------+----------------------------------------------------+ | | Codepoint in ECN field of IP header | | DSCP | | | +--------------+-------------+-------------+---------+ | | 00 | 10 | 01 | 11 | +--------+--------------+-------------+-------------+---------+ | DSCP n | Not-PCN | NM | illegal | PM | +--------+--------------+-------------+-------------+---------+ Note that 01 =3D EXP doesn't appear. Is this correct? Thanks phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby = Moncaster Sent: 04 May 2011 10:23 To: Briscoe,RJ,Bob,DES8 R Cc: pcn@ietf.org Subject: [PCN] Revised 3-in-1 draft and status of RFC5696 I'll get back to this in the next couple of days and try and release an updated draft early next week... We had more or less converged on what text to include in the new version. Meanwhile, can the working group give their views on what should happen regarding RFC5696. As I see it there are 3 options: 1) have this new RFC update it, but that leaves it as a dead document (in effect, since there will be contradictory definitions for the 01 codepoint) 2) release a bis version of RFC5696 with the EXP codepoint fixed as having to be used for carrying a PCN marking state, and with any other tweaks we think of 3) combine the two by putting in a section in this document about how to us= e it in single marking schemes (which will take quite a bit of wordsmithing). I personally favour option 2 as it is the cleanest and allows us to keep open the greatest range of future marking schemes. Option 1 is easy, but leaves some potential issues (for instance it will mean there is no standards support for anything similar to the PSDM scheme which Michael and others seem to still be interested in). Option 3 will take a lot of work, but would allow RFC5696 to become obsolete (so is also quite clean from a standards viewpoint). Toby > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: 16 April 2011 12:05 > To: Toby Moncaster > Cc: 'Michael Menth'; pcn@ietf.org > Subject: RE: [PCN] ECN handling with 3-in-1 > > Toby, > > At 09:54 16/04/2011, Toby Moncaster wrote: > >Bob, Michael, > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > Sent: 15 April 2011 15:51 > > > To: Michael Menth > > > Cc: Toby Moncaster; pcn@ietf.org > > > Subject: Re: [PCN] ECN handling with 3-in-1 > > > > > > Toby, Michael, > > > > > > 2/ e2e ECN appendix > > > Now that I'm awake, I've realised the wording of the headings for > the > > > four options we are discussing needs to be completely reframed. > > > > > > End nodes don't ask for PCN control, they ask for admission > control. > > > An operator chooses what mechanism to use for admission control > over > > > their segment of the path, and PCN is just one possible mechanism > > > they might choose. > > > > > > At the outset, we need to list the two main ways that end-nodes > tell > > > the network that they need admission control, which in turn makes > the > > > PCN-ingress remark their traffic with a PCN-compatible DSCP: > > > > > > A) flow signalling associates a filterspec with a need for > admission > > > control (e.g. thru RSVP or some equivalent message down from a SIP > > > server to the ingress), and the PCN ingress remarks traffic > matching > > > that filterspec to a PCN-compatible DSCP, as its chosen admission > > > control mechanism. > > > > > > B) Traffic arrives with a DSCP that implies it requires admission > > > control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, > > > Broadcast TV when used for video on demand, and Multimedia > > > Conferencing [RFC4594, RFC5865]. > > > >You need to re-read the appendix of RFC5696 where we discuss DSCP- > related > >issues. > > I did before writing that email. > > >I am very unkeen to add so much extra text to what should be a simple > >encoding document. This will end up making the appendix nearly as long > as > >the main document. I also have concerns that this sort of thing is > really > >architectural. This document isn't about telling operators which of > their > >traffic they should be doing admission control on. > > > >I would rather we just put a simple paragraph saying what you have in > your > >intro to this point: > > > >" End nodes don't ask for PCN control, they ask for admission control. > > An operator chooses what mechanism to use for admission control over > > their segment of the path, and PCN is just one possible mechanism > > they might choose." > > We need to provide some explanation for why we suddenly started > talking about these four cases. So we do need to say what we mean by > end-nodes asking for admission control. It would be nice to cite > something that explains, but we don't have anything, because RFC5865 > on DSCPs for admission contrl went through after all the PCN RFCs so > far. > > So I think we have to treat this appendix as the latest definitive > word on the two mains ways that end points might use to signal that > they want admission control, even tho it's not really relevant to > this doc. The only alternative would be to update the PCN > architecture RFC, and I don't want to go there. > > > > We need to define two phrases, such as: > > > * "Traffic that requires admission control" as traffic that uses > > > either method A or B. > > > * "Traffic that does not require admission control" as traffic that > > > uses neither of methods A or B. > > > >OK, happy to have those definitions, but we are going to find > ourselves > >tying knots as we try and talk about traffic that doesn't need > admission > >control but which shares the same DSCP... > > [snip] > > > > >>>> ECN traffic not subjected to PCN control but sharing a > PCN- > > > >>>compatible > > > >>>> DSCP: > > > >>>s/sharing a PCN-compatible DSCP/using a PCN-compatible DSCP on > > > >>>arrival at the PCN ingress/ > > > > > > On second thoughts, we should head this item > > > "ECN capable traffic that does not require admission control but > > > carries a DSCP that the PCN-ingress is using for PCN-capable > traffic." > > > > > > HOWEVER, I don't think this case is possible. If traffic arrives > with > > > a DSCP that would be used for PCN, it is signalling that it > requires > > > admission control [RFC5865]. > > > >BUT some of that traffic may in fact be automatically admitted > (because of > >policy), hence it wouldn't use PCN... > > > >My own view is this whole case needn't be mentioned because the > traffic is > >neither ECN nor PCN. If we were to list all negative cases we would > get an > >even longer appendix! > > Well, the traffic *is* ECN and it is confusable with PCN traffic. As > I just said in my mail to Michael, it would only be confusible with > PCN traffic if the PCN operator decided to use weird DSCPs for PCN. > > How about not listing this case as if it is normal, but instead > mention it as a 'footnote' to this appendix, as an abnormal case to > be avoided if possible, perhaps: > > "It is strongly RECOMMENDED that the advice in A.1 of the PCN > baseline encoding [RFC5696] is followed when choosing which DSCP > indicates PCN-compatible traffic. Otherwise nodes within the PCN > region will mistake traffic using e2e ECN for PCN-traffic if it also > happens to use the chosen DSCP. To avoid this confusion, the PCN > ingress would have to remark this traffic to another DSCP, causing > further complication and confusion downstream." > > > > > > > >>>> ECN traffic being subjected to PCN control, receiver > indicates > > > >>>desire > > > >>>> to see PCN marks: > > > > > > We should head this item > > > "Traffic that requires admission control, where the e2e transport > > > somehow indicates it wants to see PCN marks." > > > >s/"somehow indicates"/"signals that" > > If you want. > I was trying to avoid being prescriptive about how it might be done. > > >I'll try and unravel all the changes and send a revised version by > Monday... > >It won't necessarily include all the suggestions (see the inline > comment at > >the top), and there is a chance I may miss a couple! > > Yes, when I prepared the email you just replied to, I tried to pull > together everything that had been said, so I hope that posting will > be useful for you. > > Cheers > > > Bob > > > >Toby > > > > > > > > > > > > > Bob > > > > > > >>>>The > > > >>>PCN- > > > >>>> egress should not zero the ECN field, > > > >>>Don't agree. ECN should never leak into PCN, but PCN might be OK > to > > > >>>leak to ECN receiver. > > > >>I'm not allowing ECN to leak into PCN. I am (in limited > > > circumstances) > > > >>allowing the PCN-domain to over-write the ECN information and > hence > > > leak PCN > > > >>information to the receiver. > > > >> > > > >>>Reasoning: admission of a flow should only depend on PCN marking > > > >>>within the PCN region. It shouldn't depend on ECN marking from > > > queues > > > >>>outside the PCN region, which will not have been configured to > give > > > >>>good signals at the right load levels. > > > >>Oh, I think I see your point. RFC6040 tunnels will set the ECN of > the > > > outer > > > >>header to whatever is in the inner header. BUT you are forgetting > > > that the > > > >>default behaviour of the PCN-ingress is to clear whatever is in > the > > > outer > > > >>header and set it to 10 (if the traffic is PCN) or 00 (if the > traffic > > > is > > > >>not-PCN) > > > > > > > >Mentioning that would be helpful. Also we need to remember that > but > > > >often forget about it and then we wonder about the text ... > > > > > > > >Regards, > > > > > > > > Michael > > > > > > > >>>The reverse argument seems less likely to apply to leaking PCN > to > > > >>>receiver, because any decent level of PCN will usefully trigger > a > > > >>>lower rate, thus potentially avoiding the need to block > admissions. > > > >>> > > > >>>>and the tunnel egress should > > > >>>> use [RFC6040] normal mode (preserving any PCN-marking). > > > >>>There are no modes for an RFC6040 egress. Modes are only for the > > > >>>ingress. > > > >>OK, noted. I did know that really, I was being careless. > > > >> > > > >>>The important point is not what the tunnel egress does (assuming > the > > > >>>arrangement in the Fig below), but that the PCN egress doesn't > zero > > > >>>the outer ECN field. > > > >>Indeed... > > > >> > > > >>>>Note that > > > >>>> this may turn ECT(0) into ECT(1) and so is not > compatible > > > with > > > >>>the > > > >>>> experimental ECN nonce [RFC3540]. > > > >>>s/this/PCN marking on interior nodes/ > > > >>> > > > >>> > > > >>>> In the list above any form of IP-in-IP tunnel can be used > > > unless > > > >>>> specified otherwise. We assume a logical separation of > > > tunneling > > > >>>> and PCN actions in both PCN-ingress and PCN-egress nodes. > > > That > > > >>>is, > > > >>>> any tunneling action happens wholly outside the PCN-domain > as > > > >>>> illustrated in the following figure: > > > >>>> > > > >>>> > > > >>>> , . . . . PCN-domain . . . . . . > . > > > >>>> . ,--------. ,--------. > . > > > >>>> . _| PCN- |___________________| PCN- |_ > . > > > >>>> . / | ingress | | egress | \ > . > > > >>>> .| '---------' '--------' > |. > > > >>>> | . . . . . . . . . . . . . . > .| > > > >>>> ,--------. ,-- > ---- > > > --. > > > >>>> _____| Tunnel | | > > > Tunnel > > > >>>|____ > > > >>>> | Ingress | - - ECN preserved inside tunnel - - | > > > Egress | > > > >>>> '---------' '-- > ---- > > > --' > > > >>>> > > > >>>> > > > >>>> Figure 4: Separation of tunneling and PCN > actions > > > >>>>" > > > >>>nice ASCII art. > > > >>Thanks :) > > > >> > > > >>> > > > >>>>I hope this captures all the key elements from the discussion. > > > >>>> > > > >>>>I am still unsure exactly how we are proceeding with regards to > > > >>>updating > > > >>>>RFC5696. Can this document both update RFC5696 AND be dependent > on > > > it > > > >>>as > > > >>>>well? Currently I am thinking of adding the following as a > > > standalone > > > >>>>section: > > > >>>> > > > >>>>"Section N. Effect on baseline encoding > > > >>>> > > > >>>>The baseline encoding [rfc5696] specified that the 01 codepoint > was > > > >>>for use > > > >>>>in experimental schemes. It also gave guidelines for such > > > experiments. > > > >>>This > > > >>>>document updates the 01 codepoint and fixes its meaning. > > > Consequently > > > >>>this > > > >>>>document updates [rfc5696]. People wishing to use the 01 > codepoint > > > for > > > >>>>experimental schemes as described in [rfc5696] must accept the > risk > > > >>>that > > > >>>>PCN-nodes compatible with this encoding scheme may not be > > > compatible > > > >>>with > > > >>>>their experiment." > > > >>>It would be dangerous for me to respond to this now - I'm too > tired > > > >>>to think straight. But my gut feeling is that the wording should > > > lean > > > >>>more towards "updates", and less towards appearing to encourage > more > > > >>>experimentation, which would run counter to interoperability - > the > > > >>>raison d'etre of a standards body. > > > >>OK, I can probably highlight that we are not recommending people > > > start > > > >>experiments, but if they are already using the EXP codepoint for > > > anything > > > >>else they need to be aware of this clash... > > > >> > > > >>> > > > >>> > > > >>> > > > >>>>Two inline responses to Michael at the end > > > >>>One from me too... > > > >>> > > > >>> > > > >>> > > > >>>>Toby > > > >>>> > > > >>>>>-----Original Message----- > > > >>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf > > > >>>Of > > > >>>>>Toby Moncaster > > > >>>>>Sent: 01 April 2011 14:58 > > > >>>>>To: 'Bob Briscoe'; 'Michael Menth' > > > >>>>>Cc: pcn@ietf.org > > > >>>>>Subject: Re: [PCN] ECN handling with 3-in-1 > > > >>>>> > > > >>>>>I'm not sure if I captured all the changes we intend to do on > this > > > >>>>>draft: > > > >>>>> > > > >>>>>1) add Michael's text on e2e ECN (once it has become stable) > > > >>>>> > > > >>>>>2) add a brief paragraph explaining that this effectively > updates > > > >>>>>RFC5696 > > > >>>>>and that therefore anyone running experiments with that are on > > > >>>their > > > >>>>>own > > > >>>>>(which they kind of are anyway, if they are doing an > experiment!). > > > >>>>> > > > >>>>>3) clarify how to do single marking with this encoding. > > > >>>>> > > > >>>>>I now recall the real reason why I wanted to preserve baseline > > > >>>which is > > > >>>>>that > > > >>>>>this encoding has the RFC6040 dependency. > > > >>>>> > > > >>>>>Is there any mileage in exploring a bis for RFC5696? As I see > it > > > we > > > >>>are > > > >>>>>always going to have a slightly messy situation. For instance > I am > > > >>>not > > > >>>>>sure > > > >>>>>if you are allowed the circular dependency of 3-in-1 encoding > > > being > > > >>>>>dependent on RFC5696 but also updating RFC5696. > > > >>>>> > > > >>>>>Of course we could always revive the option we discussed, > where we > > > >>>>>obsolete > > > >>>>>RFC5696 and incorporate a baseline behaviour within this draft > > > >>>(which > > > >>>>>could > > > >>>>>then be called PCN encodings using a single DSCP)... > > > >>>>> > > > >>>>>Thoughts anyone? > > > >>>>> > > > >>>>>Toby > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > >>>>>>Sent: 01 April 2011 13:22 > > > >>>>>>To: Michael Menth > > > >>>>>>Cc: Toby Moncaster; pcn@ietf.org > > > >>>>>>Subject: Re: [PCN] ECN handling with 3-in-1 > > > >>>>>> > > > >>>>>>Michael, > > > >>>>>> > > > >>>>>>At 09:36 01/04/2011, Michael Menth wrote: > > > >>>>>>>Hi all, > > > >>>>>>> > > > >>>>>>>to quickly see that the case analysis is complete, I suggest > a > > > >>>>>>>slight rewording: > > > >>>>>>> > > > >>>>>>>Handling of ECN traffic > > > >>>>>>>* ECN traffic not being subject to PCN control and not > sharing a > > > >>>>>>>PCN-compatible DSCP > > > >>>>>>> - no action needed > > > >>>>>>>* ECN traffic not being subject to PCN control and sharing a > > > >>>>>>>PCN-compatible DSCP > > > >>>>>>> - ingress tunnels that traffic with an non-PCN- > compatible > > > >>>DSCP > > > >>>>>>>in the outer header (any tunnel may be used) > > > >>>>>>> - alternative: ingress maps the DSCP to a local DSCP > and > > > >>>egress > > > >>>>>>>re-maps it to the original PCN-compatible DSCP > > > >>>>>>> - alternative: ingress tunnels that traffic with not- > PCN > > > in > > > >>>the > > > >>>>>>>outer header (any tunnel may be used); note that this turns > of > > > >>>ECN > > > >>>>>>>for this traffic within the PCN domain. > > > >>>>>>We ought to recommend one: > > > >>>>>>#2 does nothing wrong, whereas the others do, to a certain > > > >>>extent. > > > >>>>>>THe only reason for using #3 would be if you are short of > DSCPs > > > >>>(e.g. > > > >>>>>>MPLS or Ethernet). > > > >>>>>>#1 changes the PHB, whereas #2 doesn't and is otherwise the > same. > > > >>>So > > > >>>>>>#1 can be chucked. > > > >>>>>> > > > >>>>>>>* ECN traffic being subject to PCN control > > > >>>>>>> - ingress drops CE-marked packets and egress zeros ECN > > > >>>field of > > > >>>>>>>PCN packets which disables end-to-end ECN > > > >>>>>>Not recommended > > > >>>>>> > > > >>>>>>> - alternative: ingress tunnels that traffic with a > > > >>>>>>>PCN-compatible DSCP in the outer header and the egress zeros > > > >>>>>>>ECN-field before decapsulation (any tunnel may be used) > > > >>>>>>recommended > > > >>>>>> > > > >>>>>>>* ECN traffic being subject to PCN control, and the receiver > has > > > >>>>>>>indicated to receive PCN marks > > > >>>>>>> - ingress tunnels that traffic with a PCN-compatible > DSCP > > > >>>but > > > >>>>>>>the egress SHOULD NOT zero the ECN field before > decapsulation > > > >>>>>>>according to RFC6040 normal mode; note that this may turn > > > >>>ECT(0) > > > >>>>>>>into ECT(1) so that the nonce is modified. > > > >>>>>>Good point. > > > >>>>>>This needs to be clearly flagged as an experimental only > scheme. > > > >>>>>> > > > >>>>>> > > > >>>>>>>Another two questions > > > >>>>>>>* Traffic may arrive with a non-PCN-compatible DSCP and is > > > >>>subject > > > >>>>>>>to PCN control. Do we care about the original DSCP? This > seems > > > >>>to be > > > >>>>>>>a similar issue. > > > >>>>>>Similar to what? > > > >>>>What Michael means is, if an operator chooses to change the > DSCP of > > > an > > > >>>>arriving packet in order to enable PCN for that packet, should > that > > > >>>change > > > >>>>be reversed on leaving the PCN domain? This is starting to get > > > rather > > > >>>>obscure. Appendix A.1 of RFC5696 discusses the choice of > suitable > > > >>>DSCPs for > > > >>>>PCN and makes it clear that operators should choose to use an > > > existing > > > >>>DSCP > > > >>>>providing suitable scheduling and priority. However, if an > operator > > > >>>chooses > > > >>>>to define a local DSCP instead then they are free to do so. If > I > > > >>>recall > > > >>>>right, DSCPs are not guaranteed to survive between domains > > > anyway... > > > >>>> > > > >>>> > > > >>>>>>>* How is the ECN-field of traffic with a PCN-compatible DSCP > > > >>>>>>>interpreted outside a PCN domain? I guess with ECN > semantics? > > > >>>Have > > > >>>>>>>we stated that somewhere. Do we need to state it? > > > >>>>>>Dunno whether we've said this somewhere. Will need to check. > > > >>>>Is this at all relevant to PCN? I would argue we don't need to > > > state > > > >>>this > > > >>>>anywhere at all since PCN semantics only apply inside a PCN- > domain. > > > IN > > > >>>>appendix A.1 of RFC5696 we make it clear that PCN is a marking > > > >>>behaviour for > > > >>>>use within the PCN-domain and discuss DSCP-related issues > > > >>>Given we are talking about e2e ECN support across a PCN domain, > it > > > >>>would do no harm to reinforce the idea that a DSCP cannot even > be > > > >>>considered PCN-compatible when it is outside a PCN domain - it > has > > > >>>its usual scheulding PHB, but its congestion marking behaviour > is > > > the > > > >>>ECN default, not PCN. > > > >>Would adding the following (in a suitable place) suffice?: > > > >> > > > >>"PCN is in effect a congestion marking behaviour for use with > > > realtime > > > >>traffic in a controlled domain. As such, within the PCN-domain, > PCN > > > marking > > > >>replaces ECN marking for any PCN-enabled DSCPs. Outside the PCN- > > > domain, ECN > > > >>remains the default behaviour for all DSCPs." > > > >> > > > >>Toby > > > >> > > > >>> > > > >>>Bob > > > >>> > > > >>> > > > >>> > > > >>>>>> > > > >>>>>>Bob > > > >>>>>> > > > >>>>>> > > > >>>>>>>Best wishes, > > > >>>>>>> > > > >>>>>>> Michael > > > >>>>>>> > > > >>>>>>>-- > > > >>>>>>>Prof. Dr. habil. Michael Menth > > > >>>>>>>University of Tuebingen > > > >>>>>>>Faculty of Science > > > >>>>>>>Department of Computer Science > > > >>>>>>>Chair of Communication Networks > > > >>>>>>>Sand 13, 72076 Tuebingen, Germany > > > >>>>>>>phone: (+49)-7071/29-70505 > > > >>>>>>>fax: (+49)-7071/29-5220 > > > >>>>>>>mailto:menth@uni-tuebingen.de > > > >>>>>>>http://www-kn.informatik.uni-tuebingen.de > > > > >>>>>>________________________________________________________________ > > > >>>>>>Bob Briscoe, BT Innovate& > Design > > > >>>>>_______________________________________________ > > > >>>>>PCN mailing list > > > >>>>>PCN@ietf.org > > > >>>>>https://www.ietf.org/mailman/listinfo/pcn > > > >>>________________________________________________________________ > > > >>>Bob Briscoe, BT Innovate& Design > > > > > > > >-- > > > >Prof. Dr. habil. Michael Menth > > > >University of Tuebingen > > > >Faculty of Science > > > >Department of Computer Science > > > >Chair of Communication Networks > > > >Sand 13, 72076 Tuebingen, Germany > > > >phone: (+49)-7071/29-70505 > > > >fax: (+49)-7071/29-5220 > > > >mailto:menth@uni-tuebingen.de > > > >http://www-kn.informatik.uni-tuebingen.de > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From toby@moncaster.com Wed May 4 08:02:22 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8066E078F for ; Wed, 4 May 2011 08:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIbyyNnfdrMq for ; Wed, 4 May 2011 08:02:20 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6C3E06FA for ; Wed, 4 May 2011 08:02:19 -0700 (PDT) Received: from TobysHP (host86-136-244-185.range86-136.btcentralplus.com [86.136.244.185]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LbacF-1Pto9a1ziN-00lHj5; Wed, 04 May 2011 17:02:18 +0200 From: "Toby Moncaster" To: , References: <4D9448F9.7040309@informatik.uni-tuebingen.de> <002e01cbef88$b1cc7b70$15657250$@com> <4D94EF65.20001@informatik.uni-tuebingen.de> <4D958E90.4060103@informatik.uni-tuebingen.de> <201104011222.p31CMCas029062@bagheera.jungle.bt.co.uk> <003e01cbf074$d2042270$760c6750$@com> <000c01cbfa92$38da9750$aa8fc5f0$@com> <201104150314.p3F3E8HU001775@bagheera.jungle.bt.co.uk> <000c01cbfb47$8c8ef520$a5acdf60$@com> <4DA81828.4090002@informatik.uni-tuebingen.de> <201104151450.p3FEoiab003742@bagheera.jungle.bt.co.uk> <000901cbfc13$ee81e720$cb85b560$@com> <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> <000c01cc0a3c$e2c29420$a847bc60$@com> <9510D26531EF184D9017DF24659BB87F32A9301EB3@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32A9301EB3@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 4 May 2011 16:02:14 +0100 Message-ID: <001d01cc0a6c$415ab0b0$c4101210$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acv8JidjJNrJ3s6YQ7W23VuGzoCftgOFYgxgAAo0HVAAAZCc0A== Content-Language: en-gb X-Provags-ID: V02:K0:Ax9TFMjY8UsgCKGJpJaXtKWS6nwyDGhOo0A+eJcssmh Zsgii89CAFiazooW0Q2mgGnKCwct0Zam6ZKF3hb/COCIgj8VXw BwS2XFAD6a1+XhHIr96QxrQE/HP5jlbfqEJAWTQb1Hm/eckaiJ AShnMfIwHCQ/L9TNkxFdeDCXRWQqy0YCU9c5jJ8dWEL4XioJNO GkXpuIOBjCExFHz+uM/k6hahiiruvsDplu2lAAXLBM= Cc: pcn@ietf.org Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:02:22 -0000 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: 04 May 2011 15:13 > To: toby@moncaster.com; bob.briscoe@bt.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Revised 3-in-1 draft and status of RFC5696 > > Toby > > Sorry, i didnt follow all the previous thread. I know there was some > discussion on somewhat peripheral issues (from an encoding perspective > - as in emails below). > However, I cannot remember the conclusion on the substantial issue, ie > what encoding or encodings we want to end up as standardised. Is it:- > > +--------+---------------------------------------------------- > + > | | Codepoint in ECN field of IP header > | > | DSCP | > | > | +--------------+-------------+-------------+--------- > + > | | 00 | 10 | 01 | 11 > | > +--------+--------------+-------------+-------------+--------- > + > | DSCP n | Not-PCN | NM | ThM | ETM > | > +--------+--------------+-------------+-------------+--------- > + > > That looks right Or, in the case of single marking: > > +--------+---------------------------------------------------- > + > | | Codepoint in ECN field of IP header > | > | DSCP | > | > | +--------------+-------------+-------------+--------- > + > | | 00 | 10 | 01 | 11 > | > +--------+--------------+-------------+-------------+--------- > + > | DSCP n | Not-PCN | NM | illegal | PM > | > +--------+--------------+-------------+-------------+--------- > + > That seems right. In theory you could treat the "illegal" case as PM as well... In fact, I would probably put it in with a warning something like "In the basic encoding, the 01 codepoint is illegal and should only appear if a PCN node is misconfigured. It is reasonable for the PCN-egress-node to treat the 01 codepoint as indicating PM in the same manner as 11, but it SHOULD raise a management alarm." > Note that 01 = EXP doesn't appear. Indeed, and that was my suggested bis to RFC5696. It looks like we are going to have to create a completely new combined document after all. Certainly that is the cleanest option and allows us to remove any confusions. It might take another complete cycle to do it though which is not ideal :( In order to handle the two distinct cases you set out above I would suggest that such a document has two parts: a basic encoding (for single marking schemes) and a full encoding (for dual marking schemes). This would make the choice of encoding a configuration option similar to the option of whether to turn on the two marking schemes or not. Question - would this require any changes to any other documents? Toby > Is this correct? > Thanks > phil > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Toby Moncaster > Sent: 04 May 2011 10:23 > To: Briscoe,RJ,Bob,DES8 R > Cc: pcn@ietf.org > Subject: [PCN] Revised 3-in-1 draft and status of RFC5696 > > I'll get back to this in the next couple of days and try and release an > updated draft early next week... We had more or less converged on what > text > to include in the new version. > > Meanwhile, can the working group give their views on what should happen > regarding RFC5696. As I see it there are 3 options: > > 1) have this new RFC update it, but that leaves it as a dead document > (in > effect, since there will be contradictory definitions for the 01 > codepoint) > 2) release a bis version of RFC5696 with the EXP codepoint fixed as > having > to be used for carrying a PCN marking state, and with any other tweaks > we > think of > 3) combine the two by putting in a section in this document about how > to use > it in single marking schemes (which will take quite a bit of > wordsmithing). > > I personally favour option 2 as it is the cleanest and allows us to > keep > open the greatest range of future marking schemes. Option 1 is easy, > but > leaves some potential issues (for instance it will mean there is no > standards support for anything similar to the PSDM scheme which Michael > and > others seem to still be interested in). Option 3 will take a lot of > work, > but would allow RFC5696 to become obsolete (so is also quite clean from > a > standards viewpoint). > > Toby > > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: 16 April 2011 12:05 > > To: Toby Moncaster > > Cc: 'Michael Menth'; pcn@ietf.org > > Subject: RE: [PCN] ECN handling with 3-in-1 > > > > Toby, > > > > At 09:54 16/04/2011, Toby Moncaster wrote: > > >Bob, Michael, > > > > > > > -----Original Message----- > > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > > Sent: 15 April 2011 15:51 > > > > To: Michael Menth > > > > Cc: Toby Moncaster; pcn@ietf.org > > > > Subject: Re: [PCN] ECN handling with 3-in-1 > > > > > > > > Toby, Michael, > > > > > > > > 2/ e2e ECN appendix > > > > Now that I'm awake, I've realised the wording of the headings for > > the > > > > four options we are discussing needs to be completely reframed. > > > > > > > > End nodes don't ask for PCN control, they ask for admission > > control. > > > > An operator chooses what mechanism to use for admission control > > over > > > > their segment of the path, and PCN is just one possible mechanism > > > > they might choose. > > > > > > > > At the outset, we need to list the two main ways that end-nodes > > tell > > > > the network that they need admission control, which in turn makes > > the > > > > PCN-ingress remark their traffic with a PCN-compatible DSCP: > > > > > > > > A) flow signalling associates a filterspec with a need for > > admission > > > > control (e.g. thru RSVP or some equivalent message down from a > SIP > > > > server to the ingress), and the PCN ingress remarks traffic > > matching > > > > that filterspec to a PCN-compatible DSCP, as its chosen admission > > > > control mechanism. > > > > > > > > B) Traffic arrives with a DSCP that implies it requires admission > > > > control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, > > > > Broadcast TV when used for video on demand, and Multimedia > > > > Conferencing [RFC4594, RFC5865]. > > > > > >You need to re-read the appendix of RFC5696 where we discuss DSCP- > > related > > >issues. > > > > I did before writing that email. > > > > >I am very unkeen to add so much extra text to what should be a > simple > > >encoding document. This will end up making the appendix nearly as > long > > as > > >the main document. I also have concerns that this sort of thing is > > really > > >architectural. This document isn't about telling operators which of > > their > > >traffic they should be doing admission control on. > > > > > >I would rather we just put a simple paragraph saying what you have > in > > your > > >intro to this point: > > > > > >" End nodes don't ask for PCN control, they ask for admission > control. > > > An operator chooses what mechanism to use for admission control > over > > > their segment of the path, and PCN is just one possible mechanism > > > they might choose." > > > > We need to provide some explanation for why we suddenly started > > talking about these four cases. So we do need to say what we mean by > > end-nodes asking for admission control. It would be nice to cite > > something that explains, but we don't have anything, because RFC5865 > > on DSCPs for admission contrl went through after all the PCN RFCs so > > far. > > > > So I think we have to treat this appendix as the latest definitive > > word on the two mains ways that end points might use to signal that > > they want admission control, even tho it's not really relevant to > > this doc. The only alternative would be to update the PCN > > architecture RFC, and I don't want to go there. > > > > > > We need to define two phrases, such as: > > > > * "Traffic that requires admission control" as traffic that uses > > > > either method A or B. > > > > * "Traffic that does not require admission control" as traffic > that > > > > uses neither of methods A or B. > > > > > >OK, happy to have those definitions, but we are going to find > > ourselves > > >tying knots as we try and talk about traffic that doesn't need > > admission > > >control but which shares the same DSCP... > > > > [snip] > > > > > > >>>> ECN traffic not subjected to PCN control but sharing a > > PCN- > > > > >>>compatible > > > > >>>> DSCP: > > > > >>>s/sharing a PCN-compatible DSCP/using a PCN-compatible DSCP on > > > > >>>arrival at the PCN ingress/ > > > > > > > > On second thoughts, we should head this item > > > > "ECN capable traffic that does not require admission control but > > > > carries a DSCP that the PCN-ingress is using for PCN-capable > > traffic." > > > > > > > > HOWEVER, I don't think this case is possible. If traffic arrives > > with > > > > a DSCP that would be used for PCN, it is signalling that it > > requires > > > > admission control [RFC5865]. > > > > > >BUT some of that traffic may in fact be automatically admitted > > (because of > > >policy), hence it wouldn't use PCN... > > > > > >My own view is this whole case needn't be mentioned because the > > traffic is > > >neither ECN nor PCN. If we were to list all negative cases we would > > get an > > >even longer appendix! > > > > Well, the traffic *is* ECN and it is confusable with PCN traffic. As > > I just said in my mail to Michael, it would only be confusible with > > PCN traffic if the PCN operator decided to use weird DSCPs for PCN. > > > > How about not listing this case as if it is normal, but instead > > mention it as a 'footnote' to this appendix, as an abnormal case to > > be avoided if possible, perhaps: > > > > "It is strongly RECOMMENDED that the advice in A.1 of the PCN > > baseline encoding [RFC5696] is followed when choosing which DSCP > > indicates PCN-compatible traffic. Otherwise nodes within the PCN > > region will mistake traffic using e2e ECN for PCN-traffic if it also > > happens to use the chosen DSCP. To avoid this confusion, the PCN > > ingress would have to remark this traffic to another DSCP, causing > > further complication and confusion downstream." > > > > > > > > > > >>>> ECN traffic being subjected to PCN control, receiver > > indicates > > > > >>>desire > > > > >>>> to see PCN marks: > > > > > > > > We should head this item > > > > "Traffic that requires admission control, where the e2e transport > > > > somehow indicates it wants to see PCN marks." > > > > > >s/"somehow indicates"/"signals that" > > > > If you want. > > I was trying to avoid being prescriptive about how it might be done. > > > > >I'll try and unravel all the changes and send a revised version by > > Monday... > > >It won't necessarily include all the suggestions (see the inline > > comment at > > >the top), and there is a chance I may miss a couple! > > > > Yes, when I prepared the email you just replied to, I tried to pull > > together everything that had been said, so I hope that posting will > > be useful for you. > > > > Cheers > > > > > > Bob > > > > > > >Toby > > > > > > > > > > > > > > > > > > Bob > > > > > > > > >>>>The > > > > >>>PCN- > > > > >>>> egress should not zero the ECN field, > > > > >>>Don't agree. ECN should never leak into PCN, but PCN might be > OK > > to > > > > >>>leak to ECN receiver. > > > > >>I'm not allowing ECN to leak into PCN. I am (in limited > > > > circumstances) > > > > >>allowing the PCN-domain to over-write the ECN information and > > hence > > > > leak PCN > > > > >>information to the receiver. > > > > >> > > > > >>>Reasoning: admission of a flow should only depend on PCN > marking > > > > >>>within the PCN region. It shouldn't depend on ECN marking from > > > > queues > > > > >>>outside the PCN region, which will not have been configured to > > give > > > > >>>good signals at the right load levels. > > > > >>Oh, I think I see your point. RFC6040 tunnels will set the ECN > of > > the > > > > outer > > > > >>header to whatever is in the inner header. BUT you are > forgetting > > > > that the > > > > >>default behaviour of the PCN-ingress is to clear whatever is in > > the > > > > outer > > > > >>header and set it to 10 (if the traffic is PCN) or 00 (if the > > traffic > > > > is > > > > >>not-PCN) > > > > > > > > > >Mentioning that would be helpful. Also we need to remember that > > but > > > > >often forget about it and then we wonder about the text ... > > > > > > > > > >Regards, > > > > > > > > > > Michael > > > > > > > > > >>>The reverse argument seems less likely to apply to leaking PCN > > to > > > > >>>receiver, because any decent level of PCN will usefully > trigger > > a > > > > >>>lower rate, thus potentially avoiding the need to block > > admissions. > > > > >>> > > > > >>>>and the tunnel egress should > > > > >>>> use [RFC6040] normal mode (preserving any PCN- > marking). > > > > >>>There are no modes for an RFC6040 egress. Modes are only for > the > > > > >>>ingress. > > > > >>OK, noted. I did know that really, I was being careless. > > > > >> > > > > >>>The important point is not what the tunnel egress does > (assuming > > the > > > > >>>arrangement in the Fig below), but that the PCN egress doesn't > > zero > > > > >>>the outer ECN field. > > > > >>Indeed... > > > > >> > > > > >>>>Note that > > > > >>>> this may turn ECT(0) into ECT(1) and so is not > > compatible > > > > with > > > > >>>the > > > > >>>> experimental ECN nonce [RFC3540]. > > > > >>>s/this/PCN marking on interior nodes/ > > > > >>> > > > > >>> > > > > >>>> In the list above any form of IP-in-IP tunnel can be > used > > > > unless > > > > >>>> specified otherwise. We assume a logical separation of > > > > tunneling > > > > >>>> and PCN actions in both PCN-ingress and PCN-egress > nodes. > > > > That > > > > >>>is, > > > > >>>> any tunneling action happens wholly outside the PCN- > domain > > as > > > > >>>> illustrated in the following figure: > > > > >>>> > > > > >>>> > > > > >>>> , . . . . PCN-domain . . . . . . > > . > > > > >>>> . ,--------. ,--------. > > . > > > > >>>> . _| PCN- |___________________| PCN- > |_ > > . > > > > >>>> . / | ingress | | egress | > \ > > . > > > > >>>> .| '---------' '--------' > > |. > > > > >>>> | . . . . . . . . . . . . . . > > .| > > > > >>>> ,--------. > ,-- > > ---- > > > > --. > > > > >>>> _____| Tunnel | | > > > > Tunnel > > > > >>>|____ > > > > >>>> | Ingress | - - ECN preserved inside tunnel - - | > > > > Egress | > > > > >>>> '---------' > '-- > > ---- > > > > --' > > > > >>>> > > > > >>>> > > > > >>>> Figure 4: Separation of tunneling and PCN > > actions > > > > >>>>" > > > > >>>nice ASCII art. > > > > >>Thanks :) > > > > >> > > > > >>> > > > > >>>>I hope this captures all the key elements from the > discussion. > > > > >>>> > > > > >>>>I am still unsure exactly how we are proceeding with regards > to > > > > >>>updating > > > > >>>>RFC5696. Can this document both update RFC5696 AND be > dependent > > on > > > > it > > > > >>>as > > > > >>>>well? Currently I am thinking of adding the following as a > > > > standalone > > > > >>>>section: > > > > >>>> > > > > >>>>"Section N. Effect on baseline encoding > > > > >>>> > > > > >>>>The baseline encoding [rfc5696] specified that the 01 > codepoint > > was > > > > >>>for use > > > > >>>>in experimental schemes. It also gave guidelines for such > > > > experiments. > > > > >>>This > > > > >>>>document updates the 01 codepoint and fixes its meaning. > > > > Consequently > > > > >>>this > > > > >>>>document updates [rfc5696]. People wishing to use the 01 > > codepoint > > > > for > > > > >>>>experimental schemes as described in [rfc5696] must accept > the > > risk > > > > >>>that > > > > >>>>PCN-nodes compatible with this encoding scheme may not be > > > > compatible > > > > >>>with > > > > >>>>their experiment." > > > > >>>It would be dangerous for me to respond to this now - I'm too > > tired > > > > >>>to think straight. But my gut feeling is that the wording > should > > > > lean > > > > >>>more towards "updates", and less towards appearing to > encourage > > more > > > > >>>experimentation, which would run counter to interoperability - > > the > > > > >>>raison d'etre of a standards body. > > > > >>OK, I can probably highlight that we are not recommending > people > > > > start > > > > >>experiments, but if they are already using the EXP codepoint > for > > > > anything > > > > >>else they need to be aware of this clash... > > > > >> > > > > >>> > > > > >>> > > > > >>> > > > > >>>>Two inline responses to Michael at the end > > > > >>>One from me too... > > > > >>> > > > > >>> > > > > >>> > > > > >>>>Toby > > > > >>>> > > > > >>>>>-----Original Message----- > > > > >>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf > > > > >>>Of > > > > >>>>>Toby Moncaster > > > > >>>>>Sent: 01 April 2011 14:58 > > > > >>>>>To: 'Bob Briscoe'; 'Michael Menth' > > > > >>>>>Cc: pcn@ietf.org > > > > >>>>>Subject: Re: [PCN] ECN handling with 3-in-1 > > > > >>>>> > > > > >>>>>I'm not sure if I captured all the changes we intend to do > on > > this > > > > >>>>>draft: > > > > >>>>> > > > > >>>>>1) add Michael's text on e2e ECN (once it has become stable) > > > > >>>>> > > > > >>>>>2) add a brief paragraph explaining that this effectively > > updates > > > > >>>>>RFC5696 > > > > >>>>>and that therefore anyone running experiments with that are > on > > > > >>>their > > > > >>>>>own > > > > >>>>>(which they kind of are anyway, if they are doing an > > experiment!). > > > > >>>>> > > > > >>>>>3) clarify how to do single marking with this encoding. > > > > >>>>> > > > > >>>>>I now recall the real reason why I wanted to preserve > baseline > > > > >>>which is > > > > >>>>>that > > > > >>>>>this encoding has the RFC6040 dependency. > > > > >>>>> > > > > >>>>>Is there any mileage in exploring a bis for RFC5696? As I > see > > it > > > > we > > > > >>>are > > > > >>>>>always going to have a slightly messy situation. For > instance > > I am > > > > >>>not > > > > >>>>>sure > > > > >>>>>if you are allowed the circular dependency of 3-in-1 > encoding > > > > being > > > > >>>>>dependent on RFC5696 but also updating RFC5696. > > > > >>>>> > > > > >>>>>Of course we could always revive the option we discussed, > > where we > > > > >>>>>obsolete > > > > >>>>>RFC5696 and incorporate a baseline behaviour within this > draft > > > > >>>(which > > > > >>>>>could > > > > >>>>>then be called PCN encodings using a single DSCP)... > > > > >>>>> > > > > >>>>>Thoughts anyone? > > > > >>>>> > > > > >>>>>Toby > > > > >>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > > >>>>>>Sent: 01 April 2011 13:22 > > > > >>>>>>To: Michael Menth > > > > >>>>>>Cc: Toby Moncaster; pcn@ietf.org > > > > >>>>>>Subject: Re: [PCN] ECN handling with 3-in-1 > > > > >>>>>> > > > > >>>>>>Michael, > > > > >>>>>> > > > > >>>>>>At 09:36 01/04/2011, Michael Menth wrote: > > > > >>>>>>>Hi all, > > > > >>>>>>> > > > > >>>>>>>to quickly see that the case analysis is complete, I > suggest > > a > > > > >>>>>>>slight rewording: > > > > >>>>>>> > > > > >>>>>>>Handling of ECN traffic > > > > >>>>>>>* ECN traffic not being subject to PCN control and not > > sharing a > > > > >>>>>>>PCN-compatible DSCP > > > > >>>>>>> - no action needed > > > > >>>>>>>* ECN traffic not being subject to PCN control and sharing > a > > > > >>>>>>>PCN-compatible DSCP > > > > >>>>>>> - ingress tunnels that traffic with an non-PCN- > > compatible > > > > >>>DSCP > > > > >>>>>>>in the outer header (any tunnel may be used) > > > > >>>>>>> - alternative: ingress maps the DSCP to a local DSCP > > and > > > > >>>egress > > > > >>>>>>>re-maps it to the original PCN-compatible DSCP > > > > >>>>>>> - alternative: ingress tunnels that traffic with > not- > > PCN > > > > in > > > > >>>the > > > > >>>>>>>outer header (any tunnel may be used); note that this > turns > > of > > > > >>>ECN > > > > >>>>>>>for this traffic within the PCN domain. > > > > >>>>>>We ought to recommend one: > > > > >>>>>>#2 does nothing wrong, whereas the others do, to a certain > > > > >>>extent. > > > > >>>>>>THe only reason for using #3 would be if you are short of > > DSCPs > > > > >>>(e.g. > > > > >>>>>>MPLS or Ethernet). > > > > >>>>>>#1 changes the PHB, whereas #2 doesn't and is otherwise the > > same. > > > > >>>So > > > > >>>>>>#1 can be chucked. > > > > >>>>>> > > > > >>>>>>>* ECN traffic being subject to PCN control > > > > >>>>>>> - ingress drops CE-marked packets and egress zeros > ECN > > > > >>>field of > > > > >>>>>>>PCN packets which disables end-to-end ECN > > > > >>>>>>Not recommended > > > > >>>>>> > > > > >>>>>>> - alternative: ingress tunnels that traffic with a > > > > >>>>>>>PCN-compatible DSCP in the outer header and the egress > zeros > > > > >>>>>>>ECN-field before decapsulation (any tunnel may be used) > > > > >>>>>>recommended > > > > >>>>>> > > > > >>>>>>>* ECN traffic being subject to PCN control, and the > receiver > > has > > > > >>>>>>>indicated to receive PCN marks > > > > >>>>>>> - ingress tunnels that traffic with a PCN-compatible > > DSCP > > > > >>>but > > > > >>>>>>>the egress SHOULD NOT zero the ECN field before > > decapsulation > > > > >>>>>>>according to RFC6040 normal mode; note that this may turn > > > > >>>ECT(0) > > > > >>>>>>>into ECT(1) so that the nonce is modified. > > > > >>>>>>Good point. > > > > >>>>>>This needs to be clearly flagged as an experimental only > > scheme. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>>Another two questions > > > > >>>>>>>* Traffic may arrive with a non-PCN-compatible DSCP and is > > > > >>>subject > > > > >>>>>>>to PCN control. Do we care about the original DSCP? This > > seems > > > > >>>to be > > > > >>>>>>>a similar issue. > > > > >>>>>>Similar to what? > > > > >>>>What Michael means is, if an operator chooses to change the > > DSCP of > > > > an > > > > >>>>arriving packet in order to enable PCN for that packet, > should > > that > > > > >>>change > > > > >>>>be reversed on leaving the PCN domain? This is starting to > get > > > > rather > > > > >>>>obscure. Appendix A.1 of RFC5696 discusses the choice of > > suitable > > > > >>>DSCPs for > > > > >>>>PCN and makes it clear that operators should choose to use an > > > > existing > > > > >>>DSCP > > > > >>>>providing suitable scheduling and priority. However, if an > > operator > > > > >>>chooses > > > > >>>>to define a local DSCP instead then they are free to do so. > If > > I > > > > >>>recall > > > > >>>>right, DSCPs are not guaranteed to survive between domains > > > > anyway... > > > > >>>> > > > > >>>> > > > > >>>>>>>* How is the ECN-field of traffic with a PCN-compatible > DSCP > > > > >>>>>>>interpreted outside a PCN domain? I guess with ECN > > semantics? > > > > >>>Have > > > > >>>>>>>we stated that somewhere. Do we need to state it? > > > > >>>>>>Dunno whether we've said this somewhere. Will need to > check. > > > > >>>>Is this at all relevant to PCN? I would argue we don't need > to > > > > state > > > > >>>this > > > > >>>>anywhere at all since PCN semantics only apply inside a PCN- > > domain. > > > > IN > > > > >>>>appendix A.1 of RFC5696 we make it clear that PCN is a > marking > > > > >>>behaviour for > > > > >>>>use within the PCN-domain and discuss DSCP-related issues > > > > >>>Given we are talking about e2e ECN support across a PCN > domain, > > it > > > > >>>would do no harm to reinforce the idea that a DSCP cannot even > > be > > > > >>>considered PCN-compatible when it is outside a PCN domain - it > > has > > > > >>>its usual scheulding PHB, but its congestion marking behaviour > > is > > > > the > > > > >>>ECN default, not PCN. > > > > >>Would adding the following (in a suitable place) suffice?: > > > > >> > > > > >>"PCN is in effect a congestion marking behaviour for use with > > > > realtime > > > > >>traffic in a controlled domain. As such, within the PCN-domain, > > PCN > > > > marking > > > > >>replaces ECN marking for any PCN-enabled DSCPs. Outside the > PCN- > > > > domain, ECN > > > > >>remains the default behaviour for all DSCPs." > > > > >> > > > > >>Toby > > > > >> > > > > >>> > > > > >>>Bob > > > > >>> > > > > >>> > > > > >>> > > > > >>>>>> > > > > >>>>>>Bob > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>>Best wishes, > > > > >>>>>>> > > > > >>>>>>> Michael > > > > >>>>>>> > > > > >>>>>>>-- > > > > >>>>>>>Prof. Dr. habil. Michael Menth > > > > >>>>>>>University of Tuebingen > > > > >>>>>>>Faculty of Science > > > > >>>>>>>Department of Computer Science > > > > >>>>>>>Chair of Communication Networks > > > > >>>>>>>Sand 13, 72076 Tuebingen, Germany > > > > >>>>>>>phone: (+49)-7071/29-70505 > > > > >>>>>>>fax: (+49)-7071/29-5220 > > > > >>>>>>>mailto:menth@uni-tuebingen.de > > > > >>>>>>>http://www-kn.informatik.uni-tuebingen.de > > > > > > > >>>>>>________________________________________________________________ > > > > >>>>>>Bob Briscoe, BT Innovate& > > Design > > > > >>>>>_______________________________________________ > > > > >>>>>PCN mailing list > > > > >>>>>PCN@ietf.org > > > > >>>>>https://www.ietf.org/mailman/listinfo/pcn > > > > > >>>________________________________________________________________ > > > > >>>Bob Briscoe, BT Innovate& > Design > > > > > > > > > >-- > > > > >Prof. Dr. habil. Michael Menth > > > > >University of Tuebingen > > > > >Faculty of Science > > > > >Department of Computer Science > > > > >Chair of Communication Networks > > > > >Sand 13, 72076 Tuebingen, Germany > > > > >phone: (+49)-7071/29-70505 > > > > >fax: (+49)-7071/29-5220 > > > > >mailto:menth@uni-tuebingen.de > > > > >http://www-kn.informatik.uni-tuebingen.de > > > > > > > > ________________________________________________________________ > > > > Bob Briscoe, BT Innovate & Design > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Wed May 4 09:16:44 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09183E07B1 for ; Wed, 4 May 2011 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.926 X-Spam-Level: X-Spam-Status: No, score=-101.926 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaRj7g8Vus6v for ; Wed, 4 May 2011 09:16:43 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 133B5E07A9 for ; Wed, 4 May 2011 09:16:40 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 4 May 2011 17:16:39 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.135]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 4 May 2011 17:16:39 +0100 From: To: , Date: Wed, 4 May 2011 17:16:37 +0100 Thread-Topic: [PCN] Revised 3-in-1 draft and status of RFC5696 Thread-Index: Acv8JidjJNrJ3s6YQ7W23VuGzoCftgOFYgxgAAo0HVAAAZCc0AACKuUg Message-ID: <9510D26531EF184D9017DF24659BB87F32A930207E@EMV65-UKRD.domain1.systemhost.net> References: <4D9448F9.7040309@informatik.uni-tuebingen.de> <002e01cbef88$b1cc7b70$15657250$@com> <4D94EF65.20001@informatik.uni-tuebingen.de> <4D958E90.4060103@informatik.uni-tuebingen.de> <201104011222.p31CMCas029062@bagheera.jungle.bt.co.uk> <003e01cbf074$d2042270$760c6750$@com> <000c01cbfa92$38da9750$aa8fc5f0$@com> <201104150314.p3F3E8HU001775@bagheera.jungle.bt.co.uk> <000c01cbfb47$8c8ef520$a5acdf60$@com> <4DA81828.4090002@informatik.uni-tuebingen.de> <201104151450.p3FEoiab003742@bagheera.jungle.bt.co.uk> <000901cbfc13$ee81e720$cb85b560$@com> <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> <000c01cc0a3c$e2c29420$a847bc60$@com> <9510D26531EF184D9017DF24659BB87F32A9301EB3@EMV65-UKRD.domain1.systemhost.net> <001d01cc0a6c$415ab0b0$c4101210$@com> In-Reply-To: <001d01cc0a6c$415ab0b0$c4101210$@com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:16:44 -0000 Toby said: It looks like we are going to have to create a completely new combined document after all.=20 ... In order to handle the two distinct cases you set out above I would suggest that such a document has two parts: a basic encoding (for single marking schemes) and a full encoding (for dual marking schemes). This would make th= e choice of encoding a configuration option similar to the option of whether to turn on the two marking schemes or not.=20 Question - would this require any changes to any other documents? [phil] I don't know whether a completely new combined doc is the best way. Maybe t= he RFC editor can advise? (an alternative might be to update the baseline so it just applied to singl= e marking (with EXP essentially deprecated) plus a new doc on 3-in-1, or to= update the baseline with changes so that it includes both (ie defines EXP = as per 3-in-1 or as deprecated). Anyway, this seems "just" a process questi= on. If it is a single doc, then the doc would split into 2 sections, with paral= lel sub-sections (encoding, applicability, allowed transitions). I don't understand your comment about marking schemes (rfc5670 defines one = Metering behaviour, the marking section of that doc says " A PCN-packet M= UST be marked to reflect the metering results by setting its encoding state appropriately, as specified by the specific encoding scheme that applies in the PCN-domain." Which docs affected? >From technical point of view, I think all are ok. Edge behaviours basically= unaffected - clearly SM & CL refer to teh right sections RFC 5670 is unaffected, i think. There is one point only where there might = need to be thought -in section B.2 of rfc5670 (an Informative appendix on I= mplementation Notes) (I think the wording of the new doc should allow the t= ext here still to be valid - anyway, the point is extremely pedantic) From Internet-Drafts@ietf.org Thu May 5 12:45:04 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B091E0719; Thu, 5 May 2011 12:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpmV3x0yR+O1; Thu, 5 May 2011 12:45:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4409BE095D; Thu, 5 May 2011 12:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505194503.2464.52742.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 12:45:03 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-signaling-requirements-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:45:04 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain Author(s) : G. Karagiannis, et al Filename : draft-ietf-pcn-signaling-requirements-04.txt Pages : 7 Date : 2011-04-27 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the latter case, (2) is not required). The signaling requirements pertain in particular to two edge behaviours, "controlled load (CL)" and "single marking (SM)" [draft-ietf-pcn-cl-edge- behaviour-08], [draft-ietf-pcn-sm-edge-behaviour-05]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-signaling-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05124222.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu May 5 12:45:04 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D459E0719; Thu, 5 May 2011 12:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPRYO-hai429; Thu, 5 May 2011 12:45:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D366E096B; Thu, 5 May 2011 12:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505194503.2464.93002.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 12:45:03 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-signaling-requirements-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:45:04 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain Author(s) : G. Karagiannis, et al Filename : draft-ietf-pcn-signaling-requirements-04.txt Pages : 7 Date : 2011-04-27 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the latter case, (2) is not required). The signaling requirements pertain in particular to two edge behaviours, "controlled load (CL)" and "single marking (SM)" [draft-ietf-pcn-cl-edge- behaviour-08], [draft-ietf-pcn-sm-edge-behaviour-05]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-signaling-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05124222.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Thu May 12 08:41:58 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2EE06E2 for ; Thu, 12 May 2011 08:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.85 X-Spam-Level: X-Spam-Status: No, score=-98.85 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXUHHMc15Qxo for ; Thu, 12 May 2011 08:41:57 -0700 (PDT) Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id B97A9E067A for ; Thu, 12 May 2011 08:41:57 -0700 (PDT) Received: from BLU0-SMTP9 ([65.55.116.9]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 08:41:57 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP9.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 08:41:56 -0700 Date: Thu, 12 May 2011 11:41:55 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2011 15:41:56.0959 (UTC) FILETIME=[200D8EF0:01CC10BB] Subject: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 15:41:58 -0000 A primary assumption behind the use of PCN, one which I don't recall seeing stated in so many words, is that it applies only to traffic transiting the domain. That is, it does not apply to traffic addressed to some server inside the network, unless you draw a boundary around any such server and say that PCN-nodes connected to it are PCN-edge-nodes. That said, it seems to me that by definition it is impossible to terminate a tunnel in the interior of a PCN-domain. Am I wrong? Tom From menth@informatik.uni-tuebingen.de Thu May 12 09:20:21 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896EBE0671 for ; Thu, 12 May 2011 09:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x4v4Epz1xLA for ; Thu, 12 May 2011 09:20:17 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 95975E071E for ; Thu, 12 May 2011 09:20:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9EFD452BF; Thu, 12 May 2011 18:20:11 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HkT2-zlX0y5; Thu, 12 May 2011 18:20:06 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 99444527D; Thu, 12 May 2011 18:20:06 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 58DD91089AFB; Thu, 12 May 2011 18:20:06 +0200 (CEST) Message-ID: <4DCC08B3.1030205@informatik.uni-tuebingen.de> Date: Thu, 12 May 2011 18:20:03 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tom Taylor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 16:20:21 -0000 Hi Tom, I think you are right. It is important that all PCN traffic is delivered to an egress node; otherwise PCN marks cannot be captured and taken into account for feedback. Regards, Michael Am 12.05.2011 17:41, schrieb Tom Taylor: > A primary assumption behind the use of PCN, one which I don't recall > seeing stated in so many words, is that it applies only to traffic > transiting the domain. That is, it does not apply to traffic addressed > to some server inside the network, unless you draw a boundary around > any such server and say that PCN-nodes connected to it are > PCN-edge-nodes. > > That said, it seems to me that by definition it is impossible to > terminate a tunnel in the interior of a PCN-domain. Am I wrong? > > Tom > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From toby@moncaster.com Thu May 12 09:45:15 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81A1E071C for ; Thu, 12 May 2011 09:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebGouERykPMJ for ; Thu, 12 May 2011 09:45:15 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9B915E068E for ; Thu, 12 May 2011 09:45:14 -0700 (PDT) Received: from TobysHP (host86-137-254-67.range86-137.btcentralplus.com [86.137.254.67]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MRDId-1Q9NYg2KPX-00UXSI; Thu, 12 May 2011 18:45:10 +0200 From: "Toby Moncaster" To: "'Michael Menth'" , "'Tom Taylor'" References: <4DCC08B3.1030205@informatik.uni-tuebingen.de> In-Reply-To: <4DCC08B3.1030205@informatik.uni-tuebingen.de> Date: Thu, 12 May 2011 17:45:08 +0100 Message-ID: <001d01cc10c3$f4db6d70$de924850$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcwQwIBZ5BXhuITuSia2K/sVhdTMqAAAk7cg Content-Language: en-gb X-Provags-ID: V02:K0:td0gP/6mcDJvGzG13GGNwTHwewpOjXpT3LAPcsaj84y JjZCBa8fgjeHmIcNlnucw5V6spaj1Jbh8EB9xQxi3dJ2UToMni 0jHZFiYUZtwmttVvqMfSGistPUt4ZsqQ1+sRTZZTD812XacN+L 7gu3b+RsN4jsYuxWmGeTdgDnljt8L7EvQJapxDiDD5IrAJ2Ex6 1nbFfDOlFm5H5Clh4+HXPxyI77Urton7LEy0StfWGo= Cc: 'pcn' Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 16:45:15 -0000 Tom, I assume you're talking of tunnels that straddle the PCN-domain (start outside and end inside). I've often puzzled about such things. There is one very small corner case I can think of: If non-PCN traffic within a tunnel arrives at a PCN-ingress and shares the same DSCP it might get put into the not-PCN codepoint. That tunnel could theoretically terminate within the PCN-domain, but it shouldn't affect things. There is a really obscure possibility that something broken outside the PCN domain puts some traffic that should be PCN within a tunnel bound for a node within the PCN domain. I really can't tell what would happen then! There is also the case of tunnels that start and end within the PCN-domain... Those should be OK as long as they use sensible tunnelling rules (such that marks are copied down on decapsulation). There is one argument that says having any traffic within the PCN-capable DSCP destined for a PCN-interior node is impossible since by definition that makes it into a PCN-egress node. I think that may be what you're driving at? Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 12 May 2011 17:20 > To: Tom Taylor > Cc: pcn > Subject: Re: [PCN] Can tunnels really terminate in the interior of a > PCN domain? > > Hi Tom, > > I think you are right. It is important that all PCN traffic is > delivered > to an egress node; otherwise PCN marks cannot be captured and taken > into > account for feedback. > > Regards, > > Michael > > > Am 12.05.2011 17:41, schrieb Tom Taylor: > > A primary assumption behind the use of PCN, one which I don't recall > > seeing stated in so many words, is that it applies only to traffic > > transiting the domain. That is, it does not apply to traffic > addressed > > to some server inside the network, unless you draw a boundary around > > any such server and say that PCN-nodes connected to it are > > PCN-edge-nodes. > > > > That said, it seems to me that by definition it is impossible to > > terminate a tunnel in the interior of a PCN-domain. Am I wrong? > > > > Tom > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From tom111.taylor@bell.net Thu May 12 10:00:57 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56054E06C3 for ; Thu, 12 May 2011 10:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.323 X-Spam-Level: X-Spam-Status: No, score=-100.323 tagged_above=-999 required=5 tests=[AWL=1.473, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITqMb4aeiGQF for ; Thu, 12 May 2011 10:00:57 -0700 (PDT) Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by ietfa.amsl.com (Postfix) with ESMTP id DBE71E069E for ; Thu, 12 May 2011 10:00:56 -0700 (PDT) Received: from BLU0-SMTP64 ([65.55.116.9]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 10:00:55 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP64.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 10:00:55 -0700 Date: Thu, 12 May 2011 13:00:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Toby Moncaster References: <4DCC08B3.1030205@informatik.uni-tuebingen.de> <001d01cc10c3$f4db6d70$de924850$@com> In-Reply-To: <001d01cc10c3$f4db6d70$de924850$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2011 17:00:55.0278 (UTC) FILETIME=[284FA8E0:01CC10C6] Cc: 'pcn' Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 17:00:57 -0000 FYI my query related to operational considerations. On 12/05/2011 12:45 PM, Toby Moncaster wrote: > Tom, > > I assume you're talking of tunnels that straddle the PCN-domain (start > outside and end inside). I've often puzzled about such things. > [PTT] Yes .... > > There is one argument that says having any traffic within the PCN-capable > DSCP destined for a PCN-interior node is impossible since by definition that > makes it into a PCN-egress node. I think that may be what you're driving at? > [PTT] Yes again. > Toby > ... From philip.eardley@bt.com Fri May 13 02:59:45 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA252E0766 for ; Fri, 13 May 2011 02:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgWUBf86AYA3 for ; Fri, 13 May 2011 02:59:45 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7F9E0731 for ; Fri, 13 May 2011 02:59:45 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 13 May 2011 10:59:42 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.46]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 13 May 2011 10:59:43 +0100 From: To: , Date: Fri, 13 May 2011 10:59:42 +0100 Thread-Topic: [PCN] Can tunnels really terminate in the interior of a PCN domain? Thread-Index: AcwQxi3IXOID53nNQX6Fp4ZDbpE2UQAjEFaQ Message-ID: <9510D26531EF184D9017DF24659BB87F32AA002458@EMV65-UKRD.domain1.systemhost.net> References: <4DCC08B3.1030205@informatik.uni-tuebingen.de> <001d01cc10c3$f4db6d70$de924850$@com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:59:46 -0000 I spent a bit of time puzzling about such tunnels during PCN-architecture d= ays. I remember we had some discussion with David Black, and he was happy w= ith the approach written in rfc5559. Reading it again, it seems to be sayin= g In case (1), effectively treat it as having some PCN-ingress-node functiona= lity at the tunnel egress; In case (2), make sure that when it's eventually decapsulated, nothing in t= hat distant network will be confused. phil http://tools.ietf.org/html/rfc5559#section-4.7 << Potential issues arise for a "partially PCN-capable tunnel", ie, where only one tunnel endpoint is in the PCN-domain: 1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre- congestion. 2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated, which could potentially confuse nodes beyond the tunnel egress. In line with the solution for partially capable Diffserv tunnels in [RFC2983], the following rules are applied: o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above. o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above. Note that the above implies that one has to know, or determine, the characteristics of the other end of the tunnel as part of establishing it. >> -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: 12 May 2011 18:01 To: Toby Moncaster Cc: 'pcn' Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN do= main? FYI my query related to operational considerations. On 12/05/2011 12:45 PM, Toby Moncaster wrote: > Tom, > > I assume you're talking of tunnels that straddle the PCN-domain (start > outside and end inside). I've often puzzled about such things. > [PTT] Yes .... > > There is one argument that says having any traffic within the PCN-capable > DSCP destined for a PCN-interior node is impossible since by definition t= hat > makes it into a PCN-egress node. I think that may be what you're driving = at? > [PTT] Yes again. > Toby > ... _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From Richard.Lee.FTC@FMR.COM Fri May 13 06:21:36 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575D5E073C for ; Fri, 13 May 2011 06:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpVSaJIkXvxV for ; Fri, 13 May 2011 06:21:32 -0700 (PDT) Received: from maillnx-us111.fmr.com (maillnx-us111.fmr.com [192.223.198.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9BE06D3 for ; Fri, 13 May 2011 06:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; i=Richard.Lee.FTC@fmr.com; l=4074; q=dns/txt; s=2009-03-17; t=1305292892; x=1336828892; h=x-tm-imss-message-id:from:to:cc:date:subject: thread-topic:thread-index:message-id:references: in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-originalarrivaltime:x-filenames; z=X-TM-IMSS-Message-ID:<3f67a91d000990ab@msgrtpiv02vwin.fm r.com>|From:=20"Lee,=20Richard=20FTC"=20|To:=20"philip.eardley@bt.com"=20,=20"tom111.taylor@bell.net"=0D=0A=09,=20"toby@moncaster.com"=20|CC:=20"pcn@ietf.org"=20|Date:=20Fri,=2013 =20May=202011=2009:21:24=20-0400|Subject:=20RE:=20[PCN] =20Can=20tunnels=20really=20terminate=20in=20the=20interi or=20of=09a=09PCN=0D=0A=09domain?|Thread-Topic:=20[PCN] =20Can=20tunnels=20really=20terminate=20in=20the=20interi or=20of=09a=09PCN=0D=0A=09domain?|Thread-Index:=20AcwQxi3 IXOID53nNQX6Fp4ZDbpE2UQAjEFaQAAZ6aYA=3D|Message-ID:=20<3B 4DBB0890AD6642BEAB7B3470FC18F970CAFD9D8B@MSGRTPCCRE2WIN.D MN1.FMR.COM>|References:=20=0D=0A=09<4DCC08B3.1030205@informatik.uni- tuebingen.de>=0D=0A=09<001d01cc10c3$f4db6d70$de924850$@co m>=0D=0A=09 =0D=0A=20<9510D26531EF184D9017DF24659BB87F32AA002458@EMV6 5-UKRD.domain1.systemhost.net>|In-Reply-To:=20<9510D26531 EF184D9017DF24659BB87F32AA002458@EMV65-UKRD.domain1.syste mhost.net>|Accept-Language:=20en-US|Content-Language:=20e n-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-OriginalArrivalTime:=2013 =20May=202011=2013:21:28.0576=20(UTC)=20FILETIME=3D[AAC22 000:01CC1170]|X-filenames:=20None; bh=YT9liRZj/DZG1UxAHXiK0hd1GtZMe0ZP4RjURCK6iGU=; b=WopS+6In5xz89FLS1XXkh02TqXaw51tar8Qahh1ddsnTKUNok7frLyHa et9yRPu0TZifsbGcAJKfBfdTCyJnfY4cv6qlVvRlV8Yfi9YEAWFqWcwk5 3e4uDBdAEhsJHipynOMkWoE/XtOWlZXmyih84y3MMTeTsyH39rTAliYUs E=; X-filenames: None Received: from msgmmksm01win.dmn1.fmr.com ([10.33.139.32]) by maillnx-us111.fmr.com with SMTP; 13 May 2011 09:21:30 -0400 Received: from msgrtpiv02vwin.DMN1.FMR.COM (10.93.69.139) by MSGMMKSM01WIN.DMN1.FMR.COM (Sigaba Gateway v4.1) with ESMTP id 414667581; Fri, 13 May 2011 09:21:29 -0400 X-TM-IMSS-Message-ID: <3f67a91d000990ab@msgrtpiv02vwin.fmr.com> Received: from MSGMMKIM02WIN.DMN1.FMR.COM ([172.25.108.84]) by msgrtpiv02vwin.fmr.com ([10.93.69.139]) with ESMTP (TREND IMSS SMTP Service 7.0) id 3f67a91d000990ab ; Fri, 13 May 2011 09:21:29 -0400 Received: from msgmmkdr04win.DMN1.FMR.COM ([10.33.182.38]) by MSGMMKIM02WIN.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.7381); Fri, 13 May 2011 09:21:28 -0400 Received: from msgrtphc03win.DMN1.FMR.COM ([10.95.11.183]) by msgmmkdr04win.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.7381); Fri, 13 May 2011 09:21:28 -0400 Received: from MSGRTPCCRE2WIN.DMN1.FMR.COM ([10.95.11.31]) by msgrtphc03win.DMN1.FMR.COM ([10.95.11.183]) with mapi; Fri, 13 May 2011 09:21:28 -0400 From: "Lee, Richard FTC" To: "philip.eardley@bt.com" , "tom111.taylor@bell.net" , "toby@moncaster.com" Date: Fri, 13 May 2011 09:21:24 -0400 Thread-Topic: [PCN] Can tunnels really terminate in the interior of a PCN domain? Thread-Index: AcwQxi3IXOID53nNQX6Fp4ZDbpE2UQAjEFaQAAZ6aYA= Message-ID: <3B4DBB0890AD6642BEAB7B3470FC18F970CAFD9D8B@MSGRTPCCRE2WIN.DMN1.FMR.COM> References: <4DCC08B3.1030205@informatik.uni-tuebingen.de> <001d01cc10c3$f4db6d70$de924850$@com> <9510D26531EF184D9017DF24659BB87F32AA002458@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32AA002458@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 13:21:28.0576 (UTC) FILETIME=[AAC22000:01CC1170] Cc: "pcn@ietf.org" Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 13:21:36 -0000 To all; I deal with strategic design for the enterprise A thought -- I see this as a handoff problem between 2 domains If the ingress node is in 1 PCN domain and the destination/egress node is i= n another PCN domain; you are assuming a level of trust that may not exist Wouldn't it be better to deal with it as a perimeter problem Ingress PCN-1 domain traverses across PCN-1 At the perimeter between PCN-1 and PCN-2, the egress node for the PCN-1 dom= ain marks the packets for PCN handling PCN-2 domain may or may not honor the marking If the PCN-2 domain acts on the marking; PCN-2 perimeter ingress marks PCN = for the PCN-2 domain The destination in the PCN-2 domain is the PCN-2 egress and appropriate res= ponses are sent within PCN-2, from PCN-2 to PCN-1 and within PCN-1 domains If the PCN-2 domain does not act on the marking no response is sent=20 Rich=20 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of phili= p.eardley@bt.com Sent: Friday, May 13, 2011 6:00 AM To: tom111.taylor@bell.net; toby@moncaster.com Cc: pcn@ietf.org Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN do= main? I spent a bit of time puzzling about such tunnels during PCN-architecture d= ays. I remember we had some discussion with David Black, and he was happy w= ith the approach written in rfc5559. Reading it again, it seems to be sayin= g In case (1), effectively treat it as having some PCN-ingress-node functiona= lity at the tunnel egress; In case (2), make sure that when it's eventually decapsulated, nothing in t= hat distant network will be confused. phil http://tools.ietf.org/html/rfc5559#section-4.7 << Potential issues arise for a "partially PCN-capable tunnel", ie, where only one tunnel endpoint is in the PCN-domain: 1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre- congestion. 2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated, which could potentially confuse nodes beyond the tunnel egress. In line with the solution for partially capable Diffserv tunnels in [RFC2983], the following rules are applied: o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above. o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above. Note that the above implies that one has to know, or determine, the characteristics of the other end of the tunnel as part of establishing it. >> -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: 12 May 2011 18:01 To: Toby Moncaster Cc: 'pcn' Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN do= main? FYI my query related to operational considerations. On 12/05/2011 12:45 PM, Toby Moncaster wrote: > Tom, > > I assume you're talking of tunnels that straddle the PCN-domain (start > outside and end inside). I've often puzzled about such things. > [PTT] Yes .... > > There is one argument that says having any traffic within the PCN-capable > DSCP destined for a PCN-interior node is impossible since by definition t= hat > makes it into a PCN-egress node. I think that may be what you're driving = at? > [PTT] Yes again. > Toby > ... _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Mon May 16 05:17:15 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD32EE06BD for ; Mon, 16 May 2011 05:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScwiOvFOE54L for ; Mon, 16 May 2011 05:17:15 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2BE06A4 for ; Mon, 16 May 2011 05:17:14 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 16 May 2011 13:17:10 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.227]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 16 May 2011 13:17:11 +0100 From: To: , , Date: Mon, 16 May 2011 13:17:09 +0100 Thread-Topic: [PCN] Can tunnels really terminate in the interior of a PCN domain? Thread-Index: AcwQxi3IXOID53nNQX6Fp4ZDbpE2UQAjEFaQAAZ6aYAAlXRu0A== Message-ID: <9510D26531EF184D9017DF24659BB87F32AA8AE741@EMV65-UKRD.domain1.systemhost.net> References: <4DCC08B3.1030205@informatik.uni-tuebingen.de> <001d01cc10c3$f4db6d70$de924850$@com> <9510D26531EF184D9017DF24659BB87F32AA002458@EMV65-UKRD.domain1.systemhost.net> <3B4DBB0890AD6642BEAB7B3470FC18F970CAFD9D8B@MSGRTPCCRE2WIN.DMN1.FMR.COM> In-Reply-To: <3B4DBB0890AD6642BEAB7B3470FC18F970CAFD9D8B@MSGRTPCCRE2WIN.DMN1.FMR.COM> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN domain? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 12:17:16 -0000 I'm sure you're right that it can be considered as a perimeter problem. when the group first started, we were thinking about the use case where the= re are 2 adjacent PCN-domains. The idea was to apply some CONEX-like techno= logy to this scenario, so as to enable PCN-domains to be interconnected, ev= en when the domains didn't trust each other. In order to simplify the WG's = scope, we decided to put this out of scope (well, initial scope, but I don'= t think people want to re-charter) Conex now has a WG, http://tools.ietf.org/wg/conex/=20 If i remember right, in RFC5559 we were thinking about tunnel from PCN-doma= in to non-PCN-domain (or vice-versa), rather than from one PCN-domain to an= other PCN-domain. Best wishes Phil -----Original Message----- From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM]=20 Sent: 13 May 2011 14:21 To: Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; toby@moncaster.com Cc: pcn@ietf.org Subject: RE: [PCN] Can tunnels really terminate in the interior of a PCN do= main? To all; I deal with strategic design for the enterprise A thought -- I see this as a handoff problem between 2 domains If the ingress node is in 1 PCN domain and the destination/egress node is i= n another PCN domain; you are assuming a level of trust that may not exist Wouldn't it be better to deal with it as a perimeter problem Ingress PCN-1 domain traverses across PCN-1 At the perimeter between PCN-1 and PCN-2, the egress node for the PCN-1 dom= ain marks the packets for PCN handling PCN-2 domain may or may not honor the marking If the PCN-2 domain acts on the marking; PCN-2 perimeter ingress marks PCN = for the PCN-2 domain The destination in the PCN-2 domain is the PCN-2 egress and appropriate res= ponses are sent within PCN-2, from PCN-2 to PCN-1 and within PCN-1 domains If the PCN-2 domain does not act on the marking no response is sent=20 Rich=20 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of phili= p.eardley@bt.com Sent: Friday, May 13, 2011 6:00 AM To: tom111.taylor@bell.net; toby@moncaster.com Cc: pcn@ietf.org Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN do= main? I spent a bit of time puzzling about such tunnels during PCN-architecture d= ays. I remember we had some discussion with David Black, and he was happy w= ith the approach written in rfc5559. Reading it again, it seems to be sayin= g In case (1), effectively treat it as having some PCN-ingress-node functiona= lity at the tunnel egress; In case (2), make sure that when it's eventually decapsulated, nothing in t= hat distant network will be confused. phil http://tools.ietf.org/html/rfc5559#section-4.7 << Potential issues arise for a "partially PCN-capable tunnel", ie, where only one tunnel endpoint is in the PCN-domain: 1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre- congestion. 2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated, which could potentially confuse nodes beyond the tunnel egress. In line with the solution for partially capable Diffserv tunnels in [RFC2983], the following rules are applied: o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above. o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above. Note that the above implies that one has to know, or determine, the characteristics of the other end of the tunnel as part of establishing it. >> -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: 12 May 2011 18:01 To: Toby Moncaster Cc: 'pcn' Subject: Re: [PCN] Can tunnels really terminate in the interior of a PCN do= main? FYI my query related to operational considerations. On 12/05/2011 12:45 PM, Toby Moncaster wrote: > Tom, > > I assume you're talking of tunnels that straddle the PCN-domain (start > outside and end inside). I've often puzzled about such things. > [PTT] Yes .... > > There is one argument that says having any traffic within the PCN-capable > DSCP destined for a PCN-interior node is impossible since by definition t= hat > makes it into a PCN-egress node. I think that may be what you're driving = at? > [PTT] Yes again. > Toby > ... _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From internet-drafts@ietf.org Sat May 21 04:15:39 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB8E06CD; Sat, 21 May 2011 04:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HONDob3jD5wh; Sat, 21 May 2011 04:15:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1819E068F; Sat, 21 May 2011 04:15:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110521111538.6750.52190.idtracker@ietfa.amsl.com> Date: Sat, 21 May 2011 04:15:38 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 11:15:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Encoding 3 PCN-States in the IP header using a single DS= CP Author(s) : Bob Briscoe Toby Moncaster Michael Menth Filename : draft-ietf-pcn-3-in-1-encoding-05.txt Pages : 16 Date : 2011-05-21 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding builds on the baseline encoding of RFC5696 and provides for three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-05.txt From toby@moncaster.com Sat May 21 04:20:48 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D285E06B7 for ; Sat, 21 May 2011 04:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vk8dfQWwyY7 for ; Sat, 21 May 2011 04:20:47 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 53A53E068F for ; Sat, 21 May 2011 04:20:46 -0700 (PDT) Received: from TobysHP (host86-156-248-136.range86-156.btcentralplus.com [86.156.248.136]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MU8aj-1QEhqP1Lw9-00QnGJ; Sat, 21 May 2011 13:20:44 +0200 From: "Toby Moncaster" To: References: <20110521111538.6750.52190.idtracker@ietfa.amsl.com> In-Reply-To: <20110521111538.6750.52190.idtracker@ietfa.amsl.com> Date: Sat, 21 May 2011 12:20:42 +0100 Message-ID: <002b01cc17a9$1f76c110$5e644330$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcwXqG5WfWgYK/geTK6UwSYqsDiW9QAAAoyw Content-Language: en-gb X-Provags-ID: V02:K0:Pn6lJeP2TnCUJ9lT70on48VJJj3oKknLUKeBDt5U9Tz MsZmXvs/U0zQZQ7T5UD6qywjORi590yOg5KfnvdNyAXPa0HC86 UhdZn4NFL4+oQKEWPUUyjIHl7qkUu+eQW411YSbchJ3dPJsWTO +1ocYGJgpQu75M4+3XHNGNxbG/xoK0OH1UoaXVRKoFpJrY/lni oovbyDRM3QvUQ9R9jgwShIBmoUbNr+iXf/3lFkERt4= Subject: Re: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 11:20:48 -0000 I finally finished updating this draft as agreed at the Prague meeting. Please can people give feedback, especially about the new appendix... Text: PDF: HTML: UNPG: XML: It really needs someone to go through it thoroughly as I didn't get round to doing it myself ;) There has been a parallel thread regarding what to do about RFC5696 which I will now try and resolve. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 21 May 2011 12:16 > To: i-d-announce@ietf.org > Cc: pcn@ietf.org > Subject: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Congestion and Pre- > Congestion Notification Working Group of the IETF. > > Title : Encoding 3 PCN-States in the IP header using a > single DSCP > Author(s) : Bob Briscoe > Toby Moncaster > Michael Menth > Filename : draft-ietf-pcn-3-in-1-encoding-05.txt > Pages : 16 > Date : 2011-05-21 > > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv > domain. > On every link in the PCN domain, the overall rate of the PCN-traffic > is metered, and PCN-packets are appropriately marked when certain > configured rates are exceeded. Egress nodes provide decision points > with information about the PCN-marks of PCN-packets which allows > them > to take decisions about whether to admit or block a new flow > request, > and to terminate some already admitted flows during serious pre- > congestion. > > This document specifies how PCN-marks are to be encoded into the IP > header by re-using the Explicit Congestion Notification (ECN) > codepoints within a PCN-domain. This encoding builds on the > baseline > encoding of RFC5696 and provides for three different PCN marking > states using a single DSCP: not-marked (NM), threshold-marked (ThM) > and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN > encoding. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding- > 05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding- > 05.txt > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From toby@moncaster.com Sat May 21 04:39:52 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4A6E066C for ; Sat, 21 May 2011 04:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iZnne-MJbDo for ; Sat, 21 May 2011 04:39:51 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1AE062B for ; Sat, 21 May 2011 04:39:50 -0700 (PDT) Received: from TobysHP (host86-156-248-136.range86-156.btcentralplus.com [86.156.248.136]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LkDdO-1Pq4g20aCI-00cKr3; Sat, 21 May 2011 13:39:48 +0200 From: "Toby Moncaster" To: , References: <4D9448F9.7040309@informatik.uni-tuebingen.de> <002e01cbef88$b1cc7b70$15657250$@com> <4D94EF65.20001@informatik.uni-tuebingen.de> <4D958E90.4060103@informatik.uni-tuebingen.de> <201104011222.p31CMCas029062@bagheera.jungle.bt.co.uk> <003e01cbf074$d2042270$760c6750$@com> <000c01cbfa92$38da9750$aa8fc5f0$@com> <201104150314.p3F3E8HU001775@bagheera.jungle.bt.co.uk> <000c01cbfb47$8c8ef520$a5acdf60$@com> <4DA81828.4090002@informatik.uni-tuebingen.de> <201104151450.p3FEoiab003742@bagheera.jungle.bt.co.uk> <000901cbfc13$ee81e720$cb85b560$@com> <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> <000c01cc0a3c$e2c29420$a847bc60$@com> <9510D26531EF184D9017DF24659BB87F32A9301EB3@EMV65-UKRD.domain1.systemhost.net> <001d01cc0a6c$415ab0b0$c4101210$@com> <9510D26531EF184D9017DF24659BB87F32A930207E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32A930207E@EMV65-UKRD.domain1.systemhost.net> Date: Sat, 21 May 2011 12:39:46 +0100 Message-ID: <002c01cc17ab$c92e1a30$5b8a4e90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acv8JidjJNrJ3s6YQ7W23VuGzoCftgOFYgxgAAo0HVAAAZCc0AACKuUgA02ipVA= Content-Language: en-gb X-Provags-ID: V02:K0:KhwB8wSZjZL208l2sDRKU45u0dLil5u2th2amBvRWIw /9xP2UHqucgleFr6a3fo1/GkgUaz/1pRtjNGDiab/MAYXYxPAb UG/3eIe+7Kas7VaYMHKyN19Uwa+yedLGkfFdZg7NT4DrgxM9Bu PRO6x9mI4/e+7McyQdcz6AvRq7963GDq9h3cjQe1l6wixobA5t qnk6pbfnpIokRNj9lqFObXg6ZWImJ9BtKc6NBhmw2M= Cc: pcn@ietf.org Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 11:39:52 -0000 I have now released the revised version of the 3-in-1 draft. After much thinking and pondering I reckon the only sensible thing regarding RFC5696 is to revise it (rather than deprecating it). There are two reasons for this, firstly the 3-in-1 encoding doesn't necessarily provide the cleanest approach for a single marking scheme (since it fixes which marker marks 01 and 11) and secondly there is still a desire among some to leave alternative encodings open. There are two routes to revising the document: (A) Changing it to a single-marking encoding but keep it as a standard. That requires: - deprecate the EXP encoding - remove the more irrelevant appendixes, and move the others into a -06 version of 3-in-1 (for instance all the discussion of which DSCP to use). (B) Change it to an experimental encoding but tighten the rules about it not being allowed in any other PCN-domain (in other words put the onus on experimenters to be careful). That requires: - update the rules on experimental schemes - Add relevant warning text and re-word it to be clear this is only for experiments - Move the DSCP related appendix to the 3-in-1 document Of the two options (A) is relatively easy and would be my preference. (B) requires lots of work and I would want a really convincing argument that schemes such as PSDM are of interest to an operator before we went down that route. In either case we are going to have to do some more work on 3-in-1, but hopefully mainly cut-and-paste... If I get another burst of energy today I may release a suggested draft for option (A)... Toby > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: 04 May 2011 17:17 > To: toby@moncaster.com; bob.briscoe@bt.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Revised 3-in-1 draft and status of RFC5696 > > Toby said: > It looks like we are going to have to create a completely new combined > document after all. > ... > In order to handle the two distinct cases you set out above I would > suggest > that such a document has two parts: a basic encoding (for single > marking > schemes) and a full encoding (for dual marking schemes). This would > make the > choice of encoding a configuration option similar to the option of > whether > to turn on the two marking schemes or not. > > Question - would this require any changes to any other documents? > > [phil] > I don't know whether a completely new combined doc is the best way. > Maybe the RFC editor can advise? > (an alternative might be to update the baseline so it just applied to > single marking (with EXP essentially deprecated) plus a new doc on 3- > in-1, or to update the baseline with changes so that it includes both > (ie defines EXP as per 3-in-1 or as deprecated). Anyway, this seems > "just" a process question. > > If it is a single doc, then the doc would split into 2 sections, with > parallel sub-sections (encoding, applicability, allowed transitions). > > I don't understand your comment about marking schemes (rfc5670 defines > one Metering behaviour, the marking section of that doc says " A PCN- > packet MUST be marked to reflect the metering results by > setting its encoding state appropriately, as specified by the > specific encoding scheme that applies in the PCN-domain." > > Which docs affected? > From technical point of view, I think all are ok. Edge behaviours > basically unaffected - clearly SM & CL refer to teh right sections > > RFC 5670 is unaffected, i think. There is one point only where there > might need to be thought -in section B.2 of rfc5670 (an Informative > appendix on Implementation Notes) (I think the wording of the new doc > should allow the text here still to be valid - anyway, the point is > extremely pedantic) From menth@informatik.uni-tuebingen.de Sat May 21 19:10:59 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CADE0677 for ; Sat, 21 May 2011 19:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVwUaYPFGSMC for ; Sat, 21 May 2011 19:10:57 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 94B8AE06BE for ; Sat, 21 May 2011 19:10:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3FA075284; Sat, 21 May 2011 23:28:47 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9txUc2LgQYu; Sat, 21 May 2011 23:28:43 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id EF81F49A7; Sat, 21 May 2011 23:28:42 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7971F1BDD102; Sat, 21 May 2011 23:28:33 +0200 (CEST) Message-ID: <4DD82E88.4090901@informatik.uni-tuebingen.de> Date: Sat, 21 May 2011 23:28:40 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Toby Moncaster References: <20110521111538.6750.52190.idtracker@ietfa.amsl.com> <002b01cc17a9$1f76c110$5e644330$@com> In-Reply-To: <002b01cc17a9$1f76c110$5e644330$@com> Content-Type: multipart/mixed; boundary="------------030307000701020902000109" Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 02:10:59 -0000 This is a multi-part message in MIME format. --------------030307000701020902000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Toby, I went through the doc. I have only a few corrections in the main body and some more in the appendix. It's mainly editorial to improve readability. Best wishes, Michael Am 21.05.2011 13:20, schrieb Toby Moncaster: > I finally finished updating this draft as agreed at the Prague meeting. > Please can people give feedback, especially about the new appendix... > > Text: > > PDF: > > HTML: > UNPG: > XML: > > > It really needs someone to go through it thoroughly as I didn't get round to > doing it myself ;) > > There has been a parallel thread regarding what to do about RFC5696 which I > will now try and resolve. > > Toby > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: 21 May 2011 12:16 >> To: i-d-announce@ietf.org >> Cc: pcn@ietf.org >> Subject: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-05.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Congestion and Pre- >> Congestion Notification Working Group of the IETF. >> >> Title : Encoding 3 PCN-States in the IP header using a >> single DSCP >> Author(s) : Bob Briscoe >> Toby Moncaster >> Michael Menth >> Filename : draft-ietf-pcn-3-in-1-encoding-05.txt >> Pages : 16 >> Date : 2011-05-21 >> >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv >> domain. >> On every link in the PCN domain, the overall rate of the PCN-traffic >> is metered, and PCN-packets are appropriately marked when certain >> configured rates are exceeded. Egress nodes provide decision points >> with information about the PCN-marks of PCN-packets which allows >> them >> to take decisions about whether to admit or block a new flow >> request, >> and to terminate some already admitted flows during serious pre- >> congestion. >> >> This document specifies how PCN-marks are to be encoded into the IP >> header by re-using the Explicit Congestion Notification (ECN) >> codepoints within a PCN-domain. This encoding builds on the >> baseline >> encoding of RFC5696 and provides for three different PCN marking >> states using a single DSCP: not-marked (NM), threshold-marked (ThM) >> and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN >> encoding. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding- >> 05.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding- >> 05.txt >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de --------------030307000701020902000109 Content-Type: application/msword; name="draft-ietf-pcn-3-in-1-encoding-05-MM.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-pcn-3-in-1-encoding-05-MM.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAoQAAAAAA AAAAEAAAowAAAAEAAAD+////AAAAAJ8AAACgAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAZ8AJBAAA8BK/AAAAAAAAEAAAAAAACAAA 4ZIAAA4AYmpiahBWEFYAAAAAAAAAAAAAAAAAAAAAAAAHBBYANOQAAHI8AQByPAEAdIcAAAAA AAAAAAAAAAAAAGwDAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAALcAAAAAADwIAAAAAAAAPAgAAJIVAAAAAAAAkhUAAAAAAACeFQAA nAEAABIYAAA4AAAAShgAABQAAAAAAAAAAAAAAP////8AAAAAXhgAAAAAAABeGAAAAAAAAF4Y AAAAAAAAXhgAAEQAAACiGAAABAEAAF4YAAAAAAAAGDIAAOABAACmGQAAAAAAAKYZAAAAAAAA phkAAAAAAACmGQAAAAAAAKYZAAAAAAAAgRoAAAAAAACBGgAAAAAAAIEaAAAAAAAAfzEAAAIA AACBMQAAAAAAAIExAAAAAAAAgTEAAAAAAACBMQAAAAAAAIExAAAAAAAAgTEAACQAAAD4MwAA sgIAAKo2AAA+AAAApTEAABUAAAAAAAAAAAAAAAAAAAAAAAAAkhUAAAwAAACBGgAAlgAAAAAA AAAAAAAAAAAAAAAAAACBGgAAAAAAAIEaAAAAAAAAFxsAAGQAAAB7GwAANAAAAKUxAAAAAAAA AAAAAAAAAACSFQAAAAAAAJIVAAAAAAAAphkAAAAAAAAAAAAAAAAAAKYZAADbAAAAujEAACIA AAAnMQAAAAAAACcxAAAAAAAAJzEAAAAAAACvGwAArAYAAJIVAAAAAAAAphkAAAAAAACSFQAA AAAAAKYZAAAAAAAAfzEAAAAAAAAAAAAAAAAAACcxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgRoAAAAAAAB/MQAAAAAAAAAAAAAAAAAA JzEAAAAAAAAAAAAAAAAAACcxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJzEAAAAAAACmGQAA AAAAAP////8AAAAAEJeTvv0XzAEAAAAAAAAAAP////8AAAAAWyIAAHQOAAAnMQAAAAAAAAAA AAAAAAAAazEAABQAAADcMQAAPAAAABgyAAAAAAAAJzEAAAAAAADoNgAAAAAAAM8wAABYAAAA 6DYAAAAAAAAnMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOg2AAAAAAAAAAAAAAAAAAA6FwAA 2AAAACcxAABEAAAAgRoAAAAAAACBGgAAAAAAACcxAAAAAAAAgRoAAAAAAACBGgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgRoAAAAAAACBGgAAAAAAAIEaAAAAAAAA pTEAAAAAAAClMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJzEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIEaAAAAAAAAgRoAAAAAAACBGgAA AAAAABgyAAAAAAAAgRoAAAAAAACBGgAAAAAAAIEaAAAAAAAAgRoAAAAAAAAAAAAAAAAAAP// //8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAA AAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAOg2AAAAAAAAgRoAAAAAAACBGgAA AAAAAIEaAAAAAAAAgRoAAAAAAACBGgAAAAAAAIEaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBGgAAAAAAAIEaAAAAAAAA gRoAAAAAAAA8CAAAHAwAAFgUAAA6AQAABQASAQAABwQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NDUNvbmdlc3Rpb24gYW5kIFByZS1Db25nZXN0aW9u ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQi4gQnJpc2NvZQ1Ob3RpZmljYXRp b24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQlQNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVC4gTW9uY2FzdGVyDUludGVuZGVkIHN0YXR1czogU3RhbmRhcmRz IFRyYWNrICAgICAgICAgICBNb25jYXN0ZXIgSW50ZXJuZXQgQ29uc3VsdGluZw1FeHBpcmVz OiBOb3ZlbWJlciAyMiwgMjAxMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTS4gTWVudGgNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFVuaXZlcnNpdHkgb2YgVHVlYmluZ2VuDSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1heSAyMSwgMjAxMQ0NDSAg ICAgICBFbmNvZGluZyAzIFBDTi1TdGF0ZXMgaW4gdGhlIElQIGhlYWRlciB1c2luZyBhIHNp bmdsZSBEU0NQDSAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXBjbi0zLWluLTEtZW5j b2RpbmctMDUNDUFic3RyYWN0DQ0gICBUaGUgb2JqZWN0aXZlIG9mIFByZS1Db25nZXN0aW9u IE5vdGlmaWNhdGlvbiAoUENOKSBpcyB0byBwcm90ZWN0IHRoZQ0gICBxdWFsaXR5IG9mIHNl cnZpY2UgKFFvUykgb2YgaW5lbGFzdGljIGZsb3dzIHdpdGhpbiBhIERpZmZzZXJ2IGRvbWFp bi4NICAgT24gZXZlcnkgbGluayBpbiB0aGUgUENOIGRvbWFpbiwgdGhlIG92ZXJhbGwgcmF0 ZSBvZiB0aGUgUENOLXRyYWZmaWMNICAgaXMgbWV0ZXJlZCwgYW5kIFBDTi1wYWNrZXRzIGFy ZSBhcHByb3ByaWF0ZWx5IG1hcmtlZCB3aGVuIGNlcnRhaW4NICAgY29uZmlndXJlZCByYXRl cyBhcmUgZXhjZWVkZWQuICBFZ3Jlc3Mgbm9kZXMgcHJvdmlkZSBkZWNpc2lvbiBwb2ludHMN ICAgd2l0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUENOLW1hcmtzIG9mIFBDTi1wYWNrZXRz IHdoaWNoIGFsbG93cyB0aGVtDSAgIHRvIHRha2UgZGVjaXNpb25zIGFib3V0IHdoZXRoZXIg dG8gYWRtaXQgb3IgYmxvY2sgYSBuZXcgZmxvdyByZXF1ZXN0LA0gICBhbmQgdG8gdGVybWlu YXRlIHNvbWUgYWxyZWFkeSBhZG1pdHRlZCBmbG93cyBkdXJpbmcgc2VyaW91cyBwcmUtDSAg IGNvbmdlc3Rpb24uDQ0gICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgUENOLW1hcmtz IGFyZSB0byBiZSBlbmNvZGVkIGludG8gdGhlIElQDSAgIGhlYWRlciBieSByZS11c2luZyB0 aGUgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikNICAgY29kZXBvaW50 cyB3aXRoaW4gYSBQQ04tZG9tYWluLiAgVGhpcyBlbmNvZGluZyBidWlsZHMgb24gdGhlIGJh c2VsaW5lDSAgIGVuY29kaW5nIG9mIFJGQzU2OTYgYW5kIHByb3ZpZGVzIGZvciB0aHJlZSBk aWZmZXJlbnQgUENOIG1hcmtpbmcNICAgc3RhdGVzIHVzaW5nIGEgc2luZ2xlIERTQ1A6IG5v dC1tYXJrZWQgKE5NKSwgdGhyZXNob2xkLW1hcmtlZCAoVGhNKQ0gICBhbmQgZXhjZXNzLXRy YWZmaWMtbWFya2VkIChFVE0pLiAgSGVuY2UsIGl0IGlzIGNhbGxlZCB0aGUgMy1pbi0xIFBD Tg0gICBlbmNvZGluZy4NDVN0YXR1cyBvZiB0aGlzIE1lbW8NDSAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNICAgcHJv dmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NDSAgIEludGVybmV0LURyYWZ0cyBhcmUg d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDSAgIFRhc2sg Rm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDSAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtDSAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0NICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDSAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55DSAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDSAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBv dGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINDSAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgMjIsIDIwMTEuDQ0NDUJyaXNjb2UsIGV0IGFs LiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTEgICAgICAgICAgICAgICBbUGFn ZSAxXQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgIDMtaW4tMSBQQ04gRW5jb2Rpbmcg ICAgICAgICAgICAgICAgICBNYXkgMjAxMQ0NDUNvcHlyaWdodCBOb3RpY2UNDSAgIENvcHly aWdodCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZQ0gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NDSAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWwNICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0gICAoaHR0 cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRh dGUgb2YNICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzDSAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJp Z2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0gICB0byB0aGlzIGRvY3VtZW50 LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0g ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA0LmUgb2YNICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDSAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZS4NDQ1UYWJsZSBvZiBDb250ZW50cw0NICAgMS4gIEludHJvZHVj dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzDSAgICAgMS4xLiAgQ2hhbmdlcyBpbiBUaGlzIFZlcnNpb24gKHRvIGJlIHJlbW92ZWQg YnkgUkZDIEVkaXRvcikgIC4gLiAgNA0gICAyLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNICAgICAyLjEuICBU ZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA1DSAgIDMuICBSZXF1aXJlbWVudHMgZm9yIGFuZCBBcHBsaWNhYmlsaXR5IG9mIDMt aW4tMSBQQ04gRW5jb2RpbmcgIC4gLiAgNQ0gICAgIDMuMS4gIFBDTiBSZXF1aXJlbWVudHMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNICAgICAzLjIu ICBSZXF1aXJlbWVudHMgSW1wb3NlZCBieSBCYXNlbGluZSBFbmNvZGluZyAgLiAuIC4gLiAu IC4gLiAuICA2DSAgICAgMy4zLiAgQXBwbGljYWJpbGl0eSBvZiAzLWluLTEgUENOIEVuY29k aW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0gICA0LiAgRGVmaW5pdGlvbiBvZiAzLWlu LTEgUENOIEVuY29kaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNICAgNS4g IEJlaGF2aW91ciBvZiBhIFBDTiBOb2RlIENvbXBsaWFudCB3aXRoIHRoZSAzLWluLTEgUENO DSAgICAgICBFbmNvZGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOA0gICA2LiAgQmFja3dhcmQgQ29tcGF0aWJpbGl0eSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNICAgICA2LjEuICBCYWNr d2FyZCBDb21wYXRpYmlsaXR5IHdpdGggUHJlLWV4aXN0aW5nIFBDTg0gICAgICAgICAgIElt cGxlbWVudGF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDkNICAgICA2LjIuICBSZWNvbW1lbmRhdGlvbnMgZm9yIHRoZSBVc2Ugb2YgUENOIEVu Y29kaW5nIFNjaGVtZXMgIC4gLiAuICA5DSAgICAgICA2LjIuMS4gIFVzZSBvZiBCb3RoIEV4 Y2Vzcy1UcmFmZmljLU1hcmtpbmcgYW5kDSAgICAgICAgICAgICAgIFRocmVzaG9sZC1NYXJr aW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0gICAgICAgNi4y LjIuICBVbmlxdWUgVXNlIG9mIEV4Y2Vzcy1UcmFmZmljLU1hcmtpbmcgLiAuIC4gLiAuIC4g LiAuIC4gMTANICAgICAgIDYuMi4zLiAgVW5pcXVlIFVzZSBvZiBUaHJlc2hvbGQtTWFya2lu ZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDSAgIDcuICBJQU5BIENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0gICA4LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTANICAgOS4gIENvbmNsdXNpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDSAgIDEwLiBBY2tub3dsZWRnZW1lbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0gICAx MS4gQ29tbWVudHMgU29saWNpdGVkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTENICAgMTIuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDSAgICAgMTIuMS4gTm9ybWF0aXZl IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0g ICAgIDEyLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTINICAgQXBwZW5kaXggQS4gIENvLWV4aXN0ZW5jZSBvZiBFQ04g YW5kIFBDTiAoaW5mb3JtYXRpdmUpIC4gLiAuIC4gLiAuIDEzDSAgIEF1dGhvcnMnIEFkZHJl c3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NQ0NDQ0NQnJpc2NvZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMiwgMjAx MSAgICAgICAgICAgICAgIFtQYWdlIDJdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg My1pbi0xIFBDTiBFbmNvZGluZyAgICAgICAgICAgICAgICAgIE1heSAyMDExDQ0NMS4gIElu dHJvZHVjdGlvbg0NICAgVGhlIG9iamVjdGl2ZSBvZiBQcmUtQ29uZ2VzdGlvbiBOb3RpZmlj YXRpb24gKFBDTikgW1JGQzU1NTldIGlzIHRvDSAgIHByb3RlY3QgdGhlIHF1YWxpdHkgb2Yg c2VydmljZSAoUW9TKSBvZiBpbmVsYXN0aWMgZmxvd3Mgd2l0aGluIGENICAgRGlmZnNlcnYg ZG9tYWluLCBpbiBhIHNpbXBsZSwgc2NhbGFibGUsIGFuZCByb2J1c3QgZmFzaGlvbi4gIFR3 bw0gICBtZWNoYW5pc21zIGFyZSB1c2VkOiBhZG1pc3Npb24gY29udHJvbCwgdG8gZGVjaWRl IHdoZXRoZXIgdG8gYWRtaXQgb3INICAgYmxvY2sgYSBuZXcgZmxvdyByZXF1ZXN0LCBhbmQg ZmxvdyB0ZXJtaW5hdGlvbiB0byB0ZXJtaW5hdGUgc29tZQ0gICBleGlzdGluZyBmbG93cyBk dXJpbmcgc2VyaW91cyBwcmUtY29uZ2VzdGlvbi4gIFRvIGFjaGlldmUgdGhpcywgdGhlDSAg IG92ZXJhbGwgcmF0ZSBvZiBQQ04tdHJhZmZpYyBpcyBtZXRlcmVkIG9uIGV2ZXJ5IGxpbmsg aW4gdGhlIGRvbWFpbiwNICAgYW5kIFBDTi1wYWNrZXRzIGFyZSBhcHByb3ByaWF0ZWx5IG1h cmtlZCB3aGVuIGNlcnRhaW4gY29uZmlndXJlZA0gICByYXRlcyBhcmUgZXhjZWVkZWQuICBU aGVzZSBjb25maWd1cmVkIHJhdGVzIGFyZSBiZWxvdyB0aGUgcmF0ZSBvZiB0aGUNICAgbGlu ayB0aHVzIHByb3ZpZGluZyBub3RpZmljYXRpb24gdG8gYm91bmRhcnkgbm9kZXMgYWJvdXQg b3ZlcmxvYWRzDSAgIGJlZm9yZSBhbnkgcmVhbCBjb25nZXN0aW9uIG9jY3VycyAoaGVuY2Ug InByZS1jb25nZXN0aW9uDSAgIG5vdGlmaWNhdGlvbiIpLg0NICAgW1JGQzU2NzBdIHByb3Zp ZGVzIGZvciB0d28gbWV0ZXJpbmcgYW5kIG1hcmtpbmcgZnVuY3Rpb25zIHRoYXQgYXJlDSAg IGNvbmZpZ3VyZWQgd2l0aCByZWZlcmVuY2UgcmF0ZXMuICBUaHJlc2hvbGQtbWFya2luZyBt YXJrcyBhbGwgUENODSAgIHBhY2tldHMgb25jZSB0aGVpciB0cmFmZmljIHJhdGUgb24gYSBs aW5rIGV4Y2VlZHMgdGhlIGNvbmZpZ3VyZWQNICAgcmVmZXJlbmNlIHJhdGUgKFBDTi10aHJl c2hvbGQtcmF0ZSkuICBFeGNlc3MtdHJhZmZpYy1tYXJraW5nIG1hcmtzDSAgIG9ubHkgdGhv c2UgUENOIHBhY2tldHMgdGhhdCBleGNlZWQgdGhlIGNvbmZpZ3VyZWQgcmVmZXJlbmNlIHJh dGUNICAgKFBDTi1leGNlc3MtcmF0ZSkuICBUaGUgUENOLWV4Y2Vzcy1yYXRlIGlzIHR5cGlj YWxseSBsYXJnZXIgdGhhbiB0aGUNICAgUENOLXRocmVzaG9sZC1yYXRlIFtSRkM1NTU5XS4g IEVncmVzcyBub2RlcyBtb25pdG9yIHRoZSBQQ04tbWFya3Mgb2YNICAgcmVjZWl2ZWQgUENO LXBhY2tldHMgYW5kIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFBDTi1tYXJrcyB0 bw0gICBkZWNpc2lvbiBwb2ludHMgd2hpY2ggdGFrZSBkZWNpc2lvbnMgYWJvdXQgZmxvdyBh ZG1pc3Npb24gYW5kDSAgIHRlcm1pbmF0aW9uIG9uIHRoaXMgYmFzaXMgW0ktRC5pZXRmLXBj bi1jbC1lZGdlLWJlaGF2aW91cl0sDSAgIFtJLUQuaWV0Zi1wY24tc20tZWRnZS1iZWhhdmlv dXJdLg0NICAgVGhlIGJhc2VsaW5lIGVuY29kaW5nIGRlZmluZWQgaW4gW1JGQzU2OTZdIGRl c2NyaWJlcyBob3cgdHdvIFBDTg0gICBtYXJraW5nIHN0YXRlcyAoTm90LW1hcmtlZCBhbmQg UENOLU1hcmtlZCkgY2FuIGJlIGVuY29kZWQgdXNpbmcgYQ0gICBzaW5nbGUgRGlmZnNlcnYg Y29kZXBvaW50LiAgSXQgYWxzbyBwcm92aWRlcyBhbiBleHBlcmltZW50YWwNICAgY29kZXBv aW50IChFWFApLCBhbG9uZyB3aXRoIGd1aWRlbGluZXMgZm9yIHVzZSBvZiB0aGF0IGNvZGVw b2ludC4gIFRvDSAgIHN1cHBvcnQgdGhlIGFwcGxpY2F0aW9uIG9mIHR3byBkaWZmZXJlbnQg bWFya2luZyBhbGdvcml0aG1zIGluIGEgUENOLQ0gICBkb21haW4sIGZvciBleGFtcGxlIGFz IHJlcXVpcmVkIGluIFtJLUQuaWV0Zi1wY24tY2wtZWRnZS1iZWhhdmlvdXJdLA0gICB0aHJl ZSBQQ04gbWFya2luZyBzdGF0ZXMgYXJlIG5lZWRlZC4gIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGFuDSAgIGV4dGVuc2lvbiB0byB0aGUgYmFzZWxpbmUgZW5jb2RpbmcgdGhhdCB1c2Vz IHRoZSBFWFAgY29kZXBvaW50IHRvDSAgIHByb3ZpZGUgYSB0aGlyZCBQQ04gbWFya2luZyBz dGF0ZSBpbiB0aGUgSVAgaGVhZGVyLCBzdGlsbCB1c2luZyBhDSAgIHNpbmdsZSBEaWZmc2Vy diBjb2RlcG9pbnQuICBUaGlzIGVuY29kaW5nIHNjaGVtZSBpcyBjYWxsZWQgIjMtaW4tMQ0g ICBQQ04gZW5jb2RpbmciLg0NICAgVGhpcyBkb2N1bWVudCBvbmx5IGNvbmNlcm5zIHRoZSBQ Q04gd2lyZSBwcm90b2NvbCBlbmNvZGluZyBmb3IgYWxsIElQDSAgIGhlYWRlcnMsIHdoZXRo ZXIgSVB2NCBvciBJUHY2LiAgSXQgbWFrZXMgbm8gY2hhbmdlcyBvcg0gICByZWNvbW1lbmRh dGlvbnMgY29uY2VybmluZyBhbGdvcml0aG1zIGZvciBjb25nZXN0aW9uIG1hcmtpbmcgb3IN ICAgY29uZ2VzdGlvbiByZXNwb25zZS4gIE90aGVyIGRvY3VtZW50cyBkZWZpbmUgdGhlIFBD TiB3aXJlIHByb3RvY29sDSAgIGZvciBvdGhlciBoZWFkZXIgdHlwZXMuICBGb3IgZXhhbXBs ZSwgdGhlIE1QTFMgZW5jb2RpbmcgaXMgZGVmaW5lZCBpbg0gICBbUkZDNTEyOV0gYW5kIEFw cGVuZGl4IEEgb2YgdGhhdCBkb2N1bWVudCBwcm92aWRlcyBhbiBpbmZvcm1hdGl2ZQ0gICBl eGFtcGxlIGZvciBhIG1hcHBpbmcgYmV0d2VlbiB0aGUgZW5jb2RpbmdzIGluIElQIGFuZCBp biBNUExTLg0NDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjIsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAzXQ0MDUludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAgICAgICAgICAgICBNYXkgMjAxMQ0N DTEuMS4gIENoYW5nZXMgaW4gVGhpcyBWZXJzaW9uICh0byBiZSByZW1vdmVkIGJ5IFJGQyBF ZGl0b3IpDQ0gICBGcm9tIGRyYWZ0LWlldGYtcGNuLTMtaW4tMS1lbmNvZGluZy0wNCB0byAt MDU6DQ0gICAgICAqICBEcmFmdCBtb3ZlZCB0byBzdGFuZGFyZHMgdHJhY2sgYXMgcGVyIHdv cmtpbmcgZ3JvdXANICAgICAgICAgZGlzY3Vzc2lvbnMuDQ0gICAgICAqICBBZGRlZCBBcHBl bmRpeCBBIGRpc2N1c3NpbmcgRUNOIGhhbmRsaW5nIGluIHRoZSBQQ04tZG9tYWluLg0NICAg ICAgKiAgQ2xhcmlmaWVkIHRoYXQgdGhpcyBkb2N1bWVudCBtb2RpZmllcyBbUkZDNTY5Nl0u DQ0gICAgICAqICAuLi4uLi4uDQ0gICBGcm9tIGRyYWZ0LWlldGYtcGNuLTMtaW4tMS1lbmNv ZGluZy0wMyB0byAtMDQ6DQ0gICAgICAqICBVcGRhdGVkIGRvY3VtZW50IHRvIHJlZmxlY3Qg UkZDNjA0MC4NDSAgICAgICogIFJlLXdyb3RlIGludHJvZHVjdGlvbi4NDSAgICAgICogIFJl LXdyb3RlIHNlY3Rpb24gb24gYXBwbGljYWJpbGl0eS4NDSAgICAgICogIFJlLXdyb3RlIHNl Y3Rpb24gb24gY2hvb3NpbmcgZW5jb2Rpbmcgc2NoZW1lLg0NICAgICAgKiAgVXBkYXRlZCBh dXRob3IgZGV0YWlscy4NDSAgIEZyb20gZHJhZnQtaWV0Zi1wY24tMy1pbi0xLWVuY29kaW5n LTAyIHRvIC0wMzoNDSAgICAgICogIENvcnJlY3RlZCBtaXN0YWtlcyBpbiBpbnRyb2R1Y3Rp b24gYW5kIGltcHJvdmVkIG92ZXJhbGwNICAgICAgICAgcmVhZGFiaWxpdHkuDQ0gICAgICAq ICBBZGRlZCBuZXcgdGVybWlub2xvZ3kuDQ0gICAgICAqICBSZXdyb3RlIGEgZ29vZCBwYXJ0 IG9mIFNlY3Rpb24gNCBhbmQgNSB0byBhY2hpZXZlIG1vcmUgY2xhcml0eS4NDSAgICAgICog IEFkZGVkIGFwcGVuZGl4IGV4cGxhaW5pbmcgd2hlbiB0byB1c2Ugd2hpY2ggZW5jb2Rpbmcg c2NoZW1lIGFuZA0gICAgICAgICBob3cgdG8gZW5jb2RlIHRoZW0gaW4gTVBMUyBzaGltIGhl YWRlcnMuDQ0gICAgICAqICBBZGRlZCBuZXcgY28tYXV0aG9yLg0NICAgRnJvbSBkcmFmdC1p ZXRmLXBjbi0zLWluLTEtZW5jb2RpbmctMDEgdG8gLTAyOg0NICAgICAgKiAgQ29ycmVjdGVk IG1pc3Rha2UgaW4gaW50cm9kdWN0aW9uLCB3aGljaCB3cm9uZ2x5IHN0YXRlZCB0aGF0DSAg ICAgICAgIHRoZSB0aHJlc2hvbGQtdHJhZmZpYyByYXRlIGlzIGhpZ2hlciB0aGFuIHRoZSBl eGNlc3MtdHJhZmZpYw0gICAgICAgICByYXRlLiAgT3RoZXIgbWlub3IgY29ycmVjdGlvbnMu DQ0gICAgICAqICBVcGRhdGVkIGFja3MgJiByZWZzLg0NDQ0NDUJyaXNjb2UsIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA0 XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAg ICAgICAgICAgICAgICBNYXkgMjAxMQ0NDSAgIEZyb20gZHJhZnQtaWV0Zi1wY24tMy1pbi0x LWVuY29kaW5nLTAwIHRvIC0wMToNDSAgICAgICogIEFsdGVyZWQgdGhlIHdvcmRpbmcgdG8g bWFrZSBzZW5zZSBpZg0gICAgICAgICBkcmFmdC1pZXRmLXRzdndnLWVjbi10dW5uZWwgbW92 ZXMgdG8gcHJvcG9zZWQgc3RhbmRhcmQuDQ0gICAgICAqICBSZWZlcmVuY2VzIHVwZGF0ZWQN DSAgIEZyb20gZHJhZnQtYnJpc2NvZS1wY24tMy1pbi0xLWVuY29kaW5nLTAwIHRvDSAgIGRy YWZ0LWlldGYtcGNuLTMtaW4tMS1lbmNvZGluZy0wMDoNDSAgICAgICogIEZpbGVuYW1lIGNo YW5nZWQgdG8gZHJhZnQtaWV0Zi1wY24tMy1pbi0xLWVuY29kaW5nLg0NICAgICAgKiAgSW50 cm9kdWN0aW9uIGFsdGVyZWQgdG8gaW5jbHVkZSBuZXcgdGVtcGxhdGUgZGVzY3JpcHRpb24g b2YNICAgICAgICAgUENOLg0NICAgICAgKiAgUmVmZXJlbmNlcyB1cGRhdGVkLg0NICAgICAg KiAgVGVybWlub2xvZ3kgYnJvdWdodCBpbnRvIGxpbmUgd2l0aCBbUkZDNTY3MF0uDQ0gICAg ICAqICBNaW5vciBjb3JyZWN0aW9ucy4NDQ0yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlDQ0g ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsDSAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDSAgIGRvY3VtZW50IGFyZSB0byBi ZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0NMi4xLiAgVGVybWlu b2xvZ3kNDSAgIEdlbmVyYWwgUENOLXJlbGF0ZWQgdGVybWlub2xvZ3kgaXMgZGVmaW5lZCBp biB0aGUgUENOIGFyY2hpdGVjdHVyZQ0gICBbUkZDNTU1OV0sIGFuZCB0ZXJtaW5vbG9neSBz cGVjaWZpYyB0byBwYWNrZXQgZW5jb2RpbmcgaXMgZGVmaW5lZCBpbg0gICB0aGUgUENOIGJh c2VsaW5lIGVuY29kaW5nIFtSRkM1Njk2XS4gIEFkZGl0aW9uYWwgdGVybWlub2xvZ3kgaXMN ICAgZGVmaW5lZCBiZWxvdy4NDSAgIFBDTiBlbmNvZGluZzogIG1hcHBpbmcgb2YgUENOIG1h cmtpbmcgc3RhdGVzIHRvIHNwZWNpZmljIGNvZGVwb2ludHMNICAgICAgaW4gdGhlIHBhY2tl dCBoZWFkZXIuDQ0NMy4gIFJlcXVpcmVtZW50cyBmb3IgYW5kIEFwcGxpY2FiaWxpdHkgb2Yg My1pbi0xIFBDTiBFbmNvZGluZw0NMy4xLiAgUENOIFJlcXVpcmVtZW50cw0NICAgSW4gYWNj b3JkYW5jZSB3aXRoIHRoZSBQQ04gYXJjaGl0ZWN0dXJlIFtSRkM1NTU5XSwgUENOLWluZ3Jl c3Mtbm9kZXMNICAgY29udHJvbCBwYWNrZXRzIGVudGVyaW5nIGEgUENOLWRvbWFpbi4gIFBh Y2tldHMgYmVsb25naW5nIHRvIFBDTi0NICAgY29udHJvbGxlZCBmbG93cyBhcmUgc3ViamVj dCB0byBQQ04tbWV0ZXJpbmcgYW5kIC1tYXJraW5nLCBhbmQgUENOLQ0gICBpbmdyZXNzLW5v ZGVzIG1hcmsgdGhlbSBhcyBOb3QtbWFya2VkIChQQ04tY29sb3VyaW5nKS4gIEFueSBub2Rl IGluDSAgIHRoZSBQQ04tZG9tYWluIG1heSBwZXJmb3JtIFBDTi1tZXRlcmluZyBhbmQgLW1h cmtpbmcgYW5kIG1hcmsgUENOLQ0NDQ1CcmlzY29lLCBldCBhbC4gICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIyLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNV0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29kaW5nICAgICAgICAgICAgICAgICAg TWF5IDIwMTENDQ0gICBwYWNrZXRzIGlmIG5lZWRlZC4gIFRoZXJlIGFyZSB0d28gZGlmZmVy ZW50IG1ldGVyaW5nIGFuZCBtYXJraW5nDSAgIHNjaGVtZXM6IHRocmVzaG9sZC1tYXJraW5n IGFuZCBleGNlc3MtdHJhZmZpYy1tYXJraW5nIFtSRkM1NjcwXS4NICAgU29tZSBlZGdlIGJl aGF2aW9ycyByZXF1aXJlIG9ubHkgYSBzaW5nbGUgbWFya2luZyBzY2hlbWUNICAgW0ktRC5p ZXRmLXBjbi1zbS1lZGdlLWJlaGF2aW91cl0sIG90aGVycyByZXF1aXJlIGJvdGgNICAgW0kt RC5pZXRmLXBjbi1jbC1lZGdlLWJlaGF2aW91cl0uICBJbiB0aGUgbGF0dGVyIGNhc2UsIHRo cmVlIFBDTg0gICBtYXJraW5nIHN0YXRlcyBhcmUgbmVlZGVkOiBub3QtbWFya2VkIChOTSkg dG8gaW5kaWNhdGUgbm90LW1hcmtlZA0gICBwYWNrZXRzLCB0aHJlc2hvbGQtbWFya2VkIChU aE0pIHRvIGluZGljYXRlIHBhY2tldHMgbWFya2VkIGJ5IHRoZQ0gICB0aHJlc2hvbGQtbWFy a2VyLCBhbmQgZXhjZXNzLXRyYWZmaWMtbWFya2VkIChFVE0pIHRvIGluZGljYXRlIHBhY2tl dHMNICAgbWFya2VkIGJ5IHRoZSBleGNlc3MtdHJhZmZpYy1tYXJrZXIgW1JGQzU2NzBdLiAg VGhyZXNob2xkLW1hcmtpbmcgYW5kDSAgIGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcgYXJlIGNv bmZpZ3VyZWQgdG8gc3RhcnQgbWFya2luZyBwYWNrZXRzIGF0DSAgIGRpZmZlcmVudCBsb2Fk IGNvbmRpdGlvbnMsIHNvIG9uZSBtYXJraW5nIHNjaGVtZSBpbmRpY2F0ZXMgbW9yZQ0gICBz ZXZlcmUgcHJlLWNvbmdlc3Rpb24gdGhhbiB0aGUgb3RoZXIuICBUaGVyZWZvcmUsIGEgZm91 cnRoIFBDTg0gICBtYXJraW5nIHN0YXRlIGluZGljYXRpbmcgdGhhdCBhIHBhY2tldCBpcyBt YXJrZWQgYnkgYm90aCBtYXJrZXJzIGlzDSAgIG5vdCBuZWVkZWQuICBIb3dldmVyIGEgZm91 cnRoIGNvZGVwb2ludCBpcyByZXF1aXJlZCB0byBpbmRpY2F0ZQ0gICBwYWNrZXRzIHRoYXQg YXJlIG5vdCBQQ04tY2FwYWJsZSAodGhlIG5vdC1QQ04gY29kZXBvaW50KS4NDSAgIEluIGFs bCBjdXJyZW50IFBDTiBlZGdlIGJlaGF2aW9ycyB0aGF0IHVzZSB0d28gbWFya2luZyBzY2hl bWVzDSAgIFtSRkM1NTU5XSwgW0ktRC5pZXRmLXBjbi1jbC1lZGdlLWJlaGF2aW91cl0sIGV4 Y2Vzcy10cmFmZmljLW1hcmtpbmcNICAgaXMgY29uZmlndXJlZCB3aXRoIGEgbGFyZ2VyIHJl ZmVyZW5jZSByYXRlIHRoYW4gdGhyZXNob2xkLW1hcmtpbmcuDSAgIFdlIHRha2UgdGhpcyBh cyBhIHJ1bGUgYW5kIGRlZmluZSBleGNlc3MtdHJhZmZpYy1tYXJrZWQgYXMgYSBtb3JlDSAg IHNldmVyZSBQQ04tbWFyayB0aGFuIHRocmVzaG9sZC1tYXJrZWQuDQ0zLjIuICBSZXF1aXJl bWVudHMgSW1wb3NlZCBieSBCYXNlbGluZSBFbmNvZGluZw0NICAgVGhlIGJhc2VsaW5lIGVu Y29kaW5nIHNjaGVtZSBbUkZDNTY5Nl0gd2FzIGRlZmluZWQgc28gdGhhdCBpdCBjb3VsZA0g ICBiZSBleHRlbmRlZCB0byBhY2NvbW1vZGF0ZSBhbiBhZGRpdGlvbmFsIG1hcmtpbmcgc3Rh dGUuICBJdCBwcm92aWRlcw0gICBydWxlcyB0byBlbWJlZCB0aGUgZW5jb2Rpbmcgb2YgdHdv IFBDTiBzdGF0ZXMgaW4gdGhlIElQIGhlYWRlci4NICAgRmlndXJlIDEgc2hvd3MgdGhlIHN0 cnVjdHVyZSBvZiB0aGUgZm9ybWVyIHR5cGUtb2Ytc2VydmljZSBmaWVsZC4gIEl0DSAgIGNv bnRhaW5zIHRoZSA2LWJpdCBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyAoRFMpIGZpZWxkIHRo YXQgaG9sZHMgdGhlDSAgIERTIGNvZGVwb2ludCAoRFNDUCkgW1JGQzI0NzRdIGFuZCB0aGUg Mi1iaXQgRUNOIGZpZWxkIFtSRkMzMTY4XS4NDSAgICAgICAgICAgIDAgICAgIDEgICAgIDIg ICAgIDMgICAgIDQgICAgIDUgICAgIDYgICAgIDcNICAgICAgICAgKy0tLS0tKy0tLS0tKy0t LS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKw0gICAgICAgICB8ICAgICAgICAg ICAgICBEUyBGSUVMRCAgICAgICAgICAgICB8IEVDTiBGSUVMRCB8DSAgICAgICAgICstLS0t LSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSsNDSAgICAgICBG aWd1cmUgMTogU3RydWN0dXJlIG9mIHRoZSBmb3JtZXIgdHlwZS1vZi1zZXJ2aWNlIGZpZWxk IGluIElQDQ0gICBCYXNlbGluZSBlbmNvZGluZyBkZWZpbmVzIHRoYXQgdGhlIERTQ1AgbXVz dCBiZSBzZXQgdG8gYSBQQ04tDSAgIGNvbXBhdGlibGUgRFNDUCBuIGZvciBQQ04gdHJhZmZp YyBhbmQgdGhlIEVDTi1maWVsZCBbUkZDMzE2OF0gdGhlbiBpbmRpY2F0ZXMgdGhlIHNwZWNp ZmljDSAgIFBDTi1tYXJrLiAgQmFzZWxpbmUgZW5jb2Rpbmcgb2ZmZXJzIGZvdXIgcG9zc2li bGUgZW5jb2Rpbmcgc3RhdGVzDSAgIHdpdGhpbiBhIHNpbmdsZSBEU0NQIHdpdGggdGhlIGZv bGxvd2luZyByZXN0cmljdGlvbnMuDQ0gICBvICBDb2RlcG9pbnQgYDAwJyAobm90LUVDVCkg aXMgdXNlZCB0byBpbmRpY2F0ZSBub24tUENOIHRyYWZmaWMgYXMNICAgICAgIm5vdC1QQ04i LiAgVGhpcyBhbGxvd3MgYm90aCBQQ04gYW5kIG5vbi1QQ04gdHJhZmZpYyB0byB1c2UgdGhl DSAgICAgIHNhbWUgRFNDUC4NDQ0NDQ1CcmlzY29lLCBldCBhbC4gICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIyLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNl0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29kaW5nICAgICAgICAgICAgICAgICAg TWF5IDIwMTENDQ0gICBvICBDb2RlcG9pbnQgYDEwJyAoRUNUKDApKSBpcyB1c2VkIHRvIGlu ZGljYXRlIE5vdC1tYXJrZWQgUENODSAgICAgIHRyYWZmaWMuDQ0gICBvICBDb2RlcG9pbnQg YDExJyAoQ0UpIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhlIG1vc3Qgc2V2ZXJlIFBDTi1tYXJr Lg0NICAgbyAgQ29kZXBvaW50IGAwMScgKEVDVCgxKSkgaXMgYXZhaWxhYmxlIGZvciBleHBl cmltZW50YWwgdXNlIGFuZCBtYXkNICAgICAgYmUgcmUtdXNlZCBieSBvdGhlciBQQ04gZW5j b2RpbmdzIHN1Y2ggYXMgdGhlIHByZXNlbnRseSBkZWZpbmVkDSAgICAgIDMtaW4tMSBQQ04g ZW5jb2RpbmcgKHN1YmplY3QgdG8gdGhlIHJ1bGVzIGRlZmluZWQgaW4gW1JGQzU2OTZdKS4N DSAgIFtSRkM2MDQwXSBkZWZpbmVzIHJ1bGVzIGZvciB0aGUgZW5jYXBzdWxhdGlvbiBhbmQg ZGVjYXBzdWxhdGlvbiBvZg0gICBFQ04gbWFya2luZ3Mgd2l0aGluIElQLWluLUlQIHR1bm5l bHMuICBUaGlzIFJGQyByZW1vdmVzIHNvbWUgb2YgdGhlDSAgIGNvbnN0cmFpbnRzIHRoYXQg ZXhpc3RlZCB3aGVuIFtSRkM1Njk2XSB3YXMgd3JpdHRlbi4gIEhhcHBpbHkgdGhlDSAgIHJ1 bGVzIGZvciB1c2Ugb2YgdGhlIEVYUCBjb2RlcG9pbnQgYXJlIGZ1bGx5IGNvbXBhdGlibGUg d2l0aA0gICBbUkZDNjA0MF0uIAUgSW4gcGFydGljdWxhciwgdGhlIHJlbGF0aXZlIHNldmVy aXR5IG9mIGVhY2ggbWFya2luZyBpcw0gICB0aGUgc2FtZTogQ0UgKFBNKSBpcyBtb3JlIHNl dmVyZSB0aGFuIEVDVCgxKSAoRVhQKSBpcyBtb3JlIHNldmVyZQ0gICB0aGFuIEVDVCgwKSAo Tk0pLiAgVGhpcyBpcyBkaXNjdXNzZWQgaW4gbW9yZSBkZXRhaWwgaW4gYm90aCB0aGUNICAg YmFzZWxpbmUgZW5jb2RpbmcgZG9jdW1lbnQgW1JGQzU2OTZdIGFuZCBpbg0gICBbSS1ELmll dGYtcGNuLWVuY29kaW5nLWNvbXBhcmlzb25dLg0NMy4zLiAgQXBwbGljYWJpbGl0eSBvZiAz LWluLTEgUENOIEVuY29kaW5nDQ0gICBUaGUgMy1pbi0xIGVuY29kaW5nIGlzIGFwcGxpY2Fi bGUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0d28gbWFya2luZw0gICBzY2hlbWVzIGFyZSBiZWlu ZyB1c2VkIGluIHRoZSBQQ04tZG9tYWluLiAgSW4gc29tZSBjaXJjdW1zdGFuY2VzIGl0DSAg IGNhbiBhbHNvIGJlIHVzZWQgaW4gUENOLWRvbWFpbnMgd2l0aCBvbmx5IGEgc2luZ2xlIG1h cmtpbmcgc2NoZW1lIGluDSAgIHVzZS4gIEZ1cnRoZXIgZ3VpZGFuY2Ugb24gY2hvb3Npbmcg YW4gZW5jb2Rpbmcgc2NoZW1lIGNhbiBiZSBmb3VuZCBpbg0gICBTZWN0aW9uIDYuMi4gIEFs bCBub2RlcyB0dW5uZWwgZGVjYXBzdWxhdG9ycyB3aXRoaW4gdGhlIFBDTi1kb21haW4gTVVT VCBiZSBmdWxseSBjb21wbGlhbnQNICAgd2l0aCB0aGUgRUNOIGVuY2Fwc3VsYXRpb24gcnVs ZXMgc2V0IG91dCBpbiBbUkZDNjA0MF0uICBBcyBzdWNoIHRoZQ0gICBlbmNvZGluZyBpcyBu b3QgYXBwbGljYWJsZSBpbiBzaXR1YXRpb25zIHdoZXJlIGxlZ2FjeSB0dW5uZWxzIG1pZ2h0 DSAgIGV4aXN0Lg0NDTQuICBEZWZpbml0aW9uIG9mIDMtaW4tMSBQQ04gRW5jb2RpbmcNDSAg IFRoZSAzLWluLTEgUENOIGVuY29kaW5nIHNjaGVtZSBpcyBhbiBleHRlbnNpb24gb2YgdGhl IGJhc2VsaW5lDSAgIGVuY29kaW5nIHNjaGVtZSBkZWZpbmVkIGluIFtSRkM1Njk2XS4gIFRo ZSBQQ04gcmVxdWlyZW1lbnRzIGFuZCB0aGUNICAgZXh0ZW5zaW9uIHJ1bGVzIGZvciBiYXNl bGluZSBlbmNvZGluZyBwcmVzZW50ZWQgaW4gdGhlIHByZXZpb3VzDSAgIHNlY3Rpb24gZGV0 ZXJtaW5lIGhvdyBQQ04gZW5jb2Rpbmcgc3RhdGVzIGFyZSBjYXJyaWVkIGluIHRoZSBJUA0g ICBoZWFkZXJzLiAgVGhpcyBpcyBzaG93biBpbiBGaWd1cmUgMi4NDSAgICAgICAgICstLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0gICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICBDb2RlcG9pbnQgaW4gRUNOIGZp ZWxkIG9mIElQIGhlYWRlciAgICAgIHwNICAgICAgICAgfCAgRFNDUCAgfCAgICAgICAgICAg ICAgIDxSRkMzMTY4IGNvZGVwb2ludCBuYW1lPiAgICAgICAgICAgICB8DSAgICAgICAgIHwg ICAgICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tKw0gICAgICAgICB8ICAgICAgICB8IDAwIDxOb3QtRUNUPiB8IDEwIDxFQ1QoMCk+ IHwgMDEgPEVDVCgxKT4gfCAxMSA8Q0U+IHwNICAgICAgICAgKy0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rDSAgICAgICAg IHwgRFNDUCBuIHwgICAgTm90LVBDTiAgIHwgICAgICBOTSAgICAgfCAgICAgVGhNICAgICB8 ICAgRVRNICAgfA0gICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsNDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAg ICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA3XQ0M DUludGVybmV0LURyYWZ0ICAgICAgICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAg ICAgICAgICAgICBNYXkgMjAxMQ0NDSAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDI6 IDMtaW4tMSBQQ04gRW5jb2RpbmcNDSAgIExpa2UgYmFzZWxpbmUgZW5jb2RpbmcsIDMtaW4t MSBQQ04gZW5jb2RpbmcgYWxzbyB1c2VzIGEgUENODSAgIGNvbXBhdGlibGUgRFNDUCBuIGFu ZCB0aGUgRUNOIGZpZWxkIGZvciB0aGUgZW5jb2Rpbmcgb2YgUENOLW1hcmtzLg0gICBUaGUg UENOLW1hcmtzIGhhdmUgdGhlIGZvbGxvd2luZyBtZWFuaW5nLg0NICAgTm90LVBDTjogIGlu ZGljYXRlcyBhIG5vbi1QQ04tcGFja2V0LCBpLmUuLCBhIHBhY2tldCB0aGF0IGlzIG5vdA0g ICAgICBzdWJqZWN0IHRvIFBDTiBtZXRlcmluZyBhbmQgbWFya2luZy4NDSAgIE5NOiAgTm90 LW1hcmtlZC4gIEluZGljYXRlcyBhIFBDTi1wYWNrZXQgdGhhdCBoYXMgbm90IHlldCBiZWVu IG1hcmtlZA0gICAgICBieSBhbnkgUENOIG1hcmtlci4NDSAgIFRoTTogIFRocmVzaG9sZC1t YXJrZWQuICBJbmRpY2F0ZXMgYSBQQ04tcGFja2V0IHRoYXQgaGFzIGJlZW4gbWFya2VkDSAg ICAgIGJ5IGEgdGhyZXNob2xkLW1hcmtlciBbUkZDNTY3MF0uDQ0gICBFVE06ICBFeGNlc3Mt dHJhZmZpYy1tYXJrZWQuICBJbmRpY2F0ZXMgYSBQQ04tcGFja2V0IHRoYXQgaGFzIGJlZW4N ICAgICAgbWFya2VkIGJ5IGFuIGV4Y2Vzcy10cmFmZmljLW1hcmtlciBbUkZDNTY3MF0uDQ0N NS4gIEJlaGF2aW91ciBvZiBhIFBDTiBOb2RlIENvbXBsaWFudCB3aXRoIHRoZSAzLWluLTEg UENOIEVuY29kaW5nDQ0gICBUbyBiZSBjb21wbGlhbnQgd2l0aCB0aGUgMy1pbi0xIFBDTiBF bmNvZGluZywgYW4gUENOIGludGVyaW9yIG5vZGUNICAgYmVoYXZlcyBhcyBmb2xsb3dzOg0N ICAgbyAgSXQgTVVTVCBjaGFuZ2UgTk0gdG8gVGhNIGlmIHRoZSB0aHJlc2hvbGQtbWV0ZXIg ZnVuY3Rpb24gaW5kaWNhdGVzDSAgICAgIGEgbmVlZCB0byBtYXJrIHRoZSBwYWNrZXQ7DQ0g ICBvICBJdCBNVVNUIGNoYW5nZSBOTSBvciBUaE0gdG8gRVRNIGlmIHRoZSBleGNlc3MtdHJh ZmZpYy1tZXRlcg0gICAgICBmdW5jdGlvbiBpbmRpY2F0ZXMgYSBuZWVkIHRvIG1hcmsgdGhl IHBhY2tldDsNDSAgIG8gIEl0IE1VU1QgTk9UIGNoYW5nZSBub3QtUENOIHRvIE5NLCBUaE0s IG9yIEVUTTsNDSAgIG8gIEl0IE1VU1QgTk9UIGNoYW5nZSBhIE5NLCBUaE0sIG9yIEVUTSB0 byBub3QtUENOOw0NICAgbyAgSXQgTVVTVCBOT1QgY2hhbmdlIFRoTSB0byBOTTsNDSAgIG8g IEl0IE1VU1QgTk9UIGNoYW5nZSBFVE0gdG8gVGhNIG9yIHRvIE5NOw0NICAgSW4gb3RoZXIg d29yZHMsIGEgUENOIGludGVyaW9yIG5vZGUgTVVTVCBOT1QgbWFyayBQQ04tcGFja2V0cyBp bnRvDSAgIG5vbi1QQ04gcGFja2V0cyBhbmQgdmljZS12ZXJzYSwgYW5kIGl0IG1heSBpbmNy ZWFzZSB0aGUgc2V2ZXJpdHkgb2YNICAgdGhlIFBDTi1tYXJrIG9mIGEgUENOLXBhY2tldCwg YnV0IGl0IE1VU1QgTk9UIGRlY3JlYXNlIGl0Lg0NDTYuICBCYWNrd2FyZCBDb21wYXRpYmls aXR5DQ0gICBEaXNjdXNzaW9uIG9mIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgYmV0d2VlbiBQ Q04gZW5jb2Rpbmcgc2NoZW1lcyBhbmQNICAgcHJldmlvdXMgdXNlcyBvZiB0aGUgRUNOIGZp ZWxkIGlzIGdpdmVuIGluIFNlY3Rpb24gNiBvZiBbUkZDNTY5Nl0uDQ0NDQ1CcmlzY29lLCBl dCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIyLCAyMDExICAgICAgICAgICAgICAg W1BhZ2UgOF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29k aW5nICAgICAgICAgICAgICAgICAgTWF5IDIwMTENDQ02LjEuICBCYWNrd2FyZCBDb21wYXRp YmlsaXR5IHdpdGggUHJlLWV4aXN0aW5nIFBDTiBJbXBsZW1lbnRhdGlvbnMNDSAgIFRoaXMg ZW5jb2RpbmcgY29tcGxpZXMgd2l0aCB0aGUgcnVsZXMgZm9yIGV4dGVuZGluZyB0aGUgYmFz ZWxpbmUgUENODSAgIGVuY29kaW5nIHNjaGVtZXMgaW4gU2VjdGlvbiA1IG9mIFtSRkM1Njk2 XS4NDSAgIFRoZSB0ZXJtICJjb21wYXRpYmlsaXR5IiBpcyBtZWFudCBpbiB0aGUgZm9sbG93 aW5nIHNlbnNlLiAgSXQgaXMNICAgcG9zc2libGUgdG8gb3BlcmF0ZSBub2RlcyB3aXRoIGJh c2VsaW5lIGVuY29kaW5nIFtSRkM1Njk2XSBhbmQgMy1pbi0xDSAgIGVuY29kaW5nIGluIHRo ZSBzYW1lIFBDTiBkb21haW4uICBUaGUgbm9kZXMgd2l0aCBiYXNlbGluZSBlbmNvZGluZw0g ICBNVVNUIHBlcmZvcm0gZXhjZXNzLXRyYWZmaWMtbWFya2luZyBiZWNhdXNlIHRoZSAxMSBj b2RlcG9pbnQgb2YNICAgMy1pbi0xIGVuY29kaW5nIGFsc28gbWVhbnMgZXhjZXNzLXRyYWZm aWMtbWFya2VkLiAgUENOLWJvdW5kYXJ5LW5vZGVzDSAgIG9mIHN1Y2ggZG9tYWlucyBhcmUg cmVxdWlyZWQgdG8gaW50ZXJwcmV0IHRoZSBmdWxsIDMtaW4tMSBlbmNvZGluZw0gICBhbmQg bm90IGp1c3QgYmFzZWxpbmUgZW5jb2RpbmcsIG90aGVyd2lzZSB0aGV5IGNhbm5vdCBpbnRl cnByZXQgdGhlDSAgIDAxIGNvZGVwb2ludC4NDSAgIFVzaW5nIG5vZGVzIHRoYXQgcGVyZm9y bSBvbmx5IGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcgbWF5IG1ha2Ugc2Vuc2UNICAgaW4gbmV0 d29ya3MgdXNpbmcgdGhlIENMIGVkZ2UgYmVoYXZpb3INICAgW0ktRC5pZXRmLXBjbi1jbC1l ZGdlLWJlaGF2aW91cl0uICBTdWNoIG5vZGVzIGFyZSBhYmxlIHRvIG5vdGlmeSB0aGUNICAg ZWdyZXNzIG9ubHkgYWJvdXQgc2V2ZXJlIHByZS1jb25nZXN0aW9uIHdoZW4gdHJhZmZpYyBu ZWVkcyB0byBiZQ0gICB0ZXJtaW5hdGVkLiAgVGhpcyBzZWVtcyByZWFzb25hYmxlIGZvciBs b2NhdGlvbnMgdGhhdCBhcmUgbm90DSAgIGV4cGVjdGVkIHRvIHNlZSBhbnkgcHJlLWNvbmdl c3Rpb24sIGJ1dCBleGNlc3MtdHJhZmZpYy1tYXJraW5nIGdpdmVzDSAgIHRoZW0gYSBtZWFu cyB0byB0ZXJtaW5hdGUgdHJhZmZpYyBpZiB1bmV4cGVjdGVkIG92ZXJsb2FkIG9jY3Vycy4N DTYuMi4gIFJlY29tbWVuZGF0aW9ucyBmb3IgdGhlIFVzZSBvZiBQQ04gRW5jb2RpbmcgU2No ZW1lcw0NICAgTk9URTogVGhpcyBzdWItc2VjdGlvbiBpcyBpbmZvcm1hdGl2ZSBub3Qgbm9y bWF0aXZlLg0NICAgV2hlbiBkZWNpZGluZyB3aGljaCBQQ04gZW5jb2RpbmcgaXMgc3VpdGFi bGUgYW4gb3BlcmF0b3IgbmVlZHMgdG8NICAgdGFrZSBhY2NvdW50IG9mIGhvdyBtYW55IFBD TiBzdGF0ZXMgbmVlZCB0byBiZSBlbmNvZGVkLiAgVGhlDSAgIGZvbGxvd2luZyB0YWJsZSBn aXZlcyBndWlkZWxpbmVzIG9uIHdoaWNoIGVuY29kaW5nIHRvIHVzZSB3aXRoIGVpdGhlcg0g ICB0aHJlc2hvbGQtbWFya2luZywgZXhjZXNzLXRyYWZmaWMgbWFya2luZyBvciBib3RoLg0N ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNICAgICAgICAgfCBNYXJraW5nIHNjaGVtZXMgaW4gdXNlIHwgIFJl Y29tbWVuZGVkIGVuY29kaW5nIHNjaGVtZSAgIHwNICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNICAgICAgICAg fCBPbmx5IHRocmVzaG9sZC1tYXJraW5nIHwgICBCYXNlbGluZSBlbmNvZGluZyBbUkZDNTY5 Nl0gIHwNICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNICAgICAgICAgfCBPbmx5IGV4Y2Vzcy10cmFmZmljLSAg IHwgICBCYXNlbGluZSBlbmNvZGluZyBbUkZDNTY5Nl0gIHwNICAgICAgICAgfCAgICAgICBt YXJraW5nICAgICAgICAgIHwgICAgIG9yIDMtaW4tMSBQQ04gZW5jb2RpbmcgICAgIHwNICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNICAgICAgICAgfCBUaHJlc2hvbGQtbWFya2luZyBhbmQgIHwgICAgIDMt aW4tMSBQQ04gZW5jb2RpbmcgICAgICAgIHwNICAgICAgICAgfCBleGNlc3MtdHJhZmZpYy1t YXJraW5nIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNDSAgICAgICAgICBGaWd1cmUgMzogR3VpZGVsaW5lcyBmb3IgY2hvb3NpbmcgUENOIGVu Y29kaW5nIHNjaGVtZXMNDQ0NDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg Tm92ZW1iZXIgMjIsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA5XQ0MDUludGVybmV0LURy YWZ0ICAgICAgICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAgICAgICAgICAgICBN YXkgMjAxMQ0NDTYuMi4xLiAgVXNlIG9mIEJvdGggRXhjZXNzLVRyYWZmaWMtTWFya2luZyBh bmQgVGhyZXNob2xkLU1hcmtpbmcNDSAgIElmIGJvdGggZXhjZXNzLXRyYWZmaWMtbWFya2lu ZyBhbmQgdGhyZXNob2xkLW1hcmtpbmcgYXJlIGVuYWJsZWQgaW4gYQ0gICBQQ04tZG9tYWlu LCAzLWluLTEgZW5jb2Rpbmcgc2hvdWxkIGJlIHVzZWQgYXMgZGVzY3JpYmVkIGluIHRoaXMN ICAgZG9jdW1lbnQuDQ02LjIuMi4gIFVuaXF1ZSBVc2Ugb2YgRXhjZXNzLVRyYWZmaWMtTWFy a2luZw0NICAgSWYgb25seSBleGNlc3MtdHJhZmZpYy1tYXJraW5nIGlzIGVuYWJsZWQgaW4g YSBQQ04tZG9tYWluLCBiYXNlbGluZQ0gICBlbmNvZGluZyBvciAzLWluLTEgZW5jb2Rpbmcg bWF5IGJlIHVzZWQuICBUaGV5IGxlYWQgdG8gdGhlIHNhbWUNICAgZW5jb2RpbmcgYmVjYXVz ZSBQQ04tYm91bmRhcnkgbm9kZXMgd2lsbCBpbnRlcnByZXQgYmFzZWxpbmUgIlBDTi0NICAg bWFya2VkIChQTSkiIGFzICJleGNlc3MtdHJhZmZpYy1tYXJrZWQgKEVUTSkiLg0NNi4yLjMu ICBVbmlxdWUgVXNlIG9mIFRocmVzaG9sZC1NYXJraW5nDQ0gICBObyBzY2hlbWUgaXMgY3Vy cmVudGx5IHByb3Bvc2VkIHRoYXQgc29sZWx5IHVzZXMgdGhyZXNob2xkLW1hcmtpbmcuDSAg IElmIHN1Y2ggYSBzY2hlbWUgaXMgcHJvcG9zZWQsIHRoZSBjaG9pY2Ugb2YgZW5jb2Rpbmcg c2NoZW1lIHdpbGwNICAgZGVwZW5kIG9uIHdoZXRoZXIgbm9kZXMgYXJlIGNvbXBsaWFudCB3 aXRoIFtSRkM2MDQwXSBvciBub3QuICBXaGVyZQ0gICBpdCBpcyBjZXJ0YWluIHRoYXQgYWxs IG5vZGVzIGluIHRoZSBQQ04tZG9tYWluIGFyZSBjb21wbGlhbnQgdGhlbg0gICBlaXRoZXIg My1pbi0xIGVuY29kaW5nIG9yIGJhc2VsaW5lIGVuY29kaW5nIGFyZSBzdWl0YWJsZS4gIElm IGxlZ2FjeQ0gICB0dW5uZWwgZGVjYXBzdWxhdG9ycyBleGlzdCB3aXRoaW4gdGhlIFBDTi1k b21haW4gdGhlbiBiYXNlbGluZQ0gICBlbmNvZGluZyBTSE9VTEQgYmUgdXNlZC4FDUlmIGFu IGVkZ2UgYmVoYXZpb3IgdXNlcyBvbmx5IHRocmVzaG9sZC1tYXJraW5nLCAzLWluLTEgU0hP VUxEIGJlIHVzZWQgaWYgYWxsIHR1bm5lbCBkZWNhcHN1bGF0b3JzIGFyZSBjb21wbGlhbnQg d2l0aCBbUkZDNjA0MF0gYW5kIGJhc2VsaW5lIGVuY29kaW5nIFNIT1VMRCBiZSB1c2VkIG90 aGVyd2lzZS4gTm90ZSB0aGF0IDMtaW4tMSBlbmNvZGluZyBpcyBub3QgY29tcGF0aWJsZSB3 aXRoIHRoZSB1c2Ugb2YgYmFzZWxpbmUgZW5jb2RpbmcgZm9yIHRocmVzaG9sZCBtYXJraW5n LiBUaGVyZWZvcmUsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBydW4gbm9kZXMgd2l0aCAzLWlu LTEgZW5jb2RpbmcgYW5kIGJhc2VsaW5lIGVuY29kaW5nIGluIHBhcmFsbGVsIGluIHRoYXQg Y2FzZS4gIA0NDTcuICBJQU5BIENvbnNpZGVyYXRpb25zDQ0gICBUaGlzIG1lbW8gaW5jbHVk ZXMgbm8gcmVxdWVzdCB0byBJQU5BLg0NICAgTm90ZSB0byBSRkMgRWRpdG9yOiB0aGlzIHNl Y3Rpb24gbWF5IGJlIHJlbW92ZWQgb24gcHVibGljYXRpb24gYXMgYW4NICAgUkZDLg0NDTgu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0NICAgVGhlIHNlY3VyaXR5IGNvbmNlcm5zIHJl bGF0aW5nIHRvIHRoaXMgZXh0ZW5kZWQgUENOIGVuY29kaW5nIGFyZSB0aGUNICAgc2FtZSBh cyB0aG9zZSBpbiBbUkZDNTY5Nl0uICBJbiBzdW1tYXJ5LCBQQ04tYm91bmRhcnkgbm9kZXMg YXJlDSAgIHJlc3BvbnNpYmxlIGZvciBlbnN1cmluZyBpbmFwcHJvcHJpYXRlIFBDTiBtYXJr aW5ncyBkbyBub3QgbGVhayBpbnRvDSAgIG9yIG91dCBvZiBhIFBDTiBkb21haW4sIGFuZCB0 aGUgY3VycmVudCBwaGFzZSBvZiB0aGUgUENOIGFyY2hpdGVjdHVyZQ0gICBhc3N1bWVzIHRo YXQgYWxsIHRoZSBub2RlcyBvZiBhIFBDTi1kb21haW4gYXJlIGVudGlyZWx5IHVuZGVyIHRo ZQ0gICBjb250cm9sIG9mIGEgc2luZ2xlIG9wZXJhdG9yLCBvciBhIHNldCBvZiBvcGVyYXRv cnMgd2hvIHRydXN0IGVhY2gNICAgb3RoZXIuDQ0gICBHaXZlbiB0aGUgb25seSBkaWZmZXJl bmNlIGJldHdlZW4gdGhlIGJhc2VsaW5lIGVuY29kaW5nIGFuZCB0aGUNICAgcHJlc2VudCAz LWluLTEgZW5jb2RpbmcgaXMgdGhlIHVzZSBvZiB0aGUgMDEgY29kZXBvaW50LCBubyBuZXcN ICAgc2VjdXJpdHkgaXNzdWVzIGFyZSByYWlzZWQsIGFzIHRoaXMgY29kZXBvaW50IHdhcyBh bHJlYWR5IGF2YWlsYWJsZQ0gICBmb3IgZXhwZXJpbWVudGFsIHVzZSBpbiB0aGUgYmFzZWxp bmUgZW5jb2RpbmcuBQ0NDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMjIsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDEwXQ0MDUludGVybmV0LURyYWZ0 ICAgICAgICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAgICAgICAgICAgICBNYXkg MjAxMQ0NDTkuICBDb25jbHVzaW9ucw0NICAgVGhlIDMtaW4tMSBQQ04gZW5jb2RpbmcgdXNl cyBhIFBDTi1jb21wYXRpYmxlIERTQ1AgYW5kIHRoZSBFQ04gZmllbGQNICAgdG8gZW5jb2Rl IFBDTi1tYXJrcy4gIE9uZSBjb2RlcG9pbnQgYWxsb3dzIG5vbi1QQ04gdHJhZmZpYyB0byBi ZQ0gICBjYXJyaWVkIHdpdGggdGhlIHNhbWUgUENOLWNvbXBhdGlibGUgRFNDUCBhbmQgdGhy ZWUgb3RoZXIgY29kZXBvaW50cw0gICBzdXBwb3J0IHRocmVlIFBDTiBtYXJraW5nIHN0YXRl cyB3aXRoIGRpZmZlcmVudCBsZXZlbHMgb2Ygc2V2ZXJpdHkuDSAgIFRoZSB1c2Ugb2YgdGhp cyBQQ04gZW5jb2Rpbmcgc2NoZW1lIHByZXN1cHBvc2VzIHRoYXQgYW55IHR1bm5lbCBkZWNh cHN1bGF0b3JzIGluDSAgIHRoZSBQQ04gcmVnaW9uIGhhdmUgYmVlbiB1cGRhdGVkIHRvIGNv bXBseSB3aXRoIFtSRkM2MDQwXS4NDQ0xMC4gIEFja25vd2xlZGdlbWVudHMNDSAgIFRoYW5r cyB0byBQaGlsIEVhcmRsZXksIFRlY28gQm9vdCwgS3dvayBIbyBDaGFuIGFuZCBHZW9yZ2lv cw0gICBLYXJhZ2luYW5uaXMgZm9yIHJldmlld2luZyB0aGlzIGRvY3VtZW50Lg0NDTExLiAg Q29tbWVudHMgU29saWNpdGVkDQ0gICBUbyBiZSByZW1vdmVkIGJ5IFJGQyBFZGl0b3I6IENv bW1lbnRzIGFuZCBxdWVzdGlvbnMgYXJlIGVuY291cmFnZWQNICAgYW5kIHZlcnkgd2VsY29t ZS4gIFRoZXkgY2FuIGJlIGFkZHJlc3NlZCB0byB0aGUgSUVURiBDb25nZXN0aW9uIGFuZA0g ICBQcmUtQ29uZ2VzdGlvbiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCA8cGNuQGlldGYu b3JnPiwgYW5kL29yIHRvDSAgIHRoZSBhdXRob3JzLg0NDTEyLiAgUmVmZXJlbmNlcw0NMTIu MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQ0gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAi S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0gICAgICAgICAgICAgIFJl cXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQ0gICBb UkZDMjQ3NF0gIE5pY2hvbHMsIEsuLCBCbGFrZSwgUy4sIEJha2VyLCBGLiwgYW5kIEQuIEJs YWNrLA0gICAgICAgICAgICAgICJEZWZpbml0aW9uIG9mIHRoZSBEaWZmZXJlbnRpYXRlZCBT ZXJ2aWNlcyBGaWVsZCAoRFMNICAgICAgICAgICAgICBGaWVsZCkgaW4gdGhlIElQdjQgYW5k IElQdjYgSGVhZGVycyIsIFJGQyAyNDc0LA0gICAgICAgICAgICAgIERlY2VtYmVyIDE5OTgu DQ0gICBbUkZDMzE2OF0gIFJhbWFrcmlzaG5hbiwgSy4sIEZsb3lkLCBTLiwgYW5kIEQuIEJs YWNrLCAiVGhlIEFkZGl0aW9uDSAgICAgICAgICAgICAgb2YgRXhwbGljaXQgQ29uZ2VzdGlv biBOb3RpZmljYXRpb24gKEVDTikgdG8gSVAiLA0gICAgICAgICAgICAgIFJGQyAzMTY4LCBT ZXB0ZW1iZXIgMjAwMS4NDSAgIFtSRkMzNTQwXSAgU3ByaW5nLCBOLiwgV2V0aGVyYWxsLCBE LiwgYW5kIEQuIEVseSwgIlJvYnVzdCBFeHBsaWNpdA0gICAgICAgICAgICAgIENvbmdlc3Rp b24gTm90aWZpY2F0aW9uIChFQ04pIFNpZ25hbGluZyB3aXRoIE5vbmNlcyIsDSAgICAgICAg ICAgICAgUkZDIDM1NDAsIEp1bmUgMjAwMy4NDSAgIFtSRkM0MzAxXSAgS2VudCwgUy4gYW5k IEsuIFNlbywgIlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlDSAgICAgICAgICAgICAg SW50ZXJuZXQgUHJvdG9jb2wiLCBSRkMgNDMwMSwgRGVjZW1iZXIgMjAwNS4NDSAgIFtSRkM0 NTk0XSAgQmFiaWFyeiwgSi4sIENoYW4sIEsuLCBhbmQgRi4gQmFrZXIsICJDb25maWd1cmF0 aW9uDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIw MTEgICAgICAgICAgICAgIFtQYWdlIDExXQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAg IDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAgICAgICAgICAgICBNYXkgMjAxMQ0NDSAgICAg ICAgICAgICAgR3VpZGVsaW5lcyBmb3IgRGlmZlNlcnYgU2VydmljZSBDbGFzc2VzIiwgUkZD IDQ1OTQsDSAgICAgICAgICAgICAgQXVndXN0IDIwMDYuDQ0gICBbUkZDNTEyOV0gIERhdmll LCBCLiwgQnJpc2NvZSwgQi4sIGFuZCBKLiBUYXksICJFeHBsaWNpdCBDb25nZXN0aW9uDSAg ICAgICAgICAgICAgTWFya2luZyBpbiBNUExTIiwgUkZDIDUxMjksIEphbnVhcnkgMjAwOC4N DSAgIFtSRkM1NTU5XSAgRWFyZGxleSwgUC4sICJQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRp b24gKFBDTikNICAgICAgICAgICAgICBBcmNoaXRlY3R1cmUiLCBSRkMgNTU1OSwgSnVuZSAy MDA5Lg0NICAgW1JGQzU2NzBdICBFYXJkbGV5LCBQLiwgIk1ldGVyaW5nIGFuZCBNYXJraW5n IEJlaGF2aW91ciBvZiBQQ04tDSAgICAgICAgICAgICAgTm9kZXMiLCBSRkMgNTY3MCwgTm92 ZW1iZXIgMjAwOS4NDSAgIFtSRkM1Njk2XSAgTW9uY2FzdGVyLCBULiwgQnJpc2NvZSwgQi4s IGFuZCBNLiBNZW50aCwgIkJhc2VsaW5lDSAgICAgICAgICAgICAgRW5jb2RpbmcgYW5kIFRy YW5zcG9ydCBvZiBQcmUtQ29uZ2VzdGlvbiBJbmZvcm1hdGlvbiIsDSAgICAgICAgICAgICAg UkZDIDU2OTYsIE5vdmVtYmVyIDIwMDkuDQ0gICBbUkZDNTg2NV0gIEJha2VyLCBGLiwgUG9s aywgSi4sIGFuZCBNLiBEb2xseSwgIkEgRGlmZmVyZW50aWF0ZWQNICAgICAgICAgICAgICBT ZXJ2aWNlcyBDb2RlIFBvaW50IChEU0NQKSBmb3IgQ2FwYWNpdHktQWRtaXR0ZWQgVHJhZmZp YyIsDSAgICAgICAgICAgICAgUkZDIDU4NjUsIE1heSAyMDEwLg0NICAgW1JGQzYwNDBdICBC cmlzY29lLCBCLiwgIlR1bm5lbGxpbmcgb2YgRXhwbGljaXQgQ29uZ2VzdGlvbg0gICAgICAg ICAgICAgIE5vdGlmaWNhdGlvbiIsIFJGQyA2MDQwLCBOb3ZlbWJlciAyMDEwLg0NMTIuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNDSAgIFtJLUQuaWV0Zi1wY24tY2wtZWRnZS1iZWhh dmlvdXJdDSAgICAgICAgICAgICAgQ2hhcm55LCBBLiwgSHVhbmcsIEYuLCBLYXJhZ2lhbm5p cywgRy4sIE1lbnRoLCBNLiwgYW5kIFQuDSAgICAgICAgICAgICAgVGF5bG9yLCAiUENOIEJv dW5kYXJ5IE5vZGUgQmVoYXZpb3VyIGZvciB0aGUgQ29udHJvbGxlZA0gICAgICAgICAgICAg IExvYWQgKENMKSBNb2RlIG9mIE9wZXJhdGlvbiIsDSAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1wY24tY2wtZWRnZS1iZWhhdmlvdXItMDggKHdvcmsgaW4gcHJvZ3Jlc3MpLA0gICAgICAg ICAgICAgIERlY2VtYmVyIDIwMTAuDQ0gICBbSS1ELmlldGYtcGNuLWVuY29kaW5nLWNvbXBh cmlzb25dDSAgICAgICAgICAgICAgS2FyYWdpYW5uaXMsIEcuLCBDaGFuLCBLLiwgTW9uY2Fz dGVyLCBULiwgTWVudGgsIE0uLA0gICAgICAgICAgICAgIEVhcmRsZXksIFAuLCBhbmQgQi4g QnJpc2NvZSwgIk92ZXJ2aWV3IG9mIFByZS1Db25nZXN0aW9uDSAgICAgICAgICAgICAgTm90 aWZpY2F0aW9uIEVuY29kaW5nIiwNICAgICAgICAgICAgICBkcmFmdC1pZXRmLXBjbi1lbmNv ZGluZy1jb21wYXJpc29uLTA1ICh3b3JrIGluIHByb2dyZXNzKSwNICAgICAgICAgICAgICBB cHJpbCAyMDExLg0NICAgW0ktRC5pZXRmLXBjbi1zbS1lZGdlLWJlaGF2aW91cl0NICAgICAg ICAgICAgICBDaGFybnksIEEuLCBLYXJhZ2lhbm5pcywgRy4sIE1lbnRoLCBNLiwgYW5kIFQu IFRheWxvciwNICAgICAgICAgICAgICAiUENOIEJvdW5kYXJ5IE5vZGUgQmVoYXZpb3VyIGZv ciB0aGUgU2luZ2xlIE1hcmtpbmcgKFNNKQ0gICAgICAgICAgICAgIE1vZGUgb2YgT3BlcmF0 aW9uIiwgZHJhZnQtaWV0Zi1wY24tc20tZWRnZS1iZWhhdmlvdXItMDUNICAgICAgICAgICAg ICAod29yayBpbiBwcm9ncmVzcyksIERlY2VtYmVyIDIwMTAuDQ0NDQ0NDQ1CcmlzY29lLCBl dCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIyLCAyMDExICAgICAgICAgICAgICBb UGFnZSAxMl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29k aW5nICAgICAgICAgICAgICAgICAgTWF5IDIwMTENDQ1BcHBlbmRpeCBBLiAgQ28tZXhpc3Rl bmNlIG9mIEVDTiBhbmQgUENOIChpbmZvcm1hdGl2ZSkNDSAgIFRoZSBQQ04gZW5jb2Rpbmcg ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgcmUtdXNlcyB0aGUgYml0cyBvZiB0aGUNICAg RUNOIGZpZWxkIGluIHRoZSBJUCBoZWFkZXIuICBDb25zZXF1ZW50bHksIHRoaXMgZGlzYWJs ZXMgRUNOIHdpdGhpbg0gICB0aGUgUENOIGRvbWFpbi4gIEFwcGVuZGl4IEIgb2YgW1JGQzU2 OTZdIGluY2x1ZGVkIGFkdmljZSBvbiBoYW5kbGluZw0gICBFQ04gdHJhZmZpYyB3aXRoaW4g YSBQQ04tZG9tYWluLiAgVGhpcyBhcHBlbmRpeCBjbGFyaWZpZXMgdGhhdA0gICBhZHZpY2Uu DQ0gICBGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgYXBwZW5kaXggd2UgZGVmaW5lIHR3byBm b3JtcyBvZiB0cmFmZmljIHRoYXQNICAgbWlnaHQgYXJyaXZlIGF0IGEgUENOLWluZ3Jlc3Mg bm9kZS4gIFRoZXNlIGFyZSBhQWRtaXNzaW9uLWNvbnRyb2xsZWQNICAgdHJhZmZpYyBhbmQg bk5vbi1hZG1pc3Npb24tY29udHJvbGxlZCB0cmFmZmljLg0NICAgQWRtaXNzaW9uLWNvbnRy b2xsZWQgdHJhZmZpYyB3aWxsIGJlIHJlLW1hcmtlZCB0byB0aGUgUENOLWNvbXBhdGlibGUN ICAgRFNDUCBieSB0aGUgUENOLWluZ3Jlc3Mgbm9kZS4gIFR3byBtZWNoYW5pc21zIGNhbiBi ZSB1c2VkIHRvIGlkZW50aWZ5DSAgIHN1Y2ggdHJhZmZpYzoNDSAgIGEuICBmbG93IHNpZ25h bGxpbmcgYXNzb2NpYXRlcyBhIGZpbHRlcnNwZWMgd2l0aCBhIG5lZWQgZm9yIGFkbWlzc2lv bg0gICAgICAgY29udHJvbCAoZS5nLiB0aHJvdWdoIFJTVlAgb3Igc29tZSBlcXVpdmFsZW50 IG1lc3NhZ2UgZG93biBmcm9tIGENICAgICAgIFNJUCBzZXJ2ZXIgdG8gdGhlIGluZ3Jlc3Mp LCBhbmQgdGhlIFBDTi1pbmdyZXNzIHJlbWFya3MgdHJhZmZpYw0gICAgICAgbWF0Y2hpbmcg dGhhdCBmaWx0ZXJzcGVjIHRvIGEgUENOLWNvbXBhdGlibGUgRFNDUCwgYXMgaXRzIGNob3Nl bg0gICAgICAgYWRtaXNzaW9uIGNvbnRyb2wgbWVjaGFuaXNtLgUNCUZsb3cgc2lnbmFsaW5n IHByb3ZpZGVzIGZpbHRlcnNwZWNzIGZvciBmbG93cyB0aGF0IG5lZWQgYWRtaXNzaW9uIGNv bnRyb2wuIEV4YW1wbGVzIGZvciBzdWNoIHNpZ25hbGluZyBwcm90b2NvbHMgYXJlIFJTVlAg b3IgbWVzc2FnZXMgZnJvbSBhIFNJUCBzZXJ2ZXIgdG8gdGhlIGluZ3Jlc3MuIFRoZSBQQ04t aW5ncmVzcyBub2RlIHJlY29nbml6ZXMgYWxsIHBhY2tldHMgbWF0Y2hpbmcgdGhlc2UgZmls dGVyc3BlY3MgYXMgc3ViamVjdCB0byBhZG1pc3Npb24gY29udHJvbCBhbmQgc2V0cyBhIFBD Ti1jb21wYXRpYmxlIERTQ1AgaW4gdGhlaXIgSVAgaGVhZGVyLg0NDSAgIGIuICBUcmFmZmlj IGFycml2ZXMgd2l0aCBhIERTQ1AgdGhhdCBpbXBsaWVzIGl0IHJlcXVpcmVzIGFkbWlzc2lv bg0gICAgICAgY29udHJvbCBzdWNoIGFzIFZPSUNFLUFETUlUIFtSRkM1ODY1XSBvciBJbnRl cmFjdGl2ZSBSZWFsLVRpbWUsDSAgICAgICBCcm9hZGNhc3QgVFYgd2hlbiB1c2VkIGZvciB2 aWRlbyBvbiBkZW1hbmQsIGFuZCBNdWx0aW1lZGlhDSAgICAgICBDb25mZXJlbmNpbmcgW1JG QzQ1OTRdW1JGQzU4NjVdLgUNDSAgIEFsbCBvdGhlciB0cmFmZmljIGNhbiBiZSB0aG91Z2h0 IG9mIGFzIG5Ob24tYWRtaXNzaW9uLWNvbnRyb2xsZWQuDSAgIEhvd2V2ZXIgc3VjaCB0cmFm ZmljIG1heSBzdGlsbCBuZWVkIHRvIHNoYXJlIHRoZSBzYW1lIERTQ1AgYXMgdGhlDSAgIGFB ZG1pc3Npb24tY29udHJvbGxlZCB0cmFmZmljLiAgVGhpcyBtYXkgYmUgZHVlIHRvIHBvbGlj eSAoZm9yDSAgIGluc3RhbmNlIGlmIGl0IGlzIGhpZ2ggcHJpb3JpdHkgdm9pY2UgdHJhZmZp YyksIG9yIG1heSBiZSBiZWNhdXNlDSAgIHRoZXJlIGlzIGEgc2hvcnRhZ2Ugb2YgbG9jYWwg RFNDUHMuDQ0gICBFQ04gW1JGQzMxNjhdIGlzIGFuIGVuZC10by1lbmQgY29uZ2VzdGlvbiBu b3RpZmljYXRpb24gbWVjaGFuaXNtLiAgQXMNICAgc3VjaCBpdCBpcyBwb3NzaWJsZSB0aGF0 IHNvbWUgdHJhZmZpYyBlbnRlcmluZyB0aGUgUENOLWRvbWFpbiBtYXkNICAgYWxzbyBiZSBF Q04gY2FwYWJsZS4gVGhlIGZvbGxvd2luZyBsaXN0cyB0aGUgZm91ciBjYXNlcyBmb3IgaG93 IGUyZQ0gICBFQ04gdHJhZmZpYyBtYXkgd2lzaCB0byBiZSB0cmVhdGVkIHdoaWxlIGNyb3Nz aW5nIGEgUENOIGRvbWFpbjoNDSBvICBFQ04gY2FwYWJsZSB0cmFmZmljIHRoYXQgZG9lcyBu b3QgcmVxdWlyZSBhZG1pc3Npb24gY29udHJvbCBhbmQgZG9lcw0gICBub3QgY2FycnkgYSBE U0NQIHRoYXQgdGhlIFBDTi1pbmdyZXNzIGlzIHVzaW5nIGZvciBQQ04tY2FwYWJsZQ0gICB0 cmFmZmljLiAgVGhpcyByZXF1aXJlcyBubyBhY3Rpb24uDQ0gbyAgRUNOIGNhcGFibGUgdHJh ZmZpYyB0aGF0IGRvZXMgbm90IHJlcXVpcmUgYWRtaXNzaW9uIGNvbnRyb2wgYnV0DSAgIGNh cnJpZXMgYSBEU0NQIHRoYXQgdGhlICBQQ04taW5ncmVzcyBpcyB1c2luZyBmb3IgUENOLWNh cGFibGUNICAgdHJhZmZpYy4gIFRoZXJlIGFyZSB0d28gb3B0aW9ucy4NDQ0NDQ0NQnJpc2Nv ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMiwgMjAxMSAgICAgICAgICAg ICAgW1BhZ2UgMTNdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgMy1pbi0xIFBDTiBF bmNvZGluZyAgICAgICAgICAgICAgICAgIE1heSAyMDExDQ0NDQ0gICAgICAqICBUaGUgaW5n cmVzcyBtYXBzIHRoZSBEU0NQIHRvIGEgbG9jYWwgRFNDUCB3aXRoIHRoZSBzYW1lDSAgICAg ICAgIHNjaGVkdWxpbmcgUEhCIGFzIHRoZSBvcmlnaW5hbCBEU0NQLCBhbmQgdGhlIGVncmVz cyByZS1tYXBzIGl0DSAgICAgICAgIHRvIHRoZSBvcmlnaW5hbCBQQ04tY29tcGF0aWJsZSBE U0NQLg0NICAgICAgKiAgVGhlIGluZ3Jlc3MgdHVubmVscyB0aGUgdHJhZmZpYywgc2V0dGlu ZyBub3QtUENOIGluIHRoZSBvdXRlcg0gICAgICAgICBoZWFkZXI7IG5vdGUgdGhhdCB0aGlz IHR1cm5zIG9mZiBFQ04gZm9yIHRoaXMgdHJhZmZpYyB3aXRoaW4NICAgICAgICAgdGhlIFBD TiBkb21haW4uDQ0gICAgICBUaGUgZmlyc3Qgb3B0aW9uIGlzIHJlY29tbWVuZGVkIHVubGVz cyB0aGUgb3BlcmF0b3IgaXMgc2hvcnQgb2YNICAgICAgbG9jYWwgRFNDUHMuDQ0gbyAgRUNO LWNhcGFibGUgYUFkbWlzc2lvbi1jb250cm9sbGVkIHRyYWZmaWM6ICBUaGVyZSBhcmUgdHdv IG9wdGlvbnMuDQ0NDSAgICAgICogIFRoZSBQQ04taW5ncmVzcyBwbGFjZXMgdGhpcyB0cmFm ZmljIGluIGEgdHVubmVsIHdpdGggYSBQQ04tDSAgICAgICAgIGNvbXBhdGlibGUgRFNDUCBp biB0aGUgb3V0ZXIgaGVhZGVyLiAgVGhlIFBDTi1lZ3Jlc3MgemVyb2VzBSB0aGUNICAgICAg ICAgRUNOLWZpZWxkIGJlZm9yZSBkZWNhcHN1bGF0aW9uLg0NICAgICAgKiAgVGhlIFBDTi1p bmdyZXNzIGRyb3BzIENFLW1hcmtlZCBwYWNrZXRzIGFuZCB0aGUgUENOLWVncmVzcw0gICAg ICAgICB6ZXJvcwUgdGhlIEVDTiBmaWVsZCBvZiBhbGwgUENOIHBhY2tldHMuDQ0gICAgICBU aGUgc2Vjb25kIG9wdGlvbiBpcyBub3QgcmVjb21tZW5kZWQgdW5sZXNzIHR1bm5lbGxpbmcg aXMgbm90DSAgICAgIHBvc3NpYmxlIGZvciBzb21lIHJlYXNvbi4uDQ0gbyAgRUNOLWNhcGFi bGUgYUFkbWlzc2lvbi1jb250cm9sbGVkIHRyYWZmaWMgd2hlcmUgdGhlIGUyZSB0cmFuc3Bv cnQgc29tZWhvdw0gICBpbmRpY2F0ZXMgdGhhdCBpdCB3YW50cyB0byBzZWUgUENOIG1hcmtz OiAgTk9URSB0aGlzIGlzIGN1cnJlbnRseQ0gICAgICBleHBlcmltZW50YWwgb25seS4FDQ0g ICAgICBTY2hlbWVzIGhhdmUgYmVlbiBzdWdnZXN0ZWQgd2hlcmUgUENOIG1hcmtzIG1heSBi ZSBsZWFrZWQgb3V0IG9mDSAgICAgIHRoZSBQQ04tZG9tYWluIGFuZCB1c2VkIGJ5IHRoZSBl bmQgaG9zdHMgdG8gbW9kaWZ5IHJlYWx0aW1lIGRhdGENICAgICAgcmF0ZXMuICBDdXJyZW50 bHkgYWxsIHN1Y2ggc2NoZW1lcyBhcmUgZXhwZXJpbWVudGFsIGFuZCB0aGUNICAgICAgZm9s bG93aW5nIGlzIGZvciBndWlkYW5jZSBvbmx5LgUNSG9zdHMgbWF5IHdpc2ggdG8gcmVjZWl2 ZWQgUENOIG1hcmtzIHRvIGJlIG5vdGlmaWVkIGFib3V0IHByZS1jb25nZXN0aW9uIHNvIHRo YXQgdGhleSBjYW4gcmVkdWNlIHRyYWZmaWMgcmF0ZXMuIEluIHRoYXQgY2FzZSwgdGhlIGVn cmVzcyBub2RlIHNob3VsZCBub3QgY2xlYXIgdGhlIFBDTiBtYXJrcyBiZWZvcmUgUENOIHBh Y2tldHMgbGVhdmUgdGhlIFBDTiBkb21haW4uDQ0NICAgICAgVGhlIFBDTi1pbmdyZXNzIG5l ZWRzIHRvIHR1bm5lbCB0aGUgdHJhZmZpYyB1c2luZyBbUkZDNjA0MF0uICBUaGUNICAgICAg UENOLWVncmVzcyBzaG91bGQgbm90IHplcm8gdGhlIEVDTiBmaWVsZCBvZiB0aGUgb3V0ZXIg aGVhZGVyLCBhbmQgdGhlIHR1bm5lbCBlZ3Jlc3MNICAgICAgc2hvdWxkIHVzZSBbUkZDNjA0 MF0gbm9ybWFsIG1vZGUgZm9yIGRlY2Fwc3VsYXRpb24gKHByZXNlcnZpbmcgYW55IFBDTi1t YXJraW5nKS4NICAgICAgTm90ZSB0aGF0IHRoaXMgbWF5IHR1cm4gRUNUKDApIGludG8gRUNU KDEpIGFuZCBzbyBpcyBub3QNICAgICAgY29tcGF0aWJsZSB3aXRoIHRoZSBleHBlcmltZW50 YWwgRUNOIG5vbmNlIFtSRkMzNTQwXS4NDSAgIEluIHRoZSBsaXN0IGFib3ZlIGFueSBmb3Jt IG9mIElQLWluLUlQIHR1bm5lbCBjYW4gYmUgdXNlZCB1bmxlc3MNICAgc3BlY2lmaWVkIG90 aGVyd2lzZS4gIE5CLCBXZSBhc3N1bWUgYSBsb2dpY2FsIHNlcGFyYXRpb24gb2YgdHVubmVs aW5nDSAgIGFuZCBQQ04gYWN0aW9ucyBpbiBib3RoIFBDTi1pbmdyZXNzIGFuZCBQQ04tZWdy ZXNzIG5vZGVzLiAgVGhhdCBpcywNICAgYW55IHR1bm5lbGluZyBhY3Rpb24gaGFwcGVucyB3 aG9sbHkgb3V0c2lkZSB0aGUgUENOLWRvbWFpbiBhcw0gICBpbGx1c3RyYXRlZCBpbiB0aGUg Zm9sbG93aW5nIGZpZ3VyZToFDQ0NDQ1CcmlzY29lLCBldCBhbC4gICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIyLCAyMDExICAgICAgICAgICAgICBbUGFnZSAxNF0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29kaW5nICAgICAgICAgICAgICAgICAg TWF5IDIwMTENDQ0gICAgICAgICAgICAgICAgLCAgLiAgLiAgLiAgLiAgLiAgUENOLWRvbWFp biAgLiAgLiAgLiAgLiAgLiAgLg0gICAgICAgICAgICAgICAuICAgLC0tLS0tLS0tLiAgICAg ICAgICAgICAgICAgICAsLS0tLS0tLS0uICAgIC4NICAgICAgICAgICAgICAuICAgX3wgIFBD Ti0gICB8X19fX19fX19fX19fX19fX19fX3wgIFBDTi0gIHxfICAgLg0gICAgICAgICAgICAg IC4gIC8gfCBpbmdyZXNzIHwgICAgICAgICAgICAgICAgICAgfCBlZ3Jlc3MgfCBcICAuDSAg ICAgICAgICAgICAgIC58ICAnLS0tLS0tLS0tJyAgICAgICAgICAgICAgICAgICAnLS0tLS0t LS0nICB8Lg0gICAgICAgICAgICAgICAgfCAuICAuICAuICAuICAuICAuICAuICAuICAuICAu ICAuICAuICAuICAuICAufA0gICAgICAgICAgICwtLS0tLS0tLS4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLC0tLS0tLS0tLg0gICAgIF9fX19ffCBUdW5uZWwgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBUdW5uZWwgfF9fX18NICAg ICAgICAgIHwgSW5ncmVzcyB8IC0gLSBFQ04gcHJlc2VydmVkIGluc2lkZSB0dW5uZWwgLSAt IHwgRWdyZXNzIHwNICAgICAgICAgICctLS0tLS0tLS0nICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICctLS0tLS0tLScNDQ0gICAgICAgICAgICAgRmlndXJlIDQ6IFNl cGFyYXRpb24gb2YgdHVubmVsaW5nIGFuZCBQQ04gYWN0aW9ucw0FDVBDTiBpbmdyZXNzIG5v ZGVzIHNldCBQQ04tY29tcGF0aWJsZSBEU0NQcyBhbmQgTk0gaW4gSVAgaGVhZGVycyBhbmQg UENOLWVncmVzcyBub2RlcyBzZXQgdGhlIEVDTiBmaWVsZCB0byBub3QtRUNUIGJlZm9yZSB0 aGUgcGFja2V0cyBsZWF2ZSB0aGUgUENOIGRvbWFpbi4gSW4gdGhlIGZvbGxvd2luZywgd2Ug cHJvcG9zZSB0aGUgdXNlIG9mIHR1bm5lbHMgdG8gcHJlc2VydmUgRUNOIGNvZGVwb2ludCBm b3IgUENOIHBhY2tldHMgYWNyb3NzIFBDTiBkb21haW5zLiBGaWd1cmUgNCBjbGFyaWZpZXMg dGhlIG9yZGVyIG9mIHRoZXNlIG9wZXJhdGlvbnMuIFRoZSBlbmRwb2ludHMgb2Ygc3VjaCB0 dW5uZWxzIGFyZSBsb2dpY2FsbHkgb3V0c2lkZSB0aGUgUENOIGRvbWFpbiwgaS5lLiwgUENO LWNvbXBhdGlibGUgRFNDUHMgYXJlIHNldCBhZnRlciBlbmNhcHN1bGF0aW9uIGFuZCB0aGUg RUNOIGZpZWxkIGlzIHNldCB0byBub3QtRUNUIGJlZm9yZSBkZWNhcHN1bGF0aW9uLgUNDQ0N DUF1dGhvcnMnIEFkZHJlc3Nlcw0NICAgQm9iIEJyaXNjb2UNICAgQlQNICAgQjU0Lzc3LCBB ZGFzdHJhbCBQYXJrDSAgIE1hcnRsZXNoYW0gSGVhdGgNICAgSXBzd2ljaCAgSVA1IDNSRQ0g ICBVSw0NICAgUGhvbmU6ICs0NCAxNDczIDY0NTE5Ng0gICBFbWFpbDogYm9iLmJyaXNjb2VA YnQuY29tDSAgIFVSSTogICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQ0NICAgVG9ieSBNb25j YXN0ZXINICAgTW9uY2FzdGVyIEludGVybmV0IENvbnN1bHRpbmcNICAgRHVrZXMNICAgTGF5 ZXIgTWFybmV5DSAgIENvbGNoZXN0ZXIgIENPNSA5VVoNICAgVUsNDSAgIFBob25lOiArNDQg Nzc2NCAxODU0MTYNICAgRW1haWw6IHRvYnlAbW9uY2FzdGVyLmNvbQ0gICBVUkk6ICAgaHR0 cDovL3d3dy5tb25jYXN0ZXIuY29tLw0NDQ0NDQ0NDQ0NDQ1CcmlzY29lLCBldCBhbC4gICAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDIyLCAyMDExICAgICAgICAgICAgICBbUGFnZSAxNV0N DA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29kaW5nICAgICAg ICAgICAgICAgICAgTWF5IDIwMTENDQ0gICBNaWNoYWVsIE1lbnRoDSAgIFVuaXZlcnNpdHkg b2YgVHVlYmluZ2VuDSAgIFNhbmQgMTMNICAgVHVlYmluZ2VuICA3MjA3Ng0gICBHZXJtYW55 DQ0gICBQaG9uZTogKzQ5IDcwNzEgMjk3MDUwNQ0gICBFbWFpbDogbWVudGhAaW5mb3JtYXRp ay51bmktdHVlYmluZ2VuLmRlDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ1CcmlzY29lLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIyLCAy MDExICAgICAgICAgICAgICBbUGFnZSAxNl0NDA0NBUmSbSBub3Qgc3VyZSB3aGljaCBydWxl cyB5b3UgbWVhbi4NBUkgZm91bmQgdGhpcyBwYXJhZ3JhcGggbm90IGNsZWFyIGVub3VnaC4g VGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggc2hvd3Mgd2hhdCBJIGJlbGlldmVkIHRvIHJlYWQs IEkganVzdCB3YW50ZWQgdG8gbWFrZSB0aGUgbWVzc2FnZSBjbGVhcmVyLg0FSZJkIHByZWZl ciB0byBoYXZlIHRoaXMgc2VjdGlvbiBpbmRlcGVuZGVudCBvZiBSRkM1Njk2Lg0FVGhpcyBw YXJhZ3JhcGggaXMgbm90IGZ1bGx5IGNsZWFyIHRvIG1lLiBJIHRyeSB0byByZXBocmFzZS4N BVF1ZXN0aW9uOiBob3cgaXMgaXQgcG9zc2libGUgdG8gYmxvY2sgc3VjaCB0cmFmZmljIGkg Zml0IGRvZXMgbm90IHVzZSBwZXItZmxvdyBzaWduYWxsaW5nIGF0IHRoZSBib3JkZXIgbm9k ZXM/DQVaZXJvcy96ZXJvZXM/DQVaZXJvcy96ZXJvZXM/DQVUaGlzIGlzIHJhdGhlciBhIGhh cmRseSBkb2N1bWVudGVkIGlkZWEgdGhhbiBleHBlcmltZW50YWwhIFdlIGhhZCB0aGF0IGlu IHNvbWUgb2YgdGhlIG90aGVyIGVuY29kaW5nIGRyYWZ0cywgYnV0IEkgZG9uknQga25vdyB3 aGljaCBvbmUgYW5kIEkgZG9uknQga25vdyB3aGV0aGVyIHRoaXMgZHJhZnQgaXMgZ29ubmEg c3RheS4NBUp1c3QgY2xhcmlmaWVkIGJlbG93Lg0FSSBtb2RpZmllZCB0aGlzIHRleHQgdG8g bWFrZSBpdCBjbGVhcmVyLCBzZWUgYmVsb3csIEkgaG9wZSBnb3QgdGhlIG1lc3NhZ2Ugcmln aHQuDQVUaGlzIG5lZWRzIHRvIGJlIGF0IHRoZSBiZWdpbm5pbmcgb2Z0IGhlIGFwcGVuZGl4 Lg0FVGhpcyBhbGwgc2hvdWxkIGJlIGF0IHRoZSBiZWdpbm5pbmcgb2Z0IGhlIGFwcGVuZGl4 IGFzIHRoZSByZWFkZXIgc2hvdWxkIGhhdmUgdGhhdCBpbiBtaW5kLg0NDQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgAAAMIAABwPQAAgD0AAJw9AAChPQAA/0EAAABCAAB2RAAAfEQAAINEAACPRAAA kEQAAJFEAACjXAAAX14AAGBeAADz4s7izuLA4qaSfpJn4k0/AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGwNqAAAAABZoliKlADBKEQBPSgQAUUoEAFUIATMA CIEVaEtx3AAWaIN7wgAXaJYipQBPSgMAUUoDAF5KAwBjSAEAZGirrfXGbUgJBHNICQQtAQiB BEgBAAVona31xhVoS3HcABZoolgJAE9KAwBRSgMAXkoDAG1ICQRzSAkEJwEIgQRIAQAFaKat 9cYWaJYipQBPSgMAUUoDAF5KAwBtSAkEc0gJBCcBCIEESAEABWidrfXGFmiiWAkAT0oDAFFK AwBeSgMAbUgJBHNICQQzAAiBFWhLcdwAFmiDe8IAF2iiWAkAT0oDAFFKAwBeSgMAY0gBAGRo na31xm1ICQRzSAkEGwNqAAAAABZoolgJADBKEQBPSgQAUUoEAFUIAScBCIEESAEABWiZrfXG FmiiWAkAT0oDAFFKAwBeSgMAbUgJBHNICQQgFWhLcdwAFmiDe8IAT0oDAFFKAwBeSgMAbUgJ BHNICQQAGBVofW3pABZog3vCAE9KAwBRSgMAXkoDABAACAAAAQgAAAIIAAADCAAATAgAAJUI AADeCAAAJwkAAHAJAAC5CQAAAgoAAAMKAAAECgAARgoAAHsKAAB8CgAAhQoAAIYKAADOCgAA FwsAAF8LAACkCwAA7AsAADUMAAB+DAAAwgwAANEMAADSDAAAGQ0AAFoNAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZH1t 6QAAHVoNAACjDQAA5w0AAC4OAAB2DgAAgw4AAIQOAACYDgAAmQ4AANoOAAD+DgAA/w4AAEQP AACGDwAAzg8AAAsQAAAMEAAAVRAAAJ0QAADfEAAAHREAAB4RAABXEQAAWBEAAFkRAABaEQAA oxEAAKURAADuEQAA7xEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAd7xEAAPARAAABEgAAAhIAAEUSAABwEgAA cRIAALISAADbEgAAHhMAAF4TAACnEwAA7xMAADUUAAB4FAAApBQAAKUUAACmFAAAuBQAALkU AAACFQAASxUAAJQVAADdFQAAJhYAAG8WAAC4FgAAARcAAEoXAACHFwAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2R9bekA AB2HFwAA0BcAABkYAABRGAAAmhgAAOMYAAAZGQAAYhkAAKsZAAD0GQAAPRoAAIYaAADPGgAA GBsAAGEbAACqGwAA8xsAADwcAACFHAAAzhwAAM8cAADQHAAA0RwAANIcAAAbHQAAHR0AAGYd AABnHQAAaB0AAHkdAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZH1t6QAAHXkdAAB6HQAAwB0AAAQeAABIHgAAkR4AANUe AAAcHwAAYx8AAKcfAADwHwAANiAAAHIgAACFIAAAhiAAAMwgAAARIQAAVSEAAJshAADfIQAA JyIAAG8iAAC2IgAA9yIAADYjAABbIwAAXCMAAKAjAADlIwAAJSQAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAd JSQAAG4kAAC3JAAA/yQAAEMlAACIJQAAzSUAABMmAAAlJgAAJiYAAG8mAACpJgAA7CYAADIn AAB7JwAAwCcAAAIoAAADKAAABCgAAAUoAAAGKAAABygAAFAoAABSKAAAmygAAJwoAACdKAAA 2SgAANooAAAMKQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2R9bekAAB0MKQAADSkAAEopAABgKQAAYSkAAKYpAACnKQAA 4SkAAOIpAADzKQAA9CkAACYqAAAnKgAAVSoAAFYqAAB2KgAAdyoAAKMqAACkKgAA2yoAANwq AAD9KgAA/ioAADArAAAxKwAAcisAAIgrAACJKwAAqSsAAKorAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZH1t6QAAHaor AADzKwAA9CsAAD0sAABvLAAAcCwAAI4sAACPLAAAwSwAAMIsAAAILQAATi0AAHctAAB4LQAA li0AAJctAACYLQAAmS0AAJotAACbLQAA5C0AAOYtAAAvLgAAMC4AADEuAABjLgAAZC4AAJIu AADTLgAA1C4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAd1C4AAPAuAADxLgAAIS8AAEcvAABILwAAhS8AAIYv AADLLwAA2S8AANovAAD3LwAA+C8AAC8wAAAwMAAATDAAAE0wAABOMAAAaDAAAGkwAACwMAAA +DAAADUxAAA2MQAASDEAAEkxAACPMQAA1zEAABoyAAAsMgAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2R9bekAAB0sMgAA LTIAAHQyAACQMgAAkTIAAJIyAADQMgAA0TIAAOgyAADpMgAAMTMAAHYzAAC9MwAABDQAAEo0 AABLNAAATDQAAE00AACWNAAAmDQAAOE0AADiNAAA4zQAACc1AABrNQAApzUAAOA1AAAkNgAA aTYAAK42AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZH1t6QAAHa42AAD3NgAAQDcAAIU3AADINwAACjgAAFE4AACUOAAA 0TgAANI4AAAUOQAAWzkAAKE5AADmOQAAEDoAABE6AABBOgAAQjoAAIk6AADROgAAFDsAAF07 AAClOwAA6TsAAOo7AAAiPAAAXTwAAJg8AADTPAAA1DwAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAd1DwAABk9 AAAaPQAAWz0AALg9AAD9PQAANj4AADc+AAB9PgAAwz4AANQ+AADVPgAA1j4AANc+AADYPgAA 2T4AACI/AAAkPwAAbT8AAG4/AABvPwAAsD8AAL8/AADAPwAACEAAAAlAAABRQAAAl0AAAN5A AADfQAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2R9bekAAB3fQAAAJUEAAGxBAACxQQAA8UEAADlCAAB+QgAAwUIAAPBC AAAXQwAAGEMAAENDAABEQwAAiUMAANBDAAAYRAAAYUQAAL9EAAAGRQAATUUAAFdFAABYRQAA WUUAAH9FAACARQAAwkUAAAlGAABMRgAAj0YAALdGAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZH1t6QAAHbdGAAC4RgAA AUcAAEpHAACTRwAA3EcAACVIAABuSAAAt0gAAABJAAABSQAAAkkAAANJAAAESQAATUkAAE9J AACYSQAAmUkAAJpJAADPSQAA0EkAAA9KAABVSgAAgkoAAINKAADHSgAA8koAAPNKAAA8SwAA VUsAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkfW3pAAAdVUsAAFZLAACeSwAAxUsAAMZLAAAMTAAAQEwAAEFMAABCTAAA hUwAAIZMAADMTAAA40wAAORMAAAtTQAATk0AAE9NAACRTQAAxU0AAMZNAAD7TQAA/E0AADNO AAA0TgAAWE4AAFlOAACHTgAAiE4AAM5OAAAVTwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2R9bekAAB0VTwAAU08AAFRP AABVTwAAcE8AAHFPAAC6TwAAAFAAAAFQAAACUAAAA1AAAARQAABNUAAAT1AAAJhQAACZUAAA mlAAAN1QAADeUAAAJlEAAFVRAABWUQAAmlEAAONRAAApUgAAbFIAALVSAAD7UgAAQlMAAFNT AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZH1t6QAAHVNTAABUUwAAm1MAAMVTAAANVAAAUVQAAJJUAADaVAAAHlUAAB9V AABZVQAAWlUAAJJVAACTVQAA2FUAABhWAABhVgAAl1YAAJhWAADdVgAAIlcAAGdXAACsVwAA 8VcAADZYAAB7WAAAwFgAAAVZAABKWQAAj1kAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAdj1kAAJBZAADRWQAA 0lkAANNZAADUWQAA1VkAANZZAADXWQAA2FkAACFaAAAjWgAAbFoAAG1aAABuWgAAr1oAALBa AAD5WgAAPFsAAElbAABKWwAAd1sAAHhbAAC/WwAAAlwAAEdcAAB5XAAAelwAAKJcAACjXAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2R9bekAAB2jXAAA6lwAAC5dAAB1XQAAul0AAAJeAABEXgAAYV4AAOhfAADpXwAA 6l8AAAJgAAADYAAALWAAAC5gAAB2YAAAfmAAAH9gAACAYAAAnGAAAJ1gAADlYAAAKGEAAHBh AAC5YQAA/mEAAERiAABOYgAAT2IAAJJiAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZH1t6QAAHWBeAABsXgAAdF4AAHVe AACrXgAA2F4AAN9eAADgXgAA4V4AAOReAAAGXwAAD18AABFfAAAaXwAAdF8AAHVfAAB2XwAA d18AAIBfAADlXwAA5l8AAOdfAABMYwAATWMAAFdlAADr1+vXw6/Dr5uvm6+bh3OHc4dzh5ti VGIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsDagAAAAAW aJYipQAwShEAT0oEAFFKBABVCAEgFWhLcdwAFmiDe8IAT0oDAFFKAwBeSgMAbUgJBHNICQQA JwEIgQRIAQAFaKqt9cYWaJYipQBPSgMAUUoDAF5KAwBtSAkEc0gJBCcBCIEESAEABWiprfXG FmiWIqUAT0oDAFFKAwBeSgMAbUgJBHNICQQnAQiBBEgBAAVoqK31xhZoliKlAE9KAwBRSgMA XkoDAG1ICQRzSAkEJwEIgQRIAQAFaKet9cYWaJYipQBPSgMAUUoDAF5KAwBtSAkEc0gJBCcB CIEESAEABWimrfXGFmiWIqUAT0oDAFFKAwBeSgMAbUgJBHNICQQnAQiBBEgBAAVopa31xhZo liKlAE9KAwBRSgMAXkoDAG1ICQRzSAkEJwEIgQRIAQAFaKSt9cYWaJYipQBPSgMAUUoDAF5K AwBtSAkEc0gJBAAYkmIAANRiAAAbYwAATmMAAE9jAABQYwAAUWMAAFJjAABTYwAAnGMAAJ5j AADnYwAA6GMAAOljAAD5YwAA+mMAAEJkAACGZAAAzmQAABVlAABpZQAAp2UAAKhlAACpZQAA v2UAAMBlAAAAZgAALWYAAC5mAAAvZgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2R9bekAAB1XZQAAZGUAAD91AABAdQAA QXUAAGR1AABldQAAZnUAALJ1AACzdQAAMnYAAG93AABwdwAAcncAABp4AACXeAAAtHgAAOva xqzaxqzaxtqSemZSPionAQiBBEgBAAVouq31xhZoiQ7FAE9KAwBRSgMAXkoDAG1ICQRzSAkE JwEIgQRIAQAFaLmt9cYWaIkOxQBPSgMAUUoDAF5KAwBtSAkEc0gJBCcBCIEESAEABWi4rfXG FmiJDsUAT0oDAFFKAwBeSgMAbUgJBHNICQQnAQiBBEgBAAVot631xhZok377AE9KAwBRSgMA XkoDAG1ICQRzSAkELgAIgQNqAAAAABZok377ABdok377ADBKEQBPSgQAUUoEAFUIAWNIAQBk aLet9cYAMwAIgRVoS3HcABZog3vCABdok377AE9KAwBRSgMAXkoDAGNIAQBkaLet9cZtSAkE c0gJBDMACIEVaEtx3AAWaIN7wgAXaJN++wBPSgMAUUoDAF5KAwBjSAEAZGi1rfXGbUgJBHNI CQQnAQiBBEgBAAVota31xhZok377AE9KAwBRSgMAXkoDAG1ICQRzSAkEIBVoS3HcABZog3vC AE9KAwBRSgMAXkoDAG1ICQRzSAkEACcBCIEESAEABWiurfXGFmiTfvsAT0oDAFFKAwBeSgMA bUgJBHNICQQAEC9mAABHZgAASGYAAI5mAADVZgAAHGcAACxnAAAtZwAALmcAAD5nAAA/ZwAA W2cAAFxnAACeZwAA32cAAOBnAAAfaAAAYmgAAKBoAAC9aAAAvmgAAAVpAABFaQAAbWkAAG5p AAC0aQAA+GkAABtqAAAcagAAXmoAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAdXmoAAJlqAACaagAA3GoAAN1q AADeagAA32oAAChrAAAqawAAc2sAAHRrAAB1awAAt2sAANJrAADTawAAGmwAAFJsAABTbAAA kWwAAMNsAADEbAAAB20AADZtAAA3bQAAeW0AAL5tAADlbQAA5m0AACluAABybgAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2R9bekAAB1ybgAAlG4AAJVuAADTbgAACW8AAApvAAAobwAAKW8AAE1vAACVbwAA228AAAdw AABNcAAAanAAAGtwAACRcAAA1HAAABtxAABBcQAAiXEAAKNxAACkcQAAyHEAAA1yAABUcgAA mnIAAMtyAADMcgAAzXIAAM5yAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZH1t6QAAHc5yAADPcgAA0HIAANFyAADScgAA G3MAAB1zAABmcwAAZ3MAAGhzAACfcwAAoHMAAOdzAAAudAAAdnQAALh0AADDdAAAxHQAAA11 AABVdQAAh3UAAIh1AADQdQAAGXYAACp2AAArdgAAdHYAAL12AAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOoA AAAAAAAAAAAAAAAAAAAAAAsPAGdkk377AG/GBwEBALet9cZkJgEABA8AZ2STfvsAAAQPAGdk fW3pAAAbvXYAAAR3AABMdwAAcXcAALR4AAC1eAAAtngAAPx4AABDeQAAhXkAAK55AACveQAA 9HkAADl6AAB7egAAwHoAAOd6AADoegAAMXsAAHZ7AAC9ewAAAHwAAAF8AABKfAAAjHwAALJ8 AACzfAAA93wAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAA AAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAA AAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8A AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE DwBnZH1t6QALDwBnZJN++wBvxgcBAQC3rfXGZCYBABu0eAAArHkAAK15AADZeQAA2nkAANt5 AAA8egAAPXoAAD56AACMewAAjXsAAAJ8AAADfAAAtHwAALV8AAC0fwAAtX8AAMN/AADEfwAA xX8AAIaAAACHgAAACIEAAAmBAACQgQAA7+HvzbPvzbPvn++L74vvd+9jSe/h7+HvAAAAAAAA AAAAAAAAAAAAAAAAAAAAADMACIEVaEtx3AAWaIN7wgAXaIkOxQBPSgMAUUoDAF5KAwBjSAEA ZGjDrfXGbUgJBHNICQQnAQiBBEgBAAVow631xhZoiQ7FAE9KAwBRSgMAXkoDAG1ICQRzSAkE JwEIgQRIAQAFaMSt9cYWaIkOxQBPSgMAUUoDAF5KAwBtSAkEc0gJBCcBCIEESAEABWjCrfXG FmiJDsUAT0oDAFFKAwBeSgMAbUgJBHNICQQnAQiBBEgBAAVowa31xhZoiQ7FAE9KAwBRSgMA XkoDAG1ICQRzSAkEMwAIgRVoS3HcABZog3vCABdoiQ7FAE9KAwBRSgMAXkoDAGNIAQBkaMCt 9cZtSAkEc0gJBCcBCIEESAEABWjArfXGFmiJDsUAT0oDAFFKAwBeSgMAbUgJBHNICQQbA2oA AAAAFmiJDsUAMEoRAE9KBABRSgQAVQgBIBVoS3HcABZog3vCAE9KAwBRSgMAXkoDAG1ICQRz SAkEGPd8AAA4fQAAXH0AAF19AABefQAAX30AAGB9AABhfQAAYn0AAKt9AACtfQAA9n0AAPd9 AAD4fQAA+X0AAPp9AAA7fgAAg34AALF+AACyfgAA+X4AAD9/AABYfwAAWX8AAJ9/AACyfwAA s38AAPp/AAD7fwAA/H8AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAd/H8AAP1/AABCgAAAjIAAALWAAAC2gAAA +oAAACyBAAAtgQAAcYEAAJKBAACTgQAA4YEAACaCAABAggAAQYIAAIiCAADPggAAEYMAADiD AAAOhAAAD4QAABCEAABYhAAAsoQAAAmFAABIhQAAhIUAAIWFAADJhQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2R9bekA AB2QgQAAkYEAAJSBAACVgQAAo4EAAKSBAAClgQAAuYEAAMGBAAA+ggAAP4IAAEGCAAA2gwAA N4MAADiDAAA5gwAAkoMAAKeDAAANhAAADoQAAIaEAADl1MDUwOXUwNSy1JiyhHCEXEhc1AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAQiBBEgBAAVoyq31xhZo jX2iAE9KAwBRSgMAXkoDAG1ICQRzSAkEJwEIgQRIAQAFaMmt9cYWaI19ogBPSgMAUUoDAF5K AwBtSAkEc0gJBCcBCIEESAEABWjLrfXGFmiNfaIAT0oDAFFKAwBeSgMAbUgJBHNICQQnAQiB BEgBAAVoyK31xhZojX2iAE9KAwBRSgMAXkoDAG1ICQRzSAkEMwAIgRVoS3HcABZog3vCABdo jX2iAE9KAwBRSgMAXkoDAGNIAQBkaMut9cZtSAkEc0gJBBsDagAAAAAWaI19ogAwShEAT0oE AFFKBABVCAEnAQiBBEgBAAVoxa31xhZoiQ7FAE9KAwBRSgMAXkoDAG1ICQRzSAkEIBVoS3Hc ABZog3vCAE9KAwBRSgMAXkoDAG1ICQRzSAkEADMACIEVaEtx3AAWaIN7wgAXaIkOxQBPSgMA UUoDAF5KAwBjSAEAZGjFrfXGbUgJBHNICQQAFIaEAACahAAA2YQAAOuEAACFhQAA5oUAAOeF AADBhgAAwoYAAMOGAAA2igAAN4oAAGOKAABqigAAjYoAAJCKAACUigAAnooAAJ+KAACqigAA 04oAAOva69rApsCOwNqAbFhsRGxYbERsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAnAQiBBEgBAAVo1631xhZoRW+CAE9KAwBRSgMAXkoDAG1ICQRzSAkEJwEIgQRIAQAFaNat 9cYWaEVvggBPSgMAUUoDAF5KAwBtSAkEc0gJBCcBCIEESAEABWjRrfXGFmhFb4IAT0oDAFFK AwBeSgMAbUgJBHNICQQbA2oAAAAAFmiNfaIAMEoRAE9KBABRSgQAVQgBLgAIgQNqAAAAABZo RW+CABdoRW+CADBKEQBPSgQAUUoEAFUIAWNIAQBkaNmt9cYAMwAIgRVoS3HcABZog3vCABdo jX2iAE9KAwBRSgMAXkoDAGNIAQBkaM6t9cZtSAkEc0gJBDMACIEVaEtx3AAWaIN7wgAXaEVv ggBPSgMAUUoDAF5KAwBjSAEAZGjZrfXGbUgJBHNICQQgFWhLcdwAFmiDe8IAT0oDAFFKAwBe SgMAbUgJBHNICQQAJwEIgQRIAQAFaM2t9cYWaI19ogBPSgMAUUoDAF5KAwBtSAkEc0gJBAAU yYUAABKGAABZhgAAmoYAAMOGAADEhgAAxYYAAMaGAADHhgAAEIcAABKHAABbhwAAXIcAAF2H AACchwAA3IcAAB2IAABeiAAAnogAAN2IAAAiiQAAa4kAALCJAAD1iQAA9okAAPeJAAA2igAA OIoAACmMAAAqjAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2R9bekAAB3TigAAQYsAAJGLAACViwAAn4sAALWLAAC8iwAA 8osAAAOMAAAnjAAAKIwAACqMAAArjAAAdI8AAHWPAAB5jwAAl48AAJiPAADr18PXw6/Dm4dy m15NQzgwOAAAAAAAAAAOFmiiWAkAbUgJBHNICQQAFBVoolgJABZoolgJAG1ICQRzSAkEABMD agAAAAAWaKJYCQAwShEAVQgBIBVoS3HcABZog3vCAE9KAwBRSgMAXkoDAG1ICQRzSAkEACcB CIEESAEABWjQrfXGFmhFb4IAT0oDAFFKAwBeSgMAbUgJBHNICQQoAQiBA2oAAAAABEgBAAVo 2a31xhZoRW+CADBKEQBPSgQAUUoEAFUIAQAnAQiBBEgBAAVo1631xhZoRW+CAE9KAwBRSgMA XkoDAG1ICQRzSAkEJwEIgQRIAQAFaNat9cYWaEVvggBPSgMAUUoDAF5KAwBtSAkEc0gJBCcB CIEESAEABWjYrfXGFmhFb4IAT0oDAFFKAwBeSgMAbUgJBHNICQQnAQiBBEgBAAVo1K31xhZo RW+CAE9KAwBRSgMAXkoDAG1ICQRzSAkEJwEIgQRIAQAFaNOt9cYWaEVvggBPSgMAUUoDAF5K AwBtSAkEc0gJBCcBCIEESAEABWjSrfXGFmhFb4IAT0oDAFFKAwBeSgMAbUgJBHNICQQAESqM AAArjAAALIwAAC2MAABAjAAAQYwAAFCMAABWjAAAb4wAAIOMAACXjAAAnYwAAJ6MAAC4jAAA 1YwAAPaMAAD3jAAA+IwAAAqNAAArjQAANI0AAESNAABbjQAAYY0AAGKNAAB8jQAAmY0AAL2N AAC+jQAAv40AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkfW3pAAAdv40AAMCNAADBjQAAwo0AAMONAADEjQAAxY0AAMaN AADHjQAAyI0AAMmNAAASjgAAFI4AAF2OAABejgAAX44AAHCOAACLjgAAlo4AAKqOAAC1jgAA to4AANGOAAD9jgAA/o4AAP+OAAAAjwAAAY8AAAKPAAADjwAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2R9bekAAB0DjwAA BI8AAAWPAAAGjwAAB48AAAiPAAAJjwAACo8AAAuPAAAMjwAADY8AAA6PAAAPjwAAEI8AABGP AAASjwAAE48AABSPAAAVjwAAFo8AABePAAAYjwAAGY8AABqPAAAbjwAAHI8AAB2PAAAejwAA H48AACCPAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZH1t6QAAHSCPAAAhjwAAIo8AACOPAAAkjwAAJY8AACaPAAAnjwAA KI8AAHGPAABzjwAAdI8AAJiPAAAkkAAAXZAAAJqQAAAKkQAAGZEAACiRAADkkQAA+5EAAE6S AACCkgAA35IAAOCSAADhkgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAARIAAAQPAGdkfW3pAAAZmI8AAJmP AADCjwAAI5AAACSQAAAlkAAAXZAAAF6QAABlkAAAmZAAAJqQAACbkAAACpEAAAuRAAAZkQAA GpEAACiRAAApkQAAZJEAAOORAADkkQAA5ZEAAPuRAAD8kQAATpIAAE+SAAB4kgAAgZIAAIKS AACDkgAA35IAAOCSAADhkgAA9eri6vXq2M3Fzbuwu6y7rKKXj5eii4F2opePl4F2cmEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgFWhLcdwAFmiDe8IAT0oDAFFKAwBeSgMAbUgJ BHNICQQABhZog3vCAAAUFWhFb4IAFmhFb4IAbUgJBHNICQQAEwNqAAAAABZoRW+CADBKEQBV CAEGFmiNfaIAAA4WaI19ogBtSAkEc0gJBAAUFWiNfaIAFmiNfaIAbUgJBHNICQQAEwNqAAAA ABZojX2iADBKEQBVCAEGFmiJDsUAABQVaIkOxQAWaIkOxQBtSAkEc0gJBAATA2oAAAAAFmiJ DsUAMEoRAFUIAQ4WaJN++wBtSAkEc0gJBAAUFWiTfvsAFmiTfvsAbUgJBHNICQQAEwNqAAAA ABZok377ADBKEQBVCAEOFmiWIqUAbUgJBHNICQQAFBVoliKlABZoliKlAG1ICQRzSAkEABMD agAAAAAWaJYipQAwShEAVQgBACAyADGQaAE6cH1t6QAfsIIuILDGQSGwNgUisDcFI5CJBSSQ bgQlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoEGAASAAEA CwEPAAcABAAEAAQAAAAEAAgAAACYAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4A AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAB2AgAAdgIAAHYCAAB2AgAA dgIAAHYCAAB2AgAAdgIAAHYCAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA+AgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAqAAAADYG AAA2BgAAFgAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAuAAAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAGgBAABIAQAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACwAwAANgYAADIGAAAYAAAA wAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAE AADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAyBgAAKAIAANgBAADoAQAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAE AABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAA QAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAE AABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAA MAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAE AAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAOAEAAFgBAAD4AQAACAIAABgCAABWAgAA fgIAACAAAABPSgQAUEoEAFFKBABfSAEEbUgHBG5IBwRzSAcEdEgHBAAAAABOAABg8f8CAE4A DBAAAAAAAAAAAAgAUwB0AGEAbgBkAGEAcgBkAAAADAAAABJkFAEBABSkyAAYAENKFgBfSAEE YUoWAG1IBwRzSAcEdEgJBAAAAAAAAAAAAAAAAAAAAAAAAEoAQWDy/6EASgAMDQAAAAAAABAA GQBBAGIAcwBhAHQAegAtAFMAdABhAG4AZABhAHIAZABzAGMAaAByAGkAZgB0AGEAcgB0AAAA AABYAGkA8/+zAFgADA0AAAAAAAAwBg8ATgBvAHIAbQBhAGwAZQAgAFQAYQBiAGUAbABsAGUA AAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAwAGsg9P/BADAAAA0AAAAA AAAwBgsASwBlAGkAbgBlACAATABpAHMAdABlAAAAAgAMAAAAAABGAFpAAQDyAEYADAwQAH1t 6QAwBggATgB1AHIAIABUAGUAeAB0AAAADAAPABJk8AABABSkAAAQAENKFQBPSgUAUUoFAGFK FQBCAP5v8v8BAUIADAAPAH1t6QAwBg0ATgB1AHIAIABUAGUAeAB0ACAAWgBjAGgAbgAAABAA Q0oVAE9KBQBRSgUAYUoVAEAAJ0Dy/xEBQAAMDQAAolgJADAGEABLAG8AbQBtAGUAbgB0AGEA cgB6AGUAaQBjAGgAZQBuAAAACABDShAAYUoQAD4AHkABACIBPgAMDRMAolgJADAGDQBLAG8A bQBtAGUAbgB0AGEAcgB0AGUAeAB0AAAAAgASAAgAQ0oUAGFKFABAAP4v8v8xAUAADAESAKJY CQAwBhIASwBvAG0AbQBlAG4AdABhAHIAdABlAHgAdAAgAFoAYwBoAG4AAAAEAHRICQQ+AGpA IQEiAT4ADA0VAKJYCQAwBg4ASwBvAG0AbQBlAG4AdABhAHIAdABoAGUAbQBhAAAAAgAUAAYA NQiBXAiBSAD+L/L/UQFIAAwBFACiWAkAMAYTAEsAbwBtAG0AZQBuAHQAYQByAHQAaABlAG0A YQAgAFoAYwBoAG4AAAAKADUIgVwIgXRICQRaAJlAAQBiAVoADA0XAKJYCQAwBhAAUwBwAHIA ZQBjAGgAYgBsAGEAcwBlAG4AdABlAHgAdAAAAAwAFgASZPAAAQAUpAAAFABDShAAT0oGAFFK BgBeSgYAYUoQAFoA/i/y/3EBWgAMARYAolgJADAGFQBTAHAAcgBlAGMAaABiAGwAYQBzAGUA bgB0AGUAeAB0ACAAWgBjAGgAbgAAABgAQ0oQAE9KBgBRSgYAXkoGAGFKEAB0SAkEUEsDBBQA BgAIAAAAIQDp3g+//wAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy07DMBBF90j8 g+UtSpyyQAgl6YLHjseifMDImSQWydiyp1X790zSVEKoIBZsLNkz954743K9Hwe1w5icp0qv 8kIrJOsbR12l3zdP2a1WiYEaGDxhpQ+Y9Lq+vCg3h4BJiZpSpXvmcGdMsj2OkHIfkKTS+jgC yzV2JoD9gA7NdVHcGOuJkTjjyUPX5QO2sB1YPe7l+Zgk4pC0uj82TqxKQwiDs8CS1Oyo+UbJ FkIuyrkn9S6kK4mhzVnCVPkZsOheZTXRNajeIPILjBLDsAyJX89nIBkt5r87nons29ZZbLzd jrKOfDZezE7B/xRg9T/oE9PMf1t/AgAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAA CwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tP xwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGj PM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/ s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAI AAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrD IBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfw fCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT 9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQBg/7/1pAYAAKIbAAAWAAAAdGhlbWUv dGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRntvYyd2Gkd1qtixG2hSotgt6nG8O96dZnZn NTNO6htqj0hIiII4UIkbBwRUaiUu5dMEiqBI/Qq8mdld78RrkrQRraA5tPbsb97/95s366vX 7sUMHRIhKU/aXv1yzUMk8XlAk7Dt3Rr2L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfyLX cduLlErXl5akD8tYXuYpSeDZmIsYK/gqwqVA4COQG7Ol5VptdSnGNPFQgmMQu4MFlRJ7G7nc HgPhiZJ6wWdioKWSCnBwUNcQOZVdJtAhZm0PdAT8aEjuKQ8xLBU8aHs18+ctbVxdwuvZJqYW 7C3t65u/bF+2IThYNjpFOCqU1vuN1pWtQr4BMDWP6/V63V69kGcA2PfBVWtLWWajv1bv5DJL IPtxXna31qw1XHxJ/sqcza1Op9NsZbZYoQZkPzbm8Gu11cbmsoM3IItvzuEbnc1ud9XBG5DF r87h+1daqw0Xb0ARo8nBHFontN/PpBeQMWfblfA1gK/VMvgMBdVQlJdWMeaJWlhsMb7LRR8Q GsmwoglS05SMsQ8l3MXxSFCsNeB1gktP7JIv55a0MiR9QVPV9j5MMbTDTN7LZz+8fPYEHd9/ enz/5+MHD47v/2QFObu2cRKWd7347vO/Hn2C/nzy7YuHX1bjZRn/24+f/vrLF9VA6J+ZOc+/ evz708fPv/7sj+8fVsA3BR6V4UMaE4lukiO0z2NwzETFtZyMxPl2DCNMyzs2k1DiBGstFfJ7 KnLQN6eYZdlx7OgQN4K3BfBHFfD65K5j8CASE0UrNN+IYge4yznrcFEZhRtaVynMw0kSVisX kzJuH+PDKt1dnDj57U1SYM68LB3HuxFxzNxjOFE4JAlRSD/jB4RUeHeHUieuu9QXXPKxQnco 6mBaGZIhHTnVNNu0TWPIy7TKZ8i3E5vd26jDWZXXW+TQRUJXYFZh/JAwJ4zX8UThuErkEMes HPAdrKIqIwdT4ZdxPakg0yFhHPUCos+0+dL/SIC/paTfwEBZlWnfZdPYRQpFD6pk7mDOy8gt ftCNcJxWYQc0icrYD+QBlChGe1xVwXe52yH6O+QBJwvTfZsSJ92ns8EtGjomzQpEP5mIiihe J9yp38GUjTExVAOs7nB1TJN/Im5GgbmthosjbqDK5988qrD7baXsTTi9qnpm+wRRL8KdpOcu FwF9+9l5C0+SPQINMd+n78j5HTl7/3lyXtTPF0/JMxYGgtaziJ20zdwdLx67x5SxgZoysiPN 5C3h8An6sKg3mvsmKe5haQQfdSuDBgcXCmz2IMHVx1RFgwinMLXXPS0klJnoUKKUS7gumuVK 2RoPk7+yl82mvoZY6pBY7fLALq/o5fy2UYgxVoXmTpsrWtECzqps5UomFHx7FWV1bdSZtdWN aYYVHW2FyzrE5l4OIS9cg8UimjDVIJiFIMqrcOPXquG2gxkJdNxtjvK0mCxcZIpkhAOS5Uj7 PZ+juklSXitzjmg/bDHoq+MpUStpa2mxr6HtLEkqq2ssUJdn73WylFfwLEsg7WQ7sqTcnCxB R22v1VxuesjHadsbw0UZPsYpZF3qQRKzEF41+UrYsj+1mU2Xz7LZyh1zm6AOLz9s3Occdngg FVJtYRnZ0jCPshJgidZk7V9uQlgvyoEKNjqbFStrUAxvzAqIo5taMh4TX5WTXVrRsbNfMyrl E0XEIAqO0IhNxD6G9OtSBX8CKuF9h2EE/QXezulom0cuOWdNV34nZnB2HbM0whnd6hbNO9nC DSEVNphvJfPAt0rbjXPnd8W0/AW5Ui7j/5kr+jyB1w8rgc6ADy+GBUa6U9oeFyriwEJpRP2+ gMnBcAdUC7zhhcdQVPB62vwvyKH+3/aclWHaGm6Rap+GSFA4j1QkCNkDWjLVd4qwenZ2WZEs E2QqqmSuTK3ZI3JI2FBz4Ko+2z0UQakbNslowOBO1p/7PeugUaiHnHK/OUxWnL22B/7tycc2 Mzjl8rAZaPL4FyYW48HsVLX7zfb87C07oh/MxqxG3hWgrHQUtLK2f0UTznnUWsaa83i5mRsH WZz3GBaLgSiFl0hI/wPnHxU+I6aM9YE65PvArQh+vtDCoGygqi/ZwQNpgrSLIxic7KItJi3K hjYbnXTU8sP6gifdQu+JYGvLzpLvcwa7GM5cdU4vXmSwswg7sbZrC0MNmT3ZorA0zm8yJjHm R7Lyj1l8dBcSvQU/GkyYkqaY4JcqgWGGHpg+gOa3Gs3Wjb8BAAD//wMAUEsDBBQABgAIAAAA IQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5y ZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNj Mt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU +YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUF KKLGzOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfn wAAAADYBAAALAAAAAAAAAAAAAAAAADABAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBr eZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAAABkCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIu eG1sUEsBAi0AFAAGAAgAAAAhAGD/v/WkBgAAohsAABYAAAAAAAAAAAAAAAAA1gIAAHRoZW1l L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAA AAAAAACuCQAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAA AAAFAAUAXQEAAKkKAAAAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBz dGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5v cGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0i ZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFj Y2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFj Y2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhs aW5rIi8+BQBNAGUAbgB0AGgA/zkAAF9WAABMWwAAb28AAKxxAACGeAAACHkAAD56AAA2ewAA wX4AADaCAAAnhAAA4YoAAAIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAA4bqCEQIATQBNAAAA AAAAAAAAAAAAAAAAAAAAAAAAhr6CEQIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAA/76CEQIA TQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAAScGCEQIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAA R8KCEQIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAAm8OCEQIATQBNAAAAAAAAAAAAAAAAAAAA AAAAAAAApsOCEQIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAA4cOCEQIATQBNAAAAAAAAAAAA AAAAAAAAAAAAAAAAJMWCEQIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAANciCEQIATQBNAAAA AAAAAAAAAAAAAAAAAAAAAAAAG8aCEQIATQBNAAAAAAAAAAAAAAAAAAAAAAAAAAAAfMiCEdqt 9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt 9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt 9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt 9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAANqt9cYAAAAAAAAAAAAAAAAAAAAA AAAkAAAAsAAAAOkAAAAmAQAAlgEAAKUBAAC0AQAAcAIAAIcCAADaAgAADgMAAGsDAABuAwAA AAAAAOGKAAAOAADkAAALAP////8ACAAAYF4AAFdlAAC0eAAAkIEAAIaEAADTigAAmI8AAOGS AABKAAAAXgAAAGAAAABmAAAAaQAAAGoAAABsAAAAcQAAAAAIAABaDQAA7xEAAIcXAAB5HQAA JSQAAAwpAACqKwAA1C4AACwyAACuNgAA1DwAAN9AAAC3RgAAVUsAABVPAABTUwAAj1kAAKNc AACSYgAAL2YAAF5qAABybgAAznIAAL12AAD3fAAA/H8AAMmFAAAqjAAAv40AAAOPAAAgjwAA 4ZIAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcA AABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABfAAAAYQAAAGIAAABjAAAAZAAAAGUAAABnAAAA aAAAAGsAAABtAAAAbgAAAG8AAABwAAAADwAA8DgAAAAAAAbwGAAAAAIEAAACAAAAAQAAAAEA AAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAA AAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA BAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEA AAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8MAAoAAAAAAeG6ghH/////AAAAAYa+ghH/ ////AAAAAf++ghH/////AAAAAUnBghH/////AAAAAUfCghH/////AAAAAZvDghH/////AAAA AabDghH/////AAAAAeHDghH/////AAAAASTFghH/////AAAAARvGghH/////AAAAATXIghH/ ////AAAAAXzIghH/////pTkAAKNUAACdWAAAMm4AAL1wAACAeAAAA3kAAA96AABBegAAhX0A AIV9AABdfwAAdocAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAoAAAAJ AAAACwAAAP85AABfVgAATFsAAG9vAACscQAAhngAAAh5AAA+egAANnsAAMF+AAA2ggAAJ4QA AHaHAAAAAAAA1AAAAN0AAAAJAQAAEgEAAGoBAABvAQAArwEAALgBAADlAgAA6AIAAAYDAAAO AwAAXQUAAGcFAAApBgAALAYAAFEPAABaDwAA4xUAAOYVAAAHFgAADxYAABcbAAAdGwAAHhsA ACEbAAAqGwAAMxsAADwbAABCGwAAQxsAAEYbAABHGwAASRsAAE8bAABYGwAA7xsAAPcbAAD4 GwAAARwAACgcAAAxHAAAXxwAAGgcAADgHAAA5hwAAOccAADqHAAA8xwAAPwcAAB7HQAAhB0A ANcdAADfHQAA4B0AAOkdAACJJQAAjSUAAKEmAAClJgAApiYAAKsmAACsJgAAryYAAGkqAABz KgAA6ysAAPQrAACtLQAAsy0AALQtAAC3LQAAuC0AALotAADALQAAyS0AAOYtAADsLQAA7S0A APAtAAD5LQAAAi4AAIcuAACKLgAAcjAAAHswAADFMAAAzjAAACUxAAArMQAALDEAAC8xAAA4 MQAAQTEAAKszAAC0MwAAPTYAAEY2AAB1NwAAfjcAAMY3AADPNwAADzgAABg4AAAUOQAAITkA AM05AADWOQAA9joAAPw6AAD9OgAAADsAAIM8AACQPAAAHz8AACg/AAB1PwAAfj8AAKNAAACm QAAAWUMAAFxDAABGRAAAT0QAAP9EAAACRQAAakUAAG1FAADuRQAA8UUAABtGAAAeRgAATUYA AFBGAAB5RgAAfEYAAF9KAABoSgAASEsAAFFLAADLSwAA0UsAANJLAADVSwAA3ksAAOdLAAC2 VgAAw1YAAMJaAADLWgAA+1oAAARbAABfXAAAaFwAAMNcAADNXAAAWF0AAGVdAADSXQAA2V0A ANtdAADfXQAA910AAP9dAAADXgAAD14AAGpfAABxXwAAzGAAANhgAACIYQAAkWEAAO9hAAD1 YQAAOmIAAD1iAACoYgAAr2IAAJJjAACaYwAAAGQAAANkAABhZAAAaGQAANJkAADZZAAA9WQA AP5kAABFZQAATmUAAGhlAABtZQAAsWYAALtmAAAvZwAANWcAADZnAAA5ZwAAQmcAAEtnAABb ZwAAYWcAAHJnAAB9ZwAAg2cAAIhnAAC+ZwAAx2cAAHFoAAB3aAAAeGgAAHtoAACfaAAAqmgA ALpoAADDaAAAyWgAAM5oAADiaAAA6WgAAKppAACwaQAAsWkAALRpAAC1aQAAt2kAAL1pAADG aQAA1mkAANxpAADiaQAA7WkAAPNpAAD4aQAALmoAADdqAACKbwAAlW8AAFVwAABgcAAApngA ALN4AABfeQAAaXkAAN18AADqfAAAE4MAAByDAAAZhAAAJoQAAGGEAABphAAAcoQAAHyEAAAA hQAACYUAAA2FAAAWhQAAPYUAAEOFAABqhgAAb4YAAIGGAACKhgAAmYYAAKKGAAB0hwAA6ogA APSIAAARiQAAF4kAACCJAAAmiQAA2IkAAN2JAADqiQAA84kAAPSJAAD5iQAAcYoAAHeKAACn igAArYoAAOKKAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAB0ABwAdAAcAAAAAAFkCAAB6AgAA0QIA ANgCAABiAwAAZAMAAKcDAACxAwAA7wMAAPMDAAA4BAAAOgQAAIEEAACEBAAAxQQAAM8EAAAc BQAAIgUAAF0FAABnBQAApgUAAK4FAADqBQAA8AUAADEGAAA0BgAAeQYAAIEGAADdBgAA5wYA AIkHAACQBwAA0QcAANoHAABYCAAAWwgAAKAIAACkCAAA4ggAAOoIAABaCQAAaQkAAEgKAABQ CgAAIQsAACwLAABhCwAAagsAAKoLAACsCwAA8gsAAPkLAAA4DAAAOwwAAHsMAACEDAAACg0A ABQNAACcDQAAqg0AABUOAAAgDgAALg4AADQOAAB3DgAAhg4AAMAOAADQDgAAIRAAACwQAACi EAAAtBAAAO8QAAD1EAAAbhEAAHcRAAC3EQAAwBEAAD8UAABKFAAA0hQAAOEUAADDFQAAyhUA AAcWAABCFgAASxYAAFUWAACUFgAAmRYAANgWAADgFgAAHxcAACYXAABmFwAAaRcAAKoXAACv FwAA8xcAAPcXAAA5GAAAPxgAAHUYAACBGAAAzxgAANkYAAAUGQAAGxkAAFgZAABhGQAAnhkA AKIZAADiGQAA9BkAAHIaAAB6GgAAuRoAAMEaAAD6GgAABRsAADkbAABaGwAAoxsAAKobAADo GwAA7hsAACgcAAAxHAAAcRwAAHgcAAC6HAAAwBwAAAIdAAAHHQAARh0AAE8dAACLHQAAkh0A ANAdAADWHQAAFh4AACQeAAByHgAAeR4AAKweAAC7HgAA7x4AAPkeAAA1HwAAOB8AAMMfAADK HwAAByAAABYgAACgIAAAqiAAABMhAAAbIQAAUyEAAF4hAABnIQAAbyEAAK0hAAC5IQAALSIA ADciAABcIgAAYSIAAH0iAACCIgAAqiIAAK8iAADiIgAA7CIAADcjAABDIwAAeyMAAIYjAACP IwAAlyMAALAjAAC6IwAA+iMAAAIkAABGJAAASSQAAHYkAAB+JAAAyCQAANQkAAARJQAAFCUA AFclAABbJQAAXiUAAHYlAAB+JQAAiCUAAJslAACqJQAAaiYAAHQmAACbJgAAtiYAANomAADn JgAAJCcAAEUnAABOJwAAWScAAIwnAACbJwAA1CcAANgnAADgJwAA7ScAAP4nAAAMKAAANigA AD4oAAD7KAAAAykAADkpAABHKQAA2ikAAN0pAAAdKgAAJCoAAHoqAAB8KgAA1CoAANoqAAA0 KwAAOysAAHkrAACDKwAAwCsAAM0rAAAHLAAACiwAAE0sAABcLAAA5iwAAO0sAAAqLQAAMS0A AAMuAAAILgAAJy4AAC4uAABsLgAAcy4AALEuAADBLgAA+i4AAAAvAABDLwAAWS8AAIgvAACR LwAAyy8AANEvAAANMAAAFDAAAFQwAABXMAAAlzAAAJ4wAABeMQAAYDEAAOkxAADvMQAAFDIA ACMyAACMMgAAjjIAANQyAADZMgAAYDMAAGgzAABeNQAAaDUAALs1AADENQAAADYAAAY2AAA6 NgAARjYAAIQ2AACLNgAAyTYAAM02AADZNgAA6DYAAHI3AAB+NwAAtjcAAL03AADDNwAAzzcA AAw4AAAYOAAAVzgAAFk4AAAoOQAATTkAAG85AAB6OQAAtDkAALk5AAA8OgAAPzoAAIE6AACF OgAAxDoAAMw6AADzOgAAFjsAABs7AAArOwAAjDsAAJM7AADTOwAA1jsAABs8AAAePAAAZDwA AHA8AADCPAAAxjwAAAk9AAARPQAAUD0AAFU9AADFPQAAzT0AAAw+AAAVPgAATz4AAFY+AACS PgAAmT4AAFM/AABaPwAAA0AAAAdAAAAEQQAAE0EAABJCAAAcQgAAzUIAANRCAABCQwAAREMA AKRDAACmQwAAEkQAABhEAADPRAAA1kQAAOdEAADsRAAAM0UAADRFAABSRQAAV0UAAJdFAACf RQAAyUUAAM5FAAD/RQAABEYAADdGAAA8RgAAXEYAAGFGAADRRgAA2EYAABhHAAAbRwAAvUcA AMVHAAAESAAAE0gAAJ1IAACoSAAAKUkAADFJAACdSQAApUkAAOZJAADuSQAAuEoAALpKAAD+ SgAAAUsAAEVLAABSSwAAnksAAKBLAADoSwAA70sAABBMAAAWTAAAVEwAAF5MAACVTAAAnUwA AN1MAADhTAAAIk0AADRNAADbTQAA300AABtOAAAkTgAAZE4AAHVOAAD/TgAADU8AAKdPAACr TwAAMVAAADVQAADdUAAA41AAABBRAAAmUQAA2FEAAOdRAABzUgAAeVIAAD9TAABHUwAAT1MA AFhTAADCUwAAylMAAAVUAAANVAAASlQAAFBUAAB/VAAAiFQAAHlYAAB9WAAA6FgAAOxYAAAr WQAANlkAAHNZAAB1WQAAvFkAAMNZAAABWgAACFoAAEdaAABMWgAAlVoAAJxaAADXWgAA31oA AB5bAAAhWwAAU1sAAGJbAABFXAAAR1wAAIlcAACQXAAA0VwAANhcAABsXQAAb10AAANeAAAs XgAAkV4AAJReAAAfXwAAIl8AAENfAABPXwAAE2EAABVhAADfYgAA7mIAAIRmAACJZgAADmcA ABxnAABbZwAAlGcAABVoAAA4aAAA0WgAANNoAABPaQAAdGkAAKlqAACtagAA0moAAOFqAABo awAAc2sAAOprAAAFbAAAMWwAADRsAAB5bAAAmWwAALtsAADBbAAAEG0AABVtAABYbQAAX20A ANNtAADwbQAAHG4AACBuAAAubgAAL24AALlwAADEcAAAA3EAAApxAAChcQAAo3EAADxyAAA9 cgAAfnIAAIZyAADDcgAAyHIAADRzAAA4cwAAeXMAAH1zAAACdAAACHQAAE10AABQdAAAj3QA AJZ0AAC0dAAAunQAAPp0AAABdQAAO3UAAEJ1AABidQAAcXUAAAB2AAAGdgAARHYAAE52AACM dgAAjnYAALh2AAC+dgAAAncAAAh3AABIdwAAS3cAAKV3AACqdwAAtHcAALp3AAADeAAACXgA AEt4AABVeAAAlXgAALR4AAC8eAAAwngAAAN5AAAIeQAAd3kAAH95AACUeQAAmnkAAOR5AADt eQAALHoAADh6AABKewAAUnsAALh8AAC+fAAAJ30AACt9AABOfQAAWH0AAMd+AADWfgAAg38A AIx/AADvfwAA9X8AAFmAAABdgAAALoEAADeBAACGhAAAkoQAAEeFAABWhQAAyYUAANiFAACZ hgAAqYYAACiHAAA3hwAAdIcAAOKKAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAHAAAAAAA5cgAAXHIAAHZzAACOcwAAdIcAAIeIAACZiAAACokAABiJAAAZ iQAAJ4kAAOSJAAD6iQAA4ooAAAcABQAHAAUABwAHAAUABwAFAAcABQAHAAUABwALAAAABAAA AAgAAADlAAAAAAAAAAkAAACiWAkAOBIwANNJXABFb4IAjX2iAJYipQCDe8IAiQ7FAEtx3AB9 bekAk377AAAAAAB0hwAAdocAAAAAAAABAAAA/0ADgAEAagMAAGoDAAAAAAAAAQABAGoDAAAA AAAAagMAAAAAAAACEAAAAAAAAADhigAAcAAAEABAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4A BQBNAGUAbgB0AGgA//8CAAgAAAAAAAAAAAAAAAAAAAAAAAAAAQD//wIAAAAAAAAA//8AAAIA //8AAAAA//8AAAIA//8AAAAACAAAAEcekAEAAAICBgMFBAUCAwT/KgDgQXgAwAkAAAAAAAAA /wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUekAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMukAEAAAILBgQCAgIC AgT/KgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/PZABAAACBwMJAgIFAgQE /yoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAANy6QAQAA Ag8FAgICBAMCBP8CAOH/rABACQAAAAAAAACfAQAAAAAAAEMAYQBsAGkAYgByAGkAAAA5PZAB AAACCwYJAgIEAwIE/wIA4f/8AEAJAAAAAAAAAJ8BAAAAAAAAQwBvAG4AcwBvAGwAYQBzAAAA NS6QAQAAAgsGBAMFBAQCBP8uAOFbYADAKQAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAA QRKQAQEAAgQFAwUEBgMCBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAYQBtAGIAcgBpAGEA IABNAGEAdABoAAAAIgAEAHGIiBgA8MQCAACpAQAAAACSrfXG2q31xgAAAAADAAAAAACOEgAA 5nQAABUARQAAAAQAA5D5AAAAjhIAAOZ0AAAVAEUAAAD5AAAAAAAAAIECAPAQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYFiQW0ALQAgYEyMAAAAAAAAAAA AAAAAAAAL4cAAC+HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAUqDEQDwEAAIAPz9AQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAhIUAAAAAAJ8P8PAAkkUAAAAAAAAHA1AAD///9/////fwAAAAD///9/ ////f////384EjAAAAQAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAhBAAAAAAAAAAAAAAAAAAA AAAAABAcAAAHAAAAAAAAAAAAeAAAAHgAAAAAAAAAAAAAAKAFAAAAAAAACwAAAAAAAADcAAAA //8SAAAAAAAAAAAAAAAAAAAABQBNAGUAbgB0AGgABQBNAGUAbgB0AGgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAACAEAAAwAAAABAAAAaAAAAAQAAABwAAAABwAAAIAAAAAIAAAAlAAAAAkA AACkAAAAEgAAALAAAAAMAAAA0AAAAA0AAADcAAAADgAAAOgAAAAPAAAA8AAAABAAAAD4AAAA EwAAAAABAAACAAAA5AQAAB4AAAAIAAAATWVudGgAAAAeAAAADAAAAE5vcm1hbC5kb3RtAB4A AAAIAAAATWVudGgAAAAeAAAABAAAADMAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29y ZAAAAEAAAAAAzBwu9BfMAUAAAAAAZPut/RfMAQMAAAAVAAAAAwAAAI4SAAADAAAA5nQAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmu MAAAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAAoAAAABcA AACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAADdAAAA AgAAAOQEAAAeAAAAGAAAAFVuaXZlcnNpdOR0IFT8YmluZ2VuAAAAAAMAAAD5AAAAAwAAAEUA AAADAAAAL4cAAAMAAAAAAA4ACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAA AQAAAAEAAAAADBAAAAIAAAAeAAAABgAAAFRpdGVsAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAA RAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEA AABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAA XwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwA AABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAAD+////dAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAA egAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcA AACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAA/v///5AAAACRAAAAkgAAAJMAAACUAAAA lQAAAJYAAAD+////mAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAP7////9/////f///6IA AAD+/////v////7///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA kJOevv0XzAGkAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHMAAADoNgAAAAAAAFcAbwByAGQARABvAGMA dQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB AQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTk AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACPAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJcAAAAAEAAAAAAAAAEAQwBvAG0A cABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAD+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARiAA AABNaWNyb3NvZnQgV29yZCA5Ny0yMDAzLURva3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdv cmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------030307000701020902000109-- From Ruediger.Geib@telekom.de Wed May 25 00:07:05 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C58E06BE for ; Wed, 25 May 2011 00:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9jkreTq4fUn for ; Wed, 25 May 2011 00:07:04 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id AB877E069A for ; Wed, 25 May 2011 00:07:03 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 25 May 2011 09:05:32 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 25 May 2011 09:05:31 +0200 From: To: Date: Wed, 25 May 2011 09:05:29 +0200 Thread-Topic: [PCN] Revised 3-in-1 draft and status of RFC5696 Thread-Index: Acv8JidjJNrJ3s6YQ7W23VuGzoCftgOFYgxgAAo0HVAAAZCc0AACKuUgA02ipVAAv8jiAA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4BE0@HE111648.emea1.cds.t-internal.com> References: <4D9448F9.7040309@informatik.uni-tuebingen.de> <002e01cbef88$b1cc7b70$15657250$@com> <4D94EF65.20001@informatik.uni-tuebingen.de> <4D958E90.4060103@informatik.uni-tuebingen.de> <201104011222.p31CMCas029062@bagheera.jungle.bt.co.uk> <003e01cbf074$d2042270$760c6750$@com> <000c01cbfa92$38da9750$aa8fc5f0$@com> <201104150314.p3F3E8HU001775@bagheera.jungle.bt.co.uk> <000c01cbfb47$8c8ef520$a5acdf60$@com> <4DA81828.4090002@informatik.uni-tuebingen.de> <201104151450.p3FEoiab003742@bagheera.jungle.bt.co.uk> <000901cbfc13$ee81e720$cb85b560$@com> <201104161105.p3GB57Iv007037@bagheera.jungle.bt.co.uk> <000c01cc0a3c$e2c29420$a847bc60$@com> <9510D26531EF184D9017DF24659BB87F32A9301EB3@EMV65-UKRD.domain1.systemhost.net> <001d01cc0a6c$415ab0b0$c4101210$@com> <9510D26531EF184D9017DF24659BB87F32A930207E@EMV65-UKRD.domain1.systemhost.net> <002c01cc17ab$c92e1a30$5b8a4e90$@com> In-Reply-To: <002c01cc17ab$c92e1a30$5b8a4e90$@com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 07:07:05 -0000 Hi Toby, Single Marking is fine with me, if it is just single marking. That seems to= be option (A) then. I like PSDM in the flavour proposed by Michael (and me) lately: http://tools.ietf.org/html/draft-menth-pcn-marked-signaling-ac I think the proposal is an additional edge behaviour rather than an additio= nal marking scheme. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby = Moncaster Sent: Saturday, May 21, 2011 1:40 PM To: philip.eardley@bt.com; bob.briscoe@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696 I have now released the revised version of the 3-in-1 draft. After much thinking and pondering I reckon the only sensible thing regardin= g RFC5696 is to revise it (rather than deprecating it). There are two reasons for this, firstly the 3-in-1 encoding doesn't necessarily provide the cleanest approach for a single marking scheme (since it fixes which marker marks 01 and 11) and secondly there is still a desire among some to leave alternative encodings open. There are two routes to revising the document: (A) Changing it to a single-marking encoding but keep it as a standard. Tha= t requires: - deprecate the EXP encoding - remove the more irrelevant appendixes, and move the others into a -06 version of 3-in-1 (for instance all the discussion of which DSCP to use). (B) Change it to an experimental encoding but tighten the rules about it no= t being allowed in any other PCN-domain (in other words put the onus on experimenters to be careful). That requires: - update the rules on experimental schemes - Add relevant warning text and re-word it to be clear this is only for experiments - Move the DSCP related appendix to the 3-in-1 document Of the two options (A) is relatively easy and would be my preference. (B) requires lots of work and I would want a really convincing argument that schemes such as PSDM are of interest to an operator before we went down tha= t route. In either case we are going to have to do some more work on 3-in-1, but hopefully mainly cut-and-paste... If I get another burst of energy today I may release a suggested draft for option (A)... Toby > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: 04 May 2011 17:17 > To: toby@moncaster.com; bob.briscoe@bt.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Revised 3-in-1 draft and status of RFC5696 > > Toby said: > It looks like we are going to have to create a completely new combined > document after all. > ... > In order to handle the two distinct cases you set out above I would > suggest > that such a document has two parts: a basic encoding (for single > marking > schemes) and a full encoding (for dual marking schemes). This would > make the > choice of encoding a configuration option similar to the option of > whether > to turn on the two marking schemes or not. > > Question - would this require any changes to any other documents? > > [phil] > I don't know whether a completely new combined doc is the best way. > Maybe the RFC editor can advise? > (an alternative might be to update the baseline so it just applied to > single marking (with EXP essentially deprecated) plus a new doc on 3- > in-1, or to update the baseline with changes so that it includes both > (ie defines EXP as per 3-in-1 or as deprecated). Anyway, this seems > "just" a process question. > > If it is a single doc, then the doc would split into 2 sections, with > parallel sub-sections (encoding, applicability, allowed transitions). > > I don't understand your comment about marking schemes (rfc5670 defines > one Metering behaviour, the marking section of that doc says " A PCN- > packet MUST be marked to reflect the metering results by > setting its encoding state appropriately, as specified by the > specific encoding scheme that applies in the PCN-domain." > > Which docs affected? > From technical point of view, I think all are ok. Edge behaviours > basically unaffected - clearly SM & CL refer to teh right sections > > RFC 5670 is unaffected, i think. There is one point only where there > might need to be thought -in section B.2 of rfc5670 (an Informative > appendix on Implementation Notes) (I think the wording of the new doc > should allow the text here still to be valid - anyway, the point is > extremely pedantic) _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From hannes.tschofenig@gmx.net Thu May 26 16:45:27 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1B6E06A0 for ; Thu, 26 May 2011 16:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.145 X-Spam-Level: X-Spam-Status: No, score=-99.145 tagged_above=-999 required=5 tests=[AWL=3.454, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BKJheNYifHI for ; Thu, 26 May 2011 16:45:24 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 859FAE0697 for ; Thu, 26 May 2011 16:45:24 -0700 (PDT) Received: (qmail invoked by alias); 26 May 2011 23:45:23 -0000 Received: from 70-35-43-162.static.wiline.com (EHLO [10.128.4.20]) [70.35.43.162] by mail.gmx.net (mp008) with SMTP; 27 May 2011 01:45:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Z1TJ7TsfZPaet1rS7s0r+KILq1Mv+/02PJHvVeU DkRKwMmGHBGlc0 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 02:45:20 +0300 Message-Id: To: pcn@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [PCN] Deployment Status? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 23:45:27 -0000 Hi guys,=20 I was wondering what the deployment status of the PCN mechanism is.=20 Is it ending up like so many other QoS proposals? If so, did we learn = something about what went wrong? Ciao Hannes =20= From Ruediger.Geib@telekom.de Thu May 26 23:47:46 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C234BE067A for ; Thu, 26 May 2011 23:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9x4fwBpvi-o for ; Thu, 26 May 2011 23:47:45 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6C30AE0651 for ; Thu, 26 May 2011 23:47:45 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 27 May 2011 08:46:15 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 27 May 2011 08:46:14 +0200 From: To: Date: Fri, 27 May 2011 08:46:13 +0200 Thread-Topic: [PCN] Deployment Status? Thread-Index: Acwb/wCkw4ZR9imeSl6Q/yP+/057CwAN6vBg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D084106F4DA@HE111648.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Deployment Status? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 06:47:46 -0000 Hi Hannes, PCN is specified in a modular way. That's an advantage and parts of PCN may= see deployment. Bob mentioned, that DCTCP applies ECN or PCN marking (I di= dn't read the publication yet). For the time being, Deutsche Telekom will not deploy RSVP or the like to si= gnal for QoS, but PCN is based on the presence of such a protocol. We could= imagine something lightweight, but nothing requiring state maintenance in = routers. So full PCN will not be deployed. But measurement based admissiion= control to signal network busy is within scope. PCN deployment requires (beyond others) the following mechanisms which aren= 't available: - threshold marking. - Ingress to egress aggregate measurement (difficult in the presence of ECM= P, may work if tunnels are used). There's a draft supported by me removing the need for the latter. The forme= r is still required but not available. I like the way the WG worked and the results it produced (and yet hoping th= at the above mentioned draft sees enough support to get WG status). QoS comes with a lot of complexity. As usual, only simple solutions allow f= or interoperable end to end deployment. As all standards bodies failed to s= tandardise a simple basic set of interoperable end to end QoS mechanisms (i= n general, not just regarding PCN), there's hardly any widely accepted stan= dard applied by all carriers. While Expedited Forwarding using a single DSCP is widely deployed, Assured = Forwarding (using four classes and 12 DSCPs without telling the reader whic= h application should use which class) is the first QoS standard creating as= many problems as it solves. That's true for most of the varuious other QoS= related standards which followed (not limited to IETF). There's too much f= lexibility and too little standardisation of simple solutions. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Hanne= s Tschofenig Sent: Friday, May 27, 2011 1:45 AM To: pcn@ietf.org Subject: [PCN] Deployment Status? Hi guys, I was wondering what the deployment status of the PCN mechanism is. Is it ending up like so many other QoS proposals? If so, did we learn somet= hing about what went wrong? Ciao Hannes _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From bob.briscoe@bt.com Fri May 27 05:54:56 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F53E06FA for ; Fri, 27 May 2011 05:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFGWpwv3PrVS for ; Fri, 27 May 2011 05:54:55 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDBBE0671 for ; Fri, 27 May 2011 05:54:55 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 13:54:54 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 13:54:53 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 130650088713; Fri, 27 May 2011 13:54:47 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.63.37]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p4RCsigp021308; Fri, 27 May 2011 13:54:45 +0100 Message-Id: <201105271254.p4RCsigp021308@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 May 2011 13:54:43 +0100 To: From: Bob Briscoe In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D084106F4DA@HE111648.emea1. cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D084106F4DA@HE111648.emea1.cds.t-internal.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 May 2011 12:54:53.0997 (UTC) FILETIME=[46192DD0:01CC1C6D] Cc: pcn@ietf.org Subject: Re: [PCN] Deployment Status? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 12:54:56 -0000 Hannes, Just a few additional points to add to Ruediger's email. At 07:46 27/05/2011, Ruediger.Geib@telekom.de wrote: >Hi Hannes, > >PCN is specified in a modular way. That's an advantage and parts of >PCN may see deployment. Bob mentioned, that DCTCP applies ECN or PCN >marking (I didn't read the publication yet). To clarify, DCTCP currently uses ECN, but there's work to test it with PCN threshold marking instead (it's not being called PCN, but it's exactly the same marking algo). >For the time being, Deutsche Telekom will not deploy RSVP or the >like to signal for QoS, but PCN is based on the presence of such a >protocol. We could imagine something lightweight, but nothing >requiring state maintenance in routers. So full PCN will not be >deployed. But measurement based admissiion control to signal network >busy is within scope. Just to be clear, the idea of PCN was to avoid per-flow state mtce in routers, except once, where you (probably) do flow policing at ingress. There has been work on using alternative signalling systems to RSVP, such as RACF with SIP at app layer and COPS down to the PCN edge router. Also, PCN has been considered for internal use, giving early warning that overbooking an MPLS-TE aggregate has started to reach its limits and needs increasing. >PCN deployment requires (beyond others) the following mechanisms >which aren't available: >- threshold marking. * Broadcom implemented threshold marking in their chipsets in early 2010 so it has been widely available for all vendors who buy-in their chipsets from Broadcom (which is a large part of the market). * I believe Huawei also implemented threshold marking, altho I don't know whether they are selling it as a feature. >- Ingress to egress aggregate measurement (difficult in the presence >of ECMP, may work if tunnels are used). * I believe Huawei implemented this too. Is anyone aware of any others? >There's a draft supported by me removing the need for the latter. >The former is still required but not available. > >I like the way the WG worked and the results it produced (and yet >hoping that the above mentioned draft sees enough support to get WG status). Yup >QoS comes with a lot of complexity. As usual, only simple solutions >allow for interoperable end to end deployment. As all standards >bodies failed to standardise a simple basic set of interoperable end >to end QoS mechanisms (in general, not just regarding PCN), there's >hardly any widely accepted standard applied by all carriers. > >While Expedited Forwarding using a single DSCP is widely deployed, >Assured Forwarding (using four classes and 12 DSCPs without telling >the reader which application should use which class) is the first >QoS standard creating as many problems as it solves. That's true for >most of the varuious other QoS related standards which followed (not >limited to IETF). There's too much flexibility and too little >standardisation of simple solutions. I agree with Ruediger on all this. Also, other criticial failings IMO: - Complex and/or non-existent APIs - Unrealistic applicability message. There's been a lack of recognition that QoS is a transient requirement for leading edge applications. For any particular app, the need goes away as as line rates increase (and queuing delay reduces), but the requirement moves to new leading edge apps. Instead, QoS has always been sold as something that is a characteristic of a particular app, which becomes patently false; just as the standards become ready everyone is already using the app without QoS. - Unrealistic economics. Lack of recognition that you don't need QoS if your policy is to continually maintain high quality BE by overprovisioning. This last point may be changing - recent predicitions seem to show that over the next 3-4 years revenues will fall significantly short of what is required to pay for predicted growth in demand for capacity - in both fixed and mobile. So you never know - we might yet be dragging out and dusting off the standards for some of the (simpler) QoS mechanisms some time soon. Bob >Regards, > >Ruediger > > >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >Of Hannes Tschofenig >Sent: Friday, May 27, 2011 1:45 AM >To: pcn@ietf.org >Subject: [PCN] Deployment Status? > >Hi guys, > >I was wondering what the deployment status of the PCN mechanism is. >Is it ending up like so many other QoS proposals? If so, did we >learn something about what went wrong? > >Ciao >Hannes > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From iesg-secretary@ietf.org Fri May 27 13:38:01 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BC4E0856; Fri, 27 May 2011 13:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-m+3yYxopv1; Fri, 27 May 2011 13:38:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22F8E065D; Fri, 27 May 2011 13:38:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110527203800.13071.15398.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2011 13:38:00 -0700 Cc: pcn@ietf.org Subject: [PCN] Last Call: (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 20:38:01 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri May 27 13:38:57 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4977BE0862; Fri, 27 May 2011 13:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Ze5f9P8eoX; Fri, 27 May 2011 13:38:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47B5E084F; Fri, 27 May 2011 13:38:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110527203856.15425.56836.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2011 13:38:56 -0700 Cc: pcn@ietf.org Subject: [PCN] Last Call: (PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 20:38:57 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN edge behaviour. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/ No IPR declarations have been submitted directly on this I-D.